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

Kingsley Idehen kidehen at openlinksw.com
Tue May 25 22:01:58 CEST 2010


Nathan wrote:
> 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!

Kingsley
> Best,
>
> Nathan
>
> 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?
>>
>> 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.
>>
>> 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.
>>     
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 







More information about the foaf-protocols mailing list