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

Proposal for W3C-style Attestation Registry

From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
Date: Tue, 23 Aug 2016 14:17:35 +0000
To: W3C Web Authn WG <public-webauthn@w3.org>
Message-ID: <0f76363ef9b844e6b9d53b1cb70938ed@NASANEXM01C.na.qualcomm.com>
Bearing in mind the proposal in https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0097.html, I am enclosing a proposal for an attestation registry that is more in line with recent W3C registries such as the one for MSE bytestream formats (https://w3c.github.io/media-source/byte-stream-format-registry.html).  Note the following:

a)      It is not clear (at least to me) how best to handle additional clientData for candidate attestation formats.  I am proposing that any new attestation format must specify any extensions to the ClientData dictionary it requires, but I am unclear as to whether this should even be allowed for candidate attestation formats.  If such information is missing from the corresponding specification for a candidate attestation format, then it will be assumed that clientData defaults to whatever the client implementation (user agent) supports.

b)      Proprietary attestation formats should be clearly designated as such, and I am suggesting to do so with a vendor prefix.  An example would be SafetyNet.

c)      I used the "type" attribute as this is consistent with the current specification.

d)      Disregard the self-referring hyperlinks in this document (e.g. https://w3c.github.io/webauthn/webauthnattestationregistry.html).  These can be updated if the group decides to adopt this registry.

-Giri Mandyam, Qualcomm

Received on Tuesday, 23 August 2016 14:18:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:25 UTC