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: Shane Weeden via GitHub <sysbot+gh@w3.org>
Date: Wed, 29 Jun 2022 21:09:13 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1170495443-1656536951-sysbot+gh@w3.org>
In the June 29 meeting the question was asked as to why the current DPK proposal is insufficient and why RPs are requesting the ability to indicate more stringent requirements to the client during credential registration. I offered to provide a perspective on this ( FYI - @timcappalli ), so have initially picked two things to further the discussion:

- Account sovereignty of multi-device credentials results in ongoing reliance on alternative (often phishable) second factors. 
   - If multi-device credentials (more specifically those backed up to a user's platform-provider cloud account) are not able to be excluded by RP policy during credential creation, the spec is essentially dictating that all RPs must figure out a way to make them acceptable (otherwise you have the undesirable fail-after-register UX). 
   - If DPK + a risk engine is the answer to accepting multi-device credentials, then what does the RP do when the risk engine sees first use on a new device? Sites that require control over account sovereignty will need to require some additional level of assurance, typically an existing phishable multi-factor capability. This is exactly what most adopters of WebAuthn want to move away from - and not just because it is phisable, but because it shouldn't be necessary to create and manage the lifecycle of such additional mechanisms in the first place. 
   - WebAuthn with attestation _and a guarantee of device-bound credentials_ offers a way to provide a single step login experience that covers requirements of both account sovereignty and strong phishing-resistant authentication. Multi-device credentials with account sovereignty controlled by the platform provider takes this use case backward, and will see (IMO) all these types of RPs having to maintain alternative 2nd-factor capabilities indefinitely.
   - The counter-argument is account recovery is too hard. Regulated industry and enterprise RPs understand the challenges of account recovery and are prepared to deal with this in other ways. They are unwilling or legislatively unable to accept that account sovereignty is governed by the account a user has with a platform provider.
 
- Extensions are optional in the spec, and DPK attestation is not mandatory. 
  - There is already a public implementation of multi-device credentials that does not supply DPK. DPK can not be considered a trusted signal unless attested, and it has been made clear that there are plans for a DPK implementation on Android later in 2022 which will not include attestation. 
  - Given this state in the real world (no DPK, or DPK without attestation), it is apparent that there is no way for an RP with device-bound requirements to actually express that to the client. One might argue that's a point-in-time statement, but unless the specification makes some of these optional things mandatory RPs with the aforementioned requirements will still find themselves unable to ask the client to: "please do what we will accept, or don't do anything at all".


-- 
GitHub Notification of comment by sbweeden
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1170495443 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 June 2022 21:09:15 UTC

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