This document is also available in this non-normative format: Diff from previous Editors Draft .
This
Copyright
©
2010-2011
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
is
licensed
under
a
Creative
Commons
Attribution
3.0
License
.
use
rules
apply.
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.
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 public key cryptography 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 ].
A general Introduction is provided for all that would like to understand why this specification is necessary to simplify usage of the Web.
The terms used throughout this specification are listed in the section titled Terminology .
Developers that are interested in implementing this specification will be most interested in the sections titled Authentication Sequence and Authentication Sequence Details .
This
section
describes
the
status
of
this
document
is
merely
a
public
working
draft
at
the
time
of
a
potential
specification.
It
has
no
official
standing
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
any
kind
current
W3C
publications
and
does
not
represent
the
support
or
consensus
latest
revision
of
any
standards
organisation.
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
This document was published by the WebID XG as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-xg-webid@w3.org ( subscribe , archives ). All feedback is welcome.
Publication as a Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This section is non-normative.
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.
This section is non-normative.
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.
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.
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?
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
is
compatible
with
OpenID
and
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.
Subject
Alternative
Name
extension
with
Subject
Alternative
Name
:
X509v3 extensions:
...
X509v3 Subject Alternative Name:
URI:http://example.org/webid#public
http://example.org/webid#public
would
contain
the
following:
X509v3 extensions: ... X509v3 Subject Alternative Name: URI:http://example.org/webid#public
TODO: cover the case where there are more than one URI entry
Subject
Alternative
Name
extension
of
the
Identification
Certificate
that
identifies
an
Identification
Agent
.
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.
The
user
agent
will
create
a
Identification
Certificate
with
a
Subject
Alternative
Name
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
Identification
Certificate
at
this
URI.
For
example,
if
a
user
Joe
controls
http://joe.example/profile
,
then
his
WebID
can
be
http://joe.example/profile#me
explain why the WebID URI is different from the URI of the WebID profile document.
As an example to use throughout this specification here is the following certificate as an output of the openssl program.
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
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
O=FOAF+SSL, OU=The Community Of Self Signers/UID=https://example.org/profile#me, CN=Joe (Personal)
Subject Public Key Info:
rsaEncryption
(2048 bit)
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
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
critical
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
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 Issuer: 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 Subject: O=FOAF+SSL, OU=The Community Of Self Signers/UID=https://example.org/profile#me, CN=Joe (Personal) Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) 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 Exponent: 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 X509v3 Subject Alternative Name: critical URI: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
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.
discuss the importance for UIs of the CN
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
The
WebID
Profile
document
must
expose
the
relation
between
the
WebID
URI
and
the
Identification
Agent
's
public
key
s
using
the
cert
and
rsa
ontologies,
as
well
as
the
cert
or
xsd
datatypes.
The
set
of
relations
to
be
published
at
the
WebID
Profile
document
can
be
presented
in
a
graphical
notation
as
follows.
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.
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.
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.
Add content negoatiation pointers
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.
A widely used format for writing RDF graphs is the Turtle notation.
@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 .
@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 .
There are many ways of writing out the above graph using RDFa in html. Here is just one example.
<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>
<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>
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
should
may
publish
the
link
from
the
HTML
to
the
a
machine
readable
format
(it
this
is
available
at
a
dedicated
URI)
as
follows:
<html>
<head>
<link type="rel" type="application/rdf+xml" href="profile.rdf"/>
</head>
<body> ... </body>
</html>
<html> <head> <link type="rel" type="application/rdf+xml" href="profile.rdf"/> </head> <body> ... </body> </html>
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.
TODO: the dsa ontology
TODO: discuss other formats and GRDDL, XSPARQL options for xml formats
summarize and point to content negotiation documents
The following steps are executed by Verification Agent s and Identification Agent 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.
Subject
Alternative
Name
extension
of
the
Identification
Certificate
.
The Identification Agent 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 Verification Agent can access a particular resource after the last step of the Authentication Sequence has been completed.
This section covers details about each step in the authentication process.
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.
This section will detail how the certificate is selected and sent to the Verification Agent.
A
Verification
Agent
must
be
able
to
process
documents
in
RDF/XML
[
RDF-SYNTAX-GRAMMAR
]
and
XHTML+RDFa
[
XHTML-RDFA
].
A
server
responding
to
a
WebID
Profile
request
should
be
able
to
deliver
at
least
RDF/XML
or
RDFa.
The
Verification
Agent
must
set
the
Accept-Header
to
request
application/rdf+xml
with
a
higher
priority
than
text/html
and
application/xhtml+xml
.
If
the
server
answers
such
a
request
with
an
HTML
representation
of
the
resource,
this
should
describe
the
WebId
Profile
with
RDFa.
This section will explain how a Verification Agent extracts semantic data describing the identification credentials from a WebID Profile.
The
Verification
Agent
must
There
are
number
of
different
ways
to
check
that
the
WebID
Profile
associates
the
WebID
with
the
public
key
given
in
the
X.509
Certificate.
There
are
number
of
ways
of
doing
this,
each
of
which
essentially
consists
in
certificate
against
the
one
provided
by
the
WebID
Profile
or
another
trusted
source,
the
essence
is
checking
that
the
graph
of
relations
in
the
Profile
contain
contains
a
pattern
of
relations.
Assuming
the
public
key
is
an
RSA
key,
and
that
its
modulus
is
"9D79BFE2498..."
and
exponent
"65537"
then
the
following
SPARQL
query
to
ask
the
graph
is
could
be
used:
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 . }
If the query returns true, then the graph has validated the associated public key with the WebID.
The
above
requires
the
graph
sparql
endpoint
(or
the
underlying
triple
store
to
be
able
to
do
inferencing
on
dataytypes.
This
is
because
people
the
numerical
values
may
publish
their
modulus
string
in
a
number
of
syntactical
ways.
be
expressed
with
different
xsd
and
cert
datatypes
which
must
all
be
supported
by
VerificationAgent
s.
The
modulus
can
cert
datatypes
allow
the
numerical
expression
to
be
colon
seperated,
spread
over
a
number
of
lines,
or
contain
arbitrary
non
hex
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.
Should we define the base64 notation?
If
a
Verifying
Agent
does
not
have
access
to
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
?webid
variable
in
the
following
query
with
the
required
value
the
Verifying
Agent
can
query
the
Profile
Graph
with
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 . }
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.
The public key could be a DSA key. We need to add an ontology for DSA too. What other cryptographic ontologies should we add?
This section will explain how an Identification Agent and a Verification Agent may communicate securely using a set of verified identification credentials.
If the Verification Agent has verified that the WebID Profile is owned by the Identification Agent , the Verification Agent should use the verified public key contained in the Identification Certificate for all TLS-based communication with the Identification Agent . This ensures that both the Verification Agent and the Identification Agent are communicating in a secure manner, ensuring cryptographically protected privacy for both sides.
The WebID Profile is a structured document that contains identification credentials for the Identification Agent expressed using the Resource Description Framework [ RDF-CONCEPTS ]. The following sections describe how to express certain common properties that could be used by Verification Agent s and other entities that consume a WebID Profile .
The following vocabularies are used in their shortened form in the subsequent sections:
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 WebID Profile :
Cryptographic details are important when Verification Agent s and Identification Agent s interact. The following properties should be used when conveying cryptographic information in WebID Profile documents:
This section is non-normative.
2011-02-10 Move to W3C WebID XG . Updates from previous unofficial WebID group include changes on RDF/XML publishing in HTML, clarification on multiple SAN URIs and WebID verification steps.
2010-08-09 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.
2010-07-25 Added WebID Profile section.
2010-07-18 Updates from WebID community related to RDF/XML support, authentication sequence corrections, abstract and introduction updates.
2010-07-11 Initial version.
This section is non-normative.
The following people have been instrumental in providing thoughts, feedback, reviews, criticism and input in the creation of this specification: