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] CanonicalID verification text for section 11.


 

Markus and Drummond,

 

My replies are in <Steve>.

 

On 6/12/07, Markus Sabadello <markus.sabadello@xdi.org> wrote:

 

- Lines 81-82: I think this is only true if it is not the local canonical identifier itself that is resolved. For example, in figure 11-2, if I resolve =!1, then I think I should get * jane.doe in the <LocalID>, not !1.

### An authority resolution service (its registry) may have many local synonyms d efined for a given parent-child hierarchical relationship (for example, *jane.doe, *jane, *jd.)  So which one should it pick for its <LocalID>? In the general case it can put anything it wants in the LocalID. The question becomes: what should it do in the cid=true case? I believe that the same should probably apply: that is, it can put anything it wants. I have therefore revised the text to say that the local canonical identifier " may" be returned in the <LocalID> field. Drummond and others, please respond if this does not seem correct.

The way I always understood <LocalID>s is that they may/should contain all known local synonyms EXCEPT the one that is resolved, which goes into the <Query>. So if I resolve = jane.doe, I get <LocalID>s *jane, *jd and !1, whereas if I resolve =!1, I get <LocalID>s *jane, *jd and *jane.doe.

 

<Steve> Drummond. Please reply to this. You are much more authoritative on this than me.


At least that's the current OpenXRI server behaviour.. There is need (or possibility) for the OpenXRI user to influence <LocalID> elements at XRD scope. Let me know if this should be different.

--> Sorry this is supposed to say "NO need (or possibility)"
 

<Steve> It’s not clear to me what you mean by the statement “There is no need (or possibility) for the OpenXRI user to influence <LocalID> elements at XRD scope.” In any case, I will leave this question to Drummond as well.

 

 

- Line 18: Shouldn't this say xrd:XRD/xrd:Service/xrd:ProviderID instead of xrd:XRD/xrd:ProviderID ?

### No. Is the XRD scoped ProviderID that is used here.

I don't understand. Are you sure???


Line 18 says "...MUST match the value of the xrd:XRD/xrd:ProviderID element in the authority resolution service endpoint of its parent XRD". That already implies it's inside the xrd:Service ! Also, what should be the point of matching two XRD scoped ProviderIDs at different levels of the authority hierarchy??

I think this is basically the same rule as section 7.2.4 "Client Validation of XRDs" / rule 7 of the ED02.

BTW in ED02 Drummond made this change as I suggested.. So if it really has to be xrd:XRD/xrd:ProviderID (which would totally confuse me), then he has to revert this change.

 

<Steve> I think you have made a good catch. Again, Drummond?

I also have a very non-technical question.. Line 9 says "These replacement semantics are clearly not parent-child semantics"... Then what does it actually mean to use Refs? Assume I am an ordinary user who has no idea how XRI works, and I have two i-names =ms and @id*markus, which I want to be synonyms. How do I decide which one is the "original" "hierarchical parent-child" authority, and which one is "just" the Ref-using synonym?

### Very good question. The hierarchical parent-child relationships (the black edges) are determined solely by the authority resolution services (parent nodes) that decide to answer queries for local synonyms. Let me try to draw the black edges.

     o [=]                      o [@]
     |                         |
     | *ms                     | *id
     |                         |
     o [=ms]                    o [@id]
                               |
                               | *markus
                               |
                               o [@id*markus]

The black edges (shown above ) are determined by the fact that a given authority resolution service (such as [=]) returns a (non-failure) XRD when queried for a local synonym (such as *ms.) To repeat myself: the black edges are determined by the behavior of the authority resolution services . For example, i f you query @id' s auth-res-service for *markus, and it returns an XRD (containing a verifiable CID, because this is the Canonical ID Verification model) then a black edge exits for the local synonym *markus.

As you know, t he polyarchical parent child relationship (say between [@id] and [=ms]) is established by placing a Ref from [@id*markus] to [=ms].


Sure, but why do I use a Ref from @id*markus to =ms, not from =ms to @id*markus? How do I make THAT choice? I know the resolution results are the same, but are there any "semantic" guidelines for this? A very XRI-inexperienced user may want to know that.

Well I guess in practice you would just put all your SEPs into your "first" i-name, and then if you later want synonyms you put Refs into those.

<Steve> I guess I missed the main point of your question. The answer has to do with service selection. Say that you have happily configured the OpenID authentication service for =ms and would like to use this authentication account and password for other authorities. You can place a Ref from [@id*markus] to [=ms] and when an RP resolves @id*markus for its OpenID authentication service, it will get back the XRD that [=] produces for *ms.

Now say that you’ve configured an XDI service endpoint at [@id*markus] but not at [=ms]. You can place a Ref from [=ms] to [@id*markus] and whenever a client resolves [ms] for its XDI service, it will get back the XRD that [@id] produces for *markus.

~ Steve


 



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