W3C home > Mailing lists > Public > public-webauthn@w3.org > June 2022

Re: [webauthn] Discussing mechanisms for enterprise RP's to enforce bound properties of credentials (#1739)

From: John Bradley <jbradley@yubico.com>
Date: Tue, 14 Jun 2022 11:50:32 -0700
Cc: public-webauthn@w3.org
Message-Id: <D577D111-836F-4F09-B57A-675CB729E09D@yubico.com>
To: Shane Weeden via GitHub <sysbot+gh@w3.org>
Having DPK + attestation be an equivilent to a single device credential is a goal.

I think it is an unrealistic short term goal.  We do need to finish the specs so that can be developed, however for the near term we need to prepair RP to deal with multi-device credentials with no attestation.  

We have a lot of positive deployment stories for RP to replace passwords and leverage multi device credentials that are backed up for account recovery.

I understand there is a glass half empty side of the story, but in the short term I would prefer to concentrate on the glass half full and not fixcate on DPK and attestation.   Deploy the use cases that don’t require that.  

For the ones that do there iare still non discoverable credentials on Android, Discoverable credentials on Windos, and security keys.  Not the end of the world.

John B.

> On Jun 14, 2022, at 11:24 AM, Shane Weeden via GitHub <sysbot+gh@w3.org> wrote:
> 
>> Wouldn't DPK support (PR#1663) be sufficient?  Essentially not preventing the multi-device key, but ensuring an additional single-device key being established *per device*.
> 
> I think so however it would have to include DPK attestation. 
> -- 
> GitHub Notification of comment by sbweeden
> Please view or discuss this issue at https://www.google.com/url?q=https://github.com/w3c/webauthn/issues/1739%23issuecomment-1155554896&source=gmail-imap&ust=1655835917000000&usg=AOvVaw2JcOG0NQDmAfBupY-A8Bgt using your GitHub account
> 
> 
> -- 
> Sent via github-notify-ml as configured in https://www.google.com/url?q=https://github.com/w3c/github-notify-ml-config&source=gmail-imap&ust=1655835917000000&usg=AOvVaw3VtX_Cr6dTHZh65TwrTKoD
> 
Received on Tuesday, 14 June 2022 18:52:21 UTC

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