2022-06-16-distributed-authorization

Distributed authorization sub-flow

This sub-flow is used for a service to authenticate and authorize requests from a Dataspace Participant.

Participants

1. Participant A, which performs a request to Participant B. (Participant A could be a company enrolled within a dataspace.)
2. Participant B, which serves a request to Participant A, and needs to establish Participant A's credentials. (Participant B could be a company enrolled within a dataspace, or the Dataspace Authority, depending on the flow.)
3. Authority, which is an issuer of Verifiable Credentials of Participant A. (Authority can be e.g. external Gaia-X Central Authority or Dataspace Authority, depending on the flow.)

Overview

Participant A needs to establish its identity and credentials in order to access a service from Participant B. Selecting and transporting Participant A's verifiable credentials in request headers would be too bulky and put too much logic in the client code. Therefore, Participant A sends it's DID (in a JWS) and a bearer token, allowing Participant B to authenticate the request, and obtain Participant A's verifiable credentials from its Identity Hub.

A DID JWS cannot be used by Participant B to authenticate itself to Participant A's Identity Hub, as endless recursion would ensue.

Pre-conditions

1. Participant A has deployed an Identity Hub service, and a DID Document containing the Identity Hub URL.
2. The Participant A Identity Hub contains VCs that satisfy the Participant B's service access policy.
3. The Authority has deployed a DID Document allowing to retrieve the public key.

Flow sequence

1. The Client for Participant A (which could be EDC, or any other application) sends a request to Participant B's API. The client needs access to Participant A's Private Key to sign a JWS. (In future versions the client will send also a time-limited bearer token granting access to its Identity Hub.)
2. Participant B retrieves the DID Document based on the DID URI contained in the JWS.
3. Participant B authenticates the request by validating the JWS signature against the public key in the DID Document.
4. Participant B finds Participant A's Identity Hub URL in the DID Document and retrieves Verifiable Presentation containing Verifiable Credentials from Participant's A Identity Hub. (In future versions Identity Hub will perform authentication using bearer token sent from Participant B.)
5. Participant B retrieves the DID Document of the Participant A's Verifiable Credentials issuer.
6. Participant B validates the VC signature against the public key in the DID Document.
7. Participant B applies its access policy for the given service. This applies rules specific to a given service. For example, the caller must be a dataspace participant (i.e. have a valid Verifiable Credential signed by the Dataspace Authority, that establishes its dataspace membership).
8. Participant B returns the service response if the request was successfully authorized, otherwise, an error response. Depending on the flow, the response can be synchronously or asynchronously returned.