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

[Pat Cappelaere]

Exactly.
Now, if we could just capture this in a document!!!!
Pat.

On Dec 13, 2008, at 12:46 PM, Peter Williams wrote:

> OK.
>
> I can already see the vision elements you have – from that one mail.  
> It’s architecture is evidently much bigger and richer than the OAUTH  
> writeup. I knew it had to be something bigger that simply redoing  
> the classic OAUTH use case (give a token to a spoke in a hub-and- 
> spoke overlay, so the data consumer can cite some static machine  
> auth/authz value back to the hub during the backchannel API calls)
>
> I was reading one of Eve Maler’s old presentation yesterday, trying  
> to get back to the elemental message pattern analysis that  
> originated all of this work. As an engineer, she distinguishes  
> websso from distributed transactions - and happens to give push (vs  
> more openid-ish) pull flow examples (that were more prevalent in  
> that era).
>
> See her http://www.itu.int/itudoc/itu-t/com17/tutorial/85573_pp7.ppt  
> slide 27. What is interesting is the speaker blurb (vs the  
> presentation about old SAML messages, protocols, signals etc). It  
> conveys the bigger picture “design” effort that went into the  
> patterns –and the design of the supporting elements.
>
> As one might expect of what is essentially an upper-layer stack  
> security infrastructure, much like ITU-T’s own GULS standards work  
> from the 1993-95 period, there is the attempt to fashion a common  
> token format, a common req/resp protocol, and standardization of the  
> (3) primitive statement semantics. And it was done with XML elements  
> (rather than ASN.1 types/encodings).
>
> I particularly like the conceptual model a slide 27 and the  
> supporting speaker blub that leads up to it - spread over several  
> slides. Being early SAML, its not dogmatic – and the argument  
> focuses on the space of patterns (vs some or other bit format). I  
> suspect (and please study the blurb, not the slide content) you’d  
> agree it’s structurally identical to your own vision.
>
> If we dump SAML and XML and now simply use 3 openid extensions (for  
> each statement type), retain the ability for 3 different agents to  
> mint their element of the assertion (OP for auth,  AX for  
> attributes, OAUTH for entitlement tokens), all the patterns of  
> interaction expressed in her original analysis would still hold.
>
> One could legitimately call that a stack.
>
> This all looks distinctly doable and valuable, since openid auth and  
> AX are already in the pot.
>
>
>
> For a living, I have to configure deep packet inspection “protocol”  
> filters operating at wire speed, using the Cisco layer protocol/ 
> stack notation that drives their Intrusion Prevention Systems and  
> firewall equipment. So, the more architecturally clean one can keep  
> the various extensions in the “stack,” the better it is for me and  
> my kind. If you can get openid folks to formalize their state  
> machines, that would  help too!
>
>
> From: Pat Cappelaere [mailto:pat at cappelaere.com]
> Sent: Saturday, December 13, 2008 8:40 AM
> To: Peter Williams
> Cc: general at openid.net
> Subject: Re: [OpenID] the OAUTH question, harmonization in OpenID  
> forums, a little reflection on OAUTH in US realty.
>
> 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/700f3c46/attachment-0002.htm>