Topic B: Re-issuance and batch issuance of PIDs and Attestations

[sander]

Welcome to the discussion on Re-issuance and batch issuance of PIDs and Attestations, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on Topic B: Re-issuance and batch issuance of PIDs and Attestations discussion paper.

The paper provides background information, context, and initial proposals on re-issuance and batch issuance and open comments related to user authentication requirements and re-use of existing private keys. The paper explores challenges on:

• requirements around authentication of the User at re-issuance,
• requirements on batch issuance,
• requirements synchronous issuance of an attestation.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

@skounis and others feel free to edit and take over this discussion.

[sander]

1. Would you agree that re-issuance of PIDs and attestation must always be possible? If not, what would be your proposal? Do you have any issues with the technical solution outlined above? Do you see other solutions?

Yes, a Wallet Solution must make it possible. An Attestation Provider may choose to limit the re-issuance in its Terms and Conditions and reject new token requests. Note that batch issuance of attestations should also be possible in OID4VCI without including multiple public keys and proofs of possession. See #284 and openid/OpenID4VCI#359.

[sander]

2. Would you agree that batch issuance of PIDs and attestation must always be possible? If not, what would be your proposal? Do you have any issues with the technical solution outlined above? Do you see other solutions?

Yes, a Wallet Solution must support batch issuance. Note that for capacity management reasons, an Attestation Provider may prepare batches off peak hours, so the ARF should not expect the batch to be signed or sealed at the moment of request by the Wallet Unit.

[sander]

3. What do you think about the requirement that Users must not be involved in re-issuance processes for PIDs and attestations?

Agreed. But the PID Provider or Attestation Provider may invalidate the refresh token, and in this case Users should see an indication that the PID or attestation has become unavailable.

[rmayr]

"To the maximum extent possible, Wallet Providers, PID Providers, and Attestation Providers SHALL ensure that Users do not notice which of the methods referenced in requirement 3 is used for their PIDs, attestations, or WUAs, and that Users will not be involved in managing the re-issuance of new attestations." as written in the current text is problematic, because it does not leave the wallet an option to display to the user if, e.g. their single-use credentials have been used and a further re-use would make them trackable (linkable by and across RPs). Users not being aware of these trade-offs have no way to protect themselves from potential harm.

This should be reworded to not place a burden on users to manually care about renewing their tokens (which I believe is the main intent of this statement), but still be able to get information about the option being used and receive a warning if it falls back to a less-private option.

PS: Using a zero knowledge presentation method like BBS(+) would remove this issue altogether by letting user wallets "mint" new unlinkable credentials locally, completely solving the privacy issue discussed here. We still strongly recommend to implement this way in the medium term.

[david-bakker]

@rmayr : The requirement you quote is from Topic A, which confused me for a moment :-). Would you mind moving your comment to that discussion #354 ? Then we don't mix up topics (although I agree they are related.) Thanks!

[rmayr]

But is the core of this not in re-issuance of credentials? I assumed Topic-B to address exactly that. Sorry if that was a misunderstanding.

[sander]

4. What solutions do you see for ensuring that a re-issued PID or attestations is bound to same WSCD as the PID or attestation it is replacing? Do you agree with requiring that a Refresh Token used by the Wallet Unit to start the re-issuance process of a PID or attestation must be bound with the private key belonging to a PID or attestation currently present in the WSCA, by using the DPoP mechanism in RFC 9449?

Yes, this is the simplest solution. A key known by the PID/Attestation Provider to be associated may also be used. For example using #287

[sander]

5. Do you see other options for dealing with User authentication in re-issuance scenarios?

Multiple HDK and HDK-like solutions are possible. See #284. Requirement WUA_02 should be generalised sufficiently to enable such solutions. In all these solutions, the WSCD protects a device key (critical asset), which the WSCA can blind to obtain many associated public keys. The WSCA SHALL authenticate the User before performing any cryptographic operation involving the device key (critical asset).

[sander]

6. What do you think about option 1?

The suggested change to WUA_02 in option 1 is indeed infeasible.

[sander]

7. What do you think about option 2? Should we allow the re-use of public keys in the ARF? If so, under what conditions?

Option 2 may be useful for attestations that are yet to be presented, but is too risky as long as there is no common approach to ZKP.

[sander]

8. What do you think about option 3? Should we add the use of HDK in the ARF? If so, how exactly? Mandatory, optional? Do you know of any relevant limitations to HDK?

The ARF should make HDK possible. A group of specialists from the Large Scale Pilot consortiums have analysed prerequisites: #282. Additionally, we need support to evolve the common HDK specification in draft-dijkhuis-cfrg-hdkeys and the implementation in OpenID4VCI as started in openid/OpenID4VCI#359.

The ARF should also suggest using HDK with a reference to a concrete specification, to provide a complete reference architecture to Wallet Providers. It makes sense to recommend it as a option. Having clear reference architecture decisions, without too many options, makes implementation of a privacy-friendly ecosystem easier.

I see no problems with making HDK support mandatory. In order to gain support for such a decision we should carefully address the Feedback to resolve HDK and PoA issues in the ARF.

[sander]

@nikosft @paolo-de-rosa Could we have a call to discuss how we could contribute using (further development of) this spec?

[sander]

I’ve received some questions regarding the difference with the “distributed WSCD” from the Attestation Proof of Association (PoA) paper. To clarify, HDK supports two modes:

• § 2.3 The local HDK procedure
• § 2.4 The remote HDK protocol

The local HDK procedure can be considered a concrete specification for the “distributed WSCD” from the PoA paper. Although I would prefer to speak of a “distributed WSCA”, since the cryptographic hardware on the phone is typically not used during the primary process.

In case changes are needed to § 2.3 I would be happy to collaborate on these. For example, in case more formalisation and proofs are needed: we are now looking at reusing concepts from draft-irtf-cfrg-signature-key-blinding and the related Security Analysis of Signature Schemes with Key Blinding to fit better with existing IETF standardisation and research.

With the remote HDK protocol, we can achieve additional advantages, which should be weighted against the costs, and which are analysed with regard to the ARF in:

• Proof of association requirements to attestation providers
• Delegated key share generation

[sander]

9. What do you think about User authentication in batch-issuance scenarios?

This needs to be considered together with #333. The WSCA should only authenticate the User before creating a key associated with the first attestation, and subsequent batches may rely on this single authentication. Likely we can do with a single modified requirement WUA_02.

[sander]

This is sufficiently addressed in v0.5.

[sander]

10. Do you agree that the Wallet Unit should trigger the re-issuance process for the cases where the existing PIDs or attestations are about to expire, or where the Wallet Unit is running low on once-only PIDs or attestations? If not, what other solution do you see?

Yes, but as an optional, possibly user-configurable feature, up to the Wallet Provider. Users may not want their Wallet Unit to proactively contact many PID/Attestation Providers regularly.

[sander]

11. What do you think about the first option for the situation where re-issuance is necessary because of a change in the value of one or more of the attributes?

This requires a disproportional amount of energy and bandwidth for the edge case that an attribute changes and its user wants to avoid manual action.

[sander]

12. What do you think about the second option? Would the issuance model sketched above, where the Wallet Provider is involved in the logistics of the issuance process, be acceptable to you?

This may be a value-added feature provided by some Wallet Providers, but the tight coupling of Wallet Units to (presumably) centrally controlled HTTP services is not acceptable as a requirement. It creates a precedent to significantly complicate the ecosystem, just to make one of its roles seemingly easier to implement.

Indeed being a PID/Attestation Provider requires specialized knowledge and a dedicated infrastructure. Governments should leverage and stimulate the internal market for trust services to make this competence and infrastructure available at scale in the EU. For example, (public or private) trust service providers of QEAA could deliver trust service components to PID Providers for re-use.

[sander]

13. What do you think about the third option?

This is the most viable option. Following (EU) 2024/1183 recital (52), the ARF should encourage the deployment of e-delivery infrastructure to enable end-to-end communication channels between legal and natural persons such as PID/Attestation Providers and Users for structured messages. A Wallet Unit can be used to authenticate the User as a recipient in such e-delivery infrastructure initially, but could eventually be used as an agent for direct access to an e-delivery access point.

[sander]

14. Can you think of any other option?

Have the Wallet Unit automatically check for revocation and enable the User to request re-issuance if revocation is detected.

[sander]

This has now become the recommended option 4 in version 0.5.

[jogu]

1. Would you agree that re-issuance of PIDs and attestation must always be possible? If not, what would be your proposal? Do you have any issues with the technical solution outlined above? Do you see other solutions?

re: the text here: 3c521bd#diff-ddfe04e611152cf17ec83903a26e5c411186867a196cb0921c59a1254fba734eR100-R102

in particular:

during each re-issuance, a new Refresh Token is also issued to the Wallet Unit.

The reason for issuing a new refresh token is not clear to me and it may not be necessary if the refresh token is already sufficient sender constrained. (This so called 'refresh token rotation' is not usually necessary for security purposes with, for example, confidential OAuth clients where the refresh token is sender constrained by the client authentication.)

If it is necessary, then experience from OpenBanking ecosystems is that such rotation is often problematic and can lead to the client holding refresh tokens that don't work, e.g. in the case of trying to rotate an access token whilst the network connection is unstable. This led to e.g. https://openid.net/specs/fapi-security-profile-2_0-04.html#section-5.3.2.1 discouraging the rotation of refresh tokens and requiring that if they are rotated the old token remains temporarily valid so that the client can recover if it failed to receive the new token value on the first attempt - similar language might be necessary here.

[sander]

From version 0.4:

Using a HDK function, the PID Provider or Attestation Provider only needs to obtain a single public key from the WSCA. This happens during first-time issuance of a PID or attestation, where the User is involved in the process anyway and a request to authenticate will not come unexpectedly. During re-issuance, the PID Provider or Attestation Provider then uses this public key to derive unique per-attestation public keys from the received public key, without involvement of the Wallet Unit or the WSCA. These newly derived public keys are then sent to the Wallet Unit, and the WSCA can derive the corresponding private keys from the existing private key (i.e. the one generated during first-time issuance).

Please note that some details are not fully correct. Instead:

Using a HDK function, the PID Provider or Attestation Provider only needs to obtain a single public key from the WSCA, along with non-sensitive metadata required to apply HDK. This happens during first-time issuance of a first PID or attestation, where the User is involved in the process anyway and a request to authenticate will not come unexpectedly. During re-issuance or (batch) issuance of associated PID or attestations, the same or another PID Provider or Attestation Provider then uses this public key to derive unique per-attestation public keys from the received public key, without involvement of the Wallet Unit or the WSCA. These newly derived public keys are then sent to the Wallet Unit , along with non-sensitive metadata required to apply HDK, and the WSCA can effectively derive the corresponding private keys from the existing private key (i.e. the one generated during first-time issuance).

This is why we use “hierarchical”: one PID Provider or Attestation Provider may derive keys based on another PID’s or attestation’s public key.

The “metadata required to apply HDK” for example includes seeds and key handles for key derivation. We have worked with the OpenID4VCI authors to ensure that the protocol supports adding these.

In some deployments, the WSCA never fully derives the corresponding private key. For example, the WSCA may use multi-party signature schemes, or apply ECDH with multiple iterations. In those cases, WSCA derives key material that enables proving possession, as if it fully derived the corresponding private key. Therefore I suggest to use “effectively” in the description.

[sander]

Thanks for processing this feedback in v0.5. Only the suggestion "the same or another PID Provider or Attestation Provider" was not applied, but this makes sense as it touches another discussion topic.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments and responses on this topic.

topicB AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[sander]

Regarding option 3, we advise adding HDK in the ARF to support different features
requiring deriving unique per-attestation public keys (child keys) from an initial master
key. A reference to a concrete specification/architecture would be required to avoid
compatibility issues, such as those caused by different key derivation paths. Again,
implementing HDK may require a more complex infrastructure than the one required
with the current ARF. This additional complexity could introduce new threats, for
example linkability, that should be objectively assessed before adopting this solution.
This assessment could help select the best concrete specification/architecture for the
ARF in terms of data protection and privacy.

Thank you for sharing this comment. Based on this discussion, I have updated our proposal for a concrete specification in draft-dijkhuis-cfrg-hdkeys to version 02 to:

• provide a single HDK function as per the discussion paper
• explain in more detail how this can be used in an interoperable way
• provide complete instantiations for ECDH, ECDSA, EC-SDSA on P-256
• address linkability risks in HDK metadata by direct application of KEM

While the instantiations are based on elliptic curve cryptography, the generic specification using key blinding and KEM can also be applied to other algorithms including post-quantum cryptography.

I’m curious what the AEPD thinks about this proposal.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic B. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

AEPD: […] However, the re-issuance of PIDs and attestations must be transparent to the user. Individuals should be made aware when their personal data is collected for the first-time issuance and when and why their PIDs and attestations are going to be re-issued.

Response: Indeed, re-issuance is transparent to the user. In addition, the Wallet Unit shall log issuance and re-issuance transactions, and the user may be offered the option to receive notifications.

AEPD: Concerning their data protection rights, they should also be able to control this re-issuance process, including the ability to prevent it. […]

Response: In discussion with member states representatives, it was agreed that preventing re-issuance will result in the Wallet Unit having invalid attestations. We were not able to define a use case for this to be desirable. If users do not wish re-issuance they can delete the corresponding attestation from their wallet. This will result in the same outcome.

AEPD: As we already stated in our response to the discussion of topic A, synchronous issuing should be avoided because it allows the Attestation Provider to learn about the data subject's access habits. Asynchronous batch issuance should be used instead.

Response: In this paper we do not make any recommendation in favor or against synchronous issuance. Our goal is to capture requirements for cases where synchronous issuance is needed.

AEPD: If re-issuing PIDs and attestations, the newly issued attestations should be for the same purpose for which the original data was collected. Any deviation from the original purpose would violate the purpose limitation principle. The same reasoning applies to batch issuance.

Response: The purpose is the same as the first issuance.

AEPD: It is crucial to consider data retention periods for both the "old" PIDs and attestations (before re-issuance, from the last batch, etc.). Once the re-issuance/new batch issuance is successful, the "Old" versions should be securely deleted or archived.

Response: Indeed. This is captured by requirement 5.

AEPD: […] A better approach might be to identify the specific cases when a new PID or attestation is needed because the previous one has been revoked, expired, or is no longer valid for another reason (such as a change in attribute values), for example, before the re-issuance is permitted.

Response: In the updated version of the paper, we have made this distinction. The re-issuance process is triggered by monitoring the revocation status of its PIDs and attestations.

AEPD: […] If batch issuance is always possible, this could lead to unnecessary data collection or processing. A better approach might be to require a demonstration that a PIDs or attestation batch is needed because of concrete reasons.

Response: It is not obvious to us that batch issuance can result in unnecessary data collection or processing.

AEPD: As we have said before, we understand this requirement concerning explicit user actions, but the user must be kept informed and involved as a data subject. The transparency principle must be complied with, and the data subject must be allowed to exercise all their data protection rights about this re-issuance process.

Response: Indeed Annex 2 includes a requirement for logging re-issuance events. More details will be provided with topic H - Transaction logs kept by the Wallet.

AEPD: Regarding option 3, we advise adding HDK in the ARF to support different features requiring deriving unique per-attestation public keys (child keys) from an initial master key[...].

Response: As we mention in the paper “If we want to require support from Wallet Units and Attestation Providers for this technology, it needs to be further investigated. High Level Requirements for this option will be provided in a future specification.”

AEPD: [Reponses to questions 9 and 10].

Response: The updated version of the paper follows this approach.

AEPD: In general […] should be properly protected.

Response: Please note that another option has been added (option 4), which is the recommended approach.

AEPD: A value change in an essential or mandatory attribute should lead to the attestation revocation […].

Response: The updated version of the paper follows this approach.

[EricVerheul]

My comments and recommendations on Topic B version 20 January 2025.
Kind regards, Eric Verheul
Comments&Recommendations Topic B.pdf

[EricVerheul]

"ETSI 119 476 defines unlinkability at page 7 as "parties should not be able to connect the user's selectively disclosed attributes beyond what is disclosed."
If we introduce the binary attribute "PID-based" as I suggested in the PoA paper, then this could work in concert with this definition. If a user wants to prove a selection of attributes (from different attestations) are bound to the same PID, the user could reveal these binary PID-based attributes and prove this with a the PoA. This would not fully provide us yet with the full PoA-potential, but it would be a first start.

[AltmannPeter]

Verifier unlinkability can be solved through these means, and batch issuance could potentially be slightly improved by using PoA instead of HDK approaches.

PoA and HDK are two separate things.

1. PoA is a primitive to prove that two seemingly unrelated values (e.g., public keys) are, in fact, related.
2. HDK is an alternative to freshly generated keys.

HDK (or any key derivation approach to generating a batch of keys) can use many different types of PoA. Given the discussion here, I believe it is important to clarify their relationship. I will do so under the Topic K discussion (and in the updated ETSI 119 746 too) as it pertains to that topic.

Issuer unlinkabilty requires, to the best of our knowledge, either more modern signing schemes like BBS+ etc. or a ZKP at presentation (the ZKP-on-top-of-mdoc approach). Do we all agree on that assessment? I am still looking for other options, as both of these have their respective challenges (and why I was thrilled to potentially find a third one in this discussion)...

I agree on the assessment with the following note: In theory, you got a third option with Issuer blind signed attestations. This would require that the User prepares $N$ attestation commitments, and the Issuer asking to unblind $N-1$ and then blind sign the remaining one (with the User finalizing the Issuer signature by removing the blind). Practically, this is horribly inefficient. If the User can supply verifiably random salts, then the approach could potentially work for cases with extreme privacy requirements.

For ZKP-on-top-of-mdoc, the main challenge I see is certification. Specification and standardization we can probably achieve in fairly short (as these things go) timeframes, as the primitives themselves are pretty clear at this point. However, do we know of any certification lab that is currently set up to validate ZKP constructions? That's going to be a practical challenge (and maybe a business opportunity for certification labs ;) ).

I agree that the main challenge is non-technical.

PoA is still potentially very useful for multi-credential presentations, it just isn't another option to address the still-open issuer unlinkability problem we have with mdoc-like schemes.

PoA is arguably more useful for batch issuance where the Issuer needs PoA for all the keys. Again, I would move this discussion to Topic K (will create a post today).

[AltmannPeter]

@rmayr @EricVerheul @sander

I recommend we move PoA-related discussions to: #442 so that we can focus Topic B on batch and re-issuance.

[rmayr]

I agree on the assessment with the following note: In theory, you got a third option with Issuer blind signed attestations. This would require that the User prepares N attestation commitments, and the Issuer asking to unblind N − 1 and then blind sign the remaining one (with the User finalizing the Issuer signature by removing the blind). Practically, this is horribly inefficient. If the User can supply verifiably random salts, then the approach could potentially work for cases with extreme privacy requirements.

That was exactly the construction that triggered my initial interest. Do I understand correctly - and this is why I believe this sub-discussion makes sense in the scope of this topic - that it would only achieve a single issuer-unlinkable credential per N batch issued credentials?

[AltmannPeter]

I agree on the assessment with the following note: In theory, you got a third option with Issuer blind signed attestations. This would require that the User prepares N attestation commitments, and the Issuer asking to unblind N − 1 and then blind sign the remaining one (with the User finalizing the Issuer signature by removing the blind). Practically, this is horribly inefficient. If the User can supply verifiably random salts, then the approach could potentially work for cases with extreme privacy requirements.

That was exactly the construction that triggered my initial interest. Do I understand correctly - and this is why I believe this sub-discussion makes sense in the scope of this topic - that it would only achieve a single issuer-unlinkable credential per N batch issued credentials?

Correct. That approach would work with the EUDIW crypto limitations but is entirely unpractical. Only other "conventional" option I know is RSA based CL.

[sander]

Addressing three more critiques on HDK

I’m sharing some more notes from a discussion about HDK this morning, to enable public referencing and refinement. I’m only focusing on “remote HDK”: HDK when applied in interaction with the issuer, who can derive many public keys from a single (WSCD-bound) public key. In the notes below I’ll distinguish:

• cryptographic association (use of a blinding factor)
• functional association (meeting ARF PoA requirements)

Functional association can have legal consequences. While functional association may be implemented using cryptographic association, this may be insufficient. Functional association should be designed in such a way that cryptographic properties cannot accidentally lead to legal consequences.

Critique 1. Remote HDK introduces a new risk: a malicious issuer could derive a cryptographically associated public key, issue a document bound to it, and forge a functional PoA towards relying parties.

Rebuttal 1. As specified in ARF Topic 9, keys are only functionally associated once the WSCA registers them as being associated. Therefore the malicious issuer action alone is insufficient: they would also need to convince the wallet/user to accept the issued document and register the association in the WSCA.

The functional PoA towards RPs should therefore not merely be consist of a proof of knowledge of cryptographic blinding factors, but also of a WSCD-protected statement about the WSCA internal registry – e.g. a WSCD-created (blinded) digital signature over the PoA statement. This prevents the risk scenario.

Note that if user acceptance of documents is insufficiently specified in the ARF, that should be improved. This is in PKI an important concept, cf. RFC 3647 § 4.4.4 Certificate Acceptance.

Critique 2. Remote HDK potentially introduces legal scope creep: the WSCA may now also include the issuer.

Rebuttal 2. According to the (EU) 2024/2981 Art. 2(4) definition, the WSCA manages critical assets. While the original WSCD private key is a critical asset, the HDK blinding factor is not a critical asset as per (EU) 2024/2981 Art. 2(11), which defines critical assets as being “assets within or in relation to a wallet unit of such extraordinary importance that where their availability, confidentiality or integrity are compromised, this would have a very serious, debilitating effect on the ability to rely on the wallet unit”.

While blinding factors may be important for protecting documents, within and outside of wallets, they do not affect the ability to rely on wallets.

Note that even though we speak about “remote key generation”, in remote HDK the issuer only generates a blinding factor (in what is cryptographically called a contributory key encapsulation mechanism or KEM), as metadata to achieve the privacy goal of RP-unlinkability. Functionally you could compare this to the issuer generation of salts in the “salted hashes” approach to enabling selective disclosure. While both are metadata assets to cryptographically protect confidentiality in documents that are potentially held by a wallet, they are distinct from the WSCD-protected cryptographic assets required to protect integrity.

Critique 3. Remote HDK complicates the certification of issuer and wallet components and solutions.

Rebuttal 3. Taking the legal interpretation above, it is quite simple:

• wallet solution
  • WSCD
    • may support key blinding
    • may support KEM for use with key blinding
  • WSCA
    • shall keep an internal association registry
    • shall support (private) key blinding, either
      • using WSCD native support, or
      • within the application
    • shall support KEM for use with key blinding, either
      • using WSCD native support, or
      • within the application (already in place for TLS)
    • shall only register HDK with user permission
    • shall only apply HDK if registered
• issuer solution, if the issuer supports remote HDK
  • QSCD: no specific support needed
  • document creation application
    • shall support (public) key blinding
      • low risk: wallets detect incorrect implementations
    • shall support KEM (already in place for TLS)
      • low risk: contributory KEM compensates for weak RNGs
    • shall not unnecessarily persist personal (meta)data, including:
      • blinding factors
• issuer solution, if the issuer does not support remote HDK
  • QSCD: no specific support needed
  • document creation application
    • shall not unnecessarily persist personal (meta)data

Arguably, these are simpler requirements than when wallets and issuers would need to support functional PoA merely for the (batch) (re-)issuance of documents.

Note that remote HDK also addresses the “cross-issuance” use case where the user presents PID to an issuer, who then issues QEAA/PuB-EAA back to the user, for which the user can then create a functional PoA.

We will also need functional PoA in the ARF and someday in wallet/RP implementation, but designing and standardising functional PoA is easier when it is decoupled from the (batch) (re-)issuance use case, and limited to: #341

[AltmannPeter]

I’ll prepare a longer reply to address all the points later but I just want to clarify that PoA does not address unlinkability. Quite the opposite, [**EDIT: as Verheul correctly points out, A NIZKP**] generates a proof that two attestations are linked. You cannot achieve simultaneous issuer and verifier unlinkable attestations using standard crypto available to the eudiw. Issuers will be able to link presentations until we layer ZKP on top of MSOs / SD-JWTs. PoA is an entirely separate topic.

…

Sent from my iPhone On 18 Mar 2025, at 10:58, René Mayrhofer ***@***.***> wrote:  Thanks for the quick reply! It is clear that full unlinkability depends on the selectively disclosed attributes not allowing unique identifiabiliy, and the critical use case I have in mind are centered around public transport, age verification, etc. Thanks for confirming my first understanding that unlinkability in "distributed WSCD/WSCA" is achievable under issuer collusion. I agree that wallet/WSCA-derived keys are clearly preferable to issuer-derived keys for the two main reasons of privacy (unlinkability under honest-but-curious issuer models) and control of entropy/input (under broken/dishonest issuer models). This is why we previously suggested BBS+ or related randomizable key/signature approaches. There may be scalability disadvantages by the wallet having to trigger re-issuing, but those need to be evaluated/quantified to make any reasonable comments. Is there a statement on the patent situation around PoA, which seems to have triggered concerns? — Reply to this email directly, view it on GitHub<#354 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BADDEALQM5E2NXNLSQUJYF32U7U3LAVCNFSM6AAAAABTSNMCACVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGYYTOMI>. You are receiving this because you commented.Message ID: ***@***.***>

[EricVerheul]

Dear Peter,

it generates a proof that two attestations are linked.
True, but when - and only when - the user consents to this.
Also, for simplicity I only included the non-interactive Schnorr ZKP proving that keys are associated also as this fitted in OpenID4VC[I,P] quite neatly. Which indeed provides a non-reputable proof. But there is no reason - other than that it does not easily fit OpenID4VC[I,P] - to use the interactive Schnorr ZPK or better stil the “implicit zero-knowledge approach" from [1.] which I use extensively in my HSM-based wallet design [2.] as it is supported by a standard PKCS#11 HSMs. The interactive protocols are deniable. This is also mentioned on p.16 of the PoA paper (bullet 5).

[1.] Fabrice Benhamouda, Geoffroy Couteau, David Pointcheval, Hoeteck Wee, Implicit Zero-Knowledge Arguments and Applications to the Malicious Setting, Crypto 2015, LNCS, Volume 9216, Springer, 2015.
[2.] https://wellet.nl/SECDSA-EUDI-walletV3.pdf