FAPI2S 4.5 Differences to FAPI 1.0

[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

‌

[Daniel Fett]

• JAR and JARM do not directly match PAR in terms of functionality, but the “only code in response” matches to JARM. Probably should be split into two lines.
• re state: Yes, PKCE (if enforced, like we do in FAPI 2) replaces state in its functionality for integrity protection
• pre-registration is not required with client authentication and PAR “because redirect URIs can be sent authenticated and integrity protected from the client to the AS in the PAR request”
• re response types: indeed mostly privacy. One could argue that the security is slightly better, as a nonce/signature check can be omitted by the client, whereas a PKCE check cannot
• re ID token as detached sig: I don’t think this is a duplicate. I see the function of the ID token as detached signature as distinct from its original function to transport the ID to the client/RP.
• re nbf & exp: Agreed, that is a relatively weak point.

‌

[Daniel Fett]

See https://bitbucket.org/openid/fapi/pull-requests/361/improve-comparison-table

[Dave Tonge]

PR merged