W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2021

Re: Draft Charter

From: Emil Lundberg <emil@yubico.com>
Date: Wed, 24 Mar 2021 18:59:22 +0100
Message-ID: <CANMnvkygUA0h+wT=5XLSC9bU7vv15Gek_GyMGi1k6+ay6_v8VQ@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC