This document is also available in this non-normative format: Diff from previous Editors Draft .
Copyright © 2010-2011 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
A
global
distributed
Social
Web
requires
that
each
person
be
able
to
control
their
identity,
that
this
identity
be
linkable
across
sites
-
placing
each
person
in
a
Web
of
relationships
-
and
that
it
be
possible
to
authenticate
globally
with
such
identities
allowing
each
user
identities.
By
making
distributed
authentication
easy
one
can
allow
everybody
to
protect
their
resources
and
enable
his
their
preferred
privacy
settings.
This
specification
outlines
a
simple
universal
identification
mechanism
that
is
distributed,
openly
extensible,
improves
privacy,
security
and
control
over
how
each
person
can
identify
themselves
in
order
to
allow
fine
grained
access
control
to
their
information
on
the
Web.
It
does
this
by
applying
the
best
practices
of
Web
Architecture
whilst
building
on
well
established
widely
deployed
protocols
and
standards
such
as
RDF
including
HTML,
XHTML,
URIs,
HTTP,
TLS,
X509
Certificates,
and
TLS.
RDF
Semantics.
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 ] 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 at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is produced from work by the W3C WebID Incubator Group . This is an internal draft document and may not even end up being officially published. It may also be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. The source code for this document is available at the following URI: https://dvcs.w3.org/hg/WebIDThis 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
an
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
protocol
enables
secure,
efficient
and
settings
for
websites
has
created.
maximally
user
friendly
authentication
on
the
Web.
It
is
also
designed
to
provide
a
universal
and
extensible
mechanism
enables
people
to
express
public
and
private
information
about
yourself.
This
section
outlines
the
motivation
behind
the
specification
and
authenticate
onto
any
site
by
simply
clicking
on
one
of
the
relationship
certificates
proposed
to
other
similar
specifications
that
are
them
by
their
browser.
These
certificates
can
be
created
by
any
Web
Site
for
their
users
in
active
use
today.
1.1
Motivation
This
section
is
non-normative.
It
one
click.
The
identifier,
known
as
the
WebID
,
is
a
fundamental
design
criteria
of
the
Web
to
enable
individuals
and
organizations
to
control
how
they
interact
with
URI
whose
sense
can
be
found
in
the
rest
associated
Profile
Page
,
a
type
of
society.
This
includes
how
one
expresses
their
identity,
public
information
and
personal
details
to
social
networks,
Web
sites
and
services.
web
page
that
any
Social
Network
user
is
familiar
with.
Semantic
These
WebIDs
can
be
used
to
build
a
Web
of
trust
using
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
foaf
by
allowing
people
are
willing
to
make
all
link
together
their
personal
information
public,
many
would
like
large
pieces
to
be
protected,
making
it
available
only
to
profiles
in
a
selected
group
public
or
protected
manner.
Such
a
web
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
trust
can
then
be
accessible
to
members
of
used
by
a
group,
such
as
Service
to
make
authorization
decisions,
by
allowing
only
friends,
family
members,
colleagues
access
to
post
an
article,
photo
or
comment
resource
depending
on
the
properties
of
an
agent,
such
that
the
he
is
known
by
some
relevant
people,
works
at
a
blog.
How
does
one
do
this
in
a
flexible
way,
without
requiring
given
company,
is
a
central
point
family
member,
is
part
of
access
control?
some
group,
...
Using
a
process
made
popular
by
OpenID,
we
show
The
WebID
protocol
specifies
how
one
a
Service
can
tie
authenticate
a
User
Agent
user
after
requesting
his
Certificate
without
needing
to
rely
on
this
being
signed
by
a
URI
well
known
Certificate
Authority.
This
is
done
by
proving
that
one
has
write
access
to
dereferencing
the
URI.
WebID
is
an
authentication
protocol
which
uses
X.509
certificates
Profile
,
and
checking
if
it
describes
the
user
as
being
in
control
of
the
the
private
key
related
to
associate
a
User
Agent
(Browser)
the
Public
Key
published
in
the
Certificate
she
used
to
a
Person
identified
via
a
URI.
A
authenticate.
WebID
profile
authentication
can
also
be
used
for
OpenID,
WebID
provides
a
few
additional
features
automatic
authentication
by
robots,
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
web
crawlers
of
linked
data
repositories,
which
could
be
agents
working
on
mobile
devices.
WebID
also
permits
automated
session
login
behalf
of
users
to
help
them
in
addition
their
daily
tasks.
The
WebID
protocol
is
not
limited
to
interactive
session
login.
Additionally,
all
data
authentication
on
the
World
Wide
Web,
but
can
work
with
any
TLS
based
protocol.
This
specification
is
encrypted
divided
in
the
following
sections.
This
section
gives
a
high
level
overview
of
the
WebID
Protocol,
and
guaranteed
to
only
be
received
by
presents
the
person
or
organization
organisation
of
the
specification
and
the
conventions
used
throughout
the
document.
Section
2
lists
the
preconditions
that
was
intended
need
to
receive
it.
be
in
place
for
any
authentication
sequence
to
be
successful:
which
include
the
creation
of
a
WebID
Profile
and
the
creation
of
a
WebID
Certificate
2.
Preconditions
Section
3
on
the
WebID
Protocol
describes
in
detail
how
a
server
can
authenticate
a
user.
Subject
Alternative
Name
WebID
published
there.
This
is
usually
done,
because
the
TLS
Service
Light
did
not
verify
the
SAN
using
a
Certificate
Authority
signature.
But
it
can
also
be
done
to
verify
that
the
Certificate
is
still
valid.
Subject
Alternative
Name
extension
with
at
least
one
URI
entry
identifying
the
Subject
.
This
URI
should
be
one
of
the
URIs
with
a
dereferenceable
secure
scheme,
such
as
https://
.
Dereferencing
this
URI
should
return
a
representation
containing
RDF
data.
For
example,
a
certificate
identifying
the
WebID
URI
https://bob.example/profile#me
would
contain
the
following:
X509v3 extensions: ... X509v3 Subject Alternative Name: URI:https://bob.example/profile#meAnd it would have a WebID Profile at
https://bob.example/profile
Such
a
URI
is
known
as
a
WebID
.
Most profiles are currently written out in either of those formats. Whether or not XHTML+RDFa 1.1, both either serialization of RDF should be required serialization formats in the specification is currently under heavy debate and is open to change.
Examples assume the following namespace prefix bindings unless otherwise stated:
Prefix | IRI |
---|---|
cert
|
http://www.w3.org/ns/auth/cert# |
xsd
|
http://www.w3.org/2001/XMLSchema# |
foaf
|
http://xmlns.com/foaf/0.1/ |
ex
|
https://bob.example/profile# |
The
ex:
namespace
is
a
URI
that
refers
to
Bob's
profile,
where
Bob
is
an
imaginary
charcter
character
well
known
in
security
circles.
The
user
agent
will
create
Key
Chain
must
have
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
for
that
Certificate
at
this
URI.
For
example,
if
a
user
Bob
controls
https://bob.example/profile
,
then
his
WebID
can
be
https://bob.example/profile#me
When
creating
a
certificate
it
is
very
important
to
put
an
nice
choose
a
user
friendly
Common
Name
(CN)
for
the
user,
that
will
allow
him
to
distinguish
between
different
certificates
he
may
have,
such
as
a
personal
or
a
business
certificate.
certificate,
when
selecting
one
from
his
browser.
In
the
example
below
the
CN
is
Bob
(personal)
.
This
name
can
then
also
be
used
displayed
by
any
server
authenticating
the
user
to
immediately
find
as
a
way
to
address
the
user.
human
friendly
label.
The
WebID
URL
itself
should
not
usually
be
used
as
a
visible
identifier
for
human
users,
rather
it
should
be
thought
of
as
a
hyperlink
in
an
<a
href="https://...">
code,
especially
if
anchor.
That
is
the
resulting
resource
has
an
html
representation.
CN
should
be
a
label
and
the
WebID
a
pointer.
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, CN=Bob (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 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://bob.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
foaf+SSL
enabled
from
others.
Will
probably
need
some
very
deep
TLS
thinking
to
get
this
right.
The
above
certificate
is
no
longer
valid,
as
I
took
an
valid
certificate
and
change
the
time
and
WebID.
As
a
result
the
Signatiure
signature
is
now
false.
A
completely
valid
certificate
should
be
generated
to
avoid
nit-pickers
picking
nits
nits.
Many tools exist to create a Certificate. Some keychains allow a user to create the Certificate directly with a friendly User Interface. But using a keychain on the client still requires the public key to be published on the server as detailed in the next section. It is possible to combine the creation of the key with its publication in one step in such a way as to allow the server to make the decision of what the WebID should be, by using the HTML 5 keygen element. This element can be placed in an HTML5 form, where on submitting the form, the browser asks the Key Chain to create a public and private key pair, and on receiving the public part of that keypair the Client can sends a keyrequest as part of the form to the Service . The Service can then create a WebID Certificate and return it to the Client to pass onto the KeyChain . In that way the Server is in the position to best make the decisions of what the Certificate should say and what the WebID should be without the private key ever leaving the secure Key Chain . The user experience for this Certificate creation is a one click operation.
The
WebID
Profile
document
must
expose
the
relation
between
the
WebID
URI
and
the
Identification
Agent
's
public
key
s
using
the
cert
ontologies,
ontology
as
well
as
the
standard
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. For example Bob can publish a depiction or logo, so that sites he authenticates to can personalise the user experience. He can post links to people he knows, where those are have WebIDs published on other sites, in order to create a distributed Social Web. He can also publish relations to protected documents, where he keeps more information for people who authenticate, such as his friend Alois or his friends friends who may not yet know him personally, such as Alice.
The
protocol
does
not
depend
on
any
particular
serialisation
of
the
graph,
provided
that
agents
are
able
to
parse
that
serialisation
and
obtain
the
graph
automatically.
Technologies
such
as
GRDDL
[
GRDDL-PRIMER
]
for
example
permit
any
XML
format
to
be
transformed
automatically
to
a
graph
of
relations.
Yet
for
reasons
of
interoperabity
interoperability
is
has
been
decided
that
the
document
must
be
published
at
least
in
one
of
RDFa
[XHTML-RDFA]
or
RDF/XML
[RDF-SYNTAX-GRAMMAR].
HTTP
Content
Negotiation
[SWBP-VOCAB-PUB]
can
be
employed
to
aid
in
publication
and
discovery
of
multiple
distinct
serialisations
of
the
same
graph
at
the
same
URL.
Irrespective
of
whether
content
negotiation
can
or
not
be
employed,
if
an
HTML
representation
of
the
WebID
profile
is
published,
it
is
suggested
that
the
provider
uses
the
HTML
<link>
element
to
allow
discovery
of
the
various
alternate
representations
of
the
graph
which
may
be
available:
<html> <head> <link rel="alternate" type="application/rdf+xml" href="profile.rdf"/> <link rel="alternate" type="text/turtle" href="profile.ttl"/> ... </head> ...
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
by
hand
is
the
Turtle
notation.
It
is
easy
to
learn
to
use,
is
very
handy
for
commmunicating
communicating
over
e-mail
and
on
mailing
lists,
and
can
then
be
transformed
into
RDF/XML
automatically.
It
is
also
very
similar
to
the
SPARQL
query
language.
@prefix : <http://www.w3.org/ns/auth/cert#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix bob: <https://bob.example/profile#> . @prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . bob:me a foaf:Person; foaf:name "Bob"; foaf:knows <https://example.edu/p/Alois#MSc>; foaf:weblog <http://bob.example/blog>; :key [ a :RSAPublicKey; rdfs:label "made on 23 November 2011 on my laptop"; :modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary; :exponent 65537 ; ] .
There
are
many
ways
of
writing
out
the
above
graph
using
RDFa
in
html.
HTML.
Here
is
just
one
example
of
what
a
WebID
profile
could
look
like.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr" xmlns:cert="http://www.w3.org/ns/auth/cert#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:xsd="http://www.w3.org/2001/XMLSchema#"> <head> <title>Welcome to Bob's Home Page</title> </head> <body> <!-- WebID HTML snippet. The xmlns declarations above can be moved into the div below if needed--> <div about="#me" typeof="foaf:Person"> <span property="foaf:name">Bob</span> <h2>My Good Friends</h2> <ul> <li rel="foaf:knows" href="https://example.edu/p/Alois#MSc">Alois</li> </ul> <h2>My RSA Public Keys</h2> <div rel="cert:key"> <p>I made this key on the 23 November 2011 from my laptop.</p> <div typeof="cert:RSAPublicKey"> <dl> <dt>Modulus (hexadecimal)</dt> <dd style="word-wrap: break-word; white-space: pre-wrap;" property="cert:modulus" datatype="xsd:hexBinary">cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1</dd> <dt>Exponent (decimal)</dt> <dd property="cert:exponent" datatype="xsd:integer">65537</dd> </dl> </div> </div> </div> <!-- WebID HTML snippet --> </body> </html>
The
style="word-wrap:
break-word;
white-space:
pre-wrap;"
attributes
allow
the
number
to
be
displayed
on
more
than
one
line
so
that
it
will
wrapped
across
lines
and
not
just
continue
off
to
the
right
of
the
screen.
In order to make the above modulus easy to read for humans who may wish to compare it with the modulus in their browser, one can add some javascript. Add some javascript here that adds a : between every two characters, and that splits the line up in chunks.
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:
<html>
<head>
<link rel="alternate" type="application/rdf+xml" href="profile.rdf"/>
</head>
<body> ... </body>
</html>
<html> <head> <link rel="alternate" 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 notation or in relational databases. Parsers for it are also widely available.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:cert="http://www.w3.org/ns/auth/cert#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person rdf:about="https://bob.example/profile#me"> <foaf:name>Bob</foaf:name> <foaf:weblog rdf:resource="http://bob.example/blog"/> <cert:key> <cert:RSAPublicKey> <rdfs:label>made on 23 November 2011 on my laptop</rdfs:label> <cert:modulus rdf:datatype="http://www.w3.org/ns/auth/cert#hexBinary"> cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1 </cert:modulus> <cert:exponent rdf:datatype="http://www.w3.org/ns/auth/cert#integer">65537</cert:exponent> </cert:RSAPublicKey> </cert:key> </foaf:Person> </rdf:RDF>
TODO: the dsa ontology
What should the time to live be on a WebID document?
TODO: discuss other formats and GRDDL, XSPARQL options for xml formats
summarize and point to content negotiation documents
A WebID Certificate identifies the Subject alone and no one else, if and only if she is the only one to control the corresponding private key. It is very important therefore that the Subject take care of keeping the private key secure. This can be done by keeping it in the Key Chain of a personal machine in an account that is password protected and free of viruses, or best of all on some physical device where the private key is inaccessible to be read by any software. In the second case having the device implies that the private key has not been lost or copied. In the first case the user has to be more careful for signals of misuse.
In
either
situation
if
the
Subject
is
suspicious
that
his
private
key
has
been
taken,
then
he
can
disable
future
authentications
for
that
certificate
by
removing
the
corresponding
public
key
from
his
WebID
Profile
.
If
the
profile
contains
more
than
one
public
key
for
the
Subject
then
it
is
suggested
that
each
public
key
contain
a
label
to
help
the
user
locate
the
key.
In
the
examples
above
an
rdfs:label
with
a
creation
date
was
used
for
this
purpose.
In
order
to
give
the
full
context
of
a
Client
interaction
with
a
Server
we
will
illustrate
the
protocol
with
the
following
sequence
diagram.
Bob
initiates
a
connection
to
Alice
's
server
via
a
TLS
enabled
protocol
such
as
https
HTTPS
in
order
to
access
a
Protected
Resource
or
a
Protected
Service.
The
Protected
Resource
must
be
served
over
a
TLS-Light
Service
,
that
will
not
do
full
CA
authentication
of
Client
Certificate
s
it
receives.
The
Protected
Resource
may
be
a
document
served
over
https,
HTTPS,
but
it
could
also
be
a
SOAP
service,
or
some
other
resource.
This
resource
is
protected
by
a
Guard,
which
uses
a
WebID
Verifier
to
verify
the
non
Certified
WebIds
WebIDs
found
in
the
certificate.
Once
the
verification
succeeds
the
Guard
checks
to
see
if
the
Agent
identified
by
the
WebID
is
allowed
access
to
the
resource,
by
using
trusted
information
from
the
Web
and
access
control
rules.
The steps in detail are as follows:
Subject
Alternative
Name
extension
of
the
WebID
Certificate
.
A
WebID
Certificate
may
contain
multiple
URI
entries
which
are
considered
claimed
WebID
s
at
this
point,
since
they
have
not
been
verified.
The
Verification
Agent
may
verify
as
many
or
as
few
WebIDs
it
has
time
for.
It
may
do
it
in
parallel
and
asynchronously.
However
that
is
done,
a
claimed
WebIDs
can
only
be
considered
verified
if
the
following
steps
have
been
accomplished
successfully:
This section covers details about each step in the authentication process.
Standard SSLv3 and TLSv1 and upwards can be used to establish the connection between the Client and the TLS Agent listening on the Service's port.
Many servers allow a simple form of TLS client side authentication to be setup when configuring a TLS Agent : they permit the agent to be authenticated in WANT or NEED mode. If the client sends a certificate, then neither of these have an impact on the WebID Verification steps (4) and (5). Nevertheless, from a user interaction perspective both of these are problematic as they either force (NEED) or ask the user to authenticate himself even if the resource he wishes to interact with is public and requires no authentication. People don't usually feel comfortable authenticating to a web site on the basis of a certificate alone. They prefer human readable text, and detailed error messages which the HTTP layer deliver. It is better to move the authentication to the application layer Guard as it has a lot more information about the application state. Please see the WebID Wiki for implementation pointers in different programming languages and platforms to learn about how this can be done and to share your experience.
Once the TLS connection has been setup, the application layer protocol interaction can start. This could be an HTTP GET request on the protected resource for example.
If the protocol permits it, the Client can let the Application layer, and especially the Guard know that the client can authenticate with a WebID Certificate, and even if it wishes to do so. This may be useful both to allow the Server to know that it can request the client certificate, and also in order to make life easier for Robots that may find it a lot more convenient to be authenticated at the TLS layer.
Bergi proposed a header for HTTP which could do this. Please summarise it.
TLS
allows
the
server
to
request
a
Certificate
from
the
Client
using
the
CertificateRequest
message
[section
7.4.4]
of
TLS
v1.1
[
RFC5246
].
Since
WebID
TLS
authentication
does
not
rely
on
CA's
signing
the
certificate
to
verify
the
WebID
Claims
made
therein,
the
Server
does
not
need
to
restrict
the
certificate
it
receives
by
the
CA's
they
were
signed
by.
It
can
therefore
leave
the
certificate_authorities
field
blank
in
the
request.
From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.
A security issue with TLS renegotiation was discovered in 2009, and an IETF fix was proposed in [ RFC5746 ] which is widely implemented.
If the Client does not send a certificate, because either it does not have one or it does not wish to send one, other authentication procedures can be pursued at the application layer with protocols such as OpenID, OAuth, BrowserID, etc...
As
far
as
possible
it
is
important
for
the
server
to
request
the
client
certificate
in
WANT
mode,
not
in
NEED
mode.
If
the
request
is
made
in
NEED
mode
then
connections
will
be
broken
off
if
the
client
does
not
send
a
certificate.
This
will
break
the
connection
at
the
application
protocol
layer,
and
so
will
lead
to
a
very
bad
user
experience.
The
server
should
therfore
therefore
avoid
doing
this
unless
it
can
be
confident
that
the
client
has
a
certificate
-
which
it
may
be
because
the
client
advertised
that
in
some
other
way
to
the
server.
Is there some normative spec about what NEED and WANT refer to?
The Verification Agent is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme.
If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [ RFC3986 ]
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. [...] The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.
In order therefore to know the meaning of WebID containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier. This resource will describe the referent of the WebID in some way. If it says that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
The
trust
that
can
be
had
in
that
statement
is
therefore
the
trust
that
one
can
have
in
one's
having
received
the
correct
representation
of
the
document
that
defined
that
WebID.
An
https
HTTPS
WebID
will
therefore
be
a
lot
more
trustworthy
than
an
https
HTTP
WebID
by
a
factor
of
the
likelyhood
likelihood
of
man
in
the
middle
attacks.
Once
that
is
proven
then
the
trust
one
can
have
in
the
agent
at
the
end
of
the
TLS
connection
being
the
referent
of
the
WebID
is
related
to
the
trust
one
has
in
the
cryptography,
and
the
likelyhood
likelihood
that
the
private
key
could
have
been
stolen.
Add explanation for URI with redirect.
So
the
The
Verification
Agent
needs
to
fetch
the
document,
if
it
does
not
have
a
valid
one
in
cache.
The
Verification
Agent
must
be
able
to
process
documents
in
RDF/XML
[
RDF-SYNTAX-GRAMMAR
]
and
RDFa
in
XHTML
[
XHTML-RDFA
].
The
result
of
this
processing
should
be
a
graph
of
RDF
relations
that
is
queryable,
as
explained
in
the
next
section.
It
is
suggested
that
the
Verification
Agent
should
set
the
Accept-Header
to
request
application/rdf+xml
with
a
higher
priority
than
text/html
and
application/xhtml+xml
.
The
reason
is
that
it
is
quite
likely
that
many
sites
will
produce
non
marked
up
html
HTML
and
leave
the
graph
to
the
pure
rdf
formats.
If the Guard wishes to have the most up-to-date Profile document for an HTTPS URL, it can use the HTTP cache control headers to get the latest versions.
To
check
a
WebID
claim
one
has
to
find
if
the
graph
returned
by
the
profile
relates
the
WebID
to
the
Certificate
Public
Key
with
the
cert:key
relation.
In
other
words
one
has
to
check
if
those
statements
are
present
in
the
graph.
Testing for patterns in graphs is what the SPARQL query language is designed to do [ RDF-SPARQL-QUERY ]. We will first look at how to use this as it is also the simplest method, and then what some other programmatic options may be.
Below
is
the
SPARQL
Query
Template
which
should
be
used
for
an
RSA
public
key.
It
contains
three
variables
?webid
,
?mod
and
?exp
that
need
to
be
replaced
by
the
appropriate
values:
PREFIX : <http://www.w3.org/ns/auth/cert#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> ASK { ?webid :key [ :modulus ?mod; :exponent ?exp; ] . }
The variables to be replaced for each WebID claim are:
Variable | Details on its value. |
---|---|
?webid
|
should
be
replaced
by
the
WebID
Resource.
In
the
SPARQL
notation
that
is
the
URL
string
would
be
placed
between
<...>
in
the
position
of
the
?webid
variable.
|
?mod
|
should
be
replaced
by
the
modulus
written
as
a
xsd:hexBinary
as
specified
by
the
cert:modulus
relation.
All
leading
double
0
bytes
(written
"00"
in
hexadecimal)
should
be
removed.
The
resulting
"XXX"^^xsd:hexBinary
|
?exp
|
should be replaced by the public exponent written as an xsd:integer typed literal. In SPARQL as in Turtle notation this can just be written directly as an integer. |
Assuming
that
we
received
Bob's
key
whose
modulus
starts
with
cb24ed85d64d794b6...
and
whose
exponent
is
65537
then
the
following
query
should
be
used:
PREFIX : <http://www.w3.org/ns/auth/cert#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> ASK { <https://bob.example/profile#me> :key [ :modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary; :exponent 65537; ] . }
An
ASK
query
simply
returns
true
or
false.
If
it
returns
true,
then
the
key
was
found
in
the
graph
with
the
proper
relation
and
the
claim
has
been
is
verified.
In
order
to
allow
the
class
of
queries
defined
by
the
template
above
to
return
true
when
asked
of
graphs
where
the
hexBinary
or
the
exponent
contains
whitespace
characters
in
initial
and
final
position,
the
query
engine
must
support
the
D-entailment
regime
for
xsd:hexBinary
and
xsd:integer
as
specified
in
SPARQL
1.1
Entailment
Regimes
.
For verifiers that do not have access to a SPARQL query engine but can query the RDF data programmatically, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.
If
the
RDF
library
does
datatype
normalisation
of
all
literals
before
loading
them,
then
the
most
efficient
way
to
execute
this
would
be
to
start
by
searching
for
all
triples
whose
subjects
have
relation
cert:modulus
to
the
literal
which
in
our
example
was
"cb24ed..."^^xsd:hexBinary
.
One
would
then
iterate
through
all
the
subjects
of
the
relations
that
satisfied
that
condition,
which
would
most
likely
never
number
more
than
one,
and
from
there
filter
out
all
those
that
were
the
object
of
the
cert:modulus
relation
of
the
WebID
-
in
the
example
bob:me
.
Finally
one
would
verify
that
one
of
the
keys
that
had
satisfied
those
relations
also
had
the
cert:exponent
relation
to
the
number
which
in
the
example
above
is
"65537"^^xsd:integer
.
For
triples
stores
that
do
not
normalise
literals
on
loading
a
DSA
key.
We
graph,
the
normalization
will
need
to
add
an
ontology
for
DSA
too.
be
done
after
the
query
results
and
before
matching
those
with
the
values
from
the
Certificate
.
Because
one
could
not
rely
on
the
modulus
having
been
normalized,
one
would
have
to
start
with
the
WebID
-
bob:me
and
find
all
it's
cert:key
relations
to
objects
-
which
we
know
to
be
keys
-
and
then
iterate
through
each
of
those
keys'
modulus
and
exponent,
and
verify
if
the
normalised
version
of
the
value
of
those
relation
is
equal
to
the
numbers
found
in
the
certificate.
If
one
such
key
is
found
then
the
answer
is
true
,
otherwise
the
answer
will
be
false
.
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 .
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:
cert:identity was previously used to associate an RSAPublicKey with a WebID URI. cert:identity has been deprecated in favor of its inverse property cert:key. Implementors are encouraged to publish WebID Profile Documents using cert:key. During this transitional period, implementations consuming WebID Profile Documents might still support the deprecated cert:identity as well as the stable cert:key.
This section is non-normative.
2011-12-12 Fixed several errors in examples and diagrams, clarified TLS-Light, added SSL renegotiation, key chain and cache control, updated list people in acknowledgments.
2011-11-23 Wide ranging changes: Rewrote the Verification algorithm now enhanced with a detailed sequence diagram. Moved to new ontology using xsd:hexBinary datatypes and removed rsa: ontology. Rewrote vocabulary section using clearer names. All these changes required serious rewriting everywhere.
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: