Integration Steps

Prerequisites

• The legal entity has completed onboarding in the DOME ecosystem.

• The LEAR has obtained a valid LEARCredentialMachine through the Issuer service.

• DID method supported: did:key.

• The confidential client (backend service or secure web app) is registered in the Verifier with its:

  • client_id (DID or URI).

  • redirect_uri (for authorization response).

  • jwks_uri (endpoint exposing the client’s public key set).

• The client’s private key is securely stored (e.g., in an HSM or vault).

• Access to developer documentation and environment URLs.

Step 1 – Machine credential issuance

The LEAR of the organization issues a LEARCredentialMachine to the backend service (the confidential client).

• The credential is a Verifiable Credential (VC) in JWT format.

• It is bound to the machine’s DID, derived from its public key.

• The private key must be securely stored and never shared.

Outcome:
The machine (confidential client) holds a valid LEARCredentialMachine and its associated DID key pair.

Step 2 – Client configuration

Client type: Confidential.

• Register the client in the Verifier’s Authorization Server.

• Provide the jwks_uri exposing the public keys used for signing JWTs.

• Ensure the redirect_uri is pre-registered and uses HTTPS.

• Implement JWT-based client authentication (client_secret_jwt).

Outcome:
The confidential client is fully configured to authenticate using signed JWTs and perform the Authorization Code Flow.

Step 3 – Authorization request

The confidential client starts the authorization process by redirecting the user to the Authorization Endpoint with a signed Authorization Request Object.
This object is a JWT containing all authorization parameters, hosted at a request_uri.

The Authorization Server retrieves this JWT, validates its signature against the client’s registered jwks_uri, and proceeds with the flow.

Non-normative example:

Step 4 – Authorization response

After the user successfully authenticates and authorizes access, the Authorization Server redirects back to the client’s redirect_uri with an authorization code.

Non-normative example:

Step 5 – Token request

The client exchanges the authorization code for tokens by calling the Token Endpoint.
In this step, the client authenticates using client_secret_jwt, sending a signed JWT in the client_assertion parameter.

Non-normative example:

Non-normative example of a Token Request:

Outcome:
The Authorization Server validates:

Step 6 – Token response

Non-normative example:

Outcome:

Step 7 – Use access token

The confidential client uses the access_token to call Verifier-protected APIs: