v.Next NewSocialService scenario

Eve Maler eve at xmlgrrl.com
Tue May 25 18:18:12 UTC 2010


There's also a strong similarity with the pending UMA scenarios for "distributed services" and "health data":

http://kantarainitiative.org/confluence/display/uma/distributed_services_scenario
http://kantarainitiative.org/confluence/display/uma/hdata_scenario

These show that there are lots of reasons to do dynamic association with a group of services, with both low and high security/sensitivity/assurance use cases.

While I think UMA helps solve the unified user consent part by offering a single place to configure policies so that tokens can later be issued "silently", we'd hope to meet some of the other elements of Dick's scenario through integration with features of OAuth itself, claims conveyed by the RP/requester/client satisfying the user's policy, PoCo to get ACLs, a discovery catalog service (likely one that speaks XRD/JRD), etc.  There are several ways to go for "chaining" the delegation, depending on whether it's really a requirement to have the RP/requester/client make only a single request in trying to access multiple services.

	Eve

On 25 May 2010, at 6:56 AM, Dick Hardt wrote:

> Once the RP has the OAuth access token, it makes direct requests to Twitter, LinkedIn etc. Does that answer your question?
> 
> On 2010-05-25, at 12:04 AM, Nat Sakimura wrote:
> 
>> The scenario itself is one of the main one that CX working group is tackling right now.
>> It is not easy, but it is very valuable from both the usability to the users and RPs.
>> 
>> Do you suppose that the data is going through the OP or RP is going to make
>> direct requests to Twitter, Linkedin etc. ?
>> 
>> =nat
>> 
>> (2010/05/25 12:59), Dick Hardt wrote:
>>> Below is a vision I have described on how v.Next may evolve that calls out how it relates to OAuth. Hoepfully this will provoke some discussion around v.Next.
>>> 
>>> -- Dick
>>> 
>>> User navigates to site where they can sign up for a NewSocialService. NewSocialService works well if it calls APIs at Facebook and/or Twitter and/or Linkedin. It also would like to help the user find and/or invite friends to the NewService. Access to the user's calendar makes NewSocialService really sing as well as the user's list of favourite restaurants. If the user is a frequent flyer, they also will get some special promotional offers.
>>> 
>>> A) The user provides NewSocialService (the RP) with their OP
>>> 
>>> B) NewSocialService makes an OpenID v.Next request to the OP to get:
>>> 	 OAuth 2.0 access tokens for:
>>> 		- Facebook
>>> 		- Twitter
>>> 		- LinkedIn OAuth 2.0 access token
>>> 		- portable contacts API
>>> 		- calendar API
>>> 	favorite restaurant list
>>> 	frequent flyer credential
>>> 	verified email address
>>> 
>>> C) The user's OP looks at the request, sees that the user has an account at Twitter and LinkedIn, but not Facebook, their portable contacts at Yahoo! and their calendar at Google.  The user has delegated the OP to be able to re-delegate access to all of these services. (ie. the OP has an OAuth 2.0 access token that enables the OP to delegate access to these services on behalf of the user) The OP sees the user is a member of AlaskaAir frequent flyer program.
>>> 
>>> D) The OP presents a screen to the user asking them to confirm the release of:
>>> 	- access to Twitter API
>>> 	- access to LinkedIn API
>>> 	- read access to portable contacts API at Yahoo!
>>> 	- read access to calendar at Google
>>> 	- list of favourite restaurants
>>> 	- AlaskaAir frequent flyer credential
>>> 	- email address
>>> 
>>> E) The user consents and the OP makes a re-delegation request to Twitter, LinkedIn, Yahoo! and Google. The OP puts the results into a magic bundle and magicly transmits it to the RP.
>>> The RP verifies the response and acquires access tokens for Twitter, LinkedIn, Yahoo! and Google.
>>> The RP verifies the email address claim and the frequent flyer claim
>>> The RP (NewSocialService) starts providing a cool, new social service.
>>> 
>>> NOTES:
>>> 
>>> 1) The RP makes one request, the user performs one consent operation.
>>> 2) The OP may or may not be Facebook, Twitter, LinkedIn, Yahoo! or Google. ie, the OP may also be a service provide
>>> 3) The RP may or may not have had to have been registered with Twitter, LinkedIn, Yahoo! and Google. That is an orthogonal requirement that is set by the service.
>>> 4) Re-delegation is not part of OAuth 2.0 at this time. This scenario hopefully illustrates the value of re-delegation.
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> 
>> 
>> 
>> -- 
>> Nat Sakimura (n-sakimura at nri.co.jp)
>> Nomura Research Institute, Ltd.
>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>> 
>> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
>> PLEASE READ:
>> The information contained in this e-mail is confidential and intended for the named recipient(s) only.
>> If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
>> 
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog



More information about the specs mailing list