[OpenID] the OAUTH question, harmonization in OpenID forums, a little reflection on OAUTH in US realty.

[Pat Cappelaere]

Peter,

On Dec 13, 2008, at 10:14 AM, Peter Williams wrote:

> Could the OAUTH and OpenID camps start by agreeing to harmonize  
> terms (to help the ignorant, like me)?
>
> As far as I can tell, the “Service Provider” (SP) in the OAUTH model  
> is known as the IDP/AA/OP in the SAML/openid model for push/pull  
> assertion protocols.

Not at all.  I can provide a web service to task a satellite for NASA  
(Called an Sensor Planning Service or SPS in Open Geospatial  
Consortium terms).  The SPS need to be able to authenticate users  
using their openid and go to their OP.  if the SPS is accessed via a  
form on a NASA portal, this can be done via straight OpenID.
If a workflow comes in as a consumer and tries to act on behalf ot the  
user, we need OAuth to make this happen.
If we can leverage the synergies of the two protocols, then we can  
relief the SP from having to manage access tokens and user grant/ 
revoke capabilities that do not scale very well when the workflow has  
to access many other services across many different organizations.

I would also need to use AX to get access to the user role as provided  
by his organization (assumming that it is not writable by the user)  
and I trust the organization's OP.  If the user has been granted the  
role to task the satellite, then  it may be granted.
Think about this capability for firefighters in the field.  I could  
create a temporary trust with the CA Fire Department's OP.  A  
firefighter in the field could be given a tasking role by the fire  
chief.
The firefighter could then authenticate to a workflow.  Workflow tries  
to task SPS.  SPS checks User's OP and user for acceptance of  
authority delegation to workflow, check user profile for role and  
grant access to task.  Data comes back.  Workflow continues on and  
accesses other services to process the data and eventually delivers a  
JPG to the firefighter in the field.  SPS had no-apriori knowledge of  
that firefighter before hand.

>
> Both seem to call the classical relying party the consumer (of the  
> assertion/ticket), though because of the degree to which SAML use  
> cases 99% overlap with openid, the consumer is also commonly  
> referred to as a Service Provider.
>
> A joint document might be written. Apart from harmonizing language,  
> there doesn’t seem to be a lot to do.
>
There is actually a little to do.  We need an openid extension that  
would allow the SP to check the consumer claim that it is acting on  
behalf of the user by going back to the OP and check it.  I actually  
proposed an amendment of an existing openid-oauth extension to do just  
that.

> I’ll hazard a guess at which why this has not already happened.  
> Perhaps folks can correct anything too outlandish. The only claimed  
> rationale for OAUTH existing, so far discovered, is the claim to a  
> scope beyond which openid auth is appropriate (e.g. openid auth and  
> YADIS are http protocols and are thus poor in a SOAP over message  
> queuing environment --  since the architecture sorely lacks a  
> binding model). If one accepts that, then the place in a cooperative  
> stack alongside the openid layer could be defined, with openid  
> merely being another particular layer –as opposed to the name the of  
> whole. If there is an ego-war going on over this (whole vs part) and  
> someone’s legacy in the written history of the web is at stake, then  
> there is obviously little hope of openID+ OAUTH formal harmonization.
>
I do not think that there is an ego war... we need to think this  
through and get a consensus to get it moving and implemented in a  
testbed first and then standardize it.
Pat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081213/9b293cc5/attachment-0002.htm>