Bbk spec alignment#334
Conversation
|
John - thanks for taking this on! @darwinlyang @pejic - can you review this in my absence? Sorry to dump it on you! |
| 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 |
There was a problem hiding this comment.
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."
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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..
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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.
Co-authored-by: ianbjacobs <ij@w3.org>
SHA: 9d70780 Reason: push, by stephenmcgruer Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9d70780 Reason: push, by stephenmcgruer Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Here's a first pass at aligning the spec with the new BBK requirements document.
Based on changes made for Issue #321
Preview | Diff