Given that the nonce is part of the encrypted payload, it already contributes to the cryptographic output. Therefore also using it as the "apu" value is redundant.

Likewise, the Client ID is part of the encrypted content, and so need not also be in "apv".

Arguably none of this is needed or useful but this is my attempt to carry out the will of the WG in a compromise that isn't a complete departure from the specification stack this all builds on and hopefully put an end to months of confusing and confused but very heated discussion on the topic.

@selfissued

Given that the nonce is part of the encrypted payload, it already contributes to the cryptographic output. Therefore also using it as the "apu" value is redundant.

Likewise, the Client ID is part of the encrypted content, and so need not also be in "apv".

the purpose of using nonce/client_id as apu/apv values is to ensure interoperability so that the verifier can decrypt, and NOT audience restriction or session binding

Approving this change since it implements what was agreed in the DCP WG call. I want to note that this will not work with the Multi RP PR #308 since the response might be encrypted to different client IDs. After the Multi RP RP got merged, this text will need to be revised accordingly.

Noted. Though I'm not sure what one response encrypted to different client IDs would look like...

Discussion in the WG call on the 14th of Jan 2025:

• With the latest change in Add Multi RP Credentials/Authentication capability #308, we can no longer assume the encryption key to be related to a certain Client Identifier. We might change this into the origin. @paulbastian raised the question how the RP would determine the correct origin if the request contains multiple expected_origins.
• @mike pointed out use of apv/apu would preclude algorithms that do not have those features.

I think I agree with Mike, that defining new top-level parameters beside the JWE may be more future-proof than using apu and apv, as long as those things are not directly involved in the decryption itself

I think I agree with Mike, that defining new top-level parameters beside the JWE may be more future-proof than using apu and apv, as long as those things are not directly involved in the decryption itself

Tend to agree as well since all protected headers are part of the AAD which would include these newly defined headers. This would also meet the ISO requirement:

Response encryption authentication must be bound to the origin, e.g. RP URL.

so am I getting it right that the proposed solution is to add origin to the protected header?
since the requirement is Response encryption authentication must be bound to the origin, e.g. RP URL. I assume there is no need to add any other information to the protected header?

Does it also mean that we do not use apu and apv values? if we do not define them, there will be no way for both parties to be able to use the same values.

the purpose of using nonce/client_id as apu/apv values is to ensure interoperability so that the verifier can decrypt, and NOT audience restriction or session binding

that was not my understanding but perhaps my not understanding is part of the problem

Discussion in the WG call on the 14th of Jan 2025:

* With the latest change in [Add Multi RP Credentials/Authentication capability #308](https://github.com/openid/OpenID4VP/pull/308), we can no longer assume the encryption key to be related to a certain Client Identifier. We might change this into the origin. @paulbastian raised the question how the RP would determine the correct origin if the request contains multiple `expected_origins`.

The rational for multiple expected_origins was questioned from it's introduction but it was explained that at IIW it was determined as needed because the backend infrastructure thing that signs these requests might not know the exact origin the whole page or whatever the script invoking the API is being served on. Which I can kinda see. But it'll have to know the set of possible origins in order to make the expected_origins list. I think an RP/Verifer would just need to ensure that the origin in the JWE header is one of those that it expects.

* @mike pointed out use of apv/apu would preclude algorithms that do not have those features.

I don't understand what that means exactly but what it seems to say on the face of things isn't correct.

I think I agree with Mike, that defining new top-level parameters beside the JWE may be more future-proof than using apu and apv, as long as those things are not directly involved in the decryption itself

I apologize for missing the call where this all was discussed and for my not being able to understand much of this but I don't understand how or why defining new top-level parameters beside the JWE would contribute anything to anything.

I think I agree with Mike, that defining new top-level parameters beside the JWE may be more future-proof than using apu and apv, as long as those things are not directly involved in the decryption itself

Tend to agree as well since all protected headers are part of the AAD which would include these newly defined headers. This would also meet the ISO requirement:

Response encryption authentication must be bound to the origin, e.g. RP URL.

"protected headers" are different than "top-level parameters beside the JWE" and maybe I'm being too literal but it's a meaningful distinction. Also apu and apv are protected headers. All headers are in the compact serialization (but please please don't take that as any kind of support for the JSON serialization). So yeah, the AAD would include these newly defined headers but it also includes the apu and apv headers (which also contribute to the KDF in ECDH). The text in the PR even tries to say this. So I am indeed sorry but I am pretty confused about what was discussed yesterday and what the concerns are and what to do with any of it.

so am I getting it right that the proposed solution is to add origin to the protected header? since the requirement is Response encryption authentication must be bound to the origin, e.g. RP URL. I assume there is no need to add any other information to the protected header?

Is this where the WG wants to take this? Asking 'cause I honestly don't know.

Does it also mean that we do not use apu and apv values? if we do not define them, there will be no way for both parties to be able to use the same values.

We don't define them now, they don't need to be used and default behavior when they aren't there is specified. So I'm not sure why it would be a problem. But I've very likely misunderstood something.

since this is about origin, this has to be defined only for browser API.

we discussed two options:
option 1: set apv or apu as origin value.
option 2: define a new protected header origin. do not define apv/apu values?
-> Brian thinks this might be less of an evil. should work with some of the JWE libraries Brian is intimately aware of.
-> this might help to future proof for the algorithms that do not use apu/apv ie HPKE. but will prevent the goal of detached AAD because protected header is not detached?

apv and apu are protected to the same extent as other protected headers are protected.

the goal: fail early if the wrong origin was used? what does "Response encryption authentication must be bound to the origin, e.g. RP URL." mean..?

current situation: if the purpose of the requirement is replay prevention, there is already audience restriction via origin and client_id and nonce being present in the session transcript. if this is for HPKE and potentially detached ECDH-ES then DCP WG will tackle it later.