DRAFT- InProgress

 Abstract

Commentary:

The  App Directory (AppD) is a service that provides a financial application definition that includes a trusted identifier(s) and associated metadata.  The information registered as part of an application definition supports discovery, launch configuration, intents and context data supporting the use and interoperability of financial applications.  This proposal recommends use of a distributed or detached model to managing application data servicing, where there are (N) AppD services on a network providing information related to a subset of namespace "zones" that align with the financial application identifiers.  This approach encourages independence, scale and responsive provisioning of application definitions. This is modeled from a subset of the public name service "Domain Name System", which has proven reliable and conceptually fit for discovery.

In order to support the discovery of application data stored in a given directory, name space concepts are introduced to both identify the realm of application definitions and AppD service locations that host data.  In simple terms, there has to be a way of discovering the location of the AppD service itself and the associated application definitions that are available from that service.  

This proposal focuses on defining the following key features to support this need:

• Application data discovery through nested namespace approach. (Note: An expanded definition is required outside this proposal)
• AppD service host discovery implementations should support the following requirements;
  1. Discovery through application ID namespace syntax host name resolution 
  2. Discovery through use of DNS SRV record types (RFC2782 ) - **Preferred  
  3. Federated discovery of URI records between AppD services
  4. Statically defined URI records for use within client applications directly

...

The following represents the three ways AppD service instances should be discovered over a given network.  Again, the view is that AppD services are distributed/decoupled based on associated application namespace on a given network.  This takes into account the use of the application identifiers described in previous section.  A launcher is required to use a URI (e.g. "https://appd.foo.com/api/appd/app1.appd.foo.com") to query a given directory instance for data.  In order to construct a URI, the host location and port of a given AppD service instance is required.  This proposal focuses on the following approaches to achieve this resolution. 

Application ID namespace syntax host resolution

An application directory URI can be constructed using a fully qualified application ID by recognizing the identifier as a fully qualified domain name, whereby the subdomain of the fully qualified application ID can resolve to the application directory host.  Given an application "app1" with a fully qualified identifier of "app1.appd.foo.com" an application directory host location can be derived by simply extracting the subdomain "appd.foo.com".   The extracted subdomain "app.foo.com" must resolve to the actual host location where the application directory is running.   

A launcher can then easily construct a URI by; 

1. URI protocol is defaulted to https, but can be overridden by the launcher. 
2. URI hostname is the subdomain of the fully qualified application ID. 
3. URI port is default https/443, but can be overridden by the launcher
4. URI url is by default "/api/(service)/(version)" .  It is recommended that we identify service label as "appd" with version being optional.  Calls that are made without version automatically default to latest "/api/appd/app1" vs "/api/appd/v1/app1" 

The resulting URI to retrieve application data for "app1" would be "https://appd.foo.com/api/appd/v1/app1.appd.foo.com"  

 Application identifiers, Shrinking the URI and AppdD defaults

Although the concept of fully qualified application IDs are useful in resolving the actual host of the application directory, there is no requirement for an application directory to use this fully qualified application ID as the resolver for a record.  An  application ID is unique to given application directory, but there is no requirement to use the fully qualified representation.  Taking the prior example, the fully qualified application ID "app1.appd.foo.com" is represented as "app1" within the application directory.  As a result a launcher can use a shortened URI construct "https://appd.foo.com/api/appd/v1/app1" to resolve the application data. 

DNS/SRV Records

The recommended Another approach to support AppD service discovery (resolution) is through use of existing domain name service (DNS) implementations that are broadly used on the Internet today (see: RFCs).  Name service implementations can be considered critical infrastructure and are proven stable with over twenty years of use. Name services can be used both through public Internet or locally deployed intranet, which provides optionality to deployment schemes. 

...