OpenID Exchange

[Praveen Alavilli]

this is exactly what we are trying to come up (at AOL) too. This fits in 
well for bridging Open Authentication with Open Web Services.

Although in our version (internal - not published yet) we tried to keep 
the EndPoint (SP) & OP separate and use a security token instead of the 
transaction handle to bootstrap on  - so by the time the Consumer makes 
a call to the SP, it already has a Security Token that it can pass on to 
the SP and the SP doesn't need to do the Authentication again. We also 
talked (internally) about an Interaction Service (liberty specs) 'like' 
extension to OpenId that can be optionally be supported by the OP (will 
be defined in the yadis doc).

So let's say if an OpenId user tries to access a Consumer site (a mashup 
in web 2.0 world) which tries to get his albums from Pictures Service, 
the Consumer site can do the authentication with OP and ask for a 
security token that it can use to make a web services (SOAP/REST/etc..) 
request to the Pictures Services. The Pictures Service can validate the 
token, and check for user rights either locally or at OP (if defined in 
OP's Yadis doc) and return the data if the user has previously given 
consent. If not,  Pictures Service can ask the Consumer to redirect the 
user in the browser to a Url  - which can be either the Picture 
Service's own web app or to the OP with parameters required to collect 
the user's consent.

There are definitely both pros & cons in doing it with one being that 
the user's permissions are stored at this own (trusted) OP rather than 
at each SP separately - so the user can go to one place and manage his 
permissions.Would like to see what others think about this approach.

We didn't push the spec to the openid gang yet as at the IIW last week, 
we heard of new extensions like Assertion Quality Extension, and the 
huge interest in SAML-OpenId convergence, which seemed like opening up 
other ways to achieve the same.

We would be more than happy to help & support you with formalizing the 
spec, usecases, etc..

regards,
=praveen.alavilli


mart at degeneration.co.uk wrote:
> I have made an early draft of a spec called OpenID Exchange on the wiki:
>      <http://openid.net/wiki/index.php/OpenID_Exchange_1.0>
>
> The goal of this protocol is to allow user-accompanied HTTP requests. 
> "user-accompanied" means that a consumer makes a request to a service on 
> behalf of a user and the user reviews and approves the request.
>
> Example applications of this include:
>   * Zooomr posting photos into your blog with your one-time approval, 
> without disclosing your login credentials. [1]
>   * Fetching of user profile information.
>   * Social networking friendship handshakes. [2]
>
> The protocol should, in theory, be able to act as a transport for any 
> HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET 
> requests. The protocol for "post in my blog" could, for example, just be 
> an AtomAPI POST request made over OpenID Exchange.
>
> This is still work-in-progress. The spec needs lots of refinement and at 
> some point I'll have to make a demo or two.
>
> [1] You can still see the results of the demo of my earlier version
>     of this on LiveJournal, albeit without the pictures:
>      <http://openrpcdemo.livejournal.com/>
>
> [2] Discussed further in my blog entry on social networking:
>      <http://www.apparently.me.uk/623.html>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>