Decisiones recomendadas — Arquitectura de datos interoperable del DPP¶
Arte Taxco · 27 Julio 2026 · Respuestas del arquitecto a las 9 dudas de HANDOFF-INTEROPERABILIDAD-DPP.md
Para qué existe: el chat de interoperabilidad recibió el handoff con 9 dudas. Este documento fija las decisiones recomendadas (con razón) para que ese chat las tome como punto de partida, no desde cero. Las respuestas definitivas del chat de interop se integran en
ARQUITECTURA-DPP-CADENA-PROPIEDAD.md.Principio rector: de las 9, 6 son no-regret (correctas bajo casi cualquier fondo) → decididas ya. Solo la profundidad del stack VC/DID (Q4) y el ranking fino (Q9) dependen de la lista de fondos.
Decisiones no-regret (decidir ya)¶
Q1 · Modelo de propiedad → tabla RegistroPropietario desde P1 (no v1-mínimo con
campos planos). Una cadena de propietarios es intrínsecamente registros append-only
con provenance (quién/cuándo/víaEvento); los campos owner* no pueden sostener una
cadena. Mapea 1:1 a Verifiable Credential. Es aditivo. ARQUITECTURA-DPP-CADENA-PROPIEDAD.md
ya se inclina ahí — confirmarlo.
Q3 · Diccionario → ambos. Enlazado canónico (XSD + diccionario versionado por URL)
y embebido para autosuficiencia (imprescindible dentro del PDF/A-3, para interpretar
offline). Fuente única: el diccionario genera las anotaciones del XSD y el doc
humano, anclado en DICCIONARIO-CAMPOS-SISTEMAS.md. No mantener dos.
Q5 · Acceso vs portabilidad → dos proyecciones, una política. El archivo NO lleva motor de política (un archivo estático no hace cumplir nada): es un snapshot de lo que el solicitante tiene derecho a ver. Dueño = completo; público = subconjunto redactado (specs, composición, condición, eventos, cadena anonimizada). Redactado en público: identidad/contacto, precios/valuaciones, geolocalización del dueño.
Q6 · PDF → PDF/A-3 con XML embebido (ZUGFeRD/Factur-X) como primario + XML suelto para consumo puro-máquina. Es el precedente UE de facturación electrónica para exactamente este problema (un archivo, humano+máquina, archival) → historia fundeable.
Q7 · Eventos del comprador → sí, puede declarar, marcado DECLARADO. Nunca presentar
declarado como verificado. Enriquece el pasaporte (mantenimientos) sin diluir confianza;
ya hay superficie (portal). ARQUITECTURA-DPP-CADENA-PROPIEDAD.md §5 ya lo diseñó.
Q8 · Versionado → productType selecciona el perfil; cada perfil versionado aparte.
Modelo canónico interno (atributo-registro, agnóstico de categoría) → registro de perfiles
por categoría → serializadores. Nuevo acto delegado = agregar/actualizar un perfil,
sin tocar el canónico ni las otras categorías.
Decidir la dirección ahora, verificar el detalle¶
Q2 · Vocabulario de joyería → perfil propio mapeable, con vocabulario anclado en estándares existentes, no inventado: evaluar ISO 9202 (fineness de aleaciones de metales preciosos) para la ley y CIBJO Blue Books (nomenclatura de gemas/metales preciosos) para la piedra. Namespaced + versionado para remapear al acto delegado de joyería cuando exista. (El chat de interop confirma aplicabilidad exacta.)
Gatear por fondos / fasear¶
Q4 · Estatus epistémico + firmas + DID → dividir en dos. La representación (cada
atributo con estatus + emisor + fecha + víaEvento en XML; cada claim con issuer en VC):
decidir ya. El stack DID/firmas: fasear, no sobre-ingenierizar. v1 = did:web
anclado en artetaxco.mx (sin blockchain, verificable por HTTPS/DNS, bajo-ops); AT firma
verificado/medido; declarado = auto-aseverado por el dueño. DIDs por-actor (reparador,
reciclador con llave propia) = incremento posterior. La profundidad de este stack es lo
que de verdad espera la lista de fondos.
✅ Q4-firmas v1 IMPLEMENTADO (1 Ago 2026,
FEAT-DPP-TEXTIL-T3-001).did:webEd25519 + JWS; cadaAtributoDPPse firma como VC-JWT; DID document en/.well-known/did.json; emisión (<Prueba>/f=vc) y verificación cerradas. Matiz de anclaje: el DID quedó endid:web:certificados.artetaxco.mx(la app Next que sirve el DPP), no enartetaxco.mx(Shopify no sirve/.well-known) — fiel a la intención de Q4 (HTTPS/DNS, bajo-ops). Emisor único (AT); DIDs por-actor siguen diferidos. Detalle endocs/FIXES.md. Anti-sobreafirmación: la firma prueba integridad + emisor, no la veracidad del hecho — el gapnivelExigido↔estatussigue visible.
Q9 · Alineación con fondos → es LA pregunta que necesita la lista. No se puede rankear sin ella. Hipótesis: EPCIS + datos abiertos + interop semántica (XML+diccionario) son universalmente valorados y de bajo riesgo → primero; VC/SSI es alto-valor si un fondo lo premia → gatearlo.
Priorización recomendada (robusta a fondos)¶
| Tier | Qué | Sirve a |
|---|---|---|
| 0 · Cimiento | Modelo de atributos (atributo-registro) + tabla RegistroPropietario |
Q1, Q7 · todo lo demás cuelga de aquí |
| 1 · Núcleo datos abiertos | (a) EPCIS 2.0 emisor + actualizar claim académico · (b) XML autodescriptivo (XSD+diccionario, ISO 9202/CIBJO) · (c) PDF/A-3 con XML embebido · (d) dos proyecciones por una política | Q2, Q3, Q5, Q6 |
| 2 · Gatear por fondos | Verifiable Credentials + did:web, faseado |
Q4-firmas |
El versionado del mapeador (Q8) es un principio de diseño que atraviesa Tier 1–2.
Gate duro sobre Tier 1(a): cuando EPCIS pase de "serializable" a emisor, actualizar el manuscrito y la página de evidencia ANTES de publicar (anti-sobreafirmación).
Arte Taxco · Decisiones de interoperabilidad · 27 Julio 2026 · recomendación, no definitivo