Attestation format identifiers lack formal definition and matching rules

[equalsJeffH]

Attestation format identifiers lack formal definition and matching rules.

suggested approach to add to spec:

WebAuthn attestation format identifiers are strings, and are
allocated on a first-come-first-served basis. They MUST
not be longer than 32 octets and MUST consist only of 
printable USASCII characters, i.e., VCHAR as defined 
in [RFC5234]. Implementations MUST match WebAuthn 
attestation type identifiers in a case-insensitive fashion.

[jcjones]

Saying the identifiers are allocated implies, to me, a registry. Current language is that identifiers should aim to be globally unique. It seems to me we could give your formal definition and matching rules, drop the note about allocation, and instead have something like:

Extensions are identified by a string, chosen by the extension author. They MUST
not be longer than 32 octets and MUST consist only of
printable USASCII characters, i.e., VCHAR as defined
in [RFC5234]. Implementations MUST match WebAuthn
attestation type identifiers in a case-insensitive fashion.

Extension identifiers should aim to be globally unique,
e.g., by using reverse domain-name of the defining entity such as com.example.webauthn.myextension.

[vijaybh]

Agree, with the modification that perhaps we should move away from recommending dot notation for things that are not hierarchies.

[jcjones]

Fair; I was working from e22cd4a prior to seeing your suggestion of camelCasing. I'll propose an alternate shortly.

[jcjones]

How about:

(Modifying the first paragraph of Extension identifiers)

Extensions are identified by a string, chosen by the extension author. They MUST not be longer than 32 octets and MUST consist only of printable USASCII characters, i.e., VCHAR as defined in [RFC5234]. Implementations MUST match WebAuthn attestation type identifiers in a case-insensitive fashion. Extension identifiers should aim to be globally unique,
e.g., by including the defining entity such as myCompanyExtension.

[vijaybh]

Noticed you omitted JeffH's suggested text that said people SHOULD register extensions in [I-D. hodges-webauthn-registries]. Was that accidental or intentional?

Jeff's suggested text is in https://lists.w3.org/Archives/Public/public-webauthn/2016Jul/0070.html

[jcjones]

Accidental! Accidental! I seem to have missed that message.

I like @equalsJeffH's suggested text. 👍

[equalsJeffH]

updating terminology from "attestation type" to "attestation format"

[equalsJeffH]

see also #155, adding this issue to MS WD-02.

[equalsJeffH]

@vijaybh wrote:

Noticed you omitted JeffH's suggested text that said people SHOULD register extensions in [I-D. hodges-webauthn-registries]. Was that accidental or intentional?

Jeff's suggested text is in https://lists.w3.org/Archives/Public/public-webauthn/2016Jul/0070.html

the suggested text and rationale from the email msg cited above is below (with updated terminology and pointer to current registries I-D)...

On 7/11/16, 2:59 PM, "J.C.Jones via GitHub" sysbot+gh@w3.org wrote:

Saying the identifiers are allocated implies, to me, a registry.

apologies, I didn't fully explain my rationale in this issue.

yes, I think we do wish to have an IANA registry for attestation types,
see..

draft-hodges-webauthn-registries
https://raw.githubusercontent.com/w3c/webauthn/master/draft-hodges-webauthn-registries-00b.txt

..because it will be a useful tool for the ecosystem, e.g., by gathering
publicly-specified attestation types, and pointers to their
specifications, in a well-known place.

That said, we should also provide guidance for those who do not wish to
register their attestation format identifier(s) -- i.e., we should recognize
that not everyone will wish to publicly specify their attestation formats
and specs (think proprietary enterprise-specific use cases, say).

so I propose we make use of the registry a SHOULD, and un-registered
attstn format names SHOULD use reverse domain-name naming. [perhaps the
latter should be a MUST? however, a SHOULD recognizes that there's no
effective enforcement...]

thus:

WebAuthn attestation format identifiers are strings, chosen
by the attestation format developer. They SHOULD be registered
per [I-D. hodges-webauthn-registries] "Registries for Web 
Authentication (WebAuthn)".
Unregistered attestation format identifiers SHOULD use
reverse domain-name naming, using a domain name registered by
the attestation type developer. All attestation format identifiers MUST
not be longer than 32 octets and MUST consist only of
printable USASCII characters, i.e., VCHAR as defined
in [RFC5234] (note: this means attestation format identifiers based on
domain names MUST incorporate only LDH Labels [RFC5890]).
Implementations MUST match WebAuthn
attestation format identifiers in a case-insensitive fashion.