PresentationQuery Accesstoken verification problem

[ThomasRutger]

I have a local setup with a consumer and a provider running, both have a connector instance and a IH instance (much like the mvd iatp). The IHs are equipped with a SecureTokenService API and the connectors use the RemoteSecureTokenService to obtain an SI token from the IH.

While sending a CatalogRequestMessage from consumer to provider I ran into a problem with the PresentationQuery flow.

The consumer sends an SI token with an embedded access token that can used to request VP's for the given scope from the consumer. Both the SI token and the embedded access token are signed by the same private key, which belongs to the specific StsClient. The provider then creates its own SI, embeds the access token and sends a request to /presentations/query on the consumer. The IH of the consumer then tries to verify both the SI from the provider as well as the access token. However, it fails to verify the access token as it seems to be verified using a different public key, pre configured using the config value from edc.ih.iam.publickey.path, which I pre configured using a dummy value as I wasn´t sure of its purpose.

Specifically: https://github.com/eclipse-edc/IdentityHub/blob/25e233f726b5fc6091ddedaeeb0b5ccbbc5b2a20/core/lib/accesstoken-lib/src/main/java/org/eclipse/edc/identityhub/accesstoken/verification/AccessTokenVerifierImpl.java#L95. Here it tries to resolve a public key using the public key id, but the id it seems is ignored. Instead, it uses the LocalPublicKeySupplier: https://github.com/eclipse-edc/IdentityHub/blob/main/core/identity-hub-core/src/main/java/org/eclipse/edc/identityhub/core/LocalPublicKeySupplier.java. That tries to obtain a predefined public key.

What am I doing wrong? How can I make sure it verifies the AccessToken based on the private key belonging to the actual StsClient?

[paullatzelsperger]

when the consumer's IH tries to verify the SI token, that the provider created, and that contains the access token, the following applies:

• the access token originates from the consumer's STS and is thus signed with the consumer's private key. So when the presentation query is received, the consumer's IH must verify the access token with "its own" key.
• the consumer should not resolve its own public key using a DID resolver, it can resolve it "locally", hence the LocalPublicKeySupplier.
• as you said, the SI token, in which the access token is embedded, originates from the provider, and is thus signed with the provider's private key. Consequently, the consumer IH must verify the provider's SI token with the provider's public key
• to do that, the provider's SI token carries a reference to the provider public key in the kid header
• the consumer's IH resolves the provider's public key from the DID document using that kid header

Generally, to gain a better insight, I highly recommend familiarizing yourself in depth with the IATP specification, in particular the Presentation Flow (issuance is not yet implemented in IH).

In addition, I advise against using dummy values, as all our config values must be used with intent.

[ThomasRutger]

Thanks for your answer, really appreciated. Not sure it fully addresses my situation:

I am creating dynamically StsClients on startup in the IH, based on one or more ParticipantContext that are created at startup based on a config. The StsClient uses the keypair material that is generated automatically for the ParticipantContext using KeyDescriptor.keyGeneratorParams. Since this is done after startup it seems there is no way of knowing in advance what this key is. I could theoretically store the key under a predefined alias that I configure beforehand and then use edc.ih.iam.publickey.alias property, but then what happens if the IH has more than 1 Participant? Then it seems that they must all use the same keypair?

Could you please provide guidance on how to handle this, or suggest an alternative approach if I've misunderstood something?

Thanks!

[jimmarino]

As @paullatzelsperger mentioned, please first read the IATP specification which contains important information needed to properly understand Identity Hub and specifically how keys are handled.

[paullatzelsperger]

I think i mentioned in a previous encounter that IH is NOT a finalized project/product, and it is not ready for production use. As such, it lacks documentation, and we can't provide 1:1 guidance and help.

I do see your point thought, although I cannot make any assertions as to if and when we will tackle the issue. For now, just use pre-generated keys and 1 tenant per IH, just like the setup you initially described.

[edit]: created eclipse-edc/IdentityHub#356 to track this.

[ThomasRutger]

Thanks. I recognize it is not a finalized product. My main intent was to ensure there wasn't a misconfiguration on my end. Thanks again for considering this issue.

[paullatzelsperger]

i understand, and frankly its a delicate balance to strike: on one hand we can't provide guidance, simply for dev bandwidth reasons, on the other hand we do appreciate bug reports and feedback.