[has-PR] `nonce` validation with nested verifiable presentations

[Thomas Bellebaum]

From the Section on “Preventing Replay Attacks”:

To prevent replay attacks, verifiable presentation container objects MUST be linked to client_id and nonce from the Authentication Request. The client_id is used to detect presentation of credentials to a different party other than the intended. The nonce value binds the presentation to a certain authentication transaction and allows the verifier to detect injection of a presentation in the OpenID Connect flow, which is especially important in flows where the presentation is passed through the front-channel.

Note: These values MAY be represented in different ways in a verifiable presentation (directly as claims or indirectly be incorporation in proof calculation) according to the selected proof format denoted by the format claim in the verifiable presentation container.

Assume a RP is returned a Verifiable Credential inside a Verifiable Presentation Container inside another Verifiable Presentation Container. (Yes, this is valid according to DIF.PresentationExchange, see also https://github.com/decentralized-identity/presentation-exchange/issues/355).

Should we specify which VP should be signed by the holder and which should involve the nonce? There seems to be no mention of a nonce in Presentation Exchange other than

Other protocols may require that a presentation be bound to a particular communication exchange or session. In these cases, a Presentation Request that provides a domain, challenge, or nonce value may be required.

In particular, it does not specify how to validate that a nonce was used.

[Kristina Yasuda]

what’s the usecase for nesting one VP inside another VP?

[Thomas Bellebaum]

@Kristina good question. I do not have an answer to that. I just noticed that with the current specifications, that is something which might be returned from the OP, and was looking for the right way to handle this case.

[Torsten Lodderstedt]

What verifiable presentation format would support such an embedding?

[Kristina Yasuda]

I think direction in #1577 is to allow additional mechanism to nonce, such as jti. in which case, that might solve this hypothetical problem. (just because PE allows for embedding VP with a VC in a VP, does not mean it is a valid use-case)

[Thomas Bellebaum]

Sure, but a conformant RP will still need a way to correctly handle the input sent by the OP. If the RP is expected to reject any submission in an unexpected format, then this should probably be noted somewhere in the Security Considerations section. I can see a number of bugs being implemented by naively following the current set of specs

[Kristina Yasuda]

good point. I can add a section saying embedding VP in a VP is not supported in a current version of OpenID4VP.

[Kristina Yasuda]

please review PR #277

[Thomas Bellebaum]

As someone who is trying to implement the specs to identify possible problems, the nested_paths entries create problems beyond just dealing with nonces (Think about nested credentials, or new formats which do not fall cleanly into either the VC or VP categories). This makes writing a general purpose and extensible validation procedure nearly impossible in my experience. The PresentationExchange community seems to recognize the issues but needs time to fully comprehend the implications of nested paths.

So I think the ultimate strategy might be to bring any issues to PE and fix them there. But since that might take some time, reacting to any problems here may also be an option

[Oliver Terbu]

+1 for not supporting it. I have never seen such a construct in practice.

[Kristina Yasuda]

at least one nested_paths would be needed to express a JWT-VC included in a JWT-VP. we just should not allow multiple nested_paths.

We are not asking for a new feature from a PE spec, we are limiting it’s functionalities, so I think it is ok to only add a text in 4VP spec, but of course you are free to open an issue in a PE repository, too.

[Kristina Yasuda]

PR #277 merged