Hi, I'm having trouble following a lot of the discussion here, possibly because there are assumptions about user expectations that I'm not in agreement with. I think this phrase pretty much sums up the disagreement:
> Now 4. is the tricky part because you don't want to get redirected to each of these services > to authorize each to give out data to that virtual world. I don't mean to pick on the latest participants in the thread, but this is actually exactly what I want to see happen from my perspective as a user. I don't want any service to give out my protected information to an arbitrary consumer service without my go-ahead. Of course, it's the user's prerogative to set up or use yet another service (an authorization manager?) to impersonate the user and take care of the whole delegation dance behind the scenes, but it was my understanding that most of the point of OAuth was to allow the developers of service providers and consumers to get out of the impersonation racket (impersonation of the user through the username/password pair, specifically). Ethan On Mon, Apr 13, 2009 at 9:14 AM, Christian Scholz / Tao Takashi (SL) < [email protected]> wrote: > Hi! > Great discussion here and very relevant to what some discussions on the > IETF MMOX mailing list are heading to (MMOX is about virtual worlds but > these problems might be applicable as well to social networks in general). > > The main problem here is the following: > > A virtual worlds client wants to login a user to a certain 3D world while > reusing as much of the user's data as possible. This data might be stored on > various services. Services might be authentication, profile data, inventory, > friends list, IM server but also 3D related services of course. > > All of these services can be situated anywhere on the net and we assume > there is some standard API available to access that data (e.g. > PortableContacts or XMPP). > > Now there was some talk about a service catalogue in e.g. the DiSo or > DataPortability group (and probably elsewhere) which might be a simple list > of where those services for a user might be located. One might e.g. use XRD > as a format for this. So basically you have some user endpoint which can > point you to a list of services a user has stored elsewhere on the net. > > This of course can be easily translated to social networks as virtual > worlds might be simply be seen as the same thing but with 3D services > attached. > > Now the requirements in MMOX might be as follows: > > - A user should not need to register at each virtual world to be visited as > this would break the immersion > - A user should be able to "carry" profile information, group memberships, > inventory etc. with him > > This basically means that the 3D world needs to get access to many of those > services listed in a service catalogue in order to function. The basics > would be to have a profile available and some avatar. > > Now a flow could be as follows: > > 1. The user enters an OpenID into the virtual world client and points it to > the virtual world to enter. > 2. the client performs authentication as defined > 3. the virtual world does service discovery on the user openid and obtains > the service catalogue (XRD file) > 4. the virtual world selects those service from the catalogue it needs to > use and asks for authorization. > > Now 4. is the tricky part because you don't want to get redirected to each > of these services to authorize each to give out data to that virtual world. > > So what's needed is some way of authorization manager to do this on behalf > of the user and might result in a set of access tokens to be sent back to > the virtual world to use. This might just be a basic data set the world has > access to but it should then be possible for the user to add additional > permissions manually later on. > > I am not sure I was able to explain this use case properly but I am happy > to answer any questions. > > The main problem here is simply: How do I allow access to a set of services > to a site just logged in to without being redirected to each of those. > > -- Christian > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
