RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-02

[Eran Hammer-Lahav <eran@hueniverse.com>]

Look like the less I talk the more productive the meeting is...

Comments inline.

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, July 03, 2009 12:37 AM
> To: 'XRI TC'
> Subject: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-02
> 
> Following are the minutes of the unofficial telecon of the XRI TC at:
> 
> Date:  Thursday, 02 July 2009 USA
> Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)
> 
> ATTENDING
> 
> Bill Barnhill
> Markus Sabadello
> Drummond Reed
> Will Norris
> Scott Cantor
> Joseph Holsten
> John Bradley
> Tatsuki Sakushima
> Nat Sakimura
> Eran Hammer-Lahav
> Breno de Medeiros
> 
> 
> AGENDA
> 
> 1) XRD 1.0 ELEMENTS FORMERLY KNOWN AS TARGETSUBJECT AND TARGETAUTHORITY
> 
> The proposal is to use just Subject and ds:KeyInfo at both the XRD and
> Link
> levels. See the writeup at:
> 
> 	http://wiki.oasis-open.org/xri/XrdOne/TrustElements
> 
> Note that this wiki page also includes a writeup of some of the basic
> trust
> verification rules.
> 
> Will and Drummond explained the rational for keeping the same element
> names
> at the XRD level and the Link level, since the semantics are equivalent
> in
> both cases -- all that changes is the referent.
> 
> DECISION: WD02 will use <XRD:Link:Subject> and <ds:KeyInfo> at the link
> level.

When describing <XRD:Link:Subject> it is important to note that this element has the same semantic authority as <MediaType> in that outside of trust, it is just a hint that is overruled by the actual stated subject of the linked resource. In trust, that hint is made into a validation check, but in either case, it is just a hint.
 
> 2) XRD 1.0 - COVERING XRD LINKING AS A SEPARATE SECTION
> 
> Will has pointed out that a Link with a describedBy relation has
> special
> processing rules associated with it, so he proposes that we have a
> special
> section in the spec that explains these rules. This involves several
> subissues.

Why is this not an application specific process? What makes this so special? Do we have other use cases than OpenID for this? How is a describedby link to another XRD different than an author link?

I am not sold yet on the need to spell out a separate process for this link relation. It can be useful to explain what it means semantically so that people understand the architecture. 
 
> 2A) TERMINOLOGY FOR LINKED XRDS
> 
> We discussed whether the XRD 1.0 spec should use the term "XRD
> delegation".
> 
> DECISION: There was agreement that since our fundamental term for
> relations
> between resources is "Link", we should use the neutral terms "Linked
> XRD"
> and "XRD Linking" instead of "Delegated XRD" or "XRD Delegation".
> 
> There was also consensus that we should use this term consistently
> throughout the spec.

Per my previous note, the spec should really not use the work delegation at all.

> 2B) FORMAL DEFINITION OF A LINKED XRD
> 
> The second question is what formally constitutes a linked XRD. Will
> explained that from an LRDD perspective, it is a <XRD:Link> whose
> <XRD:Link:Rel> value is "describedBy" AND whose <XRD:Link:MediaType>
> value
> is "application/xrd+xml".
> 
> Will suggested that the spec define a single URI that can be used as a
> <XRD:Link:Rel> value for the exclusive purpose of expressing the
> combination
> of both of the above statements, i.e., it would be semantically
> equivalent.
> However that would only be useful to implementers if the spec mandated
> that
> this <XRD:Link:Rel> value MUST be used for all XRD Links, which would
> potentially supercede the use of describedBy. This remains an open
> issue.

You can't do that. You can't overload a relation type with a media type (or a media type with a link relation). What you can do is register a new relation type (with the IETF of as a URI extension) that has special processing rules, which is what you are suggesting here in the first place. But again, what other use cases are there other than XRD?

Maybe a compromise is to say what such a linked XRD means and that clients should obtain the additional XRD (unless specifically instructed not to do so by the application). Anything more than that gets complicated very fast (order of precedence, nesting, loops, etc.).

> # WILL AND DRUMMOND to raise this question with Eran on the list.
> 
> Will: can we use a specific URI for the Rel, besides Rel of describedBy
> and
> mediatype of XRD. These two should be semantically equivalent.
> 
> 
> 2C) LINKED XRD SECTION OF THE SPEC
> 
> DECISION: It was agreed that XRD Linking is so important from an XRD
> processing perspective that it should be covered in its own section of
> the
> spec.

What are the use cases? If this is so important, we might need an XRD element for this.
 
> 3) XRD 1.0 - LINK PROCESSING RULES
> 
> Drummond summarized that different link processing rules result in
> different
> behaviors. For example, under XRI Resolution 2.0, a processor looked
> for a
> Ref element (the equivalent of a Linked XRD in XRD 1.0) and followed it
> (in
> priority order) before it would look for any Service (the equivalent of
> a
> Related Resource in XRD 1.0) in that same XRD.
> 
> Since in XRD 1.0, all related resources (included a delegated XRD) are
> described by <XRD:Link> elements, Will has proposed processing Links
> strictly in priority order. This means, for example, that if an XRD
> author
> wants a Link to an OpenID service to be checked *before* a Linked XRD
> (that
> may contain a different OpenID service), the author can do this simply
> by
> giving the first Link a higher priority than the second -- and vice
> versa if
> the opposite ordering is desired. (Identical priority means the choice
> between the two will be made at random.)
> 
> Will and Drummond prefer this rule because it is simple for everyone --
> XRD
> implementers, authors, and readers -- to understand. It also works
> iteratively across a chain of delegated XRDs. John agreed that it
> appears to
> offer at least the same if not greater flexibility than XRI Resolution
> 2.0.
> 
> Another important processing rule decision is "backtracking". This is
> when
> an XRD processor follows a Link from a first XRD to a second delegated
> XRD,
> then processes the Links in the second XRD in priority order. If it
> still
> does not find what it is looking for, Will and Drummond believe the
> processor should "backtrack" to the first XRD and continue processing
> its
> Links in priority order.
> 
> XRI Resolution 2.0 did not allow backtracking. But that was largely
> because
> it used a more complicated schema and processing model, so backtracking
> would have introduced too much complexity. In XRD 1.0, the schema is so
> simple, and the delegation rules so simple, that backtracking should be
> relatively straightforward (though probably relatively rare in
> practice).
> 
> DECISION: WD02 will: a) use Link priority to govern link processing
> order,
> b) follow linked XRDs in priority order if the desired Related Resource
> has
> not been found, and c) backtrack back "up" to the source XRD if the
> linked
> XRD does not contain the desired Related Resource.

How do you know you found what you wanted / the best link without processing all the linked XRDs? Why is this approach better than simply collecting all the links found and using them (assuming equal priorities all around).

I don't have an issue with this proposal but it can create conflicts with the general link framework. XRD adds priority to the framework which other methods lack, and in such a case, a higher priority overrides other rules because it is clearly the intention of the describing authority. But if the priority is not present, why would links found in the first XRD come before those in another XRD?

I just want to make sure we are staying consistent.

> 4) ROOT XRD SIGNING
> 
> Scott asked if there was an answer to his question on the list about
> signing
> the "root XRD", i.e., the first XRD in any chain of XRDs.
> 
> Drummond explained that there are two overall trust models:
> 
> 	1) The "third-party CA model" (or "conventional PKI model"),
> where
> the certificate for the signer of the root XRD and each linked XRD is
> signed
> by a CA that the XRD processor trusts.
> 	2) The "XRD chaining model", where the root XRD is either signed
> by
> a third-party CA, or the root of its own trust federation, or for any
> other
> reason can serve as a trust anchor, and then each linked XRD is
> verified
> using ds:KeyInfo supplied by or referenced by the previous XRD in the
> chain.
> 
> 
> Drummond emphasized that in the second model, any trust model can be
> applied
> to the first XRD in the chain; the XRD 1.0 spec should not constrain
> that
> aspect, only how trust chains across all the lower XRDs in the chain.
> 
> Scott summarized that the second model was similar to the traditional
> CA
> certificate model but instead applied directly to XML signing. He
> believes
> that is a very useful model that XRD should support. For example, any
> trust
> federation can serve as a trusted root, and could sign the XRDs of
> members
> of the federation.
> 
> There was consensus that both trust models -- and the steps necessary
> to
> verify an XRD using either of them -- must be described very clearly in
> the
> XRD Trust section of the spec. Nat pointed out this is likely to take
> us
> longer than we planned, but it is critically important to successful
> adoption.

We might want to break the spec into two parts and get the basic non-trust stuff out first. There are plenty of use cases where trust is not an issue and should not delay this work.

> 5) OTHER XRD 1.0 ISSUES/WORKING DRAFT 02 PLAN
> 
> Will plans to push out Working Draft 02 by the end of the week so we
> can
> begin reviewing the new text and begin suggesting text for the XRD
> Trust
> section.
> 
> 
> 6) LRDD - SUBJECT OF A HOST-META XRD
> 
> Eran has requested feedback on this issue. See this thread:
> 
> 	http://lists.oasis-open.org/archives/xri/200907/msg00007.html
> 
> Eran summarized the three options:
> 
> 	1) Keep host-meta as an XRD, and use a different URI scheme for
> the
> Subject.
> 	2) Create a URI set mechanism.
> 	3) Use a different schema (not XRD) for host-meta.
> 
> The first option has the challenge of establishing a new URI scheme.
> The
> second option gives us the necessary functionality but adds complexity
> for
> developers. The third option requires a new schema.
> 
> Breno pointed out that option #2 seems to be the one with the greatest
> precision and least risk.
> 
> Scott asked the question: is the goal to define an XRD for the host, or
> for
> all the resources on the host? Eran responded that the current use
> cases
> only require the latter (more specifically, the requirement is for all
> resources under a domain and port number.) He also said that the latter
> makes it easier to define Link behavior, because a Link on a resource
> set is
> an assertion that the link applies to all the resources in the set.
> 
> Following is an example of what this might look like.
> 
> <SubjectSet>
> 	<Scheme> </Scheme>
> 	<Authority> </Authority>
> 	<Suffix> </Suffix>
> </SubjectSet>
> 
> Scheme would be a space-delimited list. Authority would be a valid
> authority
> identifier. Suffix could be a regex at the most complex (similar to
> NAPTR),
> or a string plus wildcards.
> 
> Scott pointed out that if we use a regex, we need to specify it very
> precisely due to the subtle differences between implementations. Joesph
> and
> Scott both agreed that we should look at the DDDS specs because they
> use
> regex, and we may be able to adopt their approach.
> 
> Joesph suggested another option: use the POWDER syntax for what they
> call an
> "IRI set". This series of XML elements compiles down to a regex.

I think the POWDER model is too complex (with exclusions and other rules). We should not try to invent the ultimate URI set solution, just some basic rules that are *good enough*. People can always use other namespaces (including POWDER) to accomplish that. However, LRDD can import the IRISet POWDER element, leaving XRD alone...

If we create our own, I suggest we move forward with 

<SubjectSet>
	<Scheme><!-- Space delimited list of schemes --></Scheme>
	<Host><!-- RFC 3986 host with support for wildcard matching using '*' --></Host>
	<Port><!-- Optional port number --></Port>
	<Suffix><!-- everything else after the URI authority --></Suffix>
</SubjectSet>

Breaking of authority into host and port solves the complexity of writing definition of how to parse an authority string and what is allowed in it. It removed the need to deal with userinfo and makes host wildcards simpler to constrain in the string.

I don't really care about the format of suffix - someone who does should propose something.

> Scott said that we should either:
> 
> 	A) Use a very simple model, or
> 	B) Properly define a general model.
> 
> The mistake we should not make is either "hack up" a general model to
> try to
> simplify it, or profiling a general model and yet leave it open for
> extensibility. Either one is a recipe for disaster. Better to either
> just
> define a very simple model, or a clean general model, and stick to it.
> 
> Breno asked whether the same mechanism defined for URITemplate could
> work
> for this (call this the "SubjectTemplate" approach). He thought the
> mechanism defined for URITemplate was supposed to be sufficiently
> generic
> that it could be used for email addresses, for example, so it should
> work
> here. Will pointed out that URITemplate is designed primarily for
> replacement, vs. matching. The same applies to NAPTR. So he's not sure
> whether the same mechanism will work.
> 
> This is an open question to Eran.

I agree with Will. There really isn't a simple way to apply the syntax but I'm open for suggestions...

EHL