OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


<XRD proxy=”true”> … </XRD>


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]