Skip to content

Bbk spec alignment#334

Merged
stephenmcgruer merged 7 commits into
w3c:mainfrom
John-Earnshaw:bbk-spec-alignment
Jul 2, 2026
Merged

Bbk spec alignment#334
stephenmcgruer merged 7 commits into
w3c:mainfrom
John-Earnshaw:bbk-spec-alignment

Conversation

@John-Earnshaw

@John-Earnshaw John-Earnshaw commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Here's a first pass at aligning the spec with the new BBK requirements document.
Based on changes made for Issue #321


Preview | Diff

@stephenmcgruer

Copy link
Copy Markdown
Collaborator

John - thanks for taking this on!

@darwinlyang @pejic - can you review this in my absence? Sorry to dump it on you!

Comment thread spec.bs
This is an internal component owned by the [=user agent=] that manages
platform-dependant cryptographic key pairs including their association to [=SPC
credentials=] (i.e. passkeys). This section explains the <dfn>browser bound key
credentials=] (i.e. passkeys). Each browser bound key store is owned by a single

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is confusing because the previous sentence mentions that the BBK store is owned by the user agent. Although currently the user agents for BBK stores are only web browsers, I think we probably want to keep it as user agent to not limit the definition.

To add the change about multiple profiles, it would make more sense to phrase it like "For example, if the user agent is a web browser with profiles, a browser bound key store may be created for each profile."

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The browser bound key store is owned by the user agent, and the definition of user agent includes profiles. So merely following these procedures implies a user on a different device would be considered a separate user agent with a separate browser bound key store. I am unsure whether a negative statement (i.e. "do not sync the private key to another device") could be coded into the SPC procedures. None the less, the clarification from our requirements doc could be part of the new note below.

If we have additional security considers then we may need a statement in the security considerations. For example, the device bound session credentials spec mentions user agent responsibilities for protecting private keys in the security considerations section.

For reference here is the definition of user agent:

A user agent is any software entity that acts on behalf of a user, for example by retrieving and rendering web content and facilitating end user interaction with it. In specifications using the Infra Standard, the user agent is generally an instance of the client software that implements the specification. The client software itself is known as an implementation. A person can use many different user agents in their day-to-day life, including by configuring an implementation to act as several user agents at once, for example by using multiple profiles or the implementation’s private browsing mode.

The DBSC security considerations:

The goals of DBSC are to reduce session theft by offering an alternative to long-lived cookie bearer tokens and to allow session authentication to be based on private keys that can be better protected against exfiltration. This makes the internet safer for users in that it is less likely their identity is abused, as malware is forced to act locally and thus becomes easier to detect and mitigate.
User agent implementations are responsible for selecting the best way to protect such private keys from exfiltration, taking into account types of malware threats that exist on different platforms, and the protection mechanisms that exist. That includes, but is not limited to, secure hardware such as TPMs or secure elements, OS provided APIs for secure key generation and management, or process isolation mechanisms that provide reasonable protection against locally running malware.

As long as the session is valid and was registered to an uncompromised device, a host can thus know with cryptographic certainty that the session key is protected against malicious exfiltration to a different device.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is confusing because the previous sentence mentions that the BBK store is owned by the user agent. Although currently the user agents for BBK stores are only web browsers, I think we probably want to keep it as user agent to not limit the definition.

To add the change about multiple profiles, it would make more sense to phrase it like "For example, if the user agent is a web browser with profiles, a browser bound key store may be created for each profile."

Good spot, those sentences don't match.
Given our recent updates to the BBK requirements, should we not use "installed browser program" in both sentences to be consistent with the requirements doc?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally think we should keep "user agent" as it's used throughout the rest of the SPC spec and to keep things open to other types of user agents in the future but maybe it's looking too far into the future.

@ianbjacobs, what are your thoughts on this?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a definition of installed browser program, combining user agent and device, serve to bridge the gap between the requirements doc and the spec?

Then this section would always reference installed browser program instead of user agent directly.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should use "user agent" generally. We could put an informative note in the BBK section that says (roughly): because the first implementation of this feature was in a browser, we called it BBK, but that is not meant to imply that it could not be used in other user agents that implement SPC. Furthermore, we talk about "installed browser programs" because we are focused on the current implementation in browsers..

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've aligned the terms to all be "user agent". To clarify things I have added a note on the use of the word "browser" in the definition for BBK, and I have explained the gap in terminology in the note that links to the BBK requirements.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks John! For the line:

Each browser bound key store is owned by a single user agent, binding it to both the device and the browser.

I think it would be better to be more clear that the binding is a result of the store being owned by the user agent:

Each browser bound key store is owned by a single user agent which binds it to both the device and the browser.

Comment thread spec.bs Outdated
Comment thread spec.bs
This is an internal component owned by the [=user agent=] that manages
platform-dependant cryptographic key pairs including their association to [=SPC
credentials=] (i.e. passkeys). This section explains the <dfn>browser bound key
credentials=] (i.e. passkeys). Each browser bound key store is owned by a single

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The browser bound key store is owned by the user agent, and the definition of user agent includes profiles. So merely following these procedures implies a user on a different device would be considered a separate user agent with a separate browser bound key store. I am unsure whether a negative statement (i.e. "do not sync the private key to another device") could be coded into the SPC procedures. None the less, the clarification from our requirements doc could be part of the new note below.

If we have additional security considers then we may need a statement in the security considerations. For example, the device bound session credentials spec mentions user agent responsibilities for protecting private keys in the security considerations section.

For reference here is the definition of user agent:

A user agent is any software entity that acts on behalf of a user, for example by retrieving and rendering web content and facilitating end user interaction with it. In specifications using the Infra Standard, the user agent is generally an instance of the client software that implements the specification. The client software itself is known as an implementation. A person can use many different user agents in their day-to-day life, including by configuring an implementation to act as several user agents at once, for example by using multiple profiles or the implementation’s private browsing mode.

The DBSC security considerations:

The goals of DBSC are to reduce session theft by offering an alternative to long-lived cookie bearer tokens and to allow session authentication to be based on private keys that can be better protected against exfiltration. This makes the internet safer for users in that it is less likely their identity is abused, as malware is forced to act locally and thus becomes easier to detect and mitigate.
User agent implementations are responsible for selecting the best way to protect such private keys from exfiltration, taking into account types of malware threats that exist on different platforms, and the protection mechanisms that exist. That includes, but is not limited to, secure hardware such as TPMs or secure elements, OS provided APIs for secure key generation and management, or process isolation mechanisms that provide reasonable protection against locally running malware.

As long as the session is valid and was registered to an uncompromised device, a host can thus know with cryptographic certainty that the session key is protected against malicious exfiltration to a different device.

Comment thread spec.bs Outdated
Comment thread spec.bs
This is an internal component owned by the [=user agent=] that manages
platform-dependant cryptographic key pairs including their association to [=SPC
credentials=] (i.e. passkeys). This section explains the <dfn>browser bound key
credentials=] (i.e. passkeys). Each browser bound key store is owned by a single

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks John! For the line:

Each browser bound key store is owned by a single user agent, binding it to both the device and the browser.

I think it would be better to be more clear that the binding is a result of the store being owned by the user agent:

Each browser bound key store is owned by a single user agent which binds it to both the device and the browser.

@pejic pejic left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephenmcgruer stephenmcgruer merged commit 9d70780 into w3c:main Jul 2, 2026
3 checks passed
github-actions Bot added a commit that referenced this pull request Jul 2, 2026
SHA: 9d70780
Reason: push, by stephenmcgruer

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
github-actions Bot added a commit that referenced this pull request Jul 2, 2026
SHA: 9d70780
Reason: push, by stephenmcgruer

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants