Re: [OAUTH-WG] Transaction Authorization

Justin Richer <jricher@mit.edu> Wed, 24 July 2019 14:12 UTC

Return-Path: <jricher@mit.edu>
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 2697E120300 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 07:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4E2xZpvYeMgO for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 07:12:43 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A0A120131 for <oauth@ietf.org>; Wed, 24 Jul 2019 07:12:43 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x6OECsgd025888; Wed, 24 Jul 2019 10:13:13 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 24 Jul 2019 10:11:36 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Jul 2019 10:12:12 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 24 Jul 2019 10:12:12 -0400
From: Justin Richer <jricher@mit.edu>
To: Nat Sakimura <sakimura@gmail.com>
CC: Dick Hardt <dick.hardt@gmail.com>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Transaction Authorization
Thread-Index: AQHVNo8uPlHZsW3ub0m+zkQfIAjEo6bV7DYAgAE8y4CAAwCBAA==
Date: Wed, 24 Jul 2019 14:12:12 +0000
Message-ID: <EABD1584-153B-4775-8A5F-D6D55A6B5795@mit.edu>
References: <BD2D90C8-B629-4955-A22C-6E80E6390EEE@mit.edu> <CAD9ie-uReSZ8Ds5O20ERHJ__+VrOKVPy3Simi+gKLvqzpC61gQ@mail.gmail.com> <CABzCy2B-a3+4XOdcUM4DBS_VyuqF9NfWuWdYc1n3auOfR7twSw@mail.gmail.com>
In-Reply-To: <CABzCy2B-a3+4XOdcUM4DBS_VyuqF9NfWuWdYc1n3auOfR7twSw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_EABD1584153B47758A5FD6D55A6B5795mitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1LXdyLBE0jp4u40hAiSdrIuexCg>
Subject: Re: [OAUTH-WG] Transaction Authorization
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: Wed, 24 Jul 2019 14:12:51 -0000

I’m definitely in favor of separating the “person using the client software” from the “person making the authorization decision” and allowing them to be the same person without changing the protocol. UMA has that separation, but doesn’t handle the collapsed case very well in my opinion (in spite of best efforts to allow it). OAuth assumes they’re always the same but can be tweaked to make them different sometimes (like CIBA’s call center use case), but it’s not really set up for that.

I think we have an opportunity to get this right in XYZ because we have a more flexible way of defining “how I can interact with a user” as part of the protocol, as well as “anything I know about the user already” for the client to push in. This could be used as a signal to the AS that the end user and resource owner are different parties and it should go bug someone through an asynchronous channel for approval.

As for the rest of Nat’s list below, that’s a hefty feature set. If we pick up this work, I think a few of these might fit better into a companion spec, but they are all definitely worth discussing. I would personally rather bring all the pieces together and figure out how to slice them apart than have something incomplete that needs to be bolted on to for anyone to use it.

— Justin

On Jul 22, 2019, at 12:21 PM, Nat Sakimura <sakimura@gmail.com<mailto:sakimura@gmail.com>> wrote:

+1

Also, if it were to include user identification in the protocol, I
would like to have the spec at least cover the following:

0. User
1. External Identity Provider
2. Resources that covers the functionality of PEP.
3. Authorization Server that act as PDP for  Resources.
4. Internal Identity Server within the resource domain.
5. Client APP component
6. Client Server component

In addition, it would be good to delineate the resource owner (an
entity that has administrative rights over the set of resources) and
the end user who is in the protocol flow.

That actually asks for the following additional entities:

7. Resource Administrator
8. PAP/PIP

It is probably a good idea to state the security target as well.

Re: Starting from Resource.

Yes. I agree that this is a valid use case. At the same time, there
can be cases where the concrete resource endpoint is not known before
the user authorization. So, the protocol needs to be able to start
both ways, I guess.

Cheers,

Nat Sakimura


On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:

Hey Justin

A few use cases that highlight how the world is different now than it was when OAuth 2.0 was developed would help participants understand why changes are needed, and also provide a reference for comparing and contrasting different approaches.

One of my first comments is why the client is starting off making calls to the AS. There are times when the AS is not known for a given resource. Why not allow starting at resource?


On Tue, Jul 9, 2019 at 12:48 PM Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:

I have requested time to present Transactional Authorization (the XYZ project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new version of the spec:

https://tools.ietf.org/html/draft-richer-transactional-authz-02

Additionally, I’ve updated the writeup and examples on https://oauth.xyz/

I plan to be in Montreal for the whole week, and I’ve requested from the chairs that I present during the Tuesday session due to limited availability of some key WG members on Friday.

— Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en