[foaf-protocols] Fwd: v.Next NewSocialService scenario
kidehen at openlinksw.com
Tue May 25 22:01:58 CEST 2010
> isn't that more silo to silo migration giving a false sense of illusion
> to the user that they control there own data, when in effect they can
> only select who controls there data (from a subset of 'trusted'
> providers who support the migration protocols).
> Putting that aside though; wouldn't it be nice to leverage this to pull
> all ones data from these services in to their own personal data store,
> and further if an open spec for API access to this kind of data was
> produced, then we could let any of these services utilize the
> information whilst we remain in control of it.
> Quite sure there is a lot of scope in OAuth where one basically becomes
> there own OAuth provider, and where the authorization part (where you
> click "ok" or "deny" happens through FOAF+SSL.
> Yet, nothing concrete, just words & thoughts atm.
Yes, all those Web 2.0 silos with soon become Linked Data Spaces :-)
This is why RDFizers and Linked Data Spaces are so vital. Use Web 2.0
APIs as weapons for unshackling silos!
> 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?
>> ---------- 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.
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
President & CEO
More information about the foaf-protocols