Steps involved
Flow diagram:
-
Client (OP) initiates an Auth request by POST-ing to an endpoint, like for instance
/did-siop/v1/authentications
or clicking a Login button and scanning a QR code -
Web (RP) receives the request and access the RP object which creates the Auth Request as JWT, signs it and returns the response as an OpenID Connect URI
-
JWT example:
- The Signed JWT, including the JWS follows the following scheme (JWS Compact Serialization, https://datatracker.ietf.org/doc/html/rfc7515#section-7.1):
BASE64URL(UTF8(JWT Protected Header)) || '.' || BASE64URL(JWT Payload) || '.' || BASE64URL(JWS Signature)
- Create the URI containing the JWT:
claims
param can be either avp_token
or anid_token
:
-
-
Web receives the Auth Request URI Object from RP
-
Web sends the Auth Request URI in the response body to the client
-
Client uses the OP instance to create an Auth response
-
OP verifies the auth request, including checks on whether the RP DID method and key types are supported, next to whether the OP can satisfy the RPs requested Verifiable Credentials
-
Presentation Exchange process in case the RP had presentation definition(s) in the claims (see Presentation Exchange chapter)
-
OP creates the auth response object as follows:
- Create an ID token as shown below:
- Sign the ID token using the DID key (kid) using JWS scheme (JWS Compact Serialization, https://datatracker.ietf.org/doc/html/rfc7515#section-7.1) and send it to the RP:
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
-
OP returns the Auth response and jwt object to the client
-
Client does a HTTP POST to redirect_uri from the request (and the aud in the response): https://acme.com/siop/v1/sessions using “application/x-www-form-urlencoded”
-
Web receives the ID token (auth response) and uses the RP’s verify method
-
RP performs the validation of the token, including withSignature validation, expiration and Verifiable Presentations if any. It returns the Verified Auth Response to WEB
-
WEB returns a 200 response to Client with a redirect to another page (logged in or confirmation of VP receipt etc).
-
From that moment on Client can use the Auth Response as bearer token as long as it is valid