[has-PR] `nonce` validation with nested verifiable presentations
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.
Comments (12)
-
-
reporter @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.
-
What verifiable presentation format would support such an embedding?
-
I think direction in
#1577is to allow additional mechanism to nonce, such asjti
. 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) -
reporter 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
-
good point. I can add a section saying embedding VP in a VP is not supported in a current version of OpenID4VP.
-
please review PR #277
-
- changed title to [has-PR] `nonce` validation with nested verifiable presentations
-
reporter As someone who is trying to implement the specs to identify possible problems, the
nested_paths
entries create problems beyond just dealing withnonce
s (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
-
+1 for not supporting it. I have never seen such a construct in practice.
-
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.
-
- changed status to resolved
PR #277 merged
- Log in to comment
what’s the usecase for nesting one VP inside another VP?