Potential Conflict with jti Claim in JWT-Serialized Verifiable Credentials

[thomasrutger]

I have encountered a situation where a JWT-serialized Verifiable Credential (VC) is issued from an Identity Hub, and the jti claim is set. This can be seen in the following line from the JwtCredentialGenerator:

IdentityHub/core/issuerservice/issuerservice-issuance/src/main/java/org/eclipse/edc/issuerservice/issuance/generator/JwtCredentialGenerator.java

Line 138 in 393930e

.claims(JwtRegisteredClaimNames.JWT_ID, UUID.randomUUID().toString())

However, when the credential is presented more than once to a control plane instance with the setting edc.iam.accesstoken.jti.validation=true (which is the default), it is rejected due to the jti having already been used. This behavior appears to treat the credential as a one-time-use token.

According to the VC-JOSE-COSE spec:

“Implementers SHOULD avoid setting JWT claims to values that conflict with the values of verifiable credential properties when a claim and property pair refer to the same conceptual entity, especially with pairs such as iss and issuer, jti and id, and sub and credentialSubject.id. For example, JWK claim iss SHOULD NOT be set to a value which conflicts with the value of verifiable credential property issuer.”

Given this, it seems that setting the jti claim for a long-lived vc+jwt credential may not be appropriate, particularly if the system interprets jti as a nonce-like value used for replay protection.

My assumption is that this is unintended behavior, and that the jti claim should probably not be set on Verifiable Credentials in JWT format, or alternatively, the control plane should not enforce jti uniqueness validation for vc+jwt credentials.

Either that, or this is intended behavior and I am misinterpreting this. Could someone clarify this? Thanks!