[foaf-protocols] Fwd: v.Next NewSocialService scenario

Story Henry henry.story at bblfish.net
Wed May 26 21:59:05 CEST 2010

On 25 May 2010, at 10:28, Dan Brickley wrote:

> This excerpted from the big debate currently happening on OpenID specs
> list re layering of next versions of OpenID/OAuth. How does foaf+ssl
> play with such a scenario?

What is your view on this Dan? You are following both lists. What do 
you think we could not do with foaf+ssl that they are trying to solve?
I am not sure it is worth spending time on their debates myself yet, as
they don't tend to listen from outside it seems to me.


> Dan
> ---------- Forwarded message ----------
> From: Dick Hardt <dick.hardt at gmail.com>
> Date: Tue, May 25, 2010 at 5:59 AM
> Subject: v.Next NewSocialService scenario
> To: OpenID Specs Mailing List <specs at openid.net>
> 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.
> 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
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list