W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2019

[w3c/webauthn] 776b7b: Determine appid extension output after authenticat...

From: GitHub <noreply@github.com>
Date: Fri, 18 Jan 2019 11:00:35 -0800
To: public-webauthn@w3.org
Message-ID: <5c4222537d71e_30ab2ab6b645a578470a@hookshot-fe-32b5f5b.cp1-iad.github.net.mail>
  Branch: refs/heads/issue-1034-appid-output-corner-case
  Home:   https://github.com/w3c/webauthn
  Commit: 776b7b14d6e8f64b101db7e92318c877c588e861
  Author: Emil Lundberg <emil@yubico.com>
  Date:   2019-01-18 (Fri, 18 Jan 2019)

  Changed paths:
    M index.bs

  Log Message:
  Determine appid extension output after authenticator returns

This fixes the following corner case:

1. The user has a U2F authenticator A plugged in, which has been
   registered via the U2F API (i.e., with AppID).
2. The user has a CTAP2 authenticator B plugged in, which has been
   registered via the WebAuthn API (i.e., with RP ID).
3. The user initiates an authentication ceremony and the RP sets the
   `appid` extension.
4. The client runs the above client processing and discovers that
   authenticator A does not contain a credential for the RP ID, and
   retries with the AppID. This succeeds, and the client sets the
   extension's _output_ to `true`.
5. The client initiates authentication requests with both authenticator
   A and B, which both prompt the user for consent.
6. The user confirms user consent on authenticator B, which generates an
   assertion for the RP ID.
7. The client returns the assertion for the RP ID and the `appid` client
   extension output set to `true`.

So it was possible for the extension output to end up being `true` even
though the RP should verify the assertion using the RP ID and not the

      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.
Received on Friday, 18 January 2019 19:00:58 UTC

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