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 following URI: http://github.com/msporny/webid-specThis 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. WebID is compatible with OpenID and 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 a URI entry. The URI
identifies the Identification Agent. The URI should be
dereference-able and result in a document containing RDF data. For example,
the certificate would contain http://example.org/webid#public
,
known as a WebID URI, as the 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 keys
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 and Identification Agents 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.
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 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 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 checking that the graph of relations in the Profile contain a pattern of relations.
Assuming the public key is an RSA key, and that its modulus is "9D79BFE2498..." and exponent "65537" then the 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 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 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 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.
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 Agents 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 Agents and Identification Agents 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: