On Mon, Apr 13, 2009 at 11:18 AM, Christian Scholz / Tao Takashi (SL) < tao.taka...@googlemail.com> 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. > > 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. > 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. > 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. > > 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. 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. > > (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. > -- Christian > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
