[Openid-specs-fapi] Issue #507: FAPI2S 4.5 Differences to FAPI 1.0 (openid/fapi)

[Nat]

New issue 507: FAPI2S 4.5 Differences to FAPI 1.0
https://bitbucket.org/openid/fapi/issues/507/fapi2s-45-differences-to-fapi-10

Nat Sakimura:

My comments are in _**bold italics.**_ Some of them might be better suited for Security and Privacy considerations. 

| FAPI 1.0 Read/Write | FAPI 2.0 | Reasons |
| --- | --- | --- |
| JAR, JARM _**JARM is not really relevant here, or is it?**_  | PAR | integrity protection and compatibility improvements for authorization requests; only code in response |
| _**BCM principles**_  | shall adhere to Security BCP |  |
| `s_hash` | - | state integrity is protected by PAR; protection provided by state is now provided by PKCE _**Is this claim really valid?**_  |
| pre-registered redirect URIs | redirect URIs in PAR | pre-registration is not required with client authentication and PAR _**because … \(reasons are important\)**_ |
| response types `code id_token` or `code` | response type `code` | improve security: no ID token in front-channel; not needed _**I am not sure the claim “improve security” is real. It does reduce privacy concerns, while potentially reducing security level a bit \(as we are not using JARM\). Need to explain why it is justified.**_  |
| ID Token as detached signature | - | ID token does not need to serve as a detached signature _**Is it not the duplicate of the row above?**_  |
| potentially encrypted ID Tokens _**in the front channel**_ | encryption not required | ID Tokens only exchanged in back channel |
| `nbf` & `exp` claims in request object | request\_uri has lifetime under 300 seconds | Prevents pre-generation of requests. _**This has a pros and cons. Pre-generation could be useful in some use-cases, such as in the client that is unable to keep signing key secret enough online.**_  |
| `x-fapi-*` headers | - | Removed pending further discussion |
| MTLS for sender-constrained access tokens | MTLS or DPoP |  |

‌