Question: Yadis Service URIs in the OpenID Auth case

[Gabe Wachob]

I actually disagree with Drummond on this. 

I don't think XRI makes any such assertion - at least its not enforceable in
any way by XRI. 

In the Visa network, there is a concept of "stand-in processing" (STIP) -
where a message gets routed to Visa as a 'backup service provider'
invisibly. I had assumed that STIP would be implemented by having multiple
URI elements under a single service (ie multiple providers of the service). 

Drummond is making the opposite assumption. 

I think if OpenID Auth wants to impose this assumption (which is
OpenID-specific, I'd argue - sharing of DH keys is not a concept that
applies to XRI resolution per se) *on top* of XRI, that's fine. But I'd push
back on baking this into *XRI Resolution*.

	-Gabe

> -----Original Message-----
> From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
> On Behalf Of Johannes Ernst
> Sent: Thursday, August 24, 2006 9:26 PM
> To: Drummond Reed
> Cc: OpenID Discussion
> Subject: Re: Question: Yadis Service URIs in the OpenID Auth case
> 
> Ah. So Drummond, you are saying that while Yadis does not define
> this, the larger XRI framework makes the assumption that each service
> that's advertised in the XRDS file is advertised on behalf of exactly
> one provider, and it does not make sense, really, to have multiple
> service endpoints in the same service element that are operated by
> different providers.
> 
> I wasn't aware of that, and that's good to know. (Anybody want to
> write this up somewhere?)
> 
> That makes it much more possible to share D-H secrets between
> multiple endpoints within the same service element. But is that what
> we think should be the normal case?
> 
> Specifically, if I negotiate a shared secret with
>      http://example.com/
> will I be able to use that same shared secret with
>      httpS://example.com/ ?
> 
> I would probably argue that we should not assume that they use the
> same secret, but negotiate separately. For example, it would be
> rather difficult to share the same secret between
>      http://northkorea.example.com/
> and
>      http://usa.example.com/
> both of which are endpoints operated on behalf of a
>      example.com
> organization.
> 
> 
> On Aug 24, 2006, at 12:22, Drummond Reed wrote:
> 
> > To slightly tweak Kevin's feedback, I think Johanne's assumption #2
> > (that
> > the URIs are maintained by the same organization) is 100% valid if a
> > non-empty ProviderID element is present in the service endpoint (SEP).
> >
> > The ProviderID value is the only SEP element with a cardinality of
> > zero-or-one, so all the URIs in a SEP are associated with only one
> > provider.
> > This is important because if the ProviderID value is itself
> > resolvable to an
> > XRDS describing the Provider, it makes it easy to discover ProviderID
> > metadata that applies to all their SEPs.
> >
> > If the SEP has no ProviderID value, there's nothing technically to
> > prevent
> > different URIs in the SEP from going to different service
> > providers, but
> > it's clearly not a good practice.
> >
> > =Drummond
> >
> > -----Original Message-----
> > From: yadis-bounces at lists.danga.com [mailto:yadis-
> > bounces at lists.danga.com]
> > On Behalf Of Kevin Turner
> > Sent: Thursday, August 24, 2006 12:04 PM
> > To: yadis at lists.danga.com
> > Subject: Re: Question: Yadis Service URIs in the OpenID Auth case
> >
> > On Wed, 2006-08-23 at 17:54 -0700, Johannes Ernst wrote:
> >> Am I correct that it would be false to assume that:
> >>   - the two service URIs reside on the same server;
> >>   - are maintained by the same organization;
> >>   - use the same negotiated D-H secret (aka I negotiate with one
> >> service URI, but successfully use it with the other), even if they
> >> are very similar URIs.
> >
> > I think you are correct; none of those are 100% safe assumptions to
> > make.  Some of those might be sane conventions to establish, i.e.
> > "everything under a single Service tag is maintained by one provider,"
> > but I don't think we can count on that.  And even if you could
> > count on
> > that one, the other two wouldn't necessarily follow.
> >
> >
> 
> Johannes Ernst
> NetMesh Inc.