The main item is the draft-le-agent-passport-00 thread. The author set out per-constraint subsumption rules for -01 and agreed to compare them with other delegation drafts before IETF 127. The only other change is an authorship-ordering PR on OAuth 2.1.
Updated 13 November at 06:50 UTC
Where the specs stand
IETF drafts by Datatracker state. Highlighted ones changed in the last seven days.
Agent Passport author spells out -01 rules for cumulative limits, RAR grants and per-constraint attenuation of delegation receipts.
In reply to Kieran Sweeney, Ben Le says -01 will require a receipt with a cumulative limit to name exactly one relying party, which alone counts for the receipt and all its children. A limit without a single named party will be invalid. Sharing a total across relying parties is out of scope, and whether another party in the call path could keep the total is left open. He will define an RFC 9396 authorization_details type for grants so an authorization server that supports RAR can issue root receipts directly, while Token Exchange remains the path for an agent that obtains a receipt using its passport as actor token. He also gives a per-constraint subsumption table (host, port, methods, paths, tools, max_body_bytes, max_calls, max_spend, exp, aud). A child attenuates its parent only if every rule holds, unknown members are rejected, and anything not comparable is rejected. -01 has only a fixed limit of 8 receipts per chain and no depth claim. He plans to join Niki's comparison side meeting on 16 November and hold his own on 17 November, ahead of IETF 127.
An authorization server that already supports RAR could issue root delegation receipts for agents using a new authorization_details type.
A relying party enforcing a cumulative spend or call cap on an agent chain must be the one named counter in the receipt.
Implementers of several agent delegation drafts can use the per-constraint attenuation table as a basis for shared test vectors.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Named in the thread as having its own subsumption rule to compare against.
Related in IETF WIMSE: draft-hulea-wimse-agent-mandate. Named in the thread (as Hulea) among the drafts whose attenuation rules are to be compared.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. Kieran Sweeney, who replies in the thread, authors this credential delegation draft. This is an inference from the author name only.
Editorial
A PR proposes moving Dick and Torsten from authors to the acknowledgements in OAuth 2.1.
The PR body argues that Aaron has contributed far more to the document than anyone else, so the attribution should reflect that. It includes a screenshot as an imperfect example measure. No spec text or protocol behaviour changes. The material gives no discussion or outcome.
AAT-02 thread: compare leaves that carry an action binding apart from leaves that cite a separate approval proof, and record shared replay state.
Mohamad Yossif argues that a chain leaf need not express the binding to one exact request itself. It can carry the digest of, or cite by jti, a separate proof. He describes draft-yossif-psea-03 as a proof signed by the approver's enrolled device over the SHA-256 of the request in RFC 8785 form, which a verifier refuses on replay. He suggests the comparison list "not expressible in the token" and "expressible by reference" as two entries. Iman agrees, would keep the action identifier, approval jti and proof reference distinct, and notes that conformance case DR-C7 only checks a second presentation to the same verifier. Iman proposes a new test presenting one proof through two leaves at two enforcement points and checking that at most one finalization succeeds, which separate local replay caches would not show. The thread contains no draft text change.
Authors of an agent authorization token who must decide whether per-request approval is carried in the token or referenced from an external proof.
Deployers running several enforcement points in one verification domain who must decide whether replay state has to be shared across them.
Discussion
Kieran replies on draft-le-agent-passport-00: shared limits need one counter, and RAR could carry root receipts.
The message is a reply to Ben on two open items of the new Agent Passports and Delegation Receipts draft; only Kieran's reply is in the material, not the draft itself. On shared limit accounting between relying parties, he says a cumulative limit needs a single writer that sees every exercise. Separate RPs cannot hold the total, so either the receipt names one RP or a party in the call path keeps the running total. On RAR, he agrees authorization_details can be used for grants, so an AS that already does RAR can issue root receipts. He suggests first lining up the subsumption rule per constraint type, since asor, AAT and Hulea each have their own, and says Niki has offered to compare them before IETF 127.
An AS that already supports RAR and wants to issue root delegation receipts using authorization_details.
A designer of a multi-RP agent system who must decide where a shared spending or call limit is counted.
Related in IETF WIMSE: draft-hulea-wimse-agent-mandate. Named as one of the drafts with its own subsumption rule.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Named as one of the drafts with its own subsumption rule.
Discussion
The list is discussing what an optional approver-side signature in authorization-evidence should have to prove, before any mechanism is picked.
Mohamad Khalil Yossif argued that the as_signature in Section 9.4 only proves the AS recorded an approval, not that the approver made it. They proposed draft-yossif-psea (an EAT profile in RATS, signing the SHA-256 of RFC 8785 bytes after user verification) as one way to produce the approver's signature, carried in an optional member of authorization_evidence. They noted it would not close 9.5, since trusted display stays out of scope. The author, Dapeng, replied that the draft deliberately leaves the mechanism open and could add requirements or reference existing IETF work, but that the priority is WG convergence on the problem statement and evidence model. Iman then listed what a signed approver statement should cover: purpose, decision, exact disclosure bytes or canonical digest, approved authority bounds and the approval occurrence. They also asked for a trusted approver-to-credential binding, audience and freshness checks, and an explicit signed-byte boundary to avoid a circular dependency with the AS-signed record. They suggested test cases and said a valid signature with unestablished display provenance should be reported as a separate result. No draft text changed.
sequenceDiagram
participant A as Approver device
participant AS as Authorization server
participant V as Verifier
AS->>A: Show disclosure and bounds
A->>A: User verification, sign digest of canonical bytes
A->>AS: Approver proof
AS->>V: authorization_evidence with as_signature and optional proof
V->>V: Compare digest, check binding, audience, freshness
Who this affects
An AS that records user approvals for agent actions and needs a way to show the approval came from the person, not only from the AS's own record.
A verifier that must distinguish a valid approver signature from proof of what the person actually saw on screen.
Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also about signed authorization-evidence records for agent actions, but the mail does not reference it, so the link is by topic.
Discussion
A contributor proposes a mechanism-free requirements list for an approver-side signature in section 9.4 of draft-liu-oauth-authorization-evidence-02.
Mohamad asks to be added to the GitHub repository (account MohamadKhalilYossif) and agrees that requirements should come first. For 9.4 he proposes a short normative list that any approver-side signature must meet, naming no mechanism: it covers the exact disclosure bytes or their digest, it is made by a credential bound to the approver at enrollment, and it identifies the approval it belongs to. Existing work, PSEA included, would then be an informative reference. He will send this as a pull request rather than on the list. This is a proposal in a message, not yet text in the draft.
An implementer of human-approval flows for agent actions who wants to know what an approver signature must cover.
A reviewer who wants to follow or contribute to the draft's requirements via pull request.
Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Similar topic of signed authorization evidence, but the material does not link the two, so this is only a pointer to compare.
Discussion
Kieran answers review comments on credential-delegation -02: cumulative budgets need a single writer, and -02 says nothing on suspension or restoration.
Kieran replies to Caleb and Rob. He accepts Caleb's points 1, 4 and 6 (the remap for a user-issued token, depth-0 values, and 'user-issued'). On how a user-issued root composes with the chain format, he and Rafael still need to agree, and Caleb's jti-as-root shape is a concrete proposal. A mode marker per cumulative key is planned for -03. He cautions that a cumulative budget needs a single writer that sees every exercise, so a tally held at each verifier bounds the total per verifier only, as Section 5.5 already says. -02 names no status mechanism for tokens the DS did not issue, and Section 7 says only that an offline verifier learns of revocation through whatever status mechanism it consults. He values Rob's split between who issued the root and evidence that a person approved it. Section 7 covers revocation only, nothing on suspension or restoration, and the 1-hour cap bounds exposure without closing it.
A deployer relying on per-verifier tallies who needs to know that a cumulative limit is not enforced across separate verifiers.
A verifier of delegation tokens issued elsewhere that has to choose a status mechanism because -02 names none.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. This is the draft whose -02 text is being discussed.
Discussion
Delegation-chain drafts to be compared at a 16 Nov side meeting; the lowest del_max_depth on the path is the effective limit.
Kieran agrees with Niki and Rob that a child token's del_max_depth below its parent's is a narrowing a verifier should honor, so the effective maximum at any hop is the lowest value on the path. He says this is a separate question from the leaf being at the maximum and should be decided separately. He accepts an exact-request row in the comparison: his -02 checks each call at the DS against the operations in the token but cannot bind a leaf to a digest of one request, so the entry would be 'not expressible in the token'. He also agrees to state the 9.8 freshness bound in the terms of -02 Section 7, and asks that the -02 entry for tokens verified away from the DS be treated as provisional because Section 5.5 takes its chain format by reference. The quoted message from Niki announces a side meeting on Monday 16 November, 11:15-12:15 PST in Continental 7 and on Webex, with alignment across delegation-chain drafts as a topic.
An implementer of a delegation-chain verifier deciding how to compute the effective depth limit when child tokens narrow del_max_depth.
An author or reviewer comparing the chain drafts who wants to attend the 16 November side meeting.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. The -02 text Kieran describes (Sections 5.5, 7) is this draft.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Item 3 names asor as one of the drafts with its own per-constraint subsumption rule.
Substantive change
In oauth-delegate-sd-jwt, cnf, exp, nbf and the other security claims move out of delegate_payload into the base KB-SD-JWT payload, with defined semantics.
PR #15, which fixes #3 and #10, moves the security and validity claims (cnf, exp, nbf and so on) out of delegate_payload into the base KB-SD-JWT payload. Standard JWT and SD-JWT libraries can then evaluate them without first unpacking the delegate payload. When several delegate_payload entries are present, they share the base KB-SD-JWT's security claims. The PR also adds a section defining how cnf, iat, exp, nbf, aud, nonce, sd_hash and issuer_jwt_hash are interpreted when a KB-SD-JWT is delegated to a new Delegate Holder, versus how subsequent Delegate Holders and Verifiers interpret them, and updates the Verification section to match. Only the PR description was available, not the diff.
A library implementer who wants existing SD-JWT KB verification to check cnf and expiry on a delegated presentation without delegate-specific unpacking.
An agent that re-delegates a credential to another holder and needs the audience and nonce semantics to be unambiguous.
Discussion
The AUDIT BoF organiser asked if OAuth will produce reusable authorization record formats, and one participant repeatedly objected to the AUDIT WG.
Henk Birkholz wrote that the OAuth WG has rechartered to cover authorization and delegation of autonomous agents. He asked whether it plans tangible record or log artifact formats the proposed AUDIT WG could reuse, and said the BoF at IETF 127 aims to reuse as many existing formats as possible. Heime.Jorgen objected repeatedly, arguing that post-hoc records without pre-effect binding invite replay and TOCTOU attacks, and that the charter fails RFC 5434 criteria. They asked for extensibility slots for pre-effect seals and execution nonces. Mirja Kuehlewind replied that the objection was noted and need not be repeated. No OAuth WG member answered Henk's question in this material, and no draft text is involved.
Authors of agent authorization or delegation drafts who may be asked to make their records usable as audit evidence.
Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Signed authorization-evidence records for agent actions are the kind of record format the AUDIT BoF asks about.
Discussion
A list post proposes keeping the AS approval record in OAuth and the approver's signature in RATS, with AUDIT profiling the link.
Replying to Henk, Mohamad points to draft-yossif-psea, an EAT profile in RATS. In it the approver's enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 canonical form of the action. One independent verifier reproduces the published cases. He says it is meant to be cited, not embedded. He notes that draft-liu-oauth-authorization-evidence records the AS's view of the approval in RAR and recommends approver-side signatures in section 9.4, and that Konrad Gruszka's decision receipts leave that signature open. He proposes the split Mirja described for vCon: the AS record in OAuth, the approver's signature in RATS, and AUDIT profiling how a record references both. This is a discussion post only, and no draft text changed. Only the quoted part of the message is available, so Henk's original question is not visible.
flowchart LR
A[Approver authenticator] -->|signs SHA-256 of RFC 8785 action| S[PSEA record in RATS]
AS[Authorization server] -->|RAR approval record| R[OAuth record]
AUDIT[AUDIT profile] -->|references| S
AUDIT -->|references| R
Who this affects
A deployer who needs audit evidence of a human approval for a high-risk action, where the AS logs its own view and a separate user-signed record exists.
An implementer of RAR-based approval flows who wants to know whether approver-side signatures will be specified in OAuth or referenced from RATS.
Discussion
The authorization-evidence draft author says -02 deliberately leaves approver-side signatures open and wants WG agreement on the evidence model first.
Mohamad Khalil Yossif had pointed out that Section 9.4 of draft-liu-oauth-authorization-evidence-02 says the as_signature proves only that the AS recorded an approval, not that the approver made it. He proposed that draft-yossif-psea, an EAT profile in which the approver's authenticator signs the SHA-256 of the RFC 8785 (JCS) bytes of the disclosure object, be carried in an optional authorization_evidence member. He noted this does not close Section 9.5, because trusted display stays out of scope. The author, Dapeng, replied that Section 9.4 only makes a recommendation and deliberately leaves the mechanism open. The draft could later specify requirements or reference existing IETF work. For now the priority is WG convergence on the problem statement and evidence model, and he offered to add Mohamad to the GitHub repository. No draft text changed.
An AS that records user approvals for agent actions and needs to show later that the person, not only the server, approved them.
A verifier that wants to compare an approver-signed digest against the disclosure object recorded by the AS.
Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also defines signed authorization-evidence records for agent actions, so it addresses the same problem space.
Substantive change
This PR makes the types of an SD-JWT VC exactly those the Issuer asserts in vct and aka_vcts, and drops the extends-based matching.
Since -25, Section 2.2.2.2 says a credential is of a type if it is the vct value or listed in aka_vcts. The PR removes two leftovers in Section 5.4: a MAY that let a Consumer also match types through the extends property of Type Metadata, and a SHOULD that the vct type extend each type in aka_vcts, which cannot hold for unrelated types since a type can extend only one other. extends now only determines which Type Metadata is inherited. Section 5.4 points to the recommendation in 2.2.2.2 to list extended types in aka_vcts, and Section 7.7 now says aka_vcts types are asserted by the Issuer like the vct type, with the MUST NOT unchanged. The PR says there is no new requirement, that OpenID4VP 1.1 already matches vct_values on vct and aka_vcts, and that ISO/IEC 18013-5 will cite a dated draft at the end of November.
A verifier matching vct_values must not infer extra types from Type Metadata extends, so results do not depend on which side fetched metadata.
An Issuer whose credential type extends a parent type that verifiers request should list that parent in aka_vcts.
An ISO/IEC 18013-5 mdoc profile that delegates type matching to this document.
Related in OpenID: openid/OpenID4VP. The PR states OpenID4VP 1.1 already matches vct_values on vct and aka_vcts and treats type extension as out of band knowledge.
New proposal
The PoI Core author agrees to let the Proof-of-Intent Envelope carry a PSEA token as its device-bound attestation.
This message is Paul Williams's reply in the thread about the new draft draft-williams-oauth-poi-core-00. Mohamad Khalil Yossif had suggested that the attestation in PoI Core is close to draft-yossif-psea, an EAT profile in RATS in which the enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 form of the action parameters. Paul agrees the two are complementary. The PoIE attestation block would be extensible by media type, with PSEA as the primary profile for device-bound Tier 2 and Tier 3 assertions, while Tier 1 in-memory Web Crypto session keys stay decoupled from hardware enclaves. He describes the split: PSEA handles the device-bound signature, PoI Core defines the two-phase challenge flow (HTTP 403 with step-up negotiation) and Tier 1 browser keys via IdP certification and PoP chaining, and display integrity is handled by the Resource Server resolving opaque IDs into signed display_facts. He proposes testing an application/psea+jwt token in the PoIE node assertion schema and asks for a sample token from the conformance suite. Nothing is specified yet; this is an early alignment discussion.
sequenceDiagram
participant C as Client
participant RS as Resource Server
participant A as Authenticator
C->>RS: Request action
RS-->>C: HTTP 403 step-up challenge
RS-->>C: Opaque ID resolved to signed display_facts
C->>A: Parameters plus display_facts
A-->>C: PSEA token signed after user verification
C->>RS: Retry with PoIE carrying PSEA token
Who this affects
A resource server that needs a human to approve a specific high-value action and wants a signed proof tied to the exact parameters shown to the user.
A deployer weighing browser-only session keys against hardware-backed authenticators for different approval risk levels (Tier 1 versus Tier 2 and 3).
New proposal
A proposal to add an optional approver-signed PSEA token to authorization_evidence, so the person's own key covers what the AS says it showed.
Mohamad comments on draft-liu-oauth-authorization-evidence-02. Section 9.4 says as_signature proves only that the AS recorded an approval, and that deployments needing more SHOULD add approver-side signatures. He cites a case reported on the AUDIT list where a server signed text the person was never shown and still passed the -02 checks. He suggests draft-yossif-psea, an EAT profile in RATS in which the approver's enrolled authenticator signs, after user verification, over the SHA-256 of RFC 8785 bytes. If those bytes are the disclosure object's JCS form, a verifier can compare the digest with the disclosure's. This would not close 9.5, since PSEA leaves trusted display out of scope. He offers proposed text and a worked example against Appendix B.
sequenceDiagram
participant P as Approver
participant AS as Authorization server
participant V as Verifier
AS->>P: show disclosure object
P->>AS: PSEA token signed over SHA-256 of JCS bytes
AS->>V: authorization_evidence with as_signature and optional PSEA token
V->>V: compare PSEA digest with disclosure digest
Who this affects
A deployment where a human approval of an agent action must be provable against a compromised or careless authorization server.
Auditors checking that the text a person approved matches the recorded disclosure.
Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also defines signed authorization-evidence records for agent actions, though the message does not reference it.
Discussion
The AUDIT BoF proponents ask whether the OAuth WG will define record formats for authorization state that AUDIT could reuse.
Henk, writing for the AUDIT BoF proponents, notes that the OAuth WG rechartered to include authorization and delegation of autonomous agents, which fits the AUDIT BoF at IETF 127. They ask whether the WG plans tangible record formats that an AUDIT WG could reuse, and say the BoF stance is to reuse as many existing record formats as possible. They invite cross-review and feedback from the WG experts. No answer is included and no text changed.
Authors of agent authorization drafts who want their records usable for auditing who authorized which action.
Discussion
The AAT thread is converging on one del_max_depth meaning, with a comparison of three delegation-chain drafts due before IETF 127.
Participants discuss aligning AAT, the Asor agent_delegation format and Cred -02 (a Delegation Server design). Niki argues that a holder who sets a smaller del_max_depth than the root (root 8, holder 2) should cap everything below it, so a token at depth 3 is rejected, whereas Asor checks depth only against the root's 8. Kieran notes that a leaf at del_depth equal to the root maximum is accepted by AAT (J.10.f) but rejected under Asor semantics, and wants the test vectors reconciled. Rob agrees the cap should stay and asks the comparison to record whether each draft can bind a leaf to a digest of the exact request. Kieran and Rob both want the companion document for AAT Section 9.8 to state a revocation freshness bound, ideally in terms comparable to Cred -02 Section 7. Niki confirms the comparison and a side meeting. The thread is truncated in the source, so earlier messages are only partly visible.
Implementers of delegation-chain verifiers who must decide whether a leaf at the root maximum depth is valid.
Deployers who need a human approval to bind to one exact action inside a broader delegated grant.
Enforcement points that must state how fresh their revocation state has to be.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Its agent_delegation format and del_max_depth registry entry are the semantics being compared with AAT.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. Cred -02 is discussed for its Delegation Server ledger and revocation limits, and it adopts the Asor format unchanged for tokens verified away from the DS.
Discussion
Weekly digest: big issue cleanup on the client-id-metadata-document draft, two new ID-JAG issues, and several sd-jwt-vc PRs.
The digest lists GitHub activity only, with no spec text. In draft-ietf-oauth-client-id-metadata-document, 11 issues were closed, including those on token_endpoint_auth_method with private_key_jwt (#100), guidance on omitting token_endpoint_auth_method (#92), unsupported metadata values (#71), AS error returns (#85), disallowing the root path as a URL (#86) and data URIs for logo_uri (#19). One new issue (#131) says the response_types intersection rejects otherwise usable token-endpoint grants. Three PRs were opened, and PR #99 (Add Client Authentication section) got a comment. For oauth-identity-assertion-authz-grant, mcguinness opened #160 (sender-constrained ID-JAG should not replace required client authentication) and #159 (sections 7.2 and 8 require jwt-bearer but omit jwt-dpop). oauth-sd-jwt-vc got 7 new PRs, and PR #450 (Mike Bishop's ballot) got a comment. oauth-v2-1 PR #268 (supporting OAuth 2.0 and 2.1 clients concurrently) got 3 comments. oauth-transaction-tokens got 1 new PR. The digest does not show the reasons for the closures or the content of the PRs.
An authorization server implementing client ID metadata documents wants to know whether the client authentication and response_types handling rules are still changing.
An implementer of the ID-JAG grant who plans to use DPoP should watch #159 and #160 on the jwt-dpop gap and on client authentication.
Discussion
A reply on the Proof-of-Intent Core draft suggests carrying a PSEA token as its attestation.
The message is addressed to the author of draft-williams-oauth-poi-core-00 (the thread is titled as the new draft announcement). The sender says the attestation in PoI Core is close to the token defined in draft-yossif-psea, an EAT profile in RATS. In PSEA, the approver's enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 form of the exact action parameters. The sender cites 31 public conformance cases and one independent verifier. PSEA does not cover how the resource server requests approval or how the client key is certified, which PoI Core does define. The sender therefore proposes that the PoIE carry a PSEA token as its attestation and asks whether the author is open to checking the fit. The draft text itself is not in the material, so nothing more about PoI Core is claimed.
A resource server that wants user-verified approval of one exact action (for example a payment) and must choose between a bespoke attestation format and an existing EAT profile.
An implementer building a verifier who wants shared conformance cases rather than a draft-specific attestation format.
Editorial
A PR adds the required req_wl claim to the JWT Claims registry entries in the Transaction Tokens draft.
The contributor noticed that req_wl is a REQUIRED claim but is missing from the JWT Claims Registry Contents in the IANA section, where only tctx and rctx are listed. The PR adds the registration. It is an IANA considerations fix and does not change the token format or processing.
RFC 10070 is published: it updates RFCs 7521, 7522, 7523 and 9126 on audience values in assertion-based client authentication and grants.
The RFC Editor announced RFC 10070, a Proposed Standard by Jones, Campbell, Mortimore and Skokan, built from draft-ietf-oauth-rfc7523bis-11. It updates RFC 7523, 7521, 7522 and 9126 regarding the treatment of audience values in OAuth 2.0 client assertion authentication and assertion-based authorization grants, to address a security vulnerability in the earlier audience requirements. The announcement does not give the new audience rules, so the exact required values are not shown in this material.
An authorization server that accepts private_key_jwt client assertions or JWT bearer grants and needs to review which audience values it accepts.
A client library that builds client assertions and must check which audience value it places in them.
New proposal
A new draft proposes that a human signs a hash of the exact transaction, and the Resource Server checks it without involving the Authorization Server.
draft-williams-oauth-poi-core-00 introduces Proof-of-Intent. The human signs a Proof-of-Intent Envelope (PoIE) that commits to the SHA-256 hash of the transaction parameters, canonicalised with RFC 8785 JCS. The Resource Server (RS) verifies the signature and executes only that action. At session login the Authorization Server (AS) certifies a short-lived Ephemeral Intent Key through an RFC 7800 cnf claim. After that the client signs the RS's challenge locally, so the AS is not on the live path. A client-side Signing Vault shows the RS-signed display facts to the user. The RS picks one of three assurance tiers: session key proof of possession, platform biometrics, or FIDO2 cross-platform hardware tokens. The author contrasts this with draft-rosenberg-oauth-aauth, where approval produces a broader-scope access token through the AS. A companion draft covers multi-hop escalation and concurrency, and a reference implementation is linked.
sequenceDiagram
participant C as Client
participant AS as Authorization Server
participant RS as Resource Server
participant H as Human via Signing Vault
C->>AS: Session login
AS-->>C: Ephemeral Intent Key certified via cnf
C->>RS: Request action
RS-->>C: Signed challenge with display facts
C->>H: Show RS-signed facts
H-->>C: Sign PoIE over hash of transaction
C->>RS: PoIE
RS->>RS: Verify signature and execute that action only
Who this affects
An agent that pays an invoice, where the user must approve one exact payee and amount and the agent must not keep a reusable elevated token.
A Resource Server that wants to check high-consequence approvals offline, without calling the AS on each transaction.
A deployment that requires a hardware-backed WebAuthn approval for high-value agent actions.
Related in IETF WIMSE: draft-hulea-wimse-agent-mandate. Both address verifiable human authorization for agent actions, but the material does not show a direct link, so this is a topical pointer.
Discussion
A gateway vendor supports WG adoption of the Identity Continuation Assertion draft (-02) and backs two open issues.
A Runlayer engineer, who runs an MCP gateway between agent hosts and upstream APIs, supports working-group adoption of -02 for deployments needing IdP-authorized continuation across service boundaries. They back issue #145: the error response (§5.5.6, §6.3) should distinguish rate, fan-out, hop-count and actor-lineage depth failures so clients can pick a recovery action. They find the accepting-domain trust boundary reasonable for a gateway whose RAS also acts as CAI (§8.1). They also support an IdP-enforced bound on source-hop age (#142), provided it allows scheduled continuation from durable roots. No draft text changed in this message.
An MCP gateway that must tell agent clients whether to back off, reduce fan-out or re-authenticate after a continuation is refused.
A deployment that runs scheduled agent jobs from a long-lived root and needs a hop-age limit that does not break them.
Discussion
A reviewer asks that the Cred delegation draft keep user approval evidence separate from the root and define what a verifier sees for suspended delegations.
The message quotes Kieran Sweeney's announcement of draft-sweeney-wimse-credential-delegation-02 and adds Rob Zagarella's reply. In the quoted announcement, a Delegation Server (DS) holds deposited credentials and agents exercise them by proxy under a delegation token. The -02 changes include a sub-delegation exchange, rank order carried in the token, and cumulative bounds in a delegation_constraints claim (max_lifetime, max_subtree) with the DS as single writer. It also adopts the agent_delegation format from draft-asor-wimse-agent-delegation-chain for tokens verified away from the DS, and states that revocation is invalidation, not closure, with a 1-hour token cap. Zagarella's reply makes two points. For a user-minted root in -03, keep who minted it separate from evidence that a natural person approved it, recorded as method and assurance only (such as amr values) and never biometric data. For Section 7, say what a verifier sees for actions taken while a delegation was suspended, and whether a restored delegation is the same grant or a new one.
A Delegation Server operator who must let a verifier outside the DS tell whether a real person approved a user-minted root.
A verifier comparing a revocation or suspension decision for an action taken just before a delegation was restored.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. The draft under discussion is the one being reviewed in this thread.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Cred -02 adopts its agent_delegation format unchanged for tokens verified away from the DS.
Discussion
The AAT, Cred and Asor authors agree del_max_depth should have one meaning, and a reviewer asks the comparison to cover digest-bound leaf constraints.
This is a thread, not an announcement, and the fetched text is truncated. Quoted messages show a one-hop difference in del_max_depth. Under a root with del_max_depth 8, AAT accepts a leaf at del_depth 8 (test vector J.10.f) while the Asor -03 text rejects it. Niki Aimable Niyikiza adds a second difference: if a holder delegates with del_max_depth 2, AAT rejects a token at depth 3, while Asor checks depth only against the root's 8. Niyikiza wants the shared definition to keep the holder's cap, and Rob Zagarella agrees, since otherwise a holder cannot narrow its own onward delegation. Sweeney leans toward the Asor registry entry but cares more about reconciled vectors. Sweeney and Niyikiza also agree that the companion document for AAT Section 9.8 should state how fresh an enforcement point's revocation state must be. Zagarella asks that the planned constraint comparison record whether each draft can bind a leaf to a digest of the exact request, and that the freshness bound be stated in the same terms as Cred -02 Section 7.
An implementer of AAT or Asor delegation chains who needs depth-limit behaviour to be the same across libraries.
A deployment where each approval must bind to one exact action, such as one payee and amount, and the chain must show it sits inside the broader grant.
Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Its del_max_depth semantics and registry entry are the point of disagreement with AAT.
Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. Cred -02 Sections 5.5 and 7 are cited for depth semantics and the revocation freshness bound.
New proposal
A new individual draft defines Agent Passports and Delegation Receipts, issued through Token Exchange.
draft-le-agent-passport-00 defines two signed objects. An Agent Passport is a JWT that binds an agent's key (cnf) to the accountable organisation and to a digest of its build. Delegation Receipts form a chain from a user through agents and sub-agents. Each step is key-bound and can only narrow the one before, and the relying party verifies the chain and intersects it with the user's own access. Root receipts are obtained with RFC 8693 Token Exchange, using the passport as actor token and a new requested_token_type urn:ietf:params:oauth:token-type:agent-delegation. Status uses the Token Status List draft. The open question is whether grants should be an RFC 9396 authorization_details type. The author mentions a side meeting at IETF 127 and an IPR disclosure, and says the draft complements draft-klrc-aiagent-auth and AAuth.
sequenceDiagram
participant U as User
participant A as Agent
participant AS as Authorization Server
participant RP as Relying Party
A->>AS: Token Exchange, actor_token = Agent Passport
AS-->>A: root Delegation Receipt (agent-delegation type)
A->>A: sub-agent receipt, narrower than parent
A->>RP: passport and receipt chain
RP->>RP: verify chain, intersect with user access
Who this affects
An authorisation server that already supports RAR and wants to issue agent delegation grants as authorization_details
A relying party that must check, across organisations, that a sub-agent's authority is a subset of the user's
Related in OpenID: openid/aauth. The author says the draft is meant to complement AAuth.
Discussion
The amr-values thread argues over the broad bg value, separate sna, and a structured amr_details claim.
Ankit says Bjorn Hjelm's points are now issues: device identifier as its own value (issue 14) and geo-location treated as context rather than authentication (issue 15). In the quoted thread Bjorn argues that bg is no different from sna, which he says is a misleading term for Number Verify, and that device recognition is too vague. Shankar supports registering sna separately because bg is too broad, and proposes an optional amr_details companion claim with method, channel and mechanism so that relationships such as an OTP delivered by email can be expressed, leaving amr unchanged. Mike Jones objected to changing the structure or ordering semantics of amr without working group discussion. PR #9 and PR #10 (a new mdc value for synced passkeys) are up. The material is truncated.
A mobile-first service that uses phone numbers as account identifiers and needs to tell carrier-assisted verification apart from other background checks
Discussion
Rob Zagarella's implementer review of the Skyfire amr-values and id-verification drafts produced issues on bg, idv_time and overlap with RFC 8176.
Ankit reports that two of Rob's points are now issues: splitting the combined bg value into a device-identifier issue and a geo-location issue, and what idv_time should mean for verification time. The quoted review asks for a note per new amr value saying whether it specialises, extends or is disjoint from an existing RFC 8176 value (for example face and facliv), and asks that facliv be defined. Rob later agrees that ISO/IEC 30107-3 does not formally define passive versus active liveness and suggests facliv simply mean facial liveness was performed, leaving finer distinctions to a profile. Mike Jones says overlap is normal among amr values, removes call in PR #7 and opened issue #8 for the clarifications. The material is truncated.
An implementer that records a facial match plus an active liveness challenge and has to choose which amr values to emit
Discussion
The IESG ballot on sd-jwt-vc-23 questions two SHOULDs, and the authors answer that they will soften one and explain the other.
Éric Vyncke entered a DISCUSS on -23. He asks why type matching (Section 2.2.2.2) and status checking (Section 2.4) are not MUSTs, and notes that the type-matching SHOULD is not really an interoperability requirement under BCP 14. An author replied that the type-matching text was added late, was meant to help layers above such as DCQL and OpenID4VP, and would be better without BCP 14 language. For status, the author said a verifier may be offline and that more text will cover the consequences of not checking. Vyncke's comments also second a DISCUSS about a missing formal update of RFC 7800 and suggest replacing the normative reference to RFC 6890 with the IANA IPv4 and IPv6 special-purpose registries. The -25 diff acts on the first two points.
A wallet or verifier library that matches credential types via aka_vcts and needs to know whether the rule is a protocol requirement
A verifier that may be offline and has to decide how to handle a credential with a status claim
Discussion
Review points on the Skyfire KYAPay drafts are now tracked as GitHub issues.
Ankit lists the open points from Jean Diaconu's review as issues: how separate KYA and PAY tokens in one request relate (the token draft says they refer to the same initiator only when both iss and sub are equal), a Human-in-the-Loop option for a site to ask for recent human confirmation, and the AML methods draft's vendor-page references and false, stale or sensitive assertions. The quoted thread shows Mike Jones answering the review: PR #49 clarifies aid and sti and mentions jti and short lifetimes against replay, an issue tracks the unclear verifier description, and the token-exchange example is being reworked. The quoted text is truncated.
Rifaat asks presenters to upload slides as soon as possible. One link is for the OAuth sessions at IETF 127 and another is for the shared session with WIMSE. The message has no technical content.
Minor or unclear
Chairs and presenters declined a co-presenting slot for a competing cross-domain transaction token draft in the IETF 127 joint session.
The thread is the IETF 127 call for agenda items. The OAuth chairs requested two two-hour slots plus a joint WIMSE/OAuth session, and the Internet-Draft cut-off was 2 November 2026. Yuan (Huawei) asked for five minutes in the joint session to present draft-liu-oauth-cross-domain-txn-token, an alternative to the Cross-Domain Transaction Tokens item already on the agenda. Sean O'Dell replied, after talking with Pieter and George, that Yuan is welcome to ask questions but co-presenting is not an option at this time. The two approaches are being compared in issue #17 of gffletch/tt_xdomain. No technical content changed.
Minor or unclear
The Secdir reviewer rates draft-ietf-oauth-sd-jwt-vc-26 as Ready, with all earlier concerns resolved.
Ionuț Mihalcea posted the Secdir telechat review of draft-ietf-oauth-sd-jwt-vc-26 with the result Ready. It updates the review of -19, and the reviewer says all issues raised there were resolved or explained by the authors. The message contains no new technical findings and no text change.
Minor or unclear
A reply on draft-williams-oauth-poi-core-00 supplies a sample PSEA token and two schema details, but the message is thin.
The message is a reply from Mohamad to Paul, with the subject announcing draft-williams-oauth-poi-core-00 but no text of that draft in the file. It attaches a -03 baseline token produced and verified with a reference verifier, with action payload, RFC 8785 bytes, op, tier, iss, aud and the enrolled public key, stated to be a test key and not a conformance vector. It notes the media type is application/psea+jwt while the protected-header typ is psea-proof+jwt, and that the token is valid for 300 seconds from iat. The 31 conformance cases are in the psea-spec repository. What draft-williams-oauth-poi-core-00 defines cannot be determined from this file.
Minor or unclear
A side meeting on Attenuating Authorization Tokens is set for IETF 127 on Monday 16 November.
Niki Aimable Niyikiza announces a side meeting on Monday 16 November, 11:15 to 12:15 PST in Continental 7, also on Webex. The agenda covers implementation experience, integrations with HTTP APIs, MCP, A2A and agent frameworks, what belongs in the core document versus profiles, and alignment with related delegation chain drafts in OAuth and WIMSE, including common test vectors. This is an announcement only and contains no technical change.
Minor or unclear
The chair posted a link to the draft OAuth WG agenda for the San Francisco meeting and asked for comments.
Rifaat posted a short message linking to the draft agenda for the OAuth WG session in San Francisco (datatracker agenda-127-oauth) and asked participants to send questions or comments. The message itself lists no agenda items, so which drafts will be discussed cannot be determined from this material.
Minor or unclear
A mailing list for an AAuth working group has been opened at the OpenID Foundation.
A short message tells those interested in AAuth about the openid-specs-aauth mailing list at the OpenID Foundation. It says the foundation is still provisioning the rest of the new working group's infrastructure. The message has no technical content.
Related in OpenID: openid/aauth. The OpenID repository for the AAuth work that this list serves.
Full daily report for 2026-11-13
OAuth WG Daily Report - 2026-11-13
generated_at_utc: 2026-11-13T06:50:02+00:00
snapshot_date: 2026-11-13
Top Priorities
Rank
Draft
Score
Updated
Key State
Repo
1
draft-ietf-oauth-sd-jwt-vc
118
2026-11-06T19:07:22Z
Active, Expert Reviews OK
oauth-sd-jwt-vc
2
draft-ietf-oauth-status-list
90
2026-11-12T21:31:43Z
Active, RFC-Ed-Ack
draft-ietf-oauth-status-list
3
draft-ietf-oauth-identity-chaining
90
2026-11-12T02:07:35Z
Active, RFC-Ed-Ack
oauth-identity-chaining
4
draft-ietf-oauth-rfc8725bis
83
2026-11-06T22:32:52Z
Active, No IANA Actions
draft-ietf-oauth-rfc8725bis
5
draft-ietf-oauth-client-id-metadata-document
73
2026-11-02T22:02:56Z
Active, I-D Exists
draft-ietf-oauth-client-id-metadata-document
6
draft-ietf-oauth-identity-assertion-authz-grant
73
2026-10-31T00:32:39Z
Active, I-D Exists
oauth-identity-assertion-authz-grant
7
draft-ietf-oauth-v2-1
66
2026-10-31T04:16:32Z
Active, I-D Exists
oauth-v2-1
8
draft-ietf-oauth-delegate-sd-jwt
66
2026-10-30T12:38:29Z
Active, I-D Exists
oauth-delegate-sd-jwt
9
draft-ietf-oauth-transaction-tokens
64
2026-08-21T11:57:16Z
Active, I-D Exists
oauth-transaction-tokens
10
draft-ietf-oauth-attestation-based-client-auth
58
2026-10-18T17:33:02Z
Active, I-D Exists
draft-ietf-oauth-attestation-based-client-auth
Active Drafts
Draft
Rev
Updated
States
draft-ietf-oauth-status-list
21
2026-11-12T21:31:43Z
Active, RFC-Ed-Ack, Expert Reviews OK
draft-ietf-oauth-identity-chaining
17
2026-11-12T02:07:35Z
Active, RFC-Ed-Ack, Expert Reviews OK
draft-ietf-oauth-rfc8725bis
10
2026-11-06T22:32:52Z
Active, No IANA Actions, IANA OK - No Actions Needed
draft-ietf-oauth-sd-jwt-vc
26
2026-11-06T19:07:22Z
Active, Expert Reviews OK, Version Changed - Review Needed
draft-ietf-oauth-client-id-metadata-document
03
2026-11-02T22:02:56Z
Active, I-D Exists, WG Document
draft-ietf-oauth-spiffe-client-auth
03
2026-11-02T17:35:55Z
Active, I-D Exists, WG Document
draft-ietf-oauth-deferred-token-response
01
2026-10-31T16:12:16Z
Active, I-D Exists, WG Document
draft-ietf-oauth-v2-1
17
2026-10-31T04:16:32Z
Active, I-D Exists, WG Document
draft-ietf-oauth-identity-assertion-authz-grant
06
2026-10-31T00:32:39Z
Active, I-D Exists, WG Document
draft-ietf-oauth-delegate-sd-jwt
00
2026-10-30T12:38:29Z
Active, I-D Exists, WG Document
draft-ietf-oauth-attestation-based-client-auth
12
2026-10-18T17:33:02Z
Active, I-D Exists, WG Consensus: Waiting for Write-Up
draft-ietf-oauth-first-party-apps
04
2026-08-26T14:40:16Z
Active, I-D Exists, WG Consensus: Waiting for Write-Up
draft-ietf-oauth-rar-metadata-remediation
00
2026-08-23T20:29:29Z
Active, I-D Exists, WG Document
draft-ietf-oauth-transaction-tokens
11
2026-08-21T11:57:16Z
Active, I-D Exists, WG Consensus: Waiting for Write-Up
oauth-wg/oauth-sd-jwt-vc#455 Cite the IANA special-purpose address registries instead of RFC 6890 (Éric Vyncke's ballot comment) (2026-11-06T17:17:55Z)
Recent Issues
oauth-wg/draft-ietf-oauth-client-id-metadata-document#112 Add Security Consideration section for Fetching Client Metadata (2026-11-10T17:18:02Z)
oauth-wg/draft-ietf-oauth-client-id-metadata-document#78 Can AS optionally provide iss when fetching client_id? (2026-11-10T01:56:52Z)
oauth-wg/oauth-identity-assertion-authz-grant#121 Carry an optional client metadata digest so the IdP can vouch for the client's CIMD (JIT provisioning at the RAS) (2026-11-09T21:36:43Z)
oauth-wg/draft-ietf-oauth-client-id-metadata-document#71 Define AS behavior when CIMD contains unsupported metadata values (2026-11-09T08:34:03Z)
oauth-wg/oauth-identity-assertion-authz-grant#161 §4.3.3 Processing Rules: "SAML Audience matches the client_id" is incompatible with §4.5's required Audience→Client ID mapping (2026-11-08T14:59:29Z)
oauth-wg/oauth-sd-jwt-vc#451 Issuer key discovery: policy selects the mechanism, inputs of other mechanisms do not identify the Issuer (2026-11-05T01:36:36Z)
oauth-wg/oauth-sd-jwt-vc#453 some keyword fixes for Charles Eckel's No Objection on draft-ietf-oauth-sd-jwt-vc-23: (with COMMENT) (2026-11-05T01:14:57Z)
oauth-wg/oauth-sd-jwt-vc#452 some other items from Mahesh Jethanandani ballot (2026-11-04T23:10:46Z)
oauth-wg/oauth-sd-jwt-vc#450 Mike Bishop's ballot (2026-11-04T22:54:01Z)