This document is also available in this non-normative format: Diff from previous Editors Draft .
This document is licensed under a Creative Commons Attribution 3.0 License .
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 document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.
The source code for this document is available via Github at the followingThis 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
select
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
an
a
process
made
popular
by
OpenID,
we
show
how
one
can
tie
a
User
Agent
to
a
URL
URI
by
proving
that
one
has
write
access
to
the
URL.
URI.
WebID
is
a
simpler
alternative
to
OpenID
(fewer
connections),
that
an
authentication
protocol
which
uses
X.509
certificates
to
tie
associate
a
User
Agent
(Browser)
to
a
Person
identified
via
a
URL.
URI.
WebID
also
is
compatible
with
OpenID
and
provides
a
few
additional
features
to
OpenID.
These
features
include
such
as
trust
management,
management
via
digital
signatures,
and
free-form
extensibility
via
RDFa.
RDF.
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.
Subject
Alternative
Name
extension
with
a
URI
entry.
The
URI
http://example.org/webid#public
,
known
as
a
WebID
Subject
Alternative
Name
:
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 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
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 .
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>
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 publish the link from the HTML to the machine readable format as follows:
<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
Agents
Agent
s
and
Identification
Agents
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
a
particular
the
requested
resource.
Subject
Alternative
Name
extension
of
the
Identification
Certificate
.
There may be more than one URI in the SAN
We don't have any implementations for this second way of doing things, so this is still hypothetical. Implementations using TLS mutual-authentication are many
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
support
HTTP
content
negotiation.
be
able
to
deliver
at
least
RDF/XML
or
RDFa.
The
server
Verification
Agent
must
return
a
representation
in
RDF/XML
for
media
type
set
the
Accept-Header
to
request
application/rdf+xml
with
a
.
The
server
must
return
representation
in
XHTML+RDFa
for
media
type
higher
priority
than
text/html
or
media
type
and
application/xhtml+xml
.
Verification
Agents
and
Identification
Agents
may
If
the
server
answers
such
a
request
with
an
HTML
representation
of
the
resource,
this
should
support
any
other
RDF
format
via
HTTP
content
negotiation.
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
may
use
a
must
check
that
the
WebID
Profile
associates
the
WebID
with
the
public
key
given
in
the
X.509
Certificate.
There
are
number
of
different
methods
to
extract
ways
of
doing
this,
each
of
which
essentially
consists
in
checking
that
the
graph
of
relations
in
the
Profile
contain
a
pattern
of
relations.
Assuming
the
public
key
information
from
is
an
RSA
key,
and
that
its
modulus
is
"9D79BFE2498..."
and
exponent
"65537"
then
the
WebID
Profile
.
query
to
ask
the
graph
is
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
outlines
one
way
in
which
returns
true,
then
the
graph
has
validated
the
associated
public
key
with
the
WebID.
The above requires the graph to be able to do inferencing on dataytypes. This is because people may publish their modulus string in a number of syntactical ways. The modulus can 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
a
literal
inferencing
engine,
then
the
modulus
should
be
extracted
from
the
WebID
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
:
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 ] .
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.
This
section
still
needs
more
information.
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
Authorization
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:
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.
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: