google, xri and signed xrd

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

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

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

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