Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

Latest commit

 

History

History

2022-07-01-service-authentication

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 

Service authentication

Decision

Access to the Registration Service API is authenticated.

Callers must provide a Bearer token containing a JSON Web Token (JWT) transmitted as a JSON Web Signature (JWS) signed with an ECDSA P-256 Elliptic Curve key.

Tokens contain the following claims:

Claim Value
Issuer The participant did:web identifier (example: did:web:example.com). The Issuer Claim must resolve to a DID Document containing the public key of the key pair used to sign the JWS. This allows the server to verify the token signature against the source's public key.
Subject The same value as in the Issuer claim.
Audience The Registration Service API base endpoint (example: http://dataspace.example.com:8182/authority). This allows the server to verify the intended audience.
JWT ID A random UUID.
Expiration Time A time set in the near future.

Authentication is implemented as follows:

  • On the server side, a ContainerRequestFilter intercepts incoming requests, retrieves the DID Document corresponding to the issuer, verifies token signature and claims, and inserts a new request header containing the Issuer claim. This allows controllers to use the claim for application logic (for example, to register a new participant by its DID). The filter leverages the services provided in the EDC identity-did-core and identity-did-crypto modules to verify tokens and to resolve and parse DID documents. The server must be configured with a jwt.audience setting (e.g. as the JWT_AUDIENCE environment variable) containing the expected audience, i.e. the URL used by the client to access the API.
  • On the CLI client side, a Request Interceptor modifies outgoing requests, to add the required JWS header. This requires the CLI to have access to a file containing the private key, and to be configured with the correct DID.

For local testing with Docker Compose, an nginx container is deployed to serve a DID Document. The EDC_IAM_DID_WEB_USE_HTTPSvariable is used to use http:// instead of the https:// scheme for resolving DID URLs, to avoid having to set up SSL.

Rationale

Authentication ensures that only actors who can assert their control of a did:web identifier can register that identifier as a dataspace participant. Authentication and retrieval of DID document will also serve as the basic block for retrieving verifiable credentials and building an authorization system.

The choice of authentication scheme and key type is driven by the schemes currently supported in EDC, and can be extended as needed in the future.