Add non-repudiable signature and sealing capability

[sander]

For some use cases it is important to know whether a wallet/agent enables its holder to create non-repudiable signatures or seals on behalf of a credential subject. In practice this always requires a common trust framework to handle disputes about whether the holder indeed created the signature or seal.

For example, the EUDI Wallet is required to provide citizens the ability to create qualified electronic signatures. An organisation wallet may be able to seal outgoing messages to prove authenticity of the message.

I suggest to add a field:

• ID: nonrepudiationTrustFramework
• Type: zero or more selections, comma-separated
• Options:
  • eidas_qes: EU/EEA Trusted List qualified electronic signatures or seals under eIDAS
  • any non-eIDAS frameworks applied in practice?

[maaikevanleuken]

Ties into sole control.

Discussed during meeting: Qualified signatures - public key digital signature, key gen and signature under eIDAS spec Advanced electronic signatures - public key digital signature Simple electronic signatures - image of handwriting, no crypto

[cre8]

I think such a requirement is too specific and depends on too much factors. QEAAs for example need to be signed by eIDAS, open for EAA. For the PID are multiple approaches like signature or authenticated channel.

So I would like to close this and come back to it when eIDAS is ready and the requirements for EUDI Wallets are final so see what are relevant parts and what not

[sander]

I think such a requirement is too specific and depends on too much factors. QEAAs for example need to be signed by eIDAS, open for EAA. For the PID are multiple approaches like signature or authenticated channel.

So I would like to close this and come back to it when eIDAS is ready and the requirements for EUDI Wallets are final so see what are relevant parts and what not

@cre8 you’re commenting about issuer signatures. My suggestion was about the ability for the wallet user to create signatures, for example on PDF or XML documents. This is a common feature in several EU wallets under the 2014 eIDAS and more wallets are implementing it now that it’s required in the 2024 revision.

[cre8]

I think such a requirement is too specific and depends on too much factors. QEAAs for example need to be signed by eIDAS, open for EAA. For the PID are multiple approaches like signature or authenticated channel. So I would like to close this and come back to it when eIDAS is ready and the requirements for EUDI Wallets are final so see what are relevant parts and what not

@cre8 you’re commenting about issuer signatures. My suggestion was about the ability for the wallet user to create signatures, for example on PDF or XML documents. This is a common feature in several EU wallets under the 2014 eIDAS and more wallets are implementing it now that it’s required in the 2024 revision.

No, also when presenting credentials when the holder signs it with a private key, see the different options we have in the German architecture proposal: https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/flows/PID-AuthenticatedChannel-eIDcard/

In the last meeting we agreed that we want to add a new category: active eudi wallet, flagging all wallets that are in production or at least in the EU list of certified EUDI wallets.

Form a "demand" perspective I would rather add a feature like "QES support", because in the EU we have as you mentioned the eIDAS defining rules to make it non repudiable.