Feedback and proposed changes to TS5 #477
Description
While analysing ETSI TS 119 475 V1.1.1 Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user's authorization decisions (#327) I found issues and wrote comments to ETSI where I made various proposals for fixing the issues in the standard. As the standard is based on TS5, my understanding is that certain issues need to be fixed in TS5 for ETSI to have the authority to make the changes I propose.
If it is of any help, I created JSON schemas based on the requirements, mappings, classes, multiplicity values and types presented in ETSI TS 119 475 and, in extension, based on TS5. The schemas describe the data structures of the WRPRC header area and of the WRPRC payload. Perhaps the schemas make it easier to understand how the multiplicities, types and other things defined in TS5 affect the data structure of WRPRCs. I published and made the schemas available at GitHub in https://github.com/response200/etsi-ts-119-475-wrprc-schemas repository. Please feel free to use the schemas in any way allowed by their licence.
Below is a list of issues with my proposed changes for TS5. Each issue is numbered and each of them have “Proposed change” and “Motivation of proposed change” sections. I am open to discuss any of the issues and make modifications to any of the proposed changes.
Comments and proposed changes to TS5
Comment no. 1
Proposed change
Please, rename the entitlement attribute to entitlements.
Motivation of proposed change
I propose changing the name of the entitlement attribute to entitlements as the attribute is an array of string-type entitlements.
Comment no. 2
Proposed change
Please, make the supervisoryAuthority attribute in the WalletRelyingParty class refer to a new SupervisoryAuthority class instead of the LegalEntity class.
Motivation of proposed change
Currently the supervisoryAuthority attribute refers to the LegalEntity class. The LegalEntity class is too generic and contains too many optional/unused attributes for it to properly act as the class for the supervisoryAuthority attribute and its subattributes email, phone and formURI (in the context of WRPRCs and perhaps in the context of the RP registry).
The ARF requirement RPRC_12 says that the registration certificate shall contain the name and country of the supervisory authority and it shall contain at least one of the following: the URL of a web form, an e-mail address, or a telephone number. The LegalEntity class does not adequately communicate these aspects of the requirement.
In order to have a more targeted class, to ensure compliance with RPRC_12 and to reduce the propability of some providers of registration certificates adding unnecessary information about the supervisory authority to their WRPRCs I propose the following changes:
- Define a new SupervisoryAuthority class.
- Define a new
nameattribute for the SupervisoryAuthority class with multiplicity[1..1]and type string. - Copy the
country,email, andphoneattributes from the LegalEntity class to the SupervisoryAuthority class. - Define a new
formURIattribute with multiplicity[0..*]and type string for the SupervisoryAuthority class. Having a specific attribute for the “URL of web form provided by the Data Protection Authority supervising the Relying Party, which Users can use to report suspicious attribute presentation requests” is better than trying to overload LegalEntity'sinfoURIattribute with many different meanings. - Make the
supervisoryAuthorityattribute in the WalletRelyingParty class refer to the SupervisoryAuthority class. - Explain in TS5 in a section about the SupervisoryAuthority class that at least one of
email,phoneorformURIattributes of the SupervisoryAuthority class should be populated and should contain at least one element (they are arrays) even though the multiplicity of the attributes is[0..*].
After these changes the supervisoryAuthority attribute should comply with the RPRC_12 requirement.
Comment no. 3
Proposed change
Please, make the providesAttestations attribute in the WalletRelyingParty class refer to a new ProvidedAttestation class instead of the Credential class.
Motivation of proposed change
The providesAttestations attribute in the WalletRelyingParty class and the credential attribute in the IntendedUse class should not refer to the same Credential class, because the claim attribute of the Credential class applies only to presentation requests (Service_Provider role), not to attestation issuance (QEAA_Provider, Non_Q_EAA_Provider and PUB_EAA_Provider roles). The providesAttestations and credential attributes should refer to distinct classes one of which should not have the claim attribute.
The ARF requirement RPRC_15 says that the registration certificate shall contain the type(s) of attestation that the PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA Provider intends to issue to Wallet Units. This makes it clear that the providesAttestations attribute should not refer to a class that contains the claim attribute.
In order to have a more targeted classes, to ensure compliance with RPRC_15 and to prevent mistakes in the issuance of WRPRCs I propose the following changes:
- Define a new ProvidedAttestation class.
- Copy the
formatandmetaattributes from the Credential class to the ProvidedAttestation class. - Make the
providesAttestationsattribute in the WalletRelyingParty class refer to the ProvidedAttestation class.
After these changes the providesAttestations attribute should comply with the RPRC_15 requirement.
Please also see my comment 8, where I propose removing “PID_Provider” from the description of the providesAttestations attribute.
Comment no. 4
Proposed change
Please, rename the claim attribute to claims.
Motivation of proposed change
I propose changing the name of the claim attribute to claims since it contains an array of objects. Additionally, OID4VP section 6.1. Credential Query has the matching property's name in plural: claims.
Comment no. 5
Proposed change
Please, change the multiplicity of the claim attribute in the Credential class from [0..*] to [1..*]. Or alternatively explain in the description of the claim attribute that there is a special case.
Motivation of proposed change
Multiplicity of the claim attribute in the Credential class should be changed from [0..*] to [1..*]. ARF's requirement RPRC_21 says that all attributes requested in the presentation request are included in the list of attributes registered by the Registrar. Thus a WRP always has its claim attribute populated in the registry and the attribute always has at least one element.
This is another reason to have distinct Credential class and ProvidedAttestation class (see my comment 3).
Alternatively, is the reasoning behind the [0..*] multiplicity that there will be attestations that do not support selective disclosure in which case a WRP indeed requests everything the attestation contains? If so, I propose explaining this special case in the description of the claim attribute. The description should explain the special case in enough detail and in ARF or in some standard there should be a requirement that says that the registration of a non-existent claim attribute should be rejected by the registrar, if the type of attestation indicated by the format and meta attributes supports selective disclosure.
Comment no. 6
Proposed change
Please, change the multiplicity of the identifier attribute of the LegalEntity class from [0..*] to [1..*].
Motivation of proposed change
The identifier attribute of the LegalEntity class is defined as optional (multiplicity [0..*]). ARF requirement RPRC_07 says that the registration certificate shall include an EU-wide unique identifier for the subject of the certificate. Thus the multiplicity of the identifier attribute of the LegalEntity class should be changed to [1..*].
Comment no. 7
Proposed change
Please, remove the values attribute from the Claim class.
Motivation of proposed change
I propose removing the values attribute from the Claim class.
I do not think it makes sense for the WRP to register what values they expect the registered attributes to have. TS5 defines the values attribute based on OID4VP's DCQL Claims Query which has a values property. It makes sense in a DCQL query, but not as a registered attribute of a WRP.
ARF's requirement RPRC_15 says that the registration certificate shall contain the type(s) of attestation that the PID Provider, QEAA Provider, PuB-EAA Provider or non-qualified EAA Provider intends to issue to Wallet Units. It does not mention attributes or attribute values of those attestations.
Furthermore, ARF's requirement RPRC_03 says that the registration certificate shall include at least the information required in Annex V of the CIR 2025/848 regarding registration of wallet-relying parties. The CIR's Annex I (which Annex V refers to) point 9 does say that the registration certificate shall contain a list of attestations and attributes the WRP intends to request. It does not mention attribute values.
Based on RPRC_15, RPRC_03 and CIR 2025/848 there is no basis to include the attribute values in the registry nor in registration certificates.
Comment no. 8
Proposed change
Please, remove “PID_Provider” from the description of the providesAttestations attribute.
Motivation of proposed change
The description of the providesAttestations is in conflict with ARF's requirements ISSU_24a and ISSU_34a which state that sub-entitlements of PID Providers are not checked.
It is true that ARF's requirement RPRC_15 says that the registration certificate shall contain the type(s) of attestation that a PID Provider intends to issue to Wallet Units, but that is in conflict with the requirement ISSU_24a and the following paragraph in ARF's section 6.6.3.2:
Regarding PID Providers or QEAA Providers it may be argued that Wallet Units do not have to do this verification, since these are trusted parties. Nevertheless, it is beneficial if a Wallet Unit verifies if a PID Provider or QEAA Provider is registered for issuing a PID or a particular type of QEAA, prior to requesting the issuance of such a PID or QEAA. Doing this helps to prevent attempts to issue a PID or attestation while not being entitled to do so, either fraudulently or as a result of an error.
In issue eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework#630 I have proposed to remove “PID Provider” from ARF's RPRC_15 requirement so that it is no longer in conflict with ISSU_24a and the cited paragraph in ARF's section 6.6.3.2.
Comment no. 9
Proposed change
Please, fix multiplicity and type errors in the ts5-wrpreg-datamodel.svg file.
Motivation of proposed change
The ts5-wrpreg-datamodel.svg file is not aligned with the TS5 text. The file has following errors:
- Multiplicity of the
intendedUseattribute of the WalletRelyingParty should be[0..*]. - Type of the
pathattribute of the Claim should be “non-empty array of strings, nulls and non-negative integers”. - Type of the
valuesattribute of the Claim should be “An array of strings, integers or boolean values”. Please also see my comment 7, where I propose removing thevaluesattribute. - Type of the
legalPersonattribute of the LegalEntity should be LegalPerson.
Comment no. 10
Proposed change
Please, rename the credential attribute to credentials.
Motivation of proposed change
I propose changing the name of the credential attribute to credentials since it contains an array of objects. Additionally, OID4VP section 6. Digital Credentials Query Language (DCQL) has the matching property's name in plural: credentials.