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 <wangjian365= [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] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
