Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

On 6/4/16, 9:56 PM, "Vijay Bharadwaj" <> wrote:
>I don¡¯t think this is exactly the same as we discussed last week. The
>discussion last week was from the point of view of what user agents
>should do ¡© whether user agents should be mandated to drop extensions
>they don¡¯t understand. Your
> point there was that we should not mandate that user agents introduce
>friction in the ecosystem in this way.
>This discussion asks ¡© does it make sense for an authenticator to return
>an extension that the RP has not indicated support for (regardless of
>whether the user agent understands the extension)?

I respectfully disagree -- it seems to me it is essentially a facet of the
discussion in..

  wrt client filtering of extensions (was: 05/24/2016 WebAuthn Summary

..fifth paragraph (also included below at [1]).

If you recall, it had been proposed earlier in this "extensions,
continued.." thread that "Authenticators will only emit extensions they
were prompted to emit" which is also what Dirk's original message.. about (that msg is also quoted below).

>This does not involve user agents at all ¡©
> assume, if you like, a world in which all user agents simply pass all
>extensions through. Would it make sense in such a world for
>authenticators to send unsolicited data that the RP does not necessarily
>want or understand?

yes, I believe so, for the reasons outlined in [1]. Though, with this
proposal (IIUC), the client (aka user agent) is not filtering returned
authenticator data, but there would still be friction added to the
ecosystem in that the RP must alter their front-end to ask for extensions
rather than the extension data being simply provided gratis by the
authenticator (authnr) such that the RP needs only update their backend to
take advantage of it.

>Put another way, consider the ¡°supported extensions¡± extension by which
>an authenticator tells an RP what extensions it supports. Where is the
>counterpart where the RP tells the authenticator what it supports?

The RP ought to ignore any returned extensions (in both
ScopedCredentialInfo.Attestation and WebAuthnAssertion.authenticatorData)
that it does not understand. [it seems this needs to be clarified in the

This is overall how UAF works, fyi/fwiw.



>From: Hodges, Jeff []
>Sent: Saturday, June 04, 2016 4:21 PM
>To: Vijay Bharadwaj <>; Dirk Balfanz
>Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>On 6/4/16, 4:13 PM, "Hodges, Jeff" <> wrote:
>>On 6/4/16, 2:21 PM, "Vijay Bharadwaj" <>
>> wrote:
>>>I¡¯m all for anything that makes overall extension behavior more
>>>consistent. This proposal does have that benefit, and it seems to have
>>>some additional nice properties:
>>>RPs who aren¡¯t aware of, or wouldn¡¯t know what to do with, a particular
>>>extension don¡¯t get that extension sent to them. This saves bandwidth
>>>and some authenticator processing, while potentially simplifying
>>> RP processing as well.
>>>It forces RPs to declare up front what extensions they request. So if
>>>an egregiously bad extension is discovered tomorrow, it would be easy
>>>to write a web crawler to scan for usage of this extension.
>>> This helps with the ¡°reputational recourse¡± for misbehaved extensions
>>>that Wendy and others have proposed.
>>Is this not exactly what we discussed on Friday and is the subject of
>sorry, I meant last Wed.

>>..write-up?   If so, the arguments in the above msg hold and I/we will
>>object to adding such friction to the ecosystem.  If an authnr behaves
>>badly, there is reputational/legal recourse as-discussed
>> in the above-referenced message.
>>In any case, we should add privacy  considerations to the spec to the
>>effect that "authenticators MUST NOT emit the same uniquely-indentifying
>>information to different RPs".  Also, FIDO is (and
>> will be) offering authenticator certification programs of various kinds
>>which will ostensibly bolster this (e.g., through certification
>>agreements and trademark licensing terms).
>>Please note that UAF has supported authenticator-produced extensions
>>from the beginning and that has not been flagged as an issue by the
>>external security review nor have issues emerged (though
>> they could, but then reputational/legal recourse and the certification
>>regime is our backstop).
>>>From: Mike Jones
>>>Sent: Saturday, June 04, 2016 1:35 PM
>>>To: Dirk Balfanz <>; Hodges, Jeff
>>><>; Vijay Bharadwaj <>
>>>Subject: RE: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>>>Makes sense to me
>>>From: Dirk Balfanz <>
>>>Sent: Saturday, June 4, 2016 11:15 AM
>>>To: Hodges, Jeff <>;
>>>Vijay Bharadwaj <>
>>>Until Adam pointed this out to me in Berlin, I had no idea that these
>>>other three extensions exited. Now, it's certainly my fault - and no
>>>one else's - for not reading the attestation document more carefully
>>>(which is where these three extensions were originally
>>> defined), but I honestly don't remember these three extensions being
>>>discussed the way we discussed the authenticator-selection and
>>>transaction-authorization extensions. Does anyone else remember us
>>>discussing (perhaps in the FIDO 2.0 WG) these extensions?
>>yes, we discussed the Attestation spec several times, but that
>>apparently mean that everyone read it in detail.
>>>In particular, I don't understand why they are defined as "unprompted"
>>>extensions. This is a privacy problem. How can the client do its job of
>>>protecting user
>>> privacy if the authenticator is allowed to add data to the assertion
>>>that the client doesn't understand? I get Jeff's point about innovation
>>>if the RP and authenticator can agree on something even if the client
>>>doesn't know what that something is, but I believe
>>> we should err on the side of privacy here.
>>Unless the authnr is returning data that uniquely-identifies this
>>particular authenticator to any and all RPs -- i.e., the additional
>>extension-supplied data added to authenticatorData is different
>> on at least a per-RP ID basis -- I do not believe this is a privacy
>>issue.   Note that it is nominally possible to test for emitting such
>>non-unique-per-RP data.
>>>I would also point out that technically speaking, unprompted extensions
>>>are not allowed according to the current text, which states that "an
>>>extension must
>>> specify, at minimum, an extension identifier and an extension client
>>>argument sent via the {{getAssertion()}} or {{makeCredential()}} call".
>>that's a good catch -- we ought to qualify the above requirement as
>>being for RP-requested and client-requested extensions and exempt
>>authnr-produced extensions.
>>>On Fri, May 27, 2016 at 1:07 PM Hodges, Jeff <>
>>> wrote:
>>>On 5/27/16, 12:50 PM, "Vijay Bharadwaj" <>
>>> wrote:
>>>> You mean you object to allowing the client a say in which extensions
>>>>are >
>>>> emitted? We¡¯re not talking about removing any existing extensions,
>>>>just >
>>>> about clearly defining the circumstances under which an authenticator
>>>> might emit them.
>>>Yes, we would object to altering the present design that allows for
>>>authenticators to implement and emit extensions of their own volition,
>>>as pesently specified (c.f., AAGUID extension, SupportedExtensions
>>> extension, User Verification Index (UVI) extension).  We feel it is a
>>>subtle-but-important aspect of fostering the overall ecosystem.
>>>This entire thread has become quite frayed... having a concrete
>>>extension proposal on the table may help it coalesce -- I suggest that
>>>Giri write up the postulated "opaque data" extension using
>>> the framework that's presently defined in the spec and then hopefully
>>>we can more objectively assess it.
>>>From: Hodges, Jeff []
>>>Sent: Friday, May 27, 2016 12:48 PM
>>>To: Vijay Bharadwaj <>
>>>Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary
>>>On 5/27/16, 12:37 PM, "Vijay Bharadwaj" <>
>>> wrote:
>>>>One issue with that is that some of the extensions that are currently
>>>> defined (in fact, 3 out of 5) are emitted unprompted by the
>>>>authenticator. >Though if we wanted to make this rule, I would be fine
>>>>with it and
>>>>we could add it in the spec if others agree.
>>>>Essentially the authenticator would still be allowed to ignore
>>>>extensions, just not add new ones on its own.
>>>We paypal object to obviating existing extensions.
>>> From: J.C. Jones []
>>>Sent: Friday, May 27, 2016 12:33 PM
>>>That's how you'd enforce it: if the authenticator doesn't obey the
>>>contract, the signature won't be valid when the RP checks it.
>>>Roughly the contract would be: Authenticators will only emit extensions
>>>they were prompted to emit.

From:  "Hodges, Jeff" <>
Date:  Saturday, May 28, 2016 at 2:01 PM
To:  W3C WebAuthn WG <>
Subject:  wrt client filtering of extensions (was: 05/24/2016 WebAuthn
Resent-From:  W3C WebAuthn WG <>
Resent-Date:  Saturday, May 28, 2016 at 2:02 PM

I offer the below in hopes of helping to coalesce the recent list
discussions regarding "client filtering of extensions"...

On 5/27/16, 10:45 AM, "Wendy Seltzer" <> wrote:
>On 05/27/2016 01:13 PM, Mandyam, Giridhar wrote:
>>Sam wrote:
>>>If the client has made some editorial judgements on what extensions it
>>>will support and what user permissions it will ask for, does it also
>>>have to examine the reply to that extension from the authenticator in
>>>any way? Or for that matter, *can* it even examine the reply sensibly
>>>in all cases?
>>Given that all extensions are optional for the client, it seems that
>>this would be a decision that each browser vendor must make on their own
>>independent of the specification.  I personally don©öt think we need to
>>answer these questions for the specification to go forward.  But I look
>>forward to other responses.
>I could see it being a choice for the client:
>Some clients might choose to accept only extensions whose formats or
>contents they understand.
>Other clients might accept extensions whose authors made assertions
>(textual, not cryptographic) about what they were doing. Even if the
>client couldn't understand the response, at least if they learned later
>that the extension/authenticator were misrepresenting the communication,
>they'd have some grounds for complaint.

I agree with Wendy -- basically, the overall "client filtering of
extensions" questions do not seem amenable to being solved entirely
technologically, especially if we want to foster an innovative
low-friction Bring Your Own Device ecosystem.

The 1st client choice -- UAs honoring only certain extensions -- applies
to "RP-requested extensions" (to coin a term). Here, clients (aka user
agents) have a natural means to filter them.

The 2nd client choice -- reputational/legal recourse -- applies to both
RP-requested extensions and "authenticator-produced extensions" (to coin
another term), the latter which are not terribly feasible for clients to
actively filter out (for ecosystem biz reasons, see below).

Authenticator-produced extensions, though, are overall manageable in the
context of the 2nd client choice: if they are caught misrepresenting their
actual behavior, then there are grounds for complaint and there may be
consequences.  Also, FIDO is (and will be) offering authenticator
certification programs of various kinds which will ostensibly bolster this
(e.g., through certification agreements and trademark licensing terms).

Regarding authenticator-produced extensions and ecosystem biz reasons, if
clients were to filter returned WebAuthnAttestation or WebAuthnAssertion
objects based on whether the RP explicitly requested any extensions whose
data is returned therein, then RPs have to update code on both their
front- and back-ends to utilize such extensions. Also, there is slightly
more complexity for authenticator implementations. If the
authenticator-produced extension data is simply returned to the RP, per
present design, the RP only needs to update their back-end to utilize the

Additionally, it would place the client in the gatekeeper position for all
extensions in that once the RP must explicitly request any and all
extensions, including authenticator-produced extensions, the 1st client
choice applies in all cases. This will add friction to the ecosystem in
that now for some new authenticator-produced extension to be generally
useful to RPs, both "extn filtering clients" and RP front-ends must become
explicitly aware of it before the authenticator-produced extensions' data
will become available at RP backends (except for any clients who do not
generally filter extensions).

An additional observation: the spec presently lacks privacy considerations
overall, and for extensions in particular, which ostensibly would outline
the privacy-oriented responsibilities of the various entities, e.g., in
which cases ought clients request user permission, authenticators must not
emit the same uniquely-indentifying information to different RPs, etc.
Such statements would help provide a basis for the reputation/legal
recourse backstop and we should endeavor to add privacy (and security)
considerations to the spec.



Received on Monday, 6 June 2016 19:01:01 UTC