On Mon, Apr 13, 2009 at 4:44 PM, Ethan Jewett <[email protected]> wrote:
> 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. Picking on me is ok :-) So is this what you _dont't_ want to see or _wan't_ to see? So what I am talking about is maybe a way of coupling together services under an authorization realm again which previously have been decoupled by moving them to different unrelated services. So e.g. Facebook has it all very much under together under one site. You only need to get authorized there and FB can give out any data the user authorizes. The same is true for the Open Grid Protocol which is one of the influencing factors at MMOX. Here the main idea is also that all relevant services are grouped under one "agent domain" which is the only point where you need to authorize. In a more decentralized world where I hope we are heading services are more spread at different sites with individual authorization realms which in turn means you need to authorize each site individually which is not really user friendly. What I am talking about now is mostly a way to be able get them at least authorization wise under one roof again. As you can (hopefully) setup permissions on all your data you want to give out at a centralized service you should be able to do the same with a decentralized storage of your data. > 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). Well, there is still some differences I think (which also have been pointed out): - A token compared to username/pw can still have only limited access whereas a username/pw combination gives you all permissions - A token can have a limited lifetime - A token can have a limilted scope, e.g. not allowing every service to connect So I would see that manager really just as a convenient method of obtaining these tokens as a group where you would otherwise give out those permissions invididually. As for breaking the immersion because of some window popping up when moving from world A to B and asking for permissions I guess there is no way around though as you don't want to automatically give your OK to whatever world you are visiting. But there might be phishing problems involved of course. (although maybe that permission can be given to a limited profile and a basic avatar and if you need access to your inventory then you need to grant permission separately. Then again the question here is what part needs access, your client or that world. Questions we still ned to think more about on the MMOX list. But in the case of social networks we have a very dumb client involved and it most likely will be the third party web site and not the web browser). -- Christian > > 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 >> > > > > -- Christian Scholz http://mrtopf.de/blog New Podcast: http://datawithoutborders.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
