Re: [mmox] where is identity @ in all this?

["Hurliman, John" <[e-mail]>]

>-----Original Message-----
>From: Christian Scholz [mailto:[e-mail]]
>Sent: Thursday, February 19, 2009 3:05 PM
>To: Hurliman, John
>Cc: [e-mail]
>Subject: Re: [mmox] where is identity @ in all this?
>
>Hurliman, John schrieb:
>> That is the identity proposal I'm working on. OpenID + OpenID Token
>Exchange* + OpenID Attribute Exchange == VW Identity Service.
>>
>> * OAuth was specifically designed for a three legged scenario, and
>when you start adding in more services such as content, messaging,
>voice, etc. it no longer becomes feasible. OpenID Token Exchange solves
>this problem nicely though.
>
>Can you elaborate what the specific problem with OAuth is? Is it that
>you'd need to authorize each and every service as a user? (the same
>problem is coming up on the web as well though if you think about data
>in all sorts of places you might want to give somebody access to)
>

OAuth seems to be solving a different problem. OAuth is great for putting identity+authorization into a token, but in many cases (at least in the virtual world scenario) your identity provider and the authorization provider for a resource are two separate domains. What is needed is a way to pass around identity in a token, which is what the OpenID Token Exchange protocol does. The fact that every authorized token request in OAuth flows through the end user is great for authorization requests and the use cases it was designed for, but makes it a non starter for providing a temporary identity-only token between services.

The use case I've drawn up for virtual worlds involves a user, an identity provider, a content provider, and a world simulator (doesn't matter how many separate services this is, assume a single trust domain for now). The user tells the world simulator that it has an identity at http://identityprovider.com/user which initiates the OpenID authentication sequence. Logging into a world simulator is implicitly giving it access to a minimum set of your profile information on the identity provider and appearance data on the content provider. This is facilitated with an identity token request from the world simulator to the identity service, and that token is passed to the content service. The content service can then confirm the validity of the token and grant access to a minimum set of content.

OAuth definitely has wider adoption than OpenID Token Exchange, and if you see a way to make this scenario work with OAuth (without too many contortions) please let me know.

>And what are you planning to use Attribute Exchange (AX) for? We
>discussed using this in the DataPortability Group a while back for
>storing the URL to your service catalogue that way but the problem was a
>bit lack of adoption. I also tried to do some tests with myopenid but it
>seemed that I couldn't store new fields.
>
>If it's for profile retrieval the OpenSocial REST API is IMHO a better
>fit as it's a) easier to implement and b) more discussed and already
>adopted by e.g. myspace (and yahoo is talking about it).
>

I doubt any identity provider will let you start storing arbitrary data on their server. My understanding of AX is that identity providers can map their existing identity+profile information to well recognized AX fields and provide whatever information they have. Avatars will likely require unique fields, such as the URL of appearance data. If OpenSocial provides a better or better adopted way of doing that then it's worth investigation. It might also mean that it's premature to standardize on one or the other. That seems to leave the options: 1) leave attribute retrieval out of scope (doesn't do much to solve interoperability), 2) make up our own standard based on LLSD/LLIDL (makes the situation even worse, and goes against the proposed goals of the draft MMOX charter), or 3) support multiple implementations (increases the complexity of the spec, and creates excess cruft once one of the competing proposals dies out).