RE: [xri] About XRI resolution open issue #37

Steve,

On the attribute name, “proxy” may be better than “xrds” but I need to think about it more. In any case, I don’t believe the SAML signature chain problem exists. I may be wrong, but since each XRD contains the key info for signing the next XRD, I believe the chain can continue right through each XRD obtained via a proxy. They would all appear “flat” inside the final XRDS. For example:

<XRD>

<Query>*example</Query>

…

<saml:Assertion>SAML-assertion-and-signature-here</saml:Assertion>

<KeyInfo>keyinfohere</KeyInfo>

</Service>

</XRD>

<XRD>

…

<ProviderID>xri://=example</ProviderID>

<saml:Assertion>SAML-assertion-and-signature-here</saml:Assertion>

<KeyInfo>keyinfohere</KeyInfo>

</Service>

</XRD>

<XRD>

…

<ProviderID>xri://=example*foo</ProviderID>

<saml:Assertion>SAML-assertion-and-signature-here</saml:Assertion>

<KeyInfo>keyinfohere</KeyInfo>

</Service>

</XRD>

<XRDS>

It all looks very clean to me. Am I missing something?

=Drummond

From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Friday, January 12, 2007 4:09 PM
To: xri@lists.oasis-open.org
Subject: [xri] About XRI resolution open issue #37

Regarding item #37 at http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11.

SAML Trusted Resolution currently requires that a conformant Resolver output an XRDS which has signatures for each XRD contained therein. The (regular, not URI) Ref processing rules require that there exist an XRD chain to the root for each contained XRD. This is done using a nested XRDS in the output XRDS. This allows that each XRD--even those obtained by following a (regular) Ref--have the XRD signature chain all the way to the root authority (=, @, !). Now somebody can take the Resolver’s output XRDS and validate all of the XRD signature chains independently (of the resolver.)

Here’s the problem: An XRD obtained by following the “URI Ref” must also go into the Resolver’s output XRDS, but there is no reasonable way to create a signature for this. To show why, I’ll give a simple example, using the degenerate case:

Say =steven.churchill places a URI Ref on its OpenID service. The resolver will perform an HTTP GET to obtain the new XRD (so I can put whatever I want in it), but the only authority that can sign this XRD is the root authority “=”. (I tried offering Les a hundred bucks, but he wouldn’t lend me the private key. J)

---------------------------------------

I have a proposal.

First, let’s change the name of the URI attribute and call it xrdProxy. The overall idea is that we have performed authority resolution and service selection and now we encounter a highest priority URI that is indicating that it wants to replace the current XRD with this XRD “proxy”.

The URI looks like this: <URI xrdProxy=”true”>http://xxxxx</URI>

And the obtained XRD proxy would appear in the XRDS as such:

The resolution rules would be these: XRD proxies do not require signatures for SAML trusted resolution, and all XRD proxies must go at the end of the XRDS (including those in nested XRDSs). Note that the XRD immediately prior to a list of XRD proxies *does* require the signature in the case of SAML trusted resolution.

---------------------------------------

The problem with this proposal is that it seems that these unsigned XRD proxies may be the weak link that negates the entire security model of SAML trusted resolution.

~ Steve

xri message