Re: [http-auth] Authentication-Info

[Julian Reschke <[e-mail]>]

On 2014-12-02 15:06, Michael Sweet wrote:
> 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.

I believe we can get done 1) quickly enough.

> 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.

Changing the syntax sounds like a breaking change to Digest to me.

Adding a scheme *parameter* would work, but I wonder why that is needed 
anyway. Alexey?

> (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
>


Best regards, Julian