[OpenID] google, xri and signed xrd

Sat Sep 12 20:03:50 UTC 2009

Hi Peter,

Yes, the XRI TC has an explicit goal to get a simpler product this
time around. A few short notes on your comments.

1. The need for creating application-specific profiles. This was an
intentional decision to keep the spec simple. Each application can
define specific XRD processing rules, and therefore write its own
'discovery spec' that is compatible with the XRD format, but tailored
to the application needs (and therefore simpler). Different
applications can write simpler parsers that consume the same document
(an XRD file) and find only what they need, without stepping on each
other's toes. The alternative to a profile-based specification would
be to try and anticipate all ways that people could want to use this
format and create a bloated specification that would please no one.

2. The protocol for discovery is not necessarily the protocol of the
URL. Indeed this is left for applications to profile. Your example was
that an application might decide to resolve an http URL using non-http
protocol. That is possible, but a more plausible example is an
application (e.g., openid or webfinger) define an http-based discovery
of non-http URLs, e.g., email addresses.

3. Signatures are optional for applications. The spec defines very
specifically how to sign and verify XRDs, using a strict form of
canonicalization for robustness. The spec shows how to infer trust in
new keys found during the discovery process (i.e., how to chain trust)
but not how to bootstrap trust (again left to applications to decide,
because this is a trade-off involving not only technical
considerations). This allows any trust model to be used by
applications.

On Sat, Sep 12, 2009 at 12:30 PM, Peter Williams
<pwilliams at rapattoni.com> wrote:
> 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, 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
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)