FAPI part 2 - public clients and mTLS

[Torsten Lodderstedt]

§5.2.3,#1 only mentions OATB as holder of key mechanism

mTLS supports certificate-bound access tokens for public client and should therefore be mentioned as well

[Joseph Heenan]

@tlodderstedt I may be missing something, but is OATB not significantly more secure for public clients than certificate-bound access tokens?

ie. the value of binding an access token to a TLS client certificate is very low if the private key for that TLS client certificate is essentially publicly available.

[Torsten Lodderstedt]

@josephheenan mTLS is not used for authentication with public clients (public clients -> no credentials with AS), but mTLS allows the public client to perform TLS client authentication with any TLS key and binds the access token issued to this key.

A public client can generate a key pair and self-signed cert for any instance and use that to prevent token leakage via cert-binding. So effectively, it works quite similar to OATB with the only difference that the client must manage the TLS cert itself.

[Nat Sakimura]

I would argue that is not a public client anymore :-) Some mobile apps etc. are public clients, but some are not. For example, if the mobile app performs dyn reg, or generates its own certs, the key will not be found by the honest party's key will not be shared with the installation on the attacker's machine and thus deemed not public -- i.e., a confidential client.

[Dave Tonge]

I agree with Nat - we talked about adding a note about this fact that public clients != mobile client

[Torsten Lodderstedt]

I agree. The text needs to be precise what kind of clients is meant.

Does OB UK support true public clients (no secret at all)? Does OB UK support mobile clients and how are they handled from a credential/trust mgmt perspective?

[Dave Tonge]

OB UK doesn't support any mobile clients (public or confidential)

It supports the use of mobile apps as the user agent though, i.e. TPPs mobile app intercepts the redirect uri using a claimed HTTPs scheme and passes the auth code / id token to its backend.

FAPI was drafted to also support banks / financial institutions using it for their own mobile apps - this is the primary reason why the public client stuff is there.

[Torsten Lodderstedt]

ok. thanks.

My comment is related to public clients in the original RFC 6749 sense. mTLS allows them to get issued certificate-bound access tokens in the same way OATB can be used for that purpose. The fingerprint of the client certificate from the TLS handshake (which is not used to authenticate the client), can be added to the access token. Subsequent interactions with resource servers require the client to demonstrate possession of the respective private key.

[Joseph Heenan]

I think that there's a general issue with public or pure native mobile apps (even if confidential clients) in the PSD2 area; it seems to me fundamentally incompatible with the requirement that APIs can only be used by regulated/authorised participants. (ie. if the TPP has to embed their eidas cert into the mobile app, there's no plausible way to stop other people extracting the cert from the app and impersonating that TPP against the APIs). Although, as Barclays have shown Stevie Graham, with white box crypto etc you can make it damn hard.

That aside; I see what Torsten is saying (thank you for the explanation Torsten). A true public client that generates it's own per-instance TLS client certificate which is only used for binding the access token does have some value if there are reasons why dynamic client registration cannot be used.

[Torsten Lodderstedt]

please review the pull request

[Nat Sakimura]

Just to make sure. Is this the pull request 64?

[Torsten Lodderstedt]

yes, pull request #64

[Nat Sakimura]

Fixed #157. Merged in 157-public-clients-and-mTLS (pull request #64)

added mTLS as option to clause 1 in §5.2.3 + note on its use

→ <<cset 04f8466db08b>>