Evaluation of Authentication and Authorisation with Linked Data Support for CV3.0



The CV3.0-project [1] needs authentication- and authorisation-methods in the context of linked data. This article summarizes the research conducted to find such methods for the project as well as the technologies and approches found.

Introduction and Overview

As part of the research conducted in the CV3.0-project, the goals of two of the project's workpackages consisted of:

  • Authenticating access to a triplestore using WebID
  • Authorising access to data within the triplestore with triple-level granularity

During the work on those two workpackages, the aspects authentication and authorisation have been thoroughly researched in the context of linked data. This article gives a summary about the findings as well as the approach, which has been choosen for the CV3.0-project.

Authentication (Access Control)


As technology for authentication, WebID is mandated by the project proposal for CV3.0.

WebID [2] is an open standard for identity and login developed by the WebID community group [3] at W3C. Authentication with WebID is performed using a TLS client certificate and a correlation of it to a WebID-profile exposed as RDF on the web. The basic steps are as follows:

  1. A certificate is requested from the client. It is not required that the certificate is checked against an authority.
  2. A WebID-profile specified in the certificate is dereferenced.
  3. The public key of the certificate is compared to the dereferenced profile.
  4. If the comparison is successful, the client is authenticated.

The URI leading to the profile is given in the certificate using the Subject Alternative Name entry specified by X.509 [4]. The WebID specifications [5] give a more detailed overview of principles and the full protocol.

Emerging directly from the semantic web environment, WebID seems to be the ideal choice for the objectives of the proof-of-concept implementations done in the CV3.0-project. At the time, when the project started, no generic WebID-identityproviders (IDPs) could have been identified which could have been easily set up in our organisation in order to provide WebIDs for employees and students. Thus, such an IDP has been implemented as a first deliverable, more information can be found at the IDP homepage [6].

Other Authentication-Mechanisms

Besides WebID, other authentication systems have been examined initially to get a broader picture of the authentication landscape. Specifically, we did look at

  • OpenID / OpenID Connect and OAuth
  • BrowserID / Persona
  • Webfinger, XRD and JRD
  • Web Identity and Secure Messaging

These are not specifically linked data authentication mechanisms or even don't support linked data, however we will give nevertheless a short overview of these in the following sections.

OpenID / OpenID Connect and OAuth

Other protocols available to the identity and access management domain on the web include OpenID and OAuth.

OpenID [7] has been around since 2005 and uses URIs (like WebID) as credential. The user logs in by specifying it's URI, then, depending on the OpenID-version, different mechanisms are used for discovering the identity provider which is called an OpenID-provider. Depending on the mode, a user can then be asked for a login at the provider. Attributes are exchanged using a "properties-file"-style format. OpenID has a broad adoption, according to Wikipedia [8], there are over one billion of OpenID-enabled accounts.

Work on OAuth [9] began in 2006, it is a protocol for authorisation using tokens issued for a short period, based on HTTP. A user of a service A can authorize a service B to access (parts) of it's data at service A by defining access for service B at service A. OAuth 1.0 is specified in RFC 5849 [10]. With quite some controversy [11], OAuth development has continued and in 2012, OAuth 2.0 has been published in RFC 6749 [12].

OpenID Connect builds on OAuth 2.0 and uses JSON as exchange format. The work on the standard has been completed [13] in february 2014. OpenID foundation board member Nat Sakimura gives a good overview of the protocol in this article [14]

Following a comparison [15] of WebID and OpenID, both standards should be interoperable, as the basic principle, basing on URIs for dereferencing a personal profile, is the same. There are however some differences in the way that the protocols interact with users and services which are detailed in the given comparison.

WebFinger, XRD and JRD

WebFinger [16] is not an authentication protocol on its own but an information retrieval mechanism used by other protocols, namely OpenID Connect. Introduced [17] in 2009, WebFinger is based on HTTPS and an associated well-known URI [18]. Resources found at a given WebFinger-URI are represented in a Web Host Metadata [19] format, either serialised as XRD (XML) or JRD (JSON, however not JSON-LD).

Web Host Meta format doesn't seem to be directly compatible to RDF according to a discussion [20] on W3C's public RDF working group mailinglist.

BrowserID / Persona

Mozilla's Persona [21] is the leading implementation of the BrowserID-concept which relies on verified email-addresses to control access to webresources. The protocol is detailed in BrowserID specification [22], it's basic steps are:

  1. A resource requesting authentication calls a JavaScript-function in the browser
  2. The user gets a dialog requesting it's email-address
  3. If the browser already has a corresponding certificate, login is performed using provisioning and authentication endpoints provided by the resource
  4. Otherwise, the user gets redirected to a login to confirm his identity

There have been some [23] discussions [24] comparing WebID and BrowserID. Generally, nothing seems to speak against at least some interoperability between the two, however, there are some distinctions to be made:

  • WebID uses the native UI for certificate management, BrowserID brings its own scripted in JavaScript. This offers more possibilities, however also increases the risks, namely for phishing.
  • BrowserID works only for browsers, whereas WebID is basically applicable to every agent which supports TLS.
  • Both support multiple clients for one identity. Key revocation seems to be a bit easier with WebID, BrowserID chooses short validities for protection.
  • Both are decentralised, however for BrowserID, only Mozilla's Persona seems to be the identity provider broadly used.

Although some large sites have adopted BrowserID for login, widespread usage could not have been determined so far. Mozilla has recently analysed [25] why the project failed to gain wide adoption, more details are also given in a Google-groups posting [26].

Web Identity and Secure Messaging

An interest group [27] concerned of exchanging money over the web is building standards for authentication and identity in an associated W3C community group [28]. At the time of writing, two draft community standards have emerged from this group, secure messaging [29] and web identity [30].

The secure messaging standard focuses on maintenance of a public key infrastructure by having key registration services (comparable to keyservers) and on secure and verifiable message exchange using these keys.

On the other side, the web identity standard addresses exchange of public and private identity attributes using JSON-LD over HTTP. For protecting private data, authentication is performed using HTTP-signatures [31], an IETF draft standard.

Some implementations are available: secure messaging has been implemented by Digitital Bazaar as part of their webpayments-library payswarm [32], HTTP-signatures in Joyent's node-http-signature [33].


Authorisation takes place after successful authentication and allows or denies access to specific resources or parts of resources according to specifications given. Various models of authorisation have evolved over time which won't be further discussed in this article; instead, we will have look at authorisation in the area of semantic web / linked data only.

In the linked data environment, authorisation can occur on different levels: starting at the server/triplestore itself (broadest), on the level of resources/graphs or at individual triples (narrowest). Some exponents of the semantic web community prefer to speak of filtering rather than of authorisation if it occurs on a level deeper than resources.

We did an extensive search for authorisation ontologies and methods according to our needs and found differerent approaches, more or less evolved and suitable for the CV3.0-project. Out of these approaches, Universal Access Control has been choosen; its properties will be described in the next section.

This summary ends after that with an overview of the other approaches found and a short description of each of them.

Triple Access Control (TAC) and Universal Access Control (UAC)

Universal Access Control (UAC), developed by Thomas Bergwinkl [34], is the successor of Triple Access Control by the same author. It consists of a vocabulary [35] as well as an implementation of the various parts in JavaScript. A good overview is given by this presentation [36].

Direct exchange with the author has been beneficiary for both projects and we have become involved in the publication of the UAC-implementation which is currently in preparation. A link will be provided here as soon as the publication has happened.

Other Approaches Found

Web Access Control (WAC)

Web Access Control (WAC) [37] is one of the first approaches in providing authorisation based on WebIDs. It's working principle are access control lists (ACLs) which map WebIDs to HTTP-resources and define possible access types like read and write. As the mapping to HTTP-resources implies, granularity of the ACLs is only given on resource-level, thus WAC is not capable of fulfilling the needs stated in the CV3.0-project (triple-level authorisation granularity).


In the paper WebID+ACO: A distributed identification mechanism for social web [38], the authors propose an ontology [39] for authorisation which addresses the various HTTP-methods in a role-based model. The granularity of the approach could not have been determined by the informations given in the paper and the ontology, however the focus on a webserver and URIs for pages lead to the conclusion that the intended granularity is also at resource-level. The authors also refer to WAC and discuss their extensions to it.


S4AC [40] is a vocabulary for creating access control policies focusing on named graphs. S4AC is used by the SHI3LD-project for specifying authorisations. With its focus on named graphs, it is also not a suitable solution for the CV3.0-project.


Like S4AC, SHI3LD [41] has also been developed at INRIA [42]. The project builds a context-aware authorization layer for graph-stores, taking into account context of the requesting agent (location etc.) and granting access based on this context. As it is based on S4AC for authorisation, it is also bound to the level of named graphs and thus was also not taken into consideration for the CV3.0-project.

Privacy Preference Ontology

The privacy preference ontology [43] developed by the DERI [44] insitute in Ireland looks like a promising candidate for the needs of the CV3.0-project. It provides authorisation at all different granularities down to the triple level and there also exists a prototypal implementation. The choice for TAC/UAC over this approach was mainly made due to the good contacts with the developer of the former as well as implementations beeing available in JavaScript, the language also used in CV3.0.

Authorisation in Triplestores

During the research for authorisation technologies, we have also analysed if some existing triplestores offer the required functionality. This list [45] gives a good overview of authorisation at a triple level in different triplestores, dating September 2012.

Taking two examples: The commercial Stardog triplestore for instance gives a detailed summary [46] of its security features; Oracle has similar documentation[47] as well.


  1. CV3.0 project homepage, http://cv3.bfh.ch
  2. WebID homepage, http://webid.info/
  3. WebID community group, http://w3.org/community/webid/
  4. RFC 5280 (X.509), Subject Alternative Name, https://tools.ietf.org/html/rfc5280#section-
  5. WebID specifications, https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
  6. BUAS WebIDP, http://webidp.bfh.ch
  7. OpenID homepage and specifications, http://openid.net
  8. Wikipedia - OpenID adoption, https://en.wikipedia.org/wiki/Openid#Adoption
  9. OAuth homepage, http://oauth.net
  10. RFC 5849 - OAuth 1.0, http://tools.ietf.org/html/rfc5849
  11. Wikipedia - OAuth 2.0 controversy, https://en.wikipedia.org/wiki/OAuth#Controversy
  12. RFC 6749 - OAuth 2.0, http://tools.ietf.org/html/rfc6749
  13. Release of OpenID Connect, http://openid.net/2014/02/25/a-great-day-for-internet-identity
  14. Nat Sakimura - OpenID Connect in a nutshell, http://nat.sakimura.org/2012/01/20/openid-connect-nutshell
  15. Henry Story - WebID in relation to other technologies, http://bblfish.net/tmp/2010/08/05/webid-related.respec.html
  16. RFC 7033 - WebFinger, http://tools.ietf.org/html/rfc7033
  17. Eran Hammer - Introducing WebFinger, http://hueniverse.com/2009/08/introducing-webfinger
  18. RFC 5785 - .well-known-URIs, http://www.faqs.org/rfcs/rfc5785.html
  19. RFC 6415 - Web Host Metadata, https://tools.ietf.org/html/rfc6415
  20. W3C public RDF working group mailinglist - JRD discussion, http://lists.w3.org/Archives/Public/public-rdf-wg/2013Feb/0038.html
  21. Mozilla Persona homepage, http://developer.mozilla.org/en-US/Persona
  22. BrowserID specification, http://github.com/mozilla/id-specs/blob/prod/browserid/index.md
  23. Stackoverflow comparing WebID and BrowserID, https://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
  24. Stackoverflow comparing various federated identities, https://security.stackexchange.com/questions/5323/what-are-the-downsides-of-browserid-persona-compared-to-openid-oauth-facebook/5390#5390
  25. Identity/Persona AAR, http://wiki.mozilla.org/index.php?title=Identity/Persona_AAR&oldid=919193
  26. Google Groups - Dan Callahan on Persona's future, https://groups.google.com/forum/#!msg/mozilla.dev.identity/Qnxt8lmOEeo/fVtJrMDfOjMJ
  27. Web Payments homepage, https://web-payments.org
  28. W3C Web Payments community group, http://www.w3.org/community/webpayments
  29. Secure Messaging - draft community group specification, https://web-payments.org/specs/source/secure-messaging
  30. Web Identity - draft community group specification, https://web-payments.org/specs/source/web-identity
  31. IETF HTTP Signatures - draft Cavage, http://tools.ietf.org/html/draft-cavage-http-signatures-00
  32. Digital Bazaar - payswarm.jsl library, https://github.com/digitalbazaar/payswarm.js
  33. Joyent - HTTP Signature, https://github.com/joyent/node-http-signature
  34. Homepage of Thomas Bergwinkl, https://www.bergnet.org
  35. UAC Ontology, http://ns.bergnet.org/uac/0.1/index.html
  36. Presentation about UAC, https://www.bergnet.org/people/bergi/files/documents/2014-02-14/index.html
  37. Web Access Control, http://www.w3.org/wiki/WebAccessControl
  38. WebID+ACO: A distributed identification mechanism for social web, http://ii.uwb.edu.pl/~dtomaszuk/WebIDACO.pdf
  39. ACO Ontology, http://ii.uwb.edu.pl/~dtomaszuk/access/
  40. S4AC Ontology, http://ns.inria.fr/s4ac/v2/s4ac_v2.html
  41. SHI3LD Homepage, https://wimmics.inria.fr/projects/shi3ld/
  42. INRIA Homepage, http://www.inria.fr
  43. Privacy Preference Ontology Paper, http://ceur-ws.org/Vol-781/paper6.pdf
  44. DERI Institute Homepage, http://deri.ie
  45. An Overview of RDF Triplestores, http://www.garshol.priv.no/blog/231.html
  46. Stardog Triplestore, Security Overview, http://docs.stardog.com/security/
  47. Oracle, Finegrained Access Control, http://docs.oracle.com/cd/E11882_01/appdev.112/e25609/fine_grained_acc.htm