Re: 05/24/2016 WebAuthn Summary

This seems to me to be a good usability compromise if we're going to have
opaque extensions. It seems more straightforward to implement at the RP as
well. With this change, the RP would validate the getAssertion, then check
for the necessary extensions. If they aren't there, the user/user agent
must have denied them, so prompt the user / proceed with that knowledge.

Without this change, the RP would fail to validate the getAssertion, and
then be left to figure out what happened by the error code, or perhaps,
processing the assertion that has an invalid signature.

On Fri, May 27, 2016 at 12:37 PM, Vijay Bharadwaj <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.
>
>
>
> *From:* J.C. Jones [mailto:jjones@mozilla.com]
> *Sent:* Friday, May 27, 2016 12:33 PM
> *To:* Vijay Bharadwaj <vijaybh@microsoft.com>
> *Cc:* Mandyam, Giridhar <mandyam@qti.qualcomm.com>; Sampath Srinivas <
> samsrinivas@google.com>; Anthony Nadalin <tonynad@microsoft.com>;
> public-webauthn@w3.org
> *Subject:* Re: 05/24/2016 WebAuthn Summary
>
>
>
> 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.
>
>
>
> On Fri, May 27, 2016 at 12:27 PM, Vijay Bharadwaj <vijaybh@microsoft.com>
> wrote:
>
> As a client, how would you enforce this other than by dropping the
> signature on the floor?
>
>
>
> In general, every time you put in a MUST into a protocol or other spec,
> you need to say what the consequences are if it is violated. Otherwise it’s
> not really a MUST.
>
>
>
> *From:* J.C. Jones [mailto:jjones@mozilla.com]
> *Sent:* Friday, May 27, 2016 11:52 AM
> *To:* Vijay Bharadwaj <vijaybh@microsoft.com>
> *Cc:* Mandyam, Giridhar <mandyam@qti.qualcomm.com>; Sampath Srinivas <
> samsrinivas@google.com>; Anthony Nadalin <tonynad@microsoft.com>;
> public-webauthn@w3.org
> *Subject:* Re: 05/24/2016 WebAuthn Summary
>
>
>
>
>
>
>
> On Fri, May 27, 2016 at 10:44 AM, Vijay Bharadwaj <vijaybh@microsoft.com>
> wrote:
>
> The extensions are also signed over. So if the client were to drop an
> extension coming out of the authenticator, it might as well drop the entire
> signature since it’s not going to check out any more. A client might do
> that for egregious behaviors, but would likely be hesitant to do it.
>
>
>
> Is it feasible to prohibit authenticators from responding with extensions
> whose extension identifiers weren't matched in the getAssertion?
>
>
>
>
>