Meeting minutes
Microsoft Intro
Tim: We are newly rejoined; our goals are to catch up to start. Juliana has a holistic view ; I will be focused on platform authentication side
Juliana: I have a long history in payments before and at MS
SPC in MDN
Ian: As announced in email, SPC is now part of MDN. Feedback and additions to the content are very welcome. Next steps will be the addition of browser compatibility data (so that, for example, SPC appears in caniuse.com). Perhaps we can gather more data on support for SPC on Windows now that are Microsoft colleagues have rejoined.
Device-bound session credentials
Arnar: I work in the WebAuthn space. I also work on how we do things after sign-in. How do we bind session credentials.
… good contact at Microsoft for DBSC are Kristian Monsen and me.
Arnar: Problem statement is cookie exfiltration.
… Malware that has the same privileges as the browser can see cookies
… Private keys and challenge/response protocols are seen as a way of improving this.
… question is how to establish and use credentials. Our focus with DBSC is to establish and use credentials (not the creation/storage of private keys). For creation and storage of private keys, the browser will offload that to the OS, and the plan is to use existing TPMs and other mechanisms with a protocol.
Arnar: Several things make this project difficult: Key protection from malware, deployment and migration, complexity, API and protocol design
… in previous attempts to find solutions to this problem we've seen the deployment part is hard to do -- modifying a bunch of code all at once is difficult.
… in particular, the slowness of underlying key protection means we cannot practically sign every request.
… DBSC does not say how keys are protected (implementation detail)
… what is in scope is to allow in the protocol flexibility for frequency of requiring signatures.
… we also want a protocol that supports improvements over time.
Arnar: Regarding the deployment challenge:
… even simple websites can be complex.
… when to require signatures can be part of business work, but lots of work.
… web stacks are complex and authentication is cross-cutting. Want the new protocol to be close to where session management happens
… there is also authentication middleware in multiple places, in some cases using off the shelf libraries So what's difficult but in scope for DBSC: a way to get binding without rewriting business logic or migrating stacks.
[Overview]
* Explicit represents the "session" concept.
* New functionality on website is "add-on" not a rewrite.
* Periodic key proofs
* Browser manages when to send proofs
* Browser can HOLD other requests when proof is needed
* Reset of the website stays on cookies, but short-lived
… the web site decides the period of key proofs it wants. But the browser decides when to send proofs
… browser queues requests its receives until proofs have been exchanged.
… cookies go from "long-lived" to "short-lived"
… e.g., 10 minutes
[Making sessions explicit]
Arnar: Today I'll show how this could work using a JavaScript approach, but there might be other approaches such as HTTP headers
Arnar: "Session" does not necessarily mean "user has signed in" though that might be a common use case for establishing a session. An example of another potential use case for establishing a session: "user adds something to a shopping cart."
Nick: Is there UX to indicate to the user that a secure session is in progress?
Arnar: Not in our proposal
… DBSC happens in the background like cookies
… but at the same time, where the user can manage cookies they should be able to manage sessions (e.g., remove them)
… there might be more obvious signals in some contexts, like dev tools, for example.
Gustavo: Is it fair to say the browser would not be put to sleep if the user leaves the browser for another app?
Arnar: The session can remain active if the browser is off. However, sessions do not add anything regarding outreach to servers unless the user is making requests (and thus interacting within the session)
[diagram of current world where cookies are set, with long-term cookies
Arnar: Today, you typically sign in once and the server consults cookies
… with DBSC, the typical flow will involve the user signing in, and the server starting a session.
… the browser will generate keys, talk to the OS, request signatures, etc.
… the browser will reach out to an endpoint (managed by the site's server and involving a new protocol) for binding verifications and short-term credential issuance.
… the design goal is that the web site otherwise works the same and relies on cookies, but those cookies are now valid for only short periods.
[Periodic key proofs]
(Arnar walks through the protocol showing how a session is initiated, a key pair is generated, and credential request is sent.)
Arnar: Site can also provide a set of constraints for what must hold for the session to remain active. Right now the constraints are limited to "the following cookies must be present."
Arnar: During ordinary site functioning, if the browser encounters an expired cookie, for example, it reaches out to the end point to refresh cookies (and/or get new instructions).
… first the server asks for a challenge (to sign)
… the browser sends the session id that was established when the session was initialized along with all the cookies it knows.
… The browser gets back a challenge then sends a second request to the server including a JWT signed with a key and the server's challenge to prove it's the same browser
… the server responds with new instances of (short-term) cookies.
… in those responses, the server can change lifetimes of cookies (e.g., based on risk analysis)
Arnar: There are only session refreshes if new requests are made. The browser doesn't do this on it's own.
… however, there's a latency issue potentially due to outreach to server.
… by default with DBSC, the browser queues requests until the refresh endpoint has replied.
… this reduces server-side effort to migrate to this approach, but it does introduce latency (time to wait for server, do signatures, etc.)
… browsers can make this ALMOST invisible, e.g., by saying "if there have been requests within the last minute, that means the user is active....since this cookie expires in 10 seconds, I'll go talk to the session end point PROACTIVELY to refresh it."
… this will help reduce visible latency other than opening the browser the first time.
… also this means that a single refresh can service many cookies
IJ: How could this be useful for payments?
Arnar: This is a fairly low-level tool we are developing. We expect this to be useful in general for many things. DBSC could force malware to behave differently; the constraints on them will make them more detectable (both on client and server side)
… session exfiltration is often used to reuse stolen cookies to evade detection.
JeanLuc: Thank you for the presentation. If site sets a cookie, does browser refresh?
Arnar: Yes.
JeanLuc: Is it possible for a server to do an "on demand" request for information about the session if private key is still available?
Arnar: We have talked about this a lot: "on-demand signatures." There is a way to get that. … "I want a signature now."
… the server can force expire the cookie (expiry set to past)
… this will force the browser to hold cookies and do a refresh.
… we also have sketches for other approaches (e.g., HTTP headers)
… we are interested in concrete use cases for that.
JeanLuc: I have a concrete 3DS example. The first action the merchant does is called the 3DS Method.
… merchant sends identifier to the bank, and in an iframe the bank performs device recognition. If the bank has access to the broader context, can the bank check to see if the private key is still present?
Arnar: This would be a private key tied to the bank?
JeanLuc: Yes
Arnar: It should be possible.
Arnar: We definitely have more direct ways to do this, with e.g., response headers: "On the next request I want a signature"
… we are wondering whether to include such a feature in the MVP because it might be more complex.
Ian: I suggest JeanLuc reaches out to Arnar.
<sameert> +1 to hearing more about the use-case Jean Luc defined for 3ds
Rolf: The boundary of a web application is more weakly defined than for a native app. Did you think about conveying the boundary of the web application (e.g., a hash of code) as part of signature back to server so that the server knows whether this is the legitimate application?
Arnar: We didn't really think about that (the integrity of the web application itself).
… that was not exactly our use case. We were thinking about malware post registration (that steals cookies)
Rolf: Integrity check could prevent against malicious javascript.
Arnar: That is interesting; we'd have to think about whether this fits in this API.
Rolf: This would nicely fit, IMO. And would allow more parity with web applications.
Arnar: Cf the Web Environment Integrity Proposal. Note that Web Env. Integrity was strongly opposed due to DRM concerns.
… we've intentionally left some gaps in DBSC for potential integration with other protocols like DBSC
Rolf: Session transfer among devices is increasingly common. How would DBSC work in these transfers, and how would server understand what's happening?
Arnar: I think we can get a lot of protection with a simple initial proposal. But there should be extensions possible (e.g., to make it easy to change devices, or to get attestations). Session transfer would complicate DBSC.
… we want to confirm basic concept first.
Rolf: Looking at the JS API...for malicious JS code it's easy to overload these things.
… code could emulate functionality in a malicious way.
Arnar: We will look at the situation of compromised apps...and we'll also talk more about Headers.
IJ: Why is this different from previous requests for globally unique identifiers?
Arnar: There's nothing you can convey with DBSC that can't already be conveyed. But we need to do more regarding 3p frames.
… there might need to be constraints, like requests in a 3p context won't trigger a refresh.
<Zakim> nicktr, you wanted to ask about iframe behaviour
JeanLuc: As long as the platform owns the private key, could this functionality be cross-browser?
Arnar: No
… this is scoped like cookies
Chrome response to SPC feedback
smcgruer_[EST]: We can take to 1 February
NickTR: Any teaser?
smcgruer_[EST]: We hope to have a UX person looking at SPC in Q1. We are definitely looking at that.
Next meeting
1 February 2024
[Adjourned]