SummaryOfPolicies

Summary of GSS Policies

1. Introduction
2. Global Service Provider (GSP) Policies
1. GSPs
2. Global Services Startup
3. Global Registry Service Provider (GRSP) Policies
1. Code of Conduct
2. Survivability and Data Escrow
3. Fees
4. Registrar Support
5. Registry Reporting
4. Registrar Policies
1. Accreditation
2. Code of Conduct
3. Registrant Qualification
4. Registrant Notification
5. Registration Transfers
6. Registrar Reporting
5. I-Name Policies
1. I-Name Syntax, Normalization, and Delegation
2. I-Name Synonyms
3. I-Name Resolution
4. I-Name Status
5. I-Name Transfer
6. I-Name Wait List
7. Reserved I-Names
6. I-Number Policies
1. I-Number Syntax, Normalization, and Delegation
2. I-Number Synonyms
3. I-Number Resolution
4. I-Number Status
5. I-Number Transfer
6. Reserved I-Numbers
7. Cross-Reference Policies
8. Public Authority Policies
9. Data Protection Policies
1. Security Policies
2. Privacy Policies
3. Accountability Policies
10. Public Trustee Policies
11. Dispute Resolution Policies

NOTE: The content on this page is non-normative, i.e., it is not officially part of the XDI.ORG Global Services Specifications (GSS), but only introductory material. See GssDefinitions for further terminology and layout conventions.

1. Introduction

Note: all Capitalized Terms are defined in GssDefinitions.

2. Global Service Provider (GSP) Policies

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 operation of a Global Services service according to the requirements of the GSS (e.g., maintaining a master registry.) A Secondary GSP is responsible for providing a secondary instance of that service to the public as specified in the GSS (e.g., mirroring a master Registry for redundancy and load balancing.) A Global Service must have only one Primary GSP and may have zero or more Secondary GSPs.

• 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 specifications that affect only GSPs (as differentiated from Registrars or Registrants). Meetings and minutes of the Working Group must be public and transparent.

• A GSP's implementation of a Global Service must conform to the GSS. Any disputes will be ajudicated according to the dispute resolution terms of the relevant XDI.ORG/GSP contract.

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 desireability for the XDI community.

• If XDI.ORG believes the proposal has merit, it must publish it for public review and invite alternative proposals. The proposal must be acted on by XDI.ORG on a timely basis.

• After public review, XDI.ORG is responsible for selecting the proposal that best serves the interests of the XDI community and negotiating the Primary GSP contract and any Secondary GSP contracts.

• The Primary GSP must then submit the proposed amendments to the Global Services Specifications (GSS) governing the new Global Service to XDI.ORG which will then publish them for public review.

• Upon approval of the specs, the Primary GSP and any Secondary GSPs must implement the Global Service(s) within a commercially reasonable period.

3. Global Registry Service Provider (GRSP) Policies

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 new Global Service, where preferential access by Registrars may be allowed to provide market incentives for early adopters.

• GRSPs shall not warehouse Global I-Names, and nor register Global I-Names in their own right, but must specify in the GSS those that are needed for their operational use (see GssPolicies/InamePolicies).

• 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 for registry management or if such information is made available to all Registrars.

• 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 obtains GRS services from GRSP.

• 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-Based (see GssServices).

• Cost-based Services must have a cost-based pricing agreement between each GSP and XDI.ORG. For the V1 GSS Cost-Based Services, this must be no greater than the GSP's documented costs plus ten percent (10%).

• Fee-Based Services must have a maximum fee schedule agreement published in the GSS. For the V1 GSS, these fees are a sliding scale based on volume. They range from $5.40 to $3.40 USD for a Global Personal I-Name and $22.00 to $13.50 USD for a Global Organizational I-Name.

• For each Global Service, XDI.ORG sets the wholesale cost based on the contracted cost with each GSP plus an overhead fee to cover its operating expenses and XRI/XDI infrastructure development and support costs.

• 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 supported.

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 Desk support.

• Help Desk support has two tiers. Tier 1 handles customer XRI problems and such other issues such as basic GRS implementation or billing and collection. Tier 2 is problem that must be handled by functional experts in XRI registration and GRS operation.

• 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 upgrades.

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

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 report relates.

• The Public Registry Report includes Accredited Registrar Status for four status levels, Service Level Agreement Performance, Completed System Software Releases, Monthly Growth Trends, Daily Transaction Range, and Geographical Distribution of Registrations.

• The Confidential Registrar Report includes Global I-Names and Global I-Numbers per Registrar by month, broken down by status and source (new or transfer).

4. Registrar Policies

4.1. Accreditation

• If an applicant is an ICANN-Accredited Registrar in good standing, it is pre-qualified (but must still complete the Registrar Application – see GssForms.)

• If an applicant is not an ICANN-Accredited Registrar, it must demonstrate that it has adequate legal, management, financial, technical, customer service, and data protection capabilities to be an XDI.ORG-Accredited Registrar.

• 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 first six month startup phase for a new Global Service in order to provide market incentives for early adopters.

• 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 ability to serve Registrants fairly and impartially.

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 personal capacity, and Registrants must not assert intellectual property rights in the registered I-Name or I-Number.

• Registration of Global Organizational I-Names/I-Numbers (under the GCS "@" symbol) is not restricted, and Registrants may assert intellectual property rights in the registered I-Name or I-Number.

• 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 register multiple Global I-Names to the same Global I-Number. There is no maximum number of registrations.

• When additional Global I-Names are being registered to an existing Global I-Number, a Registrar must verify a Registrant's authentication credential(s) for a Global I-Number prior to registration.

• In the V1 GSS, the minimum registration term is one year, and the maximum is ten years (with the exception of the limited number of 50-year registrations provided under Early Global Services.)

• 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 XDI.ORG to XDI.ORG-Accredited Registrars and in turn to Registrants. There is an alternative means of authentication provided by Public Trustee Service, but this data is used only for Registrant authentication and is not available publicly.

• GRSPs must provide Registrars, and Registrars must provide Registrants, a means of being notified of any communication regarding their registration(s), including dispute notifications.

• 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 Trustees when doing a transfer.

• 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 XDI.ORG within 15 days of the end of each calendar quarter.

5. I-Name Policies

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) that also conforms to this syntax policy.

• 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 "@". A Global General 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/CrossReferencePolicies).

• 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 exceptions) and certain special-purposes characters are not allowed.

• All Delegated I-Names assigned at any delegation level must conform to the Community I-Name Syntax, Normalization, Restriction, and Uniqueness Policies.

• If a desired Global I-Name is not available, Registrars should suggest the alternative of registering an Extended I-Name using colon syntax as illustrated below (these all extensions of the Global I-Name "=Mary.Smith").

        =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 Synonym.

• A Global Organizational I-Name must have at least one and may have more than one Global Organizational I-Number and Network I-Number as a Synonym.

• If a Global I-Name resolves to more than one Global I-Number, the Registrant should indicate the order in which they should appear in a resolution response.

• In the V1 GSS, resolution of a Global I-Name will not return any Global I-Name Synonyms, only Global I-Number Synonyms. Registrars or third parties can provide this service.

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 I-Numbers registered as External Synonyms.

• For each External Synonym, if the GRS is authoritative for the Network I-Number of the Delegating Authority, the GRS will return one XAU and LAU conforming for each XAU and LAU registered to the Network I-Number.

• 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 GRS resolution response will be an XRI Redirect.)

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 policies. Suspension may last until the registration expires.

• A Registrant, Registrar, or GRSP may terminate a registration as required under the Dispute Resolution Policy or another GSS policies. Termination must be followed by a 15 day waiting period, during which it can be reactivated if the termination is reversed.

• 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 another Registrant, or b) transfer the registration to another Registrar.

• 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 dynamic according to Registrant demand.

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.)

See this section of GssPolicies/InamePolicies for the specific lists.

6. I-Number Policies

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 RFC 2373, with the following modifications:

1. To conform to the XRI Specifications for persistent XRIs, Community I-Numbers use bangs ("!") instead of colons (":") or dots (".") as the delimiter for the hexadecimal values representing each 16-bit segment.

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: a) one GCS character (8 bits), b) a 16 bit hex value, or c) a 128 bit hex value.

3. In compressing 128-bit hex values, double colons are not used to represent zero-value 16-bit segments; instead left-padded zero values are assumed.

• 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 Synonym.

• This Network I-Number must be a cross-reference delegated by the host Network Authority, where the cross-reference value is the first GRS Internal Synonym (i.e., Global I-Number assigned by the GRS).

• If a Global I-Number has more than one External Synonym, the Registrant should indicate the order in which the External Synonyms will be returned in a GRS resolution response.

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-Name, with the exception that the I-Number being resolved will not be included as an Internal Synonym.

• The GRS resolution response for a Global Network I-Number MUST return the XRI Authority URIs (XAUs) and Local Access URIs (LAUs) registered to this Global Network I-Number.

6.4. I-Number Status

• A Registrant, Registrar, or GRSP may suspend a registration as specified under the Registration Agreement, the Dispute Resolution Policy, or another GSS policy. Suspension may last until the registration expires.

• A Registrant, Registrar, or GRSP may terminate a registration as specified under the Registration Agreement, the Dispute Resolution Policy, or another GSS policy. The registration may be reactivated if the termination is reversed.

• If a registration expires and is not renewed, resolution of a Global I-Number must return its last registered resolution value (including a null value if it was suspended or terminated). The registration can be reactivated if it is renewed.

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 different Resource.

• A Global Personal I-Number must not be transferred between Registrants because it represents a Personal Authority. However it may be transfered between Registrars and control may be assigned to one or more Trustees.

• Because it represents an Organizational Authority, a Global Organizational 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 Organizational Authority. It may also be transfered between Registrars and control may be assigned to one or more Trustees.

• Because it represents a Network Authority, a Global Network 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 Network Authority. Control may also be assigned to one or more Trustees.

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

• In the V1 GSS, identifiers from an external namespace or scheme (such as an email address, phone number, IM address, HTTP URI, etc.) may not be registered as a Cross-Reference in a Global Registry. XDI.ORG plans to support this functionality in a future version of the GSS after receiving further community input regarding privacy, security, and data control implications.

• Global I-Names or Global I-Numbers registered in one Global Registry may not be registered as a cross-reference in another Global Registry.

• A Global I-Name or Global I-Number used within a Community Cross-Reference (a Cross-Reference below the GRS level) must represent the same Authority as the authoritative Global I-Name or Global I-Number.

See GssPolicies/CrossReferencePolicies for detailed examples of these types of cross-references.

8. Public Authority Policies

• 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 contains XRI resolution data and metadata as defined in the XRI Specifications.

2. Proxy resolver requests are HTTP GET requests to resolve the XRI authority portion of the requested XRI. They return an HTTP redirect to the Network Authority for the target Resource.

• 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 Global I-Number resolution requests and will be set to provide an optimum balance between cache duration and update propagation.

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

• 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 Specifications, or the Public Proxy Resolver Service must return an HTTP 400 (Bad Request) error code.

• If the request include an HTTP Accept header with a value of application/xrid+xml, the Public Proxy Resolver Service must attempt to complete proxied resolution of the requested XRI and return an XRID.

• If the request does not include an HTTP Accept header with a value of application/xrid+xml, the Public Proxy Resolver Service must return an HTTP redirect to the first HTTP Local Access URI in the XRID of the target XRI Authority.

• This HTTP redirect will include the Local Path of the XRI in the original request, if any. If an error is encountered during proxy resolution, an HTTP 502 (Bad Gateway) error code will be returned.

• A GRSP may implement security safeguards for the Public Authority service intended to maintain optimal service and prevent or minimize denial-of-service or other network attacks.

9. Data Protection Policies

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. Such security protection must at a minimum cover industry-standard authentication, authorization, and access control, and must further support all privacy and accountability controls that apply to the data.

• XDI.ORG and all its Agents should adhere to the ISO 17799 international standard for Information Security Management Systems (ISMS), and should become ISO 17799 certified by a recognized certification authority.

• All XDI.ORG Agents must publish their own Community Security Policy governing the XDI data transacted with them. At a minimum it must inherit the XDI.ORG Global Security Policy, and any additional terms and conditions it contains must not conflict with that policy.

• The Community Security Policy for an XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+security.policy)". Examples:

        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) meeting the following minimum strength requirements:

• 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 Authentication Credential(s) (see below).

9.2. Privacy Policies

• XDI.ORG, its Global Privacy Policy, and all other GSS policies and specifications must observe the privacy principle of always collecting the minimum information possible to provide the desired service.

• XDI.ORG, its Global Privacy Policy, and all other GSS policies and specifications must observe the privacy principle of offering users the choice to opt-in to sharing of data or receiving of communications.

• 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 current XDI.ORG privacy policy.

• All XDI.ORG Agents must publish their own Community Privacy Policy governing the XDI data transacted with them. At a minimum it must inherit the XDI.ORG Global Privacy Policy, and any additional terms and conditions it contains must not conflict with that policy.

• The Community Privacy Policy for any XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+privacy.policy)". Examples:

        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 Policies established and published by that Agent, b) the legal jurisdiction(s) under which enforcement actions may be taken, and c) one or more means by which a perceived violation of these policies can be brought for enforcement.

• All XDI.ORG Agents must publish their own Community Accountability Policy governing the XDI data transacted with them. At a minimum it must inherit the XDI.ORG Global Accountability Policy, and any additional terms and conditions it contains must not conflict with that policy.

• The Community Accountability Policy for any XDI.ORG Agent must be available at the standard XDI address "{XDI.ORG-Agent-XRI}/(+accountability.policy)". Examples:

        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

• Public Trustee Service offers an alternative means of authentication to the GRS for Registrants who may lose access to their GRS Authentication Credential (or to their current Registrar who stores that Credential.)

• It is optional for all Registrants, but must be made available by Registrars at the time of GRS registration and thereafter when a Registrant is engaged in GRS registration management activities.

• 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 used or disclosed for any other purpose.

• The data collected by Public Trustee Service must conform to the specifications for EPP Contact Objects as defined in RFC 3733.

• All data fields are optional, however Registrants will be notified if missing data fields may significantly impair the ability of Public Trustee Service to adequately authenticate the Registrant.

• 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 the party requesting authentication is the authentic Registrant represented by the Contact Object data.

• If the GRSP cannot reasonably confirm that the party requesting authentication is the authentic Registrant, it will not release the entrusted Authentication Credential(s), otherwise it will release them to the Registrant and/or the Registrar(s) designated by the Registrant.

• Public Trustee Service is a Cost-Based Service with no fee for a Registrant to enroll and provide Contact Object data for future authentication.

• There will be a service fee to cover its costs if a Registrant requests authentication to the GRS using Public Trustee Service, which may vary by the level of effort necessary to authenticate the Registrant using the supplied data.

11. Dispute Resolution Policies

• 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 details).

• All XDI.ORG Agents must offer a Dispute Notification Service for notification of Registrants about a dispute regarding their GRS registration.

• 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 any XDI.ORG Agent and be redirected to the Dispute Notification Service operated by the Registrar for the Disputed XRI.

• 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, such as verification of the email address or I-Name of the party submitting the request.

• Once such verification is received, the Registrar must attempt notify the Registrant using the notification means selected by the Registrant under the Notification Policy (GssPolicies/RegistrarPolicies).

Please report errors to the Webmaster

Immutable page (last edited 2005-03-30 01:37:00 by DrummondReed)

Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck