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 to protect resources and enable his 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 and TLS.
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 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 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 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 well known in security circles.
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 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 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.
In the example below the CN is Bob (personal)
.
This name can then also be used by any server authenticating the user to immediately find a way to address the user.
The WebID 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 the resulting resource has an html representation.
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 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 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 keys using the cert
ontologies, 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 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 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>; :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. 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>
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: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> <cert:key> <cert:RSAPublicKey> <rdfs:label>made on 23 November 2011 on my laptop<rdfs:label> <cert:modulus rdf:datatype="xsd:hexBinary"> cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1 </cert:modulus> <cert:exponent rdf:datatype="xsd:integer">65537</cert:exponent> </cert:RSAPublicKey> </cert:key> </foaf:Person> </rdf:RDF>
TODO: the dsa ontology
TODO: discuss other formats and GRDDL, XSPARQL options for xml formats
summarize and point to content negotiation documents
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 in order to access a Protected Resource or a Protected Service. The Protected Resource may be a document served over 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 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 WebIDs 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 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 WebID will therefore be a lot more trustworthy than an https WebID by a factor of the likelyhood 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 that the private key could have been stolen.
Add explanation for URI with redirect.
So the Verification Agent needs to fetch the document, if it does not have a valid one in cache. 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 and leave the graph to the pure rdf formats.
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 hexadecmial should then be placed in the space of the XXX in "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 verified.
The public key could be a DSA key. We need to add an ontology for DSA too.
The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the WebID Profile in order to personalise a site.
Once the Guard has a WebID he can do a lookup in a database to see if the agent is allowed the required access to the given resource. Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor. But the interesting thing about such a WebID is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another. It is therfore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains. It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace. There are too many possibilities to list them all here.
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.
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:
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-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: