[OpenID] google, xri and signed xrd
John Bradley
ve7jtb at ve7jtb.com
Sun Sep 13 12:13:03 UTC 2009
The Generic sense of interacting with the next XRD.
We expect there to be more than one trust model developed for XRD.
John B.
On 2009-09-13, at 12:18 AM, Peter Williams wrote:
> 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
>>
More information about the general
mailing list