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

["Gabe Wachob" <gabe.wachob@amsoft.net>]

You guys are starting to sound like me... 1 year ago ;-)

	-Gabe

> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Thursday, January 18, 2007 11:08 AM
> To: Steven Churchill; xri@lists.oasis-open.org
> Subject: 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