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.

How to Read this Document

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.

Preconditions

Terminology

Alice

Alice is an agent who owns a Server which runs a Service which Bob wishes to Access

Subject

The Subject is the Agent that is identified by the WebID. When used correctly it is the Subject who wishes to authenticate to a Service. When speaking of a particular agent, and in order to improve lisibility in this spec, we will name him Bob. The Subject is distinct from the Client which is used to connect to the Server.

Bob

Bob is an agent who uses a Client to connect to Alice's Service, and who controls the private key the client uses to access the resource.

Client

The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server.

Server

A Server is a machine contactable at a domain name or ip address that hosts a number of globally accessible Services.

Service

A Service is a an agent listening for requests at a given ip address on a given Server

Guard

A guard is an agent, usually on the Server that can look at a request from the Client and decide if it needs Authentication by looking at the Access control Rules. If it needs Authentication it can request it, and it can use the WebId Verifier to complete identity checks. Finally it can grant or deny access.

Verification Agent or WebId Verifier

Performs authentication on provided WebID credentials.

WebID Certificate

An X.509 [[!X509V3]] Certificate that MUST contain a Subject Alternative Name extension with at least one URI entry identifying the Subject. This URI MUST 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 http://bob.example/profile#me would contain the following:

X509v3 extensions:
   ...
   X509v3 Subject Alternative Name:
      URI:http://bob.example/profile#me

Such a URI is known as a WebID.

WebID

A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent as the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document.

Public Key

A cryptographic key that can be published and can be used to verify the possession of a private key. A public key is always included in a WebID Certificate.

WebID Profile or Profile Page

A structured document asserting the relationship between the Subject (identified by his WebID) and his Public Keys using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID. Dereferencing the WebID should return the Profile Document in one of a number of formats. The Server MUST publish the document in at least the XHTML+RDFa 1.1 [[!XHTML-RDFA]] serialization format or in RDF/XML [[!RDF-SYNTAX-GRAMMAR]]. The document may be published in a number of other RDF serialization formats, such as N3 [[!N3]] or Turtle [[!TURTLE]]. Any serialisation MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].

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.

Namespaces

Examples assume the following namespace prefix bindings unless otherwise stated:

Prefix	IRI
cert	http://www.w3.org/ns/auth/cert#
rsa	http://www.w3.org/ns/auth/rsa#
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.

Creating the certificate

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 http://bob.example/profile, then his WebID can be http://bob.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
            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.

discuss the importance for UIs of the CN

The above certificate is no longer valid, as I took an valid certificate and change the time and WebID. As a result the Signatiure is now false. A completely valid certificate should be generated to avoid nit-pickers picking nits

Publishing the WebID Profile Document

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 theortically immaterial to the protocol, so long as a well known mapping from the format of the representation to such a graph can be found automatically. In order to improve interoperability at this time it is suggested that WebID provider publish the graph of relations at least in one of RDFa [[!XHTML-RDFA]] or RDF/XML [[!RDF-SYNTAX-GRAMMAR]], though he may publish it in a number of formats to increase the usability of his site to different agents using content negotiations [[!SWBP-VOCAB-PUB]].

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.

Turtle

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://bob.example/profile#> .

 :me a foaf:Person;
   foaf:name "Joe";
   cert:key [
     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 ;
     ] .

RDFa HTML notation

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:xsd="http://www.w3.org/2001/XMLSchema#"
      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>

<div>
  <span property="foaf:name">Joe</span>

  <div rel="cert:key">
    <h2>My RSA Public Key</h2>
    <div typeof="rsa:RSAPublicKey">
      <dl>
      <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="xsd:int">65537</dd>
      </dl>
    </div>
  </div>
</div>
</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 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 type="rel" type="application/rdf+xml" href="profile.rdf"/>
</head>
<body> ...  </body>
</html>

In RDF/XML

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:rsa="http://www.w3.org/ns/auth/rsa#"
 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>Joe</foaf:name>
    <cert:key>
      <rsa:RSAPublicKey>
        <rsa:modulus rdf:datatype="http://www.w3.org/ns/auth/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
        </rsa-modulus>
        <rsa:public_exponent rdf:datatype="xsd:int">65537</rsa:public_exponent>
      </rsa:RSAPublicKey>
    </cert:key>
  </foaf:Person>

</rdf:RDF>

TODO: the dsa ontology

In Portable Contacts format using GRDDL

TODO: discuss other formats and GRDDL, XSPARQL options for xml formats

summarize and point to content negotiation documents

The WebID Protocol

Authentication Sequence

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:

Bob's Client MUST open a TLS [[!RFC5246]] connection with the server which authenticates itself using well known TLS mechanisms. This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]]. Once the TLS session is established, which means that the Server was authenticated by the client, then it is possible for the application layer protocol to get started.
If the protocol is HTTP then the client can request an HTTP GET, PUT, POST or DELETE action on a resource for example. The Guard can then intercept that request and by checking some access control rules determine if the client needs authentication. We will consider the case here where the client does need to be authenticated.
The Guard MUST requests the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarised by the following steps:
1. The guard requests of the TLS agent that it make a Certificate Request to the client. The TLS layer does this. Because the WebID protocol does not rely on Certificate Authorities to verify the contents of the Certificate, the TLS Agent can ask for any Certificate from the Client. More details in Requesting the Client Certificate
2. The Client asks Bob to choose a certificate if the choice has not been automated. We will assume that Bob does choose a WebID Certificate and sends it to the client.
3. The TLS Agent MUST verify that the client is indeed in posession of the private key. What is important here is that the TLS Agent need not know the Issuer of the Certificate, or need not have any trust relation with the Issuer. Indeed if the TLS Layer could verify the signature of the Isser and trusted the statements it signed, then step 4 and 5 would not be needed - other than perhaps as a double check to verify that the key was still valid.
4. The WebID Certificate is then passed on to the Guard with the proviso that the WebIDs still needs to be verified.
The Guard then MUST ask the Verfication Agent to verify that the WebIDs do identify the agent who knows the given public key.
The WebID is verified by looking up the definition of the URL at its canonical location. This can be done by dereferencing it. The Verification Agent MUST extract the public key and all the URI entries contained in the 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:

If the WebID Verifier does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme. For an https://... WebID this would be done using the [[!HTTP-TLS]] protocol.
The returned representation is then transformed into an RDF graph as specified in Processing the WebID Profile
That graph is then queried as explained in Querying the Graph. If the query succeeds, then that WebID is verified.

With the set of verified WebIds the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the WebID is indeed allowed access to the protected resource. The exact nature of those Access Control Rules is left for another specification. Suffice it to say that it can be something as simple as a lookup in a table.
If access is granted, then the guard can pass on the request to the protected resource, which can then interact unimpeded with the client.

Authentication Sequence Details

This section covers details about each step in the authentication process.

Initiating a TLS Connection

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.

Connecting at the Application Layer

Once the TLS connection has started the application layer protocol can get going. It is always possible during communication at the application layer for communication parameters to be set at the TLS layer, such as requesting a client certificate as described in the following section. This permits some very flexible authentiation interaction, as the Guard can find out exactly what the abilities of the client are in order to work out what type of TLS client authentication it can ask for.

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 allow Robots that may find it a lot more convenient to be authenticated automatically.

Requesting the Client Certificate

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. Most programming languages permit this option to be set.

From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.

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 from OpenID, OAuth, BrowserID, etc... as these occur at the Application Layer, which has not yet been accessed.

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. Unless the server can be confident that the client has a certificate - which it may be because it advertised that in some other way to the server - then it should try to avoid making the request in NEED mode. In most browsers this leads to a very bad user experience. Luckily only few browsers require Need mode for the client to send a certificate.

Is there some normative spec about what NEED and WANT refer to?

Processing the WebID Profile

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.

Verifying the WebID is identified by that public key

There are number of different ways to check that the public key given in the X.509 certificate against the one provided by the WebID Profile or another trusted source, the essence is checking that the graph of relations in the Profile contains a pattern of relations.

Assuming the public key is an RSA key, and that its modulus is "9D79BFE2498..." and exponent "65537" then the following SPARQL query could be used:

PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
ASK {
   <http://example.org/webid#public> cert:key [
      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 sparql endpoint (or the underlying triple store to be able to do inferencing on dataytypes. This is because the numerical values may be expressed with different xsd and cert datatypes which must all be supported by VerificationAgents. The cert datatypes allow the numerical expression to be spread over a number of lines, or contain arbitrary 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 the SPARQL endpoint doesn't provide a literal inferencing engine, then the modulus should be extracted from the graph, normalised into a big integer (integers without an upper bound), and compared with the values given in the public key certificate. After replacing the ?webid variable in the following query with the required value the Verifying Agent can query the Profile Graph with

PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
SELECT ?m ?e
WHERE {
   ?webid cert:key [
        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?

Authorization

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.

Secure Communication

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

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:

foaf: http://xmlns.com/foaf/0.1/
cert: http://www.w3.org/ns/auth/cert#
rsa: http://www.w3.org/ns/auth/rsa#

Personal Information

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:

foaf:mbox: The e-mail address that is associated with the WebID URI.
foaf:name: The name that is most commonly used to refer to the individual or agent.
foaf:depiction: An image representation of the individual or agent.

Cryptographic Details

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:

rsa:RSAPublicKey: Expresses an RSA public key. The RSAPublicKey MUST specify the rsa:modulus and rsa:public_exponent properties.
cert:key: Used to associate a WebID URI with an RSAPublicKey. A WebID Profile MUST contain at least one RSAPublicKey that is associated with the corresponding WebID URI.

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.