View source for WebID/Authorization Delegation

= Authorization Delegation =

=== Problem description ===

=== Requirements ===

==== Distinguish users from agents ====
Delegation should not be handled by camouflaging an request of an agent in the sense that this request is indistinguishable from a user request. An agent should use its own certificate and should be identified and described by its own WebID profile. This allows resources owner to permit / deny access based on this information.

==== Easy to use ====
The one and only place to describe which agents should be able to operate in the name of the profile owner should be the profile itself. To grant delegated access to a secretary agent, no other actions than simply adding triples to the WebID profile should be needed. To reset this grant the same triple should be removed.

==== Linked Data and Read Write Web integration ====

==== Minimal protocol footprint ====

==== No enforcement to reveal agent identities ====


=== Auth Sequence ===


[[File:DelegationAuthSequence.svg|800px]]

2) The secretary, who in this instance is working on behalf of Bob, adds the following header to the request:

  On-Behalf-Of: http://bob.example/#me

3) The resource is protected and so the Guard on Alice's server requests that Bob authenticates using [http://webid.info/spec/ the WebID protocol] as explained by the specs.
Bob's secretary sends her own certificate with her WebID. 

5a) standard Secretary [http://webid.info/spec/ WebID validation] 

5b) Secretary Relation Check

Here the Guard verifies that the Secretary is indeed Bob's secretary by finding a 

   :bob cert:secretary :secretary 

relation in bob's profile.
  
All other steps, see [http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol WebID 1.0 Authentication Sequence]

=== Schema ===

 <nowiki>
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix cert: <http://www.w3.org/ns/auth/cert#>.

cert:secretary a owl:ObjectProperty;
  rdfs:label "secretary";
  rdfs:domain foaf:Agent;
  rdfs:range foaf:Agent;
  rdfs:comment "The secretary agent of an agent can fully act on behalf of the agent.".
</nowiki>

=== Use cases ===

==== MyProfile ====
This example is specific for the case of [http://myprofile-project.org/ MyProfile], but it could match other cases as well.

MyProfile uses a caching engine to store external profiles (users who do not have local profiles), in order to improve user experience. However, once access control policies kick in, things get complicated.

Let's take for example the following case: A and B are both local users. C is an external user with access control set up for his/her profile. When A tries to view C's profile data, a personalized "view" of the profile specific to A is displayed. When B tries to view C's profile, different profile data is displayed for B. At this point, the caching mechanism needs to be able to cache different profile views, corresponding to different access control policies specific for the user requesting the data.

Upon receiving a request, C's server may want to know who the real requester is, and maybe make different decisions based on this information. At this moment there are two cases, the first where A directly requests information from C (using A's WebID), and the second where the caching engine acts as a "secretary" and requests information from C on behalf of A (using the secretary's own WebID, as well as the identity of the user on behalf of which it is making the request). One may argue that there is a third case, in which the caching engine requests information on no one's behalf, but in this case standard access control rules should apply for the secretary's WebID.

In order to avoid ambiguity while taking trust decisions, it is important that both the secretary's identity as well as the user's identity are conveyed during the request.

==== Personal Devices and Applications ====

Currently, the default usage intention for WebIDs are browser-based authentication scenarios.
This is an important use-case and should be of special interest but we use the world wide web not only from our browsers but also from other applications and from other application on other devices such as smartphones, tablets and freedomboxes.
In a typical every day usage scenario, we use feed readers and social network clients hand in hand with web browsers.
This is true esp. for mobile devices where specialized clients for social activities are widely in use and does exist even for academically driven social networks as the distributed Social Web based on FOAF WebIDs.

All these applications have in common that they act in the name of its users and fetch and manipulate resources in a way that this could also be done by the user itself and with her browser.
In a WebID-enabled communication scenario, these devices use their own certificates for communication since we do not want to copy the browser certificate to these devices and we also do not want to save the passphrase on theses devices and services.

''Comments:''

* For devices that are personal such as feed readers, browsers, smartphones or freedomboxes there is no need to do delegated authentication. In these cases the device can be seen as an extension of the human being who owns them ( see [http://en.wikipedia.org/wiki/The_Extended_Mind Andy Clark, The Extended Mind] for some philosophical backing ). It is therefore much easier in these cases to give each of them a certificate with the same WebID in the Subject Alternative Name position. This is easy  and cheap to do.

==== Vacation Replacement ====

In a typical office scenario, employees declare vacation replacements for the time of their holiday in order to achieve an uninterruptible service during that time.
One option to allow access to this vacation replacement is to give him the original certificate or to add his private key to the users WebID.
This solution has two drawbacks: (1) the users certificate is burned after the vacation and she needs to create a new one, (2) a resource guard can not distinguish between the user and the vacation replacement user, which allows for abuse.

In this context, the named agent is the employee which is on holiday and her vacation replacement is the secretary agent.

==== Working Groups ====

Access for working groups to a resource is typically specified in a way that each resource guard needs to hold a list of group members of this group.
In the Social Semantic Web, these working groups have its own WebID resources which describe the group as an entity and its members as relations to their user WebIDs.
To authorize a group of agents to access a resource should be as simple as to a single agent.
In order to allow this, we define the group as the named agent and all group members as its secretary agents.

An alternative could be to share one single group certificate with all members or to create a group certificate for each member and describe all public keys in the group WebID.
Again, these solutions have different drawbacks: (1) a shared certificate needs to be updated each time a user leaves the group, (2) multiple group certificates for each user does not allow for distinguishing which user accessed the resource, which allows for abuse. 

In this context, the group is the named agent and all current group members are secretary agents.

''Comments:''

* Why not just make the Access Rule to a resource for a group be that each member of the group can access the resource? The Group WebID is useful for naming the group, but there is no need for each member of the group to have a certificate with that Groups WebID. The [[WebAccessControl]] ontology has an `acl:agentClass` relation for just this purpose. For example one would define a read access on a file <card.rdf> to all members of the WebID team with: 

  :a1 acl:accessTo <card.rdf>; 
      acl:mode acl:Read; 
      acl:agentClass <http://www.w3.org/2005/Incubator/webid/team#we> .

==== Office Roles ====

An office role is a construct where a user can access specific resources because of his working description.
A product manager has access to all product related resources because of her role as product manager and not because of her identity.
The role itself is identified by WebID and all access authorization rules should use this role WebID instead of a user WebID.

In this context, the role is the named agent and the current role owner is the secretary agent.

''Comment:''

* Why not more simply have the access control rule be for members of the group :ProductManager published somewhere,  and just simply change the membership of that group when someone is no longer in that role? The [[WebAccessControl]] ontology makes that easy with the `acl:agentClass` relation to a group.

=== Implementations ===

* [https://github.com/AKSW/Erfurt/tree/feature/AcAuthRefactoringAndWebId php-liberfurt Auth RefactoringBranch]

=== External pointers ===

* [http://lips.informatik.uni-leipzig.de/pub/2009-100 November 2009 thesis "Aspects of Communication and Integration in Semantic Data Wikis"] - Philipp Frischmuth, (in german only) describes WebID delegation in Chapter 5.5.2 and esp. in 6.1.3 und 6.2.2
* [http://www.semantic-web-journal.net/content/architecture-distributed-semantic-social-network August 2011 paper "An Architecture of a Distributed Semantic Social Network"] (S.Tramp et.al - submitted on 03.08.2011 to the Semantic Web Journal) describes WebID delegation in Sec. 2.3.1. (with different namings)
* [http://lists.w3.org/Archives/Public/public-webid/2012Jun/0012.html June 2012 thread on WebID and RWW mailing lists]
* [http://lists.w3.org/Archives/Public/public-webid/2012Jul/0011.html Comparison with CORS]
* [http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf Extending the WebID protocol with Access Delegation] - Sebastian Tramp, Henry Story,  Andrei Sambra, Philip Frischmuth, Michael Martin, Sören Auer submitted for the [http://iswc2012.semanticweb.org/ ISCW 2012] [http://km.aifb.kit.edu/ws/cold2012/ 3rd International Workshop on Consuming Linked Data]