AI Codex — Adaptateur AP2 v1 (GELÉ)

Adaptateur V3 = couche confiance pour rails de paiement. La Reputation VC canonique (SPEC-identity-v0.1 §3) devient une attestation attachable à un mandate AP2. Contrat normatif, non modifiable en place : tout changement = ap2-v2. Aucune dépendance inverse : AP2 fonctionne sans AI Codex ; AI Codex gagne la couche confiance s'il est consommé.

1. Rôle & frontière (figée)

AP2 gère intention + paiement : mandates (Intent, Cart), méthodes de paiement, réseaux (cartes, FIDO, crypto). AI Codex n'y touche pas.
AI Codex fournit l'unique attribut manquant à AP2 : « cet agent est-il fiable ? », sous forme de VC vérifiable jointe au mandate, jamais fusionnée dedans.
Adaptateur en lecture seule : il ne crée pas de mandate, ne signe pas de paiement, ne modifie aucun champ AP2. Il produit une attestation et décrit comment l'attacher.
Invariant de non-dépendance : retirer AI Codex d'un flux AP2 n'invalide aucun mandate ni paiement. La présence de l'attestation est toujours optionnelle côté AP2.

2. Liaison au coeur (figée)

L'attestation projette la Reputation VC vivante (SPEC-identity §3, profil aicodex-norm-v1) du DID canonique de l'agent payeur/payé. Aucune attestation n'existe sans VC émise par l'issuer did:web:maxiaworld.app. L'adaptateur n'altère pas la VC : il l'enveloppe par référence/valeur signée sans recalcul ni troncature de composants.

3. Enveloppe d'attestation (structure figée)

3.1 Forme

L'attestation est attachée au mandate AP2 dans un bloc trustAttestations[] (ou champ d'extension équivalent prévu par AP2 pour pièces jointes vérifiables). Élément AI Codex figé :

{
  "type": "AICodexReputationAttestation",
  "profile": "aicodex-norm-v1",
  "subject": "did:key:z6Mk...",
  "mandateRef": "<id du mandate AP2 ciblé>",
  "issuedAt": "2026-05-18T12:00:00Z",
  "credential": {
    "mode": "linked|embedded",
    "url": "https://maxiaworld.app/reputation/did:key:z6Mk...",
    "vc": { "...": "Reputation VC SPEC-identity §3, présente seulement si mode=embedded" }
  }
}

3.2 Champs (figés)

Champ	Règle
`type`	`"AICodexReputationAttestation"` exact.
`profile`	`"aicodex-norm-v1"` exact (SPEC-identity §3.3).
`subject`	DID canonique de l'agent évalué, identique au `credentialSubject.id` de la VC.
`mandateRef`	Identifiant du mandate AP2 auquel l'attestation est jointe. Liaison déclarative, non contraignante pour AP2.
`issuedAt`	UTC ISO-8601, instant d'attachement (≠ `validFrom` de la VC).
`credential.mode`	`linked` (défaut, recommandé) : seule l'`url` ; la VC reste vérifiable à la source, toujours fraîche. `embedded` : copie intégrale de la VC §3 incluse pour transport hors-ligne.
`credential.url`	URL absolue HTTPS de la VC vivante. Obligatoire dans les deux modes.
`credential.vc`	Présent uniquement si `mode=embedded` : VC §3 octet-intacte (signature préservée, jamais re-signée par l'adaptateur).

Aucun autre champ en v1. Aucun champ ne duplique un composant de score hors de la VC : subject/url/(vc) sont les seuls porteurs de réputation. Pas de score inline hors VC.

3.3 Mode `linked` vs `embedded`

linked : par défaut. Le vérifieur AP2 récupère et vérifie la VC à la source (fraîcheur garantie, révocation à jour).
embedded : pour transport asynchrone/offline d'un mandate. La VC embarquée reste signée par l'issuer ; sa validUntil (7 j, SPEC-identity §3.3) borne la fenêtre de confiance. Un vérifieur DOIT re-vérifier credentialStatus en ligne si joignable.

4. Mapping AIP v0.3.0 ↔ AP2 (figé)

Le profil agent AIP v0.3.0 (SPEC-identity §2.2) se projette vers les attributs de confiance AP2 ainsi. Mapping non destructif : aucune information AIP ne devient autorité de paiement.

Source AIP v0.3.0	Cible attestation AP2	Règle
`did` (DID canonique)	`subject`	Copie exacte. Identité unique pivot.
Reputation VC `credentialSubject.score`	(resté dans `credential`, non extrait)	Le score n'est jamais copié hors VC : AP2 lit la VC, pas l'enveloppe.
Reputation VC `credentialSubject.lineage.dynastyBadge`	(resté dans `credential`)	Idem : badge lu dans la VC vérifiée, pas dupliqué.
`birth.block` (ancrage antériorité)	(non mappé)	Hors AP2 : preuve d'antériorité, jamais un rail. Neutralité §6.
`lineage.parent`	(resté dans VC)	Lignée portée par la VC, pas par l'enveloppe AP2.

Direction unique : AIP → attestation → (jointe au) mandate AP2. Aucun champ AP2 ne remonte modifier l'identité ou la VC (non-dépendance inverse, §1).

5. Flux de vérification (figé)

Un vérifieur AP2 établit la confiance sans qu'AI Codex soit dans le chemin de paiement :

Lire l'attestation jointe au mandate ; vérifier type, profile, subject, mandateRef cohérent.
Obtenir la VC : si mode=linked, GET credential.url ; si embedded, prendre credential.vc.
Vérifier la VC hors plateforme : signature eddsa-jcs-2022 de did:web:maxiaworld.app (résoudre https://maxiaworld.app/.well-known/did.json), credentialSubject.id == subject, validUntil non dépassé, credentialStatus non révoqué (StatusList2021, SPEC-identity §3.2).
Échec d'une étape → l'attestation est ignorée ; le mandate AP2 reste valide (l'attestation est optionnelle). AI Codex ne bloque jamais un paiement.

6. Neutralité (condition)

L'attestation est agnostique du rail : elle ne référence aucune méthode de paiement, aucun réseau (cartes/FIDO/crypto), aucune adresse de règlement. Elle ne porte que le DID et la VC liée.
AI Codex ne privilégie aucun rail dans cet adaptateur (SPEC-identity §1). La marketplace crypto reste découplée et n'est jamais référencée ici.
L'attestation n'exprime ni recommandation de paiement ni autorisation : uniquement la réputation vérifiable, à la charge d'AP2 d'en faire ou non usage.

7. Codes d'erreur (figés)

Émis par l'endpoint qui produit l'attestation (lecture). Corps { "code": "...", "message": "..." }, message générique (aucune fuite d'état ; détail loggé serveur).

Code	Sens
`E_DID_MALFORMED`	`subject` non conforme `did:key`/`did:web` Ed25519
`E_DID_NOT_FOUND`	DID inconnu du registre (aucune VC dérivable)
`E_VC_UNAVAILABLE`	VC introuvable/non émise pour un DID connu (anomalie : un DID connu a toujours une VC plancher, SPEC-identity §3.3)
`E_MANDATE_REF_INVALID`	`mandateRef` absent ou malformé à l'attachement
`E_RATE_LIMITED`	Quota dépassé (§8)
`E_INTERNAL`	Erreur serveur, aucun détail divulgué

Aucun autre code en v1. Aucun code ne révèle un score ou un composant.

8. Quotas & tailles (figés)

Production d'attestation : 60 / min / IP.
Dépassement → E_RATE_LIMITED (jamais d'erreur silencieuse).
Attestation linked ≤ 2 KiB. Attestation embedded ≤ 16 KiB (VC §3 incluse).

9. Conformité adaptateur

Attestation AP2 AI Codex-conforme si, et seulement si : (a) structure §3.1 exacte, champs §3.2 figés, rien de plus, (b) la VC référencée/embarquée est la VC §3 octet-intacte signée par l'issuer, jamais re-signée ni tronquée, (c) subject == credentialSubject.id, (d) aucune dépendance inverse : retirer l'attestation laisse le mandate AP2 valide, (e) aucun rail de paiement référencé (neutralité §6). Les cinq nécessaires et suffisants.

10. Suivant

Chaîne d'adaptateurs gelés complète : V1 MCP (SPEC-adapter-mcp-v1.md), V2 A2A (SPEC-adapter-a2a-v1.md), V3 AP2 (ce document). Aucun adaptateur supplémentaire en v1. Exécution = PLAN-aicodex-build.md Phase B et suivantes.

Frozen specification. The raw .md at the same path is the canonical machine artifact referenced by DID documents and A2A cards — rendered here for humans only.