Scope: High Level Requirements on Wallet Trust Evidence (Topic 9) and Relying Party handling EUDI Wallet attribute combined presentation (Topic 18)
Summary: The ARF requires generation and verification of a proof of association. There are many use cases where this is functionality would create unnecessary overhead and potentially provide more user metadata than minimally needed. For example, in an HDK architecture, PID Providers and Attestation Providers can be assured of association between trusted keys and newly generated keys by design, without additional proofs of association (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/284). The requirements should be adjusted to not require this functionality in all cases.
Context: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/282
Scope: High Level Requirements on Wallet Trust Evidence (Topic 9) and Relying Party handling EUDI Wallet attribute combined presentation (Topic 18)
Summary: The ARF requires generation and verification of a proof of association. There are many use cases where this is functionality would create unnecessary overhead and potentially provide more user metadata than minimally needed. For example, in an HDK architecture, PID Providers and Attestation Providers can be assured of association between trusted keys and newly generated keys by design, without additional proofs of association (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/284). The requirements should be adjusted to not require this functionality in all cases.
Detailed suggestions and rationale: HDK v0.1.0 feedback on Topic 9 regarding WTE_18, WTE_19, ACP_04, ACP_05, ACP_09.
ARF version: 1.4.0