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

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.

Thoughts? objections?

From: Mike Jones
Sent: Saturday, June 04, 2016 1:35 PM
To: Dirk Balfanz <balfanz@google.com>; Hodges, Jeff <jeff.hodges@paypal.com>; Vijay Bharadwaj <vijaybh@microsoft.com>
Cc: 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>
Cc: public-webauthn@w3.org<mailto:public-webauthn@w3.org>
Subject: Re: extensions, continued.. (was: 05/24/2016 WebAuthn Summary

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?

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.

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".

I therefore propose that these three extensions be changed to included a client argument that signals to the authenticator that the information described in the extension should be provided by the authenticator.

Thoughts? Opposing or supporting views?

Dirk.


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.

HTH,

=JeffH




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.