Identity Technologies on the Web: A Primer

• SSO
• Ownable and movable identity

• Simplified registration process on each OpenID-enabled web site.

• OP stores and authenticates End-user's credentials and profiles, and is responsible for securing them and providing them to other web services.

• RP is any web service that relies on OP(s) for End-user authentication.

• A Hash URI contains a fragment, a special part that is separated from the rest of the URI by a hash symbol (“#”).

• SSO
• Ownable and movable identity
• Independently issued X.509 certificates as credentials
• Non-hierarchical approach and web of trust

• Fully integrated profiles
• FOAF ontology

• Alice is an agent who owns a Server which runs a service which Bob wishes to access

• Bob is an agent who uses a Client to connect to Alice's service

• The Client initiates a request to a service listening on a specific port using a given protocol on a given Server. It can request authentication credentials from a keychain to send to a server
• In the scenarios below, "Client" means a web browser.

• A Server is a machine contactable at a domain name or IP address that hosts a number of globally accessible services.
• In the scenarios below, "Server" means a web server.

• A web service that creates, stores and publishes WebID Profile documents.

• An entity that issues X.509 certificates specified in the WebID standard such as CAs and engineers who use X.509 tools.

• Bob accesses a WebID Profile Service and enters private information he wants to publicly share, then he defines his hash fragment included in the WebID URL.
• The WebID Profile Service creates and stores Bob's profile document containing his private information. The URL of the profile document is his WebID and is now published and publicly accessible.

• Bob provides his WebID to a WebID Certificate Issuer.
• WebID certificates are based on public key encryption technology and are in X.509 format. Certificates contain public key information and keychains in the end-user's environments store private keys.
• Incidentally, Bob could issue his own certificate if he had the skills and tools to create a certificate.
• The WebID Certificate Issuer returns a certificate tied to his WebID which is then stored in the keychain of Bob's Client.
• Bob provides the WebID Profile Service with the public key in the certificate. The WebID Profile Service publishes the public key as a part of his WebID document.

• Bob accesses Alice's Server that provides web services and requires authentication. The Server is WebID-enabled.
• Bob selects the WebID sign-on option in a pop-up window shown by the Client.
• Bob's Client shows a list of certificates in its keychain.
• Bob selects a certificate bound to his WebID and the Client sends the certificate and a token signed by his private key to the Server.
• The Server verifies Bob's identity in two steps:
• Step 1: Verify that Bob owns the certificate
• Receive the certificate and token
• Verify that the token was signed by the private key paired to the public key in the certificate
• Step 2: Verify this same Bob also owns the WebID Profile document
• Retrieve the profile document from the WebID or a Hash URI contained in the certificate
• Extract a public key (a modulus and public exponent) from the profile document
• Verify that the public key is identical to those in the certificate
• If verification succeeds, the Server allows the Client to access its services.

• As described in FOAF section below, the combination of FOAF and WebID forms a decentralised authorization service. WebID is therefore superior to other identity technologies in this way because WebID employs user profile documents as its essential building block and the vocabulary of this building block is FOAF.

• Certificate authority, or certification authority, (CA) is an entity that issues digital certificates such as those used by HTTPS to secure transactions and to guarantee identity of servers and in some cases clients.

• OAuth 1.0 provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.

• An entity capable of accessing and controlling protected resources by using credentials to authenticate with the server.

• A front-end user terminal and back-end web server capable of making OAuth-1.0-authenticated requests form a team to become an OAuth 1.0 Client.

• An HTTP server capable of accepting OAuth-1.0-authenticated requests.

• OAuth 1.0 was designed to provide a feature that OpenID lacked, a feature which enables end-users to authorise a web service provider to use their data stored on other web service providers' servers. However, once OAuth 1.0 was created, web service providers who implemented OAuth 1.0 realized that sharing end-user's data among web service providers is *the* key feature which allows web service providers to collaboratively offer better service to end-users. They soon realised that SSO was unnecessary to achieve that goal.
• OAuth 1.0 provides a unique kind of authentication called "pseudo-authentication." "An end-user allows a web service provider to access something private"-- this scenario, if the whole system is secure, allows for sufficient authentication of the end-user by the web service provider. Ultimately, it is the shared body of data of an end-user that is their identity, and what service providers need to know is not who end-user is in the real world but who owns the data to be processed, who allows them to access the data and who will pay for the services.

• OAuth 2.0 provides a process for end-users to grant third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
• OAuth 2.0 includes an SSO feature as a way of granting access to restricted resources in other web applications.

• An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

• The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

• An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

• The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

• If this is the first time, the Client accesses an AS bound to the RS to get a client ID and set a password for later use. The registration process requires the Client to prove that it is acting on behalf of the RO. Two examples of this are through either outsourcing the task to the RS using URI redirections or the Client actually logging into the RS by obtaining from the RO his or her credentials to the RS.

• 2.0 is a framework that can be extended and customized while 1.0 is a complete specification that defines almost all aspects of the protocol enabling developers to create interoperable implementations. 2.0 provides developers with better flexibility to create their systems by combining OAuth and other technologies, but it also means the definition of OAuth is blurred in 2.0.
• 2.0 adopted TLS as its sole security layer while 1.0 defined its own secure protocol without help from other securing layers, including TLS. This transition has benefits and risks for developers and service providers using OAuth. For example, 2.0 doesn't require developers to implement the full protocol stacks specified by 1.0 but requires careful security considerations because 2.0 can create security holes. These holes are chiefly due to the nature of the framework lacking full consideration of security upon standardization and the inevitable combination of 2.0's broad extensibility and outsourced security protocol.

• OAuth 2.0 is capable of similar pseudo-authentication by OAuth 1.0.

• The benefit or risk of using the Web Cryptography API is that web browsers can have full control over secure transactions, while existing VOD services use proprietary solutions or lower layer standards such as TLS which prohibits web browsers from accessing or controlling the transactions.

• For more on the extensibility of HTML 5, see http://www.w3.org/TR/html5/infrastructure.html#extensibility

• EME is a building block to implement UIs for proprietary DRM systems.
• DRM systems can be implemented on top of web browsers using EME and open source encryption technologies, if that could be called a DRM system.

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:admin="http://webns.net/mvcb/">
  <foaf:PersonalProfileDocument rdf:about="">
    <foaf:maker rdf:resource="#me"/>
    <foaf:primaryTopic rdf:resource="#me"/>
    <admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foaf-a-matic"/>
    <admin:errorReportsTo rdf:resource="mailto:leigh@ldodds.com"/>
  </foaf:PersonalProfileDocument>
  <foaf:Person rdf:ID="me">
    <foaf:name>Yosuke Funahashi</foaf:name>
    <foaf:title>Mr</foaf:title>
    <foaf:givenname>Yosuke</foaf:givenname>
    <foaf:family_name>Funahashi</foaf:family_name>
    <foaf:mbox rdf:resource="mailto:yfuna@tomo-digi.co.jp"/>
    <foaf:workplaceHomepage rdf:resource="http://www.tomo-digi.co.jp/"/>
    <foaf:knows>
      <foaf:Person>
	<foaf:name>Timothy Berners-Lee</foaf:name>
      <foaf:mbox rdf:resource="mailto:timbl@w3.org"/></foaf:Person>
    </foaf:knows>
  </foaf:Person>
</rdf:RDF>

• Identity technologies such as OpenID and WebID can be used to build a Web of trust using FOAF ontology 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, etc..