Identity Interoperability

From WebID Wiki

"We can all be friends, whatever our Principals are" - anonymous fish

TimBL's diagram at TPAC2012
TimBL's diagram at TPAC2012

Over the years many different authentication systems have been developed. Each one proposes a method for an agent to prove his relation to an identifier - called a Principal. A Principal is a string that can be mapped to a URI, that usually refers to some network resource, which itself can then be linked to a subject. An LDP authorization system may authenticate agents that are allowed access to a resource using different types of Principals. This page lists a number of ways Authorization agents can prove identity of an agent using one Principal, with an ACL that may be using a different type of Principal. The aim is to gather such examples together in order to find an general theory that underpins these proofs.


Problem statement

Definition of Principal

[[ need to integrate discussion on webid mailing list ]]

Principals are different types of strings that directly or indirectly identify an Agent. They can be put in simple logical relationships. The following Turtle graph shows how in one graph one can relate 4 types of principals: 

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<http://logic.edu/webids/jz#i> a foaf:Agent;
    foaf:mbox <mailto:jz@logic.edu>;
    foaf:openid <http://logic.edu/webids/jz>;
    cert:key [ a cert:RSAPublicKey;
             cert:modulus "cb24ed85d64d794b69c701c186acc059501e856...."^^xsd:hexBinary;
             cert:exponent 65537 ] .

Each of these Principals can be used to authenticate the same individual (with different degrees of confidence), without needing to know the above graph.

A Principal is typed, so that each type of Principal comes with two functions:

  1. a function from that string identifier to a resource which that string identifier has as referent - usually a network resource
  2. a function that maps that identifier to the subject, i.e., the agent that is identified by the Principal - known in WebDAV as the represented by relation

So an OpenID Principal is a string with the following two functions:

  1. the function Ref from the OpenID Principal string to a home page (identified by a URI)
  2. the function OpenidSubj from the home page to the agent being authenticated, known also as the function from foaf:openid objects to subjects

such that OpenIdSubj(Ref(principal)) refers to the subject.

To take a precise example, a Principal "http://logic.edu/webids/jz" has a 

Ref("http://logic.edu/webids/jz") = <http://logic.edu/webids/jz>

which is a home page, and which is in the following relation to some _:agent 

_:agent foaf:openid <http://logic.edu/webids/jz> .

Hence OpenidSubj(Ref("http://logic.edu/webids/jz")) refers to the agent being authenticated (for which the authentication agent may have no other name!). It refers to the physical agent in the world. That subject may have any number of direct names, such as <http://logic.edu/webids/jz#i> in our example above.

Use cases in Access Control

Controlling Access to resources is a process that requires the following steps:

  1. Determining if the action on the resource has any restrictions (out of politeness one does not ask for identity if it is public)
  2. Authentication: Requesting the User's identity - his Principal - and a proof that he is the Subject of that Principal.
  3. Authorisation: verifying that the user is one of those authorised to access the resource for the given action.

In a distributed Web Access Control system information about which agents are allowed access may be spread across the web. For example the Access Control Document associate with a resource <meetingMinutes> may limit read/write access to some group of agents <http://remote.co/team#us>. Using the WebAccessControl ontology this could be written as: 

[] acl:accessTo <meetingMinutes>; 
   acl:mode acl:Read; acl:Write;  
   acl:agentClass <http://remote.co/team#us> .

This document may not be as uniformly consistent as the TPAC 2012 RWW attendees which is a foaf:Group where all members have a WebID. Rather it could well look more like this: 

 
<#us> a foaf:Group;
     foaf:member [ foaf:name "Jack";
                     foaf:openid <http://jack.name/blog> ],
                  [ foaf:name "Jane";
                    foaf:mbox <mailto:jy@yaioo.example> ],
                  <http://bblfish.net/people/henry/card#me> .

Here we have a group consisting of members that have provided very different identifying descriptions for themselves. So this can give rise to the following issue: if someone authenticates with a Principal different from the one listed in the group, how can the access control system go about proving the subject identity of an agent given a principal mismatch?

Direct Verification mechanisms for different types of Principals

Here we list the protocols that have carefully specified verification mechanisms for different types of Principals.

E-mail Principal

E-mail Principals can be verified in a number of ways:

  • simple e-mail verification mechanism (e.g., sending the user an e-mail and getting him to click on a link)
  • BrowserID/Mozilla Persona

If one knows that a user (at the end of a connection) is identified by a particular e-mail address, then an authentication agent knows that that user is the _:agent such that 

_:agent foaf:mbox <mailto:jz@logic.edu> .

Since foaf:mbox is inverse functional relation, any two proofs of an e-mail Principal will identify the same agent.

OpenID Principal

An OpenID 1.0 is a URL that denotes a Web Page, which the user controls. Following the OpenID authentication mechanism an Authentication Agent can prove that the _:agent at the end of the connection is in the following relation to that OpenID 

_:agent  foaf:openid  <http://logic.edu/webids/jz>  .

Since foaf:openid is inverse functional, any two proofs of an OpenID relation will identify the same agent.

Public Key Principal

Any user connecting to a Web Site with an X.509 certificate proves at that point at least that he is in control of the private key that matches that public key. That is he proves something like: 

_:agent  cert:key [ a cert:RSAPublicKey;
             cert:modulus "cb24ed85d64d794b69c701c186acc059501e856...."^^xsd:hexBinary;
             cert:exponent 65537 ]  .

The BrowserID/Mozilla Persona control flow proves the same type of thing - though the public key changes very often, so the e-mail identifier becomes important in recognizing the user over a longer period of time. For longer lasting certificates, one needs an extra verification mechanism to prove that the private key was not lost or stolen in the meantime - and thus that it still identifies the same agent over time.

WebID Principal

A WebID Principal is a URL that directly denotes an agent. A user can prove this in a number of ways:

1. By using the WebID Authentication Protocol to prove from a Public Key Principal that the WebID Principal is in the following relation 

_:agent cert:key    [ a              cert:RSAPublicKey;
                      cert:modulus   "cb24ed85d64d794b69c701c186acc059501e856...."^^xsd:hexBinary;
                      cert:exponent  65537  ]  .
_:agent owl:sameAs  <http://logic.edu/webids/jz#i> .

Indirect Verification mechanisms

Here we list indirect verification mechanisms that can be used to go from one Principal to another without asking the user to authenticate again (using a different direct verification mechanism, of course).

These may not be complete or totally fleshed out yet, so beware.

From WebID to ...

... email Principal

If one has proved a WebID for a user and wishes to then prove an e-mail Principal, the following would be a method

If the WebID Profile publishes a user's e-mail address, e.g.: 

 
 <http://logic.edu/webids/jz#i> 
     a          foaf:Agent            ;
     foaf:mbox  <mailto:jz@logic.edu>  .

Then one could use WebFinger to find a document about the user, and if that links back to the WebID in the right way, one can prove the above statement, and so identify a user with a mailbox Principal. What would the link be, how would it work? (semantically of course)

... OpenId Principal

If the WebID Profile page is the OpenID Web Page, and the WebID states that -- 

 <#i>  foaf:openid  <>  .

-- then by knowing the WebID one also has proven the OpenID.

If the WebID profile page is different than the OpenID web page, then there must be a link in both directions. That is, the WebID Profile needs to state that -- 

  <#i> foaf:openid <http://user.org/blog>

-- and the OpenId Profile page has to state the same thing. What is the best way to do this?

From an OpenID Principal to ...

... a WebID Principal

... an e-mail Principal

Other reasoning procedures

owl:sameAs

How one can verify different identities that are in an owl:sameAs relation.

Say an ACL allows access to some agent identified as <http://agent.com/r2d2#me>, but a request is received from an agent with a verified WebID Principal "http://betteroil.org/rdew#i". The ACL can be satisfied if the ProfileDocument of the agent explicitly allowed by the ACL (i.e., <http://agent.com/r2d2#me>) states that -- 

 <http://agent.com/r2d2#me>  owl:sameAs  <http://betteroil.org/rdew#i>  .


rel="me"

As done by IndieAuth. Very similar to owl:sameAs above.

Related

Something like a glossary entry

<http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability>  a                foaf:Document  ;
                                                                         foaf:topic       <#Principal>    .
                                                           <#Principal>  rdfs:subClassOf  foaf:Agent      .
                                                           foaf:account  rdfs:subClassOf  <#Principal>    . 
                                                              sioc:User  rdfs:subClassOf  <#Principal>  , 
                                                                                          foaf:Person     .
Retrieved from "https://www.w3.org/2005/Incubator/webid/wiki/index.php?title=Identity_Interoperability&oldid=600"