<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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 92.4pt 1.0in 92.4pt;}
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=MsoPlainText>Delete now, folks - unless one is interested in a discussion
of Pat’s application of openid. (There is little or no ranting).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>In summary, the ideas are: (1) adding authorization statements
to the statements that (2) a OP manages, and (3) let AX deliver them. (4) distinguish
machine authentication from user authentication, and (5) distinguish rest-services
openids from user openids.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>---------------------<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Henceforth, I'm only going to try and only use the term “SP”
in its OAUTH sense. I’ll stop using it in its SAML sense (here).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>If you see me use “RP”, it is a synonym for OpenID
Consumer of openid assertions. <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>---------------<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>First, Pat! What do you do with the public key of AC, recovered
from the OP? Note, below, I HAD to GUESS what you intended it to do.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I followed your text until the point where it said…
oh and no browser (or its driver/user) is involved :-) It made perfect sense WITH
a browser __user__ starting on AC, getting redirected to SP (by OAUTH), getting
redirected to OP.A by user-openid=consumer-key, completing user auth possibly
based on cookies, and redirected back to SP=RP. However, that’s not
right, Peter! Udner Pats model, we MUST think of OAUTH as a backroom webservice,
between 2 threads on two webserver machines.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> Application Consumer (AC)
in Domain A wants to communicate with<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> Service Provider (SP) in
domain B using OAuth.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> AC has not registered with
SP and has not exchanged a key/secret via<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> oob manual method (which
does not scale very well at the enterprise<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> level)<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> However, AC has registered
with OP in Domain A and has a profile that<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> contains its public key and
other info.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> SP gets the first OAUTH
message. AC has used its openid as its<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> consumer key. SP can
do openid discovery, authenticate AC and get<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> access to AC's public key
(and other info).<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> This is similar to what the
SP would do to grant access to users from<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>> domain B assuming that SP
now trusts OP from domain A.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>If one abuses checkid_immediate
a bit (by directly posting a REQ to the OP endpoint obtained from discovery) I _<i>can</i>_
see how ALL browsers and humans can be eliminated. Furthermore, it becomes
clear that the openid passed as the OAUTH consumer-key NOT that of a human
user, but it’s one attached to a machine “service” – the
“AC consumer” process itself.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>That is, a scheduler fires on AC
consumer host, which auto-starts OAUTH flow on some host process, which lands
at SP, where a thread starts openid discoveryflow, which is followed by a slightly-abused
checkid_immediate ping to the OP over a direct POST to OP endpoint learned via discovery.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>One obvious question is…
how does SP accomplish machine-authentication to OP (and thus get access rights
to pull the openid service’s AX profile, and the public key)?<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Let’s assume that that SP->OP
authentication happened (perhaps because SP performs SSL client cert auth procedures
with OP, say, where cert matches the public key value from the AX records attached
to a particular https URL endpoint at the OP, one per (service) openid URL)<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>What’s interesting is, once
the service’s AX profile is returned to the SP supported by an openid
positive assertion, you have the SP=RP site now do authorization/approval work
with a human user – but only if the OAUTH initiator supplied the user
openid URL. <o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>Though you don’t say it,
Im assuming that the SP does a second round of openid auth, now to that user’s
OP using checkid_immediate again, which completes the SMS procedures (in the
absence of browser cookies), and now releases the elements of the user’s AX
profile to the SP. These elements are per-subject authorization rights,
granting the SP authority to release and send back certain photos in some object-group,
to the subject=AC.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>The cycle is complete when the acls
are dynamically loaded into the trusted reference monitor of the SP, and enforces
… such that certain photos can returned to AC’s original call. Upon
receipt, the AC which does something with them, like print them.<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText>How did I do?<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText>> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> From: Pat Cappelaere [mailto:pat@cappelaere.com]<o:p></o:p></p>
<p class=MsoPlainText>> Sent: Tuesday, December 30, 2008 4:47 PM<o:p></o:p></p>
<p class=MsoPlainText>> To: Peter Williams<o:p></o:p></p>
<p class=MsoPlainText>> Cc: general@openid.net List<o:p></o:p></p>
<p class=MsoPlainText>> Subject: Re: [OpenID] CheckIDRequest with Big AX<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Let me try again to explain and keep the email short
for Dick.<o:p></o:p></p>
<p class=MsoPlainText>> Application Consumer (AC) in Domain A wants to
communicate with<o:p></o:p></p>
<p class=MsoPlainText>> Service Provider (SP) in domain B using OAuth.<o:p></o:p></p>
<p class=MsoPlainText>> AC has not registered with SP and has not exchanged
a key/secret via<o:p></o:p></p>
<p class=MsoPlainText>> oob manual method (which does not scale very well at
the enterprise<o:p></o:p></p>
<p class=MsoPlainText>> level)<o:p></o:p></p>
<p class=MsoPlainText>> However, AC has registered with OP in Domain A and
has a profile that<o:p></o:p></p>
<p class=MsoPlainText>> contains its public key and other info.<o:p></o:p></p>
<p class=MsoPlainText>> SP gets the first OAUTH message. AC has used
its openid as its<o:p></o:p></p>
<p class=MsoPlainText>> consumer key. SP can do openid discovery,
authenticate AC and get<o:p></o:p></p>
<p class=MsoPlainText>> access to AC's public key (and other info).<o:p></o:p></p>
<p class=MsoPlainText>> This is similar to what the SP would do to grant
access to users from<o:p></o:p></p>
<p class=MsoPlainText>> domain B assuming that SP now trusts OP from domain
A.<o:p></o:p></p>
<p class=MsoPlainText>> The difference here is that no browsers are
involved.<o:p></o:p></p>
<p class=MsoPlainText>> The idea is for SP to do a straight post
(checkid_immediate with AX)<o:p></o:p></p>
<p class=MsoPlainText>> to OP and get the data back as XML or json or
whatever. I made the<o:p></o:p></p>
<p class=MsoPlainText>> assumption that services always grant access to
their profile.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Having done that, imagine that the user openid is
also passed within<o:p></o:p></p>
<p class=MsoPlainText>> that OAuth message. SP can ask the user if he
authorizes AC to access<o:p></o:p></p>
<p class=MsoPlainText>> resources on his behalf via SMS. User answers
using his IPhone (of<o:p></o:p></p>
<p class=MsoPlainText>> course) since he is in the field.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> This makes a consistent mental model for the role of
the OP. Users<o:p></o:p></p>
<p class=MsoPlainText>> and services can have openids and use it for
authentication and<o:p></o:p></p>
<p class=MsoPlainText>> provide access to "certifiable"
information for others.<o:p></o:p></p>
<p class=MsoPlainText>> Once 2 domains agree to open the gates, services can
be accessed with<o:p></o:p></p>
<p class=MsoPlainText>> no effort (manual registration, token management...)
across domains.<o:p></o:p></p>
<p class=MsoPlainText>> All of a sudden, a California firefighter can have
access to satellite<o:p></o:p></p>
<p class=MsoPlainText>> tasking at NASA and get imagery on short notice.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Another great benefit is that If user grants are
maintained by the<o:p></o:p></p>
<p class=MsoPlainText>> local OP, users have only one place to go to for
revocation.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> It is actually a very small burden on the OP but
really simplifies the<o:p></o:p></p>
<p class=MsoPlainText>> work of the AC and SP in a RESTful way.
Alternative is to use SOAP<o:p></o:p></p>
<p class=MsoPlainText>> and WS-* stack and it is not a very appealing one
for our market.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> I feel like this deserves more explanation but this
email is long<o:p></o:p></p>
<p class=MsoPlainText>> enough.<o:p></o:p></p>
<p class=MsoPlainText>> Hope this works.<o:p></o:p></p>
<p class=MsoPlainText>> Thanks again.<o:p></o:p></p>
<p class=MsoPlainText>> Pat.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> On Dec 30, 2008, at 6:23 PM, Peter Williams wrote:<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> > Pat<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > To communicate with the OP, is your SP app
returning HTML to the<o:p></o:p></p>
<p class=MsoPlainText>> > browser, whose javascript auto-posts the
check_immediate REQ message<o:p></o:p></p>
<p class=MsoPlainText>> > over to the OP?<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > If you are, any request for a particular content
type (e.g. json) to<o:p></o:p></p>
<p class=MsoPlainText>> > be returned to you would have to happen in the
REQ fields in the<o:p></o:p></p>
<p class=MsoPlainText>> > checkid_immediate() openid message (to be
interoperable). I'm not<o:p></o:p></p>
<p class=MsoPlainText>> > sure there is any such request field.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > It's likely if you auto-posted the request thru
the browser to the<o:p></o:p></p>
<p class=MsoPlainText>> > OP, the OP will auto-post a (largish) RESP back
through the browser<o:p></o:p></p>
<p class=MsoPlainText>> > relay to the SP.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > If the browser is indeed properly in the comm's
loop (just as a<o:p></o:p></p>
<p class=MsoPlainText>> > relaying system doing 2 auto-posts), by the
time the relaying-<o:p></o:p></p>
<p class=MsoPlainText>> > browser has interpreted the javascript to
autopost the intermediate-<o:p></o:p></p>
<p class=MsoPlainText>> > form content over to your SP, your consumer
servlet should be<o:p></o:p></p>
<p class=MsoPlainText>> > receiving a clean POST block.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > I think folks maybe concerned that you may not
be using the browser<o:p></o:p></p>
<p class=MsoPlainText>> > correctly as a message "relaying"
device. The nature of the security<o:p></o:p></p>
<p class=MsoPlainText>> > model of checkid_immediate is such that the
browser-based foreground<o:p></o:p></p>
<p class=MsoPlainText>> > channel MUST be involved (to be conforming).
There is still no<o:p></o:p></p>
<p class=MsoPlainText>> > unanimity one the question that the human need
not be interactively<o:p></o:p></p>
<p class=MsoPlainText>> > involved, tho.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > ARGUABLY, if the SP thread on the webserver can
100% impersonate the<o:p></o:p></p>
<p class=MsoPlainText>> > user/browser properly, it could act in an
essentially non-conforming<o:p></o:p></p>
<p class=MsoPlainText>> > manner BUT expect to successfully interact with
an OP to get a RESP<o:p></o:p></p>
<p class=MsoPlainText>> > - when directly communicating with the OP's
endpoint (avoiding the<o:p></o:p></p>
<p class=MsoPlainText>> > browser relay). Obviously, the OP could still
quite properly send an<o:p></o:p></p>
<p class=MsoPlainText>> > autopost-format form as RESP, since in a
conforming system one would<o:p></o:p></p>
<p class=MsoPlainText>> > expect a browser relay to be involved. As the
SP is impersonating<o:p></o:p></p>
<p class=MsoPlainText>> > the user, it can obviously decode either of the
RESP encodings, much<o:p></o:p></p>
<p class=MsoPlainText>> > as a browser would when acting as relay.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > This all reminds me of a secure payment
protocol called SET (which<o:p></o:p></p>
<p class=MsoPlainText>> > assumed a plugin in the browser). As that
proved to be very hard to<o:p></o:p></p>
<p class=MsoPlainText>> > deploy/adopt, vendors eventually started
offering server-side SET,<o:p></o:p></p>
<p class=MsoPlainText>> > where the webserver would impersonate the users
and perform the<o:p></o:p></p>
<p class=MsoPlainText>> > client protocol remotely. Drove the original
standard designers<o:p></o:p></p>
<p class=MsoPlainText>> > (including me) nuts, till it "worked"
and worked "effectively".<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> >> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> >> From: general-bounces@openid.net
[mailto:general-<o:p></o:p></p>
<p class=MsoPlainText>> >> bounces@openid.net] On<o:p></o:p></p>
<p class=MsoPlainText>> >> Behalf Of Pat Cappelaere<o:p></o:p></p>
<p class=MsoPlainText>> >> Sent: Tuesday, December 30, 2008 2:41 PM<o:p></o:p></p>
<p class=MsoPlainText>> >> To: Martin Atkins<o:p></o:p></p>
<p class=MsoPlainText>> >> Cc: general@openid.net List<o:p></o:p></p>
<p class=MsoPlainText>> >> Subject: Re: [OpenID] CheckIDRequest with
Big AX<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> Martin,<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> I have been able to coerce my OP to do
almost what I needed.<o:p></o:p></p>
<p class=MsoPlainText>> >> I submitted my consumer openid, did the
discovery and forced a POST<o:p></o:p></p>
<p class=MsoPlainText>> >> checkid_immediate with AX.<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> The server responded with the data I wanted
but in the wrong output<o:p></o:p></p>
<p class=MsoPlainText>> >> format. It did not detect that I had
done a POST and tried to<o:p></o:p></p>
<p class=MsoPlainText>> >> returned to me the body of that stupid
intermediate form thinking<o:p></o:p></p>
<p class=MsoPlainText>> >> that<o:p></o:p></p>
<p class=MsoPlainText>> >> it would overflow a GET. But close.<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> So, could I suggest an additional attribute
that could tell the OP<o:p></o:p></p>
<p class=MsoPlainText>> >> what my preferred output format might be:
xml, json... when in non-<o:p></o:p></p>
<p class=MsoPlainText>> >> browser mode?<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> example: openid.format= xml | json<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> Pat.<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >> On Dec 30, 2008, at 4:57 PM, Martin Atkins
wrote:<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >>> Pat Cappelaere wrote:<o:p></o:p></p>
<p class=MsoPlainText>> >>>> Dick,<o:p></o:p></p>
<p class=MsoPlainText>> >>>><o:p></o:p></p>
<p class=MsoPlainText>> >>>> So I can only do a
"checkid_immediate" request with AX as long as<o:p></o:p></p>
<p class=MsoPlainText>> >> the<o:p></o:p></p>
<p class=MsoPlainText>> >>>> AX request is not tool large?<o:p></o:p></p>
<p class=MsoPlainText>> >>>> Isn't it limiting?<o:p></o:p></p>
<p class=MsoPlainText>> >>>><o:p></o:p></p>
<p class=MsoPlainText>> >>><o:p></o:p></p>
<p class=MsoPlainText>> >>> checkid_immediate still expects the
user to be in the loop, since<o:p></o:p></p>
<p class=MsoPlainText>> >>> the<o:p></o:p></p>
<p class=MsoPlainText>> >>> provider will often need to verify
cookies.<o:p></o:p></p>
<p class=MsoPlainText>> >>><o:p></o:p></p>
<p class=MsoPlainText>> >>> Likewise, checkid_immediate can (in
theory, at least) be done via a<o:p></o:p></p>
<p class=MsoPlainText>> >>> form-initiated POST request if the
request is too large for a GET.<o:p></o:p></p>
<p class=MsoPlainText>> >>><o:p></o:p></p>
<p class=MsoPlainText>> >>>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>> >>> general mailing list<o:p></o:p></p>
<p class=MsoPlainText>> >>> general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> >>>
http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText>> >><o:p></o:p></p>
<p class=MsoPlainText>> >>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>> >> general mailing list<o:p></o:p></p>
<p class=MsoPlainText>> >> general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> >> http://openid.net/mailman/listinfo/general<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
</div>
</body>
</html>