Meeting minutes
Tony: Charter?
wseltzer: No update
Tony: Open PRs
… 1693
elundberg: should be straightforward
… think we can merge
JohnBradley: Looks good
agl: Fine
Tony: Merge
Tony: 1663
agl: can't land it yet
matthewmiller: many people's mental model differed from the spec
… PassKeys are elevating that discussion
… uncertainty when DevicePubKey might be supported in clients
tim: original poster has accepted the conclusion elsewhere
… that the spec can't force support
johnbradley: This WG can't do much about the underlying question
… SPWG certification, or vendor conversation
matthewmiller: is it true that spec has never enforced single-device credential?
nsteele: spec makes no statements about it, It talks only about WebAuthn API
johnbradley: out of scope for WebAuthn; might fit in FIDO specs, where there are privacy principles that private key will never leave authenticator boundary
… and could be unclear what the "authenticator boundary" is for software authenticators
elundberg: never in normative language in WebAuthn
… unenforceable but for RPs enforcing attestation requirements
johnbradley: it's outside webauthn
matthewmiller: might we consider adding something in security considerations abuot how the cloud sync model affects security model?
… help correct the mental modeling
johnbradley: the whitepaper and FAQ intended to do that
tim: not limited to cloud, also peer-to-peer sync
johnbradley: don't know we want to get into all the possibilities
… concentrate WebAuthn spec on the client-RP connection
matthewmiller: issues 1691, 1692
… should webauthn expose when used, not block
tim: use cases highlighted there: credential is enrolled; platform configured to allow backup; credential capable of being backed up, not yet backed up
… RP could be instructed to guide user through flow
johnbradley: RP could reject, ask for Device Pub Key in next request
agl: DPK support and flags would launch concurrently with any launch of syncable platform authenticators
akshay: same from Microsoft
Tony: so, 1663
johnbradley: keep the extension, close the issue 1691
Tony: 1576 ongoing
JeffH: keep it open
Tony: 1425
elundberg: keep it open
Tony: Invited Expert application. Any objection?
… hearing none, approved
<nsteele> PR 1690
<nsteele> https://
agl: looks like spam
Tony: close it
Tony: Untriaged issues
… 1692
Akshay: related to backup, sync. What are the possible states
agl: modulo structure (flags/extension), looks great
akshay: thinking flags
… expect to have a more concrete proposal
Tony: we closed 1691
JeffH: should explain: any enforcement of "must support device pub key extension" would be a certification regime, not this WG
Tony: 1681
jeffh: close with "What Ian says should work"
Tony: Any other issues?
johnbradley: Where are on KDF extension?
Akshay: Awaiting charter
johnbradley: we can create the PR and wait to merge
akshay: will do
Tony: Other issues
nsteele: 1683
matthewmiller: working on it with Nick
Tony: You can create the PR
matthewmiller: Can we talk about a potential meeting?
[discussion of possible venues, including alongside RSA or IIW]
Tony: Let's look for potential host alongside RSA
[RSA scheduled June 6-9, SF]
[note that any venue will have vaccination requirements]
Tony: I'll also support meeting at TPAC
[adjourned]