chore(credo-ts): migrate to credo-ts v0.6.x

README.md

@@ -97,10 +97,14 @@ The generated DID:web document follows the W3C DID Core specification and includ
 
 - **@context**: Standard DID contexts
 - **id**: The DID identifier
-- **verificationMethod**: Cryptographic key material
-- **authentication**: Authentication methods
-- **assertionMethod**: Assertion methods
-- **service**: Service endpoints for communication
+- **verificationMethod**: Canonical Credo v0.6 methods (`Ed25519VerificationKey2020` for `#auth-key`/`#assertion-key`, `X25519KeyAgreementKey2019` for `#agreement-key`)
+- **authentication**: References `#auth-key`
+- **assertionMethod**: References `#assertion-key`
+- **keyAgreement**: References `#agreement-key`
+- **capabilityInvocation**: References `#auth-key`
+- **service**: DIDComm v1-compatible `did-communication` service with `recipientKeys` referencing `#auth-key`
+
+For migration details from the legacy generated shape (`#owner`/`#encryption`, multibase/base58 keys), see `docs/credo-v0.6-migration-release-notes.md` (DID:web generated document shape section).
 
 ### Loading `did:web`s
 

docs/credentials-and-proofs.md

@@ -103,6 +103,8 @@ W3C credentials in this service use JSON-LD format. Verification uses Presentati
 }
 ```
 
+Policy note: `POST /v1/proofs/{proofRecordId}/accept-request` currently rejects client-supplied `proofFormats.presentationExchange.credentials` with `422`. PEX credential selection is server-side/agent-side only.
+
 ---
 
 ## AnonCreds Credential Flow
@@ -193,15 +195,23 @@ For detailed documentation on how to control creating proofs with specific crede
 
 ## Developer Notes: Type Safety & Internal Casts
 
-In the controller layer (`src/controllers/`), we use the `satisfies` keyword at the DTO boundary to align API types with the agent's internal method parameter types, with a small number of explicit casts where needed (e.g., proof accept-request formats).
+In the controller layer (`src/controllers/`), we use the `satisfies` keyword at the DTO boundary to align API types with the agent's internal method parameter types, with a small number of explicit casts where needed (for example, proof format adaptation in utility helpers).
 
 ### Why is this necessary?
 
 The codebase bridges two distinct type systems:
 
-1. **Rest API Types (TSOA):** Defined in `src/controllers/types.ts`. These are "Plain Old JavaScript Objects" (POJOs) optimized for generating clean OpenAPI/Swagger documentation. They explicitly list fields for supported protocols (like `anoncreds` and `w3c` in `credentialFormats`).
+1. **Rest API Types (TSOA):** Defined under `src/controllers/types/`. These are "Plain Old JavaScript Objects" (POJOs) optimized for generating clean OpenAPI/Swagger documentation. They explicitly list fields for supported protocols (for example `anoncreds` and `jsonld` in `credentialFormats`).
 2. **Internal Framework Types (Credo-TS):** Defined dynamically throughout `@credo-ts/core`. These types often rely on complex TypeScript generics to support extensible modules (e.g., `CredentialFormatPayload<CredentialFormats[], 'acceptOffer'>`).
 
 While the API type and the internal type are structurally compatible (they hold the same data), the TypeScript compiler cannot easily verify that the explicit TSOA object satisfies the complex generic constraints of the extensible agent modules.
 
-Using `satisfies` and explicit casts only where necessary acts as a verified bridge. It confirms to the compiler that the API input conforms to the internal module requirements without circumventing type safety (which using `as unknown` would do). This ensures we can support polymorphic endpoints—handling both AnonCreds and W3C formats simultaneously—while maintaining strict compilation checks.
+Using `satisfies` and explicit casts only where necessary acts as a verified bridge. It confirms to the compiler that the API input conforms to the internal module requirements without circumventing type safety (which using `as unknown` would do). This ensures we can support polymorphic endpoints—handling both AnonCreds and W3C JSON-LD formats simultaneously—while maintaining strict compilation checks.
+
+### Current v0.6.x boundary rules
+
+* Prefer explicit local DTO interfaces at TSOA controller boundaries.
+* Avoid `Pick`/`Omit` utility-type composition in controller request/response models.
+* Prefer upstream naming directly (including `...Options`) when semantics match.
+* Keep proof/PEX DTOs local intentionally to avoid Sphereon/PEX graph instability in OpenAPI generation.
+* Reuse direct Credo type re-exports where proven stable (for example DID request/resolution option types).

docs/credo-did-documents-v0.5-v0.6.md

@@ -221,3 +221,25 @@ Keys are selected by **relationship + algorithm compatibility**, not inferred.
 
 Credo-TS v0.5.x treats the DID Document as a **key container**.  
 Credo-TS v0.6.x treats it as a **cryptographic contract**.
+
+---
+
+## 8. Implemented Cloudagent Profile (2026-02-27)
+
+`veritable-cloudagent` now generates DID:web documents using canonical v0.6 key semantics:
+
+- `verificationMethod` uses canonical v0.6 key types:
+  - `#auth-key` and `#assertion-key`: `Ed25519VerificationKey2020`
+  - `#agreement-key`: `X25519KeyAgreementKey2019`
+- Relationships are explicit:
+  - `authentication: [#auth-key]`
+  - `assertionMethod: [#assertion-key]`
+  - `keyAgreement: [#agreement-key]`
+  - `capabilityInvocation: [#auth-key]`
+- DID service remains DIDComm v1-compatible (`did-communication`) for current interoperability.
+
+Implementation references:
+
+- `src/utils/didWebGenerator.ts`
+- `src/controllers/v1/wallet/WalletController.ts` (JWK-compatible key-id resolution)
+- `tests/unit/didWebGenerator.test.ts`