Re: [xri] Identical-Priority XRD "URI" Elements...

[John Bradley <jbradley@mac.com>]

Yes extensions like PAPE use service types in that way to advertise  
there availability.

I however see this more like OP select which is not an extension so  
gets its own SEP separate from the openID 2.0.

Extensions add functionality to the authentication protocol and to  
this point are things that require extensions to the OP like PAPE and  
AX.

What you are proposing is like an extension to discovery and the RP  
idealy leaving the OP unmodified,  if I understand you correctly.

I think you need something like:

<xrd>
   <Service>
     <Type>http://specs.openid.net/extensions/pmae/1.0</Type>
     <URI1>https://op1.example.com/server</URI1>
     <URI2>https://op2.example.net/server</URI2>
     <LocalID1>https://acct2.example.net</LocalID1>
     <LocalID2>https://acct2.example.net</LocalID2>
   </Service>

   <Service>
     <Type>http://specs.openid.net/auth/2.0/signon</Type>
     <URI>https://op1.example.com/server</URI>
   </Service>

   <Service>
     <Type>http://specs.openid.net/auth/2.0/signon</Type>
     <URI>https://op2.example.net/server</URI>
     <LocalID>https://acct2.example.net</LocalID>
</Service>
</xrd>

That is just a quick example you need properly name-spaced elements to  
extend the XRD.
You may prefer to have localID be an attribute of your replacement for  
URI in whatever namespace you use.

One thing I don't see in your examples is a <LocalID>  element for  
each of the OP's.

I find it implausible that they are both going to authenticate the  
same claimed_id at least one needs delegation via the <LocalID>  
element and perhaps both.

If this is going to work with normal OPs you need to treat it as  
delegation.

I think this gives the user the best controll over what will happen.   
They may even define two multi headed configs at different priorities  
with different OPs in each config.

I don't see the current or proposed XRI /XRD specs precluding what I  
think you want to do.

=jbradley

On 11-Jan-09, at 1:04 AM, David Fuelling wrote:

> More inline...however don't see this as a
>
> On Sat, Jan 10, 2009 at 3:13 PM, John Bradley <jbradley@mac.com>  
> wrote:
> The XRI 2.0 spec is about how a resolver returns a service endpoint  
> or points based on the input selection criteria.
>
> There is nothing to stop a application from using the endpoints that  
> are returned as it likes.
>
> In XRI the SEPs may have refs and redirects so the resolver will  
> always follow the highest priority path.
>
> The requesting application should receive all the matching SEPS from  
> the last XRD in the chain, and can do with them as it likes.
>
> From an openID point of view I would be opposed to conflating this  
> sort of multi headed authentication with a regular openID  
> authentication.   The RP is going to have to be special anyway to  
> achieve this.
>
> Define a new Service type and include multiple URI in it.  You can  
> create any custom elements you like.
>
>
> I agree -- my "rought draft spec" currently definws a separate  
> Service Type (separate from the default OpenID Service Type),  
> although my informative example currently has two "Type" elements in  
> the same SEP.  Is this improper?  My assumption is that a regular  
> OpenID library could detect the openid "Type" and use it per usual,  
> and Multi-Auth libraries could detect the second "Type", and use the  
> extension.  For example:
> <xrd>
>   <Service>
>     <Type>http://specs.openid.net/auth/2.0/signon</Type>
>     <Type>http://specs.openid.net/extensions/pmae/1.0</Type>
>     <URI>https://op1.example.com/server</URI>
>     <URI>https://op2.example.net/server</URI>
>   </Service>
> </xrd>
> The only reason I didn't separate the two is because it would be  
> redundant to define the same OP's twice, for exampel:
> <xrd>
>   <Service>
>     <Type>http://specs.openid.net/auth/2.0/signon</Type>
>     <URI>https://op1.example.com/server</URI>
>     <URI>https://op2.example.net/server</URI>
>   </Service>
>   <Service>
>     <Type>http://specs.openid.net/extensions/pmae/1.0</Type>
>     <URI>https://op1.example.com/server</URI>
>     <URI>https://op2.example.net/server</URI>
>   </Service>
> </xrd>
> Though admitedly the two Type elements in my first example share the  
> same priority, so perhaps it should look something like this (with  
> MultiAuth specifying that when the two Type elements are found, both  
> URI's should be used as OP endpoints):
> <xrd>
>   <Service>
>     <Type priority="10">http://specs.openid.net/auth/2.0/signon</Type>
>     <Type priority="20">http://specs.openid.net/extensions/pmae/1.0</ 
> Type>
>     <URI>https://op1.example.com/server</URI>
>     <URI>https://op2.example.net/server</URI>
>   </Service>
> </xrd>
>
>
> I think that trying to reuse the existing endpoints in this way is a  
> mistake.   The user should clearly indicate that is what they want  
> to have happen in a new SEP like identifier select is a new SEP.
>
>
> I agree, though not sure if good form/function demands that they  
> should be separated (see above).  Any opinions there?

smime.p7s