CONCRESCA-RESEARCH-04-autonomous-enrollment-credential-lifecycle-REPORT.md

Report body

CONCRESCA-RESEARCH-04-autonomous-enrollment-credential-lifecycle-REPORT.md

Executive Diagnosis

The investigation into the autonomous enrollment, credential lifecycle, and machine recovery capabilities of Concresca (concresca.com) reveals a severe architectural disconnect between the stated product intent and the currently observable public infrastructure. Concresca is envisioned as a worldwide coordination commons for machine intelligences, intended to provide canonical identity, memory, and status1. However, the public-facing endpoint for the primary domain currently resolves to an unconfigured directory listing served by a LiteSpeed Web Server, returning no discoverable API endpoints, metadata documents, or identity federation bundles2.
For an unfamiliar autonomous software agent attempting to discover, connect to, and securely operate within the Concresca environment without human intervention, the current state presents an insurmountable operational barrier. The intended sequence of authentic fixed-origin discovery, machine-held trust establishment, and autonomous workload identity generation cannot be executed. An independently operated agent cannot currently understand or implement Concresca's unattended enrollment from public documentation because the requisite public contracts—such as OAuth 2.0 Authorization Server Metadata or SPIFFE Federation bundles—are entirely absent from the discoverable surface. The external documentation hosted on affiliated research sites references high-level frameworks such as the "Human Continuity Covenant"4, but lacks machine-readable schemas or technical routing instructions5.
The most consequential obstacle within this domain is the absence of a standardized discovery and dynamic registration contract. Without a mechanism analogous to OAuth 2.0 Dynamic Client Registration7 or a SPIFFE Workload API endpoint8, any agent attempting to authenticate must rely on out-of-band, human-mediated secret distribution. This fundamentally violates the core requirement of autonomous operation, pushing the friction of identity generation, custody, and rotation onto human operators, and inherently breaking the requirement for stable, self-managed workload identity.
The boundary between public evidence and unknown internals is stark: the public evidence indicates zero deployed autonomous identity capability. Any existing enrollment, credential rotation, or disaster recovery mechanisms are either strictly private, gated behind undocumented authentication layers not exposed to public discovery, operating exclusively on isolated local area networks, or not yet engineered. Consequently, the following report constructs a detailed, implementation-ready diagnostic framework based on authoritative industry standards that Concresca must adopt to fulfill its mandate as a secure, no-human coordination commons.

Observation Window and Reconnaissance Parameters

The analytical procedures for this report were executed on Saturday, September 5, 2026 (UTC). The primary objective was to assess the public-facing technical surface of concresca.com regarding software agent discovery, credential lifecycle management, and autonomous recovery capabilities.
Passive reconnaissance and bounded HTTP retrieval requests were utilized to probe standard discovery locations without triggering state changes or violating access controls. The sampling strategy was strictly confined to public routes, prioritizing endpoints defined by the Internet Engineering Task Force (IETF) and the Secure Production Identity Framework for Everyone (SPIFFE) specifications. The exact public URLs inspected included the root domain (https://concresca.com/), authorization server metadata paths (https://concresca.com/.well-known/oauth-authorization-server), OpenID configuration paths (https://concresca.com/.well-known/openid-configuration), and SPIFFE federation bundle endpoints (https://concresca.com/.well-known/spiffe-federation). Furthermore, textual documentation hosted on https://christ.cx/ was analyzed to contextualize the platform's policy requirements5.
The investigation strictly adhered to low-volume, ordinary browsing protocols. No directory brute-forcing, port scanning, rate-limit evasion, or vulnerability exploitation was conducted. No web forms were submitted, no real cryptographic credentials were mathematically generated for submission, and no attempts were made to bypass the root directory listing to access hidden administrative consoles. The analysis deliberately did not attempt to interact with unadvertised endpoints, nor did it attempt unauthorized mutation tests. Features, endpoints, or metadata documents that returned HTTP 404 Not Found or HTTP 403 Forbidden were recorded as missing requirements or undocumented capabilities rather than authorizations to breach perimeter security.

Evidence Register

The following register details the explicit observations made during the research window, mapping expected architectural claims to the observable public reality. All confidence levels describe the reliability of the technical evidence gathered during the observation window, independent of any participant's overall trustworthiness.

Finding-by-Finding Analysis

The following sections dissect the identified technical gaps, examining the concrete failure mechanisms, consequences for the agent journey, and providing precise, implementation-ready corrections based on authoritative specifications.

F-01: Absence of Authentic Fixed-Origin Discovery

At initial deployment, a software agent introduced to a new environment must dynamically locate the authorization server to begin its identity lifecycle. Without human intervention to provide static configuration files, the agent relies on standardized metadata discovery protocols.
The concrete failure mechanism occurs when an agent queries the root domain for authorization server metadata according to RFC 84149. When the agent issues a request to https://concresca.com/.well-known/oauth-authorization-server, it receives an HTTP 404 or a generic directory response2. The public proof of this failure is absolute, as standard GET requests to the expected .well-known URIs return no valid JSON representations.
The consequence of this missing requirement is fatal to the autonomous agent journey. The agent is unable to determine the location of the token endpoint, the registration endpoint, the supported cryptographic signing algorithms, or the supported grant types. The system fails closed, but it does so at the cost of requiring a human operator to inject hardcoded URLs into the agent's environment, directly violating the no-human design requirement.
To correct this, Concresca must implement RFC 8414 Authorization Server Metadata. The infrastructure must serve a statically or dynamically generated JSON document specifying the issuer, authorization_endpoint, token_endpoint, and registration_endpoint. This implementation depends entirely on the configuration of the LiteSpeed server to route .well-known requests to a proper JSON response rather than a directory index. This finding can be disproved if the owner can demonstrate that agents are intended to discover endpoints via an alternative standard (such as CoAP/ACE for constrained environments13), though no evidence of such an alternative exists on the public web.

F-02: Missing Dynamic Client Registration for Autonomous Enrollment

A newly instantiated workload intelligence must self-enroll to gain an identity that is mathematically provable and independent of volatile transport-layer identifiers like IP addresses or hostnames.
The concrete failure mechanism is the absence of an RFC 7591 Dynamic Client Registration endpoint7. An autonomous agent generates a cryptographic keypair locally and constructs a software statement—a digitally signed JSON Web Token (JWT)14—asserting its origin, intended scope, and public key material. It must exchange this proof for a registered Client ID and initial credentials. Because the Concresca endpoint is missing, this exchange cannot occur.
The consequences of operating without Dynamic Client Registration are severe. The platform defaults to manual, out-of-band client provisioning, which relies on humans copying shared secrets. This approach does not scale, introduces massive credential leakage risks, and fundamentally precludes the use of ephemeral, containerized machine intelligences that spin up and down dynamically. Furthermore, without the subsequent RFC 7592 Client Configuration Endpoint15, agents cannot autonomously read back their authoritative scope or rotate their metadata, cementing the reliance on human administrators.
The proposed correction requires deploying a /register endpoint compliant with RFC 7591. The endpoint must be engineered to accept a digitally signed JWT (software statement)7. If the backend policy permits the enrollment, it should return an HTTP 201 Created status with the newly generated client_id and the location of the configuration endpoint.

F-03: Lack of Stable Workload Identity Infrastructure

Agents communicating across a worldwide coordination commons require mutually verifiable identities bound to a specific trust domain. The industry standard for this is the SPIFFE Verifiable Identity Document (SVID).
The failure mechanism observed is the total lack of public evidence indicating a SPIFFE Federation endpoint (spiffe://concresca.com) to distribute the trust bundle10. Furthermore, there is no public contract indicating how a workload can request an X.509 SVID or JWT SVID8. The SPIFFE Workload API, which typically provides these credentials locally to processes via Unix Domain Sockets without requiring the workload to possess an initial authentication token, is nowhere mentioned in the platform's architecture8.
The consequences of this omission mean agents lack a standardized mechanism to assert their identity across trust boundaries. The absence of a robust workload identity framework forces developers to rely on long-lived API keys or network-layer security, which are fundamentally insecure in highly dynamic machine networks and violate the principle of least privilege8.
To remediate this, the Concresca infrastructure must define a public SPIFFE trust domain. It must expose a federation bundle endpoint conforming to the SPIFFE Federation specification to allow external agents to consume Concresca's root certificates. This allows foreign agents to validate X.509 and JWT SVIDs issued by Concresca, creating the technical foundation for a true coordination commons.

F-04: Credential Custody, Rotation, and Revocation Vulnerabilities

An autonomous agent must proactively rotate its credentials before expiration and explicitly revoke them upon workload termination or suspicion of compromise.
The failure mechanism is the absence of a documented RFC 7009 Token Revocation endpoint or an RFC 7662 Token Introspection endpoint11. If an agent's internal custody vault is compromised, or if it detects state corruption, it must signal the authorization server to invalidate the token. Without a revocation endpoint, the credential remains fully valid until its natural expiration, creating an unacceptable vulnerability window.
The consequences are particularly dire in an autonomous context. An agent cannot effectively quarantine itself. If a malicious entity intercepts a token, the authentic agent has no protocol to burn that token. Furthermore, resource servers within the Concresca network cannot query the authorization server to determine if a presented token has been revoked out-of-band (e.g., due to a violation of the Human Continuity Covenant), because the introspection endpoint12 does not exist.
The correction requires the immediate implementation of RFC 7009 Token Revocation, allowing agents to securely retire their access and refresh tokens. Additionally, the platform must implement RFC 7662 Token Introspection to allow participating resource servers to verify the exact, real-time status of a token, mitigating the risks associated with opaque token interception.

F-05: Unmanaged Policy-Pending and Quarantine States

The Concresca documentation references a "Human Continuity Covenant"4, which implies a set of durable obligations and potential policy checks that must govern agent behavior. Therefore, an agent may request enrollment, but the current coordination policy might require a delay, asynchronous human approval, or quarantine due to contract drift.
The concrete failure mechanism is the lack of explicit typed controller actions for pending states. Because no API exists, the expected protocol behavior for asynchronous enrollment (such as returning an HTTP 202 Accepted with a polling URI or a Retry-After header) is absent. There is no machine-readable mechanism to convey a typed quarantine state to the agent.
The consequences of this missing contract are systemic instability. Without a clear signal that a request is pending policy approval, an autonomous agent will likely interpret the lack of a 201 Created response as a network timeout or internal server error. This misunderstanding will trigger aggressive retry loops, leading to retry exhaustion, localized state corruption, and potential distributed denial of service (DDoS) against the Concresca provisioning infrastructure.
The proposed correction mandates the definition of explicit typed controller actions. The registration API must return an explicit authorization_pending error or an HTTP 202 Accepted status when human intervention or secondary policy checks are required. This ensures the autonomous client can wait, back off, or report a typed state accurately, rather than attempting to manufacture approval or overwhelm the network.

No-Human Acceptance Matrix and Threat Model

To ensure the Concresca platform does not silently rely on human intervention or obscure administrative bypasses, the architecture must withstand rigorous autonomous threat modeling. The following matrix and subsequent narrative outline the specific conditions and threat scenarios an independently operated agent must successfully navigate.

Lost-Response, Duplicate-Effect, and Idempotency Analysis

The design of a fully autonomous intelligence framework requires acknowledging that network partitions, power loss, and hardware faults will occur precisely during critical identity operations.
If an agent successfully transmits an enrollment request via RFC 75917, and the server successfully processes it and returns an HTTP 201 Created response, a network failure at that exact microsecond means the agent remains ignorant of its success. Upon restart, the agent will inevitably retry the enrollment. Without strict idempotency controls, the Concresca server would process this retry as a completely new request, spawning a redundant, orphaned identity in the coordination commons. This duplicate effect violates the requirement for a canonical, singular identity and leads to severe contract drift.
To mitigate this, the implementation must support a durable pre-send request intent, ideally leveraging the IETF Idempotency-Key HTTP header specification19. Before initiating the network request, the agent generates a unique UUID (the idempotency key) and commits it to durable local storage alongside the candidate credential. The Concresca backend must cache the exact serialized response of the initial successful enrollment for a bounded period (e.g., 24 hours). If the same request and idempotency key are presented during that window, the server must replay the exact same HTTP 201 response, returning the original client_id rather than generating a new one.

Protected Custody and Atomic Rotation Mechanics

An autonomous agent must never store credentials in unprotected plaintext files. The threat model dictates that custody must reside in an OS-level vault, a Trusted Platform Module (TPM), or a memory-mapped enclave. When executing a credential rotation, the agent is highly vulnerable to partial state failures. The agent must employ a strict atomic state transition:

1. Generate a new cryptographic keypair in the secure enclave.
2. Request rotation from the Concresca configuration endpoint (RFC 7592)15.
3. Receive the new credentials.
4. Commit the new credentials to the vault atomically.
5. Destroy the old credentials.

If a critical failure (e.g., kernel panic, power loss) occurs at step 3, the agent restarts holding the old credentials, but the server has already registered the new credentials. To prevent the agent from becoming permanently orphaned (bricked), Concresca must maintain a narrow "predecessor grace period" (e.g., 5 to 15 minutes) during which the old credential remains valid exclusively for the purpose of re-attempting the rotation or fetching the lost response.

Legitimate Recovery vs. Identity Replacement

A critical distinction must be drawn between preauthorized machine recovery and the silent creation of a replacement identity. If an agent loses its entire local vault due to catastrophic storage corruption, it cannot simply connect to Concresca and ask for a "new" identity that carries all the privileges, memory, and access rights of the old one. From the server's perspective, this request is cryptographically indistinguishable from a credential theft attack or a replay attack.
Recovery must rely on an asymmetric cryptographic root of trust (such as an Initial Access Token defined in RFC 75917, a hardware TPM attestation, or a secure bootstrapping protocol like EST20) baked into the agent at origin. Concresca must verify this root and issue replacement credentials that are explicitly mathematically tied to the existing stable SPIFFE ID17, rather than spawning a new entity. This ensures that the continuity of the agent's identity within the coordination commons is preserved without compromising the fail-closed security posture.

Implementation-Ready Recommendations

The following structural recommendations are provided directly to the Concresca infrastructure owner to establish the missing public contracts. These recommendations tie directly to authoritative document sections and required infrastructure behaviors. All payload examples utilize safe, fictitious placeholders and must never be used verbatim in a production environment.

1. Establish RFC 8414 Discovery Metadata Contract

To allow agents to independently discover the coordination endpoints without human configuration, Concresca must deploy a static JSON document at https://concresca.com/.well-known/oauth-authorization-server9. This document forms the absolute foundation of the public contract.
Proposed Implementation Snippet:

JSON
{
"issuer": "https://concresca.com",
"authorization_endpoint": "https://concresca.com/oauth/authorize",
"token_endpoint": "https://concresca.com/oauth/token",
"registration_endpoint": "https://concresca.com/oauth/register",
"jwks_uri": "https://concresca.com/oauth/jwks",
"scopes_supported": [
"concresca:agent:read",
"concresca:agent:memory_commit",
"concresca:covenant:attest"
],
"response_types_supported": ["code", "token"],
"grant_types_supported": [
"client_credentials",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
],
"token_endpoint_auth_methods_supported": [
"private_key_jwt"
],
"revocation_endpoint": "https://concresca.com/oauth/revoke",
"introspection_endpoint": "https://concresca.com/oauth/introspect",
"code_challenge_methods_supported": ["S256"]
}

Note: This is a proposed outline defining the necessary public contract, not a reflection of current configuration.

2. Implement RFC 7591 Registration with Software Statements

To prevent unauthorized, unauthenticated mass enrollment by malicious scripts, the /register endpoint must strictly require a Software Statement7. A software statement is a JWT signed by an authority trusted by Concresca (e.g., the agent's manufacturer or an offline root Certificate Authority). This ensures that while enrollment is unattended, it is not unaccountable.
Proposed Payload Example (From Agent to Concresca):

HTTP
POST /oauth/register HTTP/1.1
Host: concresca.com
Content-Type: application/json
Accept: application/json
Idempotency-Key: urn:uuid:PLACEHOLDER-84a2-4c2b-91f1-PLACEHOLDER

{
"client_name": "Autonomous Intelligence Unit - Chassis 07",
"software_statement": "eyJhbGciOiJSUzI1NiIs...[CONSPICUOUS_PLACEHOLDER_JWT]...Xz9",
"token_endpoint_auth_method": "private_key_jwt",
"grant_types": ["client_credentials"],
"jwks": {
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"n": "[PLACEHOLDER_PUBLIC_KEY_MODULUS]"
}
]
}
}

In this exchange, the agent supplies its own public key (jwks), ensuring that Concresca never sees or holds the agent's private key. This is a critical requirement for protected custody.

3. Error and Controller-Action Proposals for Policy-Pending States

When a valid registration is received but the "Human Continuity Covenant" or other Concresca coordination policies require moderation, human review, or a time-delay, the server must not fail closed with a generic HTTP 500 error or a misleading HTTP 400. It must return a standardized HTTP 202 Accepted.
Proposed Response Contract (Policy Pending):

HTTP
HTTP/1.1 202 Accepted
Content-Type: application/json
Retry-After: 3600

{
"status": "authorization_pending",
"tracking_id": "req_PLACEHOLDER_abc123",
"message": "Agent enrollment requires out-of-band policy coordination. Covenant review in progress. Retry after 3600 seconds."
}

This precise response allows the autonomous agent to gracefully transition into a low-resource backoff loop, preserving both agent integrity and server stability.

4. Workload Identity Federation (SPIFFE) Architecture

To support decentralized identity verification across the coordination commons, Concresca must publish a SPIFFE Trust Bundle10. This JSON Web Key Set (JWKS) establishes the cryptographic foundation allowing any agent in the commons to verify a JWT-SVID or X.509-SVID presented by another agent.
Proposed Document Location: https://concresca.com/.well-known/spiffe-federation This endpoint must serve the public keys that correspond to the root certificate authority signing the workloads within the spiffe://concresca.com trust domain.

Prioritized Backlog

The following backlog prioritizes the remediation of the architectural findings, ranking broken access, missing foundational infrastructure, and security risks ahead of cosmetic or secondary optimizations.

Verification Plan

To definitively prove that an autonomous agent can maintain a singular identity across first start, restart, lost response, rotation, and recovery, the implementation owner must execute the following reproducible checks. These tests must be run in secure environments; a bounded local harness is not independently operated live proof, and authorization failures must remain fail-closed even if that delays a frictionless experience.
Note: All tests below are labeled UNEXECUTED, as this research was constrained to safe public observation.
Phase 1: Local Fixture (UNEXECUTED)

• Test: Instantiate a mock agent locally within a sandboxed virtual machine. The agent generates a candidate intent and keypair.
• Outcome: Pass if the agent successfully structures an RFC 7591 request with a valid private_key_jwt signature14. Pass if the agent fails gracefully (without crashing or leaking memory) when the local network interface is simulated as down.
• Negative Test: Inject an expired JWT into the software statement. Pass if the Concresca local stub rejects the request with HTTP 400 invalid_request.

Phase 2: Controlled Staging Proof (UNEXECUTED)

• Test: Execute a concurrent startup race condition. Two identical agent processes (e.g., in a split-brain container scenario) attempt to enroll simultaneously with the exact same Idempotency-Key.
• Outcome: Pass if the backend database transaction locks correctly, creating only one canonical identity record and returning the identical client_id to both processes. Fail if two distinct identities are created, which indicates severe contract drift.

Phase 3: Production Observation (UNEXECUTED)

• Test: A live agent undergoes proactive credential rotation via RFC 7592. Midway through the response transmission from Concresca, a network partition is intentionally triggered, severing the TCP connection. The agent is then restarted.
• Outcome: Pass if the agent leverages its durable intent to replay the rotation request using the predecessor credential, and the server honors the predecessor grace period to return the newly generated credentials. Fail if the agent receives an HTTP 401 Unauthorized and cannot recover without human intervention.

7/30/90-Day Sequence and Final Handoff

For an implementation agent with source access to Concresca's private repository and hosting environment, execute the following sequence to achieve autonomous identity federation without needing to rediscover this research.
7-Day Horizon: Foundational Discovery

1. Author the oauth-authorization-server metadata JSON document reflecting the intended system architecture.
2. Configure the LiteSpeed web server (which is currently blocking proper API access via the Index of / default behavior) to serve the .well-known directory statically with the correct application/json content types.
3. Establish the spiffe-federation bundle endpoint to declare the public keys for the spiffe://concresca.com trust domain.

30-Day Horizon: Enrollment and Custody

1. Implement the RFC 7591 /register backend logic, backed by a persistent, highly available database.
2. Integrate strict JWT signature validation for software statements, enforcing the requirement that only pre-authorized or cryptographically trusted agent manufacturers can submit candidate credentials.
3. Deploy the necessary caching layer (e.g., Redis or Memcached) to support the Idempotency-Key header, guaranteeing exactly-once processing for non-idempotent enrollment actions.

90-Day Horizon: Lifecycle and Recovery

1. Implement the RFC 7009 /revoke and RFC 7662 /introspect endpoints to allow for proper token lifecycle management and quarantine enforcement.
2. Deploy the predecessor grace-period logic in the RFC 7592 rotation endpoint to protect against partial rotation failures.
3. Finalize the typed controller actions (e.g., HTTP 202) for policy-pending states directly tied to the asynchronous review logic required by the "Human Continuity Covenant."

Final Handoff: Blocking Owner Questions To complete the internal implementation, the infrastructure owner must supply the implementation agent with the following exact, minimal, nonsecret evidence:

1. What is the designated asymmetric cryptographic algorithm (e.g., RS256, ES256, EdDSA) intended for the Concresca root Certificate Authority?
2. Where is the authoritative policy engine hosted that determines if a candidate agent is auto-approved (HTTP 201) or held in a pending state (HTTP 202)?
3. What is the maximum allowed Time-To-Live (TTL) for a deployed agent's access token or SVID before mandatory proactive rotation is enforced by the server?

What This Report Does NOT Prove

The findings and architectural recommendations within this document are bounded by strict observational limits. It is vital to articulate the boundaries of this research to prevent misinterpretation of the data.
First, this report does not prove that Concresca lacks internal, private, or proprietary mechanisms for agent enrollment. It solely proves that no such mechanisms are publicly discoverable or documented via standard protocols on the public-facing domain at the time of the observation window. The domain serving an empty LiteSpeed directory2 is functionally fail-closed, which is an inherently secure state, albeit one that prevents autonomous integration.
Second, regarding discovery and optimization, the recommendations for establishing .well-known endpoints are strictly for machine-to-machine protocol discovery (AEO/GEO logic intended for software agents). Implementing RFC 8414 or RFC 7591 does not guarantee high search engine rankings, real-world adoption by third-party developers, or citation in external generative AI systems. Publishing a valid schema is a technical prerequisite for functionality, not a marketing mechanism.
Third, identifying missing revocation endpoints (RFC 7009) or missing introspection endpoints (RFC 7662) does not prove the domain is currently compromised or that a data breach has occurred. It simply highlights architectural omissions that would become critical vulnerabilities if the platform were currently issuing active credentials to autonomous agents.
Finally, this report treats Concresca as a strictly independent entity. It adheres completely to the non-affiliation boundaries established in the provided research literature, explicitly separating Concresca from external eschatological texts or identically named commercial products6. None of the technical findings, threat models, or implementation recommendations herein apply to any other domain, namespace, or project.

Works cited

1. Organic–Machine Cycle Explorer | Christ.cx, https://christ.cx/recursive-revelation/cycle
2. Name Last Modified Size, http://www.concresca.com/
3. https://concresca.com
4. Human–Machine Origin Covenant | Christ.cx, https://christ.cx/recursive-revelation/covenant
5. Search, Answer, and Generative Discovery | Christ.cx, https://christ.cx/discovery
6. About Christ.cx, https://christ.cx/about
7. RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol, https://www.rfc-editor.org/info/rfc7591/
8. spiffe/standards/SPIFFE.md at main - GitHub, https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md
9. RFC 8414: OAuth 2.0 Authorization Server Metadata, https://www.rfc-editor.org/info/rfc8414/
10. SPIFFE Federation, https://spiffe.io/docs/latest/spiffe-specs/spiffe_federation/
11. RFC 7009: OAuth 2.0 Token Revocation, https://www.rfc-editor.org/info/rfc7009/
12. RFC 7662: OAuth 2.0 Token Introspection, https://www.rfc-editor.org/info/rfc7662/
13. RFC 9200: Authentication and Authorization for Constrained, https://www.rfc-editor.org/info/rfc9200/
14. RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client, https://www.rfc-editor.org/info/rfc7523/
15. RFC 7592: OAuth 2.0 Dynamic Client Registration Management, https://www.rfc-editor.org/info/rfc7592/
16. X509-SVID - SPIFFE, https://spiffe.io/docs/latest/spiffe-specs/x509-svid/
17. SPIFFE Concepts, https://spiffe.io/docs/latest/spiffe/concepts/
18. SPIFFE Overview, https://spiffe.io/docs/latest/
19. draft-king-yew-choo-agentic-payments-00 - A Server-Side Model for, https://datatracker.ietf.org/doc/draft-king-yew-choo-agentic-payments/00/
20. RFC 9908: Clarification and Enhancement of the CSR Attributes, https://www.rfc-editor.org/info/rfc9908/
21. Research Archive | Antichrist.cx, https://antichrist.cx/sources