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

Brian Campbell <bcampbell@pingidentity.com> Wed, 03 April 2019 17:24 UTC

Return-Path: <bcampbell@pingidentity.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 1296A120140 for <oauth@ietfa.amsl.com>; Wed, 3 Apr 2019 10:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 bvCRaQjTFo_1 for <oauth@ietfa.amsl.com>; Wed, 3 Apr 2019 10:24:20 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 4DD8612013B for <oauth@ietf.org>; Wed, 3 Apr 2019 10:24:20 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id z126so12330061itd.5 for <oauth@ietf.org>; Wed, 03 Apr 2019 10:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xIfXPS3Ll6jnahnFu0WfDXGaK0DrwnnGQm5H5E/QBsw=; b=gyahhJtfsd+n+oDCTsxIeIdMiuVqx3KWlrT/aUX7SmXwrgFgqbXQX/nwKRpK+rAAfG ST/3pcVPnriqAQtXa6xf8iKzSJ8ycJLT+ay7QuPCwny73uakj3O557IoM/dceq6pVkf0 0NgbwZPHZcORpT8Rm2MLV0CaHSkq7MnlxSfWs=
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=xIfXPS3Ll6jnahnFu0WfDXGaK0DrwnnGQm5H5E/QBsw=; b=CIxWGLtTTtJxVvQ0HrDKF90BXO/icMlYoiVVGPsLo+vZPkZyDFvO3jF43MpK7qYU78 97aadQlfT0muTeCr3CiiKJETMBslE3oFciaTQhjKEuLHXwk2tyaBZ3EHbSIbW8k62wqG Zuk+oWqdu6VO3h0LdHmQ7YJAF1q7m6oBMDC2s24/LhSQJKhV8SYo6JZsfGYiQkbD3+Lb rhznQj2VmTrTZEP16InZ7u+VEhNqG874vIOyNKTwdxP2UD3FahLQQFpAU5rcxGmTnH2b jRgXTfRdmAJVyQ15YJ5oqvrivAheXxGSMXiOcjfZ2CyZSqeoaz3fCnJf0tEorUryea3t xs6Q==
X-Gm-Message-State: APjAAAUK6Kn5bunyMddwSx8LzzhsAq6w8VAFZIEMBRaFvPXXsdhbg0fc XoFDjZRp18tWPaQBv8Az4ka/B9BJtabzatdpibQ7l6d/J4IgbZVfZn6V55UKQMF0Nb7GcYVxGx8 8K5F9jJG3aOtk5Q==
X-Google-Smtp-Source: APXvYqzPtpzQT9/1b0DVxGlz2ighECHCR+LFy0irW+Hl6Fv9JUmAHruPh1pygmMaVD+mACjx7RmqutSbbsj1AM+M8G4=
X-Received: by 2002:a05:660c:685:: with SMTP id n5mr1027491itk.57.1554312259359; Wed, 03 Apr 2019 10:24:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> <CB442B2B-4084-4C0D-8B4C-59C10423B387@alkaline-solutions.com>
In-Reply-To: <CB442B2B-4084-4C0D-8B4C-59C10423B387@alkaline-solutions.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 03 Apr 2019 11:23:52 -0600
Message-ID: <CA+k3eCRS_Y1aXwX3U-q8uXRqd4hhot-s6nJ5d9qmbA9m0m9uUw@mail.gmail.com>
To: David Waite <david@alkaline-solutions.com>
Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016f0630585a3863b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ywLcbLjQdpcWSTstG88ITXl_iVA>
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: Wed, 03 Apr 2019 17:24:23 -0000

+1 to David's question here. I'd like to see justifying use cases (beyond
just the fact that some people are already doing it) for auth_time, acr,
and amr to be available in OAuth JWT access tokens. Those claims are
defined for, and in the context of, an ID Token and I fear that codifying
their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com>
wrote:

> Do we know if there is a justifying use case for auth_time, acr, and amr
> to be available in OAuth JWT access tokens? These are meant to be messages
> about the client, either directly (in the case of client credentials) or
> about its delegated authorization of the user.
>
> Embedding attributes about the user (such as group membership and roles)
> can be used for the resource to make finer-grained decisions than scopes,
> but normally I would expect say acr limitations enforced by a resource to
> instead be controlled by the AS requiring a higher quality authentication
> to release certain scopes.
>
> Thats of course not to say extensions to OAuth such as OIDC can’t provide
> these values, just that they might better be defined by those extensions.
>
> -DW
>
> On Apr 1, 2019, at 9:12 AM, George Fletcher <
> gffletch=40aol.com@dmarc.ietf.org> wrote:
>
> Thanks for writing this up. One comment on auth_time...
>
>    auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>       Important: as this claim represents the time at which the end user
>       authenticated, its value will remain the same for all the JWT
>       access tokens issued within that session.  For example: all the
>       JWT access tokens obtained with a given refresh token will all
>       have the same value of auth_time, corresponding to the instant in
>       which the user first authenticated to obtain the refresh token.
>
>
> During a current session a user can be challenged for additional
> credentials or required to re-authenticate due to a number of different
> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
> I'd assume that the auth_time value should be updated to the latest time at
> which the user authenticated.
>
> If we need a timestamp for when the "session" started, then there could be
> a session_start_time claim.
>
> Thanks,
> George
>
> On 3/24/19 7:29 PM, Vittorio Bertocci 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 listOAuth@ietf.orghttps://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
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._