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 2008-01-10

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

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

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


John Bradley 
Drummond Reed 
Gabe Wachob
Wil Tan
Andy Dale

Eran Hammer-Lahav



Eran Hammer-Lahav, author of the OAuth Discovery spec (see first draft at
http://oauth-specs.googlecode.com/svn/discovery/drafts/1/spec.html), was
invited to join this call so he could provide feedback on XRI Resolution 2.0
Committee Draft 02 based on his work including XRDS documents in OAuth

Eran explained that his second draft will include the "simple" profile
of XRDS (which he calls XRDS-Simple) on which Gabe, Wil, Markus, and
Drummond volunteered to assist him. For both XRDS-Simple and OAuth
Discovery, he has the requirement to "type" an XRD, very much like XRDS
documents allow a Service to be typed today. XRDs in fact may need multiple
types, for example, one to assert that it is an XRDS-Simple type, and one to
assert that it is OAuth Discovery compliant.

Although Eran could create an element in the OAuth namespace for this, this
is clearly the semantics for which the current xrd:XRD/xrd:Service/xrd:Type
element is intended. In addition, the ability to include zero-to-n xrd:Type
elements as child elements of the XRD element would also support multiple
typing the same way it works for Service typing as a child of the
xrd:XRD/xrd:Service element today. 

However for XRDS-Simple to use xrd:XRD/xrd:Service/xrd:Type as
xrd:XRD/xrd:Type would require a change to the XRD schema to allow it there.
(Ironically, this is the precise inverse of what we did for the <LocalID>
element, which used to exist only at the XRD level until the OpenID
specification editors had a strong use case to need at the Service level and
requested that change.)

Discussion points:

* Andy explained that he had the same use case was when he was working with
Tibco on assigning XRIs to different resources in computer networks (storage
servers, app servers, web servers, etc.) Each type of server had different
types of Services associated with them, so typing the XRDs would be the
easiest way to identify a specific set of related services.

* John asked if there would be ambiguity about what the Type element
described at the XRD level. The consensus was that in all cases you are
describing the XRD. You MAY be describing/typing the resource the XRD
describes, but that is out of scope for XRI Resolution.

* Eran explained that his need is immediate, as he needs to include this in
OAuth Discovery 2.0 (he plans to put XRDS-Simple in the appendix). He said
the first generation of OAuth Discovery is automated endpoint configuration,
and for that he only XRDS-Simple and typed XRDs. The second generation of
OAuth Discovery may need more of the full power of XRDS architecture because
it will move into lightweight automated service discovery.

* Eran explained one example where he needs an XRD to have three Types: 
  - XRDS-Simple type
  - OAuth Discovery type
  - Extended type 

* There was consensus among those on the call that this seemed like a good
solution, and would only require a relatively minor (1-3 paragraph) revision
to the spec. This could be accomplished in one revision cycle, which the TC
currently expects in order to incorporate comments from the public review

* The TC requested that Eran submit this suggestion via the xri-comment
mailing list. Eran said he would be happy to do that.

# DRUMMOND to send Eran a link to the comment submission instruction page.


Attached at the end of this agenda is a request from June Leung, chair of
the IDtrust Member Section, for all ITDMS TCs to submit budget requests for
projects they would like to accomplish in 2008.

Since these requests must be submitted by Friday, January 11, we discussed
potential options. These included:

* Interop event(s) - potentially at Internet Identity Workshop(s) or
* Marketing activities: Press tour after XRI 2.0 Standards vote.
* Tech writer for an XRI/XRDS Deployment Guide.
* Market education.
* F2F meetings (don't know if this qualifies).

# DRUMMOND to send an email to June reflecting these items.


We ran out of time to discuss this topic, but members are encouraged to
contribute to the following wiki pages:


We will move this agenda item to next week's telecon.



Dear TC Chairs,

The IDTrust Member Section Steering Committee is planning our 2008 Member
Section budget, and would like to provide as much support as we can to
Member Section TC's in addition to the broader charter of the Member
Section.  Although we realize that TC's operate independently, there may be
projects or initiatives where some Member Section budget support can be
useful to your work.  

If there are any projects / work efforts you would like to accomplish next
year where Member Section resources can help, please provide us with the
initiative and some high level budget estimates by January 11, so we can
consider the request at the January 16 steering committee meeting.  Please
note that there are limited funds available for our budget, so we might not
be able to approve all proposed work efforts.

Here is the information we need to help with our review:

Name  of Initiative :
Background / Idea:
Start/Completion Date:
Objective and Goals:
Benefit statement: 
Estimated Resource Need: 

The Steering Committee will meet on Jan 16/08 to discuss the proposals

Please send your requests as well as any questions to Dee Schur, who has
been supporting the Member Section.  Dee's email address is

We look forward in working with you in 2008!


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