DCP-01 — アイデンティティとプリンシパルへの結び付け¶
英語の仕様の参考訳です(25/10/2026 更新)。規範となるのは英語版です。この翻訳に規範的な効力はなく、内容が異なる場合は英語版が優先されます。識別子とコードブロックは翻訳せずにそのまま掲載しています。
人がエージェントに先立ちます。責任を負う人または法人への明示的な結び付けなしに、エージェントは存在しません。DCP-01 は、エージェントのアイデンティティを人のアイデンティティに結び付けるアーティファクトを定義します。
規範的なアーティファクト¶
| アーティファクト | 説明 | スキーマ |
|---|---|---|
| Responsible Principal Record(RPR) | 人や組織が誰か、管轄区域、責任の形態、有効性を宣言する記録。 | schemas/v1/responsible_principal_record.schema.json |
| Agent Passport(AP) | エージェントのパスポート:アイデンティティ、公開鍵、RPR への参照、状態(active/revoked/suspended)。 | schemas/v1/agent_passport.schema.json |
| Revocation Record | エージェントの失効の記録:誰が、いつ、なぜ失効させるか。 | schemas/v1/revocation_record.schema.json |
スキーマの $id:https://dcp-ai.org/schemas/v1/<name>.schema.json
検証¶
オブジェクトをそのスキーマに照らして検証します:
dcp validate schemas/v1/responsible_principal_record.schema.json <hbr.json>
dcp validate schemas/v1/agent_passport.schema.json <ap.json>
dcp validate schemas/v1/revocation_record.schema.json <revocation.json>
Citizenship Bundle(RPR と AP を含む)は次で検証します:
例¶
- tests/conformance/examples/responsible_principal_record.json
- tests/conformance/examples/agent_passport.json
フィールドと列挙値の正となるのは JSON Schema です。この文書は、それらを参照する規範的な仕様です。
管轄区域の証明(省略可能)¶
管轄区域の証明は、エージェントの Responsible Principal Record が特定の管轄区域で有効であることを証明する、省略可能なオブジェクトです。管轄区域の権限者(政府、規制機関、または認定された発行者)が作り、Signed Bundle に含めるか、それと一緒に提示することができます。
オブジェクトの形式¶
{
"type": "jurisdiction_attestation",
"issuer": "authority-us-ai-registry",
"jurisdiction": "US",
"rpr_hash": "sha256:<hex>",
"agent_id": "agent-uuid-here",
"attested_at": "2026-02-07T00:00:00Z",
"expires_at": "2027-02-07T00:00:00Z",
"signature": {
"alg": "ed25519",
"public_key_b64": "...",
"sig_b64": "..."
}
}
フィールド¶
| フィールド | 型 | 説明 |
|---|---|---|
type |
string | 常に "jurisdiction_attestation"。 |
issuer |
string | 発行する権限者の識別子。 |
jurisdiction |
string | ISO 3166-1 alpha-2 の国コード(たとえば "US"、"EU"、"JP")。 |
rpr_hash |
string | sha256:<hex> — 証明する Responsible Principal Record の正規の JSON の SHA-256。 |
agent_id |
string | Agent Passport の agent_id。 |
attested_at |
string | 証明が発行された ISO 8601 の日時。 |
expires_at |
string または null | 証明の期限が切れる ISO 8601 の日時。期限がない場合は null。 |
signature |
object | signature 自体を除くすべてのフィールドの正規の JSON に対する Ed25519 の署名。alg、public_key_b64、sig_b64。 |
仕組み¶
- エージェントの作成者(またはエージェントを保持する者)が
rpr_hash= SHA-256(canonical(responsible_principal_record)) を計算します。 - 作成者は
rpr_hash+agent_idを管轄区域の証明のサービス(または対面やオフラインの手続き)に提出します。 - 権限者は RPR(アイデンティティ、管轄区域、有効性)を確認し、証明に署名します。
- 証明はエージェントを保持する者に返され、Signed Bundle と一緒に、またはその中に保存されます。
検証¶
検証器は次のようにして証明を確認します:
- バンドルの
responsible_principal_recordからrpr_hashを計算し、証明のrpr_hashと比べる。 - 発行者の公開鍵(管轄区域の well-known の URL、または信頼する発行者の鍵の集合から得る)で Ed25519 の署名を検証する。
attested_atが過去で、expires_atがnullか未来であることを確認する。
VERIFICATION.md の手順 10 を参照してください。
発行者の公開鍵¶
プロトコルは、管轄区域が証明の公開鍵を well-known の URL で公開することを推奨しています(義務ではありません):
https://<authority>/.well-known/dcp-attestation-keys.json
形式:
{
"issuer": "authority-us-ai-registry",
"jurisdiction": "US",
"keys": [
{ "key_id": "key-2026-01", "public_key_b64": "...", "valid_from": "2026-01-01T...", "valid_until": "2027-01-01T..." }
]
}
これは慣習であり、発行者の鍵を配布する方法はどれでもかまいません(ピア、レジストリ、well-known の URL など)。
管轄区域の失効のリスト¶
管轄区域は、その管轄区域で失効したエージェントを列挙する JSON のファイルである、署名された失効のリストを公開することができます。形式、公開の慣習、検証器がそれをどう使うかは docs/STORAGE_AND_ANCHORING.md を参照してください。
参照¶
- 検証のチェックリスト:VERIFICATION.md
- 保存とアンカリング(失効のリスト、透明性ログ):docs/STORAGE_AND_ANCHORING.md
実装に関する注記(参考)¶
2026 年 10 月 25 日に追加。規範的ではありません。 これらの注記は要件を加えず、上の内容を何も変えません。
mainのリファレンスの コードがこの文書とどう関係するかを説明するものです。食い違う場合は、上の規範的な本文がそのまま有効です。
- 上のアーティファクトとコマンドは V1 のもの(
schemas/v1/)です。V2 の RPR とパスポート (schemas/v2/、DCP-AI v2.0 で規定)は、鍵のリスト(binding_keys、keys)、session_nonce、SignedPayloadのエンベロープの中の複合署名を持ちます。V2 のパスポートは DCP-05 のライフサイクルの 状態と、省略可能なemergency_revocation_tokenを加えます。 <hbr.json>、<ap.json>など山かっこで囲んだ名前は、自分のファイルのためのプレースホルダーです。- 上に示した管轄区域の証明のオブジェクトには、V1 の JSON Schema がありません。
schemas/v2/jurisdiction_attestation.schema.jsonはdcp_versionとcomposite_sigを必須とする V2 の形を定義しており、additionalProperties: falseにより、上に示したsignatureのメンバーを認めません。リファレンスの検証器 (lib/verify.js、SDK の検証器、dcp verify-bundle)は証明を確認しません。それを使う検証器は、 この節の確認を自ら行います。 schemas/v1/signed_bundle.schema.jsonとschemas/v2/signed_bundle.schema.jsonはどちらもbundleとsignatureだけを認めます(additionalProperties: false)。現在の形では、証明は Signed Bundle とは別に 提示され、それと一緒に運ばれます。追加のメンバーとして加えると、Signed Bundle はスキーマの検証を通りません。