ARF 3.0 Analysis

[Saramandus]

The EUDI Architecture and Reference Framework (ARF) has been updated to version 3.0. This update may introduce changes that impact the WE BUILD blueprint, pilots, and other ongoing work within the consortium.

We should review the changes in ARF 3.0, identify any relevant impacts or dependencies, and determine whether updates or actions are needed within WE BUILD.

The latest ARF

[miluDIGG]

REGARDING WUA TOPIC - TS3/CS-04

Already from ARF 2.9, there was a gap between CS-04 (WUA) and now we have TS 3 v. 1.5.2 and I wonder if WP should adapt to get closer to TS3? This since TS3 v.1.5.2 is now mentioned in CIR(EU) 2026/1731 and the STS roadmap for TS 3 is closed by which I conclude that the topic is frozen (until at least 2027 when ETSI TS 119476-3 will be ready).

A few examples that don't correspond between CS-04 and TS 3 v.1.5.2:

• Several more verification steps for RPs in TS3 that are missing in CS-04: RP must check that:

1. the WIA signature verifies under the key in the x5c certificate ( JOSE header).
2. that the certificate chains to a trust anchor. Under ARF 3. 0 this is the WP LoTL but since the EU-level list is not yet operational, WeBuild uses its own TL in the meantime.
3. that the WIA has not expired
4. verify that the OAuth-Client-Attestation PoP signature verifies under the WIAs cnf claim

• under 7.2, Relying parties SHOULD (1) but TS3 says it is a MUST (Attestation Providers MUST check KA revocation at issuance and refuse if revoked).

• under "Relying parties MUST: (PID Provider) Check the revocation status of both the WIA and the KA received during issuance at least once every 24 hours for the validity period of the PID. Where the PID validity period is less than 24 hours, checking on issuance is sufficient (TS-03 [3], clause 2.4.3)." --> TS3 adds that "If either is revoked, the PID Provider SHALL revoke the PID"

• CS-04 states in chapter 7.3 WU MUST point 1 and 2 and refers to TS3 chapter 2.2.11 which is no longer the case. Can leave as is for WeBuild (in my opinion) but correct the reference to TS3 and to WUA_37 (it is about record-keeping).

[stavamichal]

We have done some analysis in general of changes between ARF 2.9 and 3.0. I am note sure if such overview could be helfpul, but I will share with you those, that we believe could affect us directly (there is also minor overlap with changes between 2.8 and 2.9):

• TLs/LoTEs:
  • Trusted Lists are now only for QEAA Providers / QTSPs and they explicitly comply with ETSI TS 119 612 (§3.5)
  • LoTEs now include also PuB-EAA Providers (they were part of TL in 2.9) and they explicitly comply with ETSI TS 119 602 (§3.5)
  • Entities on TLs/LoTEs are never removed, only invalidated if not trusted anymore (§3.5)
• RPs and Intermediaries:
  • RP now have more layers (1 RP -> Multiple RP Services -> Multiple RP Instances) (§3.11.2)
  • RP Services are linked to registered Intended Uses -> 1 WRPRC per combination of Service and Intended Use (§3.11.2)
  • WRPAC now binds to the specific RP Service and RP Instance (§3.11.3)
  • No intermediary displaying during interaction with RP Intermediaries, only targeted RP.
• Registrar and WRPRC/WRPAC:
  • Issuing and using of WRPRCs is now mandatory for RPs. (§3.17, 3.18, §3.19)
    • WRPAC == X509 certificate (RFC 5280, ETSI TS 119 411-8)
    • WRPRC == JWT cryptographically bound to WRPAC (RFC 7519)
  • No fall-back to arbitrary self-declared metadata when WRPRC/Register validation fails.
• Trust Model:
  • Specificaly stated Trust Model with a need for entities to obtain Trust Anchors from TLs and LoTEs (§6)
• Wallet and Wallet Providers:
  • A Wallet Unit have to bind the WRPRC to the WRPAC contained in the same request by verifying the RP identifier and the RP Service identifier.
  • Wallet to Wallet interaction has been incorporated directly into the ARF 3.0 as Annex J.
• Others:
  • Mandatory proximity checks.

While this is not a full list of changes, those are change that we have noticed as the eventually most impactful in the last two versions.

[stavamichal]

@thodoris My personal opinion is that ARF 3.0 is more mature than 2.8/2.9 and we should freeze rather on 3.0 then on previous versions as this is much closer to the real production environment.

[MartinHurych-Aricoma]

I've spent some time on the 2.9.0 → 3.0.0 diff and would offer three things to the discussion. A foreword of warning, web rendered ARF seems to be broken for version 2.9.0. and returns 3.0.0 version instead, which is why I was working from .diff. I have flagged the issue on eudiw Git.

1. Two particularities of the diff itself

Worth knowing ahead, particularly for anyone intending to hand the diff to a language model. Neither is a change to the framework, but both look like one.

The main document was moved, not rewritten. The single-page docs/architecture-and-reference-framework-main.md is deleted. All 6 032 lines of it. Eleven chapter files appear in its place, docs/main/01-introduction.md through 11-annexes.md, totalling 6 063. On the face of the patch that is some twelve thousand changed lines but the real change is +1 374 / −1 372 over 207 hunks. Of those, 37 are only the link syntax the split required.

The requirement annexes are generated. annex-2.02-*.md and annex-2.03-*.md are rendered from hltr/high-level-requirements.csv by the Jinja2 templates in hltr/scripts/, and those templates changed this time. What was a four-column markdown table is now one <div> per requirement, anchored on the harmonised identifier. Between them the two files show some 17 100 added lines, almost none of which is a change to a requirement.

One consequence is not merely cosmetic. Each requirement now carries its own anchor, so a specific HLR can be linked directly for the first time.

2. The requirements

I have prepare a mapping table capturing identifier change and the content change as separate columns, a similarity score, and separate tables for the new, removed and substituted sets. You can have a look and see if you find it useful. I have also prepared a README on the method used for the mapping with some more analytical insights.

ARF 2.9.0. to 3.0.0 HLR mapping README.md
ARF-2.9.0-to-3.0.0-HLR-map.xlsx

Just a few notes. The corpus went from 684 to 725 rows, and the counts need one caveat before they mean much. Rows are never removed. A requirement that goes away has its text replaced with the literal string Empty and the row stays where it is. There were 96 such placeholders in 2.9.0 and 103 in 3.0.0. A row-level comparison therefore reports nothing deleted, which is not quite the case. Thirteen requirements had text in 2.9.0 and are Empty in 3.0.0, and six went the other way. So 47 new obligations and 13 removed.

Five of the thirteen are registration-certificate requirements, which is one of the loci of change Michal described in post above. For example RPRC_16 is the notable one. In 2.9.0 it was the requirement letting a User ask to verify what had been registered about a Relying Party.

Of the substance, 176 requirements have real text on both sides and differ. 135 are edits and 29 are heavy rewrites. The remaining 12 are a different matter: the identifier stayed and the requirement did not. Word similarity between old and new is below 0.35.
An illustration could be PID_03. In 2.9.0 it required a PID portrait to consist of a single JPEG image. In 3.0.0 the same identifier says a PID Provider may enable the User to opt out of receiving a portrait at all.

Plus around forty requirements show movement in the normative keyword. I would treat that as a search filter rather than a finding, since a keyword count can shift because a sentence was added, and can hold steady while the meaning reverses.

3. CS-006, which I think is genuinely time-sensitive

If I should try to identify the change that lands hardest on us, it would be the treatment of registration certificates. Connected to that, CS-006, Issuance of Relying Party Access and Registration Certificates, is still under development. If I tracked it correctly, it should be this PR: [Conformance specification for Wallet-Relying Party access and registration certificates by sander · Pull Request #287](#287)

Registration certificates are no longer optional. 2.9.0 spoke of a Registrar "having a policy of issuing registration certificates". §3.19 now states flatly that a Registrar has one or more associated Providers of registration certificates, and §6.4.2 requires issuance to be automated and without undue delay. The fallback goes with it. Where a Wallet Unit could previously go online to the Registrar and ask for the list of registered attributes, §6.6.2.3 (a wholly new step, on the issuance side) and §6.6.3.3 (presentation) now require verification of a registration certificate and nothing else. Figure 14 corroborates this independently. In docs/media/Figure_14_Verifying_Relying_Party_Registration.xml the branches "if registration certificate present", "else" and "check if User wants to contact Registrar" no longer appear. Worth thirty seconds of anyone's time to confirm.

The two certificates are different animals. Per §3.18 and §3.19, an access certificate is an X.509 certificate under RFC 5280 and ETSI TS 119 411-8. A registration certificate, on the other hand, is a JWT under RFC 7519 and expressly not X.509. They are bound to one another by a shared Relying Party identifier and Service identifier, and it is that binding the Wallet Unit checks.

Certificate volume now follows a matrix. §3.11.2 introduces the Relying Party Service, and its worked example is the clearest statement of the consequence: three Services against five intended uses yields seven registration certificates, one for each Service and intended-use pair.

Registration is transparency, not authorisation. §6.4.2 now says so in terms. The Registrar applies no pre-authorisation, and registering an attribute against an intended use does not authorise requesting it. Where authorisation is needed it happens outside the ecosystem entirely. I mention it because it is the point most likely to influence a working assumption somewhere.

On timing, both §6.6.2.3 and §6.6.3.3 carry a transitional note giving twenty-four months from entry into force of the Regulation amending CIR 2024/2982. But since we were discussing the freezing of the state, which we will need to do, I would support Michal's suggestion to freeze on 3.0.0 as the more mature version.

I have a some further observations and more unrefined data. I would need some time to work through all of them. But I hope this shines light on some issues and provides a starting resource. :-)