Yes, this is similar to UMA, but also includes other attribute release. (Eve mentioned this as well)
I was thinking in the re-delegation that the OP would contact each service and request a token. Enables the token to opaque to the OP and OAuth client, and follows the design pattern. Digging in a little deeper into the details, I am thinking that the OP gets a verification code that is passed back to the OAuth client, so that the client provides it's client id and client secret with the verification code to acquire an access token and refresh token from the AS. There are likely a few details to think through. Goal of scenario was to illustrate the bigger picture. -- Dick On 2010-05-25, at 12:57 PM, George Fletcher wrote: > Great use case. It's actually similar to some of the existing UMA use cases > so I think covers requirements we'd like to see solved there as well. Were > you thinking for the re-delegation part that the OP would contact each > service and request a token on behalf of the user? Or that the services will > have delegated to the OP to mint tokens they can consume? The latter has some > interesting trust and performance characteristics. > > Thanks, > George > > On 5/24/10 11:59 PM, 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 >> sp...@lists.openid.net >> http://lists.openid.net/mailman/listinfo/openid-specs >> >>
_______________________________________________ specs mailing list sp...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs
