Credential registry authentication

[F-Node-Karlsruhe]

First draft

Authenticated registry requests shall be performed doing a POST request carrying the authentication. As a first option we chose verifiable presentations (VPs) as the mean authentication. VPs already take over the authentication of the requesting identity by design and are a proven building block of the DID ecosystem. Further they can contain verifiable credentials which may be needed for authentication as well, e.g. GS1LicenceCredentials.

Open questions

Replay attacks

Option 1
Obtain challenge for the VP via an additional endpoint registry/{id}/challenge

Option 2
Add an expirationDate with a short delay to the VP (not intended (?) in the data model but possible with the LinkedDataSignature)

Protocol options

Allow OpenID4VP from the registry side?

• Registry provides presentation request for each route
• direct_post route is the route of the subject.id request which is then used to fetch the credentials in an authenticated way

-> Out of scope of OID4VC/little bit of misuse of the protocol -> privacy issue: the necessary authentication requirements are partially revealed with the presentation request

---

Preview | Diff

[F-Node-Karlsruhe]

OID4VP Draft

Using the authorize endpoint of authorization request of OID4VP using the cross device flow.

For the registry authorization the flow starts at step 2 (2.0 in figure) where wallet of the requesting wallet can query the Request Object containing the presentation definition and nonce/challenge (2.5). The first stop can be skipped, as we define the endpoint where the Requst Object can be fetched under registry{id}/authorize. After creating the requested authorizing presentation it can be send to the response_uri (3) which SHOULD be set to the original registry endpoint registry/{id}.

Till here we strictly followed the OID4VP cross device flow. The only difference comes after the official flow finished. Instead of ending the flow with a 200 response after the presentation was sent to the response_uri via post request, the response_uri answers with 200 and the requested credentials in the response body.