[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Thoughts on XRD-to-resource cardinality
--Apple-Mail-343--694904865 Content-Type: multipart/alternative; boundary=Apple-Mail-342--694904939 --Apple-Mail-342--694904939 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit At the moment sites publish information about there openID return to URI, Oauth endpoints, IDIB endpoints etc in a single XRDS that is found by doing Yadis discovery on the domain. It may be a good idea to include a link to that info on every page, but that strikes me as a bit inefficient. Site meta and a XRD describing the site in the abstract should suffice for most purposes. Putting link headers on site URI that apps like oAuth may try to do discovery on makes sense to me as well. Personally I like the idea of every URI using link headers to describe where to get meta-data about it. I just don't think the practice will be common enough that apps are not going to check site-meta or the XRD for the site first. I think that the XRD for that sort of descripttion of the site itself can be hosted by the site. The delegation problem comes up when theboot.com wants AOL to host the XRDs for its users and provide a white label OP service while maintaining the claimedID as a theboot.com URI. If the XRD's are hosted at AOL who signs them, if they are signed by the the sites SSL cert is it reasonable for theboot.com to hand that over to AOL. If not how is the boot to indicate that AOL is authoritative to sign the XRD for the boot.com? I think that is the meet of delegation issue. =jbradley On 28-Jan-09, at 1:49 PM, George Fletcher wrote: > I guess I was considering the case where some consumer does a > "discovery" request on the URL http://www.theboot.com/stories/today/top5.html > . By default, as I understand it, in a one-to-one mapping of XRD to > resource, that URL would have no XRD and discovery would fail. Isn't > this the use case that Brian was referring to on the conf call > yesterday? not wanting to have to generate an XRD for every single > URL in a large site? > > I probably confused things by referencing multiple classes of use > cases in the example. I see the following as important... > > 1. Site delegation to OpenID RP SaaS provider > > 2. Identity in the browser support > > 3. OAuth endpoints (or instance in order to access a protected [e.g. > user's play list] resource) > > All of the above should be discoverable from any URL at the site. If > discovery flow implies to walk up the path until you find an XRD, > then this wouldn't really be necessary. But if that's the case, then > I don't understand the use case Brian mentioned on the phone. I > assumed that the one XRD to many resources issue was about > describing the meta-data for all those resources. For example, all > the photo related URL on this site are protected by one XRD that > defines the link to the OAuth endpoints where authorization is > required before access is granted. > > Thanks, > George > > John Bradley wrote: >> George, >> >> On your example I don't quite get why theboot.org needs to do >> anything special to delegate its RP functionality. >> Yes it needs to have the correct return to URI in the site XRD as >> it needs to now in its XRDS. >> >> I don't see any requirement to add link headers to all the pages >> unless we are talking about some sort of identity in the browser >> application. >> >> Are you talking about theboot.org providing OP services to its >> users via there home pages and delegating that to a third party? >> >> I see that as being the use case for delegating the XRD while still >> wanting to maintain https://theboot.com/user as the openID claimed >> ID. >> >> =jbradley >> >> On 28-Jan-09, at 1:09 PM, George Fletcher wrote: >> >>> I too am trying to work through the trust issues with HTTP >>> resolution. I'm interested in how the DNS trust profile can help. >>> Here is a concrete (though hypothetical) use case... >>> >>> -------- >>> A web site (theboot.com; country music content site) supports >>> OpenID authentication via a delegated service implementing the >>> OpenID Relying Party support. The web site also supports OAuth >>> access to a user's comments and favorite music lists created as >>> part of the site. >>> >>> To Brian's point on the conf call, theboot.com doesn't want to >>> generate XRD's for every resource on the site so uses the Link >>> header mechanism to specify a "uncommitted" XRD for the entire >>> site. In this "uncommitted" XRD there is neither a CanonicalID or >>> EquivID element because neither make sense. (Note that this may be >>> better solved with /site-meta. Maybe the Link header could point >>> directly to the site-meta with a different rel= value?). >>> >>> The XRD references related resources for OpenID authentication, >>> OAuth endpoints and maybe the IdentityInTheBrowser endpoints. >>> --------- >>> >>> As an invoker of services at this web site, I'd like to know with >>> some assurance that the XRD pointed at by the Link header is >>> "authoritative" for the URI used to discover it. Even if the XRD >>> is signed, the Consumer doesn't have any way to determine if that >>> signer is authoritative for the initial URI. >>> >>> Would it make sense to allow for an optional <TrustURIMap> element >>> in the XRD that establishes some level of trust by requiring that >>> both the initial resource URI and the signing Subject/ >>> SubjectAltName match the <TrustURIMap>? >>> >>> If "trust" is not required or supported by the site, then the >>> <TrustURIMap> would not be present and the Consumer would need to >>> determine what to do. Determining whether the <TrustURIMap> is >>> "specific" enough to provide a reasonable level of trust is out of >>> scope for the spec and must be determined by the Consumer. >>> >>> Thanks, >>> George >>> >>> >>> Peter Davis wrote: >>>> >>>> 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 <mailto: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. >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 --Apple-Mail-342--694904939 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">At the moment sites publish = information about there openID return to URI, Oauth endpoints, = IDIB endpoints etc in a single XRDS that is found by doing = Yadis discovery on the domain.<div><br></div><div>It may be a good idea = to include a link to that info on every page, but that strikes me as a = bit inefficient. Site meta and a XRD describing the = site in the abstract should suffice for most purposes. Putting = link headers on site URI that apps like oAuth may try to do = discovery on makes sense to me as = well.</div><div><br></div><div>Personally I like the idea of every = URI using link headers to describe where to get meta-data = about it. I just don't think the practice will be common enough = that apps are not going to check site-meta or the XRD for the site = first.</div><div><br></div><div>I think that the XRD for that sort of = descripttion of the site itself can be hosted by the = site.</div><div><br></div><div>The delegation problem comes up when = theboot.com wants AOL to host the XRDs for its users and provide a white = label OP service while maintaining the claimedID as a theboot.com = URI.</div><div><br></div><div> If the XRD's are hosted at AOL = who signs them, if they are signed by the the sites SSL = cert is it reasonable for theboot.com to hand that over to AOL. = If not how is the boot to indicate that AOL = is authoritative to sign the XRD for the = boot.com?</div><div><br></div><div>I think that is the meet of = delegation issue.</div><div><br></div><div>=3Djbradley<br><div><div>On = 28-Jan-09, at 1:49 PM, George Fletcher wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>I = guess I was considering the case where some consumer does a "discovery" = request on the URL <a = href=3D"http://www.theboot.com/stories/today/top5.html";>http://www.theboot= .com/stories/today/top5.html</a>. By default, as I understand it, in a = one-to-one mapping of XRD to resource, that URL would have no XRD and = discovery would fail. Isn't this the use case that Brian was referring = to on the conf call yesterday? not wanting to have to generate an XRD = for every single URL in a large site?<br><br>I probably confused things = by referencing multiple classes of use cases in the example. I see = the following as important...<br><br>1. Site delegation to OpenID RP = SaaS provider<br><br>2. Identity in the browser support<br><br>3. OAuth = endpoints (or instance in order to access a protected [e.g. user's play = list] resource)<br><br>All of the above should be discoverable from any = URL at the site. If discovery flow implies to walk up the path until you = find an XRD, then this wouldn't really be necessary. But if that's the = case, then I don't understand the use case Brian mentioned on the phone. = I assumed that the one XRD to many resources issue was about describing = the meta-data for all those resources. For example, all the photo = related URL on this site are protected by one XRD that defines the link = to the OAuth endpoints where authorization is required before access is = granted.<br><br>Thanks,<br>George<br><br>John Bradley = wrote:<br><blockquote type=3D"cite">George,<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">On your example = I don't quite get why theboot.org needs to do anything special to = delegate its RP functionality.<br></blockquote><blockquote = type=3D"cite">Yes it needs to have the correct return to URI in the site = XRD as it needs to now in its XRDS.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I don't see any = requirement to add link headers to all the pages unless we are talking = about some sort of identity in the browser = application.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Are you talking = about theboot.org providing OP services to its users via there home = pages and delegating that to a third party?<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I see that as = being the use case for delegating the XRD while still wanting to = maintain <a href=3D"https://theboot.com/user";>https://theboot.com/user</a>= as the openID claimed ID.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">=3Djbradley<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">On 28-Jan-09, = at 1:09 PM, George Fletcher wrote:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">I too am trying to work through the trust issues with HTTP = resolution. I'm interested in how the DNS trust profile can help. = Here is a concrete (though hypothetical) use = case...<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">--------<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">A web site (theboot.com; country = music content site) supports OpenID authentication via a delegated = service implementing the OpenID Relying Party support. The web site also = supports OAuth access to a user's comments and favorite music lists = created as part of the site.<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">To Brian's point on the conf = call, theboot.com doesn't want to generate XRD's for every resource on = the site so uses the Link header mechanism to specify a "uncommitted" = XRD for the entire site. In this "uncommitted" XRD there is neither a = CanonicalID or EquivID element because neither make sense. (Note that = this may be better solved with /site-meta. Maybe the Link header could = point directly to the site-meta with a different rel=3D = value?).<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">The XRD references related = resources for OpenID authentication, OAuth endpoints and maybe the = IdentityInTheBrowser endpoints.<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">---------<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">As an invoker of services at = this web site, I'd like to know with some assurance that the XRD pointed = at by the Link header is "authoritative" for the URI used to discover = it. Even if the XRD is signed, the Consumer doesn't have any way = to determine if that signer is authoritative for the initial = URI.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Would it make sense to allow for = an optional <TrustURIMap> element in the XRD that establishes some = level of trust by requiring that both the initial resource URI and the = signing Subject/SubjectAltName match the = <TrustURIMap>?<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">If "trust" is not required or = supported by the site, then the <TrustURIMap> would not be present = and the Consumer would need to determine what to do. Determining whether = the <TrustURIMap> is "specific" enough to provide a reasonable level = of trust is out of scope for the spec and must be determined by the = Consumer.<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">Thanks,<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">George<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Peter Davis = wrote:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">=3Dpeterd<br></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">On Jan = 28, 2009, at 1:21 AM, Eran Hammer-Lahav = wrote:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = Ignoring the theoretical ideas and focusing on actual use cases, we > = have some clear = requirements:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 1. = Allow multiple resources to point (link) to a single XRD (with a > = single URI).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 2. = Allow an XRD to clearly state its = subject.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 3. = Allow an XRD to establish its authority (via trust) to make > claims = about its subject.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 4. = Allow an XRD to declare how a set of URIs relate to each other > (equiv, = canonical, etc).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = There is no clear use case for an XRD = to:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 5. = Allow an XRD to state multiple subjects, unrelated to one = another.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 6. = Allow multiple entities (certificates) to sing a single = XRD.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = ---<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> Here = is how each can be addressed. Define the following XRD-level > elements = (straw man names):<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = CanonicalURI - the canonical identifier of the XRD subject resource > (0 = or 1).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = EquivURI - an alias of the subject resource, a different URI to the > = same resource (0 or = more).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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-<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = canonical one. But usually the canonical URI will be the one = signed.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = ---<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> 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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = EHL<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = -----Original = Message-----<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = From: Drummond Reed [<a = href=3D"mailto:drummond.reed@cordance.net";>mailto:drummond.reed@cordance.n= et</a>]<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = Sent: Tuesday, January 27, 2009 10:00 = PM<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> To: = 'XRI TC'<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = Subject: [xri] Thoughts on XRD-to-resource = cardinality<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> I = will be offline Thursday and Friday travelling to a memorial, so = I<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = want to<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = contribute here on the list to advance today's discussion = about<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = XRD-to-resource = mapping<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> (<a = href=3D"http://wiki.oasis-open.org/xri/SelfServeAgenda#head-";>http://wiki.= oasis-open.org/xri/SelfServeAgenda#head-</a><br></blockquote></blockquote>= </blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">>> = a4044b7035eb441c2674549<br></blockquote></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = d07ccaf27daed8970).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> As = I said on the call, the concept of a one-to-many mapping between >> = an<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = XRD<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> and = the resources it describes is a mind-expander for those of us = who<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = have<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = been living a one-XRD-to-one-resource worldview for a few years = now.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> But = the<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> use = case -- being able to get and cache one XRD to describe >> = potentially<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = a<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = very large number of resources (such as an entire site) is >> = compelling.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = Under a one-to-many mapping, I believe Eran's right that the >> concept = of<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = asserting a synonym (not just CanonicalID but any synonym) pretty >> = much<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = goes<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = away. The only synonym assertion I could see providing is some form >> = of<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = aliasing template that would apply to the URIs of all the = described<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = resources (e.g., every that maps to the <a = href=3D"http://foo.example.com/*";>http://foo.example.com/*</a><br></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">>> = template<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> can = all be mapped to the <a = href=3D"http://bar.example.com/*";>http://bar.example.com/*</a> = template).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> But = that appears to be of limited use, and probably not appropriate >> = for<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = assigning CanonicalIDs (which is usually a mapping from a >> = reassignable<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> to = a<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = persistent = identifier).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> But = the rest of the XRD metadata and Link metadata still = seems<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = appropriate,<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = i.e., it applies as much to an individual resource (one-to-one >> = mapping)<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = as<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> it = does to a group of resources (one-to-many = mapping).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> So = what I'm wondering is if maybe there should be a clear way = of<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = indicating<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> the = cardinality of the XRD. In other words, a child element of the >> = root<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = XRD<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = element that indicates whether it is it an individual XRD = (one-to-one<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = mapping) or a group XRD (one-to-many = mapping).<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> If = there was a choice between two mutually exclusive options for = that<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = child<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = element, then all the other elements that are appropriate only for >> = one<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = or<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> the = other (CanonicalID, EquivID, URIMap, etc.) could follow as >> = children<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = of<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = that element.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = Here's a simple example using the element names <Resource> = and<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <ResourceGroup>:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = INDIVIDUAL XRD:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <XRD><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Expires>2009-01-01T08:30:00Z</Expires><br></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">>> = <Resource><br></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> = <CanonicalID><a = href=3D"http://example.com/resource/1";>http://example.com/resource/1</a>&l= t;/CanonicalID><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <EquivID><a = href=3D"http://example.net/resource/1";>http://example.net/resource/1</a>&l= t;/EquivID><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = </Resource><br></blockquote></blockquote></blockquote= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> <Type><a = href=3D"http://example.com/type/profile_photo";>http://example.com/type/pro= file_photo</a></Type><br></blockquote></blockquote></blockquote><blockq= uote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Link><br></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> <URI><a = href=3D"http://example.com/resource/2";>http://example.com/resource/2</a>&l= t;/URI><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Rel><a = href=3D"http://example.com/rel/profile";>http://example.com/rel/profile</a>= </Rel><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = </Link><br></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> = </XRD><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = GROUP XRD:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <XRD><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Expires>2009-01-01T08:30:00Z</Expires><br></block= quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">>> = <ResourceGroup><br></blockquote></blockquote></blockq= uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> <URIMap><a = href=3D"http://example.com/resource/*";>http://example.com/resource/*</a>&l= t;/URIMap><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = </ResourceGroup><br></blockquote></blockquote></block= quote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> <Type><a = href=3D"http://example.com/type/photos";>http://example.com/type/photos</a>= </Type><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Link><br></blockquote></blockquote></blockquote><blo= ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> <URI><a = href=3D"http://example.com/service/1";>http://example.com/service/1</a><= /URI><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = <Rel><a = href=3D"http://example.com/rel/some-group-service";>http://example.com/rel/= some-group-service</a></Rel><br></blockquote></blockquote></blockquote>= <blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> = </Link><br></blockquote></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>> = </XRD><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = Thoughts?<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = =3DDrummond<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">>><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = ---------------------------------------------------------------------<br><= /blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> To = unsubscribe from this mail list, you must leave the OASIS TC = that<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> = generates this mail. Follow this link to all your TCs in OASIS = at:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">>> <a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/";>https://www= .oasis-open.org/apps/org/workgroup/portal/</a><br></blockquote></blockquot= e></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite">>> = my_workgroups.php<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = ---------------------------------------------------------------------<br><= /blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> To = unsubscribe from this mail list, you must leave the OASIS TC = that<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> = generates this mail. Follow this link to all your TCs in OASIS = at:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">> <a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups= .php">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp</a><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Peter = Davis: NeuStar, = Inc.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Director= & Distinguished Member of the Technical = Staff<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">45980 = Center Oak Plaza Sterling, VA = 20166<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">[T] +1 = 571 434 5516 [E] peter.davis@neustar.biz <<a = href=3D"mailto:peter.davis@neustar.biz";>mailto:peter.davis@neustar.biz</a>= > [W] <a = href=3D"http://www.neustar.biz/";>http://www.neustar.biz/</a><br></blockquo= te></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><blockquote type=3D"cite"> [X] xri://@neustar*pdavis [X] = xri://=3Dpeterd<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">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.<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">------------------------------------------------------------= ---------<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To = unsubscribe from this mail list, you must leave the OASIS TC = that<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite">generates this mail. Follow this link to all your = TCs in OASIS at:<br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups= .php">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp</a><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">------------------------------------------------------------= ---------<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">To unsubscribe from this mail = list, you must leave the OASIS TC = that<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">generates this mail. Follow this link to all your = TCs in OASIS at:<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite"><a = href=3D"https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups= .php">https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp</a><br></blockquote></blockquote></div></blockquote></div><br></div></b= ody></html>= --Apple-Mail-342--694904939-- --Apple-Mail-343--694904865 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGrzCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNoMIIC0aADAgECAhAd94+bIYviuSaQ w/qU/yWPMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wODEyMTIwMTU0MzFaFw0wOTEyMTIwMTU0MzFaMIGfMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBqYnJhZGxleUBtYWMuY29tMR4wHAYJ KoZIhvcNAQkBFg9qYnJhZGxleUBtZS5jb20xHTAbBgkqhkiG9w0BCQEWDnZlN2p0YkBtYWMuY29t MRwwGgYJKoZIhvcNAQkBFg12ZTdqdGJAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxB2GGbZ5p8mVtg16CSDXeF8F3D+5sbs8L4b/YrHt/BvtQdE8GY202cUko/b/rXTUA0JC XZRDrOiH7ZxcqI4alJNel9AcSLepcdHN4+t2zhvWilm+YF0/r6m/1PikkVT9TWic61IZMpNWIUkk A+MWzEjChYPefdSMhxikhhMFZ0sv2qPE9pmdaPtD2uF4MwKnIzdZYo+X7rWoaXHIdsZwZDU3HdR5 rVuK5s9xvRED7TZgwE1/yHzHnTbedUWPdNNUlL24Jp3iiVzjZan8zOCn6x4b8O1QPN5b/FOZrerq FDZ2zhIBsWEcKdIxqIqPdVkrYvEfGBLMe1QIORu0J56L/QIDAQABo10wWzBLBgNVHREERDBCgRBq YnJhZGxleUBtYWMuY29tgQ9qYnJhZGxleUBtZS5jb22BDnZlN2p0YkBtYWMuY29tgQ12ZTdqdGJA bWUuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEADhjvX5w/BXN7OL5y1ZfydfmJ RKezNqugUDf8XbKmmMR/o+vjx395pBpO9QF8hQwtKNDuvoxLTNDMWdcCNbvaEpqREXc7liV9FfA5 ndAB1VgDqYDjY9M9LU54LH8uqEx7+pX6qa6KoR8eRHby9zi+iuSkJ4GLI59RBnVI54x4/acxggMQ MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHfeP myGL4rkmkMP6lP8ljzAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wOTAxMjgxNzE0MDlaMCMGCSqGSIb3DQEJBDEWBBTHBl964kKa3cXuPvqN avgxJMsZVzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ KoZIhvcNAQEBBQAEggEAV/d/VfaKlruqSRqbiDvChmtJZhOTX5k/KG3Kq8Ahyu7lx5E+1N9C1UH6 HhpKNJs1SNVqcvWT/vhmhePXtwk+WCUBKCUO3ht1mA9sOQidVSwGvaKfaiFwG5GerBPuSgofdAd8 8ITzA178+nvcbIxcPJ6amQUrqVySSiID55kdIMMuqtphNEQd7Kuab/sbKCCCGMvh87CeZSHfcy/e KR1g7AE9UousxeqOaGrjiFXKnGrFHdNsE/C1I2Ni7RSrXG1bZ67IBv7dyux/lmO8X7J4tGzs82qr olR8inTTecPmc8oeQ8dwcJSFAClgxlX9GXebmOVWxeSHmXgOTi7zyfE6iQAAAAAAAA== --Apple-Mail-343--694904865--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]