OpenID4VP
OpenID4VP copied to clipboard
OID4VP profile for the W3C Digital Credentials API
resolves #125
Having discussed and thought about this more, I don't think this proposal achieves the desired security properties namely allowing the wallet to authenticate the verifier before sending the response, please see here for more details, I've copied the same diagram below that I think captures the issue.
On that basis I think we should consider revising the design somewhat to a simpler model which relies on authenticating the verifiers response encryption key as an additional layer of security above the existing mechanism the browser will provide which is to attest the origin of the verifier that sent the request.
... On that basis I think we should consider revising the design somewhat to a simpler model which relies on authenticating the verifiers response encryption key as an additional layer of security above the existing mechanism the browser will provide which is to attest the origin of the verifier that sent the request.
We had an extensive discussion on this issue at IIW and concluded to use signed requests in combination with expected_origins added to the signed object by the Verifier. The Wallet needs to ensure the Browser-asserted origin is in the expected_origins to detect replay attempts.
one outstanding comment whether expected_origins is mandatory or not, but otherwise should reflect current consensus and be good to go.
"origin" should have a normative references to the HTML spec. I'm not familiar with the template engine being used, so I'm not sure how to add it.
Here is what you want to reference: https://html.spec.whatwg.org/multipage/browsers.html#concept-origin
@tlodderstedt, when you can, would you mind merging in the agreed to the suggestions? (just so it's a bit easier to review 😅). I'd like to do another round of review once those are merged. Thanks in advance!! 🙏
@marcoscaceres I am helping torsten with this PR. all the suggestions have been merged, please re-review
We also confirmed on today's working group call that Martijn is good with merging this PR as we have (or are about to) open issues to focus on his concerns and we'll discuss those (and some of the other open issues on the browser API) before we start the process for publishing the next implementer's draft.