RE: Proposal for W3C-style Attestation Registry

Since it looks like we are not having a call today, I just wanted to provide a clarification.

After speaking with Jeff Hodges today, we both agreed that the approach taken by the HTML Media Extensions WG for the MSE Bytestream Registry is not a good approach for this group.  We should stick to Jeff's original proposal for an IANA registry.  Ideally Jeff's document will find a place in the group's Github repo and issues can be filed directly against it.

{Note to W3C staff reading this:  please consider the best way to provide overarching guidance to Working Groups as to how to approach creation/update/maintenance of registries.}

That being said please take the document I sent out yesterday as input into how we approach the attestation registry, and not as the actual registry document itself.  I would like to discuss on next week's call some of the issues I raised below (a and b in attached email).

Thanks,
-Giri

From: Mandyam, Giridhar [mailto:mandyam@qti.qualcomm.com]
Sent: Tuesday, August 23, 2016 7:18 AM
To: W3C Web Authn WG <public-webauthn@w3.org>
Subject: Proposal for W3C-style Attestation Registry

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