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

Sat Dec 13 17:46:56 UTC 2008

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<http://www.itu.int/itudoc/itu-t/com17/tutorial/85573_pp7.ppt%20slide%2027>. 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/2e6c10ea/attachment-0002.htm>