Re: [OAUTH-WG] self-issued access tokens

Dick Hardt <dick.hardt@gmail.com> Mon, 04 October 2021 15:44 UTC

Return-Path: <dick.hardt@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 257F53A0907 for <oauth@ietfa.amsl.com>; Mon, 4 Oct 2021 08:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 HxXuXwlbiJkt for <oauth@ietfa.amsl.com>; Mon, 4 Oct 2021 08:44:12 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 2D2B73A08FC for <oauth@ietf.org>; Mon, 4 Oct 2021 08:44:12 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id y23so34148028lfb.0 for <oauth@ietf.org>; Mon, 04 Oct 2021 08:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DnIk2V7rUQipogsX5OXNDooSev3VtKzbpr4W9726ufk=; b=jMGCACeY0+TUyRtTC7iJFD9Ic8+Pe5F0ydxcg65oFdFHygI6We1FSBkdU52T8/kiym V3IyTy50CYWoO2C2/K38TSjlx3bUbGzicCsef5lj25MebSRqOgj34SJoh9pVGoEq8ioB fYuxbiwy71W/OEK972JMC9WgL9M6lNR27t+CatGfoK8XxomCK/6e/UqWAByk00GDSbmp iR+QZGx2solLH1LRGzgxQrIpsZPnReXJ+7FZARBXe2uklq2dy95fPXqkxVOzSeWToMz2 bX42oPhbCwmBLdH30oNY1wJcyP9tJMEZUJcIoVNhInL4rPHJOtRZVqkUsyy29tf4+wTz yo5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DnIk2V7rUQipogsX5OXNDooSev3VtKzbpr4W9726ufk=; b=wxUq4HU5PLnxOpCPk7q9vztQknnRqM1CpSb/QCyEyRwMle3YHUnFzZONeFecRPKX9f ZtoGpRFwVe0tfBTIIjYsQtqs7/XAjnn4KTysVMtrtBILIMLDh7B4j1kr2wlQLT3u19RK 9BiMBuzoH8fhbvpFIZYrIKwIIePBLVfQmV/0YaAsjQ44rHYDf3g0KjQ7FruiNm9YW0WY hB1ZTgmnoCrMEDnDCQVzRwuc7OEeLhwDZRemT6hR1Z4F4CpTuQYcQZxWrKNumqoloEJU aCATY2cP26r6U+EbUcE8dcTK0DCBQ9fyEnmwN9f33afI94JcS2SOSu+dzyEDPag6i+f8 7smQ==
X-Gm-Message-State: AOAM533Cu0XbgGTcUDGHuwBzTg8+ziwRdVM4XgBuHz0jDqqK2vvQuX/x btQsAs+AYRr+4C6lOsPDPIUggmVjPtMGUylhhwY=
X-Google-Smtp-Source: ABdhPJy4ar0KFY6C9j1fF7uv2vtp7K9ZJbflC864TGmdF5dt9xidfbuMzXUG3qFUwjXb+CcRWb/w3H8QzwMHEIx1oN8=
X-Received: by 2002:a05:6512:22c1:: with SMTP id g1mr15679719lfu.169.1633362248706; Mon, 04 Oct 2021 08:44:08 -0700 (PDT)
MIME-Version: 1.0
References: <TYCPR01MB567859999FB3350D6A1C63E5E5A99@TYCPR01MB5678.jpnprd01.prod.outlook.com> <CAD9ie-sgjUv3fppvTZvPpOyUKXo1H1i9LtkOk2yxzZ1+A+wt6w@mail.gmail.com> <TYCPR01MB56784381BE6799ADAA46E360E5AB9@TYCPR01MB5678.jpnprd01.prod.outlook.com> <CAD9ie-tMp44z_b=hG+OWC=Hc83RpC_WZ4AaerRMaOZ8cfEkDSg@mail.gmail.com> <TYCPR01MB56787D963D23F78B0800C6CBE5AB9@TYCPR01MB5678.jpnprd01.prod.outlook.com> <CAD9ie-u2MRQygYKCDOHBWvu_xO2p96+-vPHir6E3_SEh5OGbqw@mail.gmail.com> <FA113C6E-2A9A-4DFD-A7AB-500955EF9B2E@alkaline-solutions.com> <TYCPR01MB56784DD748F0977AEA0C0AA9E5AE9@TYCPR01MB5678.jpnprd01.prod.outlook.com>
In-Reply-To: <TYCPR01MB56784DD748F0977AEA0C0AA9E5AE9@TYCPR01MB5678.jpnprd01.prod.outlook.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 04 Oct 2021 08:43:32 -0700
Message-ID: <CAD9ie-te9E6o3sTeYyasp4KUtMLijWR2y5EHdZDFhKOkKFu_cQ@mail.gmail.com>
To: toshio9.ito@toshiba.co.jp
Cc: david@alkaline-solutions.com, oauth@ietf.org
Content-Type: multipart/related; boundary="0000000000009fce2305cd88c8a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XTv40zwZo6WfFrlTmS6-fi2tMa0>
Subject: Re: [OAUTH-WG] self-issued access tokens
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, 04 Oct 2021 15:44:18 -0000

Toshio, unless your system needs to interoperate with third party systems,
I don't see the value in a standardized JWT. The JWT standard provides a
standard token format. What you put in the payload is application specific.

You can do a separation of concerns behind your API endpoint for validating
the JWT. If it were me, I would not set up an AS. You won't have to set up
the endpoint and the extra call in your client.

On Sun, Oct 3, 2021 at 7:26 PM <toshio9.ito@toshiba.co.jp> wrote:

> Thanks Dick,
>
>
>
> Our use case is basically the option 2. There is only one RS. So, to
> simplify
>
> the architecture, we want to omit the round-trip of getting an access
> token from
>
> AS.
>
>
>
> I agree with your idea of using JWTs to convey client's signature. So my
>
> original question was if there was a standardized profile of a JWT for that
>
> purpose. From the responses to this thread so far, I think the answer is
> no.
>
>
>
>
>
> Thanks for comment, David,
>
>
>
> Yeah, maybe it's wise to have AS anyway for better extensibility.
>
>
>
>
>
> Toshio Ito
>
>
>
> *From:* David Waite <david@alkaline-solutions.com>
> *Sent:* Saturday, October 2, 2021 6:04 AM
> *To:* Dick Hardt <dick.hardt@gmail.com>
> *Cc:* ito toshio(伊藤 俊夫 ○RDC□IT研○CNL) <toshio9.ito@toshiba.co.jp>;
> oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] self-issued access tokens
>
>
>
>
>
>
>
> On Oct 1, 2021, at 11:06 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> <snip>
>
> If there is really only one service, then there is little value in an AS.
> I would have the client post a JWT that has the request payload in it, or a
> detached signature if it is a large payload. Personally, I like sending the
> request as a JWT as it allows services further down the processing pipeline
> to independently verify the request from the client.
>
>
>
> This assumes sufficient computing power on the IoT device, and reasonably
> low call volume.
>
> [image: イメージは差出人によって削除されました。]ᐧ
>
>
>
> One interpretation of the purpose in the AS is to create tokens based on
> its authorization decisions, while direct submission of client-authored
> JWTs would be more in line with having the RS make those decisions directly.
>
>
>
> Even if they were hosted on the same hardware, I’d still push to use an
> AS-role component in order to optimize the decision making process and to
> not have to refactor (or risk duplication) of that logic later.
>
>
>
> -DW
>
>
>
ᐧ