>> Drummond Reed wrote: >> >> Multiple, redundant identifiers is what canonical ID mapping >> provides. It >> doesn't require a master directory; it's as distributed as OpenID >> itself, >> i.e., it simply provides a way to map a reassignable URL or XRI to a >> persistent URL or XRI. > >Dick Hardt wrote: > >The persistent URL or XRI *is* a master directory. What do you do >when the persistent identifier is compromised, goes out of business ... > >That is problem B. > >Canonical IDs do not solve B.
I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. For example -- and this is only one example, other identifier authorities that adopt these or similar practices to solve B -- XDI.org spent several years developing policies that ensure that as an identifier authority, the Canonical IDs (global i-numbers) assigned by the XDI.org global XRI registries follow these policies: 1) Global i-numbers and their registration policie are designed explicitly for persistent identifiers that are never reassigned and administered by an international public trust organization (XDI.org) for which this is the primary responsibility. 2) If the i-broker serving as the end-user's registrar goes out of business, the global i-number is not compromised because, like a DNS name, it is portable, i.e., the registrant can move it to another accredited i-broker. In other words, the concern about "going out of business" becomes a concern only about the entire infrastructure going out of business. 3) Strong authentication is used in i-broker-to-registry communications to ensure that only accredited and authoritative i-brokers make changes to global registrations, and accredited i-brokers compete under market conditions to offer the best and most flexible means of authenticating registrants, thereby minimizing the risk of a registrant losing control of their global i-number. 4) Every global i-number registration also enables the registrant to register private contact data with an independent third-party trustee (their contact data custodian) to provide an independent third-party channel for authentication. For reference, see the XDI.org Global Services Specifications site at http://gss.xdi.org. It's not a perfect solution, but I would argue (my well-known bias aside) that it's a practical one. =Drummond _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs