- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Jul 2019 17:23:10 +0000
- To: public-webauthn@w3.org
> As an extension, this is going to be best-effort. With no output, it's not going to be clear to the RP whether it was honored or not -- is that acceptable to RPs? I think the output of `appid` was a mistake and so I've got this extension without an output so far. @emlun suggests a constant `true` output, which isn't too expensive, but I still think it's superfluous. As an RP transitioning to WebAuthn, if they don't care about duplicate registrations on a single authenticator then they're already happy, so let's assume that they do care. They'll include the current credential IDs in the exclude list and set this extension. Then, if there's an output from this extension, they get to find out, after the registration, whether this extension was processed or not. But what are they going to do with that information? Reject the registration because it might be duplicative and tell users to update their browser? That doesn't seem like something we want to work to support. Worse yet they might try some warning: “due to browser limitations we can't ensure that you didn't just register the same token again because it might duplicate some registration that you made before we switched to WebAuthn, so hopefully you didn't do that, right?”. So I can only see bad things happening with this information, so why waste time plumbing it in? Even if we do believe that either of the above are sensible, surely the RP would want to know about support _before_ the registration operation? That would suggest putting it in #1219 . -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1244#issuecomment-509316913 using your GitHub account
Received on Monday, 8 July 2019 17:23:11 UTC