Friday, April 18, 2008

Who's asking?

Consider a user Alice who stores her attributes at some provider. If Alice were to define rules for the release of her attributes, what are the permutations that she might need to account for?

At its most basic, a request for identity takes the logical form of
'A is asking to perform action B on C's resource D on behalf of User E (for purpose F)'
A is who is asking, i.e. what network actor is sending the request.
B is some operation, ie. read, write, delete etc
C is Alice, the owner of the resource in question, i.e. the one whose privacy will be potentially damaged should it be released inappropriately.
D is the resource in question, e.g. Alice's email address
E is the user on whose behalf the question is being posed, i.e. for which user's benefit are the attributes being sought.
F is the intended usage & processing for which the attribute is sought (distinct from for whom it is sought, E)

The resource owner C could conceivably define access rules in terms of each of the other request parameters. For instance, Alice could

1) specify that Amazon (A) can have access to her current shipping address
2) specify that all interested parties can read (B) her presence info, but none modify (B) it
3) specify that her list of upcoming business trips (D) is public
4) specify that her spouse (E) can always see her free/busy schedule
5) specify that her political allegiance be released only for polling purposes (F)

Notes:
  • You can think of an SSO request for authentication as having the resource in question (D) as the 'authentication status', and the owning user (C) left empty (because its unknown when the request is sent)
  • Many use cases are satisfied by a request in which C and E are the same. However, this is the degenerate case of the more general situation.
  • As clients become more capable, requests for identity may not always be sent by some business (and legal) entity on the behalf of user, but will be sent instead by a client directly associated with that user.
  • OAuth is designed to support #1 (motivation being to ensure that Alice doesn't have to give Amazon her password at the Profile provider)
  • OpenID Attribute Exchange distinguishes between read & write, so can support #2 (in the sense that Alice could define differentiated policies)
  • The default FOAF model is #3.
  • Liberty's ID-WSF Identity Model & People Service supports #4, and I believe that the same could be said of XDI.
  • Liberty's emerging Identity Governance Framework supports #5, XDI as well?

No comments: