https://www.decodering.org/docs/Recent content in Documentation on Open Secrets LanguageHugoen-ushttps://www.decodering.org/docs/osl-api-specification/Mon, 01 Jan 0001 00:00:00 +0000https://www.decodering.org/docs/osl-api-specification/<h1 id="open-secrets-language-osl--abstraction-api-v100">Open Secrets Language (OSL) — Abstraction API v1.0.0</h1> <h2 id="1-goals">1) Goals</h2> <p>This version defines OSL as a provider-agnostic abstraction that can map cleanly onto:</p> <ul> <li>HashiCorp Vault</li> <li>OpenBao</li> <li>HCP Vault</li> <li>AWS Secrets Manager</li> <li>Azure Key Vault</li> <li>Google Cloud Secret Manager</li> <li>CyberArk Conjur</li> <li>Kubernetes External Secrets Operator</li> <li>Doppler</li> <li>Delinea Secret Server</li> </ul> <h3 id="key-abstraction-strategy">Key abstraction strategy</h3> <p>Different providers support different features (e.g., versioning, dynamic credentials, sync/injection). This API:</p> <ol> <li>Defines a <strong>small required core</strong> that all backends can implement.</li> <li>Adds optional modules (leases, rotation, sync) that are <strong>capability-gated</strong>.</li> <li>Makes <strong>capability discovery</strong> mandatory so clients never guess.</li> </ol> <h2 id="2-versioning-and-naming">2) Versioning and naming</h2> <ul> <li><strong>Major version in the URL path</strong>: <code>/osl/v1/...</code></li> <li><strong>Spec version returned in responses</strong>: <code>&quot;osl_version&quot;: &quot;1.0.0&quot;</code></li> <li><strong>Kebab-case</strong> for endpoint paths.</li> <li><strong>Snake-case</strong> for JSON fields.</li> </ul> <h2 id="3-authentication">3) Authentication</h2> <p>Clients MUST send a bearer token on every request:</p>https://www.decodering.org/docs/identity-agent/Mon, 01 Jan 0001 00:00:00 +0000https://www.decodering.org/docs/identity-agent/<h2 id="name">NAME</h2> <p><code>Identity Agent</code> -</p> <h2 id="description">DESCRIPTION</h2> <p>A service responsible for validating application identity using certificates installed into virtual or hardware based TPM 2.0 modules.</p> <h2 id="see-also">SEE ALSO</h2> <ul> <li><code>dcdr(1)</code></li> <li><code>dcdr-server(8)</code></li> </ul>https://www.decodering.org/docs/decodering-cli/Mon, 01 Jan 0001 00:00:00 +0000https://www.decodering.org/docs/decodering-cli/<h2 id="name">NAME</h2> <p><code>dcdr</code> - command-line client for decodeRing secret lifecycle operations.</p> <h2 id="synopsis">SYNOPSIS</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>dcdr <span style="color:#f92672">[</span>global options<span style="color:#f92672">]</span> command <span style="color:#f92672">[</span>command options<span style="color:#f92672">]</span> <span style="color:#f92672">[</span>arguments<span style="color:#f92672">]</span> </span></span></code></pre></div><h2 id="description">DESCRIPTION</h2> <p><code>dcdr</code> is the command-line interface for interacting with a decodeRing server. It supports:</p> <ul> <li>application registration and user management</li> <li>secret create/read/taint/destroy workflows</li> <li>backend visibility and audit log export</li> </ul> <p>After successful authentication with <code>dcdr auth</code>, the token is cached at <code>~/.dcdr/token</code> and reused automatically.</p> <h2 id="global-options">GLOBAL OPTIONS</h2> <ul> <li><strong><code>--addr</code></strong><br> Address of the decodeRing server.</li> <li><strong><code>--token</code></strong><br> Authentication token to use for this command.</li> <li><strong><code>--skip-verify</code></strong><br> Skip SSL certificate verification.</li> </ul> <h2 id="environment">ENVIRONMENT</h2> <ul> <li><strong><code>DCDR_TOKEN</code></strong><br> Authentication token used when <code>--token</code> is not supplied.</li> <li><strong><code>DCDR_SKIP_VERIFY</code></strong><br> If set to <code>&quot;true&quot;</code>, bypasses SSL certificate verification.</li> </ul> <h2 id="see-also">SEE ALSO</h2> <ul> <li><code>dcdr-server(8)</code></li> </ul>https://www.decodering.org/docs/decodering-core/Mon, 01 Jan 0001 00:00:00 +0000https://www.decodering.org/docs/decodering-core/<h2 id="name">NAME</h2> <p><code>dcdr-core-server</code> - server process for managing secrets through a unified backend abstraction.</p> <h2 id="synopsis">SYNOPSIS</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>dcdr-server <span style="color:#f92672">[</span>options<span style="color:#f92672">]</span> </span></span><span style="display:flex;"><span>dcdr-server generate-ssl <span style="color:#f92672">[</span>--out &lt;path&gt;<span style="color:#f92672">]</span> </span></span></code></pre></div><h2 id="description">DESCRIPTION</h2> <p><code>dcdr-server</code> provides the decodeRing Core runtime and API service for managing secrets across multiple backend providers.</p> <blockquote> <p> </p> </blockquote> <p>On first startup, the server generates encryption key shards and a root authentication token. Key shards are persisted in the <code>key_shards</code> database table, and both shards and the initial root token are printed to standard output. The root token is then used to authenticate as the <code>root</code> user. The key shards are used to assemble the unlock encryption key that unlocks the server (allowing it to accept requests) as well as encrypt sensitive data.</p>