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

["Chasen, Les" <les.chasen@neustar.biz>]

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