Tech FAQs

From I-names Development Wiki

Jump to: navigation, search

Note: this page will grow organically as FAQ questions are posted and answered. Don't hesitate to post a question you don't know the answer to -- someone will.

Contents

What are the recommended modifications OpenID Relying Parties (RPs) should make to their user tables?

One of the fundamental advantages of XRI lies in the ability to map multiple reassignable i-name synonyms to a persistent i-number. This advantage is totally lost if an OpenID Relying Party (RP) keys a user's identity to their i-name instead of their i-number.

To that end, following are a general set of guidelines, developed on the OpenID General mailing list, about the modifications RPs should make to their userid tables when they adopt OpenID.

  1. Establish a Persistent Primary Key (PPK) for the user, and allow mapping from a separate "synonym table" of 0-n additional keys that serve as synonyms for the PPK. (In other words, build OpenID synonym management into your user tables from the start.)
  2. If a user registers with a URL, generate a locally-unique persistent identifier for the user and use this as the PPK, then add the URL to the synonym table.
    1. If a user with a URL later logs in with another URL and wants to associate it with the original URL, after authentication of BOTH the original URL and the new URL, add the newURL to the synonym table.
    2. If a user with a URL later logs in with an i-name and wants to associate it with the original URL, after authentication of BOTH the new i-name (and its synonymous CanonicalID i-number) and the original URL, add both the i-name and the CanonicalID i-number to the synonym table. (Note that both the PPK and the CanonicalID i-number are persistent identifiers, so unlike reassignable identifiers in the synonym table, the association between the PPK and the i-number will never break.)
  3. If a user registers with an i-name, use the i-number (supplied as the value of the highest priority CanonicalID element in the authoritative XRDS) as the PPK and add the i-name to the synonym table (realizing that it may be reassigned just like a URL).
    1. If a user later logs in with a different i-name that is synonymous with the original i-name/i-number (which the RP can detect because the new XRDS contains an CanonicalID i-number which the RP already has stored), after authentication add the new i-name to the synonym table.
    2. If a user later logs in with a different i-name that is NOT synonymous with the original i-name/i-number (which the RP can detect because the new XRDS contains a different CanonicalID i-number), BUT the user can prove this i-name/i-number is a synonym of the original i-number by authenticating BOTH the old and new i-numbers, then add both the new i-name and i-number to the synonym table.
    3. If a user later logs in with a URL that the user can prove is a synonym for the original i-number by authenticating BOTH the new URL and the original i-number, add the URL to the synonym table.

How does XRI resolution work at the community level?

What does (should) a community i-number look like?

A community i-number is delegated below a global i-number just like a higher-level domain name delegates to a lower-level domain name. The only difference is that with XRIs, the delegation character is bang ("!") instead of dot (".") and delegation goes left-to-right instead of right-to-left.

Community i-numbers can be delegated under global i-numbers in both the = (personal) and @ (organizational) registries. For global i-numbers, XDI.org policy is to assign random 64-bit values encoded as four dot-delimited hex quads. However community i-numbers may use anywhere from a 16-bit to a 128-bit value as long as it is encoded as a hex quad. The full ABNF and assigment policies are in section 4.3 of the XDI.org Global Services Specifications. Examples: 

  =!9c7d.3840.2dca.77e2            (global =number)
  =!9c7d.3840.2dca.77e2!2756       (second level community =number)
  =!9c7d.3840.2dca.77e2!2756!39d8  (third level community =number)

  @!42a7.e498.6bb2.1845            (global @number)
  @!42a7.e498.6bb2.1845!d8c2       (second level community @number )
  @!42a7.e498.6bb2.1845!d8c2!9ab9  (third level community @number)

Global i-brokers (those registered directly in the XDI.org ! registry) can also delegated to community i-brokers. Note that:

  • The ! registry accepts only i-number registrations and not i-names.
  • Global !numbers begin with two bangs, because the first represents the registry and the second an i-number registered in the registry.
  • Because XDI.org policy is to assign global !numbers only to XDI.org-accredited i-brokers, they are 16-bit values encoded as a single hex quad. Examples: 
  !!1000                           (global !number)
  !!1000!14d5                      (second level community !number)
  !!1000!14d5!2da3                 (third level community !number)

How does a community i-number get resolved?

I-number resolution is identical to i-name resolution; the only difference is that the identifier being resolved is persistent instead of reassignable. For a second-level community i-number, the steps are:

  1. First a resolution request is made to the http(s) URI for the XDI.org ! registry (https://bang.xri.net) to resolve the global i-number to its XRDS document.
  2. Then, the resolver selects the highest priority XRI authority resolution service (this service has the type xri://$res*auth*($v*2.0)).
  3. Third, the resolver selects the highest priority URI element for this service. This is the community registry URI (which must be either an http or https URI).
  4. Lastly, a second resolution request is made to the community registry URI to resolve the second-level i-number. The XRDS returned from this request is the final result.

For more information about how XRI resolution works, see the Introduction section of XRI Resolution 2.0 Working Draft 10.

Retrieved from "http://dev.inames.net/wiki/Tech_FAQs"