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...


Eran,

Great feedback.  Just wondering when section 17 of (XRI) Resolution  2.0 applies to stuff like this (if at all)?

In my case, by specifying that equal-priority URI's be chosen and used together (instead of one chosen at random, per section 4.3.3 of XRI Resolution), am I not in violation of the Section 17 directive that states: "Extension elements MUST NOT require new interpretation of elements defined in this document."?

(I suppose one could argue that I have no extension elements -- only extending the functionality of attributes -- so 17 doesn't apply?)

Thanks!

David

On Sat, Jan 10, 2009 at 12:33 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The general approach is to "override" the random selection process indicated by the XRI spec with an XRDS:XRD:Service:Type element that means (to those clients supporting your extension) that they should go back and pick all the other priority-equal Services with the same special Type and follow the rest of the flow.

 

XRI resolution tells you how to find the most suitable Service endpoint. But there is nothing there to stop you from adding a second step (which is to find the other service with the same type and equal priority).

 

EHL

 

From: sappenin@gmail.com [mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Saturday, January 10, 2009 11:09 AM
To: xri@lists.oasis-open.org
Subject: [xri] Identical-Priority XRD "URI" Elements...

 

Hey List,

I'm looking for some guidance...

I've been thinking about how to enable what I call "two-headed auth" in OpenID (which is where two OP's must provide a valid assertion to an RP before the RP grants access to protected resources), and have come up with one paticular way of doing this[1].

Basically, this just overrides (clarifies?) some of the behavior of XRI Resolution 2.0[2], section 4.3.3(3).  This section currently indicates that a consuming application which encounters multiple, identical-priority elements should just pick one of these elements at random.  My "extension/clarification" instead says that the consuming application SHOULD utilize both of the elements in tandem (instead of just one at random).  The net effect is this enables and instructs an RP to use 2 OP's to verify ownership of a particular OpenID.

So, I have the following questions relating to this:

  1. Is the behavior I've outlined in this message, and in my "very rough draft spec"[1], acceptable per the current version of XRI Resolution?  (The use of the word SHOULD leads me to beleive that it is).
  2. However, if the answer is "no", how big of a deal would it be to loosen the language of section 4.3.3(3) to read something like this (my additions are indicated between brackets []):
    "If two or more instances of the same element type have identical priority attribute values (including the null value), the consuming application SHOULD [either] select one of the instances at random[, or utilize all of the equivalent priority elements together per the requirements of each particular Service]. This consuming application SHOULD NOT simply choose the first instance that appears in XML document order."

Thanks for any guidance here.  I'd also be open to hearing if there's a better way to do what I'm trying to do with XRD.

Thanks!

David


[1] http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-1.html
[2] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.html




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