Skip to content

Architecture

Jump to bottom
osancus edited this page Jun 26, 2020 · 2 revisions

Requirements

The system is based on requirements, which define the architectural approach:

  1. Data from services should be streamed as directly as possible (with minimal involvement by anybody else in the transfer process)
  2. The MyData Agent (i.e. the system that the individual end-user uses) should be able to communicate with any other compatible agent (i.e. organization).
  3. The data sources (services) should not need any extra integrations to be included as a service. This means that the MyData Agent should be fully responsible for the integration.
  4. The consent given through the MyData Agency should be actionable by the organization's enterprise IT system automatically.

Architectural overview

The architecture can be divided into five major domains, which all include different services with potentially different service providers. Each of the domains represent independent systems that integrate via common protocols.

Architecture

Service domain

Services are data systems that are used by individual end-users. These are usually cloud-based systems that allow the end-user to collect and use data about themselves. It is becoming a common practice that these systems open APIs to allow integration and extended use of the data. Services don't require anything special installed to be included by the services.

Integrations to service domain via:

  • Custom API integration
  • Standard API protocol integration

NOTE The current services are directly integrated, but future releases should include more general API protocol-based integrations, instead of service-level integrations.

End-user domain

This domain represents the service that the individual end-user uses to manage connections and consents with organizations. The MyData Agency is an example service that allows the individuals to (a) Register Services as data sources, (b) Connect with Enterprise Agents, (c) issue consent credentials to connections and (d) proxy data from services to organizations. The example service is a Hyperledger Indy-based agent, that connects with other agents using the IndyComm-protocol.

Integrations to end-user domain via:

Enterprise domain

This domain represents the enterprise IT-environment, including the enterprise services that wish to integrate with the agent-service and utilize the consent, data, etc. Within the enterprise domain are (a) the enterprise agent that handles connections with other agents; (b) the business logic that manages data fetching, event triggers and operations that the enterprise system performs through the agent towards the end-user; (c) consent database that stores the consents and uses it to maintain the status of the end-user consents; (d) the databases/data-services and users of the data that is retrieved from the end-user services.

Integrations to enterprise domain via:

  • IndyComm protocol -capable agent (end-user connections)
  • API-integration between agent API & business logic (enterprise-side outbound events)
  • callback integration between agent webhooks & business logic (enterprise-side inbound events)

Authentication domain

This domain represents an authentication system that is capable of authenticating the end-user and issuing strong authentication credentials. In principle this can be any authentication service that has a IndyComm capable issuer service.

In the current version, the authentication component is directly integrated with the enterprise IT providers authentication service, and uses the enterprise agent to issue the authentication credential.

Integrations to authentication domain via:

Identity infrastructure domain

This domain represents the identity infrastructure that is supported by the agents. The role of the identity infrastructure is to verify the signatures used to issue consent credential, and verify the credential revocation status. The infrastructure enables the end-users to control access to their data by issuing consent (enabling access) and revoking the consent (disabling access). The identity infrastructure can be any type of registry that has a registered and implemented DID-method, and that the agent software supports.

Integrations to identity infrastructure domain via:

Clone this wiki locally