Initial draft of extension negotiation #12
Conversation
|
Note this would address #2 |
| } ExtensionSet; | ||
| ~~~ | ||
|
|
||
| The contents of ExtensionSet is a list of ExtensionEntry structs containing extensions (defined in #extensions), |
There was a problem hiding this comment.
I don't see Extensions struct defined as a member of ExtensionEntry struct.
There was a problem hiding this comment.
@pbsawant, would it make sense to signal the entire extension in the challenge? The extension types should be sufficient for extension negotiation.
There was a problem hiding this comment.
Agreed I don't think we need to define Extension within ExtensionEntry, as the Entries are just meant to signal which ExtensionType is is supported, along with required-ness.
| PrivateToken challenge="abc...", token-key="123...", extension-set="0x0001,0x0002..." extensions="def..." | ||
| ~~~ | ||
|
|
||
| # Extensions Negotiation {#negotiation} |
There was a problem hiding this comment.
How does client process these two new parameters? since "extension-set" and "extensions" carry ExtensionType, is there redundancy in these parameters? Can we instead just have "extensions", containing a list of Extension structs? Extension struct may carry an empty extension_data value, which indicates any or wild card extension parameter value.
There was a problem hiding this comment.
Would challenge, token-key and extension-set not suffice?
There was a problem hiding this comment.
Agreed that either of these approaches would work. @pbsawant if we just use extensions, we need a new way of signaling whether an extension is required. This is why I added the extension_set. Feel free to suggest an alternative structure if there is a clean way of including required-ness only for challenges.
This PR defines extension negotiation, as discussed at IETF 120 Privacy Pass.
We can use this as a model to work through whether we want to include negotiation functionality as an optional feature, or continue on auth-scheme without the functionality.
We received feedback during and after IETF that multiple parties have developed similar functionality along these lines, prompting the PR.