Consider Renaming "Device Bound Session Credentials" for Clarity

[kkoiwai]

The term "Device-Bound Session Credentials" (DBSC) in the documentation is misleading, as the protocol does not strictly enforce hardware-backed device binding. The current name implies a strong guarantee of cryptographic binding to a specific device’s hardware (e.g., TPM/SE), but the specification allows implementations where keys are software-backed or synced across devices.

Since the protocol itself does not use the term "DBSC" in APIs or technical structures except in the jwt header, renaming is low-risk.

The current name creates a risk of developers incorrectly assuming DBSC credentials are irrevocably tied to hardware, leading to overconfidence in session security.
As an anecdote, I once encountered a developer of a browser-based crypto wallet at the Internet Identity Workshop a few years ago. They claimed their wallet app was safe because it was protected by a device-bound credential, but in reality, the app was just using WebAuthn with no attestation.

cf: WebKit/standards-positions#281 (comment)

[drubery]

I'm personally open to this. Chrome is currently strongly device-bound, but we do not require that all user agents do that or even that we'll continue to do that forever. Plus "Secure Session Credentials" would have a nice alignment with our headers starting with "Secure-Session-".

We're a little worried about doing a rename during the Chrome Origin Trial since we've been reaching out to people calling the feature DBSC. But before we do a full launch, I'll get a consensus or objections from within Google and follow up here.