"We can all be friends, whatever our Principals are" - anonymous fishPrincipal. 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.
- 1 Problem statement
- 2 Direct Verification mechanisms for different types of Principals
- 3 Indirect Verification mechanisms
- 4 Related
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:
- A WebID Principal:
- An email Principal:
- An OpenID Principal:
- An RSA public key Principal
@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:email@example.com>; 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:
- a function from that string identifier to a resource which that string identifier has as referent - usually a network resource
- a function that maps that identifier to the subject, i.e., the agent that is identified by the Principal - known in WebDAV as the
So an OpenID Principal is a string with the following two functions:
- the function
Reffrom the OpenID Principal string to a home page (identified by a URI)
- the function
OpenidSubjfrom the home page to the agent being authenticated, known also as the function from
foaf:openidobjects to subjects
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 foaf:openid <http://logic.edu/webids/jz> .
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:
- Determining if the action on the resource has any restrictions (out of politeness one does not ask for identity if it is public)
- Authentication: Requesting the User's identity - his Principal - and a proof that he is the Subject of that Principal.
- 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:firstname.lastname@example.org> ], <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 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:email@example.com> .
foaf:mbox is inverse functional relation, any two proofs of an e-mail Principal will identify the same agent.
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> .
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.
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:firstname.lastname@example.org> .
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
How one can verify different identities that are in an
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> .
As done by IndieAuth.
Very similar to
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 .