Hi Jim, thanks for pointing this out.
Basically, what I’m proposing is not a new language for describing authorization policies. It’s more like the container to carry the data needed to inform the user about the intention of the client to the authorisation server. This container may contain anything - preferable expressed as JSON :-). But let’s ignore this for a moment. As OAuth is about delegating access rights to a client, the question is whether XAML could express delegation as well. If that’s the case and the AS maintains the permissions of its users as XAML policy one could potentially express the requested permissions as a subset of the users permissions. In the (consumer) use cases I’m typically dealing with, the user’s permission is determined by possession. So a user is in possession of an email account because it signed up for that service (and potentially pays for it). My feeling is XAML is more targeted towards enterprise use cases. best regards, Torsten. > On 22. Apr 2019, at 18:10, Jim Manico <[email protected]> wrote: > > Have you looked at other standards that address find grained access control > like NIST ABAC or XACML? This is a somewhat solved issue and I wonder if > previous work can be leveraged. > > A basic string “scope” is certainly not enough to represent and transport > complex authorization policy. I would imagine that something closer to XACML > would work. > > -- > Jim Manico > @Manicode > > On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva <[email protected]> wrote: > >> Hi Torsten, >> >> Great article, thanks for sharing it. >> >> We have been working on a solution for fine-grained authorization using >> OAuth2 but specific for first-party applications where the granted >> permissions/scopes depend on the policies associated with the >> resources/scopes a client is trying to access. We don't have extensions to >> the authorization endpoint but a specific grant type for this purpose on the >> token endpoint. >> >> The solution is similar to the Lodging Intent Pattern but also based on >> specific parts of UMA and ACE. >> >> Basically, when a client first tries to access a protected resource the RS >> will respond with all the information the client needs to obtain a valid >> token from the AS. The information returned by the RS can be a >> signed/encrypted JWT or just a reference that later the AS can use to >> actually fetch the information. With this information in hands, clients can >> then approach the AS in order to obtain an access token with the permissions >> to access the protected resource. >> >> The general idea is to empower RSs so that they can communicate to the AS >> how access to their resources should be granted as well as decoupling >> clients and RSs so that clients don't need to know the constraints imposed >> by the RS to their protected resources (e.g. scopes). >> >> I've started to write a document with this idea in mind and I'm happy to >> share it with you and see what you think. >> >> Best regards. >> Pedro Igor >> >> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt >> <[email protected]> wrote: >> Hi all, >> >> I just published an article about the subject at: >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948 >> >> >> I look forward to getting your feedback. >> >> kind regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
