Skip to content

Commit

Permalink
simplified approach
Browse files Browse the repository at this point in the history
  • Loading branch information
rlin1 committed Dec 21, 2023
1 parent 20d556a commit f974726
Showing 1 changed file with 16 additions and 13 deletions.
29 changes: 16 additions & 13 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -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;
};
</xmp>

: 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


<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.
Expand Down Expand Up @@ -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.
<xmp class="idl">
partial dictionary AuthenticationExtensionsClientOutputs {
USVString txAuthSimple2;
USVString txAuthSimple;
};
</xmp>

Expand All @@ -7741,11 +7743,12 @@ txAuthSimpleInput = (tstr)
</pre>

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

<pre>
CDDL:
Expand Down

0 comments on commit f974726

Please sign in to comment.