the problem with this is you're rewriting client ssl, which isn't a very good idea considering how battle tested and hardened it is. how do you know you've dea

the problem with this is you're rewriting client ssl, which isn't a very good idea considering how battle tested and hardened it is. how do you know you've dealt with all the edge cases that tls spec writers have been wringing their hands over for like forever. why do a one off impl of client auth inside the oauth protocol? why not use extremely well baked pre-existing infrastructure like webcrypto? it's not like you're magically going to be compatible with everything just because you follow the overly vague guidelines of oauth2. all you get kudos for is reading the spec - but how does that help your users? security is a very hard problem, especially asymetric crypto security. rolling your own is generally not advised. If there is a way to define and use client tls according to the current spec, that would be best. if not, I agree that it's probably a good idea to create a new spec I agree though that the curlness of the spec is orthogonal to the discussion.