Limitations: Only Trust Certain issuers of Identity

[bblfish]

Use case 2.7.1 Only Trust Certain Issuers of Identity is listed under Limitations of the UCR. I want to show how we can extend Web Access Control to make these work.

Both of these need us just to be flexible about how we describe the Agent Class. Just as we can in mathematics describe the set of all pairs not by listing them but by description eg P = { x | x % 2 == 0 }, so we can describe classes of agents by description.

1. Authorize any Authenticated Agent to access

This is the requirement The system shall allow access to be limited based on the identity of the agent. Here we could just define the class of authenticated agents as a subclass of foaf:Agent. This is done in the WAC ontology as follows:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix acl: <http://www.w3.org/ns/auth/acl#> .

<http://www.w3.org/ns/auth/acl#AuthenticatedAgent> 
     rdfs:label "Anyone authenticated";
     rdfs:subClassOf foaf:Agent .
    rdfs:comment """
   A class of agents who have been authenticated. In other words, anyone can access 
   this resource,  but not anonymously. The social expectation is that the authentication 
   process will provide an  identify and a name, or pseudonym. (A new ID should not be 
   minted for every access: the intent  is that the user is able to continue to use the ID 
   for continues interactions with peers,  and for example to develop a reputation)""" . 

And with that we can write:

<#authorization2>
    a               acl:Authorization;
    acl:agentClass  acl:AuthenticatedAgent; 
    acl:mode        acl:Read, acl:Write;                                 
    acl:accessTo    <https://alice.databox.me/blog/entry1/comments/>.

So here we see quite clearly how WAC allows the subclassing of foaf:Agents and its use by the agentClass domain.
In the next step just builds on this precedent.

2. Only Accept identities by trusted issuers

This is the requirement The system shall allow access to be limited based on the identity of the agent, only when that identity is issued by a trusted identity provider..

So this requires a notion of an issuer, which is defined in the Verifiable Credentials Spec (has the VC credentials ontology been published @dmitrizagidulin ?). It seems to be a functional property from a verifiable Credential to an issuer. Let us give it the vc: namespace. Then we can determine a group of agents that are authenticated by a set of issuers, by description using OWL (see OWL 2 Quick Reference).

First we can define the inverse of vc:credentialSubject

  wac:holdsCredential owl:inverseOf vc:credentialSubject .

Then we can define a property that goes from an agent via their credential to its issuer.

  wac:hasCredentialIssuer owl:propertyChainAxiom ( wac:holdsCredential vc:issuer ).

And with that we can now define the class of agents that have a credential issued by a group of trusted credentialIssuers, listed in </grps/trusted#issuers> as follows

<verified#agents>  rdf:type    owl:Class ;
   owl:equivalentClass  [
     rdf:type           owl:Restriction ;
     owl:onProperty     wac:hasCredentialIssuer ;
     owl:someValuesFrom  <trusted#issuers> .
   ] .

Finally this can be used by extending WAC so that it can understand the following

<#authorization2>
    a               acl:Authorization;
    acl:agentClass  </grps/verified#agents>;   # Authenticated Agents from verified issuers
    acl:mode           acl:Read, acl:Write;             # has Read/Write access to the collection
    acl:accessTo    <https://alice.databox.me/blog/entry1/comments/>.

Conclusion

The "Only Trust Certain Issuers of Identity" Use Case does not show a limitation of WAC, so much as a limitation of current implementations of WAC, which don't offer these more flexible ways of describing classes of agents.