Re: [http-auth] Authentication-Info

Dear Julian,

I prefer 1) (and 2 as an alternative if 1 is not feasible).
We should not have a separate header for common functionalities
(server-to-client authentication data vehicle)
between auth. schemes as far as possible.

The header is also a definitive part of Mutual spec
(because it mandates mutual authentication on that header),
and I'd like to harmonize use of the header with other schemes.
When syntax differences between other drafts are resolved,
I'll harmonize the syntax in my drafts as well.

-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

2014-12-02 21:51 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>:
> 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.
>
> Feedback appreciated,
>
> Julian
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth