diff --git a/index.bs b/index.bs
index 663a8bc..1134a91 100644
--- a/index.bs
+++ b/index.bs
@@ -141,7 +141,7 @@ spec:css-syntax-3;
mechanisms (submitting credentials via {{XMLHttpRequest}} [[XMLHTTPREQUEST]], for instance) are
difficult to reliably detect, as is the increasingly common case in which users wish to
authenticate themselves using a federated identity provider. Allowing websites to more directly
- interact with the user agent's credential manager would allow the credential manager to be more
+ interact with the user agent's [=credential manager=] would allow the [=credential manager=] to be more
accurate on the one hand, and to assist users with federated sign-in on the other.
These use cases are explored in more detail in [[#use-cases]] and in
@@ -153,7 +153,7 @@ spec:css-syntax-3;
Note: The API defined here is intentionally small and simple: it does not intend to provide
authentication in and of itself, but is limited to providing an interface to the existing
- credential managers implemented by existing user agents. That functionality is valuable
+ [=credential managers=] implemented by existing user agents. That functionality is valuable
right now, without significant effort on the part of either vendors or authors. There's
certainly quite a bit more which could be done, of course. See [[#teh-futur]] for some thoughts
we've punted for now, but which could be explored in future iterations of this API.
@@ -240,6 +240,12 @@ spec:css-syntax-3;
## Infrastructure ## {#core-infrastructure}
+ A credential manager is an application, hardware device, or service
+ that [=credential store|stores=], organizes, manages,
+ and allows [=credential chooser|choosing=] credentials.
+ Example credential managers include [=digital wallets=], password managers,
+ and [=passkey=] managers.
+
User agents MUST internally provide a credential
store, which is a vendor-specific, opaque storage mechanism to record which [=credentials=]
have been [=effective=]. It offers the following capabilities for [=credential=] access and
@@ -2125,7 +2131,7 @@ spec:css-syntax-3;
`false` without [=user mediation=]. For example, the [=credential chooser=] described in
[[#user-mediated-selection]] could have a checkbox which the user could toggle to mark a
credential as available without mediation for the origin, or the user agent could have an
- onboarding process for its credential manager which asked a user for a default setting.
+ onboarding process for its [=credential manager=] which asked a user for a default setting.
3. User agents MUST notify users when credentials are provided to an origin. This could take the
form of an icon in the address bar, or some similar location.
@@ -2260,7 +2266,7 @@ spec:css-syntax-3;
User agents MUST NOT expose the APIs defined here to environments which are not [=secure
contexts=]. User agents might implement autofill mechanisms which store user credentials and fill
sign-in forms on [=potentially trustworthy URL|non-potentially trustworthy URLs=], but those sites cannot
- be trusted to interact directly with the credential manager in any meaningful way, and those sites
+ be trusted to interact directly with the [=credential manager=] in any meaningful way, and those sites
MUST NOT have access to credentials saved in [=secure contexts=].
## Origin Confusion ## {#security-origin-confusion}
@@ -2524,8 +2530,8 @@ spec:css-syntax-3;
This section is non-normative.
- The API defined here does the bare minimum to expose user agent's credential managers to the web,
- and allows the web to help those credential managers understand when federated identity providers
+ The API defined here does the bare minimum to expose user agent's [=credential managers=] to the web,
+ and allows the web to help those [=credential managers=] understand when federated identity providers
are in use. The next logical step will be along the lines sketched in documents like [[WEB-LOGIN]]
(and, to some extent, Mozilla's BrowserID [[BROWSERID]]).