[OpenID] google, xri and signed xrd

Sun Sep 13 04:18:12 UTC 2009

Is the use of the loaded term "interaction" a reference to grid-
managed/powered stateful web services, or is it used generically?

On Sep 12, 2009, at 5:12 PM, "John Bradley" <ve7jtb at ve7jtb.com> wrote:

> 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
>