On Mon, Apr 13, 2009 at 6:59 PM, Ethan Jewett <[email protected]> wrote:
> > > On Mon, Apr 13, 2009 at 11:18 AM, Christian Scholz / Tao Takashi (SL) < > [email protected]> wrote: > >> Picking on me is ok :-) So is this what you _dont't_ want to see or >> _wan't_ to see? >> > > I don't want the service provider (in your case the world where my > inventory, profile, etc. is stored) to give out access to consumers (other > worlds) other than those I have explicitly authorized or agreed to. I want > the service provider to always ask me (the user) first. > Just to clarify: The world the user wants to enter actually knows nothing about that user. Profile might e.g. be stored at MySpace, authentication might be performed via myopenid, photos for textures might be downloaded from flickr etc. All these endpoints are listed in some service catalogue which is sent to the world. And all of these service might need to be authorized at some point to give out that data to that world. I agree what the user needs to be asked first before any data is given out. My main concern was how often the user is asked. Once per service or once per group of services. 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. >> > > [...] > > 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. >> > > It sounds like you're talking about a trusted network, where your terms of > service when a user registers in one world allows you to transfer their > profile data to other affiliated worlds. This transfer might be > configurable by the user on a per-world basis, though I'm not sure how much > better this would be than the standard OAuth flow. But this type of > affiliation sounds like it is a different thing from OAuth. > I think it's really just a bunch of services grouped together into a single authorization realm by some auth manager (or whatever method). And yes, the affiliation between those services and that realm is outside the OAuth spec. It might be some extension though because it would be worthwhile to use the OAuth mechanism where possible. It might also be simply some way of obtaining access tokens another way than the redirect method. [...] > Of course, tokens have these advantages. However I haven't seen any APIs > for authorizing additional consumers using a consumer that has authorized > with an OAuth token. I'd love to see this, as I think it is the right way > to go for services that want to allow a manager consumer to authorize other > consumers on the user's behalf. Currently all OAuth token authorization > schemes I have seen require that the user log in with a username/password > (or OpenID) to authorize a request for access, so an authorization manager > would have to effectively impersonate the user to authorize additional > consumers in an automated manner. > Right, so maybe really just a separate way of obtaining a group of tokens. Those individual services might still just assign a basic set of capabilities to these which could then be upgraded on a case by cases basis (again maybe some sort of extension). 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. >> > > I guess you could try to do the OAuth dance in-world with an option to jump > out into the browser for those who are more security conscious. I know > Second Life has some in-world browsing capabilities, so perhaps they could > be enhanced to facilitate the OAuth token authorization process. > Well, the Second Life client has some builtin web browser which could be used but IMHO it would already be annoying to do that OAuth dance for every service in a social networking scenario. Of course most people probably would have all their data stored at one place but if it's already 2 places (imagine I use my MySpaceID for authentication and profile data but would also like to access my flickr photos) then it's annoying. But regarding usability I'd guess that much work needs to be done should the concept of a decentralized social network really work for the masses. This approach is pretty much the same as the suggestion discussed previously > on this list to use an in-app browser for the OAuth process in Flash > applications and the drawbacks are the same - namely that this method > bypasses anti-phishing technologies in browsers, so it is tough for the user > to verify the authenticity of the site they are logging into to authorize > the request. > Right, the user needs to also trust the client of course and the more clients the more problematic this will be. > (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). >> > > This whole problem of profile exchange seems more along the lines of the > OpenID attribute exchange ( > http://openid.net/specs/openid-attribute-exchange-1_0-04.html). Of > course, that doesn't help with the immersion problem, but looking at this > might provide some guidance on how others are dealing with the issue. > I had a look at that but I am talking about more than just profiles here. And AX is of course again very centralized as it's bound to the OpenID provider. So IMHO this would be similar to the Facebook or Open Grid Protocol concept which of course makes many things easier. -- 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 -~----------~----~----~----~------~----~------~--~---
