OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


More inline...
 
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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]