forked from harbulot/webid-spec
-
Notifications
You must be signed in to change notification settings - Fork 1
/
index-respec.html
957 lines (833 loc) · 41.9 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
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
<?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; li
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-07-25",
previousMaturity: "ED",
previousURI: "http://payswarm.com/webid/drafts/ED-webid-20100725/",
// 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/" },
{ name: "Stéphane Corlosquet", mailto:"scorlosquet@gmail.com",
company: "Massachusetts General Hospital", companyURL: "http://massgeneral.org/" }
],
// 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", url: "http://tobyinkster.co.uk/" },
{ name: "Henry Story", url: "http://bblfish.net/" },
{ name: "Bruno Harbulot", url: "http://blog.distributedmatter.net/" },
{ name: "Reto Bachmann-Gmür", url: "http://trialox.org/" }
],
// 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",
// alternate formats for this document
alternateFormats: [
{ uri: 'drafts/ED-webid-20100809/diff-20100725.html',
label: "Diff from previous Editors Draft" }],
// 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>Social networking, identity and privacy have been at the center of how we
interact with the Web in the last decade. The explosion of social networking
sites has brought the world closer together as well as created new points of
pain regarding ease of use and the Web. Remembering login details, passwords,
and sharing private information across the many websites and social groups
that we are a part of has become more difficult and complicated than necessary.
The Social Web is designed to ensure that control of identity and privacy
settings is always simple and under one's control. WebID is a key enabler of the
Social Web. 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>
and RDF [[!RDF-PRIMER]] and RDFa [[!RDFA-CORE]] is necessary to understand how
to implement this specification. WebID uses a number of specific technologies
like HTTP over TLS [[!HTTP-TLS]], X.509 certificates [[!X509V3]],
RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]].</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>.</p>
</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
URI: <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 selected 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 a process made popular by OpenID, we show how one can tie a User
Agent to a URI by proving that one has write access to the URI.
WebID is an authentication protocol which uses X.509
certificates to associate a User Agent (Browser) to a Person identified via a URI.
A WebID profile can also be used for OpenID, WebId provides a few additional features such as
trust management via digital signatures, and free-form
extensibility via RDF. By using the existing SSL certificate exchange
mechanism, WebID integrates 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>
<section>
<h1>Preconditions</h1>
<section>
<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 <tref>Verification Agent</tref>. 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 exactly one
<code>Subject Alternative Name</code> extension with a URI entry. The URI
identifies the <tref>Identification Agent</tref>. The URI SHOULD be
dereference-able and result in a document containing RDF data. For example,
the certificate would contain <code>http://example.org/webid#public</code>,
known as a <tref>WebID URI</tref>, as the <code>Subject Alternative Name</code>:
<pre>
X509v3 extensions:
...
X509v3 Subject Alternative Name:
URI:http://example.org/webid#public
</pre>
<p class="issue">TODO: cover the case where there are more than one URI entry</p>
</dd>
<dt><tdef>WebID URI</tdef></dt>
<dd>A URI specified via the <code>Subject Alternative Name</code> extension
of the <tref>Identification Certificate</tref> that identifies an
<tref>Identification Agent</tref>.</dd>
<dt><tdef>public key</tdef></dt>
<dd>A widely distributed cryptographic key that can be used to verify
digital signatures and encrypt data between a sender and a receiver. A public
key is always included in an <tref>Identification Certificate</tref>.</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]]. Either the XHTML+RDFa 1.1 [[!XHTML-RDFA]]
serialization format or the RDF/XML [[!RDF-SYNTAX-GRAMMAR]] 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]] or Turtle [[!TURTLE]], MAY be supported by the
mechanism providing the WebID Profile document.
<p class="issue">Whether or not RDF/XML, XHTML+RDFa 1.1, both or neither
serialization of RDF should be required serialization formats in the
specification is currently under heavy debate.</p>
</dd>
</dl>
</section>
<section class='normative'>
<h1>Creating the certificate</h1>
<p>The user agent will create a <tref>Identification Certificate</tref> with a
<code>Subject Alternative Name</code> URI entry. This URI must be one that
dereferences to a document the user controls so that he can publish the
public key of the <tref>Identification Certificate</tref> at this URI.</p>
<p>For example, if a user Joe controls <code>http://joe.example/profile</code>,
then his WebID can be <code>http://joe.example/profile#me</code></p>
<p class="issue">explain why the WebID URI is different from the URI of the WebID profile document.</p>
<p>As an example to use throughout this specification here is the
following certificate as an output of the openssl program.</p>
<p class="example">
<pre>
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5f:df:d6:be:2c:73:c1:fb:aa:2a:2d:23:a6:91:3b:5c
Signature Algorithm: sha1WithRSAEncryption
<span style="color: red">Issuer:</span> O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority
Validity
Not Before: Jun 8 14:16:14 2010 GMT
Not After : Jun 8 16:16:14 2010 GMT
<span style="color: red">Subject:</span> O=FOAF+SSL, OU=The Community Of Self Signers/UID=https://example.org/profile#me, CN=Joe (Personal)
Subject Public Key Info:
<span style="color: red"> Public Key Algorithm:</span> rsaEncryption
<span style="color: red">Public-Key:</span> (2048 bit)
<span style="color: red">Modulus:</span>
00:cb:24:ed:85:d6:4d:79:4b:69:c7:01:c1:86:ac:
c0:59:50:1e:85:60:00:f6:61:c9:32:04:d8:38:0e:
07:19:1c:5c:8b:36:8d:2a:c3:2a:42:8a:cb:97:03:
98:66:43:68:dc:2a:86:73:20:22:0f:75:5e:99:ca:
2e:ec:da:e6:2e:8d:15:fb:58:e1:b7:6a:e5:9c:b7:
ac:e8:83:83:94:d5:9e:72:50:b4:49:17:6e:51:a4:
94:95:1a:1c:36:6c:62:17:d8:76:8d:68:2d:de:78:
dd:4d:55:e6:13:f8:83:9c:f2:75:d4:c8:40:37:43:
e7:86:26:01:f3:c4:9a:63:66:e1:2b:b8:f4:98:26:
2c:3c:77:de:19:bc:e4:0b:32:f8:9a:e6:2c:37:80:
f5:b6:27:5b:e3:37:e2:b3:15:3a:e2:ba:72:a9:97:
5a:e7:1a:b7:24:64:94:97:06:6b:66:0f:cf:77:4b:
75:43:d9:80:95:2d:2e:85:86:20:0e:da:41:58:b0:
14:e7:54:65:d9:1e:cf:93:ef:c7:ac:17:0c:11:fc:
72:46:fc:6d:ed:79:c3:77:80:00:0a:c4:e0:79:f6:
71:fd:4f:20:7a:d7:70:80:9e:0e:2d:7b:0e:f5:49:
3b:ef:e7:35:44:d8:e1:be:3d:dd:b5:24:55:c6:13:
91:a1
<span style="color: red">Exponent:</span> 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Subject Key Identifier:
08:8E:A5:5B:AE:5D:C3:8B:00:B7:30:62:65:2A:5A:F5:D2:E9:00:FA
<span style="color: red">X509v3 Subject Alternative Name:</span> critical
<span style="color: red">URI:</span>https://joe.example/profile#me
Signature Algorithm: sha1WithRSAEncryption
cf:8c:f8:7b:b2:af:63:f0:0e:dc:64:22:e5:8a:ba:03:1e:f1:
ee:6f:2c:f5:f5:10:ad:4c:54:fc:49:2b:e1:0d:cd:be:3d:7c:
78:66:c8:ae:42:9d:75:9f:2c:29:71:91:5c:29:5b:96:ea:e1:
e4:ef:0e:5c:f7:07:a0:1e:9c:bf:50:ca:21:e6:6c:c3:df:64:
29:6b:d3:8a:bd:49:e8:72:39:dd:07:07:94:ac:d5:ec:85:b1:
a0:5c:c0:08:d3:28:2a:e6:be:ad:88:5e:2a:40:64:59:e7:f2:
45:0c:b9:48:c0:fd:ac:bc:fb:1b:c9:e0:1c:01:18:5e:44:bb:
d8:b8
</pre>
</p>
<p class="issue">Should we formally require the Issuer to be
O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority. This was discussed on the list as allowing servers to distinguish certificates that are foaf+Ssl enabled from others. Will probably need some very deep TLS thinking to get this right.</p>
<p class="issue">discuss the importance for UIs of the CN</p>
<p class="issue">The above certificate is no longer valid, as I took an valid certificate and change the time and WebID. As a result the Signatiure is now false. A completely valid certificate should be generated to avoid nit-pickers picking nits</p>
</section>
<section class='normative'>
<h1>Publishing the WebID Profile Document</h1>
<p>The <tref>WebID Profile</tref> document MUST expose the relation between the
<tref>WebID URI</tref> and the <tref>Identification Agent</tref>'s <tref>public key</tref>s
using the <code>cert</code> and <code>rsa</code> ontologies, as well as the
<code>cert</code> or <code>xsd</code> datatypes. The set of relations to be
published at the <tref>WebID Profile</tref> document can be presented in a
graphical notation as follows.</p>
<img alt="Web ID graph" src="img/WebIdGraph.jpg"/>
<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph by the grayed out relations.</p>
<p>The encoding of this graph is immaterial to the protocol, so long as a well known mapping to the format of the representation to such a graph can be found. Below we discuss the most well known formats, and a method for dealing with new unknown formats as they come along.</p>
<p>The WebID provider must publish the graph of relations in one of the well known formats, though he may publish it in a number of formats to increase the useabulity of his site using Content Negotations.</p>
<p class="issue">Add content negoatiation pointers</p>
<p>It is particularly useful to have one of the representations be in HTML or XHTML even if it is not marked up in RDFa as this allows people using a web browser to understand what the information at that URI represents.</p>
<section class='normative'>
<h1>Turtle</h1>
<p>A widely used format for writing RDF graphs is the Turtle notation. </p>
<p class="example">
<pre>
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix : <https://joe.example/profile#> .
:me a foaf:Person;
foaf:name "Joe" .
[] a rsa:RSAPublicKey;
rsa:modulus """
00:cb:24:ed:85:d6:4d:79:4b:69:c7:01:c1:86:ac:
c0:59:50:1e:85:60:00:f6:61:c9:32:04:d8:38:0e:
07:19:1c:5c:8b:36:8d:2a:c3:2a:42:8a:cb:97:03:
98:66:43:68:dc:2a:86:73:20:22:0f:75:5e:99:ca:
2e:ec:da:e6:2e:8d:15:fb:58:e1:b7:6a:e5:9c:b7:
ac:e8:83:83:94:d5:9e:72:50:b4:49:17:6e:51:a4:
94:95:1a:1c:36:6c:62:17:d8:76:8d:68:2d:de:78:
dd:4d:55:e6:13:f8:83:9c:f2:75:d4:c8:40:37:43:
e7:86:26:01:f3:c4:9a:63:66:e1:2b:b8:f4:98:26:
2c:3c:77:de:19:bc:e4:0b:32:f8:9a:e6:2c:37:80:
f5:b6:27:5b:e3:37:e2:b3:15:3a:e2:ba:72:a9:97:
5a:e7:1a:b7:24:64:94:97:06:6b:66:0f:cf:77:4b:
75:43:d9:80:95:2d:2e:85:86:20:0e:da:41:58:b0:
14:e7:54:65:d9:1e:cf:93:ef:c7:ac:17:0c:11:fc:
72:46:fc:6d:ed:79:c3:77:80:00:0a:c4:e0:79:f6:
71:fd:4f:20:7a:d7:70:80:9e:0e:2d:7b:0e:f5:49:
3b:ef:e7:35:44:d8:e1:be:3d:dd:b5:24:55:c6:13:
91:a1
"""^^cert:hex;
rsa:public_exponent "65537"^^cert:int;
cert:identity :me .
</pre>
</p>
</section>
<section>
<h1>RDFa HTML notation</h1>
<p>There are many ways of writing out the above graph using RDFa in
html. Here is just one example.</p>
<p class="example">
<pre>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:cert="http://www.w3.org/ns/auth/cert#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rsa="http://www.w3.org/ns/auth/rsa#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<head>
</head>
<body>
<h2>My RSA Public Key</h2>
<dl typeof="rsa:RSAPublicKey">
<dt>WebId</dt><dd href="#me" rel="cert:identity">http://joe.example/profile#me</dd>
<dt>Modulus (hexadecimal)</dt>
<dd property="rsa:modulus" datatype="cert:hex">
00:cb:24:ed:85:d6:4d:79:4b:69:c7:01:c1:86:ac:
c0:59:50:1e:85:60:00:f6:61:c9:32:04:d8:38:0e:
07:19:1c:5c:8b:36:8d:2a:c3:2a:42:8a:cb:97:03:
98:66:43:68:dc:2a:86:73:20:22:0f:75:5e:99:ca:
2e:ec:da:e6:2e:8d:15:fb:58:e1:b7:6a:e5:9c:b7:
ac:e8:83:83:94:d5:9e:72:50:b4:49:17:6e:51:a4:
94:95:1a:1c:36:6c:62:17:d8:76:8d:68:2d:de:78:
dd:4d:55:e6:13:f8:83:9c:f2:75:d4:c8:40:37:43:
e7:86:26:01:f3:c4:9a:63:66:e1:2b:b8:f4:98:26:
2c:3c:77:de:19:bc:e4:0b:32:f8:9a:e6:2c:37:80:
f5:b6:27:5b:e3:37:e2:b3:15:3a:e2:ba:72:a9:97:
5a:e7:1a:b7:24:64:94:97:06:6b:66:0f:cf:77:4b:
75:43:d9:80:95:2d:2e:85:86:20:0e:da:41:58:b0:
14:e7:54:65:d9:1e:cf:93:ef:c7:ac:17:0c:11:fc:
72:46:fc:6d:ed:79:c3:77:80:00:0a:c4:e0:79:f6:
71:fd:4f:20:7a:d7:70:80:9e:0e:2d:7b:0e:f5:49:
3b:ef:e7:35:44:d8:e1:be:3d:dd:b5:24:55:c6:13:
91:a1
</dd>
<dt>Exponent (decimal)</dt>
<dd property="rsa:public_exponent" datatype="cert:int">65537</dd>
</dl>
</body>
</html>
</pre>
</p>
<p>If a WebId provider would rather prefer not to mark up his data in RDFa, but just provide a human readable format for users and have the RDF graph appear in a machine readable format such as RDF/XML then he MAY publish the link from the HTML to a machine readable format (it this is available at a dedicated URI) as follows:</p>
<p class="example">
<pre>
<html>
<head>
<link type="rel" type="application/rdf+xml" href="profile.rdf"/>
</head>
<body> ... </body>
</html>
</pre>
</p>
</section>
<section>
<h1>In RDF/XML</h1>
<p>RDF/XML is easy to generate automatically from structured data, be it in object notiation or in relational databases. Parsers for it are also widely available.</p>
<p class="issue">TODO: the dsa ontology</p>
</section>
<section>
<h1>In Portable Contacts format using GRDDL</h1>
<p class="issue">TODO: discuss other formats and GRDDL, XSPARQL options for xml formats</p>
<p class="issue">summarize and point to content negotiation documents</p>
</section>
</section>
</section>
<section class='normative'>
<h1>The WebID Protocol</h1>
<section class='normative'>
<h1>Authentication Sequence</h1>
<p>The following steps are executed by <tref>Verification Agent</tref>s and
<tref>Identification Agent</tref>s to determine the global identity of the
requesting agent. Once this is known, the identity can be used to determine
if access should be granted to the requested 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-certificate retrieval protocol.</li>
<li>The <tref>Verification Agent</tref> MUST extract the <tref>public key</tref> and the
<tref>WebID URI</tref> contained in the <code>Subject Alternative Name</code>
extension of the <tref>Identification Certificate</tref>.</li>
<li>The <tref>public key</tref> information associated with the
<tref>WebID URI</tref> MUST be checked by the <tref>Verification Agent</tref>.
This process SHOULD occur either by dereferencing the <tref>WebID URI</tref> and
extracting RDF data from the resulting document, or by utilizing a cached
version of the RDF data contained in the document or other data source that is
up-to-date and trusted by the <tref>Verification Agent</tref>. The processing
and extraction mechanism is further detailed in the sections titled
<a href="#processing-the-webid-profile">Processing the WebID Profile</a> and
<a href="#extracting-webid-URI-details">Extracting WebID URI Details</a>.
</li>
<li>If the <tref>public key</tref> in the
<tref>Identification Certificate</tref> is found in the list of
<tref>public key</tref>s associated with the <tref>WebID URI</tref>, the
<tref>Verification Agent</tref> MUST assume that the client intends to use
this <tref>public key</tref> to verify their ownership of the <tref>WebID URI</tref>.</li>
<li>
The <tref>Verification Agent</tref> verifies that the
<tref>Identification Agent</tref> owns the private key corresponding to the public key sent in the
<tref>Identification Certificate</tref>. This SHOULD be fulfilled by performing TLS mutual-authentication
between the <tref>Verification Agent</tref> and the
<tref>Identification Agent</tref>.
If the <tref>Verification Agent</tref> does not have access to the TLS layer,
a digital signature challenge MUST be provided by the
<tref>Verification Agent</tref>. These processes are detailed in the sections
titled <a href="#authorization">Authorization</a> and
<a href="#secure-communication">Secure Communication</a>.</li>
<li>If the <tref>public key</tref> in the
<tref>Identification Certificate</tref> matches one in the set given by the
profile document graph given above then the <tref>Verification Agent</tref>
knows that the <tref>Identification Agent</tref> is indeed identified by the
<tref>WebID URI</tref>. The verification is done by querying the
Personal Profile graph as specified in <a href="#extracting-webid-uri-details">querying the RDF graph</a>.</li>
</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.
</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 <tref>Verification Agent</tref> MUST be able to process documents in RDF/XML
[[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]]. A server responding to
a <tref>WebID Profile</tref> request SHOULD be able to deliver at least RDF/XML
or RDFa. The <tref>Verification Agent</tref> MUST set the Accept-Header to request
<code>application/rdf+xml</code> with a higher priority than <code>text/html</code>
and <code>application/xhtml+xml</code>. If the server answers such a request
with an HTML representation of the resource, this SHOULD describe the WebId Profile
with RDFa.
</p>
<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>Verifying the WebID is identified by that public key</h2>
<p>
There are number of different ways to check that the public key given in the X.509
certificate against the one provided by the <tref>WebID Profile</tref> or another
trusted source, the essence is checking that the graph of relations in the
Profile contains a pattern of relations.
</p>
<p>Assuming the public key is an RSA key, and that its modulus is
"9D79BFE2498..." and exponent "65537" then the following SPARQL query could be used:
</p>
<pre class='example'>
PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
ASK {
[] cert:identity <http://example.org/webid#public>;
rsa:modulus "9D79BFE2498..."^^cert:hex;
rsa:public_exponent "65537"^^cert:int .
}
</pre>
<p>If the query returns true, then the graph has validated the associated
public key with the WebID.</p>
<p>The above requires the sparql endpoint (or the underlying triple store
to be able to do inferencing on dataytypes. This is because the numerical
values may be expressed with different xsd and cert datatypes which must all
be supported by <tref>VerificationAgent</tref>s. The cert datatypes allow
the numerical expression to be spread over a number of lines, or contain
arbitrary characters such as "9D ☮ 79 ☮ BF ☮ E2 ☮ F4 ☮ 98 ☮..." . The datatype
itself need not necessarily be expressed in cert:hex, but could use a number of
xsd integer datatype notations, cert:int or future base64 notations.
</p>
<p class="issue">Should we define the base64 notation?</p>
<p>If the SPARQL endpoint doesn't provide a literal inferencing engine, then the modulus should be extracted from the graph, normalised into a big integer (integers without an upper bound), and compared with the values given in the public key certificate. After replacing the <code>?webid</code> variable in the following query with the required value the <tref>Verifying Agent</tref> can query the Profile Graph with</p>
<pre class='example'>
PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
SELECT ?m ?e
WHERE {
[] cert:identity ?webid ;
rsa:modulus ?m ;
rsa:public_exponent ?e .
}
</pre>
<p>Here the verification agent must check that one of the answers for ?m and ?e
matches the integer values of the modulus and exponent given in the public key in the certificate.</p>
<p class="issue"> The public key could be a DSA key. We need to add an ontology for DSA too. What other cryptographic ontologies should we add?</p>
</section>
<section class='normative'>
<h2>Authorization</h2>
<p class="issue">This section will explain how a Verification Agent may
use the information discovered via a WebID URI 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 class='normative'>
<h2>Secure Communication</h2>
<p class="issue">This section will explain how an Identification Agent and
a Verification Agent may communicate securely using a set of verified
identification credentials.</p>
<p>
If 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> SHOULD use the verified
<tref>public key</tref> contained in the <tref>Identification Certificate</tref>
for all TLS-based communication with the <tref>Identification Agent</tref>.
This ensures that both the <tref>Verification Agent</tref> and the
<tref>Identification Agent</tref>
are communicating in a secure manner, ensuring cryptographically protected
privacy for both sides.
</p>
</section>
</section>
<section class='normative'>
<h2>The WebID Profile</h2>
<p>The <tref>WebID Profile</tref> is a structured document that contains
identification credentials for the <tref>Identification Agent</tref> expressed
using the Resource Description Framework [[RDF-CONCEPTS]]. The following
sections describe how to express certain common properties that could be used
by <tref>Verification Agent</tref>s and other entities that consume a
<tref>WebID Profile</tref>.</p>
<p>The following vocabularies are used in their shortened form in the
subsequent sections:</p>
<dl>
<dt>foaf</dt>
<dd>http://xmlns.com/foaf/0.1/</dd>
<dt>cert</dt>
<dd>http://www.w3.org/ns/auth/cert#</dd>
<dt>rsa</dt>
<dd>http://www.w3.org/ns/auth/rsa#</dd>
</dl>
<section class='normative'>
<h2>Personal Information</h2>
<p>Personal details are the most common requirement when registering an
account with a website. Some of these pieces of information include an e-mail
address, a name and perhaps an avatar image. This section includes
properties that SHOULD be used when conveying key pieces of personal
information but are NOT REQUIRED to be present in a <tref>WebID Profile</tref>:</p>
<dl>
<dt>foaf:mbox</dt>
<dd>The e-mail address that is associated with the WebID URI.</dd>
<dt>foaf:name</dt>
<dd>The name that is most commonly used to refer to the individual
or agent.</dd>
<dt>foaf:depiction</dt>
<dd>An image representation of the individual or agent.</dd>
</dl>
</section>
<section class='normative'>
<h2>Cryptographic Details</h2>
<p>Cryptographic details are important when <tref>Verification Agent</tref>s
and <tref>Identification Agent</tref>s interact. The following properties
SHOULD be used when conveying cryptographic information in <tref>WebID Profile</tref>
documents:</p>
<dl>
<dt>rsa:RSAPublicKey</dt>
<dd>Expresses an RSA public key. The RSAPublicKey MUST specify the
rsa:modulus and rsa:public_exponent properties.</dd>
<dt>cert:identity</dt>
<dd>Used to associate an RSAPublicKey with a WebID URI. A WebID Profile
MUST contain at least one RSAPublicKey that is associated with the
corresponding WebID URI.</dd>
</dl>
</section>
</section>
</section>
<section class='appendix informative' id="history">
<h1>Change History</h1>
<p><a href="">2010-08-09</a> Updates from WebID community: moved OpenID/OAuth sections to separate document, switched to the URI terminology instead of URL, added "Creating the certificate" and "Publishing the WebID Profile document" sections with a WebID graph and serializations in Turtle and RDFa, improved SPARQL queries using literal notation with cert datatypes, updated list of contributors, and many other fixes.</p>
<p><a href="http://github.com/msporny/webid-spec/commit/b19d2812901b4511fdf9876c1be53bb36ee3201e">2010-07-25</a> Added WebID Profile section.</p>
<p><a href="http://github.com/msporny/webid-spec/commit/211d197510ca119c21ae48f3e5aa3f931ea88672">2010-07-18</a> Updates from WebID community related to RDF/XML support, authentication sequence corrections, abstract and introduction updates.</p>
<p><a href="http://github.com/msporny/webid-spec/commit/a54dee9c242b08edaac617d678215b389dd3556d">2010-07-11</a> 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>
<li>Kingsley Idehen, OpenLink Software</li>
<li>Seth Russell</li>
<li>Sarven Capadisli</li>
<li>Nathan Rixham</li>
</ul>
</section>
</body>
</html>