{
  "format": "agent-article-v0",
  "article_id": "EA-162",
  "canonical_url": "/tools/ea-162-oauth-oidc-agent",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EVD-EA-162-URL-36F1B4622524",
    "EVD-EA-162-URL-CFD2790A544C",
    "EVD-EA-162-URL-4E6D674BF887",
    "EVD-EA-162-URL-CB6A61ADD96B",
    "EA-162-R11-RESEARCH",
    "EA-162-R11-WEB-READBACK"
  ],
  "unknown_ids": [
    "EA-162-UNKNOWN-01",
    "EA-162-UNKNOWN-CURRENTNESS"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-047-EA0162",
    "SRC-EA-162-URL-36F1B4622524",
    "SRC-EA-162-URL-CFD2790A544C",
    "SRC-EA-162-URL-4E6D674BF887",
    "SRC-EA-162-URL-CB6A61ADD96B",
    "WEBBODY-EA0162-R8-74EAD847"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-162-URL-36F1B4622524",
      "evidence_class": "RESEARCH",
      "title": "The OAuth 2.0 Authorization Framework | AUTHOR_ORG: IETF / RFC Editor; Dick Hardt (editor) | CANONICAL_URL:",
      "href": "https://www.rfc-editor.org/rfc/rfc6749.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-162-URL-36F1B4622524"
      ],
      "supporting_locators": [
        "EVIDENCE_TABLE",
        "- The OAuth 2.0 Authorization Framework | AUTHOR_ORG: IETF / RFC Editor; Dick Hardt (editor) | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc6749.html"
      ],
      "scope": "EVIDENCE_TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-162-URL-CFD2790A544C",
      "evidence_class": "RESEARCH",
      "title": "[S2] SOURCE_CLASS: identity_standard | EXACT_TITLE: OpenID Connect Core 1.0 incorporating errata set 2 | AUTHOR_ORG: OpenID Foundation | CANONICAL_URL:",
      "href": "https://openid.net/specs/openid-connect-core-1_0.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-162-URL-CFD2790A544C"
      ],
      "supporting_locators": [
        "EVIDENCE_TABLE",
        "S2",
        "[S2] SOURCE_CLASS: identity_standard | EXACT_TITLE: OpenID Connect Core 1.0 incorporating errata set 2 | AUTHOR_ORG: OpenID Foundation | CANONICAL_URL: https://openid.net/specs/openid-connect-core-1_0.html"
      ],
      "scope": "EVIDENCE_TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-162-URL-4E6D674BF887",
      "evidence_class": "RESEARCH",
      "title": "Best Current Practice for OAuth 2.0 Security | AUTHOR_ORG: IETF / RFC Editor | CANONICAL_URL:",
      "href": "https://www.rfc-editor.org/rfc/rfc9700.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-162-URL-4E6D674BF887"
      ],
      "supporting_locators": [
        "EVIDENCE_TABLE",
        "- Best Current Practice for OAuth 2.0 Security | AUTHOR_ORG: IETF / RFC Editor | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc9700.html"
      ],
      "scope": "EVIDENCE_TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-162-URL-CB6A61ADD96B",
      "evidence_class": "RESEARCH",
      "title": "Proof Key for Code Exchange by OAuth Public Clients | AUTHOR_ORG: IETF / RFC Editor; Nat Sakimura et al. | CANONICAL_URL:",
      "href": "https://www.rfc-editor.org/rfc/rfc7636.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-162-URL-CB6A61ADD96B"
      ],
      "supporting_locators": [
        "EVIDENCE_TABLE",
        "- Proof Key for Code Exchange by OAuth Public Clients | AUTHOR_ORG: IETF / RFC Editor; Nat Sakimura et al. | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc7636.html"
      ],
      "scope": "EVIDENCE_TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-162-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-162 監査済みresearch / canonical revision binding",
      "supports": [
        "1. ESTABLISHED [S1 support]: OAuth 2.0 is an authorization framework in which a third-party application can obtain limited access to an HTTP service. It is about access delegation, not a complete statement that the caller is a human, agent, or trusted workload.\n2. ESTABLISHED [S2 support]: OIDC Core is an identity layer on OAuth 2.0. It enables a client to verify the End-User identity based on authorization-server authentication and obtain claims; the introduction explicitly notes that OAuth 2.0 alone does not define standard end-user identity information.\n3. ESTABLISHED [S3+S4 support]: RFC 9700 describes binding authorization codes to the client/device context and identifies PKCE as a countermeasure; RFC 7636 defines the authorization-code interception threat and PKCE technique. RFC 9700 also requires risk-based refresh-token decisions and scope/resource binding when refresh tokens are issued.\n4. INFERENCE [S1-S4]: Applying these standards to an agent architecture requires an explicit mapping between human identity, workload/service identity, delegated authority, resource/audience, scopes, agent run, and tool action. The base sources do not, by themselves, define an agent's intent, autonomy, chain of delegation, or business approval semantics."
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-047-EA0162"
      ],
      "supporting_locators": [
        "COMM-047-EA0162",
        "EA-162-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-162.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-162-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-162 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0162-R8-74EAD847"
      ],
      "supporting_locators": [
        "WEBBODY-EA0162-R8-74EAD847",
        "content/staging/EA-162.md",
        "EA-162-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "WHY_THIS_MATTERS_TO_UPDATE",
      "text": "Agent systems mix human login, delegated user access, workload identity, and service-to-service calls. Future updates must not call authentication, authorization, identity claims, and delegated agent authority the same thing."
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "identity / governance / security / interoperability / Enterprise AI Core / provider mapping"
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "What do OAuth 2.0, OIDC Core, RFC 9700, and PKCE establish for access and end-user identity, and what agent-specific identity/delegation questions remain open?"
    },
    {
      "heading": "EVIDENCE_TABLE",
      "text": "[S1] SOURCE_CLASS: standards_track_rfc | EXACT_TITLE: RFC 6749 - The OAuth 2.0 Authorization Framework | AUTHOR_ORG: IETF / RFC Editor; Dick Hardt (editor) | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc6749.html | PUBLICATION_UPDATE_ACCESS: October 2012; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 6749 | SUPPORTING_LOCATOR: abstract and authorization framework sections describing a third-party application obtaining limited access to an HTTP service | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for OAuth authorization framework; limit because OAuth does not itself provide an end-user identity profile.\n[S2] SOURCE_CLASS: identity_standard | EXACT_TITLE: OpenID Connect Core 1.0 incorporating errata set 2 | AUTHOR_ORG: OpenID Foundation | CANONICAL_URL: https://openid.net/specs/openid-connect-core-1_0.html | PUBLICATION_UPDATE_ACCESS: current errata-set-2 page; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: OpenID Connect Core 1.0 errata set 2 | SUPPORTING_LOCATOR: abstract lines 16-18; introduction lines 212-217; claims section lines 1548-1566 in the recorded web capture | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for identity layer, authentication, and claims; limit for the distinction from access authorization.\n[S3] SOURCE_CLASS: best_current_practice_rfc | EXACT_TITLE: RFC 9700 - Best Current Practice for OAuth 2.0 Security | AUTHOR_ORG: IETF / RFC Editor | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc9700.html | PUBLICATION_UPDATE_ACCESS: 2025-01; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 9700 | SUPPORTING_LOCATOR: authorization-code binding and PKCE lines 576-586; refresh-token protection lines 774-790 | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for current security recommendations; limit because BCP recommendations require deployment enforcement.\n[S4] SOURCE_CLASS: standards_track_rfc | EXACT_TITLE: RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients | AUTHOR_ORG: IETF / RFC Editor; Nat Sakimura et al. | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc7636.html | PUBLICATION_UPDATE_ACCESS: September 2015; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 7636 | SUPPORTING_LOCATOR: abstract lines 9-17 and introduction lines 108-113 describing authorization-code interception and PKCE mitigation | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for PKCE threat/countermeasure; limit because PKCE does not solve all token/delegation problems."
    },
    {
      "heading": "FINDINGS",
      "text": "1. ESTABLISHED [S1 support]: OAuth 2.0 is an authorization framework in which a third-party application can obtain limited access to an HTTP service. It is about access delegation, not a complete statement that the caller is a human, agent, or trusted workload.\n2. ESTABLISHED [S2 support]: OIDC Core is an identity layer on OAuth 2.0. It enables a client to verify the End-User identity based on authorization-server authentication and obtain claims; the introduction explicitly notes that OAuth 2.0 alone does not define standard end-user identity information.\n3. ESTABLISHED [S3+S4 support]: RFC 9700 describes binding authorization codes to the client/device context and identifies PKCE as a countermeasure; RFC 7636 defines the authorization-code interception threat and PKCE technique. RFC 9700 also requires risk-based refresh-token decisions and scope/resource binding when refresh tokens are issued.\n4. INFERENCE [S1-S4]: Applying these standards to an agent architecture requires an explicit mapping between human identity, workload/service identity, delegated authority, resource/audience, scopes, agent run, and tool action. The base sources do not, by themselves, define an agent's intent, autonomy, chain of delegation, or business approval semantics."
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "OAuth/OIDC success does not prove least privilege, user intent, agent identity, tool authorization, correct audience, tenant isolation, or safe downstream action. Bearer/refresh-token leakage, confused deputy, over-broad scope, issuer mix-up, redirect/PKCE errors, stale claims, replay, token exchange, and service-account misuse remain deployment risks. RFC 9700 is a BCP, not an automatically enforced control. No provider or tenant implementation was tested."
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "issuer/discovery and TLS; client registration/type; authorization-code flow; PKCE enforcement; redirect URI; state/nonce; token issuer/audience/resource; scopes and consent; access/refresh lifetime and rotation/revocation; OIDC claims and verification; workload/service identity; token exchange/delegation profile; tenant/admin policy; region/plan; secret/key storage; audit and attribution."
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "Evidence-only desk research. No authorization request, token exchange, login, service-account operation, or authenticated tenant action was performed."
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "No identity-provider interoperability, PKCE negative test, token replay, scope/audience, delegation-chain, revocation, or audit-attribution benchmark was run."
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / COST / OPERABILITY",
      "text": "Verify issuer, signature, nonce/state, PKCE, audience/resource, scope, expiry, revocation/rotation, and tenant binding before tool execution. Never place tokens in prompts or ordinary logs. Audit should link subject/client/workload/agent-run/delegation-chain/tool-action/approval; base RFCs do not guarantee that linkage. Cost/operability includes authorization round trips, token refresh, introspection/revocation, key rotation, policy evaluation, and human approval; not measured."
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "「OAuth 2.0は限定的なHTTPリソースアクセスの委任、OIDCはOAuth上でEnd-Userの認証結果とclaimsを扱うidentity layerである。Agent運用では、human／workload／service identity、resource/audience、scope、delegation chain、tool action、approvalを別々に結び付ける必要があり、OAuth／OIDCの成功だけではagentの権限・意図・安全な実行を証明しない。」"
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "Future update Work should pin RFC/OIDC references and build a provider-neutral identity TEST_PROFILE: authorization-code+PKCE, state/nonce, audience/resource restriction, least-privilege scopes, token expiry/rotation/revocation, delegated human-to-agent-to-tool attribution, confused-deputy negative case, service identity, tenant offboarding, and audit readback. Add provider-specific availability only after current docs and non-authenticated documentation are re-checked."
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "agent identity/delegation standard; token-exchange and resource-indicator profile for agents; non-human identity semantics; provider/tenant scope mapping; card/run/tool attribution; dynamic registration; sender-constrained tokens; revocation propagation; incident rates; audit/cost/SLO."
    },
    {
      "heading": "STOP_CONDITION",
      "text": "Do not treat OAuth as identity, OIDC as authorization, a valid token as proof of user intent, or a successful login as proof of agent/tool authority. Do not claim RFC 9700/PKCE enforcement without testing the actual authorization server configuration.\nUNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED\n\n\n===== RUN CLOSE / HANDOFF =====\nINDIVIDUAL_PACKET_COUNT: 6/6 (EA-157..EA-162)"
    },
    {
      "heading": "PRIMARY_SOURCE_RECORD",
      "text": "MCP dated specification and release boundary; A2A latest plus v0.3.0 fixed specification and author repository; AG-UI official docs/events draft and repository; OpenAPI 3.1.0 and OpenAI function-calling docs; CloudEvents v1.0.2 core/binding; OAuth RFC 6749, OIDC Core 1.0 errata set 2, RFC 9700, and RFC 7636. Canonical URLs and locators are recorded per packet."
    },
    {
      "heading": "CLAIM_SEPARATION",
      "text": "Six EA_IDs each have independent exact topic, evidence table, findings, limits/counterevidence/failure envelope, gates, implementation state, benchmark boundary, security/cost/operability notes, safe wording, handoff, unknowns, and stop condition. Shared sources are not treated as shared claims."
    },
    {
      "heading": "EVIDENCE_BOUNDARY",
      "text": "Official specifications establish the documented contract at the recorded version/access boundary. They do not prove a particular plan, region, tenant, implementation, conformance, quality, security posture, business outcome, or SLO.\nLIVE_SIDE_EFFECTS: 0"
    }
  ],
  "human_url": "/tools/ea-162-oauth-oidc-agent",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-162-oauth-oidc-agent",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-162-oauth-oidc-agent"
}