[OpenID] CheckIDRequest with Big AX

[Pat Cappelaere]

Peter,

On Dec 30, 2008, at 11:35 PM, Peter Williams wrote:

> 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.
>
it would likely be self-signed following similar directions per http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html

> 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).
Yes.  User ought to recognize the phone number.  He will receive SMS  
message with a short url.  Short url would point to a page describing  
the request like:
Consumer: http://consumer.example.com is requesting access to  
resources (#scope) on provider: http://provider.example.com
Enter: code to authorize
(we can also do it by voice too)
>
> 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.
>
Can't really wait for Yahoo or Google as this is a federated identity  
system.  Every organization will eventually have its own OP, maintain  
user identities and roles... Google is actually doing something fairly  
close.  That's where I got some of the ideas from.

> So which bits did you actually build?
>
All of it.  Experimental OP will be deployed in a few days with XMPP,  
SMS support (Tatango).
I will customize the EO-1 Sensor Planning Service (as an SP) and a  
Workflow Engine as an AC.  We also hope to have many other workflow  
engines in various other domains to participate.

> -----------
>
>
> (*) 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.
Would be nice to use the same way.  SP has an openid and entry in its  
own OP and its own public key...
Pat.
>
>