DID forwards compatibility

[woutslakhorst]

List of required changes

Config

• [x] #3253

DID feature consolidation

• [x] Remove controllers #3193
• [x] https://github.com/nuts-foundation/nuts-node/issues/3258

Storage

• [x] #3193
• [x] Support versioning of DID documents (required for did:nuts and did:tdw). (#3193)

VDR v2 API

• [x] Check if creationOptions is still applicable. Maybe make it a map with each method as key, so a caller can add custom settings if required. Default of nothing creates all configured methods.
• [x] Use subject_id instead of did as parameter
• [x] Support root did:web via config => auto create did:web. Used for PoCs (later?)

VDR

• [x] change main interface implementation so it can determine subject_id, DID, VM.id and Service.id. This influences lower level managers (maybe via options construct). #3208
• [x] add alsoKnownAs to did documents based on sql db (did table) #3208

Auth v2 API

• [x] Usage of didweb.DIDToURL is not forwards compatible. Change API so auth server url can be passed: https://github.com/nuts-foundation/nuts-node/issues/3197
• [x] Use subject_id instead of did as parameter: https://github.com/nuts-foundation/nuts-node/issues/3262
• [x] https://github.com/nuts-foundation/nuts-node/issues/3258
• [x] https://github.com/nuts-foundation/nuts-node/issues/3314

Discovery API

• [x] #3265

Migration

• [x] update all did:nuts documents so they're self-controlled. #3193
• [x] check if did:nuts docs are up2date with sql state?
• [x] #3330
• [x] #3329
• [x] add alsoKnownAs to did:nuts docs via network transactions?
• [x] fault tolerant migrations (extended testing required)

Wallet

• [x] All PEX related flows should operate on all wallets for a subject. (Does this create multiple VPs when combining wallets?)
  • [x] https://github.com/nuts-foundation/nuts-node/pull/3320
  • [x] https://github.com/nuts-foundation/nuts-node/pull/3322
  • [x] Presentation Submission building should take alsoKnownAs into account
  • [x] Decide whether we want to support multiple VPs in 1 submission (and implement)
• [x] Verifiable Presentation verification should take alsoKnownAs into account

Key management

• [x] select latest key for issuance (and other operations). This is currently not done, but with the introduction of the DB, this becomes possible. Removing VMs is therefore not needed. (at least for now) #3260

Broken

• [x] did:nuts with azure key vault combo (or other remote key generation) #3260

[reinkrul]

For private key storage, we should consider providing both subject and key ID to the storage layer; depending on the backend, it can then store keys in a multi-tenant or hierarchical manner, if supported.

[reinkrul]

There should be a way to derive the subject ID from a DID: when a remote party accesses data using a service-to-service access token, the PEP extracts the DID of the local party, which is then passed to the upstream resource server.

But the vendor applications now interact with the Nuts node using the subject ID instead of DID, so applications administer subject ID of DID (e.g. in mapping to a tenant/customer-specific FHIR store). Thus; it needs to know which subject the token is about, instead of just the DID. Options:

• Have an API that returns the subject ID for a particular DID (and all related DIDs and other useful info)
• Have Token Introspection provide the subject ID

Issue: https://github.com/nuts-foundation/nuts-node/issues/3258

[woutslakhorst]

There should be a way to derive the subject ID from a DID: when a remote party accesses data using a service-to-service access token, the PEP extracts the DID of the local party, which is then passed to the upstream resource server.

But the vendor applications now interact with the Nuts node using the subject ID instead of DID, so applications administer subject ID of DID (e.g. in mapping to a tenant/customer-specific FHIR store). Thus; it needs to know which subject the token is about, instead of just the DID. Options:

Have an API that returns the subject ID for a particular DID (and all related DIDs and other useful info) Have Token Introspection provide the subject ID

we should make this an issue and discuss (label!) it.

[reinkrul]

Since we now support multiple DID methods, and not all of them might not be supported by all verifiers (e.g., they disabled did:web in favor of did:tdw), we can't pre-emptively select a DID to use in the flows (user flow (OpenID4VP), OpenID4VCI and service-to-service flow). These need to be selected based on what the server asks for:

User flow

In the user flow, DIDs are used in 2 places:

• As client_id for signing the Authorization Request (JAR). This could be determined by introducing a custom supported_did_methods property in the OAuth2 Authorization Server metadata. The wallet then needs to use a DID as client_id that is supported by the AS.
• As presenter/holder when fulfilling Presentation Definitions. This needs to be replaced with the submission builder choosing the right DID(s).

OpenID4VCI

In OpenID4VCI, a DID is used to create proof which also signals to the issuer who is the intended holder of the credential. This can also be replaced by the holder inspecting supported_did_methods.

Service to Service flow

This flow uses a DID when fulfilling a Presentation Definition. This needs to be replaced with the submission builder choosing the right DID(s).

Summarizing

We need to following features:

• supported_client_id_did_methods in OAuth2 Authorization Server metadata: https://github.com/nuts-foundation/nuts-node/pull/3319
• Presentation Submission builder that takes into account multiple DIDs.

[woutslakhorst]

all done or covered by new issues.