feat(ocrypto): add pure ML-KEM-768/1024 support and unify KEM wrap paths

[dmihalcik-virtru]

Summary

• Adds pure ML-KEM-768 and ML-KEM-1024 support across the platform (policy, KAS service, crypto provider, SDK, otdfctl, keygen), emitted as the new mlkem-wrapped KAO scheme.
• Encodes ML-KEM keys as standard SPKI / PKCS#8 PEM blocks carrying the NIST OIDs (2.16.840.1.101.3.4.4.{2,3}).
• Unifies the four KEM wrap/unwrap paths (ML-KEM-768/1024, X-Wing, P-256+ML-KEM-768, P-384+ML-KEM-1024) behind a single OID-keyed registry, one envelope type, and one encryptor/decryptor pair routed through FromPublicPEM / FromPrivatePEM. Service and SDK callers collapse from per-algorithm switches to a single IsKEMKeyType branch.

Wire formats are preserved byte-for-byte; existing hybrid-wrapped KAOs round-trip unchanged. The OID-keyed registry leaves the planned hybrid-PEM-to-SPKI follow-up as a near-zero change (three OID constants + three registry entries).

Jira: DSPX-3383

Test plan

• cd lib/ocrypto && go test ./...
• cd service && go test ./...
• cd sdk && go test ./...
• cd sdk && go test -run TestREADMECodeBlocks
• golangci-lint run ./lib/ocrypto/ ./service/internal/security/ ./sdk/... — zero new issues
• bats test/tdf-roundtrips.bats — ML-KEM-768 / ML-KEM-1024 / X-Wing / P-256+ML-KEM-768 / P-384+ML-KEM-1024 round-trips pass end-to-end

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• New Features

  • Added support for ML-KEM-768 and ML-KEM-1024 post-quantum cryptographic algorithms for key wrapping and unwrapping.
  • Introduced unified KEM (Key Encapsulation Mechanism) abstraction supporting ML-KEM, X-Wing, and NIST hybrid schemes.

• Documentation

  • Updated OpenAPI schemas and gRPC protocol definitions to reflect new ML-KEM algorithm identifiers.
  • Extended KAS registry documentation for ML-KEM key management.

• Tests

  • Added comprehensive ML-KEM roundtrip and format validation test coverage.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds native ML-KEM-768/1024 support end-to-end: new ocrypto KEM layer and keypairs, SDK wrapping via mlkem-wrapped, KAS crypto/provider handling, API/proto enums and docs updated, connect.error uses single Any detail, CLI/docs/tests extended.

Changes

Native ML-KEM enablement and unified KEM layer

Layer / File(s)	Summary
Unified protocol contracts and error schema updates docs/grpc/index.html, docs/openapi/...	Enums gain MLKEM_768/1024; many schemas switch from allOf to oneOf; connect.error now uses detail: google.protobuf.Any; stricter URI/regex docs.
ocrypto KEM core and ML-KEM support lib/ocrypto/*	Adds unified KEM adapters (ML-KEM/X-Wing/NIST hybrid), ASN.1 kemEnvelope, wrap/unwrap, ML-KEM keypairs, SPKI/PKCS#8 parsing, PEM dispatch refactor.
SDK KEM integration sdk/*	Introduces mlkem-wrapped scheme; WrapDEK used for all KEMs; enum and keytype mappings updated.
Service crypto/providers service/internal/security/*	Adds StandardKEMCrypto, ML-KEM algs, provider and manager decryption paths, KEM public key export, tests.
KAS endpoints and rewrap docs/openapi/kas/kas.openapi.yaml, service/kas/access/*	Adds v2 PublicKey, supports ML-KEM in algorithm switches, rewrap verifies/decrypts mlkem-wrapped.
CLI/docs/tests otdfctl/*, service/cmd/keygen/*, test/tdf-roundtrips.bats, tests-bdd/*	CLI keygen/validate ML-KEM; docs list mlkem:768/1024; roundtrip tests and key generators added.
Policy protos/DB mapping service/policy/*.proto, service/policy/db/*	Adds ML-KEM enum values and DB grant mapping to KAS public key algs.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant SDK
  participant ocrypto
  participant KAS
  Client->>SDK: createKeyAccess(ktype, kasPublicKeyPEM, DEK)
  SDK->>ocrypto: WrapDEK(ktype, PEM, DEK)
  ocrypto-->>SDK: kemEnvelope DER
  SDK-->>Client: Manifest with KeyType (mlkem-wrapped|hybrid-wrapped)
  Client->>KAS: PublicKey (fetch) / Rewrap (as needed)
  KAS->>ocrypto: Decrypt(kemEnvelope)
  ocrypto-->>KAS: DEK
  KAS-->>Client: Rewrapped/Decrypted response

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• opentdf/platform#3276: Earlier update to Algorithm/KAS enums for HPQT hybrid ML-KEM; overlaps same enum tables now extended with ML-KEM-only variants.

Suggested labels

comp:policy, comp:kas, comp:sdk, comp:lib:ocrypto, pqc, docs, size/xl

Suggested reviewers

• strantalis

Poem

In burrows of code, a rabbit taps keys,
ML-KEM blooms like quantum breeze.
Envelopes sealed with ASN.1 light,
HKDF hums through the cryptic night.
KAS nods, SDK grins—wrapped and ready,
Keys hop safely, swift and steady. 🐇🔐

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch DSPX-3383-alternative-simplified

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces native support for pure ML-KEM-768 and ML-KEM-1024 algorithms while refactoring the existing KEM infrastructure. By unifying the wrap/unwrap logic for all KEM schemes—including X-Wing and NIST hybrid variants—the codebase becomes more maintainable and consistent. These changes ensure that key management and cryptographic operations are streamlined across the platform, simplifying future algorithm integrations.

Highlights

• ML-KEM Support: Added support for pure ML-KEM-768 and ML-KEM-1024 algorithms across the platform, including policy, KAS service, crypto provider, and SDK.
• Unified KEM Paths: Consolidated four separate KEM wrap/unwrap paths (ML-KEM, X-Wing, and NIST hybrids) into a single OID-keyed registry and unified encryptor/decryptor interface.
• Key Encoding: Updated key encoding to use standard SPKI/PKCS#8 PEM blocks carrying the NIST OIDs for ML-KEM keys.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Ignored Files

• Ignored by pattern: docs/openapi/**/* (20)
  • docs/openapi/authorization/authorization.openapi.yaml
  • docs/openapi/authorization/v2/authorization.openapi.yaml
  • docs/openapi/common/common.openapi.yaml
  • docs/openapi/entity/entity.openapi.yaml
  • docs/openapi/entityresolution/entity_resolution.openapi.yaml
  • docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml
  • docs/openapi/kas/kas.openapi.yaml
  • docs/openapi/policy/actions/actions.openapi.yaml
  • docs/openapi/policy/attributes/attributes.openapi.yaml
  • docs/openapi/policy/kasregistry/key_access_server_registry.openapi.yaml
  • docs/openapi/policy/keymanagement/key_management.openapi.yaml
  • docs/openapi/policy/namespaces/namespaces.openapi.yaml
  • docs/openapi/policy/objects.openapi.yaml
  • docs/openapi/policy/obligations/obligations.openapi.yaml
  • docs/openapi/policy/registeredresources/registered_resources.openapi.yaml
  • docs/openapi/policy/resourcemapping/resource_mapping.openapi.yaml
  • docs/openapi/policy/selectors.openapi.yaml
  • docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml
  • docs/openapi/policy/unsafe/unsafe.openapi.yaml
  • docs/openapi/wellknownconfiguration/wellknown_configuration.openapi.yaml
• Ignored by pattern: protocol/**/* (2)
  • protocol/go/policy/kasregistry/key_access_server_registry.pb.go
  • protocol/go/policy/objects.pb.go

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

---

ML-KEM brings the quantum might, Unifying paths in the night. From X-Wing to hybrid grace, Security finds a steady pace.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	178.797304ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	125.42452ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	414.260588ms
Throughput	241.39 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	43.829380472s
Average Latency	435.866501ms
Throughput	114.08 requests/second

[gemini-code-assist]

Code Review

This pull request introduces support for pure ML-KEM (ML-KEM-768 and ML-KEM-1024) algorithms and unifies KEM-based key wrapping paths (ML-KEM, X-Wing, and NIST hybrids) under a single kem interface and kemEnvelope structure. Feedback on the changes highlights critical Go interface issues where returning concrete pointer types (*kemEncryptor, *kemDecryptor) or a concrete zero-value struct (AsymDecryption{}) instead of nil for interface return types can cause standard nil checks to fail due to typed nil pointer values.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Returning a concrete pointer type *kemEncryptor from newKEMEncryptor causes a subtle but critical Go gotcha when called by functions returning the PublicKeyEncryptor interface (like FromPublicPEMWithSalt). If newKEMEncryptor returns (nil, err), the caller directly returning it will produce a non-nil interface containing a typed nil pointer (PublicKeyEncryptor(*kemEncryptor(nil))). Any subsequent encryptor != nil check by SDK/service callers will evaluate to true, leading to unexpected behavior or panics. Changing the return type of newKEMEncryptor to the interface type PublicKeyEncryptor resolves this cleanly.

Suggested change

	func newKEMEncryptor(k kem, publicKey, salt, info []byte) (*kemEncryptor, error) {
	if len(publicKey) != k.pubSize() {
	return nil, fmt.Errorf("invalid %s public key size: got %d want %d", k.keyType(), len(publicKey), k.pubSize())
	}
	return &kemEncryptor{
	k: k,
	publicKey: append([]byte(nil), publicKey...),
	salt: cloneOrNil(salt),
	info: cloneOrNil(info),
	}, nil
	}
	func newKEMEncryptor(k kem, publicKey, salt, info []byte) (PublicKeyEncryptor, error) {
	if len(publicKey) != k.pubSize() {
	return nil, fmt.Errorf("invalid %s public key size: got %d want %d", k.keyType(), len(publicKey), k.pubSize())
	}
	return &kemEncryptor{
	k: k,
	publicKey: append([]byte(nil), publicKey...),
	salt: cloneOrNil(salt),
	info: cloneOrNil(info),
	}, nil
	}

[gemini-code-assist]

Similar to newKEMEncryptor, returning a concrete pointer type *kemDecryptor from newKEMDecryptor causes a typed nil pointer interface issue when returned by functions expecting PrivateKeyDecryptor (like FromPrivatePEMWithSalt). Changing the return type of newKEMDecryptor to the interface type PrivateKeyDecryptor ensures that returning nil, err on error produces a true nil interface value.

Suggested change

	func newKEMDecryptor(k kem, privateKey, salt, info []byte) (*kemDecryptor, error) {
	if len(privateKey) != k.privSize() {
	return nil, fmt.Errorf("invalid %s private key size: got %d want %d", k.keyType(), len(privateKey), k.privSize())
	}
	return &kemDecryptor{
	k: k,
	privateKey: append([]byte(nil), privateKey...),
	salt: cloneOrNil(salt),
	info: cloneOrNil(info),
	}, nil
	}
	func newKEMDecryptor(k kem, privateKey, salt, info []byte) (PrivateKeyDecryptor, error) {
	if len(privateKey) != k.privSize() {
	return nil, fmt.Errorf("invalid %s private key size: got %d want %d", k.keyType(), len(privateKey), k.privSize())
	}
	return &kemDecryptor{
	k: k,
	privateKey: append([]byte(nil), privateKey...),
	salt: cloneOrNil(salt),
	info: cloneOrNil(info),
	}, nil
	}

[gemini-code-assist]

The function FromPrivatePEMWithSalt returns (PrivateKeyDecryptor, error), where PrivateKeyDecryptor is an interface. Returning a concrete zero-value struct AsymDecryption{} on error can lead to issues where the returned interface is not nil (it contains a non-nil type with a nil/zero value), which breaks standard decrypter != nil checks. It is highly recommended to return nil, err instead.

Suggested change

	case !errors.Is(err, errNotKEM):
	return AsymDecryption{}, err
	case !errors.Is(err, errNotKEM):
	return nil, err

[github-actions]

⚠️ Govulncheck found vulnerabilities ⚠️

The following modules have known vulnerabilities:

• examples
• otdfctl
• sdk
• service
• lib/fixtures
• tests-bdd

See the workflow run for details.

[coderabbitai]

Actionable comments posted: 7

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (6)

service/kas/access/rewrap.go (1)

403-408: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Remove raw SRT/body logging from the debug path.

requestBody.String() and rbString can contain the caller’s auth token, wrapped key material, policy body, and client public key. Emitting them verbatim to logs is a credentials/PII leak; log identifiers or lengths only.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@service/kas/access/rewrap.go` around lines 403 - 408, The debug call in
p.Logger.DebugContext currently logs sensitive raw data via requestBody.String()
and rbString; change it to avoid printing credentials/PII by logging only
non-sensitive metadata (e.g., lengths, hashes, or request IDs). Update the
DebugContext invocation in rewrap.go (the call to p.Logger.DebugContext that
currently uses slog.String("rewrap_body", requestBody.String()) and
slog.String("rewrap_srt", rbString)) to emit something like
slog.Int("rewrap_body_len", requestBody.Len()) and
slog.String("rewrap_srt_hash", shortHexHash(rbString)) or a request identifier
instead of the full strings, ensuring no raw token, key material, policy, or
client public key is logged.

service/internal/security/in_process_provider.go (1)

82-90: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Dispatch PKCS8 exports by declared algorithm.

The RSA → KEM → EC probe chain swallows the real provider error for the expected key type. If a KEM export fails because the stored key is malformed or unavailable, this falls through to ECPublicKey and returns a misleading error. Since k.algorithm is already known, choose the exporter directly.

♻️ Proposed refactor

 	case trust.KeyTypePKCS8:
-		// Try to get the key as an RSA key first
-		if rsaKey, err := k.cryptoProvider.RSAPublicKey(kid); err == nil {
-			return rsaKey, nil
-		}
-		if kemKey, err := k.cryptoProvider.KEMPublicKey(kid); err == nil {
-			return kemKey, nil
-		}
-		return k.cryptoProvider.ECPublicKey(kid)
+		switch {
+		case k.algorithm == AlgorithmRSA2048 || k.algorithm == AlgorithmRSA4096:
+			return k.cryptoProvider.RSAPublicKey(kid)
+		case ocrypto.IsKEMKeyType(k.algorithm):
+			return k.cryptoProvider.KEMPublicKey(kid)
+		default:
+			return k.cryptoProvider.ECPublicKey(kid)
+		}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@service/internal/security/in_process_provider.go` around lines 82 - 90, The
PKCS8 handling currently probes RSAPublicKey → KEMPublicKey → ECPublicKey and
can mask the true error for the expected key type; change the logic to dispatch
directly based on k.algorithm (the declared algorithm on the key) and call only
the corresponding exporter (e.g., call k.cryptoProvider.RSAPublicKey(kid) if
k.algorithm indicates RSA, k.cryptoProvider.KEMPublicKey(kid) if KEM, or
k.cryptoProvider.ECPublicKey(kid) if EC), returning that call's result so the
real provider error is preserved instead of falling through to another exporter.

docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml (2)

94-180: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Fix schema composition: additionalProperties: false rejects oneOf branch-only fields

In docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml, both authorization.v2.Resource and entity.Entity declare variant properties only inside oneOf branches while setting additionalProperties: false on the parent. In OpenAPI 3.1 / JSON Schema 2020-12, additionalProperties doesn’t account for properties defined only within oneOf subschemas, so those fields can be treated as “additional” and rejected. Move the union keys to the parent schema or switch to unevaluatedProperties: false.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml` around lines
94 - 180, The parent schemas authorization.v2.Resource and entity.Entity declare
their discriminant/variant fields only inside oneOf branches while setting
additionalProperties: false, which causes JSON Schema 2020-12/OpenAPI 3.1 to
treat those branch-only properties as "additional" and reject valid inputs; fix
by moving the union keys (e.g., registeredResourceValueFqn, attributeValues
under authorization.v2.Resource and claims, clientId, emailAddress, userName
under entity.Entity) into the parent properties block (keeping the oneOf for
required+titles) or alternatively replace additionalProperties: false with
unevaluatedProperties: false on those parent schemas so branch properties are
allowed and still restricted. Ensure authorization.v2.Resource.AttributeValues
stays as a referenced schema and preserve ephemeralId and category as currently
declared.

---

317-329: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Fix google.protobuf.Any schema to match Protobuf JSON mapping (don’t overload it with Connect error detail {type,value,debug})

• docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml (317-329) defines google.protobuf.Any as an object with type, value, and optional debug, but protobuf google.protobuf.Any JSON encoding uses @type (and the embedded message JSON; value is only for well-known types), not {type,value,debug}.
• Connect error responses use a details array of objects shaped like { type, value, debug }; reusing that shape as google.protobuf.Any will break any non-error fields typed as google.protobuf.Any.
• Keep a separate schema for Connect error detail entries (details[]) and restore google.protobuf.Any to the Protobuf JSON (@type + embedded JSON) representation.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml` around lines
317 - 329, Replace the overloaded schema named google.protobuf.Any so it matches
Protobuf JSON mapping: define it as an object that uses an "`@type`" string field
plus an arbitrary embedded JSON payload (allow additionalProperties) instead of
the {type, value, debug} shape; remove the type/value/debug properties from
google.protobuf.Any. Create a separate schema (e.g., ConnectErrorDetail or
ErrorDetail) for the Connect error detail entries and use that schema for the
details[] array (with properties type, value, debug) so error details stay
isolated from true google.protobuf.Any usage; update any references for
details[] to point to the new ConnectErrorDetail schema.

docs/openapi/policy/attributes/attributes.openapi.yaml (2)

1940-2031: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Fix Get*Request schemas rejecting the new union fields

• docs/openapi/policy/attributes/attributes.openapi.yaml sets additionalProperties: false on the parent for both policy.attributes.GetAttributeRequest and policy.attributes.GetAttributeValueRequest, while attributeId/valueId/fqn are defined only within oneOf branches—so validators still treat those keys as additional and effectively only the deprecated id path remains valid.
• Fix in the proto source / OpenAPI generation so the “oneOf-only” properties are accounted for in the parent schema (e.g., move additionalProperties: false into each oneOf branch and/or use composition-aware closure like unevaluatedProperties), then regenerate the OpenAPI.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/policy/attributes/attributes.openapi.yaml` around lines 1940 -
2031, The OpenAPI schemas policy.attributes.GetAttributeRequest and
policy.attributes.GetAttributeValueRequest wrongly set additionalProperties:
false at the parent while attributeId/valueId/fqn are only declared inside oneOf
branches, causing validators to treat those keys as unexpected; fix by updating
the proto/OpenAPI generation so the union-member properties are visible at the
parent level—either move additionalProperties: false into each oneOf branch
(inside each member schema) or replace the parent additionalProperties:false
with unevaluatedProperties:false (or otherwise merge the oneOf properties into
the parent properties block) for both GetAttributeRequest and
GetAttributeValueRequest, then regenerate the OpenAPI artifacts so validators
accept attributeId/valueId/fqn (reference schemas:
policy.attributes.GetAttributeRequest and
policy.attributes.GetAttributeValueRequest).

---

1154-1162: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fix ineffective alg exclusion in OpenAPI (not: { enum: [0] })

not: { enum: [0] } only blocks the numeric literal 0. For a protobuf JSON string enum (where enum values are represented as strings), that constraint is effectively redundant and won’t filter KAS_PUBLIC_KEY_ALG_ENUM_UNSPECIFIED. Update the proto source so regeneration emits a not that excludes the actual UNSPECIFIED string value (not 0).
Location: docs/openapi/policy/attributes/attributes.openapi.yaml:1154-1162.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/policy/attributes/attributes.openapi.yaml` around lines 1154 -
1162, The OpenAPI exclusion is blocking numeric 0 but not the protobuf JSON
string for the UNSPECIFIED enum; fix the proto so the generator emits a NOT that
excludes the actual UNSPECIFIED string value (not 0). Concretely, update the
enum definition used by policy.KasPublicKeyAlgEnum so the UNSPECIFIED member is
represented with the JSON/string name the OpenAPI generator emits (or add the
proto/generator option that makes the generator output the string literal), then
regenerate docs so the alg property’s not.enum contains the UNSPECIFIED string
(matching policy.KasPublicKeyAlgEnum) instead of 0.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/openapi/authorization/authorization.openapi.yaml`:
- Around line 981-1010: The OpenAPI schema for the Connect error envelope is
wrong: the schema defines connect.error.detail as a single google.protobuf.Any
object but Connect uses details as an array; update the generator so the
connect.error schema uses a "details" property of type array with items
referencing '`#/components/schemas/google.protobuf.Any`' (replace the singular
"detail" property with "details[]"), adjust any mapping logic that converts
google.rpc.Status.details to an array (the code path that emits the
connect.error schema), then regenerate
docs/openapi/authorization/authorization.openapi.yaml so the Connect HTTP JSON
error representation matches the actual repeated details field.

In `@docs/openapi/kas/kas.openapi.yaml`:
- Around line 291-343: The kas.KeyAccessRewrapResult schema places error and
kasWrappedKey only inside oneOf branches while the parent has
additionalProperties: false and omits top-level required fields, causing valid
branch instances to be rejected; update the parent schema by either (a) moving
error and kasWrappedKey into the parent properties with appropriate types and
keep oneOf for semantics, or (b) replace additionalProperties: false with
unevaluatedProperties: false so branch-evaluated properties are allowed, and add
status and keyAccessObjectId to the parent required array so they are always
required; modify the kas.KeyAccessRewrapResult definition (oneOf, properties,
additionalProperties/unevaluatedProperties, required) accordingly.

In `@docs/openapi/policy/namespaces/namespaces.openapi.yaml`:
- Around line 875-913: The GetNamespaceRequest schema currently lists a oneOf
that only accepts fqn or namespaceId, so a payload with only the deprecated id
will fail validation; fix by adding a third oneOf branch that accepts an id-only
object (define properties.id: type string, format: uuid, title id, required: [
"id" ], keep deprecated: true) so GetNamespaceRequest will validate payloads
with only id, or alternatively remove the mention of id from the description if
you intend to disallow it; update the schema under GetNamespaceRequest
accordingly.

In `@docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml`:
- Around line 693-729: policy.Action currently sets additionalProperties: false
while defining custom and standard only inside the oneOf branches
(custom/standard), which causes valid variants to be rejected; update the
proto->OpenAPI generation so policy.Action uses unevaluatedProperties: false
(JSON Schema 2020-12 / OpenAPI 3.1) instead of additionalProperties: false, or
alternatively move the custom and standard property declarations to the
top-level properties of policy.Action while keeping the oneOf validation on
required fields; ensure the generator emits unevaluatedProperties at the
policy.Action schema level so the oneOf branches for custom and standard are
allowed.

In `@docs/openapi/wellknownconfiguration/wellknown_configuration.openapi.yaml`:
- Around line 152-197: The connect.error schema currently defines a singular
"detail" property; change it to "details" and make it an array of
google.protobuf.Any (e.g., type: array, items: $ref:
'`#/components/schemas/google.protobuf.Any`') so the ConnectRPC HTTP error JSON
representation matches the wire contract; update the schema under connect.error
(and any references) to use "details" (array) instead of "detail" and ensure
title/description remain accurate for connect.error and google.protobuf.Any.

In `@lib/ocrypto/benchmark_test.go`:
- Around line 600-604: The benchmark is using the raw 32-byte testDEK instead of
the actual AES-GCM ciphertext the production wrap path produces; update the
ASN1-Marshal benchmark (the blocks constructing kemEnvelope with EncryptedDEK)
to call the real wrap/encapsulation path to produce the AES-GCM ciphertext and
assign that to kemEnvelope.EncryptedDEK (instead of testDEK) before calling
asn1.Marshal; locate usages by the symbols kemEnvelope, EncryptedDEK, testDEK
and asn1.Marshal and do the same fix for the other two Marshal cases referenced
(lines ~631-635 and ~662-666) so the benchmark measures the real wire-format
size and cost.

In `@sdk/tdf.go`:
- Around line 678-686: If kasInfo.Algorithm is empty, detect the actual key type
from the provided PEM (kasInfo.PublicKey) before deciding KEM vs legacy; call
ocrypto.KeyType(...) on a derived algorithm or use ocrypto.IsKEMKeyType by
inferring the KEM type from the PEM, then proceed into the existing KEM branch
(generateWrapKeyWithKEM) so keyAccess.KeyType and keyAccess.WrappedKey are set
to the proper mlkem/hybrid scheme; alternatively, if you prefer strictness,
return an explicit error when kasInfo.Algorithm is empty instead of falling back
to the legacy path — update the logic around ocrypto.KeyType(kasInfo.Algorithm)
and the switch that uses ocrypto.IsKEMKeyType to incorporate the PEM-derived
type or the empty-algorithm rejection.

---

Outside diff comments:
In `@docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml`:
- Around line 94-180: The parent schemas authorization.v2.Resource and
entity.Entity declare their discriminant/variant fields only inside oneOf
branches while setting additionalProperties: false, which causes JSON Schema
2020-12/OpenAPI 3.1 to treat those branch-only properties as "additional" and
reject valid inputs; fix by moving the union keys (e.g.,
registeredResourceValueFqn, attributeValues under authorization.v2.Resource and
claims, clientId, emailAddress, userName under entity.Entity) into the parent
properties block (keeping the oneOf for required+titles) or alternatively
replace additionalProperties: false with unevaluatedProperties: false on those
parent schemas so branch properties are allowed and still restricted. Ensure
authorization.v2.Resource.AttributeValues stays as a referenced schema and
preserve ephemeralId and category as currently declared.
- Around line 317-329: Replace the overloaded schema named google.protobuf.Any
so it matches Protobuf JSON mapping: define it as an object that uses an "`@type`"
string field plus an arbitrary embedded JSON payload (allow
additionalProperties) instead of the {type, value, debug} shape; remove the
type/value/debug properties from google.protobuf.Any. Create a separate schema
(e.g., ConnectErrorDetail or ErrorDetail) for the Connect error detail entries
and use that schema for the details[] array (with properties type, value, debug)
so error details stay isolated from true google.protobuf.Any usage; update any
references for details[] to point to the new ConnectErrorDetail schema.

In `@docs/openapi/policy/attributes/attributes.openapi.yaml`:
- Around line 1940-2031: The OpenAPI schemas
policy.attributes.GetAttributeRequest and
policy.attributes.GetAttributeValueRequest wrongly set additionalProperties:
false at the parent while attributeId/valueId/fqn are only declared inside oneOf
branches, causing validators to treat those keys as unexpected; fix by updating
the proto/OpenAPI generation so the union-member properties are visible at the
parent level—either move additionalProperties: false into each oneOf branch
(inside each member schema) or replace the parent additionalProperties:false
with unevaluatedProperties:false (or otherwise merge the oneOf properties into
the parent properties block) for both GetAttributeRequest and
GetAttributeValueRequest, then regenerate the OpenAPI artifacts so validators
accept attributeId/valueId/fqn (reference schemas:
policy.attributes.GetAttributeRequest and
policy.attributes.GetAttributeValueRequest).
- Around line 1154-1162: The OpenAPI exclusion is blocking numeric 0 but not the
protobuf JSON string for the UNSPECIFIED enum; fix the proto so the generator
emits a NOT that excludes the actual UNSPECIFIED string value (not 0).
Concretely, update the enum definition used by policy.KasPublicKeyAlgEnum so the
UNSPECIFIED member is represented with the JSON/string name the OpenAPI
generator emits (or add the proto/generator option that makes the generator
output the string literal), then regenerate docs so the alg property’s not.enum
contains the UNSPECIFIED string (matching policy.KasPublicKeyAlgEnum) instead of
0.

In `@service/internal/security/in_process_provider.go`:
- Around line 82-90: The PKCS8 handling currently probes RSAPublicKey →
KEMPublicKey → ECPublicKey and can mask the true error for the expected key
type; change the logic to dispatch directly based on k.algorithm (the declared
algorithm on the key) and call only the corresponding exporter (e.g., call
k.cryptoProvider.RSAPublicKey(kid) if k.algorithm indicates RSA,
k.cryptoProvider.KEMPublicKey(kid) if KEM, or k.cryptoProvider.ECPublicKey(kid)
if EC), returning that call's result so the real provider error is preserved
instead of falling through to another exporter.

In `@service/kas/access/rewrap.go`:
- Around line 403-408: The debug call in p.Logger.DebugContext currently logs
sensitive raw data via requestBody.String() and rbString; change it to avoid
printing credentials/PII by logging only non-sensitive metadata (e.g., lengths,
hashes, or request IDs). Update the DebugContext invocation in rewrap.go (the
call to p.Logger.DebugContext that currently uses slog.String("rewrap_body",
requestBody.String()) and slog.String("rewrap_srt", rbString)) to emit something
like slog.Int("rewrap_body_len", requestBody.Len()) and
slog.String("rewrap_srt_hash", shortHexHash(rbString)) or a request identifier
instead of the full strings, ensuring no raw token, key material, policy, or
client public key is logged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7e06f245-10ee-4ccc-aa31-fc6244c218c2

📥 Commits

Reviewing files that changed from the base of the PR and between 79ab34f and 8c6e15e.

⛔ Files ignored due to path filters (2)

• protocol/go/policy/kasregistry/key_access_server_registry.pb.go is excluded by !**/*.pb.go
• protocol/go/policy/objects.pb.go is excluded by !**/*.pb.go

📒 Files selected for processing (60)

• docs/grpc/index.html
• docs/openapi/authorization/authorization.openapi.yaml
• docs/openapi/authorization/v2/authorization.openapi.yaml
• docs/openapi/common/common.openapi.yaml
• docs/openapi/entity/entity.openapi.yaml
• docs/openapi/entityresolution/entity_resolution.openapi.yaml
• docs/openapi/entityresolution/v2/entity_resolution.openapi.yaml
• docs/openapi/kas/kas.openapi.yaml
• docs/openapi/policy/actions/actions.openapi.yaml
• docs/openapi/policy/attributes/attributes.openapi.yaml
• docs/openapi/policy/kasregistry/key_access_server_registry.openapi.yaml
• docs/openapi/policy/keymanagement/key_management.openapi.yaml
• docs/openapi/policy/namespaces/namespaces.openapi.yaml
• docs/openapi/policy/objects.openapi.yaml
• docs/openapi/policy/obligations/obligations.openapi.yaml
• docs/openapi/policy/registeredresources/registered_resources.openapi.yaml
• docs/openapi/policy/resourcemapping/resource_mapping.openapi.yaml
• docs/openapi/policy/selectors.openapi.yaml
• docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml
• docs/openapi/policy/unsafe/unsafe.openapi.yaml
• docs/openapi/wellknownconfiguration/wellknown_configuration.openapi.yaml
• lib/ocrypto/asym_decryption.go
• lib/ocrypto/asym_encryption.go
• lib/ocrypto/benchmark_test.go
• lib/ocrypto/ec_key_pair.go
• lib/ocrypto/hybrid_common.go
• lib/ocrypto/hybrid_nist.go
• lib/ocrypto/hybrid_nist_test.go
• lib/ocrypto/kem.go
• lib/ocrypto/mlkem.go
• lib/ocrypto/mlkem_format_test.go
• lib/ocrypto/mlkem_test.go
• lib/ocrypto/rsa_key_pair.go
• lib/ocrypto/xwing.go
• lib/ocrypto/xwing_test.go
• otdfctl/cmd/policy/kasKeys.go
• otdfctl/docs/man/policy/kas-registry/key/create.md
• otdfctl/docs/man/policy/kas-registry/key/import.md
• otdfctl/docs/man/policy/kas-registry/key/rotate.md
• otdfctl/pkg/cli/sdkHelpers.go
• otdfctl/pkg/utils/pemvalidate.go
• sdk/basekey.go
• sdk/experimental/tdf/key_access.go
• sdk/experimental/tdf/keysplit/attributes.go
• sdk/granter.go
• sdk/tdf.go
• service/cmd/keygen/main.go
• service/internal/security/basic_manager.go
• service/internal/security/crypto_provider.go
• service/internal/security/in_process_provider.go
• service/internal/security/in_process_provider_test.go
• service/internal/security/standard_crypto.go
• service/internal/security/test_helpers_test.go
• service/kas/access/publicKey.go
• service/kas/access/rewrap.go
• service/policy/db/grant_mappings.go
• service/policy/kasregistry/key_access_server_registry.proto
• service/policy/objects.proto
• test/tdf-roundtrips.bats
• tests-bdd/cukes/utils/utils_genKeys.go

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

In Connect's HTTP JSON error representation, is the field named detailsas a repeated array ordetail as a single object?

💡 Result:

In the Connect protocol's HTTP JSON error representation, the field is named details and it is a repeated array [1][2][3]. The structure of a Connect error in JSON typically includes the code (string), message (string), and an optional details field (array) [1][2][3]. The details field contains a list of objects that wrap Protobuf messages, often including fields such as type, value, and debug [1]. Example representation: { "code": "invalid_argument", "message": "name is required", "details": [ { "type": "google.protobuf.Struct", "value": "base64-encoded-protobuf", "debug": {"field": "email", "issue": "Email is required"} } ] } [1]

Citations:

• 1: https://connectrpc.com/docs/python/errors
• 2: https://github.com/connectrpc/connect-go/blob/e9aff4ae/protocol_connect.go
• 3: https://docs.tcn.com/connect-error-6575697d0

---

Restore Connect error envelope to document details[] (not detail)

The generated OpenAPI schema models connect.error.detail as a single object, but Connect’s HTTP JSON error representation uses details as a repeated array. This is a contract mismatch that will cause generated clients/docs to deserialize real error responses incorrectly. Fix the proto/generator source that produces docs/openapi/authorization/authorization.openapi.yaml, then regenerate.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/authorization/authorization.openapi.yaml` around lines 981 -
1010, The OpenAPI schema for the Connect error envelope is wrong: the schema
defines connect.error.detail as a single google.protobuf.Any object but Connect
uses details as an array; update the generator so the connect.error schema uses
a "details" property of type array with items referencing
'`#/components/schemas/google.protobuf.Any`' (replace the singular "detail"
property with "details[]"), adjust any mapping logic that converts
google.rpc.Status.details to an array (the code path that emits the
connect.error schema), then regenerate
docs/openapi/authorization/authorization.openapi.yaml so the Connect HTTP JSON
error representation matches the actual repeated details field.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🌐 Web query:

In OpenAPI 3.1 / JSON Schema 2020-12, does additionalProperties: falseon an object allow properties declared only insideoneOfsubschemas, or are those keys still treated as additional unless the parent declares them or usesunevaluatedProperties?

💡 Result:

In OpenAPI 3.1 and JSON Schema 2020-12, the additionalProperties: false keyword does not "see" into oneOf (or other applicator) subschemas [1][2]. It only validates properties declared in properties or patternProperties within the same schema object where additionalProperties is defined [3][2]. If you declare additionalProperties: false at the same level as a oneOf keyword, any properties defined only inside the oneOf subschemas will be treated as additional and will cause validation to fail, even if they are logically part of the expected object [1][4][2]. To correctly restrict properties while using oneOf (or allOf/anyOf), you should use unevaluatedProperties: false instead [4][2]. Unlike additionalProperties, the unevaluatedProperties keyword is "applicator-aware" [5]. It tracks all properties that have been successfully validated by any schema in the entire evaluation path—including those inside oneOf, anyOf, allOf, and $ref—and only fails if there are properties remaining that have not been accounted for by any of these subschemas [6][5][2]. Summary of best practice: - Do not use additionalProperties: false when using composition keywords (oneOf, anyOf, allOf) if you intend for those subschemas to define allowed properties [4][2]. - Use unevaluatedProperties: false at the root or relevant level to ensure that all properties are fully accounted for, including those inherited or defined via composition [6][5].

Citations:

• 1: https://stackoverflow.com/questions/78113257/json-schema-oneof-and-additionalproperties-confusion
• 2: https://jsonic.io/guides/json-schema-additional-properties
• 3: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/jsonschema-core.md
• 4: https://stackoverflow.com/questions/73481514/which-is-the-correct-allof-syntax-for-openapi-3-schema-inheritance
• 5: https://www.learnjsonschema.com/2020-12/unevaluated/unevaluatedproperties
• 6: OpenAPI/JsonSchema - use unevaluatedProperties instead of additionalProperties and support setting to false microsoft/typespec#5961

---

Fix kas.KeyAccessRewrapResult schema: branch fields get rejected by additionalProperties: false

In docs/openapi/kas/kas.openapi.yaml (lines 291-343), error and kasWrappedKey are defined only inside oneOf branches, but the parent object sets additionalProperties: false. JSON Schema/OpenAPI validators can treat branch-only keys as “additional” at the parent level, so both success and failure instances may fail validation. Also, status and keyAccessObjectId are described as “Required: Always” but are not included in the parent schema’s top-level required list.

Change the parent constraint to allow branch properties (e.g., use unevaluatedProperties: false or define error/kasWrappedKey in the parent properties / adjust required) and add top-level required entries for status and keyAccessObjectId.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/kas/kas.openapi.yaml` around lines 291 - 343, The
kas.KeyAccessRewrapResult schema places error and kasWrappedKey only inside
oneOf branches while the parent has additionalProperties: false and omits
top-level required fields, causing valid branch instances to be rejected; update
the parent schema by either (a) moving error and kasWrappedKey into the parent
properties with appropriate types and keep oneOf for semantics, or (b) replace
additionalProperties: false with unevaluatedProperties: false so
branch-evaluated properties are allowed, and add status and keyAccessObjectId to
the parent required array so they are always required; modify the
kas.KeyAccessRewrapResult definition (oneOf, properties,
additionalProperties/unevaluatedProperties, required) accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python - <<'PY'
import pkgutil
import subprocess
import sys
from pathlib import Path

missing = [m for m in ("yaml", "jsonschema") if pkgutil.find_loader(m) is None]
if missing:
    subprocess.check_call([sys.executable, "-m", "pip", "install", "--quiet", "pyyaml", "jsonschema"])

import yaml
from jsonschema import Draft202012Validator

path = Path("docs/openapi/policy/namespaces/namespaces.openapi.yaml")
doc = yaml.safe_load(path.read_text())
schema = doc["components"]["schemas"]["policy.namespaces.GetNamespaceRequest"]
validator = Draft202012Validator(schema)

cases = {
    "id_only": {"id": "123e4567-e89b-12d3-a456-426614174000"},
    "namespaceId_only": {"namespaceId": "123e4567-e89b-12d3-a456-426614174000"},
    "fqn_only": {"fqn": "https://example.com"},
}

for name, instance in cases.items():
    errors = [e.message for e in validator.iter_errors(instance)]
    print(f"{name}: {'valid' if not errors else errors}")
PY

Repository: opentdf/platform

Length of output: 1935

---

Fix GetNamespaceRequest schema contract so deprecated id is actually valid

In policy.namespaces.GetNamespaceRequest (docs/openapi/policy/namespaces/namespaces.openapi.yaml:875-913), the description states callers may use deprecated id, but the top-level oneOf only includes branches that require fqn or namespaceId. A payload with only {"id": ...} matches neither branch, so schema validation will reject it. Update the schema/source to add an id-only oneOf branch (or remove the id wording from the description if it’s not supported).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/policy/namespaces/namespaces.openapi.yaml` around lines 875 -
913, The GetNamespaceRequest schema currently lists a oneOf that only accepts
fqn or namespaceId, so a payload with only the deprecated id will fail
validation; fix by adding a third oneOf branch that accepts an id-only object
(define properties.id: type string, format: uuid, title id, required: [ "id" ],
keep deprecated: true) so GetNamespaceRequest will validate payloads with only
id, or alternatively remove the mention of id from the description if you intend
to disallow it; update the schema under GetNamespaceRequest accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🌐 Web query:

In OpenAPI 3.1 / JSON Schema 2020-12, does additionalProperties: falseon an object allow properties declared only insideoneOfsubschemas, or are those keys still treated as additional unless the parent declares them or usesunevaluatedProperties?

💡 Result:

In JSON Schema 2020-12 (which OpenAPI 3.1 uses), setting additionalProperties: false on an object does NOT “see” properties declared only within oneOf subschemas. Keys that are not declared in the object schema’s own sibling properties/patternProperties (within that same schema object) are treated as additional, even if a oneOf branch would validate them—unless you use unevaluatedProperties instead. Practical implication: if your parent schema has type: object and additionalProperties: false, and the only mention of some key k is inside oneOf branches’ properties, then a validator that implements additionalProperties as specified will still reject k as “additional” at the parent level. unevaluatedProperties: false is designed to fix this by allowing the closing check to account for properties evaluated/covered by subschemas (including those reached via oneOf). Evidence: - additionalProperties “only recognizes” the sibling properties and patternProperties in the same schema object, and warns that it can’t look inside composition such as allOf/oneOf; this leads to properties declared in subschemas being invisible to additionalProperties. [1][2][3] - unevaluatedProperties is explicitly intended as a generalization of additionalProperties that can “recognize properties declared in subschemas” (including composition keywords), so it avoids rejecting those keys. [1][3][4]

Citations:

• 1: https://json-schema.org/understanding-json-schema/reference/object?highlight=dependencies
• 2: https://github.com/sourcemeta/learnjsonschema.com/blob/main/content/2020-12/applicator/additionalProperties.markdown
• 3: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/jsonschema-core.md
• 4: "unevaluatedProperties" to facilitate re-use and better schema organization json-schema-org/json-schema-spec#556

---

Fix policy.Action OpenAPI schema: additionalProperties: false conflicts with oneOf-only custom/standard properties (docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml, lines 693-729).

policy.Action is an object with additionalProperties: false, but custom and standard are declared only inside oneOf branches. Under OpenAPI 3.1 / JSON Schema 2020-12 rules, additionalProperties: false won’t allow properties that are only present in oneOf subschemas—so both action variants can be rejected. Fix the proto schema that generates this OpenAPI and regenerate (e.g., restructure the schema or use unevaluatedProperties instead of relying on oneOf-scoped properties).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/policy/subjectmapping/subject_mapping.openapi.yaml` around lines
693 - 729, policy.Action currently sets additionalProperties: false while
defining custom and standard only inside the oneOf branches (custom/standard),
which causes valid variants to be rejected; update the proto->OpenAPI generation
so policy.Action uses unevaluatedProperties: false (JSON Schema 2020-12 /
OpenAPI 3.1) instead of additionalProperties: false, or alternatively move the
custom and standard property declarations to the top-level properties of
policy.Action while keeping the oneOf validation on required fields; ensure the
generator emits unevaluatedProperties at the policy.Action schema level so the
oneOf branches for custom and standard are allowed.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

What is the JSON HTTP error representation for ConnectRPC errors? Does the payload use a detailsarray or a singledetail object?

💡 Result:

ConnectRPC (Connect protocol) represents errors over HTTP as a JSON object with top-level fields like "code" and "message", and it uses a "details" array (not a single "detail" object). For example, the official Connect error docs show a response body containing "details": [ { "type":..., "value":..., "debug":... } ]. [1] So: - Use details: [...] (array) - Not detail: {...} (single object)

Citations:

• 1: https://connectrpc.com/docs/python/errors

---

Fix connect.error schema to use details as an array, not detail as a single object.

ConnectRPC’s HTTP error JSON representation uses a details array ("details": [ { "type": ..., "value": ..., "debug": ... } ]), so the published schema changing from details[] to a single detail object is a wire-contract break for clients/docs.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/openapi/wellknownconfiguration/wellknown_configuration.openapi.yaml`
around lines 152 - 197, The connect.error schema currently defines a singular
"detail" property; change it to "details" and make it an array of
google.protobuf.Any (e.g., type: array, items: $ref:
'`#/components/schemas/google.protobuf.Any`') so the ConnectRPC HTTP error JSON
representation matches the wire contract; update the schema under connect.error
(and any references) to use "details" (array) instead of "detail" and ensure
title/description remain accurate for connect.error and google.protobuf.Any.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Benchmark the real wrapped payload.

These ASN1-Marshal cases populate kemEnvelope.EncryptedDEK with the raw 32-byte testDEK, not the AES-GCM ciphertext that the real wrap path serializes. That makes the marshal benchmark and envelope size materially more optimistic than the production wire format for all three schemes.

Also applies to: 631-635, 662-666

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/ocrypto/benchmark_test.go` around lines 600 - 604, The benchmark is using
the raw 32-byte testDEK instead of the actual AES-GCM ciphertext the production
wrap path produces; update the ASN1-Marshal benchmark (the blocks constructing
kemEnvelope with EncryptedDEK) to call the real wrap/encapsulation path to
produce the AES-GCM ciphertext and assign that to kemEnvelope.EncryptedDEK
(instead of testDEK) before calling asn1.Marshal; locate usages by the symbols
kemEnvelope, EncryptedDEK, testDEK and asn1.Marshal and do the same fix for the
other two Marshal cases referenced (lines ~631-635 and ~662-666) so the
benchmark measures the real wire-format size and cost.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Infer the wrap scheme from the PEM when kasInfo.Algorithm is empty.

This branch only keys off kasInfo.Algorithm. A caller that passes a raw ML-KEM/X-Wing PEM in kasInfo.PublicKey but leaves Algorithm empty will skip the KEM path, fall back to the legacy wrapper branch, and produce wrapped instead of mlkem-wrapped/hybrid-wrapped (or fail before that). That breaks the direct-PEM KEM flow this PR is adding. Detect the key type from the PEM before this switch, or reject empty algorithms up front.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@sdk/tdf.go` around lines 678 - 686, If kasInfo.Algorithm is empty, detect the
actual key type from the provided PEM (kasInfo.PublicKey) before deciding KEM vs
legacy; call ocrypto.KeyType(...) on a derived algorithm or use
ocrypto.IsKEMKeyType by inferring the KEM type from the PEM, then proceed into
the existing KEM branch (generateWrapKeyWithKEM) so keyAccess.KeyType and
keyAccess.WrappedKey are set to the proper mlkem/hybrid scheme; alternatively,
if you prefer strictness, return an explicit error when kasInfo.Algorithm is
empty instead of falling back to the legacy path — update the logic around
ocrypto.KeyType(kasInfo.Algorithm) and the switch that uses ocrypto.IsKEMKeyType
to incorporate the PEM-derived type or the empty-algorithm rejection.

[github-actions]

X-Test Results

✅ go@main-pull-3562
✅ java@main-pull-3562
✅ go@main-v0.9.0
✅ js@main-pull-3562
✅ java@main-v0.9.0
✅ js@main-v0.9.0
cukes-report
opentdfplatformW451EA.dockerbuild
govulncheck-failure-3
govulncheck-failure-2
govulncheck-failure-8
govulncheck-failure-5
govulncheck-failure-1
govulncheck-failure-0