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] Thoughts on XRD-to-resource cardinality


this approach makes sense to me.  On the trust profile topic, however,  
it's not clear to me how, in HTTP resolution mode, we can establish  
any bonding between the resource identifier and the XRD signing key.

Having said that, I am preparing to publish my DNS trust profile,  
which might ease this situation.  I'll drop a note on the list when  
I've got it written up on the wiki.

=peterd

On Jan 28, 2009, at 1:21 AM, Eran Hammer-Lahav wrote:

> This is an interesting idea but I am not sure we need to go this  
> far. Brian, Breno, Dirk, and I had an interesting conversation about  
> this today.
>
> Ignoring the theoretical ideas and focusing on actual use cases, we  
> have some clear requirements:
>
> 1. Allow multiple resources to point (link) to a single XRD (with a  
> single URI).
> 2. Allow an XRD to clearly state its subject.
> 3. Allow an XRD to establish its authority (via trust) to make  
> claims about its subject.
> 4. Allow an XRD to declare how a set of URIs relate to each other  
> (equiv, canonical, etc).
>
> There is no clear use case for an XRD to:
>
> 5. Allow an XRD to state multiple subjects, unrelated to one another.
> 6. Allow multiple entities (certificates) to sing a single XRD.
>
> ---
>
> Here is how each can be addressed. Define the following XRD-level  
> elements (straw man names):
>
> CanonicalURI - the canonical identifier of the XRD subject resource  
> (0 or 1).
> EquivURI - an alias of the subject resource, a different URI to the  
> same resource (0 or more).
>
> 1. While resources can share any XRD, even with a stated subject, it  
> will probably fail trust verification in most applications if the  
> URI being discovered is not listed in one of the two URI elements  
> above. I think we should name the kind of XRD that has no URI  
> subject declared internally, and has its subject derived from the  
> URI being discovered pointing to it. A sort of "uncommitted" XRD.
>
> 2. The XRD can use any combination of the URI elements to declare  
> its subject. Usually if it contains a single URI, it will use the  
> CanonicalURI, and if more than one, it can have one canonical and  
> many equiv, or just many equiv without clearly choosing a canonical.
>
> 3. To make trust simple enough, there has to be a connection between  
> the XRD subject and the subject of the certificate used to sign it.  
> In theory, any one of the URIs can be signed, including an non- 
> canonical one. But usually the canonical URI will be the one signed.
>
> 4. The clear meaning of the two URI elements allow declaring how  
> multiple URI relate to one another, while the XRD describes a single  
> resource.
>
> ---
>
> This approach simply adds to what we have today the explicit ability  
> to not state the subject of an XRD, and allow such uncommitted  
> descriptor to be used by multiple resources.
>
> We should discuss the elements names (I am not against the current  
> ___ID elements, but they don't translate well to the non-identity  
> use cases, even if the ID maps to the I in URI...), as well as more  
> such URI relationships at the XRD level.
>
> EHL
>
>
>> -----Original Message-----
>> From: Drummond Reed [mailto:drummond.reed@cordance.net]
>> Sent: Tuesday, January 27, 2009 10:00 PM
>> To: 'XRI TC'
>> Subject: [xri] Thoughts on XRD-to-resource cardinality
>>
>> I will be offline Thursday and Friday travelling to a memorial, so I
>> want to
>> contribute here on the list to advance today's discussion about
>> XRD-to-resource mapping
>> (http://wiki.oasis-open.org/xri/SelfServeAgenda#head-
>> a4044b7035eb441c2674549
>> d07ccaf27daed8970).
>>
>> As I said on the call, the concept of a one-to-many mapping between  
>> an
>> XRD
>> and the resources it describes is a mind-expander for those of us who
>> have
>> been living a one-XRD-to-one-resource worldview for a few years now.
>> But the
>> use case -- being able to get and cache one XRD to describe  
>> potentially
>> a
>> very large number of resources (such as an entire site) is  
>> compelling.
>>
>> Under a one-to-many mapping, I believe Eran's right that the  
>> concept of
>> asserting a synonym (not just CanonicalID but any synonym) pretty  
>> much
>> goes
>> away. The only synonym assertion I could see providing is some form  
>> of
>> aliasing template that would apply to the URIs of all the described
>> resources (e.g., every that maps to the http://foo.example.com/*
>> template
>> can all be mapped to the http://bar.example.com/* template).
>>
>> But that appears to be of limited use, and probably not appropriate  
>> for
>> assigning CanonicalIDs (which is usually a mapping from a  
>> reassignable
>> to a
>> persistent identifier).
>>
>> But the rest of the XRD metadata and Link metadata still seems
>> appropriate,
>> i.e., it applies as much to an individual resource (one-to-one  
>> mapping)
>> as
>> it does to a group of resources (one-to-many mapping).
>>
>> So what I'm wondering is if maybe there should be a clear way of
>> indicating
>> the cardinality of the XRD. In other words, a child element of the  
>> root
>> XRD
>> element that indicates whether it is it an individual XRD (one-to-one
>> mapping) or a group XRD (one-to-many mapping).
>>
>> If there was a choice between two mutually exclusive options for that
>> child
>> element, then all the other elements that are appropriate only for  
>> one
>> or
>> the other (CanonicalID, EquivID, URIMap, etc.) could follow as  
>> children
>> of
>> that element.
>>
>> Here's a simple example using the element names <Resource> and
>> <ResourceGroup>:
>>
>> INDIVIDUAL XRD:
>>
>> <XRD>
>>    <Expires>2009-01-01T08:30:00Z</Expires>
>>    <Resource>
>>        <CanonicalID>http://example.com/resource/1</CanonicalID>
>>        <EquivID>http://example.net/resource/1</EquivID>
>>    </Resource>
>>    <Type>http://example.com/type/profile_photo</Type>
>>
>>    <Link>
>>        <URI>http://example.com/resource/2</URI>
>>        <Rel>http://example.com/rel/profile</Rel>
>>    </Link>
>> </XRD>
>>
>> GROUP XRD:
>>
>> <XRD>
>>    <Expires>2009-01-01T08:30:00Z</Expires>
>>    <ResourceGroup>
>>        <URIMap>http://example.com/resource/*</URIMap>
>>    </ResourceGroup>
>>    <Type>http://example.com/type/photos</Type>
>>
>>    <Link>
>>        <URI>http://example.com/service/1</URI>
>>        <Rel>http://example.com/rel/some-group-service</Rel>
>>    </Link>
>> </XRD>
>>
>> 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
>
>
> ---------------------------------------------------------------------
> 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
>

Peter Davis: NeuStar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ 
  [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for  
the use of the recipient(s) named above and may contain confidential  
and/or privileged information. If you are not the intended recipient  
you have received this e-mail message in error and any review,  
dissemination, distribution, or copying of this message is strictly  
prohibited. If you have received this communication in error, please  
notify us immediately and delete the original message.




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