Summary of GSS Policies

To simplify review, this page summarize the policies defined in the GssPolicies section of the GSS. Please note that these summaries

Note: all Capitalized Terms are defined in GssDefinitions.

2. Global Service Provider (GSP) Policies

GssPolicies/GspPolicies includes two sections:

2.1. GSPs

• GSPs must be authorized contractors to XDI.ORG.
• GSPs can be either Primary or Secondary. The Primary GSP has overall responsibility for the provisioning, management, and operati
• All XDI.ORG Primary GSP contracts must include survivability and transition provisions.
• If there is more than one GSP for a Global Service, the GSPs must form a GSP Working Group responsible for operational specificat
• A GSP's implementation of a Global Service must conform to the GSS. Any disputes will be ajudicated according to the dispute reso

2.2. Global Services Startup

• Any entity may propose a new Global Service to XDI.ORG.
• The proposal must be in writing and include all details necessary for XDI.ORG trustees to make a decision regarding its desireabi
• If XDI.ORG believes the proposal has merit, it must publish it for public review and invite alternative proposals. The proposal m
• After public review, XDI.ORG is responsible for selecting the proposal that best serves the interests of the XDI community and ne
• The Primary GSP must then submit the proposed amendments to the Global Services Specifications (GSS) governing the new Global Ser
• Upon approval of the specs, the Primary GSP and any Secondary GSPs must implement the Global Service(s) within a commercially rea

3. Global Registry Service Provider (GRSP) Policies

GssPolicies/RegistryPolicies includes five sections:

3.1. Code of Conduct

• GRSPs must at all times operate as a trusted neutral third-party provider of Global Registry Services.

• GRSPs shall uphold the provisions of the XDI.ORG I-Trust(tm) Contract (see GssAgreements.)

• GRSPs will not show any preference to qualified Registrars or Registrants, except during the first six-month startup phase of a n
• GRSPs shall not warehouse Global I-Names, and nor register Global I-Names in their own right, but must specify in the GSS those t
• Entities related to a GSRP that also operates as Registrars must maintain separate books.
• GRSPs shall not have access to user data or proprietary information of a Registrar except as required for Registry management.
• GRSP must ensure that no Registry or Registrar data is shared except as required for registry management.
• Confidential information about GRSP's business services will not be shared with employees of any Registrar except as necessary fo
• No member of GRSP's Board of Directors will simultaneously serve on the Board of Directors of a Registrar.
• No employee of GRSP will serve as an employee of or hold a greater than 5% interest, financial or otherwise, in a company that ob
• GRSPs will conduct internal neutrality reviews on a regular basis.

3.2. Survivability and Data Escrow

• GRSPs must use commerically reasonable procedures to backup Global Registry data.
• GRSPs must enter into a data escrow agreement with XDI.ORG.

3.3. Fees

• Global Services are classified as either Cost-Based or Fee-Based.
• In the V1 GSS, the three I-Number Registries and the Public Resolver service are Cost-Based; the two I-Name Registries are Fee-Ba
• Cost-based Services must have a cost-based pricing agreement between each GSP and XDI.ORG. For the V1 GSS Cost-Based Services, th
• Fee-Based Services must have a maximum fee schedule agreement published in the GSS. For the V1 GSS, these fees are a sliding scal
• For each Global Service, XDI.ORG sets the wholesale cost based on the contracted cost with each GSP plus an overhead fee to cover
• The initial service term for all V1 Global Services is one year.
• GRSPs and Registrars MAY offer service terms of more or less than one year as long as the standard annual service term is always

3.4. Registrar Support

• A Primary GRSP must provide Registrars with a Web portal for Web-based self-help services, plus email- and telephone-based Help D
• Help Desk support has two tiers. Tier 1 handles customer XRI problems and such other issues such as basic GRS implementation or b
• There are four levels of escalation for problem resolution: basic, technical, system outage, or catastrophic outage.
• Primary GRSPs must include a notice to Registrars of planned outages for database maintenance or installation of software upgrade

• Primary GRSPs must establish an operational test-and-evaluation facility and provide technical support for OT&E testing to Regist

3.5. Registry Reporting

• A Primary GRSP must provide a Public Registry Report and a Confidential Registrar Report each calendar quarter.
• XDI.ORG must keep the Confidential Registrar Report confidential until three months after the end of the quarter to which the rep
• The Public Registry Report includes Accredited Registrar Status for four status levels, Service Level Agreement Performance, Comp
• The Confidential Registrar Report includes Global I-Names and Global I-Numbers per Registrar by month, broken down by status and

4. Registrar Policies

GssPolicies/RegistrarPolicies includes seven sections:

4.1. Accreditation

• If an applicant is an ICANN-Accredited Registrar in good standing, it is pre-qualified (but must still complete the Registrar App
• If an applicant is not an ICANN-Accredited Registrar, it must demonstrate that it has adequate legal, management, financial, tech
• Accreditation is a six-step process:

  1. Submit Registrar Application (see GssForms).

  2. Receive a Notice of Qualification.
  3. Execute a Registrar Agreement

  4. Complete OT&E.

  5. Complete Legal Agreements.
  6. Receive GRSP Authorization for Commencement of Service.

4.2. Code of Conduct

• Registrars must at all times operate as trusted providers of Global Registration Services.

• Registrar must uphold the provisions of the XDI.ORG I-Trust(tm) Contract (see GssAgreements).

• Registrars shall not be granted or try to obtain preferential access to the GRS, except where permitted by XDI.ORG during the fir
• Registrar will warehouse Global I-Names or assist Registrants to do so.
• Registrar shall clearly and conspicuously disclose to Registrants any relationship or conflict which may impact Registrar's abili

4.3. Registrant Qualification

• Registration of Global I-Names and Global I-Numbers is on a first-come, first-served basis to all qualified Registrants.
• Registration of Global Personal I-Names/I-Numbers (under the GCS "=" symbol) are restricted to individuals acting in their own pe
• Registration of Global Organizational I-Names/I-Numbers (under the GCS "@" symbol) is not restricted, and Registrants may assert
• Registration of Global Network I-Numbers (under the GCS "!" symbol) is restricted to XDI.ORG-Accredited Registrars.
• Except for Global Network I-Numbers, the minimum registration is one Global I-Name and one Global I-Number. Registrants may regis
• When additional Global I-Names are being registered to an existing Global I-Number, a Registrar must verify a Registrant's authen
• In the V1 GSS, the minimum registration term is one year, and the maximum is ten years (with the exception of the limited number
• All Registrants must agree to the XDI.ORG Registrar Agreement, including the Dispute Resolution Provisions.

4.4. Registrant Notification

• There is no conventional "Whois" data in the GRS. Accountability for registrations and registrant notification is delegated by XD
• GRSPs must provide Registrars, and Registrars must provide Registrants, a means of being notified of any communication regarding
• Notifications may be by push or pull.
• Registrants can opt-in to other communications from XDI.ORG, GRSPs, or their Registrar.

4.5. Registration Transfers

• GRSPs and Registrars must verify the authentication credential(s) and confirm the authorization of the relevant Registrants or Tr
• Fees, if any, for transfers must be be commercially reasonable and publicly published.
• Transfers to not affect the current registration term of a Global I-Name or I-Number.
• After a transfer, a GRS registration may not be transferred again for a period of 60 days.

4.6. Registrar Reporting

• Registrars must provide the Confidential Registrar Report as specified in GssPolicies/RegistryPolicies to the Primary GRSP and to

5. I-Name Policies

GssPolicies/InamePolicies includes seven sections:

5.1. I-Name Syntax, Normalization, and Delegation

• An XDI.ORG Community I-Name must conform to the XRI Specifications for reassignable XRIs for XRI Authorities.

• A Community I-Name must begin with a Global I-Name, and may contain a Cross-Reference (see GssPolicies/CrossReferencePolicies) th

• A Global I-Name or Delegated I-Name cannot begin or end in an XRI reserved character, a dot ("."), or a hyphen ("-").
• A Global I-Name or Delegated I-Name cannot exceed 254 bytes.
• A Global I-Name and Delegated I-Name must be unique within the scope of the Authority that assigns it.
• A Global Personal I-Name must begin with the GCS character "=". A Global Organizational I-Name must begin with the GCS character
• Global General I-Names are not supported in the V1 GSS but will be supported in a future version.

• A Global I-Name may contain a Cross-Reference that conforms to the Global Cross-Reference Policy (GssPolicies/CrossReferencePolic

• The only XRI reserved character allowed is a colon (":") (which must be escaped when transforming an XRI into an IRI or URI.)
• Dots (".") and hyphens ("-") are the only other ASCII punctuation allowed because they are not XRI reserved characters.
• Whitespace of any kind is not allowed per the XRI Specifications, and should be normalized to a dot (".").
• Per the XRI Specifications, all characters outside the ASCII range must be UTF-8 encoded.
• In the V1 GSS there are no additional rules for Global I-Name normalization, however these may be added in a future version.
• To help prevent homographic attacks, Global I-Names and Delegated I-Names are restricted to a single UCS script (with three excep
• All Delegated I-Names assigned at any delegation level must conform to the Community I-Name Syntax, Normalization, Restriction, a
• If a desired Global I-Name is not available, Registrars should suggest the alternative of registering an Extended I-Name using co

        =Mary.Smith:Montana
        =Mary.Smith:England
        =Mary.Smith:Ireland
        =Mary.Smith:Rose
        =Mary.Smith:Rose.Water
        =Mary.Smith:Iris
        =Mary.Smith:2000
        =Mary.Smith:2001

5.2. I-Name Synonyms

• A Global Personal I-Name must have at least one and may have more than one Global Personal I-Number and Network I-Number as a Syn
• A Global Organizational I-Name must have at least one and may have more than one Global Organizational I-Number and Network I-Num
• If a Global I-Name resolves to more than one Global I-Number, the Registrant should indicate the order in which they should appea
• In the V1 GSS, resolution of a Global I-Name will not return any Global I-Name Synonyms, only Global I-Number Synonyms. Registrar

5.3. I-Name Resolution

• The GRS resolution response for a Global I-Name MUST contain all Global I-Numbers registered as Internal Synonyms and all Network
• For each External Synonym, if the GRS is authoritative for the Network I-Number of the Delegating Authority, the GRS will return
• If the GRS is not authoritative for the Network I-Number of the Delegating Authority, no XAU or LAU shall be returned (i.e., the

5.4. I-Name Status

• A Registrar has up to 60 hours to release a registration if the Registrant abandons the transaction or defaults on payment.
• A Registrant, Registrar, or GRSP may suspend a registration as required under the Dispute Resolution Policy or another GSS polici
• A Registrant, Registrar, or GRSP may terminate a registration as required under the Dispute Resolution Policy or another GSS poli
• If a registration expires, it must be followed by a 30 day waiting period, during which it can be reactivated if it is renewed.

5.5. I-Name Transfer

• The Registrant of a Global I-Name that is not subject to dispute, non-payment, or other encumbrances may: a) reassign it to anoth
• All Registrars must support this function, i.e., portability is assured for all Global I-Names.

5.6. I-Name Wait List

• Wait List functionality is not specified in the V1 GSS because XDI.ORG needs to first verify demand for this service.
• When Wait List service is offered, Wait List registration will be on a first-come-first-served basis.
• The depth of Wait List registrations (meaning the number accepted for any particular Global I-Name) will not be fixed but will be

5.7. Reserved I-Names

• There are three categories of reserved Global I-Names:
  1. Those reserved for public use in documentation and examples.
  2. Those reserved by XDI.ORG's own operational use as a public trust organization.
  3. Those reserved to identify GRSPs (who, by the GRSP Code of Conduct, may not register Global I-Names themselves.)

GssPolicies/InumberPolicies includes six sections:

6.1. I-Number Syntax, Normalization, and Delegation

• An XDI.ORG Community I-Number must conform to the XRI Specifications for persistent XRIs for XRI Authorities.

• A Community I-Number is based on IPv6 addressing architecture as specified in [http://www.ietf.org/rfc/rfc2373.txt RFC 2373], wit

  1. To conform to the XRI Specifications for persistent XRIs, Community I-Numbers use bangs ("!") instead of colons (":") or dots (
  2. An XDI.ORG Community I-Number is not a fixed 128-bit value but a variable length string in which each sub-segment may be either
  3. In compressing 128-bit hex values, double colons are not used to represent zero-value 16-bit segments; instead left-padded zero
• A Global Personal I-Number must begin with "=!" followed by a cross-reference to a random 64-bit value generated by the GRS.
• A Global Organizational I-Number must begin with "@!" followed by a cross-reference to a random 64-bit value generated by the GRS
• A Global Network I-Number must begin with "!!" followeb by a 16-bit hexadecimal value.
• In Global I-Numbers or Delegated I-Numbers, all hexadecimal digits must be normalized to uppercase.
• Community I-Numbers assigned at any delegation level must conform to the Community I-Number Syntax Policy.

6.2. I-Number Synonyms

• A Global Personal or Organizational I-Number must have at least one and may have more than one Network I-Number as an External Sy
• This Network I-Number must be a cross-reference delegated by the host Network Authority, where the cross-reference value is the f
• If a Global I-Number has more than one External Synonym, the Registrant should indicate the order in which the External Synonyms

6.3. I-Number Resolution

• Resolution of a Global Personal or Organizational I-Number will return the same values as a Global Personal or Organizational I-N
• The GRS resolution response for a Global Network I-Number MUST return the XRI Authority URIs (XAUs) and Local Access URIs (LAUs)

6.4. I-Number Status

• A Registrant, Registrar, or GRSP may suspend a registration as specified under the Registration Agreement, the Dispute Resolution
• A Registrant, Registrar, or GRSP may terminate a registration as specified under the Registration Agreement, the Dispute Resoluti
• If a registration expires and is not renewed, resolution of a Global I-Number must return its last registered resolution value (i

6.5. I-Number Transfer

• Once registered to represent a Resource, a Global I-Number or a Community I-Number must never be reassigned to represent a differ
• A Global Personal I-Number must not be transferred between Registrants because it represents a Personal Authority. However it may
• Because it represents an Organizational Authority, a Global Organizational I-Number that is not subject to dispute, non-payment,
• Because it represents a Network Authority, a Global Network I-Number that is not subject to dispute, non-payment, or other encumb

6.6. Reserved I-Numbers

• Global Network I-Numbers are reserved in the range below and including the hexadecimal value "1000" and the upper-end value "FFFF
• The Global Network I-Number "!!1000" is reserved for internal testing of XRI resolver and I-Broker implementations.
• The Global Network I-Number range from "!!0990" to "!!0999" inclusive is reserved for public use in documentation and examples.

7. Cross-Reference Policies

GssPolicies/CrossReferencePolicies includes only one section.

• In the V1 GSS, identifiers from an external namespace or scheme (such as an email address, phone number, IM address, HTTP URI, et
• Global I-Names or Global I-Numbers registered in one Global Registry may not be registered as a cross-reference in another Global
• A Global I-Name or Global I-Number used within a Community Cross-Reference (a Cross-Reference below the GRS level) must represent

GssPolicies/PublicAuthorityPolicies includes one section.

• In the V1 GRS Public Authority Service responds to two types of XRI resolution requests:

  1. Standard XRI resolution requests are HTTP or HTTPS GET requests for an XRI Descriptor (XRID) an XML document that conta

  2. Proxy resolver requests are HTTP GET requests to resolve the XRI authority portion of the requested XRI. They return an H

• Trusted resolution will be supported in a future version of the GSS.

• The Primary GRSP must maintain a Public Authority Service at one or more HTTP and HTTPS URIs specified in the GssOpSpecs.

• A client of the Public Authority service must include an HTTP Accept header with a value of application/xrid+xml.

• The Public Authority Service must return an XRID that conforms to the XRI Specifications.

  • The value of the AuthorityID element must be specified in the GssOpSpecs for each Global Registry Service.

  • The value of the Expires element is a global variable under the control of the Primary GRSP. It may differ for Global I-Name and

  • The contents of the other XRID elements must conform to the Global I-Name Resolution Policy (GssPolicies/InamePolicies) and Glob

• The Primary GRSP must maintain an Public Proxy Resolver Service at one or more HTTP and HTTPS URIs specified in the GssOpSpecs.

• A client of the Public Authority service MUST make an HTTP or HTTPS request for proxied XRI resolution that conforms to the XRI S

• If the request include an HTTP Accept header with a value of application/xrid+xml, the Public Proxy Resolver Service must attem

• If the request does not include an HTTP Accept header with a value of application/xrid+xml, the Public Proxy Resolver Service m

• This HTTP redirect will include the Local Path of the XRI in the original request, if any. If an error is encountered during prox
• A GRSP may implement security safeguards for the Public Authority service intended to maintain optimal service and prevent or min

9. Data Protection Policies

GssPolicies/DataProtectionPolicies includes three sections:

9.1. Security Policies

• XDI.ORG and its Agents must use commercially reasonable efforts to protect the security of all XDI Data under their authority. Su

• XDI.ORG and all its Agents should adhere to the [http://en.wikipedia.org/wiki/ISO 17799 ISO 17799] international standard for Inf -

  • -
• All XDI.ORG Agents must publish their own Community Security Policy governing the XDI data transacted with them. At a minimum it
• The Community Security Policy for an XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+security.

        xri://@GSP-A/(+security.policy)
        xri://@GSP-B/(+security.policy)
        xri://@Example.Registrar.A/(+security.policy)
        xri://@Example.Registrar.B/(+security.policy)
        xri://!!1000/(+security.policy)
        xri://!!FFFF/(+security.policy)

• A Registrar must authenticate GRS transactions on behalf of a Registrant by providing an Authentication Credential (Shared Secret
  • Minimum of eight characters in length.
  • Includes at least one letter and at least one digit.
  • Case-sensitive.
• Registrars MAY impose their own higher-strength requirements.
• Registrants may also choose Public Trustee Service or another Trustee Service as an alternate means of safekeeping their GRS Auth

9.2. Privacy Policies

• XDI.ORG, its Global Privacy Policy, and all other GSS policies and specifications must observe the privacy principle of always co
• XDI.ORG, its Global Privacy Policy, and all other GSS policies and specifications must observe the privacy principle of offering
• The XDI.ORG Global Privacy Policy is to be drafted by XDI.ORG General Counsel and will reuse as much content as possible from the
• All XDI.ORG Agents must publish their own Community Privacy Policy governing the XDI data transacted with them. At a minimum it m
• The Community Privacy Policy for any XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+privacy.p

        xri://@GSP-A/(+privacy.policy)
        xri://@GSP-B/(+privacy.policy)
        xri://@Example.Registrar.A/(+privacy.policy)
        xri://@Example.Registrar.B/(+privacy.policy)
        xri://!!1000/(+privacy.policy)
        xri://!!FFFF/(+privacy.policy)

9.3. Accountability Policies

• XDI.ORG Agents must provide: a) a means of identifying the real-world legal entity accountable for enforcement the Community Poli
• All XDI.ORG Agents must publish their own Community Accountability Policy governing the XDI data transacted with them. At a minim
• The Community Accountability Policy for any XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+ac

        xri://@GSP-A/(+accountability.policy)
        xri://@GSP-B/(+accountability.policy)
        xri://@Example.Registrar.A/(+accountability.policy)
        xri://@Example.Registrar.B/(+accountability.policy)
        xri://!!1000/(+accountability.policy)
        xri://!!FFFF/(+accountability.policy)

10. Public Trustee Policies

GssPolicies/PublicTrusteePolicies includes one section:

• Public Trustee Service offers an alternative means of authentication to the GRS for Registrants who may lose access to their GRS
• It is optional for all Registrants, but must be made available by Registrars at the time of GRS registration and thereafter when
• Registrars may offer any number of Trustee Services from any number of Trustee Service providers.
• Public Trustee Service data is ONLY for providing an alternative means of authenticating for GRS transactions and must not be use

• The data collected by Public Trustee Service must conform to the specifications for EPP Contact Objects as defined in [http://iet

• All data fields are optional, however Registrants will be notified if missing data fields may significantly impair the ability of
• Registrants have the options of reviewing, updating, or deleting their Public Trustee data.
• If a party requests authentication to the GRS using Public Trustee Service, the GRSP shall use its best efforts to confirm that t
• If the GRSP cannot reasonably confirm that the party requesting authentication is the authentic Registrant, it will not release t
• Public Trustee Service is a Cost-Based Service with no fee for a Registrant to enroll and provide Contact Object data for future
• There will be a service fee to cover its costs if a Registrant requests authentication to the GRS using Public Trustee Service, w

11. Dispute Resolution Policies

GssPolicies/DisputeResolutionPolicies includes just one section.

• The XDI.ORG I-Name Uniform Dispute Resolution Policy is closedly modelled after the ICANN Uniform Dispute Resolution Policy.
• It references a set of Dispute Resolution Rules governing the dispute resolution process (see the posted MS Word document for det
• All XDI.ORG Agents must offer a Dispute Notification Service for notification of Registrants about a dispute regarding their GRS
• This service uses the standard XDI address "{XDI.ORG-Agent-XRI}/(+dispute.notification)". Examples:

        xri://@GSP-A/(+dispute.notification)
        xri://@GSP-B/(+dispute.notification)
        xri://@Example.Registrar.A/(+dispute.notification)
        xri://@Example.Registrar.B/(+dispute.notification)
        xri://!!1000/(+dispute.notification)
        xri://!!FFFF/(+dispute.notification)

• The service allows a party to input the Global I-Name or Global I-Number that is the subject of the dispute ("Disputed XRI") at a
• The Registrar for the Disputed XRI MUST accept a dispute notification message to be delivered to the Registrant.
• To prevent spam or other unsolicited communications, this Registrar may require verification of the dispute notification request,
• Once such verification is received, the Registrar must attempt notify the Registrant using the notification means selected by the