Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Mon, 25 March 2019 14:44 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 48A2E1203D0 for <oauth@ietfa.amsl.com>; Mon, 25 Mar 2019 07:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.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 sDeqRGs1pdTW for <oauth@ietfa.amsl.com>; Mon, 25 Mar 2019 07:44:19 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 30E5C1203CF for <oauth@ietf.org>; Mon, 25 Mar 2019 07:44:19 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id s81so5418427qke.13 for <oauth@ietf.org>; Mon, 25 Mar 2019 07:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bpeiqjJBLZMfTUvZ1YEWe55ooTmQlcdV9cJv/PKZzBg=; b=b24iB3Y44mAmSbGUfg9KOGizx/fS4zdw5TIgeB9NrJ67O+u/2TP0WNyWzWu8M5tv+q +WMWmf83oR6tkajHqgAJ6jFoUBXMRKaZeilxrdv7+1vm/glTfFbChlG68DYB8Zz6Ge1e cGOj+sA4JJoSSDXwqdnBhKoxmsaTW2L0wZPdDxkS+I4I0v09dHaYV6QOIPTlznp2uUIb T2aXVaI2mg4b4+o7bdp+dk4YhjpmcWizbIpdBkiIDy4XqHxl67j1OQ0J/xOyrspsZ5+5 S6xDeowwS1hcsejgmh0PhUXysdt9d6ZigSjogb98bYn5bi9lRiWMXUkTlgsIaTBWsrbT zoIQ==
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=bpeiqjJBLZMfTUvZ1YEWe55ooTmQlcdV9cJv/PKZzBg=; b=V+7+bVUQ6kR+uVyhM/0tCowUKItow/jMNVJZ6M4+fqm+YBC0sbhDyQOTAfMXlVgW97 LpFmbXGneBtY0WVQrlfNI8tfQ4pICjT3jqMScWE9D03AG83jvqMcsjmtc9yISweBwfZy Keiti5F0FjS3ST2FZqckE4RLjMTZooqxvc4ovnH+nc0qxn/zYNgKAg7Lcp59wqMZR7ls wdTWktxyzVA+I+EtkXWRpRqtPiQl4FKrN7a3ny2LgJuChpl15xMGVqWyE2AqlA52IjTX 0qmz24kMUTBREH1ZYVPa8NXMixthcaXSNaLx3jYhNUJK86Tle05N5O24Wnnwm0XAd48Y 9XqA==
X-Gm-Message-State: APjAAAXKmdEEl+/urL8Ca1BnORESwq83cyrfrCsauDhNYl2kCy6X60sy TmC40L054nmEEhaO6jifw5UYAcpL+7oGHkp0PrB2cUoC
X-Google-Smtp-Source: APXvYqyXsJ2nDllUgAHQ+e6WZ41yGJ1mNX5ErcbtqnpchLTZPEQdJSmXeL57/qYfc16iEmeAOV1NmEGs402aCpM8usQ=
X-Received: by 2002:a37:9acc:: with SMTP id c195mr19161337qke.106.1553525058186; Mon, 25 Mar 2019 07:44:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <B755AE4D-2D10-4380-AC12-4B7A8F53B812@gmail.com> <CAO7Ng+siADYHEhr8gryPZ_6c50uQ3XxDM5inAFwgG+Xa0bnwfg@mail.gmail.com> <CA+iA6uhHOSmiSG_vxvad_g2ufi57OS4TxdvoO20g+7vm7rNZiA@mail.gmail.com> <CAO7Ng+vGC5ByU1wZrbNWvaZ+QuDByhJ8huw8UXVxfOCWQpaH1w@mail.gmail.com>
In-Reply-To: <CAO7Ng+vGC5ByU1wZrbNWvaZ+QuDByhJ8huw8UXVxfOCWQpaH1w@mail.gmail.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Mon, 25 Mar 2019 15:44:06 +0100
Message-ID: <CA+iA6ujkEMdHPMn7JQLts7OAusV3ieKKMon572vTACtFvTGnrA@mail.gmail.com>
To: Dominick Baier <dbaier@leastprivilege.com>
Cc: IETF oauth WG <oauth@ietf.org>, Nov Matake <matake@gmail.com>, vittorio@auth0.com
Content-Type: multipart/alternative; boundary="0000000000003e73080584ec3da9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/61nSEfygOauJ547dYvpY1gyv6YY>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 25 Mar 2019 14:44:22 -0000

I believe there are plenty of OAuth 2.0 only use cases out there... but
nevertheless I agree with the potential confusion and thus security
problems arising from that (though one may argue the semantics are the
same).

Hans.

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com>
wrote:

> Yes I know - and I think in hindsight it was a mistake to use the same
> claim type for multiple semantics.
>
> All the “this is OIDC not OAuth” arguments are making things more
> complicated than they need to be - in my experience almost no-one (that I
> know) does OIDC only - nor OAuth only. They always combine it.
>
> In reality this leads to potential security problems - this spec has the
> potential to rectify the situation.
>
> Dominick
>
> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu)
> wrote:
>
> Without agreeing or disagreeing: OIDC does not apply here since it is not
> OAuth and an access token is not an id_token.
> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>
> "The "sub" (subject) claim identifies the principal that is the
>    subject of the JWT.  The claims in a JWT are normally statements
>    about the subject.  The subject value MUST either be scoped to be
>    locally unique in the context of the issuer or be globally unique.
>    The processing of this claim is generally application specific"
>
> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
> Hans.
>
> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com>
> wrote:
>
>> IMHO the sub claim should always refer to the user - and nothing else.
>>
>> OIDC says:
>>
>> "Subject - Identifier for the End-User at the Issuer."
>>
>> client_id should be used to identify clients.
>>
>> cheers
>> Dominick
>>
>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:
>>
>> Hi Vittorio,
>>
>> Thanks for the good starting point of standardizing JWT-ized AT.
>>
>> One feedback.
>> The “sub” claim can include 2 types of identifier, end-user and client,
>> in this spec.
>> It requires those 2 types of identifiers to be unique each other in the
>> IdP context.
>>
>> I prefer omitting “sub” claim in 2-legged context, so that no such
>> constraint needed.
>>
>> thanks
>>
>> nov
>>
>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
>> vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>    - Despite OAuth2 not requiring any specific format for ATs, through
>>    the years I have come across multiple proprietary solution using JWT for
>>    their access token. The intent and scenarios addressed by those solutions
>>    are mostly the same across vendors, but the syntax and interpretations in
>>    the implementations are different enough to prevent developers from reusing
>>    code and skills when moving from product to product.
>>    - I asked several individuals from key products and services to share
>>    with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>    Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!
>>    ).
>>    I studied and compared all those instances, identifying commonalities
>>    and differences.
>>    - I put together a presentation summarizing my findings and
>>    suggesting a rough interoperable profile (slides:
>>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>    <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>>    - The presentation was followed up by 1.5 hours of unconference
>>    discussion, which was incredibly valuable to get tight-loop feedback and
>>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>>    and contributed generously to the discussion. Thank you!!!
>>    Note: if you were at OSW2019, participated in the discussion and
>>    didn't get credited in the draft, my apologies: please send me a note and
>>    I'll make things right at the next update.
>>    - On my flight back I did my best to incorporate all the ideas and
>>    feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>>    Hannes and above all Brian were all super helpful in negotiating the
>>    mysterious syntax of the RFC format and submission process.
>>
>> I was blown away by the availability, involvement and willingness to
>> invest time to get things right that everyone demonstrated in the process.
>> This is an amazing community.
>> V.
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
>

-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu