Re: [webauthn] Personal information updates & webauthn (#1456)

> So there is no way to know that many actions could work before initiating them.

I gathered some of that from the thread about why there’s nothing like `PublicKeyCredential.supports(opts)`. In this case — and that one — I don’t quite understand why “this is problematic for non-discoverable” would also have to mean “so it can’t be done for discoverable creds, either”. Even if there’s a future where a solution is found for updating or support-checking of non-discoverable creds, is there a problem with throwing for those cases in the mean time, unlocking the capabilities for discoverable creds?

<details>
  <summary>Though the idiosyncrasies I was thinking of weren’t related to that exactly...</summary>
  <ul>
    <li>the <a href="https://w3ctag.github.io/design-principles/#new-data-formats">one-off usage of CBOR</a> without an apparent initiative to <a href="https://w3ctag.github.io/design-principles/#js-only">make it usable in the language of the API</a></li>
    <li>"icon" instead of "iconURL" (CredentialUserData), <a href="https://w3ctag.github.io/design-principles/#naming-consistency">even though they mean the same thing and are part of the same overall API</a></li>
    <li>abbreviations apparently motivated by byte-shaving <a href="https://w3ctag.github.io/design-principles/#naming-common-words">instead of intelligibility</a> (e.g. "rp" instead of "relyingParty")</li>
    <li>broadly, <a href="https://w3ctag.github.io/design-principles/#:~:text=Design%20based%20on%20functionality%2C%20not%20based%20on%20the%20existing%20API">underabstraction</a> for major use cases</li>
    <li>forgive me but ... a kinda tough-to-shake sense that the design might have been driven by enterprise interests more than <a href="https://w3ctag.github.io/design-principles/#priority-of-constituencies">user needs</a>?</li>
  </ul>

I’m here because of something like: “we’d like our users to be able to securely sign in using Windows Hello, Apple Touch ID, etc, like they’re used to doing from native apps, possibly obviating the need for a password”. Part of what’s been confusing about WebAuthn is the emphasis it seems to place on non-discoverable creds, which — maybe I’m misunderstanding something here, but — don’t seem super applicable to typical users of typical apps? Our users don’t own Yubikeys.

I’m glad the API exists (and that much smarter folks than me are working on it). The above is a bit vent-y, so I want to be clear that even though it’s criticism, the work that’s gone into the API is still appreciated.
</details>

(Above is collapsed cause it’s tangential and very “general opinion-y”.)

> My expectation personally is that we see WebAuthn evolve to indicate broader actions, and to have the client (browser/platform) taking on more responsibility to mediate RP requests

If I’m picturing what you mean correctly, I think that’s my hope as well: more abstraction / higher level API that corresponds more closely to the intended effects from a user experience POV.

-- 
GitHub Notification of comment by bathos
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1456#issuecomment-872823891 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 July 2021 08:35:31 UTC