[OpenID] CheckIDRequest with Big AX

Wed Dec 31 02:48:06 UTC 2008

Delete now, folks - unless one is interested in a discussion of Pat's application of openid. (There is little or no ranting).

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.

---------------------

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).

If you see me use "RP", it is a synonym for OpenID Consumer of openid assertions.

---------------

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.

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.

> Application Consumer (AC) in Domain A wants to communicate with

> Service Provider (SP) in domain B using OAuth.

> AC has not registered with SP and has not exchanged a key/secret via

> oob manual method (which does not scale very well at the enterprise

> level)

> However, AC has registered with OP in Domain A and has a profile that

> contains its public key and other info.

> SP gets the first OAUTH message.  AC has used its openid as its

> consumer key.  SP can do openid discovery, authenticate AC and get

> access to AC's public key (and other info).

> This is similar to what the SP would do to grant access to users from

> domain B assuming that SP now trusts OP from domain A.

If one abuses checkid_immediate a bit (by directly posting a REQ to the OP endpoint obtained from discovery) I _can_ 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.

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.

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)?

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)

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.

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.

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.

How did I do?

> -----Original Message-----

> From: Pat Cappelaere [mailto:pat at cappelaere.com]

> Sent: Tuesday, December 30, 2008 4:47 PM

> To: Peter Williams

> Cc: general at openid.net List

> Subject: Re: [OpenID] CheckIDRequest with Big AX

>

> Let me try again to explain and keep the email short for Dick.

> Application Consumer (AC) in Domain A wants to communicate with

> Service Provider (SP) in domain B using OAuth.

> AC has not registered with SP and has not exchanged a key/secret via

> oob manual method (which does not scale very well at the enterprise

> level)

> However, AC has registered with OP in Domain A and has a profile that

> contains its public key and other info.

> SP gets the first OAUTH message.  AC has used its openid as its

> consumer key.  SP can do openid discovery, authenticate AC and get

> access to AC's public key (and other info).

> This is similar to what the SP would do to grant access to users from

> domain B assuming that SP now trusts OP from domain A.

> The difference here is that no browsers are involved.

> The idea is for SP to do a straight post (checkid_immediate with AX)

> to OP and get the data back as XML or json or whatever.   I made the

> assumption that services always grant access to their profile.

>

> Having done that, imagine that the user openid is also passed within

> that OAuth message.  SP can ask the user if he authorizes AC to access

> resources on his behalf via SMS.  User answers using his IPhone (of

> course) since he is in the field.

>

> This makes a consistent mental model for the role of the OP.  Users

> and services can have openids and use it for authentication and

> provide access to "certifiable" information for others.

> Once 2 domains agree to open the gates, services can be accessed with

> no effort (manual registration, token management...) across domains.

> All of a sudden, a California firefighter can have access to satellite

> tasking at NASA and get imagery on short notice.

>

> Another great benefit is that If user grants are maintained by the

> local OP, users have only one place to go to for revocation.

>

> It is actually a very small burden on the OP but really simplifies the

> work of the AC and SP in a RESTful way.  Alternative is to use SOAP

> and WS-* stack and it is not a very appealing one for our market.

>

> I feel like this deserves more explanation but this email is long

> enough.

> Hope this works.

> Thanks again.

> Pat.

>

> On Dec 30, 2008, at 6:23 PM, Peter Williams wrote:

>

> > Pat

> >

> > To communicate with the OP, is your SP app returning HTML to the

> > browser, whose javascript auto-posts the check_immediate REQ message

> > over to the OP?

> >

> > If you are, any request for a particular content type (e.g. json) to

> > be returned to you would have to happen in the REQ fields in the

> > checkid_immediate() openid message (to be interoperable). I'm not

> > sure there is any such request field.

> >

> > It's likely if you auto-posted the request thru the browser to the

> > OP, the OP will auto-post a (largish) RESP back through the browser

> > relay to the SP.

> >

> > If the browser is indeed properly in the comm's loop (just as a

> > relaying system doing 2 auto-posts), by the time the relaying-

> > browser has interpreted the javascript to autopost the intermediate-

> > form content over to your SP, your consumer servlet should be

> > receiving a clean POST block.

> >

> > I think folks maybe concerned that you may not be using the browser

> > correctly as a message "relaying" device. The nature of the security

> > model of checkid_immediate is such that the browser-based foreground

> > channel MUST be involved (to be conforming). There is still no

> > unanimity one the question that the human need not be interactively

> > involved, tho.

> >

> > ARGUABLY, if the SP thread on the webserver can 100% impersonate the

> > user/browser properly, it could act in an essentially non-conforming

> > manner BUT expect to successfully interact with an OP to get a RESP

> > - when directly communicating with the OP's endpoint (avoiding the

> > browser relay). Obviously, the OP could still quite properly send an

> > autopost-format form as RESP, since in a conforming system one would

> > expect a browser relay to be involved. As the SP is impersonating

> > the user, it can obviously decode either of the RESP encodings, much

> > as a browser would when acting as relay.

> >

> > This all reminds me of a secure payment protocol called SET (which

> > assumed a plugin in the browser). As that proved to be very hard to

> > deploy/adopt, vendors eventually started offering server-side SET,

> > where the webserver would impersonate the users and perform the

> > client protocol remotely. Drove the original standard designers

> > (including me) nuts, till it "worked" and worked "effectively".

> >

> >

> >> -----Original Message-----

> >> From: general-bounces at openid.net [mailto:general-

> >> bounces at openid.net] On

> >> Behalf Of Pat Cappelaere

> >> Sent: Tuesday, December 30, 2008 2:41 PM

> >> To: Martin Atkins

> >> Cc: general at openid.net List

> >> Subject: Re: [OpenID] CheckIDRequest with Big AX

> >>

> >> Martin,

> >>

> >> I have been able to coerce my OP to do almost what I needed.

> >> I submitted my consumer openid, did the discovery and forced a POST

> >> checkid_immediate with AX.

> >>

> >> The server responded with the data I wanted but in the wrong output

> >> format.  It did not detect that I had done a POST and tried to

> >> returned to me the body of that stupid intermediate form thinking

> >> that

> >> it would overflow a GET.  But close.

> >>

> >> So, could I suggest an additional attribute that could tell the OP

> >> what my preferred output format might be: xml, json... when in non-

> >> browser mode?

> >>

> >> example: openid.format= xml | json

> >>

> >> Pat.

> >>

> >> On Dec 30, 2008, at 4:57 PM, Martin Atkins wrote:

> >>

> >>> Pat Cappelaere wrote:

> >>>> Dick,

> >>>>

> >>>> So I can only do a "checkid_immediate" request with AX as long as

> >> the

> >>>> AX request is not tool large?

> >>>> Isn't it limiting?

> >>>>

> >>>

> >>> checkid_immediate still expects the user to be in the loop, since

> >>> the

> >>> provider will often need to verify cookies.

> >>>

> >>> Likewise, checkid_immediate can (in theory, at least) be done via a

> >>> form-initiated POST request if the request is too large for a GET.

> >>>

> >>> _______________________________________________

> >>> general mailing list

> >>> general at openid.net

> >>> http://openid.net/mailman/listinfo/general

> >>

> >> _______________________________________________

> >> general mailing list

> >> general at openid.net

> >> http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081230/bc28a2f9/attachment-0002.htm>