Yeah, I did.

XACML is a good standard, even better after v3. We do have options to
leverage XACML policy language model to write policies, but protocol-wise,
something on top of OAuth, would be very nice. As an authorization
framework, fine-grained/contextual authorization seems to be a natural
addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM 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] <[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
>> <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

Reply via email to