> Am 10.05.2019 um 22:27 schrieb George Fletcher <[email protected]>: > > 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.
It’s not necessarily the request object but the client id and the scope. Can you please explain what implementation issue you expect? I don’t see much of a difference between storing/maintaining simple scope values and a JSON document for a grant. > > 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 >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
