[Enhancements] Proposal: Strengthening TRQP Readiness for Production-Scale Ecosystem Adoption

[sankarshanmukhopadhyay]

Summary

The Trust Registry Query Protocol (TRQP) provides a clear, well-structured foundation for lightweight, machine-readable verification of authoritative information. As multiple ecosystems evaluate adopting TRQP for production-grade deployments, several areas have emerged where the specification would benefit from additional clarification, optional profiles, or architectural extensions.

This issue proposes a set of constructive enhancements aimed at strengthening the protocol’s operational reliability, interoperability, and scalability while preserving its core design philosophy.

---

1. Lifecycle & Revocation Semantics

The current TRQP design assumes the trust registry as a static system of record and intentionally excludes update operations.

Suggested enhancement:
Introduce an optional “State Change / Lifecycle Profile” that describes how revocations, expiries, suspensions, and state transitions should be represented, queried, and timestamped.

Rationale:
Production ecosystems require deterministic temporal semantics (“valid at time T”, “revoked as of X”). Without a reference model, implementations may diverge.

---

2. Discovery Mechanism (“Registry-of-Registries”)

Discovery of a trust registry endpoint is left to the governance framework or authority_id.

Suggested enhancement:
Provide a simple discovery convention—JSON metadata document, DID service descriptor, or HTTP well-known pattern—so verifiers can reliably locate registry endpoints and retrieve governance metadata.

Rationale:
Cross-ecosystem interoperability and dynamic onboarding depend on a predictable discovery layer.

---

3. Transport Extensibility Roadmap

The HTTPS binding is well-specified, but many machine-to-machine environments require alternative transports (WebSockets, MQTT, gRPC, event streams).

Suggested enhancement:
Add a section outlining how alternative transports may be introduced via future “Transport Profiles” without changing core semantics.

Rationale:
A clear pathway prevents fragmentation and allows implementers to plan for high-throughput or low-latency environments.

---

4. Interoperability with Credential Ecosystems

TRQP is intentionally independent of specific credential technologies, but many ecosystems will rely on verifiable credentials, schema registries, or ledger anchors.

Suggested enhancement:
Provide an optional mapping profile showing how TRQP responses may reference credential status lists, VC metadata, or ledger-based proofs.

Rationale:
This reduces integration ambiguity and aligns TRQP with existing ToIP and DIF ecosystem patterns.

---

5. Non-Functional & Operational Guidance

The Security and Privacy sections are strong, but production deployments also require guidance on operational considerations.

Suggested enhancement:
Add a non-normative appendix covering recommended practices for rate limiting, caching/TTL, SLAs, geo-replication, availability, monitoring, and audit logging.

Rationale:
Shared operational guidance reduces reinvention and strengthens ecosystem reliability.

---

6. Governance Metadata Profiles

Governance references are “RECOMMENDED,” but many regulated ecosystems may require these to be normative.

Suggested enhancement:
Define two optional profiles:
• Baseline TRQP — minimal governance metadata
• High-Assurance TRQP Profile — mandatory governance, jurisdiction, dispute, and audit metadata

Rationale:
This gives high-trust sectors (financial, mobility, healthcare) a clear compliance pathway without increasing baseline protocol weight.

---

7. Recognition Semantics Across Ecosystems

The specification defines the Recognition query type but does not describe how recognition relationships should be modelled, published, or validated.

Suggested enhancement:
Add guidance or an informative section defining recommended patterns for recognition publishing, expiration, change propagation, and supporting proofs.

Rationale:
Recognition is key to multi-ecosystem interoperability, and consistent patterns will avoid divergent implementations.

---

8. Security Profiles

Security guidelines are comprehensive but generic.

Suggested enhancement:
Introduce optional “Security Profiles” (Minimal, Standard, High-Assurance) specifying expectations for authentication, MTLS, replay resistance, key rotation, timestamping, and auditability.

Rationale:
Profiles give ecosystem designers clearly differentiated implementation options aligned with their risk posture.

---

Closing

TRQP is strategically well-positioned to become the canonical verification rail for inter-ecosystem trust frameworks. These enhancements aim to support the transition from early pilots to production-scale deployments while preserving the protocol’s minimalistic and interoperable design.

[darrellodonnell]

@sankarshanmukhopadhyay I would love to see this theme broken up into themed sub-issues.

This input is great but warrants decomposition.

As one example, take the following:

The current TRQP design assumes the trust registry as a static system of record and intentionally excludes update operations.

• "assumes the trust registry as a static system of record" - I disagree with this. The TRQP assumes that the system of record can answer a question at a point in time. The system of record is not static at all - it maintains evolving state but that evolution (CRUD on the data layer, operations driving the changes) is out-of-scope of the TRQP itself. It is just the "get an answer"

• "and intentionally excludes update operations." - absolutely correct. The TRQP is about QUERY, it's in the name. That was intentional as the moment you get into the "C_UD" side of things you are deep into operations and every system will vary. That is not to say that the "trust registry" world doesn't need such input, advice, and guidance. That is needed. TRQP is just a starint point.

“State Change / Lifecycle Profile”

This is certainly valuable - the question that I ask is "whose problem is that to solve?". It isn't a query - it is, perhaps, an output of a query though - and that is important.

Your homework @sankarshanmukhopadhyay is to:

1. come up with a snazzy naming convention that we can use to anchor the sub-issues to this thread. Something like "[CONSIDERATIONS] Lifecycle & Revocation Semantics" maybe?
2. break the sub-issues out (Claude Code or Codex could do this maybe?)

[sankarshanmukhopadhyay]

Following discussion on this thread, the enhancement themes have been decomposed into atomic issues to improve clarity, prioritization, and editorial review.

The intent is not to expand or complicate the normative core of TRQP. Instead, these issues focus on optional profiles, roadmap guidance, and non-normative appendices that strengthen production readiness while preserving minimal interoperability semantics.

The following discrete issues have been opened:

1. Lifecycle metadata and revocation semantics
2. Endpoint discovery convention
3. Transport extensibility roadmap
4. Credential ecosystem integration profile
5. Non-functional operational guidance appendix
6. Governance metadata assurance profiles
7. Recognition relationship modeling clarification
8. Security posture profile definitions

Each issue (has the prefix '[RFE]') is scoped independently with clear acceptance criteria to enable phased evaluation and prioritization.

This structure should allow the working group to assess which items belong in the core specification, which should be defined as optional profiles, and which are best handled as informative guidance.

My understanding is that as a core principle TRQP should remain a minimal, read-only trust query protocol with stable semantics and low editorial surface area. I’m aligned that we should not “bake in” registry-of-registries behavior or expand TRQP into a governance framework. The step forward could be to keep the normative core minimal, and explicitly route the rest into optional profiles or informative guidance so implementers have a shared playbook without destabilizing the base spec.

Below is the proposed scoping split, to make review and triage concrete.

Topic / Concern	What stays in Normative Core	What becomes Optional Profile	What becomes Informative Guidance
Lifecycle + temporal validity (revoked/suspended/valid-at-time T)	No write semantics; core remains read-only query/response with existing meaning preserved	A lifecycle semantics profile that defines optional fields (validFrom/validUntil/revokedAt/status) and “valid-at-time” query patterns	Rationale + examples showing how implementers avoid divergent interpretations across ecosystems
Discovery (how a client finds a TRQP endpoint)	Core does not mandate discovery or introduce a registry-of-registries requirement	A discovery convention/profile (e.g., DID service endpoint pattern, well-known JSON, or similar) that is explicitly optional	Guidance describing tradeoffs and when out-of-band governance is sufficient vs when machine discovery is needed
Transport extensibility beyond REST/HTTPS	REST/HTTPS binding remains the normative baseline as currently specified	Optional transport profiles (future) that preserve the same semantics over other transports	A roadmap section describing how to add transports without breaking semantics or security properties
Credential ecosystem integration (VC status lists, schema registries, etc.)	Core remains credential-agnostic; no dependency on VC formats or ledgers	Optional “mapping” profile if the group wants a standard integration layer	Non-normative examples showing common integration patterns and boundary conditions (what TRQP asserts vs what VC mechanisms assert)
Operational best practices (TTL, caching, rate limits, SLAs, logging)	None (avoid turning ops guidance into protocol requirements)	None, unless a sector profile truly needs it	An appendix of deployment guidance to reduce production foot-guns while staying explicitly non-normative
Governance metadata (baseline vs high-assurance)	Core does not require governance metadata beyond what is already specified	Optional governance metadata assurance profiles (baseline / high-assurance)	Explanatory text on why regulated ecosystems need predictable governance metadata fields
Recognition semantics (modeling recognition relationships + validation expectations)	If recognition is already in scope, clarify only what is required to interpret responses consistently	If deeper semantics are desired, an optional profile for recognition proofing/propagation expectations	Examples and edge cases (transitivity, delegation boundaries, proof discovery) to prevent inconsistent “trust chain” modeling
Security posture differentiation (minimal/standard/high-assurance)	Keep baseline security expectations aligned with current spec posture	Optional security profiles for higher-risk deployments (mTLS, replay resistance, timestamping, auditability, key rollover expectations)	Threat-model-driven explanation of why certain controls map to certain risk environments, without forcing them into the baseline