Dear Warren, Thank you very much for the detailed feedback. This is exactly the kind of review we were hoping to get. Your main concern is well taken. The intended protection against policy or privilege amplification is part of the design, but we agree that the -00 draft does not explain the end-to-end authorization and cryptographic binding clearly enough. In particular, possession of an OAuth access token alone is not sufficient to mint an arbitrary anonymous token with broader authority. A PBAT can only be derived from an AS-issued PBAC, where the approved authorization context and the corresponding policy are bound to the credential during issuance. The client may derive PBATs only within that authorized policy. At redemption, the RS independently verifies the PBAT and checks that the requested tag/resource is admitted by the bound policy. Therefore, attempts to substitute a less restrictive policy, extend the authorized scope, or derive a token for an action outside the AS-authorized policy should fail verification or policy admission. In short, the intended security property is: the client may derive and use authority granted by the AS, but cannot amplify that authority. We agree, however, that this property is currently described across several parts of the draft rather than demonstrated clearly. For the -01 revision, we plan to:
* add a running end-to-end example covering authorization, PBAC issuance, PBAT derivation, and RS verification; * add an explicit counterexample to the attack described in Section 18.4, showing where a client attempting to broaden the policy or permissions is rejected; * make the binding between the AS-approved authorization context, policy, PBAC, and derived PBATs much more explicit; and * clarify the corresponding verification steps performed by the RS. We will also clarify the BLS terminology. The construction does not use the BLS signature scheme. BLS12-381 is used as a pairing-friendly curve in the current cryptographic instantiation, while the signature mechanism is based on equivalence-class signatures (EQS). We agree that the distinction and the security properties provided by the ciphersuite need to be explained more clearly, while keeping the detailed cryptographic construction appropriately separated from the OAuth protocol description. Your references to Biscuits, Macaroons, and IAM delegation/impersonation are also very helpful. We will look more closely at these models and clarify how PBAT relates to existing approaches to delegation and attenuation. Thanks again for taking the time to review the draft. We will incorporate these points into -01, and we would very much welcome your feedback on whether the revised running example and attack counterexample make the authorization model sufficiently clear. Best regards, Jian on behalf of the authors 发件人: Warren Parad <[email protected]> 发送时间: 2026年9月14日 21:43 收件人: Wangjian <[email protected]> 抄送: [email protected]; YongLi <[email protected]>; David Kretzler <[email protected]>; [email protected]; [email protected]; Antoine FRESSANCOURT <[email protected]> 主题: Re: [OAUTH-WG] [OAuth] Feedback requested on draft-li-oauth-policy-based-anonymous-tokens-00 I hope this actually works in practice, because this is something that would offer some great improvements in stuff that I know my company is doing, work that has been done on things like Biscuits and Macaroons, as well as activities in cloud providers that utilize IAM Assume Role Delegation/Impersonation. The biggest concern I have with the document is that it lacks running through an exact example so it is impossibly hard to follow. I would definitely add clarification about how BLS works, because the whole draft is dependent on that. Following that, I'm personally confused as to how exactly an RS knows that a client didn't lie about the access that client has (the original policy). What stops a client with a valid OAuth2 JWT from minting an anonymous token with a policy that is less restrictive than what they actually have. I have some thoughts about how that is verified, but it's speculation, not proof, not something defined in the draft (at least clearly), and additionally none of which would be viable in practice. So clarity on that with the actual example and explicit counter example to 18.4 to example how exactly that attack is prevented. Warren On Mon, Sep 14, 2026 at 3:02 PM Wangjian <[email protected]<mailto:[email protected]>> wrote: Dear OAuth WG, I’m Jian Wang, one of the authors of the following individual Internet-Draft, and we would like to invite feedback from the WG: draft-li-oauth-policy-based-anonymous-tokens-00 Policy-Based Anonymous Tokens Draft: https://datatracker.ietf.org/doc/draft-li-oauth-policy-based-anonymous-tokens/ The draft explores a privacy-preserving authorization approach in which a resource server can verify whether an access request satisfies predefined authorization policies, while minimizing unnecessary disclosure of user identity information and reducing cross-service correlation. The work is motivated by emerging scenarios such as AI agent interactions, distributed services, and cross-domain data sharing, where authorization decisions may still be required without exposing more identity information than necessary. We would particularly appreciate feedback on: * how the proposed approach relates to or could complement existing OAuth mechanisms and ongoing work; * relevant specifications or prior discussions that we should take into account; * the authorization model and policy representation proposed in the draft; and * additional use cases or requirements that should be considered as the work evolves. We would be happy to discuss the proposal further with the WG and refine the draft based on community feedback. If useful, we would also be glad to present the work at a future WG meeting. Thank you in advance for your comments and suggestions. Best regards, Jian Wang on behalf of the authors _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
