This discussion is going on and on and people are talking about it from all points of view (including Kim, Pete, Dave, Paul, and Eve, who apparently started it all in a conversation with Jim). The conversation seems to be arguing about technical issues, but in reality it is mostly a semantic argument rather than a technical one.
From what I can gather, I think all of the parties agree that:
- The user can give permission to an entity to do "something" for the user at some later point in time.
- When this "something" occurs, the entity initiating the "something" needs to be identified as well as the user for whom the "something" is taking place.
- When this "something" occurs the user does not need to be physically present, online, or otherwise directly involved.
The points of disagreement seem to be in the area of how to refer to this taking place and whether or not this is supported by one protocol or another. I'm not married to the terms "user-not-present" (which is, physically true, by the way) nor the term "on behalf of", although I do think that both apply to this case. I'm also OK with the term "delegation".
One thing that hasn't been clearly discussed here is the case of real impersonation. There are real world cases where impersonation takes place, such as when an administrative assistant performs some tasks in the name of his boss (like sending flowers to my wife :-) ). I certainly don't want those flowers to indicate that they came from my admin. However, I still think that case is rooted in my admin authenticating as himself to a provider where I have granted permission for him to act in my name (perhaps for a particular set of tasks), so this seems like the same ultimate use case (me defining permissions on some resource I control).
So the last part in the discussion is onto the protocols. I can state unequivocally that Liberty ID-WSF does in fact fully support this use case and has explicit definition of all the parties involved in a transaction. Liberty also provides for the means for collection of the permissions necessary for the transaction as well as a means for an entity to indicate to the service provider that they intend to invoke a particular request later in a context where the user will no longer be present (so that the service provider can prompt for any necessary permissions from the user). At Liberty, we painstakingly walked through the entire use case and all of its related messages to ensure that the system would work in that case.
I do not understand how this same (or similar) sequence would be done using the WS-* family of specifications. I am sure it could be done, but I believe anyone doing so would be doing a one-off solution that would not interoperably work with anyone else's one-off solution as the protocols don't dictate a standard way to do this (yet). I would like to be wrong here and call on the WS-* guys to stand up and point out how this could be accomplished in a standard way that is expected to be interoperable.
Tags : identity / liberty / Liberty Alliance / WS-Trust / delegation / SAML / impersonation
4 comments:
Also, another category of impersonation which I don't always see addressed is the situation when a power of attorney being in place. IANAL but I seem to remember that in this situation the attorney acts as if they are the subject - even signing the subject's name in situations when the subject would have signed. If the subject would have used InfoCard protocols to log in to an RP (e.g. to manage their bank account or pay bills), the attorney would also log in to those providers using the same identity, unless the RP has such sophisticated account management that it can associate multiple identities with the account, in which case the attorney can log in as themself. There seems to be a security usability issue with power of attorney in RP systems which require the subject to provide the RP with a secret to authenticate, and require the subject to change the secret frequently, as well as systems which use the biometric of the subject to authenticate.
Mark Wahl
What about the scenario where the service provider offers the user an option to use 'delegation' if so required. If the user accepts then greater liability is placed on the user for any of these 'delegated' transactions. The service provider could also request a 'delegation token' and possibly place some restrictions on what can transpire i.e. banking etc.
KDY
The model I spoke about was one where the service provider gives the user the option of delegation.
I'm not sure there's any greater liability than if the user did the operation themselves (i.e. they are still responsible).
I would expect that the SP would definitely have restrictions.
Conor, you mention that impersonation/delegation/user-absent use cases are explicitly handled by Liberty.
Can you indicate which part of the specification deals with these scenarios? A quick search didn't turn up any obvious leads.
Thanks,
Erik
Post a Comment