Re: [OAUTH-WG] Transaction Authorization

Justin Richer <jricher@mit.edu> Wed, 24 July 2019 13:20 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 8FC9C12034E for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 06:20:25 -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 duaOSlrpSura for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 06:20:23 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 4EFF71201E0 for <oauth@ietf.org>; Wed, 24 Jul 2019 06:20:23 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x6ODLiKT029452; Wed, 24 Jul 2019 09:21:45 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 24 Jul 2019 09:20:02 -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 09:20:18 -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 09:20:18 -0400
From: Justin Richer <jricher@mit.edu>
To: Dick Hardt <dick.hardt@gmail.com>
CC: oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Transaction Authorization
Thread-Index: AQHVNo8uPlHZsW3ub0m+zkQfIAjEo6bV7DYAgAQuwYA=
Date: Wed, 24 Jul 2019 13:20:18 +0000
Message-ID: <9D257804-01E0-4132-A9E2-298BB4E271D9@mit.edu>
References: <BD2D90C8-B629-4955-A22C-6E80E6390EEE@mit.edu> <CAD9ie-uReSZ8Ds5O20ERHJ__+VrOKVPy3Simi+gKLvqzpC61gQ@mail.gmail.com>
In-Reply-To: <CAD9ie-uReSZ8Ds5O20ERHJ__+VrOKVPy3Simi+gKLvqzpC61gQ@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_9D25780401E04132A9E2298BB4E271D9mitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0egIMWb4-wsZvKT-LG-Ri17PrvI>
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 13:20:30 -0000

I agree that we need to expound on the new use cases that this approach enables, and I’ll send them out here and add them to the site as I get them written down.

To your specific idea: My thinking here was that we can leverage the transaction model to make this work in a consistent fashion. This is noted in the spec and website, but to expand here:

1) Client goes to the RS and tries a request, with no token or with insufficient token.
2) RS goes to the AS and says “hey someone wants a thing but can’t get it, here’s a resource object that describes what would be sufficient access to make that work” .. this request has some signal in it that tells the AS that it’s not a client asking for a token, maybe set the “client” field to “false” or something? I’m not sure how best to signal that yet.
3) AS returns a resource_handle for the requested resource set. This can be random and dynamically generated, doesn’t have to be human readable.
4) RS returns the resource handle and a pointer to the AS’s transaction endpoint to the client in a WWW-Authenticate response header that we’d define, but would look suspiciously like UMA2’s response header with similar information.
5) Client makes its normal XYZ request to the AS but includes the resource_handle it got back from (4).

— Justin

On Jul 21, 2019, at 5:27 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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth