Warning:
This wiki has been archived and is now read-only.

Media and Identity

From Web and Broadcasting Business Group
Jump to: navigation, search

Identity Technologies on the Web: A Primer

Purpose of This Document

The goal of this document is to provide a succinct summary of various identity-related technologies developed in and around W3C that increase the capabilities of Media applications on the Web, and how they apply more specifically in a broadcasting-industry context.

Target Audience

This note is aimed at those who are unfamiliar with current identity technologies on the Web. Specifically, this note has been authored with broadcasters, ad agencies, non-web developers and end-users in mind. We hope that after reading this note readers will have a better understanding of identity technologies and that they will be better prepared to consider business and/or service models using these technologies with broadcasting.

Identity Technologies

OpenID

OpenID
  • Characteristics
    • OpenID is an open standard for authentication.
    • OpenID is a decentralized Single Sign On system for the Web.
    • OpenID is a URI, e.g. http://yosukef.myopenid.com/
  • Basic Information
    • SDO: OpenID Foundation [site]
    • Creation Date: Summer, 2005
    • Adoption: Over one billion OpenID-enabled user accounts and over 50,000 websites accepting OpenID for logins [page]
    • License: Non-exclusive, royalty free, worldwide copyright license [pdf]
    • Specs: OpenID Authentication 2.0
  • Primary Functions
    • Authentication
      • SSO
      • Ownable and movable identity
    • Profile management
      • Simplified registration process on each OpenID-enabled web site.
  • Important Actors
    • End-user
    • OpenID Provider (OP)
      • OP stores and authenticates End-user's credentials and profiles, and is responsible for securing them and providing them to other web services.
    • Relying Party (RP)
      • RP is any web service that relies on OP(s) for End-user authentication.
  • Primary Scenarios
    • End-user creates his or her OpenID at an OP's web site.
    • RP maintains a list of OPs that the RP relies on.
    • OP authenticates End-user with OpenID. RP doesn't.
    • End-user can login to any RP web site using his or her OpenID with the help of an OP.
    • End-user can't login to RP web sites if the RPs don't rely on the OP that the End-user has designated.
    • End-user can change OP and maintain his or her OpenID if they provided a URI at the time they created the OpenID.
    • End-user can simplify common profile information and store it centrally.
  • Note
    • Anybody can become an OP without the need for permission or a license from any party.
  • Further Reading

WebID

WebID
  • Characteristics
    • WebID is an open standard for authentication.
    • WebID is a Hash URI, e.g. http://www.w3.org/People/Berners-Lee/card#i that points to a person's WebID Profile document, a type of web page that must be available in Turtle format, but may also be available in other RDF serialisation formats from the same URLs.
      • A Hash URI contains a fragment, a special part that is separated from the rest of the URI by a hash symbol (“#”).
    • The WebID protocol is an authentication protocol on the Web. It enables people to authenticate onto WebID-enabled sites by selecting one of the certificates installed in their keychain through a web browser. CAs and anybody using X.509 tools can create these certificates.
  • Basic Information
  • Primary Functions
    • Authentication
      • SSO
      • Ownable and movable identity
      • Independently issued X.509 certificates as credentials
      • Non-hierarchical approach and web of trust
    • Profile management
      • Fully integrated profiles
      • FOAF ontology
  • Important Actors
    • Alice
      • Alice is an agent who owns a Server which runs a service which Bob wishes to access
    • Bob
      • Bob is an agent who uses a Client to connect to Alice's service
    • Client
      • 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.
    • Server
      • 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.
    • WebID Profile Service
      • A web service that creates, stores and publishes WebID Profile documents.
    • WebID Certificate Issuer
      • An entity that issues X.509 certificates specified in the WebID standard such as CAs and engineers who use X.509 tools.
  • Primary Scenarios
    • Create a WebID Profile document at a WebID Profile Service
      • 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.
    • Create a certificate bound to the WebID or WebID Profile document
      • 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.
    • Sign on a WebID-enabled site with the WebID
      • 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.
  • Note:
    • Authorization by FOAF and WebID
      • 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 (CA)
      • 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.
  • Further Reading

Related Technologies

OAuth 1.0

OAuth 1.0
  • Characteristics
    • OAuth 1.0 is an open standard for authorization to access web service APIs.
    • OAuth 1.0 is a protocol that enables clients to access server resources on behalf of a resource owner (such as a different client or an end-user).
      • 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.
  • Basic Information
  • Primary Functions
    • Authorization for web service APIs
  • Caution about Terminology
    • In the OAuth 1.0 specification, the definition and terminology used for user, client and server is unique. So beware.
  • Important Actors
    • Resource Owner (RO)
      • An entity capable of accessing and controlling protected resources by using credentials to authenticate with the server.
    • Client
      • 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.
    • Server
      • An HTTP server capable of accepting OAuth-1.0-authenticated requests.
  • Primary Scenarios
    • RO has an account on a Server. RO uploads private data to the Server.
    • RO accesses a Client to use a service they provide for processing the private data on the Server.
    • RO requests the Client to execute the process.
    • The Client asks the Server for their availability using temporary credentials they've agreed to in advance. If the Server is available, the user-terminal shows the login page of the Server using HTTP redirect mechanism.
    • RO logs in to the Server and tells the Server to allow the Client to access the private data.
    • The user-terminal redirects back to the Client and this tells the Client that now it has right to access the private data.
    • The Client starts to execute the process, including retrieving the private data from the Server.
  • Note
    • Pseudo-authentication by OAuth 1.0
      • 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.
    • Currently, some people are saying, "OAuth 1.0 Revision A (1.0a) is better than OAuth 1.0 because of a security enhancement." This is misleading because no specification document named "OAuth Core 1.0a" exists, therefore please don't waste your time looking for it.
    • The use of OAuth 1.0 with any transport protocol other than HTTP is not defined in RFC 5849.
    • OAuth 1.0 is not compatible with OAuth 2.0.
  • Further Reading

OAuth 2.0

OAuth 2.0
  • Characteristics
    • OAuth 2.0 is an open standard for authorization to access web service APIs.
    • OAuth 2.0 is a framework that enables creating authorization protocols through customization and extension.
    • Protocols based on OAuth 2.0 enable clients to access resources on a Resource Server on behalf of a Resource Owner (such as a different client or an end-user) through Authorization Servers.
      • 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.
    • OAuth 2.0, as a framework, covers native applications such as desktop applications and mobile device applications, but still needs each implementor to define the details.
  • Basic Information
  • Primary Functions
    • Authorisation for web service APIs
  • Important Actors
    • Resource Owner (RO)
      • 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.
    • Resource Server (RS)
      • The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
    • Client
      • 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).
    • Authorization Server (AS)
      • The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
  • Primary Scenarios
    • RO has an account on a RS. RO uploads private data to the RS.
    • RO accesses a Client to use a service they provide for processing the private data on the RS.
    • RO requests the Client to execute the process.
    • The Client asks an AS for RS's availability using a client id and password. If the RS is available, the Client starts executing the process, including retrieving the private data from the Server.
      • 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.
  • Note
    • The major differences between 1.0 and 2.0
      • 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.
    • Pseudo-authentication by OAuth 2.0
      • OAuth 2.0 is capable of similar pseudo-authentication by OAuth 1.0.
    • OAuth 2.0 is not backward compatible with OAuth 1.0
  • Further Reading

Web Cryptography API

  • Characteristics
    • Web Cryptography API is a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, encryption and decryption, and for generating and/or managing the keying material necessary to perform these operations.
    • Using the Web Cryptography API you can implement secure device and user authentication functions similar to what already exists in VOD services on the Web.
      • 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.
  • Basic Information
  • Primary Functions
    • See Primary Scenarios
  • Important Actors
    • See Primary Scenarios
  • Primary Scenarios
  • Note
    • N/A
  • Further Reading
    • W3C/Web Cryptography WG [site]

Encrypted Media Extensions (EME)

  • Characteristics
    • EME is an open standard for authorization to play protected content such as audio and video.
    • EME is a vendor-neutral extension for HTML5 which extends HTMLMediaElement by adding APIs that control playback of protected content.
    • EME defines APIs that enable web browsers to control key exchanges between Content Decryption Modules in devices and corresponding License Servers on the Web.
      • 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.
  • Basic Information
  • Primary Functions
    • See Primary Scenarios
  • Important Actors
    • See Primary Scenarios
  • Primary Scenarios
  • Note
    • EME triggered W3C's decision that support for "protected content" is "in-scope" for HTML.
  • Further Reading

FOAF

  • Characteristics
    • FOAF (Friend of a friend) is an open standard for the ontology used in people's profiles.
    • Each FOAF profile has a unique identifier (such as a personal e-mail address, a Jabber ID, an OpenID, a WebID, or a URI of a personal homepage/weblog), which is used when defining relationships between profiles.
    • FOAF allows the profiles of people to describe social networks without the need for a centralised database.
    • FOAF profiles are in file formats such as RDF/XML (see the example below) and Turtle or embeddable formats such as Microdata and RDFa. 
<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>
  • Basic Information
  • Primary Functions
    • N/A
  • Important Actors
    • N/A
  • Primary Scenarios
    • N/A
  • Note
    • FOAF is an application of Semantic Web technologies, so many Semantic Web tools and techniques are available to search for and locate information about individuals without requiring a centralised database.
    • Authorization by FOAF + identity technologies
      • 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..
Retrieved from "https://www.w3.org/community/webandbroadcasting/wiki/index.php?title=Media_and_Identity&oldid=759"