Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva <[e-mail]>]

On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <[e-mail]>
wrote:

> Hi Pedro,
>
> >
> > > 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.
>
> The problem from my perspective (and my understanding of UMA) is the RS
> does not have any information about the context of the request. For
> example, the client might be calling a certain resource (list of accounts)
> and immediately afterwards wants to obtain the balances and initiate a
> payment. I think the UMA case the RS either predicts this based on policy
> or past behaviour of the client OR the client will need to issue several
> token requests. That might not be a problem in 1st party scenarios but it
> is in 3rd party scenarios if the AS gathers consent.
>

Yeah, we are talking about different use cases. But they are still quite
related in regards to enriching authorization decisions. it would be nice
to have something in OAuth that could address both 1st and 3rd party use
cases. As I said before, the model I'm talking about is kind of a 1st party
Lodging_Intent.

Just to clarify, UMA does not cover the scenario I'm talking about although
it provides a very good ground for extensions like this. It is not part of
UMA scope. It provides much more than that too ...


>
> >
> > 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.
>
> Right, you mentioned it is intended to be used for 1st parties only.
>
> > 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 think the client needs to pass this information, which brings us back to
> the original question of my article.
>
> best regards.
> Torsten.
>
> >
> >
> > >
> > > 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 <
> [e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>