- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2019 20:50:56 +0000
- To: public-webauthn@w3.org
From the call of 2019-07-17, we are leaning towards closing with issue with no action. Firstly, “resident” here means discoverable, i.e. can be found with an empty allow-list. It has always been the case that authenticators may choose to implement credentials in a stateful manner if they wish. With the current CTAP2 specification, an authenticator can make credentials discoverable at will. I hope to change that in the future, but that's the reality at the moment and thus the reality for all existing CTAP2 authenticators. Given that, if rk=forbidden was defined then, in order to meet that prohibition, a platform would have to refuse to create credentials on any current CTAP2 authenticator. (Because they could be making discoverable credentials behind the scene and there's no way for the platform to know.) That seems like a terrible experience and thus we expect that no RP would ever actually set that option. Therefore why have it? @christiaanbrand says [above](https://github.com/w3c/webauthn/issues/1149#issuecomment-506040708) that his desire is to avoid PIN prompts as an RP. Today there's a problem with that because, once a PIN is set on a CTAP2.0 authenticator, a PIN is needed to create any sort of credential. That's being addressed for CTAP2.1 and, if the authenticator supports U2F, Chromium will work around it today by using the U2F interface to create the credential. But all that is independent of whether a credential is discoverable so having the concept of “forbidden” resident keys doesn't seem to help avoid PIN prompts any more than “discouraged” does. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1149#issuecomment-512563474 using your GitHub account
Received on Wednesday, 17 July 2019 20:50:58 UTC