W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2016

[webauthn] hostname canonicalization in {#makeCredential} section?

From: =JeffH via GitHub <sysbot+gh@w3.org>
Date: Tue, 16 Aug 2016 22:20:46 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-171531941-1471386044-sysbot+gh@w3.org>
equalsJeffH has just created a new issue for 

== hostname canonicalization in {#makeCredential} section? ==
webauthn says (in 
3. Set |callerOrigin| to the origin of the caller. Derive 
the RP ID from |callerOrigin| by computing the "public suffix + 1" or 
(which is also referred to as the "Effective Top-Level Domain plus 
One" or 
"eTLD+1") part of |callerOrigin| [[PSL]]. Let |rpId| be the lowercase 
form of this RP ID. Set |rpIdHash| to the SHA-256 hash of the UTF-8 
of |rpId|.
this is apparently operating on the `hostname` component of 
`|callerOrigin|`.  (this itself needs to be clarified but tracked in a
 separate issue)

instead of simply lower casing the hostname and ensuring utf-8 
encoding (as done in 3d and 4th sentences), should we not be 
specifying something essentially the same as done in RFC6265 
<https://tools.ietf.org/html/rfc6265#section-5.1.2> ?
5.1.2.  Canonicalized Host Names

   A canonicalized host name is the string generated by the following

   1.  Convert the host name to a sequence of individual domain name

   2.  Convert each label that is not a Non-Reserved LDH (NR-LDH) 
       to an A-label (see Section of [RFC5890] for the former
       and latter), or to a "punycode label" (a label resulting from 
       "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
       (see Section 6.3 of this specification).

   3.  Concatenate the resulting labels, separated by a %x2E (".")
this is because in this world of deployed IDNA (RFC5890 and RFC3490, 
see also [1]), all operations on domain names must be done 
label-by-label, on A-labels and Non-Reserved LDH (NR-LDH) labels. 

Alternatively, if it is assumed that a user agent implementing 
webauthn will have already performed "host name canonicalization", the
 webauthn spec should state that and cite the appropriate (likely W3C)
 spec requiring that processing. 

[1] https://tools.ietf.org/html/rfc6265#section-6.3
6.3.  IDNA Dependency and Migration

   IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490].  However, there 
   differences between the two specifications, and thus there can be
   differences in processing (e.g., converting) domain name labels 
   have been registered under one from those registered under the 
   There will be a transition period of some time during which 
   based domain name labels will exist in the wild.  User agents 
   implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
   in order to facilitate their IDNA transition.  If a user agent does
   not implement IDNA2008, the user agent MUST implement IDNA2003

Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/167 using your GitHub account
Received on Tuesday, 16 August 2016 22:20:53 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:22 UTC