Device Bound Session Credentials Cross-Site Key Sharing

Hello,

Google is trying to work through how Device Bound Session Credentials
(DBSC) can protect multiple sites run by one party which use a federated
login based on link decoration. This has a similar motivation to
WebAuthn's related
origin requests <https://w3c.github.io/webauthn/#sctn-related-origins>
(e.g. protect example.co.uk despite login happening on example.com). I had
wanted to discuss this at the May 21 meeting but given that meeting was
cancelled I figured I would see what we can resolve by email.

We would propose to let a Relying Party (RP) use the same key as a Session
Provider (SP, usually called IdP for federated login but DBSC isn't
necessarily about login), so that trust in the security of the RP session
is exactly the same as trust in the security of the SP session. This is
triggered by the RP including extra information in the registration header:

   - The identity of the SP session
   - The public key of the SP session

We will place a very low quota on the number of such requests a single site
can make (something like 3 attempts before a long backoff). We believe the
privacy costs of this sharing are minimal because it requires the SP and RP
to already share a good guess of a high-entropy identifier, the public key
itself.

We still plan to limit the damage of successful key guessing by using
.well-known files similar to WebAuthn or Related Website Sets which will
make it hard to propagate successful guesses across many sites.

Full details are available in the spec here
<https://w3c.github.io/webappsec-dbsc/#federated-sessions> and here
<https://w3c.github.io/webappsec-dbsc/#algo-create-session-key>. The main
thing I'm looking for feedback on is:

   - Do others agree this kind of cross-site data sharing is low-risk?
   - Would other user agent implementers be inclined to put this behind a
   permission prompt? We believe that it's difficult to explain to users the
   tradeoff between "these two sites already have a good guess who you are,
   but you'd be confirming it" and "extra protections against cookie theft",
   and worry about the adoption cost of confusing UX at login time.

Thanks,
Dan Rubery