digeorgi
commented
2 days ago Thank you very much for your input.
Use the Credential Trust Establishment spec at the Decentralized Identity Foundation instead of this. It is far clearer than the confusing system that is outlined above. https://identity.foundation/credential-trust-establishment/ Why ddi the ARF include all of this unnecessary complexity and confusion when DIF has a clear path forward that accomplishes same goals? It's a maze of references to understand which providers and relying parties are qualified failed to make clear how to identify a qualified issuer and a qualified verifier for a specific credential. It’s clearer for a PID, but obscure for any other credential in the system.
We did not study the specification you recommend in detail. At first sight, it seems to specify signed data structures containing a DID and some properties of the parties holding that DID, signed by some authority. Conceptually, this seems close to a certificate. We would therefore appreciate a more detailed explanation of how the DIF specification could solve the challenges we seek to solve by introducing access certificates, and why this solution would be less confusing.
Labeling a participant as ‘qualified’ or ‘approved’ with the ecosystem is insufficient. It is necessary to indicate for which credential schemas (collection of attributes) that participant is approved for issuance or verification. The ability to trust an entity for one type of credential and not another is critical to a healthy and diverse ecosystem.
Please note that QEAA Providers are legally trusted to issue any type of attestation. The ARF cannot limit this ability of QEAA Providers. However, we agree that this aspect is insufficiently described in the ARF, and we will clarify the descriptions. For more details, also see our response to #207
Description
Name: Heather Dahl, Sam Curren, Indicio
ARF Chapter: 6.3.2.2 PID PROVIDER OR ATTESTATION PROVIDER RECEIVES AN ACCESS CERTIFICATE "A PID Provider Access Certificate Authority or Attestation Provider Access Certificate Authority (CA) issues one or more access certificates to the PID Provider or to the Attestation Provider. A PID Provider or an Attestation Provider needs such a certificate to authenticate itself towards a Wallet Instance when issuing a PID or an attestation to it, as described in section 6.6.2.2. A PID Provider access certificate indicates that its subject is a PID Provider. Similarly, an Attestation Provider access certificate indicates that its subject is a QEEA Provider, a PuB-EAA Provider or a (non-qualified) EAA Provider. Note that the access certificate does not contain information about the authorization of the Provider to issue attestations of a specific type. Authorization is dealt with in the following manner: For PID Providers, QEAA Providers, and Pub-EAA Providers, no authorization is necessary, since these kinds of Providers are legally trusted by default. For EAA Providers, this is different. Without additional measures, a fraudulent EAA Provider may be technically able to issue types of QEAAs, PuB-EAAs or EAAs that it is not legally allowed to issue. To prevent this, the applicable Rulebook (see [Topic 12]) may define mechanisms allowing a Wallet Instance, during issuance of an EAA, to verify that the EAA Provider is authorised or registered to issue the type of EAA the Wallet Instance is requesting. The same mechanism may also be used by Relying Parties during presentation of an EAA."
Recommendation: Use the Credential Trust Establishment spec at the Decentralized Identity Foundation instead of this. It is far clearer than the confusing system that is outlined above. https://identity.foundation/credential-trust-establishment/ Why ddi the ARF include all of this unnecessary complexity and confusion when DIF has a clear path forward that accomplishes same goals? It's a maze of references to understand which providers and relying parties are qualified failed to make clear how to identify a qualified issuer and a qualified verifier for a specific credential. It’s clearer for a PID, but obscure for any other credential in the system.Labeling a participant as ‘qualified’ or ‘approved’ with the ecosystem is insufficient. It is necessary to indicate for which credential schemas (collection of attributes) that participant is approved for issuance or verification. The ability to trust an entity for one type of credential and not another is critical to a healthy and diverse ecosystem.