forked from webid-community/webid-spec
-
Notifications
You must be signed in to change notification settings - Fork 1
/
index-respec.html
687 lines (578 loc) · 28.2 KB
/
index-respec.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html>
<html>
<head>
<title>WebID 1.0</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<style type='text/css'>
code { font-family: monospace; }
span.hilite { color: red; /* font-weight: bold */ }
li p { margin-top: 0.3em;
margin-bottom: 0.3em; }
div.explanation { background-color: #ADD8E6;
width: 80%;
margin: 12px; padding: 8px; }
div.explanation li { margin-top: 8px; }
div.explanation dd { margin: 4px; }
.adef {
font-family: monospace;
font-weight: bold;
color: #ff4500 !important;
}
.aref {
font-family: monospace;
font-weight: bold;
color: #ff4500 !important;
}
span.entity { color: red; }
span.element { color: green; }
</style>
<script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
<!-- <script src='/ReSpec.js/js/respec.js' class='remove'></script> -->
<script class='remove'>
var preProc = {
apply: function(c) {
// process the document before anything else is done
var refs = document.querySelectorAll('adef') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
var p = item.parentNode ;
var con = item.innerHTML ;
var sp = document.createElement( 'dfn' ) ;
var tit = item.getAttribute('title') ;
if (!tit) {
tit = con;
}
sp.className = 'adef' ;
sp.title=tit ;
sp.innerHTML = con ;
p.replaceChild(sp, item) ;
}
refs = document.querySelectorAll('aref') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
var p = item.parentNode ;
var con = item.innerHTML ;
var sp = document.createElement( 'a' ) ;
sp.className = 'aref' ;
sp.setAttribute('title', con);
sp.innerHTML = '@'+con ;
p.replaceChild(sp, item) ;
}
// local datatype references
refs = document.querySelectorAll('ldtref') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
if (!item) continue ;
var p = item.parentNode ;
var con = item.innerHTML ;
var ref = item.getAttribute('title') ;
if (!ref) {
ref = item.textContent ;
}
if (ref) {
ref = ref.replace(/\n/g, '_') ;
ref = ref.replace(/\s+/g, '_') ;
}
var sp = document.createElement( 'a' ) ;
sp.className = 'datatype';
sp.title = ref ;
sp.innerHTML = con ;
p.replaceChild(sp, item) ;
}
// external datatype references
refs = document.querySelectorAll('dtref') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
if (!item) continue ;
var p = item.parentNode ;
var con = item.innerHTML ;
var ref = item.getAttribute('title') ;
if (!ref) {
ref = item.textContent ;
}
if (ref) {
ref = ref.replace(/\n/g, '_') ;
ref = ref.replace(/\s+/g, '_') ;
}
var sp = document.createElement( 'a' ) ;
sp.className = 'externalDFN';
sp.title = ref ;
sp.innerHTML = con ;
p.replaceChild(sp, item) ;
}
// now do terms
refs = document.querySelectorAll('tdef') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
if (!item) continue ;
var p = item.parentNode ;
var con = item.innerHTML ;
var ref = item.getAttribute('title') ;
if (!ref) {
ref = item.textContent ;
}
if (ref) {
ref = ref.replace(/\n/g, '_') ;
ref = ref.replace(/\s+/g, '_') ;
}
var sp = document.createElement( 'dfn' ) ;
sp.title = ref ;
sp.innerHTML = con ;
p.replaceChild(sp, item) ;
}
// now term references
refs = document.querySelectorAll('tref') ;
for (var i = 0; i < refs.length; i++) {
var item = refs[i];
if (!item) continue ;
var p = item.parentNode ;
var con = item.innerHTML ;
var ref = item.getAttribute('title') ;
if (!ref) {
ref = item.textContent ;
}
if (ref) {
ref = ref.replace(/\n/g, '_') ;
ref = ref.replace(/\s+/g, '_') ;
}
var sp = document.createElement( 'a' ) ;
var id = item.textContent ;
sp.className = 'tref' ;
sp.title = ref ;
sp.innerHTML = con ;
p.replaceChild(sp, item) ;
}
}
} ;
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
// embed RDFa data in the output
doRDFa: true,
specStatus: "unofficial",
//publishDate: "2010-07-05",
diffTool: "http://www3.aptest.com/standards/htmldiff/htmldiff.pl",
// the specifications short name, as in http://www.w3.org/TR/short-name/
shortName: "webid",
subtitle: "Web Identification and Discovery",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
copyrightStart: "2010",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2010-04-22",
//previousMaturity: "FPWD",
// if there a publicly available Editors Draft, this is the link
edDraftURI: "http://payswarm.com/webid/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
extraCSS: ['http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css'],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Manu Sporny", mailto:"msporny@digitalbazaar.com",
company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" }
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{ name: "Toby Inkster" },
{ name: "Henry Story", url: "http://bblfish.net/" }
],
// errata: 'http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata',
// name of the WG
wg: "Social Web XG",
// URI of the public WG page
wgURI: "http://esw.w3.org/Foaf%2Bssl",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "socialweb-xg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/44350/status",
maxTocLevel: 4,
preProcess: [ preProc ]
};
function updateExample(doc, content) {
// perform transformations to make it render and prettier
content = content.replace(/<!--/, '');
content = content.replace(/-->/, '');
content = doc._esc(content);
content = content.replace(/\*\*\*\*([^*]*)\*\*\*\*/g, '<span class="hilite">$1</span>') ;
return content ;
}
function updateDTD(doc, content) {
// perform transformations to
// make it render and prettier
content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
content = content.replace(/!ENTITY % ([^ \t\r\n]*)/g, '!ENTITY <span class="entity">% $1</span>');
content = content.replace(/!ELEMENT ([^ \t$]*)/mg, '!ELEMENT <span class="element">$1</span>');
return content;
}
function updateSchema(doc, content) {
// perform transformations to
// make it render and prettier
content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
content = content.replace(/<xs:element\s+name="([^&]*)"/g, '<xs:element name="<span class="element" id="schema_element_$1">$1</span>"') ;
return content;
}
function updateTTL(doc, content) {
// perform transformations to
// make it render and prettier
content = '<pre class="sh_sourceCode">' + doc._esc(content) + '</pre>';
content = content.replace(/@prefix/g, '<span class="sh_keyword">@prefix</span>');
return content;
}
</script>
</head>
<body>
<section id='abstract'>
<p>Identification and privacy have been at the center of how we
interact with sites on the Web. The explosion of Websites over the last decade
and a half has created a point of pain for anyone that uses the Web on a
regular basis. Remembering login details, passwords,
and sharing private information across the many websites that people use on a
daily basis has become more difficult and complicated than necessary. This
specification outlines a simple universal identification mechanism that is
distributed, openly extensible, improves privacy, security and control over how
one can identify themselves and control access to their information on the Web.
</p>
<section>
<h2>How to Read this Document</h2>
<p>There are a number of concepts that are covered in this document that the
reader may want to be aware of before continuing. General knowledge of
<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a>
is necessary to understand how to implement this specification.
WebID also uses HTTP over TLS [[!HTTP-TLS]], X.509 certificates
[[!X509V3]], and RDFa [[!RDFA-CORE]].</p>
<p>A general <a href="#introduction">Introduction</a> is provided for all that
would like to understand why this specification is necessary to simplify usage
of the Web.</p>
<p>The terms used throughout this specification are listed in the section
titled <a href="#terminology">Terminology</a>.</p>
<p>Developers that are interested in implementing this specification will be
most interested in the sections titled
<a href="#authentication-sequence">Authentication Sequence</a> and
<a href="#authentication-sequence-details">Authentication Sequence Details</a>.
</section>
</section>
<section id='sotd'>
<!-- <p>This document has been reviewed by W3C Members, by software
developers, and by other W3C groups and interested parties, and is
endorsed by the Director as a W3C Recommendation. It is a stable
document and may be used as reference material or cited from another
document. W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.</p> -->
The source code for this document is available via Github at the following
URL: <a href="http://github.com/msporny/webid-spec">http://github.com/msporny/webid-spec</a>
</section>
<section class='informative'>
<h1>Introduction</h1>
<p>
The WebID specification is designed to help alleviate the difficultly that
remembering different logins, passwords and settings for websites has created.
It is also designed to provide a universal and extensible mechanism to express
public and private information about yourself. This section outlines the
motivation behind the specification and the relationship to other similar
specifications that are in active use today.
</p>
<section class='informative'>
<h1>Motivation</h1>
<p>
It is a fundamental design criteria of the Web to enable individuals and
organizations to control how they interact with the rest of society. This
includes how one expresses their identity, public information and personal
details to social networks, Web sites and services.
</p>
<p>
Semantic Web vocabularies such as Friend-of-a-Friend (FOAF) permit distributed
hyperlinked social networks to exist. This vocabulary, along with other
vocabularies, allow one to add information and services protection to
distributed social networks.
</p>
<p>
One major criticism of open networks is that they seem to have no way of
protecting the personal information distributed on the web or limiting
access to resources. Few people are willing to make all their personal
information public, many would like large pieces to be protected, making
it available only to a select group of agents. Giving access to
information is very similar to giving access to services. There are many
occasions when people would like services to only be accessible to
members of a group, such as allowing only friends, family members,
colleagues to post an article, photo or comment on a blog. How does one do
this in a flexible way, without requiring a central point of
access control?
</p>
<p>
Using an process made popular by OpenID, we show how one can tie a User
Agent to a URL by proving that one has write access to the URL. WebID is
a simpler alternative to OpenID (fewer connections), that uses X.509
certificates to tie a User Agent (Browser) to a Person identified via a URL.
WebID also provides a few additional features to OpenID. These
features include trust management, via digital signatures, and free-form
extensibility via RDFa. By using the existing SSL certificate exchange
mechanism, WebID integrates more smoothly with existing Web browsers, including
browsers on mobile devices. WebID also permits automated session login
in addition to interactive session login. Additionally, all data is encrypted
and guaranteed to only be received by the person or organization that was
intended to receive it.
</p>
</section>
<section class='informative'>
<h1>Relation to OpenID</h1>
<p>While some may say that OpenID and WebID conflict, WebID is 100% compatible
with OpenID since both use a URL for identification. Therefore, WebID does not
intend to replace OpenID, but can work beside OpenID just as easily as providing
a complete solution. That said, there are a number of benefits that WebID
achieves over OpenID:
</p>
<p>WebID gives people and other agents a Web ID URL for identification, just
like OpenId does. However, in the case of WebID, the user does not need to
remember the URL, the browser or User Agent does. A login button on a
WebID web site is just a button. No need to enter any identifier like one
has to for OpenID. Just click the button. Your browser will then ask you what
identity you wish to use. The person that is browsing does not need to
remember either the WebID URL or the website password. The only password one
needs to remember is the one that is used to access their collection of
WebIDs in their browser.</p>
<p>The WebID protocol requires just one direct network connection to establish
identity via the client. The server requires one connection to the client and
one connection to retrieve the WebID Profile if it does not have the credential
information cached. Compare this to the much more complex OpenID sequence, which
requires six connections by the client to establish a login. In a world of
distributed data where each site can point to data on any other site, multiple
connections become costly to manage.</p>
<p>WebID builds on well established Internet and Web standards;
<a href="http://en.wikipedia.org/wiki/REST">REST</a>,
RDF [[RDF-PRIMER]], RDFa [[!RDFA-CORE]], TLS [[!HTTP-TLS]], and X.509
[[!X509V3]]. By building on previous standards, it makes both explaining and
implementing WebID easier on developers.</p>
<p>Since WebID is RESTful, you can perform basic HTTP operations to
<code>GET</code> your WebID, and if you needed update it, you can use
HTTP <code>PUT</code> semantics. You can also create a WebID via
<code>POST</code>. This is improved from the OpenID specification, which
requires a new set of operations described in the OpenID Attribute Exchange
specification.</p>
<p>It is easy to extend a WebID with new attributes via RDF. The power of
RDF and RDFa allows developers to add extensions to WebID by defining new
vocabularies that they publish. There is no authorization process necessary
and thus WebID allows for distributed innovation. Every WebID property is
a URI, which when clicked, can give you yet more information about what the
property means. A developer can create new usage classes by extending their
vocabulary at will. A developer can add relationships to a WebID by simply
adding more HTML to the developer's page. OpenID does not provide any type of
distributed innovation akin to RDF or RDFa.</p>
<p>WebID is built on RDF and thus enables all of the advanced semantic web
concepts that RDF enables. For example, a developer may perform machine
reasoning with a WebID. One can construct machine-executable statements like
"If this WebID claims to be a friend of one of our partner WebIDs that is
trusted and the relationship is bi-directional, trust the WebID."
While OpenID attempts to support this use case by mapping OpenID to RDF, it's
far easier to do with WebID because WebID is natively RDF-aware.</p>
<p>Implementing WebID is easier than OpenID because all of the basic
technologies have been working and integrated into Web browsers for many years.
There were already three interoperable implementations of WebID before this
specification was written.</p>
<p>WebID is truly decentralized - with WebID you get a web of trust.
OpenID only supports the Web of Trust model if you indirectly trust the
OpenID provider. In other words - OpenID is not truly decentralized. In OpenID
you must trust OpenID providers. With WebID you only have to trust the people
and the organizations with which you are communicating. In other words, you
don't have to ask anyone whether or not you can trust your friends. You can
query people that you trust directly to see if someone is trustworthy or not.
There is no need for a central WebID authority.
</p>
<p>WebID is fully distributed, anyone can setup a WebID by placing a single
file on a web server of their choosing. There is no need for a special
OpenID-like provider service. The only thing anyone that wants a WebID needs
is a web account where you can post your WebID file, ideally on your own domain
name. You can also use a WebID hosting provider, but it's not necessary for
WebID to work. While it is possible to run an OpenID server, other
OpenID applications may not trust you and thus you won't be able to fully
utilize your private OpenID credentials. The reason that there are a few
large OpenID providers and very few small OpenID providers is because of this
trust design issue related to OpenID.</p>
<p>WebID does not require HTTP redirects. Redirects are are problematic on many
cell phones, because telecoms heavily rely on proxys, which selectively block
redirects.</p>
<p>A WebID provider is 100% compatible with an OpenID provider and thus can
inter-operate with OpenID-powered networks.</p>
</section>
<section class='informative'>
<h1>Relation to OAuth</h1>
<p>
OAuth and WebID are mutually beneficial when used together. WebID can be
used to provide RSA parameters to the RSA-SHA1 signature method required by
OAuth 1.0. WebID can also be used to establish the consumer_key and HTTPS
connection that will be used to transmit OAuth Tokens in OAuth 2.0.
</p>
</section>
</section>
<section class='normative'>
<h1>The WebID Protocol</h1>
<section class='normative'>
<h1>Terminology</h1>
<dl>
<dt><tdef>Verification Agent</tdef></dt>
<dd>Performs authentication on provided WebID credentials and determines if
an <tref>Identification Agent</tref> can have access to a particular
resource. A <tref>Verification Agent</tref> is typically a Web server, but
may also be a peer on a peer-to-peer network.</dd>
<dt><tdef>Identification Agent</tdef></dt>
<dd>Provides identification credentials to a Verification Agent. The
<tref>Identification Agent</tref> is typically also a User Agent.</dd>
<dt><tdef>Identification Certificate</tdef></dt>
<dd>An X.509 [[!X509V3]] Certificate that MUST contain the
<code>Subject Alternative Name</code> field pointing to a URL that is
dereference-able and results in a document containing RDF data. For example
the certificate would contain <code>http://example.org/webid#public</code>,
known as a <tref>WebID URL</tref>, as
the <code>Subject Alternative Name</code>:
<code><pre>
X509v3 extensions:
...
X509v3 Subject Alternative Name:
URI:http://example.org/webid#public
</pre></code>
<dt><tdef>WebID URL</tdef></dt>
<dd>A URL specified in the <code>Subject Alternative Name</code> field of the
<tref>Identification Certificate</tref> that identifies a
<tref>WebID Profile</tref> document.</dd>
<dt><tdef>WebID Profile</tdef></dt>
<dd>
A structured document that contains identification credentials for the
<tref>Identification Agent</tref> expressed using the Resource Description
Framework [[RDF-CONCEPTS]]. The XHTML+RDFa 1.1 [[!XHTML-RDFA]] serialization
format MUST be supported by the mechanism, e.g. a Web Service, providing the
WebID Profile document. Alternate RDF serialization
formats, such as N3 [[!N3]], Turtle [[!TURTLE]], or RDF/XML
[[!RDF-SYNTAX-GRAMMAR]] MAY be supported by the mechanism providing the
WebID Profile document.
</dd>
</dl>
</section>
<section class='normative'>
<h1>Authentication Sequence</h1>
<p>The following steps are executed by Verification Agents and Identification
Agents to determine if access should be granted to a particular resource.
</p>
<ol>
<li>The <tref>Identification Agent</tref> attempts to access a resource
using HTTP over TLS [[!HTTP-TLS]] via the <tref>Verification Agent</tref>.</li>
<li>The <tref>Verification Agent</tref> MUST request the
<tref>Identification Certificate</tref> of the <tref>Identification Agent</tref>
as a part of the TLS client-cerificate retrieval protocol.</li>
<li>The <tref>Verification Agent</tref> MUST extract the <tref>WebID URL</tref>
contained in the <code>Subject Alternative Name</code> field of the
<tref>Identification Certificate</tref>. The <tref>WebID Profile</tref> document
MUST be dereferenced and all triples pertaining to the public key associated
with the <tref>WebID URL</tref> MUST be extracted.
</li>
<li>The remote document triples MUST be queried for information about the
public key contained in the <tref>Identification Certificate</tref>.
If the public key in the certificate is found in the list of public keys
associated with the <tref>WebID URL</tref>, the <tref>Verification Agent</tref>
MUST assume that the client has write access to the <tref>WebID Profile</tref> and
therefore owns the document.</li>
<li>At this point, the <tref>Verification Agent</tref> has verified that the
<tref>WebID Profile</tref> is owned by the <tref>Identification Agent</tref>. The
<tref>Verification Agent</tref> MUST use the now verified public key contained
in the <tref>Identification Certificate</tref> for all TLS-based communication
with the <tref>Identification Agent</tref>.
</ol>
<p>
The <tref>Identification Agent</tref> MAY re-establish a different identity at
any time by executing all of the steps in the Authentication Sequence again.
Additional algorithms, detailed in the next section, MAY be performed to
determine if the <tref>Verification Agent</tref> can access a particular
resource after the last step of the Authentication Sequence has been
completed.</li>
</p>
</section>
<section class='normative'>
<h1>Authentication Sequence Details</h1>
<p>This section covers details about each step in the authentication process.
</p>
<section class='normative'>
<h2>Initiating a TLS Connection</h2>
<p class="issue">This section will detail how the TLS connection process is
started and used by WebID to create a secure channel between the
Identification Agent and the Verification Agent.</p>
</section>
<section class='normative'>
<h2>Exchanging the Identification Certificate</h2>
<p class="issue">This section will detail how the certificate is selected and
sent to the Verification Agent.</p>
</section>
<section class='normative'>
<h2>Processing the WebID Profile</h2>
<p>A server responding to a WebID Profile request MUST support returning an
XHTML+RDFa [[!XHTML-RDFA]] document with either a <code>text/html</code> or
<code>application/xhtml+xml</code> MIMEtype. A server MAY support HTTP content
negotiation and return a document that conforms to N3 [[!N3]], Turtle
[[!TURTLE]], or RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
<p class="issue">This section will explain how a Verification Agent extracts
semantic data describing the identification credentials from a WebID Profile.</p>
</section>
<section class='normative'>
<h2>Extracting Identification URL Details</h2>
<p>
The <tref>Verification Agent</tref> may use a number of different methods to
extract the public key information from the <tref>WebID Profile</tref>.
</p>
The following SPARQL query outlines one way in which the public key
could be extracted from the <tref>WebID Profile</tref>:
<code><pre>
PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
SELECT ?modulus ?exp
WHERE {
?key cert:identity <http://example.org/webid#public>;
a rsa:RSAPublicKey;
rsa:modulus [ cert:hex ?modulus; ];
rsa:public_exponent [ cert:decimal ?exp ] .
}
</pre></code>
<p class="issue">This section still needs more information.</p>
</section>
<section class='normative'>
<h2>Determining Access Privileges</h2>
<p class="issue">This section will explain how a Verification Agent may
use the information discovered via a WebID URL to determine if one should
be able to access a particular resource. It will explain how a Verification
Agent can use links to other RDFa documents to build knowledge about the
given WebID.</p>
</section>
</section>
<section id="appendix">
<section class='informative' id="history">
<h1 >Change History</h1>
<p>2010-07-11 Initial version.</p>
</section>
<section class='informative' id="acknowledgements">
<h1>Acknowledgments</h1>
<p>The following people have been instrumental in providing thoughts, feedback,
reviews, criticism and input in the creation of this specification:</p>
<ul>
<li>Melvin Carvalho</li>
<li>Bruno Harbulot</li>
<li>Toby Inkster</li>
<li>Ian Jacobi</li>
<li>Jeff Sayre</li>
<li>Henry Story</li>
</ul>
</section>
</section>
</body>
</html>