- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Jan 2019 19:21:35 +0000
- To: public-webauthn@w3.org
RP implementation logic _before_ this change: - **Extension output `appid: false`:** Ok, RP ID was definitely used, business as usual. - **Extension output `appid: true`:** Ok, AppID is supposed have been used instead. But hmm, there's that [corner case](https://github.com/w3c/webauthn/issues/1034) in the L1 spec where the client might set `appid: true` even though the signature was computed over the RP ID instead of the AppID. Does this client implement the logic as specified in L1? **Better try the RP ID anyway if AppID fails.** RP implementation logic _after_ this change: - **Extension output `appid: false`:** Ok, RP ID was definitely used, business as usual. - **Extension output `appid: true`:** Ok, spec says to **try both AppID and RP ID.** I.e., RPs already kind-of have to do this. The motivation for the change is to simplify the client processing, and to also bring the RP processing specification in line with what RPs actually need to do to work around that corner case in L1 (which will in theory "always"(ish) be necessary since it's hard to know whether the client implements that logic as specified in L1, as specified in L2, or as was intended by L1). In the end, though, the L1 corner case is a small one which in the worst case might hit the user with inexplicably failed authentications until they unplug all authenticators but one, so it's not a big problem, and it might be too much hassle to make this (on the surface) breaking change just to fix that. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1144#issuecomment-456932078 using your GitHub account
Received on Wednesday, 23 January 2019 19:21:36 UTC