It’s
been a while and my head spins just thinking about this. Let me ask some random
questions:
- Is a GCS character by itself a valid
authority subsegment?
- If so, can it be resolved? That is,
if you just have the IP address of the “=” root authority server, can you
ask it for “xri://=”?
- I don’t understand why a client would
want the GCS authority XRD when using a proxy. It will know which GCS
character, that’s for sure, because it will send it in as http://xri.net/@foo. Unless you’re saying
that it needs to verify trusted resolution itself, in which case it should
have everything it needs (public key, providerID, etc.) pre-configured and
start from the “*foo” XRD. It’s like X509 certs, if you have the certificate
of the CA you trust, and are presented with a cert that is signed by that
CA, you can verify it.
- Are you suggesting that we return
the GCS root XRD only for proxy resolution? Why not for normal resolution
for consistency? And this corresponds to Q1 and Q2 above. If a GCS
character is a subsegment in its own right, you can resolve it. Drummond
has also requested for that ability. It would be a lot more elegant if xri://@
is 1 subsegment, therefore you get 1 XRD back, xrd://@foo has 2 subsegments
so expect 2 XRD’s back, whether it is proxy resolution or authority
resolution. Sure, we can save some 200 bytes by omitting the root XRD for
root resolution, but that can also be reconciled by having the authority
resolution server with 2 endpoints:
http://at.xri.net/@ - corresponds
to xri://@ => 1 XRD
http://at.xri.net/@*foo –
corresponds to xri://@foo => 2 XRDs
http://at.xri.net/@/ - this is
actually the authority resolution service URI returned in the 1st URI
above.
http://at.xri.net/@/*foo –
gives you 1 XRD i.e. for *foo because you are asking @’s authority resolution
service for the next subsegment. Just like if you asked @foo’s auth res server
for “*bar” it’s not going to give you back @foo’s XRD, it’ll just give you *bar’s
XRD.
This means that existing clients who use direct authority
resolution and do not want the root XRD can just reconfigure their SEP to the
third URI above. This seems to sit well with me, but I’m sure there’s a flaw
somewhere I can’t see.
From: Wachob, Gabe
[mailto:gwachob@visa.com]
Sent: Saturday, June 24, 2006 8:56
AM
To: Tan,
William; xri@lists.oasis-open.org
Subject: RE: [xri] Returning a
complete XRDS in proxy resolution
Wil-
1) The GCS XRD should be composed by
inserting the information that the proxy has for the GCS authority. In fact, in
openxri proxy, that information is largely in the proxy.properties file
already... In reality, root authorities need to publish information widely
about themselves anyway, so I don't think this is a big issue. Note that the
root authority information only needs to go to proxies, non-proxy-using
clients, and clients wishing to perform SAML-trusted-authentication themselves.
In short, clients using proxies don't need this root authority info - one of
the major reasons to use proxies.
2) I don't think this inconsistency (if it
actually exists) is a problem. If a client is doing trusted resolution
verification itself, it can either ignore the first XRD (corresponding to the
root) and just use the information it has preconfigured for that root, or (if
especially paranoid) perform some correlation between the preconfigured info it
has for a trusted root and that first XRD. This correlation is not
XML-comparison - it would only be a logical comparison (I suppose) that the key
fields (e.g. the public key the root uses to sign resolution requests, and root
authority's providerid, etc) are equivalent to what the client has
preconfigured. Applications probably don't care which behavior for correlation
is used -- they should be basically equivalent, and thus also basically
equivalent with direct resolution by a client. Thus, I'm not sure where the
issue lies...
-Gabe
From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Friday, June 23, 2006 4:49
AM
To: Wachob, Gabe;
xri@lists.oasis-open.org
Subject: RE: [xri] Returning a
complete XRDS in proxy resolution
Hi Gabe,
I remember very vaguely discussions about
that. What you said makes sense, and I agree that the proxy output should
include the GCS XRD in its output.
There are a few issues though:
- What
should the GCS XRD be? Is it the XRD configured in the resolver (used by
the proxy)? What if the XRD for a given GCS changes? Will the proxy
“resolve” the GCS to get the XRD for it?
- Doing
so breaks the consistency between direct resolution and proxy resolution.
Currently, an application that uses the resolver doesn’t care if the
resolver got the XRDS from a proxy or by direct resolution – the resulting
XRDS will have the same structure (same number of XRD’s). It’s not a big
deal and can be dealt with quite easily.
I’m not sure if it would be a trivial
change in OpenXRI yet; we’ll need to see what changes are made to the spec.
From: Wachob, Gabe
[mailto:gwachob@visa.com]
Sent: Friday, June 23, 2006 10:51
AM
To: xri@lists.oasis-open.org
Subject: [xri] Returning a
complete XRDS in proxy resolution
I have been playing with the openxri 1.0.0 proxy code and
noticed that when I request a full XRDS document back, the first XRD inside
does NOT correlate to the GCS character (e.g. "@"), but rather to the
first subsegment after the GCS. In an earlier draft of our specs, we explicitly
addressed this issue and the only sensical thing to do was to include the XRD for
the GCS authority (but only when doing proxy resolution - this is one of the
main differences with lookahead/recursive resolution).
The openxri proxy seems NOT to return an XRD for the GCS
authority and this seems broken to me. I can't find in the resolution text
where this is spelled out so I understand why it was implemented this way.
However, I think an XRDS returned from proxy resolution MUST include the GCS
authority XRD so a client knows exactly which GCS authority is the root
(even if not doing trusted resolution). I'm assuming this is a fairly trivial
change to the openxri proxy code.
I strongly suggest we add this language explicilty in 7.6
(in addition to referring to the requirements of 4.2) for when a client is
using XRI proxy resolvers. In addition, I think we should add this requirement
for section 6 (trusted resolution). While a client doing trusted resolution
verification already has to know about roots it trusts (and therefore can do
correlation with the root authority and the first non-root-authority XRD), I
think explicitness and parallelism to the non-trusted mode are important.
__________________________________________________
gwachob@visa.com
Chief Systems Architect
Technical Innovation and Standards Management
Visa International
Phone: +1.650.432.3696 Fax: +1.650.554.6817
|