UserPreferences

GssPolicies/InumberTransfer

I-Number Transfer

  1. Motivation
  2. Background
  3. I-Number Persistence Policy
  4. Personal I-Number Transfer Policy
  5. Organizational I-Number Transfer Policy
  6. Independent I-Number Transfer Policy
  7. Implications
    1. Persistence in Federated Identifiers
    2. Account Delegation
  8. Related Policies

1. Motivation

These policies govern the transferability of Global I-Numbers between Registrants or between Registrars. They are motivated by the need to:

2. Background

I-Numbers differ from I-Names in one key respect: the former is persistent (non-reassignable) while the latter is reassignable. In other words, once assigned to represent a Resource, an I-Number should never be reassigned to represent a different Resource. Note that this does not mean that the binding between an I-Number and one or more specific locations or representations of the target Resource cannot be changed; indeed, a primary purpose of I-Numbers is to ensure persistent identification of the same logical Resource even as it moves or changes its address(es) on the network. It simply means the I-Number will not be reassigned to represent a different logical Resource (a constraint that does not apply to I-Names).

3. I-Number Persistence Policy

Once registered to represent a Resource, a Global I-Number or a Community I-Number MUST NOT be reassigned to represent a different Resource.

4. Personal I-Number Transfer Policy

A Global Personal I-Number or a Personal Community I-Number MUST NOT be transferred between Registrants because it represents an individual as a logical Authority. However the registration of a Global Personal I-Number MAY be transfered between Registrars by a Registrant. Control of a Global Personal I-Number MAY also be delegated by the Registrant to another Registrant – see the Account Delegation Policy (GssPolicies/AccountDelegation).

5. Organizational I-Number Transfer Policy

Because it represents a non-personal entity as a logical Authority, a Global Organizational I-Number or a Organizational Community I-Number that is not subject to dispute, non-payment, or other encumbrances MAY be transferred between Registrants as long as it continues to represent the same logical Authority. Registration of a Global Personal I-Number MAY also be transfered between Registrars by a Registrant. Control of a Global Organizational I-Number MAY also be delegated by the Registrant to another Registrant – see the Account Delegation Policy (GssPolicies/AccountDelegation).

6. Independent I-Number Transfer Policy

Because it represents a context-independent entity as a physical Authority, a Global Independent I-Number that is not subject to dispute, non-payment, or other encumbrances MAY be transferred between Registrants as long as it continues to represent the same physical Authority. Control of the Global Independent I-Number MAY also be delegated by a Registrant to another Registrant – see the Account Delegation Policy (GssPolicies/AccountDelegation).

7. Implications

7.1. Persistence in Federated Identifiers

Persistence is an operational requirement that must be observed by all authorities who participate in segments of a federated identifier. Although XDI.ORG GSS policies can ensure persistence for Global I-Numbers and Community I-Numbers stemming from Global I-Numbers, persistence of I-Numbers from authorities outside this community is beyond the scope of the GSS.

7.2. Account Delegation

Because Global I-Numbers and Community I-Numbers will often need to be maintained beyond the lifetime of the original Registrant, they require the ability to delegate control of an I-Number registration. See GssPolicies/AccountDelegation.

8. Related Policies