[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Conflict in Canonical ID verification behavioral models.
|
I understand #1 below, and believe it’s
accurate. I don’t understand #2 below, or the
explanation of the motivation. I would summarize it this way: 1) Under Hierarchical Canonical ID
Verification (the model specified in section 11 of WD11 ED02), the resolver verifies
that the Canonical ID identifiers asserted in an XRD have been assigned by the
same authority that is authoritative for the XRD (and therefore by definition
are authorized by that authority). This limits the Canonical IDs that may be
asserted in an XRD to a set of hierarchical synonyms that all start from the same
root. 2) Under Polyarchical Canonical ID
Verification (the proposal at http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification
once the wiki starts working again), the resolver verifies that the Canonical
ID identifiers asserted in an XRD are all authorized by the authorities for
those identifiers. This enables the Canonical IDs that may be asserted in an
XRD to be any set of synonyms from any number of roots. Note that the second approach, Polyarchical Canonical ID
Verification, is a superset of the first approach, Hierarchical Canonical ID
Verification, because all identifiers that would verify under #1 would also
verify under #2. Key motivations for #2: 1) It allows URLs to be asserted as synonyms for XRIs (which
satisfies the OpenID Canonical ID verification use cases). 2) It enables any number of XRDs from any number of
authorities to assert the same Canonical ID if they wish. This use case applies
both to XRIs and URLs. A reminder to all TC members that we will hold a second
special telecon on this issue today at 10AM PT on our regular bridge number: Dial In Number: 571-434-5750 Conference ID: 5474 =Drummond From: Steven Churchill
[mailto:steven.churchill@xdi.org] The following outlines the two behavioral definitions for
CanonicalID verification. The first one is the “current”
definition. The second is the new proposal. 1. Under
Canonical ID Verification, the resolver promises (under the rules of its
identity model) that the final XRD returned when resolving a given XRI will
have been produced along its canonical identifier path. 2. Under
Canonical ID Verification, the resolver promises (under the rules of its
identity model) that the final XRD returned when resolving a given XRI will
have been produced along the path of the resolved XRI. Reconciling this behavioral conflict is going to be a
specification nightmare. And its going to be really hard to get our heads
around it before we attempt to do so. On requirements and motivations: Behavioral definition (1) has been with us for at least 8
months. The motivations/requirements for this are obvious: changes in input
parameters (for example resolving a given XRI for a different service type)
produce different XRDs with different Canonical IDs. If an RP is using that
Canonical ID as its primary key, then that RP needs a guarantee that the XRD
metadata has not been spoofed. Behavioral definition (2) has arisen in the last few weeks
due to a thread in the OpenID mailing list. The proposal is that we introduce a
new behavioral model (2) to the existing Resolver and that we specify how a
URI-based resolving agent should behave. The notion that the folks in the
OpenID camp will adopt “resolving agent” behavior specified in the
XRI Resolution Specification is a long shot at best. In any case, if we were to define behavior for a resolving
agent, then it should be consistent with the XRI Resolver and it should perform
service selection. If it performs service selection, then its behavioral model
is “stuck” with (1) above. ~ Steve |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]