WebID-TLS
Specification Link is provided https://www.w3.org/2005/Incubator/webid/spec/tls/
WebID-TLS (Web Identity over Transport Layer Security) is a protocol that enables secure authentication and authorization using WebID technology over the Transport Layer Security (TLS) protocol. It is an extension of the WebID protocol that adds support for TLS-based authentication.
WebID-TLS is designed to allow users to authenticate themselves to a website or service using their WebID and digital certificate, which are authenticated over a secure TLS connection. The website or service can then verify the user's identity and grant them access based on their WebID and the information associated with it.
WebID-TLS is often used in combination with other technologies, such as the Simple Authentication and Security Layer (SASL), to provide a secure and decentralized authentication mechanism for web applications and services. It is also commonly used in combination with the Resource Description Framework (RDF) and the Web Ontology Language (OWL) to represent and manage user identity and associated data in a semantic way.
In summary;
The must have a with a Subject Alternative Name URI entry. This URI must be one that dereferences to a whose graph contains a cert:key relation from the WebID to the public key published in the . (see below )
For example, if a user Bob controls https://bob.example/profile, then his can be https://bob.example/profile#me
When creating a certificate it is very important to choose a user friendly 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, when selecting one from his browser. In the example below the CN is Bob (personal). This name can then also be displayed by any server authenticating the user as a human friendly label. The URL itself 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://..."> anchor. That is the CN should be a label and the a pointer.
The document must be a ] document. It must also expose the relation between the URI and the 's s using the [cert ontology](http://www.w3.org/ns/auth/cert#dfn-webid_profile "WebID_Profile"]] as well as the standard xsd datatypes.
Vocabulary
RDF graphs are built using vocabularies defined by URIs, that can be placed in subject, predicate or object position. The definition of each URI should be found at the namespace of the URI. Here we detail the core cryptographic terms needed. The optional foaf vocabulary used to describe agents can be found at the the foaf namespace vocabulary document.
Below is a short summary of the vocabulary elements to be used when conveying the relation between the and his or her key, within a document. For more details please consult the cert ontology document.
Used to associate a URI with any PublicKey. A must contain at least one PublicKey that is associated with the corresponding URI.
Refers to the class of RSA Public Keys. A RSAPublicKey must specify both a cert:modulus and a cert:exponent property. As the cert:modulus and cert:exponent relations both have as domain a cert:RSAPublicKey, the type of the key can be inferred by the use of those relations and need not be written out explicitly.
Used to relate an RSAPublic key to its modulus expressed as a hexBinary. An RSA key must have one and only one modulus. The datatype of a modulus is xsd:hexBinary. The string representation of the hex:Binary must not contain any whitespaces in between the hex numbers.
Used to relate an RSAPublic key to its exponent expressed as a decimal integer. An RSA key must have one and only one exponent. The datatype of a modulus is xsd:integer.