EU age verification profile (Annex A)

Four differences, none of them cosmetic

The first is the one that surprises people. There is no signed request object. A HAIP verifier wraps its request in a JWT, signs it, and sends the chain along in the x5c header. Annex A sends plain query parameters instead, and it gives the reason: the integrity that signing buys you depends on a trust list of relying parties, that list does not exist here, so an attacker who obtained any valid certificate could substitute a request of their own. In the specification's words, "the Age Verification solution does not use JAR".

The second follows from the first. Reader authentication and client authentication are both declared out of scope, which is why this path needs no access certificate. The app is not trying to work out who you are before it answers, and the profile says so rather than leaving it implied.

The third is the response. HAIP encrypts it, using response_mode direct_post.jwt and a key the verifier advertises in client_metadata. Annex A requires plain direct_post, so there is no response key, and client_metadata is absent from the profile altogether. A verifier that sends one anyway is sending a parameter the profile never defined.

The fourth is identity. Instead of x509_san_dns, the profile requires the client identifier to be the literal string redirect_uri followed by the response URI itself, so a verifier is identified by where it asks the answer to be sent rather than by a name inside a certificate. Annex A's worked example goes further and uses a response URI carrying a per session token, which makes its client identifier change on every request. That is what the example happens to do, not something the profile requires, and the difference is worth holding on to before you build a session token into a URL you did not need to.

How the app gets invoked

Annex A requires that the app support at least the custom URL scheme av://. That is the floor rather than the ceiling: the profile's preferred transport is the W3C Digital Credentials API, and the custom scheme is what covers the case where the browser has no such API. On Android the shipping app resolves av:// directly, so a link is enough to hand a request over.

The credential it answers with is the EU age verification attestation, doctype eu.europa.ec.av.1, an mdoc that carries age_over_N booleans and nothing else. It is not the PID, and asking for age_over_18 as a plain SD-JWT claim gets you nothing, because no EU credential carries it in that shape.

Why this matters commercially, not just technically

These two profiles are usually discussed as though one were a subset of the other. They are not. A verifier that passes the OpenID Foundation conformance suite for HAIP has proved nothing about this profile, and the suite cannot test it even in principle, because the plan only offers the encrypted response mode that Annex A forbids. The reverse holds too. Evidence for one is not evidence for the other, and we say so about our own conformance results.

The practical consequence is that the two paths are at different stages for everyone, not only for us. The wallet path waits on access certificates and on member states shipping wallets. The age verification path is answerable today, because nothing in it is gated on a certificate. If a vendor tells you they are live on EU age verification, the useful follow up is which of the two they mean.