- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Sat, 30 May 2020 20:34:00 +0000
- To: public-webauthn@w3.org
Comments from narrow to wider: #### AAGUID transmission Doesn't seem necessary to leak this to RPs? RP learn and, if they demand, can judge attestation for recovery authenticators when a recovery is attempted. It seems that the motivation is just to follow the existing structure? #### Algorithm transition I don't believe that the group tricks for establishing the recovery authenticator's public key are needed. I think all you need is to asymmetrically encrypt a seed to the recovery authenticator and thus only scalarmults are needed. It does mean that the primary authenticator transiently has the recovery private key but, in this context, the primary authenticator is trusted — it's getting enrolled as an authenticator after all! Having said that, while I've not worked though it in detail, I've seen this trick used for Bitcoin stuff before and I'm happy that it's sound, so it's not a big deal really. But, this does mean that it's possible to implement this pattern without groups, i.e. a post-quantum transition is possible. But there's no algorithm negotiation, i.e. the RP should be able to say what algorithms it can support for `generate`. #### UX UX seems complex? Do you envision selling pre-setup packs of authenticators? As Shane points out, they could just be clones in that case (although with different security properties). Otherwise, the UX of pairing two authenticators, making sure that the user knows which is primary and which is backup, listing backup devices (how are they named?), letting the user manage this etc, seems daunting. And, of course, RPs would have a bunch more stuff to manage. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1425#issuecomment-636381933 using your GitHub account
Received on Saturday, 30 May 2020 20:34:01 UTC