aud Claim Value in JWT Proof Sent to Credential Endpoint

[peppelinux]

This issue proposes defining a requirement for setting the value of the aud (audience) claim within the JWT proof sent to the credential endpoint. The proposal suggests that the aud claim should be set to the HTTP URL of the endpoint, rather than the entity ID of the credential issuer.

Rationale

The aud (audience) claim in JWT is intended to ensure that a JWT is intended for a specific recipient (or audience). Setting the aud claim to the HTTP URL of the credential endpoint, rather than the entity ID of the credential issuer, has several advantages:

1. Endpoint Specificity: Using the HTTP URL as the aud value ties the JWT proof directly to the specific endpoint that should accept it. This provides a clear and direct linkage between the JWT and its intended destination, enhancing security by preventing the JWT from being accepted by unintended endpoints and for different scopes.

2. Consistency with OAuth 2.0: In OAuth 2.0, the aud claim is often set to the URL of the resource server or the authorization server's token endpoint. Aligning the practice for credential issuance with OAuth 2.0 conventions can promote consistency across implementations and make the behavior more predictable for developers.

3. Flexibility for Credential Issuers: Credential issuers may host multiple endpoints for different purposes (e.g., issuing different types of credentials). Specifying the endpoint URL in the aud claim allows for finer-grained control and routing of JWT proofs to the appropriate processing logic.

4. Simplification of Validation Logic: By specifying the exact endpoint URL in the aud claim, the validation logic at the credential endpoint can be simplified. The endpoint can easily verify that it is the intended audience for the JWT without needing to map entity IDs to specific endpoint URLs.

Proposal

It is proposed that the specification or guidelines for sending JWT proofs to the credential endpoint include a requirement to set the aud claim to the HTTP URL of the endpoint. This approach should be documented as a best practice, with explanations provided for the rationale and benefits as outlined above.

Pull Request

This issue aims be resolved by the following PR: https://github.com/openid/OpenID4VCI/pull/188

[jogu]

On point 2: The OAuth WG seems to have standardised on the issuer value to be used for aud in client authentication assertion JWT (but also requires other values to be accepted); see this text from https://www.rfc-editor.org/rfc/rfc9126.html#section-2 :

To address that ambiguity, the issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

[paulbastian]

I don't think there is much benefit, as the credential endpoint is directly connected to the credential issuer base URL in the issuer metadata, but I see the point.

Reading this I was wondering if there would be an improvement if the proof reflects the requested credential, as the same credential endpoint could issue multiple credentials. A candidate could be the credential_configuration_id or even a credential_instance_id?

[Sakurann]

Reading this I was wondering if there would be an improvement if the proof reflects the requested credential, as the same credential endpoint could issue multiple credentials. A candidate could be the credential_configuration_id or even a credential_instance_id?

what would that improve..?