UserPreferences

IbrokerUseCases


1. Cordance I-Broker v1.0 Use Case Outline

  1. Cordance I-Broker v1.0 Use Case Outline
    1. Registration
      1. Global I-Names
        1. Check Availability of a Global I-Name
        2. Register Global I-Name
          1. Variation: =Name
          2. Variation: @Name
          3. Variation: First-time Global Registrant (No Global I-Number)

1.1. Registration

1.1.1. Global I-Names

1.1.1.1. Check Availability of a Global I-Name
1.1.1.2. Register Global I-Name
1.1.1.2.1. Variation: =Name
1.1.1.2.2. Variation: @Name
1.1.1.2.3. Variation: First-time Global Registrant (No Global I-Number)

Variation: Previous Global Registrant (Existing Global I-Number)

Variation: Previous Global Registrant But New Account & New Global I-Number

To what extent do we or should we separate the registration of an i-name from the creation of an account such that a registrant can register an i-name without creating an account?

DSR: Logically, they are separate operations. The GSS (Global Services Specifications) will specify that the i-broker must submit an i-number when registering a global i-name. An unresolved issue is whether the i-broker must first register a community i-number as a global i-number before submitting the global i-number as the resolution value for a global i-name. For example, in order to register "=Drummond.Reed" to resolve to "=!(!!1002/!1001.1234.5678)", the GSS needs to specify whether the broker needs to first register "!!1002/!1001.1234.5678" with the "=!" registry, or whether both registrations (the global i-name and the global i-number) can both be accomplished in one operation.

But that's all going to be covered in the GSS. The use case only needs to specify: a) functional requirements for the user, and b) functional requirements for the i-broker.

The functional requirements for the user in this case that the i-broker must confirm with the user whether the users want to register a new global i-name to their current account, or whether they want to set up a new, SEPARATE account for this i-name.

The functional requirement for the i-broker is that it must determine what the user wants to do, then format the registration request properly so that the new global i-name is registered to the proper global i-number. Wait List Global I-Name [Is there a GCS specification for this? Without such a specification this could be controversial]

Yes, there will be a GSS spec for it, and Cordance/NeuStar/AmSoft is going to write it. The spec will be based on the use cases we develop here. From a functional requirement standpoint, it means that if a global i-name is taken, the user should be given the choice of purchasing a place on the wait list. The i-broker should then be able to check the depth of the wait list (I don't think wait lists need to have any specified depth – the depth can depend on the demand for that i-name.) Once the i-broker reports back to the user, if the user decides to proceed with purchasing a place on the wait list, the i-broker needs to be able to submit the wait list registration request, get the confirmation, and then list an i-name as "wait-listed" in the user's account. Variation: =Name Variation: @Name Variation: First-time Global Registrant (No Global I-Number) Variation: Previous Global Registrant (Existing Global I-Number) Variation: Previous Registrant But New Account & New Global I-Number Transfer Global I-Name Variation: =Name Variation: @Name Variation: First-time Global Registrant (No Global I-Number) Variation: Previous Global Registrant (Existing Global I-Number) Variation: Previous Registrant But New Account & New Global I-Number Change (Rename) Global I-Name Changing a global i-name as a use case in v1 can be handled through instructions to the registrant to register a new global i-name and let the previous registration expire (or transfer it if desired.) Renew Global I-Name (v2) Note: included only as a reminder that this function must be in v2. Community I-Names (To be discussed whether in scope for CIBv1.) User Account Management Authentication Login to Account Recover Password Recover I-Names Change Password I-Name Management Note that this is intended to capture the use cases from the perspective of an existing account holder invoking these use cases from within the account UI, not a brand new registrant. Add New I-Name Note that this could invoke either Register Global I-Name or Register Community I-Name (if the latter is in v1). Delete I-Name Note: this may be optional for v1 (the registrant can always just let the i-name expire.) Personal Contact Gateway Setup and Management Activate Contact Gateway Deactivate Contact Gateway Note that this is required to provide the owner with a way to temporarily turn off their gateway without losing any of the information contained in it.

I don't get the use case. Is this like a vacation message or something? Or is this a way of "turning off" a contact gateway completely – so if someone activates a link to the contact gateway page, the page comes back and says "No longer active." or something like that? Delegate Control of Contact Gateway Note that this is required if the PCG is to be used by parents to control how others can communicate with their children.

Good catch. Delegation is in fact a huge issue. I think this should be designed into the account structure itself. I've updated the account management use cases below to reflect this. Let's discuss when we have time to make sure we're sync'd on this. Configure Contact Gateway (Wizard) Includes both text/images to be displayed and form field inputs to be included (most likely a limited menu of options). Probably should be designed as a multi-step wizard. View Contact Gateway Addresses Should display the users contact gateway address(es) (both i-name based and i-number based), explain the differences, and explain how to use them. Preview Contact Gateway Page This will show the user what their contact gateway page will look like. It may be the last step in the wizard (above), but it should also be a standalone option. Send Sample Email with I-Name Signature This email would demonstrate to the account holder how they can use their contact gateway address as their email sig. This is important for viral propagation of i-names. Contact Usage Invoke Contact Gateway Variation: I-Name Holder Variation: I-Name Holder and Trust Network Member Account Holder Usage Respond to Contact Request Variation: Direct Response Variation: Blind Response Variation: Share I-Business Card (v2) Configuration, Administration, and Reporting Configuration Need to fill in all required v1 configuration options. Primary Account Administration A primary account is one that is administered directly by an end-user using authentication credentials associated directly with this account. Create Account Note: this may only be needed as a secondary use case, i.e., invoked by another use case such as Register Global I-Name. Variation: =Account Variation: @Account Suspend Account Needed to deal with non-payment or violation of terms-of-service. Variation: =Account Variation: @Account Delete Account Note: may only be needed as an administrative function by the I-Broker Administrator. Variation: =Account Variation: @Account Secondary Account Administration A secondary account is one that is not administered directly by an end-user, but administered by one or more a primary accounts. Secondary accounts are needed for: • Delegated control of a =account (such as a parent, who has a primary account, registering a secondary account for their child.) • Control of an @account. It is a requirement that an @account be administered by one or more =accounts. Create Secondary Account Variation: =Account Variation: @Account Suspend Secondary Account Variation: =Account Variation: @Account Delete Secondary Account Variation: =Account Variation: @Account Reporting Need to fill in all required v1 reports. Number of Accounts • By type • By date range Number of Global I-Name Registrations • By type • By date range • Show associated revenues