Dan: explainer looks good and detailed and talks about user needs but is quite in depth. Don't seem to have a security and privacy questionnaire response.

Peter: seems more like broad ideas than something that would warrant an s&p

Dan: spend time at the f2f

Hadley: reviewing a comment that came in...

[discussion of sync fabrics]

Tess: regarding e.g. iCloud keychain - Apple doesn't have access to contents of the keychain. Only your devices have access because they're in the same ring of trust.

Hadley: from a user perspective -I have to trust that Apple has done that.

Tess: yes you have to trust the company that built it. Different companies have different ways of demonstrating they are worthy of that trust. Apple makes some kinds of devices available to security researchers. People in in the industry can review that research.

Hadley: makes me wonder if we should recommend to the working group a checklist - if a key sync fabric provider meets these criteria then they can be said to be compliant with the spec. E.g. letting independent researchers have a look.

Tess: yes it would make sense for the working group to have that .. best practices. And notes for auditing. If you're been charged with evaluating .. then you should look at xyz. A little concerned - hard to have the working group require.

Hadley: problem I'm trying to solve: me as a user - i see the web site I want to log into has implemented this new version of webautn and I want to know if I should trust it. I have nothing beyond the reputation of the browser / key syncing company...

Tess: also true for Yubikey...

Yves: if the key is stored in the browser then you have to make sure you're trusting the browser maker.

Dan: browsers should be able to interoperate with multipls 3p sync fabrics?

Hadley: they are talking about the phones...

Tess: you can still use hardware security keys -- but that won't sync across a sync fabric. It's not a replacement - it's an alternative. Some might say "in order to access this you have to have a physical key" - but for the common case - vast majority don't have a hardware key... A feature like this opens up webauthn to be used in a wider context (so it can displace passwords). We should welcome an effort to reduce that threat.

Dan: [raising issues of requests from governemnts to providers of key sync fabric]

Tess: we can't address policy issues.

Hadley: potentially opens up users to ... Feels like we need external credentialling.

Tess: For centralizing - sympathetic - we require our browsers to have 3p architetcure for these things - then a less scrupoulous company implements one - and they use it to snarf up your credentials - now they can impersonate you wherever they want. So there's a concern but remedy might be worse.

Tess: ... or governments.

Hadley: similar issue of using phone OS as credential storage fabric - you still need to trust your phone OS. There are lots of phones out there on old versions of OS or less maintained forks...

Peter: interesting option - you can build a system where you have a hardware key that you use to sign your syncable keys - so the system lets you log in with any key signed by that key. You have your phone and you have your ubikey - once a month you can re-gen the keys but they expire... Device key extension - might be this.

Dan: we can ask them about key sync fabric providers.. we can ask them about device key extension...

Tess: his is a decent overview video btw: https://developer.apple.com/videos/play/wwdc2021/10106/

Hi @agl. We are discussing this in our W3CTAG breakout today.

This has generated an interesting discussion, and we have a couple of questions you may be able to help with.

1. **How safe are sync fabric providers?** We talked through a number of scenarios in which this could fail to protect users: 

* one where the sync fabric provider has access to the credentials themselves and abuses them, 
* one where authorities could serve warrants on sync fabric providers and gain access to all of a user's accounts, and
* one in which an unscrupulous but widely-used site requires that users use their sync fabric to log in — and then they have access to all of that user's accounts. 
  
Have you and the working group considered these types of scenarios? What sort of mitigations might be added to the spec or the ecosystem to protect users from scenarios like these?

2. **Can you say more about device-key extension?** We were intrigued with the protections that come from pairing syncable credentials in a phone or sync fabric to an automatically-generated, device-bound key pair. Would you imagine those keys expiring regularly (monthly or weekly, etc)? And while this clearly mitigates some of the danger to the user (their older credentials would no longer be available, should they be exposed or exfiltrated) — how much damage could still be done if credentials were leaked before they expire? And are there other ways to protect users in this scenario?

Dan: +1 Peter: +1 Tess: +1 Rossen: +1

Dan: I'm looking at the response to Peter's question about private keys on devices.. I don't understand why "most websites would not use this" or how what he describes is different from what you said you thought it was..

Peter: what I was thinking was a system wehre you have a hardware key which is non extractable and a set of softwar ekeys which are syncable and you use the hardware key to countersign the public keys of the syncable keys.

Dan: I think they're thinking about this in terms of keys that are already being synced across some back lane, so the main key is not a hardware based keys, it's a key being synced.. the website that's using it wants to have some additional information about 'you're now authenticated on thsi device and I know this public key is only associated with a private key that's only for this particular device and I have that in addition to the main synced key' - so that would provide some kind of additional 'we haven't seen you on this device before' type thing. The whole thing is based on the idea that the main key is not tied to a specific device

Peter: looks like their extension is you sign in with two keys, neither of which signs the other, but one is tied to a device and one is synced, so you know it's you and you know which device it's coming from. That looks like what they're talking about.

Dan: I do wonder why they think most sites wouldn't use it

Peter: maybe most people wouldn't bother or care

Hadley: worth asking

Dan: [leaves comment]

Peter: the fundamental problem with syncable keys is creating a vector for the keys to leak. What I was describing was you still have a physical key that you only use once every so often, when your other keys expire, to resign all of your syncable keys, but on a daily basis you use your syncable keys. It doesn't rptoect you from being leaked but lets you rotate keys frequently in case they do get leaked, and sites still know who you are because your identity is based on your hardware key

Hadley: and I was asking about the states where....

Yves: key repudiation? I don't know.. can you inform the site a specific key has been compromised?

Peter: is there a mechanism for revoking key like that? Instead of whatever the sites mechanism is?

Yves: replace it with a new key or a repudiation system?

Peter: afaik with sites i"ve used webauth on so far you just log in and replace your key or tell the site you're no longer using that key. I don't know of a platform way. Something where you tell the browser they key is no longer good and the browser tells sites not to use it?

Yves: that would be something

Hadley: like telling your bank you've lost your credit card

Dan: I also asked about the design Peter mentioned. We talked last week about in the larger response from Adam it seems like he's really pushign back on requirements about safety of the key sync fabric as you suggested Hadley and I'm wondering what we ought to do about that

Hadley: I'd think at a bare minimum it would not be inappropriate to lay out in the spec these are dangerous. Not uncommon to do. If memory serves they don't yet have a spec for this. If nothing else, being able to share with implementers we thought through some potential pitfalls or drawbacks - we're sharing with you so you can take stesp to minimise them.

Dan: implementers should be cautious of

Hadley: that's different than coming up with a set of normative statements

Dan: My preference would be to leave that comment, get the feedback on whether they've thought about this alternative design, and try to close the issue based on that? We're pointing out the issues but I don't think anything here is a killer

Hadley: sounds sensible

Dan: the other thing I see, which I appreciate, is that this is a working group proposal, multi stakeholder, the contacts are not just the implementers, this is good

Hadley: and early enough to talk about the design, but also mature enough that there's something to work on

Dan: the group chair is one of the contacts, but is there any controversy about this approach in the WG do we know?

Peter: there are a few things in the explainer we haven't really looked at. Conditional UI.. preventing unintended credential overrides..

Dan: we closed conditional ui review last week. I think that's okay.

Peter: thing that lets the website tell the device a key has been deleted... seems useful. Leave feedback about doing that the other way around? Browser could tell sites?

Thanks for the thorough and thoughtful reply, @agl.

While we appreciate that you aren't keen for the spec to list mitigations or privacy protections on the part of the credential sync fabric providers — which we understand — it is useful to brainstorm them. You, as a working group, will have put more thought and energy into threat modelling than anyone else at this point. It's valuable to capture that.

We'd recommend that you include something in the spec, when you get to drafting it, to share some of this thinking with implementers (even something as simple as "users are trusting credential sync fabric providers to keep their keys secure. While the mechanisms of demonstrating that trust or keeping those credentials secure is out of scope for this spec, we are flagging to implementers that they may need to focus on this problem. Without it, the entire feature won't work."). 

While the implementers may choose to address the issue in different ways, it's still helpful to give them that warning/benefit of your advanced thinking. 

Hadley: they repsonded to a bunch of things. They're opening a bunch of security issues that they don't want to spec out but that they should raise so implementers consider them. They have accepted that and opened an issue of their own on it so I'm happy. But there's other stuff in there.

Rossen: doesn't seem like they've addressed Peter's comment

Peter: more of a suggestion for an alternative approach, not necessarily our job to redesign their features for them

Rossen: is this something we care strongly about to wait for them to get back to us?

Peter: general concerns that if they go to a model where keys are entirely software based, I agree this will make the feature more useful and more people will adopt it, and as soon as there's a major breach the trust will be burned down to the ground.

Dan: worth articulating

Peter: I suggested a hybrid approach... hardware keys would take longer to catch on. My comment isn't a blocker.

Dan: Useful for Hadley to leave the sentence about the thread .. and on this basis happy to close

Hadley: okay