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

[John Bradley]

Interesting,

However I suspect that there are more people on this list who think a  
openID RP should be able to be deployed in a virtual hosting  
environment without SSL or any access to that layer.

With the current state of openID SSL integration I have been having a  
challenge trying to get OPs not to negotiate the null cypher for  
associations.

Anything could be done,  however would it still be openID?

John B.
On 31-Aug-09, at 2:44 PM, Peter Williams wrote:

>
>
> From: John Bradley [mailto:john.bradley at wingaa.com]
> Sent: Sunday, August 30, 2009 2:06 PM
> To: Peter Williams
> Cc: Story Henry; John at osuosl.org; openid-general at lists.openid.net
> Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update  
> (August 2009)
>
> 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.
>
>
> 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.
>
> That which folks could not do to enhance SSL itself  for websso  
> (because of the way IETF works, and who runs/influences the  
> contributors/editors of that forum), I see openid as having done  
> through market forces. Openid is to me an enhanced session manager  
> for ssl sessionids, with the added value of discovery and  
> authorization controls – that allow multiple “SSL connections” to be  
> proxied UNDER policy control (rather than ad-hoc http proxy/connects  
> that just fashioned a MITM space).
>
> Now, the deployed SSL would need to be unhooked from the https-level  
> de-facto policy of tying trust to the DNS – which is currently  
> partially governing end-end connection policie (under ideas from 15  
> years ago (that have not moved forward one iota)).
>
> So, just as facebook have treated openid as a hidden protocol under  
> a UX flow (using only a slice of the protocol furthermore to do  
> machine-machine signalling), so one can continue the trend, working  
> towards openid supporting machine-machine authentication for web  
> services, etc. This obviously leaves behind the restriction of  
> openid as being ONLY a foreground protocol, addressing UCI, privacy,  
> control and all the other in-your face issues.
>
> So, the more the SSl handshake/event-handlers and openid state  
> machines merge, the better. Then, a market will emerge for hardware  
> that can do NAT/load-balancer offloading of https/openid today, just  
> as the same switches now do multi-gigabit/s ssl offloading and  
> proxing.
>
> If the same trends were also to be incorporating the yet more  
> powerful foaf+ssl ideas (which are admittedly 3-4 behind the  
> adoption curve of openid2), those switches would able to set to do  
> what many used to think of secure XML routers doing (the so-called  
> AOS devices, from the likes of HP and Intel). But rather than do it  
> with messages, one would be doing it with sessions – which we know  
> has proven itself a scalable winner for fast hardware. But those  
> sessions would now have inferecing based routing – which takes us  
> above and beyond the dynamic routing regimes of the internet  
> backbones and into true virtual routing.
>
> If one goes with this trend analysis, yes public key is part of  
> openid, but through an ever tighter association with the SSL  
> handshake and event handlers, not because openid does an  
> alternative( relatively crappy) job of repeating what SSL does so  
> well.
>
> There were attempts to add certain NR-features to openid, that  
> unfortunately got caught up in patent issues. But, many folks see a  
> need for SSL to ALSO allow the servers behind the loadbancer  
> offloaders to retain  a measured of crypto-level relationship to the  
> client. Here, again, I suspect openid could be adding that something  
> back to SSL (and be doing something useful without getting into the  
> patented areas).
>
> If one accepts any of the above, then yes CX and secure discovery  
> are simply using this “new https” as a bearer, and openid  
> “extensions” are to such an ssl+openid-bearer what https apps are to  
> the SSL record layer today – consumers of generic session-oriented  
> security services. But, the https layer has moved on a generation.

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