feat(spec): add trqp_v2 (ToIP TRQP v2.0) trusted_authorities type (#1)

[mjfelis]

Summary

Adds a new dereferenceable issuer-trust type, trqp_v2, to the DCQL trusted_authorities enumeration — alongside the existing openid_federation, etsi_tl, and aki. A trqp_v2 value is a DID URL whose fragment references a service entry in the authority's DID Document, pointing at that authority's ToIP Trust Registry Query Protocol v2.0 (approved) registry. So:

• a Verifier can authoritatively confirm an issuer is authorized (POST <serviceEndpoint>/authorization → authorized: true), and
• an Agent can discover where to acquire a qualifying credential (TRQP + OpenID4VCI),

without inventing an x401-specific issuer list and without locking into any single registry technology (OpenID Federation, ETSI Trusted List, EBSI, or a decentralized registry can all sit behind the same query shape).

Unlike the other dereferenceable types (which only list issuers), TRQP returns an authoritative yes/no, making trqp_v2 the one trusted_authorities type that is authoritative for enforcement, not merely an acquisition hint.

Entry shape

trqp_v2 is a plain { type, values } entry like every other type — no type-specific members:

{
  "type": "trqp_v2",
  "values": ["did:example:health-authority#trqp"]
}

• Each value is a DID URL whose fragment (#trqp) references a service entry in the authority's DID Document (per DID v1.1 §Fragment).
• The DID (fragment stripped) is the authority_id and the trust anchor; the fragment's serviceEndpoint is the TRQP v2.0 registry base.

authority_id is sent in the TRQP request body per the HTTPS binding; the fragment is for endpoint discovery only.

Why DID-fragment (security)

• DID-anchored, not URL-anchored. Trust is anchored on the authority's DID — verifiable, key-controlled, rotatable, multi-anchorable — and the registry endpoint is self-published in that DID's Document, so a request author cannot point a verifier at a fake registry without controlling the authority's DID.
• No non-standard service type. DID Core selects a service by its id (the fragment), not its type, so we rely only on the standard fragment mechanism.
• Fragment over ?service= query. DID v1.1 §5.1.3 discourages query parameters in canonical identifiers (added complexity / larger attack surface); a service's id is itself a fragment DID URL.
• Credential-resolvable. values MAY even be omitted when the authority is resolvable from the presented credential (issuer DID → JsonSchemaCredential/VTJSC → authority DID, per Verifiable Trust trust resolution); the same #trqp dereference applies to the derived authority DID.

Changes (all in spec.md)

• Credential Acquisition Guidance — new trqp_v2 bullet.
• Issuer Trust enforcement — one sentence on direct verifier enforcement: resolve the authority DID, dereference the fragment to the registry serviceEndpoint, POST /authorization, accept only on authorized: true.
• Cross-references — trqp_v2 added to the dereferenceable-type lists in the overview, design rationale, Agent Processing Rules, Verifier Processing Rules, and Issuer Trust.

The Payment Object section and all unrelated content are unchanged; the trusted_authorities preamble keeps its original { type, values } wording.

Note on registration

trusted_authorities types are ultimately governed by the DCQL registry; full standardization of trqp_v2 would also require a DCQL registration. This PR documents the type the same way the existing types are described in the spec.

[dan-proof]

Will take a look this next week, as we have active discussion going on in the FIDO member group working on this surrounding the authority/issuance list topic.