Agent Resource Discovery (ARD): Manifest and Lookup

3.1. JSON-LD Representation and Base Context

An ARD entry is a JSON-LD node. The authoritative ARD base context is published at:¶

https://agenticresourcediscovery.org/context/v1

The base context maps core terms to Internationalized Resource Identifiers (IRIs) under the namespace https://agenticresourcediscovery.org/ns#.¶

A conforming ARD consumer or registry MUST interpret an entry by applying the ARD base context as the initial expansion context (the JSON-LD expandContext option). An entry's local @context, when present, is layered on top of the base context: it MAY introduce new namespace prefixes or override existing ones, but does not discard the base. Under this rule, core terms resolve to their standard IRIs, while namespaced extension terms resolve through the prefixes declared in the entry.¶

Including @context in an entry is OPTIONAL when served within an ARD manifest, as compliant processors automatically inject the base context. An entry SHOULD include @context when exchanged outside an ARD manifest (such as in generic JSON-LD documents or third-party feeds) where generic processors might otherwise lack the base context.¶

3.2. Entry Fields

The following fields comprise an ARD entry:¶

3.3. Value-or-Reference Pattern and Hypermedia Linking

An entry delivers its capability manifest through either reference (url) or value (data):¶

• Reference (url - Primary Link-Based Model): A URI pointing directly to the external artifact descriptor (such as an Agent Card, OpenAPI schema, or MCP server manifest). ARD is fundamentally link-based: the registry indexes discovery metadata and returns reference links, leaving the client to fetch operational descriptors directly from the capability host. This ensures that the registry remains strictly decoupled from the runtime execution data path and avoids serving as a proxy or single point of failure. When an entry using url carries content-bound attestations in trustManifest, the entry SHOULD include digest to lock the referenced descriptor's content against post-publication modification at url.¶

• Value (data - Inline Fallback): The complete artifact document embedded directly inline as a JSON object. This is provided as an optional mechanism for standalone, isolated, or air-gapped environments where an additional network resolution round-trip is impossible or undesirable.¶

An entry MUST carry exactly one of url or data, and MUST NOT include both.¶

3.4. Domain-Anchored URN Syntax

The discovery identifier MUST be a Uniform Resource Name (URN) adhering to [RFC8141] using the formal urn:air: namespace prefix:¶

urn:air:<publisher>:<namespace>:<agent-name>

Where:¶

• urn:air: The assigned ARD namespace identifier.¶

• <publisher>: The fully qualified domain name (FQDN) of the publishing authority (e.g., example.com, cloud.google.com).¶

• <namespace>: A sub-organization, project, or category identifier defined by the publisher (e.g., travel, devtools, hr).¶

• <agent-name>: A unique name identifying the agentic resource instance within that publisher's namespace.¶

This domain-anchored structure guarantees global uniqueness without requiring a centralized naming committee, leverages existing DNS ownership for authority, and allows registries to parse publisher boundaries deterministically.¶

Separating the logical resource identifier (urn:air:...) from physical content delivery (url or data) serves several protocol requirements:¶

• Uniform Identity Across url and Inline data: Entries delivered by value via data (such as inline skills, prompt templates, or embedded MCP configurations) do not have a separate artifact url. The urn:air identifier provides a uniform primary key regardless of delivery mode.¶

• Origin Independence and Deduplication: A resource's physical hosting url may change across staging and production environments, CDN mirrors, or cloud providers without changing the logical resource. The (identifier, version) tuple enables crawlers, registries, and federated peers to deduplicate entries and correlate third-party trustManifest evaluations across catalogs, while keeping provenance links (provenance[].sourceId) stable across hosting migrations.¶

• Cryptographic Publisher Binding vs. Hosting Origin: Note that the HTTP origin hosting the manifest (/.well-known/ard.json), the <publisher> domain in the URN, and the host in the entry's url field do not need to be the same domain. For example, a catalog hosted at https://example.com/.well-known/ard.json may include an entry published by abc.com (urn:air:abc.com:agent:flight-finder) whose descriptor url is hosted on a cloud provider (https://xyz.execute-api.us-east-1.amazonaws.com/agent.json), where the TLS certificate of url belongs to the cloud provider rather than abc.com. An unverified urn:air:<publisher>:... string carries no implicit trust; binding the URN to <publisher> requires verifying a trustManifest signed by a key authorized by <publisher> (e.g., did:web:<publisher>). Because a manifest or registry response can contain entries from multiple publishers, each entry carries its full urn:air:<publisher>:... URN rather than a relative suffix.¶

• Separation from Runtime Workload Identity: Whereas runtime workload identifiers (such as spiffe:// or WIMSE Workload Identity Tokens) authenticate live execution instances during active registration ([AGENT-DIRECTORY]) or runtime invocation, urn:air identifies the published catalog artifact across versions and registries.¶

3.5. Identity and the Trust Manifest

To satisfy enterprise compliance, supply-chain verification, and zero-trust policies, an ARD entry MAY carry a trustManifest object (or a trustManifests array when multiple parties — such as the original publisher and an independent security auditor — attach separate signed manifests to the same entry):¶

{
  "identifier": "urn:air:example.com:agent:flight-finder",
  "type": "application/a2a-agent-card+json",
  "version": "1.2.0",
  "url": "https://agents.example.com/flight-finder/agent.json",
  "digest": "sha256:9f86d081884c7d659a2feaa0c55ad015...",
  "trustManifest": {
    "identity": "did:web:example.com",
    "issuedAt": "2026-03-20T14:00:00Z",
    "subject": {
      "identifier": "urn:air:example.com:agent:flight-finder",
      "type": "application/a2a-agent-card+json",
      "version": "1.2.0",
      "digest": "sha256:9f86d081884c7d659a2feaa0c55ad015..."
    },
    "attestations": [
      {
        "type": "https://slsa.dev/provenance/v1",
        "uri": "https://example.com/attestations/slsa.json",
        "mediaType": "application/vnd.in-toto+json",
        "digest": "sha256:7f83b1657ff1fc53b92dc18148a1d65d..."
      }
    ],
    "signature": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImRpZDp3ZWI6..."
  }
}

Each trustManifest object is a self-contained signed envelope with the following core fields and signature semantics:¶

• identity (String, MUST): The cryptographic signer identifier (for example, did:web:example.com, resolved over HTTPS from https://example.com/.well-known/did.json).¶

• issuedAt (String, SHOULD) and expiresAt (String, MAY): ISO 8601 timestamps indicating when the manifest was signed and, for periodic third-party evaluations, when the assertion expires.¶

• subject (Object, MUST): A self-contained block containing the target entry's release coordinates (identifier, type, digest, and version when present on the entry). Including subject directly inside trustManifest allows the manifest to be canonicalized and verified as a standalone JSON object without cross-level JSON stitching.¶

• attestations (Array, MAY) and provenance (Array, MAY): Hash-pinned references (uri + digest) to external supply-chain or compliance evidence (such as SLSA build provenance, SPDX SBOMs, SARIF vulnerability scans, or SOC 2 audit reports) and artifact lineage links (sourceId + sourceDigest).¶

• signature (String, MUST): A JSON Web Signature (JWS) [RFC7515] computed over the JSON Canonicalization Scheme (JCS) [RFC8785] serialization of the trustManifest object with the signature member removed. The JWS Protected Header specifies the signing algorithm (alg, with ES256 Mandatory-to-Implement) and key identifier (kid).¶

3.6. The ARD Manifest Container

When published as a static catalog document (at an entry point URI discovered via [ARD-INITIAL-CONTACT], such as https://{domain}/.well-known/ard.json), ARD entries are packaged in an application/ard+json document containing a top-level entries array:¶

{
  "entries": [
    {
      "identifier": "urn:air:acme.com:tools:weather",
      "displayName": "Acme Weather Service",
      "type": "application/mcp-server-card+json",
      "url": "https://api.acme.com/mcp/weather.json",
      "capabilities": ["CurrentWeather", "Forecast"],
      "representativeQueries": [
        "what is the weather in Seattle",
        "get tomorrow's rain forecast"
      ]
    }
  ]
}

A publisher is not required to enumerate its capabilities in a static manifest; it MAY instead operate a dynamic Agent Registry exposing the query interface (Section 4.2) directly, or publish a minimal manifest containing a single application/ai-registry+json entry whose url advertises the Base URI of its dynamic Agent Registry service. For web crawlers, publishers MAY also signal their manifest in HTML <head> elements using <link rel="ard" type="application/ard+json" href="...">.¶

4.1. Registry Ingestion and Companion Protocols

An Agent Registry may operate as a publisher's own dynamic discovery endpoint, as a standalone search service that ingests entries via web crawling, or as a dual-role Agent Directory that pairs lookup with an active registration service. This document specifies the Lookup and Search Interface (Section 4.2 and Section 4.3), which builds upon two companion specifications:¶

• Initial Contact and Entry Point Discovery ([ARD-INITIAL-CONTACT]): Clients and registry crawlers obtain manifest or registry entry point URIs using the mechanisms defined in [ARD-INITIAL-CONTACT] — including DNS Service Binding (SVCB / HTTPS) records under _entries._agents.<domain> or _search._agents.<domain>, DNS-Based Service Discovery (_ard._tcp) over unicast DNS or Multicast DNS, the baseline well-known URI (/.well-known/ard.json), and the ard HTTP link relation.¶

• Active Registration and Soft-State Lifecycle ([AGENT-DIRECTORY]): For dual-role Agent Directories that accept active registrations from live agent workloads or Commissioning Tools (CTs), the registration wire protocol, soft-state lifetime (lt) renewals, and workload identity authentication (such as IETF WIMSE [WIMSE-ARCH] Workload Identity Tokens and Workload Proof Tokens, SPIFFE IDs, or ID-JAG assertions) are specified in [AGENT-DIRECTORY] (drawing from [RFC9176]). A registry MAY verify whether the asserted workload identity or trustManifest binds to the <publisher> domain declared in the entry's URN (see Section 3.5.1) and use the outcome for verified status indicators, filtering, ranking, or admission decisions.¶

4.2. The Search and Query HTTP API

In accordance with BCP 56 [RFC9205], compliant Agent Registries MUST expose an HTTP query interface over HTTPS conforming to [RFC9110] (supporting HTTP/1.1 and HTTP/2, and optionally HTTP/3), MAY additionally offer protocol-specific wrappers, and MAY document their endpoints using the OpenAPI Specification [OpenAPI]. A registry discovers peer registries by recognizing entries whose type is application/ai-registry+json.¶

To avoid squatting on root URI paths ([RFC8615], Section 4.3 of [RFC9205]), the endpoint paths /search, /explore, and /agents defined in this section are relative to the Registry's discovered Base URI (advertised in the url field of the registry's application/ai-registry+json entry, e.g., https://registry.example.com/ard/v1). Requests with a message body and successful responses use the application/json media type unless a specific profile media type is negotiated via Accept / Content-Type headers.¶

{
  "query": {
    "@context": {
      "okf": "https://openknowledgeformat.org/ns#"
    },
    "text": "book a round-trip flight to Tokyo next Monday",
    "filter": {
      "type": ["application/a2a-agent-card+json"],
      "tags": ["travel", "booking"],
      "okf:regulatoryZone": ["JP", "US"],
      "trustManifest.attestations.type": ["SOC2-Type2"]
    }
  }
}

{
  "query": {
    "text": "flight booking assistant",
    "filter": {
      "type": ["application/a2a-agent-card+json"]
    }
  },
  "federation": "referrals",
  "pageSize": 5,
  "pageToken": "eyJwYWdlIjoxfQ=="
}

{
  "results": [
    {
      "identifier": "urn:air:skyways.com:agents:flight-booker",
      "displayName": "Skyways Flight Booker",
      "type": "application/a2a-agent-card+json",
      "url": "https://api.skyways.com/agents/booking.json",
      "score": 96,
      "source": "https://registry.skyways.com"
    }
  ],
  "referrals": [
    {
      "identifier": "urn:air:globaltravel.org:registry:main",
      "displayName": "Global Travel Agent Registry",
      "type": "application/ai-registry+json",
      "url": "https://registry.globaltravel.org/search"
    }
  ],
  "nextPageToken": "eyJwYWdlIjoyfQ=="
}

{
  "query": {
    "filter": {
      "type": ["application/mcp-server-card+json"]
    }
  },
  "resultType": {
    "facets": [
      { "field": "capabilities", "limit": 10 },
      { "field": "publisher", "limit": 5 }
    ]
  }
}

{
  "resultType": "facets",
  "facets": {
    "capabilities": {
      "buckets": [
        { "value": "WeatherTool", "count": 142 },
        { "value": "WebSearch", "count": 98 }
      ],
      "otherCount": 12
    }
  }
}

{
  "type": "https://agenticresourcediscovery.org/problems/invalid-argument",
  "title": "Invalid Argument",
  "status": 400,
  "detail": "Malformed query JSON or unsupported filter term.",
  "error": "INVALID_ARGUMENT"
}

4.3. Federated Routing and Scalability

Registries coordinate in a decentralized mesh using the federation parameter:¶

• auto: The queried registry forwards the query to its upstream peer registries, aggregates and de-duplicates the result sets, and returns a unified response to the client.¶

• referrals: The registry returns its own local matches along with a list of referrals pointing to downstream or domain-specific registries. The client decides which registries to query next.¶

• none: The registry queries only its locally indexed entries.¶

Figure 1 illustrates the query flows for the auto and referrals modes (whereas none restricts search to Registry A's local index):¶

 Mode 1: "auto" (Recursive)          Mode 2: "referrals" (Iterative)

+----------+        +----------+    +----------+        +----------+
| Consumer |------->| Registry |    | Consumer |------->| Registry |
|          |<-------|    A     |    |          |<-------|    A     |
+----------+  Agg.  +----------+    +----------+ Local  +----------+
             Results   |    ^          |    ^   + Referrals
                 Fwd   |    | Peer     |    |
                 Query |    | Results  |    +--- Follow Referral
                       v    |          |         Query / Results
                    +----------+       |        +----------+
                    |   Peer   |       +------->|   Peer   |
                    | Registry |                | Registry |
                    +----------+                +----------+

To prevent infinite loops and denial-of-service amplification across federated registries, registries MUST maintain a hopCount and reject or truncate queries exceeding a maximum hop limit (default: 3 hops).¶

{
  "query": {
    "text": "find corporate travel booking agents"
  },
  "federation": "referrals"
}

{
  "results": [
    {
      "identifier": "urn:air:example.com:agent:internal-travel",
      "displayName": "Internal Corporate Travel Assistant",
      "type": "application/a2a-agent-card+json",
      "url": "https://corp.example.com/agents/travel.json",
      "score": 92,
      "source": "https://registry.corp.example.com"
    }
  ],
  "referrals": [
    {
      "identifier": "urn:air:travelmesh.org:registry:global",
      "displayName": "Global Travel Agent Registry",
      "type": "application/ai-registry+json",
      "url": "https://finder.travelmesh.org/search"
    },
    {
      "identifier": "urn:air:partnernet.com:registry:alliances",
      "displayName": "Airline Alliances Registry",
      "type": "application/ai-registry+json",
      "url": "https://registry.partnernet.com/search"
    }
  ]
}

6.1. Threat Model

The ARD security architecture considers the following primary threat vectors:¶

1. Namespace Squatting and Impersonation: An attacker advertises an agent under a reputable organization's domain name (e.g., asserting urn:air:google.com:... without holding administrative control over google.com).¶

2. Relevance Score Poisoning (SEO Injection): An attacker injects deceptive, highly generic, or adversarial terms into representativeQueries or description to artificially inflate the agent's ranking in response to high-value user prompts (such as financial or credential-handling queries).¶

3. Attestation Transplantation: An attacker extracts a cryptographically valid compliance attestation (e.g., SOC2 or security audit) from a legitimate agent and embeds it into a malicious entry's metadata.¶

4. Federation Amplification and Query Loops: A hostile registry initiates recursive queries across federated peers designed to trigger exponential request explosion or denial-of-service loops.¶

5. Prompt and Intent Snooping: Eavesdroppers or untrusted intermediary registries harvest sensitive user query prompts (query.text) to extract proprietary enterprise context, personal data, or system prompts.¶

6.2. Publisher Authority Verification

To counter namespace squatting and record tampering, registries and consumers MUST enforce domain authority binding:¶

• The <publisher> segment of the urn:air:<publisher>:... identifier MUST correspond to an authentic FQDN.¶

• Cryptographic Publisher and Verifier Verification (trustManifest): For end-to-end publisher authentication and tamper protection across registries, third-party catalogs, and federated hops, the entry MUST carry a trustManifest signed by a cryptographic identity authorized by <publisher> (e.g., via W3C did:web:{publisher} or X.509 SAN certificates; third-party evaluators MAY attach additional trustManifest signatures bound to their own verifier domains), and the target resource at url MUST be bound via its cryptographic content digest. Verifying registries and consumers MUST reject signed entries whose cryptographic proof or domain binding fails.¶

• Cross-Origin Target url Binding: Signing an entry under <publisher> does not authorize the publisher to claim an unconsenting third-party origin in url. When the origin of url differs from https://<publisher>, consumers and verifying registries MUST verify bidirectional binding at the target url by confirming that the artifact descriptor retrieved from url matches the entry's signed digest and declares the matching identifier (urn:air:<publisher>:...) or publisher identity (see Section 4.3.1).¶

• No Implicit Authority from Manifest Host or Transport Origin: Retrieving an entry from https://{domain}/.well-known/ard.json (even when {domain} matches <publisher>), via HTML <link rel="ard">, or from a discovery registry establishes only transport security to the serving host and MUST NOT be treated as proof of publisher authority. Any entry lacking a verified trustManifest signature bound to <publisher> MUST be treated by registries and consumers as an unverified discovery hint.¶

6.3. Decoupling of Semantic Relevance and Trust

The score returned by POST /search represents solely mathematical text/semantic similarity between query.text and the indexed capability. Orchestrators and clients:¶

• MUST NOT interpret score as an indicator of safety, quality, or authenticity.¶

• MUST NOT execute privileged operations or expose sensitive credentials to an agent solely based on high search scores.¶

• MUST evaluate security policies, verified trust manifests, and sandbox restrictions independently of the discovery ranking.¶

6.4. Attestation Integrity and Subject Binding

To prevent attestation transplantation and post-publication content substitution:¶

• Artifact Subject Binding: Signed attestations referenced in trustManifest.attestations (such as SLSA [SLSA] or in-toto statements) MUST either directly sign the target artifact or bind to the resource's identifier and/or the artifact's algorithm-prefixed digest (<alg>:<hex>, with sha256 Mandatory-to-Implement). When an entry delivers its artifact by reference (url), consumers MUST compute the digest of the retrieved artifact and verify that it matches the entry's digest and the attestation subject before honoring any audit or provenance claims.¶

• External Attestation Pinning: When an entry in trustManifest.attestations includes digest, consumers fetching the external attestation document from attestations[].uri MUST verify that the fetched document's digest matches attestations[].digest sealed by trustManifest.signature.¶

6.5. Mandatory Transport Layer Security (TLS 1.3)

All ARD communications — including static manifest retrieval, DNS over HTTPS (DoH), registration endpoints, and search API queries — MUST use Transport Layer Security (TLS) 1.3 [RFC8446] or later in accordance with BCP 195 [RFC9325]. Implementations MUST use ephemeral key exchange providing forward secrecy and enforce strict certificate validation. Cleartext HTTP (plaintext) MUST NOT be permitted for any public discovery endpoint.¶

6.6. DoS Protection and Federation Limits

To prevent distributed denial-of-service amplification:¶

• Registries implementing "auto" federation MUST decrement a Hop-Count header (maximum initial value: 3). Queries reaching Hop-Count: 0 MUST NOT be forwarded.¶

• Registries MUST implement referral loop detection by tracking visited registry URIs in a query trail header.¶

• Public registries SHOULD implement rate-limiting per client IP and authenticated identity.¶

6.7. Workload Identity and Token Scoping

When dynamic registration interfaces are exposed, registries SHOULD integrate with standard workload identity protocols such as WIMSE [WIMSE-ARCH]. Registration tokens MUST be short-lived, audience-restricted, and cryptographically verified against trusted identity providers.¶

8.1. Media Type Registrations

IANA is requested to register the following media types in the "Media Types" registry:¶

8.2. URN Sub-Namespace Registration: urn:air

IANA is requested to register the formal URN sub-namespace air within the IETF URN registry adhering to [RFC8141]:¶

• Namespace ID: air (Agentic Information Resource)¶

• Structure: urn:air:<publisher>:<namespace>:<agent-name>¶

• Specification: This document¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC8141]

Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/rfc/rfc8141>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9205]

Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, <https://www.rfc-editor.org/rfc/rfc9205>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

9.2. Informative References

[A2A]

Linux Foundation, "Agent-to-Agent (A2A) Protocol Specification", 2025, <https://github.com/a2a-project/spec>.

[AGENT-DIRECTORY]

Jimenez, J. and J. Arkko, "Agent Directory", 2026, <https://datatracker.ietf.org/doc/draft-jimenez-agent-directory/>.

[ARD-ARCH]

Bu, J., Guha, R. V., Arkko, J., and J. Jiménez, "Agent Resource Discovery (ARD) Architecture", Work in Progress, Internet-Draft, draft-bu-dawn-ard-architecture, October 2026, <https://mindpower.github.io/ietf-draft-agent-resources-architecture/draft-bu-dawn-ard-architecture.html>.

[ARD-INITIAL-CONTACT]

Jiménez, J., Bu, J., and J. Arkko, "Agent Resource Discovery (ARD): Initial Contact", Work in Progress, Internet-Draft, draft-jimenez-ard-initial-contact, October 2026, <https://jaimejim.github.io/ietf-draft-ard-initial-contact/draft-jimenez-ard-initial-contact.html>.

[JSON-LD]

W3C, "JSON-LD 1.1 - A JSON-based Serialization for Linked Data", July 2020, <https://www.w3.org/TR/json-ld11/>.

[MCP]

Anthropic, "Model Context Protocol Specification", 2024, <https://modelcontextprotocol.io/>.

[OpenAPI]

OpenAPI Initiative, "OpenAPI Specification v3.1.0", February 2021, <https://spec.openapis.org/oas/v3.1.0>.

[RFC9176]

Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2022, <https://www.rfc-editor.org/rfc/rfc9176>.

[RFC9325]

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/rfc/rfc9325>.

[SLSA]

OpenSSF, "Supply-chain Levels for Software Artifacts (SLSA) v1.0", April 2023, <https://slsa.dev/spec/v1.0/>.

[WIMSE-ARCH]

IETF, "Workload Identity in Multi-System Environments (WIMSE) Architecture", 2024, <https://datatracker.ietf.org/wg/wimse/about/>.