RE: wrt registries (was: Spec status)

Sorry, that bit was a little cryptic.

For at least some formats (Android for example) our spec isn't the primary reference either. So, depending on what we do for extensions, that section might shrink down to just a name and a pointer to the SafetyNet documentation. In which case it could completely move into the registry.

Whether the above is entirely true or practical is not completely clear yet. This is the reason I'm going through and trying to make the attestation sections more modular like we already have for extensions. Once we have a clear definition of what an attestation format is, and what its inputs/outputs are, we can see if some of these sections shrink down enough. Otherwise, I agree we could just leave them in the spec and point to them from the I-D.

-----Original Message-----
From: jeff.hodges@kingsmountain.com [mailto:jeff.hodges@kingsmountain.com] 
Sent: Thursday, July 28, 2016 2:43 AM
To: Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: wrt registries (was: Spec status)

Quoting Vijay Bharadwaj <vijaybh@microsoft.com> on 07/20/2016
(01:04:57 PM MDT):
>
> o   We should consider moving the attestation formats into a       
> registry (perhaps the same one as for the extensions),

If by "move the attestation formats into a registry" you mean to move the *definitions, and specifications of, attestation formats* into a registry, that is incorrect.

I think what you mean to propose is..

   We should consider moving the specification of the
   attestation formats into a separate specification,
   and also creating and employing a registry of
   attestation format types.

..yes?

I.e., having a registry of attestation format names, and specifying attestation formats in a separate spec, are two orthogonal things.  
Unfortunately, we seem to continually conflate those things (further below, I attempt to clarify the relationship between registries and specifications).

Also, please note that we have an internet-draft for creating the two registries we have been discussing: an attestation types (i.e.,
formats) registry, and an extension identifiers registry..

draft-hodges-webauthn-registries-00
https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0097.html


Also, you said "perhaps the same one as for the extensions" -- this is incorrect as those would be two separate registries. Although, they can be created by a single registry-creating specification.

We should add text to the spec referencing these to-be-created registries -- this will hopefully keep us on the same page regarding our plans in this regard.

HTH,

=JeffH


PS: regarding the relationship between registries and specifications:

There seems to be a general misunderstanding of the purpose and use of registries amoungst us -- if we are not careful to use correct terminology we are only going to continue to confuse ourselves -- please allow me to try to clarify registry characteristics (IANA-managed registries in particular) and how they relate to
specifications:

IANA "protocol assignment" registries..

   http://www.iana.org/protocols


..themselves contain only "name, number, code, value" assignments, the registries themselves _do not_ contain the definitions or specifications of the meaning of each name, number, code, or value.

Rather, a registry contains a list of of the possible "name, number, code, value"s of a particular protocol variable, and _point to the specification(s)_ where they are defined. And that is all.

Take the "JSON Web Key Parameters" registry as an example..

* the IANA-registered set of "JSON Web Key Parameters" are here..

https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters


* note that the registry contains only the name, and other salient attributes, of each key parameter, and a reference to the specification where the key parameter is actually defined.

* note that at this time, JSON web key parameters are defined in two separate  specifications: RFC7517 and RFC7518.  Additionally, RFC7517 defined, and caused the creation of, this IANA registry, and RFC7518 simply defines an additional set of key parameters, and registers them in this registry.

Received on Thursday, 28 July 2016 16:20:36 UTC