ETSI TS 119 475, Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user's authorisation decisions
defines how a wallet instance should evaluate RP's attributes in terms of presentation policies
this draft enables RP policies within the EUDIW framework for interoperability
See
4.7 Over-asking validation
To support user trust and data minimisation, wallets are expected to validate whether a relying party’s attribute requests are consistent with its registered intended use. This process, known as overasking validation, compares the requested attributes with those declared during registration.
In cases where a registration certificate is present, the wallet can retrieve the declared use cases and associated attributes directly from the certificate. If no registration certificate is provided, the wallet may obtain equivalent information from the registrar using a trusted and discoverable interface.
The intended use should be represented in a structured and machine-readable form to allow automated comparison. The query structure and attribute naming should follow agreed schemas to enable consistent evaluation. Where proximity-based flows are used and certificates are not transmitted, the wallet should rely on external validation endpoints or cached registration data to perform this check.
ETSI TS 119 475, Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user's authorisation decisions
defines how a wallet instance should evaluate RP's attributes in terms of presentation policies
this draft enables RP policies within the EUDIW framework for interoperability
See
4.7 Over-asking validation
To support user trust and data minimisation, wallets are expected to validate whether a relying party’s attribute requests are consistent with its registered intended use. This process, known as overasking validation, compares the requested attributes with those declared during registration.
In cases where a registration certificate is present, the wallet can retrieve the declared use cases and associated attributes directly from the certificate. If no registration certificate is provided, the wallet may obtain equivalent information from the registrar using a trusted and discoverable interface.
The intended use should be represented in a structured and machine-readable form to allow automated comparison. The query structure and attribute naming should follow agreed schemas to enable consistent evaluation. Where proximity-based flows are used and certificates are not transmitted, the wallet should rely on external validation endpoints or cached registration data to perform this check.