How do we map public keys to AHF services?

[emanuelpalm]

Problem

How do we keep track of who owns what inside an Arrowhead Local Cloud?

The use case we have discussed up until this point involves two brokers, each located in its own local cloud, relying on its own Quorum node. Each broker has one consuming service engaged in an ownership exchange. So far, so good. The problem I raise here comes along as soon as there are more than one consuming service in each cloud. Does each service have its own Quorum identity (Ethereum address), or does each Broker always use the same Quorum identity for all consuming services in the same cloud? If each service has its own identity—which I believe to be the more useful alternative—then how do we reliably associate a service with its own identity?

Proposed Solutions

1. Mapping AHF service identifiers to public keys.
   • Pros: Simple to implement. Transparent to consuming services. Can work without an AA(A) system.
   • Cons: Only secure if used together with a compatible AA(A) system. Coarse-grained administrative capabilities.
2. Mapping AA(A) access control objects to public keys.
   • Pros: Fine-grained administrative capabilities (e.g., broker identities could be transferred between local services via the authorization system while a local cloud is live). Transparent to consuming services.
   • Cons: Requires the existence of an AA(A) system with fine-grained access control rules (such as NGAC).
3. Services managing their own accounts.
   • Pros: Relies minimally on Arrowhead.
   • Cons: Requires consuming services to setup and manage their own accounts, keep track of their own secrets and sessions, etc. (essentially involves implementing our own AA(A) system).

My own vote goes to 2. It might be, however, suitable to implement 1 for our first prototype, especially since there is no available Arrowhead AA(A) system with fine-grained capability management , at least that I know of.

[emanuelpalm]

@NoahWinneberger What do you think? :)