Minutes for XRI TC Calls Thursday 8PM PT USA/ Friday 9AM PT USA

["Drummond Reed" <drummond.reed@cordance.net>]

Following are the minutes of the unofficial XRI TC calls held Thursday 9/22
8PM PT USA (for Asia/US) and Friday 9/23 9AM PT USA (for US/Europe).

Note that the discussion of each agenda topic is included for both calls.

PRESENT ON THE THURSDAY 8PM USA CALL:

Kunal
Drummond
Les
Peter
Wil

PRESENT ON THE FRIDAY 9AM USA CALL:

Drummond
Dave
Victor
Chaten
Mike
Gabe
Marty
Steve
Les (at the end)


AGENDA FOR THURSDAY 9/22 & FRIDAY 9/23 XRI TC CALLS (UNOFFICIAL)

0) SYNTAX ISSUE #4: XRI NORMALIZATION
This agenda item is to check to make sure we have consensus on moving this
issue into drafting:

	http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I4XriNormalization

*****
DISCUSSION ON THE THURSDAY 8PM USA CALL:

There was consensus on advancing this issue.

DISCUSSION ON THE FRIDAY 9AM USA CALL:

After an explanation of the proposed change, there was consensus to move
this into drafting.

*****
ACTION: Advance to drafting stage.


1) SYNTAX ISSUE #2 - PROPOSED ABNF FOR EMPTY PATH SEGMENTS
See the full description at:

	http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I2ProposedAbnf 

See the detailed analysis and proposal at:
	
http://www.oasis-open.org/committees/download.php/14487/draft-xri-2-cd02-abn
f-v1.doc 

******
DISCUSSION ON THE THURSDAY 8PM USA CALL:
There was no feedback on this proposal from the participants on the call as
they had not studied this particular issue closely.

DISCUSSION ON THE FRIDAY 9AM USA CALL:
Dave and Gabe suggested that we proceed with this change and agree to
revisit it if we find a problem. There was consensus on this action.

*****
ACTION: Advance to drafting stage.


2) SYNTAX ISSUE #8 - XRI/IRI AUTHORITY SPOOFING
See the full description at:
	
http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I8IriAuthoritySpoofing 

See also the thread entitled "RE: [xri] GCS Spoofing at:

	http://lists.oasis-open.org/archives/xri/200509/threads.html 


******
DISCUSSION ON THE THURSDAY 8PM USA CALL:

Wil, who was the original suggestor of this issue, said that he prefers to
find some level of support for anti-spoofing at the specification level, as
client-side directives are very difficult to enforce uniformly.

But he also agrees that so far there is no silver bullet. 

We discussed the potential of handling this with a separate guidelines
document that could be maintained by the TC that advises implementers about
homographic attacks and specific character sets.

Peter also suggested that we could check with the IETF Area Director for the
IRI spec to find out why IRI took the stance they did regarding the IRI
iunreserved characters and homographic attacks. 

Wil pointed out that in IRI syntax, the forward slash character is the key
attack point because it visually appears to end the authority segment, but
it can be spoofed so that the real authority segment ends much further to
the right, often out of a user's sight. However XRI reverses this problem;
since order is left-to-right, the attack point for spoofing an XRI authority
is the leading character, ie., the GCS character. If this character can be
spoofed, it can fool a user into thinking that they are dealing with an XRI
authority when in fact they are resolving against an IRI authority.

After discussion of a few other options, Wil recommended that we add
normative guidance to the spec that user agents should treat punctuation
characters and symbos characters that may use used for an XRI authority
spoofing attack like spaces, i.e., they SHOULD NOT be displayed unencoded in
authority segments, and SHOULD be flagged for special attention in visual
display.

*****
DISCUSSION ON THE FRIDAY 9AM USA CALL:
First Drummond explained the the three potential solutions to an XRI
authority spoofing attack that had been discussed on the list:

1) Character exclusion. This approach would exclude all the IRI characters
that could be used for spoofing from the iunreserved production. This is
untenable because it is such a large set, and further these characters may
be needed in machine-to-machine communications where this is not an issue.

2) Special GCS character for IRI authorities. This approach would try to
minimize the threat by requiring a special GCS character for IRI
authorities. However this was rejected both because it wouldn't solve the
problem - if users didn't understand this special character, they would
still be fooled by the following GCS spoofing character. (In addition there
are very few acceptable GCS character candidates left.)

3) Require the IRI authority to be a cross-reference. This was rejected
because it would conflict with the current ability for iauthorities to be
used as private XRI community roots.

We then discussed a fourth option which Dave pointed out was considered in
the development of the XRI 2.0 ABNF:

4) Require a special cross-reference to prefix an IRI authority. This
special cross-reference (example: "($dns)") would make it much more explicit
that an IRI authority was being used.

However it was felt that if the intent was to signal to a user that IRI
authority resolution would be required, a user agent could easily apply the
same rule without any change to the current ABNF. In other words, if the
authority segment of an XRI did NOT meet the ABNF for an XRI authority, then
by definition it must be an IRI authority and the user agent could always
consistently indicate that to a user even if the identifier tried to spoof
being an XRI authority (no such similar option exists at the DNS layer).

In further discussion, Gabe felt that any of these solutions were large
potential changes to the Syntax spec for the "slice" of the authority
spoofing problem that we would solve. There was consensus that the problem
is beyond the scope of the XRI TC to solve completely.

Chetan felt that it was important not to interfere with machine consumption
of XRIs which may need these characters.

Dave said that the IRI committee concluded this was a user agent problem.
Gabe reinforced that the world of XRI users should be able to leverage the
authority spoofing solutions being developed for the IRI/IDN world. 

The final consensus was to follow Wil's suggestion and add normative
guidance about this attack, explaining that it is a variant of IRI/IDN
attacks, in which an IRI authority could try to spoof an XRI authority.
These normative text should be added to Section 2.1.5, Excluded Characters,
and 3.3, Spoofing and Homographic Attacks. 

*****
ACTION: Advance the final consensus above to drafting stage.


3) METADATA ISSUE #1: IDENTIFIER TYPE SECTION
Per an email yesterday to the list, this issue has now evolved into a formal
proposal to add a $t tag to the Metadata specification. The requirements and
proposal are posted at:

http://wiki.oasis-open.org/xri/Xri2Cd02/MetaData/I1IdentifierTypeSection


******
DISCUSSION ON THE THURSDAY 8PM USA CALL:

Peter suggested that the TC should work with Marty to understand the best
option of the set that he suggested in his email tonight. The participants
were in agreement about the value of a $t Metadata tag; the primary
questions revolve around how that space will be managed/delegated. The
suggestion was for Marty and other supporters of this proposal to draft the
specific language for the proposed section.

******
DISCUSSION ON THE FRIDAY 9AM USA CALL:

We began with discussion of the message that Marty posted yesterday to help
explain the requirements for this proposal:

	http://lists.oasis-open.org/archives/xri/200509/msg00106.html 

Marty explained that the main impetus for the $t space is to provide a
uniform method of including an identifier type declaration in an XRI or an
XRI cross-reference that can help solve identifier interoperability problems
for identifiers commonly used in and across enterprises.

The $t space would provide a way for XRI usage communities to explicitly
recognize certain identifiers. Such explicit typing of identifiers can be
helpful particularly in the context of local directory searches.

Dave put it this way: "It's really a way of sharing namespaces among
multiple authorities."

Gabe summarized his understanding this way: "What this represents is a way
of infinitely extending client-side resolution processing." However Gabe
felt strongly that this should only extend XRI resolution and not change its
base specified behaviour.

Marty agreed that the $t space could imply special processing of the
identifier that has been labeled with $t, but this could be outside the
scope of the XRI specifications and in the scope of some other
specification.

Dave clarified that all XRIs that use $t identifier type declarations, and
cross references that incorporate them, would still completely valid XRIs
subject to standard XRI resolution and thus can be "transparent" from that
standpoint.

Mike said that discussions have been confusing when the term "resolver" is
used because it's not clear whether the speaker is referring to XRI
resolution or another type of resolution. Dave, Drummond, and Marty all
commented that there could be other non-XRI forms of resolution associated
with XRIs that have $t metadata, but that this doesn't need to be part of
XRI resolution. Dave suggested that this really belonged in the scope of an
XRI consuming application and did not need to involved XRI infrastructure.

Mike observed that maybe in fact there could be implications for a $t space
for XRI resolution. Drummond amplified this by saying there could be
alignment between the $t space and a formal way to extend XRI resolution
(and that this would be very powerful.) However it was agreed that: a) this
would need to be developed in tandem, and b) none of this is in scope of XRI
2.0.

Steve brought up the option that perhaps this could be accomplished as a
subsegmentation of the $- (annotation) space. Dave pointed out that this
won't work because $- metadata is ignored in XRI resolution, and $t metadata
would still be significant in XRI resolution.

Marty explained that another part of the requirement for identifier
interoperability was to be able to have a referenceable specification for
globally understood identifier types. Drummond added that Peter has
recommended in several postings that this specification also address how
independent third parties could register into this space.

Mike said the clearest definition of the requirement for the proposed $t
space that he now understands is, "Identifier metadata that identifies the
type of the following subsegment."

Gabe feels it's very important that XRI resolution is not changed by this
proposal - an XRI containing a $t cross-reference would not resolve any
different way in XRI resolution than an identifier that contained another
type of cross-reference.

*****
ACTION: It was agreed that are not at the consensus point yet, but a clear
next step is for proponents to draft the proposed text for a $t section.
Marty agreed to spearhead this. It was also agreed to try to advance
discussion via the list over the next week, and if possible reach consensus
on advancing this on next Friday's call.


4) RESOLUTION ISSUES #7, #8, #9, #10, #13 REQUIREMENTS DISCUSSION
The detailed use cases and requirements for these proposal have been posted
at:

	
http://www.oasis-open.org/committees/download.php/14641/proposed-resolution-
use-cases-and-reqs-v1.doc 

******
DISCUSSION ON THE THURSDAY 8PM USA CALL:

We did not discuss this because the participants on the call had been
significantly involved with producing the use cases and requirements and so
they didn't have much to add.

******
DISCUSSION ON THE FRIDAY 9AM USA CALL:

We did not have time to discuss this agenda item. It was agreed that TC
members should read the posted proposal on use cases and requirements,
advance discussion via the list, and make this a topic for next week's call.

*****
ACTION: Continue discussion starting with the use cases and requirements
proposal.

*** END ***