-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved version of extension for Transaction Confirmation #2020
base: main
Are you sure you want to change the base?
Changes from 22 commits
bf2c769
1b47d14
20d556a
f974726
890caeb
7473063
8ea1d67
c3a701a
030bb92
891f450
756347d
35bc67d
31040ea
4238d66
edade0b
c69673d
d2ee495
d18e271
a175ab9
4e30789
ca74747
9f2723f
af053d6
704decb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3655,11 +3655,12 @@ Note: The {{CollectedClientData}} may be extended in the future. Therefore it's | |
|
||
<xmp class="idl"> | ||
dictionary CollectedClientData { | ||
required DOMString type; | ||
required DOMString challenge; | ||
required DOMString origin; | ||
DOMString topOrigin; | ||
boolean crossOrigin; | ||
required DOMString type; | ||
required DOMString challenge; | ||
required DOMString origin; | ||
DOMString topOrigin; | ||
boolean crossOrigin; | ||
CollectedClientDataExtensions extensions; | ||
}; | ||
|
||
dictionary TokenBinding { | ||
|
@@ -3668,6 +3669,9 @@ Note: The {{CollectedClientData}} may be extended in the future. Therefore it's | |
}; | ||
|
||
enum TokenBindingStatus { "present", "supported" }; | ||
|
||
dictionary CollectedClientDataExtensions { | ||
}; | ||
</xmp> | ||
|
||
<div dfn-type="dict-member" dfn-for="CollectedClientData"> | ||
|
@@ -7685,6 +7689,101 @@ To <dfn abstract-op>Create a new supplemental public key record</dfn>, perform t | |
[=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. | ||
|
||
|
||
### Confirmation Extension (confirmation) ### {#sctn-confirmation-extension} | ||
|
||
This <dfn>confirmation extension</dfn> allows for capturing user confirmation. A | ||
[=[RP]=] can specify a confirmation prompt string, intended for display by the platform and by the authenticator (if supported). | ||
With this approach, [=Relying Parties=] can use the feature independently of the capabilities of the authenticator used by the user, | ||
while still benefitting from the increased security level if the authenticator itself supports showing the confirmation prompt. | ||
|
||
Authenticators could use a Trusted UI to ensure that the user indeed sees the confirmation prompt. | ||
|
||
Example uses cases could be "I want to move $1234 from account A to account B" or "I want to share my health data with hospital X". | ||
|
||
: Extension identifier | ||
:: `confirmation` | ||
|
||
: Operation applicability | ||
:: [=authentication extension|Authentication=] | ||
|
||
: Client extension input | ||
:: A single USVString confirmationPrompt. This string might contain the following formatting tags: <code><b></b></code> to mark the text inbetween as bold and <code><br /></code> to force a line break. Support of these formatting tags is "best effort". Implementations not supporting it SHALL NOT display the tags in "verbatim". | ||
|
||
<xmp class="idl"> | ||
partial dictionary AuthenticationExtensionsClientInputs { | ||
USVString confirmation; | ||
}; | ||
</xmp> | ||
|
||
: Client extension processing | ||
:: 1. use a dialog to the user that makes the user aware of the confirmation to be provided (as opposed to doing a simple sign in). | ||
1. display the confirmation prompt to the user. The client SHOULD | ||
indicate that the confirmation prompt originates from a specific relying party | ||
(as opposed to the platform itself). | ||
|
||
1. use the {{CollectedClientConfirmationData}} structure containing the confirmation prompt instead of using the {{CollectedClientData}} structure. | ||
|
||
1. pass-through the extension to the authenticator (see "authenticator extension input" below) | ||
1. pass-through the "authenticator extension output" to the caller as part of the assertion | ||
|
||
|
||
The {{CollectedClientDataExtensions}} dictionary contains the following | ||
additional field: | ||
<xmp class="idl"> | ||
partial dictionary CollectedClientDataExtensions { | ||
USVString confirmation; | ||
}; | ||
</xmp> | ||
|
||
: Client extension output | ||
:: Returns the value [TRUE] to indicate to the [=[RP]=] that the extension was acted upon. | ||
<xmp class="idl"> | ||
partial dictionary AuthenticationExtensionsClientOutputs { | ||
boolean confirmation; | ||
}; | ||
</xmp> | ||
|
||
: Authenticator extension input | ||
:: The client provides the extension input encoded as a CBOR text string (major type 3). | ||
|
||
``` | ||
$$extensionInput //= ( | ||
confirmation = tstr, | ||
) | ||
``` | ||
|
||
: Authenticator extension processing | ||
:: The authenticator supporting this extension MUST display the confirmation prompt to the user | ||
before performing either [=user verification=] or [=test of user | ||
presence=]. The authenticator MAY wrap lines that are too wide to be shown if needed. | ||
|
||
: Authenticator extension output | ||
:: A single CBOR text string, representing the confirmation prompt. | ||
|
||
``` | ||
$$extensionOutput //= ( | ||
confirmation = tstr, | ||
) | ||
``` | ||
|
||
Note: It is up to the relying party to handle the different [=user verification=] options appropriately. | ||
This includes appropriate settings for {{AuthenticatorSelectionCriteria/userVerification}} and | ||
appropriate processing of [=authData/flags/UV=] and [=authData/flags/UP=]. | ||
This [=confirmation extension=] doesn't change the way [=user verification=] is | ||
handled by the [=client platform=] / [=authenticator=]. | ||
|
||
|
||
#### `confirmation` Extension Output Verification Procedures #### {#sctn-confirmation-extension-verification} | ||
|
||
The following verification steps are performed in the context of [step 19](#authn-ceremony-verify-extension-outputs) | ||
of [[#sctn-verifying-assertion]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, |hash|, and |credentialRecord|. | ||
[=[RP]=] policy may specify whether a response without a `confirmation` extension output is acceptable. | ||
|
||
1. Verify that the `confirmation` key exists in the [=authData/extensions=] in |authData|. | ||
1. Verify that the `confirmation` value in the [=authData/extensions=] in |authData| equals the confirmation prompt that is expected (i.e., that was used when requesting the `confirmation` extension). | ||
1. If processing a response without the `confirmation` extension is acceptable by policy: Fall back to <code>|credential|.{{PublicKeyCredential/response}}.{{AuthenticatorResponse/clientDataJSON}}</code> entry if authenticator extension output is absent. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Copy-pasting offline chat with @rlin1
It is up to the relying party to handle the different user verification options appropriately. This includes appropriate settings for userVerification and appropriate processing of UV and UP. This confirmation extension doesn’t change the way user verification is handled by the client platform / authenticator. Have added a note regarding this.
In that case the authenticator doesn’t support the confirmation extension. The client platform will add the confirmation details to the collectedClientData structure so that any authenticator would just sign over it- The relying arty can detect that by not finding the confirmation extension in the assertion, but only seeing the confirmation details in the collectedClientData.
It is up to the relying party to decide whether or not to accept an assertion without the confirmation extension (but with confirmation details in the collected clientData). This situation indicates that a privileged component (i.e. client platform) has shown the confirmation details, but it wasn’t done by the authenticator itself (which could be an attested component). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the approach of letting RPs decide whether to accept an assertion without confirmation makes sense but its not clearly called out in the PR. We should further clarify here that if authenticator does not support the confirmation extension, the confirmation string is still signed over. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should be addressed by commit 9f2723f |
||
|
||
|
||
# User Agent Automation # {#sctn-automation} | ||
|
||
For the purposes of user agent automation and [=web application=] testing, this document defines a number of [[WebDriver]] [=extension commands=]. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to get trimmed down to just
confirmation
: