Skip to content
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

Open
wants to merge 24 commits into
base: main
Choose a base branch
from
Open
Changes from 22 commits
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 104 additions & 5 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -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 {
Expand All @@ -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">
Expand Down Expand Up @@ -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>&lt;b&gt;&lt;/b&gt;</code> to mark the text inbetween as bold and <code>&lt;br /&gt;</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".
Copy link
Contributor

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:

Suggested change
:: A single USVString confirmationPrompt. This string might contain the following formatting tags: <code>&lt;b&gt;&lt;/b&gt;</code> to mark the text inbetween as bold and <code>&lt;br /&gt;</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".
:: A single USVString confirmation. This string might contain the following formatting tags: <code>&lt;b&gt;&lt;/b&gt;</code> to mark the text inbetween as bold and <code>&lt;br /&gt;</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.

Choose a reason for hiding this comment

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

Copy-pasting offline chat with @rlin1

How does the extension processing work when uv is preferred or required. Does the authenticator/client need to show two prompts?

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.

If the authenticator does not support displaying the confirmation prompt but supports signing the confirmation, does the browser/OS take over this responsibility? Do we need corresponding changes in CTAP to let providers indicate to the browser/OS whether this extension is fully/partially supported.

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.

“If processing a response without the confirmation extension is acceptable by policy” – Not sure what this means. How does an RP specify that confirmation prompt is optional. And if the confirmation is optional then it does not provide auditable evidence that consent was visible to the user as you stated below.

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).

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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=].
Expand Down