AppID AdHoc Technical Issues Group Name AppID AdHoc

App-ID Ad-Hoc Technical Issues Group Name: App-ID Ad-Hoc Group Source: Darold Hemphill, iconectiv, dhemphill@iconectiv. com Meeting Date: 2015 -01 -12

Contents • Registry challenges • Possible registry solutions: Partitioned vs. Central/Root • Required attributes • Proposed App-ID syntax • Use case scenarios • What App-ID is not © 2014 one. M 2 M Partners 2

Registry Challenges • • Ensuring App-IDs are not duplicated Required fields are provided Archive and Validate API (WADL, WSDL etc. ) Identify Company or Group creating App-ID – Company creating App-ID is only party allowed to version the App-ID i. e. , version 1, version 2 (not software version) – Associating users to companies to control authorization – Maintain Company/Group buyouts, mergers, acquisitions © 2014 one. M 2 M Partners 3

Partitioned Registry Registrar B B-123 Registrar A A-123 Registrar C C-123 Pros • Steering Committee assigns namespaces to Registrars • Registrars are independent - no common infrastructure Cons • Synchronization 1 between Registrars required to provide view of all App-IDs • Namespace included in App-ID name e. g. , A-123, B-123, C-123, registrar lock-in • All registrars must implement solution correctly or the registry will suffer • Company changes registrar will change name space of future App-IDs Possibly model database synchronization off of Whitespace database–to–database synchronization specification http: //transition. fcc. gov/bureaus/oet/whitespace/guides/TVWS_Database_Synchronization_Interop. Spec_V 1. 1. 1%204 -17 -12. pdf 1 © 2014 one. M 2 M Partners 4

Central/Root Registry Pros Registrar A ABC-123 • DB Layer and some processing is common • Single naming space • No synchronization • Common reference data e. g. , Company Code • API is RDBMS or API • Scales with # of Registrars Cons • Someone needs to build and maintain the DB and API as a shared resource • API source ownership Registrar B ABC-124 Registrar C ABC-125 Firewall API Central/Root Registry Common Infrastructure © 2014 one. M 2 M Partners 5

Required Attributes for App-ID • Company (and User) requesting the App-ID – Who can version the App-ID? • Version of the App-ID – Expect that APIs will expand change over time • Protocol of the App-ID – App-ID for REST and SOAP might have the same scope, but nodes can speak one protocol and not the other © 2014 one. M 2 M Partners 6

App-ID Scenario 1 • Company A creates App-ID X version 1 for a REST API • Hardware and software environment build around App-ID X • Company B creates a variation of App-ID X Questions 1. Should any Company B be able to define App-ID X version 2 or create their own App-ID? © 2014 one. M 2 M Partners 7

App-ID Scenario 2 • The Steering Committee initially assigns 3 registrars in a partitioned App-ID solution. • After some time, one of the registrars wishes to discontinue supporting their registry partition. • The Steering Committee would need to transition the partitioned App-ID space to a new registrar or existing registrar who would assume responsibility for maintaining the App-IDs going forward. • Companies wishing to version their App-IDs will purchase from new registrar. Note: this scenario only occurs in a partitioned App‑ID registry. © 2014 one. M 2 M Partners 8

Summary • This is an introduction to the Registry issues • An initial draft of recommendations is contained in contribution TP App. ID-2014 -0001 • It is understood that additional concepts and issues may arise as the result of this overview 9