[OpenID] CheckIDRequest with Big AX

Wed Dec 31 00:46:32 UTC 2008

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