RE: Extensions (was RE: [minutes] 13 May F2F)

I agree that we could create a spec that just creates the IANA registry, this would take a few months to work through this as there has to be expert review, etc.

So we should put this on the agenda for tomorrow's meeting.

From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
Sent: Tuesday, May 24, 2016 3:20 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: public-webauthn@w3.org
Subject: Re: Extensions (was RE: [minutes] 13 May F2F)

On 5/21/16, 3:20 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> wrote:
One addendum on a discussion that happened in the room after we formally adjourned, involving a number of participants who were hanging around in the room after the meeting:

There was a spirited discussion around extensions, and specifically about the extensions proposed in issues #97 and #98. Some implementers felt that asking a client platform to pass through opaque extensions was unrealistic since doing this may have the effect of breaking a promise that the client has made to the user. (For instance, passing through an opaque extension containing location information might break a client's promise to turn off location tracking.) OTOH Giri felt that such extensions would be very valuable in some use cases where such issues did not apply.

This developed into a discussion of what the role of extensions is, and what purpose the pre-defined extensions serve in the specification. It was felt that a better approach would be:
- Only have the spec define what an extension is, and how it should be defined (this is currently section 5)
- Pull all pre-defined extensions (currently section 6) out of the spec
- Create a registry (IANA?) where such extensions may be registered, and possibly seed it by registering the currently pre-defined extensions from section 6
- Put a pointer in the spec to this IANA registry

This proposal appeared to be generally acceptable to those present,
but it would be valuable to get wider feedback from the list. Does anyone have comments or feedback on this proposal?

Thank you for writing this up Vijay -- yes we have comments -- and I wish we'd captured the discussion at the time.

Given the specific items listed above and the overall conclusion drawn here, I and Hubert do not generally agree with it. Silence at the time does not equal agreement,  especially at the end of a long week of meetings and in such informal discussion concerning subtle-but-important  things
:-)

e.g. I don't recall anyone mentioning pulling the pre-defined extensions out of the webauthn spec -- though I do recall mentioning/discussing employing an IANA registry.

It is perfectly fine to create an "empty" registry at IANA (given the correct "IANA registry policy"), and then populate the registry from various other specs.  Thus creating and populating a registry does not necessitate removal of the extensions from our spec and placing them in some other spec which creates the registry.  I have details on this process to share, which I will send in a separate message.

We feel we need a discussion here on the mailing list and during our calls regarding "what the role of extensions is, and what purpose the pre-defined extensions serve in the specification" -- we'd like to better understand and document the various perspectives the group has regarding the extension mechanism and the pre-defined extensions such that we can come to a satisfactory agreement.

fwiw, I've done some fairly close reading of the extension mechanism, the extensions, and attestation portions of the present spec and note that they are fairly tightly intertwined, such that even the proposal on the table to migrate attestation details to another spec is not simple (but admittedly not impossible).

Also I have thoughts on the "opaque pass-thru extension" (to coin a name) that sparked the discussion (as noted above), and will put those in a separate thread.

HTH,

=JeffH