Definition: an identity token is a statement from "my" identity provider about "my" identity that can be securely communicated to other systems.General Identity Token use case
Purpose: simplify the user experience so that the user isn't constantly "authenticating" to systems
Alice wants to view a protected photo album shared by her friend Bob. In order for Alice to gain access to the protected resource, she has to prove to the photo service that she is Alice. However, Alice doesn't want to "create an account" at the photo service or have any other "relationship" with the service, just view the protected photos.Where might this concept fit into UMA?
At first, this seems really simple. Alice loads the protected photo album into her browser and when asked by the photo service, she "authenticates" (proves she's Alice) and then gets access to the photos. Even here there are some unanswered questions, which identity does Alice use to authenticate to the photo service? If the photo service doesn't support "federation" then Alice is pretty much forced to create an account with the photo service.
It gets more complicated when you add another entity into the system. Let's say that Alice uses her own photo service (that is different from Bob's) and when she receives the URL to the protected album from Bob, she loads it into her photo service. Alice is already authenticated to her photo service, yet she'll need to "authenticate again" to Bob's photo service to "prove she's Alice".
The goal of identity tokens is to allow Alice's photo service to receive an identity token from Alice's identity provider that it can pass on to Bob's photo service so that Alice doesn't have to "authenticate twice".
Taking the example above in a UMA context, Bob's protected album is protected by Bob's AM. When Alice tries to access the protected album, she'll be directed to Bob's AM where she has to "prove she is Alice". This falls into the "claims negotiation" part of the protocol. This might be as simple as a "claims request" to "identify yourself" with a response of an identity token.
In looking at the UMA use cases from a very high level, my view is that identity tokens are really only useful in the Requesting Party to AM flows and possibly in the Requesting Party to Host flows (though here I'd envision the identity token being part of the OAuth access token).
The purpose of the identity token is to be something that can be presented to the AM to "prove" who the requesting user is without the requesting user having to "authenticate" to the AM. In the scope of claims, is this good enough? or does the AM need better "proof"?
I think UMA should be more generalized because its not just OAuth,
even OpenID, Cardspace and other methods is also popping up. Having
different mechanism for Authentication leaves few things hanging..
like what is the Unique Token that identifies users uniquely in global
scenario? I think that can come at a later stage as OAuth, OpenID and
others mature and have some definite dimensions.
I think we should try to come up with version 1 in the simplest form
possible. Like so many other protocols, as it matures along with other
technologies, UMA will become more robust.
I've experienced that if I think from Implementation Point of View and
the Protocol Point of View, things are different.. With every
discussion, the gap is closing fast..
What is your solution? and what do you recommend?
On 3/30/10, George Fletcher <george....@corp.aol.com> wrote:
> Hoping to spark some discussion on whether Identity Tokens make sense
> for UMA and need some level of specification or whether they should be
> out of scope. Please see the Protocol Issues List
WG-UMA mailing list
Hi Ankit-- Good point that we want to be flexible. While UMA has a "statutory" (design-principle-based) dependency on OAuth for its access management properties, it also has statutory loose coupling with systems that exist to identify users, such as OpenID. So I think identity tokens can be useful to us if they can help Requester systems make trustworthy statements about particular human beings who will benefit from the requested access, no matter what identifier system is being used.
E.g., if a claim can be made that "Hey, I'm asking for access on behalf of bob123456 at Twitter", or "...on behalf of xmlgrrl at Google", or "...on behalf of randomOpenIDprovider.net/users/FooBar", then that's something the authorizing user can make policy about.
(Note that such claims are interesting no matter whether the human being is technically a Requesting Party or whether they're just a person on whose behalf the Requesting Party service is acting. In other words, if we assume that the request for claims is able to distinguish between these two use cases somehow, we can continue to kick that can down the road for this discussion.)