Re: [webauthn] Attestation format identifiers lack formal definition and matching rules

@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

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

On 7/11/16, 2:59 PM, "J.C.Jones via GitHub" <> 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 


..because it will be a useful tool for the ecosystem, e.g., by 
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 
register their attestation format identifier(s) -- i.e., we should 
that not everyone will wish to publicly specify their attestation 
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 
latter should be a MUST? however, a SHOULD recognizes that there's no
effective enforcement...]

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 
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.

GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at 
using your GitHub account

Received on Friday, 2 September 2016 21:18:35 UTC