Re: AW: Technologies with promise (was: EU Payment Wallet Standards)

Yeah, none of these requirements being set align with the goals we’re trying to solve. Looking at stablecoins which move billions of dollars online already (Turkey, Argentina, Nigeria, and Vietnam are leading countries in adoption) what they really need is a better key management option. Simple key theft via malware (look at infostealer malware which attacks the OS keychains) is one of the most common ways to steal stablecoins. However the user should have the choice to move their keys from one wallet to another also. So while it’s interesting that’s a path you’re taking, I want to call out that we’re not placing the same constraints on the problem based on developer feedback of what they say they need. In the cases where passkeys are being used the reason wallet developers use it is because they are theoretically the only way a page can get access to a hardware backed key. Although, the user can choose to store the key in like a password manager and undermine the security the site developer thought they were getting.

Similarly, the reason for Webcat is to avoid hacks like the Bybit hack [1] where the JavaScript calldata was compromised in a supply chain attack and that modified where the funds were sent to. Webcat becomes a JS integrity layer for the page to make it easier to detect when a supply chain attack like this occurs. It’s also useful for Web based secure messaging apps or web applications like secure drop where you want a high degree of certainty the integrity of the application isn’t being compromised to eavesdrop.

These are all solutions focused on practical attacks we’re seeing on the Web already. That’s the primary focus with these solutions is to have the browser help them out more. Similarly in cases like secure messaging or secure drop they need symmetrical keys not asymmetrical keys and there’s been an issue relying on the PRF extension because it’s never clear which authenticators will actually support the extension.

So yeah all this to say, I think we’re solving different problems. We’re focused on preventing attacks that are already happening. I think you’re working on building some trust certification system via a client side hierarchical PKI.

-Kyle

[1] : https://www.cyfrin.io/blog/safe-wallet-hack-bybit-exploit

-------- Original Message --------
On Monday, 06/15/26 at 10:46 Steffen Schwalm <Steffen.Schwalm@msg.group> wrote:

> Hi all,
>
> „It maybe also enables having a PID issued to a hardware-bound signer, which can then create qualified signatures. In the eidas context, consumer hardware can effectively become a QSCD. (I would appreciate Steffens input here, on what would actually be possible in terms of satisfying eidas requirements”
>
> - How the hardware-bound signer gets its qualified certificate to create qualified signature? If the hardware bound signer is part of EUDI, the EUDI becomes by definition part of QTSP, since qualified signature to be provided by QTSP (issuing certificate and/or remote signing) only
> - Consumer hardware shall fulfil the requirements from CEN EN 419 241 incl. certification – means it becomes de facto HSM + SAM – is not impossible but increases the complexity for consumer hardware and so limits the possible mobiles to be used
>
> What could be option is to use eSIM and move the hardware-bound signer on eSIM – even it would mean Telecom providing eSIM may become QTSP or need to possibly adjust eSIM somehow – but issue on complexity for mobiles remains.
>
> Best
>
> Steffen
>
> Von: Jori Lehtinen <lehtinenjori03@gmail.com>
> Gesendet: Montag, 15. Juni 2026 00:18
> An: John Bradley <jbradley@yubico.com>
> Cc: Kyle Den Hartog <kyle@pryvit.tech>; Manu Sporny <msporny@digitalbazaar.com>; public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
> Betreff: Re: Technologies with promise (was: EU Payment Wallet Standards)
>
> Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk always remains. Only open attachments and links from known and trusted senders.
>
>>> For PRF you can tell how it is backed based on the attestation returned in makeCredential.
>
> Good to know. I need to look into that and make it possible to display that information to the user in my wrapper.
>
>>> That said, PRF is not ideal for signing keys in many circumstances. There is a new WebAuthn extension for raw signing with derived keys. https://github.com/w3c/webauthn/pull/2078
>
> Yes! I've been dreaming of the ability to sign arbitrary data with WebAuthn.
>
> I think a combination of approaches is needed. My view is that an identity and its associated capabilities/credentials, liabilities/contracts, and all data should be recoverable/accessible/usable across multiple linked devices, with a replica of the main capability to access these protected by hardware-bound encryption of each device and then that main cap would allow to access resource specific capabilities that are used to authorize and encrypt relay of changes between devices.
>
> High-assurance signatures could be delegated to hardware-bound signing credentials when stronger guarantees are required. For example that decentralized identity could issue a delegation informing others to verify x actions with that hardware bound signers verification keys.
>
> It maybe also enables having a PID issued to a hardware-bound signer, which can then create qualified signatures. In the eidas context, consumer hardware can effectively become a QSCD. (I would appreciate Steffens input here, on what would actually be possible in terms of satisfying eidas requirements)
>
> However, this is only the first step (super important step). Some form of Byzantine fault-tolerant distributed ledger for the public stuff like the hardware-bound credential's identifiers and its associated verification material is also required.
>
> I think all of this is essentialy distributed editing and that is one reason why I consider CRDTs as one important primitive. Many know them just for collaboration software (which eveything including more than one actor essentially is (realtime or not) :p) but I see them as a tool for decentralized deterministic interpretation of any data model and the changes made to it (causality what happend after what etc. idependent of delivery order). Every one actively ensures on their own part that the rules are followed. malformed data can be ignored, conflicts can be noticed (eg. a fork in a log gets flattened in to sequence according to causality rules and next signature after fork doesn't verify -> fork attempt gets dropped/ignored) and entities that break the rules can be noticed and isolated/ignored. Eventually when everyone just gets the data everyone agrees on the same correct state without the need for further communication, also essential for offline support it is possible some changes mase on a temporary offline device arrive later than some changes made when after that on a device that is online, so here they ensure that the offline one is dropped if the online one was made later even if the offline one arrives later.
>
> That went a bit of the rails :p
>
> In any case, that WebAuthn extension for raw signing is valuable, important and awesome work. I love it.
>
> This is true decentralization, and true high-assurance security.  ❤️‍🔥
>
> su 14. kesäk. 2026 klo 23.22 John Bradley <jbradley@yubico.com> kirjoitti:
>
>> For PRF you can tell how it is backed based on the attestation returned in makeCredential.
>>
>> That said PRF is not ideal for signing keys in many circumstances.
>>
>> There is a new WebAuthn extension for raw signing with derived keys.
>>
>> https://github.com/w3c/webauthn/pull/2078
>>
>> That is targeted more towards digital credential wallets.
>>
>> Yubico released a preview version of the extension that is being tested by several wallets for feedback to the spec.
>>
>> In Europe CC certification is needed for wallet secure cryptographic devices (WSCD) firing initial EUDI wallet implementations to use cloud HSM. That is neither scalable nor truly privacy preserving in my opinion.
>>
>> We do need solutions for certifiable cryptographic elements under the users control.
>>
>> Regards
>>
>> John B.
>>
>> On Sun, Jun 14, 2026 at 11:42 Jori Lehtinen <lehtinenjori03@gmail.com> wrote:
>>
>>> A hardware-backed key management extension would be great.
>>>
>>> I'm currently using WebAuthn PRF as a workaround to obtain hardware-bound entropy that can then be used to recover encrypted keys stored remotely (with local caching).
>>>
>>> As I understand it, WebAuthn does not guarantee that the entropy is always backed by a local user-agent HSM; the credential may be backed by other authenticator implementations, including synced or remote passkey ecosystems. However, it does provide a deterministic source of entropy tied to a device, allowing a frontend verified controller of a device to always resolve the same entropy and recover other secrets that are protected via encryption.
>>>
>>> Here is my convenience wrapper around WebAuthn for this use case:
>>>
>>> https://www.npmjs.com/package/@sovereignbase/hardware-bound?activeTab=readme
>>>
>>> That is just a helper to obtain the PRF bytes; all of the key management, backup, and recovery logic still needs to be built around it.
>>>
>>> su 14. kesäk. 2026 klo 21.23 Kyle Den Hartog <kyle@pryvit.tech> kirjoitti:
>>>
>>>> I only heard about KPS this week, so still want to do some additional digging on it. I want to do some experimenting with it to see what it takes to implement it and what a spec might look like. This is still like the idea stage of the incubation stage, so very early.
>>>>
>>>> As for the web crypto extension, I’d enjoy to get some feedback from sites that would like to rely on it. Much comes from the idea of Web Wallets, but it’s not clear if another browser vendor would be open to implementing it. So, I think as a starting point giving a +1 to the WICG proposal and sharing it with other vendors is the next step.
>>>>
>>>> https://github.com/WICG/proposals/issues/214
>>>>
>>>> Another thing we are also looking at which would be useful as a web primitive and I’ve been implementing to test out is Webcat:
>>>>
>>>> https://webcat.tech/
>>>>
>>>> It would be useful to understand what sites would need to make this feature of the Web Platform easier to use. For example, I don’t know how it would work well with a site that does A/B testing.
>>>>
>>>> -Kyle
>>>>
>>>> -------- Original Message --------
>>>> On Sunday, 06/14/26 at 15:11 Manu Sporny <msporny@digitalbazaar.com> wrote:
>>>> On Thu, Jun 11, 2026 at 11:45 PM Kyle Den Hartog <kyle@pryvit.tech> wrote:
>>>>> Yes, and that’s why I’m interested in alternative options for the Web platform like with ideas like this: https://voltrevo.github.io/kps/
>>>>
>>>> This is neat -- is it coming to Brave, Kyle?
>>>>
>>>>> This is also why I've proposed https://github.com/brave-experiments/hardware-backed-webcrypto as an alternative to decouple hardware bound keys from the phishing resistant mechanism.
>>>>
>>>> Oh, yes, please. What can we do to help you push this forward at W3C,
>>>> Kyle? We've been asking for this for over a decade now... do you have
>>>> any timelines you could share?
>>>>
>>>> -- manu
>>>>
>>>> --
>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>> Founder/CEO - Digital Bazaar, Inc.
>>>> https://www.digitalbazaar.com/