Audience value in ues cases with an intermediary

Type

Technical

Summary

In case an intermediary requests data from the wallet (e.g. an EAA), which audience value should appear in the resulting SD-JWT and KB-JWT?

Version and Section

Version: current

Section: (Q)EAA Presentation with OpenID4VC Step 14 of the same-device workflow: The Wallet generates a KB-JWT by signing over nonce and audience with device_priv

Feedback / Questions

In case a relying party employs an intermediary to request data from the wallet (e.g. an EAA) the intermediary is to be considered as a relying party according to the ARF, section 3.11. As a relying party it has to do the necessary verifications on the received credentials. Which audience value should such an intermediary expect in the received SD-JWTs from a wallet and a corresponding kb-jwt? From the wallets perspective and according to the ARF the intermediary is the relying party requesting the data. So, the audience value should be the client_idenfitier of the intermediary. But the final recipient of the data from the SD-JWT and depending on implementation even the SD-JWT itself is the original relying party, which requested data via the intermediary. If this original relying party receives a SD-JWT with the intermediary listed as audience, how can this relying party proof that this SD-JWT was indeed ment for it? Some relying parties might want to store the original SD-JWT and accompanying KB-JWTs as a form of proof, that they interacted with the user and got permission to perform some operation for him. This is only possible, if they are also listed in the audience claim.

Suggestion: From our point of view the audience claim should in this case be an array containing clear identification data for both the intermediary and the actual relying party. These identifiers should be taken from the access certificate for the intermediary and from the registration certificate for the relying party.