<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.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The power of openid is that app developers don’t need to
do oauth on the backflow (more core library code, more management, more control
issues) or a web service (more core library code, more management, more control
issues).<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 know I’m stepping on toes here, but that’s the
point! Merger with OAUTH has to make a functional difference, not just repeat
what already exists in a different form. Don’t want two management and
control frameworks.<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'>We have the concept that (a) a websso flow between OP and SP
involving the user has setup a persistent association, and (b) the SP and OP/AX
agent can now freely ping each other using AX (with no visible experience), (c)
no identity verification service need be requested (identity=openid=null)
allowing a developer to use the AX extension with the core assertion protocol without
worrying about claimedids (d) the nature of AX schema is such that there are an
infinite number of attribute-based protocols that an app developers can now
create. Multi-valued AX response can be sending back 1000 photos if it wants,
or 7 .crt files (certificates) in a user’s chain. The attribute values
may even be defined as ordered (since the schema is [properly] vendor-driven).<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'>Of course the security context for that AX-only flow is one of
the OP (as user AGENT) is talking to SP (local session derived from an openid
assertion). That is, the user is talking to the user, as represented by two
agents. A better name for the OP in an AX-only flow would be AX authority, or
similar. The AX authority is likely to be a proxy – a data service front
ending ldap, or sql, or some data object library.<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'>Now we just have to be a little careful. In the culture of
OpenID, the OP is operating under UCI rules (data ownership and release control
are _<i>culturally</i>_ in the hands of the user, not the vendor/SAAS operating
the OP site as in the more traditional FaceBook & VeriSign TTP cultures). However,
the same is not true for the SP. As in the case of the Foundation itself, the
SP can be operating under (published) rules that TAKE OWNERSHIP of information,
once introduced into the SP site. A contract binding exists, under the trust
model, agreeing to ownership issues, legal obligations of the parties, etc.
And, as we now know, XDI envisions itself as playing the role of
setup/management/control of such contract bindings (in the openid world).<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'>Whether the app developers uses the openid backflow or
foreground flow seems to me to be a minor matter of engineering and
practicality. The data flow is simply AX-only messages – with null identity
verification fields – over an openid association that brings to the flow
the benefits of the data origin authentication service of the respondent assertion’s
signed mac. Just because AX-only flows over associations pass through the
foreground channel does NOT mean the user’s focus has to be take away
from the current task, in GUI terms. There does not HAVE to be a page referenced
at the OP/AX server that says: do you give consent to the release of these 1000
pictures and contacts. If the trust model of the OP/SP (i.e. an XDI document) is
such that consent is implied under the contract binding, there may be a background
delta-based sync going on every 1m, in a hidden iframe. If the association
lifetime expires, then I can there being a need for the app to force an full
run of openid auth, to re-establish the claimedid by invoking the identity
verification service, and thus attempt to give new life to the local sessions
at SP and/or OP.<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<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"'> larry drebes
[mailto:ltd@janrain.com] <br>
<b>Sent:</b> Tuesday, December 30, 2008 6:03 AM<br>
<b>To:</b> Pat Cappelaere<br>
<b>Cc:</b> Peter Williams; general@openid.net List<br>
<b>Subject:</b> Re: [OpenID] CheckIDRequest with Big AX<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>The use case is legit.
The OpenID flow is through the user agent, the user is redirected to the OP,
the OP redirects back to the RP. For backchannel access to data (where
access has previously been granted), oauth or a callback url are
much simpler flows than than going through the user agent redirect.
larry-<o:p></o:p></p>
<div>
<p class=MsoNormal>On Tue, Dec 30, 2008 at 5:25 AM, Pat Cappelaere <<a
href="mailto:pat@cappelaere.com">pat@cappelaere.com</a>> wrote:<o:p></o:p></p>
<div>
<p class=MsoNormal>I think that AX is used in its designed role here.<o:p></o:p></p>
<div>
<p class=MsoNormal>The user grants access to his information.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>The SP ought to be free to access that information at
anytime and update/store stuff at anytime, right?<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>This seems reasonable to me and very appropriate to leverage
that capability at the enterprise level.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Pat.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On Dec 30, 2008, at 6:59 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'>This begs a wider question concerning AX. The underlying issue
relates to my own confusion over the wider role of AX (expressed in a thread a
week or two ago).</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'>For Dick, evidently AX is the extensible form of sreg –
and is about a visible user-centric experience (e.g. a signup wizard). It's
little more. There is a bit of stuff about AX update.</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'>For others, two websites may be exploiting an _<i>existing</i>_
openid pairwise security association to signal each other over that
authenticated channel, using AX extensions for requests/response FOR
PER-APPLICATION PURPOSES. This may be occurring OUTSIDE a visible user
experience (such as signup form population). The user may have no interactive
role. One might only set a config policy of "please sync me every
10m", and 10 AX transactions occur over 10 hidden iframes (every 10m).</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'>Im with Pat on AX; doing the kind of thing he is doing is what
it seemed to be saying it was for...</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 with XRI, the power of openid is its architecture and the
enabling that XRI/XDI/AX/URls provide to app developers. It's not the
particular GUI practice today – which at the end of the day is just
another websso protocol that also ran. Since any and all websso is however a
fundamental enabler (because it brings with it solutions to security
associations, consent, and impersonated session management), its what now
follows from and develops on the openid architecture that is the _<i>really</i>_
interesting stuff.</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'> </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'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt;
border-width:initial;border-color:initial'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>
<div>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[<a href="mailto:general-bounces@openid.net" target="_blank">mailto:general-bounces@openid.net</a>] <b>On
Behalf Of </b>larry drebes<br>
<b>Sent:</b> Tuesday, December 30, 2008 3:19 AM<br>
<b>To:</b> Pat Cappelaere<br>
<b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> List<br>
<b>Subject:</b> Re: [OpenID] CheckIDRequest with Big AX</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='color:black'>Hi Pat,<o:p></o:p></span></p>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>The normal behavior for an OP is
to assume the user is in the loop. With javascript enabled the form POST
submit should happen automatically, for the vast majority of time this is not
pestering the user.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>larry-<o:p></o:p></span></p>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>On Mon, Dec 29, 2008 at 7:46 PM,
Pat Cappelaere <<a href="mailto:pat@cappelaere.com" target="_blank">pat@cappelaere.com</a>>
wrote:<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='color:black'>I have an interesting problem.<br>
<br>
I am trying to make a CheckIDRequest along with a few experimental AX.<br>
Problem is that my attributes are fairly large and could overflow the<br>
GET.<br>
The Janrain Ruby library detects that and turns the response into a<br>
secondary form. A user has to hit continue for the form to do a<br>
post. This is fine if there is a user in the loop (although confusing<br>
at best) but this is not my case. I do not have a user in the loop.<br>
I am really trying to authenticate an application consumer that<br>
happens to have an openid and trying to get its pubic key in order to<br>
do the OAuth dance using AX... cool stuff...<br>
<br>
My questions are:<br>
<br>
Is this the normal behavior of an OP?<br>
<br>
Should I try to patch the server library to return a directPOST?<br>
<br>
Or get my consumer to break down the request in two parts? I am not<br>
quite sure how the second part would look like though...<br>
<br>
Any suggestions?<br>
<br>
Thanks,<br>
<br>
Pat.<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>