Hannes Tschofenig <[email protected]>: To my surprise I had to notice that the authors have re-created a number > of mechanisms we created in OAuth. > > I am wondering whether the authors are aware of this or whether this > re-design (with just minor variations) is intentional. > > In either case it isn't great and I encourage the authors to take a look > at already ongoing efforts.
Token Binding has different objectives and is located at a different level (*between* TLS and HTTP authorization). Still it's reasonable to see if mechanisms could be reused. (While draft-ietf-oauth-pop-architecture-00 does mention TLS channel binding support as one of the use cases for OAuth proof-of-possession, I haven't been able to locate a specific mechanism supporting that goal. Quite possibly I just didn't look at the right place -- can you help?) The Token Binding protocol (draft-popov-token-binding-00) inherently depends on TSL but not on HTTP, so it's natural for it to be based on TLS-style data structures (not JSON Web Tokens as in draft-ietf-oauth-proof-of-possession-00). What else is there that you think should be considered to avoid duplication? I do have some complaints about draft-popov-token-binding-00 and draft-balfanz-https-token-binding-00, though, and possibly they just aren't as clear as they should, thus making it harder to figure out these things: - draft-popov-token-binding-00 IANA Considerations register ALPN protocol IDs such as "http/1.1_tb_p256", with "Specification: this document". In reality, it appears that draft-balfanz-https-token-binding-00 specifies these protocols (and should be requesting IANA registration), based on draft-popov-token-binding-00. The relationship between the documents appears convoluted: draft-balfanz-https-token-binding-00 shouldn't have to be a normative reference in draft-popov-token-binding-00. - draft-popov-token-binding-00 uses "application protocol messages" but doesn't say what these are. (I think this refers to TLS application data, but TLS application data is not structured into messages. Presumably the idea is that the TLS-style token binding protocol message be prepended to the TLS application data stream, but the specification needs to be more explicit about that, and probably should show a concrete example.) - draft-popov-token-binding-00 nominally specifies "The Token Binding Protocol Version 1.0", but there's no indication of that version number in the ALPN protocol registrations -- neither in the IDs (such as "http/1.1_tb_p256") nor in the descriptions (such as "HTTP/1.1 with Token Binding using ECDSA key and NIST P256 curve"). - draft-popov-token-binding-00 and draft-balfanz-https-token-binding-00 both include normative language saying that TLS extended master secrets are required. This doesn't make sense. This should be normative only in draft-popov-token-binding-00. (Also, it doesn't seem right to specifically require the Extended Master Secret TLS *extension* as the documents do. If a new version of TLS fixes the master secret computation without requiring an extension for this, this unncessarily precludes using Token Binding with that TLS version.) - draft-popov-token-binding-00 should be clearer about what of it is a framework that still needs to be instantiated and what of it is the actual protocol. The actual "tokens" supposed to be bound feature in the introduction and in the overview only: I haven't found guidance that says explicitly that higher layers will have to do certain steps (with illustrative examples?). In short, if I didn't already have an idea of what these specifications are all about, I'm not sure I could figure it out just from reading them. So I'd suggest we first get these specifications cleared up significantly before for start to look at the protocol mechanisms in detail. Bodo
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
