Re: [OAUTH-WG] TAuth

[Stevie Graham <[e-mail]>]

Hi,

Coming across this thread late. I’m the Author of the TAuth post.

> What I don't understand is that he's saying people disable TLS checks so he's going to solve it with mutual TLS? 

It’s simple. Mutual TLS enables service providers to assert the peers are properly authenticated and enforce this as a policy. This won’t stop an incompetent developer disabling peer verification but it will stop that developer using the service if they do.

> The reason an OAuth 2.0 server does not authenticate _public_ clients is because, by definition, a public client cannot keep its client secret confidential and so client authentication is almost meaningless. <snip> but they don't recognize that their insistence relies on the assumption that a secret key embedded in a client application can be kept confidential.

This is incorrect. Modern mobile clients are capable of keeping a secret confidential, e.g. the Secure Enclave Processor on modern iOS devices and the Android analogues. The SEP can generate key material and use it to encrypt and sign arbitrary data. Key material is generated within the SEP and cannot be exfiltrated. To me this is the definition of being able to protect its own secrets. The TAuth bearer token analogue is not sensitive at all and cannot be used without the corresponding key material.

> Does adding TOKBIND resolve the issues?

Feel free to correct me here. I wasn’t that familiar with token binding but after reading the draft IMO it’s inferior to TAuth because it binds tokens to the connection. This necessitates refresh tokens, which I find an impediment to developer experience. TAuth binds tokens to the identity (the cert and pkey) thus can be reused again and again across TLS sessions. Token binding also provides no cryptographic guarantees that the peers are verified and that the connection is private.

Best

Stevie Graham

Teller - https://teller.io/ <https://teller.io/>

@stevegraham
@tellerapi