Question: Yadis Service URIs in the OpenID Auth case

[Drummond Reed]

Johannes, see ### inline.

-----Original Message-----
From: Johannes Ernst [mailto:jernst+lists.danga.com at netmesh.us] 
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.

### Yes. 

I wasn't aware of that, and that's good to know. (Anybody want to  
write this up somewhere?)

### I have added it to the XRI Resolution 2.0 Working Draft 11 editor's
issues/task list as item #26 (see
http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11#head-451250f0bed73
c52cb9e1000d4eb4557e3ee05cf). 

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.

### I'm not expert enough to answer that about shared secret negotiation. I
do know that Peter Davis advised that wrt SAML metadata, a single ProviderID
for a service provider -- that resolves to an XRDS contained a service
endpoint (SEP) for obtaining a SAML metadata document -- could provide the
metadata not just for all the URIs at one SEP, but even for all the SEPs
from that service provider. (Doing this requires using an indexing feature
in the SAML metadata document format -- each SAML request carries an index
pointer to the relevant metadata.)

### So the concept of sharing service metadata both within and across SEPs
is definitely on the table. Peter's on vacation this week (and I think
next), but he can reply in more detail once he's back.

### Keep in mind that in this case, you are not negotiating with the SEP
itself but with the ProviderID, which has its own XRDS document with its own
set of SEPs.

=Drummond 


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.