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

I agree with Jeff that this is more subtle than people might realize.  Interoperability is improved when extensions that are not understood are ignored by default.  However, there are some extensions that are critical to understand, and should cause a failure if not understood.

For instance, the "crit" (critical) header parameter in JWS https://tools.ietf.org/html/rfc7515#section-4.1.11 and JWT is used to embody this distinction.  We may want/need something similar.

                                                       -- Mike

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

There are several subtle-but-important aspects to this overall topic so I wish to second AdamP's request for taking our time to work out our extension-related stuff.

On 5/23/16, 10:13 AM, "Adam Powers" <adam@fidoalliance.org<mailto:adam@fidoalliance.org>> wrote:
...certainly more flexible and open than revving the WebAuthn spec for each new extension.

If we maintain a registry denoting extension types, then spec'g newly-defined extensions and their processing rules  would not require rev'g the WebAuthn spec -- rather, one could write a separate spec for the extension(s) and duly registering them with the registry. This is well-established practice for a host of protocols and their specs.


I would like to socialize this at FIDO since it also impacts specs that are adjacent to WebAuthn (such as CTAP). Can I have a few weeks before we call it consensus?

+1


thanks,

=JeffH


On May 23, 2016 at 9:37:54 AM, J.C. Jones (jjones@mozilla.com<mailto:jjones@mozilla.com>) wrote:
It's important to me that extensions are useful to everyone; for this reason, I like this proposal. I believe it's going to be necessary to let the user filter extensions, particularly as we talk about implementations other than FIDO-standardized ones. A generic 'opaque extension' will make for a very coarse filtering mechanism for the users, whereas having a registry would enable clients to present more useful information.

Anyway, +1.

On Sat, May 21, 2016 at 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?