- From: M.A. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Mar 2024 11:07:34 +0000
- To: public-webauthn@w3.org
> 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 authenticators, it is 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 not fitting variant. So even in the case we support a format for structured data, we always need an option was well as a fallback to plaintext. Currently I would argue that anything else than plaintext is nothing that could be achieve easily. -- GitHub Notification of comment by mage28 Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2020#issuecomment-1988183564 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 11 March 2024 11:07:35 UTC