Webauthn: Transaction authorization extensions are registration and authentication extension?

[Kieun]

Section 9 describes the initial set of WebAuthn extensions. Each extension is registration and/or authentication extension depending on the use cases.
In case of transaction authorization, there are two defined extensions: TxAuthSimple and TxAuthGeneric.
And both extensions are registration extension and authentication extension at the same time, which means those extensions can be handled during create() or get() operation.
In UAF, transaction confirmation (In WebAuthn context, transaction authorization) is extended use case of authentication (getAssertion) with user private key.

As I understand it, the user needs to sign message including contents with credential private key instead of attestation private key to provide non-repudiation for the transaction authorization.
Thus, extensions for the transaction authorization might be not registration extension but authentication extension.

[emlun]

Do you mean that UAF requires an authentication operation in order to show a prompt to the user?

[Kieun]

Yes, transaction confirmation in UAF is extended authentication operation.
See followings description in UAF spec.

UAF supports both methods; they are called "Authentication" and "Transaction Confirmation". The technical difference is, that with Authentication the user confirms a random challenge, where in the case of Transaction Confirmation the user also confirms a human readable content, i.e. the contract. From a security point, in the case of authentication the application needs to be trusted as it performs any action once the authenticated communication channel has been established. In the case of Transaction Confirmation only the transaction confirmation display component implementing WYSIWYS needs to be trusted, not the entire application.

[emlun]

Then it indeed seems like UAF devices can't support txAuthSimple or txAuthGeneric for registration, but does that mean no other device should either? Some RPs might still want to be able to request those extensions from future devices that do support them for registration. UAF devices are allowed to simply ignore the extension for the registration ceremony.

[Kieun]

if the RP just needs to show a prompt to the user, RP may use web UI component instead of using those extensions.
The transaction authorization is for RP to ensure that the user is confirming the transaction content.
Thus, if the purpose of transaction authorization is for getting cryptographic proof of user confirmation of the content, the signature for the proof should be generated with user's private key.
If the signature generated with attestation key which is shared across same authenticators(model), the server cannot ensure that the signature is generated by the specific user.

[emlun]

Ah yes, that is true. However at registration time the RP does not yet trust the user's private key, only the attestation key, so no security would be gained by also signing with the user's private key.

I agree it raises the question of whether there's still a point in allowing the extensions for registration, but I think there is. Even if it's impossible to verify authorization by any particular user at this point, it still verifies authorization by whoever the new user is - unless the client controls a trusted attestation key, of course.

[AngeloKai]

Moving extension related issues to PR.

@equalsJeffH @nadalin @YubicoDemo for tracking.

[selfissued]

It seems that these should be an authentication extensions but not registration extensions.

[nadalin]

@akshayku any update ?

[akshayku]

I see a value of this extension being present during MakeCredential.

Signature signed by the authenticator will show that this extension was being used or not. If RP can accept the key creation itself by trusting the signature by attestation certificate, I don't know why this extension being present is not considered secure especially with a fact that nonce is also being signed.

So even if it is signed by attestation certificate, nonce gives that binding if RP is so concerned.

I would close this issue as I don't see the problem here.

[equalsJeffH]

on 18-Jul call we decided to modify the spec such that this is only to confirm a transaction via a #getAssertion operation. we need a PR to implement this decision.