http-extensions
http-extensions copied to clipboard
httpwg
Add SF-based Authorization and WWW-Authenticate headers
This seems like another good candidate for a structured format. Maybe something we can add to the retrofitted structured headers draft as a new set of mapped fields?
This is attractive, but it would require each auth scheme that wanted to use the new mapped fields to define how to convert the "normal HTTP" form into structured fields.
I suppose we could say that a scheme MUST NOT be used in the mapped field unless it defined such a conversion, and we could do the common ones to start (likely: Basic, Digest, Bearer).
That's not a small amount of work, and I half wonder whether it should be in a separate spec.
Thoughts?
I don't have a strong opinion about where the work should be done, but it doesn't seem like a whole lot of work (saying that without having actually tried to make the change). In any case, this seems like a reasonable path forward to me. If no one volunteers to do it, I can give it a shot in the new year.
I believe the mapping is straight-forward.
WWW-A would be a list of parametrized tokens. The token would take the scheme name, and its parameters would be the auth-params.
There's only the special case of Basic auth, where we don't have auth-params but a single token68 value. Mapping that to a specific param name shouldn't be big issue.
If people want this, I can give it a try.
@reschke please do, but realise that you'll need to map each parameter name to a type -- possible with a converstion -- for each scheme.
That's of course impossible as it is open-ended. Why would that be required?
The proposal isn’t to create a compatible field, it’s to create a mapped one. That requires definition of a mapping.
Yes, but I don't see why we need to define the types.
If auth scheme "foo1" has a parameter "bar" that is integer-typed, and auth scheme "foo2" has a parameter "bar" that is string-typed, why is that a problem?
What we can say is that - as auth params are either token or quoted-string, so will be the SF params (sf-token or sf-string).
What do you mean by "those types"? The types of auth-params for a specific scheme?
We can either let the scheme define them, or just say "sf-token or sf-string", mapping what the current syntax allows.
Yes, but that's not realising the value of using SF. Ideally we'd define the mappings for most existing schemes, falling back to that for unrecognised schemes.
Julian, were you going to attempt a PR?
Julian, were you going to attempt a PR?
Depends on what you're looking for. I can write down a generic mapping for all schemes that use the generic syntax properly. I don't believe doing more would be useful.
I'd love to see us define the fields for some schemes as a template, and explain to new auth schemes how they could define themselves using structured fields. So, don't claim to be complete, but point out how new documents can refer to structured fields without having them being outside the context of structured types.
Here's an example of where we are writing new auth schemes and have to have somewhat involved text about when you have quotes, etc: https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-09.html#section-2.1-8