MAP Security Model

<THIS SECTION IS UNDER CONSTRUCTION>

Overview

The Person-Centric Architecture of the MAP has a profound impact on the security model because it reverses many of the assumptions shared by traditional security models.

CONVENTIONAL MODEL	MAP's PERSON-CENTRIC MODEL
State may be distributed	All state is local (to the agent)
Application logic may be distributed (e.g., REST services)	All application logic is local -- i.e., it is executed locally within the agent
Integrations are distributed	All integrations are local -- i.e., they happen within an agent

Primary Elements:

The MAP Security Model is composed from the following primary elements.

• I-Spaces (map-i-space-happ) provide encapsulating membranes. Each agent (person, org, etc.) has its own I-Space that provides agent identity, data storage, and membrane enforcement for that I-Space. The I-Space keeps track of what agents belong to (i.e., are contained within the membrane of) that I-Space. The I-Space mediates all service interactions between agents contained within that I-Space and the We-Spaces in which the service invocation happens. It offers functions that support service requests. These functions are bridge functions, which means they can be invoked from other happs that share the same computing node.

• Agent Identity. Each agent has a cryptographic identity. Specifically, each agent has a set of keys that includes:

  • Signature Key Pair consisting of a private signing key the agent uses to sign messages it originates and a public signature verification key that can be used by other agents to verify that messages were, in fact, signed by that agent.

  • Encryption Key Pair consisting of a private decryption key paired with a public encryption key .

• Service Offers. Agents offer services to other agents. The memetic signature of the offer, spells out the terms and conditions of the offer. This includes definition of the reciprocal resource flows that stem from service invocations and the responsibilities of both agents with respect to those resources. Often, delivery of a service depends upon having access to information from the service receiver. The information (e.g., properties, holons) required in order to deliver the service can be specified in the offer in terms of the information model defined in MAP Meta-Spaces.

• We-Spaces: are where offers are placed. Once accepted, offers become agreements that are created and logged in (ususally) different We-Spaces. Service invocations and responses are logged in the same We-Space as the service agreement that governs these invocations.

• Meme-Spaces: contain standard information sharing agreements that can be proven and reused in different service offers.

• Meta-Spaces -- provide descriptors of the holons, properties, action and holon relationships that can be referenced in offers and agreements -- software readable descriptions allow enforcement within the MAP platform -- off-loading this burden from hApp developers.

• Service Offers -- specify what service is offered (described via L0 ontology), what info is required in order to deliver that service, what service invocation protocol(s) are supported, e.g., JLINC. Public signing key of the Provider.

  • Tie to CC License Types -- opposite purposes, but similar vectors

    • CC ZERO -- allows sharing by default -- MAP ZERO: precludes sharing with any other agent by default

    • CC BY -- must identify source of info -- MAP: must NOT identify source agent

    • CC SA -- if shared, receiving party must also agree to license terms -- MAP: same

    • CC NC -- info received must not be used for commercial purposes -- MAP: same

  • Tie to CC 3-level architecture: Legal, Human, Software readable

  • References to MAP L0 type descriptors (actions, holons, properties, holon relationships)

  • On the importance of standards (e.g., FHIR) to minimize semantic data mapping complexities

  • Standard Info Sharing Agreements can be stored in MAP Meme Space happ

  • Offers are placed in We-Spaces

• Agreements

  • Accepting an Offer creates an Agreement, typically in a new We-Space

  • Agreements are logged in the We-Space and include all 3-levels of the Information Access Agreement (so legal and human readable expressions are also enjoy cryptographic protections)

  • Auditors may be (temporarily) added to a We-Space

  • reference the offer, include the public signing key of both the Provider Agent and the Requester AGent

Service Invocations:

All invocations of a service originate from an originating cell of an app on a computing node agent. The originating cell initiates the invocation by making a bridge call on the map-i-space app's request function. For example, suppose my I-Space contains my laptop, my smartphone and my desktop computer.

• Requesting party:

  • Builds the request

  • Request must reference the Agreement and the invocation protocol (e.g., JLINC)

  • Digests the request and signs it using their private signing key

  • Encrypts the signed message using the receiving party's public encryption key (retrieved from the Agreement)

  • submits the request to the We-Space in which the Agreement is active

• We-Space:

  • logs the request (in merkle chained event log)

  • Receiver:

    • decrypts the message using their private decryption key

    • extracts and dereferences the agreement

    • validates the agreement:

      • is the agreement active

    • Authenticates the request:

      • uses the public signing key extracted from the agreement to validate the request signature to ensure requesting party was in fact the party noted in the agreement

      • generates a digest for the message and compares it to the digest included in the request to ensure request has not been modified in route.

    • Authorizes the request:

      • compares the info / actions requested in the request with what is authorized in the agreement

      • if authorized, forward the request to the service implementation

    • Execute the request

    • Compose the response

      • build the response object

      • include the response elements specified in the service definition

      • digest the response and sign the response using their private signing key

      • encrypt the response using the public encryption key of the service requesting party (retrieved from the Agreement)

    • Log the response and deliver to the requesting party

  • Requesting party receives response:

    • authenticates the response

    • validates the response

    • authorizes the response

Authentication

Access Control

Audit

Cryptographic Techniques:

The MAP Security Model relies on several well-known and widely-used cryptographic techniques.