RDF-based decentralized identity protocol.

The WebID-TLS protocol enables secure, efficient and maximally user friendly authentication on the Web. It enables people to authenticate onto any site by simply choosing one of the certificates proposed to them by their browser. These certificates can be created by any Web Site for their users. This specification extends the WebID Identity [WEBID] specification which defines many of the core concepts used in WebID-TLS, such as the identifier, known as the WebID, as well as the associated Profile Document.

WebIDs can be used to build a Web of trust using vocabularies such as [FOAF] by allowing people to link together their profiles in a public or protected manner. Such a web of trust can then be used by a Service to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that he/she is known by some relevant people, works at a given company, is a family member, is part of some group, …

WebID Profile Document#

You’re identified by your WebID Profile Document. The primary purpose of the profile document is to map a URI to public keys using the cert ontology.


@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<#me> a foaf:Person;
  foaf:name "Bob";
  foaf:knows <https://example.edu/p/Alois#MSc>;
  foaf:img <http://bob.example/picture.jpg>;
  cert:key [ a cert:RSAPublicKey;
    rdfs:label "made on 23 November 2011 on my laptop";
    cert:modulus "LONG HASH STRING"^^xsd:hexBinary;
    cert:exponent 65537 ;
   ] .

Certificate Generation#

The protocol works by using a profile document to generate a TLS certificate.

  • A user initiates certificate generation by creating a new public/private keypair

  • the server then issues a certificate that indicates that it belongs to a particular Profile Document

The certificate issuing server is intended to also be the same one that hosts the profile document, so it might then add the public key to the document that was used to generate the certificate.


The certificate is used to authenticate you when connecting to other servers.

  • The other server requests that you provide a certificate, this seems to be imagined as a browser popup prompting you to select from any certificate that has been previously generated by your or other servers.

  • The client then proves that it has the private key that is paired with the public key, which is also listed in the profile document.

  • The other server verifies the certificate by dereferencing the profile URL to the profile document and comparing the public key to the one in the profile with SPARQL.


Write comparison and summary re: beacons and other ID verification systems