Meeting minutes
Roaming authenticators and SPC
stephen: At a high level, when the group designed SPC, a core goal was to avoid "cannot proceed" states.
… this is a known problem in WebAuthn land, where the user can't proceed with authentication but they are still staring at some UX
… this comes from two reasons (1) privacy model, which leads to always seeing some UX to avoid timing attacks, and (2) roaming authenticators that may be available but not immediately
… in SPC we endeavored to address this through two mechanisms: (1) silent query for authenticator existence is the first.
… we thought this would exist due to capabilities like conditional UI.
… but there are platforms where the browser cannot query for credential existence.
… e.g., authenticators decline credman to do silent queries.
… (2) a second ability was the ability to silently check if an credential is usable with SPC (via the FIDO-defined bit). But that info is in practice often stored in the browser.
… so we find ourselves in a situation where roaming authenticators cannot be used with SPC as SPC is designed.
… I have some ideas to address this.
… approach one is to support roaming authenticators when they are used and then to cache those credentials. It's possible but not implemented today.
… if we had such a cache, we could recognize both cached and any actually connected authenticators.
… there are always issues with caches, of course.
… a second approach would be to redesign SPC, but we'd have to accept then that we cannot avoid failure states. But that's already true today (which is why we have the fallback dialog)
… so the beginnings of proposal would look like this:
1) Update the fallback dialog to allow the user to choose a passkey; an escape hatch for a user choice to use a phone or hardware key or some other authenticator
2) Allow the caller to indicate a preference for streamlining the authentication, which would basically mean not handling roaming authenticators. But the caller could also indicate a preference for including roaming authenticators even if that means more UX.
… for example there could be a boolean as input to express a preference
Tim_Cappalli: The idea of cached credentials was why we did "linked security keys"...but it's not really implemented.
… we can't assume users will have hardware keys plugged in
Bjorn: +1 to Tim's comments
… I agree with Stephen, having a safety valve in the fallback UX sounds like a good approach
Stephen: We're not opposed to having a caching layer (though not a small feat). But it's not high on the priority list today on the implementation side for our WebAuthn team; but they're happy for different parts of Chrome to implement it if they put the work in.
Ian: Any thoughts from people on the idea of a preference to not show / show more UX? Are there any use cases people have in mind where they'd really like to be sure roaming authenticators will be included?
Ryan: I think we would want to be able to say "we prefer immediately available authenticators"
Stephen: Cached credentials could be seen as same level as other immediately available authenticators, but that may be a naive assumption. Are there any use cases where people would say "Never want a roaming authenticator"?
Albert: How does this differ from immediate mediation?
Stephen: It would be a similar functionality (Immediate mediation is now called Immediate UI Mode)
… but immediate mediation is somewhat controversial
… immediate mediation in webauthn only works if you specify no credential ids; but that's the opposite with SPC.
… that was to reduce probing ability.
… with immediate mediation the call fails when no credentials...
… if we had a version of SPC without credential IDs, we may not be able to allow 3p use cases.
Tim_Cappalli: I'm working on a related proposal with a larger range of UI modes, but allow site to continue even when user does not choose an authenticator
Albert: I see an advantage of having several different UI modes if passkey is not immediately available.
Ian: Any other WebAuthn activities around this?
Tim: No, not really.
Stephen: I will likely create a markdown proposal and link to it from issue 12.
Definition of third party in SPC
w3c/
Stephen: Nina Satragno suggests we try to align with WebAuthn.
… there is capability in WebAuthn to detect and ignore invalid subdomains.
Ian: Should a parent be able to use a credential of a subdomain?
DavidBenoit: TLD should be able to delegate which subdomain is the issuer for the TLD. I want to be sure we don't introduce the possibility of some subdomain issuing tokens for a TLD without permission.
Ian: How complex to align SPC with WebAuthn?
Stephen: Should not be complicated.
… I think that the code may already do this.
… but not a high priority to do a pull request on the spec.
Ian: Let's record in the issue support for doing this and come back to it when people have more time.
<stephen_mcgruer> +1
TPAC registration open
https://
EARLY BIRD FEE DEADLINE: 7 August. For more about registration fees, see:
ECommerce/AI Workshop agenda
Next meeting
13 August
Can 3p bit be optional for third-parties?
Albert: Would it be possible to allow different origins to use an RP's credential for SPC even if the bit is not set? What concerns are raised by making the 3p bit optional?
Stephen: I don't think it can be optional for 3p. We heard strongly at the time we created this that people could do association attacks.
… if you don't have a 3p bit, then people could do SPC calls for other origins and it's implied that "domain A" is working with "domain B", even if that's not true.
… to continue discussion, it would be good to understand the underlying use case.
Ian: Remind me whether 1ps can use credentials without bits?
Stephen: In theory, yes. I think there are implementation bugs. I think it works in some contexts but bugs in some contexts.
… let us know if people need this to be fixed.