Re: [http-auth] Authentication-Info

[Michael Sweet <[e-mail]>]

Julian,

> On Dec 2, 2014, at 7:51 AM, Julian Reschke <[e-mail]> wrote:
> 
> Hi there,
> 
> this is a minor outstanding issue with the Digest and SCRAM drafts. It was discussed in both the WG sessions and in hallway conversations.
> 
> This header field originally was defined in the "Digest" part of RFC 2617, and consequently, it was copied over into <http://tools.ietf.org/html/draft-ietf-httpauth-digest-08#section-3.5>.
> 
> <http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04> currently uses it as well, but with with a slightly differing syntax.
> 
> Given the fact that we have two authentication scheme definitions that have a use case for this header field -- shouldn't we define it in a way so that it becomes a generic (optional) feature for authentications schemes?
> 
> Choices:
> 
> 1) The cleanest approach seems to move the definition into a separate spec which later can be absorbed by a future RFC7235bis. I volunteer to write that spec (it'll be very short), but this would require changes to the Digest spec post-WGLC.
> 
> 2) Alternatively, we could tune the Digest draft to introduce the header field in a more generic way, allowing other schemes to use it as well. That would avoid a dependency to a yet unwritten spec, but the complexity wouldn't really change.
> 
> 3) We can tell Alexey to pick a different field name, which would shift all required changes to the SCRAM spec.

In the interests of schedule, I would favor options 2 and 3.

In the interests of reuse/generic use, option 2 would seem to be the way to go.

If we want to minimize changes to both specs, then extending the ABNF in the digest spec to include an optional initial auth-scheme would take of things.  Alternately we can just define a standard "scheme" parameter that contains the auth-scheme value, which has the added benefit of allowing new Digest implementations to include it without breaking existing ones.

(and of course nothing prevents a 7235bis from adopting the definition in the new Digest spec, you just avoid the delay of developing a dependent spec now...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair