As you are a person who contributed to UMA2 spec (btw, I appreciate your work!) I wouldn't like to disagree with you on that matter, but still I cannot see any information in the UMA2 Grant specification which, at least, describes what are the required/acceptable authorization headers and how is the client actually authenticating to the AS in the step from chapter 3.3.1.
There is only an example with Basic authorization header, which is not described, actually it doesn't even seem to have base64 value":
Authorization: Basic jwfLG53^sad$#f
The spec seems incomplete in that matter, and as I was reading the two UMA specs there were several places where the authorization header was not described, not even mentioned.
IMHO this could be improved in the specs. If you, or the coauthor of your book is able to update the spec in that matter this would be much more understandable.
Thanks, I will try with the pushed access token + userinfo approach.
What I was trying to say is that reusing the OIDC AAT at the authorization header in UMA would be a nice optimization of the flow (assuming that OIDC and UMA go nicely together, and the KISS rule). This way the AS could fetch the claims automatically before executing the policies. Have you ever considered this idea at the UMA work group? Maybe the authorization header part was left undefined in the specs to allow for such things in the first place? If so, have you considered it in gluu?