webauthn
webauthn copied to clipboard
w3c
Improved version of extension for Transaction Confirmation
supporting security keys or platform authenticators to show the transaction. Also supports the platform to show the transaction text. If the client displayed the transaction text but not the authenticator (for example when using a security without display), the transaction text will be only included in the collectedClientData - similar to what SPC is doing. If the authenticator showed the transaction text, it will also be included in the extension that was signed by the authenticator (known and potentially attested entity showed the transaction text as opposed to a unknown client).
To be decided: should we change the extension name back to txAuthSimple?
Pro: Authenticators that implemented it would still work and don't need a change.
Can it harm: Don't think so. Clients never practically supported the extension and the functionality change relates to the clients.
@christiaanbrand or @rlin1 can you join a WebAuthn WG call in March to discuss this?
We would love to see this extension added to L3 and get browser/OS support. It is fundamentally relevant - even crucial - for any PSD2 regulated bank and other financial institutions.
@christiaanbrand or @rlin1 can you join a WebAuthn WG call in March to discuss this?
I plan to join the call on March 6th.
I want to vouch for this for the reason already mentioned - without the ability to send transaction data to an authenticator in a way it can display them to the user (what you see is what you sign), achieving compliance in banking will be difficult for any FIDO2-related efforts. Standards such as Secure Payment Confirmation help a bit, but having the extension available would be much appreciated.
Most important stuff has already been mentioned by @rlin1, @FlxMgdnz and @petrdvorak. Thank you! Having the option to send/display some data (ideally) on the authenticator would be greatly extend the usage for FIDO2/Passkey beyond authentication/sign-in usecases and open it up, e.g. for financial usecases (regulated by PSD2) that require the secure display of transaction details. But it is actually helpful for all usecases where it makes sense to show a user a compact information WHAT he is actually doing, in a way that is almost impossible to modify by malware and such.
Maybe one more "storytelling comment" on this...
When we started working on our FIDO2 HW token about two years ago, I read through the FIDO2 documents and thought: "This is great. We can send a challenge to an authenticator, and it will sign it."
Then we started implementing things and found out that clientDataJSON, which actually contains the challenge, is essentially useless as the bearer of the data, as it is sent to the authenticator ironed out via SHA256 hash. While I understand the need for efficiency in interfaces like NFC/Bluetooth/USB (after all, some enterprises probably still run their COBOL apps on Windows 95), this is a neat candidate for abstraction in the standard so that we can decide to send clientDataJSON as a plain-text form to the authenticator, rather than hash and use the challenge itself for the WYSIWYS purpose.
From the specification, I understand the clientDataJSON structure is the following:
dictionary CollectedClientData {
required DOMString type;
required DOMString challenge;
required DOMString origin;
DOMString topOrigin;
boolean crossOrigin;
};
So, practically, it is something like this (non-minified, intentionally randomly found a bank with a long name, and used long challenge):
{
"type": "webauthn.get",
"challenge": "cb48493c-a0c7-4a9d-9aed-a172724d4357&A1*A100CZK*ICZ2730300000001165254011*D20180425",
"origin": "moldindcondbank.md",
"topOrigin": "moldindcondbank.md",
"boolean": false
}
Is this so horrible in terms of size? I mean... the SHA256 hash almost makes the payload longer. ;-)
Maybe one more comment from my side after extensive reading on this subject (apologies, but I am fascinated that a challenge-response protocol does not allow sending the challenge to the authenticator in plain form, or at least augment it with custom data).
From what I understood, one of the reasons why web browser vendors did not implement txAuthSimple extension was that they did not want to display data provided by the relying party (web page) in the browser UI. We can live without this - no need to display anything. This is why we added a display to our authenticator. The user can only see the challenge data / associated data in the authenticator - we are OK with this. We just need a way to sneak structured data to the authenticator.
I still think the best way to do this is not to destroy the challenge object by hashing it, but having an extension that works the best effort is enough.
Maybe one more comment from my side after extensive reading on this subject (apologies, but I am fascinated that a challenge-response protocol does not allow sending the challenge to the authenticator in plain form, or at least augment it with custom data).
From what I understood, one of the reasons why web browser vendors did not implement
txAuthSimpleextension was that they did not want to display data provided by the relying party (web page) in the browser UI. We can live without this - no need to display anything. This is why we added a display to our authenticator. The user can only see the challenge data / associated data in the authenticator - we are OK with this. We just need a way to sneak structured data to the authenticator.I still think the best way to do this is not to destroy the challenge object by hashing it, but having an extension that works the best effort is enough.
I agree that it would be a good first step to simply hand over tx data to authenticators and enable scenarios where dedicated hardware authenticators with display capabilities can be used. Ultimately, we should aim for platform support, as this will have a much bigger impact.
From what I remember, there were concerns about tx data formatting and encoding, which need to be handled in secure context where you'd want as little of such complexity as possible. So the challenge is to define a format that is comprehensive enough for a user to understand what they are signing off, but simple enough for the platform providers' implementation teams to follow.
OK, it makes sense.
One solution could be just to ask the RP to provide a meaningful message, as you suggest.
If a structured data is required, I can contribute my experience in this by suggesting formats to look into, then. If this is primarily about payments and PSD2 (as many people above suggest), you can look into:
- SPAYD (short payment description) which I "invented" and is used on every invoice in the Czech Republic.
- EPC Code the same thing, proposed on European level
In our systems, we wanted to have more generic data encoded, so we took the experience from above to design a generic data payload format for operation data.
As a result, it allows you to encode data such as payments, or configuration changes into the short fixed format payload, i.e.:
Example 1
A1*A100CZK*ICZ2730300000001165254011*D20180425
Payment of 100 CZK to IBAN CZ2730300000001165254011 with associated date 2018-04-25.
Displayed as:
AMOUNT: 100 CZK
IBAN: CZ2730300000001165254011
DATE: 2018-04-25
Example 2
A0*TClosing Ticket*R32784237923
Confirmation of closing ticket with reference ID 32784237923.
Displayed as:
MESSAGE: Closing Ticket
REFERENCE: 32784237923
I agree that it would be a good first step to simply hand over tx data to authenticators and enable scenarios where dedicated hardware authenticators with display capabilities can be used. Ultimately, we should aim for platform support, as this will have a much bigger impact.
I need to agree with Felix here. We need a solution that has browser/platform authenticator support, otherwise we won't have enough reach. While not the kind of security as with roaming authenticators, it would be still a major step forward from signing "something shown on the website".
From what I remember, there were concerns about tx data formatting and encoding, which need to be handled in secure context where you'd want as little of such complexity as possible.
Exactly. There won't be many - if any - formatting options. Thanks for the screenshot, I hope I can use it in our internal marketing slides for FIDP/passkey :-). It helps to understand what MAY be possible in future.
If a structured data is required..
I worked a while ago on some similiar templates/patterns like SPAYD and EPC Code for other QR-code like graphics. It was horrible to design and you quickly get into issues with languages and still missing use cases, so after a couple of years we have many usecases that are ending up in the "plain text" variant, while there was no fitting variant. And this was mainly for the banking branch and some generic service usecases. So even in the case we would support a format for structured data, we always need to keep it optional and require always a plaintext as alternative. Currently I would argue that anything else than plaintext is nothing that could be achieved easily, especially when there were concerns by the browser vendors even for the plaintext variant - I did not know this, interesting!
@mage28 Structured data can accommodate any use case where the plain text is sufficient, i.e.:
A0*TAny text with in any language to be displayed...
But I get the point.
Currently, we designed a way to have some workaround for this:
- We will support
txAuthSimpleas proposed in this PR (for when it is supported) - We will hack
hmac-secretextension as a carrier of data to authenticator as workaround (we are OK with 64 bytes it gives us)
I am very much in favor of reintroducing the txAuthSimple extension for all the reasons already mentioned above.
I agree with @mage28's arguments for using plain text in the txAuthSimple extension. After all, I think it was named "simple" for a reason. It should be as simple as possible to support by all parties involved and you can't get any more basic than plain text. Dealing with structured data is a job for something like txAuthGeneric which had a contentType field to specify how the data should be interpreted. I am not disputing @petrdvorak's statement that "structured data can accommodate any use case where the plain text is sufficient", but I am a bit worried that adding any complexity could become a blocker for wider adoption of the txAuthSimple extension.
One thing that deserves discussion IMHO is how to handle the fact that the authenticator may insert line breaks if needed. The question is whether the authenticator extension output should include the line breaks, like in the earlier L1 version of the spec, or exclude them, as is the case of the present PR. I can see arguments on both sides. If the way the message is displayed on the authenticator is broken up such that the user misinterprets its meaning, then there can be legal consequences. The signature issued by the authenticator should therefore reflect the exact string that the user authorized so that it can serve as evidence in case of a dispute. On the other hand, this of course puts extra work on the relying party, because it needs to evaluate whether the returned txAuthSimpleOutput is acceptable. In the simplest case this could just mean replacing all line breaks in txAuthSimpleOutput with spaces and comparing to the original transactionText. But things can quickly become more complicated, for example, with narrow screens which may require breaking up long words or other expressions without spaces, e.g. IBAN.
I am OK with keeping the content plain text. Anything is better for us than nothing. 😊
@andrewkozlik I have spent quite some time in mobile banking, dealing with various screen sizes and varying line-break outputs. This does not present a problem in practice. I would even say that the WYSIWYS principle is even more open. You always sign some bits, but you never see those - WYSIWYS does not have to take into account:
- font family, color, and size (which the user can modify by enabling color filters or assistive features)
- text breaking on a display (which may depend on screen resolution)
- symbol replacement (i.e., changing EUR for € sign)
- even the localization (meaning it is OK to see the "Please approve payment of 100.00 EUR to account 123123/0100" message while signing byte representation of
A2*A100.00EUR*Q123123/0100, as long as you can justify the texts have equal meaning and the mapping is correct, plus this allows you to change language dynamically)
After all, at various points, you need to trust the system for the correct WYSIWYS, i.e., the display has to display what you tell it to (which is kind of expected), the fonts installed in the system must result in displaying the right message, the payload itself may use different representation along the way (plain text, Base64, ...), etc.
We have confirmed this principle when discussing signing in our mobile authenticator.
As a result, if we put some text in the txAuthSimple, I would argue that we should work with this text "as is" in anything related to cryptography. Authenticators can put any formatting to the text for presentation purposes, but this should live independently from signing...
Hello @rlin1, could you please provide some context behind renaming the extension? We are OK with a different name, just curious...
Consider using a short name for the extension "conf" - instead of "confirmation".
Consider using a short name for the extension "conf" - instead of "confirmation".
... configuration... conference... You might be overthinking it, keep the name descriptive. 😊
Edit:
strlen('txAuthSimple')
12
strlen('confirmation')
12
Is introducing the confirmation length limit (1024 bytes?) helpful or harmful? What do you think?
Is introducing the confirmation length limit (1024 bytes?) helpful or harmful? What do you think?
likely helpful. Potentially even shorter...
Is introducing the confirmation length limit (1024 bytes?) helpful or harmful? What do you think?
Characters or bytes? Practically 1024 is more than sufficient, probably you will need to stick with very short and clear text informations, probably of less than 100 or 200 characters. So setting a max length limit of 1024 is surely not harmful for all usecases I can imagine and sets some technical restrictions. It can potentially be even shorter, but then we start to discuss when it starts to hurt the one or other.
@mage28 We are looking at this from the connected authenticator perspective, so bytes are a bit better measure of the data transfer limit. For our use case, the typical message will be much shorter. Even rich transaction details are shorter, i.e.:
Please approve a recurring payment of 43,289.99 EUR from an account
FI211234569876543210 to account IE64BOFI90583812345678, payment
reference: 9458711390468640.
(160 characters)
Note: PSD3 might change the scope of dynamic linking, so that the authentication code is linked to an amount, currency, destination account, and source account, at least.
256 or 512 or 1024 bytes (not chars) including the zero terminator char, please.
That is 255 or 511 or 1023 printable bytes.
This will make the implementation so much easier for constricted embedded environments.
@prusnak Reading through the conversation, this will primarily be about platform authenticators. Also, regarding the "confirmation" naming semantics, I read it as "it is the text the user can see in Windows UI alongside the standard confirmation window"). As a result, the JavaScript code will likely work by just providing a text... I would suggest keeping this USVString ("characters") and trimming the limit to 256 characters (which is plenty, as my example above suggests). UTF-8 encoding will result in at most 1024 bytes and will fit the zero terminating byte, or will fill the limit (CTAP protocol should hopefully take care of working with the data as bytes).
To continue our efforts to implement WYSIWYS in the connected authenticator: We found that besides not having txAuthSimple, even hmac-secret is not implemented as expected.
We were a bit desperate, as we really needed to get the data to the connected authenticator device so that the user could confirm it... and we managed to hack it.
By only supporting non-discoverable credentials, we get the list of allowCredential in WebAuthn, and - voila - this is the only data bundle we can pass in the authenticator and obtain it without modifications. So, we now append our challenge to the credential ID. Our authenticator can interpret this. Other authenticators don't need to care. Credential ID is not them. We then also compute a proprietary signature response (still conforming to ES256), binding the "plain challenge" we get in allowCredential list to the "hashed challenge" constructed from ClientDataJSON by the WebAuthn protocol... Cool, it works. It is ugly. But it works. We can do better...
Introducing "WebAuthn2: This time, we will get it right.", starring Steven Segal.
The signable challenge is in Verifiable Credentials format so that it is signed by the relying party, and the browser (or connected authenticator) can display it, as it is a standard format. Then, signing the challenge in the authenticator (platform or cross-platform) results in a Verifiable Presentation.
Is there any effort alongside this outline?
2025-03-26 WG call: this hasn't been discussed in quite some time, and the last time it was discussed there were concerns around untrusted text in a trusted UI. Planning to close this at the next meeting unless there is activity.
2025-03-26 WG call: this hasn't been discussed in quite some time, and the last time it was discussed there were concerns around untrusted text in a trusted UI. Planning to close this at the next meeting unless there is activity.
That does not sound good. Does it mean trying putting it to the backlog again? Concerns are still from Browsers vendors? Concerns on security issues even with plain text? From the users perspective, the idea behind is to provide the best possible option to provide information what actually is authenticated/signed. Can we perhaps more details on concerns or impact? It really hinders the introduction of FIDO2/Passkeys as an alternative method of transaction signing.
I fully agree with @mage28 — building a challenge-response protocol support that does not allow showing the challenge in the authenticator and actively defending the decision requires skills.
- Why is this not a problem for Secure Payment Confirmation? Or will this be canceled, too?
- Would providing signed content (like verifiable credentials) help?
There is also a recent public statement from the german DK / GBIC proposing their interest in this feature: https://die-dk.de/en/topics/article/gbic-statement-secure-display-transaction-data-fido2-standard/