[OpenID] User-editable XRDS files?

Sun Feb 8 17:44:19 UTC 2009

I think we can try to connect 4 older threads with the hash-tree concept:

1.      paypal adding trust to specifically financial transactions,
2.      CX/TX addressing trust networking and contracting moments,
3.      vanity XRDS file hosting so users control https flows and obtain openid portability, and
4.      https OpenIDs and https/http redirecting during discovery.

In

> Sent: Saturday, February 07, 2009 4:11 PM
> To: shibboleth-users at internet2.edu
> Cc: general at openid.net
> Subject: Re: [OpenID] [Shib-Users] SAML 1.0 Browser POST Profile

I pointed to the nice summary about some patented (and non patented) hash tree/chain technologies targeting the infrastructure supporting financial transactions, http://www.fwsudia.com/bhtpap2c.pdf - technologies that augment https resolution, and specifically augment  type of discovery-focussed resolution that lies at the heart of URL-based OpenID.

In that resource, we learned how various types of https sever certificates (or other, equivalent certification-grade assertions) can authenticate an entire data mesh through reverse hashing. That is: having authenticated the root of a hash chain/tree, a billion other objects can be easily & _selectively_ origin-authenticated to any number of relying parties...once an assertion/ssl handshake has bootstrapped trust in the rendezvous point (the user's vanity XRDS at a vanity XRI/URL). Military folks have applied similar ideas for years to deliver massively scalable sparse-mode, multicast symmetric key management (allowing connectionless, per-packet wire-speed re-keying over ATM/FR/X.25, with different key streams per multicast source and per multicast group).

As the thrust of the openid security context is between user and RP (where OPs and XRI/XDI providers of vanity openid/XRDS are merely "facilitators" rather than 'control points" [in contrast to the world conceived by SAML websso]), when we add a billion vanity XRDS files managed directly by users into the mix, we have to ensure that RPs can authenticate the XRDS file is owned by the user. In assurance language, we would say: ensure that openid discovery 2.0 verifies that the vanity openid/XRI is truly bound to the XRDS when resolving the vanity openid/XRI. Perhaps https and hash-chains helps, here!

Given we are designing specifically for a UCI threat environment, perhaps we also take David Fuelling's MultiAuth proposal and together with the very UCI properties now let user's mandate that RPs "confirm" that they are able to obtain the same hash chain/tree roots for certain data meshes from the AX fields communicated by _several_ OPs, given the same vanity https openid input. Collusion amongst several international OPs operating in different political systems to subvert that channel would appear harder to arrange per user. Subverting that would be much harder than inducing one of a few commercial mega-OPs to become a rogue assurer. (It's easy to imagine the Google OP acting under secret order to server some host-government's disinformation agent ..actively trying to pollute/compromise the keystreams for a given user ...or national group of web users. It's much harder to imagine that happening effectively (and undetectably to the user) in a coordinated manner across the web, tho).

If we can build the self-standing channel between user and RP leveraging OPs etc and do it in a manner that counters the threat of a rogue OP, then the vanity https openids whose server certs facilitate the bootstrapping now have a solid reasons to exist and produce very concrete benefits that go beyond the original https URI semantics:

*       the user's XRDS controls the UCI portability properties through delegation,
*       the scalability of a billion vanity XRDS is not in question,
*       users can now mandate use of OP https endpoints and end-end https
*       the signature on the user's XRDS can be dynamically attached for RPs to verify using merely an xmldsig extension (where the signature is not RSA but the hash tree nodes), and
*       the RP gets to initiate openid auth over the OP's https channels (setting the oblitaation on OPs that it will initiate all flows over https).

At least in  foreground flows, the users browser/firewall will of course be inspecting any http/https transitions by non-complying OPs. Normal PC firewalls can be inspecting which ciphers are being negotiated (and watching for OP servers using SSL ciphered re-handshakes attempting to hide ciphersuite-downgrade negotiations from the inspecting firewall/proxy)

This all seems doable, and very web like. Not sure it require ANY participatipn from the mega-OPs to achieve it, either. In a "paypal" assurance "framework" linking its CA- issued server certs to its hash-trees, to its network of "authorized" OPs, to its RP communities bound into trust networks by the likes of CX/TX, one can see the assurance levels of openid going up to the level needed for regulated financial transactions  - and doing that WITHOUT fundamentally interfering with the low assurance applications of openid applied to low-assurance web2.0 social networks, etc. That is...https openids would have achieved what https itself achieved politically - which of course made it so massively "adoptable".

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Martin Atkins
> Sent: Thursday, February 05, 2009 4:46 PM
> To: general at openid.net
> Subject: Re: [OpenID] User-editable XRDS files?
>
> Peter Williams wrote:
> > And the final steps...
> >
> > Copy the result to some simple public file store outside of the
> control of the OP.
> >
>
> No.
>
> That would obviously be an optional step for an advanced user who his
> hosting his own identifier.
>
> If you don't trust whoever hosts your identifier, then you're already
> screwed.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

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