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


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.


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.


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.

# 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.


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.


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.


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. 

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.


7) NEXT CALL

The next call is next Thursday at the regular time. Drummond reported that
due to summer travel he most likely will not be able to be on next week's
telecon. He will work with Will, Eran, and Peter to make sure it is covered.




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