Subject: [http-auth] drafty http-auth wg charter

From: Sean Turner <[email-masked]>
Date: Thu, 13 Sep 2012 15:28:06 -0400

I'm glad to see there's some interest in an http-auth BOF.  With the 
deadlines fast approaching, I'd like jump start the charter discussions 
by providing a drafty wg charter.  Feel free to use this or not.

spt

--------

HTTP authentication [ref] is currently used for user authentication by 
some web sites. While form-based user authentication is currently much 
more commonly used, there is utility in providing better documentation 
for existing HTTP user authentication schemes that are in use, and for 
documenting experimental HTTP user authentication schemes that might 
offer security benefits for future uses.

The httpbis WG recently issued a call for proposals [ref] for HTTP 
authentication schemes as part of its work in further developing HTTP, 
including work on HTTP/2.0.  While a number of proposals were made, 
[ref] there is at present no consensus to adopt any of those as 
standards-track work items within the httpbis WG.

The http-auth WG will develop a set of informational or experimental 
RFCs for HTTP user authentication schemes that could, following 
experimentation, be widely adopted as standards-track schemes for HTTP 
user authentication.

All schemes to be developed in the http-auth WG must be usable with the 
existing HTTP authentication framework, [ref] or with evolutions of that 
framework as developed in the httpbis WG. That is, the evolution of the 
HTTP authentication framework is to be done in the httpbis WG and not in 
the http-auth WG.

However, the http-auth WG may document requirements for changes or 
additions to the HTTP authentication framework and any schemes developed 
in the http-auth WG that would benefit from such changes or additions to 
the HTTP authentication framework must document those changes or 
additions as an inherent part of their specifications. Any such schemes 
must however also be usable with the existing unmodified HTTP 
authentication framework.

The http-auth WG will work closely with the httpbis and tls WGs and the 
<<whatever>> WGs in W3C to ensure that the outcomes from the http-auth 
WG do not conflict with work done elsewhere.

The initial list of work items will be:

- <<the subset of the set of schemes that were proposed to
   the httpbis WG [ref] that survive the BoF>>

Adoption of additional work items will require a re-charter.

The following are out of scope:

- changes to HTTP
- changes to TLS
- definition of authentication mechanisms that do not work with
   the current HTTP authentication framework
- authentication of devices or components of web services (??)
   <<not sure about this bit, we don't want to boil any oceans,
   but maybe "just web sites" is too limiting?>>

Milestones:

- <<entirely dependent on the list of survivors>>

---

From: Harry Halpin <[email-masked]>
Date: Fri, 14 Sep 2012 17:38:50 +0200

On 09/13/2012 09:28 PM, Sean Turner wrote:
> deadlines fast approaching, I'd like jump start the charter 
> discussions by providing a drafty wg charter.  Feel free to use this 
> or not.
>
> spt
>
> --------
>
> All schemes to be developed in the http-auth WG must be usable with 
> the existing HTTP authentication framework, [ref] or with evolutions 
> of that framework as developed in the httpbis WG. That is, the 
> evolution of the HTTP authentication framework is to be done in the 
> httpbis WG and not in the http-auth WG.
>
> additions to the HTTP authentication framework and any schemes 
> developed in the http-auth WG that would benefit from such changes or 
> additions to the HTTP authentication framework must document those 
> changes or additions as an inherent part of their specifications. Any 
> such schemes must however also be usable with the existing unmodified 
> HTTP authentication framework.
>
> The http-auth WG will work closely with the httpbis and tls WGs and 
> the <<whatever>> WGs in W3C to ensure that the outcomes from the 
> http-auth WG do not conflict with work done elsewhere.

I'd add in "Web Cryptography WG" (which is doing JS Crypto API work) and 
say "and possibly other relevant WG", since depending on how this rolls 
out there may be cross-over with some open needs in other W3C WGs.

>   the current HTTP authentication framework

I think this depends on what we mean by framework. Do we mean "strong 
backwards compatibility"?

So we are limiting ourselves to username+passwords strings 
(basic-cookie) here in HTTP Basic, albeit strongly encrypted and with 
better character-set support? That seems feasible but would rule out 
some other options.

>   but maybe "just web sites" is too limiting?>>

I'd agree with components of web services, but "authenticating devices" 
may be too far. Some WGs may want to have HTTP Auth have some 
relationship  with the presence of key material to authenticate that a 
particular key exists on a particular device, as they are currently 
doing in the Web Crypto WG. I agree though it can be treacherous (and 
sketchy) territory.

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Sep 2012 11:56:32 -0500

On Thu, Sep 13, 2012 at 2:28 PM, Sean Turner <[email-masked]> wrote:
> including work on HTTP/2.0.  While a number of proposals were made, [ref]
> there is at present no consensus to adopt any of those as standards-track
> work items within the httpbis WG.

Did I miss the consensus call on this?  Or, if there was no consensus
call, how was consensus determined?  (FWIW, I do believe that call is
right, I'm just curious about the process.)

> The http-auth WG will develop a set of informational or experimental RFCs
> for HTTP user authentication schemes that could, following experimentation,
> be widely adopted as standards-track schemes for HTTP user authentication.

OK, we are going for experimental only at first.  No problem there.

> framework as developed in the httpbis WG. That is, the evolution of the HTTP
> authentication framework is to be done in the httpbis WG and not in the
> http-auth WG.

Interesting.

> However, the http-auth WG may document requirements for changes or additions
> to the HTTP authentication framework and any schemes developed in the
> http-auth WG that would benefit from such changes or additions to the HTTP
> authentication framework must document those changes or additions as an
> inherent part of their specifications. Any such schemes must however also be
> usable with the existing unmodified HTTP authentication framework.

Sounds like a recipe for very, very slow progress.  "Hi, we need this
change."  "<crickets>" "no, really, we need this change" <long debate
ensues>.  But let's be optimistic, who knows.

> <<whatever>> WGs in W3C to ensure that the outcomes from the http-auth WG do
> not conflict with work done elsewhere.
>

Ones that don't survive the BoF could still be pursued as individual
submissions, no?  After all, we're talking about publishing on the
Experimental track.  Or would the IESG be encouraged to reject
publication of any documents that did not survive the BoF?

> Adoption of additional work items will require a re-charter.

This is always implied.

> The following are out of scope:

What about:

 - new values for WWW-Authenticate header (which would adhere to the
current standard, of course)

 - new status codes?

> - changes to TLS

Certainly we don't want to touch TLS, but then, for proposals like OBC we might.

>   the current HTTP authentication framework

That can be a tough call.  Does my RESTauth proposal work within the
current framework?  It uses WWW-Authenticate properly, so I'd say
"yes", but it also is RESTful, so maybe "no".  I'm at least somewhat
concerned by this particular item in the out-of-scope list!

>   but maybe "just web sites" is too limiting?>>

Why rule this out of scope _now_?  Why not wait and see whether any
proposals in that vein are too complex or something?  Is it because of
possible impact on browser UIs?  But look, this item rules out so much
potential improvement that I would lose almost all interest as a
participant.  No, I strongly object to this item on the out-of-scope
list!

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Sep 2012 19:00:09 +0200

On 2012-09-14 18:56, Nico Williams wrote:
 > ...>> The following are out of scope:
>>
>> - changes to HTTP
>
> What about:
>

These does not require changes in HTTP. A status code registry has 
existed for eons, the registry for auth schemes is part of HTTPbis 
(http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-20.html#rfc.section.2.3).

> concerned by this particular item in the out-of-scope list!

Why would being "restful" (for some value of "restful") be a problem?

> ...

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Sep 2012 18:00:43 +0100

> right, I'm just curious about the process.)

I'd have to check the httpbis list, but Mark (httpbis wg chair)
called it out in Vancouver and I guess confirmed it on the list,
at least via minutes. As you say, he made the right call, there
was very clearly no consensus to adopt any of 'em, much as I'd
rather the outcome had been different.

S.

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Sep 2012 13:06:20 -0500

> Why would being "restful" (for some value of "restful") be a problem?

Because then it's not really an "HTTP authentication scheme" because
technically speaking it's using HTTP properly as a transport, so it's
"above" HTTP as far as on-the-wire layers go.  None of the existing
HTTP authentication schemes have this property.  (But then, also, none
handle multi-legged authentication, and multi-legged authentication
exchanges in the traditional DIGEST and Basic approach would be
somewhat strange.)

Nico
--