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 10-11AM PT Thursday 2008-01-24


Following are the minutes for the unofficial telecon of the XRI TC at:

Date:  Thursday, 24 January 2008 USA
Time:  10:00AM - 11:00PM Pacific Time

Event Description:
Weekly unofficial call of the XRI Technical Committee.

ATTENDING

Gabe Wachob 
Markus Sabadello
John Bradley 
Marty Schleiff
Drummond Reed
Les Chasen


AGENDA

1) UPDATE ON TIMING OF OASIS STANDARD VOTE

After checking with Mary McRae, who coordinates specification votes for
OASIS, it turns out the timeline we proposed last week was just a little too
tight to comfortably fit within OASIS SLAs for turnaround times. So we need
to hold the vote in May rather than April. We reviewed the new proposed
timeline:

	- Feb 1: Public review of CD02 ends
	- Feb 15: First draft CD03 reflecting feedback (Type element reuse)
	- Feb 22: Final draft CD03, vote begins
	- Feb 25: Vote on CD03 begins
	- Feb 29: Vote on CD03 ends
	- Mar 10: Begin second public review (15 days)
	- Mar 25: End second public review
	- Mar 26: Begin Committee Specification vote
	- Apr 2: End Committee Specification vote
	- Apr 7: Submit for OASIS Standard vote
	- May 1: Begin OASIS Standard vote
	- May 31: End OASIS Standard vote

There was consensus to move forward with this, pending receipt of additional
comments from the current public review.


2) COMMENTS RECEIVED ON XRI RESOLUTION 2.0 COMMITTEE DRAFT 02 

We have received two comments from Eran Hammer-Lahav. The first one cover
the points he raised with us on an earlier telecon, and the second regarding
improved wording in section 12. 

* Drummond explained that Eran has also informally suggested that in Section
4 (XRDS Documents), we explicitly call out the attributes that apply to each
element. There was general consensus that would be easier to read.

* So far we have not seen any other comments or specific discussions. Marty
explained that the W3C URI mailing list is currently having an extensive
discussion about, "What does the URI represent?" Gabe explained that if a
URI returns a 303, then the identifier is abstract, whereas if the URI
directly returns the resource, then it is concrete. He pointed out that this
requires deferencing the identifier in order to know whether it is abstract
or concrete, vs. the XRI approach of having a uniform syntax and resolution
protocol for abstract identifiers.


4) DISCUSSION ABOUT OPENID IMPLEMENTATIONS OF XRI

John Bradley explained that he's been working extensively on integrating XRI
into OpenID implementations. He's been seeing very uneven implementations by
OpenID relying parties (RPs), largely due to their limited understanding of
the CanonicalID element and full XRDS processing rules. In particular, RPs
who follow the OpenID 2.0 specification
(http://openid.net/specs/openid-authentication-2_0.html) will send the value
of the CanonicalID element (typically an i-number) to an OP for
authentication, which is technically fine, but which introduces the problem
that the OP does not know which i-name the user entered at the RP.

John learned that several XRI i-brokers supporting OpenID worked out the
"append solution" to this problem, where the i-broker added the append
attribute value "qxri" to the <xrd:URI> element in their OpenID SEP. This
means the i-name entered at the RP should appear on the service endpoint URI
received by the OP. The OP can detect this and display the correct i-name to
the user.

While this approach works, it requires RPs to understand the processing of
the append attribute. And alternate solution John has implemented is for the
RP to simply send the OP whatever XRI was entered by the user (presumably
the i-name), and the OP authenticates that. John pointed out that it makes
no difference whether the RP sends the i-name or i-number to the OP, as the
RP is responsible for verifying that the i-number is a valid synonym anyway.
And the RP still persists the i-number.

There was consensus that both approaches work, and the latter required less
on the part of RPs. However there is still the issue of RPs processing XRDS
documents correctly if they go beyond simple "Yadis" usage, e.g., use
Redirects or Refs or non-trivial SEP selection.

Drummond suggested that the TC publish a document entitled, "Best Practices
for Using XRI and XRDS with OpenID" that can be widely referenced by OPs,
RPs, and developers. John agreed to spearhead this effort. Les volunteered
Wil to help with review. Drummond also agreed to help.

# DRUMMOND to create a "cover page" for this new document on the wiki.

# JOHN to proceed with a first draft of the document.




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