Re: [OAUTH-WG] Transaction Authorization with OAuth

On Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

> Hi Pedro,
>
> > On 22. Apr 2019, at 16:34, Pedro Igor Silva <psilva@redhat.com> wrote:
> >
> > Hi Torsten,
> >
> > Great article, thanks for sharing it.
>
> my pleasure :-)
>
> >
> > 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).
>
> Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I’m asking because the signing case uses more data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes or
> even just a single hash of a document.
>

Yes, it does. Like I mentioned, the model is based on UMA (Permission
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
talked with UMA WG in the past about this solution and how we extended the
specs to solve this type of problem.

By being active during the authorization process the RS is in control over
additional claims that should be considered by the policies when making
decisions about the resources/scopes a client/user can access. Where the
information could be obtained from different sources such as the current
HTTP request or internally/externally to the RS.

We did not have much demand for addressing the signature use case, but use
cases similar to the "payment" use case. As I mentioned, the model I'm
talking about is not based on user consent. But considering that you can
also pass any information to the AS, you should be able to let users to
authorize the creation of signatures for one or more documents.

>
> >
> > 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.
> >
>
> Look forward to reading your article.
>
> best regards,
> Torsten.
>
> > Best regards.
> > Pedro Igor
> >
> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> 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
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>