I need to read this draft RFC a few times before I can grasp it completely. There is an existing RFC drafted in 2013 with a focus on OAuth 2.0 threat model and

I need to read this draft RFC a few times before I can grasp it completely. There is an existing RFC drafted in 2013 with a focus on OAuth 2.0 threat model and security considerations [1], and it looks like this new RFC is making more specific recommendations on top of it. May be read them together. To be honest, I was wishing for OAuth 2.5 if not OAuth 3.0 to consolidate already fragmented OAuth 2.0 spec and landscape [2]. At this stage, there are too many draft proposals and a majority of them led by vendors with some interest in standardizing their implementations. For example, this RFC suggests restricting issued access token to one resource at a time (using audience parameter). Well with Microservices landscape this gets really challenging. Your client application may be interacting with multiple resources. Neither OpenID Connect nor OAuth 2.0 offer solutions to issue multiple access tokens (not yet). An API Gateway may be a solution but still so much ambiguity. I think OpenID Community has done a better job to organize their specifications and working groups [3]. If you go on their specification page it tabulates really well what spec is final, currently under implementation, draft, or obsolete. Still, big vendors influence agenda and direction. (Disclaimer: I am the founder of https://axioms.io/ https://axioms.io/ which OAuth 2/OpenID Connect compliant identity management platform) [1]: https://tools.ietf.org/html/rfc6819 https://tools.ietf.org/html/rfc6819 [2]: RFC 6749, RFC 6750, RFC 6819, RFC 7662, RFC 7009, RFC 7519, RFC 8414, RFC 7591, RFC 7592, and 20 more. [3]: https://openid.net/developers/specs/ https://openid.net/developers/specs/