RE: [xdi] Agenda: Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-03-08

["Steven Churchill" <steven.churchill@xdi.org>]

Recall that we had a discussion previously (attached) that pointed out that
issue #37 would require changing the section on trusted resolution and add
complexity that is only motivated as a workaround for those who are
reluctant (or simply unwilling) to simply modify their XRD at their ibroker.

~ Steve


-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Wednesday, March 07, 2007 6:09 PM
To: xri@lists.oasis-open.org; xdi@lists.oasis-open.org
Cc: andy.dale@ootao.com
Subject: [xdi] Agenda: Joint XRI & XDI TC Telecon 10AM PT Thursday
2007-03-08

Following is the agenda for a joint unofficial telecon of the XRI and XDI
TCs at:

Date:  Thursday, 8 March 2007 USA
Time:  10:00AM - 11:30AM Pacific Time

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

TO ACCESS THE AUDIO CONFERENCE:
    Dial In Number: 571-434-5750
    Conference ID: 5474

TO ACCESS THE WEB CONFERENCE:
    Click on the link below:
    http://209.173.53.68/Login/ParticipantLogIn.asp
    Conference ID: 5474

We recommend that you test your computer's compatibility before the start of
the web conference by accessing the System Test page:
http://209.173.53.68/systest/SystemTest.asp


AGENDA

1) REMINDER TO REGISTER FOR THE OASIS SYMPOSIUM AND XRI/XDI F2F MEETING
Hotel and registration discount deadlines are approaching. See

	http://www.oasis-open.org/events/symposium/2007/index.php 


2) IDENTITY SELECTOR SUPPORT FOR XRI

A meeting with Kim Cameron and the MS Cardspace team is still pending,
however we are still waiting on feedback from Andy Dale an Paul Trevithick
regarding the list of potential issues regarding XRIs and Cardspace.
(Drummond pinged Andy and hopefully he'll be able to update us prior to or
on the call.)

3) XRI SYNTAX 2.1 ABNF (MAIN TOPIC)

Since the proposed ABNF is now the key gating item for XRI Syntax 2.1, on
which both XRI Syntax 2.0 and XRI $ Dictionary 2.0 have a dependency,
closing on this is now our top priority. Please review the recent messages
to the email list and the following wiki pages prior to the call:

	http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1

	http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs 

4) XRI RESOLUTION 2.O WD 11 - SERVICE REF ISSUE (#37)

If there is any time left, we will discuss and try to close on issue #37. A
second variant on the last proposal has been posted. See:

	
http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11#head-07b8fdfe8d971
7a6e7bd7827a68a78858bee0c7f

--- Begin Message ---

• From: "Chasen, Les" <les.chasen@neustar.biz>
• To: "Steven Churchill" <steven.churchill@xdi.org>,<xri@lists.oasis-open.org>
• Date: Thu, 18 Jan 2007 11:07:52 -0800

Title: RE: [xri] About XRI resolution open issue #37

They can already add any SEPs they want.  We have a requirement to allow
custom new fields such as the openid:delegate to SEPs.  We also want to
allow custom extensions at the XRD level.  Does this address the =avery
issue? 

IMHO, I think it is a huge mistake to undertake anything that
significantly changes our service selection logic.  It is complicated
enough with out extra flows.  Any changes that require lots of thought
and validation should be tossed out.  We need to get this thing out of
WD status and into the standards flow once and for all.

email: @neustar*les.chasen
contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
 
 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Thursday, January 18, 2007 1:06 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] About XRI resolution open issue #37
>
>
> It seems that we are introducing complexity to the Resolution spec
> primarily
> as a workaround: people cannot manipulate their XRD as they wish, so
we
> are
> adding a back door. We are letting them specify an XRD proxy that they
> *can*
> manipulate as they wish.
>
> I see two solutions:
>
> 1) Add the back door XRD proxy solution to the resolution spec (and
its
> attendant complexity illustrated in the emails below.)
>
> 2) Specify in the GSS that people be able to add what they want to
their
> XRD.
>
> ~ Steve
>
>
> -----Original Message-----
> Steve Churchill wrote:
>
> I think that Wil's proposal would work fine.
>
> But it would require some changes to the SAML trusted resolution
section
> of
> the spec. The problem with the spec currently is that it talks about
> trusted
> "resolution" (conceivably this is trusted "XRI resolution") and thus
it
> deals exclusively with an Auth Res Service in section 6.2, etc.
>
> Section 6 would need to be modified to deal with "trusted XRD proxy
> dereferencing" and specify what Wil has proposed below.
>
> ~ Steve
>
>
> -----Original Message-----
> Wil Tan wrote:
>
> It took me a while to wrap my head around this after ignoring the
> trusted resolution sections of the draft for so long.
> Let me try correcting the following XRDS in Steve's example.
>
> Steven Churchill wrote:
> >
> > Let's look at the degenerate case first: just resolving a single
child
> > in the root.
> >
> > Say we want to resolve =steven.churchill for its OpenID service -
and
> > that I set the highest priority URI for my OpenID service with a
> > xrdProxy="true".
> >
> > <XRDS ref="=steven.churchill">
> >
> > <XRD>
> >
> > <Query>*steven.churchill</Query>
> >
> > .
> >
> > <ProviderID>xri://=</ProviderID>
> >
> >
> <saml:Assertion>contains-hash-signed-by-equals-private-
> key</saml:Assertion>
> >
> > <Service>
> >
> > <Type select="true">http://openid.net/signon/1.0</Type>
> >
> Insert here: <ProviderID>steve's i-number or some other persistent
> URI</ProviderID>
> Insert here: <KeyInfo>public-key-of-the-above-ProviderID</KeyInfo>
> >
> > <URI xrdProxy="true">https://stevenchurchill.com/XRD/OpenID</URI>
> >
> > </Service>
> >
> > </XRD>
> >
> > <XRD proxy="true" (or perhaps this attribute is not needed if indeed
> > this is signed) >
> >
> > <Query>*steven.churchill</Query>
> >
> > .
> >
> > <ProviderID>what-goes-here?</ProviderID>
> >
> Replace above with: <ProviderID>steve's i-number or some other
> persistent URI</ProviderID>
>
> > <saml:Assertion>contains-hash-signed-by-whom?</saml:Assertion>
> >
> Replace above with
>
<saml:Assertion>signed-by-ProviderID-verifiable-using-KeyInfo-of-previou
s-
> Se
> rvice/KeyInfo</saml:Assertion>
> >
> > <Service>
> >
> > <Type select="true">http://openid.net/signon/1.0</Type>
> >
> > <URI append="qxri" priority="1">https://2idi.com/openid/</URI>
> >
> > <URI append="qxri" priority="2">http://2idi.com/openid/</URI>
> >
> > </Service>
> >
> > </XRD>
> >
> > <XRDS>
> >
> > Drummond, is the hash in the second XRD signed by my own private
key?
> > If so, do I need to add a $res*auth service to my *steven.churchill
> > XRD just to provide the <KeyInfo> (even though I really don't want
> > *steven.churchill to be a namespace)?
> >
> So, the URI that serves your "proxied" XRD has to be assigned a
> ProviderID. Its identifier and public key should be published by the
> Service element that led the resolver to fetch this URI, using the
> Service/ProviderID and Service/ds:KeyInfo elements respectively.
>
>
> =wil

--- End Message ---