|
| 1 | +# Acceptance of Self-Issued / User-Asserted Attributes |
| 2 | + |
| 3 | +**Authors:** |
| 4 | + |
| 5 | +- Consortium Architecture Working Group AMS Track 4 |
| 6 | + |
| 7 | +- Boris Lingl, boris.lingl@datev.de |
| 8 | +- Alexander Manecke, a.manecke@telekom.de |
| 9 | +- Ignacio Ripoll, ignacio.ripoll@corpme.es |
| 10 | +- Iris Speiser, iris.speiser@datev.de |
| 11 | +- Marlene Urbschat, marlene.urbschat@datev.de |
| 12 | + |
| 13 | +## Context |
| 14 | + |
| 15 | +The consortium needed to determine whether self-issued/user-asserted attributes are acceptable within the ecosystem. |
| 16 | + |
| 17 | +The acceptability and legal fit of self-issued attestations were unclear. While self-issued attestations offer flexibility and ease of issuance, they do not provide the same level of assurance as electronic attestations of attributes (EAA) or qualified electronic attestations of attributes (QEAA) issued by trusted parties. |
| 18 | + |
| 19 | +The core trade-off is between enabling broad adoption and maintaining a consistently high level of trust across jurisdictions. |
| 20 | + |
| 21 | +## Decision |
| 22 | + |
| 23 | +The consortium will allow the use of self-issued/user-asserted attributes. |
| 24 | + |
| 25 | +However, self-issued attributes shall not be treated as qualified attestations and shall not imply the same level of legal or regulatory assurance. |
| 26 | + |
| 27 | +Relying parties remain responsible for determining whether self-issued attestations are sufficient for their use case and risk profile. |
| 28 | + |
| 29 | +## Consequences |
| 30 | + |
| 31 | +### What becomes easier? |
| 32 | + |
| 33 | +- Faster ecosystem adoption. |
| 34 | +- Reduced issuance complexity. |
| 35 | +- Lower barriers to participation. |
| 36 | +- Increased flexibility for use cases where qualified attestations are not required. |
| 37 | + |
| 38 | +### What becomes more difficult? |
| 39 | + |
| 40 | +- Trust evaluation becomes the responsibility of relying parties. |
| 41 | +- Acceptance may vary across jurisdictions. |
| 42 | +- Additional policy decisions may be required by service providers. |
| 43 | + |
| 44 | +### How do we address the risks introduced by this change? |
| 45 | + |
| 46 | +- Clearly distinguish self-issued and qualified attestations. |
| 47 | +- Define metadata and trust indicators that allow relying parties to assess assurance levels. |
| 48 | +- Allow relying parties to reject self-issued attestations where regulatory requirements demand stronger evidence. |
| 49 | + |
| 50 | +## Advice |
| 51 | + |
| 52 | +- 2026-06-11: Consortium Working Group: Self-issued/user-asserted attributes should be supported to maximize ecosystem adoption. |
| 53 | +- 2026-06-11: Legal and Compliance Representatives: Self-issued attestations must not be confused with qualified attestations. |
| 54 | +- 2026-06-11: Service Providers: Acceptance policies should be based on jurisdictional and risk requirements. |
0 commit comments