[OpenID] Windows Live ID OpenID CTP Status Update (August 2009)

[John Bradley]

The conversation seems to have moved from using SSL client auth to  
deliver a pointer to authentication information,  to using the  
signature over a file at a URL to prove control over the URL.

The notion of using a signed document in combination with the user  
being able to prove possession of the private key has come up a number  
of times.

Prior to XRI and openID making peace,  signed XRDS documents where  
considered along with SAML  as possible authentication alternatives.

It may be an interesting conversation, and perhaps a good idea,  but  
is it openID?

One thing we do lack is a consensus on what openID is other than a  
redirect based protocol with a symmetric shared secret between the OP  
and RP per the openID 2.0 spec.

That is perhaps one of the things slowing us down moving to openID 2.1.

Should openID 2+ be broadly defined as anything that lets a user prove  
control of a URI resource?

I have played with using information cards and signed XRD to achieve a  
similar effect to ssl+fof,

Andrew Arnott built a proof of concept that let a user with a personal  
information card assert a openID transparently to the dotNetoOenAuth  
library.  It worked great and was truly user centric no OP required.

There are a lot of things that could be done,  but until we decide  
some things about what openID is it will be more difficult to make  
progress.

So a good first question to tackle is should asymmetric cryptography  
RSA/ECDSA be a part of the core spec.

If the answer continues to be no then it takes a bunch of options off  
the table.

I think the answer for extensions like CX and secure discovery may  
well be different than for the core spec.

I am interested in what people thing openID is or should be going  
forward.

John B.

On 30-Aug-09, at 4:29 PM, Peter Williams wrote:

>
>
>
> http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
>
> When the user logs into such an OpenId provider using foaf+ssl, the OP
> having fetched the foaf file to verify identity, find the openid in
> that graph, then gets the openid page and verifies that it points to
> the foaf file as well as to the OP.
>
>
> Now that’s cute, because the second half is really only a minor  
> variation of what OPs and RPs do today (using HTML metatags and  
> XRD.SEP.localids for cross-domain name mapping). It goes a bit  
> further in the first half, as it also address user auth (by  
> providing a basis for accepting the SSL layers of assertion of  
> uncertified public key as one that actually binds to a webid, that  
> implies an openid, which an OP may now release to the RP as a  
> claimed identifier). (*)
>
> But also note how different it was in application to my conception.  
> I had the foaf+ssl talking to the RP rather than the OP (where the  
> RP which would do all the various mappings, resolvings, and  
> verifying). I shifted the control point (back the way it was in the  
> openid1 world), turning the OP into just one of several transitory  
> intermediaries on the message relay path that separates me the RP  
> from you the user.
>
> Now the nice thing is, that I think both controls models work; and  
> neither excludes the other. Either RP or OP can be applying this  
> sort of thing, or BOTH can. Thus, we address the balance of power  
> issue, addressing the issue of dependency becomes a barrier to  
> adoption. One gets around the confidence problem of dependency,  
> because as an RP one now has built in resilience to failure, and the  
> expectation that of course the RP can ALSO challenge the user  
> directly (using its own run of foaf+ssl).
>
>
> Peter.
>
>
> (*) rather than have a third-party sign the foaf file, I’d still  
> like the ssl layer (at RP) to be verifing the digest of the foaf  
> file referenced by the webid (where the hash is in some of other  
> field of the client cert, tied to that foaf file). In this way, the  
> whole system is one of essentially one of an ssl-based, self- 
> assertion of an authenticated foaf file to the RP (making things  
> akin to a self-asserted infocard).
>
>

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