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] XRD delegated identifer element (was part of: questions about LRDD / OpenID)



On Mar 23, 2009, at 10:13 PM, Dirk Balfanz wrote:

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

Can someone remind me what the use case is for #1 (including the  
canonical URI for the link target resource).  I want to say it has to  
do with one of the trust or signing profiles, but am not 100% sure.   
If that's right, then I absolutely believe we need to be thinking  
about it.  No, it's not in OpenID 2.0, but 1) OpenID isn't the only  
use-case we're thinking about and 2) I'm sure that as OpenID is used  
in more high-risk transactions (PayPal joined the OpenID board, after  
all) it's absolutely going to be something they will want.  If that  
element isn't about trust, then just ignore me :)


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

well if you call it a "OP-local identifier" then it certainly sounds  
like something specific to OpenID.  But what about my photo sharing  
service?  Flickr doesn't know me by my OpenID, I have a different  
identifier there.  I would argue that the same is true for the vast  
majority of services today which one might want to list in their  
XRD... most of those services have their own identifier of some sorts  
for users.  This was part of XRDS, after all, so I'm sure Drummond or  
John could probably give a clearer reason for why its there.

-will


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