RE: On behalf of

So Ive watched Henry's ideas and argument evolved, since he first challenged folks in the openid world.
 
The fundamental premise was: why reinvent, when 95% of openid can be done with FOAF + semweb enforcement in logic ?
 
Then, 4 use cases from openid wereanalysed: identifier and identity doc management by IDPs, authorization at RPs, remote form-filling, and (my favorite) ensuring identity transference (there is no impact on your weblife when Google-the-IDP dumps you as a subscriber, because there is user-centric resilience in the design).
 
As openid went pro, many of those use case got sidelined, of course. We are left with
 
We are down now to the http://foxnews.com login button effect' tailored for mass consumerism. There, nobody knows whether yahoo and google and doing openid (or some funky openid/oauth hybrid), live is doing ws-fedp, or twitter is doing OAUTH, or if Im doign SAML2. THere is not a URL in site, and who cares! Nobody cnsumer on the planet cares about the blob format, or the signalling.
 
If one looks at Google open social, open connect, one can even let them present the site's popup, doing "home realm" discovery with a list of IDP selected by the target SP. A nice cloud outsource of discovery.
 
if one looks at Azure clouds ACS service, one sees the API-powered bridge - enabling hosted/onpremise SP service delegate to a token translator, that bridges to openid/oauth/saml/ws-fedp and insulated the local webapp from the blob-wars.
 
-----
 
Presumably, we want to take up again some of the dropped motivators / use cases (form filling, resilience, authorization, identity transferability) that got left behind in the openid world.
 
 
 
 
 
 
 
 
 
 


----------------------------------------
> From: benjamin.heitmann@deri.org
> Date: Fri, 4 Feb 2011 14:18:31 +0000
> CC: public-xg-webid@w3.org
> To: nathan@webr3.org
> Subject: Re: On behalf of
>
> On 4 Feb 2011, at 13:13, Nathan wrote:
> >
> > And we suppose that each x is ident/acl controlled, then s will need to contact x on behalf of the agent. We currently don't have a solution for this (?)
>
>
> In the OAuth world, this is called 3-legged [1] OAuth.
>
> I am not sure of the cryptographic details, but basically this imposes a strong requirement towards specifying the whole authorisation flow
> and all of its details for each individual OAuth eco-system. (Thats why a client of the Twitter OAuth Eco-system can not participate in the Google OAuth eco-system without an additional "connector" implementation.)
>
> When I asked Henry about the issue of 3-legged authorisation, he said that it can probably be solved through providing more elaborate user interfaces, so that all parties can be authorised by the user on his WebID hosting server.
>
>
> See Henry's sketch of a WebID enabled photo printing service [2] for an example of how to (maybe) avoid 3-legged authorisation
>
>
> To summarise my opinion on this:
> * no, WebIDs currently dont explicitly address this use case
> * it is fundamentally relevant to the topic of authorisation
> * it requires specifying the process / flow / orchestration of the different participating roles (in that authorisation architecture)
> * as such it might be out of scope to define that process here
> * however it makes for a very compelling use case
>
>
>
>
> [1] http://wiki.opensocial.org/index.php?title=OAuth_Use_Cases#OpenSocial_and_3-legged_OAuth
> [2] http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo
>

Received on Friday, 4 February 2011 14:51:40 UTC