[OpenID] Purpose of OpenID Foundation and the Elections

Peter Williams pwilliams at rapattoni.com
Fri Dec 12 01:48:35 UTC 2008


What I heard there Martin was:-

Since there is a crypto association between the parties, one can now exchange any message one wants - and thus openid is any protocol you like (since the openid is just like SSL - an authenticated bearer - ready to be applied to problem X).

Now, On revocation and micro-governance (for example, the recall of capabilities etc), on might consider using DRM techniques, now increasingly repurposed for micro-governing transactions rather than drivers and music loading. This is getting quite hot: viz Microsoft and RSA investments in the area.

I'm supportive, Martin! The scope of openid3 should leave behind its roots in user auth, reg and attribute queryies -  and migrate to being a general security architecture - enacted through the easy-flexibility of the application layer and really go at now fully exploiting URL-based routing.

-------

It will be interesting to see the new crypto split, that openid2/yadis over ssl portends. Whereas today, one conceives the world in terms of IPSEC + SSL + signedAPDUs, topology-based security concepts are already evolving that stack-based conception. Already in the multicast/wifi/voip/atm world, we have standard multicast key management suited to connectionless integrity and confidentiality crypto mechanism. With the likes of DVRP resolution now scaling up nicely, MPLS VPNs are now allowing n private routing domains (augmented with IPsec where useful) to provide n trust fabrics - logically linking OPs and SP into trust networks as  function of internet3.

Ideally, the likes of openid3 will eliminate SSL as we know it (a transport layer construct) ... putting its function up at the app layer, where the role played today by the  socket/IPaddress/DNS will be played by URL re-routing. In many ways, DanSimon @MSFT already did this, with EAP, but never applied it to web signalling.

What openid3 "really" needs is some topnotch crypto engineers who know how to design decent handshakes where the key management facilitates the (scalable) trust fabric concepts, given above. Then you have any application semantics you want, and all the control practices anyone could ever want, in any trust network expressible as a routing graph!


 -----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Martin Atkins
Sent: Thursday, December 11, 2008 5:28 PM
Cc: general at openid.net List
Subject: Re: [OpenID] Purpose of OpenID Foundation and the Elections

Pat Cappelaere wrote:
> Nice promise.
> I would love to extend it one step further:
> The data is mine. If I authorize an application to access it on my
> behalf, application can then get it.  And I can revoke that grant...
> and dispute access...  This is OpenID + OAuth which will now authorize
> transactions between services.  Very close to the VISA experience
> actually.  This would not be very hard to implement since most of the
> infrastructure is already in place.  No reason for providers to
> implement it on their own and do it wrong and provide another bad user
> experience.
>

It's important to be clear about what you mean by revoking access to the
data.

Information, by its very nature, cannot be "taken back". Once you tell
someone something, you can't un-tell them. You can choose not to give
them new information, of course, but they will still know what you told
them to start with.

Facebook's Platform attempts to work around this using legal agreements
in the form of agreeing to the terms of service, which put restrictions
on what client applications are allowed to "store". (Whether all
application developers comply with this in practice is unclear.)

VISA of course has similar contractual arrangements with card providers
and merchants, but their framework is far stronger than ticking a box to
agree to a terms of service, and I assume involves those involved
agreeing to allow auditing to ensure compliance.

OpenID as it exists today does not have the legal framework necessary to
support this sort of assurance, and some would argue that the "anyone
can play" architecture is in fact fundamentally incompatible with such.

Of course, this can be mitigated somewhat by being careful what you
promise. No-one is claiming that today's OpenID allows you to "take
back" information you've previously supplied, it simply aims to make it
easier for you to provide the information you *want* to provide.

The question is of course whether that is a useful value proposition or
whether OpenID needs to do better.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general



More information about the general mailing list