Subject: [http-auth] [Mutual] (due Aug 28) Mutual auth issues (part 1)

From: Yutaka OIWA <[email-masked]>
Date: Thu, 13 Aug 2015 02:17:22 +0000

Dear all HTTPAUTH WG members,

I'd like to have your comments on the following three issues.
Please make your initial response *before August 28*, or the
WG will consider these issues as successfully resolved
(as the WG Chair said in the Prague meeting.)

We appreciate your responses in any of the following form:
  * on the github issue tracking system (comments, pull-request etc.)
  * on this mailing list
  * on the private email
We'll summarize comments on the medium above, and send it to this
mailing list.  (Please be understood that your comments on the
private email may be included in the summary and published.)

==== draft-ietf-httpauth-mutual ====

= Section 3.1 =

[P1] Is adoption of RFC5987 OK?
https://github.com/yoiwa/httpauth-mutual/issues/1

[P2] The encoding is fixed to UTF-8, without any language.
     (justification: it is not an on-line negotiable parameter,
      and the new protocol does not need to consider older
      clients.)
https://github.com/yoiwa/httpauth-mutual/issues/2

= Section 4: Messages =

[P3] Are the reserved parameter names making sense?
https://github.com/yoiwa/httpauth-mutual/issues/3

Thank you for your cooperation.

-- 
Yutaka OIWA, Ph.D.               Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Sophie Bremer <[email-masked]>
Date: Sat, 15 Aug 2015 07:34:28 +0200

Hi Yutaka,

> https://github.com/yoiwa/httpauth-mutual/issues/1

It looks good. Even so pwd-hash*=UTF-8''ABCDEF or other token values do not make sense, the involved parties should support it in favor of future flexibility.

> https://github.com/yoiwa/httpauth-mutual/issues/2

This makes implementation at the low level easier, so I find it reasonable.

--
4.3 401-KEX-S1

  path:          (non-mandatory, string) specifies which path in the
                 URI space the same authentication is expected to be
                 applied.  The value is a space-separated list of URIs,
                 in the same format as it was specified in domain
                 parameter [RFC2617] for the Digest authentications.
--

What is the reason to use the parameter name "path" instead of "domain"?
Wiktionary says:

--
domain ‎(plural domains)

	• A geographic area owned or controlled by a single person or organization.
The king ruled his domain harshly.
	• A field or sphere of activity, influence or expertise.
Dealing with complaints isn't really my domain: get in touch with customer services.
His domain is English history.
	• A group of related items, topics, or subjects.
--

I am in favor of the name "domain" for continuity between authentication specs as you may have guessed by now. :)

> Thank you for your cooperation.

Regards,

Sophie

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Aug 2015 10:25:15 +0100

Hi,

Sent from my iPad
> On 13 Aug 2015, at 03:17, Yutaka OIWA <[email-masked]> wrote:
> 

Yes, this sounds sensible.
> https://github.com/yoiwa/httpauth-mutual/issues/2

I agree this is the right approach.

> https://github.com/yoiwa/httpauth-mutual/issues/3

This question is a bit harder to answer. Overall I think they make sense.
"auth-domain" might be named better as "auth-scope", but I don't have a strong preference, especially if you already have deployed implementation of the draft.

Best Regards,
Alexey

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