Hadley: Why can't keys be exported from device?

Jeffrey: by default they want to use a Trusted Platform Module (TPM) but not everything has one. This API ca be implemented by something that doesn't have it. If you have a TPM you get stronger guarantees than if you don't. Evenif you don't have one .. the browser does its best attempt at making the key non extractable. Sticks it in whatever the OS provides, maybe can be pinned to the application. If you ahve the extra assurance then you get it.

Hadley: better than status quo but.. good enough? Second question.. in goals, first sentence explains the threat model. My assumption had been that the threat model is that the cookie is removed to another device and used nefariously. The goal in that pagraph is they're concerned about an attacker tampering with the UA, browser memory, secrets on disk

Jeffrey: if you have an attacker that can mess with the ua they can copy the cookie and take it somewhere else. Even if you clean your local machine they still have the cookie

Hadley: that's the threat model I thought.. but they don't say anything about cookies removed from the device

Jeffrey: I think that's what they mean by cookie theft.. but they don't define that. I think tha'ts what they mean.

Lola: essentially tmp bound to the device is acting as the authenticator. THe TPM can have multiple session keys? Each session has a key. It's a one-to-many relationship between a session and a TPM?

Jeffrey: yes. Two kinds of sessions here... you log into your website and store your public key with them and that private key sits i nthe tpm, is not extractable. There's potentially a very long session with that private key. A whole bunch of short sessions where you can ask for a short lived cookie from them. Sign a rqeust with the private key, get the short lived cookie backand use that for actual website interaction. It expires and you have to get a new one.

Lola: are there specific concerns you have about this?

Jeffrey: two angles. One that Hadley was poking at - not everyone has a TPM. I believe they're plannign to provide the api even for the people without the TPMs. THe guarantees only apply to people with TPMs. Is this actually going to be able to improve the ecosystem? Google wants to use this to get better assurance for everyone. Google already does generally good things with session lengths. WHat I'd like is for the banks to accept longer sessions. Is there any prospect of this api improvig that? We should try to help the users.

Lola: How does this benefit the user? Understand the bank thing... but people will be fine. What is the benefit to the user of this specific thing aside from the security thing? Or is this mainly addressing it from the security perspective and there is no tangiable benefit to the user?

Jeffrey: it's entirely a security feature. If you run malware and they steal your cookies and you clean your machine, can they still use the cookies? Right now they can, and after this they can't.

Sarven: what's specified? The API between the browser and the TPM?

Jeffrey: between the browser and the server.

Lola: in the first section it says that it offers an api for websites to control the lifetime. This also has a protocol for periodically and automatically providing possession of the cookies to the webistes. It's addressing two things to solve the one problem?

Jeffrey: I'm not sure I Like that division of the two bits. I think of this as the website can register a private key with the server, between the browser and the server, and theyc an use that to issue cookies, which guard general interactions with the server. You get the higher assurance of a private key and the convenience of cookies. Server frameworks are written assuming you use cookies to authenticate, this allows that same pattern.

... The other angle we should think about is whether this could be better integrated with webauthn which is the other api that allows you to authenticate to a server with a private key.

Lola: been xplored?

Jeffrey: talked to them. THey don't think it fits. Webauthn is a js api not an http api. To do most authentication you need something to put it down to the http layer .Second, the webauthn in browsers now calls down to os apis which never implemented the silent mediation option in credential management. If you call the OS api it's always goign to ask the user to confirm. You want a silent confirmation that you still have the key. Martin seems to strongly think and I kinda think we should just fix the OS APIs. But it's true that's a heavy lift. We can't just do that in browsers and it will take a lot longer than shipping this.

Amy: why not both? is this an interim solution?

Jeffrey: don't know. Don't see an immediate path for retrofitting it.. if you get silent mediation instead of asking the TPM you could ask the webauthn key. Probably works the same way. That might be a good answer to my second question. Overall API seems relatively sensible to me. Maybe not phrased the same way as if you were thinking about it as exposing web authn to the http layer, but it works fine. Getting cookie refresh to work better just helps users on its own. If a website is using this t would never have to bounce through a reauth page.

Lola: comes back to how long the session is. Not having to keep reauthenticating that is a benefit to the user.

Hadley: unconvinced it's worth the disruption. Not sure that's a TAG position. GIven that it doesn't cover all users, and some of the reason to do this is regulatory. Regulatory is likely to be if it's not going to cover everybody assume it's not there at all.

Jeffrey: maybe only provide the API when it's useful for assurance. When a bank tries to use this api and it fails, they know they have to reauth all the time. If it is presence they can trust the user has the higher protection for their keys and therefore can have a longer session.

Sarven: transition to a higher secure channel? They said it's widely deployed..

Jeffrey: they also say 60%..

Sarven: assuming everyone is going to have this possiblity, you can migrate away reauthing the session frquently.

Jeffrey: if everyone gets some sort of hardware key protection, which seems like a good thing for hardware to start having, eventually maybe everyone can use this. Nice because it doesn't have attestation. A UA that .. in the long term when 99% of users have a TPM and websites start being written to require this instead of use it when it's there UAs can also implement it without a TPM. WE're not going to build a world where some users are excluded assuming UAs have that work around.

Amy: something device obselescence something something

Jeffrey: reason to do the emulation now. Banks will not trust this enough to give longer sessions. Is this a regulatory thing, or just banks not understanding web security

Hadley: Both. Heavy layer of this kind of regulation that came out of the subprime mortgate mess. The regulatory response int he uk and us was okay banks we gave you too much rope and you hung yourselves, we've got to steop in and supervise more. Also strong motiation for banks to limit their own liability in how much fraud they're exposed to as they lose money. US regulator moves a whole lot more slowly than the UK regulator. THe ways in which those things are expressed is different. Other jurisdictions are available.

rant about banks

Hadley: different kinds of login. Once i"m through the initial attaching login credentials to my account which requires all of this, then it's just a 2f username and password login process. IF you're setting up a transaction...

more bank ranting

Hadley: more fraud built in to US banking system..

Lola: if this is implemented in all browsers widely, do developers need to do anything different to make it work?

Jeffrey: they need to implement this endpoint that sets things up and does the refresh. They have to kick it off in the first place somehow. Return this session registration (JWT). Their average page is not goign to have to change because of the short length cookies. And they can probably simplify their site a little bit because they can kind of guarantee those cookies are around. You're not in the middle of asssion going to lose them, it's automatically refreshed.

Sarven: doesn't expand on same origin policy..

Jeffrey: question is whether the cookie it sets can be wider scoped than one origin

Sarven: they are only limiting to same origin?

Jeffrey: I see a *.example.com which makes me think it's not just a normal cookie.. in scope specifications json... not sure that it actually allows wider scope than origins

Lola: apparently MS are also developing something similar. I don't know if they've submitted for diesgn review. The demonstrating proof of possession in the browser application. This was feedback given by mozilla as part of their standards position. There isn't any comment to say whether or not the editors of this spec have considered..

Jeffrey: there is a reply on the mozilla one saying microsoft moved it to be part of DBSC

Lola: the microsoft explainer still has issues on it within the last week. If they've done that that's fine.

... Is it worth trying to get Apple's perspective? There's a response to Apple's concerns about making the device backup worse. They have questions. When we are doing a design review do we need the other orgs to have their positions already? Do we wait?

Hadley: we're largely giving our opinion

Lola: I'd like to know what Apple thinks in response to this person's reply

Hadley: it is useful to know if there's little support from other implementers

Lola: ask how they are thinking about devices without TPM, or users who do not have access to devices with a TPM.

Jeffrey: how does this benefit the average site, as opposed to the large sites with big security teams. Are we mixed on whether this is good overall?

Lola: I think overall it's a good API. Concernes are .. just because it's good don't know if it should be implemented just yet.

... Is there a scenario where the TPM accidentally loses access to the private keys?

Jeffrey: filling up and dropping oldest stuff? I don't think they do that. If it did you'd just have to log in again.

... We could make the comment that we don't think the concern about backups is a real worry. Okay to log in again if you restore from backup.

Hadley: from a user perspective that's not unreasonable

Lola: if I'm restoring a new device I don't want to it to know about me until I tell it

resume bank ranting

We appreciate the plan to improve first-party authentication by using high-security private keys as the main long-lived session credential with short-lived auto-refreshed cookies to help existing server frameworks work as-is.

How are you thinking about devices that don't have TPMs? We are aware that this might be useful in regulated environments like banking. What are the chances that banks could use this to lengthen their reauthentication timeouts? Are there any design changes you could make to improve that chance?

We think that expecting users to reauthenticate after restoring a device seems acceptable in this case.

Can you explain how this could migrate to using keys from WebAuthn's Silent Mediation, if that is ever implemented in operating systems.

Martin: no action this week.

bumped

• Include suggestions to help spec authors understand TAG's mindset
• lolaodelola to update comment to include suggestions

Lola: They replied, but I didn't yet have time to read it Hadley: Did the others do? … does not look like it … let's talk about this next week

Wait for Martin and Lola.

They replied 2 weeks ago. Martin to try to find time to draft a comment; falling back to Jeffrey attempting next week.

(Martin) Propose that we share the proposed analysis: https://docs.google.com/document/d/1EU9jsh07pci6Cgk9Bh0oUM0dAajZdxBg9OclXiEAizw/edit?usp=sharing

Lola: based on Martin's analysis doc we are probably saying "no" - I have some questions to Martin's doc that I left in Slack...

Martin: i agree with the structure... allows web sites to determine how often they need to validate signatures...

Lola: next step for this it draft a response.

Martin: should I just throw this up on a gist so it's it's own stand-alone doc?

Dan: suggest a markdown file in the reviews repo...

Hadley: do we need any more consensus or approvals across the board for what Martin's posting? A document seems like a more formal statement from the TAG.

Martin: I can put up a PR and people can weigh in. but I don't think it's one of those ones where it's contraversial.

Hadley: please explain also what issue it's for and what the deadline is...

Martin: OK. Propose that once the PR is merged then we have TAG consensus -- and then done for now. If they come back with changes we can re-open the issue.

Explainer: https://github.com/w3c/webappsec-dbsc/blob/main/README.md

Went through new examples in alternative:

https://docs.google.com/document/d/1EU9jsh07pci6Cgk9Bh0oUM0dAajZdxBg9OclXiEAizw/edit?usp=sharing

Goal was to have the browser pick up a new protocol for getting refreshed cookies.

Jeffrey: might have an even even simpler alternative than this one. We only want Accept-Signature for some paths, so that you don't sign requests for every resource on a site. If we had a second layer that said, sign expired cookies. Don't want to suggest that without working it out. We can still tell them to take advantage of signatures.

Martin: Cookie expiration doesn't give sites the certainty they need about when the browser needs to act. Can't use the clock to get that.

Jeffrey: Yes, clock skew will make it hard to use cookie expiration.

Dan: will take a look again; seemed OK in the past.

Martin: waiting on jeffrey for this one… or any feedback from Lola… Jeffrey indicated he was half way through… I’m happier with the design. Others might disagree. Comment should be “the design is useful and holding keys in a TEM might be a good approach…” Integration with http could be better.

Lola: nothing to add… agree to wait for jeffrey’s feedback.

we will touch on this at the plenary and check status with Jeffrey

Martin: waiting on jeffrey for this one… or any feedback from Lola… Jeffrey indicated he was half way through… I’m happier with the design. Others might disagree. Comment should be “the design is useful and holding keys in a TEM might be a good approach…” Integration with http could be better.

Lola: nothing to add… agree to wait for jeffrey’s feedback.

we will touch on this at the plenary and check status with Jeffrey

(see below)

• design-reviews#1094: Device-Bound Session Credentials Analysis - @martinthomson, @jyasskin, @lolaodelola

Jeffrey: This got a reply from the proponents; feel it's a question for Martin mostly. Anyone else watching?

Lola: +1 seems for Martin

Jeffrey: Bumping to next session. My summary is that Martin's suggestion is to use cookies and sign the cookies, and he shows ways to get back all the features that the DBSC has, but at least his servver-side picture looks more complex than what is being proposed. However I and the proponents don't seem to be convinced.

Lola: How would we resolve something like that?

Jeffrey: We don't have to agree with the proponents; if the TAG thinks there's a better way to do it, and the proponents are not convinced, we resolve as unsatisfied. If there's not consensus in TAG, then we say that. There's a resolution label for that. (There's 'ambivolent' and 'lack of consensus' so we can pick whichever is best.)

Jeffrey: Martin and the proponents have a considered disagreement.

Martin: They're overstating their case, and I'm probably overstating mine. I didn't find their arguments persuasive.

...

Jeffrey: Maybe we can ask them which other services they're working with, besides Google, to justify the need to reduce server complexity.

Martin: Previous attempts were at the TLS layer, which required a lot more infrastructure change. Not sure if there are lessons that carry over.

Jeffrey: Maybe the conclusion is just that they need ot operate at the HTTP layer, but that doesn't decide between the proponents' and Martin's suggestion.

Martin: I realize that perhaps Google people, who have already shipped on both ends, would have some attachment to what they shipped and so might be biased. Perhaps we can find someone else who operates a service to offer their insights into how this might work for them.

...: The proposed architecture would not be acceptable for Mozilla to ship (too high a complexity cost for the value) unless we could be convinced that there was a significant benefit for server operators.

Jeffrey: Let's ask that.

Martin: Don't want selection bias.

Jeffrey: Google people are supposed to gather feedback during origin trials.

Martin: But they won't get feedback on alternatives.

Jeffrey: Maybe this is something for the webappsec agenda and gather alternatives.

History in https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1052.

Jeffrey: I think the next action is for Martin to write a comment. Last meeting's discussion indicated that they should bring this up with WebAppSec and prove that it's useful beyond just Google.