Where firmas fits.

Online Safety Act 2023 (Part 3, age assurance)

The Online Safety Act requires services hosting pornography and certain other adult content to use "highly effective age assurance" to ensure users are 18+. Ofcom's enforcement codes accept several methods including digital-identity wallets; "self-declaration" is explicitly NOT highly effective.

What firmas covers

• firmas_adult_v1 / firmas_adult_mdoc_v1 — selectively-disclosable age_over_18 boolean, derived from OS-attested age signals + portfolio evidence + handshake corroboration, not from a self-declaration alone
• Token Status List revocation if the credential is invalidated
• Optional assurance_evidence claim — vouch_score + named anti-forgery controls (handshake-graph, doc-cap, jurisdiction-pin) — gives the verifier underwriting visibility beyond an opaque trust score

What firmas does NOT cover

• Document verification (passport / driving license scan + biometric match)
• Facial-age estimation (commercial vendors do this; firmas doesn't take biometric measurements)
• Liveness detection
• Cross-session unique-user tracking (firmas presentations are 60-second one-shot; the verifier sees a claim, not a user identifier)

Ofcom's 2025 codes treat layered approaches favourably — firmas's declared + corroborated trait pairs well with a separate liveness check from a non-firmas vendor when "highly effective" requires both freshness and uniqueness signals.

eIDAS 2.0 (Regulation 2024/1183) + EUDIW Architecture Reference Framework + EU Age Verification System pilot

The EUDI Wallet target architecture supports Personal Identification Data (PID) plus arbitrary attribute attestations. The Commission's Age Verification System (AVS) pilot uses an EUDIW-compatible age proof. Both SD-JWT VC and ISO 18013-5 mDoc are mandated wire formats.

What firmas covers

• Both SD-JWT VC and ISO 18013-5 mDoc — every credential issuable in both standard formats from /.well-known/openid-credential-issuer
• HAIP §4.4 strict (PKCE-S256, DPoP, wallet attestation, PAR-required)
• OpenID4VCI 1.0 + OpenID4VP 1.0 ceremonies, both verifier-initiated and wallet-initiated
• Per credential: selectively-disclosable claims, Token Status List revocation, holder binding via cnf.jwk or COSE_Key
• Federation entity statement at /.well-known/openid-federation embedding both issuer + verifier metadata

What firmas does NOT cover

• PID credential (Personal Identification Data — name + date of birth + national ID number) — intentionally not issued. firmas's public catalogue is three traits only; name lives internal-only for the Dealroom cross-app sign flow and is never advertised in the OpenID4VCI metadata
• Qualified Trust Service Provider operations under eIDAS Art. 24 — firmas is non-qualified by design
• Qualified electronic signature creation devices

eIDAS Art. 45b(1) explicitly recognises non-qualified Electronic Attestations of Attributes; firmas is positioned squarely in that category. The AVS pilot age proof is byte-compatible with firmas_adult_mdoc_v1 at the doctype level (eu.europa.ec.eudi.adult.1).

Real Decreto 1086/2020 + AEPD age-verification guidance + SETSI Art. 19a notification path for non-qualified TSPs

Spain implements eIDAS 2.0 nationally via the SETSI office at the Ministerio para la Transformación Digital. AEPD (data protection authority) has published age-verification guidance emphasising data minimisation; the regulator explicitly criticised methods that retain personal data beyond the verification event.

What firmas covers

• Spanish-language UI throughout the firmas app + /business + /verify
• firmas_residency_v1 with resident_of = "ES" (or ISO 3166-2 sub-region for Catalonia, Madrid, etc.)
• AEPD-compatible data minimisation — no PII reaches the firmas server during issuance; presentations are 60-second one-shots, no persistence on the verifier side required

What firmas does NOT cover

• Notify SETSI under Art. 19a — paperwork track, not engineering. Tracked separately
• Trust List inclusion — firmas is intentionally not on the Spanish trust list (non-qualified by design)

Rindogatan LLC (firmas's operator) is incorporated to the founder's Spain-domiciled person; SETSI is the natural supervisory body. Notification is a documented Phase-2 deliverable.

Lei 14.811/2024 (online child protection) + ANATEL technical guidance + emerging age-verification mandates

Brazil's Lei 14.811/2024 imposes age-protection obligations on platforms serving Brazilian minors. ANATEL technical advice mentions age verification but does not mandate a specific method; LGPD (Brazil's GDPR) restricts retention.

What firmas covers

• Portuguese-language UI (pt-BR locale shipped across the firmas app + /business + /verify)
• firmas_residency_v1 with resident_of = "BR" (no sub-region; Brazil's legal age threshold is federal)
• LGPD-compatible architecture — no personal data leaves the device; the issuer signature binds a trait, not an identity

What firmas does NOT cover

• CPF (Brazilian tax ID) verification — firmas does not collect or attest the CPF
• Integration with the gov.br digital identity (this is a government-API path; firmas's posture is to NEVER reach a centralized authority)

COPPA (under-13) + KOSA (pending) + FTC §5 substantiation + state-level age-verification statutes (LA, TX, UT, etc.)

No federal age-verification mandate at the FTC level today (KOSA pending). State statutes vary widely. FTC §5 requires substantiation of claims — a firmas Adult credential is substantiated by its assurance_evidence claim and the published trust framework.

What firmas covers

• firmas_adult_v1 with the OS-attested age signal as INPUT (Apple iOS 26+ Declared Age Range API + Google Play Age Signals API are mint-time pings, not presentation-time)
• firmas_residency_v1 with sub-region disclosure (US-CA / US-TX / US-LA etc.) to drive state-routing on the relying party side
• FTC §5 substantiation via the assurance_evidence claim — named anti-forgery controls, vouch_score, document + handshake counts the relying party can underwrite against

What firmas does NOT cover

• Federal contractor-style identity vetting (firmas is not on the GSA approved-verifier list)
• FCRA-regulated background checks

AB 1043 (Apple Declared Age Range API + Play Age Signals API mandate) + CCPA / CPRA + emerging state age-verification rulings

AB 1043 requires app-store operators to expose an OS-level age signal that apps may consume for age-gating decisions. The signal is self-attested by the user (parents for under-13s). CCPA / CPRA constrain how a verifier may retain data collected during age verification.

What firmas covers

• OS age signal as INPUT — firmas wraps Apple Declared Age Range API and Google Play Age Signals API responses into a verifier-readable credential without exposing the underlying signal directly. Mint-time-ping only; the OS does NOT see verification events
• firmas_residency_v1 with resident_of = "US-CA" — relying parties can geo-route to CCPA-compliant logic on presentation
• CCPA-friendly architecture — no Personal Information collected by firmas, no retention beyond the issuance event itself

What firmas does NOT cover

• Sell or transfer "personal information" as defined by CCPA — firmas has no such information to begin with
• Persist the OS age signal beyond the issuance moment (the credential carries a boolean claim, not the raw signal)

AB 1043 explicitly treats the OS signal as an INPUT for downstream verifiers, not a verification end-state. firmas's framing — "the OS signal is one of several anti-forgery controls, not the only one" — fits AB 1043's expectation that platforms layer additional checks.

Online Safety Amendment (Social Media Minimum Age) Act 2024 — under-16 social media ban + age-assurance pilots

Australia's 2024 amendment mandates that social-media platforms verify users are 16 or older. The eSafety Commissioner runs age-assurance pilots; methods accepted include digital-identity wallets, document checks, and behavioural signals.

What firmas covers

• firmas_adult_v1 attests age_over_18 — a stricter threshold than the 16+ minimum Australia's amendment requires; covers the use case
• OpenID4VP presentation surface compatible with the eSafety Commissioner's wallet-acceptance criteria

What firmas does NOT cover

• age_over_16 specifically — current firmas claims are age_over_14 + age_over_18 only. Adding age_over_16 is a one-line change if Australian demand surfaces

JuSchG (youth-protection law) + JMStV (state media treaty) + KJM (Commission for Youth Media Protection) acceptance criteria

Germany's youth-protection regime is jurisdictionally complex — KJM publishes specific lists of accepted age-verification systems (Konzepte) under the JuSchG / JMStV framework. Strict separation of identification and authentication steps (the "Identifizierung + Authentifizierung" two-step model).

What firmas covers

• firmas_adult_v1 — declared-age + portfolio evidence + handshake corroboration
• German-language UI throughout the app
• Two-step model architecture — issuance (identification) is separable from presentation (authentication) by design; a verifier sees only the trait, not the underlying identifying data

What firmas does NOT cover

• KJM-Konzept registration — paperwork; firmas's posture is to operate under eIDAS 2.0 Art. 45b(1) rather than seek KJM acceptance, which traditionally requires face-to-face onboarding or qualified e-ID. The architecture is compatible; the formal accreditation is a separate decision

What firmas never does, anywhere.

These are hard product rules, not jurisdiction-conditional. A relying party that needs any of the below must source it from a different provider — and firmas is happy to compose alongside such a provider through layered checks. We don't do them ourselves.

• Biometric capture, processing, or storage (no face, iris, fingerprint, voiceprint — BIPA-clean by design)
• Document verification (no passport / driving-license / national-ID scan + match)
• Liveness detection
• Cross-session user tracking (presentations are 60-second one-shots; the verifier sees a claim, not a stable user id)
• Personal Identification Data (PID) issuance through public OID4VCI — name is internal-only for the Dealroom flow and never advertised in issuer metadata
• KYC / AML / sanctions-list screening
• Government-API integrations for identity verification (no gov.br, no Cl@ve, no SPID, no BankID, no Verify.gov.uk)
• Qualified Trust Service Provider operations
• Commercial vendor pass-through (no Yoti, no Persona, no AU10TIX, no Veriff — firmas runs the full stack itself)