Registries for Web Authentication (WebAuthn)
draft-hodges-webauthn-registries-10

[Ballot discuss]
This is really a discuss discuss. With a specification required policy for entries, I think it is quite important to make it clear who has change control over the entries in the registries. I would very much recommend that the information required for a registry entry has an explicit change control field. That field should also note the change probably should reside with the body who own the specification that is referenced in the registry entry.

[Ballot comment]
For both registries, you say, “The expert(s) will clearly identify any issues which cause a registration to be refused.”  You don’t, however, give any guidance about what such issues might be, and it would be useful to give some — consider a time in the future when there are new experts who were not around when this stuff was set up.  This is not a DISCUSS, so if you really have nothing to say I won’t block on it.  But please do consider whether there’s any useful advice to give about what issues might be appropriate “no” material... and that issues explicitly might not.

[Ballot comment]
For both registries, you say, “The expert(s) will clearly identify any issues which cause a registration to be refused.”  You don’t, however, give any guidance about what such issues might be, and it would be useful to give some — consider a time in the future when there are new experts who were not around when this stuff was set up.  This is not a DISCUSS, so if you really have nothing to say I won’t block on it.  But please do consider whether there’s any useful advice to give about what issues might be appropriate “no” material... and that issues explicitly might not.

[Ballot comment]
For both registries, you say, “The expert(s) will clearly identify any issues which cause a registration to be refused.”  You don’t, however, give any guidance about what such issues might be, and it would be useful to give some — consider a time in the future when there are new experts who were not around when this stuff was set up.  This is not a DISCUSS, so if you really have nothing to say I won’t block on it.  But please do consider whether there’s any useful advice to give about what issues might be appropriate “no” material... and that issues explicitly might not.

[Ballot comment]
For both registries, you say, “The expert(s) will clearly identify any issues which cause a registration to be refused.”  You don’t, however, give any guidance about what such issues might be, and it would be useful to give some — consider a time in the future when there are new experts who were not around when this stuff was set up.  This is not a DISCUSS, so if you really have nothing to say I won’t block on it.  But please do consider whether there’s any useful advice to give about what issues might be appropriate “no” material... and that issues explicitly might not.

[Ballot comment]
Thanks for the BCP 14 fix.

Looks like these haven't been answered, so I'm leaving them open for possible follow-up:

Section 2:
* Is there a compelling reason to force a particular URL onto IANA?

Section 2.1:
* "Attestation statement format identifiers are case sensitive.  Attestation statement format identifiers may not ... " can be simply "Attestation statement format identifiers are case sensitive and may not ..."

Section 2.1.1:
* The list of field names in this section and in 2.2.1 are hanging and not really separated from their definitions.  I suggest putting back the "o" bullets and following the names by colons, just to make it clear.

[Ballot comment]
Thanks for this document to enable work in W3C.

To echo what Murray already noted, Per Section 2, why the specific URL for the IANA registry?

[Ballot comment]
Looks fine to me, but I'm not really an expert on IANA sections yet ...

My only comment is that I also found "USASCII" strange, and probably "ASCII" (listed here https://www.rfc-editor.org/materials/abbrev.expansion.txt) might be better.

Regards,
Rob

[Ballot discuss]
An easy fix but a necessary one:

This document makes use of BCP 14 language without citing BCP 14.  (I fully blame Jeff for this oversight.)

[Ballot comment]
Section 2:
* It seems to me that the last two paragraphs could be combined, e.g., "For both registries, the expert(s) and IANA will direct ...".
* Is there a compelling reason to force a particular URL onto IANA?

Section 2.1:
* I think "USASCII" should be two words, or hyphenated perhaps, or just "ASCII", unless there's an ABNF token or something to which it refers.
* "Attestation statement format identifiers are case sensitive.  Attestation statement format identifiers may not ... " can be simply "Attestation statement format identifiers are case sensitive and may not ..."

Section 2.1.1:
* Are the asterisks around bullet list items an artifact of the new format?  This is the second time I've seen it.  Guess I'd better get used to it.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-hodges-webauthn-registries-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the WebAuthn Attestation Statement Format Identifier registry. The new registry will be located on a new registry page for Web Authentication located at:

https://www.iana.org/assignments/webauthn

The new registry will be managed via Specification Required as specified in RFC8126.

IANA understands that there are five initial registrations in the new registry as follows:

WebAuthn Attestation Statement Format Identifier: packed
Description: The "packed" attestation statement format is a WebAuthn-optimized format for attestation. It uses a very compact but still extensible encoding method. This format is implementable by authenticators with limited resources (e.g., secure elements).
Reference: Section 8.2 Packed Attestation Statement Format in [https://www.w3.org/TR/webauthn/]

WebAuthn Attestation Statement Format Identifier: tpm
Description: The TPM attestation statement format returns an attestation statement in the same format as the packed attestation statement format, although the rawData and signature fields are computed differently.
Reference: Section 8.3 TPM Attestation Statement Format in [https://www.w3.org/TR/webauthn/]

WebAuthn Attestation Statement Format Identifier: android-key
Description: Platform-provided authenticators based on versions "N", and later, may provide this proprietary "hardware attestation" statement.
Reference: Section 8.4 Android Key Attestation Statement Format in [https://www.w3.org/TR/webauthn/]

WebAuthn Attestation Statement Format Identifier: android-safetynet
Description: Android-based, platform-provided authenticators MAY produce an attestation statement based on the Android SafetyNet API.
Reference: Section 8.5 Android SafetyNet Attestation Statement Format in [https://www.w3.org/TR/webauthn/]

WebAuthn Attestation Statement Format Identifier: fido-u2f
Description: Used with FIDO U2F authenticators
Reference: Section 8.6 FIDO U2F Attestation Statement Format in [https://www.w3.org/TR/webauthn/]

Second, a new registry is to be created called the WebAuthn Extension Identifier Registry. The new registry will also be located on the new registry page for Web Authentication located at:

https://www.iana.org/assignments/webauthn

The new registry will be managed via Specification Required as specified in RFC8126.

There are eight initial registrations in the new registry as follows:

WebAuthn Extension Identifier: appid
Description: This authentication extension allows WebAuthn Relying Parties that have previously registered a credential using the legacy FIDO JavaScript APIs to request an assertion.
Reference: Section 10.1 FIDO AppID Extension (appid) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: txAuthSimple
Description: This registration extension and authentication extension allows for a simple form of transaction authorization. A WebAuthn Relying Party can specify a prompt string, intended for display on a trusted device on the authenticator
Reference: Section 10.2 Simple Transaction Authorization Extension (txAuthSimple) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: txAuthGeneric
Description: This registration extension and authentication extension allows images to be used as transaction authorization prompts as well. This allows authenticators without a font rendering engine to be used and also supports a richer visual appearance than accomplished with the webauthn.txauth.simple extension.
Reference: Section 10.3 Generic Transaction Authorization Extension (txAuthGeneric) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: authnSel
Description: This registration extension allows a WebAuthn Relying Party to guide the selection of the authenticator that will be leveraged when creating the credential. It is intended primarily for WebAuthn Relying Parties that wish to tightly control the experience around credential creation.
Reference: Section 10.4 Authenticator Selection Extension (authnSel) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: exts
Description: This registration extension enables the WebAuthn Relying Party to determine which extensions the authenticator supports. The extension data is a list (CBOR array) of extension identifiers encoded as UTF-8 Strings. This extension is added automatically by the authenticator. This extension can be added to attestation statements.
Reference: Section 10.5 Supported Extensions Extension (exts) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: uvi
Description: This registration extension and authentication extension enables use of a user verification index. The user verification index is a value uniquely identifying a user verification data record. The UVI data can be used by servers to understand whether an authentication was authorized by the exact same biometric data as the initial key generation. This allows the detection and prevention of "friendly fraud".
Reference: Section 10.6 User Verification Index Extension (uvi) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: loc
Description: The location registration extension and authentication extension provides the client device's current location to the WebAuthn Relying Party, if supported by the client platform and subject to user consent.
Reference: Section 10.7 Location Extension (loc) in [https://www.w3.org/TR/webauthn/]

WebAuthn Extension Identifier: uvm
Description: This registration extension and authentication extension enables use of a user verification method. The user verification method extension returns to the WebAuthn Relying Party which user verification methods (factors) were used for the WebAuthn operation.
Reference: Section 10.8 User Verification Method Extension (uvm) in [https://www.w3.org/TR/webauthn/]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-04-29):

From: The IESG
To: IETF-Announce
CC: kaduk@mit.edu, draft-hodges-webauthn-registries@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Registries for Web Authentication (WebAuthn)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Registries for Web Authentication (WebAuthn)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-04-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines IANA registries for W3C Web Authentication
  attestation statement format identifiers and extension identifiers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hodges-webauthn-registries/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hodges-webauthn-registries/ballot/


No IPR declarations have been submitted directly on this I-D.