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