WebID/Authorization Delegation

Authorization Delegation

Problem description


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


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 the WebID protocol as explained by the specs. Bob's secretary sends her own certificate with her WebID.

5a) standard Secretary 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 WebID 1.0 Authentication Sequence


@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.".

Use cases


This example is specific for the case of 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.


  • 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 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.


  • 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.


  • 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.


External pointers

Last modified on 14 August 2012, at 11:05