Much of this doesn’t apply to XRD so you don’t need to worry
about it, but the thing to remember about XRI resolution is that, well, it is
for XRI resolution. If you use XRDS for other purposes, much of the spec doesn’t
apply to you. But John or Drummond can probably offer a better answer.
EHL
From: sappenin@gmail.com
[mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Sunday, January 18, 2009 8:06 AM
To: Eran Hammer-Lahav
Cc: xri@lists.oasis-open.org
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
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:
- 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).
- 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
|