IdentityHub should be able to use multiple local public keys

[paullatzelsperger]

Feature Request

When verifying access tokens on incoming presentation queries, we currently rely on a locally-supplied public key (LocalPublicKeySupplier), which relies either on a vault alias, a path or a raw (PEM) string.

There are two key problems with this:

• it can only handle one public key
• when IH generates the key pair when the ParticipantContext is created, the public key is not available locally, only from the DID document

Which Areas Would Be Affected?

AccessTokenVerifierImpl

Why Is the Feature Desired?

being able to handle multiple ParticipantContexts

Solution Proposal

We must parse the kid header from the access token to resolve the public key by ID.

Option 1:

When generating ParticipantContexts, we also store the public key in the vault. Then we can use the LocalPublicKeyService (from the Connector code base), which resolves the key by ID from the vault.

Option 2:

We extend the LocalPublicKeyService so that it also able to resolve public keys from the database. That way, we don't have to store the public key in the vault.

Option 3:

We simply use the DidPublicKeyResolver to resolve "our own" public key.

Caution: simply relying on the access token's kid header is not enough, we always need the participantContextId to avoid impersonation attacks!

[thomasrutger]

This would be a nice feature in my case. Once it is confirmed that this addition will be implemented and a solution option is chosen, but it is not a priority for you at this moment, I am willing to submit a contribution.

Option 1 seems to make most sense to me at this point. Otherwise option 1 can be tried and if it fails option 3 can be used as a fallback. I am unsure about the specifics of Option 2.

[paullatzelsperger]

Thanks for offering, but we (the EDC technical committee) will need to align the approach (option 1, 2 or 3) with other ongoing developments and discussions. Once an approach is chosen the triage label is removed and implementation can start. Until such time, we ask for patience.

To me, Option 2 with a fallback to Option 3 would be best, because it avoids data duplication: DID documents are stored in the database and served from there, so we could just look in the DB for "our own" public key.

I'm not the biggest fan of keeping non-secret information in the vault, as resolving it usually involves remote calls and that may be costly.

[thomasrutger]

Because I wanted to proceed with my demonstration setup, I meanwhile implemented it in the following way so that I could continue:

• Add a LocalDatabasePublicKeyResolver that resolves a public key using the DidDocumentService
• Add this LocalDatabasePublicKeyResolver to AccessTokenVerifierImpl and pass it to tokenValidationService.validate in verify method.
• Add ParticipantContextService to AccessTokenVerifierImpl such that it can be used to find the DID using a participantId
• Add issuerMustMatchParticipantIdRule to check if the issuer equals the matched participant DID to avoid abuse.

Alternatively DidDocumentService can be used in AccessTokenVerifierImpl to find DID corresponding to participantId, but I found using ParticipantContextService to find DID directly from a ParticipantContext easier.

Alternatively interface AccessTokenVerifier can be adapted to use ParticpantContext directly instead of participantId (but probably it is not desirable to change the interface).

In addition, I also had to address these issues: #360 and #361 in order to continue.

As said, I am open to submitting a PR, but I understand if patience is required.

[paullatzelsperger]

@thomasrutger as coincidence would have it I had time to work on this today, see the linked PR (still draft). I think you got the general idea right (resolving keys from the database), although the devil may be in the details. Especially tightly coupling services may not be ideal.

Also, the verifier must check that resolved public key belongs to the sender (= participant ID) of the request.

as for those other issues, they'll have to go through triage first, and we shouldn't resolve multiple issues with one PR if it can be helped.

Naturally, to bridge the gap on your end, temporarily patching the code base is always a possibility :)

[thomasrutger]

Excellent news! Thanks.