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


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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

Subject: Minutes:Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-09-20

[My apologies for late posting of these minutes -- I was travelling and only
finished them on the plane last night.]

Following are the minutes for a joint unofficial telecon of the XRI and XDI
TCs at:

Date:  Thursday, 20 September 2007 USA
Time:  10:00AM - 12:00PM Pacific Time

Event Description:
Weekly unofficial joint call of the XRI and XDI Technical Committees.

    Dial In Number: 571-434-5750
    Conference ID: 5474


Wil Tan
Drummond Reed
Markus Sabadello
Peter Davis
Kermit Snelson
Victor Grey
Gabe Wachob



Steve Churchill sent a question the list the morning that overlaps with a
question from Victor Grey and Kermit Snelson.

Currently the spec calls for iterative Ref processing, i.e., if XRD A has
Refs A1, A2, and A3, and processing Ref A1 yields an XRD B that does not
have the requested service endpoint, but has Ref B1, then is Ref B1

The answer is yes, this is the correct behavior.

The next question is whether, if Ref B1 is a dead-end, does the resolver try
A2? This may not be explicit in the flowchart in section 8.1.2 of ED05.

After a long discussion about "backtracking", it was agreed that resolvers
should not do backtracking for all the reasons the TC has concluded in
earlier discussions. Specifically:

1) With backtracking, an error in a ref chain may go undetected. Without
backtracking, the error will be detected/reported immediately.

2) With backtracking, refs are "multidirectional", i.e., resolvers
potentially need to follow multiple ref paths to different authorities, and
resolution behaviour can become very hard to predict/test. Without
backtracking, refs are unidirectional - once you start down a path, you stay
on that path. This means all Refs in an XRD should point to the same logical
authority, with the goal of providing provide redundancy. XRDS authors can
still chain together refs across a set of authorities to distribute XRDS
control, but the path through those refs is deterministic. (Note: for fine
grained control at the service level, an XRDS author can use service refs.)

3) With backtracking, resolution could be much slower. Prohibiting
backtracking encourages faster response.

We clarified that if a resolver encounters any form of error that prevents
it from successfully resolving a ref ((i.e., any result that is not a 1xx),
then it MUST try the next ref. However as soon as the resolver successfully
resolves a ref to an XRDS, it is now in a new XRDS path, and it never backs
out of that XRDS path.

Victor then asked if you try a URI in a Service element and it fails and you
try a second one and get an XRDS but not what you are looking for, do you

Again, our consensus was no, once you successfully retreive an XRDS, you are
now on a new XRDS path.

# DRUMMOND to make sure this rule is clear by adding a Backtracking section
to the Refs section, plus additional text and flowchart annotations in the
Generic Protocol section as necessary.

# WIL to respond to Steve's message to the list.


Victor and Kermit have implemented CanonicalID verification and
other features of ED05 in their rxripr (Ruby XRI Proxy Resolver) and
compiled the question list below. Each question is followed by bullet points
regarding the discussion/decision and pound signs for action items.

1. Let's assume that an authority resolution request is made with ref=false
and cid=true. If there were Refs that were not followed because of that, we
should return a <Status> of "101 - REF_NOT_FOLLOWED", but if we verified the
CID we should return a <Status> of "110 - CID_VERIFIED". How can we indicate
both? And of course, all the permutations of that scenario.

* We had a long discussion about this. The conclusion was that it would be a
better architecture to have 1xx status codes reflected as status attributes
and not separate error codes, as this prevents "status code explosion".
(Note: this was the same decision we came to regarding trust parameters. For
example, instead of trust=https+saml, now each trusted resolution parameter
is its own boolean, e.g., https=true;saml:true.)

* So our conclusion was to add three attributes to the Status element:

** refs= is a boolean. The default is true; if absent or empty, it is true.
** cid= and ceid= both take an enumerated list of four values: absent,
verified, failed, off. The default is true; and if absent or empty, it is

 - making them optional, if absent, refs=true, cid=off, ceid=off. Deprecate
101 error code. The default is off; and if absent or empty, it is off.

# DRUMMOND to make this change throughout in ED06.

We also agreed that section 14 should be renamed "Status Codes".

# DRUMMOND to make this change throughout in ED06.

2. In https trusted resolution, we are reading the spec to say that in order
to use a $res*auth type service, the Service element has to BOTH have an
HTTPS URI, and contain an element exactly like this:

Have we got that right?

* Yes. We discussed this and there was consensus that although it appears
redundant, it leads to simpler processing for consuming applications and is
in keeping with the rule that new authority resolution services can be added
using new media types or media type parameters.

* Also, the same applies to self-describing XRDS documents, including
community roots.

# DRUMMOND to add a note in ED06 amplifying this rationale.

3. If we are not supporting SAML at this time, and we receive a request with
saml=true, my take on it is that rather than attempting to do -any-
resolution, we should immediately return an XRDS that looks like this:

<XRDS xmlns="xri://$xrds" ref="xri://=example"> <XRD
xmlns="xri://$xrd*($v*2.0)" version="2.0" > <Query>*example</Query> <Status

* Yes, return the above.

Also, is it within spec when returning a 201 to change the text message to
something more informative, like "SAML_NOT_IMPLEMENTED" ?

* Yes, you can and should do that. More descriptive error message text is

# DRUMMOND to ensure the text in section 14 is clear about this.

4. When attempting to satisfy an "https=true" authority resolution request,
if we find no $res*auth service at all, but there is a <Ref> element, should
we follow that to see if it is trusted-res compliant?

* Yes. IMPORTANT: If https=true, Refs must also be https URIs.

# DRUMMOND to ensure this is clear in ED06.

How about if we do find a $res*auth service, but it is not trusted- res
compliant, and there is a <Ref> element? Having failed trusted- res on the
Service elements, do we then report a 231 error, or do we follow the Ref to
see if it can provide a trusted-res resolution path?

* Only if the service ref is HTTPS.

# DRUMMOND to check ED06 to make sure this is clear.

Also, how about if there is a $res*auth service, and it either is missing an
HTTPS URI, or is missing the correct <MediaType> element, or both, and has a
<Ref> inside the <Service> element. Do we follow the Ref or fail right then?

* If a Service is marked with the https media type, then it MUST have at
least one https URI. If the service endpoint fails this test, then the
resolver should fail immediately (if there is no other service endpoint that

# DRUMMOND to add text to ED06 to make this clear.

5. We think the spec should say that when following Refs, the implementation
SHOULD check to see that each URI it follows is unique. Otherwise there is a
security vulnerability where an attacker could create a denial of service
condition by putting up an XRD that produces a circular reference (i.e. an
infinite loop).

* Agreed. After some discussion we concluded that it would be good to have a
separate status code for detecting a circular reference, so it was faster to

# DRUMMOND to add error for LOOP_DETECTED - one for 22x (authority
resolution) and one for 24x (service selection).

6. And last but not least, having followed one or more Refs, and having put
together a final XRDS that contains other XRDSes, what does that do to CID
verification? I assume that CID verification should only examine the chain
of XRDs relating to the original set of XRI subsegments, and not look inside
the enveloped XRDS -- is that correct?

* This actually involves two questions: A) does the resolver need to check
all XRDs in all XRDS documents, or only the outer XRDS and not any nested
XRDS? B) Is the CanonicalID chain checked inside each XRDS document, or
between documents?

* The answer to (A) is that CanonicalID verification is performed on all
XRDs in all XRDS documents in the entire resolution cycle. However
CanonicalEquivID verification is only performed on the VERY LAST XRD in the
entire cycle.

* The answer to (B) is that each CanonicalID verification chain applies only
within a single XRDS document. So even though Ref processing can produce a
nested XRDS document, if resolution continues back inside the parent XRDS
document, the CanonicalID verification rules (that each CID must be a direct
child of its parent) applies to the last parent *in that same XRDS*, not in
the nested XRDS. The same applies for each nested XRDS.

# DRUMMOND to clarify and illustrate in ED06.


Drummond reported that although he is travelling this week and will be at
Digital ID World next week, he'll work as fast as possible to complete ED06.
The goal is to have it complete, both with all action items on...


...as well as the additional action items in these minutes. This will likely
not be completed until after Digital ID World, however the good news is that
this should be the final draft. After one round of final review, it should
be ready for a vote the week of October 8.

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