[OpenID] Making Deployers Choose (was: Real Identity Verification)

[Peter Williams]

I dont see much future in idp-centric federations in web2.0, to be honest -  which is where I feel Shib's design is biased. Of the various models, openid tends more to sp-centric federations, where ax update promotes what  SAML calls sp-affiliations.

Where we can agree about the future adoption, probably, is where openidauth must improve so as to providea more rigorous foundation for Nat's protocols - making "battle of the terms" assertions (and meta-assertions(due to the protocol)).

If an openid auth extension is to deliver proof of acceptance, the underlying openid auth bearer protocol has to have bidirectional "intended recipient" security controls- where the protocol remotely enforces the controlled release requirements. Typically, this is done with crypto and key management - which provided the proof security services/mechanisms. Rather than every extension invent its own controlled release crypto, this CORE service needs to be in the foundation.AS we see in Nat's technical design, its easy to use crypto 101 intuitively (just RSA encrypt a symmetric key!) rather  than use more trusted crypto **controls** which add and REMOTELY enforce symmetric key type-tagging.

Fun to compare ssl to openid auth.

SSL (connection/bearer) won over IPSEC (connectionless). Layer 4 vs layer 3

OpenID (association/bearer) may win over SAML (connectionless/messaging). Layer 7vs 5

Of course, cisco are winning all, since their MPLS "layer 2.5" solution is making virtual WANs/stacks, these days!

From: Nate Klingenstein [mailto:ndk at internet2.edu]
Sent: Tuesday, November 04, 2008 4:52 AM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] Making Deployers Choose (was: Real Identity Verification)

Peter,

I fully agree today, but I want the statement "OpenID is different to Shibboleth" to be fundamentally wrong in the future.  I want the statement, "your deployment can use trusted, managed identity sources, or take all comers, with the software of your choice" to be true instead.  Deployers shouldn't be asked to select between protocols and non-interoperable software packages.  That's our collective failure as an identity community.  They should just pick the implementation, trust, UX, and privacy rules that support their needs the best, and it should work with the implementations others have.

Shibboleth has been battling non-interoperability with SAML vendors very hard, and we all finally made some progress.  Google's OAuth work and CardSpace are trying to bring everything together, and Shibboleth can support much of both already.  Adding trust to OpenID is another good step.

Convergence ain't just an 11-letter word.  It's our duty to our users and deployers.
Nate.

On 4 Nov 2008, at 12:36, Peter Williams wrote:


OpenID is different to Shibboleth. OpenID brings the likes of Yahoo and Google assertions to RPs (just like us). I don't WANT to manage the 6 million consumers who come to our website, anymore than I want to manage their email boxes. Let ads (on other people's sites) pay for all that!


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