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

[webauthn] Enforce backup eligibility during assertion (#1791)

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Tue, 30 Aug 2022 00:43:48 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-1355022609-1661820227-sysbot+gh@w3.org>
Firstyear has just created a new issue for https://github.com/w3c/webauthn:

== Enforce backup eligibility during assertion  ==
## Proposed Change

https://github.com/w3c/webauthn/blob/main/index.bs#L983

Currently this text states:

```
:: A [=Public Key Credential Source=]'s [=generating authenticator=] determines at creation time whether the [=public key credential source=]
    is allowed to be [=backed up=]. Backup eligibility is signaled in [=authenticator data=]'s [=flags=] along with the current [=backup state=].
    Backup eligibility is a [=credential property=] and is permanent for a given [=public key credential source=].
    A backup eligible [=public key credential source=] is referred to as a <dfn>multi-device credential</dfn> whereas one that is not
    backup eligible is referred to as a <dfn>single-device credential</dfn>. See also [[#sctn-credential-backup]].
```

The detail here is that "Backup eligibility is a credential property and is permanent". 

We can see during registration that this property is checked by:

https://github.com/w3c/webauthn/blob/main/index.bs#L5029

However during assertion the BE property is NOT checked.

This has now lead to Apple's iOS and macOS sending BE=true during registration, but BE=false during subsequent usage of the credential during assertion ceremonies. This is certainly 'an' interpretation of the above sections, but it is ambiguous to other potential readings of the text. For example, my interpretation is that a property being permanent means that the credential will always send BE=true during any ceremony, and that BE=true changing to BE=false is invalid because you can-not "un-backup" a credential.

The primary reason to harden this is that (I think?) Apple plan to upgrade credentials from being BE=false to BE=true, and due to their current design, this WONT be signalled to RP's meaning they miss the ability to make informed choices about this change in properties during assertion.

Additionally it is confusing to an RP today when at registration a *permanent* property is changing between registration and assertion.

So I think that some clarity is needed here that either:

* That the BE flag is persisted by the RP during registration
* That during assertion BE=true/false is consistent to the persisted BE state OR that the RP is allowed to make an informed decision if this value changes.

OR

* The BE flag is registration only, and that it's "permanency" exists due to the RP persisting the BE flag allowing post-reg auditing. 
* That BE will ALWAYS be false in assertions and setting it to true is invalid. The only time you will be aware of a credential being BE=true is during registration. 

Thoughts? 




Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1791 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 30 August 2022 00:43:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 30 August 2022 00:43:51 UTC