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

[Christian Scholz <[e-mail]>]

Hurliman, John wrote:
>> -----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.

In my understanding OAuth[1] is actually meant to just do authorization,
not authentication and is invented for the case that your identity
provider and authorization provider is in fact not the same service.
It basically lets service A access resources of service B on behalf of
the user without requiring a password.

And looking now at the OpenID Token exchange[2] isn't this actually
binding the token to the OpenID provider? I wonder what happens if that
provider does not support this extension (and my guess is that only few do)?

I agree that OAuth has it's issues in that it requires user interaction
to authorize each access. But this also seems to come up now in the
discussion about the twitter API now being changed to do OAuth only[3]
and maybe this can be brought up in the OAuth list as well. Maybe this
can also be some sort of extension to OAuth. If available the auth step
can be automatic, if not the client needs to open up some web browser.

Whatever we use in the end though I think it's important to keep
whatever provides tokens separate from the OpenID provider (actually I'd
suggest to keep everything except the authentication step away from it).

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

Ok, I see the point here in that it would be possible then to at least
cerate whitelist or blacklists instead of making this public in the
first place.
The main problem is again though to be able to automatically grant
access to certain resources. This means that there maybe needs to be a
way to identify resources (like "a limited set of my profile") and some
way to exchange tokens. Maybe also 2-legged OAuth can help here (see [4]
and [5]). With 2-legged OAuth you don't need to ask the user for
permission. All what is done is that the pre-shared API key is checked.
This way you might be able to do whitelisting/blacklisting as well.

That being said, I haven't though in detail about all this as time was a
bit limited recently. I hope to spend some time soon thinking and
implementing examples though (and discussing it of course).


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

I will and maybe we can also find some solution together. I would
suggest though that if we cannot find a way to make this work with OAuth
we better use some extra service to check the token (if that's possible)
in order to not rely on features not deployed widely.

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

I doubt the same ;-)
But note that your OpenID provider does not necessarily be your primary
source for profile information. But I agree that OpenSocial does not
have all necessary data available and in fact it should be more
extensible in it's nature. Right now it really seems like the sum of all
possible fields of all the social network providers involved in the effort.

As for AX IMHO it's bound again a bit too much to the OpenID provider
and maybe also means that cannot support other means of authentication.

I also actually think that e.g. the appearance URL should not be coming
from your profile but a separate service catalogue (e.g. based on XRDS)
which lists things like your profile URL, your special VW related
services and all other possible services. Using such a catalogue would
also enable us to be flexible in what services to support for various
tasks. You could even list multiple services with priorities and the
client can check what is supported for each VW.

That all being said it's probably all too early to discuss in all that
detail as we first need to have that charter. But the topic definitely
is a hot one not only in the MMOX context but also the web context in
general.



[1] http://oauth.net
[2] http://dev.aol.com/OpenidTokenExchange
[3] https://twitter.pbwiki.com/oauth-desktop-discussion
[4] http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
[5]
http://groups.google.com/group/oauth-extensions/browse_thread/thread/d46f4775d25e0c9d



-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: [phone]                           E-Mail [e-mail]
Fax: [phone]                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)