GssOpSpecs

Operational Specifications

1. SPECIAL STATUS NOTE
2. Introduction
3. Global Registry Services (GRS)
1. IXRP Interface
2. IXRP Accreditation Testing
1. Preparations for OT&E Certification
2. The Registrar Tool Kit
3. OT&E Certification Test Cases
4. Post OT&E Certification
4. Public Authority Service (PAS)
1. Community Root Authority XRIDs
1. = Registry (Personal Authorities)
2. @ Registry (Organizational Authorities)
3. ! Registry (Network Authorities)
2. Delegated Authority XRIDs
1. XRIDescriptor
2. Resolved
3. AuthorityID
4. Expires
5. Authority/AuthorityID
6. Authority/URI (XAU) and Service/URI (LAU)
7. Authority/Type
8. Service/Type and Service/MediaType
9. Synonyms/Internal
10. Synonyms/External
11. TrustMechanism
3. Public Proxy Resolver Service
1. Request URIs
2. Request Formats
3. XRID Return Values
4. HTTP Redirects
5. Public Trustee Service (PTS)
1. Contact Object Management
2. Authentication Requests

1. SPECIAL STATUS NOTE

2. Introduction

3. Global Registry Services (GRS)

3.1. IXRP Interface

OASIS XDI TC

Since the EPP specification suite was designed for DNS Names and not XRI I-Names and I-Numbers, some logical mappings are necessary. The following mappings apply:

Note that there is no conventional "Whois" service in the GRS, however IXRP does use standard EPP Contact Objects for Public Trustee Service (GssPolicies/PublicTrusteePolicies). See the Public Trustee Service section below.

Open Issues for IXRP Mapping:

3.2. IXRP Accreditation Testing

3.2.1. Preparations for OT&E Certification

1. The OT&E Testbed server information and username/password for two accounts to access the GRS OT&E Testbed for Registrar client testing.

2. Instructions on where to download:

1. The IXRP Registrar Tool Kit.

2. Documentation for the IXRP Registrar Tool Kit.

3. The IXRP specifications and IXRP Common Application Programmer Interfaces (APIs).

3. Instructions on how to proceed with the OT&E certification process.

4. Instructions on how to obtain an SSL certificate from an approved Certificate Authority.

5. Instructions on how to provide the GRS with the list of subnets that will be used to access the GRS.

6. Test Plans and Procedures that will explain the test cases, test metrics, data collection, test data analysis, and reporting to be performed during OT&E verification.

The Registrar is responsible for installing the IXRP client application that will interface to the GRS using the IXRP protocol. The Registrar will interface the IXRP client to their back office systems via the IXRP common APIs. The XRI Registrar Tool Kit will be available to any interested party that would like to implement Registrar client applications.

The GRS-Registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish a SSL Version 3.0 encrypted channel. The username/password and subnet list provides additional security as only a valid combination of a SSL Version 3.0 certificate; username/password and subnet will be allowed to access the live GRS.

During IXRP client implementation, the Registrar has access to the GRS OT&E Testbed environment. In the OT&E Testbed, the Registrar may test the operation of its software to verify the correct handling of IXRP commands, their responses, and notification messages. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live GRS. Registrars will continue to have access to the OT&E Testbed after certification so they may continue to test their back office software systems.

When a Registrar has completed the testing of its IXRP client and back office systems and would like to proceed with OT&E certification, it should contact the GRS Customer Care group to schedule a time slot. Time slots will be scheduled on a first-come-first-serve basis.

The GRS OT&E Technical Support Team and Registrar will then coordinate conducting the OT&E tests at the scheduled time.

3.2.2. The Registrar Tool Kit

The Registrar Toolkit Kit is a software development kit (SDK) that will support the development of a Registrar software system for registering Global I-Names and Global I-Numbers in the Registry using the IXRP Registry-Registrar Protocol and the IXRP common APIs. The SDK will consist of software and documentation as described below.

The SDK can be used by the Registrar as a basis for connecting to the GRS Testbed environment during OT&E, and can also be used to develop a system for interfacing with the live GRS once the Registrar has been certified.

The software will consist of a working Java IXRP common API and samples of interfaces to back office systems that implement the IXRP protocol core functions and IXRP extensions that are used to communicate between the Registry and Registrar. The SDK will illustrate how XML requests (Registration Events) can be assembled and forwarded to the Registry for processing. The software will provide the Registrar with the basis for a reference implementation that conforms to the IXRP Registry-Registrar Protocol. The software component of the SDK will also include XML Schema definition files for all Registry IXRP objects and IXRP Object extentions.

The documentation will also describe the IXRP software package hierarchy, the object data model, and a description of the defined objects and methods (including calling parameter lists, and expected response behavior). New versions of the SDK will be made available from time to time to provide support additional features as they become available as well as other platform and language support.

3.2.3. OT&E Certification Test Cases

During OT&E certification, a Registrar's client application will be required to demonstrate the proper execution of the following operations.

1. SSL Version 3.0 connection establishment

2. IXRP <login> command

3. Change of <login> password

4. IXRP <logout> command

5. I-Name Operations

1. Create I-Name without I-Number and without contacts (IXRP Transform <create>)

2. Create I-Name with I-Number

3. Create I-Name with contacts

4. Create I-Name with maximum registration period

5. Create I-Name with maximum number of I-Numbers

6. Create I-Name with maximum number of contacts

7. Create I-Name with maximum length name ('=' or '@' + 127 characters)

8. Create I-Name with invalid string

9. Check I-Name (IXRP Query <check>) – I-Name not available

10. Check I-Name (IXRP Query <check>) - I-Name available

11. Check I-Name - maximum length name ('=' or '@' + 127 characters) not available

12. Query I-Name (IXRP Query <INFO>)

13. Query I-Name transfer status (IXRP Query <transfer>)

14. Delete I-Name (IXRP Transform <delete>)

15. Renew I-Name (IXRP Transform <renew>)

16. Transfer I-Name (IXRP Transform <transfer>)

17. Change I-Name (IXRP Transform <update>) - I-Number

18. Change I-Name (IXRP Transform <update>) - contact

19. Change I-Name (IXRP Transform <update>) - status

6. I-Number Operations

1. Create I-Number (IXRP Transform <create>)

2. Create I-Number with maximum length host name (80 characters)

3. Check I-Number (IXRP Query <check>) - I-Number known

4. Check I-Number (IXRP Query <check>) - I-Number unknown

5. Query I-Number (IXRP Query <INFO>)

6. Delete I-Number (IXRP Transform <delete>)

7. Change I-Number (IXRP Transform <update>) - LocalAccessURI

8. Change I-Number (IXRP Transform <update>) - remove LocalAccessURI

7. Contact Operations

1. Create contact (IXRP Transform <create>)

2. Check contact (IXRP Query <check>) - contact known

3. Check contact (IXRP Query <check>) - contact unknown

4. Query contact (IXRP Query <INFO>)

5. Query contact transfer status (IXRP Query <transfer>)

6. Delete contact (IXRP Transform <delete>)

7. Transfer contact (IXRP Transform <transfer>)

8. Change contact (IXRP Transform <update>) - change element

9. Change contact (IXRP Transform <update>) - remove element

8. Registrant Account Operations

1. Create Registrant Account (IXRP Transform <create>)

2. Check Registrant Account (IXRP Query <check>) - contact known

3. Check Registrant Account (IXRP Query <check>) - contact unknown

4. Query Registrant Account (IXRP Query <INFO>)

5. Query Registrant Account transfer status (IXRP Query <transfer>)

6. Delete Registrant Account (IXRP Transform <delete>)

7. Transfer Registrant Account (IXRP Transform <transfer>)

8. Change Registrant Account (IXRP Transform <update>) - change element

9. Change Registrant Account (IXRP Transform <update>) - remove element

9. Effectiveness and Utility of client session management and information exchange.

10. Performance of client session management and information exchange throughput.

Open Issue: operations for XAUs

NOTE: XDI.ORG reserves the right to change the OT&E certification requirements as necessary to ensure compliance with the evolving IXRP IEFT standard and IXRP common APIs.

3.2.4. Post OT&E Certification

All tests performed during OT&E certification must be completed without errors. The Registry will provide the certification results in a timely manner and provide feedback for Registrars who fail to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. This process may be repeated as necessary.

Upon successful OT&E certification, the Registrar becomes eligible for operation in the live GRS. A new username/password is assigned and the GRSP will configure the live system to recognize the SSL certificate, username, password, and subnet blocks for the Registrar. The Registrar may start operation when it has satisfied the final financial and legal requirements for going live (see section 2.2 of GssPolicies/RegistrarPolicies).

4. Public Authority Service (PAS)

4.1. Community Root Authority XRIDs

IMPORTANT: Separate XRI Authority URIs are specified for Global I-Name and Global I-Number resolution requests, even though they are directed to the same logical XRI Authority. This optimization allows the GRS to maximize resolution performance. XRI resolvers that access the GRS SHOULD use the URIs that end in the DNS label "name" when requesting Global I-Name resolution and the URIs that end in the DNS label "number" when requesting Global I-Number resolution.

4.1.1. = Registry (Personal Authorities)

• http://equals.xdi.org/xrid.xml

• https://equals.xdi.org/xrid.xml

<XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)">
    <XRIDescriptor xrid:id="1">
        <Resolved>=</Resolved>
                <AuthorityID>xri://equals.xdi.org</AuthorityID>
        <Expires>2005-09-30T00:00:00Z</Expires>
        <Authority>
            <AuthorityID>xri://=</AuthorityID>
            <Type>xri://$res*auth.res/XRIA</Type>  
            <URI>http://name.equals.xdi.org/</URI>
            <URI>https://name.equals.xdi.org/</URI>
            <URI>http://number.equals.xdi.org/</URI>
            <URI>https://number.equals.xdi.org/</URI>
        </Authority>
        <TrustMechanism>xri://$res*trusted/None</TrustMechanism>
    </XRIDescriptor>
</XRIDescriptors>

4.1.2. @ Registry (Organizational Authorities)

• http://at.xdi.org/xrid.xml

• https://at.xdi.org/xrid.xml

<XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)">
    <XRIDescriptor xrid:id="1">
        <Resolved>@</Resolved>
                <AuthorityID>xri://at.xdi.org</AuthorityID>
        <Expires>2005-09-30T00:00:00Z</Expires>
        <Authority>
            <AuthorityID>xri://@</AuthorityID>
            <Type>xri://$res*auth.res/XRIA</Type>  
            <URI>http://name.at.xdi.org/</URI>
            <URI>https://name.at.xdi.org/</URI>
            <URI>http://number.at.xdi.org/</URI>
            <URI>https://number.at.xdi.org/</URI>
        </Authority>
        <TrustMechanism>xri://$res*trusted/None</TrustMechanism>
    </XRIDescriptor>
</XRIDescriptors>

4.1.3. ! Registry (Network Authorities)

• http://bang.xdi.org/xrid.xml

• https://bang.xdi.org/xrid.xml

<XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)">
    <XRIDescriptor xrid:id="1">
        <Resolved>!</Resolved>
                <AuthorityID>xri://bang.xdi.org</AuthorityID>
        <Expires>2005-09-30T00:00:00Z</Expires>
        <Authority>
            <AuthorityID>xri://!</AuthorityID>
            <Type>xri://$res*auth.res/XRIA</Type>  
            <URI>http://bang.xdi.org/</URI>
            <URI>https://bang.xdi.org/</URI>
        </Authority>
        <TrustMechanism>xri://$res*trusted/None</TrustMechanism>
    </XRIDescriptor>
</XRIDescriptors>

4.2. Delegated Authority XRIDs

4.2.1. XRIDescriptor

4.2.2. Resolved

4.2.3. AuthorityID

4.2.4. Expires

4.2.5. Authority/AuthorityID

4.2.6. Authority/URI (XAU) and Service/URI (LAU)

1. For Network I-Numbers, the XAU and LAU values MUST be those registered directly in the GRS by the XDI.ORG-Accredited Registrar represented by the Network I-Number.

2. For all other Global I-Names and Global I-Numbers, the response will depend on each Network I-Number registered as an External Synonym for the Resolved XRI value.

1. If the GRS is not the Delegating Authority for this Network I-Number, no XAU or LAU shall be returned, only Internal and External Synonyms (below). Note that in this case the GRS resolution response is considered an XRI Redirect.

2. If the GRS is the Delegating Authority for this Network I-Number, the GRS will return one XAU or LAU conforming to the following ABNF for each XAU or LAU registered to the Network I-Number, respectively.

        return-URI        = net-inum-URI "/" global-inum-syn
        net-inum-URI      = XAU or LAU from Network I-Number of Delegating Authority
        global-inum-syn   = priority Global I-Number Synonym for Global I-Name or Global I-Number

4.2.7. Authority/Type

4.2.8. Service/Type and Service/MediaType

4.2.9. Synonyms/Internal

4.2.10. Synonyms/External

4.2.11. TrustMechanism

4.3. Public Proxy Resolver Service

4.3.1. Request URIs

• http://public.xdi.org/

• https://public.xdi.org/

4.3.2. Request Formats

4.3.3. XRID Return Values

4.3.4. HTTP Redirects

5. Public Trustee Service (PTS)

5.1. Contact Object Management

RFC 3733

PTS Contact Objects MUST support the attributes specified in Section 2 of RFC 3733.

Open Issue: Are there any attributes the PTS does not need?

Open Issue: Do we want to specify a Global I-Number for the Contact Identifier in section 2.1?

Registrars MUST be able to perform the EPP Transform Commands on a Contact Object (create, delete, transfer, update) as defined in section 3.2 of RFC 3733.

5.2. Authentication Requests

This form MUST include the PTS Terms of Service Agreement (GssAgreements), payment for the PTS Authentication Request, and the following additional information:

1. Current Contact Data is the set of Contact Object attribute values specified under Contact Object Management (above) that represent current contact data for the requestor.

2. Global I-Names and/or Global I-Numbers subject to the authentication request.

3. Authentication Data is the same set of Contact Object attribute values originally supplied by the Registrant (to the best of his/her knowledge).

4. Authentication References is contact and descriptive data for third parties who can verify the original authentication data.

5. Special Circumstances enables the requestor to explain any special circumstances reqarding this authentication request.

6. New Trustees is a list of the Registrar(s) the requestor designates to receive a copy of the entrusted Authentication Credential if PTS authentication is positive. This may be left blank, in which case only the requestor will receive a copy of the Authentication Credential(s).

7. Authorization for the GRSP to Perform Authentication is the explicit statement of authorization for the GRSP to execute the authentication request.

The GRSP MAY also provide an equivalent online HTML interface, linked from XDI.ORG and the GRSP's website, that accepts payment via credit card or other electronic payment means.

Please report errors to the Webmaster

Immutable page (last edited 2005-10-26 05:16:42 by DrummondReed)

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