From bf2c769e2f989a28c5840a47683edf5c5ba2a5a5 Mon Sep 17 00:00:00 2001 From: Rolf Lindemann Date: Tue, 19 Dec 2023 15:33:06 +0100 Subject: [PATCH 01/20] first draft of improved txAuthSimple2 extension --- index.bs | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/index.bs b/index.bs index ef332a628..ba877d3b7 100644 --- a/index.bs +++ b/index.bs @@ -7652,6 +7652,96 @@ To Create a new supplemental public key record, perform t [=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. +### Simple Transaction Authorization Extension (txAuthSimple2) ### {#sctn-simple-txauth-extension2} + +This extension allows for a simple form of transaction authorization. A + [=[RP]=] can specify a 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 transaction text. + +: Extension identifier +:: `txAuthSimple2` + +: Operation applicability +:: [=authentication extension|Authentication=] + +: Client extension input +:: A single USVString prompt. + + partial dictionary AuthenticationExtensionsClientInputs { + USVString txAuthSimple2; + }; + + +: Client extension processing +:: If (and only if) the authenticator doesn't support this extension (to be determined by the platform via the response to CTAP getClientInfo), then the Client is expected to display + the transaction text to the user and to include the transaction text in the collectedClientData structure as described below. + If the authenticator supports this extension, then the client SHALL pass-through the extension to the + authenticator and not perform any other client processing. + + + dictionary CollectedClientTxAuthSimple2Data : CollectedClientData { + required CollectedClientAdditionalTxAuthSimple2Data transactionText; + }; + + + The {{CollectedClientTxAuthSimple2Data}} dictionary inherits from + {{CollectedClientData}}. It contains the following additional field: + +
+ : transactionText member + :: The full context of the transaction to sign. +
+ + + + dictionary CollectedClientAdditionalTxAuthSimple2Data { + required USVString rpId; + required USVString transactionText; + }; + + + The {{CollectedClientAdditionalTxAuthSimple2Data}} dictionary contains the following + fields: + +
+ : rpId member + :: The id of the [=Relying Party=] that created the credential. + + : transactionText member + :: The full context of the transaction that the user is intended to approve. +
+ +: Client extension output +:: Returns the authenticator extension output string UTF-8 decoded into a USVString. + + partial dictionary AuthenticationExtensionsClientOutputs { + USVString txAuthSimple2; + }; + + +: Authenticator extension input +:: If the authenticator supports this extension, then the client provides the extension input encoded as a CBOR text string (major type 3). + +
+CDDL:
+txAuthSimpleInput = (tstr)
+
+ +: Authenticator extension processing +:: The authenticator MUST display the prompt to the user before performing either [=user verification=] or [=test of user + presence=]. The authenticator MAY insert line breaks if needed. + +: Authenticator extension output +:: A single CBOR string, representing the prompt as displayed (including any eventual line breaks). + +
+CDDL:
+txAuthSimpleOutput = (tstr)
+
+ + + # 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=]. From 1b47d149a738fbc7028ba6130dd3d32958305f34 Mon Sep 17 00:00:00 2001 From: Rolf Lindemann Date: Tue, 19 Dec 2023 16:40:57 +0100 Subject: [PATCH 02/20] added issues --- index.bs | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/index.bs b/index.bs index ba877d3b7..e0de9328d 100644 --- a/index.bs +++ b/index.bs @@ -7679,6 +7679,15 @@ This extension allows for a simple form of transaction authorization. A If the authenticator supports this extension, then the client SHALL pass-through the extension to the authenticator and not perform any other client processing. + +
+ Mention that the client shouldn't prompt the user for "sign-in" but instead for approving a transaction. + + Should we keep the "type" on "authenticate" or change to something closer to transaction (SPC uses 'payment.get')? + + Should we change the name back to txAuthSimple - cannot really hurt - but makes it easier for authenticators already implementing it. +
+ dictionary CollectedClientTxAuthSimple2Data : CollectedClientData { required CollectedClientAdditionalTxAuthSimple2Data transactionText; From 20d556a9dc0da79f51f69ab06e2840dfac0e8b28 Mon Sep 17 00:00:00 2001 From: Rolf Lindemann <rolf@noknok.com> Date: Wed, 20 Dec 2023 11:08:21 +0100 Subject: [PATCH 03/20] added more issues --- index.bs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.bs b/index.bs index e0de9328d..dd7cca279 100644 --- a/index.bs +++ b/index.bs @@ -7683,6 +7683,9 @@ This extension allows for a simple form of transaction authorization. A <div class="issue"> Mention that the client shouldn't prompt the user for "sign-in" but instead for approving a transaction. + Should we always let the client use CollectedClientTxAuthSimple2Data instead of CollectedClientData to have more consistency (or only if the client displayed it)? + If yes: Should the client verify it matches the transactionText returned by the authenticator (if that exists)? + Should we keep the "type" on "authenticate" or change to something closer to transaction (SPC uses 'payment.get')? Should we change the name back to txAuthSimple - cannot really hurt - but makes it easier for authenticators already implementing it. From f97472623b10767d1336f4b893c521c17a40155e Mon Sep 17 00:00:00 2001 From: Rolf Lindemann <rolf@noknok.com> Date: Thu, 21 Dec 2023 09:10:23 +0100 Subject: [PATCH 04/20] simplified approach --- index.bs | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/index.bs b/index.bs index dd7cca279..4fd7778c3 100644 --- a/index.bs +++ b/index.bs @@ -7669,23 +7669,25 @@ This extension allows for a simple form of transaction authorization. A :: A single USVString prompt. <xmp class="idl"> partial dictionary AuthenticationExtensionsClientInputs { - USVString txAuthSimple2; + USVString txAuthSimple; }; : Client extension processing -:: If (and only if) the authenticator doesn't support this extension (to be determined by the platform via the response to CTAP getClientInfo), then the Client is expected to display - the transaction text to the user and to include the transaction text in the collectedClientData structure as described below. - If the authenticator supports this extension, then the client SHALL pass-through the extension to the - authenticator and not perform any other client processing. +:: If this extension is present, the client SHALL + 1. use a dialog to the user that makes sense in the context of approving a transaction (as opposed to sign in). + 1. display the transaction text to the user. The client SHOULD + indicate that the transaction text originates from a specific relying party + (as opposed to the platform itself). + + 1. use the {{CollectedClientTxAuthSimple2Data}} structure containing the transaction text instead of using + the {{CollectedClientData}} structure. + + 1. pass-through the extension to the authenticator (see "client extension output" below) + 1. pass-through the "authenticator extension output" to the caller as part of the assertion
- Mention that the client shouldn't prompt the user for "sign-in" but instead for approving a transaction. - - Should we always let the client use CollectedClientTxAuthSimple2Data instead of CollectedClientData to have more consistency (or only if the client displayed it)? - If yes: Should the client verify it matches the transactionText returned by the authenticator (if that exists)? - Should we keep the "type" on "authenticate" or change to something closer to transaction (SPC uses 'payment.get')? Should we change the name back to txAuthSimple - cannot really hurt - but makes it easier for authenticators already implementing it. @@ -7728,7 +7730,7 @@ This extension allows for a simple form of transaction authorization. A :: Returns the authenticator extension output string UTF-8 decoded into a USVString. partial dictionary AuthenticationExtensionsClientOutputs { - USVString txAuthSimple2; + USVString txAuthSimple; }; @@ -7741,11 +7743,12 @@ txAuthSimpleInput = (tstr) : Authenticator extension processing -:: The authenticator MUST display the prompt to the user before performing either [=user verification=] or [=test of user +:: The authenticator MUST display the transaction text to the user + before performing either [=user verification=] or [=test of user presence=]. The authenticator MAY insert line breaks if needed. : Authenticator extension output -:: A single CBOR string, representing the prompt as displayed (including any eventual line breaks). +:: A single CBOR string, representing the transaction text (excluding any eventual line breaks that were inserted). 
 CDDL:

From 890caebb76b38507cb829264a16c10db9266d0d1 Mon Sep 17 00:00:00 2001
From: Rolf Lindemann 
Date: Mon, 8 Jan 2024 12:39:38 +0100
Subject: [PATCH 05/20] .

---
 index.bs | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/index.bs b/index.bs
index 4fd7778c3..549cfaffc 100644
--- a/index.bs
+++ b/index.bs
@@ -7678,11 +7678,11 @@ This extension allows for a simple form of transaction authorization. A
        1. use a dialog to the user that makes sense in the context of approving a transaction (as opposed to sign in).
        1. display the transaction text to the user. The client SHOULD
              indicate that the transaction text originates from a specific relying party
-	     (as opposed to the platform itself).
-	     
+             (as opposed to the platform itself).
+     
        1. use the {{CollectedClientTxAuthSimple2Data}} structure containing the transaction text instead of using
              the {{CollectedClientData}} structure.
-	     
+     
        1. pass-through the extension to the authenticator (see "client extension output" below)
        1. pass-through the "authenticator extension output" to the caller as part of the assertion
 
@@ -7690,7 +7690,7 @@ This extension allows for a simple form of transaction authorization. A
     

       Should we keep the "type" on "authenticate" or change to something closer to transaction (SPC uses 'payment.get')?
 
-      Should we change the name back to txAuthSimple - cannot really hurt - but makes it easier for authenticators already implementing it.
+      Should we change the name back to txAuthSimple - cannot really hurt as no platform supports it today and authenticator implementations don't have to change.
     

 
     

From 8ea1d67ce093940469e659a34f8654f7753cda6e Mon Sep 17 00:00:00 2001
From: Rolf Lindemann <rolf@noknok.com>
Date: Mon, 8 Jan 2024 15:23:59 +0100
Subject: [PATCH 06/20] clarification that client always sends extension to
 authenticator

---
 index.bs | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/index.bs b/index.bs
index 818f965d7..1ca04a6e9 100644
--- a/index.bs
+++ b/index.bs
@@ -7735,7 +7735,7 @@ This extension allows for a simple form of transaction authorization. A
     
 
 : Authenticator extension input
-:: If the authenticator supports this extension, then the client provides the extension input encoded as a CBOR text string (major type 3).
+:: The client provides the extension input encoded as a CBOR text string (major type 3).
 
 
 CDDL:
@@ -7743,12 +7743,13 @@ txAuthSimpleInput = (tstr)
 

 
 : Authenticator extension processing
-:: The authenticator MUST display the transaction text to the user
+:: The authenticator supporting this extension MUST display the transaction text to the user
     before performing either [=user verification=] or [=test of user
-    presence=]. The authenticator MAY insert line breaks if needed.
+    presence=]. The authenticator MAY insert line breaks when displaying the text if needed.
 
 : Authenticator extension output
-:: A single CBOR string, representing the transaction text (excluding any eventual line breaks that were inserted).
+:: If the authenticator supports this extension (and only then): A single CBOR string, representing the
+    transaction text (excluding any eventual line breaks that were inserted).
 
 
 CDDL:

From c3a701ad63e3adc017579de0b291634922b1eb19 Mon Sep 17 00:00:00 2001
From: rlin1 
Date: Mon, 12 Feb 2024 11:57:11 +0100
Subject: [PATCH 07/20] rename to txAuthSimple

---
 index.bs | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/index.bs b/index.bs
index 1ca04a6e9..087ae50a8 100644
--- a/index.bs
+++ b/index.bs
@@ -7652,7 +7652,7 @@ To Create a new supplemental public key record, perform t
         [=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$].
 
 
-### Simple Transaction Authorization Extension (txAuthSimple2) ### {#sctn-simple-txauth-extension2}
+### Simple Transaction Authorization Extension (txAuthSimple) ### {#sctn-simple-txauth-extension}
 
 This extension allows for a simple form of transaction authorization. A
    [=[RP]=] can specify a prompt string, intended for display by the platform and by the authenticator (if supported).
@@ -7660,7 +7660,7 @@ This extension allows for a simple form of transaction authorization. A
    while still benefitting from the increased security level if the authenticator itself supports showing the transaction text.
 
 : Extension identifier
-:: `txAuthSimple2`
+:: `txAuthSimple`
 
 : Operation applicability
 :: [=authentication extension|Authentication=]
@@ -7680,7 +7680,7 @@ This extension allows for a simple form of transaction authorization. A
              indicate that the transaction text originates from a specific relying party
              (as opposed to the platform itself).
      
-       1. use the {{CollectedClientTxAuthSimple2Data}} structure containing the transaction text instead of using
+       1. use the {{CollectedClientTxAuthSimpleData}} structure containing the transaction text instead of using
              the {{CollectedClientData}} structure.
      
        1. pass-through the extension to the authenticator (see "client extension output" below)
@@ -7694,31 +7694,31 @@ This extension allows for a simple form of transaction authorization. A
- dictionary CollectedClientTxAuthSimple2Data : CollectedClientData { - required CollectedClientAdditionalTxAuthSimple2Data transactionText; + dictionary CollectedClientTxAuthSimpleData : CollectedClientData { + required CollectedClientAdditionalTxAuthSimpleData transactionText; }; - The {{CollectedClientTxAuthSimple2Data}} dictionary inherits from + The {{CollectedClientTxAuthSimpleData}} dictionary inherits from {{CollectedClientData}}. It contains the following additional field: -
+
: transactionText member :: The full context of the transaction to sign.
- dictionary CollectedClientAdditionalTxAuthSimple2Data { + dictionary CollectedClientAdditionalTxAuthSimpleData { required USVString rpId; required USVString transactionText; }; - The {{CollectedClientAdditionalTxAuthSimple2Data}} dictionary contains the following + The {{CollectedClientAdditionalTxAuthSimpleData}} dictionary contains the following fields: -
+
: rpId member :: The id of the [=Relying Party=] that created the credential. From 030bb9242c2259ef857f09e57842e673af18f18c Mon Sep 17 00:00:00 2001 From: rlin1 Date: Mon, 12 Feb 2024 13:32:29 +0100 Subject: [PATCH 08/20] removed TODOs --- index.bs | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/index.bs b/index.bs index 087ae50a8..f153c8b90 100644 --- a/index.bs +++ b/index.bs @@ -7687,12 +7687,6 @@ This extension allows for a simple form of transaction authorization. A 1. pass-through the "authenticator extension output" to the caller as part of the assertion -
- Should we keep the "type" on "authenticate" or change to something closer to transaction (SPC uses 'payment.get')? - - Should we change the name back to txAuthSimple - cannot really hurt as no platform supports it today and authenticator implementations don't have to change. -
- dictionary CollectedClientTxAuthSimpleData : CollectedClientData { required CollectedClientAdditionalTxAuthSimpleData transactionText; @@ -9362,6 +9356,22 @@ for their contributions as our W3C Team Contacts. "date": "June 2019" }, + "RFC9052": { + "authors": ["Jim Schaad"], + "title": "CBOR Object Signing and Encryption (COSE): Structures and Process", + "href": "https://datatracker.ietf.org/doc/rfc9052/", + "status": "IETF Internet Standard", + "date": "August 2022" + }, + + "RFC9053": { + "authors": ["Jim Schaad"], + "title": "CBOR Object Signing and Encryption (COSE): Initial Algorithms", + "href": "https://datatracker.ietf.org/doc/rfc9053/", + "status": "RFC Informational", + "date": "August 2022" + }, + "ISOBiometricVocabulary": { "authors": ["ISO/IEC JTC1/SC37"], "title": "Information technology — Vocabulary — Biometrics", From 891f450e21c695a6ab0b4f541e0325abde40cfa6 Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Mon, 12 Feb 2024 13:38:27 +0100 Subject: [PATCH 09/20] more clarifications --- index.bs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index f153c8b90..2bd5e6860 100644 --- a/index.bs +++ b/index.bs @@ -7659,6 +7659,10 @@ This extension allows for a simple form of transaction authorization. A 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 transaction text. +Authenticators could use a Trusted UI to ensure that the user indeed sees the transaction text. + +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 :: `txAuthSimple` @@ -7675,7 +7679,7 @@ This extension allows for a simple form of transaction authorization. A : Client extension processing :: If this extension is present, the client SHALL - 1. use a dialog to the user that makes sense in the context of approving a transaction (as opposed to sign in). + 1. use a dialog to the user that makes the user aware of the fact that a transaction is being approved (as opposed to doing a simple sign in). 1. display the transaction text to the user. The client SHOULD indicate that the transaction text originates from a specific relying party (as opposed to the platform itself). From 756347dfe36a5a119862074da58c3f44df1a07bc Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Thu, 7 Mar 2024 11:10:57 +0100 Subject: [PATCH 10/20] added RP verification procedure --- index.bs | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/index.bs b/index.bs index 2bd5e6860..529f9cfb0 100644 --- a/index.bs +++ b/index.bs @@ -7532,7 +7532,7 @@ See also [[#sctn-supplemental-public-keys-extension-usage]] for further details. ##### Authentication (`get()`) ##### {#sctn-supplemental-public-keys-extension-verification-get} If the [=[RP]=] requested the `supplementalPubKeys` extension in a {{CredentialsContainer/get()|navigator.credentials.get()}} call, -then the below verification steps are performed in the context of [step 17](#authn-ceremony-verify-extension-outputs) +then the below 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 `supplementalPubKeys` extension output is acceptable. @@ -7708,7 +7708,6 @@ Example uses cases could be "I want to move $1234 from account A to account B" o <xmp class="idl"> dictionary CollectedClientAdditionalTxAuthSimpleData { - required USVString rpId; required USVString transactionText; }; @@ -7717,9 +7716,6 @@ Example uses cases could be "I want to move $1234 from account A to account B" o fields:
- : rpId member - :: The id of the [=Relying Party=] that created the credential. - : transactionText member :: The full context of the transaction that the user is intended to approve.
@@ -7754,6 +7750,21 @@ CDDL: txAuthSimpleOutput = (tstr) +#### `txAuthSimple` Extension Output Verification Procedures #### {#sctn-txauthsimple-extension-verification} + +Verifying the [=txAuthSimple=] extension output is performed by the [=[RP]=] whenever a the use of [=txAuthSimple=] was requested. + +##### Authentication (`get()`) ##### {#sctn-txauthsimple-extension-verification-get} + +This extension is only specified to be used in conjunction with a {{CredentialsContainer/get()|navigator.credentials.get()}} call. + +If the [=[RP]=] requested the `txAuthSimple` extension in a {{CredentialsContainer/get()|navigator.credentials.get()}} call, then the below verification step 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 `txAuthSimple` extension output is acceptable. + +1. Verify that the {{AuthenticationExtensionsClientOutputs/txAuthSimple}} member of |clientExtensionResults| exists. +1. Verify that the {{AuthenticationExtensionsClientOutputs/txAuthSimple}} member contains the transaction text that is expected (i.e., that was used when requesting the `txAuthSimple` extension. + # User Agent Automation # {#sctn-automation} From 35bc67df6ac213f7d4bd147961125f6deb72a742 Mon Sep 17 00:00:00 2001 From: rlin1 Date: Wed, 13 Mar 2024 18:59:28 +0100 Subject: [PATCH 11/20] renamed to confirmation --- index.bs | 68 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/index.bs b/index.bs index 529f9cfb0..5583a2024 100644 --- a/index.bs +++ b/index.bs @@ -7652,19 +7652,19 @@ To Create a new supplemental public key record, perform t [=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. -### Simple Transaction Authorization Extension (txAuthSimple) ### {#sctn-simple-txauth-extension} +### Simple Confirmation Extension (confirmation) ### {#sctn-simple-txauth-extension} -This extension allows for a simple form of transaction authorization. A - [=[RP]=] can specify a prompt string, intended for display by the platform and by the authenticator (if supported). +This extension 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 transaction text. + 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 transaction text. +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 -:: `txAuthSimple` +:: `confirmation` : Operation applicability :: [=authentication extension|Authentication=] @@ -7673,18 +7673,18 @@ Example uses cases could be "I want to move $1234 from account A to account B" o :: A single USVString prompt. partial dictionary AuthenticationExtensionsClientInputs { - USVString txAuthSimple; + USVString confirmationPrompt; }; : Client extension processing :: If this extension is present, the client SHALL - 1. use a dialog to the user that makes the user aware of the fact that a transaction is being approved (as opposed to doing a simple sign in). - 1. display the transaction text to the user. The client SHOULD - indicate that the transaction text originates from a specific relying party + 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 {{CollectedClientTxAuthSimpleData}} structure containing the transaction text instead of using + 1. use the {{CollectedClientConfirmationData}} structure containing the confirmation prompt instead of using the {{CollectedClientData}} structure. 1. pass-through the extension to the authenticator (see "client extension output" below) @@ -7692,39 +7692,39 @@ Example uses cases could be "I want to move $1234 from account A to account B" o - dictionary CollectedClientTxAuthSimpleData : CollectedClientData { - required CollectedClientAdditionalTxAuthSimpleData transactionText; + dictionary CollectedClientConfirmationData : CollectedClientData { + required CollectedClientAdditionalConfirmationData confirmationPrompt; }; The {{CollectedClientTxAuthSimpleData}} dictionary inherits from {{CollectedClientData}}. It contains the following additional field: -
- : transactionText member - :: The full context of the transaction to sign. +
+ : confirmationPrompt member + :: The full context of the confirmation to give.
- dictionary CollectedClientAdditionalTxAuthSimpleData { - required USVString transactionText; + dictionary CollectedClientAdditionalConfirmationData { + required USVString confirmationPrompt; }; - The {{CollectedClientAdditionalTxAuthSimpleData}} dictionary contains the following + The {{CollectedClientAdditionalConfirmationData}} dictionary contains the following fields: -
- : transactionText member - :: The full context of the transaction that the user is intended to approve. +
+ : confirmationPrompt member + :: The full context of the confirmation to give.
: Client extension output :: Returns the authenticator extension output string UTF-8 decoded into a USVString. partial dictionary AuthenticationExtensionsClientOutputs { - USVString txAuthSimple; + USVString confirmationPrompt; }; @@ -7733,37 +7733,37 @@ Example uses cases could be "I want to move $1234 from account A to account B" o 
 CDDL:
-txAuthSimpleInput = (tstr)
+confirmatonPromptInput = (tstr)
: Authenticator extension processing -:: The authenticator supporting this extension MUST display the transaction text to the user +:: 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 insert line breaks when displaying the text if needed. + presence=]. The authenticator MAY wrap lines that are too wide to be shown if needed. : Authenticator extension output :: If the authenticator supports this extension (and only then): A single CBOR string, representing the - transaction text (excluding any eventual line breaks that were inserted). + confirmation prompt. 
 CDDL:
-txAuthSimpleOutput = (tstr)
+confirmationPromptOutput = (tstr)
-#### `txAuthSimple` Extension Output Verification Procedures #### {#sctn-txauthsimple-extension-verification} +#### `confirmation` Extension Output Verification Procedures #### {#sctn-txauthsimple-extension-verification} -Verifying the [=txAuthSimple=] extension output is performed by the [=[RP]=] whenever a the use of [=txAuthSimple=] was requested. +Verifying the [=txAuthSimple=] extension output is performed by the [=[RP]=] whenever a the use of [=confirmatione=] was requested. ##### Authentication (`get()`) ##### {#sctn-txauthsimple-extension-verification-get} This extension is only specified to be used in conjunction with a {{CredentialsContainer/get()|navigator.credentials.get()}} call. -If the [=[RP]=] requested the `txAuthSimple` extension in a {{CredentialsContainer/get()|navigator.credentials.get()}} call, then the below verification step are performed in the context of [step 19](#authn-ceremony-verify-extension-outputs) +If the [=[RP]=] requested the `confirmation` extension in a {{CredentialsContainer/get()|navigator.credentials.get()}} call, then the below verification step 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 `txAuthSimple` extension output is acceptable. +[=[RP]=] policy may specify whether a response without a `confirmation` extension output is acceptable. -1. Verify that the {{AuthenticationExtensionsClientOutputs/txAuthSimple}} member of |clientExtensionResults| exists. -1. Verify that the {{AuthenticationExtensionsClientOutputs/txAuthSimple}} member contains the transaction text that is expected (i.e., that was used when requesting the `txAuthSimple` extension. +1. Verify that the {{AuthenticationExtensionsClientOutputs/confirmation}} member of |clientExtensionResults| exists. +1. Verify that the {{AuthenticationExtensionsClientOutputs/confirmation}} member contains the confirmation prompt that is expected (i.e., that was used when requesting the `confirmation` extension. From 31040ea9d92740b2105dd4a8ec28cc0d491a8810 Mon Sep 17 00:00:00 2001 From: rlin1 Date: Wed, 13 Mar 2024 19:15:40 +0100 Subject: [PATCH 12/20] removed simple from name --- index.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 5583a2024..001782e27 100644 --- a/index.bs +++ b/index.bs @@ -7652,7 +7652,7 @@ To Create a new supplemental public key record, perform t [=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. -### Simple Confirmation Extension (confirmation) ### {#sctn-simple-txauth-extension} +### Confirmation Extension (confirmation) ### {#sctn-simple-txauth-extension} This extension 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). @@ -7670,7 +7670,7 @@ Example uses cases could be "I want to move $1234 from account A to account B" o :: [=authentication extension|Authentication=] : Client extension input -:: A single USVString prompt. +:: A single USVString confirmationPrompt. partial dictionary AuthenticationExtensionsClientInputs { USVString confirmationPrompt; @@ -7697,7 +7697,7 @@ Example uses cases could be "I want to move $1234 from account A to account B" o }; - The {{CollectedClientTxAuthSimpleData}} dictionary inherits from + The {{CollectedClientConfirmationData}} dictionary inherits from {{CollectedClientData}}. It contains the following additional field:
From 4238d66858b6b0132febd5aa698ff386c605089a Mon Sep 17 00:00:00 2001 From: rlin1 Date: Thu, 14 Mar 2024 12:16:42 +0100 Subject: [PATCH 13/20] replaced leftover txAuthSimple by confirmation --- index.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index 001782e27..cb0dae036 100644 --- a/index.bs +++ b/index.bs @@ -7652,7 +7652,7 @@ To Create a new supplemental public key record, perform t [=set/append=] this [=supplemental public key record=] to |credentialRecord|.[$credential record/supplementalPubKeys$]. -### Confirmation Extension (confirmation) ### {#sctn-simple-txauth-extension} +### Confirmation Extension (confirmation) ### {#sctn-confirmation-extension} This extension 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). @@ -7750,11 +7750,11 @@ CDDL: confirmationPromptOutput = (tstr) -#### `confirmation` Extension Output Verification Procedures #### {#sctn-txauthsimple-extension-verification} +#### `confirmation` Extension Output Verification Procedures #### {#sctn-confirmation-extension-verification} -Verifying the [=txAuthSimple=] extension output is performed by the [=[RP]=] whenever a the use of [=confirmatione=] was requested. +Verifying the [=confirmation=] extension output is performed by the [=[RP]=] whenever a the use of [=confirmatione=] was requested. -##### Authentication (`get()`) ##### {#sctn-txauthsimple-extension-verification-get} +##### Authentication (`get()`) ##### {#sctn-confirmation-extension-verification-get} This extension is only specified to be used in conjunction with a {{CredentialsContainer/get()|navigator.credentials.get()}} call. From edade0b96cf9f61d33de6348ac3f721f46616843 Mon Sep 17 00:00:00 2001 From: rlin1 Date: Thu, 14 Mar 2024 12:26:34 +0100 Subject: [PATCH 14/20] added two formatting tags --- index.bs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index cb0dae036..cdf1a698a 100644 --- a/index.bs +++ b/index.bs @@ -7670,7 +7670,8 @@ Example uses cases could be "I want to move $1234 from account A to account B" o :: [=authentication extension|Authentication=] : Client extension input -:: A single USVString confirmationPrompt. +:: A single USVString confirmationPrompt. This string might contain the following formatting tags: <b></b> to mark the text inbetween as bold and <br /> to force a line break. Support of these formatting tags is "best effort". Implementations not supporting it SHALL NOT display the tags in "verbatim". + partial dictionary AuthenticationExtensionsClientInputs { USVString confirmationPrompt; From c69673d9da105189ae302809a71342b7e995b19e Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Thu, 14 Mar 2024 12:28:05 +0100 Subject: [PATCH 15/20] fixed typo: confirmaton --> confirmation --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index cdf1a698a..0132ca401 100644 --- a/index.bs +++ b/index.bs @@ -7734,7 +7734,7 @@ Example uses cases could be "I want to move $1234 from account A to account B" o <pre> CDDL: -confirmatonPromptInput = (tstr) +confirmationPromptInput = (tstr) </pre> : Authenticator extension processing From d2ee4954c7415249c5883720e9edd6cb8715501f Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Mon, 29 Apr 2024 12:09:24 +0200 Subject: [PATCH 16/20] incorporated the changes proposed by emlun --- index.bs | 73 +++++++++++++++++++------------------------------------- 1 file changed, 25 insertions(+), 48 deletions(-) diff --git a/index.bs b/index.bs index 0132ca401..a04e7005c 100644 --- a/index.bs +++ b/index.bs @@ -7674,22 +7674,20 @@ Example uses cases could be "I want to move $1234 from account A to account B" o <xmp class="idl"> partial dictionary AuthenticationExtensionsClientInputs { - USVString confirmationPrompt; + USVString confirmation; }; : Client extension processing -:: If this extension is present, the client SHALL - 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 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. use the {{CollectedClientConfirmationData}} structure containing the confirmation prompt instead of using the {{CollectedClientData}} structure. - 1. pass-through the extension to the authenticator (see "client extension output" below) - 1. pass-through the "authenticator extension output" to the caller as part of the assertion + 1. pass-through the extension to the authenticator (see "client extension output" below) + 1. pass-through the "authenticator extension output" to the caller as part of the assertion @@ -7722,20 +7720,21 @@ Example uses cases could be "I want to move $1234 from account A to account B" o </dl> : Client extension output -:: Returns the authenticator extension output string UTF-8 decoded into a USVString. +:: Returns the value [TRUE] to indicate to the [[RP]=] that the extension was acted upon. <xmp class="idl"> partial dictionary AuthenticationExtensionsClientOutputs { - USVString confirmationPrompt; + boolean confirmation; }; : Authenticator extension input :: The client provides the extension input encoded as a CBOR text string (major type 3). -
-CDDL:
-confirmationPromptInput = (tstr)
-
+ ``` + $$extensionInput //= ( + confirmation = tstr, + ) + ``` : Authenticator extension processing :: The authenticator supporting this extension MUST display the confirmation prompt to the user @@ -7743,29 +7742,23 @@ confirmationPromptInput = (tstr) presence=]. The authenticator MAY wrap lines that are too wide to be shown if needed. : Authenticator extension output -:: If the authenticator supports this extension (and only then): A single CBOR string, representing the - confirmation prompt. +:: A single CBOR text string, representing the confirmation prompt. -
-CDDL:
-confirmationPromptOutput = (tstr)
-
+ ``` + $$extensionOutput //= ( + confirmation = tstr, + ) + ``` #### `confirmation` Extension Output Verification Procedures #### {#sctn-confirmation-extension-verification} -Verifying the [=confirmation=] extension output is performed by the [=[RP]=] whenever a the use of [=confirmatione=] was requested. - -##### Authentication (`get()`) ##### {#sctn-confirmation-extension-verification-get} - -This extension is only specified to be used in conjunction with a {{CredentialsContainer/get()|navigator.credentials.get()}} call. - -If the [=[RP]=] requested the `confirmation` extension in a {{CredentialsContainer/get()|navigator.credentials.get()}} call, then the below verification step are performed in the context of [step 19](#authn-ceremony-verify-extension-outputs) +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 {{AuthenticationExtensionsClientOutputs/confirmation}} member of |clientExtensionResults| exists. -1. Verify that the {{AuthenticationExtensionsClientOutputs/confirmation}} member contains the confirmation prompt that is expected (i.e., that was used when requesting the `confirmation` extension. - +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 |credential|.{{PublicKeyCredential/response}}.{{AuthenticatorResponse/clientDataJSON}} entry if authenticator extension output is absent. # User Agent Automation # {#sctn-automation} @@ -9372,22 +9365,6 @@ for their contributions as our W3C Team Contacts. "date": "June 2019" }, - "RFC9052": { - "authors": ["Jim Schaad"], - "title": "CBOR Object Signing and Encryption (COSE): Structures and Process", - "href": "https://datatracker.ietf.org/doc/rfc9052/", - "status": "IETF Internet Standard", - "date": "August 2022" - }, - - "RFC9053": { - "authors": ["Jim Schaad"], - "title": "CBOR Object Signing and Encryption (COSE): Initial Algorithms", - "href": "https://datatracker.ietf.org/doc/rfc9053/", - "status": "RFC Informational", - "date": "August 2022" - }, - "ISOBiometricVocabulary": { "authors": ["ISO/IEC JTC1/SC37"], "title": "Information technology — Vocabulary — Biometrics", From a175ab9dbc1ee9b731590dbe2a4c1162279f0139 Mon Sep 17 00:00:00 2001 From: rlin1 Date: Tue, 30 Apr 2024 18:41:15 +0200 Subject: [PATCH 17/20] changed CollectedClientData integration approach --- index.bs | 43 +++++++++++++------------------------------ 1 file changed, 13 insertions(+), 30 deletions(-) diff --git a/index.bs b/index.bs index 59e308196..01ab3f0eb 100644 --- a/index.bs +++ b/index.bs @@ -3622,11 +3622,12 @@ Note: The {{CollectedClientData}} may be extended in the future. Therefore it's 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 { @@ -3635,6 +3636,9 @@ Note: The {{CollectedClientData}} may be extended in the future. Therefore it's }; enum TokenBindingStatus { "present", "supported" }; + + dictionary CollectedClientDataExtensions { + };
@@ -7621,35 +7625,14 @@ Example uses cases could be "I want to move $1234 from account A to account B" o 1. pass-through the "authenticator extension output" to the caller as part of the assertion + The {{CollectedClientDataExtensions}} dictionary contains the following + additional field: - dictionary CollectedClientConfirmationData : CollectedClientData { - required CollectedClientAdditionalConfirmationData confirmationPrompt; + partial dictionary CollectedClientDataExtensions { + USVString confirmation; }; - The {{CollectedClientConfirmationData}} dictionary inherits from - {{CollectedClientData}}. It contains the following additional field: - -
- : confirmationPrompt member - :: The full context of the confirmation to give. -
- - - - dictionary CollectedClientAdditionalConfirmationData { - required USVString confirmationPrompt; - }; - - - The {{CollectedClientAdditionalConfirmationData}} dictionary contains the following - fields: - -
- : confirmationPrompt member - :: The full context of the confirmation to give. -
- : Client extension output :: Returns the value [TRUE] to indicate to the [[RP]=] that the extension was acted upon. From 4e30789868eab3ef8a515e10fb1ed6347132c0cc Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Mon, 17 Jun 2024 10:33:13 +0200 Subject: [PATCH 18/20] error corrections --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 01ab3f0eb..5ababa168 100644 --- a/index.bs +++ b/index.bs @@ -7621,7 +7621,7 @@ Example uses cases could be "I want to move $1234 from account A to account B" o 1. use the {{CollectedClientConfirmationData}} structure containing the confirmation prompt instead of using the {{CollectedClientData}} structure. - 1. pass-through the extension to the authenticator (see "client extension output" below) + 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 @@ -7634,7 +7634,7 @@ Example uses cases could be "I want to move $1234 from account A to account B" o : Client extension output -:: Returns the value [TRUE] to indicate to the [[RP]=] that the extension was acted upon. +:: Returns the value [TRUE] to indicate to the [=[RP]=] that the extension was acted upon. partial dictionary AuthenticationExtensionsClientOutputs { boolean confirmation; From 9f2723f3cbba6f0d785200a97c132518ee92fbf4 Mon Sep 17 00:00:00 2001 From: rlin1 <rolf@noknok.com> Date: Thu, 20 Jun 2024 17:03:02 +0200 Subject: [PATCH 19/20] added note regarding user verification --- index.bs | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 650cd2c1c..87265577b 100644 --- a/index.bs +++ b/index.bs @@ -7691,7 +7691,7 @@ To <dfn abstract-op>Create a new supplemental public key record</dfn>, perform t ### Confirmation Extension (confirmation) ### {#sctn-confirmation-extension} -This extension allows for capturing user confirmation. A +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. @@ -7766,6 +7766,13 @@ Example uses cases could be "I want to move $1234 from account A to account B" o ) ``` +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) From af053d6717a865764eeefaf3e2b226ca13ad3dcc Mon Sep 17 00:00:00 2001 From: Rolf Lindemann <rolf@noknok.com> Date: Mon, 8 Jul 2024 11:49:20 +0200 Subject: [PATCH 20/20] clarified confirmation prompt beign displayed by authenticator or client --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 87265577b..e28dbcef7 100644 --- a/index.bs +++ b/index.bs @@ -7781,7 +7781,7 @@ of [[#sctn-verifying-assertion]] using these variables established therein: |cre 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. +1. If processing a response without the `confirmation` extension is acceptable by policy: Fall back to <code>|credential|.{{PublicKeyCredential/response}}.{{AuthenticatorResponse/clientDataJSON}}</code> entry and the verify the field {{AuthenticatorExtensionsClientInputs}}.{{confirmationPrompt}} in [=client data=] if authenticator extension output is absent. This field represents the value as shown by the client (and not the authenticator). # User Agent Automation # {#sctn-automation}