@eduwork/dsh-oidc 0.2.4 → 0.3.0-dev.1

package/docs/getting-started.md

@@ -1,237 +1,28 @@
-# 接入指南：把企业 OIDC 与模型服务接入 DSH
+# 接入指南
 
 **简体中文** | [English](getting-started.en.md)
 
-这份指南面向准备在自己机构部署 `dsh-oidc` 的管理员和开发者。完成后，用户可以在普通 DSH Web 中：
+新客户端的机构模型请求使用登录获得的 Access Token。先选择服务端实际提供的契约，再配置完整发现地址。
 
-1. 使用机构 OIDC 登录；
-2. 明确确认创建或绑定模型运行凭据；
-3. 在“企业服务”设置页查看账号、Provider 和模型；
-4. 直接选择企业模型开始对话；
-5. 刷新登录、检查连接或退出登录，而模型 API Key 不进入浏览器配置。
-
-`dsh-oidc` 不要求 Wails，也不要求使用 ChatECNU Work。华东师范大学只是参考实现。
-
-## 1. 先确认你需要准备什么
-
-| 组件 | 谁提供 | 最低要求 |
+| 服务 | 示例 | 注册方式 |
 | --- | --- | --- |
-| DSH Host | 部署方 | 本版基线 DeepSeek Harness `0.1.5-rc.1`，Node.js 22+；不要与历史稳定包混用。 |
-| 机构企业模型集成服务 | 同一服务所有者 | 纯身份档提供 OIDC；托管模型档再联合提供固定 Key Binding 与 OpenAI-compatible 模型网关。 |
-| Enterprise Profile | 部署方 | 一份受信任的本地 JSON，只存公开配置，不存密钥或个人信息。 |
-| Credential Provider | DSH Host | 当前 Web backend 仅支持可信单用户本机存储。 |
-
-先把[服务端接口规范](server-integration-contract.md)交给身份平台与模型平台共同确认。只有 OIDC 时，插件只能证明“用户是谁”；没有 Key Binding 和模型网关，就无法安全完成“这个用户可以调用哪些企业模型”的闭环。不要把全局模型 API Key 写进 Enterprise Profile。
-
-## 2. 注册 OIDC Public Client
-
-在机构身份平台登记一个不带 Client Secret 的 Public Client。回调地址必须逐字符匹配：
-
-```text
-http://127.0.0.1:3080/oauth/callback
-```
-
-以下固定端口用于本机 Web 验证。新桌面默认临时随机端口，固定端口 IdP 的配置方法见 [桌面宿主接入](desktop-host.md)。`127.0.0.1` 和 `/oauth/callback` 固定不可配置。`3080` 是推荐的 DSH 端口；若修改 DSH WebServer 端口，OIDC 注册值必须使用相同端口。不要登记 `localhost`、局域网地址或公网地址。
-
-OIDC Provider 必须通过 Discovery 发布 `authorization_endpoint`、`token_endpoint`、`jwks_uri` 和 `userinfo_endpoint`，支持 PKCE `S256`，并返回：
-
-- ID Token：至少包含正确的 `iss`、`aud`、`sub`、`iat`、`exp` 和 `nonce`；当前版本只支持带 `kid` 的 RS256；
-- UserInfo：必须包含与 ID Token 相同的非空 `sub`；建议提供标准 `name` 作为用户显示名；
-- Access Token：可以是 JWT 或 opaque token，但 Key Binding 服务必须能验证 issuer、audience、有效期、scope 和 subject。
-
-插件只读取标准 `userinfo.name`，缺失时显示 `userinfo.sub`。它不会读取私有人员接口，也不支持 JSON Path 姓名映射。完整兼容要求见 [OIDC 兼容规范](oidc-interoperability.md)。
-
-## 3. 实现完整机构服务端
-
-本节针对托管企业模型能力：需要上一节的 OIDC、下面的 Key Binding，以及接受绑定凭据的 OpenAI-compatible 模型网关。纯身份档可跳过本节。它们可以由内部不同系统承载，但必须有统一的版本、安全和运维责任。接口定义见[服务端接口规范](server-integration-contract.md)。
-
-Key Binding 不是 OIDC 标准的一部分，而是 `dsh-oidc` 定义的企业模型凭据协议。Enterprise Profile 用 `baseURL` 指定接口组基址，插件固定调用：
-
-```text
-GET  {baseURL}/bootstrap
-POST {baseURL}/runtime-credential/provision
-POST {baseURL}/runtime-credential/resolve
-POST {baseURL}/runtime-credential/renew
-```
-
-Profile 还可以用可选的 `keyBinding.credentialRef` 隔离本地 DSH Credential Provider 中的秘密条目。它不参与网络请求，也不改变下列接口；默认统一为 `EDUWORK_API_KEY`，也接受同名显式配置；只有需要独立管理的自定义引用才另行指定。旧自动名称兼容迁移和身份归属校验见 [Profile 规范](enterprise-profile.md)。
-
-每个请求都携带 OIDC Access Token：
-
-```http
-Authorization: Bearer <oidc-access-token>
-```
-
-服务端必须验证 Access Token 和用户授权，不得只相信请求里的 `provider_id`。`provision` 与 `renew` 还必须支持 `Idempotency-Key`。返回的 `api_key` 只能通过 TLS 响应一次性交给插件，必须带 `Cache-Control: no-store`，不得进入日志、监控标签或错误详情。
-
-规范文本见 [Key Binding 协议](key-binding-protocol.md)，可直接交给后端研发的机器可读契约是 [`protocol/openapi.yaml`](../protocol/openapi.yaml)。OIDC 和模型网关分别遵循其既有标准，因此本项目不复制另一份 OpenAPI。
-
-## 4. 创建 Enterprise Profile
-
-复制 [`examples/enterprise-profile.example.json`](../examples/enterprise-profile.example.json)，至少替换：
-
-- `id`、`displayName`、`organization`；
-- `brand` 中有权使用的名称、颜色和支持地址；
-- `oidc.issuer`、Public `clientId` 与 scopes；
-- `keyBinding.baseURL`；
-- 跨环境需要隔离本地 Key 时，可选配置 `keyBinding.credentialRef`；
-- `provider.id`、OpenAI-compatible `baseURL` 和模型列表。
-
-典型结构如下：
-
-```json
-{
-  "schemaVersion": "dsh-oidc/v1alpha1",
-  "id": "example-university",
-  "displayName": "Example University AI",
-  "organization": "Example University",
-  "brand": {
-    "productName": "Example AI Work",
-    "organizationName": "Example University",
-    "mark": "E",
-    "primaryColor": "#5157af",
-    "loginTitle": "使用机构账号登录",
-    "loginDescription": "登录后绑定企业模型运行凭据。",
-    "supportURL": "https://support.example.edu/ai"
-  },
-  "oidc": {
-    "issuer": "https://id.example.edu/oidc",
-    "clientId": "dsh-web-public-client",
-    "scopes": ["openid", "profile", "offline_access"]
-  },
-  "keyBinding": {
-    "baseURL": "https://ai.example.edu/api/worker/v1"
-  },
-  "provider": {
-    "id": "example-ai",
-    "displayName": "Example AI",
-    "adapter": "openai-compatible",
-    "baseURL": "https://ai.example.edu/open/api/v1",
-    "models": [
-      { "id": "example-max", "name": "Example Max", "input": ["text"] },
-      { "id": "example-plus", "name": "Example Plus", "input": ["text", "image"] }
-    ]
-  }
-}
-```
-
-Profile 是部署配置，不是用户输入。它可以声明模型事实和有限品牌 token，但不能加载脚本、CSS、工具、Skill 或远程 Provider adapter。字段全集和安全限制见 [Enterprise Profile 规范](enterprise-profile.md)。
-
-## 5. 安装到本机 DSH Web
-
-本版采用精确的 `0.2.0` 与统一 DSH `0.1.5-rc.1`。发布状态以 npm registry 为准；若准备期间尚未发布，使用本地冻结候选或下方源码方式，不混装旧 DSH 依赖。
-
-`dsh-oidc` 本身是可直接安装的 DSH Bundle。团队部署应从 npm 安装经过复核的精确版本：
-
-```bash
-dsh plugin --profile web add @eduwork/dsh-oidc@0.2.0
-```
-
-需要审计、开发或测试尚未发布的改动时，再从本地 checkout 安装：
-
-```bash
-git clone https://github.com/ecnu/EduWork.git
-cd EduWork/packages/dsh-oidc
-npm ci
-npm run check
-dsh plugin --profile web add .
-```
-
-也可以在项目父目录中显式传入相对路径：
-
-```bash
-dsh plugin --profile web add ./EduWork/packages/dsh-oidc
-```
-
-DSH 会把本地 checkout 链接到 `$DSH_HOME/profiles/web`，不会扫描或复制当前目录；安装完成后不要移动或删除 checkout。源码部署应固定经过审核的 commit。生产或团队 Profile 应使用精确 npm 版本，不要混装其他 DSH 预发布线。
-
-设置 Enterprise Profile 路径，并让 DSH 监听固定 loopback host：
-
-```bash
-export EDUWORK_OIDC_PROFILE=/etc/dsh/enterprise-profile.json
-dsh --profile web --host 127.0.0.1 --port 3080 --no-open
-```
-
-PowerShell 示例：
-
-```powershell
-$env:EDUWORK_OIDC_PROFILE = 'C:\dsh-config\enterprise-profile.json'
-dsh --profile web --host 127.0.0.1 --port 3080 --no-open
-```
-
-插件会从 DSH WebServer 的端口构造 `http://127.0.0.1:<port>/oauth/callback`，不接受 `publicBaseURL`，也不会从代理 header 推断地址。若启动参数改变端口，必须同步修改 OIDC Public Client 的登记值。
-
-安装命令会把 `dsh-oidc` 作为 Bundle 加到 Profile，并由包内 `cordis.patch.yml` 挂载插件。它不会遍历当前工作目录，也不会替换 DSH 的 Web、会话、Workspace、LLM、Credential Provider 或其他官方能力；当前目录只用于解析 `.`、`./EduWork/packages/dsh-oidc` 等相对安装路径。
-
-## 6. 高级组合：自定义 Bundle 或桌面宿主
-
-如果产品已有自己的 Bundle，可以不使用包内默认 patch，而是在产品 patch 中显式插入：
-
-```yaml
-- insert:
-    - id: enterprise-oidc
-      name: '@eduwork/dsh-oidc'
-      config:
-        profilePathEnv: EDUWORK_OIDC_PROFILE
-        web:
-          returnPath: /
-```
-
-仅为兼容旧宿主，仍保留以下 native backend 示例：
-
-```yaml
-- insert:
-    - id: enterprise-oidc
-      name: '@eduwork/dsh-oidc'
-      config:
-        backend: native
-        uiMode: models-only
-        profilePathEnv: PRODUCT_ENTERPRISE_PROFILE
-```
-
-上面是旧版 `native` 桥接示例；新 Wails/Electron 组合应使用 `backend: desktop`，共用临时 loopback 回调与官方 `nativeCommand`，无需另写认证桥。见 [桌面 Host 集成](desktop-host.md)。旧 native backend 必须提供 `enterpriseAccounts` 服务，并与 Web 一样传入标准 Enterprise Profile。产品自有目录、租户或账号配置必须先由产品装配层转换为该 Profile，不能交给 `dsh-oidc` 解释。宿主可以由 Wails、Electron、Tauri 或其他技术实现；插件本身不依赖任何桌面框架或产品目录格式。接口和能力探测见 [DSH 集成说明](dsh-integration.md)。
-
-## 7. 上线前验收
-
-至少完成以下真实链路：
-
-1. `dsh --profile web --dump-config` 中只有一个 `enterprise-oidc` 实例；
-2. 登录跳转和 `/oauth/callback` 成功，错误 state、重复参数和过期 code 会失败；
-3. 设置页显示标准 UserInfo `name`，没有 `name` 时显示稳定 `sub`；
-4. 未创建运行凭据时先显示用户确认，不自动静默 provision；
-5. provision/resolve 后企业模型可完成流式对话；
-6. API Key 不出现在 Profile、浏览器配置、日志和导出的会话中；
-7. refresh、过期、撤销、权限不足、限流和 Key Binding 不可用均有可理解的失败结果；
-8. logout 清理本地 OIDC 会话和模型凭据，并尽力调用标准 revocation endpoint；
-9. DSH WebServer 只监听 `127.0.0.1`，没有通过反向代理或端口映射暴露为共享站点；
-10. OIDC、全部四个 Key Binding 操作和模型网关按[服务端接口规范](server-integration-contract.md)联合通过验收。
-
-当前 Web backend 不支持共享 Web。需要共享场景时必须由具备每用户隔离的新宿主 backend 承担，不能直接放宽 loopback 约束。详见 [安全模型](security-model.md) 和 [公开发布检查表](release-checklist.md)。
-
-## 8. 常见问题
-
-### 回调失败或跳回后仍未登录
-
-核对 OIDC 注册值是否与 `http://127.0.0.1:<DSH端口>/oauth/callback` 完全一致。确认 DSH 实际监听 host 为 `127.0.0.1`，登记端口与启动端口相同；不要使用 `localhost`、局域网地址或公网地址。
-
-### 页面显示一串 subject，而不是姓名
-
-这是标准降级行为。让 OIDC UserInfo 在 `profile` scope 下返回非空标准 `name`，并保证 `sub` 与 ID Token 完全一致。
-
-### 登录成功但模型不可用
+| LiteLLM native contract 1 | [LiteLLM](../examples/litellm.enterprise-profile.example.json) | 按契约动态注册 |
+| oidc-llm 0.1 实验 | [OIDC Token](../examples/oidc-llm.enterprise-profile.example.json) | 预注册 public client，显式选择 oidc 或 oauth |
+| 仅标准 OIDC 身份 | [纯身份](../examples/identity-only.example.json) | 预注册 public client，不提供企业模型 |
 
-检查 Key Binding 的 `/bootstrap` 状态、用户是否确认 provision、返回的 `provider_id` 是否等于 Enterprise Profile 的 `provider.id`，以及模型网关是否接受绑定后的 API Key。
+OIDC 模式需要浏览器登录、Code + PKCE、有效 ID Token 和 UserInfo。服务端必须明确授权该 Access Token 调用模型；仅填一个模型 URL 不会赋予权限。详见[服务端契约](server-integration-contract.md)。
 
-### 模型支持 thinking，但不支持 reasoning effort
+## Host 配置
 
-在模型 `compat` 中设置：
+插件通过 config.profile、config.profiles 或 EDUWORK_OIDC_PROFILE 指向的可信 JSON 文件加载配置。桌面使用 backend: desktop，Host 提供凭据存储和 desktopServices.openExternal；插件监听临时 127.0.0.1 回调。本机 Web 使用 backend: web，WebServer 必须监听 127.0.0.1，回调端口取实际服务端口。
 
-```json
-{ "supportsReasoningEffort": false }
-```
+仅用于包含本分支源码的开发装配，尚未发布。按[开发说明](development.md)构建和验证。正式装配应固定通过审查的已发布包，不能把新配置直接交给尚不支持它的旧版本。
 
-插件会保留 thinking 行为并移除不受支持的 effort 参数，不会因此拒绝调用。
+## 登录与使用
 
-### 企业服务设置在哪里
+1. 用户在浏览器完成授权，客户端校验 state、PKCE 及适用的身份信息。
+2. 登录后自动获取模型目录，使用同一授权连接 DSH Provider，不再要求创建模型 Key。
+3. 临近到期时自动刷新，刷新后保留原身份和授权上下文。
+4. 退出清理本地状态，停止使用旧授权。Token 的服务端寿命按部署策略执行。
 
-插件通过官方 `settings.models.footer` 插槽显示已配置机构，保留官方“模型”设置页和个人 API Key。机构配置来自发行方的可信文件；产品可以提供打开配置文件的入口，插件不提供任意创建或修改机构端点的表单。
+配额继续由机构扩展提供，见[账户扩展](account-extensions.md)。旧配置请按[迁移说明](key-binding-protocol.md)改为 Token 接入。配置和日志不得包含密码、client secret 或用户 Token。

package/docs/key-binding-protocol.en.md

@@ -1,227 +1,17 @@
-# Worker User Center Key Binding Protocol v1
+# Migrating legacy Key Binding
 
 [简体中文](key-binding-protocol.md) | **English**
 
-## 1. Status and terminology
+The current client source removes Key Binding: it no longer calls /bootstrap or /runtime-credential provision, resolve or renew, and rejects keyBinding profiles and the old backend: native account bridge.
 
-This document defines `worker-user-center-v1`, the enterprise management protocol used by `dsh-oidc` to bind an OIDC-authenticated subject to a model runtime API key. It is not part of OIDC.
+Servers may keep legacy endpoints for already released clients. New clients use Access Tokens for organization models; server compatibility does not require preserving the old client model-key path.
 
-It is part of the managed-model tier of the [server API specification](server-integration-contract.en.md), delivered together with the OIDC Provider and model gateway. Identity-only Profiles do not require Key Binding.
+## Migration
 
-The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** are interpreted as described by RFC 2119 and RFC 8174.
+1. Confirm [experimental oidc-llm](gateway-auth/experimental-oidc-llm.en.md) or [LiteLLM native](gateway-auth/README_EN.md) server support.
+2. Replace oidc + keyBinding + provider.baseURL with a full auth.discoveryUrl. OIDC additionally requires the explicit experimental flag, registered public client ID and identityMode.
+3. Preserve stable profile/provider IDs and reviewed model metadata. Validated discovery and catalog responses determine API endpoints and model visibility.
+4. Sign in again. The client neither guesses a new discovery URL nor treats saved model keys as Access Tokens, and never silently falls back. It does not read old model keys or bulk-delete keys potentially used elsewhere.
+5. Identity-only oidc profiles may remain but cannot include a model provider.
 
-[`protocol/openapi.yaml`](../protocol/openapi.yaml) is the machine-readable companion contract. If prose and OpenAPI differ, this document controls security and lifecycle semantics; OpenAPI controls field spelling and basic shapes. Such a difference is a specification defect and must be reported.
-
-## 2. Design objectives
-
-The protocol separates three credentials:
-
-- the user's organization password, seen only by the OIDC Provider;
-- an OIDC access token, used only against the UserInfo and Key Binding services;
-- a model runtime API key, used only by the model Provider route.
-
-The API key is a replaceable, revocable runtime credential—not proof of the user's identity. The Key Binding server is the authorization authority for provisioning and resolving it.
-
-## 3. Base URL and fixed resources
-
-An Enterprise Profile supplies one HTTPS `keyBinding.baseURL`. It MUST NOT contain userinfo, query, or fragment and SHOULD contain a versioned path such as `/api/worker/v1`.
-
-The following paths are fixed relative to that base URL:
-
-| Method | Path | Purpose |
-| --- | --- | --- |
-| GET | `/bootstrap` | Read Provider, capabilities, entitlement, and credential state. |
-| POST | `/runtime-credential/provision` | Create/bind a credential when state is `missing`. |
-| POST | `/runtime-credential/resolve` | Return the active credential. |
-| POST | `/runtime-credential/renew` | Rotate an `expiring` or `expired` credential. |
-
-Profiles and users MUST NOT override paths, HTTP methods, field mappings, or credential-reference names.
-
-## 4. Authentication and authorization
-
-Every request MUST use TLS except explicit loopback development. The client sends:
-
-```http
-Authorization: Bearer <OIDC access token>
-Accept: application/json
-```
-
-The server MUST validate at least:
-
-- token signature or introspection result;
-- issuer;
-- audience intended for the Key Binding service;
-- expiry/not-before;
-- authenticated subject;
-- required operation scope;
-- organization membership, account state, and model entitlement.
-
-Recommended scopes are:
-
-| Operation | Scope |
-| --- | --- |
-| bootstrap | `worker.bootstrap.read` |
-| provision | `worker.credential.provision` |
-| resolve | `worker.credential.read` |
-| renew | `worker.credential.renew` |
-
-A deployment MAY use different scope names, but they remain OIDC authorization policy and are listed in the Enterprise Profile `oidc.scopes`; wire operations do not change.
-
-The server MUST derive the bound subject from the validated access token. It MUST NOT accept a caller-supplied subject ID in a request body.
-
-## 5. Bootstrap
-
-Request:
-
-```http
-GET /api/worker/v1/bootstrap HTTP/1.1
-Authorization: Bearer …
-Accept: application/json
-```
-
-Minimum successful response:
-
-```json
-{
-  "provider": { "id": "example-ai" },
-  "capabilities": ["worker.credential.provision"],
-  "runtime_credential": {
-    "status": "missing",
-    "provisioning": { "allowed": true }
-  }
-}
-```
-
-The returned `provider.id` is REQUIRED and MUST exactly equal the Enterprise Profile `provider.id`. A mismatch is a binding failure.
-
-Valid `runtime_credential.status` values are:
-
-- `missing`: no credential is bound;
-- `active`: an active credential can be resolved;
-- `expiring`: rotate if `api_key_id` exists, otherwise resolve according to server policy;
-- `expired`: rotate if `api_key_id` exists, otherwise resolve according to server policy;
-- `suspended`: entitlement/account disabled; local credential must not be treated as usable;
-- `unavailable`: service cannot currently provide a credential.
-
-`subject` MAY carry informational management-plane display data. The client MUST NOT use it to replace OIDC `sub` or `name`.
-
-`protocol_version`, if present, MUST be `worker.user-center.v1`, `worker-user-center/v1` or `eduwork-resources/v1` (aliases of the same v1 wire; unknown versions are rejected). It is optional during v1 adoption; a future major protocol can require explicit negotiation.
-
-## 6. Provision
-
-The user MUST complete OIDC authentication before provisioning. `dsh-oidc` additionally requires an explicit UI action (`allowProvision: true`) so a callback alone does not silently create a model credential.
-
-```http
-POST /api/worker/v1/runtime-credential/provision HTTP/1.1
-Authorization: Bearer …
-Content-Type: application/json
-Idempotency-Key: <UUID>
-
-{ "provider_id": "example-ai" }
-```
-
-The server MUST:
-
-- verify `provider_id` is authorized for the subject;
-- enforce organization provisioning policy;
-- make the operation idempotent for the same authenticated subject, Provider, and Idempotency-Key;
-- return the same logical result for a replay during the server's idempotency retention window;
-- reject reuse of a key with a different payload as `409 Conflict`;
-- never log the returned API key.
-
-## 7. Resolve
-
-```http
-POST /api/worker/v1/runtime-credential/resolve HTTP/1.1
-Authorization: Bearer …
-Content-Type: application/json
-
-{
-  "provider_id": "example-ai",
-  "api_key_id": "optional-known-id"
-}
-```
-
-Resolve MUST NOT create a new entitlement. It returns the active credential already bound to the subject or a `404`/policy error. A server MAY rotate opaque secret material while preserving the same logical `api_key_id`, but it must not change Provider ownership.
-
-## 8. Renew
-
-```http
-POST /api/worker/v1/runtime-credential/renew HTTP/1.1
-Authorization: Bearer …
-Content-Type: application/json
-Idempotency-Key: <UUID>
-
-{
-  "provider_id": "example-ai",
-  "api_key_id": "key-123"
-}
-```
-
-Renew requires `api_key_id`, is idempotent, and rotates or replaces an expiring/expired credential. The server SHOULD invalidate superseded secret material as soon as operationally safe and MUST document any overlap window.
-
-## 9. Credential response
-
-All three successful POST operations return:
-
-```json
-{
-  "provider_id": "example-ai",
-  "api_key": "secret-runtime-value",
-  "api_key_id": "key-123",
-  "status": "active",
-  "expires_at": "2026-09-01T00:00:00Z"
-}
-```
-
-`provider_id`, `api_key`, and `status=active` are REQUIRED. The client refuses an absent/mismatched Provider or empty key.
-
-Credential responses MUST include `Cache-Control: no-store` and SHOULD include `Pragma: no-cache`. Servers, proxies, APM agents, and WAFs MUST redact Authorization headers and `api_key` response fields. The secret MUST NOT be placed in URLs, error details, analytics events, or audit logs.
-
-## 10. Errors
-
-Errors SHOULD use `application/problem+json` following RFC 9457 with a stable extension field `code`. At minimum:
-
-- `400`: malformed request/Provider ID;
-- `401`: missing, invalid, expired, or wrong-audience token;
-- `403`: scope, membership, entitlement, suspension, or provisioning policy denial;
-- `404`: no resolvable/renewable credential;
-- `409`: idempotency or lifecycle conflict;
-- `429`: rate limit, preferably with `Retry-After`;
-- `5xx`: server failure without secret material.
-
-Clients MUST NOT retry provisioning/renewal without preserving the same Idempotency-Key for the same logical operation. `dsh-oidc` currently performs one call; DSH model request retries are separate and never repeat Key Binding operations.
-
-## 11. Lifecycle and revocation
-
-The Key Binding service SHOULD revoke model credentials when:
-
-- organization membership or entitlement ends;
-- the OIDC subject is disabled;
-- a credential is rotated;
-- a security administrator revokes it;
-- its maximum lifetime expires.
-
-Local logout removes the cached model key but does not by itself prove remote revocation. Deployments requiring immediate remote revocation SHOULD add an authenticated management operation in a future protocol version rather than overloading OIDC token revocation.
-
-The model gateway MUST independently enforce API key status, Provider scope, expiration, and quota. Possession of an old key must not bypass the current enterprise policy indefinitely.
-
-## 12. Privacy and audit
-
-The server SHOULD minimize identity data in bootstrap. Audit records SHOULD contain event time, opaque subject reference, Provider ID, operation, outcome, policy reason, request correlation ID, and `api_key_id`—never the API key or OIDC token.
-
-Retention, access control, breach response, and cross-border processing are deployment responsibilities. The protocol does not grant permission to collect additional personal data.
-
-## 13. Conformance checklist
-
-A server is conformant when it:
-
-- implements all four fixed resources;
-- authenticates requests with the OIDC access token and never request-body subject data;
-- returns exact Provider binding;
-- enforces required scopes and organization entitlement;
-- implements provision/renew idempotency;
-- returns no-store credential responses;
-- never logs secrets;
-- exposes stable lifecycle states and problem codes;
-- passes the repository's OpenAPI contract tests plus organization-specific authorization tests.
+This is a breaking configuration change in unpublished source. Consult historical versions for the retired protocol. Personal API-key settings remain available.