[OpenID] google, xri and signed xrd

Sun Sep 13 00:12:20 UTC 2009

I would add that the XRI 3.0 resolution spec and others will be  
available shortly after XRD 1.0 gets CS approval.

Doing it in a more modular way has advantages.

John B.

On 2009-09-12, at 4:03 PM, Breno de Medeiros wrote:

> 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)
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general