openid / OpenID4VP

53 stars 19 forks source link

Binding Response Code to Session #27

Open OIDF-automation opened 1 year ago

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1962

Original Reporter: fabian-hk

The Verifiable Presentation spec provides the ability to use the direct_post response mode along with a redirect uri that contains a cryptographically secure nonce (response code). As far as I can see, the spec does not explicitly mention that this response code must be bound to a browser session. I think the reference design in Section 10.5 does this, but isn't this a very important security feature that should be mentioned in Section 6.2?

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

response code ensures that only legitimate verifier front-end can fetch data from verifier backend. it does not have to be bound to the original session in the authz request.

I remember elaborating on section 10.5 in a separate issue, but can’t find which one right away…

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: fabian-hk

Are you talking about this Issue: https://bitbucket.org/openid/connect/issues/1951/direct_post-response-mode-response-with-a?

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: fabian-hk

If the response code is not bound to a session, an attacker could initiate authentication and send the authentication request to the user in a phishing attack. The user would authenticate the request and then be redirected to the browser with the redirect URL. Since the response code is not bound to the session, the user would be logged in even though she never wanted to log in. This is a violation of the session integrity security property, which requires that the user be logged in only when she wants to log in.

awoie commented 11 months ago

relates to #65 , so let's discuss in #65 since it was picked up again at IETF 118.