Indeed but at the same time, it may be needed for the AS to keep it anyways for compliance purposes.
I have not gone through the thread yet, but here is my brief response to Torsten's post. https://nat.sakimura.org/2019/05/12/comments-back-to-transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-by-torsten/ Cheers, Nat Sakimura On Fri, May 10, 2019 at 10:27 PM George Fletcher <[email protected]> wrote: > > 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 -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
