Skip to content

Commit

Permalink
Change "will" to "will likely".
Browse files Browse the repository at this point in the history
(Addressing Tim's comment.)
  • Loading branch information
Adam Langley committed Oct 25, 2023
1 parent f5ea861 commit 24dd8e9
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -7099,7 +7099,7 @@ Supplemental keys never have a scope that is larger than the [=user credential=]

This extension is intended for use by those [=[RPS]=] employing risk-analysis systems informing their sign-in decisions. This extension signals the continuity of some property <i>when used consistently</i> with both {{CredentialsContainer/create()|navigator.credentials.create()}} and {{CredentialsContainer/get()|navigator.credentials.get()}} operations. The property being signaled depends on the scope of the supplemental key and its [=attestation=] statement, if any. The clearest example of a supplemental key is one that is device-bound. Repeated observation of a device-bound supplemental key indicates that a credential is being used repeatedly from the same device. (Which cannot be otherwise assumed in the case of [=backup eligible=] credentials.) But supplemental keys with wider scopes are also defined and the exact properties that they communicate depend on the attestation included along with them.

When a [=[RP]=] uses the `supplementalPubKeys` extension with a {{CredentialsContainer/create()|create()}} call to create a new [=user credential=], a signature by one or more new supplemental keys may be returned along with the new supplemental public keys themselves. For the sake of example, assume that a single supplemental public key is returned, called &ldquo;SPK1&rdquo;. For as long as the [=user credential=] is exercised within the scope of the supplemental key, the [=[RP]=]'s subsequent {{CredentialsContainer/get()|get()}} operations for that credential will generate [=assertions=] including further signatures by &ldquo;SPK1&rdquo;.
When a [=[RP]=] uses the `supplementalPubKeys` extension with a {{CredentialsContainer/create()|create()}} call to create a new [=user credential=], a signature by one or more new supplemental keys may be returned along with the new supplemental public keys themselves. For the sake of example, assume that a single supplemental public key is returned, called &ldquo;SPK1&rdquo;. For as long as the [=user credential=] is exercised within the scope of the supplemental key, the [=[RP]=]'s subsequent {{CredentialsContainer/get()|get()}} operations for that credential will likely generate [=assertions=] including further signatures by &ldquo;SPK1&rdquo;.

The credential may move beyond the scope of that supplemental key (for example, by being exported and imported elsewhere, if [=backup eligible=]) and, if used in this new domain, the {{CredentialsContainer/get()|get()}} operation will return a <i>new</i> supplemental key, SPK2, and its signature. Subsequent {{CredentialsContainer/get()|get()}} operations may observe either SPK1 or SPK2, depending on the context in which the [=user credential=] is being used.

Expand Down

0 comments on commit 24dd8e9

Please sign in to comment.