<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>OK.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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) <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>See her <a
href="http://www.itu.int/itudoc/itu-t/com17/tutorial/85573_pp7.ppt%20slide%2027">http://www.itu.int/itudoc/itu-t/com17/tutorial/85573_pp7.ppt
slide 27</a>. 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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>One could legitimately call that a stack.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This all looks distinctly doable and valuable, since openid auth
and AX are already in the pot.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>
<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p>
</div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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!<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Pat Cappelaere
[mailto:pat@cappelaere.com] <br>
<b>Sent:</b> Saturday, December 13, 2008 8:40 AM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] the OAUTH question, harmonization in OpenID
forums, a little reflection on OAUTH in US realty.<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Peter,<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On Dec 13, 2008, at 10:14 AM, Peter Williams wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Could the OAUTH and OpenID camps start by agreeing to harmonize
terms (to help the ignorant, like me)?</span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.</span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>If a workflow comes in as a consumer and tries to act on
behalf ot the user, we need OAuth to make this happen.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.</span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A joint document might be written. Apart from harmonizing
language, there doesn’t seem to be a lot to do.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Pat.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>