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

[Dirk Balfanz <balfanz@google.com>]

On Mon, Mar 23, 2009 at 9:20 PM, 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.

Seems to me we don't need (1): We don't have this in OpenID 2.0, and
the lack of it doesn't seem to be one of the things that's broken with
OpenID 2.0, so why introduce it now?

As for (2), I would think that an OP-local identifier is an
OpenID-specific thing that XRD doesn't/shouldn't worry about. It could
be one of those extensions that Eran has been blogging about:
http://www.hueniverse.com/hueniverse/2009/03/the-xrd-extensibility-model.html.

So I'd think it would look something like this:

<XRD xmlns:openid="http://specs.openid.net/...";>
  <Subject>http://claimed-id-of-the-user</Subject>
  <Link>
    <Rel>http://something-designating-openid-endpoint</Rel>
    <URI>http://location-of-op-endpoint</URI>
    <openid:LocalID>http://local-id-of-user-at-op</openid:LocalID>
  </Link>
</XRD>

Dirk.



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