One thing to keep in mind with the "Push Request Object" model and the
concept of a more detailed scope structure, if the specified values are
not for a single transaction, then the AS will be required to keep the
"Pushed Request Object" for the "lifetime" of the access_token and
possibly the refresh_token depending on the use case. This could have
some implementation issues for the AS.
Thanks,
George
On 5/10/19 9:52 AM, Dave Tonge wrote:
Thanks Torsten for this article - it is incredibly helpful.
I'm very much in favour of the "structured_scope" approach.
While I understand George's point I think the line is very blurred
between coarse-grained scopes and fine-grained transaction consent. In
addition fine-grained authorisation metadata is needed for ongoing
access APIs as well, e.g. how can a client ask for ongoing access to:
- transactions in a users accounts with ids abc123 and abc124
From a UX perspective it is beneficial for the AS to ask the user for
consent once. The AS therefore needs to have all the information about
relating to the consent available when the user is redirected to the
authorization endpoint. There should be a standard way for the Client
to pass this data to the AS and I think structured scopes either sent
as a query param or in a request object are a neat way of doing this.
Dave
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
