W3C home > Mailing lists > Public > public-webauthn@w3.org > June 2016

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

From: Vijay Bharadwaj <vijaybh@microsoft.com>
Date: Sun, 5 Jun 2016 04:56:53 +0000
To: "Hodges, Jeff" <jeff.hodges@paypal.com>, Dirk Balfanz <balfanz@google.com>
CC: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <79e70783a4b54046bb44f6e21ba8356f@microsoft.com>

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)? 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?

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?

From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
Sent: Saturday, June 04, 2016 4:21 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com>; Dirk Balfanz <balfanz@google.com>
Cc: public-webauthn@w3.org
Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

On 6/4/16, 4:13 PM, "Hodges, Jeff" <jeff.hodges@paypal.com<mailto:jeff.hodges@paypal.com>> wrote:

On 6/4/16, 2:21 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> 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 this..

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 <balfanz@google.com<mailto:balfanz@google.com>>; Hodges, Jeff <jeff.hodges@paypal.com<mailto:jeff.hodges@paypal.com>>; Vijay Bharadwaj <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>>
Cc: public-webauthn@w3.org<mailto:public-webauthn@w3.org>
Subject: RE: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

Makes sense to me

From: Dirk Balfanz<mailto:balfanz@google.com>
Sent: Saturday, June 4, 2016 11:15 AM
To: Hodges, Jeff<mailto:jeff.hodges@paypal.com>; Vijay Bharadwaj<mailto:vijaybh@microsoft.com>

Hi there,

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 <jeff.hodges@paypal.com<mailto:jeff.hodges@paypal.com>> wrote:
On 5/27/16, 12:50 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> 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 [mailto:jeff.hodges@paypal.com]
Sent: Friday, May 27, 2016 12:48 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>>
Cc: public-webauthn@w3.org<mailto:public-webauthn@w3.org>
Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

On 5/27/16, 12:37 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com<mailto:vijaybh@microsoft.com>> 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 requested extensions, just not add new ones on its own.

We paypal object to obviating existing extensions.

 From: J.C. Jones [mailto:jjones@mozilla.com]
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.
Received on Sunday, 5 June 2016 04:57:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:21 UTC