Re: [xri] XRD delegated identifer element (was part of: questions about

Subject: Re: [xri] XRD delegated identifer element (was part of: questions about LRDD / OpenID)

On Tue, Mar 24, 2009 at 5:20 AM, Drummond Reed <drummond.reed@cordance.net> wrote:

> Markus wrote:

>

> My intuitive answer would be that the delegate goes into XRD:Link:Alias, but I'm probably not really

> so close to this.

Yes, I had been thinking about the possibility of using “XRD:Link:Alias” as the new name for “XRD:Link:LocalID” too.

But here’s the conceptual problem with that. As currently proposed in http://wiki.oasis-open.org/xri/XrdOne/XrdSchema, XRD defines two elements at the XRD level to express identifiers identifying the resource described by the XRD:

1) XRD:Subject – the canonical URI for the resource.

2) XRD:Alias – any other synonymous URI for the resource.

The problem with using either of the element name “Subject” or “Alias” at the XRD:Link level is that it can lead to semantic confusion about whether the element is identifying the canonical ID or synonym ID of:

a) The resource that is the target of the link, or

b) The resource described by the XRD _as identified in the context of_ the resource that is the target of the link.

The second point is subtle but very important. As an example, say you have an XRD describing resource A with an XRD:Link to resource B. Inside this XRD:Link element, there are a total of four logical options for identifier elements:

1) The canonical URI for resource B (the target of the link).

2) Any other synonymous URI for resource B.

3) The canonical identifier (which may not be a URI) for resource A _in the context of resource B_, i.e., the canonical identifier by which resource B identifies resource A.

4) Any other synonymous identifier (which may not be a URI) for resource A _in the context of resource B_, i.e., any other identifier by which resource B identifies resource A.

Note that (1) is already recognized as a key use case for XRD 1.0, and that (3) is the well-know delegated identifier use case for OpenID. (2) and (4) are less compelling use cases, and thus may not warrant a standard XRD element (but don’t be surprised if they crop up).

So even if we limit our scope to (1) and (3), that means that we need _two_ child elements of <XRD:Link> that express:

* the canonical URI for resource B (the target of the link), AND

* The canonical identifier by which resource B identifies resource A.

That’s the semantics we need to express as clearly as possible in the element names. In other words, were we to “spell them out clearly”, these two element names might be:

1) <XRD:Link:Canonical-URI-For-Link-Target-Resource>

2) <XRD:Link:Canonical-URI-For-XRD-Subject-In-Context-Of-Link-Target-Resource>

If we agree those are the correct semantics, we just need to figure out the best short names that capture those semantics. Here’s one suggestion (but my no means the only one):

1) <XRD:Link:Object> This follows from RDF semantics. If the RDF subject of an XRD has the element name <XRD:Subject>, and each RDF predicate on that RDF subject is an <XRD:Link:Rel>, then a logical name for the RDF object of the link would be <XRD:Link:Object>

2) <XRD:Link:RelativeSubject> This follows from the above, i.e., if we use “Subject” to mean the resource described by the XRD, then “Relative Subject” would mean the same Subject, only as identified relative to the Link Object.

Thoughts?

=Drummond

From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Monday, March 23, 2009 11:29 AM
To: Drummond Reed
Cc: Will Norris; XRI TC
Subject: Re: [xri] XRD delegated identifer element (was part of: questions about LRDD / OpenID)

My intuitive answer would be that the delegate goes into XRD:Link:Alias, but I'm probably not really so close to this.

Markus

On Mon, Mar 23, 2009 at 6:52 PM, Drummond Reed <drummond.reed@cordance.net> wrote:

I'm latching onto the very last question Will put in his response to Markus'
XRD/LRDD questions this morning:

> To add one additional question... for the delegation use case, how is
> it expected that one would specify the OpenID delegate URL in XRD? I
> can't think of any existing XRD element that would be suitable for
> this, so I'm assuming we are expecting OpenID Discovery to define a
> new Link sub-element, like they already do in XRDS? Of course, if
> there is no delegate specified, you would just use the XRD Subject.

The "existing XRD element that would be suitable for this" is supposed to be
the LocalID element, listed near the bottom of
http://wiki.oasis-open.org/xri/XrdOne/XrdSchema. That was already the
element designed to replace the openid:delegate element for identifier
delegation in OpenID 2.0 discovery.

So, my first question is to confirm with Eran and everyone that this is
still the case, i.e., the <XRD:Link:LocalID> element is the element intended
to be used for identifier delegation by OpenID (or any other protocol that
needs local identifier delegation).

My second question is whether, if this is the case, we should (as we are
doing with all the other XRD 1.0 elements) revisit the semantics of the
element name itself and decide if there is a better alternative.

My third question is how this factors into trust verification, since you are
effectively asserting a synonym here.

Thoughts?

=Drummond

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xri message