dataspace-client-sdk-node 0.1.1 → 0.1.2

package/SDK_PARITY_MAP.md

@@ -1,120 +0,0 @@
-# SDK Parity Map (Node vs Python)
-
-Estado: guía de referencia para alinear `dataspace-client-sdk-node` con `connector-sdk-py`.
-
-Convención:
-- Node SDK: `dataspace-client-sdk-node`
-- Python SDK: `connector-sdk-py`
-- Wallet interno temporal en Node: `src/sdk/dataspace-wallet-sdk-node/`
-
-## 0) Repos fuente del ecosistema (contexto obligatorio)
-
-| Repo | Rol |
-|---|---|
-| `dataspace-client-sdk-node` | SDK backend Node (este repo) |
-| `connector-sdk-py` | referencia de paridad backend Python |
-| `gdc-sdk-client-ts` | SDK/frontend wallet UX-side |
-| `gwtemplate-node-ts` | base backend GW + `gdc-backend-utils-node` |
-| `gdc-unid-node-ts` | fork operativo de GW para UNID |
-| `uhc-unid-chat-node` | consumidor de alto nivel (voice/chat orchestration) |
-
-## 1) Perímetro de paridad
-
-La paridad se mide por capacidades, no por nombres internos exactos:
-
-1. Auth backend (PKCE + exchange / SMART backend)
-2. Submit + poll de operaciones de dominio
-3. Lifecycle de API keys
-4. Wallet/KMS cliente (firma, verificación, cifrado, descifrado)
-
-## 2) Identity Routes (canónicas)
-
-Patrón objetivo para rutas de identidad:
-
-`/{prefix}/cds-{jurisdiction}/v1/{sector}/{tenantId}/identity/auth/{action}`
-
-Donde `prefix` depende del servicio:
-- `host` (GW)
-- `publisher` (DataConv)
-- `ica` (ICA)
-
-Nota de compatibilidad:
-- Consumidores que usan métodos de alto nivel (`authenticateBackendPkceAndExchange`) no deberían depender de este detalle.
-- Consumidores que montaban rutas manuales sí deben migrar.
-
-## 3) Paridad de Auth
-
-| Capability | Node SDK | Python SDK | Estado objetivo |
-|---|---|---|---|
-| Identity DCR submit/poll | path builder + submit/poll | operación equivalente | ✅ |
-| Identity code submit/poll | path builder + submit/poll | operación equivalente | ✅ |
-| Identity token submit/poll | path builder + submit/poll | operación equivalente | ✅ |
-| Identity exchange submit/poll | path builder + submit/poll | operación equivalente | ✅ |
-| PKCE orchestration | `authenticateBackendPkceAndExchange(...)` | `authenticate_backend_pkce_and_exchange(...)` | ✅ |
-| SMART backend orchestration | método Node equivalente (pendiente según contrato) | `authenticate_backend_smart_standard(...)` | ⏳ |
-
-## 4) Paridad de Wallet/KMS cliente
-
-Arquitectura temporal Node:
-- módulo interno `src/sdk/dataspace-wallet-sdk-node/`
-- evolución futura: extraer a paquete/repo independiente
-
-Baseline funcional backend/KMS que debe respetarse:
-- en GW (`gdc-unid-node-ts`/`gwtemplate-node-ts`) existen servicios KMS runtime (`KmsService`, `DemoKmsService`) y utilidades KEK en backend utils,
-- el SDK cliente no replica managers de GW,
-- pero sí debe exponer wallet/KMS reutilizable para servicios backend cliente.
-
-| Capability | Node target (`dataspace-wallet-sdk-node` interno) | Python target | Estado |
-|---|---|---|---|
-| Key material provider abstraction | `WalletProvider` | provider equivalente | ⏳ |
-| In-memory provider | `memory-provider` | provider equivalente | ⏳ |
-| Deterministic seed provider (demo/dev) | `seed-provider` | provider equivalente | ⏳ |
-| Public JWK export | `getPublicJwks(...)` | equivalente | ⏳ |
-| Sign/verify | `sign(...)`, `verify(...)` | equivalente | ⏳ |
-| Encrypt/decrypt | `encrypt(...)`, `decrypt(...)` | equivalente | ⏳ |
-| Single-tenant facade | `WalletClient` | equivalente | ⏳ |
-| Multi-tenant facade | `MultiWalletClient` | equivalente | ⏳ |
-
-## 5) Paridad de dominios (baseline)
-
-| Domain capability | Node SDK | Python SDK | Estado |
-|---|---|---|---|
-| Family/Organization onboarding | métodos batch + poll | equivalente | ✅/⏳ según endpoint |
-| RelatedPerson | métodos batch + poll | equivalente | ✅ |
-| Observation | métodos batch + poll | equivalente | ✅ |
-| Communication | métodos batch + poll | equivalente | ✅ |
-| Composition | métodos batch + poll | equivalente | ✅ |
-| Task | métodos batch + poll | equivalente | ✅ |
-| Conversion upload | upload + poll | equivalente | ✅ |
-
-## 6) Surface nuevo (onboarding/licensing/payment)
-
-| Capability | Node SDK | Python SDK | Contract endpoint | Estado |
-|---|---|---|---|---|
-| Family Organization search | pendiente | pendiente | `individual/org.schema/Organization/_search` (+ `_batch-response`) | ⏳ |
-| Family Organization create/resume | pendiente | pendiente | `individual/org.schema/Organization/_batch` (+ `_batch-response`) | ⏳ |
-| Family Order create | pendiente | pendiente | `individual/org.schema/Order/_batch` (+ `_batch-response`) | ⏳ |
-| Host registry order (host flow) | pendiente | pendiente | `host/.../registry/org.schema/Order/_batch` (+ `_batch-response`) | ⏳ |
-| Offer consumption for family flow | pendiente | pendiente | offer returned by Organization `_batch-response` | ⏳ |
-| Stripe intent | pendiente | pendiente | `payment/stripe/_intent` | ⏳ |
-| Stripe status | pendiente | pendiente | `payment/stripe/_status` | ⏳ |
-| API key create | pendiente | disponible en Python | `identity/api-key/_create` | ⏳ |
-| API key disable | pendiente | disponible en Python | `identity/api-key/_disable` | ⏳ |
-| API key search | pendiente | disponible en Python | `identity/api-key/_search` | ⏳ |
-
-## 7) Reglas de cambio
-
-Cada PR que cambie superficie pública en Node o Python debe incluir:
-
-1. actualización de esta tabla,
-2. tests de paridad/compatibilidad,
-3. nota de migración si hay breaking changes.
-
-## 8) Check de salida para release
-
-Antes de publicar nueva versión Node:
-
-1. `README` actualizado con auth + wallet.
-2. ejemplos funcionales en `examples/`.
-3. tests de paridad en verde.
-4. changelog con sección de migración (si aplica).