Confidentiality of Self-Issued OP response

[Christina Bauer]

For Self-Issued OpenID Providers as native applications, the response to the RP is not passed to the browser in a redirect, but by OS specific means. As of now, the Self-Issued OP Specification does not specify the properties required for this step.

In particular, we have a problem if an attacker can register an application they control as a handler for the RP redirect_uri on the End-Users device. Then the attacker might obtain a 'fresh' valid ID token with the RP in the audience for an identity of the End-User.

For a more detailed description, please see the writeup in the attached pdf.

[Daniel Fett]

PR: https://bitbucket.org/openid/connect/pull-requests/119

[Kristina Yasuda]

Merged in siop-v2-response-confidentiality (pull request #119)

fixes #1425 - adds security consideration for confidentiality response (same-device)

Approved-by: Torsten Lodderstedt Approved-by: Daniel Fett Approved-by: Kristina Yasuda

→ <<cset 290f3296991e>>

[Kristina Yasuda]

I am not sure why merging the PR automatically closed this issue (maybe because it was in the title)

Reopening this, since during SIOP call I understood that there are more PRs expected to reflect findings in the attached pdf.

[Kristina Yasuda]

does this attack require the attacker having its own browser app? why identifying “a good browser“ is relevant?

[Christina Bauer]

It requires to have any app controlled by the attacker on the users device that can claim to handle the redirect_uri of a good SIOP (e.g. with a deep-link without the verification of the App Link in Android).

[Mark Haine]

Migrated to GitHub

https://github.com/openid/SIOPv2