- From: Emil Lundberg <emil@yubico.com>
- Date: Wed, 24 Mar 2021 18:59:22 +0100
- To: nadalin@prodigy.net
- Cc: Adam Langley <agl@google.com>, W3C Web Authn WG <public-webauthn@w3.org>, John Fontana <jfontana@yubico.com>, Wendy Seltzer <wseltzer@w3.org>
- Message-ID: <CANMnvkygUA0h+wT=5XLSC9bU7vv15Gek_GyMGi1k6+ay6_v8VQ@mail.gmail.com>
I'm not sure what "lights out operations" means, or what the recovery extension (#1425) has to do with remote desktops. I think #1425 is more closely related to (1), or perhaps a new "(8) Account recovery and/or credential backup options" item. On Wed, Mar 24, 2021 at 6:20 PM <nadalin@prodigy.net> wrote: > I have tried to map the issues to the charter items below, there may be > others that map. Thanks for the comments. I did not want to define the > issues too deep as that might take us down a path that may exclude things > or a specific implementation, I’m fine to add more detail if the WG wants > this. As far as secret keys are concerned this may be useful in a recovery > situation or in a transaction confirmation case > > > > API Features in scope are: > > (1) Requesting generation of multiple asymmetric key pair within a > specific scope (e.g., an origin) with crypto agility and crypto parameter > selection; Support for authenticators providing more than one key · Issue > #1546 · <https://github.com/w3c/webauthn/issues/1546> PublicKeyCredentialParameters > can't select curve (E.g. ed448) · Issue #1446 · w3c/webauthn (github.com) > <https://github.com/w3c/webauthn/issues/1446> > > (2) Proving that the browser has possession of a specific private key, > where the proof can only be done within the scope of the key pair. In other > words, authentication should obey the same origin policy; > > (3) Remote desktop (lights out operations) ability; Support for remote > desktops · Issue #1577 · w3c/webauthn (github.com) > <https://github.com/w3c/webauthn/issues/1577> Add recovery extension by > emlun · Pull Request #1425 · w3c/webauthn (github.com) > <https://github.com/w3c/webauthn/pull/1425> > > (4) Ability to allow a non- modal UI; Add support for non-modal UI · > Issue #1545 · w3c/webauthn (github.com) > <https://github.com/w3c/webauthn/issues/1545> > > (5) Binding of ambient credentials; > > (6) Re-authentication from the discretion of the replying party; Adding > info about HSTS for the RPID to client Data. · Issue #1554 · w3c/webauthn > (github.com) <https://github.com/w3c/webauthn/issues/1554> > > (7) Dynamic Linking of authentication credentials. double check > whether the Secure Payment Confirmation effort has implications on the > WebAuthn spec · Issue #1492 · w3c/webauthn (github.com) > <https://github.com/w3c/webauthn/issues/1492> > > > > > > > > > > > > *From:* Adam Langley <agl@google.com> > *Sent:* Tuesday, March 23, 2021 10:45 AM > *To:* nadalin@prodigy.net > *Cc:* W3C Web Authn WG <public-webauthn@w3.org>; John Fontana < > jfontana@yubico.com>; Wendy Seltzer <wseltzer@w3.org> > *Subject:* Re: Draft Charter > > > > On Wed, Mar 17, 2021 at 9:04 AM <nadalin@prodigy.net> wrote: > > Here is a marked-up version of the charter to review. Please post comments > to the list. > > > > What motivates the addition of "cryptographic agility and crypto parameter > selection"? > > > > Where it says "modal UI" it should say "non-modal". > > > > (6) is defined twice. > > > > More generally, (4)-(6) seem like they would be difficult to interpret by > someone who's not already familiar with ongoing discussions behind them. > (For example, I'm not sure what they mean.) But perhaps that's fine. > > > > In light of the PRF discussion last time, do we wish to bring storing > secret keys in scope this time? > > > > > > Cheers > > > AGL > > > > > > > > > > > -- Emil Lundberg Software Developer | Yubico <http://www.yubico.com/>
Received on Wednesday, 24 March 2021 17:59:47 UTC