[OpenID] google, xri and signed xrd

Sat Sep 12 19:30:07 UTC 2009

So I broke down and took a look at oasis work products.

http://www.oasis-open.org/committees/download.php/33876/xri-syntax-3.0-wd02.doc:

-       seems to be a generalization of the HXRI notion. The syntax and the allied notion of binding seems (to me to be) the most contentious part for W3C, as it competes with the URI+inference doing the same thing.

-       Everything to do with a particular DNS-like tree-walking resolver is gone. But I don't believe that the resolver was the W3C main objection. Their fundamental objection is that XRI "thinking" institutionalizes a 2 tier web, of trusted providers and untrustworthy plebs.

-       The definitions and orientation are very much now about semweb (XDI variant) and identity equivalence logics, rather than name serving and synonym registration.

http://www.oasis-open.org/committees/download.php/33232/xrd-1.0.pdf

-       like X.509, XRD is now a "format" - and must necessarily be profiled.

-       It defines a protocol for obtaining resource descriptors from http(s) URIs, which implies that HTTP is not said protocol. That is, there will be different protocols that can "resolve" an http URI. That is, the protocol portion of a URI is no longer that which defines the protocol (which makes things innately incompatible with web architecture...!) Or perhaps , I'm just an old school thinker, and the world has moved on ... Formally, a XRI has the form of an URI, but is not one. So formally, its legitimate to play these kinds of definitional games. One should always worry about specs that require super-parsing and contextual semantics, as they tend to lose most of the vb crowd.

-       The introduction make it clear that the focus is service advertisement and interface discovery, aping a bit how ldap is used in grid middleware. It will be interesting to see if the information model of XRD can do better than the class/object/attribute/syntax information model of X.500, from the mid 80s.

-       In section 2.0, folks clearly buy-in to the rel=X movement the microformats world; which seems sensible. Its seems a minor improvement over the SEP.type=<uri> way of doing the same thing, in openid 2.0 - though. But, it will probably garner votes, now.

-       In section 2.2, we see that there are implied trust, authority and caching models. Whether these are semweb focused, XDI focused, grid focused... we don't know.

-       Link looks like a renaming of SEP. Honestly... I cannot tell the difference.

-       Links URITemplate looks like a re-engineering of the old re-writing rules of QXRI.

-       The semantics of KeyInfo are interesting and different to XRI 2.0 : "validate interaction with the linked resource." This seems to mean that different "interactions" can leverage the keying material.

-       In 2.5, Im glad to see URIs used for naming elements, etc, not HXRIs etc

-       3.2 seems to be the old Referral semantics ,for distributed authority management. But, it also feels more generalized (from the few words provided).

-       3.3 clearly says that selection can depend on non-XRD extensions; which is cute (it can be delegated to the binding resolver)

-       4.1 and 4.2 don't say a lot, on an important topic. It should be made clear that the constraints only apply to the signatures in the XRD namespace. Signatures in XRD extensions are not addressed (or constrained).

Hmm. Its al definitely simpler. But without the bindings resolvers, it's hard to evaluate he likely effectiveness of the two - as so much context is missing. It's hardly the intellectual tour-de-force though that I was led to believe. It's mostly a dumbing down of XRI resolution v2 (which I found quite an intellectual tour de force..)

Reminds me of the moment with ISO divorced X.509 syntax and processing from X.500 name resolution, so it could roam free of OSI, ultimately get dumbed down by Netscape, and thus do what it did for the web when mixed with SSL for form the https protocols.

And, given the historical impact of that decision, folks may well be doing the right thing.

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Saturday, September 12, 2009 9:26 AM
To: Peter Williams
Cc: openid General
Subject: Re: [OpenID] google, xri and signed xrd

Andrew Arnott started to port the XRI resolver to .NET.

The decision was made part way into the project to wait for the XRD 1.0 spec and XRI 3.0 resolution.

For the GSA using XRI for whitelists, the discussion did happen.

Though it was more around white-lists for info-card.

We didn't want to introduce new xmldsig requirements for openID RPs that don't currently exist.

Once there is a XRD spec with dsig that is part of openID that can be revisited.

When the info-card profile comes out next week you will be able to see where we might take it in the future.

Though the infocard whitelist will be based on SAML meta-data rather than XRD for the moment.

I had hoped to do a distributed white-list for openID but that was a bridge too far for the first round.

A central whitelist was the practical choice, not the one we believed was best long term.

John B.

PS XRI 2.0 is not an oasis standard we lost the vote, I cant change that.

On 2009-09-12, at 10:34 AM, Peter Williams wrote:

Addressing the weaknesses in openid discovery (XRI discovery, not YADIS)

1.       Goto Google.com<http://Google.com>, and select the iGoogle home page. (...portal page, now with gadgets...)

2.       Install http://www.freexri.com/tools/GoogleGadget/

3.       Use XRI gadget, type "@blog*lockbox" and tryout "resolution" (see it popup a teaching window, and note I have a certificate SEP registered for this "endpoint")

4.       On teaching window, also tryout the SAML option to get a signed XRD (choose resolve type "authority")

5.       On teaching window, also tryout the SAML option with the XRDS option, to get *multiple* signed XRD forming a chain of signed assertions (choose resolve type "authority")

What is interesting here is that .gov could easily publish its whitelist of OPs in such a form, rather than kludging up a root registration authority. The XRD is signed on the fly (even though the registered "cert" for the OP's https endpoint is static). To scale out the domain graph, there are chains...much as one has chains of certs and x-certs in PKI-based domain management.

If anyone has an XRI Resolution client in .NET, please let me know. In security, having your own code interwork with your own code is typically not a strong proof of anything.

_______________________________________________
general mailing list
general at lists.openid.net<mailto:general at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-general

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