We describe a simple protocol for RESTful authentication, using widely deployed technologies such as HTTP, SSL/TLS and Semantic Web vocabularies. This protocol can be used for one-click sign-on to web sites using existing browsers | requiring the user to enter neither an identi er nor a password. Upon this, distributed, open yet secure social networks and applications can be built. After summarizing each of these technologies and how they come together in FOAF+SSL,4 we describe declaratively the reasoning of a server in its authentication decision. Finally, we compare this protocol to others in the same space.
. e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T
Neither Shibboleth nor OpenID fully comply with web architecture principles (see Section 2.1 on REST), which in part explains their limitations.
This paper describes a novel approach that relies on combining the use of SSL client certi cates and Semantic-Web-based FOAF networks. The result is a secure, open and distributed authentication mechanism, which is able to satisfy simple requirements | such as authenticating a user by URI, like OpenID, but without the user needing to remember this URI | as well as more complex requirements, where the authorization to a service depends on distributed properties of the user, such as his position in a social network. This proposal is built on a RESTful architecture, the same that underpins the largest and most successful network of distributed linked information, the Web.
Section 2 introduces the background technologies of the Semantic Web and FOAF, as well as cryptography and client-certi cate authentication. Section 3 presents the FOAF+SSL protocol. Section 4 compares this approach to others. 2 2.1
The RESTful Web Architecture
Representational State Transfer (REST) [1, Chap. 5] is an architectural style for
building large-scale distributed information networks, the most famous of these
being the World Wide Web [
REST speci es the architectural style required to build such a protocol with the aim of maximum networkability; that is, any representation should be able to link to any resource from anywhere, using the URI alone to do so. 2.2
The Semantic Web Whereas URLs in the initial web of hyperlinked documents referred only to documents, the Semantic Web speci es how to extend this to enable a web of resources. In the Semantic Web, it becomes possible for URLs to refer to anything, be it: . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T 1. physical things | for example, <https://romeo.example/#i> may refer to a human named Romeo; 2. relations between two individuals | for example, the relation of knowing someone which <http://xmlns.com/foaf/0.1/knows> refers to; or 3. classes | for example, people may be described as being instances of <http://xmlns.com/foaf/0.1/Person>, the set of persons.
The meaning of these URLs can be found by dereferencing them using their canonical protocol. Thus, doing an HTTP GET on <http://xmlns.com/foaf/0.1/knows> should return a representation describing it. Since HTTP is built to allow content negotiation, well con gured web servers will return the representation best tting the client's needs. Entering the above URL in a web browser will return a human readable HTML page describing the `knows' relation. A Semantic Web agent could ask for the standard machine-friendly RDF representation.
A Semantic Web document is a serialization of a graph of directed relations between objects. Each relation exists as a triple of <subject> <relation> <object>, where each of subject, relation and object can be chosen among any of the URIs or string literals. Since it is tedious to read and write such URLs, this article uses the N36 @prefix notation. The following pre xes will be used throughout this article: @prefix log: <http://www.w3.org/2000/10/swap/log#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @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 rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix romeo: <https://romeo.example/#> . #see RFC2606 on .example domains @prefix jult: <https://juliet.example/#> . @prefix : <> . # special vocabulary defined for this paper
Thus, to say \Romeo is a person", one can write: romeo:i a foaf:Person.. Since each of the resources in that sentence is named by a URL, one can GET further information about each by dereferencing it, and if that representation itself contains relations do the same recursively. This is known as Linked Data7.
Each representation returned by a resource can be interpreted as a graph of relations, which can be isolated in N3 by placing them within curly brackets f g.8 The relation that maps a resource to the graph described by the document retrieved using the canonical dereferencing method of its URI is de ned as the :semantics relation. Thus, after dereferencing romeo:i, one may state the following, without asserting the actual statements within the brackets as true: (P1) romeo:i :semantics { romeo:i a foaf:Person; :hasPrivateKeyFor pubKey; foaf:name "Romeo"; foaf:knows jult:me . } 6 Current N3 tutorial at: http://www.w3.org/2000/10/swap/doc/Overview.html. 7 see Tim Berners-Lee's note http://www.w3.org/DesignIssues/LinkedData.html 8 Unlike the Named Graph brackets in SPARQL; N3 supports anonymous graphs. . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T
These graphs can also be used to formulate rules, as when we de ne the above :semantics relation in terms of the established log:semantics property, which relates a document to its graph, and :representation relating a resource to one of its representations (the ? pre xed variables are universally quanti ed): (D1) { ?resource :representation ?doc . ?doc log:semantics ?graph . } => { ?resource :semantics ?graph . }
The log: namespace9 tends to make signi cant use of enclosed graphs, or \formulas". In particular, the log:includes property links a subject graph to an object graph by asserting that the latter is a subset of the former graph; the log:implies property, also written as =>, can serve as the basis for reasoning based on rst-order logic (with the introduction of appropriate variables).
Even though the Semantic Web is built in order to make merging of information easy, it is not a requirement to do so. We will be using this notation to help illustrate clearly when merging graphs is reasonable. 2.3
FOAF, reputation networks and the Web of Trust FOAF,10 short for Friend-of-a-Friend, is an RDF vocabulary used to describe people, agents, groups and their relations. When used on the Semantic Web, this allows each person to describe himself and his network of friends.
By giving oneself a URI | aka. a Web ID |, one can describe one's personal social network by linking oneself to acquaintances by reference. Someone who has been given the romeo:i URL by Romeo himself, and then fetched its :semantics (ending up with the statements in P1) has good reason to trust that the information there is correct and, thus, to merge it (in a defeasible manner) with his own belief store. This graph itself will contain further URIs, such as jult:me, whose :semantics the agent can also GET. Similarly, the user can then add romeo:i to his FOAF le, to publish :me foaf:knows romeo:i.
Thus, a peer-to-peer information network can be built, where each person specializes in keeping up-to-date the information they feel responsible for, linking to the best sources for objects they do not wish to maintain. In return, as the quality of one's information and links increases, others feel more con dent linking to it, reducing their own work and responsibilities.
As the network grows, the value of the network grows exponentially, as
predicted by Metcalf's Law [
The plain foaf:knows relation may be enhanced with trust descriptions so
as to create a reputation network [
Public key cryptography Public key cryptography allows two peers to communicate securely without requiring them to share a secret, through the use of unique pairs of keys. One key, called the public key, may be disseminated widely, and the other, the private key, is to be kept only by its owner. This is in contrast to symmetric cryptography, where both participants must share the knowledge of the same secret key for both encryption and decryption.
Public key cryptography relies on the conjecture that it is infeasible to obtain any private key that corresponds to a given public key through brute force because this operation is too computationally expensive. It also assumes that no two distinct individuals will generate the same key-pair randomly. We can de ne in D2 an inverse functional property :hasPrivateKeyFor.
(D2) :hasPrivateKeyFor a owl:InverseFunctionalProperty; rdfs:domain foaf:Agent; rdfs:range cert:PublicKey .
Thanks to the dual-nature of the public and private key pair, two distinct actions are made possible: 1. Encryption is the obfuscation of a plain text message, generating a scrambled message using the public key of a key pair, so that it may only be decrypted using the corresponding private key. 2. Signing is the process of associating a digital signature with a message; this signature is generated using a private key. The authenticity and integrity of the message can then be veri ed using the corresponding public key.
A public key certi cate is the signed combination of a public key and some information related to this key. Such a certi cate may be self-signed (using the private key that matches the public key it contains) or signed by a third party. The party that signs a certi cate (self-signed or not) endorses its contents. Trusting the party that signed a certi cate can be a reason for believing its contents.
Two di erent architectures have been developed to make use of third party signing of public key certi cates: the hierarchical Public Key Infrastructure (Section 2.5) and the cryptographic Web of Trust (Section 2.6). In both architectures, an application or hosting environment is initially con gured with a trusted set of certi cates known as trust anchors. When presented with an unknown certi cate, an application veri es its authenticity by attempting to build a certi cation path | or chain | between the certi cate and one of the trust anchors. A certi cate becomes trusted if and only if it has been signed using a certi cate which is already trusted. If necessary, this operation may be repeated to build a path through intermediate certi cates, through which the trust relation is transitive.
The hierarchical Public Key Infrastructure model and the cryptographic Web of Trust model mainly di er in the way in which certi cates are distributed and intermediates are trusted. In both cases, the initial establishment of trust (i.e. the selection of trust anchors) requires an initial import of certi cates which is out of band, but this process is much less onerous than obtaining all public key certi cates for all entities likely to take part in secure communications. . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T 2.5
PKI and hierarchical model of trust
The Internet X.509 Public Key Infrastructure [
Most web-browsers and operating systems provide a default list of CA certi cates which they make their users trust implicitly. This list can usually be changed by the user, a feature often used by institutional PKIs. 2.6
Cryptographic Web of Trust The cryptographic Web of Trust (WoT) is a form of public key infrastructure (although rarely called PKI) where each participant may assert trust in any other participant, without a speci c hierarchy.
The Web of Trust model is used by PGP; what is often referred to as a PGP public key is, in fact, a form of a public key certi cate, since it also contains additional information (such as an e-mail address) and is signed so as to assert its authenticity. Such a certi cate is self-signed, but may also contain additional signatures | those by whom the association between the key and this additional information is trusted.
In PGP, the trust anchors are the user's own certi cate and the certi cates the user trusts, some of which may be from trusted introducers (that is, people through whom trust is transitive). The number a signatures a certi cate has re ects the connectivity to other parties. The more signatures a certi cate has, the more likely it is that a third party will be able to nd a certi cation path to that certi cate via trusted introducers. 2.7
SSL authentication
The most widely deployed protocol for securing communications between a
useragent and a web server is Transport Layer Security (TLS) [
During the SSL handshake, at the beginning of the SSL connection, the client obtains an X.509 certi cate from the server. At this point, the client relies on its trust anchors to verify it. If this certi cate is trusted and veri ed, the handshake proceeds. Once the handshake has nished, the communication (on 11 Unless explicitly noted, this article uses SSL to encompass TLS 1.x and SSL 3.0. top of SSL) can proceed in a secure manner; the only other party capable of reading the communication must have the private key corresponding to this server certi cate.
There exists a variant of the handshake procedure in which the client is requested or required to present a certi cate to the server, enabling the server to authenticate the client using the same veri cation method as above.
The remainder of this section describes, from a Semantic Web point of view, how trust in a certi cate is evaluated. This forms the basis for comparison of how FOAF+SSL di ers from this, in Section 3.2. We describes the reasoning of a server, S, for authenticating a client, :client, making a request. Server S has a set of trusted CAs. S would state that issuerDN was a trusted CA with: (P2) issuerDN a :TrustedCA;
:hasPrivateKeyFor CAKey .
The CAKey is a cert:PublicKey that is usually identi ed by a number of inverse functional properties, which form an OWL2 key.12 For the sake of brevity, these relations are not shown here. Su ce it to say that CA Keys can be uniquely identi ed by them.
S requests that :client presents a certi cate signed by any one of a number of CAs it knows about. S receives :certDoc with semantics such as the following (the subject is also identi ed via a DN): _:certDoc :semantics _:certSemantics . _:certSemantics = { <> dc:created issuerDN;
foaf:primaryTopic subjectDN . subjectDN :hasPrivateKeyFor pubKey .
issuerDN :hasPrivateKeyFor CAKey . } (P3) (P5) So far, the SSL handshake ensured S that the client has the private key: (P4)
:client :hasPrivateKeyFor pubKey .
The client asserts the contents of the certi cate (not shown) and that it is signed by issuer: . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T :client :claims { _:certDoc :signature _:certSig; _:certSig :signedWith CAKey; :sigString "XYZ SIG" . }
S can assert, after veri cation, that :certDoc has been signed using the private key corresponding to CAKey: (P6) _:certDoc :signature [ :signedWith CAKey ] .
Proving that a document is signed by P , is to assert P claims its contents: (D3) { ?P :hasPrivateKeyFor ?key .
?doc :signature [ :signedWith ?key ] } => { ?P :claims [ is :semantics of ?doc ] } .
12 http://www.w3.org/TR/owl2-syntax/#Keys . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T
Then, from the signature veri cation P6, the certi cate contents P3 and the de nition D3, S can assert: (P7)
issuer :claims _:certSemantics .
To trust someone is to trust what they claim. S trusts TrustedCAs, thus: (D4) { ?ca :claims ?s . ?ca a :TrustedCA } => { ?s a log:Truth } . From P2, P7 and D4, S can conclude: (P8)
subjectDN :hasPrivateKeyFor pubKey .
From P4 gained by the SSL handshake, the above P8 and the de nition D2 of :hasPrivateKeyGot as a owl:inverseFunctionalProperty, we can deduce: (P9)
:client owl:sameAs subjectDN .
At this point, the server S has authenticated the :client as this Distinguished Name (DN). Considering that the :client's request is to access resource R, the server can then nd out if this DN is authorized access to R.
The problem with DNs is that, although they can be made to form a URI, the dereferencing mechanism for DNs is not global in the way http URLs are. Therefore, if access to R is granted in some rule based way, where more information about R needs to be discovered for a decision to be made, then the DN cannot provide a global solution. For very much the same reasons, data in LDAP servers cannot have elds that point resources in any other LDAP server. As a result, current uses of client certi cates limit the usage of each to a few domains.
The ability to link globally is an essential piece required for building a global social network. The next sections shows how FOAF+SSL solves this problem. 3
This section describes the FOAF+SSL protocol. The FOAF+SSL protocol uses SSL but uses a di erent trust model than PKI to verify certi cates.13
When protecting a service, it is important to di erentiate authentication from authorization. Authentication is the action of verifying the identity of the remote user. Authorization consists of allowing or denying access to or operations on a given resource, based on the identity obtained during authentication.
FOAF+SSL enables a server to authenticate a client given a simple URL. This URL can then be used directly for authorization, or to explore more information in the web of linked data, in order to decide if the referent of the URL satis es the constraints required for accessing the resource. 13 Although the examples we use are based on the Web, FOAF+SSL could in principle also be used for authentication to other SSL-enabled services, such as IMAPS. . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T 3.1
Protocol sequence RomUesoerhAygpeenrdtata
The FOAF+SSL authentication protocol consists of the following steps, as illustrated in Figure 1: 1. A client fetches a public HTTP resource which points to a protected resource, for example <https://juliet.example/location>. 2. The client, romeo:i, dereferences this URL. 3. During the SSL handshake, the server requests a client certi cate. Because FOAF+SSL does not rely on CAs, it can ask for any certi cate. The client sends Romeo's certi cate (which may be self-signed) containing its public key (see \Subject Public Key Info" in Listing 1.1) and a Subject Alternative Name URI (see \X509v3 extensions" in Listing 1.1). Because the SSL handshake has been successful, Juliet's server knows that Romeo's client has the private key corresponding to the public key of the certi cate. Listing 1.1. Excerpt of a text representation of a FOAF+SSL certi cate.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit)
Modulus (1024 bit): 00:b6:bd:6c:e1:a5:ef:51:aa:a6:97:52:c6:af:2e: 71:94:8a:b6:da:9e:5a:5f:08:6d:ba:75:48:d8:b8: [...]
Exponent: 65537 (0x10001) X509v3 extensions:
X509v3 Subject Alternative Name:
URI:https://romeo.example/#i . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T 4. Juliet's server dereferences the Subject Alternative Name URI found in the certi cate and ends up with a superset of D1. 5. The document's log:semantics is queried for information regarding the public key contained in the X.509 certi cate. This can be done in part with a SPARQL query as shown in Listing 1.2. If the public key of the certi cate matches the one published in the FOAF le, romeo:i is authenticated.
Listing 1.2. SPARQL query to obtain the public key information. SELECT ?modulus ?exp WHERE { ?key cert:identity <https://romeo.example/#i>; a rsa:RSAPublicKey; rsa:modulus [ cert:hex ?modulus; ]; rsa:public_exponent [ cert:decimal ?exp ] . } 6. Once this authentication step is complete, the position of romoe:i in Juliet's social graph can be determined. Juliet's server can get this information by crawling the web starting from her FOAF le, or by other means. 7. Authentication has been done; authorization can now take place. 3.2
Authentication Logic This section draws a parallel with Section 2.7, again, following the reasoning of the web server S trying to authenticate a :client.
At the end of stage 3 in the FOAF+SSL sequence diagram, S has received the client certi cate securely. Being self-signed (or signed by an unknown party), its semantics are somewhat di erent. S is really only interested in the URI identi ers referring to the subject | abandoning thus the limitations of DNs. In addition, since it is asserted by the client, S knows that:14 (P10) :client :claims { <> dc:created romeo:i;
foaf:primaryTopic romeo:i.
romeo:i :hasPrivateKeyFor pubKey . } S may know of romeo:i only what it gathered from the SSL handshake: (P11) :client :hasPrivateKeyFor pubKey .
When someone makes a claim, they have to agree with the logical consequences of their claim, including those arising from new facts. Thus, someone who makes a claim :mustAgree with the conclusions of the union of what we know securely, what they believe, and established reasoning rules: (D5) { ?client :claims ?clientGraph . ( ?clientGrph secureFactGraph owlReasoningRules ) log:conjunction [ log:conclusion ?C ] }
=> { ?client :mustAgree ?C } 14 The signer being the author, following the reasoning from P10, P6, D3 would also end up with this result | for self signed certi cates only. . e s n e c i L s n o m m o C e v i t a e r C " d e t r o p n U 0 . 3 n o i t u b i r t t A \ e h t r e d n u e l b a l i a v a s i e l c i t r a s i h T
Hence, from P10, P11, and D2, S may conclude that :client would have to agree that it is romeo:i. This should not be a surprise, as that is indeed what one assumes someone who sends such a certi cate intends.
(P12) :client :mustAgree [ log:includes { romeo:i = :client } ] .
Since :client asserts it is romeo:i, it accepts to be inspected via romeo:i. Since romeo:i is a URL, S can dereference it and thus discover P1. Then, by P1, P11, D2, and D5: (P13) romeo:i :mustAgree [ log:includes { romeo:i = :client } ] .
In other words, both romeo:i and :client must agree, given what S knows, that romeo:i owl:sameAs :client. In particular romeo:i cannot repudiate this assertion since romeo:i itself provided P1 authoritatively. It follows that if S is authorized to serve R to romeo:i, S can serve R to :client. 3.3
Following links In the previous section, we showed how a server can authenticate a client who claims a Web ID. Authorization policies | how to decide which group of agents may access which resource | will be particular to each application. It could be done by giving a list of authorized Web IDs. It could be done by trusting statements returned by a selected group of Web IDs, for example, when allowing all friends of a given friend access to a resource, as speci ed by the representation returned by their Web ID. This would make the initial list of trusted Web IDs similar to the trust anchors in PKI and WoT. A lot still remains to be explored.
A topic for further research is to de ne the various ways in which trust can be transmitted. Let us look at one simple example here. Imagine a user connects to a service and is authenticated as joe:i, using the FOAF+SSL method described above. Imagine joe:i returns a representation claiming joe:i owl:sameAs romeo:i. Since anyone could make that statement, that, in itself, should not be the basis for belief for services that care about security. If, on the other hand, romeo:i :semantics [ log:includes f romeo:i owl:sameAs joe:i . g ], then this could be used as con rmation of the claim, and from there on both IDs could be used interchangeably by S. 4
Unlike the OpenPGP extension to TLS [
OpenID also shares considerable similarities with FOAF+SSL, due in part to OpenID's reliance on URLs as identi ers, just as FOAF+SSL relies on dereferenceable URIs bearing FOAF data. However, OpenID fails to make much use of the information at the OpenID resource, using it only to nd the authorization service. As a result, OpenID requires a much higher number of connections to establish identity | 6 as opposed to 2 | and parts ways with RESTful design in the attribute exchange protocol, loosing thereby the advantages of a networked architecture. 5
FOAF+SSL provides a secure and exible global authentication system. With public key cryptography at its core, it gains all the security advantages of this technology. Because FOAF+SSL is RESTful and integrates well with the Semantic Web, it can discover more information about an entity by walking the Linked Data cloud. Compared with PKI, FOAF+SSL removes the need for hierarchical authorities to assert identity, making it much more exible. Thus, this mechanism adapts itself well to the formation and expansion of virtual organisations and distributed social networks.
Ian Jacobi acknowledges funding for this project from NSF Cybertrust award #0524481 and IARPA award #FA8750-07-2-0031. Bruno Harbulot acknowledges EPSRC funding under grant EP/E001947/1 (http://www.nanocmos.ac.uk/).