[OpenID] CheckIDRequest with Big AX

Wed Dec 31 04:35:25 UTC 2008

Ok

Im pretty sure you are proposing that for the openids attached to services, the OP for services is acting as a _public_ (AX) directory of service openids (and their various AX attributes including the entities public key). The SP is not required to complete its "user" auth, to access _service_ openid AX recordsets (over https).

I think you will find that the public key has to itself be stored in a form that is signed by a third party, as a certificate. Otherwise, you are going to hit entity spoofing problems. There are rules you have to follow when making RSA signed assertions, to avoid entity spoofing.

Once the SP has from the OP a trustworthy public key for AC, however, then yes it can verify an RSA signature on the original OAUTH request that AC used to propose the consumer-key=service-openid (and the user openid) claims.

Yes, given that signature, the SP can trust AC to be asserting (in that signed request) that user openid and service openids are related (as acl-subject and intended-recipient).

Yes, if the SP now talks to the user's OP, AND the user authenticates (via SMS), then the SP can bind its subject role to user openid. It can also learn ACLs stored by user at OP from an AX REQ, authorizing subject=user to access objects at SP (*) providing they are only released to intended-recipient AC.

But this is all VERY contingent on the human user recognize the phone number of the SMS page, as coming from the user's  OP. (There is no browser initiating context, display and feedback, remember, in contrast to how myopenid/phonefactor do phone callbacks, today).

I suspect its not viable yet, as is. Just getting OAUTH to sign its messages, and register its certified public keys in an AX repository would be a small miracle in its own right, I suspect. But it's a start, in public. Let's wait - and see what the private Yahoo technical counter-proposal is, once they are ready to announce it. Then we can all figure what all the various issues really are, and reflect.

So which bits did you actually build?

-----------

(*) It's not clear how one identifies a particular SP, in the ACL. One way would be to use a SSL certid of the https endpoint of the SP, but that has lifecycle issues. SSL Cert lifecycles are unlikely to align well with ACL lifeycles.

> -----Original Message-----
> From: Pat Cappelaere [mailto:pat at cappelaere.com]
> Sent: Tuesday, December 30, 2008 7:36 PM
> To: Peter Williams
> Cc: general at openid.net List
> Subject: Re: [OpenID] CheckIDRequest with Big AX
>
> Peter,
>
> I will respond here as I can rather than inline since it might get
> more convoluted.
>
> #1.  What do you do with the public key of AC, recovered from the OP?
>         I use it as the shared secret to validate the digital signature
> and
> make sure the message has not been tampered with.  I would then be
> fairly sure that it came from AC.
>
> #2  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)?
>         Good one.  At registration time, AC grants access to all bu
> default.
> SP then can verify that AC is a valid application registered to the OP
> (which he has been told to trust).  The signature matched using the
> public key so I can assume that it really came from the AC.  Then I
> can go to talk to the user.
>
> Everything else seems right in a nutshell :) at least to me.
> Firefighter can get his imagery once the workflow completes its many
> interactions...and put out the fire.
>
> I hope that I am not stretching out too far the limits of the current
> protocol.  Would great to make this work.
> Thanks again.
> Pat.
>
> On Dec 30, 2008, at 9:48 PM, Peter Williams wrote:
>
> > 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
> >
> >