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

Re: 05/24/2016 WebAuthn Summary

From: J.C. Jones <jjones@mozilla.com>
Date: Fri, 27 May 2016 12:32:46 -0700
Message-ID: <CAObDDPCZFjasF6=Be0vgMVEg1WPph+QcouUuPETXZotKd7Oq6Q@mail.gmail.com>
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" <public-webauthn@w3.org>
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?
>
>
>
Received on Friday, 27 May 2016 19:33:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:15 UTC