IETF Logo Mail Archive

Re: [OAUTH-WG] Transaction Authorization

Nat Sakimura <sakimura@gmail.com> Mon, 22 July 2019 16:21 UTC

Return-Path: <sakimura@gmail.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 BA641120052 for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 09:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dECcWnt9vqwV for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 09:21:49 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 778AD1202A1 for <oauth@ietf.org>; Mon, 22 Jul 2019 09:21:49 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id p13so40027779wru.10 for <oauth@ietf.org>; Mon, 22 Jul 2019 09:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mgx+3mhuT+Op/ccTzkc4BAECArn6lpWOZcw26xdRsiM=; b=A5BTikihyxK6eykGz0iOUxq9OfjwusI5LH1p/qQDyVlE+bRqH0SLDJHYYwKKoTJ9oE TGlAxBVD5lVv5ciSqR1Npx2OMn9DpqZCelVi8sDwAhsi2PEP6NIqqnxx23n6KPnbVBGQ BruZO0ulMLkZQuITyLbkBZzoCwunCTYmHDXT7P78+1FFGmMYJFElmT9rTSpk0zoY5KOI LycmQUxIS0kHgYCyLfbuKcafUF8wp0sge5aVzgdzpjPNqvt+pu1nYFefmSl56v9WV+3S FHHEY6ksLsc10BVeh6d9tR5K6gqhfEqGriNUIGdEEqW6qBSp2yN34Sd/1hx3lWkSxHJQ CF7A==
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:content-transfer-encoding; bh=mgx+3mhuT+Op/ccTzkc4BAECArn6lpWOZcw26xdRsiM=; b=SHvqRCP/my48cCfUZnry7YTNsXdp9E/Pt96oBi8KZeFkEdtePF3oj1Xy7d14Rmurdb wbMMUm8RPraTbYhPbVBj/nzZW4EnpJODFNwRyAvOmm8mOfDC1KH5QJOTiYfY12To/7Tj jeZm4Yhi4NIjf78C+OO3UGKtrL65wjnnl2LWl0mIAajap5PZ4fsXDJlXqMv1+yxmSfDl iz1BaGEeEjlGmMsxOk2BUeLnkyMzCfKnT2m7MFz2xp1z0U3bp2dM48IfefR9hPxMz4Xk oRljGASP4qCVE874TaK1caWA7llPnMX+GAUYg54o52qG9a9oW3k/Q6nIPIx+GJ0hKsQX piFA==
X-Gm-Message-State: APjAAAUrLx2I3pOp+MZ7EnoUHfewr0WiH2miNkn1jj/9BufV2V2k8zWG 89jiMCHKaBHO56kOCOhvKt3016i2EU2AkRlC38U=
X-Google-Smtp-Source: APXvYqwWwAurZRwX+c5dQc8pi5d7dCSzxL/OmptQvArOvjR41fDPJbNZbjSWuy9ikMOGZLezbGXe7DASrz99xLvmXME=
X-Received: by 2002:adf:a341:: with SMTP id d1mr27766501wrb.260.1563812507454; Mon, 22 Jul 2019 09:21:47 -0700 (PDT)
MIME-Version: 1.0
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>
From: Nat Sakimura <sakimura@gmail.com>
Date: Mon, 22 Jul 2019 12:21:37 -0400
Message-ID: <CABzCy2B-a3+4XOdcUM4DBS_VyuqF9NfWuWdYc1n3auOfR7twSw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/azaHvtkOv5La2dWqoPgd0vELIMs>
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: Mon, 22 Jul 2019 16:21:52 -0000

+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> 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> 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
> https://www.ietf.org/mailman/listinfo/oauth



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

v2.23.0 | Report a Bug | By Email