IETF Logo Mail Archive

Re: [OAUTH-WG] Transaction Authorization with OAuth

Pedro Igor Silva <psilva@redhat.com> Mon, 22 April 2019 17:54 UTC

Return-Path: <psilva@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C8E12012C for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 10:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1kV8Kh1kgtO for <oauth@ietfa.amsl.com>; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D289120128 for <oauth@ietf.org>; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
Received: by mail-ua1-f41.google.com with SMTP id l17so3862750uar.4 for <oauth@ietf.org>; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yna0lhrJfcWLRb7FyB6+9LjNA8EtnitkHVQN3/TWmBo=; b=uQUvJxU4k6YejxhUGCkrKcDLcwRKCUpEQ8YTu281qRXmHCzbOIM9wURLzqk7OQYz1P 9bH1O0bwdpGR35Z7WWC2dl1AED77fQ5MVV8l5kKj3D2tASV5W8NI3IogfLUwKdHYQMc8 3PNwhM2toMjJvdgOakxxtMfee3wdahIzFHXp5upGt4Ok2VIdjsUMaW6HSrwbNjg5uNkZ EMWID2FRPlNIe6Tshr5bMv6Ya20ZiH7CwFFSw0eKUl65hZ4HLXWC4s9QWqK8rQrFjdqA 2haphQoVcXe1O2ACmuiwpfY6gblNgOw23b14sTEaZvZXq908Fi5StZBI8q9jxCpQA+1w tYZg==
X-Gm-Message-State: APjAAAUR8/7npIcCZIuHU9Kf0yVYLYbdTSek09fYo6/yDctZtbEdPZ+i R48uaxabv38OMIS3bCt29CZdep7vgE9UFJhtzJWZwIvr
X-Google-Smtp-Source: APXvYqx6Bt6nXp5NT4k2/p1TU25ChhitYHNCsyeDqfJJY6CO2bccSa66e/kXRo/gF2WL7Z+Q1Yh5Dgo7CyTZLscgKiE=
X-Received: by 2002:ab0:6803:: with SMTP id z3mr1171645uar.87.1555955676308; Mon, 22 Apr 2019 10:54:36 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <CAJrcDBfmhR5Fx1okJv7xdgATytDTA8rhBZNJJviY39WGK06uPw@mail.gmail.com> <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net> <CAJrcDBcm0x6zzWYBxjh4B8EJQozFC1ciyx5_j2rnW8DBLGqUCg@mail.gmail.com> <B41AFDAE-CE92-4477-8489-F47C05A4DD3E@lodderstedt.net> <CAJrcDBfHo=47g63ZRGiUmi=1z_=Dy+rdY83MnSgWa0L1kYKwGQ@mail.gmail.com>
In-Reply-To: <CAJrcDBfHo=47g63ZRGiUmi=1z_=Dy+rdY83MnSgWa0L1kYKwGQ@mail.gmail.com>
From: Pedro Igor Silva <psilva@redhat.com>
Date: Mon, 22 Apr 2019 14:54:25 -0300
Message-ID: <CAJrcDBf2QJn-_GhucZ+9ZWSvC+9ot-cFwNmxVij8sgN7QxVT3Q@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f843905872229f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KE-ClBdJ_MUKerWflN-oCb6-YIM>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2019 17:54:41 -0000

Sorry. I mean, UMA provides much more than this 1st party authorization
flow I'm talking about ....

On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva <psilva@redhat.com> wrote:

>
>
> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> 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 <
>> 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
>> >
>>
>>

v2.23.0 | Report a Bug | By Email