Re: Proposal for W3C-style Attestation Registry

Thanks Giri and Jeff,

On 08/24/2016 12:33 PM, Mandyam, Giridhar wrote:
> 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.

We can put Jeff's document into the webauthn github, sure.
> {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.}

Noted! I'll work with the team to see if we can put together some shared

>From my perspective, one of the benefits of an IANA registry is the
possibility of ongoing maintenance. W3C Working Groups have
limited-length charters, and so even if W3C can assure the persistence
of documents, we can't assure that the right group will exist to update
them. An IANA registry can point to specifications done by W3C WGs,
where the change-control of the specs remains with W3C.

> 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 []
> Sent: Tuesday, August 23, 2016 7:18 AM
> To: W3C Web Authn WG <>
> Subject: Proposal for W3C-style Attestation Registry
> Bearing in mind the proposal in, 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 (  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.  These can be updated if the group decides to adopt this registry.
> -Giri Mandyam, Qualcomm

Wendy Seltzer -- +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)        +1.617.863.0613 (mobile)

Received on Wednesday, 24 August 2016 17:01:10 UTC