From nobody Fri Oct 2 10:11:47 2020 Return-Path: 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 C15623A11F3 for ; Fri, 2 Oct 2020 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=cert.org 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 Mg5OgvI_oyJn for ; Fri, 2 Oct 2020 10:11:44 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 2460B3A11EC for ; Fri, 2 Oct 2020 10:11:43 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 092HBgQX026324; Fri, 2 Oct 2020 13:11:42 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 092HBgQX026324 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1601658702; bh=dnG6BqVdpTQlNga4nFdf6V/olsAnhOpzmjXhZGwy2X4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UWTyM5U4mu8hy5eF9CV3zR+RkS+IbsJZYkwJLdU2zFbtNgpzqz+oySbprMj/SSx43 mp0CsZoavXn4MTkLzDB0rinLV8KMbVX/j24EQ+3tJsEoKZl7aeODv0lHzTlLvGP/1U C+NW/OyhoN9Yk1g5WQWyXRBQ58bSAY5e98EKr8VM= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 092HBflY033071; Fri, 2 Oct 2020 13:11:41 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 2 Oct 2020 13:11:41 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Fri, 2 Oct 2020 13:11:41 -0400 From: Roman Danyliw To: Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09 Thread-Index: AdZ3yNCMMi3AzHwFQQyw6c2oHNRUWAD/NPKAB0YNQFA= Date: Fri, 2 Oct 2020 17:11:39 +0000 Message-ID: <8dc3552dc8564a549e19171c3306c8ce@cert.org> References: <8a42a78a8a3645f793b0991e4dd5bb34@cert.org> <428325A0-611A-4E3B-943A-4D848F7BB038@lodderstedt.net> In-Reply-To: <428325A0-611A-4E3B-943A-4D848F7BB038@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 17:11:46 -0000 Hi Torsten! Sorry for my tardy response. Yes, the proposed edits and explanations addr= ess my concerns. Roman > -----Original Message----- > From: Torsten Lodderstedt > Sent: Wednesday, August 26, 2020 8:26 AM > To: Roman Danyliw > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection- > response-09 >=20 > Hi Roman, >=20 > thanks for your review feedback. >=20 > > On 21. Aug 2020, at 16:43, Roman Danyliw wrote: > > > > Hi! > > > > I conducted an another AD review of draft-ietf-oauth-jwt-introspection- > response-09. As background, -07 of this document went to IESG Review and > the document was brought back to the WG to address the DISCUSS points. > > > > Below is my feedback which can be addressed concurrently with IETF LC. > > > > ** Section 5. I want to clarify what are the permissible members of > token_introspection. The two relevant text snippets seem to be: > > > > (a) "token_introspection A JSON object containing the members of the > > token introspection response, as specified in the "OAuth > > Token Introspection Response" registry established by > > [RFC7662] as well as other members." > > > > (b) "Claims from the "JSON Web Token Claims" registry that are > > commonly used in [OpenID.Core] and can be applied to the > > resource owner MAY be included as members in the > > "token_introspection" claim." > > > > -- Per (a), Recommend citing the IANA sub-registry directly -- > https://www.iana.org/assignments/oauth-parameters/oauth- > parameters.xhtml#token-introspection-response (and not the "as specified = in > the "OAuth Token Introspection Response" registry established by [RFC7662= ]") >=20 > done >=20 > > > > -- Per (a), "... as well as other members", what members is this refere= ncing? > Is that (b)? Recommend being clear upfront on which exact registries are= the > sources of valid members. >=20 > I reworked the whole paragraph (hrefs for registries not shown). >=20 > As specified in section 2.2. of [RFC7662], specific implementations MAY e= xtend > the token introspection response with service-specific claims. In the con= text of > this specification, such claims will be added as top-level members of the > token_introspection claim. Response names intended to be used across > domains MUST be registered in the OAuth Token Introspection Response > registry defined by [RFC7662]. In addition, claims from the JSON Web Toke= n > Claims registry established by [RFC7519] MAY be included as members in th= e > token_introspection claim. They can serve to convey the privileges delega= ted to > the client, to identify the resource owner or to provide a required conta= ct > detail, such as an e-Mail address or phone number. When transmitting such > claims the AS acts as an identity provider in regard to the RS. The AS > determines based on its RS-specific policy what claims about the resource > owner to return in the token introspection response. >=20 > Does this work for you? >=20 > > > > -- Per (b), "... commonly used in [OpenId.Core]", what are those specif= ically? > Is that claims registered in > https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is > [OpenID Connect Core 1.0]? Recommend being unambiguous in which claims > are permitted by pointing the IANA registry. > > > > -- If I'm understanding right that the source comes either from oauth- > parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what > happens if it isn't one of those? >=20 > Every implementation is also free to use their own specific claims. This = is > defined in section 2.2. of RFC >=20 > > > > ** Section 5. Per " The AS MUST ensure the release of any privacy-sens= itive > data is legally based", recommend also including a forward reference to S= ection > 9 >=20 > done >=20 > best regards, > Torsten. >=20 > > > > Regards, > > Roman > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Oct 2 15:20:04 2020 Return-Path: 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 CE1053A0CB3 for ; Fri, 2 Oct 2020 15:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 DqWILpJ0PtpX for ; Fri, 2 Oct 2020 15:19:59 -0700 (PDT) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (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 AFA7F3A0A21 for ; Fri, 2 Oct 2020 15:19:59 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id q13so3909158ejo.9 for ; Fri, 02 Oct 2020 15:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=VCSCREu4D+SVbIJZe9P31G1Kjg+Q0Yrr46B48uZrQBw=; b=d+CszksDiOIIuzSI5iGlsScgT3CAYq1CkHbVaZ+SfEjwfXximD0NZi/2sKjtvjbLes DY8GUF9QwwQGm9BE3J+jOG+O27MPJimvytuRLbl9RDCyv23XzOVT0cOHuyAzT+mBVx24 ScUDeOA8L09Wjorrzjlbgesx/NPbqbGnLmFgLCpW3AXtU3syN2F46TQprcRRwhuKLpD6 l+HlEQC3zWyLUAZie1DY6eT3BEZpx/ijxNPZ07GCM7hM2iQniUv9cja4MZQ6ccfcBjRt tVXq/OkBdB9Hm5lqHfKnuZtIMSEsmWzFtcVnC8g8xioTAxactacvWas+mfjIjPBFJZxU PZ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VCSCREu4D+SVbIJZe9P31G1Kjg+Q0Yrr46B48uZrQBw=; b=NpdAMEAx75u/iwXAyDYrKrr9VCt6qOuo6QRRRg2X/NPKKeShRv0EEdCjN3dGTRgdE5 xy9nbGnuLYBrc9e6sFrxXFjIB1w0oqk7RQsCN0pIurgdw8Wah0Ib5mvrgIZqWE5/cebY YaxoFC2OPQfZ6EJgza+PUkrQ69zsHVZKrwsByUWKnnWiKJ+gZ4c1Fvz/sUjDmbGdxCj4 Uq4oZ8Hy93uVGA+XPCo6o4XmIcu5fFYzyBu5/kXQy44Yo/ZytI+d22uu5+6NcY50WlI1 svnUjMLyV69EdhwVsnytVWlihFguhqOt1WSA1htVb1jYHqeYziuyQdnzTsIWokEq9lMg 3wGg== X-Gm-Message-State: AOAM531JZ2lmSXcU6g9KjOuwjmiNSXp3JYEY1X/VQAd1C1NIyv+xtCI1 LQdMn4+3KLj4kvKt7b+CZXwXiepd4csLyih+B5pmg+XhUig= X-Google-Smtp-Source: ABdhPJxb5aD53M8CgTjgVjmtuDVtW6KdEU99DuAdeImXYoTUS6cRylGQm2PfMW0rQlymUwWNxzbJViUH9r+9WOzCIr8= X-Received: by 2002:a17:906:7695:: with SMTP id o21mr4281350ejm.176.1601677197856; Fri, 02 Oct 2020 15:19:57 -0700 (PDT) MIME-Version: 1.0 From: Andrii Deinega Date: Fri, 2 Oct 2020 15:19:47 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006c56ed05b0b78828" Archived-At: Subject: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:20:02 -0000 --0000000000006c56ed05b0b78828 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG, https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 provides the flowing about JWT access tokens =E2=80=9Cresource servers can consume them directly for authorization or ot= her purposes without any further round trips to introspection ( [RFC7662]) or userinfo [OpenID.Core]) endpoints.=E2=80=9D which is completely understandable. I do understand that the objective of this document is to standardize the token which the AS shares with the RS as it was discussed in other email threads. Here is what I would like to get a better understanding of: 1. How should a response of the introspection endpoint look like if the RS makes an attempt to introspect a JWT access token? 2. How should a response of the OpenID Connect userinfo endpoint look like for a JWT access token? I assume that it=E2=80=99s expected to have no difference compared to a reg= ular bearer token (given that a particular implementation of the AS provides these endpoints). Does it sound right? If so, what are we going to get if the RS or the client revokes a valid JWT access token using the revocation endpoint (RFC 7009)? Do you think there is a need to add more detailed information about these scenarios in the document? This way, we could refer back to these sections in the documentation in case any disputes around security-related topics come up. Thank you. Regards, Andrii --0000000000006c56ed05b0b78828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

https://tools.ietf.org/htm= l/draft-ietf-oauth-access-token-jwt-10 provides the flowing about JWT a= ccess tokens

=E2=80=9Cresource servers can consume them directly for= authorization or other purposes without any further round trips to introsp= ection ( [RFC7662]) or userinfo [OpenID.Core]) endpoints.=E2=80=9D

w= hich is completely understandable. I do understand that the objective of th= is document is to standardize the token which the AS shares with the RS as = it was discussed in other email threads.

Here is what I would like t= o get a better understanding of:
1. How should a response of the introsp= ection endpoint look like if the RS makes an attempt to introspect a JWT ac= cess token?
2. How should a response of the OpenID Connect us= erinfo endpoint look like for a JWT access token?

I assume that it= =E2=80=99s expected to have no difference=C2=A0compared to a regular bearer= token (given that a particular implementation of the AS provides these end= points). Does it sound right?

If so, what are we= =C2=A0going to get if the RS or the client revokes a valid JWT access token= using the revocation endpoint (RFC 7009)?

Do you think t= here is a need to add more detailed=C2=A0information about these scenarios = in the document? This way, we=C2=A0could refer back to these sections in th= e documentation in case any disputes around security-related topics come up= .

Thank you.

Regards,
Andrii


--0000000000006c56ed05b0b78828-- From nobody Fri Oct 2 16:35:49 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 953373A1748; Fri, 2 Oct 2020 16:35:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <160168173955.1485.13491581367998166334@ietfa.amsl.com> Date: Fri, 02 Oct 2020 16:35:39 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 23:35:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-07.txt Pages : 21 Date : 2020-10-02 Abstract: This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 2 16:53:23 2020 Return-Path: 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 AC2AC3A1757 for ; Fri, 2 Oct 2020 16:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 KfQP_8nlIlJQ for ; Fri, 2 Oct 2020 16:53:20 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 DC5BE3A1754 for ; Fri, 2 Oct 2020 16:53:19 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id f15so2797165ilj.2 for ; Fri, 02 Oct 2020 16:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QZjmQpeSTy0LpZs5SJIrOk3exuCEz+P2bY0u5ehpCwc=; b=JFYAv5bVlq7ODNE7/8aBS+4/UgLd2HFskunJcrj12+31mVe34xN3KLpyCz2lM9qOo/ cX2qUdkzzWpKvsvMQzBeybG3p+8kMV70IF6yPMtv6XVYltvB0HH1mfpNfkToTqPy8Ufn Q8VwcSKepoIsgxpXKE1vQY9Glzg8GdUxe+2zUYDxGHRKL7eQ92n1rf92BfGB6gmJjv7i x/SP3vp12hkAzG+Az6o3Dyxd6RchP+nr9qwyVtsVC/kfztTdXCcSmKpsWXCUjKgplBZJ RBenSqbMSjUfsj5UmjLZlpxs/VYu7cWO2ltLTLFWo7B4alY+txemjmSF09am/VBzrvCL TzvQ== 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; bh=QZjmQpeSTy0LpZs5SJIrOk3exuCEz+P2bY0u5ehpCwc=; b=ZnRdPLGht/KXRC3VaPiDk2DvfmLCjlaj0nq8ZJk8bYuP3ukXgzYGMt8n6CGjrASECk uRRANRe6pwsnv0Exm+mK7bovOLGRoq3V/CrEpAc1iMZwIxqMskPcawrwNWuHlKPDKvVM 2Bqy9cGHHUdtriAPda58TUrd82ZnQKtTzScGVJuWHCc+U1Dn0E+7TLjbRjRT5WLMbEJf HQ5NnNkRO3xXovv16h4TDnVUz3on5vDwrDhCx2Lm/LUEdlvNZMifwxmfILiOOXEQZWAF RI1TUAGwl4rdKF5+vkzbggTL4j/QbpdoiMtgB42SUGo1WSytOIwchgrupGeMZHhMfD3i 6xjQ== X-Gm-Message-State: AOAM532DnnS68nVGY1XF1giq22LAEE32ZtCXTFnOLbtgeJyA5yXFQpiZ AuSjVPjKq83/vkV1inrcivvQP82QUlI/zA== X-Google-Smtp-Source: ABdhPJwPKkda294hJ3HtqqKg168fB6mOeIMzZ4BEj2Ms3guhcTFnUTjpsJNSzAny4eePxkWylTtMRA== X-Received: by 2002:a92:c7a7:: with SMTP id f7mr3643174ilk.209.1601682798579; Fri, 02 Oct 2020 16:53:18 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id o15sm1574731ilc.41.2020.10.02.16.53.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 16:53:18 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id d197so3376914iof.0 for ; Fri, 02 Oct 2020 16:53:17 -0700 (PDT) X-Received: by 2002:a02:1004:: with SMTP id 4mr4336942jay.127.1601682797587; Fri, 02 Oct 2020 16:53:17 -0700 (PDT) MIME-Version: 1.0 References: <160168173955.1485.13491581367998166334@ietfa.amsl.com> In-Reply-To: <160168173955.1485.13491581367998166334@ietfa.amsl.com> From: Aaron Parecki Date: Fri, 2 Oct 2020 16:53:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000003174a805b0b8d6f1" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 23:53:22 -0000 --0000000000003174a805b0b8d6f1 Content-Type: text/plain; charset="UTF-8" Hi all, Based on some of the discussions from our virtual interim meeting and the OAuth Security Workshop, I published a (minor) update to the browser app BCP. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 The primary changes are: * Revised the language around PKCE/Implicit to clarify that PKCE applies only when issuing access tokens * Clarified that ASs MUST NOT issue access tokens in the authorization response * Changed "MUST" to "SHOULD" for rotating refresh tokens * Editorial clarifications to the summary bullet point section I believe these changes reflect all the latest discussions we've had. There are still some outstanding items I am aware of that need adding to the document as well. Apologies for the delay in getting this out. I hope we can pick up the momentum on this document again! Aaron Parecki On Fri, Oct 2, 2020 at 4:36 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 for Browser-Based Apps > Authors : Aaron Parecki > David Waite > Filename : draft-ietf-oauth-browser-based-apps-07.txt > Pages : 21 > Date : 2020-10-02 > > Abstract: > This specification details the security considerations and best > practices that must be taken into account when developing browser- > based applications that use OAuth 2.0. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003174a805b0b8d6f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Based on some of the discussion= s=C2=A0from our virtual interim meeting and the OAuth Security Workshop, I = published a (minor) update to the browser app BCP.

https://tools.ietf.org/html/draft-ietf-oauth-browser= -based-apps-07

The primary changes are:

* Revised the language around PKCE/Implicit to clari= fy that PKCE applies only when issuing access tokens
* Clarified = that ASs MUST NOT issue access tokens in the authorization response
* Changed "MUST" to "SHOULD" for rotating refresh to= kens
* Editorial clarifications to the summary bullet point secti= on

I believe these changes reflect all the latest = discussions we've had. There are still some outstanding items I am awar= e of that need adding to the document as well. Apologies for the delay in g= etting this out. I hope we can pick up the momentum on this document again!=

Aaron Parecki


=

On Fri, Oct 2, 2020 at 4:36 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 for Browser-Based Apps
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Aaro= n Parecki
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 David Waite
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-browser-based-apps-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-10-02

Abstract:
=C2=A0 =C2=A0This specification details the security considerations and bes= t
=C2=A0 =C2=A0practices that must be taken into account when developing brow= ser-
=C2=A0 =C2=A0based applications that use OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-oauth-browser-based-apps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-oauth-browser-based-apps-07
https://datatracker.ietf= .org/doc/html/draft-ietf-oauth-browser-based-apps-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-oauth-browser-based-apps-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003174a805b0b8d6f1-- From nobody Sat Oct 3 10:18:18 2020 Return-Path: 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 A23273A0BA6 for ; Sat, 3 Oct 2020 10:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 DPrvbBA1kzOA for ; Sat, 3 Oct 2020 10:18:14 -0700 (PDT) Received: from mail.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E13C3A0B93 for ; Sat, 3 Oct 2020 10:18:13 -0700 (PDT) Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-02-69-159-172-90.dsl.bell.ca [69.159.172.90]) by mail.babelouest.org (Postfix) with ESMTPSA id 3FDB32034C for ; Sat, 3 Oct 2020 13:18:10 -0400 (EDT) To: oauth@ietf.org References: From: Nicolas Mora Autocrypt: addr=nicolas@babelouest.org; keydata= mQINBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABtCVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+iQJRBBMBCAA7AhsDBQsJCAcCBhUICQoLAgQW AgMBAh4BAheAFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAl8FCPUCGQEACgkQ/oITlEC9Irkb ZxAAodrP5pSZFAbxqu9vKtkY4xNLyV+xVmjxEd376M8chbrEmbZaKd7v2sAC+RfJzZqygTsU ACiwM65jEbM87pIUZpaC6EhqRkmciTjPDrDEfKvf6TvOPkNCVgH8pPDligkA/VhmXYW+enOx jJfBrJstKmSa19heKwB6tqbgbIJ5GIQzLbPRCW4jvZ0NBZ7p3drbz0llM5y7e+jtytrOOswD O3z4KGJMjKiQwU88SJ1HRQc9CDe4BW9AZyljWf91FUd1Ees1n8X/6HwVySf1Q6Tpa3K7RDT/ fVvA38eI/X+MLdYMJvX45YCi61ySfFf/afXGkFgwVip98qe/W9AAOCYYj0+XQajgjfExnBAB /6Qvs1kVrT1Sg1LElyMZtk9nZQxOv2MqMQghgeptgvjILa2knYJKYPO1LHGVAXZc1CxB2tgt MrxdaGAw6ObW+d1Lt1ohVd78JHm23MhBnly8LjEJp+gIWB9zqSlkgGocWP9Fljf9K2haAieQ Ot/C3/9NohYzn15v1Ib/iEAVzV7fhD7V0nhTZFuLPlxuRWc4QY3E3j8irRcdxjjcnG1PxMOh KJH/R4xILS+iEsot8cNr6V63H1vVMcKF34EFmWTw2cS13FKrl13klcHD0eoOXpNCte2jwxrz 26edRd+nC8DBUG6OCdroOzEsvkI4IcJZgfbzooG5Ag0EWYmqvwEQAOsjmWy2MtpLohfEffsZ a988t2MvJMUrmQmrJmSEY0xYebCZFTcFWvPQzRO9r9rdnUH59ckbMp69CEowGyuliGRsqRsy Du+t6JaFmNDLLme9soDhoyFnVySZhYTE6TZCJSlMOgsME3tURkb4VX0fDllV4fWTkudsjHHE gZ3MrWbFwIGAmh2/MeynVJl59UgoEosf7L6xwBkNucN9JSj/Wk+Cu6iCySmDrteu0M/+ZnGB /sYHTCWtCusm314G4IPk1ciO2Xwq8Qg8pPECVh/8a7xkK67RzAcuX/v1ZQfrBPflcHICwEy2 4bx0cOJ2PnT9eSk/YvoYTnYphM2hBW/legAjOm7BcPFxMwvQmMTUQoB9EV7K66Iydxf12C1F 0kYyA3/gdjMiJK9ayNiSBVQWuH9mUQ1sToOHLg0uoMQFBvlEwhas7tVVoAqixHKxjvYbdnUW ZLabZ08CU00sYcRKVwunefCc0UWd5CJ/gp/Vl0UxkkLLwPqf5Nu5mZjx4wLrbg63mHXxqfTI FYUTwT9dTjJBHqxq+GGKdjVhzgQqNw2I/hxOumGHhwTteAyK1f7TJzUP2zu6a6IF2rD1UCzI DbQ18tkIzGJ6IZhyB1rVY8DlXuNBzebwb4InKDvrZNvdfI8YE/LhMN+CGnDVGph/zBgCLx7v jAodyT+4A/pHWVzvABEBAAGJAh8EGAEIAAkFAlmJqr8CGwwACgkQ/oITlEC9IrljgA/9FvQX aWYHq4O7roGEJhftnaFye3j8tkrWFhvp9E7eadbxcKWe1g4ZsqgAYBANLc+sjHYQmRSvkWJY ymed5A9zB824vtWVKqVwV/A36SSNNywiOvDcoyAY1uONDzeMJTOJ3JDh6DXwAoprFvQ2sDxQ 1FO+0rSjNJOHGfMtnbSe7+ZT00mFwxXHZDMgRSIkrlqDe5eWL+vnYguV7lar0s/GM8SyXSga Wo0wZwJkuvbS0debRcutJUR6dYovyGNoS50811wowsFZWynRUhL92LV+xCDCG4n0L5/CG2po awvkOwoNiGtSjWIqLhq9fR/wh3N6dBIoWygl/636Qcibn9l1nyMw3TzVHOci/PynwHFY7NuD 4FkIKQ4iwLHKmZT1aAwwneFeBFrY4iFBlDcCcFz9Tzje5T/sdVEyF3h5/OM3D+/WOgN3goQk QedL+NP+z2PETKKQ61Bb2i0kEuBmmgQb71EUIo+7hNXxEH2RkIc4zmXBLCrsIjDBWW0XWkxG iSbpfuXJyVniIIS19kAzpm6839+HUZsgnF+36EhaoM+Ib1s+2hdkwCtSLXMJpKYV3Ntr/Xn4 /4HcTJpp1iJKNWf1YGF7qzLFnxZijR6G8kR7jYEsZwZFxCX6XYm3nsPcU8NhgkRSSXvawaGE puuDhgFV8Kha5yEPTBe9H0BFe0srkfg= Message-ID: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> Date: Sat, 3 Oct 2020 13:18:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 17:18:17 -0000 My 2 cents, Le 20-10-02 à 18 h 19, Andrii Deinega a écrit : > > Here is what I would like to get a better understanding of: > 1. How should a response of the introspection endpoint look like if the > RS makes an attempt to introspect a JWT access token? AFAIK, the RFC doesn't specify if the introspection should be different between an opaque AT and a JWT AT, so my guess is the introspection result shouldn't be different either. > 2. How should a response of the OpenID Connect userinfo endpoint look > like for a JWT access token? >There should be no difference in userinfo response between an opaque AT and a JWT AT. The userinfo and the introspection endpoints have different goals, and I don't expect the userinfo to return data based on the AT provided (except to identify the sub it relates to). Instead, the userinfo must return user claims based on the AS configuration and the claims requested. > I assume that it’s expected to have no difference compared to a regular > bearer token (given that a particular implementation of the AS provides > these endpoints). Does it sound right? > That's my opinion too, although I don't recall any specification talking about it, so I guess it's a matter of implementation. > If so, what are we going to get if the RS or the client revokes a valid > JWT access token using the revocation endpoint (RFC 7009)? > > Do you think there is a need to add more detailed information about > these scenarios in the document? This way, we could refer back to these > sections in the documentation in case any disputes around > security-related topics come up. > If a client revokes a valid AT, after that, the AS introspection should answer an error response: https://tools.ietf.org/html/rfc7662#section-2.3 The problem here might be: how should the RS know if a JWT token has been revoked on the AS? I don't think there is a specified solution for this because it all depends on the implementation. The RS might use the introspection endpoint to check if a valid JWT AT has been revoked or not. - If the introspection endpoint is checked on some JWT AT use, it might lead to an attack - If the introspection endpoint is checked on every JWT AT use, then the advantage of using a JWT AT is close to 0 There might be some kind of pushed events between the AS and the RS when a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all. Like this, the RS knows if a JWT AT has been revoked or not. If the client uses a proof of possession process, the revocation endpoint may be useless, because if the client doesn't want an AT to be used after a certain point, it just has not to use it anymore. /Nicolas From nobody Sun Oct 4 08:27:55 2020 Return-Path: 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 E48DB3A011B for ; Sun, 4 Oct 2020 08:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 f4kENM166QQG for ; Sun, 4 Oct 2020 08:27:52 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 09DDC3A0112 for ; Sun, 4 Oct 2020 08:27:51 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id k18so4881606ybh.1 for ; Sun, 04 Oct 2020 08:27:51 -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; bh=B2ZVq0d3op3owBS6qlofzmfPGaRHnQlP+6P8qFYlv6o=; b=ZUbsqVXi855/9SFDPrMq/i2eA9aNfpfGmaopDZRz2wvsu/+rpFP97q6D76FFLe8zx3 f9fIvzbcitHHshbVfqb7K0RwH+c2ON5wGekPb0qCUv1cK8lBbVxIdJrxwdo5ZgwaS/cb s/hTl88bo1fvYXISX+m4UvUeTi/FI7LTTzg7FG4IXH3L1v0UjllgC9jVKpaEsV37sMzl RZZl2vugIkt0fYqSWeIrFH8NGyDO3D5Kht/yzrzPnETVmdjcXFyesFcaIiuDhNhgCaZX Ax8xK1DfUyU/kHrMCQaS5NEKpYCPnvUYd9mMfnsdR2zyz34sZ+cckENIqzOmNW7uNuh3 K6hA== 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=B2ZVq0d3op3owBS6qlofzmfPGaRHnQlP+6P8qFYlv6o=; b=RTxVUpVCgoF5Dk+ri+zBRvxdoLNyBuQh3X4DbkaVjUHyVF+J0P+FAc/TDWgl/wAWHI 3wEvQthm7C1qP4d+MHrCgBeZbFXdDR445ILR15K8YkxRNLoGBR7jU3oKZ14Nc3b+jQon 3X61tq3aQj/MyFnVIOu3BKypKLfrvfaqteS9KTx38pgnAmMAjRifPUOyqDkLCJeMIZf1 thYKURcQSIGJsmYH56BXdtSS+RcakjOH2Rf7HR2vuS8qObiWYvqHobNJ+b5v0J9YFQZK yNke2bwh9OVvXtXIKBtCZ9Uq7ygh2Jfhtny3ATsuXlIQpHPGAuJpOKQNNpQpP2u3/98M sG/Q== X-Gm-Message-State: AOAM530jVNeHKTuanTJBNEr5DDu2z1lU7T0ZWXc1hut1+HOBhzz4HrzW 4Fb/2MkSAMgm4trSk6gZVsd9voBGkgycf4+/++6RnDeb X-Google-Smtp-Source: ABdhPJwyC1Jw7xtV152MfLl8TKAKFXgk3LBLB3ftn26iUOdNpzISXiGVW1VVU35/yagPcbvuu1+pAJSTBSAGDcLyj28= X-Received: by 2002:a25:3453:: with SMTP id b80mr14373753yba.237.1601825271013; Sun, 04 Oct 2020 08:27:51 -0700 (PDT) MIME-Version: 1.0 References: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> In-Reply-To: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> From: Thomas Broyer Date: Sun, 4 Oct 2020 17:27:41 +0200 Message-ID: To: Nicolas Mora Cc: "" Content-Type: multipart/alternative; boundary="00000000000045663905b0da02f0" Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 15:27:54 -0000 --00000000000045663905b0da02f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Disclosure: I have not read the draft on JWT AT, those comments are based only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT. Le sam. 3 oct. 2020 =C3=A0 19:18, Nicolas Mora a = =C3=A9crit : > My 2 cents, > > Le 20-10-02 =C3=A0 18 h 19, Andrii Deinega a =C3=A9crit : > > > > Here is what I would like to get a better understanding of: > > 1. How should a response of the introspection endpoint look like if the > > RS makes an attempt to introspect a JWT access token? > > AFAIK, the RFC doesn't specify if the introspection should be different > between an opaque AT and a JWT AT, so my guess is the introspection > result shouldn't be different either. > > > 2. How should a response of the OpenID Connect userinfo endpoint look > > like for a JWT access token? > >There should be no difference in userinfo response between an opaque AT > and a JWT AT. > > The userinfo and the introspection endpoints have different goals, and I > don't expect the userinfo to return data based on the AT provided > (except to identify the sub it relates to). Instead, the userinfo must > return user claims based on the AS configuration and the claims requested= . > > > I assume that it=E2=80=99s expected to have no difference compared to a= regular > > bearer token (given that a particular implementation of the AS provides > > these endpoints). Does it sound right? > > > That's my opinion too, although I don't recall any specification talking > about it, so I guess it's a matter of implementation. > > > If so, what are we going to get if the RS or the client revokes a valid > > JWT access token using the revocation endpoint (RFC 7009)? > > > > Do you think there is a need to add more detailed information about > > these scenarios in the document? This way, we could refer back to these > > sections in the documentation in case any disputes around > > security-related topics come up. > > > If a client revokes a valid AT, after that, the AS introspection should > answer an error response: https://tools.ietf.org/html/rfc7662#section-2.3 > > The problem here might be: how should the RS know if a JWT token has > been revoked on the AS? > I don't think there is a specified solution for this because it all > depends on the implementation. > > The RS might use the introspection endpoint to check if a valid JWT AT > has been revoked or not. > - If the introspection endpoint is checked on some JWT AT use, it might > lead to an attack > - If the introspection endpoint is checked on every JWT AT use, then the > advantage of using a JWT AT is close to 0 > With a JWT AT you can check the JWT signature and detect expiry without introspection. But otherwise, yes, no difference. There might be some kind of pushed events between the AS and the RS when > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all. > Like this, the RS knows if a JWT AT has been revoked or not. If there are some kind of pushed events between the AS and the RS, then it could push the revoked (and/or expired) opaque AT too, giving almost no advantage to JWT ATs. If the client uses a proof of possession process, the revocation > endpoint may be useless, because if the client doesn't want an AT to be > used after a certain point, it just has not to use it anymore. > > /Nicolas > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000045663905b0da02f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Disclosure: I have not read the draft on JWT AT, tho= se comments are based only on my current knowledge of OAuth 2.0 / OpenID Co= nnect, and JWT.

Le sam. 3 oct. 2020 =C3=A0 = 19:18, Nicolas Mora <nicolas@b= abelouest.org> a =C3=A9crit=C2=A0:
My 2 cents,

Le 20-10-02 =C3=A0 18 h 19, Andrii Deinega a =C3=A9crit=C2=A0:
>
> Here is what I would like to get a better understanding of:
> 1. How should a response of the introspection endpoint look like if th= e
> RS makes an attempt to introspect a JWT access token?

AFAIK, the RFC doesn't specify if the introspection should be different=
between an opaque AT and a JWT AT, so my guess is the introspection
result shouldn't be different either.

> 2. How should a response of the OpenID Connect userinfo endpoint look<= br> > like for a JWT access token?
>There should be no difference in userinfo response between an opaque AT=
and a JWT AT.

The userinfo and the introspection endpoints have different goals, and I don't expect the userinfo to return data based on the AT provided
(except to identify the sub it relates to). Instead, the userinfo must
return user claims based on the AS configuration and the claims requested.<= br>
> I assume that it=E2=80=99s expected to have no difference=C2=A0compare= d to a regular
> bearer token (given that a particular implementation of the AS provide= s
> these endpoints). Does it sound right?
>
That's my opinion too, although I don't recall any specification ta= lking
about it, so I guess it's a matter of implementation.

> If so, what are we=C2=A0going to get if the RS or the client revokes a= valid
> JWT access token using the revocation endpoint (RFC 7009)?
>
> Do you think there is a need to add more detailed=C2=A0information abo= ut
> these scenarios in the document? This way, we=C2=A0could refer back to= these
> sections in the documentation in case any disputes around
> security-related topics come up.
>
If a client revokes a valid AT, after that, the AS introspection should
answer an error response: https://tools.ie= tf.org/html/rfc7662#section-2.3

The problem here might be: how should the RS know if a JWT token has
been revoked on the AS?
I don't think there is a specified solution for this because it all
depends on the implementation.

The RS might use the introspection endpoint to check if a valid JWT AT
has been revoked or not.
- If the introspection endpoint is checked on some JWT AT use, it might
lead to an attack
- If the introspection endpoint is checked on every JWT AT use, then the advantage of using a JWT AT is close to 0

With a JWT AT you can check the JW= T signature and detect expiry without introspection.
But otherwise, yes, no difference.

There might be some kind of pushed events between the AS and the RS when a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all.
Like this, the RS knows if a JWT AT has been revoked or not.

If there are some k= ind of pushed events between the AS and the RS, then it could push the revo= ked (and/or expired) opaque AT too, giving almost no advantage to JWT ATs.<= /div>


If the client uses a proof of possession process, the revocation
endpoint may be useless, because if the client doesn't want an AT to be=
used after a certain point, it just has not to use it anymore.

/Nicolas

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000045663905b0da02f0-- From nobody Sun Oct 4 09:55:22 2020 Return-Path: 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 4FBCF3A08BB for ; Sun, 4 Oct 2020 09:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-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 Xn7S-RMyxwyV for ; Sun, 4 Oct 2020 09:55:18 -0700 (PDT) Received: from mail.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E323A08BA for ; Sun, 4 Oct 2020 09:55:17 -0700 (PDT) Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-02-69-159-172-90.dsl.bell.ca [69.159.172.90]) by mail.babelouest.org (Postfix) with ESMTPSA id E94C320E08; Sun, 4 Oct 2020 12:55:14 -0400 (EDT) To: Thomas Broyer Cc: oauth@ietf.org References: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> From: Nicolas Mora Autocrypt: addr=nicolas@babelouest.org; keydata= mQINBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABtCVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+iQJRBBMBCAA7AhsDBQsJCAcCBhUICQoLAgQW AgMBAh4BAheAFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAl8FCPUCGQEACgkQ/oITlEC9Irkb ZxAAodrP5pSZFAbxqu9vKtkY4xNLyV+xVmjxEd376M8chbrEmbZaKd7v2sAC+RfJzZqygTsU ACiwM65jEbM87pIUZpaC6EhqRkmciTjPDrDEfKvf6TvOPkNCVgH8pPDligkA/VhmXYW+enOx jJfBrJstKmSa19heKwB6tqbgbIJ5GIQzLbPRCW4jvZ0NBZ7p3drbz0llM5y7e+jtytrOOswD O3z4KGJMjKiQwU88SJ1HRQc9CDe4BW9AZyljWf91FUd1Ees1n8X/6HwVySf1Q6Tpa3K7RDT/ fVvA38eI/X+MLdYMJvX45YCi61ySfFf/afXGkFgwVip98qe/W9AAOCYYj0+XQajgjfExnBAB /6Qvs1kVrT1Sg1LElyMZtk9nZQxOv2MqMQghgeptgvjILa2knYJKYPO1LHGVAXZc1CxB2tgt MrxdaGAw6ObW+d1Lt1ohVd78JHm23MhBnly8LjEJp+gIWB9zqSlkgGocWP9Fljf9K2haAieQ Ot/C3/9NohYzn15v1Ib/iEAVzV7fhD7V0nhTZFuLPlxuRWc4QY3E3j8irRcdxjjcnG1PxMOh KJH/R4xILS+iEsot8cNr6V63H1vVMcKF34EFmWTw2cS13FKrl13klcHD0eoOXpNCte2jwxrz 26edRd+nC8DBUG6OCdroOzEsvkI4IcJZgfbzooG5Ag0EWYmqvwEQAOsjmWy2MtpLohfEffsZ a988t2MvJMUrmQmrJmSEY0xYebCZFTcFWvPQzRO9r9rdnUH59ckbMp69CEowGyuliGRsqRsy Du+t6JaFmNDLLme9soDhoyFnVySZhYTE6TZCJSlMOgsME3tURkb4VX0fDllV4fWTkudsjHHE gZ3MrWbFwIGAmh2/MeynVJl59UgoEosf7L6xwBkNucN9JSj/Wk+Cu6iCySmDrteu0M/+ZnGB /sYHTCWtCusm314G4IPk1ciO2Xwq8Qg8pPECVh/8a7xkK67RzAcuX/v1ZQfrBPflcHICwEy2 4bx0cOJ2PnT9eSk/YvoYTnYphM2hBW/legAjOm7BcPFxMwvQmMTUQoB9EV7K66Iydxf12C1F 0kYyA3/gdjMiJK9ayNiSBVQWuH9mUQ1sToOHLg0uoMQFBvlEwhas7tVVoAqixHKxjvYbdnUW ZLabZ08CU00sYcRKVwunefCc0UWd5CJ/gp/Vl0UxkkLLwPqf5Nu5mZjx4wLrbg63mHXxqfTI FYUTwT9dTjJBHqxq+GGKdjVhzgQqNw2I/hxOumGHhwTteAyK1f7TJzUP2zu6a6IF2rD1UCzI DbQ18tkIzGJ6IZhyB1rVY8DlXuNBzebwb4InKDvrZNvdfI8YE/LhMN+CGnDVGph/zBgCLx7v jAodyT+4A/pHWVzvABEBAAGJAh8EGAEIAAkFAlmJqr8CGwwACgkQ/oITlEC9IrljgA/9FvQX aWYHq4O7roGEJhftnaFye3j8tkrWFhvp9E7eadbxcKWe1g4ZsqgAYBANLc+sjHYQmRSvkWJY ymed5A9zB824vtWVKqVwV/A36SSNNywiOvDcoyAY1uONDzeMJTOJ3JDh6DXwAoprFvQ2sDxQ 1FO+0rSjNJOHGfMtnbSe7+ZT00mFwxXHZDMgRSIkrlqDe5eWL+vnYguV7lar0s/GM8SyXSga Wo0wZwJkuvbS0debRcutJUR6dYovyGNoS50811wowsFZWynRUhL92LV+xCDCG4n0L5/CG2po awvkOwoNiGtSjWIqLhq9fR/wh3N6dBIoWygl/636Qcibn9l1nyMw3TzVHOci/PynwHFY7NuD 4FkIKQ4iwLHKmZT1aAwwneFeBFrY4iFBlDcCcFz9Tzje5T/sdVEyF3h5/OM3D+/WOgN3goQk QedL+NP+z2PETKKQ61Bb2i0kEuBmmgQb71EUIo+7hNXxEH2RkIc4zmXBLCrsIjDBWW0XWkxG iSbpfuXJyVniIIS19kAzpm6839+HUZsgnF+36EhaoM+Ib1s+2hdkwCtSLXMJpKYV3Ntr/Xn4 /4HcTJpp1iJKNWf1YGF7qzLFnxZijR6G8kR7jYEsZwZFxCX6XYm3nsPcU8NhgkRSSXvawaGE puuDhgFV8Kha5yEPTBe9H0BFe0srkfg= Message-ID: Date: Sun, 4 Oct 2020 12:55:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 16:55:20 -0000 Hello, Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > There might be some kind of pushed events between the AS and the RS when > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all. > Like this, the RS knows if a JWT AT has been revoked or not. > > > If there are some kind of pushed events between the AS and the RS, then > it could push the revoked (and/or expired) opaque AT too, giving almost > no advantage to JWT ATs. > Not necessarily, let's say the AS informs the RS only of the revoked ATs, when a RS checks an AT, it verifies the signature first, then the claims, then checks if the AT has been revoked by checking its internal list filled by the AS pushed events. In this model, considering that token revocations don't happen a lot, the ratio revoked AT/valid AT is very low, so the advantage of a JWT is important, because it means not so much communication between the AS and the RSs, and a very reliable AT. But this means a communication mechanism that isn't standardized yet. /Nicolas From nobody Sun Oct 4 17:17:27 2020 Return-Path: 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 8A3893A0AB8 for ; Sun, 4 Oct 2020 17:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=manicode.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 L9dzPg55y8x6 for ; Sun, 4 Oct 2020 17:17:24 -0700 (PDT) Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 152BC3A0AB6 for ; Sun, 4 Oct 2020 17:17:23 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id t7so4750359pjd.3 for ; Sun, 04 Oct 2020 17:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ySwJQBCfC93U9Xwrxqf7oGDSZQ5pB7gBgOZDIIWlHfA=; b=DNetaAwYAx2Xtqnbi26Ya3OfX+1g1fyOFqmJQnlg1Vk1gpltMTvYXmrBrhFEHO6CQW U1RsqTkTD0D6/739OVO8bsG5B5XcfFG9NGRTtbSG7zO7kQaegHDXqDJ/3PyUIiO2HZIh Z2HjjUndtmgFpmb0imZecZnZ4LSYwixJtmMo8YEiigGo2KrelVzKSNu+FZmDMkIujR2G lalrrXM3ZBzC3LYEwvKI+oCZNNNeXkOAgh5aCsnvNvRXrkgGYpjTngH8geyOEMhMMvgC Ze9FJuDYXLS43rctAPXugdBENZM8RzGtHvuoAY/qD/S2Az1LjD6CR+tSep10DWd2sslM BXxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ySwJQBCfC93U9Xwrxqf7oGDSZQ5pB7gBgOZDIIWlHfA=; b=OB0Y4VwreevwqBnfgCXDjAc9yrLCyHsbF0wmSuEDauhH6yV/Z1O6etm7VVUfy0w++T AWwep/GYY4KC/PyEi3Pfa9L25wn5U3K19f/P4yLDRXG2K5YQa4YYwf2QaAjhf3mU6yAr jPI+xfVSFwrPPZOF1RiPT4UbKlgodevndgzghd+JIxmMcpQlQYiwNXP829RZcTOvr56+ 6Dob2FivDWB2XrkC+EZGjyJ8Vw9xzJ3KauZRWyec1vo3ephb4fNbLYd96dLNCvyf5NxX Ld2wlVHRGYJFLmaUKi5YbOgQw9NgbkERub4aiYEeBiPeYCQVJoasN+/nF/a8xhnLetWz 136Q== X-Gm-Message-State: AOAM533n3ebwZV1pwKfBjrtAVhytbfcVm3D5Pj6SzizMj2nfRJIfSjpX Ko9xDnNkh8phB2oYuzvkQ48uGg== X-Google-Smtp-Source: ABdhPJzzRnnRypRl2iLPGcYD1fqZErsIsTk/lPJu4Xj1088xA0v74vexLO9r3hKHtgHsvRYdXiFrgw== X-Received: by 2002:a17:90a:bb81:: with SMTP id v1mr4493765pjr.62.1601857043275; Sun, 04 Oct 2020 17:17:23 -0700 (PDT) Received: from ?IPv6:2605:e000:112c:15:1c86:c08:4402:5c13? ([2605:e000:112c:15:1c86:c08:4402:5c13]) by smtp.gmail.com with ESMTPSA id d129sm9203954pfc.161.2020.10.04.17.17.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Oct 2020 17:17:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jim Manico Mime-Version: 1.0 (1.0) Date: Sun, 4 Oct 2020 14:17:19 -1000 Message-Id: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> References: Cc: Thomas Broyer , oauth@ietf.org In-Reply-To: To: Nicolas Mora X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 00:17:26 -0000 > In this model, considering that token revocations don't happen a lot... Just a brief note, a secure piece of software makes the logout feature promi= nent. Every logout event should trigger token revocation. I=E2=80=99m mentioning this because a lot of OAuth solutions in the mobile s= pace literally ignore the logout event, such as Facebook=E2=80=99s mobile OA= uth solution.=20 - Jim > On Oct 4, 2020, at 6:55 AM, Nicolas Mora wrote: >=20 > =EF=BB=BFHello, >=20 >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : >>=20 >> There might be some kind of pushed events between the AS and the RS wh= en >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all= . >> Like this, the RS knows if a JWT AT has been revoked or not. >>=20 >>=20 >> If there are some kind of pushed events between the AS and the RS, then >> it could push the revoked (and/or expired) opaque AT too, giving almost >> no advantage to JWT ATs. >>=20 > Not necessarily, let's say the AS informs the RS only of the revoked > ATs, when a RS checks an AT, it verifies the signature first, then the > claims, then checks if the AT has been revoked by checking its internal > list filled by the AS pushed events. >=20 > In this model, considering that token revocations don't happen a lot, > the ratio revoked AT/valid AT is very low, so the advantage of a JWT is > important, because it means not so much communication between the AS and > the RSs, and a very reliable AT. >=20 > But this means a communication mechanism that isn't standardized yet. >=20 > /Nicolas >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 5 08:21:11 2020 Return-Path: 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 B54073A0B50 for ; Mon, 5 Oct 2020 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=F76G6+9G; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=F76G6+9G 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 1Tvjdz6Wipkv for ; Mon, 5 Oct 2020 08:21:07 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (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 031313A0A6C for ; Mon, 5 Oct 2020 08:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZBtOhFHe/8FkABy/8kGYQQ0Y4xIc/sUiyqpp3W1u+Y=; b=F76G6+9GdtNSrbL5YYPeiNKGspIQ75GXn+e/m7VpVq8ubvADIP8b433M1CCsSq33YrCU1hSGBK66nPbv0yGYHNxg/QC/oPkLFiLnxiQiCeYyYfPXcpZVHbwMzf/juEdiDznzdRQb8VPkdNyoNqoXEiUdnyiKog8JQXmb4GG9cJU= Received: from AM6P194CA0053.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::30) by VI1PR0802MB2367.eurprd08.prod.outlook.com (2603:10a6:800:a1::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Mon, 5 Oct 2020 15:21:04 +0000 Received: from VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::e4) by AM6P194CA0053.outlook.office365.com (2603:10a6:209:84::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.36 via Frontend Transport; Mon, 5 Oct 2020 15:21:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT016.mail.protection.outlook.com (10.152.18.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34 via Frontend Transport; Mon, 5 Oct 2020 15:21:03 +0000 Received: ("Tessian outbound 7161e0c2a082:v64"); Mon, 05 Oct 2020 15:21:03 +0000 X-CR-MTA-TID: 64aa7808 Received: from 0bdf4b19e39f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F25F04C7-EF24-4D84-BAF4-9F50AD52DA8F.1; Mon, 05 Oct 2020 15:20:58 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0bdf4b19e39f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 05 Oct 2020 15:20:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n1+Z0U2yEZgw0bhuS+cGDnaSmzJTFjxooAcu/2ExG/roCcWEuSI91v7tWfip2JTJDLj/f+GvDhI5q/1sZFLFKoD4FLvcpskGl6q27Y6cKC6340Dsi7TwxmSocogHAm0XjNeChv5/0Ob2PjOFUTFMkEwTg/dxGGEceulsGr9y5p5S9lbGOXy+b3M2DK+dcJweCmw+W6G1XB2wiw8EcY3O+vMQhqlJ61dO+voQ0nhZPPmGnkUuGz8EWKpcTm5iPszQOH1ThwBktiw8wf0xBMCluopM//YnBaskuQ3eKNIBCc0p/GV6Mpt3lv3/kdL8MMp9cPG/wOWoiUOMhzn6EbRvMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZBtOhFHe/8FkABy/8kGYQQ0Y4xIc/sUiyqpp3W1u+Y=; b=CGzegEwXrOYumUQuUG7ZmovnUbiMZPJuXTd4koTWBKoI4LrAgQdJuog2eEy+PGbLb+6s2/ktMbNBAixrteiUHIV/62MQThyuLpLuN0asWV29A+ZeneD28XZM8tSxfaSK+Ee0f4BTxX52h+P9ze7SNJcHjW+DcM1a7Q/hLn/fm2JdeDtxyHrMdMl62KmJtA3Fuk6Hu6J2eNA0MT8+hRjcOiHZpnrjR0s8xDK3Un3lAqhMxnlpVwUdFS7AJPHSskis1Ukol5gNvwi0nUtZzZbKMjuhm6ymQFNAkngAw/DYA3BSz8NHZr9ejg/s10CBhyLZHj6s3S4XS7b/W4mqYZbgeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZBtOhFHe/8FkABy/8kGYQQ0Y4xIc/sUiyqpp3W1u+Y=; b=F76G6+9GdtNSrbL5YYPeiNKGspIQ75GXn+e/m7VpVq8ubvADIP8b433M1CCsSq33YrCU1hSGBK66nPbv0yGYHNxg/QC/oPkLFiLnxiQiCeYyYfPXcpZVHbwMzf/juEdiDznzdRQb8VPkdNyoNqoXEiUdnyiKog8JQXmb4GG9cJU= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3028.eurprd08.prod.outlook.com (2603:10a6:208:5f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.37; Mon, 5 Oct 2020 15:20:57 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::900e:c64d:a006:4860]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::900e:c64d:a006:4860%6]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 15:20:57 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: JWT Secured Authorization Request (JAR): IPR Confirmation Thread-Index: AdaQTDJ082InKWCbSFmnHjj1u5M0TgAVLU6AAACgfAACoeqzIA== Date: Mon, 5 Oct 2020 15:20:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: DF6FFEC07F0C3648819C193B5A50BAAD.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [185.176.157.98] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2ff225e1-13dc-4132-da41-08d869424651 x-ms-traffictypediagnostic: AM0PR08MB3028:|VI1PR0802MB2367: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: xN6nWMSl//uL86BvuxzKmJqPgNAB5/DXLt4UA33859W67iuhj/bPsvNhy58vkjHiT/wBmvgttBhdIRbCKpKifrODU18Hp1dH5NC9KhImVSDJWuuqOz2ugZdHMRZVvZHXEd89PBR7/0XQNtxmUsF5XqxyLMQejf11VHiIcMqoRy4yO8l91CrYl51ZmToUzFH1H6yy/pPMO4AJ/o1tH7b8XsDei3S7axZmJ915zzZza6F3X4EUI7aQW/jANMoqtZ3qn9Slp2LDFxQOqO19IiGalkFhes6H9r9zs6834HPFT4r628NWBckkWGNGVbJDUENzhi9VYJwOSwvrnXOAm6I3gN9+NtCQKDsLUPNRb11s/S4xQAaWpikOVGyxwPaivKg3i3whiikMJZdwrfjiGjvr1w== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(136003)(39860400002)(366004)(186003)(6916009)(86362001)(5660300002)(52536014)(6506007)(53546011)(26005)(71200400001)(7696005)(45080400002)(9686003)(55016002)(8676002)(2906002)(316002)(8936002)(33656002)(83080400001)(166002)(966005)(66946007)(478600001)(66476007)(66556008)(64756008)(66446008)(76116006)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SE014hL3U7JbtVxI+l7mvF8fFWateldXMOpYMqILBHDbN6HDIpNnL6zXmesKlWK0J3AN6kvRQHDU5/cBQ+8ocqxZrvvtpYhMb5EbccM+bxGM4ropsLcR3atZRZG0uH/xdqyErxiAyYTp8pifHgAltoz/EBAueGp/G+llU/triBSBA7itwO95ChWleQxtxmXhBq2Lslub43TI5KGtdEpHXO3297HT23tBBGbI8lne5TdmC8sve5/5hog8fLLBcUdvRgObuxZlG4oOUt6aBOE6dS9pIVF6a6ES/TsTE6YQqB/GPkdZ1PpHpUuBEJpVklp0CPQc2R/SIp4QMlECEdQzTLxiQ2eUDzXtpNi5vl29IxLqgblIQmpykqpSt0Isws2MMFLC2tiIaHlPoBMSJgQrG5nLLmAcoNI9L52P3Zf0xQkyIpdnTX0BvelqbSP6w9CxeTtDbATcxms9J7oV0CjZGHYsuW7OmQ2ztL8qaHVW/HrwaUhT4F7wk/oLTAIhpzKyefqyoOohrZxLjD47Mtpz82F+facjSw1CXELGEK7zTrlJeBCYexMPxRzwc5RWJVWQfVUqIibs6PSTKeSdmWa9umRX9VNiEWkaIrh6m2Byne5JhVTcDtf4nguINzgo/r/ZxelwlWND24apEgyc9EYPug== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716727A0CF8A09C3B27BB9EFA0C0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3028 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: a71039f0-a481-467c-517d-08d869424290 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FyRVEogIyLXOs0UbbjHdJ40KegA98dN0KWDypHogRVg8/IawxHNe8bXVI4/uqkdTX9CSW29i+ZbaXuoTND4urpbGBI4JYzgJt25tYMmuc+ktsQg7W62BgJxZu6H1ZoN+77Rv8DkoKSAr6U6JejO2kpGi8gsVhOq+v+iRvP2b1rzShC+AW8li8ArrwOCLU2XbgM/tf84M2ilFnFRx79513u8dUvFVIB8/Ft0VvHI1+yCak71+LLYAjQEVzyGRaArsM690Hs0boGhmbJP0Z6eiNbvW1qArWjX8dVp43GgovuZA132633iIdMpgLhJtM5fK9aaiy5vCPLstcC7kGEzsfTAskD9wWnSPzABzgQE58TvvlLNdjAWWY+xhPU1iuviL4M0ods16p+RtxaX+gsIKy9ik+sBQ/XyZsth6uPlPWNH4/uRyMS8PDidDUvYeAI84wkKkAjUgWWOol6OAUoc8Xv+IzGKTdR1OyppNEGXIHf4= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(46966005)(83080400001)(966005)(186003)(82740400003)(81166007)(2906002)(70586007)(47076004)(70206006)(478600001)(7696005)(33656002)(316002)(53546011)(36906005)(336012)(83380400001)(86362001)(5660300002)(166002)(52536014)(356005)(8936002)(6916009)(8676002)(33964004)(45080400002)(6506007)(26005)(82310400003)(9686003)(55016002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2020 15:21:03.9973 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2ff225e1-13dc-4132-da41-08d869424651 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2367 Archived-At: Subject: [OAUTH-WG] FW: JWT Secured Authorization Request (JAR): IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 15:21:10 -0000 --_000_AM0PR08MB3716727A0CF8A09C3B27BB9EFA0C0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJOiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBlbWFpbCBtYWRlIGl0IHRvIHRoZSBtYWls aW5nIGxpc3QNCg0KRnJvbTogTmF0IFNha2ltdXJhIDxuYXRAbmF0LmNvbnN1bHRpbmc+DQpTZW50 OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMjAgNzo0NCBBTQ0KVG86IEpvaG4gQnJhZGxleSA8 dmU3anRiQHZlN2p0Yi5jb20+DQpDYzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBv YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24gUmVx dWVzdCAoSkFSKTogSVBSIENvbmZpcm1hdGlvbg0KDQpJIGtub3cgb2Ygbm8gSVBSLCBhbmQgbWFr ZSB0aGUgcmVxdWlyZWQgY29udHJpYnV0aW9ucyBhZ2Fpbi4NCg0KDQpPbiBUdWUsIFNlcCAyMiwg MjAyMCBhdCAyOjI1IFBNIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJIGtub3cgb2Ygbm8gSVBSLCBhbmQgbWFrZSB0aGUg cmVxdWlyZWQgY29udHJpYnV0aW9ucyBhZ2Fpbi4NCk9uIE1vbiwgU2VwIDIxLCAyMDIwLCA0OjIy IFBNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIaSBNaWtlLCBOYXQsIEpvaG4sDQoN CkkgYW0gdXBkYXRpbmcgdGhlIHNoZXBoZXJkIHdyaXRldXAgZm9yIHRoZSAiVGhlIE9BdXRoIDIu MCBBdXRob3JpemF0aW9uIEZyYW1ld29yazogSldUIFNlY3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1 ZXN0IChKQVIpIiBzcGVjaWZpY2F0aW9uLCBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMC50eHQsIGFuZCBnaXZlbiB0aGUgY2hhbmdlcyBJIG5l ZWQgeW91ciBJUFIgY29uZmlybWF0aW9uIGFnYWluLiAoTWlrZSBqb2luZWQgYXMgY28tYXV0aG9y IGxhdGVyIGFuZCBoZW5jZSBJIG5lZWQgaGlzIGNvbmZpcm1hdGlvbiBhbnl3YXkuKQ0KDQpPbmUg aXRlbSBpbiB0aGUgdGVtcGxhdGUgcmVxdWlyZXMgbWUgdG8gaW5kaWNhdGUgd2hldGhlciBlYWNo IGRvY3VtZW50IGF1dGhvciBoYXMgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwgYXBwcm9wcmlh dGUgSVBSIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl IHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5IGJlZW4gZmlsZWQu DQoNCkNvdWxkIHlvdSBwbGVhc2UgY29uZmlybT8NCg0KQ2lhbw0KSGFubmVzDQoNCg0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQoNCi0tDQpOYXQgU2FraW11cmENCk5B VC5Db25zdWx0aW5nIExMQw0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM0PR08MB3716727A0CF8A09C3B27BB9EFA0C0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZZSTogSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgZW1haWwgbWFkZSBp dCB0byB0aGUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBOYXQgU2FraW11cmEgJmx0O25hdEBuYXQuY29u c3VsdGluZyZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAy MCA3OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb20mZ3Q7OyBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSldUIFNl Y3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpOiBJUFIgQ29uZmlybWF0aW9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkga25vdyBvZiBubyBJUFIsIGFuZCBt YWtlIHRoZSByZXF1aXJlZCBjb250cmlidXRpb25zIGFnYWluLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDoxLjVwdDtvdXRsaW5lOm5vbmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgU2VwIDIyLCAyMDIwIGF0IDI6MjUgUE0gSm9obiBCcmFk bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SSBrbm93IG9mIG5vIElQUiwgYW5kIG1ha2UgdGhlIHJlcXVpcmVkIGNvbnRyaWJ1dGlv bnMgYWdhaW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1vbiwgU2VwIDIxLCAyMDIwLCA0OjIyIFBNIEhhbm5lcyBUc2Nob2Zlbmln ICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1pa2Us IE5hdCwgSm9obiw8YnI+DQo8YnI+DQpJIGFtIHVwZGF0aW5nIHRoZSBzaGVwaGVyZCB3cml0ZXVw IGZvciB0aGUgJnF1b3Q7VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yazogSldU IFNlY3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpJnF1b3Q7IHNwZWNpZmljYXRpb24s IHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRo LWp3c3JlcS0zMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMzAudHh0PC9hPiwgYW5kIGdpdmVuIHRoZSBjaGFu Z2VzIEkgbmVlZCB5b3VyIElQUiBjb25maXJtYXRpb24gYWdhaW4uIChNaWtlIGpvaW5lZCBhcyBj by1hdXRob3IgbGF0ZXIgYW5kIGhlbmNlIEkgbmVlZCBoaXMgY29uZmlybWF0aW9uIGFueXdheS4p PGJyPg0KPGJyPg0KT25lIGl0ZW0gaW4gdGhlIHRlbXBsYXRlIHJlcXVpcmVzIG1lIHRvIGluZGlj YXRlIHdoZXRoZXIgZWFjaCBkb2N1bWVudCBhdXRob3IgaGFzIGNvbmZpcm1lZCB0aGF0IGFueSBh bmQgYWxsIGFwcHJvcHJpYXRlIElQUiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5IGhhdmUgYWxy ZWFkeSBiZWVuIGZpbGVkLjxicj4NCjxicj4NCkNvdWxkIHlvdSBwbGVhc2UgY29uZmlybT88YnI+ DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzPGJyPg0KPGJyPg0KPGJyPg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TmF0IFNha2ltdXJhPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TkFULkNvbnN1bHRpbmcgTExDPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQog b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB3716727A0CF8A09C3B27BB9EFA0C0AM0PR08MB3716eurp_-- From nobody Mon Oct 5 08:35:20 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBA3A07F9; Mon, 5 Oct 2020 08:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <160191211588.32472.13236025465527336357@ietfa.amsl.com> Date: Mon, 05 Oct 2020 08:35:15 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 15:35:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-16.txt Pages : 50 Date : 2020-10-05 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There is also an HTML version available at: https://www.ietf.org/id/draft-ietf-oauth-security-topics-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 5 10:39:33 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A033A0E91; Mon, 5 Oct 2020 10:39:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160191956813.27022.10685901002598920092@ietfa.amsl.com> Date: Mon, 05 Oct 2020 10:39:28 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 17:39:28 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/Toronto (17:00 to 18:00 UTC). Agenda: 1. High level overview of anti-tracking and the IsLoggedIn & WebID initiatives 2. Impact on the OAuth WG work 3. Proposal for a WG position on these initiatives. 4. Discussion Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7e21c550ab77d0da08845741bb0b2a0c From nobody Mon Oct 5 11:09:01 2020 Return-Path: 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 03CF43A0F4B for ; Mon, 5 Oct 2020 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 ITLPm3ujCgc0 for ; Mon, 5 Oct 2020 11:08:58 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 D20813A0F46 for ; Mon, 5 Oct 2020 11:08:57 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 13so446405wmf.0 for ; Mon, 05 Oct 2020 11:08:57 -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; bh=vg7S5ccR4MXiP2AH5AleQSKQwBxUeXdw7SWCdsLoebA=; b=gI+Tn5n7hE5fPPWt2Shwe+U9YDhkgYw5AjHI80uvYlHw9n3yFtztYzpXnqj/ULonTY f6cCo5fl84536+pt9sEVCnAiWOe5iXg8gfvR2ydFJjqopqN16KZbTggFpeTkPRCDel4a rDEPBQialuWxu5pZU6w2JpesCBO8CNYk/LjPfO9YzJpLx4DOAxKhyEVHzE4m8ax5Gk6d y54UhCfaOEYRnpruRu//ClEZwL4JmTWQoj4aNLIYTmcko3d1NblKyDx53eUZw94OjyN8 /uLeGlacavfPTn9uuNSkiLhh8UYDE01MoOGF4NU1+KlsJy0w8Vd3JDEOaIwNI0vPVm8Y VSQw== 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; bh=vg7S5ccR4MXiP2AH5AleQSKQwBxUeXdw7SWCdsLoebA=; b=TyGN6eRisf1w5h2YCMpgZfMfGM9BPvhevTV40I+x4OBB1Fj20FIi1FNyg02ywWOke3 am7lBXt6b7fvLHDVjHaPQm1eo2C4FdeQkFZjAmHAxuU8iY3DwyEJKVGYGEv8CUwUIXfn xtio8n+ZG0ILOhE7j5Vt1dShQVioYjnqhTjjflRpqXpqxu3k4t/agtSTledpq0sOMpEG F9JOmqopJ5iAvjqHW9tuHLLB4EGjnWw4r+vDPlHLT/qaMTdxHmJ7fakm0NgrjbMuIzC2 DtL9FJhIDWXU+LLcH750YaOZh/WpVIIRebhzDOmRhuNzZFviobabVHjzhQJi2LclLCY7 ouIg== X-Gm-Message-State: AOAM530kAZW86FAudkjAqK68uEbHnJR7/zf4XImDknM4ZGl6cc6V/Paz IgJBqCm98DjlZkmtlvGXcZNnJI++G5moK8WY6YQGt1daCkc= X-Google-Smtp-Source: ABdhPJyDyENAg1B6uDFq6GPsVcoysFPzh8llsgQzxTloSrd6sM7y2dc9yONR6NjqJV9PctDYNQ9nPUEhNAUR4ZmTyIA= X-Received: by 2002:a1c:40d5:: with SMTP id n204mr601874wma.148.1601921335816; Mon, 05 Oct 2020 11:08:55 -0700 (PDT) MIME-Version: 1.0 References: <1472915592.3292331601918508022.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <1472915592.3292331601918508022.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Mon, 5 Oct 2020 14:08:44 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000002e0cf805b0f060c9" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - IsLoggedIn & WebID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 18:09:00 -0000 --0000000000002e0cf805b0f060c9 Content-Type: multipart/alternative; boundary="0000000000002e0cf605b0f060c7" --0000000000002e0cf605b0f060c7 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Mon, Oct 5, 2020 at 1:21 PM Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim - IsLoggedIn & WebID To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 171 344 4160 Meeting password: V3BcTMb85DM Monday, November 2, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,1713444160## <%2B1-650-479-3208,,*01*1713444160%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 1713444160@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 1713444160.ietf@lync.webex.com Need help? Go to http://help.webex.com --0000000000002e0cf605b0f060c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Mon, Oct 5, 2020 at 1:21 PM
S= ubject: (Forward to others) Webex meeting invitation: OAuth WG Interim - Is= LoggedIn & WebID
To: <o= auth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 171 344 4160
Meeting password: V3BcTMb85DM
=C2= =A0
Monday, November 2, 2020
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to join from a mobile device = (attendees only)
+1-650-4= 79-3208,,1713444160## Call-in toll number (US/Canada)
=C2=A0
<= tr style=3D"margin:0px">=
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
Global call-in numbers
=C2=A0
Join from a video system or appli= cation
Dial 1713444160@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 1713444160.ietf@lync.webex.com
=C2= =A0
=09
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--0000000000002e0cf605b0f060c7 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20201005T172147Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20201102T120000 DTEND;TZID=3DAmerica/New_York:20201102T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741= bb0b2a0c TRANSP:OPAQUE SEQUENCE:1601918507 UID:f86f03b4-5131-4667-8366-f80d0b8e461d DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dm7e21c550ab77d0da08845741bb0b2a0c\nMeeting number (access code): 171 = 344 4160\n\nMeeting password: V3BcTMb85DM\n\n\n\nTAP TO JOIN FROM A MOBILE = DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1713444160## tel:%2B1-650-479-320= 8,,*01*1713444160%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PH= ONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbe= rs\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm934ca9018452379939= 3715a0b4fa22c1\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:17134= 44160@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting= number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDi= al sip:1713444160.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nh= ttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NOTI= CE: Please note that this Webex service allows audio and other information = sent during the session to be recorded, which may be discoverable in a lega= l matter. By joining this session, you automatically consent to such record= ings. If you do not consent to being recorded, discuss your concerns with t= he host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n \n \n
 
\n \n\n\n\n\n\n = \n \n \n \n \n \n \n
\n When it's time, join the Webex meeting here.\n \n
 
\n Meeting number (access code): 171 344 4160\n =
\n
Meeting password:V3BcTMb85DM
\n= \n \n \n \n \n \n
 
\n \n \n= \n
Join meeting<= /td>\n
\n
\n\n \n 
 
\n\n 
= Tap to join from a mobile device (attendees only)  
+1-650-479-3208,,171= 3444160## Call-in toll number (US/Canada) 

J= oin by phone  
1-650-479-3208 Call-in toll number (US/Canada)  
Global call-in numbe= rs 


\n\n
 
\n\nJoin from a v= ideo system or application
Dial 1713444160@ietf.webex.com 
You can also= dial 173.243.2.68 and enter your meeting number.  
=  
\n\n
Join using Microsoft Lync or Microsoft Skype for Busine= ss
Dial 1713444160.ietf@lync.webex.com
\n\n
 
\n= \n\n \n = \n \n = \n \n \n
 
Need help? Go to http://help.webex.com\n =
 =
\n
\n SUMMARY:OAuth WG Interim - IsLoggedIn & WebID PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --0000000000002e0cf605b0f060c7-- --0000000000002e0cf805b0f060c9 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <174f9f34901c1ce7aee1> X-Attachment-Id: 174f9f34901c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAxMDA1 VDE3MjE0N1oNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMTEwMlQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMTEwMlQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW03ZTIxYzU1MGFiNzdkMGRhMDg4NDU3NDFiYjBiMmEwYw0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTYwMTkxODUwNw0KVUlEOmY4NmYwM2I0LTUxMzEtNDY2Ny04MzY2LWY4MGQw YjhlNDYxZA0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW03ZTIxYzU1MGFiNzdkMGRhMDg4NDU3NDFi YjBiMmEwY1xuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTcxIDM0NCA0MTYwXG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IFYzQmNUTWI4NURNXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9C SUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDE3MTM0NDQxNjAj IyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxNzEzNDQ0MTYwJTIzJTIzKjAxKiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMy MDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbiBudW1i ZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW05 MzRjYTkwMTg0NTIzNzk5MzkzNzE1YTBiNGZhMjJjMVxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTcxMzQ0NDE2MEBpZXRmLndlYmV4LmNvbVxu WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTcxMzQ0NDE2MC5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5 b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9y ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNw YWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9u dC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7 XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRo OiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1l ZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJ Zm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAh aW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJ d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1c bgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFp bXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5 bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4 OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8 Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1l LCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFj Y2VzcyBjb2RlKTogMTcxIDM0NCA0MTYwPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5WM0JjVE1iODVETTwvRk9OVD48 L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNB OTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tN2UyMWM1NTBhYjc3ZDBkYTA4ODQ1NzQxYmIwYjJhMGMi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0i I0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9 IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k ZWVzIG9ubHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMzQ0 NDE2MCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5v bmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7 Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTM0NDQxNjAjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bTkzNGNhOTAxODQ1MjM3OTkzOTM3MTVhMGI0ZmEyMmMxIiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0g b3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE3MTM0NDQxNjBAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+MTcxMzQ0 NDE2MEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDoxNzEzNDQ0MTYwLmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTM0NDQxNjAuaWV0ZkBs eW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCTx0YWJsZT48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcy cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdo dDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8v aGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAg ICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0 aCBXRyBJbnRlcmltIC0gSXNMb2dnZWRJbiAmIFdlYklEDQpQUklPUklUWTo1DQpDTEFTUzpQVUJM SUMNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBU SU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --0000000000002e0cf805b0f060c9-- From nobody Tue Oct 6 05:17:09 2020 Return-Path: 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 499EC3A1449 for ; Tue, 6 Oct 2020 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 s44NCTL_hPZJ for ; Tue, 6 Oct 2020 05:17:05 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 678573A1448 for ; Tue, 6 Oct 2020 05:17:05 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id n142so5616821ybf.7 for ; Tue, 06 Oct 2020 05:17:05 -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; bh=bRUSJY3j2SsooMoIDs14IOynOO15tKoQ4oVDiTjKTlk=; b=hqU+BzHM5JQlPQj2Jj6L2J1w8s122GEsEvMvpO0+MxxodAGb6jTfmb0+O9ZVdatsZ9 hsqPFfrV9AORrJDXDJbfoejT1Pi1+L27NiWUIB3zrnZs6+/qObNbOCyc7aAjDFQeWvxZ XAL8mca3l/P5fwYCfMU7MoboKiVUo5WD7ziCAsafeAVYreDrYktmhkQthxbPNAJjov44 QrL5/dm63rfgdd/Z5FUygy798k5LEgpyQP9nz8Cc+0V71YVNUm6kSluLer0n5Tp0R+AL qRXbdhJBupP1w2lhtg4eTMVla9aLilBmhEru20M8LrU/3W73uhxriOYESV4NYEg+1oau +s9g== 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=bRUSJY3j2SsooMoIDs14IOynOO15tKoQ4oVDiTjKTlk=; b=QWIq2yRhnPFUp2UXWxse63QnYfGD86TcXex674+fIY2YBe6TD7HwiPHwhtNg+S9FC9 3A1kXtaBX/4uzcmm9T/m2CZQMORmsaHk+ktk7XGwsAmfD50nswo1qzr6AFIU/CbtYaCa nSBifAovVsiggdH3awQbgGjvklYxUsHZMmQBeQgvq0f7lFQbMbfLYN+QchqrcUtNCz2U /F84AATNK5XtAeE2oVm+d3JizGNKj+jg1EF/yNL6GPd+O0RrP9hfsJuBR2AnjgyaiHiH 84iurTPXvOdkB4c66Q3KaSy9XObe48B01sQLhROKCSBMGF6GetQsQ2AOcSqnk/B6PRqx /czg== X-Gm-Message-State: AOAM533/XYhnZ1aNwyaoRXBI/VHM1ZDgUZCpIkCa0CaEZu2QdD5Oj2oF B2FZ6He4LpIOAb4Fmo7uWKe6XijKewBYTbzAiz/+cP/M9kI= X-Google-Smtp-Source: ABdhPJyyT51b+xUlwhjqm1/apBYT+6mE+PdYYTMnnlDa3iWFR2lIT2uMpcG2+Uki2/XUYpnamKSzZtAhKtuHaIF7BlM= X-Received: by 2002:a25:7314:: with SMTP id o20mr5771464ybc.211.1601986624268; Tue, 06 Oct 2020 05:17:04 -0700 (PDT) MIME-Version: 1.0 References: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> In-Reply-To: From: Thomas Broyer Date: Tue, 6 Oct 2020 14:16:53 +0200 Message-ID: To: Nicolas Mora Cc: "" Content-Type: multipart/alternative; boundary="000000000000acaeed05b0ff9314" Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 12:17:07 -0000 --000000000000acaeed05b0ff9314 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora wrote: > Hello, > > Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > > > There might be some kind of pushed events between the AS and the RS > when > > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at > all. > > Like this, the RS knows if a JWT AT has been revoked or not. > > > > > > If there are some kind of pushed events between the AS and the RS, then > > it could push the revoked (and/or expired) opaque AT too, giving almost > > no advantage to JWT ATs. > > > Not necessarily, let's say the AS informs the RS only of the revoked > ATs, when a RS checks an AT, it verifies the signature first, then the > claims, then checks if the AT has been revoked by checking its internal > list filled by the AS pushed events. > Well, you were the one saying that =E2=80=9Cthe advantage of using a JWT AT= is close to 0=E2=80=9D =F0=9F=98=89 (and I was the one bringing the advantage of being able to do some verifications prior to contacting the introspection endpoint, btw) In any case, for an opaque AT, you only get to introspect it once to know its expiration (and you can cache the result); so those preliminary checks you can do with a JWT only save you one introspection request IFF the token is not valid, e.g. expired; if it's valid or has been revoked, then you'll have to introspect it anyway. And if you imagine that "pushed events" mechanism, then it would work the same for an opaque AT or a JWT AT, saving you the introspection requests that would otherwise be mandatory for checking revocation. So (and I know it wasn't the original subject of the discussion), a JWT AT can save you, compared to an opaque AT: * a call to the userinfo endpoint if it embeds the claims you need * a call to the introspection endpoint if it's expired or otherwise invalid, and/or some memory/storage space that you could use as a cache for that information for an opaque AT (to avoid issuing other introspection requests, as an optimization / compromise) --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --000000000000acaeed05b0ff9314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 4, 2020 at 6:55 PM Nicola= s Mora <nicolas@babelouest.org= > wrote:
= Hello,

Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit=C2=A0:

>=C2=A0 =C2=A0 =C2=A0There might be some kind of pushed events between t= he AS and the RS when
>=C2=A0 =C2=A0 =C2=A0a JWT AT is revoked, to allow the RS not to introsp= ect a JWT AT at all.
>=C2=A0 =C2=A0 =C2=A0Like this, the RS knows if a JWT AT has been revoke= d or not.
>
>
> If there are some kind of pushed events between the AS and the RS, the= n
> it could push the revoked (and/or expired) opaque AT too, giving almos= t
> no advantage to JWT ATs.
>
Not necessarily, let's say the AS informs the RS only of the revoked ATs, when a RS checks an AT, it verifies the signature first, then the
claims, then checks if the AT has been revoked by checking its internal
list filled by the AS pushed events.

We= ll, you were the one saying that =E2=80=9Cthe advantage of using a JWT AT i= s close to 0=E2=80=9D=C2=A0=F0=9F=98=89
(and I was the one bringi= ng the advantage of being able to do some verifications prior to contacting= the introspection=C2=A0endpoint, btw)
In any case, for an opaque= AT, you only get to introspect it once to know its expiration (and you can= cache the result); so those preliminary checks you can do with a JWT only = save you one introspection request IFF the token is not valid, e.g. expired= ; if it's valid or has been revoked, then you'll have to introspect= it anyway.
And if you imagine that "pushed events" mec= hanism, then it would work the same for an opaque AT or a JWT AT, saving yo= u the introspection requests that=C2=A0would otherwise be mandatory for che= cking revocation.

So (and I know it wasn't the= original subject of the discussion), a JWT AT can save you, compared to an= opaque AT:
=C2=A0* a call to the userinfo endpoint if it embeds = the claims you need
=C2=A0* a call to the introspection endpoint = if it's expired or otherwise invalid, and/or some memory/storage space = that you could use as a cache for that information for an opaque AT (to avo= id issuing other introspection requests, as an optimization / compromise)

--
= Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--000000000000acaeed05b0ff9314-- From nobody Tue Oct 6 07:17:50 2020 Return-Path: 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 164F03A0A0B for ; Tue, 6 Oct 2020 07:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZbayvnHCd22R for ; Tue, 6 Oct 2020 07:17:47 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 3D70A3A0A08 for ; Tue, 6 Oct 2020 07:17:47 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u6so13158767iow.9 for ; Tue, 06 Oct 2020 07:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JqdOYd7N3mAD+yjXZS75V8zMBk7hsIzKLXD6wjCQA+k=; b=ZdeGmmi+SOqxarDh9q8md5hp1oFDQQ1KwCNV+GEwYgjlPWeaoyJ/E7MOa6HeUpqNv0 w1TE4rOecorcMclbHXm3nP6jGEtD+zeRPWNuOhlj7qk6zL+4S0Sla+O28njDyMCK08vr d9vD+WwFDajXkFrNolQqvxE8Ojptk9SEC51FOTM1+iBu5zWyzKZ29kbytLNz/usmO9r4 tlpWKojIwCcIq4pUyHvo7c10vfj3azy4cZPTf1HdcpHFQyH3VCCdJQrE1Kz0A8p2TtHg /BLRXTSJ7OHU5UWLM3yTPRQR1sHWnoX0NL2YFI6aPk/heSP8LpAcMpFMGn1BZ7tYbP9w wfqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JqdOYd7N3mAD+yjXZS75V8zMBk7hsIzKLXD6wjCQA+k=; b=FVagNhs+v7TZ8X4B/4M4ppe55v4KlKZfAu67oi8gdqr0JHON8EmYPLcGatHZM9lgbi CHqJVuMh8PVH1DBQhYva8VoCZ3PlEjYOn0fGjBizVqk6T1kuK0CzGqBpIs2zL6ilhY7D 4eJarB2pOub31yUj3xbYXO+Q5Bh9Y0sqHa/XWUHFA/Znh8LROlVAUABXs+Y87WXaqyLh y4SbvNIXYwUq5xpSmcs2mzgbvAyExAhOeJsXuM47juQqAr0VplyJ0DuU3L+9TCoATI31 MhpXmbqmIyCy5r2cqagKrzlQSygxkbAuL9WZpeYHRxOz9DCKcNAHsV5RlXcpNXpZHhv7 hQ0A== X-Gm-Message-State: AOAM5316NgSnj+CKLhJlteB3oXCn0rtQBNUGmda9XLzjVMTqqXRk4kbh /IMoNMjDksOENSdec0PJmrzVChxT31MVWGlgS+YmzjJaebw= X-Google-Smtp-Source: ABdhPJyO9ntloI7NA1U8AwbHfbKVN5NoGt7eYOtnlrBW2s5dylbyejVDPMIHbNqzOLHQjJHhVhkN24UbfKmwwssND6w= X-Received: by 2002:a6b:610c:: with SMTP id v12mr1272885iob.101.1601993866123; Tue, 06 Oct 2020 07:17:46 -0700 (PDT) MIME-Version: 1.0 From: Janak Amarasena Date: Tue, 6 Oct 2020 19:47:10 +0530 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000529ff405b10143da" Archived-At: Subject: [OAUTH-WG] JSON based access token requests for OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 14:17:49 -0000 --000000000000529ff405b10143da Content-Type: text/plain; charset="UTF-8" Hi All, As per my understanding OAuth 2(RFC6749) doesn't mandate any specific media type to be used in the access token request. The spec implies application/x- www-form-urlencoded should be used. Since the media type application/json is very popular and widely used now, any thoughts on referencing the use of this as well for access token requests? Best Regards, Janak Amarasena --000000000000529ff405b10143da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

As per my understanding OAuth 2= (RFC6749) doesn't mandate any specific media type to be used in the acc= ess token request. The spec implies=C2=A0application/x-www-form-urlencoded=C2=A0should be used. Since the media type=C2=A0application/json= =C2=A0is very popular and widely used now, any thoughts on referenci= ng the use of this as well for access token requests?

<= div>Best Regards,
Janak Amarasena
--000000000000529ff405b10143da-- From nobody Tue Oct 6 07:30:04 2020 Return-Path: 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 6E5CA3A0A3E for ; Tue, 6 Oct 2020 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 j6DqVb8UTRuh for ; Tue, 6 Oct 2020 07:29:57 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6772E3A0A2D for ; Tue, 6 Oct 2020 07:29:57 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 82A4212D02 for ; Tue, 6 Oct 2020 14:29:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1601994595; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nNcIExDUq0LntdriWT/P021sTDDDzDzyGbsap5EPcyY=; b=E6gl/lgHCYRFX52yEIyrL05GYCbY3ZdJSbtI4Y6dSvX5kfT/cIJv0U9nA3PgSvgpsC1t/Y Y1Ca6jFXCXuJhZY6oajekXdeiT6hGW5Fj46H4zDFbFrLrpZcUksMj5VeY0CIsZcKgWu+TF je58KO0aYhK01j4ejc7+9vaSj5pyvXw= To: oauth@ietf.org References: <160191211588.32472.13236025465527336357@ietfa.amsl.com> From: Daniel Fett Message-ID: <2e77de06-6ec3-51f1-72c0-ce83c6b8ee0e@danielfett.de> Date: Tue, 6 Oct 2020 16:29:54 +0200 MIME-Version: 1.0 In-Reply-To: <160191211588.32472.13236025465527336357@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CFED2E622E4D6749FF556B29" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1601994595; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nNcIExDUq0LntdriWT/P021sTDDDzDzyGbsap5EPcyY=; b=DNhWxkNbXZ8/xaDQm3CZwZu/YUCJiXkaQTSc3FT/15MZTq/HhIqRgu8A+T/ssUrTGnJ2F8 MR8zKMlcitWd/z8cAcEOylDb972evg2JO3h/rk5gst30xHxYPO8NlQGB8J1kXJE7h3Uv+9 YJCeVbW0UMdR134n1qV+IKafYo2lCLA= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1601994595; a=rsa-sha256; cv=none; b=EZhCEYrk68mmMy7lP/hxZ0q6Se/JjalpnsfSb0p8Zer6+KzQgMgUuukh5RhesM2oIuwWQX JVvpt5XNcp2SsF11x6fec4xfw7GDY0OX0BAP7sGxi7n34yOLqoqPTzMLqRplc2Fd75ZTgo tmNmMCbQdIP9IiJUzNUy5hwJ77p+IRI= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 14:30:04 -0000 This is a multi-part message in MIME format. --------------CFED2E622E4D6749FF556B29 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, the most important changes for this version are as follows: * New advice: For public clients, nonce is not sufficient to protect against authorization code injection. PKCE is now a MUST for public clients. * We have refined the guidance on using nonce for code injection protection, for example if multiple ID tokens are returned ("response_type=code id_token"). * The draft now covers the PKCE Downgrade Attack and countermeasures. Authorization servers MUST follow special rules when allowing non-PKCE and PKCE flows for the same client. * Native apps with a "localhost" redirect URI can be exempt from exact redirect URI matching: Port numbers may differ, as in RFC8252, Section 7.3. * And finally, some clarifications on refresh token sender-constraining and mTLS. -Daniel Am 05.10.20 um 17:35 schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename : draft-ietf-oauth-security-topics-16.txt > Pages : 50 > Date : 2020-10-05 > > Abstract: > This document describes best current security practice for OAuth 2.0. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and covers new threats relevant due to the broader > application of OAuth 2.0. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > > There is also an HTML version available at: > https://www.ietf.org/id/draft-ietf-oauth-security-topics-16.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de --------------CFED2E622E4D6749FF556B29 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all,

the most important changes for this version are as follows:
  • New advice: For public clients, nonce is not sufficient to protect against authorization code injection. PKCE is now a MUST for public clients.
  • We have refined the guidance on using nonce for code injection protection, for example if multiple ID tokens are returned ("response_type=code id_token").
  • The draft now covers the PKCE Downgrade Attack and countermeasures. Authorization servers MUST follow special rules when allowing non-PKCE and PKCE flows for the same client.
  • Native apps with a "localhost" redirect URI can be exempt from exact redirect URI matching: Port numbers may differ, as in RFC8252, Section 7.3.
  • And finally, some clarifications on refresh token sender-constraining and mTLS.

-Daniel


Am 05.10.20 um 17:35 schrieb internet-drafts@ietf.org:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Security Best Current Practice
        Authors         : Torsten Lodderstedt
                          John Bradley
                          Andrey Labunets
                          Daniel Fett
	Filename        : draft-ietf-oauth-security-topics-16.txt
	Pages           : 50
	Date            : 2020-10-05

Abstract:
   This document describes best current security practice for OAuth 2.0.
   It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and covers new threats relevant due to the broader
   application of OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There is also an HTML version available at:
https://www.ietf.org/id/draft-ietf-oauth-security-topics-16.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



-- 
https://danielfett.de
--------------CFED2E622E4D6749FF556B29-- From nobody Tue Oct 6 08:10:29 2020 Return-Path: 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 5CB933A0AD0 for ; Tue, 6 Oct 2020 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 ax_A1JEftaBh for ; Tue, 6 Oct 2020 08:10:27 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 E05FE3A0AC8 for ; Tue, 6 Oct 2020 08:10:26 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id g7so13342709iov.13 for ; Tue, 06 Oct 2020 08:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9xOCuRz1+cqel5NMeNnwc4TCyiaRhASQtu9sZdOsjxw=; b=TwvXnroOm39WAT3wKkpOrYdzxhx20txsWQ9CA1FvyYT9wUUeT5gr5dxwelm3V/KIrd YHTk1O/HFgLrKbkYx8B/rf8KB48iuQy68xCLKWBG3FObmvQ3m2OzHTMC84gbTCYsImXU qb6kYLwCFPyryp/kY0Z3+imHS86e2ynTpuOfHYZbLgsTPUicrVQa7l26sYCV4nFOx9Gm qF1prQcq69V7ESJjwTgp6uz9zJCTUG114lk+/u/x1U9G0n94/daRbcKgE8tT/MgHmYUF /iN78LO7ET8WngRAWDysPMCSszjcZezwtlNGv9geguk+nUzJCamw10thLrNiShzHrE69 l1Wg== 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=9xOCuRz1+cqel5NMeNnwc4TCyiaRhASQtu9sZdOsjxw=; b=fD+/qqvG13ErlO89z14ohm09HRmUecD3v8LId/rwchY9phTCn+hhgXYIaCqUl1mdf+ 6Yc7qSaZiZcQomIf8SC4TMlr+AnV906L07CwrVy2yyfCOYjUYLrf7leQZIpAIvT4U5dY GIfMK1w2iksgP/53ivqs41hP8TKfs1DOieZ/dhNeGT7b5mrsrg5XhldgdKitHPLyAXDn 1Gt8D572S+rLOUr8gGm+TJal8LRdtNWWiF0ENn+Le2/iT76Y7dUt0jfeTr30FAgQqxKp cQs150J9UThRSdac5/0oKAdfewr6mSpyA3Cz7xuvyuz8Me1XtUtz3MRGNpkzHkbrn+l5 DpRw== X-Gm-Message-State: AOAM533UZPEuXQT4yIecG/y4PzWn/iiwnSRxrss5HuQ9A36Z6V9pIbc+ p3ZN0G7UUuvb5/jQc6IpPQiZsALrGNS5Cg== X-Google-Smtp-Source: ABdhPJwTc3sowe1+bAckIf5TVIK9O7k3ZIAsWqcZr5NW+/Wm+za/a6UFRd5criUY6xnGor8nAgudyA== X-Received: by 2002:a5d:8b4c:: with SMTP id c12mr1477654iot.167.1601997025378; Tue, 06 Oct 2020 08:10:25 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id t26sm1596377ioi.11.2020.10.06.08.10.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 08:10:24 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id m17so13397529ioo.1 for ; Tue, 06 Oct 2020 08:10:24 -0700 (PDT) X-Received: by 2002:a02:605c:: with SMTP id d28mr1656704jaf.12.1601997024254; Tue, 06 Oct 2020 08:10:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 6 Oct 2020 08:10:13 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Janak Amarasena Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008fe64e05b101fff5" Archived-At: Subject: Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 15:10:28 -0000 --0000000000008fe64e05b101fff5 Content-Type: text/plain; charset="UTF-8" The spec does clearly require form-encoded POST requests to the token endpoint, it's not just an implication. The requests made include simple key/value pairs so there's nothing really gained by making this a JSON post. Changing that at this point would be a drastic breaking change to pretty much all existing code for very little benefit if any. That said, Justin Richer did already write up a draft exploring this topic, but it hasn't shown much interest in the group yet. https://www.ietf.org/id/draft-richer-oauth-json-request-00.html Aaron On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasena wrote: > Hi All, > > As per my understanding OAuth 2(RFC6749) doesn't mandate any specific > media type to be used in the access token request. The spec implies > application/x-www-form-urlencoded should be used. Since the media type > application/json is very popular and widely used now, any thoughts on > referencing the use of this as well for access token requests? > > Best Regards, > Janak Amarasena > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --- Aaron Parecki https://aaronparecki.com --0000000000008fe64e05b101fff5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The spec does clearly require form-encoded POST requests = to the token endpoint, it's not just an implication. The requests made = include simple key/value pairs so there's nothing really gained by maki= ng this a JSON post. Changing that at this point would be a drastic breakin= g change to pretty much all existing code for very little benefit if any.

That said, Justin Richer = did already write up a draft exploring this topic, but it hasn't shown = much interest in the group yet.

Aaron

=





On Tue, Oct 6, 2020 at 7:18 AM Ja= nak Amarasena <janakama360@gmai= l.com> wrote:
Hi All,
As per my understanding OAuth 2(RFC6749) doesn't mandat= e any specific media type to be used in the access token request. The spec = implies=C2=A0application/x-www-form-urlencoded=C2=A0sho= uld be used. Since the media type=C2=A0application/json=C2=A0is very popular and wid= ely used now, any thoughts on referencing the use of this as well for acces= s token requests?

Best Regards,
Janak Am= arasena
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
---
Aaron Par= ecki

--0000000000008fe64e05b101fff5-- From nobody Tue Oct 6 14:22:04 2020 Return-Path: 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 3BF433A14F5 for ; Tue, 6 Oct 2020 14:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=auth0.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 B9DA2IEFB7S5 for ; Tue, 6 Oct 2020 14:22:01 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 056943A14F4 for ; Tue, 6 Oct 2020 14:22:00 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id i3so2244142pjz.4 for ; Tue, 06 Oct 2020 14:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=batBHv46hE4rzVBMIpRLmrHpMD7C8aJMELPHeG7p3pA=; b=McAeCF+9t96WgcE43HtIxxvT4T+grZGOsE2IxPXT8oIsL4wu7DhLwQJky1zntd5SLz g0GKtBsnpl33TD6dsOgG7724FoTuA5nNopZVr+zOMpFJJa2+C71QBfEqKhfmzpqsqCz3 qtPko0QN24q7rKJ850fw872DB6UGf1DbkAfY9U7OPrCvB9W/MymdPHjN3VOuRutNVxk4 KKa/wxwuJTy8a9xS1phCpgPW3VDmmcNmZ4Rsbo7076BtDMFNQcFrPEI1uw4z+m91m4OO 5jbQn4j4D94WqAcQo8Uc/We/cfzxcPyHL4wHX52ezFTu6o4rKqQwMaSW+3pMe0S6g/WW T3/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=batBHv46hE4rzVBMIpRLmrHpMD7C8aJMELPHeG7p3pA=; b=fiSinDkmioWjdfUr6mI+XO+iome842uYi2c1+Z8aYC8UZUQlTcUbxEsvzyEGcHQstL rbpZsrCSIflCkOAuMpKBF5XfydT+e4IStMSH0FArWGonyIQ3af2A0CoOjhyvrmIBZo9n uQ0i6X41PisyF4LCKEhKAaPGLqvxykDxvuYEKX2ZcBpFttLE6y9a/siodaq53EWpD5sX 4tBfn1rNJQxtGjIG3kVyN8RzgBY8tAJTSnDzdYkwtuZvs8bDA4TrB75bOBnRfP4fdOCn vkGCoO0TDtJqHuhiJtjJuYwMYvmkYjrAli5HGJ/uz6uxaDOe9hmRCtZi0S7jgAeDJ2ir 6oAw== X-Gm-Message-State: AOAM5323fBAcdRTEI1hgt7QdG+zBC5DkzIEqAiJwhM3+qzp1yQnkBozZ Rk6ryWT/0qh3iUNiJROIKG934+ZvW63xRyt/ X-Google-Smtp-Source: ABdhPJyPElpbZ8s0dbm/bLGnSm7QEu2cQCeg6ho7YMJg52pXiq9r0EKaX2kYv3SlP31cF26W7wnp6g== X-Received: by 2002:a17:90a:f184:: with SMTP id bv4mr54428pjb.1.1602019320006; Tue, 06 Oct 2020 14:22:00 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id h12sm117262pfo.68.2020.10.06.14.21.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:21:59 -0700 (PDT) From: To: "'Jim Manico'" , "'Nicolas Mora'" Cc: References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> In-Reply-To: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> Date: Tue, 6 Oct 2020 14:21:59 -0700 Message-ID: <060901d69c26$ba2deab0$2e89c010$@auth0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOrL5PoOMmS7FkPutnv0CxOSedfQJQ4VslqQhqX5A= Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:22:02 -0000 Hey Jim, regarding > Every logout event should trigger token revocation That isn=E2=80=99t necessarily the case. An access token represents the = ability of a client to access a given resource; the fact that it = requires an authentication transaction/session establishment to be = issued to the client does not mean that the AT lifetime is tied to the = lifetime of that session. Say that I allow LinkedIn to tweet on my = behalf. Once I have done that, it doesn=E2=80=99t matter whether I stay = logged in their web app or otherwise. Even if I log out of the session = in which context I got my twitter AT, I can still post on LinkedIn from = my native LinkedIn app and the corresponding post will show up on = twitter as well. Now, one might choose to *explicitly* tie tokens lifetime to originating = sessions lifetime, see the discussion on the OpenID Connect group about = a possible online_access scope for influencing RTs and Ats (in = particular, in the context of SPAs) but that's additional semantic that = isn=E2=80=99t defined today. -----Original Message----- From: OAuth On Behalf Of Jim Manico Sent: Sunday, October 4, 2020 5:17 PM To: Nicolas Mora Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > In this model, considering that token revocations don't happen a = lot... Just a brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token revocation. I=E2=80=99m mentioning this because a lot of OAuth solutions in the = mobile space literally ignore the logout event, such as = Facebook=E2=80=99s mobile OAuth solution.=20 - Jim > On Oct 4, 2020, at 6:55 AM, Nicolas Mora = wrote: >=20 > =EF=BB=BFHello, >=20 >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : >>=20 >> There might be some kind of pushed events between the AS and the = RS when >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at = all. >> Like this, the RS knows if a JWT AT has been revoked or not. >>=20 >>=20 >> If there are some kind of pushed events between the AS and the RS,=20 >> then it could push the revoked (and/or expired) opaque AT too, giving = >> almost no advantage to JWT ATs. >>=20 > Not necessarily, let's say the AS informs the RS only of the revoked=20 > ATs, when a RS checks an AT, it verifies the signature first, then the = > claims, then checks if the AT has been revoked by checking its=20 > internal list filled by the AS pushed events. >=20 > In this model, considering that token revocations don't happen a lot,=20 > the ratio revoked AT/valid AT is very low, so the advantage of a JWT=20 > is important, because it means not so much communication between the=20 > AS and the RSs, and a very reliable AT. >=20 > But this means a communication mechanism that isn't standardized yet. >=20 > /Nicolas >=20 > _______________________________________________ > 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 From nobody Tue Oct 6 14:25:39 2020 Return-Path: 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 1173B3A14F4 for ; Tue, 6 Oct 2020 14:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 Wo86Ae8RfZiM for ; Tue, 6 Oct 2020 14:25:37 -0700 (PDT) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (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 01C7E3A10C0 for ; Tue, 6 Oct 2020 14:25:36 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id ce10so19784295ejc.5 for ; Tue, 06 Oct 2020 14:25:36 -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; bh=q9neRA53nwPRk/t42SZxz6bwiz5Uvwukilui8uXNpmw=; b=r/9e4IEqdlsRk7uu2HIyxDxDpbwQBe4b4/LIKJUtq+omkf0HcO6g5gDPcpi3WwXlt6 QqhkeAVqxn155DHl8E3lH34HGvDwNQ1cXAh0aFxRgl5Q3vm5lqEtrmOQQSCT5feAGj47 8PRY+F5PNfLsYDYBHMKB/D0qQ3Ea3WpqqmkHorf5UJ3KM8WbnNigFqWpi5JYsMZ3ErCU t2swINRw0AsQTlWfzmckh46CYF3XiE0LgLIN1wrfLzgbAGR6cXTKes98zbpeSkA7/dIs lgjSxwdyuC+u+U2J/4mAE/R19sSpmItB4UqqPqQELJeE+bMDwXwlS6JHA9DRDQx1O5ck TxYA== 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=q9neRA53nwPRk/t42SZxz6bwiz5Uvwukilui8uXNpmw=; b=gxQw6i45isoA7c7JaobF0BAfy2aSeeZ7ZqaRSHyQ0yKVCLbUyYPIC8uaJRkqqdDZ61 YpUxMlb7JvKAmA8P9CTKit682M2PAznWCzCoPhM8Gjq1C0AO7NOQeyF4k3mXsIBT5/DM tA1Nsy6Lsz2e9H/rg1qTkV2lqNMtt4bwEmal8m3PPkvrQ9qj8OMMlnChRG1SOotdxVJL FjNp2WBu+6OhHKVQmSl5AK1n7BakcHEqrPc/egWTLZRIRGxAxcfSYrmLvuV2QQZs37cE dNkoE43qOJpe2p5lDk5tbfic+QPw/UmV6UUw6TEdRQ5vDkyfNDOKauVkATO1+vd2e9YV GffQ== X-Gm-Message-State: AOAM531AKwHuZup4vdu6AQeoCBb0bOWcHxpRwHJvsiKpXOwSiNcctD3H i5gqdxMAMWFKDHKXInp1cqqcK64n5ml929Es/aayyV3SNJo= X-Google-Smtp-Source: ABdhPJzVWHwZ2kx1eajaZVft9HMvpAx6NcGrExKazJ1k1bI2rOSjR21dJKhoeoOm1y/kVp0ryQMFmu5Ls8It2r5avoA= X-Received: by 2002:a17:906:a002:: with SMTP id p2mr1464446ejy.399.1602019535333; Tue, 06 Oct 2020 14:25:35 -0700 (PDT) MIME-Version: 1.0 References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> In-Reply-To: <060901d69c26$ba2deab0$2e89c010$@auth0.com> From: Andrii Deinega Date: Tue, 6 Oct 2020 14:25:24 -0700 Message-ID: To: vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000053ad0c05b1073da4" Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:25:39 -0000 --00000000000053ad0c05b1073da4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vittorio and WG, Would it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 In case the authorization server exposes the introspection, revocation, and OpenID Connect userinfo endpoints they MUST act in the same way as it happens with a regular access token. That allows the AS to change the type of an access token on the fly and that won=E2=80=99t lead to interoperate i= ssues. Plus, the consumers of these endpoints use them regardless of the type of access token. The way how the AS can notify RSs that the token revocation event happened (if it decides to do so) is completely left to implementers. ? Another minor editorial thing from me is it would possible to change and refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the token word twice. Regards, Andrii On Tue, Oct 6, 2020 at 2:22 PM wrote: > Hey Jim, regarding > > Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents the a= bility of > a client to access a given resource; the fact that it requires an > authentication transaction/session establishment to be issued to the clie= nt > does not mean that the AT lifetime is tied to the lifetime of that sessio= n. > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, i= t > doesn=E2=80=99t matter whether I stay logged in their web app or otherwis= e. Even if > I log out of the session in which context I got my twitter AT, I can stil= l > post on LinkedIn from my native LinkedIn app and the corresponding post > will show up on twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to originating > sessions lifetime, see the discussion on the OpenID Connect group about a > possible online_access scope for influencing RTs and Ats (in particular, = in > the context of SPAs) but that's additional semantic that isn=E2=80=99t de= fined > today. > > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > In this model, considering that token revocations don't happen a lot... > > Just a brief note, a secure piece of software makes the logout feature > prominent. Every logout event should trigger token revocation. > > I=E2=80=99m mentioning this because a lot of OAuth solutions in the mobil= e space > literally ignore the logout event, such as Facebook=E2=80=99s mobile OAut= h > solution. > > - Jim > > > On Oct 4, 2020, at 6:55 AM, Nicolas Mora wrote= : > > > > =EF=BB=BFHello, > > > >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > >> > >> There might be some kind of pushed events between the AS and the RS > when > >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at > all. > >> Like this, the RS knows if a JWT AT has been revoked or not. > >> > >> > >> If there are some kind of pushed events between the AS and the RS, > >> then it could push the revoked (and/or expired) opaque AT too, giving > >> almost no advantage to JWT ATs. > >> > > Not necessarily, let's say the AS informs the RS only of the revoked > > ATs, when a RS checks an AT, it verifies the signature first, then the > > claims, then checks if the AT has been revoked by checking its > > internal list filled by the AS pushed events. > > > > In this model, considering that token revocations don't happen a lot, > > the ratio revoked AT/valid AT is very low, so the advantage of a JWT > > is important, because it means not so much communication between the > > AS and the RSs, and a very reliable AT. > > > > But this means a communication mechanism that isn't standardized yet. > > > > /Nicolas > > > > _______________________________________________ > > 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 > --00000000000053ad0c05b1073da4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vittorio and WG,

Would it be poss= ible to include something like the following to https://tools.ietf.org/ht= ml/draft-ietf-oauth-access-token-jwt-10

In case the authorizati= on server=C2=A0exposes the introspection, revocation, and OpenID Connect us= erinfo endpoints=C2=A0they MUST act in the same way as it happens with a re= gular access token. That allows the AS to change the type of an access toke= n on the fly and that won=E2=80=99t lead to interoperate issues. Plus, the = consumers of these endpoints use them regardless of the type of access toke= n.

The way how the AS can notify RSs that the toke= n revocation event happened (if it decides to do so) is completely left to= =C2=A0implementers.

?

Ano= ther minor editorial thing from me is it would possible to change and refer= to "JWT access tokens" as AJWT. Thus, this document won't re= peat the token word twice.

Regards,
Andr= ii

On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=
Hey Jim, regard= ing
> Every logout event should trigger token revocation
That isn=E2=80=99t necessarily the case. An access token represents the abi= lity of a client to access a given resource; the fact that it requires an a= uthentication transaction/session establishment to be issued to the client = does not mean that the AT lifetime is tied to the lifetime of that session.= Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it= doesn=E2=80=99t matter whether I stay logged in their web app or otherwise= . Even if I log out of the session in which context I got my twitter AT, I = can still post on LinkedIn from my native LinkedIn app and the correspondin= g post will show up on twitter as well.
Now, one might choose to *explicitly* tie tokens lifetime to originating se= ssions lifetime, see the discussion on the OpenID Connect group about a pos= sible online_access scope for influencing RTs and Ats (in particular, in th= e context of SPAs) but that's additional semantic that isn=E2=80=99t de= fined today.

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora <nicolas@babelouest.org>
Cc: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

> In this model, considering that token revocations don't happen a l= ot...

Just a brief note, a secure piece of software makes the logout feature prom= inent. Every logout event should trigger token revocation.

I=E2=80=99m mentioning this because a lot of OAuth solutions in the mobile = space literally ignore the logout event, such as Facebook=E2=80=99s mobile = OAuth solution.

- Jim

> On Oct 4, 2020, at 6:55 AM, Nicolas Mora <nicolas@babelouest.org> wrote: >
> =EF=BB=BFHello,
>
>> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit :
>>
>>=C2=A0 =C2=A0 There might be some kind of pushed events between the= AS and the RS when
>>=C2=A0 =C2=A0 a JWT AT is revoked, to allow the RS not to introspec= t a JWT AT at all.
>>=C2=A0 =C2=A0 Like this, the RS knows if a JWT AT has been revoked = or not.
>>
>>
>> If there are some kind of pushed events between the AS and the RS,=
>> then it could push the revoked (and/or expired) opaque AT too, giv= ing
>> almost no advantage to JWT ATs.
>>
> Not necessarily, let's say the AS informs the RS only of the revok= ed
> ATs, when a RS checks an AT, it verifies the signature first, then the=
> claims, then checks if the AT has been revoked by checking its
> internal list filled by the AS pushed events.
>
> In this model, considering that token revocations don't happen a l= ot,
> the ratio revoked AT/valid AT is very low, so the advantage of a JWT <= br> > is important, because it means not so much communication between the <= br> > AS and the RSs, and a very reliable AT.
>
> But this means a communication mechanism that isn't standardized y= et.
>
> /Nicolas
>
> _______________________________________________
> 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
--00000000000053ad0c05b1073da4-- From nobody Tue Oct 6 14:31:22 2020 Return-Path: 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 183A13A14FC for ; Tue, 6 Oct 2020 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, 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=manicode.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 mQtn7whcbo5O for ; Tue, 6 Oct 2020 14:31:19 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 3FD6F3A14F9 for ; Tue, 6 Oct 2020 14:31:18 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id s19so1874120plp.3 for ; Tue, 06 Oct 2020 14:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pMZqCH42N1F6oyRMT47m4NXNLlhTfJQGd+/jcg4HFdY=; b=OQOiI01raadR8scxbjPSvLvrvznkViI4Mzc3CUQWv13kYXEASdCp1UJ4Yl2fw5Js4u /k0DzRLP8WllxMeIqTvVTWGua0LcSSmE20tTAhWEuD+ZyNihHq9K0KFCk2r/aLWpDCWY 22uE5c4MpCdzRchlhywCjnWDkg0GMEMGiz9Kp6PYi+U+oKlr1PfTYVdnACvGGVDa7e6W IxPu/axDxSxrvbWfd6jJWdr45OZ8dMnzp9+3MHOprwlYO1mH729WygawfXKTuyv3buVm H61yzspo9b2fkgqs0vXR4GYp4H/ckytzyLeFbtxxPCXtQdV8u5XHlpqw5s5UxhJlh+cy DPoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pMZqCH42N1F6oyRMT47m4NXNLlhTfJQGd+/jcg4HFdY=; b=tqkfRbIo/t5BFuStSkIVFHsISynXgMWY3SyMhJ+8NxaAndpa8waBYIqctCOMz9Nmv9 EhCNCjTL4M407BwoaqfFa+/9nLB0RnSKEt2NXxYnSTVxzY3/a86M6E/o68J0FSUhloed XsKdAK2/KcgYsxiVxuMeMA+Tf36mA7wLFfUbzKdNksHfn63D0RV67J4B0D8d5zE9xNs+ AJXejcXxQUlarRZ19iJxRzqeDSPCfoQu4/n5CRowR/wFyDF/gj+f/ldbEgqbCWtIz5FA 76ZWlW/iB5iLMTT5IoFtLbk5AuTcbg/XK9uM0aACjqVVCOhkXInIX/v+WG3HFl2OfUiy lCbg== X-Gm-Message-State: AOAM531RDMQNGdDlBfewwG2ywabUk0RveVC1YbV9fxikoKOpa5cLaxu8 ANfZE+NIZxiwr80E2PBwabW4tXr1Jl9VGQ== X-Google-Smtp-Source: ABdhPJwQu+1D206MfdPeFLsR8b3E6zGROWMQAk+zBH7TEEx0BvzncZm6LEWUZ6340JPqbjSWZDsL9g== X-Received: by 2002:a17:90a:c501:: with SMTP id k1mr94908pjt.170.1602019877524; Tue, 06 Oct 2020 14:31:17 -0700 (PDT) Received: from ?IPv6:2605:e000:112c:15:cdbe:66c2:9fea:a3aa? ([2605:e000:112c:15:cdbe:66c2:9fea:a3aa]) by smtp.googlemail.com with ESMTPSA id l188sm111126pfl.200.2020.10.06.14.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 14:31:16 -0700 (PDT) To: vittorio.bertocci@auth0.com, 'Nicolas Mora' Cc: oauth@ietf.org References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> From: Jim Manico Message-ID: <27c3c22e-7e37-2be0-49e2-7acf96ac7612@manicode.com> Date: Tue, 6 Oct 2020 11:31:15 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <060901d69c26$ba2deab0$2e89c010$@auth0.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:31:21 -0000 Thanks for this message, Vittorio. > Say that I allow LinkedIn to tweet on my behalf. Once I have done=20 that, it doesn=E2=80=99t matter whether I stay logged in their web app or= otherwise. Ah, of course. That makes perfect sense. I should had been a lot more specific. I was commenting more on how many = mobile apps which use OAuth AuthZ refresh/access tokens from the native=20 client RFC do not support logout. I noticed that when I log out of the=20 Facebook mobile app, my refresh token is still active and I'm not really = fully logged out. If I am in a native client triggering a logout event,=20 I would expect to see revocation in play! Also, in an microservice environment where JWT's are used as client side = sessions, logout events often do not actually revoke currently active=20 JWT's. #lazyLogoutBooo That's all from me. =3D) Aloha, Jim On 10/6/20 11:21 AM, vittorio.bertocci@auth0.com wrote: > Hey Jim, regarding >> Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents the= ability of a client to access a given resource; the fact that it require= s an authentication transaction/session establishment to be issued to the= client does not mean that the AT lifetime is tied to the lifetime of tha= t session. Say that I allow LinkedIn to tweet on my behalf. Once I have d= one that, it doesn=E2=80=99t matter whether I stay logged in their web ap= p or otherwise. Even if I log out of the session in which context I got m= y twitter AT, I can still post on LinkedIn from my native LinkedIn app an= d the corresponding post will show up on twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to originatin= g sessions lifetime, see the discussion on the OpenID Connect group about= a possible online_access scope for influencing RTs and Ats (in particula= r, in the context of SPAs) but that's additional semantic that isn=E2=80=99= t defined today. > > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > >> In this model, considering that token revocations don't happen a lot..= =2E > Just a brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token revocation. > > I=E2=80=99m mentioning this because a lot of OAuth solutions in the mob= ile space literally ignore the logout event, such as Facebook=E2=80=99s m= obile OAuth solution. > > - Jim > >> On Oct 4, 2020, at 6:55 AM, Nicolas Mora wrot= e: >> >> =EF=BB=BFHello, >> >>> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : >>> >>> There might be some kind of pushed events between the AS and the = RS when >>> a JWT AT is revoked, to allow the RS not to introspect a JWT AT a= t all. >>> Like this, the RS knows if a JWT AT has been revoked or not. >>> >>> >>> If there are some kind of pushed events between the AS and the RS, >>> then it could push the revoked (and/or expired) opaque AT too, giving= >>> almost no advantage to JWT ATs. >>> >> Not necessarily, let's say the AS informs the RS only of the revoked >> ATs, when a RS checks an AT, it verifies the signature first, then the= >> claims, then checks if the AT has been revoked by checking its >> internal list filled by the AS pushed events. >> >> In this model, considering that token revocations don't happen a lot, >> the ratio revoked AT/valid AT is very low, so the advantage of a JWT >> is important, because it means not so much communication between the >> AS and the RSs, and a very reliable AT. >> >> But this means a communication mechanism that isn't standardized yet. >> >> /Nicolas >> >> _______________________________________________ >> 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 > --=20 Jim Manico Manicode Security https://www.manicode.com From nobody Tue Oct 6 14:38:40 2020 Return-Path: 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 F342E3A14FD for ; Tue, 6 Oct 2020 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=auth0.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 h68l-N1kA8aN for ; Tue, 6 Oct 2020 14:38:37 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 E925E3A14FC for ; Tue, 6 Oct 2020 14:38:36 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id g29so73373pgl.2 for ; Tue, 06 Oct 2020 14:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=nfgc8FYSOt1GqNZkJK766O1MulgHPbzlWZyTqoOHsnA=; b=RTBjXJE+Pj8JtODIFAJS6saa83EtLx9WaxpQzPXM13xWgkHMXV7roAv/H3WLZVLsO3 HebmarBeMhb8XoTpDMHnA/e6MSgakvLb6QKcd99eSoMTUb87VwJZs0X7VEZR2DQaYkT9 DjnfZA52Kyse0Bqko1XQKO8+hxw9Tvgt1kfeC/iI5GCpQwaBfC7ssTxduGJjeu17juu4 B/Zx/XRpr7BuLMU5yHaDm9idoykrcRCItT720n3+Ljj9sa8Cn+qBmYlR8VJVjySB8/AZ kinCPEFMOpK4GbmSkbsQGPsRftd96uNX2SA9Y99TAU0Z/9e2SJp8nc9DtFWMTYPlVZwS MsMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=nfgc8FYSOt1GqNZkJK766O1MulgHPbzlWZyTqoOHsnA=; b=sByDIHZn21FEPDb1AGus69nulycSVbnkG9If47Q5tez2ROYGbppViKvhRz6vLR31ST oRqBqYZ183+eyhopicTWX2i5BxYRENPj3ItCLOmvv+WMtutBpDrBw1KRctv6gDW/VVhl o0Y70rGKS5dvhYuzZIi/kqQf/pbcPCW4DHDgOhzEGhH6FVk1YoC4MS0aFFk6Bepq9G2q F+w/PZArStALV8gLneVVgqWCZLuZKaXyIUZ9Vx7zTlU6ZvA6FRqXarbUOobgo+B19cvH i8NcntCsGB4iIQcxl+oGTkFzDOvbIAUnRwEorENOj/hXVvAlNXBfokr1Y+OLI1IFoHSf uDyA== X-Gm-Message-State: AOAM530lHpy4ciYeRZwC9sI3SJyOxmrUEJOiIkf/dfTGq9bhF3VcxFyX qQYbx5TNGTFq2LeqPqCvewOoVg== X-Google-Smtp-Source: ABdhPJy9Ednx8QInssZHKjcmxtin7lwbipT5faoyVjEvTL4gOAsIRkD87A8YL0VNqctavCImIthqAw== X-Received: by 2002:a63:151f:: with SMTP id v31mr194210pgl.126.1602020316187; Tue, 06 Oct 2020 14:38:36 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id s8sm3603601pjn.10.2020.10.06.14.38.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:38:35 -0700 (PDT) From: To: "'Thomas Broyer'" , "'Nicolas Mora'" Cc: References: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> In-Reply-To: Date: Tue, 6 Oct 2020 14:38:35 -0700 Message-ID: <063001d69c29$0c0f2680$242d7380$@auth0.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0631_01D69BEE.5FB2BF80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLG11BRlKJ0/lyYnR+Vsd4foOMaQJgjnz4AyDBJF8CDqy+TwJpvUdiqdJGVJA= Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:38:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0631_01D69BEE.5FB2BF80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for bringing the revocation topic up. In brief: =20 * I agree on the comments that differentiate between userinfo and = introspection- userinfo doesn=E2=80=99t really play a role in validation = hence I=E2=80=99d keep it out of the JWT AT doc. * I agree that the introspection endpoint shouldn=E2=80=99t do anything = special or different for JWT ATs =20 The last point is more involved.=20 I think that using introduction just for checking revocation would be = overkill and wasteful, no point sending the entire token if it has been = already validated (bandwidth) and no point for the AS to repeat checks = already done by the RS, especially at large scale and for chatty = solutions. One of the reasons for making `JTI` mandatory in the profile is to = provide a mechanism for handling AT revocation easier. There is no = standard today for doing that.=20 In some 1:1 conversations on the topic, one solution that sounds = promising is for the AS to publish a list per each resource/client = including all the revoked JTIs. The RS is free to fetch that list at any = time and incorporate local revocation checks at whatever frequency it = wants.=20 The na=C3=AFve alternative is to have an endpoint on the AS the RS can = use to inquire on whether a given JTI has been revoked. That is less = wasteful than doing a full introspection, but still network hungry. Both alternatives have implications on the AS, now saddled with tracking = possibly large numbers of tokens. There are heuristics to handle that = (eg have identifiers for sessions and use those to manage revocations, = rather than trating every AT as independent) and ultimately it would not = be in the purview of the protocol to worry about that, but something to = consider when implementing. =20 Would it be useful to produce normative guidance on one of the = approaches above? If yes, where would that live? I am not sure the JWT = AT profile is the right place, perhaps an addendum to the current = revocation specs? =20 =20 From: OAuth On Behalf Of Thomas Broyer Sent: Tuesday, October 6, 2020 5:17 AM To: Nicolas Mora Cc: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint =20 =20 =20 On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora > wrote: Hello, Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > There might be some kind of pushed events between the AS and the = RS when > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at = all. > Like this, the RS knows if a JWT AT has been revoked or not. >=20 >=20 > If there are some kind of pushed events between the AS and the RS, = then > it could push the revoked (and/or expired) opaque AT too, giving = almost > no advantage to JWT ATs. > Not necessarily, let's say the AS informs the RS only of the revoked ATs, when a RS checks an AT, it verifies the signature first, then the claims, then checks if the AT has been revoked by checking its internal list filled by the AS pushed events. =20 Well, you were the one saying that =E2=80=9Cthe advantage of using a JWT = AT is close to 0=E2=80=9D =F0=9F=98=89 (and I was the one bringing the advantage of being able to do some = verifications prior to contacting the introspection endpoint, btw) In any case, for an opaque AT, you only get to introspect it once to = know its expiration (and you can cache the result); so those preliminary = checks you can do with a JWT only save you one introspection request IFF = the token is not valid, e.g. expired; if it's valid or has been revoked, = then you'll have to introspect it anyway. And if you imagine that "pushed events" mechanism, then it would work = the same for an opaque AT or a JWT AT, saving you the introspection = requests that would otherwise be mandatory for checking revocation. =20 So (and I know it wasn't the original subject of the discussion), a JWT = AT can save you, compared to an opaque AT: * a call to the userinfo endpoint if it embeds the claims you need * a call to the introspection endpoint if it's expired or otherwise = invalid, and/or some memory/storage space that you could use as a cache = for that information for an opaque AT (to avoid issuing other = introspection requests, as an optimization / compromise) =20 --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ =20 ------=_NextPart_000_0631_01D69BEE.5FB2BF80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for = bringing the revocation topic up. In brief:

 

  • I agree on the = comments that differentiate between userinfo and introspection- userinfo = doesn=E2=80=99t really play a role in validation hence I=E2=80=99d keep = it out of the JWT AT doc.
  • I agree that the = introspection endpoint shouldn=E2=80=99t do anything special or = different for JWT ATs

 

The last = point is more involved.
I think that using introduction just for = checking revocation would be overkill and wasteful, no point sending the = entire token if it has been already validated (bandwidth) and no point = for the AS to repeat checks already done by the RS, especially at large = scale and for chatty solutions.
One of the reasons for making `JTI` = mandatory in the profile is to provide a mechanism for handling AT = revocation easier. There is no standard today for doing that.
In = some 1:1 conversations on the topic, one solution that sounds promising = is for the AS to publish a list per each resource/client including all = the revoked JTIs. The RS is free to fetch that list at any time and = incorporate local revocation checks at whatever frequency it wants. =
The na=C3=AFve alternative is to have an endpoint on the AS the RS = can use to inquire on whether a given JTI has been revoked. That is less = wasteful than doing a full introspection, but still network = hungry.
Both alternatives have implications on the AS, now saddled = with tracking possibly large numbers of tokens. There are heuristics to = handle that (eg have identifiers for sessions and use those to manage = revocations, rather than trating every AT as independent) and ultimately = it would not be in the purview of the protocol to worry about that, but = something to consider when implementing.

 

Would it be = useful to produce normative guidance on one of the approaches above? If = yes, where would that live? I am not sure the JWT AT profile is the = right place, perhaps an addendum to the current revocation = specs?

 

 

From: OAuth = <oauth-bounces@ietf.org> On Behalf Of Thomas = Broyer
Sent: Tuesday, October 6, 2020 5:17 AM
To: = Nicolas Mora <nicolas@babelouest.org>
Cc: = <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: = [OAUTH-WG] JWT access tokens and the revocation = endpoint

 

 

 

On = Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora <nicolas@babelouest.org> = wrote:

Hello,

Le 20-10-04 =C3=A0 11 h 27, Thomas = Broyer a =C3=A9crit :

>     There might be = some kind of pushed events between the AS and the RS when
>  =    a JWT AT is revoked, to allow the RS not to introspect a = JWT AT at all.
>     Like this, the RS knows if a = JWT AT has been revoked or not.
>
>
> If there are = some kind of pushed events between the AS and the RS, then
> it = could push the revoked (and/or expired) opaque AT too, giving = almost
> no advantage to JWT ATs.
>
Not necessarily, = let's say the AS informs the RS only of the revoked
ATs, when a RS = checks an AT, it verifies the signature first, then the
claims, then = checks if the AT has been revoked by checking its internal
list = filled by the AS pushed events.

 

Well, you were the one saying that =E2=80=9Cthe = advantage of using a JWT AT is close to 0=E2=80=9D 😉

(and I was the one bringing the advantage of being = able to do some verifications prior to contacting the = introspection endpoint, btw)

In any case, for an opaque AT, you only get to = introspect it once to know its expiration (and you can cache the = result); so those preliminary checks you can do with a JWT only save you = one introspection request IFF the token is not valid, e.g. expired; if = it's valid or has been revoked, then you'll have to introspect it = anyway.

And if you imagine = that "pushed events" mechanism, then it would work the same = for an opaque AT or a JWT AT, saving you the introspection requests = that would otherwise be mandatory for checking = revocation.

 

So (and I know it wasn't the original subject of the = discussion), a JWT AT can save you, compared to an opaque = AT:

 * a call to the = userinfo endpoint if it embeds the claims you = need

 * a call to the = introspection endpoint if it's expired or otherwise invalid, and/or some = memory/storage space that you could use as a cache for that information = for an opaque AT (to avoid issuing other introspection requests, as an = optimization / compromise)

 

-- =

<= /div> ------=_NextPart_000_0631_01D69BEE.5FB2BF80-- From nobody Tue Oct 6 14:42:08 2020 Return-Path: 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 1709A3A1501 for ; Tue, 6 Oct 2020 14:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=auth0.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 yWEeicPX5Wlf for ; Tue, 6 Oct 2020 14:42:05 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 537FA3A1500 for ; Tue, 6 Oct 2020 14:42:05 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id q123so126164pfb.0 for ; Tue, 06 Oct 2020 14:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=vbBmspJT+cWpoG7atuEOCPDTiiDA34ZsyLT/v1tdbI0=; b=ABB/kJQq9mJ5Uk7c5jjlwM42lZS3sYG6mv963UsC+uiQXjm51OPmRVkC913s27C6wo Gpv4OsdkBfCpl6Twt6ImftZgaZhYgqJLzYIa+aXzINIatxp81/9Ie6eCco89PojUMTTP Igqpv7xWMjVF5p2yRjvhfv3EnX0gZbiHSZmd99dc0/+I7WRY/tKtkECFCu+55AZ7Ko4r sAJSmiOo44aBPgbN2YdqKUuCt1qsxGMouOsvu7Sm8GXveW4j13tJGbwZVMSDGCFpqKnQ Y7UIMfQFsDqPXxPWsTk0UVxMV6r4qt4wkJs99AAcGQydyGCSmX/PYyLq7rN6+lHEdR9+ fwZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=vbBmspJT+cWpoG7atuEOCPDTiiDA34ZsyLT/v1tdbI0=; b=hQHUTJmzUXqR9JXt6l5mTVACg5k6AWK2GSWK7P13nfPqbUwvm5RcbNKzqiA6BRQthT 75Wnq22xdvVGQcMH+bZbb+EDctwIaYqNSy0e1nvhkfmlmrzdffhDNi5iuZML+J4DXOjA WooxwaT/gHlNOmkOfalWcj/3hd4Du37YOM70vTRVVByj+TAa8iEVDJTaREVdrioxcm+2 d3gMGAey7cDBGA2TMlylu7Dfdqa4dl01UND+Jkx7rfLOkCVsyBARcCnf/5moBKfSdTRG b59O2MQOpQeCT2uy4k4EcZQzgTRnw+Jd0AChjlTdbhRxh2d1SaZ0WyLhEh+fUsqg1Q6I 9VVw== X-Gm-Message-State: AOAM533nA6rPAn8PVGGthGMx+d+4rpHo8GdbNaDKBiDWy3ZWsKDzFDxo FWYald+JAGteMpOmQstNneJKnjJcamM2PZjT X-Google-Smtp-Source: ABdhPJxY+GTSc/lhGCy9RIRO7ZCteFcJvI8g21zOmJK7GPcrs66zVhwN8F5V/uROzQydUs309huvmg== X-Received: by 2002:a63:4811:: with SMTP id v17mr173261pga.253.1602020524751; Tue, 06 Oct 2020 14:42:04 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id d129sm128949pfc.161.2020.10.06.14.42.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:42:04 -0700 (PDT) From: To: "'Jim Manico'" , "'Nicolas Mora'" Cc: References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> <27c3c22e-7e37-2be0-49e2-7acf96ac7612@manicode.com> In-Reply-To: <27c3c22e-7e37-2be0-49e2-7acf96ac7612@manicode.com> Date: Tue, 6 Oct 2020 14:42:04 -0700 Message-ID: <063701d69c29$886411a0$992c34e0$@auth0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOrL5PoOMmS7FkPutnv0CxOSedfQJQ4VslAe3qkQ0BaqH+pKjtrYGQ Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:42:07 -0000 Thanks for the clarification! I agree, the scenarios you described would = be improved by actually killing the ability of the app to access the = resources, instead on relying on the client to discard the tokens = without leaking them. That's why I am a big proponent of the = online_access scope, tho I know a lot of people don=E2=80=99t like it as = it perpetrates the offline_access original sin =F0=9F=98=8A -----Original Message----- From: Jim Manico =20 Sent: Tuesday, October 6, 2020 2:31 PM To: vittorio.bertocci@auth0.com; 'Nicolas Mora' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint Thanks for this message, Vittorio. > Say that I allow LinkedIn to tweet on my behalf. Once I have done = that, it doesn=E2=80=99t matter whether I stay logged in their web app = or otherwise. Ah, of course. That makes perfect sense. I should had been a lot more specific. I was commenting more on how many = mobile apps which use OAuth AuthZ refresh/access tokens from the native = client RFC do not support logout. I noticed that when I log out of the = Facebook mobile app, my refresh token is still active and I'm not really = fully logged out. If I am in a native client triggering a logout event, = I would expect to see revocation in play! Also, in an microservice environment where JWT's are used as client side = sessions, logout events often do not actually revoke currently active = JWT's. #lazyLogoutBooo That's all from me. =3D) Aloha, Jim On 10/6/20 11:21 AM, vittorio.bertocci@auth0.com wrote: > Hey Jim, regarding >> Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents = the ability of a client to access a given resource; the fact that it = requires an authentication transaction/session establishment to be = issued to the client does not mean that the AT lifetime is tied to the = lifetime of that session. Say that I allow LinkedIn to tweet on my = behalf. Once I have done that, it doesn=E2=80=99t matter whether I stay = logged in their web app or otherwise. Even if I log out of the session = in which context I got my twitter AT, I can still post on LinkedIn from = my native LinkedIn app and the corresponding post will show up on = twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to = originating sessions lifetime, see the discussion on the OpenID Connect = group about a possible online_access scope for influencing RTs and Ats = (in particular, in the context of SPAs) but that's additional semantic = that isn=E2=80=99t defined today. > > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > >> In this model, considering that token revocations don't happen a = lot... > Just a brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token revocation. > > I=E2=80=99m mentioning this because a lot of OAuth solutions in the = mobile space literally ignore the logout event, such as = Facebook=E2=80=99s mobile OAuth solution. > > - Jim > >> On Oct 4, 2020, at 6:55 AM, Nicolas Mora = wrote: >> >> =EF=BB=BFHello, >> >>> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : >>> >>> There might be some kind of pushed events between the AS and the = RS when >>> a JWT AT is revoked, to allow the RS not to introspect a JWT AT = at all. >>> Like this, the RS knows if a JWT AT has been revoked or not. >>> >>> >>> If there are some kind of pushed events between the AS and the RS,=20 >>> then it could push the revoked (and/or expired) opaque AT too,=20 >>> giving almost no advantage to JWT ATs. >>> >> Not necessarily, let's say the AS informs the RS only of the revoked=20 >> ATs, when a RS checks an AT, it verifies the signature first, then=20 >> the claims, then checks if the AT has been revoked by checking its=20 >> internal list filled by the AS pushed events. >> >> In this model, considering that token revocations don't happen a lot, = >> the ratio revoked AT/valid AT is very low, so the advantage of a JWT=20 >> is important, because it means not so much communication between the=20 >> AS and the RSs, and a very reliable AT. >> >> But this means a communication mechanism that isn't standardized yet. >> >> /Nicolas >> >> _______________________________________________ >> 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 > -- Jim Manico Manicode Security https://www.manicode.com From nobody Tue Oct 6 14:53:37 2020 Return-Path: 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 C36DF3A1504 for ; Tue, 6 Oct 2020 14:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=auth0.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 eeIDVJ3Ezfh1 for ; Tue, 6 Oct 2020 14:53:33 -0700 (PDT) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 CA5B33A09C4 for ; Tue, 6 Oct 2020 14:53:33 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id j8so5056pjy.5 for ; Tue, 06 Oct 2020 14:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=7nhc7wbuPquCGCRCVtnRWdTFFArwW+nvC2BqFuqEvXY=; b=qw7/nDz6q8lW+UxKu54o8CWMNrJVYxQ5b2u87RsCnxmnKh2NMlRrklOXjTwrHhNe45 w7kB8FZdW+xNi0il6R1njF3zRh4cqyLlBKNShXQO3xcsPQ8WlcpeZvFij539QQI/jivt 3eUQ6syFyh+8obdMqVSV8sRvXoyTCUGMk18IN+ICDaLmcbuBAqXMAsrWqKDRHzPUblKA 9lgH+/gxtZxuRE1hmtHN5hHaR39dWyB2juXbaSCWv5Ure7VuqgjbLMSq9j5Ch33FOnqC 2Le5MQnZKlvDzYdzx7iBm1MgBTbLSEZIrHEaYcrE2GSTd6lkJ5/Rs2NdpTd/9WFwH+ch SGyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=7nhc7wbuPquCGCRCVtnRWdTFFArwW+nvC2BqFuqEvXY=; b=kzh9SK5ansMOloZiKk4TzuMZ7tGsew44gEqi4LtLwgkVQ4JxVVOZl6svNZCPbP4MAO vNUPpEz/Kd6SXwsS346ZcCQM+0IULb3izX+Oe+gYjKiv8oGMCuE9LBVaUxM9RrXd+uzi s1/YMoC+lQM5cKuomPCTGhvjRv7PyLl84PSwX+JFhCiLR+/nBaLanEvh650eH8wPEPfL TjzIFx+qjAMAOJd/4HU6KlM4Wz+8kxAtvKFXIQUy8pQVmyCIASDhuxmb0GbpZR0YYLhs TWe3HerxGD7x5LN92zRmWcnniDeTjwBZTeCLh/fpswCyaTyb7tnY6gd+qdEUWKo+nKkp 5Sxw== X-Gm-Message-State: AOAM532nhJdxlivICk7zHduF416gxg5L64n13pDW2YtUWMEurDk78Sb8 71w/r1HXD7+U8Dha/X1N8kZTsw== X-Google-Smtp-Source: ABdhPJzmapfyxGPGiIv9lk/opA/m0mS5J1GrXcTjZVe9wxCdpXSNYeRxI60WiftJEK0aLnFs9H1RRg== X-Received: by 2002:a17:902:714d:b029:d3:b593:297b with SMTP id u13-20020a170902714db02900d3b593297bmr112457plm.85.1602021213048; Tue, 06 Oct 2020 14:53:33 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id q8sm142245pfk.207.2020.10.06.14.53.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:53:32 -0700 (PDT) From: To: "'Andrii Deinega'" , References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> In-Reply-To: Date: Tue, 6 Oct 2020 14:53:32 -0700 Message-ID: <064801d69c2b$229141c0$67b3c540$@auth0.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0649_01D69BF0.7634B3B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIOrL5PoOMmS7FkPutnv0CxOSedfQJQ4VslAe3qkQ0A637UMKjxp1Dw Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:53:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0649_01D69BF0.7634B3B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrii, Thanks for the thoughtful comments! Here=E2=80=99s my 2 c. =20 On the proposed language: given that the JWT AT profile is just = providing more details on the content of an AT, making JWT ATs a proper = subset of all ATs, readers should have no reason to believe that = introspection or any other existing spec discussing AT behavior should = operate differently. That assumption holds for everything across the = board, hence it would be a bit odd to call out this particular case. On = the userinfo case, I would find it even more left field to say anything = about it. If we do reach a consensus on specific revocation practices that apply = to JWT ATs specifically, and we conclude that they should live in this = document, I will be happy to add language accordingly. =20 On the AJWT: I hear you on the dissonance that JWT AT carries, but I am = very hesitant to introduce new acronyms to an already = crowded/impenetrable domain. JWT access token might not roll off the tongue, but at this point = =E2=80=98JWT=E2=80=99 is nearly a proprietary eponym and the expression = =E2=80=9CJWT token=E2=80=9D is extraordinarily common in literature, a = quick google query will give you the full measure of the phenomenon, = hence I think we=E2=80=99ll be OK with the current form. Cheers, V. =20 From: Andrii Deinega =20 Sent: Tuesday, October 6, 2020 2:25 PM To: vittorio.bertocci@auth0.com; oauth@ietf.org Cc: Jim Manico ; Nicolas Mora Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint =20 Vittorio and WG, =20 Would it be possible to include something like the following to = https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 In case the authorization server exposes the introspection, revocation, = and OpenID Connect userinfo endpoints they MUST act in the same way as = it happens with a regular access token. That allows the AS to change the = type of an access token on the fly and that won=E2=80=99t lead to = interoperate issues. Plus, the consumers of these endpoints use them = regardless of the type of access token. =20 The way how the AS can notify RSs that the token revocation event = happened (if it decides to do so) is completely left to implementers. =20 ? =20 Another minor editorial thing from me is it would possible to change and = refer to "JWT access tokens" as AJWT. Thus, this document won't repeat = the token word twice. =20 Regards, Andrii =20 On Tue, Oct 6, 2020 at 2:22 PM = > wrote: Hey Jim, regarding > Every logout event should trigger token revocation That isn=E2=80=99t necessarily the case. An access token represents the = ability of a client to access a given resource; the fact that it = requires an authentication transaction/session establishment to be = issued to the client does not mean that the AT lifetime is tied to the = lifetime of that session. Say that I allow LinkedIn to tweet on my = behalf. Once I have done that, it doesn=E2=80=99t matter whether I stay = logged in their web app or otherwise. Even if I log out of the session = in which context I got my twitter AT, I can still post on LinkedIn from = my native LinkedIn app and the corresponding post will show up on = twitter as well. Now, one might choose to *explicitly* tie tokens lifetime to originating = sessions lifetime, see the discussion on the OpenID Connect group about = a possible online_access scope for influencing RTs and Ats (in = particular, in the context of SPAs) but that's additional semantic that = isn=E2=80=99t defined today. -----Original Message----- From: OAuth > On = Behalf Of Jim Manico Sent: Sunday, October 4, 2020 5:17 PM To: Nicolas Mora = > Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > In this model, considering that token revocations don't happen a = lot... Just a brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token revocation. I=E2=80=99m mentioning this because a lot of OAuth solutions in the = mobile space literally ignore the logout event, such as = Facebook=E2=80=99s mobile OAuth solution.=20 - Jim > On Oct 4, 2020, at 6:55 AM, Nicolas Mora > wrote: >=20 > =EF=BB=BFHello, >=20 >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : >>=20 >> There might be some kind of pushed events between the AS and the = RS when >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at = all. >> Like this, the RS knows if a JWT AT has been revoked or not. >>=20 >>=20 >> If there are some kind of pushed events between the AS and the RS,=20 >> then it could push the revoked (and/or expired) opaque AT too, giving = >> almost no advantage to JWT ATs. >>=20 > Not necessarily, let's say the AS informs the RS only of the revoked=20 > ATs, when a RS checks an AT, it verifies the signature first, then the = > claims, then checks if the AT has been revoked by checking its=20 > internal list filled by the AS pushed events. >=20 > In this model, considering that token revocations don't happen a lot,=20 > the ratio revoked AT/valid AT is very low, so the advantage of a JWT=20 > is important, because it means not so much communication between the=20 > AS and the RSs, and a very reliable AT. >=20 > But this means a communication mechanism that isn't standardized yet. >=20 > /Nicolas >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_0649_01D69BF0.7634B3B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Andrii,

Thanks for the thoughtful = comments! Here=E2=80=99s my 2 c.

 

On the = proposed language: given that the JWT AT profile is just providing more = details on the content of an AT, making JWT ATs a proper subset of all = ATs, readers should have no reason to believe that introspection or any = other existing spec discussing AT behavior should operate differently. = That assumption holds for everything across the board, hence it would be = a bit odd to call out this particular case. On the userinfo case, I = would find it even more left field to say anything about it.
If we do = reach a consensus on specific revocation practices that apply to JWT ATs = specifically, and we conclude that they should live in this document, I = will be happy to add language accordingly.

 

On the AJWT: = I hear you on the dissonance that JWT AT carries, but I am very hesitant = to introduce new acronyms to an already crowded/impenetrable = domain.
JWT access token might not roll off the tongue, but at this = point =E2=80=98JWT=E2=80=99 is nearly a proprietary eponym and the = expression =E2=80=9CJWT token=E2=80=9D is extraordinarily common in = literature, a quick google query will give you the full measure of the = phenomenon, hence I think we=E2=80=99ll be OK with the current = form.

Cheers,

V.

 

From: Andrii Deinega = <andrii.deinega@gmail.com>
Sent: Tuesday, October 6, = 2020 2:25 PM
To: vittorio.bertocci@auth0.com; = oauth@ietf.org
Cc: Jim Manico <jim@manicode.com>; = Nicolas Mora <nicolas@babelouest.org>
Subject: Re: = [OAUTH-WG] JWT access tokens and the revocation = endpoint

 

Vittorio and WG,

 

Would = it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10


In case the authorization = server exposes the introspection, revocation, and OpenID Connect = userinfo endpoints they MUST act in the same way as it happens with = a regular access token. That allows the AS to change the type of an = access token on the fly and that won=E2=80=99t lead to interoperate = issues. Plus, the consumers of these endpoints use them regardless of = the type of access token.

 

The way how the AS can notify RSs that the token = revocation event happened (if it decides to do so) is completely left = to implementers.

 

?

 

Another minor editorial thing from me is it would = possible to change and refer to "JWT access tokens" as AJWT. = Thus, this document won't repeat the token word = twice.

 

Regards,

Andrii

 

On = Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org= > wrote:

Hey Jim, = regarding
> Every logout event should trigger token = revocation
That isn=E2=80=99t necessarily the case. An access token = represents the ability of a client to access a given resource; the fact = that it requires an authentication transaction/session establishment to = be issued to the client does not mean that the AT lifetime is tied to = the lifetime of that session. Say that I allow LinkedIn to tweet on my = behalf. Once I have done that, it doesn=E2=80=99t matter whether I stay = logged in their web app or otherwise. Even if I log out of the session = in which context I got my twitter AT, I can still post on LinkedIn from = my native LinkedIn app and the corresponding post will show up on = twitter as well.
Now, one might choose to *explicitly* tie tokens = lifetime to originating sessions lifetime, see the discussion on the = OpenID Connect group about a possible online_access scope for = influencing RTs and Ats (in particular, in the context of SPAs) but = that's additional semantic that isn=E2=80=99t defined = today.

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Jim = Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora = <nicolas@babelouest.org>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT = access tokens and the revocation endpoint

> In this model, = considering that token revocations don't happen a lot...

Just a = brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token = revocation.

I=E2=80=99m mentioning this because a lot of OAuth = solutions in the mobile space literally ignore the logout event, such as = Facebook=E2=80=99s mobile OAuth solution.

- Jim

> On = Oct 4, 2020, at 6:55 AM, Nicolas Mora <nicolas@babelouest.org> wrote:
>
> = =EF=BB=BFHello,
>
>> Le 20-10-04 =C3=A0 11 h 27, Thomas = Broyer a =C3=A9crit :
>>
>>    There might = be some kind of pushed events between the AS and the RS = when
>>    a JWT AT is revoked, to allow the RS not = to introspect a JWT AT at all.
>>    Like this, the = RS knows if a JWT AT has been revoked or not.
>>
>> =
>> If there are some kind of pushed events between the AS and = the RS,
>> then it could push the revoked (and/or expired) = opaque AT too, giving
>> almost no advantage to JWT = ATs.
>>
> Not necessarily, let's say the AS informs the = RS only of the revoked
> ATs, when a RS checks an AT, it verifies = the signature first, then the
> claims, then checks if the AT has = been revoked by checking its
> internal list filled by the AS = pushed events.
>
> In this model, considering that token = revocations don't happen a lot,
> the ratio revoked AT/valid AT = is very low, so the advantage of a JWT
> is important, because it = means not so much communication between the
> AS and the RSs, and = a very reliable AT.
>
> But this means a communication = mechanism that isn't standardized yet.
>
> /Nicolas
> =
> _______________________________________________
> 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

------=_NextPart_000_0649_01D69BF0.7634B3B0-- From nobody Tue Oct 6 15:05:47 2020 Return-Path: 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 129EF3A1507 for ; Tue, 6 Oct 2020 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 vgg1645ZQIoX for ; Tue, 6 Oct 2020 15:05:44 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 F10C83A09F0 for ; Tue, 6 Oct 2020 15:05:43 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id g7so88480iov.13 for ; Tue, 06 Oct 2020 15:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=b6cC0eKSpndxZwdQZS+zP0ktxLsQHhieie6xuJfUM0Q=; b=OZ0neKAYXVf5NQCt7UIJZEFbxXyggCB30eyFK36S7cXF//ngchLzAv74eDhwm5j40M gEf9m4DaXD5Oz2fRilvbWVOTJxvQ3k1K2vkT2nZ2JeL5kspn3DHPjt2BSYkRxivIfkTi Ay/YyKKw5KPF33tMvDxe5NlqMg2yl/cg3q8sQW/KDBq0obVFGHiRhtKCNXGx/qS0D/It g7uSXcIzzN6+WEdeMlsk/Q0nVJzgYqYBO+eDJf2KRJgppXfezN2BsneE7lA1OOrmVZyP BwoV/TGZ+JjKgZxl7RqNUX++1GgQ13N8Nurcp2xrNY1DWMsbP+cMTEBWrwFkM4/japFw WGOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b6cC0eKSpndxZwdQZS+zP0ktxLsQHhieie6xuJfUM0Q=; b=YDzJUtpqIhDmuY8eB2nd8KMmGKC6F37MzRVNjGm5HvT+pdpeKDK5CVGOmwR92CC6i+ u4rM90u7FwojrAA6X3xpnAcQl4OBgEjyaVVl2cyywhIOw1nADvxtGl4nkZCbuANzry6X s1L5kWFRcrhm/d77yfcnB0QSKm8pQ8EeyXtY28CELGQAU3FwroADg8deIcMuRqacMOnl hjLPhMGV24IkBg8Y6+s7ttJoJ456LHcFXNWuCHUy+yDuozNV5qnYa1cjTvBspbSdBl5n MOKuBhhYerhPOJ3H68v0sOgV55qsJlOLuUo7+STzVsTTtqGyU5KxjObzCRdF4KAZg7dq qOHA== X-Gm-Message-State: AOAM532chpJPyO3SHk1e5jDx5iBl0cSUBx9LOmlR1oyU5HU66oDI0ITm 92FOr0hj8qZdEWBH2zT/y2BPK5H8sPc3Gg== X-Google-Smtp-Source: ABdhPJxYKlpQmvAbot01WO6laIynnv8OyqchLJDaJmGSlawluKW78TsarYjDANPnMI0xSQ4t9/YWCA== X-Received: by 2002:a05:6638:2412:: with SMTP id z18mr305891jat.56.1602021942577; Tue, 06 Oct 2020 15:05:42 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id c18sm61307ild.35.2020.10.06.15.05.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 15:05:41 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id y13so159334iow.4 for ; Tue, 06 Oct 2020 15:05:41 -0700 (PDT) X-Received: by 2002:a6b:fa0e:: with SMTP id p14mr2902902ioh.208.1602021941274; Tue, 06 Oct 2020 15:05:41 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Tue, 6 Oct 2020 15:05:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000bb6f2905b107cc9b" Archived-At: Subject: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 22:05:46 -0000 --000000000000bb6f2905b107cc9b Content-Type: text/plain; charset="UTF-8" Hi all, I have a couple questions for those of you who have implemented refresh token rotation... Have you included the option of a grace period on refresh token use, allowing multiple uses within some time window? I'm wondering because a grace period where a refresh token may be used more than once would work around the problem that has been brought up, of a mobile app accidentally using a refresh token more than once during normal operation because different threads are unable to coordinate between themselves. However that also kind of defeats the purpose since attacks within that grace period would be hard to detect. I'm looking for an idea of where people have landed on that issue in practice. If you have implemented a grace period, then how do you handle expiring the additional refresh tokens that have been granted? For example, if RT "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what happens if "R1.2" is then later used? Would you invalidate "R1.1" at that point? If so, why, and if not, why not? It would be most interesting to hear practical experience from people who have already built refresh token rotation into a system. Thanks! --- Aaron Parecki https://aaronparecki.com --000000000000bb6f2905b107cc9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all, I have a couple questions for those of you wh= o have implemented refresh token rotation...

Have = you included the option of a grace period on refresh token use, allowing mu= ltiple uses within some time window? I'm wondering because a grace peri= od where a refresh token may be used more than once would work around the p= roblem that has been brought up,=C2=A0of a mobile app accidentally using a = refresh token more than once during normal operation because different thre= ads are unable to coordinate between themselves. However that also kind of = defeats the purpose since attacks within that grace period would be hard to= detect. I'm looking for an idea of where people have landed on that is= sue in practice.

If you have implemented a grace p= eriod, then how do you handle expiring the additional refresh tokens that h= ave been granted? For example, if RT "R1" is used twice, resultin= g=C2=A0in new ATs "A1.1", "A1.2" and new RTs "R1.1= " and "R1.2", what happens if "R1.2" is then later= used? Would you invalidate "R1.1" at that point? If so, why, and= if not, why not?

It would be most interesting to = hear practical experience from people who have already built refresh token = rotation into a system.

Thanks!

---
Aaron Parecki
--000000000000bb6f2905b107cc9b-- From nobody Tue Oct 6 15:28:30 2020 Return-Path: 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 77FF73A151C for ; Tue, 6 Oct 2020 15:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=auth0.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 M85ELC0HTcXF for ; Tue, 6 Oct 2020 15:28:26 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 D27843A0FC0 for ; Tue, 6 Oct 2020 15:28:26 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id h2so1941595pll.11 for ; Tue, 06 Oct 2020 15:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=TLPz8Y+P9P99g8nDCCz7MkvO6V8hyUhfoEy7nUOAT6o=; b=rNTmoC3KQu2ohkpOwtGMqwYo+zPRm8Pc/6ELEJ5Mnapmw2fxlm0MNIuoBuG+1qreO+ Ng7C9Q0nL/5Ht9CELG8bYHkY0cwkeAQYK900y8nLEF6RGSLCGDvg9s3QcfBhjMSWijFb Ny8tujQW+PRvCjjwafxLRcnUVhFyab5/An88zgEjETLrdlqEjsZk/8yLZqUIIcbwxq8i fzxx4pKzm5K8gaArDTwRsyMSzOs/hibng8aBRZ3RJwXAQBtTXZgv+0SnOLBkR9Z5bWNu pkcZzWj8PQgv3JZKp5GyNPKXupU616AMZ7xEzdu/WNCt9sHC2wyAW1S7lPmWmy28ZJOZ EHKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=TLPz8Y+P9P99g8nDCCz7MkvO6V8hyUhfoEy7nUOAT6o=; b=KKHg0y4aFIQFFMglO7qZaXmt5MZu7YfY4OM5uJhvJo7E23369eEjeosPOnsQEmdMMi CkEsQndsA+sDHRoVuD+79CtIV2nDia2eysTIMQloKWCDo+9vfZGYShY0cffgTRyfVl4M E7KeJf7IjDpWR6RcECEM8UnLcH12dSUXy1k1Qw7OFGwUIqdSSCQgaM1qnx/JJ+XjjCKM SaMWSjgfz2XiFMIXCWt1b34YQL8n5UYEPOetSAzXtt/qiJnpcCoLxLi9CDKEYf8eRTh0 660e+IfL9KxIalt/OToCq7FiqWpAVKYtF3gVPBGdm6UbHEv2vIhdgx2GI8mmXrNJgK0F cliA== X-Gm-Message-State: AOAM5339m8k8QGWre7TRtu8We5tEySgUUMGVarogs57EVXuu+9hVHSLE WTibE7x0cXDva8l9WIi3O55y1V32Q6Adxulw X-Google-Smtp-Source: ABdhPJzFUsQEvdgcdjFmRToNHmZrBUI6pETjHwQVKEsbyt7AYmAeusBiuKJxau3VgHb++KdCjUQS8Q== X-Received: by 2002:a17:90a:17ad:: with SMTP id q42mr269386pja.36.1602023305859; Tue, 06 Oct 2020 15:28:25 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id g3sm36130pjl.6.2020.10.06.15.28.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 15:28:25 -0700 (PDT) From: To: "'Aaron Parecki'" , "'OAuth WG'" References: In-Reply-To: Date: Tue, 6 Oct 2020 15:28:25 -0700 Message-ID: <067801d69c30$02119bc0$0634d340$@auth0.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0679_01D69BF5.55B42350" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFWoIr2EjR7EjLptonet55CHSVES6qLGtTA Content-Language: en-us Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 22:28:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0679_01D69BF5.55B42350 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Aaron, Auth0 does offer a configurable grace period, during which the = =E2=80=9Cpreceding=E2=80=9D token can be reused.=20 I am not 100% sure what we do in the exact scenario you described, and I = will double check for you, but here=E2=80=99s my intuition. =20 The operation redeem(RT_n) should result in AT, RT_n+1. The grace period = just extends the time in which the operation can occur, but every = operation should be idempotent. All repeats of that operation within the = grace period should have the same result, which means that every = resulting RT is a representative of the RT_n+1 class, hence all valid at = the same time. After the grace period elapses, RT_n is invalid, and = that=E2=80=99s it. So, in your example I would consider RT1.1 and RT1.2 as equivalent, as = they are both representatives of the RT_n+1 equivalence class. =20 It would be very hard to do otherwise, given that network operations = aren=E2=80=99t guaranteed to be concluded in the order they were = executed without semaphores, and above all the network failures the = grace period is designed to handle can apply to any of the requests, = regardless of the order. =20 From: OAuth On Behalf Of Aaron Parecki Sent: Tuesday, October 6, 2020 3:06 PM To: OAuth WG Subject: [OAUTH-WG] Implementation questions around refresh token = rotation =20 Hi all, I have a couple questions for those of you who have implemented = refresh token rotation... =20 Have you included the option of a grace period on refresh token use, = allowing multiple uses within some time window? I'm wondering because a = grace period where a refresh token may be used more than once would work = around the problem that has been brought up, of a mobile app = accidentally using a refresh token more than once during normal = operation because different threads are unable to coordinate between = themselves. However that also kind of defeats the purpose since attacks = within that grace period would be hard to detect. I'm looking for an = idea of where people have landed on that issue in practice. =20 If you have implemented a grace period, then how do you handle expiring = the additional refresh tokens that have been granted? For example, if RT = "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs = "R1.1" and "R1.2", what happens if "R1.2" is then later used? Would you = invalidate "R1.1" at that point? If so, why, and if not, why not? =20 It would be most interesting to hear practical experience from people = who have already built refresh token rotation into a system. =20 Thanks! --- Aaron Parecki https://aaronparecki.com =20 ------=_NextPart_000_0679_01D69BF5.55B42350 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey = Aaron,

Auth0 does offer a = configurable grace period, during which the =E2=80=9Cpreceding=E2=80=9D = token can be reused.

I am not 100% = sure what we do in the exact scenario you described, and I will double = check for you, but here=E2=80=99s my intuition.

 

The = operation redeem(RT_n) should result in AT, RT_n+1. The grace period = just extends the time in which the operation can occur, but every = operation should be idempotent. All repeats of that operation within the = grace period should have the same result, which means that every = resulting RT is a representative of the RT_n+1 class, hence all valid at = the same time. After the grace period elapses, RT_n is invalid, and = that=E2=80=99s it.

So, in your = example I would consider RT1.1 and RT1.2 as equivalent, as they are both = representatives of the RT_n+1 equivalence class.

 

It would be = very hard to do otherwise, given that network operations aren=E2=80=99t = guaranteed to be concluded in the order they were executed without = semaphores, and above all the network failures the grace period is = designed to handle can apply to any of the requests, regardless of the = order.

 

From: OAuth = <oauth-bounces@ietf.org> On Behalf Of Aaron = Parecki
Sent: Tuesday, October 6, 2020 3:06 PM
To: = OAuth WG <oauth@ietf.org>
Subject: [OAUTH-WG] = Implementation questions around refresh token = rotation

 

Hi = all, I have a couple questions for those of you who have implemented = refresh token rotation...

 

Have you included the option of a grace period on = refresh token use, allowing multiple uses within some time window? I'm = wondering because a grace period where a refresh token may be used more = than once would work around the problem that has been brought = up, of a mobile app accidentally using a refresh token more than = once during normal operation because different threads are unable to = coordinate between themselves. However that also kind of defeats the = purpose since attacks within that grace period would be hard to detect. = I'm looking for an idea of where people have landed on that issue in = practice.

 

If you have implemented a grace period, then how do = you handle expiring the additional refresh tokens that have been = granted? For example, if RT "R1" is used twice, = resulting in new ATs "A1.1", "A1.2" and new RTs = "R1.1" and "R1.2", what happens if "R1.2" = is then later used? Would you invalidate "R1.1" at that point? = If so, why, and if not, why not?

 

It would be most interesting to hear practical = experience from people who have already built refresh token rotation = into a system.

 

Thanks!


---

Aaron = Parecki

<= p = class=3DMsoNormal> 

------=_NextPart_000_0679_01D69BF5.55B42350-- From nobody Tue Oct 6 15:57:00 2020 Return-Path: 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 97CCF3A152F for ; Tue, 6 Oct 2020 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hzZzDQUWEwWy for ; Tue, 6 Oct 2020 15:56:55 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 A51E93A1527 for ; Tue, 6 Oct 2020 15:56:55 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id n142so379655ybf.7 for ; Tue, 06 Oct 2020 15:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zdSxZFx4t1KIbQeZI6IHenF9yw0J/j8zfEQFyz9sEvs=; b=gLEXi/G+KQVYocc3UgLph973MXgBerpS8ym2WyOUR3ZGBvsDPY0XnhXvRK3jAdhJ21 /qUGCM7pLFYaYUtLO3RK5Sl2VQcEGKHyZKaZuAk+uSsdtO+LZI3Q4dTITGef0OeHi8ix Int7zKbCC0sLbaZERFW1KKTOoTgqwLJhv06P7VgdN7jCmC5ke5fycsv3BjBuc5xievZA hVYB2r004vrU5O+dK7kZyoj7aSjvrZRyr6k4+G/0nUjWuGAo4zmlEzYT41bLMNzTtZxQ Y5/E5kVhY3gxBssbnSAhNYVkFs9VFCxhFmAfT6a8olIQKPg2kE5VwKY0N9/nF2vmUn8S jK/A== 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=zdSxZFx4t1KIbQeZI6IHenF9yw0J/j8zfEQFyz9sEvs=; b=AIyUBF/W6W5ScUa8/YAB33UhE65tEUktQqobB3gFKZmOnqGPqdTl88Rq1EfcWCNOkh oNjwYvYccVgP8LJIZtuVZwfk0JiM2MmwXbXmIUSrbphjqGWQLvnTGY9AAUN67oSrlFmy wLiq16upnvIrRdHYrJIsoQVkL804Qabzm3mVXwwkKgHldFD1lMKDr/mDkkK83VWjxi24 rkt1B6DJw0gTcuL/FV9zbQyffFvpDARxpBbYsBXcilE24YGCwGy9iAyinuQlaxUaB5mw Xta4DvSF/Bu08Gei/WJ8r5KcyPX7Fw7/tTtU2n5yZUPAr0MCNBCKH74HdWLvtOYONsA3 sgNA== X-Gm-Message-State: AOAM532zAVNJd0dBXYlUJ3lCwltwZ8TxB8EOBfxVqqsUkYTNfIFIxa+9 zt/J9kjBFWTOyir6fr95J6HLiQrkXZrmqmZc02ht0g== X-Google-Smtp-Source: ABdhPJz2HfkKi1iyk3jUHVtQP1IJ6YjAp9DR8wCrpfdreR392nsdxaoqnn58+r9iGmVBrU4lC+i+d5m9ulmIKHZ+Ano= X-Received: by 2002:a5b:d44:: with SMTP id f4mr684365ybr.153.1602025014640; Tue, 06 Oct 2020 15:56:54 -0700 (PDT) MIME-Version: 1.0 References: <067801d69c30$02119bc0$0634d340$@auth0.com> In-Reply-To: <067801d69c30$02119bc0$0634d340$@auth0.com> From: Jeff Craig Date: Tue, 6 Oct 2020 17:56:43 -0500 Message-ID: To: vittorio.bertocci=40auth0.com@dmarc.ietf.org Cc: Aaron Parecki , OAuth WG Content-Type: multipart/alternative; boundary="000000000000eba5d105b10883f4" Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 22:56:59 -0000 --000000000000eba5d105b10883f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My experience is more from the Client side of the equation on this problem, but I do have some thoughts. Our goal is to prevent cases where we lose the ability to Refresh a Token due to transient issues (which have run the gamut from network problems to bad software updates on the AS side). Our use case also does all token handling server-side, so our threat model is not the same as the mobile application you described. There is a clear tradeoff in reducing user friction with additional authorization events, and securing access. The recommendation my team typically gives people building Authorization Servers with Refresh Token Rotation is to keep the old refresh token until they see the new one (which means that there are generally two refresh tokens valid at any point in time, an unfortunate trade-off). A more difficult, but potentially plausible implementation would be to hold onto the older Refresh Token until the newly issued Access Token is used (thus implying the refresh was successful on both sides). We aren't trying to protect against multiple in-flight refreshes though (we've done a LOT of work to attempt to remove that possibility in a globally consistent manner), we're trying to protect against a network interruption that prevents the first use of R1, so our assumption is that R2.1 was completely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A/R2.1 is dropped in flight, R1 is sent again, A/R2.2 is returned and stored. Since R1 was seen a second time, we recommend that R2.1 be ignored in future. Next refresh will use R2.2, at which point R1 should never be seen again. The biggest issue that I see with a time-based grace period is that for many offline tasks, a single refresh failure may be ignored by the client, and it could be hours before the second refresh attempt using the older refresh token is made (depending on time of day and what these requests are being used for), making the grace period low value in that case. On Tue, Oct 6, 2020 at 5:28 PM wrote: > Hey Aaron, > > Auth0 does offer a configurable grace period, during which the =E2=80=9Cp= receding=E2=80=9D > token can be reused. > > I am not 100% sure what we do in the exact scenario you described, and I > will double check for you, but here=E2=80=99s my intuition. > > > > The operation redeem(RT_n) should result in AT, RT_n+1. The grace period > just extends the time in which the operation can occur, but every operati= on > should be idempotent. All repeats of that operation within the grace peri= od > should have the same result, which means that every resulting RT is a > representative of the RT_n+1 class, hence all valid at the same time. Aft= er > the grace period elapses, RT_n is invalid, and that=E2=80=99s it. > > So, in your example I would consider RT1.1 and RT1.2 as equivalent, as > they are both representatives of the RT_n+1 equivalence class. > > > > It would be very hard to do otherwise, given that network operations > aren=E2=80=99t guaranteed to be concluded in the order they were executed= without > semaphores, and above all the network failures the grace period is design= ed > to handle can apply to any of the requests, regardless of the order. > > > > *From:* OAuth *On Behalf Of *Aaron Parecki > *Sent:* Tuesday, October 6, 2020 3:06 PM > *To:* OAuth WG > *Subject:* [OAUTH-WG] Implementation questions around refresh token > rotation > > > > Hi all, I have a couple questions for those of you who have implemented > refresh token rotation... > > > > Have you included the option of a grace period on refresh token use, > allowing multiple uses within some time window? I'm wondering because a > grace period where a refresh token may be used more than once would work > around the problem that has been brought up, of a mobile app accidentally > using a refresh token more than once during normal operation because > different threads are unable to coordinate between themselves. However th= at > also kind of defeats the purpose since attacks within that grace period > would be hard to detect. I'm looking for an idea of where people have > landed on that issue in practice. > > > > If you have implemented a grace period, then how do you handle expiring > the additional refresh tokens that have been granted? For example, if RT > "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1= " > and "R1.2", what happens if "R1.2" is then later used? Would you invalida= te > "R1.1" at that point? If so, why, and if not, why not? > > > > It would be most interesting to hear practical experience from people who > have already built refresh token rotation into a system. > > > > Thanks! > > > --- > > Aaron Parecki > > https://aaronparecki.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000eba5d105b10883f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My experience is more from the Client side of the equ= ation on this problem, but I do have some thoughts. Our goal is to prevent = cases where we lose the ability to Refresh a Token due to transient issues = (which have run the gamut from network problems to bad software updates on = the AS side). Our use case also does all token handling server-side, so our= threat model is not the same as the mobile application you described. Ther= e is a clear tradeoff in reducing user friction with additional authorizati= on events, and securing access.

The recommen= dation my team typically gives people building=C2=A0Authorization Servers w= ith Refresh Token Rotation is to keep the old refresh token until they see = the new one=C2=A0(which means that there are generally two refresh tokens v= alid at any point in time, an unfortunate trade-off). A more difficult, but= potentially plausible implementation would be to hold onto the older Refre= sh Token until the newly issued Access Token is used (thus implying the ref= resh=C2=A0was successful on both sides).

We aren't = trying to protect against multiple in-flight refreshes though (we've do= ne a LOT of work to attempt to remove that possibility in a globally consis= tent manner), we're trying to protect against a network interruption th= at prevents the first use of R1, so our assumption is that R2.1 was complet= ely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A/R2.1= is dropped in flight, R1 is sent again, A/R2.2 is returned and stored. Sin= ce R1 was seen a second time, we recommend that R2.1 be ignored in future. = Next refresh will use R2.2, at which point R1 should never be seen again.

The biggest issue that I see with a time-based grac= e period is that for many offline tasks, a single refresh failure may be ig= nored by the client, and it could be hours before the second refresh attemp= t using the older refresh token is made (depending on time of day and what = these requests are being used for), making the grace period low value in th= at case.

On Tue, Oct 6, 2020 at 5:28 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= ; wrote:

Hey Aaron,

Auth0 do= es offer a configurable grace period, during which the =E2=80=9Cpreceding= =E2=80=9D token can be reused.

I a= m not 100% sure what we do in the exact scenario you described, and I will = double check for you, but here=E2=80=99s my intuition.

=C2=A0

The oper= ation redeem(RT_n) should result in AT, RT_n+1. The grace period just exten= ds the time in which the operation can occur, but every operation should be= idempotent. All repeats of that operation within the grace period should h= ave the same result, which means that every resulting RT is a representativ= e of the RT_n+1 class, hence all valid at the same time. After the grace pe= riod elapses, RT_n is invalid, and that=E2=80=99s it.

So, in your example I would consider RT1.1 and RT1.2 as = equivalent, as they are both representatives of the RT_n+1 equivalence clas= s.

=C2=A0

It would be very hard to do otherwise, given that network op= erations aren=E2=80=99t guaranteed to be concluded in the order they were e= xecuted without semaphores, and above all the network failures the grace pe= riod is designed to handle can apply to any of the requests, regardless of = the order.

=C2=A0

=

= From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron PareckiSent: Tuesday, October 6, 2020 3:06 PM
To: OAuth WG <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org>Subject: [OAUTH-WG] Implementation questions around refresh token = rotation

=C2=A0=

Hi all, I have a couple questions for = those of you who have implemented refresh token rotation...

=C2=A0

Have you included the option of a grace period on refres= h token use, allowing multiple uses within some time window? I'm wonder= ing because a grace period where a refresh token may be used more than once= would work around the problem that has been brought up,=C2=A0of a mobile a= pp accidentally using a refresh token more than once during normal operatio= n because different threads are unable to coordinate between themselves. Ho= wever that also kind of defeats the purpose since attacks within that grace= period would be hard to detect. I'm looking for an idea of where peopl= e have landed on that issue in practice.

=C2=A0

= If you have implemented a grace period, then how do you handle expiring the= additional refresh tokens that have been granted? For example, if RT "= ;R1" is used twice, resulting=C2=A0in new ATs "A1.1", "= A1.2" and new RTs "R1.1" and "R1.2", what happens = if "R1.2" is then later used? Would you invalidate "R1.1&quo= t; at that point? If so, why, and if not, why not?

<= div>

=C2=A0

It would be most interesting to hear practical experience from pe= ople who have already built refresh token rotation into a system.=

=C2=A0

Thanks!


---

Aaron Parecki<= /u>

<= div>

=C2=A0

=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000eba5d105b10883f4-- From nobody Tue Oct 6 23:10:24 2020 Return-Path: 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 6E9853A1128 for ; Tue, 6 Oct 2020 23:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 lBtp54Idw9cK for ; Tue, 6 Oct 2020 23:10:20 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 16D383A170A for ; Tue, 6 Oct 2020 23:10:05 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id y20so1163875iod.5 for ; Tue, 06 Oct 2020 23:10:05 -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; bh=2DmJK6ngtQcWSuFSEti+ZBBC815yXOzdLE2weXj9J8c=; b=oKrzpqczddGOMavS2NF+pXwdQkstbjFpI5ShGniG8GDdKb4txvxWscHux3+mI9deSS 8hzphFXPAFHVdtkCd1kUqsQL4yxVqGDl3eiUWCUwzzdcxy91Iq70dslB/xIbZEYjRlTN EKNZ4PibMWlWuLlsCBKb+CQF5BjxzJWDn1+hdKoSjkV/+iWubXTobOKSFhauJQcmJ0US ZUp3srVyb5UrcJFDgT6nanjusd68gnPM12+bUixfP5loHvOv/UUJ81xWqX+0d82xD0JZ p4IJ7ARYXbEtzdlZsaGw/37ML0JofZptrsYVCugEI3CVF5IxMN3DUpSiKlxVAzQhl1oh DePg== 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=2DmJK6ngtQcWSuFSEti+ZBBC815yXOzdLE2weXj9J8c=; b=gwsNxDXOE7uFkmjyIArTD/W2UQMVqkHIkI1OQz65nMxw+Nh4VsMm4rag6GgulePwmS F9QnSui7OoHbD45pj6R1THvpQ/jb/5xAQOmVpmKaE706lhssaEz2XEKEzX/DbJhLXeRs UMFj8MYVnc1H+4iC6xyOSYenZzZ5M4xj2eLFDtnVcrHLfzHr8SosczaAnBsCZOMNK/pF SJ85RUB67KZZeJNxDqQM7g9jEE5uwP9WSwHR4JIiEFv+eFHvuu4pu5RHUphlgQNGXatv 1toVdeDATyyoo0ID2aV/AcdxbCTZxIpNMncynJTDDiZR5dS88M/D4FiAzaXJRbpRclNN UEsw== X-Gm-Message-State: AOAM531jHlgGDBsHFwOk2vbjAI+3f4dwOkFn4GsYdt0+xokAnvOCVS7A Z3+t/AsFwDwMQfdxS6bffz9WsrgJJuOAVBG9jWxf7o4E X-Google-Smtp-Source: ABdhPJwlOpyQkJ5KHugaiGrrtJMrR2Z+K/RMe26KAy1emYminVRpqo8XAUm9jvmhYmtrGdX15O0V+l0p8zwoy/dKeVI= X-Received: by 2002:a5e:cb43:: with SMTP id h3mr1156056iok.65.1602051004183; Tue, 06 Oct 2020 23:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Janak Amarasena Date: Wed, 7 Oct 2020 11:39:28 +0530 Message-ID: To: Aaron Parecki Cc: oauth Content-Type: multipart/alternative; boundary="00000000000004379e05b10e9183" Archived-At: Subject: Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 06:10:22 -0000 --00000000000004379e05b10e9183 Content-Type: text/plain; charset="UTF-8" Hi Aaron, Let me clarify a bit. What I meant was the spec does not make it mandatory to use x-www-form-urlencoded I am stating this as I did not see any clause with the word "MUST" with regard to this. And also what I was asking was not to change using x-www-form-urlencoded to json. More like about the possibility of adding an example of how the parameters should be used if the request is sent in JSON format like shown in Justin's draft. This will in turn imply JSON formatted requests are also acceptable and to anyone who wants to support this media type has guidance. Best Regards, Janak Amarasena On Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki wrote: > The spec does clearly require form-encoded POST requests to the token > endpoint, it's not just an implication. The requests made include simple > key/value pairs so there's nothing really gained by making this a JSON > post. Changing that at this point would be a drastic breaking change to > pretty much all existing code for very little benefit if any. > > That said, Justin Richer did already write up a draft exploring this > topic, but it hasn't shown much interest in the group yet. > > https://www.ietf.org/id/draft-richer-oauth-json-request-00.html > > Aaron > > > > > > > On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasena > wrote: > >> Hi All, >> >> As per my understanding OAuth 2(RFC6749) doesn't mandate any specific >> media type to be used in the access token request. The spec implies >> application/x-www-form-urlencoded should be used. Since the media type >> application/json is very popular and widely used now, any thoughts on >> referencing the use of this as well for access token requests? >> >> Best Regards, >> Janak Amarasena >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > --- > Aaron Parecki > https://aaronparecki.com > > --00000000000004379e05b10e9183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aaron,

Let me clarify a bit. What I = meant was the spec does not make it mandatory to use=C2=A0x-www-form= -urlencoded I am stating this as I did not see any clause with the w= ord "MUST" with regard to this. And also what I was asking=C2=A0w= as not to change using=C2=A0x-www-form-urlencoded=C2=A0to jso= n. More like about the possibility of adding an example of how the paramete= rs=C2=A0should be used if the request is sent in JSON format like shown in = Justin's draft. This will in turn imply JSON formatted requests are als= o acceptable and to anyone who wants to support this media type has guidanc= e.

Best Regards,
Janak Amarasena

On= Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki <aaron@parecki.com> wrote:
The spec does= clearly require form-encoded POST requests to the token endpoint, it's= not just an implication. The requests made include simple key/value pairs = so there's nothing really gained by making this a JSON post. Changing t= hat at this point would be a drastic breaking change to pretty much all exi= sting code for very little benefit if any.

That said, Justin Richer did already write up a draft ex= ploring this topic, but it hasn't shown much interest in the group yet.=

Aaron






On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasen= a <janakama36= 0@gmail.com> wrote:
Hi All,

As per my understand= ing OAuth 2(RFC6749) doesn't mandate any specific media type to be used= in the access token request. The spec implies=C2=A0application/x-www= -form-urlencoded=C2=A0should be used. Since the media type=C2= =A0application/json=C2=A0is very popular and widely used now, any thoughts on refere= ncing the use of this as well for access token requests?

Best Regards,
Janak Amarasena
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
---<= /div>Aaron Parecki

--00000000000004379e05b10e9183-- From nobody Wed Oct 7 00:20:50 2020 Return-Path: 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 D66BD3A119C for ; Wed, 7 Oct 2020 00:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 fCZOiTM7hTDA for ; Wed, 7 Oct 2020 00:20:46 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E00E73A0DEF for ; Wed, 7 Oct 2020 00:20:45 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id g12so885750wrp.10 for ; Wed, 07 Oct 2020 00:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=dTQaoCND23ZY11Kj/XRkGi/s+Q15SIZjppHzRDl6GKk=; b=Hfn/7nFl4mj9cdCuWl3X24GrFzkKOvwV120vrGN+SabjxB3HbVY7jXSxIuQ3OayqaR CtKNKlMR8H086n5+DTszQfNng2+NidKNJvKOGYUksm6d3OnEOC6KuDagoSuiGWJLFzIg ZpkCeftN/2rDRli4OMtCFlya/yNYcWXi8oXqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=dTQaoCND23ZY11Kj/XRkGi/s+Q15SIZjppHzRDl6GKk=; b=FfVX3vnxf83HBRiAMBEwtwPvf7Nbr/cCfHn9mF5rUN9DB+ttRTOp269TpRzwWnVBOD sOWfeO2lJzfgKGhidcMPKOXqPx9OHNH4471f8chCQXMfrhbt0xcwndqyQvQpaiTURD5I 41r2ntXHcJk8pKwAkokuZRKp+kcswyoLICVeI+EeDxPK37NFct/W/PACAbneCc3549on xfyzWCmxMTeR1ttY6rfrunzjf8M9RQCxAALO9ec356sG3j2ITXL+WuHZ5M7pHP4/Jyp0 m3qOJ458/a8vX+GH+cx99yxI+KSQjS37tmagorZfYOYYnbu5cWFqsDI/KVM6hEkyGk2t LDkA== X-Gm-Message-State: AOAM5309hhduybmAopG0cd4Dnc338Ywml41oRP1vu/0IpQIHqf0x/l69 4GAlGZ/nF/0RHHuQ3ddFAoZiTxfkbaP2Kt1ED1TYy7h3BZKuNKHDxxaf/trR+XlEtj6yf1PFHBd p/GVRg0FcjLGX516lZv0UmbWOSjlWWh7BJqbfso7voS9V8agAhH0F3hphL/nctl/WAqQkqiA= X-Google-Smtp-Source: ABdhPJwdGjvbj0wIm3uPO6ZzaYyT9jzIuF0tFEVPcLicgcWuDSu0nON3V+SeQBCXvsNDvEb58x+Ihw== X-Received: by 2002:adf:fbc5:: with SMTP id d5mr1785613wrs.232.1602055243216; Wed, 07 Oct 2020 00:20:43 -0700 (PDT) Received: from [10.0.0.5] (45.133.143.150.dyn.plus.net. [150.143.133.45]) by smtp.gmail.com with ESMTPSA id o129sm1429230wmb.25.2020.10.07.00.20.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 00:20:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-94A1AFC1-0609-438F-B835-EAFBD79FE40D Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Wed, 7 Oct 2020 08:20:41 +0100 Message-Id: <1611ED62-651C-4657-84A9-FF04CDF6903A@forgerock.com> References: Cc: OAuth WG In-Reply-To: To: Aaron Parecki X-Mailer: iPhone Mail (17H35) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 07:20:49 -0000 --Apple-Mail-94A1AFC1-0609-438F-B835-EAFBD79FE40D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 6 Oct 2020, at 23:05, Aaron Parecki wrote: >=20 > =EF=BB=BF > Hi all, I have a couple questions for those of you who have implemented re= fresh token rotation... >=20 > Have you included the option of a grace period on refresh token use, allow= ing multiple uses within some time window? I'm wondering because a grace per= iod where a refresh token may be used more than once would work around the p= roblem that has been brought up, of a mobile app accidentally using a refres= h token more than once during normal operation because different threads are= unable to coordinate between themselves. However that also kind of defeats t= he purpose since attacks within that grace period would be hard to detect. I= 'm looking for an idea of where people have landed on that issue in practice= . Right. We=E2=80=99ve avoided adding a grace period for this reason. An attac= ker in a position to steal a refresh token is also presumably in a position t= o see when the legitimate client uses it and then sneak in just afterwards w= ithin the grace period. You could maybe only allow grace period refreshes fr= om the same IP address but I=E2=80=99m not sure that would always hold in th= e flaky mobile network scenarios (eg refresh fails on 2G due to disconnect t= hen client switches to Wifi hotspot and retries).=20 > If you have implemented a grace period, then how do you handle expiring th= e additional refresh tokens that have been granted? For example, if RT "R1" i= s used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1= .2", what happens if "R1.2" is then later used? Would you invalidate "R1.1" a= t that point? If so, why, and if not, why not? >=20 > It would be most interesting to hear practical experience from people who h= ave already built refresh token rotation into a system. >=20 > Thanks! >=20 > --- > Aaron Parecki > https://aaronparecki.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-94A1AFC1-0609-438F-B835-EAFBD79FE40D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 6 Oct 2020, at 23:05, Aaron Parecki <aaron@= parecki.com> wrote:

<= div dir=3D"ltr">=EF=BB=BF
Hi all, I have a couple quest= ions for those of you who have implemented refresh token rotation...

Have you included the option of a grace period on refresh t= oken use, allowing multiple uses within some time window? I'm wondering beca= use a grace period where a refresh token may be used more than once would wo= rk around the problem that has been brought up, of a mobile app acciden= tally using a refresh token more than once during normal operation because d= ifferent threads are unable to coordinate between themselves. However that a= lso kind of defeats the purpose since attacks within that grace period would= be hard to detect. I'm looking for an idea of where people have landed on t= hat issue in practice.

Rig= ht. We=E2=80=99ve avoided adding a grace period for this reason. An attacker= in a position to steal a refresh token is also presumably in a position to s= ee when the legitimate client uses it and then sneak in just afterwards with= in the grace period. You could maybe only allow grace period refreshes from t= he same IP address but I=E2=80=99m not sure that would always hold in the fl= aky mobile network scenarios (eg refresh fails on 2G due to disconnect then c= lient switches to Wifi hotspot and retries). 

If you have impl= emented a grace period, then how do you handle expiring the additional refre= sh tokens that have been granted? For example, if RT "R1" is used twice, res= ulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what ha= ppens if "R1.2" is then later used? Would you invalidate "R1.1" at that poin= t? If so, why, and if not, why not?

It would be mos= t interesting to hear practical experience from people who have already buil= t refresh token rotation into a system.

Thanks!
---
Aaron Parecki

_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
= --Apple-Mail-94A1AFC1-0609-438F-B835-EAFBD79FE40D-- From nobody Wed Oct 7 03:02:09 2020 Return-Path: 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 C21973A0799 for ; Wed, 7 Oct 2020 03:02:07 -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 70qzlRQyf7KQ for ; Wed, 7 Oct 2020 03:02:06 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 B36753A047D for ; Wed, 7 Oct 2020 03:02:05 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id f21so1348418ljh.7 for ; Wed, 07 Oct 2020 03:02:05 -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; bh=xTUoUz+yekcg55VDIWd3othPM6qaj2yMzwoK/sP1uNs=; b=m58rFUWncFaIyhDldLHMacCyRvWMf1A3+FpsLMKxap0WjqOANNAh37A30+JstVgeVF urQZhVRS+V0zF5x+2AZw3zHr5u7QW1uI2XcVojTwx5KwvdD8O97yXvy3BqS8G8aFc0qp DpvKCLzW+V5jMoB/l/NapRir7/zn77383Yqkgoc0bNbLkraVfk80FO7+rkSl+5Dd2TfZ T1CIIBBEBDFX+0Uk/QwjL4eXFDSbjENSTM7/bomoxmpPJapnXGQ5gORY6m8vTFBMUq2r AihZvTJRwHCAju8DNKKzaoOalAw8h/VmQODLDjcNF43GZMMZFxHB2kkLPuQYCx9H7+SK +ihQ== 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=xTUoUz+yekcg55VDIWd3othPM6qaj2yMzwoK/sP1uNs=; b=VPQIigHDvo+Z5npsiERYeMbDaMSL7Y2OnkojuAdvQJyHh1/fvxdG4S2oJiA0lKaIdg FZRO7lAy9g+qYuFM0V95BCEshmvPBrrqhUDXlRpEXhLIhoR2nsON85ZwvZs/BfBtMS5i F2ChkPy+xSpPvfrBlLtvnm8Bfg7hqe5U5/WzMq6s6G63Z/M2DbK9vyVirF3quNwz1XYz TCpW7BeUcrvzuyEsC6mt4tW83F88OWec6uOGjJ/w7LMR8o23P50NnkQycV93iW8A8UYv kFP8KNhCtUVX2asOEIQRuRzSlpJe/480MoGrrok0sSWa5kKyJOYUD99acQS0uAI4XL9s hTmA== X-Gm-Message-State: AOAM533ivGFU0ePBaT9V4ApTubZ+sFKsHf6VMQvkx19CZ1p+BHIVJ9Rj OJblDbJM2E3G51P3qNGC44uc8CFExcFoMkXJxXM= X-Google-Smtp-Source: ABdhPJx7WoKMpDMNanMWbife2njVsjemoRX4ek+n61yUhXrVA4hUGXPgVy7e6UKv74n5uMb1qrAHwjLSrapf2JWQths= X-Received: by 2002:a2e:9e44:: with SMTP id g4mr830753ljk.246.1602064923366; Wed, 07 Oct 2020 03:02:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 7 Oct 2020 03:01:27 -0700 Message-ID: To: Janak Amarasena Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="000000000000aa1a1205b111ce99" Archived-At: Subject: Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 10:02:08 -0000 --000000000000aa1a1205b111ce99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Janak, thanks for the clarification. A constraint of the OAuth 2.1 draft is that it adds no new features beyond what has already been standardised and deployed. While I am a fan of JSON, supporting both application/x-www-form-urlencoded and application/json will negatively impact interoperability and add complexity as the content type will need to be negotiated. If it is any consolation, GNAP is starting off with application/json. /Dick =E1=90=A7 On Tue, Oct 6, 2020 at 11:10 PM Janak Amarasena wrote: > Hi Aaron, > > Let me clarify a bit. What I meant was the spec does not make it mandator= y > to use x-www-form-urlencoded I am stating this as I did not see any > clause with the word "MUST" with regard to this. And also what I was > asking was not to change using x-www-form-urlencoded to json. More like > about the possibility of adding an example of how the parameters should b= e > used if the request is sent in JSON format like shown in Justin's draft. > This will in turn imply JSON formatted requests are also acceptable and t= o > anyone who wants to support this media type has guidance. > > Best Regards, > Janak Amarasena > > On Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki wrote: > >> The spec does clearly require form-encoded POST requests to the token >> endpoint, it's not just an implication. The requests made include simple >> key/value pairs so there's nothing really gained by making this a JSON >> post. Changing that at this point would be a drastic breaking change to >> pretty much all existing code for very little benefit if any. >> >> That said, Justin Richer did already write up a draft exploring this >> topic, but it hasn't shown much interest in the group yet. >> >> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html >> >> Aaron >> >> >> >> >> >> >> On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasena >> wrote: >> >>> Hi All, >>> >>> As per my understanding OAuth 2(RFC6749) doesn't mandate any specific >>> media type to be used in the access token request. The spec implies >>> application/x-www-form-urlencoded should be used. Since the media type >>> application/json is very popular and widely used now, any thoughts on >>> referencing the use of this as well for access token requests? >>> >>> Best Regards, >>> Janak Amarasena >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> --- >> Aaron Parecki >> https://aaronparecki.com >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000aa1a1205b111ce99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Janak, thanks for the clarification.

A = constraint of the OAuth 2.1 draft is that it adds no new features beyond wh= at has already been standardised and deployed.

Whi= le I am a fan of JSON, supporting both=C2=A0application/x-www-form-urlencoded and=C2=A0app= lication/json will negatively impact interoperability and add complexity as= the content type will need to be negotiated.

If i= t is any consolation, GNAP is starting off with application/json.

/Dick
3D""=E1=90=A7

On Tue, Oct 6, 20= 20 at 11:10 PM Janak Amarasena <janakama360@gmail.com> wrote:
Hi Aaron,

Let me = clarify a bit. What I meant was the spec does not make it mandatory to use= =C2=A0x-www-form-urlencoded I am stating this as I did not se= e any clause with the word "MUST" with regard to this. And also w= hat I was asking=C2=A0was not to change using=C2=A0x-www-form-urlenc= oded=C2=A0to json. More like about the possibility of adding an exam= ple of how the parameters=C2=A0should be used if the request is sent in JSO= N format like shown in Justin's draft. This will in turn imply JSON for= matted requests are also acceptable and to anyone who wants to support this= media type has guidance.

Best Regards,
= Janak Amarasena

On Tue, Oct 6, 2020 at 8:40 PM Aaron Parecki <aaron@parecki.com>= wrote:
The spec does clearly require form-encoded POST requests to the t= oken endpoint, it's not just an implication. The requests made include = simple key/value pairs so there's nothing really gained by making this = a JSON post. Changing that at this point would be a drastic breaking change= to pretty much all existing code for very little benefit if any.

That said, Justin Richer did alre= ady write up a draft exploring this topic, but it hasn't shown much int= erest in the group yet.

Aaron






On Tue, Oct 6, 2020 at 7:= 18 AM Janak Amarasena <janakama360@gmail.com> wrote:
Hi All,

As per my understanding OAuth 2(RFC6749) doesn't mandate any specific= media type to be used in the access token request. The spec implies=C2=A0<= font face=3D"monospace" style=3D"font-family:monospace;color:rgb(0,0,0)">ap= plication/x-www-form-urlencoded=C2=A0should be used. S= ince the media type=C2=A0application/json=C2=A0is very popular and widely used now, = any thoughts on referencing the use of this as well for access token reques= ts?

Best Regards,
Janak Amarasena
<= /div> _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
---<= /div>Aaron Parecki

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000aa1a1205b111ce99-- From nobody Wed Oct 7 04:46:28 2020 Return-Path: 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 EE3DD3A0A7B for ; Wed, 7 Oct 2020 04:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 isLWAPgWKL23 for ; Wed, 7 Oct 2020 04:46:24 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 6C8793A0A6F for ; Wed, 7 Oct 2020 04:46:24 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id o64so660906uao.1 for ; Wed, 07 Oct 2020 04:46:24 -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; bh=yQ/JjSvzbUZR3rnqt0EbXrtrR/Ugzijq98KCh+0A2q4=; b=pjS+fYEd1YTbbsy2922QtiJ/ymhHJtr0ICcS+4nBhiX1BHObohVJJW4gaL24sNjErp HlmFaEWGHcNbtSRdBXfI1RQNv6yyb8RK4H2izF45DFs1obs0z2njOtNq/P6sJglQmKrA U+oOZ3m/AFI2MBUymrkfg2ebHU3o+dgec+/deDlJxpzVUYrmKU4zE8MuOucrleHDNfBC Rw9g3P/arxJ3xT1KNJwBsa5naMxfx61vM9IQydDq7QiK1f6yh6GsLX06ptsIUkW029P4 KTXCCsY/bDshzl2YBWmuXz/o+tgOz33B5fPfCjahiZfAwkIg3LKQBJZvZ9IC59IYtnAy ho9Q== 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=yQ/JjSvzbUZR3rnqt0EbXrtrR/Ugzijq98KCh+0A2q4=; b=daBnrciVOebihTbYkPJ5WaXajQX3hXd5xRXsP/GAqvnzm8t+0Vy4YpcdT08jlcF5tB SDTxFl5P15eF54I8lSsInEOIlg6xPCJz0FH/s6PP3PXxrTbzbWXMdjNjDURYVE/ms6dA k0/83/7a0dB2gkLW89CyFrcrsq6+QT201gvDFllvwybTQ/KfNMTYRcMuNE17lUdlEWfg jMFalFW2mLE7XDnhsu++ruJD0bQwET+NWC7B7WPscnwcq4NMDIe4m+PKg/IMnmyMPZRV BYfMj/GH4kxZbLax+iZrTfhYzReFmIE80K76v9oG4T9/JoNH36ebBHSijU5XslP1vzTg 41bg== X-Gm-Message-State: AOAM532Lc/EsLPcw2y53VTkBHK2RUScbI7BH4mnrAeFzn/plT4Z4SwbU MnPhB9geW84+Ct5IivCyKCDLF8AAWD6FIl39n6k= X-Google-Smtp-Source: ABdhPJw003w2ybZa3IZFE8vpcaZ4a7O2DCicDk5sECAOGiZR7eq+wndZVlyeL63Sw0PcYUbo8gYqx5hu7wGv8nGdMZ4= X-Received: by 2002:ab0:5e8:: with SMTP id e95mr1181853uae.57.1602071183431; Wed, 07 Oct 2020 04:46:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: 0x0010thx Date: Wed, 7 Oct 2020 18:46:10 +0700 Message-ID: To: Janak Amarasena Cc: oauth Content-Type: multipart/alternative; boundary="000000000000cb1bb505b1134365" Archived-At: Subject: Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 11:46:26 -0000 --000000000000cb1bb505b1134365 Content-Type: text/plain; charset="UTF-8" hihi i am sorry my run me code scope runtime is work hehehe good Trisna1337 Pada tanggal Sel, 6 Okt 2020 21:18, Janak Amarasena menulis: > Hi All, > > As per my understanding OAuth 2(RFC6749) doesn't mandate any specific > media type to be used in the access token request. The spec implies > application/x-www-form-urlencoded should be used. Since the media type > application/json is very popular and widely used now, any thoughts on > referencing the use of this as well for access token requests? > > Best Regards, > Janak Amarasena > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000cb1bb505b1134365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hihi i am sorry my run me code scope runtime=C2=A0 is wor= k=C2=A0

hehehe good

Trisna1337

Pad= a tanggal Sel, 6 Okt 2020 21:18, Janak Amarasena <janakama360@gmail.com> menulis:
Hi All,

As per m= y understanding OAuth 2(RFC6749) doesn't mandate any specific media typ= e to be used in the access token request. The spec implies=C2=A0applica= tion/x-www-form= -urlencoded=C2=A0should be used. Since the media type=C2=A0application/json=C2=A0is very popular and widely used now, a= ny thoughts on referencing the use of this as well for access token request= s?

Best Regards,
Janak Amarasena
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000cb1bb505b1134365-- From nobody Wed Oct 7 10:45:50 2020 Return-Path: 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 2BCE33A0CF8 for ; Wed, 7 Oct 2020 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=trustap-com.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 gl2jeVGCO1Wq for ; Wed, 7 Oct 2020 10:45:44 -0700 (PDT) Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 839B13A0CEC for ; Wed, 7 Oct 2020 10:45:44 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id p13so3074443edi.7 for ; Wed, 07 Oct 2020 10:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0oomEuPZhPrbLAPbmYTT9F2nA3pwRCJEO4kox8I38IU=; b=x5gh9homVCnH/qQ/Z6zgLZlb7MKk4Mm+lD8rMde5y6Msk2rP1mdmU0mXZZBg5JMy5m 6HTKC4jBEyB4aLqW4G7XnpkOaBUJFhTD4V5OejP59p17cLgCsBswkfdlcpHynBhn9rfV Nc+PT9PI6UFB7/RCsQJLY6NFcBLnepDIvLLpI64qVZtYutLoVz/PifXQGNok9Y+nJkxH NLglecmxGNexNetRJxbGeshmzUTjFU+6VHTMnZ6QYseGEDEUt+GV3FzAfb17LrhI/H59 nHxNOZ1wfYomAWZw4L63KtkY7NWwUMOvWr3jwhwT5TaS28djFMwCoKLxdyHICS99ZBvI PJ2g== 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=0oomEuPZhPrbLAPbmYTT9F2nA3pwRCJEO4kox8I38IU=; b=JIhQlsft6rIki6+k+c/voQWfDOvpXSI5j/nhDswzcIb5+lI9CUfNQOOGc+Hhy236DA OtX42C7Q4CU3i5jymjJWpxKb/Pl6zIny7oJGt5vLucObwXVOCTR01F/Gl6VyXR69rIY2 U2yH1PUy3P4UVKPnTTUMGQaZqQvxVCeYX+IzozJ/snM6z0s7vjksD9+jDeTAeVGQvCxd Wo7GB1XCRwmyT688jVm1soElga1WVgwxdf1YmdhyWnmfDbpLryMtEF9JSNqo3+IcMiMf X41mWG0aMP0fkMJSNPVpNumzRXGy/HVNqWw+yu+gQe6iINPI2y9EQ5Zp/b5fXnm6W5nl KlAg== X-Gm-Message-State: AOAM53382CGYPl+rzIhLJ5Cu3Ua3KnYG8GfGKiLZGwhiPUUJZQL0SP6R ZBS1114j5SZmFbjMCzQQzRuCc69zh3/sSwMUNhWS1wabyfMAPA== X-Google-Smtp-Source: ABdhPJx23wBoWFx3PJ1qIxUgnYSO2nVFwBhVxjBQK4x0Ancwt8FuW4fO6UsjDnFbP+YpY80HI+qUDmDIs0r+nlz5B4E= X-Received: by 2002:aa7:c984:: with SMTP id c4mr4739584edt.42.1602092742858; Wed, 07 Oct 2020 10:45:42 -0700 (PDT) MIME-Version: 1.0 References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> <064801d69c2b$229141c0$67b3c540$@auth0.com> In-Reply-To: <064801d69c2b$229141c0$67b3c540$@auth0.com> From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= Date: Wed, 7 Oct 2020 18:45:31 +0100 Message-ID: To: vittorio.bertocci=40auth0.com@dmarc.ietf.org Cc: Andrii Deinega , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5f7dc05b1184888" Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 17:45:47 -0000 --000000000000d5f7dc05b1184888 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Long time lurker, first time poster, glad to be finally getting involved! In terms of weighing in on the revocation practice, I don't think this document needs to address it as JWT ATs don't seem to require special handling in this case. I think a general coverage of approaches to token revocation would be more appropriate in a BCP. One thing I'm unsure of when reading this is how a RS can depend on an AS to give it a JWT AT. Due to the opaque nature of ATs, it seems natural that an AS can change the AT profile it uses at its own discretion, but there's no negotiation or parameter that can force an AS to return a JWT AT, with the potential for breakages. Do the RS and AS agree on the profile ahead of time? Perhaps this is specified in a separate document, but I think the topic of profile negotiation should be covered in this document, even at a high level, or reference to more detailed coverage. A few other notes on the document itself: - Section 2.1: Is there precedence of "application/at+jwt" being used in the wild that prevents the SHOULD from being a MUST? - Figure 1: Nitpick: An `&` that looks like it should prefix `state` is on the preceding line. - Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`? - Section 4: This is a personal opinion, but I'd recommend moving the step concerning `aud` validation to the top of the list, for focus. This= is because, having personally taken more than a little while to figure out = the difference between access tokens and ID tokens, I see the risk of cross-= JWT confusion as very relevant. I think the necessity of the other steps are= a bit more obvious. Thanks! Kind regards, Se=C3=A1n. On Tue, 6 Oct 2020 at 22:53, wrote: > Hi Andrii, > > Thanks for the thoughtful comments! Here=E2=80=99s my 2 c. > > > > On the proposed language: given that the JWT AT profile is just providing > more details on the content of an AT, making JWT ATs a proper subset of a= ll > ATs, readers should have no reason to believe that introspection or any > other existing spec discussing AT behavior should operate differently. Th= at > assumption holds for everything across the board, hence it would be a bit > odd to call out this particular case. On the userinfo case, I would find = it > even more left field to say anything about it. > If we do reach a consensus on specific revocation practices that apply to > JWT ATs specifically, and we conclude that they should live in this > document, I will be happy to add language accordingly. > > > > On the AJWT: I hear you on the dissonance that JWT AT carries, but I am > very hesitant to introduce new acronyms to an already crowded/impenetrabl= e > domain. > JWT access token might not roll off the tongue, but at this point =E2=80= =98JWT=E2=80=99 is > nearly a proprietary eponym and the expression =E2=80=9CJWT token=E2=80= =9D is > extraordinarily common in literature, a quick google query will give you > the full measure of the phenomenon, hence I think we=E2=80=99ll be OK wit= h the > current form. > > Cheers, > > V. > > > > *From:* Andrii Deinega > *Sent:* Tuesday, October 6, 2020 2:25 PM > *To:* vittorio.bertocci@auth0.com; oauth@ietf.org > *Cc:* Jim Manico ; Nicolas Mora > *Subject:* Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > > Vittorio and WG, > > > > Would it be possible to include something like the following to > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 > > > In case the authorization server exposes the introspection, revocation, > and OpenID Connect userinfo endpoints they MUST act in the same way as it > happens with a regular access token. That allows the AS to change the typ= e > of an access token on the fly and that won=E2=80=99t lead to interoperate= issues. > Plus, the consumers of these endpoints use them regardless of the type of > access token. > > > > The way how the AS can notify RSs that the token revocation event happene= d > (if it decides to do so) is completely left to implementers. > > > > ? > > > > Another minor editorial thing from me is it would possible to change and > refer to "JWT access tokens" as AJWT. Thus, this document won't repeat th= e > token word twice. > > > > Regards, > > Andrii > > > > On Tue, Oct 6, 2020 at 2:22 PM 40auth0.com@dmarc.ietf.org> wrote: > > Hey Jim, regarding > > Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents the a= bility of > a client to access a given resource; the fact that it requires an > authentication transaction/session establishment to be issued to the clie= nt > does not mean that the AT lifetime is tied to the lifetime of that sessio= n. > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, i= t > doesn=E2=80=99t matter whether I stay logged in their web app or otherwis= e. Even if > I log out of the session in which context I got my twitter AT, I can stil= l > post on LinkedIn from my native LinkedIn app and the corresponding post > will show up on twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to originating > sessions lifetime, see the discussion on the OpenID Connect group about a > possible online_access scope for influencing RTs and Ats (in particular, = in > the context of SPAs) but that's additional semantic that isn=E2=80=99t de= fined > today. > > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > In this model, considering that token revocations don't happen a lot... > > Just a brief note, a secure piece of software makes the logout feature > prominent. Every logout event should trigger token revocation. > > I=E2=80=99m mentioning this because a lot of OAuth solutions in the mobil= e space > literally ignore the logout event, such as Facebook=E2=80=99s mobile OAut= h > solution. > > - Jim > > > On Oct 4, 2020, at 6:55 AM, Nicolas Mora wrote= : > > > > =EF=BB=BFHello, > > > >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > >> > >> There might be some kind of pushed events between the AS and the RS > when > >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at > all. > >> Like this, the RS knows if a JWT AT has been revoked or not. > >> > >> > >> If there are some kind of pushed events between the AS and the RS, > >> then it could push the revoked (and/or expired) opaque AT too, giving > >> almost no advantage to JWT ATs. > >> > > Not necessarily, let's say the AS informs the RS only of the revoked > > ATs, when a RS checks an AT, it verifies the signature first, then the > > claims, then checks if the AT has been revoked by checking its > > internal list filled by the AS pushed events. > > > > In this model, considering that token revocations don't happen a lot, > > the ratio revoked AT/valid AT is very low, so the advantage of a JWT > > is important, because it means not so much communication between the > > AS and the RSs, and a very reliable AT. > > > > But this means a communication mechanism that isn't standardized yet. > > > > /Nicolas > > > > _______________________________________________ > > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d5f7dc05b1184888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Long time lurker, first time poster, glad t= o be finally getting involved!

In terms of weighing in on the revoca= tion practice, I don't think this document needs to address=C2=A0it as = JWT ATs don't seem to require=C2=A0special handling in this case. I thi= nk a general=C2=A0coverage of approaches to token revocation would be more = appropriate in a BCP.

One thing I'm unsure of when reading this = is how a RS can depend on an AS to give it a JWT AT. Due to the opaque natu= re of ATs, it seems natural that an AS can change the AT profile it uses at= its own discretion, but there's no negotiation or parameter that can f= orce an AS to return a JWT AT, with the potential for breakages. Do the RS = and AS agree on the profile ahead of time?=C2=A0 Perhaps this is specified = in a separate document, but I think the topic of profile negotiation should= be covered in this document, even at a high level, or reference to more de= tailed=C2=A0coverage.

A few other notes on the document itself:
<= ul>
  • Section 2.1: Is there precedence of "application/at+jwt" b= eing used in the wild that prevents the SHOULD from being a MUST?
  • F= igure 1: Nitpick: An `&` that looks like it should prefix `state` is on= the preceding line.
  • Figure 2: The example `typ` is `at+JWT`, shoul= d this be `at+jwt`?
  • Section 4: This is a personal opinion, but I= 9;d recommend moving the step concerning `aud` validation to the top of the= list, for focus. This is because, having personally taken more than a litt= le while to figure out the difference between access tokens and ID tokens, = I see the risk of cross-JWT confusion as very relevant. I think the necessi= ty of the other steps are a bit more obvious.
    • Thanks!

    Kind = regards,

    Se=C3=A1n.

    On Tue, 6 Oct 2020 at 22:53, <vittorio.ber= tocci=3D40auth0.com@dmarc.iet= f.org> wrote:

    Hi Andrii,

    Thanks for the thoughtful comments! Here=E2=80=99s my 2 c.

    =C2=A0

    = On the proposed language: given that the JWT AT profile is just providing m= ore details on the content of an AT, making JWT ATs a proper subset of all = ATs, readers should have no reason to believe that introspection or any oth= er existing spec discussing AT behavior should operate differently. That as= sumption holds for everything across the board, hence it would be a bit odd= to call out this particular case. On the userinfo case, I would find it ev= en more left field to say anything about it.
    If we do reach a consensus = on specific revocation practices that apply to JWT ATs specifically, and we= conclude that they should live in this document, I will be happy to add la= nguage accordingly.

    =C2=A0

    On the AJWT: I hear you on the dissonance t= hat JWT AT carries, but I am very hesitant to introduce new acronyms to an = already crowded/impenetrable domain.
    JWT access token might not roll off= the tongue, but at this point =E2=80=98JWT=E2=80=99 is nearly a proprietar= y eponym and the expression =E2=80=9CJWT token=E2=80=9D is extraordinarily = common in literature, a quick google query will give you the full measure o= f the phenomenon, hence I think we=E2=80=99ll be OK with the current form.<= u>

    Cheers,

    V.

    =C2=A0<= /u>

    From: Andrii Deinega <andrii.deinega@gmail.com>
    Sent:= Tuesday, October 6, 2020 2:25 PM
    To: vittorio.bertocci@auth0.com; oauth@ietf.org
    Cc= : Jim Manico <= jim@manicode.com>; Nicolas Mora <nicolas@babelouest.org>
    Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

    =C2=A0

    Vittorio and WG,

    =C2=A0

    Would it be = possible to include something like the following to htt= ps://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10=


    In case the authorization server=C2= =A0exposes the introspection, revocation, and OpenID Connect userinfo endpo= ints=C2=A0they MUST act in the same way as it happens with a regular access= token. That allows the AS to change the type of an access token on the fly= and that won=E2=80=99t lead to interoperate issues. Plus, the consumers of= these endpoints use them regardless of the type of access token.=

    =C2=A0

    The way how the AS can notify RSs that the token r= evocation event happened (if it decides to do so) is completely left to=C2= =A0implementers.

    = =C2=A0

    ?

    =C2=A0

    Another minor editorial thing from me is it would possible to c= hange and refer to "JWT access tokens" as AJWT. Thus, this docume= nt won't repeat the token word twice.

    =C2=A0

    Regards,

    Andrii<= u>

    =C2=A0

    <= div>

    On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bert= occi=3D40au= th0.com@dmarc.ietf.org> wrote:

    Hey Jim, regarding
    > Every logout eve= nt should trigger token revocation
    That isn=E2=80=99t necessarily the ca= se. An access token represents the ability of a client to access a given re= source; the fact that it requires an authentication transaction/session est= ablishment to be issued to the client does not mean that the AT lifetime is= tied to the lifetime of that session. Say that I allow LinkedIn to tweet o= n my behalf. Once I have done that, it doesn=E2=80=99t matter whether I sta= y logged in their web app or otherwise. Even if I log out of the session in= which context I got my twitter AT, I can still post on LinkedIn from my na= tive LinkedIn app and the corresponding post will show up on twitter as wel= l.
    Now, one might choose to *explicitly* tie tokens lifetime to originat= ing sessions lifetime, see the discussion on the OpenID Connect group about= a possible online_access scope for influencing RTs and Ats (in particular,= in the context of SPAs) but that's additional semantic that isn=E2=80= =99t defined today.

    -----Original Message-----
    From: OAuth <oauth-bounces@iet= f.org> On Behalf Of Jim Manico
    Sent: Sunday, October 4, 2020 5:17= PM
    To: Nicolas Mora <nicolas@babelouest.org>
    Cc: oauth@ietf.org
    Subject: Re: [OAUTH-WG] J= WT access tokens and the revocation endpoint

    > In this model, con= sidering that token revocations don't happen a lot...

    Just a bri= ef note, a secure piece of software makes the logout feature prominent. Eve= ry logout event should trigger token revocation.

    I=E2=80=99m mention= ing this because a lot of OAuth solutions in the mobile space literally ign= ore the logout event, such as Facebook=E2=80=99s mobile OAuth solution.
    - Jim

    > On Oct 4, 2020, at 6:55 AM, Nicolas Mora <nicolas@babelouest.org= > wrote:
    >
    > =EF=BB=BFHello,
    >
    >> Le 20= -10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit :
    >>
    >>= ;=C2=A0 =C2=A0 There might be some kind of pushed events between the AS and= the RS when
    >>=C2=A0 =C2=A0 a JWT AT is revoked, to allow the RS = not to introspect a JWT AT at all.
    >>=C2=A0 =C2=A0 Like this, the = RS knows if a JWT AT has been revoked or not.
    >>
    >>
    = >> If there are some kind of pushed events between the AS and the RS,=
    >> then it could push the revoked (and/or expired) opaque AT too= , giving
    >> almost no advantage to JWT ATs.
    >>
    > = Not necessarily, let's say the AS informs the RS only of the revoked > ATs, when a RS checks an AT, it verifies the signature first, then t= he
    > claims, then checks if the AT has been revoked by checking its =
    > internal list filled by the AS pushed events.
    >
    > In = this model, considering that token revocations don't happen a lot,
    = > the ratio revoked AT/valid AT is very low, so the advantage of a JWT <= br>> is important, because it means not so much communication between th= e
    > AS and the RSs, and a very reliable AT.
    >
    > But thi= s means a communication mechanism that isn't standardized yet.
    > =
    > /Nicolas
    >
    > ________________________________________= _______
    > 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
    <= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --000000000000d5f7dc05b1184888-- From nobody Thu Oct 8 03:21:33 2020 Return-Path: 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 482B13A0A1C for ; Thu, 8 Oct 2020 03:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=lodderstedt.net 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 9NVc5hyFXphb for ; Thu, 8 Oct 2020 03:21:30 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 EA4203A0138 for ; Thu, 8 Oct 2020 03:21:29 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id t21so5254129eds.6 for ; Thu, 08 Oct 2020 03:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IxX3lT5a8wUGNNfGSMC3YukBZMEeQI4WeXAkZh4mczo=; b=vT2ODjZzx1gZ784MmCB+1whSA1OvJOQ1OMfBp2bFl6iqT4PnI56aPhDVR6cO7LXnU2 jHyzs2fkfwzuyDSjwAgsB5wJRky2TZtEYiXsNfezCxoLkX64HkEAODWz5KN3iuTFAAXz SPruGkvJVkjYbCtExPcC25OqXeJs5h7AUXzkN9f8tTIaT8uFmi32szmvb1AWXkFox81O 4fmYVvBsF/svUHsYiUzuA2MN/06FMM7/iHP3zeh8Kw5z20VzduHZQdaQUxoiM31IUkHM /yDn5vpV7YeJLeBLyHoFd6NWRwod5a/H0w7bMt03ZSCCDBt6insvZMlOAsLwH2B2L0qx sHdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IxX3lT5a8wUGNNfGSMC3YukBZMEeQI4WeXAkZh4mczo=; b=mmlS2mn+Q0Gu/qKkZp6wE8sfv782QZGriJd9fTSRNXq+U0eqJGCrbIRh7nEQ+TJcq2 hts1GSt7JvbUQKeBviv+fPqrjIRHDZWKJzhPng71iPDU9aiqOEHbLgmRQOaQXREr11n2 yYt+/KQXLHZM10NoMrllYQ9aWqaFsVTb542hr19m8wtD+kmp2hMrfOfnnAjmWc6i/2hP QM1A+gjgBM2ABRthfJVmvCs4y6/uveNE1vVBHzvIMNT+Fl2/6hzS7xSdUxMWbqmSPhiI KVUmuBQlU4/qYhPhbJWO9kcMRzkq2D0RoWJIRsZgjqN4rbRysL0YC4foHt4UNq1PQ+hK SwqQ== X-Gm-Message-State: AOAM530yiiXDYxiSvmm9GZg8Ulkyx3gWbCD6pGy7von257X4+b8nyIjL GrqY7nH00tYuLlHBweTJ47i1iGzq4MEBGGSe X-Google-Smtp-Source: ABdhPJw+ZznssLRQQfO79P588GVrxoEdCCjj7LCooxpzvH9CThKWWF3AcgG/xZ2mdaNx7g06lxDoVA== X-Received: by 2002:a05:6402:c84:: with SMTP id cm4mr8163480edb.270.1602152488140; Thu, 08 Oct 2020 03:21:28 -0700 (PDT) Received: from p200300eb8f1e2a7aa8a05874361f4c54.dip0.t-ipconnect.de (p200300eb8f1e2a7aa8a05874361f4c54.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7a:a8a0:5874:361f:4c54]) by smtp.gmail.com with ESMTPSA id f28sm3682521edc.94.2020.10.08.03.21.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2020 03:21:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Torsten Lodderstedt In-Reply-To: Date: Thu, 8 Oct 2020 12:21:26 +0200 Cc: vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> <064801d69c2b$229141c0$67b3c540$@auth0.com> To: =?utf-8?Q?Se=C3=A1n_Kelleher?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 10:21:32 -0000 > On 7. Oct 2020, at 19:45, Se=C3=A1n Kelleher wrote: >=20 > Hi all, >=20 > Long time lurker, first time poster, glad to be finally getting = involved! >=20 > In terms of weighing in on the revocation practice, I don't think this = document needs to address it as JWT ATs don't seem to require special = handling in this case. I think a general coverage of approaches to token = revocation would be more appropriate in a BCP. >=20 > One thing I'm unsure of when reading this is how a RS can depend on an = AS to give it a JWT AT. Due to the opaque nature of ATs, it seems = natural that an AS can change the AT profile it uses at its own = discretion, but there's no negotiation or parameter that can force an AS = to return a JWT AT, with the potential for breakages. Do the RS and AS = agree on the profile ahead of time? =20 yes, they do. Basically, the AS is acting on behalf of the RS and = centralises the authorization work.=20 > Perhaps this is specified in a separate document, but I think the = topic of profile negotiation should be covered in this document, even at = a high level, or reference to more detailed coverage. Good point. I think this is a general assumption in OAuth. Should = probably go into OAuth 2.1. >=20 > A few other notes on the document itself: > =E2=80=A2 Section 2.1: Is there precedence of = "application/at+jwt" being used in the wild that prevents the SHOULD = from being a MUST? > =E2=80=A2 Figure 1: Nitpick: An `&` that looks like it should = prefix `state` is on the preceding line. > =E2=80=A2 Figure 2: The example `typ` is `at+JWT`, should this = be `at+jwt`? > =E2=80=A2 Section 4: This is a personal opinion, but I'd = recommend moving the step concerning `aud` validation to the top of the = list, for focus. This is because, having personally taken more than a = little while to figure out the difference between access tokens and ID = tokens, I see the risk of cross-JWT confusion as very relevant. I think = the necessity of the other steps are a bit more obvious. > Thanks! >=20 > Kind regards, >=20 > Se=C3=A1n. >=20 > On Tue, 6 Oct 2020 at 22:53, = wrote: > Hi Andrii, >=20 > Thanks for the thoughtful comments! Here=E2=80=99s my 2 c. >=20 > =20 >=20 > On the proposed language: given that the JWT AT profile is just = providing more details on the content of an AT, making JWT ATs a proper = subset of all ATs, readers should have no reason to believe that = introspection or any other existing spec discussing AT behavior should = operate differently. That assumption holds for everything across the = board, hence it would be a bit odd to call out this particular case. On = the userinfo case, I would find it even more left field to say anything = about it. > If we do reach a consensus on specific revocation practices that apply = to JWT ATs specifically, and we conclude that they should live in this = document, I will be happy to add language accordingly. >=20 > =20 >=20 > On the AJWT: I hear you on the dissonance that JWT AT carries, but I = am very hesitant to introduce new acronyms to an already = crowded/impenetrable domain. > JWT access token might not roll off the tongue, but at this point = =E2=80=98JWT=E2=80=99 is nearly a proprietary eponym and the expression = =E2=80=9CJWT token=E2=80=9D is extraordinarily common in literature, a = quick google query will give you the full measure of the phenomenon, = hence I think we=E2=80=99ll be OK with the current form. >=20 > Cheers, >=20 > V. >=20 > =20 >=20 > From: Andrii Deinega =20 > Sent: Tuesday, October 6, 2020 2:25 PM > To: vittorio.bertocci@auth0.com; oauth@ietf.org > Cc: Jim Manico ; Nicolas Mora = > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint >=20 > =20 >=20 > Vittorio and WG, >=20 > =20 >=20 > Would it be possible to include something like the following to = https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 >=20 >=20 > In case the authorization server exposes the introspection, = revocation, and OpenID Connect userinfo endpoints they MUST act in the = same way as it happens with a regular access token. That allows the AS = to change the type of an access token on the fly and that won=E2=80=99t = lead to interoperate issues. Plus, the consumers of these endpoints use = them regardless of the type of access token. >=20 > =20 >=20 > The way how the AS can notify RSs that the token revocation event = happened (if it decides to do so) is completely left to implementers. >=20 > =20 >=20 > ? >=20 > =20 >=20 > Another minor editorial thing from me is it would possible to change = and refer to "JWT access tokens" as AJWT. Thus, this document won't = repeat the token word twice. >=20 > =20 >=20 > Regards, >=20 > Andrii >=20 > =20 >=20 > On Tue, Oct 6, 2020 at 2:22 PM = wrote: >=20 > Hey Jim, regarding > > Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents = the ability of a client to access a given resource; the fact that it = requires an authentication transaction/session establishment to be = issued to the client does not mean that the AT lifetime is tied to the = lifetime of that session. Say that I allow LinkedIn to tweet on my = behalf. Once I have done that, it doesn=E2=80=99t matter whether I stay = logged in their web app or otherwise. Even if I log out of the session = in which context I got my twitter AT, I can still post on LinkedIn from = my native LinkedIn app and the corresponding post will show up on = twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to = originating sessions lifetime, see the discussion on the OpenID Connect = group about a possible online_access scope for influencing RTs and Ats = (in particular, in the context of SPAs) but that's additional semantic = that isn=E2=80=99t defined today. >=20 > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint >=20 > > In this model, considering that token revocations don't happen a = lot... >=20 > Just a brief note, a secure piece of software makes the logout feature = prominent. Every logout event should trigger token revocation. >=20 > I=E2=80=99m mentioning this because a lot of OAuth solutions in the = mobile space literally ignore the logout event, such as Facebook=E2=80=99s= mobile OAuth solution.=20 >=20 > - Jim >=20 > > On Oct 4, 2020, at 6:55 AM, Nicolas Mora = wrote: > >=20 > > =EF=BB=BFHello, > >=20 > >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > >>=20 > >> There might be some kind of pushed events between the AS and the = RS when > >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT = at all. > >> Like this, the RS knows if a JWT AT has been revoked or not. > >>=20 > >>=20 > >> If there are some kind of pushed events between the AS and the RS,=20= > >> then it could push the revoked (and/or expired) opaque AT too, = giving=20 > >> almost no advantage to JWT ATs. > >>=20 > > Not necessarily, let's say the AS informs the RS only of the revoked=20= > > ATs, when a RS checks an AT, it verifies the signature first, then = the=20 > > claims, then checks if the AT has been revoked by checking its=20 > > internal list filled by the AS pushed events. > >=20 > > In this model, considering that token revocations don't happen a = lot,=20 > > the ratio revoked AT/valid AT is very low, so the advantage of a JWT=20= > > is important, because it means not so much communication between the=20= > > AS and the RSs, and a very reliable AT. > >=20 > > But this means a communication mechanism that isn't standardized = yet. > >=20 > > /Nicolas > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > 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 From nobody Thu Oct 8 05:17:48 2020 Return-Path: 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 DEDD63A0D96 for ; Thu, 8 Oct 2020 05:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 UBpxlM8LIdCQ for ; Thu, 8 Oct 2020 05:17:44 -0700 (PDT) Received: from mail.gtrs.de (mail.gtrs.de [94.23.167.223]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070A53A0D88 for ; Thu, 8 Oct 2020 05:17:43 -0700 (PDT) Received: from [172.23.101.107] (pd9fb2963.dip0.t-ipconnect.de [217.251.41.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.gtrs.de (Postfix) with ESMTPSA id 90A341C03E5 for ; Thu, 8 Oct 2020 12:02:36 +0000 (UTC) To: "oauth@ietf.org" From: Guido Schmitz Autocrypt: addr=g.schmitz@gtrs.de; prefer-encrypt=mutual; keydata= xsFNBExwZ1UBEACrRLUyt0jbab7/nCjULVkApY3mu+pLUfekl+yfw9XfUHFrmFonu4zYAFu8 dduseM9m0AG5b50i7L/dyJjgMlOx/WqoDycdIh37l3u6rU7EY7UY1w88pywOcUt64NW9uQnz 5wQU/UMC/JuFfGKirVTmtVY9kedfrcry8pJ5IPxmKxxf/LA42Qos/DSOzZpJYkeUM4z9l73t GB8C+WrMjGEviyQfQhlx0Ad1MbDF9ZavTSAKnRtX599BCl2p33l4iIq5ebh7Gq19LHACd3c8 SGLNnt8TqRXUo1HPE8ug05hagzc+85eAW37tjesFpkKQB4miXv6IB7tW8We128H3gxbWXzZb kktAHocZkAxoDPIPuxW5h3X4kotDb7aQsDM/Rbnc/YhVHd0L9EHnHkFbL1MJa+LXP0eCwq5D Ud51rtE5Ktmzhc0AZ0AYEDQNSyD4KwiRM9idMjM2DmNRvjyTL7VJj3NdVX+HkeVRhwkI6eCI U7I65yNdAKPfxSEhK1RKjXDzhEr3IZwZMjzwaaTt77sjIZan5UclTKP3tEYu0VknbDAusClB 9omg4jq8qM94lqSrHDVpps4xmMTW3T+Hwl6kHTsvLbz2q/QROItletxdfeys0y0jeD1pJ7Uu bQmUS8YeJa10PLNgUWvho+6gng5lmYJppmjXLcO4oL0v8TQ2mQARAQABzStHdWlkbyBUaW0g Um9tYW4gU2NobWl0eiA8Zy5zY2htaXR6QGd0cnMuZGU+wsF7BBMBAgAlAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTHBpZAIZAQAKCRAgw0pxFWieqbHXEACPKQS/0Cmq2kur8FLL g3YlehjORZDxcnF3XzC6qkD0iJu5xmwMxNgwGElD6ezRWRkNhc4C0G0YmG1IKB3qbpRLVMke ApjkNcoKkffvEACReUxNSzaNhRvzWdK8fBLs4DFqudV5iBC0kmm6DjzUccNXMjbFn7smYVbR MIsZ74hNUkpn44g6oB3myR5s8VdQdKiQJmP9qdwNtfDI81HBK1jU9dJSS11M2pxmhklYZ8us mjkNEFi9qy3Prx1vlyio/78TP0xwTkIRe48Kg6oMdXKWFjXq/K2iOm2d0rRzvpF8C3mE8MWP YsGD65XHlhtJ0bAJw+F5xVhvzFkRPOPwjmgZ2RKfChchTb/L5mD9+2kor0dWiFGNCs0Dxa5T j0PLd0ExYzZi6GRs+Yvz3moSiN92Rlvoasgebp6pUM1kfTsh9ln7IMWUZW7UeQDymT2HHYfx Gc/qiBU5u2kT7qzAfN6mJkDYQZthzirETcnHlElX6YZQRR2gqov8Px5miMaIGxW514vwCTvD 7Lh8jnTrxDYCCkwItscBMNxNeySYYMQoDnfPHeMGnEa0NoykRaZDAYXBrDduM4E6fJoRhlM/ RLi3XvxtkDNMejHXWq5Z3znULfFVy/OUPanoOC8Qd15YQMA4kVJ4u+Wr2h5dpwrIvB6O3zpE yhgES3bXkqo7KHHjTM7BTQRMcGdVARAAts2esuf7nLVY2PBKMw8J9eN5qo6u+5O4rq5v2vn0 iDRKvOO3pttLx3bCMCFBuWqiXN0LGssAfYa2UXQZx4UhGMVa/Bz2W0k+DkAZjBDTqEDmdBl8 pNVTWNeHf196natvO6xWKL5UQed9LfOsDnwRxlt47f/h+dbaw6AoVKeQ1UuQGH/xOHjdbjBv 15CzxQtHOj30DuqTLdVbM65u2bF+MwGAEC8NGexiQmYmns/UoKbkmXgZc5mm8w4M1O5xI7MI I5YT4HIPPRPzUFL347Mt5nRpuW3H8JIiBCv8YBlTMzTS1IslP0+yERsS8SBRM3U34hH3867Y WwQ2gfKq5Hmycmj3H1X/fBD/kosOKxRsMhEl9vEc1n2FYvb/tQc5vKULR/ZQW4aZWGRMKbni GP65lTF9FxWSyaddNZi/RqBZnYiWc6Z+M5Qr/KSrOl2h7IE9Hhz4ZAupVam49NGuptf8RBmv NyCWrGXvR09/sSbPw+unkR4xHMQDDNI9HlkuiiVf1i0s/16jGyHVbZG8bUlSWOsN2CTR3bXO Pa5a4osEb/DAhGZrgz88/6fNNv4oWPpAv1NoVfXiwtoFn2fIus8RxL7+TR2IhUOzUZ8HLPTl gZAHLIui8dTrF2PyawUNaaELujmMQP/X/sSiUHO7BqsUBFhSDmT3sDkqPYqDBmhMXL8AEQEA AcLBXwQYAQIACQUCTHBnVQIbDAAKCRAgw0pxFWieqSoLD/kBN3aIqikEdTR3p2newQ+Kzyvx xTt1PSrrDWWZ9+hdqNJSJSv85cq9nJOpJLSCsBpapZCR5OXOPbuvUtmfKpZo90zbeGPHVuvL 1i4qrV+YTvSsFR8ORkfzu6Jyh+MYSeWTKfSW53Re/TupJV/0PcNmOw5XufdHSsS1kdF+A53v cR1oXBXwBAlu4wdvPejjE3ON4l4Ge2GHyhoTXj6iOYOwcebHHJ0BMg2py5IWoII1HM0dfT9r hcOvlc2Wegy4I6+tFnWdiWXAzYpHcxiWdyRIy3ElQj+sQisQqEvJaIUYW8ul3I5pUuKhlKbQ qwA9DA5pYwMcwiRvHslc8dOWK1XUF03xRrNq4mA6Un+mFyteHlDDKfXE9695KcxgZsE93kNf 9ij+zU02/65xellirmk8s/GXoBxj7mhV/CJ9XRC8ZVg2ZzGP/UtyS+5mW6KmbJk5o/Lv/R3n S/fBQE5yevffwhFu5b/Zo8B/l1MQ7DMSLG4y423ciOZE2yYiwYmlddalhrnYVnQ7+9BFnDAl ORUf7ffJlp3YHDfi7+ytMiDjiWbqKzf7hFcybptYpVdm0WS+9mLVKrfYhLAuaK2M7xZSvzZP T4Fe4GGgZELOyx8qGiiBMDRVpLCV2uze4mW7ARr4VcSWN2HbB6pzGmgxF4qwJJUzxhc8wklS IEKDvXjlUw== Message-ID: <91cca627-2250-366f-cc14-a153812ba902@gtrs.de> Date: Thu, 8 Oct 2020 14:17:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 12:17:46 -0000 Hi, We just had a discussion in Stuttgart on the possibility of misconfigured endpoints, i.e., an honest client uses the wrong endpoints for interacting with some honest AS. Such a setting might be the outcome of a social engineering attack against the administrators of a client (e.g., the attacker disguises as an AS support agent and convinces the client admin that some endpoint needs to be changed). If some endpoint is configured to a URL controlled by some adversary, critical data can leak and the attacker can even tamper with the requests to this endpoint. Is this a realistic attack scenario? Does anybody have more insight or data on this problem? (I think that such a scenario had been mentioned at some OSW discussion.) A potential mitigation against this problem could be the usage of AS metadata discovery (RFC8414). In this case, the client only needs to set the "issuer" to configure the endpoint URLs. A social engineering attack to change the issuer might be less likely as a social engineering attack to change some endpoint URLs (which a client admin might have less understanding of). Further, using AS metadata discovery also reduces the risk of misconfiguration at the client in general. Maybe it is a good idea to add a recommendation for the usage of RFC8414 in the security BCP. What do you think? Regards, Guido From nobody Thu Oct 8 05:31:11 2020 Return-Path: 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 990D63A0DA6 for ; Thu, 8 Oct 2020 05:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 dLHQjeAPGNDr for ; Thu, 8 Oct 2020 05:31:08 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 5D3553A0DAA for ; Thu, 8 Oct 2020 05:31:08 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id cq12so5658160edb.2 for ; Thu, 08 Oct 2020 05:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNl++8G3agUWrybMppXr2hIEBeOQB4vSCXQr7g2N0j0=; b=BqH3vF4AWY4q9/F7NBk3oqyoLjSdTe9wzaHRZel5rRRHby8rZ+QJVv7px+S37LqErK W6/hHhF3jf/TfSOXRFlHhQaePdhCPTwuZTRVBoLNlQj+NgpIuNi0DYCe8hRishMcS7TU tgCYUoASS2pZP2qKGm9I1qfF56kPoJ/ZEcLkE= 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=BNl++8G3agUWrybMppXr2hIEBeOQB4vSCXQr7g2N0j0=; b=A/YKyuiJ9JJX9IolNQgxuvI929JoVF2bPD55SPRQ9fE34LvL+hGjtGMGPc1TRGN2MS RBY5viXpDHFyaWFCNEF/Nl8TleiGhHY/pNtaYPbBLyMHE+eef1GhbQgEGh/Qhf0am5Ks AOUg0FebgBUqtz2GpDsdENMOqDWp6ym+KLQGpolPTx6y9yOTrF++M4ic4lRm2Gk7XqxN Oj8tzdidDFgWRig8X7SMVnko3fX5dehCGvOSeFTGyeSRoV+SQOhF0J4D/YjICoVczrTp Oeur9GzM/aE42d8zpTrvjLcef+t5XI4SkKvFfxArybsfAbat+d3FgS0m5Xa7kIeDShIF cOnA== X-Gm-Message-State: AOAM531umwecODzGhtwfUntktlgbNSmDciAhUgjmBlteSqMbEbsXU1/B FdNJRayvQQ4O9oIT3+zLNSLJ/ex6Yo9aUw4eJYrIQ6ViYfShDgGAWtoeghjU06cIiigusnc0zwF AlLEISCJnFVyiy0s66jr2hw4y X-Google-Smtp-Source: ABdhPJyj3vHrRXa2Q1adVHywJ+eAi5xENA0LyZl08R7kOMzo6ogcyIiKoLRy4Xe1rtqBsVGvEE6WWXezoykxTpdre5w= X-Received: by 2002:a05:6402:744:: with SMTP id p4mr8505111edy.190.1602160266717; Thu, 08 Oct 2020 05:31:06 -0700 (PDT) MIME-Version: 1.0 References: <91cca627-2250-366f-cc14-a153812ba902@gtrs.de> In-Reply-To: <91cca627-2250-366f-cc14-a153812ba902@gtrs.de> From: Dave Tonge Date: Thu, 8 Oct 2020 14:30:55 +0200 Message-ID: To: Guido Schmitz Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009247e405b128012d" Archived-At: Subject: Re: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 12:31:11 -0000 --0000000000009247e405b128012d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Guido We've also discussed this issue in the FAPI Working Group at the OpenID Foundation. We came to the conclusion that we should require the use of either RFC8414 or OpenID Connect Discovery. I'd be in favour of adding the recommendation to the BCP. I'm not aware of an attack in the wild in this area, but I'm definitely aware of quite a bit of misconfiguration of clients. We've had a problem in the UK OpenBanking space where alternative authorization endpoints were communicated via email or hosted PDFs. In my mind this opens up social engineering attacks that are much less likely when RFC8414 is used. Dave On Thu, 8 Oct 2020 at 14:18, Guido Schmitz wrote: > Hi, > > We just had a discussion in Stuttgart on the possibility of > misconfigured endpoints, i.e., an honest client uses the wrong endpoints > for interacting with some honest AS. Such a setting might be the outcome > of a social engineering attack against the administrators of a client > (e.g., the attacker disguises as an AS support agent and convinces the > client admin that some endpoint needs to be changed). If some endpoint > is configured to a URL controlled by some adversary, critical data can > leak and the attacker can even tamper with the requests to this endpoint. > > Is this a realistic attack scenario? Does anybody have more insight or > data on this problem? (I think that such a scenario had been mentioned > at some OSW discussion.) > > A potential mitigation against this problem could be the usage of AS > metadata discovery (RFC8414). In this case, the client only needs to set > the "issuer" to configure the endpoint URLs. A social engineering attack > to change the issuer might be less likely as a social engineering attack > to change some endpoint URLs (which a client admin might have less > understanding of). Further, using AS metadata discovery also reduces the > risk of misconfiguration at the client in general. Maybe it is a good > idea to add a recommendation for the usage of RFC8414 in the security > BCP. What do you think? > > Regards, > > Guido > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --0000000000009247e405b128012d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Guido

    We've also di= scussed this issue in the FAPI Working Group at the OpenID Foundation.
    We came to the conclusion that we should require the use of either RFC8414= or OpenID Connect Discovery.

    I'd be in favour of adding= the recommendation=C2=A0to the BCP.=C2=A0

    I'm not aware= of an attack in the wild in this area, but I'm definitely aware of qui= te a bit of misconfiguration of clients. We've had a problem in the UK = OpenBanking space where alternative authorization endpoints were communicat= ed via email or hosted PDFs. In my mind this opens up social engineering at= tacks that are much less likely when RFC8414 is used.

    Dave



    On Thu, 8 Oct 2020 at 14:18, Guido Schmitz <g.schmitz@gtrs.de> wrote:
    =
    Hi,

    We just had a discussion in Stuttgart on the possibility of
    misconfigured endpoints, i.e., an honest client uses the wrong endpoints for interacting with some honest AS. Such a setting might be the outcome of a social engineering attack against the administrators of a client
    (e.g., the attacker disguises as an AS support agent and convinces the
    client admin that some endpoint needs to be changed). If some endpoint
    is configured to a URL controlled by some adversary, critical data can
    leak and the attacker can even tamper with the requests to this endpoint.
    Is this a realistic attack scenario? Does anybody have more insight or
    data on this problem? (I think that such a scenario had been mentioned
    at some OSW discussion.)

    A potential mitigation against this problem could be the usage of AS
    metadata discovery (RFC8414). In this case, the client only needs to set the "issuer" to configure the endpoint URLs. A social engineering= attack
    to change the issuer might be less likely as a social engineering attack to change some endpoint URLs (which a client admin might have less
    understanding of). Further, using AS metadata discovery also reduces the risk of misconfiguration at the client in general. Maybe it is a good
    idea to add a recommendation for the usage of RFC8414 in the security
    BCP. What do you think?

    Regards,

    Guido

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --

    =

    Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

    = DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


    --0000000000009247e405b128012d-- From nobody Thu Oct 8 05:39:21 2020 Return-Path: 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 4EA773A0DD8 for ; Thu, 8 Oct 2020 05:39:20 -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, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 XpG2J2w5oXK7 for ; Thu, 8 Oct 2020 05:39:18 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7003A0DD5 for ; Thu, 8 Oct 2020 05:39:18 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id BB11A12BFC for ; Thu, 8 Oct 2020 12:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1602160756; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m7IUxpJaQdG0x16w5octvl/JtWjSqdRYc88FbqTB3Oo=; b=I/6hznEt9LwkY5Z7Y5gcrqh/22I4RxAkQ/2YLivr86laA4xc5uzI9363LS5FljKeNNYKYP Rh2u3NFiMP38sSbftMZNRcYwH+o45jq4+3J6QAwXczEUj7hnRiJvCnvjErEJVXhE8urgpy hlvrqL59CbVSntqKWgZ15GFoJz6wShk= To: oauth@ietf.org References: <91cca627-2250-366f-cc14-a153812ba902@gtrs.de> From: Daniel Fett Message-ID: <6c0efe83-7f61-dbff-b0dd-36f529dce590@danielfett.de> Date: Thu, 8 Oct 2020 14:39:16 +0200 MIME-Version: 1.0 In-Reply-To: <91cca627-2250-366f-cc14-a153812ba902@gtrs.de> Content-Type: multipart/alternative; boundary="------------EBFD945E8625DA5988631F10" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1602160757; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m7IUxpJaQdG0x16w5octvl/JtWjSqdRYc88FbqTB3Oo=; b=J322cMU22AWLE14GYkjMgiSRT/epJYf/XYMk3IVWn0WF35eCI8kgacDrq/ECAW7tjl5tGp RzWvKVMkBNImLFS3zUSy9PcRpcgFeGDZK4RAqVRXIQ1uycZJjyzfinZOgAHLC5m8+41HKs t3mGEyjF03XylcxhACblvo5b8Q7NAo8= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1602160757; a=rsa-sha256; cv=none; b=P97iYsrzZ5gQ8TnxZ7suoB382dCo1a6VkHgg8WLfm7JjDZls9caHR4MWoM8vT1QSHigTlm cGTv/t5s9vhOdzvLsU5zUc26AzVDDPFZX1EqOJ7ogT+0+Fe2tnJy/9O7NnJ1zX2sdukQj/ AAvkGVJ+EndwRh4Sdy8KtE5AKrsXE8U= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 12:39:20 -0000 This is a multi-part message in MIME format. --------------EBFD945E8625DA5988631F10 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Guido, Am 08.10.20 um 14:17 schrieb Guido Schmitz: > We just had a discussion in Stuttgart on the possibility of > misconfigured endpoints, i.e., an honest client uses the wrong endpoints > for interacting with some honest AS. Such a setting might be the outcome > of a social engineering attack against the administrators of a client > (e.g., the attacker disguises as an AS support agent and convinces the > client admin that some endpoint needs to be changed). If some endpoint > is configured to a URL controlled by some adversary, critical data can > leak and the attacker can even tamper with the requests to this endpoint. > > Is this a realistic attack scenario? Does anybody have more insight or > data on this problem? (I think that such a scenario had been mentioned > at some OSW discussion.) This scenario is also explicitly mentioned in FAPI 1.0: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md#markdown-header-832-client-credential-and-authorization-code-phishing-at-token-endpoint > A potential mitigation against this problem could be the usage of AS > metadata discovery (RFC8414). In this case, the client only needs to set > the "issuer" to configure the endpoint URLs. A social engineering attack > to change the issuer might be less likely as a social engineering attack > to change some endpoint URLs (which a client admin might have less > understanding of). Further, using AS metadata discovery also reduces the I find it plausible that having the issuer as the single entry point makes misconfigurations less likely. One disadvantage could be that an attacker might use a bening-looking issuer URL to "hide" the fact that he uses an honest server's authorization endpoint but an attacker-controlled token endpoint. Such attacks, however, need to be caught by mix-up mitigations anyway (see https://danielfett.de/2020/05/04/mix-up-revisited/). A positive side-effect of a more widespread use of RFC8414 could be that it becomes easier to configure OAuth and new(ish) features such as PKCE and PAR could be enabled/relied-upon by clients more easily. > risk of misconfiguration at the client in general. Maybe it is a good > idea to add a recommendation for the usage of RFC8414 in the security > BCP. What do you think? Publishing RFC8414 metadata is (almost) mandatory already, since servers MUST declare their support of PKCE (but they can also use deployment-specific ways to accomplish this). I would support adding - that servers SHOULD publish RFC8414 metadata and - that clients SHOULD make use RFC8414 discovery. -Daniel -- https://danielfett.de --------------EBFD945E8625DA5988631F10 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    Hi Guido,

    Am 08.10.20 um 14:17 schrieb Guido Schmitz:
    We just had a discussion in Stuttgart on the possibility of
misconfigured endpoints, i.e., an honest client uses the wrong endpoints
for interacting with some honest AS. Such a setting might be the outcome
of a social engineering attack against the administrators of a client
(e.g., the attacker disguises as an AS support agent and convinces the
client admin that some endpoint needs to be changed). If some endpoint
is configured to a URL controlled by some adversary, critical data can
leak and the attacker can even tamper with the requests to this endpoint.

Is this a realistic attack scenario? Does anybody have more insight or
data on this problem? (I think that such a scenario had been mentioned
at some OSW discussion.)

    This scenario is also explicitly mentioned in FAPI 1.0: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md#markdown-header-832-client-credential-and-authorization-code-phishing-at-token-endpoint

    A potential mitigation against this problem could be the usage of AS
metadata discovery (RFC8414). In this case, the client only needs to set
the "issuer" to configure the endpoint URLs. A social engineering attack
to change the issuer might be less likely as a social engineering attack
to change some endpoint URLs (which a client admin might have less
understanding of). Further, using AS metadata discovery also reduces the

    I find it plausible that having the issuer as the single entry point makes misconfigurations less likely.

    One disadvantage could be that an attacker might use a bening-looking issuer URL to "hide" the fact that he uses an honest server's authorization endpoint but an attacker-controlled token endpoint. Such attacks, however, need to be caught by mix-up mitigations anyway (see https://danielfett.de/2020/05/04/mix-up-revisited/).

    A positive side-effect of a more widespread use of RFC8414 could be that it becomes easier to configure OAuth and new(ish) features such as PKCE and PAR could be enabled/relied-upon by clients more easily.

    risk of misconfiguration at the client in general. Maybe it is a good
idea to add a recommendation for the usage of RFC8414 in the security
BCP. What do you think?

    Publishing RFC8414 metadata is (almost) mandatory already, since servers MUST declare their support of PKCE (but they can also use deployment-specific ways to accomplish this).

    I would support adding

    - that servers SHOULD publish RFC8414 metadata and
    - that clients SHOULD make use RFC8414 discovery.

    -Daniel


    -- 
https://danielfett.de
    --------------EBFD945E8625DA5988631F10-- From nobody Thu Oct 8 07:41:15 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4603A08DC; Thu, 8 Oct 2020 07:41:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Hannes Tschofenig via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, Hannes Tschofenig Message-ID: <160216807269.20921.1930277691984951790@ietfa.amsl.com> Date: Thu, 08 Oct 2020 07:41:12 -0700 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-access-token-jwt-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 14:41:13 -0000 Hannes Tschofenig has requested publication of draft-ietf-oauth-access-token-jwt-10 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ From nobody Fri Oct 9 10:17:14 2020 Return-Path: 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 317613A0D33 for ; Fri, 9 Oct 2020 10:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xxTtiT2Fgo4I for ; Fri, 9 Oct 2020 10:17:10 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 8E3103A0D2B for ; Fri, 9 Oct 2020 10:17:10 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id h5so1004094wrv.7 for ; Fri, 09 Oct 2020 10:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=7H8tyJP7sL0HRM9NppB43vN0T7k/+GwT9yYXOm+0So0=; b=H+DMRvtjVV+iej/r+UFrpbQ7EwCu92Et+T+ax3hW0l34UX+ZGJYJh1QrfToFVQHdFc ez5KnPVh3jvb72pGO+UzniXtdFhvbSJWjYaPcPsZ4gRu1/9KicJD1Zaue/8oxdJKmO4E MD6O/3Bxf77zU2G3ITBoIvG5fz5rUqDsJPqTMWFLL58sE2s5E7yWkxlXkPT7WhNoLgD7 9sxz7Mi1uRt854xahICTUlDDQObGSTkMNrSQxkhB42+6xVuLfSNleWHgbw5dNuByLWnv HSpJZLN2WLQ2/ykTLXkp1DU5UMRMc8ZHO6yzKzxx0+v+ZYuSrrEiAF76+Ow0JOx5RtTi m94g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=7H8tyJP7sL0HRM9NppB43vN0T7k/+GwT9yYXOm+0So0=; b=DnZAycgpBXVTjjKKqmqFW4JVFMOGlmicn8oT9dzulURIMajK/aIy9HPNJbFpLyQ5bt 99uH12kH6xzvnM1toxY/fd/VwdjbCJ2fAYCCW6X0y4+BeMVCceKD0tOzEavaHEgzGFNX AugtBgRvg8/sS9bhC738wllD3VrGkmk1/9tK5CG5mqdWI+GL7yeW7pxXV8OifUMGhvi6 gjTSfelzVY025BtSv6l6MtdP90I4HyWnW38yblCtRqRtdbt0hTTfx3toAyNcP1OvLvK8 yQ7z/RwN5ueBu9st5NE2dE5qExznECILHC87TFARejE2si7HakqimbvupH+Mo1POkfOv XhqQ== X-Gm-Message-State: AOAM53044MP4farDd+baKwI9Pk2ZnVLCxDNPE081V3/zVelPdBc9T2IZ 0LaiOcMr/75jdPyH6LEeqshhgtJ7MpzUVsN7txvo/giEyXunOw== X-Google-Smtp-Source: ABdhPJx7ctz54d8OW2HUALSWGvWhReKdQoZgCWg88XVNSZMbt/gEGNoJFp3NirkpvEnqMOp3hbjtbvLWurdCfUuPKyo= X-Received: by 2002:adf:9361:: with SMTP id 88mr15557037wro.37.1602263827976; Fri, 09 Oct 2020 10:17:07 -0700 (PDT) MIME-Version: 1.0 From: Jeff Hodges Date: Fri, 9 Oct 2020 10:16:31 -0700 Message-ID: To: oauth@ietf.org Cc: Justin Toupin , Sam Goto , Jeff Hodges Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:17:12 -0000 > The Web Authorization Protocol (oauth) WG will hold > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/Toronto (17:00 to 18:00 UTC). > > Agenda: > 1. High level overview of anti-tracking and the IsLoggedIn & WebID initiatives > 2. Impact on the OAuth WG work > 3. Proposal for a WG position on these initiatives. > 4. Discussion > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m7e21c550ab77d0da08845741bb0b2a0c Hi, We're involved in WebID and just want to acknowledge that we are aware of this upcoming discussion and that we're happy to join the meeting to answer questions and provide context if that'd be helpful. HTH, Sam Goto Justin Toupin =JeffH From nobody Fri Oct 9 10:26:12 2020 Return-Path: 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 F39313A0D40 for ; Fri, 9 Oct 2020 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 SoDoapMuHTfx for ; Fri, 9 Oct 2020 10:26:08 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 2F8AF3A0D3D for ; Fri, 9 Oct 2020 10:26:08 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id c141so4863757lfg.5 for ; Fri, 09 Oct 2020 10:26:08 -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; bh=eH9UW2frofjUVTAv3g78mDS7Z54usvdNNCILEcL0VFk=; b=ERBQeuGY8Vu55aZXN2277hIZmaRljoviXuJmTje/DcYABQseqNDW7052iZcOoNRArb x5GKYldRgU8OL+hbndKef+7dKA7fLLYIEG6tk8V2Me2pxeFz1uz5+536+n2lBpkfyDMn 0hBimD5ZeyIGLfN6zGzusFljOt5FyEaBT8tgfvIzF+Eiwj8SlcyriVzzHKJI61dGsvmj iVwHLgvpMS3bDdPbMu65vb98H4yOADru9is+B0CZ8PIyHP4o5RnDKgOzlt4M3EHZzazK uAq8rtBJehbEU4qvnr69DLawtvGBwcjBAc9+yGatFtXssWQuPgxIj3X4p7P0m97ud8EO GrKg== 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=eH9UW2frofjUVTAv3g78mDS7Z54usvdNNCILEcL0VFk=; b=rolXxxXrJzaxXHrO8HgqknaKyT31YTkeujwX2XVllR1hkIEXX9W9784NX7B1sR8iVS 9DBc7FJW+QGzUGMX+e7Ehkjm0kNvgLHKkYQwlfuTDbXAXVdWJSmXTnKWl4Nxe3G8K35s z06+6g8RW74RZGv3qB2nUCjKqg0Yv/cPTVV4BOcHat67g8zeW8YfpuOCsNMPaEXVOTvr iG7mFCrOvEF5245hLhYZRBCntz7KTELyFlNOAuOTMh33Sd1MeM1pf1RUKKqnyCac6JLq XNa23rFES0tktXlziHaNBcLRaffyo3pQY0X82M1kTgddBsFd/DR91psH3W/EkIgIyqyV 1pQQ== X-Gm-Message-State: AOAM530JHFoVb4y1hQ/GY8d4x6+d/uKFnB6lr4eI4ri5E3mzJ9F7nol8 f1Y/wHXmtfzs/bllUnKlfDNHcXszFJQ1lOKBp0M= X-Google-Smtp-Source: ABdhPJxqPoNuz6zvGoBG3khkDbDy+9Rv6DxE3EuTXmSa/6lZie6/mq8nZI0Yja+Yx0oUzRP7vwjv1IPoGXIenzQVsFg= X-Received: by 2002:a05:6512:31c7:: with SMTP id j7mr4218004lfe.221.1602264366193; Fri, 09 Oct 2020 10:26:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 9 Oct 2020 10:25:29 -0700 Message-ID: To: Jeff Hodges Cc: oauth@ietf.org, Sam Goto , Justin Toupin Content-Type: multipart/alternative; boundary="0000000000006226c405b1403e2d" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:26:10 -0000 --0000000000006226c405b1403e2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please join! =E1=90=A7 On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodges wrote: > > The Web Authorization Protocol (oauth) WG will hold > > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 > America/Toronto (17:00 to 18:00 UTC). > > > > Agenda: > > 1. High level overview of anti-tracking and the IsLoggedIn & WebID > initiatives > > 2. Impact on the OAuth WG work > > 3. Proposal for a WG position on these initiatives. > > 4. Discussion > > > > Information about remote participation: > > https://ietf.webex.com/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2= a0c > > Hi, > > We're involved in WebID and just want to acknowledge that we are aware > of this upcoming discussion and that we're happy to join the meeting > to answer questions and provide context if that'd be helpful. > > HTH, > > Sam Goto > Justin Toupin > =3DJeffH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000006226c405b1403e2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Please join!
    3D""=E1=90=A7

    On Fri, Oct 9, = 2020 at 10:17 AM Jeff Hodges <jdhodges=3D40google.com@dmarc.ietf.org> wrote:
    > The Web Authorization Proto= col (oauth) WG will hold
    > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/To= ronto (17:00 to 18:00 UTC).
    >
    > Agenda:
    > 1.=C2=A0 =C2=A0 High level overview of anti-tracking and the IsLoggedI= n & WebID initiatives
    > 2.=C2=A0 =C2=A0 Impact on the OAuth WG work
    > 3.=C2=A0 =C2=A0 Proposal for a WG position on these initiatives.
    > 4.=C2=A0 =C2=A0 Discussion
    >
    > Information about remote participation:
    > https://ietf.webex.co= m/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2a0c

    Hi,

    We're involved in WebID and just want to acknowledge that we are aware<= br> of this upcoming discussion and that we're happy to join the meeting to answer questions and provide context if that'd be helpful.

    HTH,

    Sam Goto
    Justin Toupin
    =3DJeffH

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000006226c405b1403e2d-- From nobody Fri Oct 9 11:46:05 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B00AD3A12A0; Fri, 9 Oct 2020 11:45:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160226915962.22443.7999788834020809718@ietfa.amsl.com> Date: Fri, 09 Oct 2020 11:45:59 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-10-26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 18:46:00 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2020-10-26 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: Update on the latest with the Security BCP Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mec334e16fade3ebb65f0584161d97adc From nobody Fri Oct 9 12:06:53 2020 Return-Path: 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 5E0FC3A140C for ; Fri, 9 Oct 2020 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 GpNNanbvPGJJ for ; Fri, 9 Oct 2020 12:06:49 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 63F833A1409 for ; Fri, 9 Oct 2020 12:06:49 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id j136so10832124wmj.2 for ; Fri, 09 Oct 2020 12:06: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; bh=172QZN0R8FzeUd0VtV7nIClFx5cW8cyZFkEDifhl0Vs=; b=OU6mI1IxMV7gs1JZkDvyJJrz+qQKm83rEi1Mbei9cdWkRgV8CczqSFx4VhPC3pPMlt 5oSoYsvHSuFQuqj1oTwjenxROcKwQX+X65NwFawvpDkKJJUcgF6oSrUpaLydvj5CW5Ih ZgkzX/if200tcLLc9hqWlIRHVTgKMbePH0dS3N79jIpLJgv2kt6zkh89s1UVShDdfdcf M50GGPugCJi//dh7xEM63Msenpprc5aUKxYfNIwlixxkG24r6gqzdMuvpZ1Ah+ODUieZ IOFCz4Hhneoxgs/alJUINWFZkPeY31gTYk5TvbSyHhjawAkC72vPP6Vbunru55+U4qej ldSA== 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; bh=172QZN0R8FzeUd0VtV7nIClFx5cW8cyZFkEDifhl0Vs=; b=YukSmc2hqi4G0F9Ta39k2VFrM25fvPA4O8DBMZA2T5URp5j0LVJ1gRoRQqYVjcVUG4 9bXtbaHpnG95wDMUdLHxvshh5ROMWkpD+2gAB9ZtqVY6Hi2olsRMs+ssgfUrw/xDfLcW bM4RIH7trpTItPWgHZSD996QVJ/JaV+yfhAV+yr+jQ5QTFFfIgG7OXdrzHPMI3PxIVhk UYENlUXjrMVpvkVlvVCcXo3eDWiQfaGgvt4IGNlgeTefb+B1iT9M4PNZHHTNFcTGF+oQ jV4sG4Lgwjc4WNoFo+aFvLQojvL2nRzznsEIW2+UK8Yb7nbWtIFCF3dNQRsQOsTo+2Fb JIPg== X-Gm-Message-State: AOAM531hho52AsQqyusM+DsnvRaX0BH7QoCAbKFYSYR+Bmo/VUqky2IV VPLDBsseaZS6ixR/3nMUMR0khTvYN9BKJY1FZCPobDfRQCo= X-Google-Smtp-Source: ABdhPJyXg5F8K5L+KekztOVx90NmkUmSiQrnrEzXMzz7dNPbJJYW0SBZ4O7InhV0BhMdAMJUgDu6j9sP6Uh6PTNeZBY= X-Received: by 2002:a1c:e283:: with SMTP id z125mr16643980wmg.154.1602270407289; Fri, 09 Oct 2020 12:06:47 -0700 (PDT) MIME-Version: 1.0 References: <1651541607.5544921602267019696.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <1651541607.5544921602267019696.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Fri, 9 Oct 2020 15:06:36 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="000000000000760be605b141a67e" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - OAuth 2.0 Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 19:06:51 -0000 --000000000000760be605b141a67e Content-Type: multipart/alternative; boundary="000000000000760be205b141a67c" --000000000000760be205b141a67c Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Fri, Oct 9, 2020 at 2:10 PM Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim - OAuth 2.0 Security BCP To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 171 098 6417 Meeting password: iKpByAKN843 Monday, October 26, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,1710986417## <%2B1-650-479-3208,,*01*1710986417%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 1710986417@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 1710986417.ietf@lync.webex.com Need help? Go to http://help.webex.com --000000000000760be205b141a67c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    ---------- Forwarded message ---------
    From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
    Date: Fri, Oct 9, 2020 at 2:10 PM
    S= ubject: (Forward to others) Webex meeting invitation: OAuth WG Interim - OA= uth 2.0 Security BCP
    To: <o= auth-chairs@ietf.org>


    =C2=A0
    =09
    You can forward this invitation to others.

    Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
    =C2= =A0
    Meeting number (access code): 171 098 6417
    Meeting password: iKpByAKN843
    =C2= =A0
    Monday, October 26, 2020
    12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
    =20
    =C2=A0
    Join meeting
    = =C2=A0
    Tap to join from a mobile device = (attendees only)
    +1-650-4= 79-3208,,1710986417## Call-in toll number (US/Canada)
    =C2=A0
    <= tr style=3D"margin:0px">=
    Join by phone
    1-650-479-3208=C2=A0Call-in toll number (US/Canada)
    Global call-in numbers
    =C2=A0
    Join from a video system or appli= cation
    Dial 1710986417@ietf.webex.com
    You can also dial 173.243.2.68 and enter your meeting nu= mber.
    =C2=A0
    Join using Microsoft Lync or Microsoft Skype for Business
    Dial 1710986417.ietf@lync.webex.com
    =C2= =A0
    =09
    =C2=A0
    Need help? Go to http://help.webe= x.com
    =C2=A0
    --000000000000760be205b141a67c Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20201009T181019Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20201026T120000 DTEND;TZID=3DAmerica/New_York:20201026T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dmec334e16fade3ebb65f05841= 61d97adc TRANSP:OPAQUE SEQUENCE:1602267019 UID:d8b03705-b9bf-482e-8c7a-df9be58bbb49 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dmec334e16fade3ebb65f0584161d97adc\nMeeting number (access code): 171 = 098 6417\n\nMeeting password: iKpByAKN843\n\n\n\nTAP TO JOIN FROM A MOBILE = DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1710986417## tel:%2B1-650-479-320= 8,,*01*1710986417%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PH= ONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbe= rs\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm378f2e5c7066ac6569= 91878dd150151c\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:17109= 86417@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting= number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDi= al sip:1710986417.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nh= ttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NOTI= CE: Please note that this Webex service allows audio and other information = sent during the session to be recorded, which may be discoverable in a lega= l matter. By joining this session, you automatically consent to such record= ings. If you do not consent to being recorded, discuss your concerns with t= he host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n \n \n
     
    \n \n\n\n\n\n\n = \n \n \n \n \n \n \n
    \n When it's time, join the Webex meeting here.\n \n
     
    \n Meeting number (access code): 171 098 6417\n =
    \n
    Meeting password:iKpByAKN843
    \n= \n \n \n \n \n \n
     
    \n \n \n= \n
    Join meeting<= /td>\n
    \n
    \n\n \n 
     
    \n\n 
    = Tap to join from a mobile device (attendees only)  
    +1-650-479-3208,,171= 0986417## Call-in toll number (US/Canada) 

    J= oin by phone  
    1-650-479-3208 Call-in toll number (US/Canada)  
    Global call-in numbe= rs     


    \n\n
     
    \n\nJoin from a v= ideo system or application
    Dial 1710986417@ietf.webex.com 
    You can also= dial 173.243.2.68 and enter your meeting number.  
    =  
    \n\n
    Join using Microsoft Lync or Microsoft Skype for Busine= ss
    Dial 1710986417.ietf@lync.webex.com
    \n\n
     
    \n= \n\n \n = \n \n = \n \n \n
     
    Need help? Go to http://help.webex.com\n =
     =
    \n
    \n SUMMARY:OAuth WG Interim - OAuth 2.0 Security BCP PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --000000000000760be205b141a67c-- --000000000000760be605b141a67e Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1750ec1b4f3c1ce7aee1> X-Attachment-Id: 1750ec1b4f3c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAxMDA5 VDE4MTAxOVoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMTAyNlQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMTAyNlQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1lYzMzNGUxNmZhZGUzZWJiNjVmMDU4NDE2MWQ5N2FkYw0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTYwMjI2NzAxOQ0KVUlEOmQ4YjAzNzA1LWI5YmYtNDgyZS04YzdhLWRmOWJl NThiYmI0OQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lYzMzNGUxNmZhZGUzZWJiNjVmMDU4NDE2 MWQ5N2FkY1xuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTcxIDA5OCA2NDE3XG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IGlLcEJ5QUtOODQzXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9C SUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDE3MTA5ODY0MTcj IyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxNzEwOTg2NDE3JTIzJTIzKjAxKiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMy MDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbiBudW1i ZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW0z NzhmMmU1YzcwNjZhYzY1Njk5MTg3OGRkMTUwMTUxY1xuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTcxMDk4NjQxN0BpZXRmLndlYmV4LmNvbVxu WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTcxMDk4NjQxNy5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5 b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9y ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNw YWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9u dC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7 XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRo OiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1l ZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJ Zm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAh aW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJ d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1c bgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFp bXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5 bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4 OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8 Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1l LCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFj Y2VzcyBjb2RlKTogMTcxIDA5OCA2NDE3PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5pS3BCeUFLTjg0MzwvRk9OVD48 L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNB OTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tZWMzMzRlMTZmYWRlM2ViYjY1ZjA1ODQxNjFkOTdhZGMi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0i I0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9 IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k ZWVzIG9ubHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxMDk4 NjQxNyUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5v bmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7 Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTA5ODY0MTcjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bTM3OGYyZTVjNzA2NmFjNjU2OTkxODc4ZGQxNTAxNTFjIiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0g b3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE3MTA5ODY0MTdAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+MTcxMDk4 NjQxN0BpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDoxNzEwOTg2NDE3LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTA5ODY0MTcuaWV0ZkBs eW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCTx0YWJsZT48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcy cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdo dDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8v aGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAg ICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0 aCBXRyBJbnRlcmltIC0gT0F1dGggMi4wIFNlY3VyaXR5IEJDUA0KUFJJT1JJVFk6NQ0KQ0xBU1M6 UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVND UklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --000000000000760be605b141a67e-- From nobody Sat Oct 10 03:10:23 2020 Return-Path: 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 E7A0E3A1381 for ; Sat, 10 Oct 2020 03:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=lodderstedt.net 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 EoNv5PVtonmj for ; Sat, 10 Oct 2020 03:10:17 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 7A24E3A1380 for ; Sat, 10 Oct 2020 03:10:17 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id u8so16652687ejg.1 for ; Sat, 10 Oct 2020 03:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=lBbtVOm7Iv9ao5h5cR05rJJfCtBdYgO8vgzwFAczzVM=; b=HxM9DzcAJDFdW6ARO2GGLibqLWNSZZvvdOvH0B+3LTBHKzRUo+Vrq2emOVK0WqbINy 8gECpMrGnWpoP/yokUHCy5I+G33tXUAq7kDaRqbZCKusJ5x2G5kkJRmQBmQwSxIbsMRJ 14AU4l7q5LPftbG2BJthjBRVsggk9VF/ChZc0dUEtRCMNo38YKp35TD4fSEKHbLTy8Es IpUwkzx9QECKfOz7AjVPM5hu6pwqt/R7/Jv+x67LyPJfOT+dWZeLygu1XLJlPuCzAq7L +2ibxjy8vurrHV0jGXnZdDeybQ4yrXW5oS6ftDSpI1qkf3JfPA2vJCVJabjBzvtzKKMm VJcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=lBbtVOm7Iv9ao5h5cR05rJJfCtBdYgO8vgzwFAczzVM=; b=lJxmF51duyqkRfhxqYbJZUuiSOLI9P+a1KBVs5zKrntCPuNDI2tj90HX0m8KBrDcR0 lzramNG9aD1WNFyeYcf7PpiN/+tHEaiUN87zkT1L2tL596Ns1bx/QhKFO21I2Eh7mWPx wj8yIv9aq2ZqC2gX1cBnX6dWKLVyi3lG+eHm4ytPsMAwwAeIeCJ28d9NYU0KKK6/RQSY 0EruQ5VKzM9kkN0v9hr8oYfwxUQHlrR6Ldj6w2b/MSmQ2e8ms7TTUxx/5ZZS9MHhH0Rf ZTXoehX3FRkv8QBCY/epUgcJ/IqT1r9Qb0ZQm0xVdubKaRP7j8cFNmn+ACX21Fb58PHz KvOw== X-Gm-Message-State: AOAM531Iewp7P1Cw21uBpq2SwnKrYvPYBOdsxuCbqTg7ljFwHQ5rAqS3 ZCrXBAXlC2K0ASCjVzapHxxOhWifZ6nwJh6S X-Google-Smtp-Source: ABdhPJzEw/2SNgTNidg4SUHzOofbGfMfuGdFLXx96KrcmPhkAJZkLNhuHri6PDIG0r6vdcAA5QLeog== X-Received: by 2002:a17:906:1e15:: with SMTP id g21mr18059781ejj.131.1602324615562; Sat, 10 Oct 2020 03:10:15 -0700 (PDT) Received: from ?IPv6:2003:eb:8f1e:2ab3:509:1ac7:83:8202? (p200300eb8f1e2ab305091ac700838202.dip0.t-ipconnect.de. [2003:eb:8f1e:2ab3:509:1ac7:83:8202]) by smtp.gmail.com with ESMTPSA id g20sm8198886ejz.88.2020.10.10.03.10.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2020 03:10:14 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-5B33CACB-F6BB-4A76-B9D6-D46BCBFE7EBC; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 10 Oct 2020 12:10:13 +0200 Message-Id: References: <1611ED62-651C-4657-84A9-FF04CDF6903A@forgerock.com> Cc: Aaron Parecki , OAuth WG In-Reply-To: <1611ED62-651C-4657-84A9-FF04CDF6903A@forgerock.com> To: Neil Madden X-Mailer: iPad Mail (18A393) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 10:10:22 -0000 --Apple-Mail-5B33CACB-F6BB-4A76-B9D6-D46BCBFE7EBC Content-Type: multipart/alternative; boundary=Apple-Mail-4D565B04-4308-4C0E-9C9B-2BCF4712B663 Content-Transfer-Encoding: 7bit --Apple-Mail-4D565B04-4308-4C0E-9C9B-2BCF4712B663 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 07.10.2020 um 09:20 schrieb Neil Madden : >=20 > =EF=BB=BF >=20 >>> On 6 Oct 2020, at 23:05, Aaron Parecki wrote: >>>=20 >> =EF=BB=BF >> Hi all, I have a couple questions for those of you who have implemented r= efresh token rotation... >>=20 >> Have you included the option of a grace period on refresh token use, allo= wing multiple uses within some time window? I'm wondering because a grace pe= riod where a refresh token may be used more than once would work around the p= roblem that has been brought up, of a mobile app accidentally using a refres= h token more than once during normal operation because different threads are= unable to coordinate between themselves. However that also kind of defeats t= he purpose since attacks within that grace period would be hard to detect. I= 'm looking for an idea of where people have landed on that issue in practice= . >=20 > Right. We=E2=80=99ve avoided adding a grace period for this reason. An att= acker in a position to steal a refresh token is also presumably in a positio= n to see when the legitimate client uses it and then sneak in just afterward= s within the grace period. You could maybe only allow grace period refreshes= from the same IP address but I=E2=80=99m not sure that would always hold in= the flaky mobile network scenarios (eg refresh fails on 2G due to disconnec= t then client switches to Wifi hotspot and retries).=20 We did not implement a grace period for the same reason. Refresh token rotat= ion is a countermeasure against refresh token theft and replay for public cl= ient. A grace period to some degree limits it effectiveness against exactly t= his attack. best regards, Torsten. >=20 >> If you have implemented a grace period, then how do you handle expiring t= he additional refresh tokens that have been granted? For example, if RT "R1"= is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "= R1.2", what happens if "R1.2" is then later used? Would you invalidate "R1.1= " at that point? If so, why, and if not, why not? >>=20 >> It would be most interesting to hear practical experience from people who= have already built refresh token rotation into a system. >>=20 >> Thanks! >>=20 >> --- >> Aaron Parecki >> https://aaronparecki.com >>=20 >> _______________________________________________ >> 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 --Apple-Mail-4D565B04-4308-4C0E-9C9B-2BCF4712B663 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    Am 07.10.2020 um 09:20 schrieb Neil Madden &l= t;neil.madden@forgerock.com>:

    =EF=BB=BF

    On 6 Oct 2020, at 23:05, Aaron Parecki <aaron@pare= cki.com> wrote:

    =EF=BB=BF
    Hi all, I have a couple questions f= or those of you who have implemented refresh token rotation...
    Have you included the option of a grace period on refresh token u= se, allowing multiple uses within some time window? I'm wondering because a g= race period where a refresh token may be used more than once would work arou= nd the problem that has been brought up, of a mobile app accidentally u= sing a refresh token more than once during normal operation because differen= t threads are unable to coordinate between themselves. However that also kin= d of defeats the purpose since attacks within that grace period would be har= d to detect. I'm looking for an idea of where people have landed on that iss= ue in practice.

    Right. We=E2= =80=99ve avoided adding a grace period for this reason. An attacker in a pos= ition to steal a refresh token is also presumably in a position to see when t= he legitimate client uses it and then sneak in just afterwards within the gr= ace period. You could maybe only allow grace period refreshes from the same I= P address but I=E2=80=99m not sure that would always hold in the flaky mobil= e network scenarios (eg refresh fails on 2G due to disconnect then client sw= itches to Wifi hotspot and retries). 

    =
    We did not implement a grace period for the same reason. Refresh token= rotation is a countermeasure against refresh token theft and replay for pub= lic client. A grace period to some degree limits it effectiveness against ex= actly this attack.

    best regards,
    Torsten.


    If you have implemente= d a grace period, then how do you handle expiring the additional refresh tok= ens that have been granted? For example, if RT "R1" is used twice, resulting=  in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what happens i= f "R1.2" is then later used? Would you invalidate "R1.1" at that point? If s= o, why, and if not, why not?

    It would be most inter= esting to hear practical experience from people who have already built refre= sh token rotation into a system.

    Thanks!

    ---
    Aaron Parecki
    _______________________________________________
    OAuth m= ailing list
    OAuth@ietf.org
    https://www.ietf.= org/mailman/listinfo/oauth
    ______________= _________________________________
    OAuth mailing list<= br>OAuth@ietf.org
    https://www.ietf.org/mailman/listinf= o/oauth
    = --Apple-Mail-4D565B04-4308-4C0E-9C9B-2BCF4712B663-- --Apple-Mail-5B33CACB-F6BB-4A76-B9D6-D46BCBFE7EBC Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMDEwMTAxMDEzWjAvBgkqhkiG9w0BCQQxIgQg iBZvco/s1yCUdwczgLmENFX5PlCr6m5Yjp6aEWPmX+MwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEARn4FfoHuCSHGt8Z3aKIQ4bIFVxx1yWJwK6o15n4VsVtniARGipOL NOQ6SNZhqqmhnOa0aNcWIp7ntSjDihVYKKn7AYxhSllIPC09kivub2w9vinKpQo7IeGRCELiw6ev apSYeYOfhakTyXkmLToHjbj2ybDvag+lM/nQmCSaWvEiy047sOfnh8b+gPKutqgkw7okrK8eIvCL cg/KtBOH1Fvl81y2cjxedvWMxzvhJ8X6dK16seZ+Jd7RWum00KSdBlVwDDqQgJSk/hMCwMTFZ2Jz 9UIpRDR71iRwoS54YteP1oCPk1v0vPzAAAQohsAEkfSzi86hU5SxIP6Z+7XmeQAAAAAAAA== --Apple-Mail-5B33CACB-F6BB-4A76-B9D6-D46BCBFE7EBC-- From nobody Sat Oct 10 13:42:02 2020 Return-Path: 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 D1E393A07BD for ; Sat, 10 Oct 2020 13:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.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 QWaozoFaVq6y for ; Sat, 10 Oct 2020 13:41:59 -0700 (PDT) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899693A07B0 for ; Sat, 10 Oct 2020 13:41:59 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 56ECC20473D; Sat, 10 Oct 2020 20:41:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1602362517; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tVIUL5pJlkKBNlfa2qDUmQ2vdIMCMQeXy5QNh9W87CQ=; b=aNpIgRE7DaLPnXjPCzC9f0yb/nyDObKXFvvfz3eYuUNQwaD28dkb3d468EhIJGMu74Vd5d NqIqwYAWeJH5ugAR5sbfZ/YZuEpQp4ard6xXvo0F0fEne3XlHXA67zH8gnnT4RFLWuBxzu SHV8LWVW1kl4vQQMSwn3m2Vfl9psxvI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From: David Waite In-Reply-To: Date: Sat, 10 Oct 2020 14:41:54 -0600 Cc: OAuth WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Parecki Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 20:42:01 -0000 On Oct 6, 2020, at 16:05, Aaron Parecki wrote: > However that also kind of defeats the purpose since attacks within = that grace period would be hard to detect. I'm looking for an idea of = where people have landed on that issue in practice. This is effectively a race condition, and a grace period hides your = ability to detect the race. Because of the race condition is no = guarantee that the second refresh token is the one that is retained, the = client could still fail once it needs its next access token. Instead, an ideal system would allow you to make a security exception = and turn off rotation, possibly only until the client revises their = logic. -DW= From nobody Sat Oct 10 14:16:40 2020 Return-Path: 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 15BE73A08CF for ; Sat, 10 Oct 2020 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 tSNIV7ytt2Q7 for ; Sat, 10 Oct 2020 14:16:37 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 0C05C3A08CD for ; Sat, 10 Oct 2020 14:16:37 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id h20so13031472lji.9 for ; Sat, 10 Oct 2020 14:16:36 -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; bh=Dhy7lVdq9vVfjAAk7VsjD0FalzfFf3cceovgCMacigM=; b=ZklasIT54KBF9RQoJ90D58GahNuhKOMCRc8EZ1w8EQyZVQTCrV7zB8lc6dRgXdg9qG MSo84FC61eZtfztFzoPTYtj8NJOco7sQb41OAjdjsp9XvyLfMIiHrrrpbO00OuWBaxDe mDjSKL7f3HGCGLrtuDzHgfegpM+AhMI4lom+IekEDYkkPVv6REIZc6SkbEJ4B26Uvfon awS61uigcpm9iHQYQ+aCcxM6QT9Gh19B1dYgE05hLQNLx1xJP+EVIoO58NENhA/PnB0f HqGXh2eL82AO+Fi8SAkyjfyiWn8ALut6ENbzkePgdVc8rPGZ5lxxd/NSpcsKbHK0XWrX TQkg== 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; bh=Dhy7lVdq9vVfjAAk7VsjD0FalzfFf3cceovgCMacigM=; b=X+4eE43dVGEITP2eaF8p0Enhb32lB5/56aBrTZ8bxSiQKAv48HAJrZ6fJmQK2AxodY jn3337V/daG/mktrVy/OVznZ1sAgjzrcVPtm/aHBB0Uw3ZW+EbgLXgI6H+V78eI7Uc4U hg79ef17dmfIKAuQUh7wYCWH5MwnehMo0WBGFo6d4dZw9XMneFqA7LIjGsXebsKDoV6Y YstOwfycg0hkv5hwO/e0+QXsDL7d6N8JaW7abuvTZ48Q95XtCGqDLSpQ8MIYDQ086gKg D5ZJhfKqFai0DL0LH6hNveg8TWvIj1/9E0V0dLjqaik5S2aV8nM41TvxJnC2Mm8quNTl LZnw== X-Gm-Message-State: AOAM5309xDKSfAtOXV/zXLSxS1fT6N/Y5/QyJloaHjFtT73vTzz5ozZd p/DyeLh29kZ5+Px4ACGgFjHi1XQHZDLEpwT59nFNxqtKprk= X-Google-Smtp-Source: ABdhPJw6HNcZB5p+i7w0KcdzPDy05RjA3Ot6dh8bryZBY18EpYLQl5le+wvy1HCmD3NtDvq/NEPp5DkbOhBltGxLqtk= X-Received: by 2002:a2e:a177:: with SMTP id u23mr7196069ljl.104.1602364595021; Sat, 10 Oct 2020 14:16:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sascha Preibisch Date: Sat, 10 Oct 2020 14:16:23 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000007cad6d05b15794e6" Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 21:16:39 -0000 --0000000000007cad6d05b15794e6 Content-Type: text/plain; charset="UTF-8" In the past, customers brought to our attention that some clients were not able to receive a new refresh_token and use it right away. For that use case we added a different type of rotation. The new refresh_token was exactly the same as the given one. Except that it had a new expiration date, lifetime and such. It was usually tight to exactly one scope valid scope value. Since customers were able to configure this behaviour for specific clients, they used this feature for single or a limited number of use cases. Other than that, a used refresh_token became invalid once it was used with no overlap. Regards, Sascha On Sat, 10 Oct 2020 at 13:42, David Waite wrote: > On Oct 6, 2020, at 16:05, Aaron Parecki wrote: > > However that also kind of defeats the purpose since attacks within that > grace period would be hard to detect. I'm looking for an idea of where > people have landed on that issue in practice. > > This is effectively a race condition, and a grace period hides your > ability to detect the race. Because of the race condition is no guarantee > that the second refresh token is the one that is retained, the client could > still fail once it needs its next access token. > > Instead, an ideal system would allow you to make a security exception and > turn off rotation, possibly only until the client revises their logic. > > -DW > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000007cad6d05b15794e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    In the past, customers brought to=C2=A0our=C2=A0attention = that some clients were not able to receive a new refresh_token and use it r= ight away. For that use case we added a different=C2=A0type of rotation. Th= e new refresh_token was exactly the same as the given one. Except that it h= ad a new expiration date, lifetime and such. It was usually tight to exactl= y one scope valid scope value.
    Since customers were able to configure t= his behaviour for specific clients, they used this feature for single or a = limited=C2=A0number of use cases.
    Other than that, a used refresh= _token became invalid once it was used with no overlap.

    Regards,
    Sascha

    <= div dir=3D"ltr" class=3D"gmail_attr">On Sat, 10 Oct 2020 at 13:42, David Wa= ite <david=3D= 40alkaline-solutions.com@dmarc.ietf.org> wrote:
    On Oct 6, 2020, at 16:05, Aaron Parecki <aaron@parecki.com> wrote:
    > However that also kind of defeats the purpose since attacks within tha= t grace period would be hard to detect. I'm looking for an idea of wher= e people have landed on that issue in practice.

    This is effectively a race condition, and a grace period hides your ability= to detect the race. Because of the race condition is no guarantee that the= second refresh token is the one that is retained, the client could still f= ail once it needs its next access token.

    Instead, an ideal system would allow you to make a security exception and t= urn off rotation, possibly only until the client revises their logic.

    -DW
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000007cad6d05b15794e6-- From nobody Sun Oct 11 21:43:48 2020 Return-Path: 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 26AF73A0C45 for ; Sun, 11 Oct 2020 21:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 5xfRjrNilbJN for ; Sun, 11 Oct 2020 21:43:43 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 61C513A0C43 for ; Sun, 11 Oct 2020 21:43:43 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id p15so21297743ejm.7 for ; Sun, 11 Oct 2020 21:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q+bQC2VJmNc7JeWM924e8btFjRY63Fwpv6FAgIL+c50=; b=WaFo6zLMGyyDWlN/vw2cjT9tBslQ4//9AlelaUMv5H975hcAB7orbBh5E8hlRb7ddk OH++BUXuH4eDpM3ZGQOuB4GxUwlEmdPJ/4Oj3CL6N6cWnG8N4p1vY4l96IDSUz26OAiy W0x1H8YCxcLNIPXUenkvrzc1us1fUNOFvq++g= 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=Q+bQC2VJmNc7JeWM924e8btFjRY63Fwpv6FAgIL+c50=; b=ujfhNnJSCKFS4Tq3UditVXVK4LUA4E/zFHld2djonMjgQWNBKqFVPfZ+Z2a1RNWYEu HMhWDjiUtAJfxqLFAO+v8CRjPo5Iw/E2rewLUywsKQiaoFLrZ/Rwah83WhaHmJDeVU71 WWg8Z8CPOBGZuuMWErFXDVdyFNwTd5La8wmCBRdLSOTAMOWLZzvVTB+XZg57e+onvU4R JFSiS3iHE9/zwFnuE3HV8BZTfJZdwMSQv2j1QVdtwK/frWjJT5e0oZ/pNDiMuXKfK13v ugcJ9gp8PmD/fZ9djmoghnaiK3KyYB87VLwChrIfjfzxOUUoU2SZSNUV5OSdfCVGdWxt N1wg== X-Gm-Message-State: AOAM531083kh7Pad0vkIcN+xoUvxW3vUuqgEW/gjEqRvk9uDfMTAVSpa /XiiFxalNyybCid4PkMhFM4T4FVpKN5IdmLKEY9Zre0qSau90Qcy3Q+QGWv18mAFs2PC644QoQ1 dU/WLowonrfWNWFSXP3l3x4utWaw= X-Google-Smtp-Source: ABdhPJyM6na3l6RcnE3t8MmF2nk4110YWsxXl/eOd0l9+rUNbObrzGIlAuLSOH5b/kxcD5xgv+VUu8T3BFdrO1jVMB4= X-Received: by 2002:a17:906:2709:: with SMTP id z9mr4343408ejc.277.1602477821654; Sun, 11 Oct 2020 21:43:41 -0700 (PDT) MIME-Version: 1.0 References: <067801d69c30$02119bc0$0634d340$@auth0.com> In-Reply-To: From: Dave Tonge Date: Mon, 12 Oct 2020 06:43:30 +0200 Message-ID: To: Jeff Craig Cc: vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG Content-Type: multipart/alternative; boundary="000000000000520f8305b171f14c" Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 04:43:46 -0000 --000000000000520f8305b171f14c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Our goal is to prevent cases where we lose the ability to Refresh a Token due to transient issues (which have run the gamut from network problems to bad software updates on the AS side). We've seen this issue quite a bit and it's very frustrating. I would suggest that refresh token rotation is not used for confidential clients that authenticate with private_key_jwt or tls_client_auth. On Wed, 7 Oct 2020 at 00:57, Jeff Craig wrote: > My experience is more from the Client side of the equation on this > problem, but I do have some thoughts. Our goal is to prevent cases where = we > lose the ability to Refresh a Token due to transient issues (which have r= un > the gamut from network problems to bad software updates on the AS side). > Our use case also does all token handling server-side, so our threat mode= l > is not the same as the mobile application you described. There is a clear > tradeoff in reducing user friction with additional authorization events, > and securing access. > > The recommendation my team typically gives people building Authorization > Servers with Refresh Token Rotation is to keep the old refresh token unti= l > they see the new one (which means that there are generally two refresh > tokens valid at any point in time, an unfortunate trade-off). A more > difficult, but potentially plausible implementation would be to hold onto > the older Refresh Token until the newly issued Access Token is used (thus > implying the refresh was successful on both sides). > > We aren't trying to protect against multiple in-flight refreshes though > (we've done a LOT of work to attempt to remove that possibility in a > globally consistent manner), we're trying to protect against a network > interruption that prevents the first use of R1, so our assumption is that > R2.1 was completely lost, and only R2.2 matters moving forward. Meaning: = R1 > is sent, A/R2.1 is dropped in flight, R1 is sent again, A/R2.2 is returne= d > and stored. Since R1 was seen a second time, we recommend that R2.1 be > ignored in future. Next refresh will use R2.2, at which point R1 should > never be seen again. > > The biggest issue that I see with a time-based grace period is that for > many offline tasks, a single refresh failure may be ignored by the client= , > and it could be hours before the second refresh attempt using the older > refresh token is made (depending on time of day and what these requests a= re > being used for), making the grace period low value in that case. > > On Tue, Oct 6, 2020 at 5:28 PM 40auth0.com@dmarc.ietf.org> wrote: > >> Hey Aaron, >> >> Auth0 does offer a configurable grace period, during which the >> =E2=80=9Cpreceding=E2=80=9D token can be reused. >> >> I am not 100% sure what we do in the exact scenario you described, and I >> will double check for you, but here=E2=80=99s my intuition. >> >> >> >> The operation redeem(RT_n) should result in AT, RT_n+1. The grace period >> just extends the time in which the operation can occur, but every operat= ion >> should be idempotent. All repeats of that operation within the grace per= iod >> should have the same result, which means that every resulting RT is a >> representative of the RT_n+1 class, hence all valid at the same time. Af= ter >> the grace period elapses, RT_n is invalid, and that=E2=80=99s it. >> >> So, in your example I would consider RT1.1 and RT1.2 as equivalent, as >> they are both representatives of the RT_n+1 equivalence class. >> >> >> >> It would be very hard to do otherwise, given that network operations >> aren=E2=80=99t guaranteed to be concluded in the order they were execute= d without >> semaphores, and above all the network failures the grace period is desig= ned >> to handle can apply to any of the requests, regardless of the order. >> >> >> >> *From:* OAuth *On Behalf Of *Aaron Parecki >> *Sent:* Tuesday, October 6, 2020 3:06 PM >> *To:* OAuth WG >> *Subject:* [OAUTH-WG] Implementation questions around refresh token >> rotation >> >> >> >> Hi all, I have a couple questions for those of you who have implemented >> refresh token rotation... >> >> >> >> Have you included the option of a grace period on refresh token use, >> allowing multiple uses within some time window? I'm wondering because a >> grace period where a refresh token may be used more than once would work >> around the problem that has been brought up, of a mobile app accidentall= y >> using a refresh token more than once during normal operation because >> different threads are unable to coordinate between themselves. However t= hat >> also kind of defeats the purpose since attacks within that grace period >> would be hard to detect. I'm looking for an idea of where people have >> landed on that issue in practice. >> >> >> >> If you have implemented a grace period, then how do you handle expiring >> the additional refresh tokens that have been granted? For example, if RT >> "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.= 1" >> and "R1.2", what happens if "R1.2" is then later used? Would you invalid= ate >> "R1.1" at that point? If so, why, and if not, why not? >> >> >> >> It would be most interesting to hear practical experience from people wh= o >> have already built refresh token rotation into a system. >> >> >> >> Thanks! >> >> >> --- >> >> Aaron Parecki >> >> https://aaronparecki.com >> >> >> _______________________________________________ >> 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 > --=20 Dave Tonge --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000520f8305b171f14c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    >=C2=A0Our goal is to prevent cases where we lose the abil= ity to Refresh a Token due to transient issues (which have run the gamut fr= om network problems to bad software updates on the AS side).

    We've seen this issue= quite a bit and it's very frustrating. I would suggest that refresh to= ken rotation is not used for confidential clients that authenticate with pr= ivate_key_jwt or tls_client_auth.=C2=A0

    On Wed, 7 Oct 2020 at 0= 0:57, Jeff Craig <jeffcraig=3D40google.com@dmarc.ietf.org> wrote:
    My experience is mor= e from the Client side of the equation on this problem, but I do have some = thoughts. Our goal is to prevent cases where we lose the ability to Refresh= a Token due to transient issues (which have run the gamut from network pro= blems to bad software updates on the AS side). Our use case also does all t= oken handling server-side, so our threat model is not the same as the mobil= e application you described. There is a clear tradeoff in reducing user fri= ction with additional authorization events, and securing access.
    =
    The recommendation my team typically gives people buil= ding=C2=A0Authorization Servers with Refresh Token Rotation is to keep the = old refresh token until they see the new one=C2=A0(which means that there a= re generally two refresh tokens valid at any point in time, an unfortunate = trade-off). A more difficult, but potentially plausible implementation woul= d be to hold onto the older Refresh Token until the newly issued Access Tok= en is used (thus implying the refresh=C2=A0was successful on both sides). <= div>
    We aren't trying to protect against multiple in-flig= ht refreshes though (we've done a LOT of work to attempt to remove that= possibility in a globally consistent manner), we're trying to protect = against a network interruption that prevents the first use of R1, so our as= sumption is that R2.1 was completely lost, and only R2.2 matters moving for= ward. Meaning: R1 is sent, A/R2.1 is dropped in flight, R1 is sent again, A= /R2.2 is returned and stored. Since R1 was seen a second time, we recommend= that R2.1 be ignored in future. Next refresh will use R2.2, at which point= R1 should never be seen again.

    The biggest issue = that I see with a time-based grace period is that for many offline tasks, a= single refresh failure may be ignored by the client, and it could be hours= before the second refresh attempt using the older refresh token is made (d= epending on time of day and what these requests are being used for), making= the grace period low value in that case.

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    On Tue, Oct 6, 2020 at 5:28 = PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

    Hey Aaron,

    Auth0 doe= s offer a configurable grace period, during which the =E2=80=9Cpreceding=E2= =80=9D token can be reused.

    I am n= ot 100% sure what we do in the exact scenario you described, and I will dou= ble check for you, but here=E2=80=99s my intuition.

    =C2=A0

    The operati= on redeem(RT_n) should result in AT, RT_n+1. The grace period just extends = the time in which the operation can occur, but every operation should be id= empotent. All repeats of that operation within the grace period should have= the same result, which means that every resulting RT is a representative o= f the RT_n+1 class, hence all valid at the same time. After the grace perio= d elapses, RT_n is invalid, and that=E2=80=99s it.

    So, in your example I would consider RT1.1 and RT1.2 as equ= ivalent, as they are both representatives of the RT_n+1 equivalence class.<= u>

    =C2=A0

    It would be very hard to do otherwise, given that network opera= tions aren=E2=80=99t guaranteed to be concluded in the order they were exec= uted without semaphores, and above all the network failures the grace perio= d is designed to handle can apply to any of the requests, regardless of the= order.

    =C2=A0

    = From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
    Sent: Tuesday, October 6, 2020 3:06 PM
    To: OAuth WG <oauth@ietf.org>
    <= b>Subject: [OAUTH-WG] Implementation questions around refresh token rot= ation

    =C2=A0

    Hi all, I have a couple questions for tho= se of you who have implemented refresh token rotation...

    <= /div>

    =C2=A0

    Have you included the option of a grace period on refresh t= oken use, allowing multiple uses within some time window? I'm wondering= because a grace period where a refresh token may be used more than once wo= uld work around the problem that has been brought up,=C2=A0of a mobile app = accidentally using a refresh token more than once during normal operation b= ecause different threads are unable to coordinate between themselves. Howev= er that also kind of defeats the purpose since attacks within that grace pe= riod would be hard to detect. I'm looking for an idea of where people h= ave landed on that issue in practice.

    =C2=A0

    If= you have implemented a grace period, then how do you handle expiring the a= dditional refresh tokens that have been granted? For example, if RT "R= 1" is used twice, resulting=C2=A0in new ATs "A1.1", "A1= .2" and new RTs "R1.1" and "R1.2", what happens if= "R1.2" is then later used? Would you invalidate "R1.1"= at that point? If so, why, and if not, why not?

    =C2=A0

    It would be most interesting to hear practical experience from peop= le who have already built refresh token rotation into a system.

    =C2=A0

    =

    Thanks!


    ---

    Aaron Parecki

    =C2=A0

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Dave To= nge

    =

    Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

    = DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


    --000000000000520f8305b171f14c-- From nobody Sun Oct 11 23:58:03 2020 Return-Path: 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 EFB6E3A1304 for ; Sun, 11 Oct 2020 23:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=forgerock.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 KHUrMnnwcrjo for ; Sun, 11 Oct 2020 23:57:52 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 88BB83A12CB for ; Sun, 11 Oct 2020 23:57:51 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id l15so13112654wmh.1 for ; Sun, 11 Oct 2020 23:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VQdBQNsifhEX9QTi1XO+kxVAi8AEFYMygVJQTkPsNqg=; b=cx2ygXActmBubSRetBUEcI7QSgPQBmqvy381YHAMguewp1qNyHhhgxZz31Fi21sdXw XGKQITizxfMByKjOv/OQr2rxxZsmdVCv22rxWBlhCdAygVACTqPysfKASyBXHo6YF8vi VkKgrNwHL+AFEoauhv1qQEnvq6R4OWuD4ZniA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VQdBQNsifhEX9QTi1XO+kxVAi8AEFYMygVJQTkPsNqg=; b=M4Fv2jQ+i5r97yTD50A8oFzZ35ZCrtOaTmGu4Cm31FwvQ7zEYQFfVSmA2X/9vYrC4m O1kdSwbW7E4W6fI9b83SyQXQH1kwLBvZji2EQ+5G5375CoLt79C6Kx+OeTKUjQKnOvoK jSAh/eousT20QanVOaeAFyJLBsrEX6Lb4BfTtQcZO/oxrKxtpkVEobGYtp9X67hqRaEr qUZtP+b+5wINukxu8TE3Lkg4MpcmLk7bVbJ8EO4ipv6zkFALvgdEYznBz2039OAwg9iX apPsnvjWyYmnBCaF6WvL+bECdBcC4d6a4cY3RhVIfbhFOwSQfsLgqhffwdxhB4BgOFsg RjCw== X-Gm-Message-State: AOAM532OzwFAPn0vPGtku1/emVGQGZZJvLfO+igse4VaOb2oTrdxvUb/ gYZvnsXZlR4wgp8E77DCRlR2Tba4d2IJTubB X-Google-Smtp-Source: ABdhPJxPJ5NG5jCmVHGe8e7JV1QGAv+VwnIvSiSd2uDvJzhxFAT8XSSSDo2avnzQT/wZz2uF3t3NCQ== X-Received: by 2002:a7b:c317:: with SMTP id k23mr9062718wmj.44.1602485869386; Sun, 11 Oct 2020 23:57:49 -0700 (PDT) Received: from [10.0.0.4] (45.133.143.150.dyn.plus.net. [150.143.133.45]) by smtp.gmail.com with ESMTPSA id n2sm21994296wma.29.2020.10.11.23.57.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2020 23:57:48 -0700 (PDT) From: Neil Madden Message-Id: <6E139FB3-D319-452E-BD84-17515CBE3F26@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF8E3DF1-D3D1-484D-BE76-A680C3FD14D8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 12 Oct 2020 07:57:47 +0100 In-Reply-To: Cc: Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG To: Dave Tonge References: <067801d69c30$02119bc0$0634d340$@auth0.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 06:58:01 -0000 --Apple-Mail=_DF8E3DF1-D3D1-484D-BE76-A680C3FD14D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not sure I agree with this advice. Singling out = private_key_jwt and tls_client_auth suggests that the problem is an = attacker being able to eavesdrop on the refresh request itself and then = replay it. But if they are able to do that then they can instead just = steal the access tokens from the response. I think refresh token rotation is better thought of as providing = protection against insecure token storage on the client (e.g. in browser = localStorage). Both public and confidential clients are capable of = creating secure connections with TLS, but we assume that confidential = clients (regardless of auth mechanism) have access to secure storage - = otherwise they shouldn=E2=80=99t be confidential clients in the first = place. I think the same reasoning applies here too - if a client has insecure = storage then an attacker could just steal the access tokens instead. But = I think the difference is that an attacker is more likely to gain = temporary access to local storage (e.g. when the user goes to the = bathroom and leaves their device unlocked) than they are to gain = temporary access to eavesdrop on a connection. The kind of = vulnerabilities that allow eavesdropping tend to be repeatable so the = attacker doesn=E2=80=99t need to steal a refresh token to ensure ongoing = access, they can just steal the access tokens every time the client = refreshes. That said, there are lots of vulnerabilities that would give an attacker = repeatable access to the client=E2=80=99s local storage - e.g. XSS - so = refresh token rotation only catches a subset of possible attacks. =E2=80=94 Neil > On 12 Oct 2020, at 05:43, Dave Tonge = wrote: >=20 > > Our goal is to prevent cases where we lose the ability to Refresh a = Token due to transient issues (which have run the gamut from network = problems to bad software updates on the AS side). >=20 > We've seen this issue quite a bit and it's very frustrating. I would = suggest that refresh token rotation is not used for confidential clients = that authenticate with private_key_jwt or tls_client_auth.=20 >=20 > On Wed, 7 Oct 2020 at 00:57, Jeff Craig = > wrote: > My experience is more from the Client side of the equation on this = problem, but I do have some thoughts. Our goal is to prevent cases where = we lose the ability to Refresh a Token due to transient issues (which = have run the gamut from network problems to bad software updates on the = AS side). Our use case also does all token handling server-side, so our = threat model is not the same as the mobile application you described. = There is a clear tradeoff in reducing user friction with additional = authorization events, and securing access. >=20 > The recommendation my team typically gives people building = Authorization Servers with Refresh Token Rotation is to keep the old = refresh token until they see the new one (which means that there are = generally two refresh tokens valid at any point in time, an unfortunate = trade-off). A more difficult, but potentially plausible implementation = would be to hold onto the older Refresh Token until the newly issued = Access Token is used (thus implying the refresh was successful on both = sides). >=20 > We aren't trying to protect against multiple in-flight refreshes = though (we've done a LOT of work to attempt to remove that possibility = in a globally consistent manner), we're trying to protect against a = network interruption that prevents the first use of R1, so our = assumption is that R2.1 was completely lost, and only R2.2 matters = moving forward. Meaning: R1 is sent, A/R2.1 is dropped in flight, R1 is = sent again, A/R2.2 is returned and stored. Since R1 was seen a second = time, we recommend that R2.1 be ignored in future. Next refresh will use = R2.2, at which point R1 should never be seen again. >=20 > The biggest issue that I see with a time-based grace period is that = for many offline tasks, a single refresh failure may be ignored by the = client, and it could be hours before the second refresh attempt using = the older refresh token is made (depending on time of day and what these = requests are being used for), making the grace period low value in that = case. >=20 > On Tue, Oct 6, 2020 at 5:28 PM = > wrote: > Hey Aaron, >=20 > Auth0 does offer a configurable grace period, during which the = =E2=80=9Cpreceding=E2=80=9D token can be reused. >=20 > I am not 100% sure what we do in the exact scenario you described, and = I will double check for you, but here=E2=80=99s my intuition. >=20 > =20 >=20 > The operation redeem(RT_n) should result in AT, RT_n+1. The grace = period just extends the time in which the operation can occur, but every = operation should be idempotent. All repeats of that operation within the = grace period should have the same result, which means that every = resulting RT is a representative of the RT_n+1 class, hence all valid at = the same time. After the grace period elapses, RT_n is invalid, and = that=E2=80=99s it. >=20 > So, in your example I would consider RT1.1 and RT1.2 as equivalent, as = they are both representatives of the RT_n+1 equivalence class. >=20 > =20 >=20 > It would be very hard to do otherwise, given that network operations = aren=E2=80=99t guaranteed to be concluded in the order they were = executed without semaphores, and above all the network failures the = grace period is designed to handle can apply to any of the requests, = regardless of the order. >=20 > =20 >=20 > From: OAuth > = On Behalf Of Aaron Parecki > Sent: Tuesday, October 6, 2020 3:06 PM > To: OAuth WG > > Subject: [OAUTH-WG] Implementation questions around refresh token = rotation >=20 > =20 >=20 > Hi all, I have a couple questions for those of you who have = implemented refresh token rotation... >=20 > =20 >=20 > Have you included the option of a grace period on refresh token use, = allowing multiple uses within some time window? I'm wondering because a = grace period where a refresh token may be used more than once would work = around the problem that has been brought up, of a mobile app = accidentally using a refresh token more than once during normal = operation because different threads are unable to coordinate between = themselves. However that also kind of defeats the purpose since attacks = within that grace period would be hard to detect. I'm looking for an = idea of where people have landed on that issue in practice. >=20 > =20 >=20 > If you have implemented a grace period, then how do you handle = expiring the additional refresh tokens that have been granted? For = example, if RT "R1" is used twice, resulting in new ATs "A1.1", "A1.2" = and new RTs "R1.1" and "R1.2", what happens if "R1.2" is then later = used? Would you invalidate "R1.1" at that point? If so, why, and if not, = why not? >=20 > =20 >=20 > It would be most interesting to hear practical experience from people = who have already built refresh token rotation into a system. >=20 > =20 >=20 > Thanks! >=20 >=20 >=20 > --- >=20 > Aaron Parecki >=20 > https://aaronparecki.com > =20 >=20 > _______________________________________________ > 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 = >=20 >=20 > --=20 > Dave Tonge >=20 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DF8E3DF1-D3D1-484D-BE76-A680C3FD14D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m not sure I agree with this advice. Singling out private_key_jwt and = tls_client_auth suggests that the problem is an attacker being able to = eavesdrop on the refresh request itself and then replay it. But if they = are able to do that then they can instead just steal the access tokens = from the response.

    I = think refresh token rotation is better thought of as providing = protection against insecure token storage on the client (e.g. in browser = localStorage). Both public and confidential clients are capable of = creating secure connections with TLS, but we assume that confidential = clients (regardless of auth mechanism) have access to secure storage - = otherwise they shouldn=E2=80=99t be confidential clients in the first = place.

    I think = the same reasoning applies here too - if a client has insecure storage = then an attacker could just steal the access tokens instead. But I think = the difference is that an attacker is more likely to gain temporary = access to local storage (e.g. when the user goes to the bathroom and = leaves their device unlocked) than they are to gain temporary access to = eavesdrop on a connection. The kind of vulnerabilities that allow = eavesdropping tend to be repeatable so the attacker doesn=E2=80=99t need = to steal a refresh token to ensure ongoing access, they can just steal = the access tokens every time the client refreshes.

    That said, there are = lots of vulnerabilities that would give an attacker repeatable access to = the client=E2=80=99s local storage - e.g. XSS - so refresh token = rotation only catches a subset of possible attacks.

    =E2=80=94 Neil

    On 12 Oct 2020, at 05:43, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

    > Our goal is = to prevent cases where we lose the ability to Refresh a Token due to = transient issues (which have run the gamut from network problems to bad = software updates on the AS side).

    We've seen = this issue quite a bit and it's very frustrating. I would suggest that = refresh token rotation is not used for confidential clients that = authenticate with private_key_jwt or = tls_client_auth. 

    On Wed, 7 = Oct 2020 at 00:57, Jeff Craig <jeffcraig=3D40google.com@dmarc.ietf.org> wrote:
    My experience is more from the Client side of the equation on = this problem, but I do have some thoughts. Our goal is to prevent cases = where we lose the ability to Refresh a Token due to transient issues = (which have run the gamut from network problems to bad software updates = on the AS side). Our use case also does all token handling server-side, = so our threat model is not the same as the mobile application you = described. There is a clear tradeoff in reducing user friction with = additional authorization events, and securing access.

    The recommendation = my team typically gives people building Authorization Servers with = Refresh Token Rotation is to keep the old refresh token until they see = the new one (which means that there are generally two refresh = tokens valid at any point in time, an unfortunate trade-off). A more = difficult, but potentially plausible implementation would be to hold = onto the older Refresh Token until the newly issued Access Token is used = (thus implying the refresh was successful on both sides).

    We aren't trying to = protect against multiple in-flight refreshes though (we've done a LOT of = work to attempt to remove that possibility in a globally consistent = manner), we're trying to protect against a network interruption that = prevents the first use of R1, so our assumption is that R2.1 was = completely lost, and only R2.2 matters moving forward. Meaning: R1 is = sent, A/R2.1 is dropped in flight, R1 is sent again, A/R2.2 is returned = and stored. Since R1 was seen a second time, we recommend that R2.1 be = ignored in future. Next refresh will use R2.2, at which point R1 should = never be seen again.

    The biggest issue that I see with a time-based grace period = is that for many offline tasks, a single refresh failure may be ignored = by the client, and it could be hours before the second refresh attempt = using the older refresh token is made (depending on time of day and what = these requests are being used for), making the grace period low value in = that case.

    On Tue, Oct 6, 2020 at 5:28 PM = <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

    Hey Aaron,

    Auth0 does offer a = configurable grace period, during which the =E2=80=9Cpreceding=E2=80=9D = token can be reused.

    I am not 100% sure what we do in the exact scenario = you described, and I will double check for you, but here=E2=80=99s my = intuition.

     

    The operation redeem(RT_n) should result in AT, = RT_n+1. The grace period just extends the time in which the operation = can occur, but every operation should be idempotent. All repeats of that = operation within the grace period should have the same result, which = means that every resulting RT is a representative of the RT_n+1 class, = hence all valid at the same time. After the grace period elapses, RT_n = is invalid, and that=E2=80=99s it.

    So, in your example I would = consider RT1.1 and RT1.2 as equivalent, as they are both representatives = of the RT_n+1 equivalence class.

     

    It would be very hard to do otherwise, given that = network operations aren=E2=80=99t guaranteed to be concluded in the = order they were executed without semaphores, and above all the network = failures the grace period is designed to handle can apply to any of the = requests, regardless of the order.

     

    From: OAuth <oauth-bounces@ietf.org> On Behalf Of = Aaron Parecki
    Sent: Tuesday, October = 6, 2020 3:06 PM
    To: OAuth WG <oauth@ietf.org>
    Subject:= [OAUTH-WG] Implementation questions around refresh token rotation

     

    Hi all, I have a couple questions for = those of you who have implemented refresh token rotation...

     

    Have you = included the option of a grace period on refresh token use, allowing = multiple uses within some time window? I'm wondering because a grace = period where a refresh token may be used more than once would work = around the problem that has been brought up, of a mobile app = accidentally using a refresh token more than once during normal = operation because different threads are unable to coordinate between = themselves. However that also kind of defeats the purpose since attacks = within that grace period would be hard to detect. I'm looking for an = idea of where people have landed on that issue in practice.

     

    If you = have implemented a grace period, then how do you handle expiring the = additional refresh tokens that have been granted? For example, if RT = "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs = "R1.1" and "R1.2", what happens if "R1.2" is then later used? Would you = invalidate "R1.1" at that point? If so, why, and if not, why not?

     

    It would = be most interesting to hear practical experience from people who have = already built refresh token rotation into a system.

     

    Thanks!


    ---

    Aaron = Parecki

    https://aaronparecki.com

     

    _____________= __________________________________
    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


    --
    Dave Tonge


    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial = Technology is registered in England & Wales, company registration = number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 = Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 = 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is = confidential. Use of this email or of any information in it other than = by the addressee is unauthorised and unlawful. Whilst reasonable efforts = are made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded = for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group = company.


    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    = --Apple-Mail=_DF8E3DF1-D3D1-484D-BE76-A680C3FD14D8-- From nobody Mon Oct 12 00:04:02 2020 Return-Path: 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 2D2563A0F35 for ; Mon, 12 Oct 2020 00:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 l0x7i8YavrK3 for ; Mon, 12 Oct 2020 00:03:58 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 D144A3A0D25 for ; Mon, 12 Oct 2020 00:03:57 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id a3so21633948ejy.11 for ; Mon, 12 Oct 2020 00:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4NzDWsSkf5Q422E3WHkoQ2VLaA8WaJZFjL6rMWol3xI=; b=SNqvRrgBzL7/GFTk+qvK55i6k6r+SrDPQkfjTH12dhkMWFzoXLPDiG7HA/mJy5DMsg AWhkvGjwqwO4gnvtv1LOVej6j5/2FyiNc20hm3pKYAy5QvNPpzBXYkcAiABrcRq9CWvm sbZFsKPdE9YDa60eTty/gjfYcJ2lIsVdO/Rcw= 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=4NzDWsSkf5Q422E3WHkoQ2VLaA8WaJZFjL6rMWol3xI=; b=Vo+76iuOQ0MV0fcFfHOBkdv/HZPK62gtvH/I1WBuUNrD6lsxgFJ3GMB2ZSBY0YT6PZ THm6nawVDBKtqvDU1Fpy2gdT5viW8wXULVe4QiMKzSL5cHjss1jDANgJGB/NbgHGl6RB 9FDaZ+V05fEj0Ozks/ZHoWqilpbex/+m1vgqTggUBo5iBadqzshVtOAFyUCnEbi4AVdj pb1IhaCNst0sBgvQYCNxQp/5S1Vx4Apa8pQhZcuHE5+JWzO/ROk7IKic23Ux0YiWoImK 996m9SDtKLvOlq8pK1gtMf9QfjxNdClJ3Xjca6MWL4PUoYP4Tj1vd/1QqAwkRHjyiSbX 0O5A== X-Gm-Message-State: AOAM532930srjjjJbkrTo+4fIbn3adsVsWmBmONS+IppbIRWjlbX851l wsYfuM+M3j3GWh2oa3t/prLR9RWooZIY1PmwUyTRQOIhGnL0mjnQVQcqP+/RUgPtclDV96qnBFK erhhDjw+XvCmhnw== X-Google-Smtp-Source: ABdhPJygTKSUsumQcKNOYTN2sAa4t8QEbQMiYhm6fh41Ovfie+m7tvKQpOBBIZiCDs2g/jQ+somSlXhwB+NyohiImbo= X-Received: by 2002:a17:906:b285:: with SMTP id q5mr27215790ejz.470.1602486236017; Mon, 12 Oct 2020 00:03:56 -0700 (PDT) MIME-Version: 1.0 References: <067801d69c30$02119bc0$0634d340$@auth0.com> <6E139FB3-D319-452E-BD84-17515CBE3F26@forgerock.com> In-Reply-To: <6E139FB3-D319-452E-BD84-17515CBE3F26@forgerock.com> From: Dave Tonge Date: Mon, 12 Oct 2020 09:03:45 +0200 Message-ID: To: Neil Madden Cc: Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG Content-Type: multipart/alternative; boundary="000000000000db125805b173e6eb" Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 07:04:01 -0000 --000000000000db125805b173e6eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil > refresh token rotation is better thought of as providing protection against insecure token storage on the client I agree with your reasoning - and that was more the intent of what I said. We've seen refresh token rotation used for confidential clients that have secure storage (i.e. are run in a data center not on a mobile device) and it has caused problems with zero additional security benefits. Dave On Mon, 12 Oct 2020 at 08:57, Neil Madden wrote= : > I=E2=80=99m not sure I agree with this advice. Singling out private_key_j= wt and > tls_client_auth suggests that the problem is an attacker being able to > eavesdrop on the refresh request itself and then replay it. But if they a= re > able to do that then they can instead just steal the access tokens from t= he > response. > > I think refresh token rotation is better thought of as providing > protection against insecure token storage on the client (e.g. in browser > localStorage). Both public and confidential clients are capable of creati= ng > secure connections with TLS, but we assume that confidential clients > (regardless of auth mechanism) have access to secure storage - otherwise > they shouldn=E2=80=99t be confidential clients in the first place. > > I think the same reasoning applies here too - if a client has insecure > storage then an attacker could just steal the access tokens instead. But = I > think the difference is that an attacker is more likely to gain temporary > access to local storage (e.g. when the user goes to the bathroom and leav= es > their device unlocked) than they are to gain temporary access to eavesdro= p > on a connection. The kind of vulnerabilities that allow eavesdropping ten= d > to be repeatable so the attacker doesn=E2=80=99t need to steal a refresh = token to > ensure ongoing access, they can just steal the access tokens every time t= he > client refreshes. > > That said, there are lots of vulnerabilities that would give an attacker > repeatable access to the client=E2=80=99s local storage - e.g. XSS - so r= efresh > token rotation only catches a subset of possible attacks. > > =E2=80=94 Neil > > On 12 Oct 2020, at 05:43, Dave Tonge wrote: > > > Our goal is to prevent cases where we lose the ability to Refresh a > Token due to transient issues (which have run the gamut from network > problems to bad software updates on the AS side). > > We've seen this issue quite a bit and it's very frustrating. I would > suggest that refresh token rotation is not used for confidential clients > that authenticate with private_key_jwt or tls_client_auth. > > On Wed, 7 Oct 2020 at 00:57, Jeff Craig 40google.com@dmarc.ietf.org> wrote: > >> My experience is more from the Client side of the equation on this >> problem, but I do have some thoughts. Our goal is to prevent cases where= we >> lose the ability to Refresh a Token due to transient issues (which have = run >> the gamut from network problems to bad software updates on the AS side). >> Our use case also does all token handling server-side, so our threat mod= el >> is not the same as the mobile application you described. There is a clea= r >> tradeoff in reducing user friction with additional authorization events, >> and securing access. >> >> The recommendation my team typically gives people building Authorization >> Servers with Refresh Token Rotation is to keep the old refresh token unt= il >> they see the new one (which means that there are generally two refresh >> tokens valid at any point in time, an unfortunate trade-off). A more >> difficult, but potentially plausible implementation would be to hold ont= o >> the older Refresh Token until the newly issued Access Token is used (thu= s >> implying the refresh was successful on both sides). >> >> We aren't trying to protect against multiple in-flight refreshes though >> (we've done a LOT of work to attempt to remove that possibility in a >> globally consistent manner), we're trying to protect against a network >> interruption that prevents the first use of R1, so our assumption is tha= t >> R2.1 was completely lost, and only R2.2 matters moving forward. Meaning:= R1 >> is sent, A/R2.1 is dropped in flight, R1 is sent again, A/R2.2 is return= ed >> and stored. Since R1 was seen a second time, we recommend that R2.1 be >> ignored in future. Next refresh will use R2.2, at which point R1 should >> never be seen again. >> >> The biggest issue that I see with a time-based grace period is that for >> many offline tasks, a single refresh failure may be ignored by the clien= t, >> and it could be hours before the second refresh attempt using the older >> refresh token is made (depending on time of day and what these requests = are >> being used for), making the grace period low value in that case. >> >> On Tue, Oct 6, 2020 at 5:28 PM > 40auth0.com@dmarc.ietf.org> wrote: >> >>> Hey Aaron, >>> >>> Auth0 does offer a configurable grace period, during which the >>> =E2=80=9Cpreceding=E2=80=9D token can be reused. >>> >>> I am not 100% sure what we do in the exact scenario you described, and = I >>> will double check for you, but here=E2=80=99s my intuition. >>> >>> >>> >>> The operation redeem(RT_n) should result in AT, RT_n+1. The grace perio= d >>> just extends the time in which the operation can occur, but every opera= tion >>> should be idempotent. All repeats of that operation within the grace pe= riod >>> should have the same result, which means that every resulting RT is a >>> representative of the RT_n+1 class, hence all valid at the same time. A= fter >>> the grace period elapses, RT_n is invalid, and that=E2=80=99s it. >>> >>> So, in your example I would consider RT1.1 and RT1.2 as equivalent, as >>> they are both representatives of the RT_n+1 equivalence class. >>> >>> >>> >>> It would be very hard to do otherwise, given that network operations >>> aren=E2=80=99t guaranteed to be concluded in the order they were execut= ed without >>> semaphores, and above all the network failures the grace period is desi= gned >>> to handle can apply to any of the requests, regardless of the order. >>> >>> >>> >>> *From:* OAuth *On Behalf Of *Aaron Parecki >>> *Sent:* Tuesday, October 6, 2020 3:06 PM >>> *To:* OAuth WG >>> *Subject:* [OAUTH-WG] Implementation questions around refresh token >>> rotation >>> >>> >>> >>> Hi all, I have a couple questions for those of you who have implemented >>> refresh token rotation... >>> >>> >>> >>> Have you included the option of a grace period on refresh token use, >>> allowing multiple uses within some time window? I'm wondering because a >>> grace period where a refresh token may be used more than once would wor= k >>> around the problem that has been brought up, of a mobile app accidental= ly >>> using a refresh token more than once during normal operation because >>> different threads are unable to coordinate between themselves. However = that >>> also kind of defeats the purpose since attacks within that grace period >>> would be hard to detect. I'm looking for an idea of where people have >>> landed on that issue in practice. >>> >>> >>> >>> If you have implemented a grace period, then how do you handle expiring >>> the additional refresh tokens that have been granted? For example, if R= T >>> "R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1= .1" >>> and "R1.2", what happens if "R1.2" is then later used? Would you invali= date >>> "R1.1" at that point? If so, why, and if not, why not? >>> >>> >>> >>> It would be most interesting to hear practical experience from people >>> who have already built refresh token rotation into a system. >>> >>> >>> >>> Thanks! >>> >>> >>> --- >>> >>> Aaron Parecki >>> >>> https://aaronparecki.com >>> >>> >>> _______________________________________________ >>> 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 >> > > > -- > Dave Tonge > > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000db125805b173e6eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Neil

    =C2=A0> refresh token rotation is b= etter thought of as providing protection against insecure token storage on = the client

    I agree with your reas= oning - and that was more the intent of what I said. We've seen refresh= token rotation used for confidential clients that have secure storage (i.e= . are run in a data center not on a mobile device) and it has caused proble= ms with zero additional security benefits.=C2=A0

    Dave


    On Mon, 12 Oct 2020 at 08:57, Neil Madden = <neil.madden@forgerock.com<= /a>> wrote:
    <= div style=3D"overflow-wrap: break-word;">I=E2=80=99m not sure I agree with = this advice. Singling out private_key_jwt and tls_client_auth suggests that= the problem is an attacker being able to eavesdrop on the refresh request = itself and then replay it. But if they are able to do that then they can in= stead just steal the access tokens from the response.

    I = think refresh token rotation is better thought of as providing protection a= gainst insecure token storage on the client (e.g. in browser localStorage).= Both public and confidential clients are capable of creating secure connec= tions with TLS, but we assume that confidential clients (regardless of auth= mechanism) have access to secure storage - otherwise they shouldn=E2=80=99= t be confidential clients in the first place.

    I th= ink the same reasoning applies here too - if a client has insecure storage = then an attacker could just steal the access tokens instead. But I think th= e difference is that an attacker is more likely to gain temporary access to= local storage (e.g. when the user goes to the bathroom and leaves their de= vice unlocked) than they are to gain temporary access to eavesdrop on a con= nection. The kind of vulnerabilities that allow eavesdropping tend to be re= peatable so the attacker doesn=E2=80=99t need to steal a refresh token to e= nsure ongoing access, they can just steal the access tokens every time the = client refreshes.

    That said, there are lots of vul= nerabilities that would give an attacker repeatable access to the client=E2= =80=99s local storage - e.g. XSS - so refresh token rotation only catches a= subset of possible attacks.

    =E2=80=94 Neil


    = >=C2=A0Our goal i= s to prevent cases where we lose the ability to Refresh a Token due to tran= sient issues (which have run the gamut from network problems to bad softwar= e updates on the AS side).

    We'v= e seen this issue quite a bit and it's very frustrating. I would sugges= t that refresh token rotation is not used for confidential clients that aut= henticate with private_key_jwt or tls_client_auth.=C2=A0
    =
    On Wed= , 7 Oct 2020 at 00:57, Jeff Craig <jeffcraig=3D40google.com@dmarc.ietf.org>= wrote:
    My experience is more from the Client side of the equation on= this problem, but I do have some thoughts. Our goal is to prevent cases wh= ere we lose the ability to Refresh a Token due to transient issues (which h= ave run the gamut from network problems to bad software updates on the AS s= ide). Our use case also does all token handling server-side, so our threat = model is not the same as the mobile application you described. There is a c= lear tradeoff in reducing user friction with additional authorization event= s, and securing access.

    The recommendation m= y team typically gives people building=C2=A0Authorization Servers with Refr= esh Token Rotation is to keep the old refresh token until they see the new = one=C2=A0(which means that there are generally two refresh tokens valid at = any point in time, an unfortunate trade-off). A more difficult, but potenti= ally plausible implementation would be to hold onto the older Refresh Token= until the newly issued Access Token is used (thus implying the refresh=C2= =A0was successful on both sides).

    We aren't trying = to protect against multiple in-flight refreshes though (we've done a LO= T of work to attempt to remove that possibility in a globally consistent ma= nner), we're trying to protect against a network interruption that prev= ents the first use of R1, so our assumption is that R2.1 was completely los= t, and only R2.2 matters moving forward. Meaning: R1 is sent, A/R2.1 is dro= pped in flight, R1 is sent again, A/R2.2 is returned and stored. Since R1 w= as seen a second time, we recommend that R2.1 be ignored in future. Next re= fresh will use R2.2, at which point R1 should never be seen again.

    The biggest issue that I see with a time-based grace perio= d is that for many offline tasks, a single refresh failure may be ignored b= y the client, and it could be hours before the second refresh attempt using= the older refresh token is made (depending on time of day and what these r= equests are being used for), making the grace period low value in that case= .

    On Tue, Oct 6, 2020 at 5:28 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.o= rg> wrote:

    Hey Aaron,<= /p>

    Auth0 does offer a configurable grace period, dur= ing which the =E2=80=9Cpreceding=E2=80=9D token can be reused.

    I am not 100% sure what we do in the exact sce= nario you described, and I will double check for you, but here=E2=80=99s my= intuition.

    =C2=A0

    The operation redeem(RT_n) should result in AT, RT_= n+1. The grace period just extends the time in which the operation can occu= r, but every operation should be idempotent. All repeats of that operation = within the grace period should have the same result, which means that every= resulting RT is a representative of the RT_n+1 class, hence all valid at t= he same time. After the grace period elapses, RT_n is invalid, and that=E2= =80=99s it.

    So, in your example I w= ould consider RT1.1 and RT1.2 as equivalent, as they are both representativ= es of the RT_n+1 equivalence class.

    =C2=A0

    It would be very hard to do= otherwise, given that network operations aren=E2=80=99t guaranteed to be c= oncluded in the order they were executed without semaphores, and above all = the network failures the grace period is designed to handle can apply to an= y of the requests, regardless of the order.

    =C2=A0

    From: OAuth <oauth-bounces@ietf.org> = On Behalf Of Aaron Parecki
    Sent: Tuesday, October 6, 2020 3:0= 6 PM
    To: OAuth WG <oauth@ietf.org>
    Subject: [OAUTH-WG] Implementatio= n questions around refresh token rotation

    =C2=A0

    Hi = all, I have a couple questions for those of you who have implemented refres= h token rotation...

    <= /u>=C2=A0

    Have you included the= option of a grace period on refresh token use, allowing multiple uses with= in some time window? I'm wondering because a grace period where a refre= sh token may be used more than once would work around the problem that has = been brought up,=C2=A0of a mobile app accidentally using a refresh token mo= re than once during normal operation because different threads are unable t= o coordinate between themselves. However that also kind of defeats the purp= ose since attacks within that grace period would be hard to detect. I'm= looking for an idea of where people have landed on that issue in practice.=

    =C2=A0

    If you have implemented a grace period, = then how do you handle expiring the additional refresh tokens that have bee= n granted? For example, if RT "R1" is used twice, resulting=C2=A0= in new ATs "A1.1", "A1.2" and new RTs "R1.1" = and "R1.2", what happens if "R1.2" is then later used? = Would you invalidate "R1.1" at that point? If so, why, and if not= , why not?

    =C2=A0=

    It would be most interesting t= o hear practical experience from people who have already built refresh toke= n rotation into a system.

    =C2=A0

    Thanks!<= u>


    =

    ---

    Aaron Parecki

    =C2= =A0

    ___________________= ____________________________
    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


    --
    Dave Tonge


    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=


    _______________________________________________
    OA= uth mailing list
    OAu= th@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    =





    Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

    = DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


    --000000000000db125805b173e6eb-- From nobody Mon Oct 12 02:15:25 2020 Return-Path: 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 3575A3A139F for ; Mon, 12 Oct 2020 02:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net 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 9I2fHxQPYKmm for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 655E73A13A1 for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id e22so22220337ejr.4 for ; Mon, 12 Oct 2020 02:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=B+zu8Z6IFjR6XvnClH+JN2G0wxIU10R1/8gzOZNTusU=; b=KHhxaa2jd0OWE0BgNNmtN9YgmVi8pl4h2cIvCPtHBQYoh0AppDG/ZhghyLbJZDT4KK nRloJthzndtNnME/0twNQsjb41AFFeVlWOzDG8H4YZTRkrBoBWc4NwVSl1eN78YtmXgs yOX91GiGk7vSFExVflEnVHmnUs6HcAmpXkWUeFEQVv2Kfj5l8adl8dpsj13Ms4m5p5uL F0885LZcpAm0p+CYvnAex0DB0U3poXgRfYBRQY5peWT/l9SW7gPVwBF8PIkJV2fCR76h C5HmBusXwvj7qZ52QuSh+77HtyKVCFyZMEvUGSr+WuI4mgFHna4IqLkxcVWUtCf3qmgd b6Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=B+zu8Z6IFjR6XvnClH+JN2G0wxIU10R1/8gzOZNTusU=; b=Lp1OJ1dpSSMAtN4Kmz4KdEnocuwjGu06Am26IQRy7tOVKT+5XVdiRvQrqq+MVLPryO HvOPY4bfA2ba8gm+DP+hhHy1EPkrDsdLZdG7PsZndhwh5gkLZiSakpgEe90/YRIrZKlD fWlXokNRU1LqroFPp3oQNuLlJVGcrNPLXJbs7ew0X+Xzt5zJJOxnlUe1WmW3RP9QHUY0 oxGrOTlDmPTu2WbdI2DTjk4cv/UgvQWL+VbLEj5Hp83B5cgTQpUO0MbFck3MTmMcIQ3w 3rvX2zH7mMU3zhHQtJ2u5v4XS1Mu03n8ORKORsxNIcpjfzW4qUDNKhh709kp1qTcTXmB GMhA== X-Gm-Message-State: AOAM533PvaHT7sr5OK3OF32Wy42XwkH/7Kj/pvxplrMiQlbjR0DBPEsG x5CdiItLgTontJycKcsZw3lV/w== X-Google-Smtp-Source: ABdhPJz3W+XL4F4935cs0VQZERSmMSTgflSZp8RyDGxWNLxNNHazNefaLrCEu546xgWC8KCX832nvQ== X-Received: by 2002:a17:906:9702:: with SMTP id k2mr4556348ejx.494.1602494117707; Mon, 12 Oct 2020 02:15:17 -0700 (PDT) Received: from ?IPv6:2003:eb:8f1e:2acb:f17f:cd59:cd54:7b42? (p200300eb8f1e2acbf17fcd59cd547b42.dip0.t-ipconnect.de. [2003:eb:8f1e:2acb:f17f:cd59:cd54:7b42]) by smtp.gmail.com with ESMTPSA id a12sm10100615edy.87.2020.10.12.02.15.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 02:15:16 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Mon, 12 Oct 2020 11:15:15 +0200 Message-Id: <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net> References: Cc: Neil Madden , Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG In-Reply-To: To: Dave Tonge X-Mailer: iPad Mail (18A393) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 09:15:24 -0000 --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A Content-Type: multipart/alternative; boundary=Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Transfer-Encoding: 7bit --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 12.10.2020 um 09:04 schrieb Dave Tonge : >=20 > =EF=BB=BF > Hi Neil >=20 > > refresh token rotation is better thought of as providing protection aga= inst insecure token storage on the client >=20 > I agree with your reasoning - and that was more the intent of what I said.= We've seen refresh token rotation used for confidential clients that have s= ecure storage (i.e. are run in a data center not on a mobile device) and it h= as caused problems with zero additional security benefits.=20 Those are good examples of why refresh token rotation should not be used if t= here are better ways available to protect refresh tokens from replay. Client= authentication or sender constrained refresh tokens are the better choice. >=20 > Dave >=20 >=20 >> On Mon, 12 Oct 2020 at 08:57, Neil Madden wro= te: >> I=E2=80=99m not sure I agree with this advice. Singling out private_key_j= wt and tls_client_auth suggests that the problem is an attacker being able t= o eavesdrop on the refresh request itself and then replay it. But if they ar= e able to do that then they can instead just steal the access tokens from th= e response. >>=20 >> I think refresh token rotation is better thought of as providing protecti= on against insecure token storage on the client (e.g. in browser localStorag= e). Both public and confidential clients are capable of creating secure conn= ections with TLS, but we assume that confidential clients (regardless of aut= h mechanism) have access to secure storage - otherwise they shouldn=E2=80=99= t be confidential clients in the first place. >>=20 >> I think the same reasoning applies here too - if a client has insecure st= orage then an attacker could just steal the access tokens instead. But I thi= nk the difference is that an attacker is more likely to gain temporary acces= s to local storage (e.g. when the user goes to the bathroom and leaves their= device unlocked) than they are to gain temporary access to eavesdrop on a c= onnection. The kind of vulnerabilities that allow eavesdropping tend to be r= epeatable so the attacker doesn=E2=80=99t need to steal a refresh token to e= nsure ongoing access, they can just steal the access tokens every time the c= lient refreshes. >>=20 >> That said, there are lots of vulnerabilities that would give an attacker r= epeatable access to the client=E2=80=99s local storage - e.g. XSS - so refre= sh token rotation only catches a subset of possible attacks. >>=20 >> =E2=80=94 Neil >>=20 >>> On 12 Oct 2020, at 05:43, Dave Tonge wrote= : >>>=20 >>> > Our goal is to prevent cases where we lose the ability to Refresh a To= ken due to transient issues (which have run the gamut from network problems t= o bad software updates on the AS side). >>>=20 >>> We've seen this issue quite a bit and it's very frustrating. I would sug= gest that refresh token rotation is not used for confidential clients that a= uthenticate with private_key_jwt or tls_client_auth.=20 >>>=20 >>>> On Wed, 7 Oct 2020 at 00:57, Jeff Craig wrote: >>>> My experience is more from the Client side of the equation on this prob= lem, but I do have some thoughts. Our goal is to prevent cases where we lose= the ability to Refresh a Token due to transient issues (which have run the g= amut from network problems to bad software updates on the AS side). Our use c= ase also does all token handling server-side, so our threat model is not the= same as the mobile application you described. There is a clear tradeoff in r= educing user friction with additional authorization events, and securing acc= ess. >>>>=20 >>>> The recommendation my team typically gives people building Authorizatio= n Servers with Refresh Token Rotation is to keep the old refresh token until= they see the new one (which means that there are generally two refresh toke= ns valid at any point in time, an unfortunate trade-off). A more difficult, b= ut potentially plausible implementation would be to hold onto the older Refr= esh Token until the newly issued Access Token is used (thus implying the ref= resh was successful on both sides). >>>>=20 >>>> We aren't trying to protect against multiple in-flight refreshes though= (we've done a LOT of work to attempt to remove that possibility in a global= ly consistent manner), we're trying to protect against a network interruptio= n that prevents the first use of R1, so our assumption is that R2.1 was comp= letely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A/R2= .1 is dropped in flight, R1 is sent again, A/R2.2 is returned and stored. Si= nce R1 was seen a second time, we recommend that R2.1 be ignored in future. N= ext refresh will use R2.2, at which point R1 should never be seen again. >>>>=20 >>>> The biggest issue that I see with a time-based grace period is that for= many offline tasks, a single refresh failure may be ignored by the client, a= nd it could be hours before the second refresh attempt using the older refre= sh token is made (depending on time of day and what these requests are being= used for), making the grace period low value in that case. >>>>=20 >>>>> On Tue, Oct 6, 2020 at 5:28 PM wrote: >>>>> Hey Aaron, >>>>>=20 >>>>> Auth0 does offer a configurable grace period, during which the =E2=80=9C= preceding=E2=80=9D token can be reused. >>>>>=20 >>>>> I am not 100% sure what we do in the exact scenario you described, and= I will double check for you, but here=E2=80=99s my intuition. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The operation redeem(RT_n) should result in AT, RT_n+1. The grace peri= od just extends the time in which the operation can occur, but every operati= on should be idempotent. All repeats of that operation within the grace peri= od should have the same result, which means that every resulting RT is a rep= resentative of the RT_n+1 class, hence all valid at the same time. After the= grace period elapses, RT_n is invalid, and that=E2=80=99s it. >>>>>=20 >>>>> So, in your example I would consider RT1.1 and RT1.2 as equivalent, as= they are both representatives of the RT_n+1 equivalence class. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It would be very hard to do otherwise, given that network operations a= ren=E2=80=99t guaranteed to be concluded in the order they were executed wit= hout semaphores, and above all the network failures the grace period is desi= gned to handle can apply to any of the requests, regardless of the order. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth On Behalf Of Aaron Parecki >>>>> Sent: Tuesday, October 6, 2020 3:06 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] Implementation questions around refresh token rota= tion >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi all, I have a couple questions for those of you who have implemente= d refresh token rotation... >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Have you included the option of a grace period on refresh token use, a= llowing multiple uses within some time window? I'm wondering because a grace= period where a refresh token may be used more than once would work around t= he problem that has been brought up, of a mobile app accidentally using a re= fresh token more than once during normal operation because different threads= are unable to coordinate between themselves. However that also kind of defe= ats the purpose since attacks within that grace period would be hard to dete= ct. I'm looking for an idea of where people have landed on that issue in pra= ctice. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If you have implemented a grace period, then how do you handle expirin= g the additional refresh tokens that have been granted? For example, if RT "= R1" is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" an= d "R1.2", what happens if "R1.2" is then later used? Would you invalidate "R= 1.1" at that point? If so, why, and if not, why not? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> It would be most interesting to hear practical experience from people w= ho have already built refresh token rotation into a system. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --- >>>>>=20 >>>>> Aaron Parecki >>>>>=20 >>>>> https://aaronparecki.com >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>>=20 >>>=20 >>> --=20 >>> Dave Tonge >>>=20 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology L= imited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services R= egister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tec= hnology is registered in England & Wales, company registration number 069097= 72. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, R= egus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to copyrig= ht, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. W= hilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for v= iruses. All calls and emails to and from this company may be monitored and r= ecorded for legitimate purposes relating to this company's business. Any opi= nions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techno= logy Limited or of any other group company. >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Li= mited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services R= egister (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Tec= hnology is registered in England & Wales, company registration number 069097= 72. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, R= egus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to copyright= , and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Whi= lst reasonable efforts are made to ensure that any attachments are virus-fre= e, it is the recipient's sole responsibility to scan all attachments for vir= uses. All calls and emails to and from this company may be monitored and rec= orded for legitimate purposes relating to this company's business. Any opini= ons expressed in this email (or in any attachments) are those of the author a= nd do not necessarily represent the opinions of Moneyhub Financial Technolog= y Limited or of any other group company. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    Am 12.10.2020 um 09:04 schrieb Dave Tonge <= ;dave.tonge@momentumft.co.uk>:

    =EF=BB=BF
    Hi Neil=

     > refresh token rotation is better thought of as providing protection agai= nst insecure token storage on the client

    I agree with your reasoning - and that was more the intent of what I sai= d. We've seen refresh token rotation used for confidential clients that have= secure storage (i.e. are run in a data center not on a mobile device) and i= t has caused problems with zero additional security benefits. 

    Those are good examples of w= hy refresh token rotation should not be used if there are better ways availa= ble to protect refresh tokens from replay. Client authentication or sender c= onstrained refresh tokens are the better choice.


    Dave
    <= div class=3D"gmail_default">


    On Mon, 12 Oct 2020 at 08:57,= Neil Madden <neil.madden@fo= rgerock.com> wrote:
    I=E2=80=99m not sure I agre= e with this advice. Singling out private_key_jwt and tls_client_auth suggest= s that the problem is an attacker being able to eavesdrop on the refresh req= uest itself and then replay it. But if they are able to do that then they ca= n instead just steal the access tokens from the response.

    I think refresh token rotation is better thought of as providing protection= against insecure token storage on the client (e.g. in browser localStorage)= . Both public and confidential clients are capable of creating secure connec= tions with TLS, but we assume that confidential clients (regardless of auth m= echanism) have access to secure storage - otherwise they shouldn=E2=80=99t b= e confidential clients in the first place.

    I think t= he same reasoning applies here too - if a client has insecure storage then a= n attacker could just steal the access tokens instead. But I think the diffe= rence is that an attacker is more likely to gain temporary access to local s= torage (e.g. when the user goes to the bathroom and leaves their device unlo= cked) than they are to gain temporary access to eavesdrop on a connection. T= he kind of vulnerabilities that allow eavesdropping tend to be repeatable so= the attacker doesn=E2=80=99t need to steal a refresh token to ensure ongoin= g access, they can just steal the access tokens every time the client refres= hes.

    That said, there are lots of vulnerabilities t= hat would give an attacker repeatable access to the client=E2=80=99s local s= torage - e.g. XSS - so refresh token rotation only catches a subset of possi= ble attacks.

    =E2=80=94 Neil

    On 12 Oct 2020, at 05:43, Dave Tonge= <dave.t= onge@momentumft.co.uk> wrote:

    >=  Our goal is to p= revent cases where we lose the ability to Refresh a Token due to transient i= ssues (which have run the gamut from network problems to bad software update= s on the AS side).
    We've seen this issu= e quite a bit and it's very frustrating. I would suggest that refresh token r= otation is not used for confidential clients that authenticate with private_= key_jwt or tls_client_auth. 

    On Wed, 7 Oct 2020 at 00:57, Je= ff Craig <jeffcraig=3D40google.com@dmarc.ietf.org> wrote:
    My experience i= s more from the Client side of the equation on this problem, but I do have s= ome thoughts. Our goal is to prevent cases where we lose the ability to Refr= esh a Token due to transient issues (which have run the gamut from network p= roblems to bad software updates on the AS side). Our use case also does all t= oken handling server-side, so our threat model is not the same as the mobile= application you described. There is a clear tradeoff in reducing user frict= ion with additional authorization events, and securing access.
    The recommendation my team typically gives people building=  Authorization Servers with Refresh Token Rotation is to keep the old r= efresh token until they see the new one (which means that there are gen= erally two refresh tokens valid at any point in time, an unfortunate trade-o= ff). A more difficult, but potentially plausible implementation would be to h= old onto the older Refresh Token until the newly issued Access Token is used= (thus implying the refresh was successful on both sides).

    We aren't trying to protect against multiple in-flight refreshes tho= ugh (we've done a LOT of work to attempt to remove that possibility in a glo= bally consistent manner), we're trying to protect against a network interrup= tion that prevents the first use of R1, so our assumption is that R2.1 was c= ompletely lost, and only R2.2 matters moving forward. Meaning: R1 is sent, A= /R2.1 is dropped in flight, R1 is sent again, A/R2.2 is returned and stored.= Since R1 was seen a second time, we recommend that R2.1 be ignored in futur= e. Next refresh will use R2.2, at which point R1 should never be seen again.=

    The biggest issue that I see with a time-based gra= ce period is that for many offline tasks, a single refresh failure may be ig= nored by the client, and it could be hours before the second refresh attempt= using the older refresh token is made (depending on time of day and what th= ese requests are being used for), making the grace period low value in that c= ase.

    On Tue, Oct 6, 2020 at 5:28 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.o= rg> wrote:
    =

    Hey Aaron,

    =

    Auth0 does offer a configurable grace period, during w= hich the =E2=80=9Cpreceding=E2=80=9D token can be reused.

    =

    I am not 100% sure what we do in the exact scenario y= ou described, and I will double check for you, but here=E2=80=99s my intuiti= on.

     

    The operation redeem(RT_n) should result in AT, RT_n+1. The g= race period just extends the time in which the operation can occur, but ever= y operation should be idempotent. All repeats of that operation within the g= race period should have the same result, which means that every resulting RT= is a representative of the RT_n+1 class, hence all valid at the same time. A= fter the grace period elapses, RT_n is invalid, and that=E2=80=99s it.

    So, in your example I would consider RT1.= 1 and RT1.2 as equivalent, as they are both representatives of the RT_n+1 eq= uivalence class.

     

    It would be very hard to do otherwise, given tha= t network operations aren=E2=80=99t guaranteed to be concluded in the order t= hey were executed without semaphores, and above all the network failures the= grace period is designed to handle can apply to any of the requests, regard= less of the order.

     <= /u>

    From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki=
    Sent: Tuesday, October 6, 2020 3:06 PM
    To: OAuth WG <= ;oauth@ietf.org><= br>Subject: [OAUTH-WG] Implementation questions around refresh token r= otation

     

    Hi all, I have a couple questions for tho= se of you who have implemented refresh token rotation...

     

    Have you included the option of a grace period on refresh token u= se, allowing multiple uses within some time window? I'm wondering because a g= race period where a refresh token may be used more than once would work arou= nd the problem that has been brought up, of a mobile app accidentally u= sing a refresh token more than once during normal operation because differen= t threads are unable to coordinate between themselves. However that also kin= d of defeats the purpose since attacks within that grace period would be har= d to detect. I'm looking for an idea of where people have landed on that iss= ue in practice.

    &n= bsp;

    If you have implemented a g= race period, then how do you handle expiring the additional refresh tokens t= hat have been granted? For example, if RT "R1" is used twice, resulting = ;in new ATs "A1.1", "A1.2" and new RTs "R1.1" and "R1.2", what happens if "R= 1.2" is then later used? Would you invalidate "R1.1" at that point? If so, w= hy, and if not, why not?

    =  

    It would be most i= nteresting to hear practical experience from people who have already built r= efresh token rotation into a system.

     

    Thanks= !


    =

    ---

    Aaron Parecki

    &= nbsp;

    __________________= _____________________________
    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


    --
    =
    Dave Tonge


    Moneyhub Enterprise is a trading style of Moneyhub Finan= cial Technology Limited which is authorised and regulated by the Financial C= onduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Fi= nancial Services Register (FRN 809360) at https://register.fca.org.uk/. Mone= yhub Financial Technology is registered in England & Wales, company regi= stration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 M= oneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=  

    DIS= CLAIMER: This email (including any attachments) is subject to copyright, and= the information in it is confidential. Use of this email or of any informat= ion in it other than by the addressee is unauthorised and unlawful. Whilst r= easonable efforts are made to ensure that any attachments are virus-free, it= is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded= for legitimate purposes relating to this company's business. Any opinions e= xpressed in this email (or in any attachments) are those of the author and d= o not necessarily represent the opinions of Moneyhub Financial Technology Li= mited or of any other group company.


    __________________= _____________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mail= man/listinfo/oauth





    Moneyhub Enterprise is a trading style of Moneyhub Financial= Technology Limited which is authorised and regulated by the Financial Condu= ct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financ= ial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub= Financial Technology is registered in England & Wales, company registra= tion number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Mone= yhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.&nb= sp;

    DISCLA= IMER: This email (including any attachments) is subject to copyright, and th= e information in it is confidential. Use of this email or of any information= in it other than by the addressee is unauthorised and unlawful. Whilst reas= onable efforts are made to ensure that any attachments are virus-free, it is= the recipient's sole responsibility to scan all attachments for viruses. Al= l calls and emails to and from this company may be monitored and recorded fo= r legitimate purposes relating to this company's business. Any opinions expr= essed in this email (or in any attachments) are those of the author and do n= ot necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.


    _______________= ________________________________
    OAuth mailing listOAuth@ietf.org
    https://www.ietf.org/mailman/listinfo= /oauth
    = --Apple-Mail-10B5E0BA-ADDD-444E-91D3-C837096880C6-- --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMDEyMDkxNTE1WjAvBgkqhkiG9w0BCQQxIgQg QWOFU98K4e57p6ou5zQvNg8Zt9j+LwGj7pQqwHXZmfgwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAIwdla73NNjnIQBVFXcf0CTLzfqunHAkxScnYHmUfiKCpfJLF8V0Y SHozqHp33MK/B4ZDSPSudssotEB8oTQTlYTjfCZpBdgjWcrHQnPEri9tT7UOaj5w4jwpi8/5j9LJ kr5ZY+UN25rnDPAjNfvOn6Ca2Go5UpScsR7yXB6dtks2/Yqvq4z/yJBmiPOsdCzmF59wc33xBtil oHpsaR/HLDeMn1txJ7y11oMCD662hCxLICfAqNWBQSBBCyvrGz2zLtJxuGIvJbEQmgW0Rg2pVTeX uOPXoaujb6B4cN4fLZFBa1+K3HY/HiFhCJHNb6B68A08aPbRgYj6Kca5qrYK4QAAAAAAAA== --Apple-Mail-B60855C8-B52A-4F7F-B465-5268C6AD998A-- From nobody Mon Oct 12 02:54:34 2020 Return-Path: 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 620A03A13CB for ; Mon, 12 Oct 2020 02:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alkaline-solutions.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 9C7YIJHUONCZ for ; Mon, 12 Oct 2020 02:54:31 -0700 (PDT) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FA23A13CA for ; Mon, 12 Oct 2020 02:54:31 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 402BA20473B; Mon, 12 Oct 2020 09:54:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1602496469; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2POAzcSIPqcBXzQW94MNp3NRYI4KzXDK9LmU5y6NktY=; b=pOO6ZMuFP5q46tPqpdvtzqifhMafEKrS854r2/OAwTZc41Mx8WxoFC2gOqA0CgXj6dNHd0 9xoK3D91mjEhUlXMlGl9RkTc4ZM9M5ETJEjnC2jYKCBN1yklNvI7yEyqeA8ndN1N06mVIk oJOuzB6ptyOF3NzHK+yLI2mDHyUHN8Y= From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_36892377-4E91-49BE-A93E-34DA885E33E5" Mime-Version: 1.0 Date: Mon, 12 Oct 2020 03:54:26 -0600 In-Reply-To: <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net> Cc: Dave Tonge , Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG To: Torsten Lodderstedt References: <81E51F61-E093-4467-BBDB-5FC1CF593598@lodderstedt.net> Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 09:54:33 -0000 --Apple-Mail=_36892377-4E91-49BE-A93E-34DA885E33E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 An AS may decide refresh token rotation is useful for other reasons = (such as if the token is an encrypted value and the AS cluster does key = rotation), or may decide to rotate all tokens for consistency. Eventually best practices may indicate sender constrained tokens for = public clients. At that point, refresh rotation may not be security = practice but could still be something an AS does as part of its own = design. And an AS may elect to do this often so that clients fail (and = correct their logic) faster. -DW > On Oct 12, 2020, at 03:15, Torsten Lodderstedt = wrote: >=20 >>=20 >> Am 12.10.2020 um 09:04 schrieb Dave Tonge = >: >>=20 >> =EF=BB=BF >> Hi Neil >>=20 >> > refresh token rotation is better thought of as providing = protection against insecure token storage on the client >>=20 >> I agree with your reasoning - and that was more the intent of what I = said. We've seen refresh token rotation used for confidential clients = that have secure storage (i.e. are run in a data center not on a mobile = device) and it has caused problems with zero additional security = benefits.=20 >=20 > Those are good examples of why refresh token rotation should not be = used if there are better ways available to protect refresh tokens from = replay. Client authentication or sender constrained refresh tokens are = the better choice. --Apple-Mail=_36892377-4E91-49BE-A93E-34DA885E33E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 An = AS may decide refresh token rotation is useful for other reasons (such = as if the token is an encrypted value and the AS cluster does key = rotation), or may decide to rotate all tokens for consistency.

    Eventually best = practices may indicate sender constrained tokens for public clients. At = that point, refresh rotation may not be security practice but could = still be something an AS does as part of its own design. And an AS may = elect to do this often so that clients fail (and correct their logic) = faster.

    -DW

    On Oct 12, 2020, at 03:15, = Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> = wrote:


    Am 12.10.2020 um = 09:04 schrieb Dave Tonge <dave.tonge@momentumft.co.uk>:

    =EF=BB=BF
    Hi Neil

     > refresh = token rotation is better thought of as providing protection against = insecure token storage on the client

    I agree with your reasoning - and that was more = the intent of what I said. We've seen refresh token rotation used for = confidential clients that have secure storage (i.e. are run in a data = center not on a mobile device) and it has caused problems with zero = additional security = benefits. 

    Those are = good examples of why refresh token rotation should not be used if there = are better ways available to protect refresh tokens from replay. Client = authentication or sender constrained refresh tokens are the better = choice.

    = --Apple-Mail=_36892377-4E91-49BE-A93E-34DA885E33E5-- From nobody Mon Oct 12 05:23:23 2020 Return-Path: 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 257153A144A for ; Mon, 12 Oct 2020 05:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net 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 6E_iu5Jrop26 for ; Mon, 12 Oct 2020 05:23:18 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 D4CDE3A1436 for ; Mon, 12 Oct 2020 05:23:17 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id 33so16649814edq.13 for ; Mon, 12 Oct 2020 05:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=miegZNS89ejq72/Sd5hT/F/Zipkgw334UQtYJcLERMM=; b=qn7NZLnTwaKj6qtSFSn/QHletZCoCjXTxGYfWOH8H+zVrrXwCoMQfPHtSvjxnEVqXE p9ktRnlPmNxs89vvqJ1I0m9BPjO+syT/tkE9/yAZJ9qZka6uuG09Zxr1CHpaf9NfJK+G 7aUA1DxrZ897Vn23BUp0y+4eC4tY5WhyxoERRbMWQffJ56Lj1MwraYZ9uFrpbjJ5qorj GDSNHvup0nV2kebZH552csirTwktlnBnzsrw945CSKR+8j17vjTpreWu2aKmL3uN/kH9 voY8v65ZSQZOqcHMZ0pSi631NAqYO9YvNkAg/qtMSmwB1kF563ToJKXiYCxDHECmyWrV T/8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=miegZNS89ejq72/Sd5hT/F/Zipkgw334UQtYJcLERMM=; b=uf/xkWQjCcUy1iUrY8CtrbtGgXy0fmq5RgNZY1N9LiyHso2YCWySGW5kfFZGj5W758 QyMfAFjeAUeELRGyezNngOWdgphXoAsPHV1jpBm/HVl5bIqIVcoNTYlx2i9KAXqSEJ4p zTtmTi74neouoznsX4r19/MI7RXPFKCmqqfv/TM7y6ZPV3EXoPbiOZCBLXRj7aHSamZ/ 2AMLafcXJ6vFpCF5eKpkp9fKtX7JnmOiukkl5oswLHFxs6p1kdC0dlNAfA5EkKghu+4Q 6d0k8+vTTrDYMaZt/eyQgAqANKkUedt/ACVufztHq2LnTKOEuFco+V6CJd4vbKpibxeO oJKg== X-Gm-Message-State: AOAM530XnyGHCb14ZOJTBYns7m8VkC5CzccqGlWO/AyQXwFzP9XrVYIK t6EqhTmgJho1KafGAz01JAlq2A== X-Google-Smtp-Source: ABdhPJzSUCcHSXUx27ILvRD+KxfipgR3WfWZVuuWzuHcem0iYTcKx6jIzzJQ+/scViXzjzYHE9+4bA== X-Received: by 2002:a50:ef12:: with SMTP id m18mr14045615eds.313.1602505396224; Mon, 12 Oct 2020 05:23:16 -0700 (PDT) Received: from ?IPv6:2a01:598:9182:fe1c:8d43:995c:e49d:4e17? ([2a01:598:9182:fe1c:8d43:995c:e49d:4e17]) by smtp.gmail.com with ESMTPSA id m6sm10462579ejb.85.2020.10.12.05.23.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 05:23:15 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-78464E6A-AFFB-4033-A06C-F4475F5968CF; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Mon, 12 Oct 2020 14:23:13 +0200 Message-Id: <722EAF9B-BE47-43EF-BA9F-E72FD4D5BA56@lodderstedt.net> References: Cc: Torsten Lodderstedt , Jeff Craig , vittorio.bertocci=40auth0.com@dmarc.ietf.org, OAuth WG In-Reply-To: To: David Waite X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [OAUTH-WG] Implementation questions around refresh token rotation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 12:23:21 -0000 --Apple-Mail-78464E6A-AFFB-4033-A06C-F4475F5968CF Content-Type: multipart/alternative; boundary=Apple-Mail-1A91E7C9-31F9-4642-BBC0-9AAF3DA99E78 Content-Transfer-Encoding: 7bit --Apple-Mail-1A91E7C9-31F9-4642-BBC0-9AAF3DA99E78 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Out of curiosity: Have you seen this in practice? I=E2=80=99m asking since m= ost/all refresh token implementations I have seen are handles. Just rotating= for consistency makes especially the live of server based clients harder as= they need to propagate such a change through the cluster. > Am 12.10.2020 um 11:54 schrieb David Waite : >=20 > =EF=BB=BFAn AS may decide refresh token rotation is useful for other reaso= ns (such as if the token is an encrypted value and the AS cluster does key r= otation), or may decide to rotate all tokens for consistency. >=20 > Eventually best practices may indicate sender constrained tokens for publi= c clients. At that point, refresh rotation may not be security practice but c= ould still be something an AS does as part of its own design. And an AS may e= lect to do this often so that clients fail (and correct their logic) faster.= >=20 > -DW >=20 >>> On Oct 12, 2020, at 03:15, Torsten Lodderstedt wrote: >>>=20 >>>=20 >>>> Am 12.10.2020 um 09:04 schrieb Dave Tonge = : >>>>=20 >>> =EF=BB=BF >>> Hi Neil >>>=20 >>> > refresh token rotation is better thought of as providing protection a= gainst insecure token storage on the client >>>=20 >>> I agree with your reasoning - and that was more the intent of what I sai= d. We've seen refresh token rotation used for confidential clients that have= secure storage (i.e. are run in a data center not on a mobile device) and i= t has caused problems with zero additional security benefits.=20 >>=20 >> Those are good examples of why refresh token rotation should not be used i= f there are better ways available to protect refresh tokens from replay. Cli= ent authentication or sender constrained refresh tokens are the better choic= e. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1A91E7C9-31F9-4642-BBC0-9AAF3DA99E78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Out of curiosity: Have you= seen this in practice? I=E2=80=99m asking since most/all refresh token impl= ementations I have seen are handles. Just rotating for consistency makes esp= ecially the live of server based clients harder as they need to propagate su= ch a change through the cluster.

    Am 12.10.2020 um 11:54 schrieb David Waite <david=3D40alkaline-sol= utions.com@dmarc.ietf.org>:

    =EF=BB=BFAn AS may decide refresh token rotation is usef= ul for other reasons (such as if the token is an encrypted value and the AS c= luster does key rotation), or may decide to rotate all tokens for consistenc= y.

    Eventually best pract= ices may indicate sender constrained tokens for public clients. At that poin= t, refresh rotation may not be security practice but could still be somethin= g an AS does as part of its own design. And an AS may elect to do this often= so that clients fail (and correct their logic) faster.

    -DW

    On Oct 12, 2020, at 03:15, Torsten Lod= derstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

    Am 12.10.2020 u= m 09:04 schrieb Dave Tonge <dave.tonge@momentumft.co.uk>:

    =EF=BB=BF
    Hi Neil<= /div>

     > refresh token rota= tion is better thought of as providing protection against insecure token sto= rage on the client

    =
    I agree with your reasoning= - and that was more the intent of what I said. We've seen refresh token rot= ation used for confidential clients that have secure storage (i.e. are run i= n a data center not on a mobile device) and it has caused problems with zero= additional security benefits. 

    Those are good= examples of why refresh token rotation should not be used if there are bett= er ways available to protect refresh tokens from replay. Client authenticati= on or sender constrained refresh tokens are the better choice.

    _______________________________________________
    OAu= th mailing list
    OAuth@ietf.org
    https://www.i= etf.org/mailman/listinfo/oauth
    = --Apple-Mail-1A91E7C9-31F9-4642-BBC0-9AAF3DA99E78-- --Apple-Mail-78464E6A-AFFB-4033-A06C-F4475F5968CF Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG 9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z 8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG 9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW 0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj 2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF 6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEwMTIx MjIzMTNaMC8GCSqGSIb3DQEJBDEiBCBqyqQMviKaTGHmVQMoQWrat5fBrSWoV0PHImybmKWs0TCB vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBCwUA BIIBABRmoKe8zOEs2gAzuaSjqzWROBdsl96KOxeOJ3DZMJ5/rZ/MBmn03cOHiZ0Krb72Wm/QBgUR t0+pf1AVypbERKCuAkPdzzf4g7OwTZh0cPuMreGwrKGEE0VgN+VS2MmKjLCzKmtXQwlPLfnjN5NB CsEpq1jpWNeRRO2stTosvsIf8sLVOo9MyOqNh8YrAmu+3SmYXwtJM09IwpuyZx5QRTdE12Gf/9V/ rH6qowYiK0ag8WELryjjkKdCGfjABfJRXeEgh7brRERAcPi2+j/aZX7psVJuT/OnPCLSdS6tU788 425Mm2ZdFuI2WBo4hZ5jvkzZ8tPY6yRFeKe4tQdDtcQAAAAAAAA= --Apple-Mail-78464E6A-AFFB-4033-A06C-F4475F5968CF-- From goto@google.com Mon Oct 12 11:19:22 2020 Return-Path: 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 C69503A15F6 for ; Mon, 12 Oct 2020 11:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.97 X-Spam-Level: X-Spam-Status: No, score=-15.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7O7rZ9FwIvcX for ; Mon, 12 Oct 2020 11:19:21 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 31DB23A15F4 for ; Mon, 12 Oct 2020 11:19:21 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id h7so20312740wre.4 for ; Mon, 12 Oct 2020 11:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cGAC4mAQSY9D8AielhYf93+tDRV87JnT6muaQjZ/Qew=; b=IEoa/aUxIkiaObILfHfs8O1TgiQ0xw6cWpqK9m978AZyiJw/4nWdaFUVnKak4aDhZu QbDGVVd+4OpPBV2I7htlt3tSBEJGhS/74El0zItG0CsdhZ/l66iTX+Jgf4bhAXSj2pQS m30LYwSFttSS+w62AaKT4f6bFKCEIbSMFgJBmk1Dk1SNAYCPIa133riZ70FvNVhbbx05 bBhz95Fc+Heqk6SxORYqHmuuQETH+SX5H5RpkgsQU+YhCZEg5lYpHgh41BfzjTP5pIW7 wnZ8FjpVtbusCA6STbFjDp2pj/QF+J8EzzJneqtGbF/vyEwky1Y2xslC/MH7I8Um8YXs hiTQ== 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=cGAC4mAQSY9D8AielhYf93+tDRV87JnT6muaQjZ/Qew=; b=X+YjDXdQo0sozDvyMriFWI5z8yQ0EsNEC7BbbS1xUrWE8wKM1JU089FbJjWaaySI7+ OU/t3j4p5gz50AaIIwd967JRmRajqCrFc6O3QqwB17txWP1WHacaX7FAIufmLmeL7mM7 10yqgRf9sNm9qKXR/SeEkunRbm9zX7tWInoy3AZLkJxitq/X3HC/CzinrBI2S6pREXVM B/ZJ/wrO1vthHmYlfihJCZZN1yNsMWOV373thjWAGIh7/9ocCmkwXi0JPiAQt5Idn1d3 VSrRZ3JkMQFxXa1qFeCyrdBdD+2LYpeU4BgcMayPz9szS4VYfuxyr8nakB+C+BQcPIym muvw== X-Gm-Message-State: AOAM533p1Rbfm2A+16UnhQk9R47zoJzHhDJ+841QtJg+vavysxq0T14N LspEVhOua78QlUmeSfjmsXfOG3OTv8nO+cLX3yFr4A== X-Google-Smtp-Source: ABdhPJwPIWoJhAypnlQCAfzr8DH6KE3zs2eXU/qKTYKu2wVr+dyCpp4YQoBCBCRY6h5lhIvER0X0nE3ywn84M/eA6Sc= X-Received: by 2002:a5d:6143:: with SMTP id y3mr13834253wrt.277.1602526759436; Mon, 12 Oct 2020 11:19:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sam Goto Date: Mon, 12 Oct 2020 11:19:08 -0700 Message-ID: To: Dick Hardt Cc: Jeff Hodges , oauth@ietf.org, Justin Toupin Content-Type: multipart/alternative; boundary="0000000000003da4cf05b17d5626" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 18:20:23 -0000 --0000000000003da4cf05b17d5626 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome! Will do! On Fri, Oct 9, 2020 at 10:26 AM Dick Hardt wrote: > Please join! > =E1=90=A7 > > On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodges 40google.com@dmarc.ietf.org> wrote: > >> > The Web Authorization Protocol (oauth) WG will hold >> > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 >> America/Toronto (17:00 to 18:00 UTC). >> > >> > Agenda: >> > 1. High level overview of anti-tracking and the IsLoggedIn & WebID >> initiatives >> > 2. Impact on the OAuth WG work >> > 3. Proposal for a WG position on these initiatives. >> > 4. Discussion >> > >> > Information about remote participation: >> > >> https://ietf.webex.com/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2a= 0c >> >> Hi, >> >> We're involved in WebID and just want to acknowledge that we are aware >> of this upcoming discussion and that we're happy to join the meeting >> to answer questions and provide context if that'd be helpful. >> >> HTH, >> >> Sam Goto >> Justin Toupin >> =3DJeffH >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000003da4cf05b17d5626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Awesome! Will do!

    On Fri, Oct 9, 2020 at 10:26 AM Dick Hard= t <dick.hardt@gmail.com> = wrote:
    Please join!
    3D""=E1=90=A7

    On Fri, Oct 9, 20= 20 at 10:17 AM Jeff Hodges <jdhodges=3D40google.com@dmarc.ietf.org> wrote:<= br>
    > The Web Aut= horization Protocol (oauth) WG will hold
    > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/To= ronto (17:00 to 18:00 UTC).
    >
    > Agenda:
    > 1.=C2=A0 =C2=A0 High level overview of anti-tracking and the IsLoggedI= n & WebID initiatives
    > 2.=C2=A0 =C2=A0 Impact on the OAuth WG work
    > 3.=C2=A0 =C2=A0 Proposal for a WG position on these initiatives.
    > 4.=C2=A0 =C2=A0 Discussion
    >
    > Information about remote participation:
    > https://ietf.webex.co= m/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2a0c

    Hi,

    We're involved in WebID and just want to acknowledge that we are aware<= br> of this upcoming discussion and that we're happy to join the meeting to answer questions and provide context if that'd be helpful.

    HTH,

    Sam Goto
    Justin Toupin
    =3DJeffH

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000003da4cf05b17d5626-- From nobody Wed Oct 14 09:48:43 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E41393A0832; Wed, 14 Oct 2020 09:48:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160269411578.23309.18054780455023209849@ietfa.amsl.com> Date: Wed, 14 Oct 2020 09:48:35 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-30 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 16:48:36 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2020-11-30 from 12:00 to 13:00 America/Toronto (17:00 to 18:00 UTC). Agenda: Present and discuss the latest with DPoP: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m0983844069af46bf19cc6cb0bda41968 From nobody Wed Oct 14 11:15:20 2020 Return-Path: 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 E24143A0FCC for ; Wed, 14 Oct 2020 11:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 u7YJ7HwCNz92 for ; Wed, 14 Oct 2020 11:15:15 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 BE9AA3A0B5F for ; Wed, 14 Oct 2020 11:15:14 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id d81so470110wmc.1 for ; Wed, 14 Oct 2020 11:15:14 -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; bh=mDMGjC1z8GvtonVaOlbWepJVkHmScP5f3oAkLPJ7mJE=; b=r8uNdw1OvENc3cUxoLgl3WfzzSwNNQeTh7F+GafudePozX+Nz0Nbk/qLuHhiOQ4zUV Ea1sBZhK1h74u09QEwTrwokoI6R2AhiLwLUnN/FFSvA0G1EApShGuRqVzsfmdRHPkHaj YfWPNMt1i8c+Im3oJMDsGsJuntN2ESfug4os/sl8L1+MUX2iGbl8AOTKYwKJSU5FqudO jnxKuEYgUGRDXNDhir0FrgYn7oK9xwEs2e2ZCcZ9Cf3bnKNcyunr6NvDSX6r0Aa1urtE lSn6vuKgPJMYIom3mW+pQJtg+ZBl7SECDx60OvDlprh/sheuyefP3uwLucBkgecWUN6R xFtA== 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; bh=mDMGjC1z8GvtonVaOlbWepJVkHmScP5f3oAkLPJ7mJE=; b=jymH9p47EBDUG+il0CJBJ66Ou/zL1s+l1OYG9A4kxh33iB7KlRHhYsN55tJTKutFrO v8yoiEFteakeia0JoUZCf+L54hN8ka0RICCVurkhdWHgctahsaWfoA7pJCVj+rjl1VJQ oT6Gb7YyoSSk4XYtml1V2Olm9BSBSX8CU/RhRT1YxKOGCGAj99vN1QvrhYJte7mQpAJz TTG4Y0Ljwhi2+P4Cq5rV9pbNQgfeLBVf/TSEgnFM4MGKsUQB2cfJiHkCdvoLq+AxpdRF D9H8muSBVB4BIY6Pvr4rgejShJnJ7OBy2S7R621QcNro/EqxIrYfRgU37Nd7dDwTubgl E4Bg== X-Gm-Message-State: AOAM531Tdkgb2e52sTamMJB6DWl30oauC7IAc/W7YafaBuMy3e2fuSoD RDWj+DyeJ5YjUOreTm0HRGqj5CRvOtEPjI831iFXhwos2dY= X-Google-Smtp-Source: ABdhPJz0mQg/grfHDfznTEjB1Ye1wCmtrBkNWYb/HWnurfnG4DnYUNG08g9DGki9h/16zcFnrFgJyKOgviSbi3cjjno= X-Received: by 2002:a1c:40d5:: with SMTP id n204mr138537wma.148.1602699313004; Wed, 14 Oct 2020 11:15:13 -0700 (PDT) MIME-Version: 1.0 References: <1730740853.6770201602680022222.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <1730740853.6770201602680022222.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Wed, 14 Oct 2020 14:15:01 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000003bdddb05b1a583c6" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 18:15:18 -0000 --0000000000003bdddb05b1a583c6 Content-Type: multipart/alternative; boundary="0000000000003bddd905b1a583c4" --0000000000003bddd905b1a583c4 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Wed, Oct 14, 2020 at 8:53 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim - DPoP To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 171 915 6508 Meeting password: rrF63xrn2TJ Monday, November 2, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,1719156508## <%2B1-650-479-3208,,*01*1719156508%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 1719156508@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 1719156508.ietf@lync.webex.com Need help? Go to http://help.webex.com --0000000000003bddd905b1a583c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    ---------- Forwarded message ---------
    From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
    Date: Wed, Oct 14, 2020 at 8:53 AM
    = Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim - D= PoP
    To: <oauth-chairs@ietf.= org>


    =C2=A0
    =09
    You can forward this invitation to others.

    Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
    =C2= =A0
    Meeting number (access code): 171 915 6508
    Meeting password: rrF63xrn2TJ
    =C2= =A0
    Monday, November 2, 2020
    12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
    =20
    =C2=A0
    Join meeting
    = =C2=A0
    Tap to join from a mobile device = (attendees only)
    +1-650-4= 79-3208,,1719156508## Call-in toll number (US/Canada)
    =C2=A0
    <= tr style=3D"margin:0px">=
    Join by phone
    1-650-479-3208=C2=A0Call-in toll number (US/Canada)
    Global call-in numbers
    =C2=A0
    Join from a video system or appli= cation
    Dial 1719156508@ietf.webex.com
    You can also dial 173.243.2.68 and enter your meeting nu= mber.
    =C2=A0
    Join using Microsoft Lync or Microsoft Skype for Business
    Dial 1719156508.ietf@lync.webex.com
    =C2= =A0
    =09
    =C2=A0
    Need help? Go to http://help.webe= x.com
    =C2=A0
    --0000000000003bddd905b1a583c4 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20201014T125342Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20201102T120000 DTEND;TZID=3DAmerica/New_York:20201102T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dmb721b19c248d16599386b385= 615e88fa TRANSP:OPAQUE SEQUENCE:1602680022 UID:ae67b1cd-765a-487a-9115-ef31bf0380e9 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dmb721b19c248d16599386b385615e88fa\nMeeting number (access code): 171 = 915 6508\n\nMeeting password: rrF63xrn2TJ\n\n\n\nTAP TO JOIN FROM A MOBILE = DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1719156508## tel:%2B1-650-479-320= 8,,*01*1719156508%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PH= ONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbe= rs\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm2ff5ec96547a7f459d= 2c3c1685b94c79\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:17191= 56508@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting= number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDi= al sip:1719156508.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nh= ttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NOTI= CE: Please note that this Webex service allows audio and other information = sent during the session to be recorded, which may be discoverable in a lega= l matter. By joining this session, you automatically consent to such record= ings. If you do not consent to being recorded, discuss your concerns with t= he host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n \n \n
     
    \n \n\n\n\n\n\n = \n \n \n \n \n \n \n
    \n When it's time, join the Webex meeting here.\n \n
     
    \n Meeting number (access code): 171 915 6508\n =
    \n
    Meeting password:rrF63xrn2TJ
    \n= \n \n \n \n \n \n
     
    \n \n \n= \n
    Join meeting<= /td>\n
    \n
    \n\n \n 
     
    \n\n 
    = Tap to join from a mobile device (attendees only)  
    +1-650-479-3208,,171= 9156508## Call-in toll number (US/Canada) 

    J= oin by phone  
    1-650-479-3208 Call-in toll number (US/Canada)  
    Global call-in numbe= rs     


    \n\n
     
    \n\nJoin from a v= ideo system or application
    Dial 1719156508@ietf.webex.com 
    You can also= dial 173.243.2.68 and enter your meeting number.  
    =  
    \n\n
    Join using Microsoft Lync or Microsoft Skype for Busine= ss
    Dial 1719156508.ietf@lync.webex.com
    \n\n
     
    \n= \n\n \n = \n \n = \n \n \n
     
    Need help? Go to http://help.webex.com\n =
     =
    \n
    \n SUMMARY:OAuth WG Interim - DPoP PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --0000000000003bddd905b1a583c4-- --0000000000003bdddb05b1a583c6 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1752852747dc1ce7aee1> X-Attachment-Id: 1752852747dc1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAxMDE0 VDEyNTM0MloNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMTEwMlQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMTEwMlQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1iNzIxYjE5YzI0OGQxNjU5OTM4NmIzODU2MTVlODhmYQ0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTYwMjY4MDAyMg0KVUlEOmFlNjdiMWNkLTc2NWEtNDg3YS05MTE1LWVmMzFi ZjAzODBlOQ0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iNzIxYjE5YzI0OGQxNjU5OTM4NmIzODU2 MTVlODhmYVxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTcxIDkxNSA2NTA4XG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IHJyRjYzeHJuMlRKXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9C SUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDE3MTkxNTY1MDgj IyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxNzE5MTU2NTA4JTIzJTIzKjAxKiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMy MDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbiBudW1i ZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW0y ZmY1ZWM5NjU0N2E3ZjQ1OWQyYzNjMTY4NWI5NGM3OVxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTcxOTE1NjUwOEBpZXRmLndlYmV4LmNvbVxu WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTcxOTE1NjUwOC5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5 b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9y ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNw YWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9u dC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7 XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRo OiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1l ZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJ Zm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAh aW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJ d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1c bgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFp bXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5 bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4 OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8 Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1l LCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFj Y2VzcyBjb2RlKTogMTcxIDkxNSA2NTA4PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5yckY2M3hybjJUSjwvRk9OVD48 L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNB OTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tYjcyMWIxOWMyNDhkMTY1OTkzODZiMzg1NjE1ZTg4ZmEi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0i I0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9 IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k ZWVzIG9ubHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxOTE1 NjUwOCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5v bmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7 Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTkxNTY1MDgjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bTJmZjVlYzk2NTQ3YTdmNDU5ZDJjM2MxNjg1Yjk0Yzc5IiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0g b3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE3MTkxNTY1MDhAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+MTcxOTE1 NjUwOEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDoxNzE5MTU2NTA4LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTkxNTY1MDguaWV0ZkBs eW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCTx0YWJsZT48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcy cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdo dDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8v aGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAg ICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0 aCBXRyBJbnRlcmltIC0gRFBvUA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxB Uk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0K RU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --0000000000003bdddb05b1a583c6-- From nobody Wed Oct 14 13:14:42 2020 Return-Path: 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 266283A1034 for ; Wed, 14 Oct 2020 13:14:41 -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 46MmEanQzut7 for ; Wed, 14 Oct 2020 13:14:39 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 4941C3A1033 for ; Wed, 14 Oct 2020 13:14:39 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id p15so746455wmi.4 for ; Wed, 14 Oct 2020 13:14:39 -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; bh=4jsj3Nf27eLBVvEiKNW1Ve0oYj2tBEcQrk3mfjlg5SM=; b=WUe1/FVaKCe1DtmrN3dTwZsYYy12TXHIVeJPaMVs0I4XNGaB2D5jlggrZS1KIkE1JL cfNdsiy0KbMKBL2IbVKkgMOPSLqW1NDXAJSHoQ95NTC/2XHmuzVbWt022btmEq7C0hPQ tgCQNZvONO8VGuASPNpJZkdjKtVWShE9HuBjDi2EiUQ4+mD6sroKsna1yn/R0calwm3H Ow4Ir0oHKVXEQc/maS12s2baEkeDpD6/4LNN7oOhh1OsDLUPCCGY/OPN3hajeT3yC6wc EiPb03HKszPiAE8kDmVXX5DpOuF3YkogxdlCG0AZ8V6UCAeHk3jxr7lng0yJUqQI9KuZ JEHw== 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=4jsj3Nf27eLBVvEiKNW1Ve0oYj2tBEcQrk3mfjlg5SM=; b=DnBm/ZBb1Y91u5+n2/Qe9ke0yNUjVwClfiOPpouiyDxoASQ/iesIKFXwxRZbZmUfwA G41Zzr9b9HlZk3J+wqVXjvB2Cm0A+OB7pXmTkKBvwrHMO8v4hKNjnpT7mOrYB+2nRNln e0RMBqFkBkdtQGhKqCvMe70Em5nRMOQzsoMKcBjDOiLERfGPyRuiz+WjtKu9dYvjSzPP OcMXaPDg6c3CRpl2QNz83H6lTutX9pUPp+wdVxAw+qiuWQXdhsk4eMsZKDAXCtANckZS azP4+HZP8XvReQT2oJqHlGaxkN5KeN3m7N09ShhaofQa/I4R2ZLXEa1AucHTyHV3P1la Gwcg== X-Gm-Message-State: AOAM530A8mSQ2JsP1yy/ED/+BWDED7usLf6HRzlZHw9mRlCZlfmls7u3 5EaBLApvnl+445m73wyJiZob255HrM7LCk3Rv+4= X-Google-Smtp-Source: ABdhPJxY05Fb3oDSRblKuYsP2YNi29UskAKwhh0hCrR6CftmpOmw1x+YHLzBnOvVsU7gj2vLkJQaoaPfb5iXWF8xgpM= X-Received: by 2002:a1c:40d5:: with SMTP id n204mr513334wma.148.1602706477726; Wed, 14 Oct 2020 13:14:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 14 Oct 2020 16:14:26 -0400 Message-ID: To: Sam Goto Cc: Dick Hardt , Jeff Hodges , oauth , Justin Toupin Content-Type: multipart/alternative; boundary="00000000000048c05405b1a72ec7" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 20:14:41 -0000 --00000000000048c05405b1a72ec7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, During the last *Identiverse* meeting, there was a session, presented by Vittorio, about new browser features to prevent user tracking and their potential impact on the identity flows. Please, make sure to watch this short presentation, as it will provide you with the background needed to allow us to have a productive discussion without spending too much time on this background information. https://identiverse.gallery.video/detail/video/6184443037001/browser-featur= es-vs-identity-protocols Regards, Rifaat On Mon, Oct 12, 2020 at 2:20 PM Sam Goto wrote: > Awesome! Will do! > > On Fri, Oct 9, 2020 at 10:26 AM Dick Hardt wrote: > >> Please join! >> =E1=90=A7 >> >> On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodges > 40google.com@dmarc.ietf.org> wrote: >> >>> > The Web Authorization Protocol (oauth) WG will hold >>> > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 >>> America/Toronto (17:00 to 18:00 UTC). >>> > >>> > Agenda: >>> > 1. High level overview of anti-tracking and the IsLoggedIn & WebID >>> initiatives >>> > 2. Impact on the OAuth WG work >>> > 3. Proposal for a WG position on these initiatives. >>> > 4. Discussion >>> > >>> > Information about remote participation: >>> > >>> https://ietf.webex.com/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2= a0c >>> >>> Hi, >>> >>> We're involved in WebID and just want to acknowledge that we are aware >>> of this upcoming discussion and that we're happy to join the meeting >>> to answer questions and provide context if that'd be helpful. >>> >>> HTH, >>> >>> Sam Goto >>> Justin Toupin >>> =3DJeffH >>> >>> _______________________________________________ >>> 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 > --00000000000048c05405b1a72ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All,

    During the last Identiverse= meeting, there was a session, presented by Vittorio, about new browser fea= tures to prevent user tracking and their potential impact on the identity f= lows.
    Please, make sure to watch this short presentation, as it w= ill provide you with the background needed to allow us to have a productive= =C2=A0discussion without spending too=C2=A0much time on this background inf= ormation.


    Re= gards,
    =C2=A0Rifaat


    On Mon, Oct 12, 2020 at 2= :20 PM Sam Goto <goto=3D40google.com@dmarc.ietf.org> wrote:
    Awesome! Will = do!

    On Fri, Oct 9, 2020 at 10:26 AM Dick Hardt <dick.hardt@gmail.com> wrote:
    Pleas= e join!
    =E1=90=A7

    On Fri, Oct 9, 2020 at 10:17 AM= Jeff Hodges <jdhodges=3D40google.com@dmarc.ietf.org> wrote:
    > The Web Authorization Pro= tocol (oauth) WG will hold
    > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/To= ronto (17:00 to 18:00 UTC).
    >
    > Agenda:
    > 1.=C2=A0 =C2=A0 High level overview of anti-tracking and the IsLoggedI= n & WebID initiatives
    > 2.=C2=A0 =C2=A0 Impact on the OAuth WG work
    > 3.=C2=A0 =C2=A0 Proposal for a WG position on these initiatives.
    > 4.=C2=A0 =C2=A0 Discussion
    >
    > Information about remote participation:
    > https://ietf.webex.co= m/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2a0c

    Hi,

    We're involved in WebID and just want to acknowledge that we are aware<= br> of this upcoming discussion and that we're happy to join the meeting to answer questions and provide context if that'd be helpful.

    HTH,

    Sam Goto
    Justin Toupin
    =3DJeffH

    _______________________________________________
    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
    --00000000000048c05405b1a72ec7-- From nobody Wed Oct 14 13:26:14 2020 Return-Path: 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 27E773A1049 for ; Wed, 14 Oct 2020 13:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9xt3IXiLvZfU for ; Wed, 14 Oct 2020 13:26:10 -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 AC77F3A1047 for ; Wed, 14 Oct 2020 13:26:09 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id b8so590776wrn.0 for ; Wed, 14 Oct 2020 13:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ygVZ1WxIC7ZQOdXowSzwOrhAn2R5xm5ekEve7aVljA=; b=WlT5tap899B6mcgPYjEb+Zk7sMwl7yu5CBofxV4fcxa0nbpdWYw6Rw+BSBn02eqo6q BQg8ZadFV9zxG0aW4EVxuhMqdPfI+NzxzjUpIYIXcQBcdIu51YpmtM5tGzkeQAbi3N/P OQyc9j4+dj/JQxbfxiDFW6YviVOu4SD2xzTokWGCWo+K3PcZ/eBlbiUGU6DZ0fs4G9Xg WjP9/gdmtLU2Y+dxddM7gMQGXHt0eZ4VdHzArShAbWAERSAfB8Kn/fU5PiWVwTbP6+2A S4zeP1KQ4OzmmlNFDlacXvsRnYpaIt37plhSar7wp/ZdoYTcvFoOQhV4rU2k2CqtVZCw iRtQ== 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=2ygVZ1WxIC7ZQOdXowSzwOrhAn2R5xm5ekEve7aVljA=; b=YxBQdvWZ3Eor6Fpa8RhH76rHWI0OEnKJsrwuhpfsw9dIBUB1zT5t7Q3Th9eq0duFii 5ut5W406nghMl4o/eG7spWuRVsRK+NY1rAgU5aZkj7OzTvWBtJ7LaSYF8nNcNfqvJqfT 3Tyxog4JbNeU8yO3nRotCE8vYbAjDvFAovxfrnmLs3iYUEv2y9pzO4hpnbb1m1ao9lCg 4yv9gWznw7snAIkjGoVvhnguiIfEAuwQnoDV1bD9w2+iML2PdtUQ6fjo1t4pg6DFrX4M q01yDv5Peyh8Tkbb0AYMEdA03TkusLwN0zXAFhRaDExlQTsUiyFRPOUq8f28Ott/x5Nf W3KQ== X-Gm-Message-State: AOAM530t42kW2NctL2z75phDhnWdq+GTJz8Qdv/CcDflMK7NxHGkACmT GFKAkgA6ZQhsLOes3LjprC0wu97t6mTPXUK7zM9jbA== X-Google-Smtp-Source: ABdhPJyMAKZHDzH3h0x7hsw9NUQpvv/mlffwZA9gbzsUSLangZsqOAuWvsT9zV1+6yjFzCnbLjD6MESyn4R/iDHpfb4= X-Received: by 2002:adf:8b48:: with SMTP id v8mr509240wra.21.1602707167886; Wed, 14 Oct 2020 13:26:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sam Goto Date: Wed, 14 Oct 2020 13:25:56 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: Sam Goto , Jeff Hodges , Justin Toupin , oauth Content-Type: multipart/alternative; boundary="0000000000006c43d905b1a757b3" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-11-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 20:26:13 -0000 --0000000000006c43d905b1a757b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1. Would strongly recommend watching Vittorio's talk as background / context / motivation for WebID (short thread ). George Fletcher has also given a really good talk / webinar in the beginning of the year which is more or less similar in substance to Vittorio's: https://www.niso.org/events/2020/05/browser-changes-and-identity-federation= -impact-identity-flows On Wed, Oct 14, 2020 at 1:14 PM Rifaat Shekh-Yusef wrote: > All, > > During the last *Identiverse* meeting, there was a session, presented by > Vittorio, about new browser features to prevent user tracking and their > potential impact on the identity flows. > Please, make sure to watch this short presentation, as it will provide yo= u > with the background needed to allow us to have a productive discussion > without spending too much time on this background information. > > > https://identiverse.gallery.video/detail/video/6184443037001/browser-feat= ures-vs-identity-protocols > > Regards, > Rifaat > > > On Mon, Oct 12, 2020 at 2:20 PM Sam Goto > wrote: > >> Awesome! Will do! >> >> On Fri, Oct 9, 2020 at 10:26 AM Dick Hardt wrote: >> >>> Please join! >>> =E1=90=A7 >>> >>> On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodges >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> > The Web Authorization Protocol (oauth) WG will hold >>>> > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 >>>> America/Toronto (17:00 to 18:00 UTC). >>>> > >>>> > Agenda: >>>> > 1. High level overview of anti-tracking and the IsLoggedIn & WebI= D >>>> initiatives >>>> > 2. Impact on the OAuth WG work >>>> > 3. Proposal for a WG position on these initiatives. >>>> > 4. Discussion >>>> > >>>> > Information about remote participation: >>>> > >>>> https://ietf.webex.com/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b= 2a0c >>>> >>>> Hi, >>>> >>>> We're involved in WebID and just want to acknowledge that we are aware >>>> of this upcoming discussion and that we're happy to join the meeting >>>> to answer questions and provide context if that'd be helpful. >>>> >>>> HTH, >>>> >>>> Sam Goto >>>> Justin Toupin >>>> =3DJeffH >>>> >>>> _______________________________________________ >>>> 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 > --0000000000006c43d905b1a757b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1. Would strongly recommend watching Vittorio's talk = as background / context / motivation for WebID (short=C2=A0thread). George F= letcher has also given a really good talk / webinar=C2=A0in the beginning o= f the year which is more or less similar in substance to Vittorio's:


    On Wed, Oct 14, 2020 at 1:14 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wro= te:
    All,

    During the last Identiverse meeting, th= ere was a session, presented by Vittorio, about new browser features to pre= vent user tracking and their potential impact on the identity flows.
    <= div>Please, make sure to watch this short presentation, as it will provide = you with the background needed to allow us to have a productive=C2=A0discus= sion without spending too=C2=A0much time on this background information.


    Regards,
    =
    =C2=A0Rifaat


    =
    On Mon, Oct 12, 2020 at 2:20 PM Sam G= oto <goto=3D40google.com@dmarc.ietf.org> wrote:
    Awesome! Will do!
    On Fri, = Oct 9, 2020 at 10:26 AM Dick Hardt <dick.hardt@gmail.com> wrote:
    Please join!
    3D""=E1=90=A7

    On Fri, Oct 9, 2020 at 10:17 AM Jeff Hodge= s <jdhodges=3D40google.com@dmarc.ietf.org> wrote:
    > The Web Authorization Protocol (oaut= h) WG will hold
    > a virtual interim meeting on 2020-11-02 from 12:00 to 13:00 America/To= ronto (17:00 to 18:00 UTC).
    >
    > Agenda:
    > 1.=C2=A0 =C2=A0 High level overview of anti-tracking and the IsLoggedI= n & WebID initiatives
    > 2.=C2=A0 =C2=A0 Impact on the OAuth WG work
    > 3.=C2=A0 =C2=A0 Proposal for a WG position on these initiatives.
    > 4.=C2=A0 =C2=A0 Discussion
    >
    > Information about remote participation:
    > https://ietf.webex.co= m/ietf/j.php?MTID=3Dm7e21c550ab77d0da08845741bb0b2a0c

    Hi,

    We're involved in WebID and just want to acknowledge that we are aware<= br> of this upcoming discussion and that we're happy to join the meeting to answer questions and provide context if that'd be helpful.

    HTH,

    Sam Goto
    Justin Toupin
    =3DJeffH

    _______________________________________________
    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
    --0000000000006c43d905b1a757b3-- From nobody Wed Oct 14 13:43:44 2020 Return-Path: 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 D2DB03A1065; Wed, 14 Oct 2020 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3LaBE_0gYKWE; Wed, 14 Oct 2020 13:43:36 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD763A1062; Wed, 14 Oct 2020 13:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 71F193C3035; Wed, 14 Oct 2020 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I5HyFSRRP48; Wed, 14 Oct 2020 13:43:34 -0700 (PDT) Received: from [192.168.1.31] (cpe-76-95-228-63.socal.res.rr.com [76.95.228.63]) by c8a.amsl.com (Postfix) with ESMTPSA id 0A5233C3034; Wed, 14 Oct 2020 13:43:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chris Smiley In-Reply-To: <20200531223908.5A9C9F406F6@rfc-editor.org> Date: Wed, 14 Oct 2020 13:43:34 -0700 Cc: ericramos1980@gmail.com, mbj@microsoft.com, ve7jtb@ve7jtb.com, Hannes.Tschofenig@gmx.net, kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0D70AB74-2B9C-4D25-AC26-AEDE315A2169@amsl.com> References: <20200531223908.5A9C9F406F6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC7800 (6195) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 20:43:39 -0000 Greetings, FYI we have deleted this report as a duplicate (per the verifier note = below). Thank you. RFC Editor/cs > On May 31, 2020, at 3:39 PM, RFC Errata System = wrote: >=20 > The following errata report has been rejected for RFC7800, > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6195 >=20 > -------------------------------------- > Status: Rejected > Type: Editorial >=20 > Reported by: Eric ramos > Date Reported: 2020-05-31 > Rejected by: Benjamin Kaduk (IESG) >=20 > Section: 7157 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, > DOI 10.17487/RFC7517, May 2015, > . >=20 >=20 > Notes > ----- >=20 > --VERIFIER NOTES--=20 > Seems to be a (malformed?) duplicate of eid 6187 >=20 > -------------------------------------- > RFC7800 (draft-ietf-oauth-proof-of-possession-11) > -------------------------------------- > Title : Proof-of-Possession Key Semantics for JSON Web = Tokens (JWTs) > Publication Date : April 2016 > Author(s) : M. Jones, J. Bradley, H. Tschofenig > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Oct 14 14:03:08 2020 Return-Path: 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 68ACF3A1042 for ; Wed, 14 Oct 2020 14:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 MNj3Hp4rkIae for ; Wed, 14 Oct 2020 14:03:05 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 408A03A082C for ; Wed, 14 Oct 2020 14:03:05 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id e18so623142wrw.9 for ; Wed, 14 Oct 2020 14:03:05 -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; bh=RnLDIARPG2IDRaZxETT3lG+KkP+yPLqfliM7Eyg8yqw=; b=qNmXWNCJHlZSA1uJMRcuGsl4m4WZiwzwYUQJ02gDx6so3wdVXHxe07XYSqh84IqgcF k7eS3KWVwVPqu/DvZNJ6IIIyd8cBCfxit2R0ism1FsX0pxAQ9HYYi6MQmorzISWb8xW/ m1as3+z4+IoBJkTns8p1pIJpp4LNK1VR1lDRnic6gg8BYZ9A2/LIwpNHtechDelKhZvK gGsAcxoOJNRoeHPmj9YrQSbUdxGYVhHI3dQjU2FzPa7yND+xFWc8WpUH047lKJM+Hn+d C47jxObXMikJVAV5E+zjCO3wJQPjCgqOg6s0J9OHxI7KSkqHR5+N7w4v61zA26RvlBHH n6hg== 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; bh=RnLDIARPG2IDRaZxETT3lG+KkP+yPLqfliM7Eyg8yqw=; b=J086am9FlM+Es34dqngGF/Du5+vk4BNHdNjNGuR/tTGN9zY88YcpLvdN0n0z7DgVHW V2iUCnIIyx6rikFSO+Z22D4wEjN8NUHppZz2lppkMdqJDRDzoFQT2+JrArp2V9wt8MR3 j7k3csb/aRDPJtNqtJqzRdy5UQM2WeJmfmzVR96RsGTa5RX8WwcdIGbkYnmmniHKnp6f RfOy1Tsm3BwQwc61PK9oZ8bZonqdEqnrpspSMHS4yXQAnndS5P7nb8zJEgBwIcioEYC2 FW7VGCUCn/2hjLLRMJzwVE8irg18ytZJseixDLrh9jgODQafV2IO1x5sGkJgbwqnKUh3 dhAg== X-Gm-Message-State: AOAM532YoTMPmZ2/utt/ZwSDMUTyLzAE/h8LQlWd66Sa3erQNUH2ydYt 4sBEjv5TwegY1xHIFQfa0mtCF+u8MsEtmgn9uvnbiCT04OY= X-Google-Smtp-Source: ABdhPJySsxW4GoGCeGsIJ2Dr1FhJtVpmGq9+3+jGILjncscRTt64H8lPX67UoYvmEAgTW1JKvo4+zQYRHZ0iWYBIDuU= X-Received: by 2002:adf:cd87:: with SMTP id q7mr601753wrj.169.1602709383292; Wed, 14 Oct 2020 14:03:03 -0700 (PDT) MIME-Version: 1.0 References: <1997397045.6829671602684106454.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <1997397045.6829671602684106454.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Wed, 14 Oct 2020 17:02:52 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="000000000000786d1405b1a7db74" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 21:03:07 -0000 --000000000000786d1405b1a7db74 Content-Type: multipart/alternative; boundary="000000000000786d1305b1a7db72" --000000000000786d1305b1a7db72 Content-Type: text/plain; charset="UTF-8" Here is the correct invitation for the *DPoP* meeting. Regards, Rifaat ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Wed, Oct 14, 2020 at 10:01 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Interim - DPoP To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 171 459 0056 Meeting password: XGyxwjpB338 Monday, November 30, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,1714590056## <%2B1-650-479-3208,,*01*1714590056%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 1714590056@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 1714590056.ietf@lync.webex.com Need help? Go to http://help.webex.com --000000000000786d1305b1a7db72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Here is the correct invitation for the DPoP meeting= .

    Regards,
    =C2=A0Rifaat


    ---------- For= warded message ---------
    From: Web Authorization Protocol Working Group <messenger@webex.com>
    Date: Wed, Oct 14, 2020 at 10:01 AM
    Subject: (Forward to others) = Webex meeting invitation: OAuth WG Interim - DPoP
    To: <oauth-chairs@ietf.org>


    =C2=A0
    =09
    You can forward this invitation to others.

    Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
    =C2= =A0
    Meeting number (access code): 171 459 0056
    Meeting password: XGyxwjpB338
    =C2= =A0
    Monday, November 30, 2020
    12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
    =20
    =C2=A0
    Join meeting
    = =C2=A0
    Tap to join from a mobile device = (attendees only)
    +1-650-4= 79-3208,,1714590056## Call-in toll number (US/Canada)
    =C2=A0
    <= tr style=3D"margin:0px">=
    Join by phone
    1-650-479-3208=C2=A0Call-in toll number (US/Canada)
    Global call-in numbers
    =C2=A0
    Join from a video system or appli= cation
    Dial 1714590056@ietf.webex.com
    You can also dial 173.243.2.68 and enter your meeting nu= mber.
    =C2=A0
    Join using Microsoft Lync or Microsoft Skype for Business
    Dial 1714590056.ietf@lync.webex.com
    =C2= =A0
    =09
    =C2=A0
    Need help? Go to http://help.webe= x.com
    =C2=A0
    --000000000000786d1305b1a7db72 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20201014T140146Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20201130T120000 DTEND;TZID=3DAmerica/New_York:20201130T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm0983844069af46bf19cc6cb0= bda41968 TRANSP:OPAQUE SEQUENCE:1602684106 UID:8d995cce-89d8-4468-acd6-489332953ebd DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dm0983844069af46bf19cc6cb0bda41968\nMeeting number (access code): 171 = 459 0056\n\nMeeting password: XGyxwjpB338\n\n\n\nTAP TO JOIN FROM A MOBILE = DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1714590056## tel:%2B1-650-479-320= 8,,*01*1714590056%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PH= ONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbe= rs\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dmc0c4e5ed792d8c00ae= d7ceffd4e9aff6\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:17145= 90056@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting= number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDi= al sip:1714590056.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nh= ttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NOTI= CE: Please note that this Webex service allows audio and other information = sent during the session to be recorded, which may be discoverable in a lega= l matter. By joining this session, you automatically consent to such record= ings. If you do not consent to being recorded, discuss your concerns with t= he host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n \n \n
     
    \n \n\n\n\n\n\n = \n \n \n \n \n \n \n
    \n When it's time, join the Webex meeting here.\n \n
     
    \n Meeting number (access code): 171 459 0056\n =
    \n
    Meeting password:XGyxwjpB338
    \n= \n \n \n \n \n \n
     
    \n \n \n= \n
    Join meeting<= /td>\n
    \n
    \n\n \n 
     
    \n\n 
    = Tap to join from a mobile device (attendees only)  
    +1-650-479-3208,,171= 4590056## Call-in toll number (US/Canada) 

    J= oin by phone  
    1-650-479-3208 Call-in toll number (US/Canada)  
    Global call-in numbe= rs     


    \n\n
     
    \n\nJoin from a v= ideo system or application
    Dial 1714590056@ietf.webex.com 
    You can also= dial 173.243.2.68 and enter your meeting number.  
    =  
    \n\n
    Join using Microsoft Lync or Microsoft Skype for Busine= ss
    Dial 1714590056.ietf@lync.webex.com
    \n\n
     
    \n= \n\n \n = \n \n = \n \n \n
     
    Need help? Go to http://help.webex.com\n =
     =
    \n
    \n SUMMARY:OAuth WG Interim - DPoP PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --000000000000786d1305b1a7db72-- --000000000000786d1405b1a7db74 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <17528eb47e1c1ce7aee1> X-Attachment-Id: 17528eb47e1c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAxMDE0 VDE0MDE0NloNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMTEzMFQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMTEzMFQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW0wOTgzODQ0MDY5YWY0NmJmMTljYzZjYjBiZGE0MTk2OA0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTYwMjY4NDEwNg0KVUlEOjhkOTk1Y2NlLTg5ZDgtNDQ2OC1hY2Q2LTQ4OTMz Mjk1M2ViZA0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0wOTgzODQ0MDY5YWY0NmJmMTljYzZjYjBi ZGE0MTk2OFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMTcxIDQ1OSAwMDU2XG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IFhHeXh3anBCMzM4XG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9C SUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDE3MTQ1OTAwNTYj IyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxNzE0NTkwMDU2JTIzJTIzKjAxKiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5LTMy MDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1pbiBudW1i ZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW1j MGM0ZTVlZDc5MmQ4YzAwYWVkN2NlZmZkNGU5YWZmNlxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTcxNDU5MDA1NkBpZXRmLndlYmV4LmNvbVxu WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv ciBCdXNpbmVzc1xuRGlhbCBzaXA6MTcxNDU5MDA1Ni5pZXRmQGx5bmMud2ViZXguY29tXG5cblxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAu Y2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNl c3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5 b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJu cyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVND O0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9y ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNw YWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9u dC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7 XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRo OiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1l ZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJ Zm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAh aW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJ d2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1c bgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFp bXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5 bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWdu PSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5c bgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4 OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJs ZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8 Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1l LCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFj Y2VzcyBjb2RlKTogMTcxIDQ1OSAwMDU2PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBT SVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5YR3l4d2pwQjMzODwvRk9OVD48 L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNB OTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tMDk4Mzg0NDA2OWFmNDZiZjE5Y2M2Y2IwYmRhNDE5Njgi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0i I0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9 IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k ZWVzIG9ubHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTcxNDU5 MDA1NiUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5v bmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7 Jz4rMS02NTAtNDc5LTMyMDgsLDE3MTQ1OTAwNTYjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bWMwYzRlNWVkNzkyZDhjMDBhZWQ3Y2VmZmQ0ZTlhZmY2IiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4g bnVtYmVyczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0g b3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE3MTQ1OTAwNTZAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+MTcxNDU5 MDA1NkBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05U PiZuYnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0 cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1 c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7 IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsi PkRpYWwgPGEgaHJlZj0iIHNpcDoxNzE0NTkwMDU2LmlldGZAbHluYy53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjkiPjE3MTQ1OTAwNTYuaWV0ZkBs eW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCTx0YWJsZT48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+PC90YWJsZT5cbglcblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAwJTsiIGFsaWduPSJs ZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcy cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdo dDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVmPSJodHRwOi8v aGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAg ICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0 aCBXRyBJbnRlcmltIC0gRFBvUA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxB Uk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0K RU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --000000000000786d1405b1a7db74-- From nobody Sun Oct 18 09:05:56 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 638F13A0990; Sun, 18 Oct 2020 09:05:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <160303714332.6068.1637816246101622639@ietfa.amsl.com> Date: Sun, 18 Oct 2020 09:05:43 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 16:05:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-10.txt Pages : 20 Date : 2020-10-18 Abstract: This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 09:09:21 2020 Return-Path: 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 0AB8D3A09AD for ; Sun, 18 Oct 2020 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net 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 JZVdBRijDDD8 for ; Sun, 18 Oct 2020 09:09:18 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 49A793A09A8 for ; Sun, 18 Oct 2020 09:09:18 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id ce10so10485239ejc.5 for ; Sun, 18 Oct 2020 09:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=vaZRNGB37MALmoHLE59g5H5v8k1IdmZbTfPRVi7CfWs=; b=hU9D2sH74Qt4Avig4uSbkha2mScB99bDqW7VUnZAgiijKMNPQfibGcT+p4AF7/v/NY wWzdGA7hyH9GgNJwNkCQ5K2opDYWxDqLoS5dM+tkeYLyx7jIXAtI2YPRB+bYvp8T9HS2 Ugxu/Wg44W0ohbxI2QzNyfoRZEtu44WobXG23BlL0gD+0neqEAAC88OAwGEE3yCKVSdc C2Pivj1tGuPd1nTZ6eHDwy9e2cUdL6JJUVUa6j09YHfKszwI/dHLMNPOs/RmwJNwo6Qa /6ySmlWElIiM+ZmG1uI/b6+0nqtvpx/0TJ60UCCETRtdLUk9UCH3+EIsav4T9gqR2cwI v0Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=vaZRNGB37MALmoHLE59g5H5v8k1IdmZbTfPRVi7CfWs=; b=hiHRuk2B+msbr/nKLy5qufCyzYF87KaMqSrsrdOGgS5Je7Wq6wjw5InVnUPVtdKxmY P/Y9OO2c5qOTx/bYkVeVtKlwhDIMTbqcB06orV19Ii3N91vhZcXtrpO9kI/JpaRwQjVW /Zi9M3YPb4uSrfYCkXmAi+wcIWqoLKGhVpMnxDYiMFsw38PGIQISWACXFuQOwhIzenuJ aajTtTC4UFv7tE963S9ZgWEOi1mNq6JQbIdjvJXEkfHTYDgVQmNIORNDjgXJMEg6va1r Tl668Givh+ah956JL57EZuZgMKqfoaRBnnPkVT8WPqQvLS60zAp6mZxsN7bexu3mvRv2 t+uQ== X-Gm-Message-State: AOAM533BqSXgeHz9ouWs3na9OS1ZlPGljM7SscESxgsOOpaZXai3It/Q f2cmKnnJnSwIkjr25NHKAkNe82SpyYoH6G3L X-Google-Smtp-Source: ABdhPJxpx0ApnTCYD9t/HOz1W4EscffyuwT2TmqZ4Py2KFVX9Pif/Hs2QHd3LRecNCeQohv2134lXg== X-Received: by 2002:a17:906:52d5:: with SMTP id w21mr14057854ejn.501.1603037356428; Sun, 18 Oct 2020 09:09:16 -0700 (PDT) Received: from p200300eb8f1e2a8dd0f8825fc3117f11.dip0.t-ipconnect.de (p200300eb8f1e2a8dd0f8825fc3117f11.dip0.t-ipconnect.de. [2003:eb:8f1e:2a8d:d0f8:825f:c311:7f11]) by smtp.gmail.com with ESMTPSA id m9sm7700237ejl.45.2020.10.18.09.09.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2020 09:09:15 -0700 (PDT) From: Torsten Lodderstedt Content-Type: multipart/alternative; boundary="Apple-Mail=_4FA4AE89-1EC8-4F4D-BAB3-59DA8054ECD4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: References: <160303714332.6068.1637816246101622639@ietfa.amsl.com> To: OAuth WG Date: Sun, 18 Oct 2020 18:09:14 +0200 X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-jwt-introspection-response-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 16:09:20 -0000 --Apple-Mail=_4FA4AE89-1EC8-4F4D-BAB3-59DA8054ECD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 I just published a new revision of = draft-ietf-oauth-jwt-introspection-response.=20 Here are the changes from the history section:=20 * added requirement to authenticate RS if privacy sensitive data is released * reworked text on claims from different registries * added forward reference to privacy considerations to=20 section 5 * added text in privacy considerations regarding client/user tracking Thanks for the review comments and change proposals. best regards, Torsten.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [OAUTH-WG] I-D Action: = draft-ietf-oauth-jwt-introspection-response-10.txt > Date: 18. October 2020 at 18:05:43 CEST > To: > Cc: oauth@ietf.org > Reply-To: oauth@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : JWT Response for OAuth Token Introspection > Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename : = draft-ietf-oauth-jwt-introspection-response-10.txt > Pages : 20 > Date : 2020-10-18 >=20 > Abstract: > This specification proposes an additional JSON Web Token (JWT) > secured response for OAuth 2.0 Token Introspection. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-10= > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-r= esponse-10 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-res= ponse-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4FA4AE89-1EC8-4F4D-BAB3-59DA8054ECD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all, 

    I just = published a new revision = of draft-ietf-oauth-jwt-introspection-response. 

    Here are the changes = from the history section: 

    * added requirement to = authenticate RS if privacy sensitive data is
      =     released
    * reworked text on claims = from different registries
    * added forward reference = to privacy considerations to 
    section 5
    * = added text in privacy considerations regarding client/user
          tracking

    Thanks for the review comments and change = proposals.

    best = regards,
    Torsten. 

    Begin forwarded message:

    From: = internet-drafts@ietf.org
    Subject: = [OAUTH-WG] I-D = Action: draft-ietf-oauth-jwt-introspection-response-10.txt
    Date: = 18. October 2020 at 18:05:43 = CEST
    To: = <i-d-announce@ietf.org>
    Cc: oauth@ietf.org
    Reply-To: = oauth@ietf.org


    A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
    This draft is a work item of the Web = Authorization Protocol WG of the IETF.

    =        Title =           : JWT = Response for OAuth Token Introspection
    =        Authors =         : Torsten Lodderstedt
    =             &n= bsp;           &nbs= p;Vladimir Dzhuvinov
    Filename =        : = draft-ietf-oauth-jwt-introspection-response-10.txt
    Pages =           : 20
    = Date =            : = 2020-10-18

    Abstract:
    =   This specification proposes an additional JSON Web Token = (JWT)
      secured response for OAuth 2.0 Token = Introspection.


    The IETF = datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspec= tion-response/

    There are also htmlized = versions available at:
    https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-= response-10
    https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-intr= ospection-response-10

    A diff from the = previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-intros= pection-response-10


    Please = note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at = tools.ietf.org.

    Internet-Drafts are also = available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/


    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    = --Apple-Mail=_4FA4AE89-1EC8-4F4D-BAB3-59DA8054ECD4-- From nobody Sun Oct 18 09:18:01 2020 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49B3A0992; Sun, 18 Oct 2020 09:17:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <160303787486.11535.4121936533117572396@ietfa.amsl.com> Date: Sun, 18 Oct 2020 09:17:54 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 16:17:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-03.txt Pages : 35 Date : 2020-10-18 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 09:21:19 2020 Return-Path: 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 AEC203A09B0 for ; Sun, 18 Oct 2020 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net 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 YEg56Yn417-8 for ; Sun, 18 Oct 2020 09:21:16 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 CFE663A08C1 for ; Sun, 18 Oct 2020 09:21:10 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id t25so10446143ejd.13 for ; Sun, 18 Oct 2020 09:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=/DtotF1Egw5Sy034XxmnVVQT0gRsnDAbdtHXk7/GYIM=; b=Abv8hFT4mK9Gpkv9oJmay8WUKF3cZyCxmAQQzk/TP/6iU+RV9em6toHv6QUYkj30DE 2HbMS2nIWNB9ZSYQn+fXqnjkKPPw7brbI+kJgR5kmAWgQQiLAMn2bkR+O4tOnNfbuyVf QhQWfd9+gn59rFuwKkMiY7TK75Odn0H629Z9BOr9XfpurfThiD9EnCc0c6pqw17PnYVb xW/sO3Vu05oS+Rm+PCf4UEWodm/qT0QgDcGZ/Z0J9p4KU0Lt61i4R5mZAW2dfUYZaNv6 BcZj4FH8DGC8q5tjJB23r3YRxu9Ljb3eL6PHlcz1J/2Y8X0R/PgDKLJKOaZeavuv77oD fqmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=/DtotF1Egw5Sy034XxmnVVQT0gRsnDAbdtHXk7/GYIM=; b=aptv/TfTqYEspBDX7esm2EZptYDMvBBOfmDVwcqrCdBMgMrnHvpqarLTWEEC8cJsxe Pe9H761OH8dsWS/9gKvpwkVyB79HlHtoVXgQJk+OuTk0xP4CgKfjqZK6JWO6xio0Jy80 8qHwRrDQx0RROMx/fYVG6gmIwsCEwi4GqE5SjQLj932ZJAyWM/WYmffCWBlBf+EOiaS+ 6ximZyGD3yg5N0F8X6I0Ot97nEHLb/IErKPucpgeTs4+3EuNcvBXPxR9xGwy9mkLw7PU BnbyT3flqtTeHYI+AaRusvgpaNqWOszFMJ/Y+8VBwJ1B3rld5ts4CFGDEgC/zQjMKkgA F35A== X-Gm-Message-State: AOAM530cTKNts+lMwUdo8hmeWvLEy2ra4OCq4947fTiiWeLXwk1AjLB9 Kt0s54PxHYRZDL+byKlTsfu5ea06C5ZuXMN5 X-Google-Smtp-Source: ABdhPJxLe8jGSKu0J0ktGqssxESGZ0/FtCWoM187Z2JWfNmU2rbUyNN90qeqT0j2OivoUNbYFIbKCg== X-Received: by 2002:a17:906:bc91:: with SMTP id lv17mr13827522ejb.249.1603038068686; Sun, 18 Oct 2020 09:21:08 -0700 (PDT) Received: from p200300eb8f1e2a8dd0f8825fc3117f11.dip0.t-ipconnect.de (p200300eb8f1e2a8dd0f8825fc3117f11.dip0.t-ipconnect.de. [2003:eb:8f1e:2a8d:d0f8:825f:c311:7f11]) by smtp.gmail.com with ESMTPSA id y12sm7507056ede.82.2020.10.18.09.21.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2020 09:21:08 -0700 (PDT) From: Torsten Lodderstedt Content-Type: multipart/alternative; boundary="Apple-Mail=_1A23B03D-50D7-4706-AF27-9A344D437085" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: References: <160303787499.11535.7383487086065947464@ietfa.amsl.com> To: OAuth WG Date: Sun, 18 Oct 2020 18:21:07 +0200 X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-rar-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 16:21:18 -0000 --Apple-Mail=_1A23B03D-50D7-4706-AF27-9A344D437085 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 I just published a new revision of draft-ietf-oauth-rar. This revision = focuses on clarifications regarding the processing of RAR-based = requests.=20 Here is the list of changes: =E2=80=A2 Added section about enrichment of authorization = details objects by the AS =E2=80=A2 Clarified processing of unknown authorization details = parameters =E2=80=A2 clarified dependencies between resource and = authorization_details parameters =E2=80=A2 Updated references to current revisions or RFC numbers best regards, Torsten.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-oauth-rar-03.txt > Date: 18. October 2020 at 18:17:55 CEST > To: "Brian Campbell" , "Torsten = Lodderstedt" , "Justin Richer" = >=20 >=20 > A new version of I-D, draft-ietf-oauth-rar-03.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-ietf-oauth-rar > Revision: 03 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2020-10-18 > Group: oauth > Pages: 35 > URL: = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ > Html: = https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.html > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-rar-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-rar-03 >=20 > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_1A23B03D-50D7-4706-AF27-9A344D437085 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all, 

    I just = published a new revision of draft-ietf-oauth-rar. This revision = focuses on clarifications regarding the processing of RAR-based = requests. 

    Here is the list of changes:

    =E2=80=A2 = Added section about enrichment of authorization details objects by the = AS
    =E2=80=A2 Clarified processing of = unknown authorization details parameters
    = =E2=80=A2 clarified dependencies = between resource and authorization_details parameters<= /div>
    =E2=80=A2 Updated references to current revisions or = RFC numbers

    best= regards,
    Torsten. 

    Begin = forwarded message:

    From: = internet-drafts@ietf.org
    Subject: = New Version = Notification for draft-ietf-oauth-rar-03.txt
    Date: = 18. October 2020 at 18:17:55 = CEST
    To: = "Brian Campbell" <bcampbell@pingidentity.com>, "Torsten Lodderstedt" = <torsten@lodderstedt.net>, "Justin Richer" <ietf@justin.richer.org>


    A new version = of I-D, draft-ietf-oauth-rar-03.txt
    has been successfully = submitted by Torsten Lodderstedt and posted to the
    IETF = repository.

    Name: = draft-ietf-oauth-rar
    Revision: 03
    Title:= = OAuth 2.0 Rich Authorization Requests
    Document = date: = 2020-10-18
    Group: oauth
    Pages: 35
    URL: =            https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.txt=
    Status: =         https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
    Html: =           https://www.ietf.org/archive/id/draft-ietf-oauth-rar-03.html
    Htmlized:           https://tools.ietf.org/html/draft-ietf-oauth-rar-03
    Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-rar-03=

    Abstract:
      This = document specifies a new parameter "authorization_details" that
      is used to carry fine grained authorization data = in the OAuth
      authorization request.




    Please note that it may take a couple of minutes from the = time of submission
    until the htmlized version and diff are = available at tools.ietf.org.

    The IETF = Secretariat



    = --Apple-Mail=_1A23B03D-50D7-4706-AF27-9A344D437085-- From nobody Mon Oct 19 16:10:26 2020 Return-Path: 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 736883A1124 for ; Mon, 19 Oct 2020 16:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[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_IMAGE_ONLY_12=1.629, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 BpAsA5mjZUKF for ; Mon, 19 Oct 2020 16:10:23 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 2968C3A1121 for ; Mon, 19 Oct 2020 16:10:23 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id r127so2024105lff.12 for ; Mon, 19 Oct 2020 16:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=xMKLwARkbkOHsRFP4y9Pf/HhfyGLS0evsoYUM/E/pOw=; b=tx23gfSMr86iT30MN+CQxg7iC3NGl81SIOHdXKKR43tWPdPJ6DpLUXWDdeqd4xZz5v lMXK9yj1p0wl/0lyK9LwwncDwrTDn6MejMZQDYjbJGVVgqSQS5sqLLccYtij6Kq12st+ KTRqXGwT1EnyIm/0pQHFDBCYoQ9/R4VCGDQXzG73B5DPVrz+xQvhbA0LZcELGI+lYPlC +j0BJ6qOD/wvEHEw/A1qt3Zd1C11ArxvttlLGZJKO1fHnkjJq84CfXDoNTJp8t1ul+4S s4oESLxCGT4LxpkxwD9td938faGL54f9SKLNZzOyIOf64VN9agDNOvXX2MpvD1fjTmNF Fc0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=xMKLwARkbkOHsRFP4y9Pf/HhfyGLS0evsoYUM/E/pOw=; b=Ff66dXAx6M9UPdiULNiSYT/atPwhBUERmHANWtaOAIlT7+ckmSWerIq+tze/BtI5il Q1HeefRyWgnFXCNTlQe0RK4qDTDEpuij0o+d86VdZQrlLF8DjMlsNWdw1sA76t9FxwUV NZ6TFRIUmi0kH5gJxloEOYVb/7Lz2cayoacPW537N7vMA8cnQytYKnD8nEbjbvdjNMBn rhH+zccjU3gF2+RB+6P6wF5dEkN0vkd85E4Zt2xU6EPXqUcEeklcWjVh3/ubplzdA7MK gGnFS6+4ZuwLq7FVq4XXqchqneysoZLvzGRg/qgD/er1xsCoawgFbvUody9eJtEE911a 2tVw== X-Gm-Message-State: AOAM5337xajR9UkDmLCaJAk/Rqxy4W1s3oqS/tIK3FLxclmT5N7uUg6m wzB35EYX7HZN0kdBoXrkznPYHPyOjr51nByl8do= X-Google-Smtp-Source: ABdhPJx21+Z9CC2yculuoLji0OjHybaTTbMGUDgOCZ7uU+M8/IYFZqlExFNVzUgCKU7cX0Vnholc0nVRNd6ONvsNr/k= X-Received: by 2002:a19:c70f:: with SMTP id x15mr616689lff.296.1603149021161; Mon, 19 Oct 2020 16:10:21 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 19 Oct 2020 16:09:45 -0700 Message-ID: To: Vittorio Bertocci Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000edcd3705b20e375f" Archived-At: Subject: [OAUTH-WG] Android App Links (AKA Universal Links) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 23:10:24 -0000 --000000000000edcd3705b20e375f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Vittorio (cc'ing OAuth list as this was brought up in the office hours today) https://developer.android.com/training/app-links An app is the default handler and the developer has verified ownership of the HTTPS URL. While a user can override the app being the default handler in the system settings -- I don't see how a malicious app can be the default setting. What am I missing? /Dick =E1=90=A7 --000000000000edcd3705b20e375f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey Vittorio

    (cc'ing OAuth list as = this was brought up in the office hours today)


    An app is = the default handler and the developer has verified ownership of the HTTPS U= RL. While a user can override the app being the default handler in the syst= em settings -- I don't see how a malicious app can be the default setti= ng.

    What am I missing?

    /D= ick
    =E1=90=A7
    --000000000000edcd3705b20e375f-- From nobody Tue Oct 20 08:43:08 2020 Return-Path: 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 1B0EB3A111B for ; Tue, 20 Oct 2020 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=microsoft.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 MYqkyYq5epqx for ; Tue, 20 Oct 2020 08:43:06 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650137.outbound.protection.outlook.com [40.107.65.137]) (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 15DD93A0B63 for ; Tue, 20 Oct 2020 08:43:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bhOFzHvDKm90yZslvf+kuJFIR3oNg9d02Ap4aS1SW2tDU/gre48Bk3erWgM9wMiHnqUTnuiafikjs4wScY/g5TFOBaglhXBF8xLIpCv+r4KfBoLdn9lvPUyImJjqnI7l+/XZoaBaVcFGoK+wmcNfGQczhLQWDsF5rUgiroBF4h8kyVD9RCBoymDkWaWDWN5byp7GRkPy9b5aSA40wDPqMeVnVV68lFI7QqdnyWLCVgteabFBGTxNsR3UK+GSRx3TP6e7eUCnMeX9FTTpo6NqrRWT+PrqnB/KE35rHiw9uHQRV/UWLBwwZa7dPIvJEos+OTccpbp92V/OaJKvUafE5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fkrI4KMKhXIRw2WV7Ye/OZX3qVE48pgFXTf4WKgZmks=; b=el3u9qqEpcxf219b/wwrTXXXcn2dtaWbu0P+93vJ8V2t+lPCAoLEkFmdOYj2/eRaIpOYu3FYWJRMIAxD9rnAbGCODy/OgSROIWhNZse1RVyk7OvVnPuT/D6IAl4iG5Buuywm9vxERcCeQG3WeFKXegcZKjbgZyIwIgCo/9bjxdLzsCGxS8ShGn6cze8UfuPnW2oLXWFwYNJ28SBKL/MaCCEMfpplzqG8h93goYz7bL3WXMBOGd32Ue3TsX/+o+9EmNDlfRMpB4sXNBXiNLDd1cUlJe3vulSsEQXqXPtAIkqqE3/YyJf2R4kWL1dYWMP0An8YxjR/a9bLyKruVUdoyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fkrI4KMKhXIRw2WV7Ye/OZX3qVE48pgFXTf4WKgZmks=; b=UXy4pbvZHmEE1dbtwmlRRuwxLHu+ZWjZ0KXldb9h3gNWHzLt3nrO/zimFK7nIGerkNgQX/QXmo4lDtowoOKnu1ckmymTLjTXaTONa3KtP4XTwF02EjPkkjwqAHjZ84Cm8GP+ROTVDFECGbvQ8eVYE2YWKyfIIFcBRIg5wziNBEE= Received: from (2603:10b6:610:a9::23) by CH2PR00MB0727.namprd00.prod.outlook.com (2603:10b6:610:ad::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3531.0; Tue, 20 Oct 2020 15:42:59 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::c166:6acb:e760:291b]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::c166:6acb:e760:291b%4]) with mapi id 15.20.3533.000; Tue, 20 Oct 2020 15:42:59 +0000 From: Mike Jones To: Hannes Tschofenig , John Bradley , "nat@nat.consulting" CC: "oauth@ietf.org" Thread-Topic: JWT Secured Authorization Request (JAR): IPR Confirmation Thread-Index: AdaQTDJ082InKWCbSFmnHjj1u5M0TgWq2tkA Date: Tue, 20 Oct 2020 15:42:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=fd26ab91-f05e-4b32-9140-762d7a214c56; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-20T15:42:28Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.94.142] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 630ecf74-ec6c-439a-60f6-08d8750ed2cb x-ms-traffictypediagnostic: CH2PR00MB0727: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y9sCRKAUohTRn/PLjc2Kb9g5QOe07L2dSuIA9UPPX9d9TJwz0rS2zgOwuVlCjvYOQuQ6P6TM+C+s1MDLBMPgxAQfBubzkXnQcJvFO40IfOvKNvld+7XHytcB5Fj2dk9uCSDjWybVCJyFZ2Em+EgLZdtk7eQHwol2xBLj/MW3AU4SnYr7UwCy6zpOrgkapTELpnRq7wYkU5aqMUGQPQ9JDORFVScYS0O2/EoKUEYN3vf5acylxqWGs/4szTd0pjk+jy7Zpx98l03YjpY7dOa26r5WVO3pu7dYSh9OikputtzZyz4LwEak/ny2H9GvhYGv4aLcILLDdk8EEpO0CC2uMZc1WicWYwAUSNltpBDrWfm4hllz+bwNhtLBXbG2+ofOuS3fY+oKGHAnLd1aqJqtTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(316002)(71200400001)(4326008)(52536014)(110136005)(66446008)(33656002)(66556008)(186003)(53546011)(6506007)(8936002)(64756008)(83380400001)(478600001)(66946007)(26005)(66476007)(10290500003)(76116006)(7696005)(966005)(8990500004)(8676002)(86362001)(5660300002)(55016002)(2906002)(82960400001)(82950400001)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: BbMlzqS3ib2CLRhEpXNEkYK93f/CIlo2dwmW4ik3auhn0+EH6Hz78+v/t4DZeT48El0CZ2Cnq+SAcQ7XRfV4DcJPjSGPP5pO+TaDShXROyvJffnt9hPekLNTFZXXrrfkIU0aQAeYYbAXq9OKB5l4VGjUK4c5nRbid2yJtzQBJ+sK2/57pnOO8OogvChusSP3ckQkhWffE2BstnG7UCOOqq4Vpdpj38sMdKS7mhvE526t2+2mRXO3xzjEU0c7snccl/LbQEh5eLSAUpyhZZ9xKw/EfdcsVr/Hxz1NB9QEhaV5PGsW2S8E7kdML8PqifjVE1VnGPTI2jqkYux0j07qrFVCgBcZ93dImgtuChMPK1Y6QBKywdONyydlqFtFIBvQTbTl8c4npTh9HvjG05SuGMGiMeURUrHK0wi+vmHmll1xETH3FYtFJwYmW4WGGjsbtSU2ODffyXcecnTWSqbFLVBdeOFXnfS6KItBQFObDqghT5sXKqTa0HumVKw+6MMEIkeZAHg6EV4renZtt/FOH+UVOCftpju1YXeZxXcgQlAOcuFQXM8M0wKmZw/UjuJELMeoR2bYPmJHAjfE3E6sPqgIpSg6AmWO8pkFibt9WlA3oMtQSRZEd/DyupVmQeb55VEK4nKXYMbDFm6eAxzs2Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 630ecf74-ec6c-439a-60f6-08d8750ed2cb X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 15:42:59.8943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tQ4m91vGXOcYzsj/X2A5SImMJbTRUPJi/M+b1Si/3iRR+YF2aLUiuxkrURNbh43p11TeKPv9CWVeYQrgE93mUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0727 Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 15:43:07 -0000 I'm not aware of any IPR that pertains to this specification. -- Mike -----Original Message----- From: Hannes Tschofenig =20 Sent: Monday, September 21, 2020 12:22 PM To: John Bradley ; nat@nat.consulting; Mike Jones Cc: oauth@ietf.org Subject: JWT Secured Authorization Request (JAR): IPR Confirmation Hi Mike, Nat, John, I am updating the shepherd writeup for the "The OAuth 2.0 Authorization Fra= mework: JWT Secured Authorization Request (JAR)" specification, see https:/= /tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt, and given the changes I = need your IPR confirmation again. (Mike joined as co-author later and hence= I need his confirmation anyway.) One item in the template requires me to indicate whether each document auth= or has confirmed that any and all appropriate IPR disclosures required for = full conformance with the provisions of BCP 78 and BCP 79 have already been= filed. Could you please confirm? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue Oct 20 09:09:36 2020 Return-Path: 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 4993A3A07D7 for ; Tue, 20 Oct 2020 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uokIozEeItX6 for ; Tue, 20 Oct 2020 09:09:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1B73A07C4 for ; Tue, 20 Oct 2020 09:09:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C4CE2F40726; Tue, 20 Oct 2020 09:09:29 -0700 (PDT) To: mbj@microsoft.com, phil.hunt@yahoo.com, tonynad@microsoft.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: david.brossard@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201020160929.C4CE2F40726@rfc-editor.org> Date: Tue, 20 Oct 2020 09:09:29 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:09:35 -0000 The following errata report has been submitted for RFC8176, "Authentication Method Reference Values". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6314 -------------------------------------- Type: Editorial Reported by: David Brossaard Section: 1. Original Text ------------- For context, the "amr" (Authentication Methods References) claim is defined by Section 2 of the OpenID Connect Core 1.0 specification [OpenID.Core] as follows: Corrected Text -------------- For context, the "amr" (Authentication Methods References) claim is defined by Section 2 of the OpenID Connect Core 1.0 specification [OpenID.Core] as follows: Notes ----- There is no text change but the link on "Section 2" points to section 2 in the same RFC rather than section 2 in the OpenID Connect Core 1.0 specification. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8176 (draft-ietf-oauth-amr-values-08) -------------------------------------- Title : Authentication Method Reference Values Publication Date : June 2017 Author(s) : M. Jones, P. Hunt, A. Nadalin Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Oct 20 09:21:56 2020 Return-Path: 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 BB1833A117D; Tue, 20 Oct 2020 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 27GlC9JApLKM; Tue, 20 Oct 2020 09:21:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED943A116F; Tue, 20 Oct 2020 09:21:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A4FCF40719; Tue, 20 Oct 2020 09:21:45 -0700 (PDT) To: david.brossard@gmail.com, mbj@microsoft.com, phil.hunt@yahoo.com, tonynad@microsoft.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201020162145.1A4FCF40719@rfc-editor.org> Date: Tue, 20 Oct 2020 09:21:45 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Errata Rejected] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:21:50 -0000 The following errata report has been rejected for RFC8176, "Authentication Method Reference Values". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6314 -------------------------------------- Status: Rejected Type: Editorial Reported by: David Brossaard Date Reported: 2020-10-20 Rejected by: Benjamin Kaduk (IESG) Section: 1. Original Text ------------- For context, the "amr" (Authentication Methods References) claim is defined by Section 2 of the OpenID Connect Core 1.0 specification [OpenID.Core] as follows: Corrected Text -------------- For context, the "amr" (Authentication Methods References) claim is defined by Section 2 of the OpenID Connect Core 1.0 specification [OpenID.Core] as follows: Notes ----- There is no text change but the link on "Section 2" points to section 2 in the same RFC rather than section 2 in the OpenID Connect Core 1.0 specification. --VERIFIER NOTES-- Errata reports are for reporting issues with the authoritative RFC version(s) as published by the RFC Editor. RFC 8176 predates the usage of the "v3 XML" format, so the plain text version is the authoritative one, and thus questions of HTML links are irrelevant for it. -------------------------------------- RFC8176 (draft-ietf-oauth-amr-values-08) -------------------------------------- Title : Authentication Method Reference Values Publication Date : June 2017 Author(s) : M. Jones, P. Hunt, A. Nadalin Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Oct 20 09:24:27 2020 Return-Path: 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 2F1303A1186 for ; Tue, 20 Oct 2020 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 oUCWZPnrGFCV for ; Tue, 20 Oct 2020 09:24:25 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E051D3A1183 for ; Tue, 20 Oct 2020 09:24:24 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09KGOHfl014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2020 12:24:21 -0400 Date: Tue, 20 Oct 2020 09:24:16 -0700 From: Benjamin Kaduk To: david.brossard@gmail.com Cc: mbj@microsoft.com, phil.hunt@yahoo.com, tonynad@microsoft.com, oauth@ietf.org Message-ID: <20201020162416.GI39170@kduck.mit.edu> References: <20201020162145.1A4FCF40719@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201020162145.1A4FCF40719@rfc-editor.org> Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:24:26 -0000 On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: > --VERIFIER NOTES-- > Errata reports are for reporting issues with the authoritative RFC version(s) as published by the RFC Editor. RFC 8176 predates the usage of the "v3 XML" format, so the plain text version is the authoritative one, and thus questions of HTML links are irrelevant for it. For what it's worth, this "bad HTML link" situation occurs with some regularity -- the "html" versions of non-v3-XML RFCs are created by running a script over the text version. The script uses heuristics to convert certain types of text into links, and "Section " gets expanded to this document unless followed by "of RFC ". I believe this script is open-source and patches would be welcome, though I don't know the location of the source-code repository in question off the top of my head. -Ben From nobody Tue Oct 20 09:26:35 2020 Return-Path: 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 ABF3E3A118E for ; Tue, 20 Oct 2020 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=salesforce.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 b1CFi8gvcea5 for ; Tue, 20 Oct 2020 09:26:33 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 EE4F83A1189 for ; Tue, 20 Oct 2020 09:26:32 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id h4so1232134pjk.0 for ; Tue, 20 Oct 2020 09:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y47pYmIscovTxz6s0lXCfmnSXPYEolW3/26s43cc/TY=; b=FxR/0sk2izIM+UElRSxbSBd6OIDUc4m4mneIzlJSIEgJ+lpIJ5vN+BLmQZL631DJcb hoQeRd5+GYKiWTgr47yH5bcieGprjdzptTrp8wMPE+z0m+08Rn39hT1XQ5IoIHQC/VXh c0kl+RPKbHxh3IdKk3vrUyREnhc00YLoybaqQ= 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=Y47pYmIscovTxz6s0lXCfmnSXPYEolW3/26s43cc/TY=; b=Ym3kYxQMCGSMrm9wKNippHVxqLYYGOHblt4S7mB9rsor6pzSIS9fTf3DWr5EgPs50e Su+njyL/hZVFrz8qjav5ulg0ZYjHIqhoD+TF7vWlrYwzdolymsI6ZG36EzZpFM4S09CI mT7l/FwGTBdnDgoHHqQfnAzA/IC73zwbTOaKV0dGuygUZNQuskZ6L7/bJCy/BKpulSiq t1/RW7JuQTIeH2RWaFxO0gEuwM3afItmW9BwIZnH9Wy9eQvj2BLk+ZyfucyVjApZJQQK u/Wz0QoL5lmhZ9NXeSQuKbPpMDpKcM5ADEqI3es+T+UtxB1YEKzmI17lHmx//VkqYlKh lbPA== X-Gm-Message-State: AOAM531Nq/wVcxIecA2Qktp6gx3GvaRMzH3gZ8NAtUIKsfKN/Lb3PHvT vhET0QHzsgYJ8EQON0f15YYorxPDLZ4reN2Thw7E7A== X-Google-Smtp-Source: ABdhPJx7Mrs4kAhBiBGlSRfMbCCcRjBGO/6Swclmy0ivvj5Fu5rC05qvkqBR1x+oisUn/4I+yu7FjGhxWaDKF7mW25s= X-Received: by 2002:a17:902:8a8a:b029:d5:aba7:5abb with SMTP id p10-20020a1709028a8ab02900d5aba75abbmr3737635plo.50.1603211192104; Tue, 20 Oct 2020 09:26:32 -0700 (PDT) MIME-Version: 1.0 References: <20201020162145.1A4FCF40719@rfc-editor.org> <20201020162416.GI39170@kduck.mit.edu> In-Reply-To: <20201020162416.GI39170@kduck.mit.edu> From: David Brossard Date: Tue, 20 Oct 2020 09:26:21 -0700 Message-ID: To: Benjamin Kaduk Cc: David Brossard , mbj@microsoft.com, phil.hunt@yahoo.com, oauth@ietf.org, tonynad@microsoft.com Content-Type: multipart/alternative; boundary="0000000000009b0fcf05b21cb129" Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:26:35 -0000 --0000000000009b0fcf05b21cb129 Content-Type: text/plain; charset="UTF-8" Thanks Ben (and apologies about the double submission). In this case, given the reference is not an RFC, that would explain why the script failed. Can we do a manual fix after the script has run to update the RFC? On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk wrote: > On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: > > --VERIFIER NOTES-- > > Errata reports are for reporting issues with the authoritative RFC > version(s) as published by the RFC Editor. RFC 8176 predates the usage of > the "v3 XML" format, so the plain text version is the authoritative one, > and thus questions of HTML links are irrelevant for it. > > For what it's worth, this "bad HTML link" situation occurs with some > regularity -- the "html" versions of non-v3-XML RFCs are created by running > a script over the text version. The script uses heuristics to convert > certain types of text into links, and "Section " gets expanded to this > document unless followed by "of RFC ". I believe this script is > open-source and patches would be welcome, though I don't know the location > of the source-code repository in question off the top of my head. > > -Ben > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- *David Brossard* Sr. Director of Product Management Identity, Authentication, Federation, and Single Sign-On | Salesforce c: +1 502-922-6538 (US) | +1 236-333-6379 (Canada) Learn more about identity here | Identity for Developers --0000000000009b0fcf05b21cb129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Ben (and apologies about the double submission).
    In this case, given the reference is not an RFC, that woul= d explain why the script failed. Can we do a manual fix after the script ha= s run to update the RFC?

    On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kadu= k <kaduk@mit.edu> wrote:
    On Tue, Oct 20, 2020 at= 09:21:45AM -0700, RFC Errata System wrote:
    >=C2=A0 --VERIFIER NOTES--
    > Errata reports are for reporting issues with the authoritative RFC ver= sion(s) as published by the RFC Editor.=C2=A0 RFC 8176 predates the usage o= f the "v3 XML" format, so the plain text version is the authorita= tive one, and thus questions of HTML links are irrelevant for it.

    For what it's worth, this "bad HTML link" situation occurs wi= th some
    regularity -- the "html" versions of non-v3-XML RFCs are created = by running
    a script over the text version.=C2=A0 The script uses heuristics to convert=
    certain types of text into links, and "Section <N>" gets ex= panded to this
    document unless followed by "of RFC <Y>".=C2=A0 I believe t= his script is
    open-source and patches would be welcome, though I don't know the locat= ion
    of the source-code repository in question off the top of my head.

    -Ben

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    David Brossard
    Sr. Director of Product Management
    Identity, Authentication, Federation, and = Single Sign-On |=C2=A0Salesforce=C2=A0
    c: +1 502-922-6538 (US) | = +1 236-333-6379 (Canada)
    --0000000000009b0fcf05b21cb129-- From nobody Tue Oct 20 09:31:57 2020 Return-Path: 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 0544E3A0ADF for ; Tue, 20 Oct 2020 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 43wToi4I57ZU for ; Tue, 20 Oct 2020 09:31:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7610C3A0AC5 for ; Tue, 20 Oct 2020 09:31:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09KGVjPQ017589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2020 12:31:50 -0400 Date: Tue, 20 Oct 2020 09:31:45 -0700 From: Benjamin Kaduk To: David Brossard Cc: David Brossard , mbj@microsoft.com, phil.hunt@yahoo.com, oauth@ietf.org, tonynad@microsoft.com, rfc-editor@rfc-editor.org Message-ID: <20201020163145.GK39170@kduck.mit.edu> References: <20201020162145.1A4FCF40719@rfc-editor.org> <20201020162416.GI39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:31:55 -0000 [adding back rfc-editor@rfc-editor.org] Hi David, I am quite far removed from the actual operation of the script and the rfc-editor.org website, so I don't know the answer to your question. That said, my understanding is that it's set up with automation that assumes the script is idempotent, and can regenerate various bits from scratch in certain cases, so a manual edit might not be very reliable. -Ben On Tue, Oct 20, 2020 at 09:26:21AM -0700, David Brossard wrote: > Thanks Ben (and apologies about the double submission). > > In this case, given the reference is not an RFC, that would explain why the > script failed. Can we do a manual fix after the script has run to update > the RFC? > > On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk wrote: > > > On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: > > > --VERIFIER NOTES-- > > > Errata reports are for reporting issues with the authoritative RFC > > version(s) as published by the RFC Editor. RFC 8176 predates the usage of > > the "v3 XML" format, so the plain text version is the authoritative one, > > and thus questions of HTML links are irrelevant for it. > > > > For what it's worth, this "bad HTML link" situation occurs with some > > regularity -- the "html" versions of non-v3-XML RFCs are created by running > > a script over the text version. The script uses heuristics to convert > > certain types of text into links, and "Section " gets expanded to this > > document unless followed by "of RFC ". I believe this script is > > open-source and patches would be welcome, though I don't know the location > > of the source-code repository in question off the top of my head. > > > > -Ben > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > *David Brossard* > Sr. Director of Product Management > Identity, Authentication, Federation, and Single Sign-On | Salesforce > c: +1 502-922-6538 (US) | +1 236-333-6379 (Canada) > Learn more about identity here > > | > Identity for Developers > From nobody Tue Oct 20 11:49:54 2020 Return-Path: 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 9A85E3A12DA for ; Tue, 20 Oct 2020 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 QIzNTS6oW7qV for ; Tue, 20 Oct 2020 11:49:47 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0233A12D5 for ; Tue, 20 Oct 2020 11:49:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2CE003C13B0; Tue, 20 Oct 2020 11:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T5tBRIyarBn; Tue, 20 Oct 2020 11:49:44 -0700 (PDT) Received: from [IPv6:2605:e000:1524:de:e156:b6f:66ea:442b] (unknown [IPv6:2605:e000:1524:de:e156:b6f:66ea:442b]) by c8a.amsl.com (Postfix) with ESMTPSA id AEE383C13A7; Tue, 20 Oct 2020 11:49:43 -0700 (PDT) From: Sandy Ginoza Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_91CC5DF4-CC18-41A3-ADAC-9F60C248F514" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 20 Oct 2020 11:49:47 -0700 In-Reply-To: <20201020163145.GK39170@kduck.mit.edu> Cc: David Brossard , tonynad@microsoft.com, phil.hunt@yahoo.com, mbj@microsoft.com, David Brossard , oauth@ietf.org, RFC Editor To: Benjamin Kaduk References: <20201020162145.1A4FCF40719@rfc-editor.org> <20201020162416.GI39170@kduck.mit.edu> <20201020163145.GK39170@kduck.mit.edu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 18:49:54 -0000 --Apple-Mail=_91CC5DF4-CC18-41A3-ADAC-9F60C248F514 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, The HTML file (available from https://www.rfc-editor.org/rfc/rfc8176 = ) was generated using rfc2html = (https://www.pypi.org/project/rfc2html = ). Please feel free to direct = questions to the maintainers listed on that page. Thanks, RFC Editor/sg > On Oct 20, 2020, at 9:31 AM, Benjamin Kaduk wrote: >=20 > [adding back rfc-editor@rfc-editor.org] >=20 > Hi David, >=20 > I am quite far removed from the actual operation of the script and the > rfc-editor.org website, so I don't know the answer to your question. = That > said, my understanding is that it's set up with automation that = assumes the > script is idempotent, and can regenerate various bits from scratch in > certain cases, so a manual edit might not be very reliable. >=20 > -Ben >=20 > On Tue, Oct 20, 2020 at 09:26:21AM -0700, David Brossard wrote: >> Thanks Ben (and apologies about the double submission). >>=20 >> In this case, given the reference is not an RFC, that would explain = why the >> script failed. Can we do a manual fix after the script has run to = update >> the RFC? >>=20 >> On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk wrote: >>=20 >>> On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: >>>> --VERIFIER NOTES-- >>>> Errata reports are for reporting issues with the authoritative RFC >>> version(s) as published by the RFC Editor. RFC 8176 predates the = usage of >>> the "v3 XML" format, so the plain text version is the authoritative = one, >>> and thus questions of HTML links are irrelevant for it. >>>=20 >>> For what it's worth, this "bad HTML link" situation occurs with some >>> regularity -- the "html" versions of non-v3-XML RFCs are created by = running >>> a script over the text version. The script uses heuristics to = convert >>> certain types of text into links, and "Section " gets expanded to = this >>> document unless followed by "of RFC ". I believe this script is >>> open-source and patches would be welcome, though I don't know the = location >>> of the source-code repository in question off the top of my head. >>>=20 >>> -Ben >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >> --=20 >> *David Brossard* >> Sr. Director of Product Management >> Identity, Authentication, Federation, and Single Sign-On | Salesforce >> c: +1 502-922-6538 (US) | +1 236-333-6379 (Canada) >> Learn more about identity here >> = >> | >> Identity for Developers >> >=20 --Apple-Mail=_91CC5DF4-CC18-41A3-ADAC-9F60C248F514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    Hi all,

    The HTML file (available from https://www.rfc-editor.org/rfc/rfc8176) was generated = using rfc2html (https://www.pypi.org/project/rfc2html). Please feel free = to direct questions to the maintainers listed on that page.

    Thanks,
    RFC Editor/sg


    On = Oct 20, 2020, at 9:31 AM, Benjamin Kaduk <kaduk@MIT.EDU> = wrote:

    [adding back rfc-editor@rfc-editor.org]

    Hi = David,

    I am quite far removed from the = actual operation of the script and the
    rfc-editor.org website, so = I don't know the answer to your question.  That
    said, = my understanding is that it's set up with automation that assumes the
    script is idempotent, and can regenerate various bits from = scratch in
    certain cases, so a manual edit might not be = very reliable.

    -Ben

    On Tue, Oct 20, 2020 at 09:26:21AM -0700, David Brossard = wrote:
    Thanks Ben = (and apologies about the double submission).

    In this case, given the reference is not an RFC, that would = explain why the
    script failed. Can we do a manual fix = after the script has run to update
    the RFC?

    On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk = <kaduk@mit.edu> = wrote:

    On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System = wrote:
    --VERIFIER = NOTES--
    Errata reports are for reporting issues with the = authoritative RFC
    version(s) as published by = the RFC Editor.  RFC 8176 predates the usage of
    the = "v3 XML" format, so the plain text version is the authoritative one,
    and thus questions of HTML links are irrelevant for it.

    For what it's worth, this "bad HTML link" = situation occurs with some
    regularity -- the "html" = versions of non-v3-XML RFCs are created by running
    a = script over the text version.  The script uses heuristics to = convert
    certain types of text into links, and "Section = <N>" gets expanded to this
    document unless followed = by "of RFC <Y>".  I believe this script is
    open-source and patches would be welcome, though I don't know = the location
    of the source-code repository in question off = the top of my head.

    -Ben

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth



    --
    *David Brossard*
    Sr. Director of Product = Management
    Identity, Authentication, Federation, and = Single Sign-On | Salesforce
    c: +1 502-922-6538 (US) | +1 = 236-333-6379 (Canada)
    Learn more about identity here
    <https://trailhead.salesforce.com/content/learn/modules/identity= _basics/identity_basics_product>
    |
    Identity for Developers
    <https://developer.salesforce.com/developer-centers/identity/>


    = --Apple-Mail=_91CC5DF4-CC18-41A3-ADAC-9F60C248F514-- From nobody Wed Oct 21 05:24:41 2020 Return-Path: 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 F386C3A0AD6 for ; Wed, 21 Oct 2020 05:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.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 jRNPtbdhd820 for ; Wed, 21 Oct 2020 05:24:37 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 305433A0AD4 for ; Wed, 21 Oct 2020 05:24:37 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id c77so1932815wmd.4 for ; Wed, 21 Oct 2020 05:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+op9Yt3gjHtsB+UpZq6TVYTne4XhaxvOlG7o2KLFJZk=; b=H31CZqQMMtNUGoHWUo1zkYCTTBxPAGXxKvHTeDQkv9UaawfCQUg+mcjVZ2SetJZeuS nz0Fkj5ZIDqeIosZ4jpsvxDH0xEe8hgS1en1ujfmaL3SDiAtvtn0GX6Ufy1m5D2I9EOx Y7QSspwywEgPdIhkpvRFU5PT/Yzf9C74clE78XnFtMtjCDdGRk372Q1vq6I1ksEMSgCd iVQuJ4qBCvRRJU1DTmvaQ6UEtOIOPLhYhnkqgsF6nyuzLc7QZcrY4XAr30YebH0Hm2lR VfZf6/ei9XhoSe3DyQJJ1lU5seEF8bWuY5gupatGPTOCL02f4F+tnoAaTjkEbuG1kbns aAtw== 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; bh=+op9Yt3gjHtsB+UpZq6TVYTne4XhaxvOlG7o2KLFJZk=; b=gqudKnBSTWzBlSoOVka5CR0v4GHXY1w9dcThJO2DNO74k9qLOdR8f6sEse2NS7i/tP t7GggiNtWIE/UWfewc6dHugyeXtpGEBUuRP+nSdNrIGTaKBM7U6gPBLT0HhcT0AzrhNI i0HA85Xt00JNWIzV3mEsP+ykMRB9h23bxM53sngm+mp8tSSm0kZ5I9nYu09s1hkZHgEy V8k70rv0yQudWJw8i0B4B9bIVMWP91m+efytpi5Q94HgK+S1J3gdUvyxDyYuNktMD6Xp 1rcVWx0XZoR2a0qLZaSwJ5O8qQhY2/TFSgoPik8sYTEIv0BrjUhC1Ua21JXQf95/czT7 rJTQ== X-Gm-Message-State: AOAM5326Nzm6oY3a4RmRAOopfJWca5j3ixK3ogWQpSIo7AkozLp6zoC3 vZsV/8eWOWvZJ4J8xpYA4YBZSQHpGLgsrXncZCiS0tuYywxhvqra X-Google-Smtp-Source: ABdhPJzmSkjtsLVbxNy2GBjkQ/BoR2dYIfz5jqcAfbZUBb3PhMNZmWpmfbizZv47kzP+7Yx4zwQ5/cEnV3Wrn85V73E= X-Received: by 2002:a1c:2b05:: with SMTP id r5mr3296560wmr.179.1603283074837; Wed, 21 Oct 2020 05:24:34 -0700 (PDT) MIME-Version: 1.0 References: <2cd8bfd1-f491-0086-979f-0527ccf16281@connect2id.com> In-Reply-To: From: Takahiko Kawasaki Date: Wed, 21 Oct 2020 21:24:46 +0900 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000002682cc05b22d6e20" Archived-At: Subject: Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 12:24:40 -0000 --0000000000002682cc05b22d6e20 Content-Type: text/plain; charset="UTF-8" "there seems to be a good consensus that servers must not require the duplicates." from FAPI Issue 315: PAR certification question - must servers allow requests where scope/response_type only passed to PAR endpoint https://bitbucket.org/openid/fapi/issues/315/par-certification-question-must-servers A consensus has been reached which is enough at least for the conformance suite. It is the same as my suggestion. Thank you for discussion. Taka On Wed, Sep 30, 2020 at 2:21 PM Takahiko Kawasaki wrote: > So, my suggestion is "When JAR compatible behaviors are employed, AS > implementations should not require that an OIDC request come with `scope` > query/form parameter when the request uses a request object." (NOTE: "an > OIDC request" implies that the request object contains `scope` including > `openid`.) > > Any thoughts? > > Taka > > On Thu, Sep 24, 2020 at 11:07 PM Takahiko Kawasaki > wrote: > >> Hi Vladimir, >> >> Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not >> require all request parameters be put duplicately in a request object. It >> is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2 >> >> Clause 10) that has the requirement. In the context of FAPI Part 1, a >> request object does not have to be used. One more note is that parameters >> inside a request object and parameters outside a request object are merged >> (as they are in OIDC Core 1.0) when the authorization request is being made >> for FAPI Read-Only APIs (not for FAPI Read-Write APIs). >> >> Taka >> >> >> On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov < >> vladimir@connect2id.com> wrote: >> >>> Hi Taka, >>> >>> Speaking of the OIDC Core 1.0 conformance tests, IMO those should not >>> change with the publication of JAR. >>> >>> Speaking of the FAPI 1.0 tests, those already require all request >>> parameters to be JWT-secured, which makes the requests also JAR compliant: >>> all parameters are found in the JWT, with scope (as complete scope or >>> minimally required scope=openid), response_type, client_id and redirect_uri >>> also having a copy outside the JWT, as query parameters. Thus the request >>> is OIDC as well as JAR compliant. >>> >>> If I had an RP I would always construct OIDC auth requests like that, to >>> make sure they comply with OIDC as well as the new JAR spec (and will not >>> have issues with servers which implement both specs but are not able to >>> "switch" behavior for some reason). >>> >>> Vladimir >>> On 23/09/2020 14:58, Takahiko Kawasaki wrote: >>> >>> Hi Vladimir, >>> >>> Thank you for your reply. It sounds that your opinion is "`scope` >>> request parameter must exist outside the request object even if JAR applies >>> if the authorization request is an OIDC request". I'm on the fence on this >>> topic and just wondered whether those who had wanted to remove >>> `response_type` outside the request object (although doing it was a >>> breaking change) would want to remove `scope` outside the request object >>> too with the same motivation (although I don't remember well what was the >>> motivation). JAR dares to drop `response_type`, so it would not be >>> surprising to see that JAR dares to drop `scope` (including `openid`) too. >>> >>> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the >>> parameter if the parameter is included in the request object. >>> >>> If we applied the same logic, we would be able to state: >>> >>> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows >>> omission of the parameter if the parameter is included in the request >>> object. >>> >>> In terms of `response_type`, practically speaking, JAR has modified OIDC >>> Core 1.0. Because JAR has already been allowed to go so far as that point, >>> I would say it is difficult to find a convincing reason not to allow >>> omission of `scope`. >>> >>> AFAIK, in the context of OIDC Core 1.0, parameters that are required to >>> exist outside a request object even if they are included in the request >>> object are `client_id`, `response_type` and `scope`. Because `client_id` is >>> mandatory in JAR (it has become mandatory after long discussion), >>> discussion for the parameter is not needed. Because the community has >>> already reached consensus that `response_type` can be omitted, discussion >>> for the parameter is not needed, either. What I've brought here is >>> discussion for `scope`, hopefully the last parameter that is affected by >>> JAR. >>> >>> Again, I'm on the fence on this topic. However, because logical >>> conclusion (at least of mine) is that JAR should allow omission of `scope` >>> (it also should be noted that JAR's basic rule prohibits referring to >>> request parameters outside a request object), I want to see explicit >>> consensus if `scope` (including `openid`) outside a request object is still >>> required even after JAR is enabled. >>> >>> In short, my question is "Should `scope` be omitted?" I guess that the >>> conclusion will affect the official conformance suite. >>> >>> Best Regards, >>> Takahiko Kawasaki >>> Authlete, Inc. >>> >>> >>> >>> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>> >>>> Hi Taka, >>>> On 21/09/2020 20:12, Takahiko Kawasaki wrote: >>>> >>>> If we allow JAR (JWT Secured Authorization Request) to relax the >>>> requirement of `response_type` request parameter (outside a request object) >>>> from mandatory to optional, should we relax the following requirement of >>>> `scope` request parameter stated in OIDC Core 1.0 Section 6.1, too? >>>> >>>> ---------- >>>> Even if a scope parameter is present in the Request Object value, a >>>> scope parameter MUST always be passed using the OAuth 2.0 request syntax >>>> containing the openid scope value to indicate to the underlying OAuth 2.0 >>>> logic that this is an OpenID Connect request. >>>> ---------- >>>> >>>> Otherwise, an authorization request like >>>> "client_id=...&request(_uri)=..." fails if the request object represents an >>>> OIDC request. An authorization request has to look like >>>> "client_id=...&request(_uri)=...&scope=openid" (`scope` including `openid` >>>> has to be given) even if the authorization server conforms to JAR and >>>> allows omission of `response_type` request parameter. >>>> >>>> The bottom of section 5 has normative text which allows a JAR compliant >>>> server to also comply with the OIDC spec with its own style of request / >>>> request_uri parameter handling insofar as to not reject other query params >>>> (such as scope, etc). The difference is that according to JAR their values >>>> cannot be used or merged (as in OIDC). But what can be reasonably done is >>>> to detect scope=openid as you say and then switch to OIDC style request >>>> object behavior. >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5 >>>> >>>> The client MAY send the parameters included in the request object >>>> duplicated in the query parameters as well for the backward >>>> compatibility etc. However, the authorization server supporting this >>>> specification MUST only use the parameters included in the request >>>> object. >>>> >>>> The confusion between the two specs clears when it's seen that the >>>> request objects in OIDC and JAR have different objectives. >>>> >>>> In OIDC the objective is to enable securing of selected parameters. >>>> >>>> In JAR the objective is to secure the entire authz request. >>>> >>>> >>>> >>>> I think that implementers want to know consensus on this because it >>>> affects implementations. Has this been discussed yet? >>>> >>>> Best Regards, >>>> Takahiko Kawasaki >>>> Authlete, Inc. >>>> >>>> >>>> Vladimir >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --0000000000002682cc05b22d6e20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    "there seems to be a good consensus that servers must= not require the duplicates."
    On Wed, Sep 30= , 2020 at 2:21 PM Takahiko Kawasaki <taka@authlete.com> wrote:
    So, my suggestion is &= quot;When JAR compatible behaviors are employed, AS implementations should = not require that an OIDC request come with `scope` query/form parameter whe= n the request uses a request object." (NOTE: "an OIDC request&quo= t; implies that the request object contains `scope` including `openid`.)
    Any thoughts?

    Taka

    <= div class=3D"gmail_quote">
    On Thu, Sep= 24, 2020 at 11:07 PM Takahiko Kawasaki <taka@authlete.com> wrote:
    Hi Vladimir,
    =
    Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) d= oes not require all request parameters be put duplicately in a request obje= ct. It is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2 Clause 10) that has the requirement. In the c= ontext of FAPI Part 1, a request object does not have to be used. One more = note is that parameters inside a request object and parameters outside a re= quest object are merged (as they are in OIDC Core 1.0) when the authorizati= on request is being made for FAPI Read-Only APIs (not for FAPI Read-Write A= PIs).

    Taka


    On Thu, Sep 24, 202= 0 at 7:14 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
    =20 =20 =20

    Hi Taka,

    Speaking of the OIDC Core 1.0 conformance tests, IMO those should not change with the publication of JAR.

    Speaking of the FAPI 1.0 tests, those already require all request parameters to be JWT-secured, which makes the requests also JAR compliant: all parameters are found in the JWT, with scope (as complete scope or minimally required scope=3Dopenid), response_type, client_id and redirect_uri also having a copy outside the JWT, as query parameters. Thus the request is OIDC as well as JAR compliant.

    If I had an RP I would always construct OIDC auth requests like that, to make sure they comply with OIDC as well as the new JAR spec (and will not have issues with servers which implement both specs but are not able to "switch" behavior for some reason= ).

    Vladimir

    On 23/09/2020 14:58, Takahiko Kawasaki wrote:
    =20
    Hi Vladimir,

    Thank you for your reply. It sounds that your opinion is "`scope` request parameter must exist outside the request object even if JAR applies if the authorization request is an OIDC request". I'm on the fence on this topic and just wondered whether those who had wanted to remove `response_type` outside the request object (although doing it was a breaking change) would want to remove `scope` outside the request object too with the same motivation (although I don't remember well what was the motivation). JAR dares to drop `response_type`, so it would not be surprising to see that JAR dares to drop `scope` (including `openid`) too.

    OIDC Core 1.0 requires `response_type`, but JAR allows omission of the parameter if the parameter is included in the request object.

    If we applied the same logic, we would be able to state:

    OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows omission of the parameter if the parameter is included in the request object.

    In terms of `response_type`, practically speaking, JAR has modified OIDC Core 1.0. Because JAR has already been allowed to go so far as that point, I would say it is difficult to find a convincing reason not to allow omission of `scope`.

    AFAIK, in the context of OIDC Core 1.0, parameters that are required to exist outside a request object even if they are included in the request object are `client_id`, `response_type` and `scope`. Because `client_id` is mandatory in JAR (it has become mandatory after long=C2=A0discussion), discussion for the parameter is not needed. Because the community has already reached consensus that `response_type` can be omitted, discussion for the parameter is not needed, either. What I've brought here is discussion for `scope`, hopefully the last parameter that is affected by JAR.

    Again, I'm on the fence on=C2=A0this topic. However, becau= se logical conclusion (at least of mine) is that JAR should allow omission of `scope` (it also should be noted that JAR's basic rule prohibits referring to request parameters outside a request object), I want to see explicit consensus if `scope` (including `openid`) outside a request object is still required even after JAR is enabled.

    In short, my question is "Should `scope` be omitted?"= ; I guess that the conclusion will affect the official conformance suite.

    Best Regards,
    Takahiko Kawasaki
    Authlete, Inc.



    On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

    Hi Taka,

    On 21/09/2020 20:12, Takahiko Kawasaki wrote:
    If we allow JAR (JWT Secured Authorization Request) to relax the requirement of `response_type` request parameter (outside a request object) from mandatory to optional, should we relax the following requirement of `scope` request parameter stated in OIDC Core 1.0 Section 6.1, too?

    ----------
    Even if a scope parameter is present in the Request Object value, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.
    ----------

    Otherwise, an authorization request like "client_id=3D...&request(_uri)=3D..." fails i= f the request object represents an OIDC request. An authorization request has to look like "client_id=3D...&request(_uri)=3D...&scope=3Do= penid" (`scope` including `openid` has to be given) even if the authorization server conforms to JAR and allows omission of `response_type` request parameter.

    The bottom of section 5 has normative text which allows a JAR compliant server to also comply with the OIDC spec with its own style of request / request_uri parameter handling insofar as to not reject other query params (such as scope, etc). The difference is that according to JAR their values cannot be used or merged (as in OIDC). But what can be reasonably done is to detect scope=3Dopenid as you say and then switch to OIDC style request object behavior.

    https://tools.ietf.org/html/draft-ietf-o= auth-jwsreq-30#section-5

       The client MAY send the parameters included in the re=
quest object
   duplicated in the query parameters as well for the backward
   compatibility etc.  However, the authorization server supporting this
   specification MUST only use the parameters included in the request
   object.

    The confusion between the two specs clears when it's see= n that the request objects in OIDC and JAR have different objectives.

    In OIDC the objective is to enable securing of selected parameters.

    In JAR the objective is to secure the entire authz request.



    I think that implementers want to know consensus on this because it affects implementations. Has this been discussed yet?

    Best Regards,
    Takahiko Kawasaki
    Authlete, Inc.


    Vladimir


    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000002682cc05b22d6e20-- From nobody Fri Oct 23 12:33:34 2020 Return-Path: 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 7A0DB3A096B for ; Fri, 23 Oct 2020 12:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 SlfToNUogAor for ; Fri, 23 Oct 2020 12:33:32 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 0D0743A0934 for ; Fri, 23 Oct 2020 12:33:32 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id s9so3383628wro.8 for ; Fri, 23 Oct 2020 12:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Um4s3zm2dPfXbwZ1nPjaKfOUZZhoxo+dZIh80F5QYsk=; b=Cor8L+Qa7UzSHn2Jbu9gO5ho/xLamSpWrSmc2SMio3OfxHzuftVzZcaONCJUwv0x61 Ur1jEGqN2kxFuJRgRkrVgQzQofpv0maa5YG+VkLRoJ7dOWGA/bvJ8ECJltf55khAiDsz C5MSpGf/m0z/ZYqJR1hP0druKEAr0+4C9XScl1uOlodt+gZrPpMfanffFuh1ZMfiYbaH 5l7MDVXxYsbw8qOKiJwbV5H496SLmZFhLdb6B+MLWwr8VFfEUickcWn/2x8pPQ0kYZYB 1QumsHw8gJaNG6JE4W5GN0QSmwj6PffpAObvTH+GeXXsQ4WXQwpjLNiMQQJURRGNnLpU 9VVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Um4s3zm2dPfXbwZ1nPjaKfOUZZhoxo+dZIh80F5QYsk=; b=baSoitpP1UGXlWS0xDDFsdnLZz5FUW+ee6bU5YKMjrRwEEF0+9z7eqI7RqnA8Yn8UA s+2DTkM/XW4uMGKb70c5/L7BaFxwqRUz54GM3DeMFnaE8PRL57HQche9nj9PzZwav88k FxAxbMknP69iR3mXuEgBpmrfYwvCTso4A1P+xhgz0Tc9aS5x/lt/O1vw2/wH6mbCR9wE kJ0ppFPJI0CpYuP/JNtXcLmztQcJNtiQ2Ps4SjDIX9hoa2kvmzmd2Nk/GUiJ5bfgpG2A a4P7gW/7TYF0OTjmU9H5E3oq3So2r48Be046G0hRFw4yfopF+5Z+rGhw9mH4TX1rvGfv ILbA== X-Gm-Message-State: AOAM531vfFjbMwkYaH0+u1qPKwWdsgrc1BC0x6ZniSZ9dqZunKrmNQh3 NYehP+snUMIrN9b55ip0O0OnmGfPkMFydiulYShBFeMHCRU= X-Google-Smtp-Source: ABdhPJyoPT4Me/YD0SlnZ9nOoPd0e2ZzgcA5a9hKgmtaurvNX9NQOmVxmM13iILMES25B1z0yYNK1y1S/+nrH8DbSLs= X-Received: by 2002:a5d:554b:: with SMTP id g11mr4240128wrw.370.1603481610278; Fri, 23 Oct 2020 12:33:30 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 23 Oct 2020 15:33:19 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c8d8fd05b25ba779" Archived-At: Subject: [OAUTH-WG] Reminder - Interim Meeting to discuss the Security BCP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 19:33:33 -0000 --000000000000c8d8fd05b25ba779 Content-Type: text/plain; charset="UTF-8" All, This is a reminder that we have an Interim meeting this coming Monday, Oct 26th @ 12:00 EasternTime, to discuss the latest with the Security BCP: https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-16.html Regards, Rifaat & Hannes --000000000000c8d8fd05b25ba779 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All,

    This is a reminder that we have an= Interim meeting this coming Monday, Oct 26th=C2=A0@ 12:00 EasternTime, to = discuss the latest with the Security BCP:

    Regards,
    =C2=A0Rifaat & Hannes

    --000000000000c8d8fd05b25ba779-- From nobody Sun Oct 25 02:34:23 2020 Return-Path: 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 B7DCF3A1547 for ; Sun, 25 Oct 2020 02:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.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 4szRdgVpvAST for ; Sun, 25 Oct 2020 02:34:20 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 C755C3A1546 for ; Sun, 25 Oct 2020 02:34:19 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id a72so8226666wme.5 for ; Sun, 25 Oct 2020 02:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wpOOcZxo+yBXkZJh3fWZtHVyQF1LjvwHg0+eVT6ljwQ=; b=rO6qnikoNPmP8WZhI0fXltRSDbJbJDrTQEVHcSqz/4bMjMe4EQTzEYgoju0GvkezYa ZTzvtl7huDvu66lXt40zWjv/er19PqDbTy2/+8hcE/M5KACq+O7G4LFeWq4sXyCRzWNK xACNZ1gOxbPTcIIcuMhyGEEapRAHYTDI1RZkqyhV/OLXtpoLM+xqXxJ2J76ll7RrT8EP HUatJFkghIwqv0VTNyYT6ctpTfbjaMWgTVGmZg0ommL8sSCWTpJv2DDpMBOT2Iw/Q4wG We2xMz35rcspJYppJ+khZPI1cEx9pHu41AqAlg48fdS7RW7B7FOC0kAc6+2StoKZvqhP BZiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wpOOcZxo+yBXkZJh3fWZtHVyQF1LjvwHg0+eVT6ljwQ=; b=kpyXV6kfqDBFzYjs1Wampy+TVdGA+/FV53WQpkRwSRJ+lGrneYQloAYCenW06Dlpfz gVFeb+CWAfF5Dg5iY7SEc9ZXj1sYx/r4KSbPhxPDhWYEwG30ZEdvqXdGjUCvr0s1+Se9 eROdkXWefnDQ19qAJijfmRW3aCzmyX/ec7Xu31Z2tZHSv/m4tCJSrkTNbrrk6guxA1vC zJocK8kTAOWPf6/LnA5ZjY6DOY9qtV/HSAjtLIsfGEtDyiMvuM3HjVNmSqOlB4Ol3AcK 76mxmoBYTme9MdisyWrUTxFFori55I7zGIM1UgBq+pAScqo62wU3fRtJ3dc3zntIJfQv bmMQ== X-Gm-Message-State: AOAM532Xdy3f3X9oKbskPJHKjxGyTb9kfht4qE4kgzU9pjB9ghP221Go YFrWuVNhSlpxgTZM5A0BwkkCTiQMr4QKdO5fOjaRjhBS/7ORjGav X-Google-Smtp-Source: ABdhPJxhKmODYYmVpTExjgnmDRNIuvb9y4IAYrpCX/s21UwHH2RvRyog/4cJ1s6btHiATbf/z8SpB5oUioXotBT4SLs= X-Received: by 2002:a1c:9910:: with SMTP id b16mr10266511wme.64.1603618457815; Sun, 25 Oct 2020 02:34:17 -0700 (PDT) MIME-Version: 1.0 From: Takahiko Kawasaki Date: Sun, 25 Oct 2020 18:34:26 +0900 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000088a1e705b27b8410" Archived-At: Subject: [OAUTH-WG] [JAR] For future readers and implementers X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 09:34:22 -0000 --00000000000088a1e705b27b8410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, As it seems that the community has reached a consensus on how to solve conflicts between JAR (OAuth 2.0 JWT Secured Authorization Request) and OIDC Core and that the OpenID conformance suite has been updated accordingly, I collected scattered pieces of information about JAR for future readers and implementers of the specification. Implementer=E2=80=99s note about JAR (JWT Secured Authorization Request) https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe Small feedback from me to the draft version 30 is s/"request_uri parameter"/"request_uri" parameter/ for Section 9.2 and 9.3. Best Regards, Taka --00000000000088a1e705b27b8410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello,

    As it seems that the community has reached a= consensus on how to solve conflicts between JAR (OAuth 2.0 JWT Secured Aut= horization Request) and OIDC Core and that the OpenID conformance suite has= been updated accordingly, I collected scattered pieces of information abou= t JAR for future readers and implementers of the specification.

    Impl= ementer=E2=80=99s note about JAR (JWT Secured Authorization Request)
    https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe
    =
    Small feedback from me to the draft version 30 is s/"request_uri p= arameter"/"request_uri" parameter/ for Section 9.2 and 9.3.<= br>
    Best Regards,
    Taka
    --00000000000088a1e705b27b8410-- From nobody Mon Oct 26 07:33:42 2020 Return-Path: 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 98F353A0937 for ; Mon, 26 Oct 2020 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=hackmanit-de.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 kb-1uFLdcpZc for ; Mon, 26 Oct 2020 07:33:38 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 6F4AB3A0925 for ; Mon, 26 Oct 2020 07:33:37 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id s15so9330976ejf.8 for ; Mon, 26 Oct 2020 07:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit-de.20150623.gappssmtp.com; s=20150623; h=from:subject:autocrypt:to:cc:message-id:date:user-agent :mime-version:content-language; bh=6vkFkNEEF8vioUH5WwKiSSOwDSBhkEhpMK3rFRtYiLQ=; b=LY2JCMvXHL+DuM0ggwhy0AXts2SX2GtWsq4J9v+Hp7sMgIKe0NB4SD0zPh00A1mk6i Fj1uJvUTj8oN6Jz6FZ+8XoCx6wFJIKumCElsilONFy58dP5gpgrz2HZkrra0IeCX6MaC cOKHaIWL2YaA4TU3EBhpeLBcdZ0HlPKElYUh51sOiaAu6cfrMgDY290Nc/e384zA7JPJ O+BUxs2AiQfwD1yB7mB0k5Us0QqrXAz7R8V0VbrVuUYb3ttCjoM9b3hFWdLfYCQUeMZy qHB06Z6m55NEW4Dg4EIjH492abYTYlHYqF/ffuGAHIgBbKeKlmVBKUKzrvXhf4wEU3Lj dkzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:autocrypt:to:cc:message-id:date :user-agent:mime-version:content-language; bh=6vkFkNEEF8vioUH5WwKiSSOwDSBhkEhpMK3rFRtYiLQ=; b=WKG8kYL14RAAIaPMqh3Rc4ors2KWXpCqsPGC3O6SS/Z8jRE2mBQeDsTi5JT/MIg0PI 8UGNUWE0t/5XoISc+N6+BXktq/fZoKs4HLsdZ1bbZdwNiD688Zh5avaXul9v8nG7ZaT/ stdemaTb8VlZiV0Lx1Q/8sPzYmtRBLX9H8PaM456x7Urbg4GVrEBaS69K8B/rrI7ASnF pwcvH4IFCLcn4yGNY99M0W4Qsm8lfEfagCXUVy27kRrFRNs8nZ2iwBsAqBgfVDN/C6UC Xe/b2T2zSNwjUoFek8N/XVz8mQCHLiLsM0b/coFy4Lt3mYVXkJDKRCqxsKZJwcH5JZfY Xqrw== X-Gm-Message-State: AOAM531tPBXhykgNTBfb8WI+C+HTAZskHValq0cGzkpp5Zmoox6BuFDX JvLqL7rQJr8HKU5MBOlr1rpzbA== X-Google-Smtp-Source: ABdhPJw10JRcwoJOZBOzQzwScFctwOaLmLk5Au1LofDe9lwR0tjF5G5SmgzRQ1bW+MTPVBxbByxJVQ== X-Received: by 2002:a17:906:d1c3:: with SMTP id bs3mr15113333ejb.246.1603722816298; Mon, 26 Oct 2020 07:33:36 -0700 (PDT) Received: from [10.10.11.10] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id cw15sm5964442ejb.47.2020.10.26.07.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 07:33:35 -0700 (PDT) From: Karsten Meyer zu Selhausen Autocrypt: addr=karsten.meyerzuselhausen@hackmanit.de; keydata= mQINBFh1IBMBEADV73c10lB7zeFy6/ezLFzOBp8z6Zy1zUyIrf6RoBk1GQWREcGEGeaL90Pj F5plZeASVJdsEYnYXdgcIPE0tlBq6al6OYoWtH/VbFPWEPLVhA3rL1iXVJveD3J40OzSYP8N G7bla3zQ2+TXOB3iDPPsHZUdHCLASkIIWQK6+fE1C2epAdPtnsLsb++1d080jfXXwgyUUh4y bimcy9Jg5oZ4QMwnSq3Y+x38PNb+nTgjDi1X/89/WsNd7Bdh4Zvw3CAuc/W58CFaDjb7liUD YRoAp6ysnjPKEUSnAnMpgaiXJc1gFoL+ahdKJ3D9XTn28NTjUrvOkVidsuKbyxnXP9I6BO6i 2jzjrH6TEAfIYMjZlYTyPZTt271SW5iAHYwvPZWlqQTBT2P/d4gHl0To5b4e+UXxjQgxqUyi QIcxh3Ris21Kx4lKQKDXYWiwNTZzx8AdqrcxCWfK+MRpFyk0B+4uDMm7Apm5ZWwDKN/JnVsJ yokkkrrHs/elRCUGtN9NyhJQf3VnE87862Pej8PVvQJr3uVnoNX2yieTvJZftIOBG1b9ta6Z BcYyn3un1rSn7lBPg+RSnPemposVorQpjGwT+Dhg13Bpv5q0JfSc//js/nB6A4iq5YssdtQ7 35QBWLLaF1oCxalvrQVDD4Sh06eAUQsga9xeE0yv7sxqdsozdwARAQABtEJLYXJzdGVuIE1l eWVyIHp1IFNlbGhhdXNlbiA8a2Fyc3Rlbi5tZXllcnp1c2VsaGF1c2VuQGhhY2ttYW5pdC5k ZT6JAj8EEwEIACkFAlh1IBMCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAK CRBFNcDn2xbxSK7sEAC5hk0VQHo2+fMV3b4TgSt4qSPLz6EnWwoqcEzUGYHErQXy7tCENpqS rsZsFphpgvWo1tcQdpyQTFm0dry4ASJD78lEiYC/8Hedp0fIaJTGwxrSLpRxV/Wb+iqkbgz8 /Qydl3QyupSqznSHQMd0uhvzHLxoYvHAIKy52gCK0T9gmxcCIh7UEjDfm+kqHp+oU4sbNe+2 ZEtJLuCKW+amNyqnHXr7ehAIaYmTdKOEcUb2UM7Yzp9g4kSkg1GbPlAn6yjyAqJ96sobKFXX S3rkXksRTxkGKW278Nrs4UBO+OIu32kIXCM2m3fKaUK777jAQu1e8sdj2nL0sPWQvMikZRx6 0dy+wVuH8gGHZsd7rW201Sv5pAhSAK4l58GS3xSLId6smXCend9Vu+tcYA+Bb+45943LmoPA PrdIUeI+zC9pjGwm+x+jFiCxbChqAiJF7RyYv9crziEYnTQ70gHGNOTOTIS5t0ufc9D4wD4O IkkrPQYg3KcAqP2Kyj1uHcqdk7XEhV1fdTXdeEt1e7auWPh0d3Fo+BTtiGXfNMuORArE0El6 ky8eUOqZEJ8rYpEGDLt0JFkJM5AhX4PrQWekjaMhQ5yl/+M+Ss0V0JkImagSgWdvUn1+eAs0 zEuVxTc6ON69mIyMalQ5d4ofvPnKr3GNVmEiXAVDMGUZHoeabfgSBbkCDQRYdSATARAAsp2V mr3N7iNND8+M/OyA/OwcDQ6utZh+m4TnKsOVdiNLGpu2U3/2Qg3yrbjic2dWx1CsS6VH2/oO 1e/a4FlxA93wFv/OZjiUjHtEvdIJeHWlCvWOUlMsqyGDc3Q75fNjFw6DGKkiOu9lZaBs6naS BmkvAMGjV5bNKLyIL5j7Im1pCdZ2lCjD7eVwR3RQQKobTmu916htX8g1cB9yFmquu37X+ZBl A4GLJi63Kw0L2r8i8iO1NqDLOfT8IeNkOroEm3SDAuEApGAubKLSPBJ1khQ7kDhpdfzSYKUF tiIHpGWVOImDjqf4JIcF7OIdRPQfFPlwoPnsyBAS8znQJvmqbbMowgFZe3UMLAN78CETZHGM OLBPB873oWyZ07Ar4v/SL5/aD+FRj2VnYEcGwt0HMmMyaN6ed8Udj4OTNZ7ceZA1Tw8/lZuI KCamj0XfJIK6376RCGnqjsEfS65P1KWZXfWphCKWp2c7uWKtau1q8pgiVRoBSAmjvfXRrIvK LhhQyNOiCUDKrvEWpoeq9y5GTrY27ncLov8nSR/SUPOw5HwJmzdFjhOF9XAOtiND/QRH886O IohdlnUu668mwLCmL2ROe7XWcTkFQWLDg+5b0bC9dgfL+HHpWGUdQPG3CCyPG5LfDmnmuXkE eU1kSD27kFe1kM6pfqpCydJW66DuwoMAEQEAAYkCJQQYAQgADwUCWHUgEwIbDAUJCWYBgAAK CRBFNcDn2xbxSAAbEACeIsfrsq2tlyigZv+bwkiVP1oKtWfXN1e3K3lDOBqPJaPXWFOopq/1 9osk58PFtVEaDlYPlN/NP6Jq5nTTC8QyLG3swAdo4ZJXWEg1NTRu8ddYUvZWuRHWRghaq7qh eW5lVPqilCndSG7bkDPU/Vyd93nPKnKTKKs/Nd7ePneWA0JQohEg5gO/GU0v5SN3YfTxG1LV Cxu3HHHFodDLK4KITSYmt1+g0WCADeclwm5+L5lIvgKQvcIpjpMGNK1wj2E3exsLlgo/ZEyS AslOPXyQw2yfYLrcfGpvWa3e+AvU7eLVBgihskpibJg53yw31B0CXAJBbjg7AsxR8UE5pl6h 2gTjN2t++GvqefGtw/bPvx2RzFsorh1/RYaFgcaFyefghmpi55iiIhgEOiSIct0LoYl3cmH8 DGYKhSskpSDgfE41Esk/P2odeax9SmJuv4mnqkiGFPpTwCfUka2k0mCpBDpfTdECWUFhreGS qFbrvJDZRBiyaVyCjOvOc0v6Z0/iIRgHWTjITpqaQh69kqAtt9GQWV6i3THnpHFlIC2ecvdc YCagneZdoLEHCS8Nois/uDbp5qZwZcF5zKMI+T7u6Qf8EGdvxCB1fp0Sdlmeto0c6/gnFUix 4J/tozBwSXSg7JCxTrUdnJtcQAJzosOUZTVO/ZZR/n0+904kud6o3w== To: oauth@ietf.org Message-ID: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> Date: Mon, 26 Oct 2020 15:33:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CC0CA602BF376D1A7AFD4A00" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 14:33:41 -0000 This is a multi-part message in MIME format. --------------CC0CA602BF376D1A7AFD4A00 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello WG, adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2 ). However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue. We would like to ask the working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00= Abstract =C2=A0=C2=A0 This document specifies a new parameter "iss" that is used t= o =C2=A0=C2=A0 explicitly include the issuer identifier of the authorizatio= n server =C2=A0=C2=A0 in the authorization response of an OAuth authorization gran= t.=C2=A0 If =C2=A0=C2=A0 implemented correctly, the "iss" parameter serves as an effe= ctive =C2=A0=C2=A0 countermeasure to "mix-up" attacks. The need for a proper specification of the "iss" parameter was discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/ Best regards, Karsten --=20 Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Does your OAuth or OpenID Connect implementation use PKCE to strengthen t= he security? Learn more about the procetion PKCE provides and its limitat= ions in our new blog post: https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-con= fidential-oauth-client Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------CC0CA602BF376D1A7AFD4A00 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hello WG,

    adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2).
    However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue.

    We would like to ask the working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00

    Abstract

       This document specifies a new parameter "iss" that is used to
       explicitly include the issuer identifier of the authorization server
       in the authorization response of an OAuth authorization grant.  If
       implemented correctly, the "iss" parameter serves as an effective
       countermeasure to "mix-up" attacks.


    The need for a proper specification of the "iss" parameter was discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/

    Best regards,
    Karsten


    -- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
    --------------CC0CA602BF376D1A7AFD4A00-- From nobody Mon Oct 26 08:06:55 2020 Return-Path: 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 BB5DE3A0C0A for ; Mon, 26 Oct 2020 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 lQeq0NY3Oonv for ; Mon, 26 Oct 2020 08:06:52 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (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 40C523A0A06 for ; Mon, 26 Oct 2020 08:06:52 -0700 (PDT) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id X45Bk68f8zAfGX45CkvHrJ; Mon, 26 Oct 2020 08:06:51 -0700 X-CMAE-Analysis: v=2.4 cv=TeJTCTch c=1 sm=1 tr=0 ts=5f96e60b a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=9YbGl7VAAAAA:8 a=ZS-cmYKORgS9EeuWxlMA:9 a=r4LEt5SkN1rejCcQ:21 a=4KQkCOPDxcHvq9Gw:21 a=QEXdDO2ut3YA:10 a=jRiBNK6MsXuhxgvlEu8A:9 a=o9Buy8lpsuiF2yCf:21 a=lgwvC8R7iWXqwNI9:21 a=RjFB5uIzcAI4r0ot:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=AcK2Xwxry4XOpw9gWFIK:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Mon, 26 Oct 2020 17:06:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020406050807060706080108" X-CMAE-Envelope: MS4xfEN3xAlFJ1Ts2hKd0dXCfg4W4lm7NnFyehwJBc+t5CdqD05EPJHEA8XMEGXtdZPLSE3ln7Q2iXok8NDwP6v+qJp0ITLILy78HlEra0uIH8jIlA+fsivk e508dadaLPYGs2n7Llo80F+/j50UGcRP9d4+SXWu/5gk2te+OKdx8/UI8DJ8qfczI3vUbVD0eh0YYg== Archived-At: Subject: Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 15:06:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020406050807060706080108 Content-Type: multipart/alternative; boundary="------------B4A26B9A6638C29E29E61137" Content-Language: en-US This is a multi-part message in MIME format. --------------B4A26B9A6638C29E29E61137 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Karsten, Thanks for the write up. I would like to suggest the name authorization_response_iss_parameter_supported, instead of iss_parameter_supported. To make it explicit and unambiguous that it's about the authZ response. Vladimir On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote: > > Hello WG, > > adding the issuer identifier to the authorization response as a > countermeasure to mix-up attacks is well-known on this list and > already part of the security BCP (see 4.4.2 > ). > However, the "iss" parameter is currently not properly specified. > Daniel and I wrote an ID to solve this issue. > > We would like to ask the working group to give us feedback on our > first draft version: > https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-= 00 > > Abstract > > =C2=A0=C2=A0 This document specifies a new parameter "iss" that is used= to > =C2=A0=C2=A0 explicitly include the issuer identifier of the authorizat= ion server > =C2=A0=C2=A0 in the authorization response of an OAuth authorization gr= ant.=C2=A0 If > =C2=A0=C2=A0 implemented correctly, the "iss" parameter serves as an ef= fective > =C2=A0=C2=A0 countermeasure to "mix-up" attacks. > > > The need for a proper specification of the "iss" parameter was > discussed in this thread: > https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc= / > > Best regards, > Karsten > > > --=20 > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing= , Security Training > > Does your OAuth or OpenID Connect implementation use PKCE to strengthen= the security? Learn more about the procetion PKCE provides and its limit= ations in our new blog post: > https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-c= onfidential-oauth-client > > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj= Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz > --------------B4A26B9A6638C29E29E61137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

    Hi Karsten,

    Thanks for the write up. I would like to suggest the name auth= orization_response_iss_parameter_supported, instead of iss_parameter_supported. To make it explicit and unambiguous that it's about the authZ response.

    Vladimir

    On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote:

    Hello WG,

    adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2).
    However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue.

    We would like to as= k the working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-au= th-resp-00

    Abstract

    =C2=A0=C2=A0 This document specifies a new parameter "iss" th= at is used to
    =C2=A0=C2=A0 explicitly include the issuer identifier of the authorization server
    =C2=A0=C2=A0 in the authorization response of an OAuth author= ization grant.=C2=A0 If
    =C2=A0=C2=A0 implemented correctly, the "iss" parameter serve= s as an effective
    =C2=A0=C2=A0 countermeasure to "mix-up" attacks.


    The need for a prop= er specification of the "iss" parameter was discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYy= ZoAaBIc/

    Best regards,
    Karsten


    --=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, =
Penetration Testing, Security Training

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cann=
ot-protect-your-confidential-oauth-client

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz


    --------------B4A26B9A6638C29E29E61137-- --------------ms020406050807060706080108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEwMjYxNTA2NDlaMC8G CSqGSIb3DQEJBDEiBCAHp51yznZKUwGG0pM4iuOlBh8A85PjAc3sgK+/tHYotjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAEC+metFpOc2K31L4TQ8LYtnSh1P2DRGFu7RTPaw/baa6SNU YckSihMwiuUx4y7TixutcqlGcIV4VjvchUi7gRGcH+FULt9rStx7CZiLsxalKq+4DvixwoXA /lvBVE757ECRcKa9XotC2i4EVEwAwZHvGLyQK7RFWHYngJquS+bAsPmnuEwpF7XmLyChksTs PG1/qar13ARCoPAn+vsWsvzk6GD/weNCIoRvJXJXelaweWNFPMV61RR1C6PpkfkVUPncMmTm xJIhZ7o6i+D9Vwam8EXmKBiXWqhB9sKdtq2M0SWO13MNh5cFrMCS0rj79bTm0DvVBOP50Xtu MyNWYm0AAAAAAAA= --------------ms020406050807060706080108-- From nobody Mon Oct 26 09:41:16 2020 Return-Path: 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 132E43A0B2B for ; Mon, 26 Oct 2020 09:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=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 R4dxrkREFbgF for ; Mon, 26 Oct 2020 09:41:10 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 4301D3A0AE4 for ; Mon, 26 Oct 2020 09:41:10 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id a9so12916977lfc.7 for ; Mon, 26 Oct 2020 09:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ecRGrkMRjQpOMjCHCS2oxkTfLGf2OtR4+txykP9iB0=; b=VMcPtZ1uohZiRx7PgMFOdAsPEbeE/UGfSZnuJf64mi1D2cXlsceQiMGtKtR/mACjZi 5I5RY6LlS5qMfl1wxK6/yupD4KZSXQEd8M0MCen5L5/5BbFReKFbgByW/MYOei4w7XYr Yy0axNZ/t7fxNckJUkjH/sGKM4f6Te6eDLCdLoZxakpWfEP4SHpYwkRhKZrYysi3kPL2 vl6AD4MG5ECot1g+erbPjyTlqaVeQe56l1P+5Y408Mfrh5+s9OQ+WnHJBHYxllfW4wX9 apMXk6cHQw+v579Myceyyj9ouirb/l8npIR5R4ZLILmShLJYvcntUwMQVwjuP0w41rVU pFhg== 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=6ecRGrkMRjQpOMjCHCS2oxkTfLGf2OtR4+txykP9iB0=; b=Y62aXpQt18VufxESY5QsZQ/GjA9KlI34IizQoeV+hEyhedlYUHdxHl5syi6+HJ2uvj gcksRjeaWdA/8PnNzBQ0YEH0lsppdoUsOmfQO7D5wWhi50EJczGqvyJkCMaa/UzGrFkj Uhoql6HXGQC1xTfc3p4NIzpKIFWRrhAExrDqh+udIG7gj8DxI8XbRolMsWkB8rvX3J28 yigxnxFy5on3/ImP5QamNS4JmjXGmWc7cceuscV8dCNdGMf9G59Z0WRD1F9fA8ZhFzS7 U/anqH+/OnmM5zABkVHhHxr5zBvS3aAX84rAHv+FStjz8hHfsT2vEOvv12ONn6NTQYnU n+bg== X-Gm-Message-State: AOAM531tSfnzObA7tPwMj7zDinjjDxRWNUvlibFW8zt07U6XDErxPvfn tMQtxB0+OUfB2nCJ58qFflph9v2hKr9vNjvOYIy8js9i6UqK1N/TCP4Ef78CM36hC/lF+NxypoV VVaHWS5pDHrlGeA== X-Google-Smtp-Source: ABdhPJwnjxO2LfW9naR0xHGIRWo7OcpXrouCa5/u3ciugm2k9vUbroHo9tU5MWwZq3+QynkQhOCS4PkQQNqFoQPPxSY= X-Received: by 2002:ac2:5f09:: with SMTP id 9mr5132408lfq.407.1603730467541; Mon, 26 Oct 2020 09:41:07 -0700 (PDT) MIME-Version: 1.0 References: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> In-Reply-To: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> From: Brian Campbell Date: Mon, 26 Oct 2020 10:40:41 -0600 Message-ID: To: Karsten Meyer zu Selhausen Cc: oauth Content-Type: multipart/alternative; boundary="000000000000d575b805b295988f" Archived-At: Subject: Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 16:41:14 -0000 --000000000000d575b805b295988f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd suggest removing the "of an OAuth authorization grant" bit from the abstract. The term 'authorization grant' has meaning from https://tools.ietf.org/html/rfc6749?#section-1.3 that doesn't really work there in the abstract. On Mon, Oct 26, 2020 at 8:33 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > Hello WG, > > adding the issuer identifier to the authorization response as a > countermeasure to mix-up attacks is well-known on this list and already > part of the security BCP (see 4.4.2 > > ). > However, the "iss" parameter is currently not properly specified. Daniel > and I wrote an ID to solve this issue. > > We would like to ask the working group to give us feedback on our first > draft version: > https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00 > > Abstract > > This document specifies a new parameter "iss" that is used to > explicitly include the issuer identifier of the authorization server > in the authorization response of an OAuth authorization grant. If > implemented correctly, the "iss" parameter serves as an effective > countermeasure to "mix-up" attacks. > > > The need for a proper specification of the "iss" parameter was discussed > in this thread: > https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/ > > Best regards, > Karsten > > > -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training > > Does your OAuth or OpenID Connect implementation use PKCE to strengthen t= he security? Learn more about the procetion PKCE provides and its limitatio= ns in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-c= annot-protect-your-confidential-oauth-client > > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d575b805b295988f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'd suggest removing the "of an OAuth autho= rization grant" bit from the abstract. The term 'authorization gra= nt' has meaning from https://tools.ietf.org/html/rfc6749?#section-1.3 that doesn&= #39;t really work there in the abstract.


    =



    On Mon, Oct 26, 2020 at 8:33 AM Karsten= Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrote:
    =20 =20 =20

    Hello WG,=

    adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2).
    However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue.

    We would like to ask th= e working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-me= yerzuselhausen-oauth-iss-auth-resp-00

    Abstract

    =C2=A0=C2=A0 This document specifies a new parameter "iss&qu= ot; that is used to
    =C2=A0=C2=A0 explicitly include the issuer identifier of the authorization server
    =C2=A0=C2=A0 in the authorization response of an OAuth authorizat= ion grant.=C2=A0 If
    =C2=A0=C2=A0 implemented correctly, the "iss" parameter= serves as an effective
    =C2=A0=C2=A0 countermeasure to "mix-up" attacks.


    The need for a proper specification of the "iss" parameter was discussed in t= his thread: https://mailarchive.ietf.org/= arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/

    Best regards,
    Karsten


    --=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.d=
e | IT Security Consulting, Penetration Testing, Security Training

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000d575b805b295988f-- From nobody Mon Oct 26 10:03:26 2020 Return-Path: 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 5887E3A0D6D for ; Mon, 26 Oct 2020 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 HiLyY-YFNt3g for ; Mon, 26 Oct 2020 10:03:22 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 702873A0D6E for ; Mon, 26 Oct 2020 10:03:22 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id r9so10820416ioo.7 for ; Mon, 26 Oct 2020 10:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DPR6TBV6Ko3i0LP4AnefmqkKkehMjQITfDTWFfoggo4=; b=Llvjh6dtetlKxIORHej8lR8qZUYnOWOwD4uPhfO8o5BO6sGMGhqUsMC3ifGp7vgeR1 cHfCTnpCMgomhW0qhQBKnACBc8ElOvLTafgTab6Qc3POt4vm1RZeNJOHRgYw0osv9ovo FKPoxLalq1af2kdYJzUyOdevovzdG87UU5iJDV8zb4ELMsrmUzgYppO8fIcAaZJ9dfHP yQZMYhTSbQbflZ3KLnWJ3DSBkzeeT4Owf0IGpuNkaFFV2MddhfotWqwFQysog65wJpcC WPahKJrjYsYiXqI95YScIH5oksAXjdMoboyPdYKboBd5MMHkMjzu9Ri4VgmqkS8sIeVp Iniw== 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=DPR6TBV6Ko3i0LP4AnefmqkKkehMjQITfDTWFfoggo4=; b=SIL/8YkWrN3E6nSEzKyOA/Ty6QUrusB0Rfd4dTyh2IDyQsaWpEONK39BloccAWdEaD st6YHNmTjf3fxiMBqDDMY5o9WQt+QpJQmLTGEK0A9ixGEou+acgtua5D4BRGFUjRRH3e zeL/8qE+9OrS9zsVpAdtoNbgFJMvQryhmj2D/dnMqIzfXEVC2Xqwl8t+RfOYF6T8b5QR xE9V0cbc3ab2EhqVtxvRmXvocdvbaJO3mLD/Xh5FDTzCviwFvpP12HohjaJRObeIIgdq 0F2D9YrDN8cU0f4astumoFhmCVldEufrNoGLL0gOBLKI90NehVcoaywDTpcWmQWMDWVT n+0A== X-Gm-Message-State: AOAM532XDqqoBCES10tGjkPeQX3oWz9ILTqj7Ng/DBXO2KuZP2Ja8nRZ PWsikCXXzIYihzN/AzgO0ciU6dgsX4CWfg== X-Google-Smtp-Source: ABdhPJwSnZCKuLW5QJZJUo1opvHWyWaf6t9o7yfHG9In6GRD9Rr++A5PKno2+2jdhzdbiLBuCZ1T3w== X-Received: by 2002:a5d:8853:: with SMTP id t19mr10858711ios.164.1603731801050; Mon, 26 Oct 2020 10:03:21 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id z15sm5971117ioj.22.2020.10.26.10.03.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 10:03:20 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id p15so10835203ioh.0 for ; Mon, 26 Oct 2020 10:03:20 -0700 (PDT) X-Received: by 2002:a02:892:: with SMTP id 140mr12603733jac.38.1603731799756; Mon, 26 Oct 2020 10:03:19 -0700 (PDT) MIME-Version: 1.0 References: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> In-Reply-To: <6604cde2-a936-7e66-034b-9282380205a6@hackmanit.de> From: Aaron Parecki Date: Mon, 26 Oct 2020 10:03:08 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Karsten Meyer zu Selhausen Cc: OAuth WG Content-Type: multipart/alternative; boundary="0000000000003d543305b295e891" Archived-At: Subject: Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 17:03:24 -0000 --0000000000003d543305b295e891 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To capture my comment from the interim meeting call, I would like to see some explicit text in this draft (as well as the Security BCP section that will reference this draft) that clarifies this parameter is not needed and this attack is not relevant if a client only interacts with one authorization server. More broadly, I would like to make sure the scope of the attacks that this prevents is clarified so that people may better understand when they do not need to worry about this and don't need to use this new parameter. --- Aaron Parecki https://aaronparecki.com On Mon, Oct 26, 2020 at 7:33 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > Hello WG, > > adding the issuer identifier to the authorization response as a > countermeasure to mix-up attacks is well-known on this list and already > part of the security BCP (see 4.4.2 > > ). > However, the "iss" parameter is currently not properly specified. Daniel > and I wrote an ID to solve this issue. > > We would like to ask the working group to give us feedback on our first > draft version: > https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00 > > Abstract > > This document specifies a new parameter "iss" that is used to > explicitly include the issuer identifier of the authorization server > in the authorization response of an OAuth authorization grant. If > implemented correctly, the "iss" parameter serves as an effective > countermeasure to "mix-up" attacks. > > > The need for a proper specification of the "iss" parameter was discussed > in this thread: > https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/ > > Best regards, > Karsten > > > -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training > > Does your OAuth or OpenID Connect implementation use PKCE to strengthen t= he security? Learn more about the procetion PKCE provides and its limitatio= ns in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-c= annot-protect-your-confidential-oauth-client > > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003d543305b295e891 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    To capture my comment from the interim meeting call, I wou= ld like to see some explicit text in this draft (as well as the Security BC= P section that will reference this draft) that clarifies this parameter is = not needed and this attack is=C2=A0not relevant if a client only interacts = with one authorization server.

    More broadly, I would lik= e to make sure the scope of the attacks that this prevents is clarified so = that people may better understand when they do not need to worry about this= and don't need to use this new parameter.

    On Mon, Oct 26, 2020 at 7:33 AM = Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrote:
    =
    =20 =20 =20

    Hello WG,=

    adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2).
    However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue.

    We would like to ask th= e working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-me= yerzuselhausen-oauth-iss-auth-resp-00

    Abstract

    =C2=A0=C2=A0 This document specifies a new parameter "iss&qu= ot; that is used to
    =C2=A0=C2=A0 explicitly include the issuer identifier of the authorization server
    =C2=A0=C2=A0 in the authorization response of an OAuth authorizat= ion grant.=C2=A0 If
    =C2=A0=C2=A0 implemented correctly, the "iss" parameter= serves as an effective
    =C2=A0=C2=A0 countermeasure to "mix-up" attacks.


    The need for a proper specification of the "iss" parameter was discussed in t= his thread: https://mailarchive.ietf.org/= arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/

    Best regards,
    Karsten


    --=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.d=
e | IT Security Consulting, Penetration Testing, Security Training

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the=
 security? Learn more about the procetion PKCE provides and its limitations=
 in our new blog post:
https://www.hackmanit.de=
/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000003d543305b295e891-- From nobody Mon Oct 26 11:18:47 2020 Return-Path: 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 11A493A0B9F for ; Mon, 26 Oct 2020 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.777 X-Spam-Level: * X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no 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 5Ijnm44EkpRC for ; Mon, 26 Oct 2020 11:18:43 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6333A0BA0 for ; Mon, 26 Oct 2020 11:18:42 -0700 (PDT) Received: from [192.168.1.11] ([90.91.133.250]) by mwinf5d32 with ME id kiJf230175QJY7u03iJgqA; Mon, 26 Oct 2020 19:18:41 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 26 Oct 2020 19:18:41 +0100 X-ME-IP: 90.91.133.250 To: Daniel Fett Cc: oauth From: Denis Message-ID: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> Date: Mon, 26 Oct 2020 19:18:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------84F1E793F01603826EBCD021" Content-Language: en-GB Archived-At: Subject: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 18:18:45 -0000 This is a multi-part message in MIME format. --------------84F1E793F01603826EBCD021 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks. I propose to add a new section 4.16. 4.16 Client collaborative attacks Two clients may agree to collaborate. In such a situation, one client transmits to another client an access token that it legitimately got and also accepts to perform all the cryptographic computations that the other client needs to use the access token, including when the access token is cryptographically bound to a key. Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case. However, if the access token contains claims that allow the RS to uniquely identify the legitimate holder of the access token and if the RS only accepts access tokens that are able to uniquely identify the legitimate holder of the access token, then this attack can be mitigated since the client collaborative attack becomes an impersonation attack. For mitigating the collaborative attack, either a "sub" claim must be present or any combination of other claims allowing for the RS to uniquely identify the holder of the access token must be present inside an access token, for example OpenID claims like: name, family_name, given_name, middle_name, nickname, preferred_username, gender, birthdate, email, email_verified, phone_number, phone_number_verified or address. On the contrary, for example, an access token that would only contain a claim stating that the holder of the access token is over 21 or a birthdate without any claim allowing the RS to uniquely identify the legitimate holder of the access token, should not be accepted by the RS. Under these conditions, it should be observed that the first user might be unlikely to be willing to collaborate since the other user would be able to perform actions on behalf of the first user and the first user would be held responsible of the actions of the second user. *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis --------------84F1E793F01603826EBCD021 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    Hi Daniel,

    Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks.
    I propose to add a new section 4.16.


    4.16 Client collaborative attacks
    Two clients may agree to collaborate. In such a situation, one client transmits to another client an access token
    that it legitimately got and also accepts to perform all the cryptographic computations that the other client needs
    to use the access token, including when the access token is cryptographically bound to a key.

    Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

    However, if the access token contains claims that allow the RS to uniquely identify the legitimate holder of the access token
    and if the RS only accepts access tokens that are able to uniquely identify the legitimate holder of the access token, then
    this attack can be mitigated since the client collaborative attack becomes an impersonation attack.
    For mitigating the collaborative attack, either a "sub" claim must be present or any combination of other claims allowing for the RS
    to uniquely identify the holder of the access token must be present inside an access token, for example OpenID claims like: name,
    family_name, given_name, middle_name, nickname, preferred_username, gender, birthdate, email, email_verified, phone_number,
    phone_number_verified or address.
    On the contrary, for example, an access token that would only contain a claim stating that the holder of the access token is over 21
    or a     birthdate without any claim allowing the RS to uniquely identify the legitimate holder of the access token, should not be accepted by the RS.
    Under these conditions, it should be observed that the first user might be unlikely to be willing to collaborate since the other user would be able
    to perform actions on behalf of the first user and the first user would be held responsible of the actions of the second user.

    Comment on section 4: "Validating JWT Access Tokens"

    The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token.
    However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token
    are indeed be present inside an access token.

    It might be useful to add it, so that the above text can refer to it.

    Denis

    --------------84F1E793F01603826EBCD021-- From nobody Mon Oct 26 14:19:07 2020 Return-Path: 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 50A933A0F3D for ; Mon, 26 Oct 2020 14:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=trustap-com.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 ZpiWT-7QP-7v for ; Mon, 26 Oct 2020 14:19:03 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 1E2233A0F0C for ; Mon, 26 Oct 2020 14:18:57 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id v19so11124158edx.9 for ; Mon, 26 Oct 2020 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5UN972V4S7ZHeOijXNLDrihgSHZ+fiIAOuERiGmNVn8=; b=NJc5gdyvVgDCDJ7jUsJ8O+sIepQ6wLb/ei/kHEu3sAlcxwpQH99MH9Jopiqa5m+40k nqpsVFw6GVn+LdG7ncTnOYvRlC1st18dc6/UdWuWdBjEZSyGoiAp1kBqTXMwD9grOWKf 4MTp6MLRoRYSU5Gug05np9iFUn/aDmM0Wb6LrVTs9itmP4c4Gt25tpnM050yXuidpebF rZUjdS47cs7NCLvGhS2FZeirnWIaYvyPZ+2PeTPCRVS8UxbkpkKZ43FtuFnlkh7ZLvvQ S23kFxCzUBCUbDb5Jj/TnGxUOHkyEbEaI1NWpnwlGTQsuhEbesQTLppkgT9tkGDq0nL7 l0HA== 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=5UN972V4S7ZHeOijXNLDrihgSHZ+fiIAOuERiGmNVn8=; b=qH6TLsPqBfYRkBfE3jrsKxV7ZbG8h7vaCdKNP6GgOjWkdhhIatSWKeU0aXgdzfzv1S ap82CUktU/59/gVc8Nmycv4mNMgNQLGqJJPBW1JAov2EAIgbWmJd7WSc81mTMblBEin6 hCmupcGqnnv5HqLxtl+huFDIUnZqbuGFuq0XXQiRbEBPZcPvAEyT+cFYs9BLmKqaja6u RjzS/66cXQ0bqFLL2ECHn8/ylx1gox/H8byP+RaAIZt/37c61GeUw6cGhY3CxQExlQxO +rnWPmuZ5F4IjxFckcoOd6lQB6QAVGYT3MJjHVYhXF+bP662Ymd6B0zVn7PpwmLXsIQ2 fLqA== X-Gm-Message-State: AOAM530aJBhQRIo52JwWOw6e4idu4/sAz0sP+iGPSueVuF3FrLzuqAXX NUn4vnsrdFeZ/QI/F4OvY+vhv7JJycto9XQCDPG1wA== X-Google-Smtp-Source: ABdhPJzQ4e/2rKt6JqJXjVu2J3yVJB+47sBjfaFLanlxDUbl2qGVwgdfmAETrSwvRsSuAGYEuA2DbBnpVmE4F8kcKmY= X-Received: by 2002:a05:6402:1c04:: with SMTP id ck4mr18036751edb.274.1603747135341; Mon, 26 Oct 2020 14:18:55 -0700 (PDT) MIME-Version: 1.0 References: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> In-Reply-To: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= Date: Mon, 26 Oct 2020 21:18:44 +0000 Message-ID: To: Denis Cc: Daniel Fett , oauth Content-Type: multipart/alternative; boundary="0000000000004fe36305b2997a8e" Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 21:19:05 -0000 --0000000000004fe36305b2997a8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I hadn't come across this idea before, it's an interesting angle and for me it's a nice new example to help highlight the difference between authZ and authN. It reminds me of sharing access cards to get into computer labs in college. Some thoughts: - It took me a while to figure out the agent, victim, intent and impact for the attack based on its name and description. The presented term may already be accepted, but if not, would you consider the term "authorizat= ion sharing attack"? I feel that this conveys the intent and impact of the attack a bit more clearly. However, if the access token contains claims that allow the RS to uniquely > identify the legitimate holder of the access token > and if the RS only accepts access tokens that are able to uniquely > identify the legitimate holder of the access token, then > this attack can be mitigated since the client collaborative attack become= s > an impersonation attack. - Being pedantic, I don't think this mitigates the attack so much as it reduces it to the mentioned impersonation attack. However, I'm not sure that "impersonation attack" is the right term to use here, as this scena= rio seems to imply that the subject consents to the impersonation, which is = in contrast to the standard impersonation attack where the subject is the victim. For mitigating the collaborative attack, either a "sub" claim must be > present or any combination of other claims allowing for the RS > to uniquely identify the holder of the access token must be present insid= e > an access token > - A more general phrasing of this could be that "it should be possible to use an access token to uniquely identify an individual". I say this because this kind of identification can also be done using opaque tokens= , in which case the claims are not necessarily "inside" the access token. Under these conditions, it should be observed that the first user might be > unlikely to be willing to collaborate since the other user would be able > to perform actions on behalf of the first user and the first user would b= e > held responsible of the actions of the second user. - This seems to be the main justification as to why the above mitigations are considered as such. I don't agree with the conclusion because I feel it's based on debateable assumptions, the main one being that the "first user might be unlikely to be willing to collaborate" if they know that their access token identifies them, which tries to predic= t human behaviour. It also depends on the user knowing whether access toke= ns can be used to identify them. - I'm again being pedantic, but I would also note that just being able to identify a user from an access token is unlikely to be a sufficient deterrent, it would need to be coupled with logging of all access token usages for auditing purposes. Again though, this assumes that we can predict human behaviour. - Following on from one of my above points, I would remove the user element from this section, and avoid calling it a mitigation. I'd instea= d outline that if access tokens can be used to identify individuals then i= t reduces possible authZ sharing attacks to authN sharing attacks. I think this is an interesting attack vector, particularly because it requires the authZ sharer to have internal knowledge of how the RS operates, and so has relatively niche applications. It also seems to assume that the RS in question doesn't store user IDs with access logs, at which point, is it simpler to just recommend that authN'd requests to an RS should be logged with user IDs? I've written up an alternative for consideration: Authorization sharing attack > > If access tokens are not used to identify individuals, and if this > information is known to an individual, then such an individual may use > knowledge of this to share the authorization granted to them by access > tokens. This may be done by sharing access tokens across clients and > individuals, at which point the RS will not be able to distinguish betwee= n > different subjects and clients using the same access token. > > If access tokens are used to identify individuals, and such identifying > information (ideally user IDs) is stored with access logs for auditing > purposes, then this reduces this attack to an authentication sharing atta= ck. > I think it's a bit too general for a BCP, and too vague around the notion of an "individual", but it might give some food for further thought. Kind regards, Se=C3=A1n. > On Mon, 26 Oct 2020 at 18:19, Denis wrote: > Hi Daniel, > > Following the conversation we had today, hereafter is a proposal for > addressing client collaborative attacks. > I propose to add a new section 4.16. > > > 4.16 Client collaborative attacks > > Two clients may agree to collaborate. In such a situation, one client > transmits to another client an access token > that it legitimately got and also accepts to perform all the cryptographi= c > computations that the other client needs > to use the access token, including when the access token is > cryptographically bound to a key. > > Since OAuth 2.0 does not mandate the use of cryptographic devices, this > kind of attack cannot be countered in the general case. > > However, if the access token contains claims that allow the RS to uniquel= y > identify the legitimate holder of the access token > and if the RS only accepts access tokens that are able to uniquely > identify the legitimate holder of the access token, then > this attack can be mitigated since the client collaborative attack become= s > an impersonation attack. > > For mitigating the collaborative attack, either a "sub" claim must be > present or any combination of other claims allowing for the RS > to uniquely identify the holder of the access token must be present insid= e > an access token, for example OpenID claims like: name, > family_name, given_name, middle_name, nickname, preferred_username, > gender, birthdate, email, email_verified, phone_number, > phone_number_verified or address. > > On the contrary, for example, an access token that would only contain a > claim stating that the holder of the access token is over 21 > or a birthdate without any claim allowing the RS to uniquely identify the > legitimate holder of the access token, should not be accepted by the RS. > > Under these conditions, it should be observed that the first user might b= e > unlikely to be willing to collaborate since the other user would be able > to perform actions on behalf of the first user and the first user would b= e > held responsible of the actions of the second user. > > > > *Comment on section 4: "Validating JWT Access Tokens" * > The JWT profile for OAuth 2.0 access tokens > [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim int= o > an access token. > However, this section does not mandate the RS to verify that claims > allowing for the RS to uniquely identify the holder of the access token > are indeed be present inside an access token. > > It might be useful to add it, so that the above text can refer to it. > > Denis > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004fe36305b2997a8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I hadn't come across this idea=C2=A0before, it's a= n interesting angle and for me it's a nice new example to help highligh= t the difference between authZ and authN. It reminds me of sharing access c= ards to get into computer labs in college. Some thoughts:
    • It to= ok me a while to figure out the agent, victim, intent and impact for the at= tack based on its name and description. The presented term may already be a= ccepted, but if not, would you consider the term "authorization sharin= g attack"? I feel that this conveys the intent and impact of the attac= k a bit more clearly.
    However, if the access token contai= ns claims that allow the RS to uniquely identify the legitimate holder of t= he access token
    and if the RS o= nly accepts access tokens that are able to uniquely identify the legitimate= holder of the access token, then
    this attack can be mitigated since the client collaborative attack becom= es an impersonation attack.
    • Being pedantic, I do= n't think this mitigates the attack so much as it reduces it to the men= tioned impersonation attack. However, I'm not sure that "impersona= tion attack" is the right term to use here, as this scenario seems to = imply that the subject consents to the impersonation, which is in contrast = to the standard impersonation attack where the subject is the victim.
      • <= /ul>
      For mitigating the collaborative attack, either a "sub&qu= ot; claim must be present or any combination of other claims allowing for t= he RS
      to uniquely identify the holder of the access token must be present insi= de an access token
      • A more general phrasing o= f this could be that "it should be possible to use an access token to = uniquely identify an individual". I say this because this kind of iden= tification can also be done using opaque tokens, in which case the claims a= re not necessarily "inside" the access token.
      U= nder these conditions, it should be observed that the first user might be u= nlikely to be willing to collaborate since the other user would be able
      to per= form actions on behalf of the first user and the first user would be held r= esponsible of the actions of the second user.
        <= li>This seems to be the main justification as to why the above mitigations = are considered as such. I don't agree with the conclusion because I fee= l it's based on debateable assumptions, the main one being that the &qu= ot;first user might be unlikely to be willing to collaborate" if they = know that their access token identifies them, which tries to predict human = behaviour. It also depends on the user knowing whether access tokens can be= used to identify them.
      • I'm again being pedantic, but I would a= lso note that just being able to identify a user from an access token is un= likely to be a sufficient deterrent, it would need to be coupled with loggi= ng of all access token usages for auditing purposes. Again though, this ass= umes that we can predict human behaviour.
      • Following on from one of = my above points, I would remove the user element from this section, and avo= id calling it a mitigation. I'd instead outline that if access tokens c= an be used to identify individuals then it reduces possible authZ sharing a= ttacks to authN sharing attacks.
      I think this is an interesti= ng attack vector, particularly because it requires the authZ sharer to have= internal knowledge of how the RS operates, and so has relatively niche app= lications. It also seems to assume that the RS in question doesn't stor= e user IDs with access logs, at which point, is it simpler to just recommen= d that authN'd requests to an RS should be logged with user IDs?
      <= /div>

      I've written up an alternative for considerati= on:

      A= uthorization sharing attack

      If access tokens are not used to identif= y individuals, and if this information is known to an individual, then such= an individual may use knowledge of this to share the authorization granted= to them by access tokens. This may be done by sharing access tokens across= clients and individuals, at which point the RS will not be able to disting= uish between different subjects and clients using the same access token.
      If access tokens are used to identify individuals, and such identifyin= g information (ideally user IDs) is stored with access logs for auditing pu= rposes, then this reduces this attack to an authentication sharing attack.<= br>

      I think it's a bit too general for = a BCP, and too vague around the notion of an "individual", but it= might give some food for further thought.

      Kind re= gards,

      Se=C3=A1n.

    On Mon, 26 Oct 2020 at 18:19, Den= is <denis.ietf@f= ree.fr> wrote:
    =20 =20 =20

    Hi Daniel,

    Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks.
    I propose to add a new section 4.16.


    4.16 Client collaborative attacks
    Two clients may agree to collaborate. In such a situation, one client transmits to another client an access token
    that it legitimately got and also accepts to perform all the cryptographic computations that the other client needs
    to use the access token, including when the access token is cryptographically bound to a key.

    Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

    However, if the access token contains claims that allow the RS to uniquely identify the legitimate holder of the access token
    and if the RS only accepts access tokens that are able to uniquely identify the legitimate holder of the access token, then
    this attack can be mitigated since the client collaborative attack becomes an impersonation attack.
    For mitigating the collaborative attack, either a "sub" c= laim must be present or any combination of other claims allowing for the RS
    to uniquely identify the holder of the access token must be present inside an access token, for example OpenID claims like: name,
    family_name, given_name, middle_name, nickname, preferred_username, gender, birthdate, email, email_verified, phone_number,
    phone_number_verified or address.
    On the contrary, for example, an access token that would only contain a claim stating that the holder of the access token is over 21
    or a     birthdate without any claim allowing the RS to uniquely identify the legitimate holder of the access token, should not be accepted by the RS.
    Under these conditions, it should be observed that the first user might be unlikely to be willing to collaborate since the other user would be able
    to perform actions on behalf of the first user and the first user would be held responsible of the actions of the second user.

    Comment on section 4: "Validating JWT Ac= cess Tokens"

    The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. <= br> However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token
    are indeed be present inside an access token.

    It might be useful to add it, so that the above text can refer to it.

    Denis

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000004fe36305b2997a8e-- From nobody Mon Oct 26 14:25:36 2020 Return-Path: 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 792D93A0656 for ; Mon, 26 Oct 2020 14:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 ZNNDFsKD9l2b for ; Mon, 26 Oct 2020 14:25:31 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 3C7923A0489 for ; Mon, 26 Oct 2020 14:25:30 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id x20so4939441ilj.8 for ; Mon, 26 Oct 2020 14:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ETHBXM+89lXPfM96JXJKJeGFjtl5dcjCi8Ej8rvM72c=; b=oU3L16F4CCMjYuwOokNQW4EhaccxARWWV1H8Ny8/aCLfnG1RVbURdrcSdIrD7o6T6b n7wWg3UPQiuUrL4NTGXelID9NMIJyvoIatv69/Ip2nT78VIZxQQ8re86iAQwXypIsIQE SHusjGnQbMHC6xNmuQgGl2jwfj+tvR8E2T1ld6ddbJN3vbNEXFiKerRttmFQnzWsdYMS AIk4MUg8XgS7nD5zQnlQi47fDjA7tGU+pgbaxaJqTW8iygB9ePNsq2COVAuviZLoIcsr b2aU8XRq/wX38EIocQ2geermqX79dl4n34nQ9MFn0ph52QDgAYTngQheviuYcOfN5FHg HbrQ== 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=ETHBXM+89lXPfM96JXJKJeGFjtl5dcjCi8Ej8rvM72c=; b=mE7SUAt2G8Oghk584azO3xyD4VKPdJ+zjAgpbRdX+PKuicE72daNFoI8+DBtNQ0Ml6 oDtf0bC9OPgvdu5mzXigHsXSkWdWv8GPvWyxnaxVU1Bg6b3UOLmpulMYNsPhP2PHGJU1 If7UGDA0C5IfHCDkd0AwQUD/4IJxUqB+lNnmXw96PgDic1ocwEhU/u6/KDRcpTro3NN5 sck9PYWF3Qm6F7X+GAL/Q4nvuOShL363ZpyjbSIc8pA7HG5lwzDGUY/OE38iHzIjU5Sv RGqqpIJ4g34zCcRzdJIuGTpLtEt06GWQyy6ygHfmo/dkF7McUwIoXdWdrwjFlpf4WMSD o6vg== X-Gm-Message-State: AOAM531lv2iSbTYqqJnV/wK6K2R0ue0Pmue/xCS+agCWPhCa2dX5GtMb iHe5PAPqQ8oFDyUjPfCHNx8DaRBMY9CDnQ== X-Google-Smtp-Source: ABdhPJzCcX7wzYzaXCZ0oyh5xPbJ9+CB06/cFwPSasIYWTOQ9FEXAv3DwYq8CzliG7fVK0MvCdMu6w== X-Received: by 2002:a92:670e:: with SMTP id b14mr12443897ilc.36.1603747529874; Mon, 26 Oct 2020 14:25:29 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id w22sm5886140iob.32.2020.10.26.14.25.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 14:25:29 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id u19so12309799ion.3 for ; Mon, 26 Oct 2020 14:25:28 -0700 (PDT) X-Received: by 2002:a6b:fa0e:: with SMTP id p14mr11873800ioh.208.1603747528397; Mon, 26 Oct 2020 14:25:28 -0700 (PDT) MIME-Version: 1.0 References: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> In-Reply-To: From: Aaron Parecki Date: Mon, 26 Oct 2020 14:25:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Se=C3=A1n_Kelleher?= Cc: Denis , oauth Content-Type: multipart/alternative; boundary="000000000000bd5ada05b29991f8" Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 21:25:34 -0000 --000000000000bd5ada05b29991f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Se=C3=A1n, this is an excellent analysis and makes this attack mu= ch easier to understand. I completely agree with your rewritten text, both that it better describes the situation as well as the conclusion that it ends up being a bit too general for the BCP. --- Aaron Parecki https://aaronparecki.com https://oauth2simplified.com On Mon, Oct 26, 2020 at 2:19 PM Se=C3=A1n Kelleher wrote= : > I hadn't come across this idea before, it's an interesting angle and for > me it's a nice new example to help highlight the difference between authZ > and authN. It reminds me of sharing access cards to get into computer lab= s > in college. Some thoughts: > > - It took me a while to figure out the agent, victim, intent and > impact for the attack based on its name and description. The presented= term > may already be accepted, but if not, would you consider the term > "authorization sharing attack"? I feel that this conveys the intent an= d > impact of the attack a bit more clearly. > > However, if the access token contains claims that allow the RS to uniquel= y >> identify the legitimate holder of the access token >> and if the RS only accepts access tokens that are able to uniquely >> identify the legitimate holder of the access token, then >> this attack can be mitigated since the client collaborative attack >> becomes an impersonation attack. > > > - Being pedantic, I don't think this mitigates the attack so much as > it reduces it to the mentioned impersonation attack. However, I'm not = sure > that "impersonation attack" is the right term to use here, as this sce= nario > seems to imply that the subject consents to the impersonation, which i= s in > contrast to the standard impersonation attack where the subject is the > victim. > > For mitigating the collaborative attack, either a "sub" claim must be >> present or any combination of other claims allowing for the RS >> to uniquely identify the holder of the access token must be present >> inside an access token >> > > - A more general phrasing of this could be that "it should be possible > to use an access token to uniquely identify an individual". I say this > because this kind of identification can also be done using opaque toke= ns, > in which case the claims are not necessarily "inside" the access token= . > > Under these conditions, it should be observed that the first user might b= e >> unlikely to be willing to collaborate since the other user would be able >> to perform actions on behalf of the first user and the first user would >> be held responsible of the actions of the second user. > > > - This seems to be the main justification as to why the above > mitigations are considered as such. I don't agree with the conclusion > because I feel it's based on debateable assumptions, the main one bein= g > that the "first user might be unlikely to be willing to collaborate" i= f > they know that their access token identifies them, which tries to pred= ict > human behaviour. It also depends on the user knowing whether access to= kens > can be used to identify them. > - I'm again being pedantic, but I would also note that just being able > to identify a user from an access token is unlikely to be a sufficient > deterrent, it would need to be coupled with logging of all access toke= n > usages for auditing purposes. Again though, this assumes that we can > predict human behaviour. > - Following on from one of my above points, I would remove the user > element from this section, and avoid calling it a mitigation. I'd inst= ead > outline that if access tokens can be used to identify individuals then= it > reduces possible authZ sharing attacks to authN sharing attacks. > > I think this is an interesting attack vector, particularly because it > requires the authZ sharer to have internal knowledge of how the RS > operates, and so has relatively niche applications. It also seems to assu= me > that the RS in question doesn't store user IDs with access logs, at which > point, is it simpler to just recommend that authN'd requests to an RS > should be logged with user IDs? > > I've written up an alternative for consideration: > > Authorization sharing attack >> >> If access tokens are not used to identify individuals, and if this >> information is known to an individual, then such an individual may use >> knowledge of this to share the authorization granted to them by access >> tokens. This may be done by sharing access tokens across clients and >> individuals, at which point the RS will not be able to distinguish betwe= en >> different subjects and clients using the same access token. >> >> If access tokens are used to identify individuals, and such identifying >> information (ideally user IDs) is stored with access logs for auditing >> purposes, then this reduces this attack to an authentication sharing att= ack. >> > > I think it's a bit too general for a BCP, and too vague around the notion > of an "individual", but it might give some food for further thought. > > Kind regards, > > Se=C3=A1n. > >> > On Mon, 26 Oct 2020 at 18:19, Denis wrote: > >> Hi Daniel, >> >> Following the conversation we had today, hereafter is a proposal for >> addressing client collaborative attacks. >> I propose to add a new section 4.16. >> >> >> 4.16 Client collaborative attacks >> >> Two clients may agree to collaborate. In such a situation, one client >> transmits to another client an access token >> that it legitimately got and also accepts to perform all the >> cryptographic computations that the other client needs >> to use the access token, including when the access token is >> cryptographically bound to a key. >> >> Since OAuth 2.0 does not mandate the use of cryptographic devices, this >> kind of attack cannot be countered in the general case. >> >> However, if the access token contains claims that allow the RS to >> uniquely identify the legitimate holder of the access token >> and if the RS only accepts access tokens that are able to uniquely >> identify the legitimate holder of the access token, then >> this attack can be mitigated since the client collaborative attack >> becomes an impersonation attack. >> >> For mitigating the collaborative attack, either a "sub" claim must be >> present or any combination of other claims allowing for the RS >> to uniquely identify the holder of the access token must be present >> inside an access token, for example OpenID claims like: name, >> family_name, given_name, middle_name, nickname, preferred_username, >> gender, birthdate, email, email_verified, phone_number, >> phone_number_verified or address. >> >> On the contrary, for example, an access token that would only contain a >> claim stating that the holder of the access token is over 21 >> or a birthdate without any claim allowing the RS to uniquely identify >> the legitimate holder of the access token, should not be accepted by the= RS. >> >> Under these conditions, it should be observed that the first user might >> be unlikely to be willing to collaborate since the other user would be a= ble >> to perform actions on behalf of the first user and the first user would >> be held responsible of the actions of the second user. >> >> >> >> *Comment on section 4: "Validating JWT Access Tokens" * >> The JWT profile for OAuth 2.0 access tokens >> [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim in= to >> an access token. >> However, this section does not mandate the RS to verify that claims >> allowing for the RS to uniquely identify the holder of the access token >> are indeed be present inside an access token. >> >> It might be useful to add it, so that the above text can refer to it. >> >> Denis >> >> _______________________________________________ >> 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 > --000000000000bd5ada05b29991f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thank you=C2=A0Se=C3=A1n, this is an excellent analysis an= d makes this attack much easier to understand. I completely agree with your= rewritten text, both that it better describes the situation=C2=A0as well a= s the conclusion that it ends up being a bit too general for the BCP.
    <= br>

    On Mon, Oct 26, 2= 020 at 2:19 PM Se=C3=A1n Kelleher <s= ean@trustap.com> wrote:
    I hadn't come across this idea=C2=A0bef= ore, it's an interesting angle and for me it's a nice new example t= o help highlight the difference between authZ and authN. It reminds me of s= haring access cards to get into computer labs in college. Some thoughts:
    • It took me a while to figure out the agent, victim, intent and im= pact for the attack based on its name and description. The presented term m= ay already be accepted, but if not, would you consider the term "autho= rization sharing attack"? I feel that this conveys the intent and impa= ct of the attack a bit more clearly.
    However, if the acce= ss token contains claims that allow the RS to uniquely identify the legitim= ate holder of the access token
    = and if the RS only accepts access tokens that are able to uniquely identify= the legitimate holder of the access token, then
    this attack can be mitigated since the client collaborati= ve attack becomes an impersonation attack.
    • Being= pedantic, I don't think this mitigates the attack so much as it reduce= s it to the mentioned impersonation attack. However, I'm not sure that = "impersonation attack" is the right term to use here, as this sce= nario seems to imply that the subject consents to the impersonation, which = is in contrast to the standard impersonation attack where the subject is th= e victim.
    For mitigating the collaborative attack, either= a "sub" claim must be present or any combination of other claims= allowing for the RS
    to uniquely identify the holder of the access token must = be present inside an access token
    • A more gen= eral phrasing of this could be that "it should be possible to use an a= ccess token to uniquely identify an individual". I say this because th= is kind of identification can also be done using opaque tokens, in which ca= se the claims are not necessarily "inside" the access token.
      • =
    Under these conditions, it should be observed that the first = user might be unlikely to be willing to collaborate since the other user wo= uld be able
    to perform actions on behalf of the first user and the first user = would be held responsible of the actions of the second user.
    • This seems to be the main justification as to why the abo= ve mitigations are considered as such. I don't agree with the conclusio= n because I feel it's based on debateable assumptions, the main one bei= ng that the "first user might be unlikely to be willing to collaborate= " if they know that their access token identifies them, which tries to= predict human behaviour. It also depends on the user knowing whether acces= s tokens can be used to identify them.
    • I'm again being pedantic= , but I would also note that just being able to identify a user from an acc= ess token is unlikely to be a sufficient deterrent, it would need to be cou= pled with logging of all access token usages for auditing purposes. Again t= hough, this assumes that we can predict human behaviour.
    • Following = on from one of my above points, I would remove the user element from this s= ection, and avoid calling it a mitigation. I'd instead outline that if = access tokens can be used to identify individuals then it reduces possible = authZ sharing attacks to authN sharing attacks.
    I think this = is an interesting attack vector, particularly because it requires the authZ= sharer to have internal knowledge of how the RS operates, and so has relat= ively niche applications. It also seems to assume that the RS in question d= oesn't store user IDs with access logs, at which point, is it simpler t= o just recommend that authN'd requests to an RS should be logged with u= ser IDs?

    I've written up an alternative = for consideration:

    Authorization sharing attack

    If access tokens are not = used to identify individuals, and if this information is known to an indivi= dual, then such an individual may use knowledge of this to share the author= ization granted to them by access tokens. This may be done by sharing acces= s tokens across clients and individuals, at which point the RS will not be = able to distinguish between different subjects and clients using the same a= ccess token.

    If access tokens are used to identify individuals, and = such identifying information (ideally user IDs) is stored with access logs = for auditing purposes, then this reduces this attack to an authentication s= haring attack.

    I think it's a bit t= oo general for a BCP, and too vague around the notion of an "individua= l", but it might give some food for further thought.

    Kind regards,

    Se=C3=A1n.

    On Mon, 26 Oct 202= 0 at 18:19, Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20

    Hi Daniel,

    Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks.
    I propose to add a new section 4.16.


    4.16 Client collaborative attacks
    Two clients may agree to collaborate. In such a situation, one client transmits to another client an access token
    that it legitimately got and also accepts to perform all the cryptographic computations that the other client needs
    to use the access token, including when the access token is cryptographically bound to a key.

    Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

    However, if the access token contains claims that allow the RS to uniquely identify the legitimate holder of the access token
    and if the RS only accepts access tokens that are able to uniquely identify the legitimate holder of the access token, then
    this attack can be mitigated since the client collaborative attack becomes an impersonation attack.
    For mitigating the collaborative attack, either a "sub" c= laim must be present or any combination of other claims allowing for the RS
    to uniquely identify the holder of the access token must be present inside an access token, for example OpenID claims like: name,
    family_name, given_name, middle_name, nickname, preferred_username, gender, birthdate, email, email_verified, phone_number,
    phone_number_verified or address.
    On the contrary, for example, an access token that would only contain a claim stating that the holder of the access token is over 21
    or a     birthdate without any claim allowing the RS to uniquely identify the legitimate holder of the access token, should not be accepted by the RS.
    Under these conditions, it should be observed that the first user might be unlikely to be willing to collaborate since the other user would be able
    to perform actions on behalf of the first user and the first user would be held responsible of the actions of the second user.

    Comment on section 4: "Validating JWT Ac= cess Tokens"

    The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. <= br> However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token
    are indeed be present inside an access token.

    It might be useful to add it, so that the above text can refer to it.

    Denis

    _______________________________________________
    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
    --000000000000bd5ada05b29991f8-- From nobody Mon Oct 26 18:04:26 2020 Return-Path: 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 7A3C33A113F for ; Mon, 26 Oct 2020 18:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=team.telstra.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 7hgMriNgj42c for ; Mon, 26 Oct 2020 18:04:22 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) (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 A10C93A113E for ; Mon, 26 Oct 2020 18:04:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.77,421,1596463200"; d="scan'208,217";a="403116272" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 27 Oct 2020 12:03:09 +1100 Received: from wsapp5862.srv.dir.telstra.com ([10.75.3.94]) by ipcbvi.tcif.telstra.com.au with ESMTP; 27 Oct 2020 12:03:09 +1100 Received: from wsapp5873.srv.dir.telstra.com (10.75.11.109) by wsapp5862.srv.dir.telstra.com (10.75.3.94) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 12:02:43 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5873.srv.dir.telstra.com (10.75.11.109) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 12:03:08 +1100 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by autodiscover.team.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 27 Oct 2020 12:03:08 +1100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aIm/j4G69zuvaWmVsClh9na5Ah2Sw0wlnZJR4TkK0IqfMEcdadsOBh5Fgkq6Hd0Ozkbv+272kpPvewUc+GwW8IVgYoOvf58yruRnunqqSFJRQp7n2FE7FfO50TFnQyMEZue4OUCcREZj3J/VD9JNgMVt73jzVI7ZLkno+onGaSVWvuxpFGdLoqFX2O7TfHvp1s87IAjgA2cXBILMqwwgHn47WxsyIhmsxRUimZ+88ym7x2PCoJxN6EZVTh79jOW+d6mthuBO4c9l/1BTjpJXaQcT08b2OoT3j/6LXa3V7M831oxqIYYKCyeMFdlR7INz448hANOaSVPCWOpYcWIRIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PIRGHungGmNFngmaiI3/1TBd8jNJ12aKZOSTFxDVFAA=; b=d5asfVd7JKkyGycLyy8/N9J/5DP5gEoqucNOw7Fc8EFCrA+pVKkcG08/o/qVa/yySfGDoUr2XLMcsFuNOr/kXqxJp0UgKZqDZBUJqsZ8e28GMp91owqcLDs5t9ZK5Y7gkuWuJ894fpsTgBBTyCh/usyfcN8khzkvySwpRg4ItICL6uxPIjEQSSOgBdh60+bTFDCpTIeB22svPiM/iwH2sB3rtwBql785QJ0R1/6kIEYIRWXiaCn4FY7CgNV15CUBeGSExxI8zEEAg2WZxuCcJcjlylt8SCiu3HKKzFKSlcoSMLWDZ5pnQAnBlqJxWWMvHlLlREfdYPElGcwdjU6+0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PIRGHungGmNFngmaiI3/1TBd8jNJ12aKZOSTFxDVFAA=; b=I4eN6az5iqPCpvkEQqodFeSO/D+Lr4ByMBVt+83z5Z8ThOfdapu42rVNlu4+eePujwzzdRUYZKi5ZmBHpJ9lJw45ib4m8EH+Q5FMurAkvlCYpQ3wRmfJ3UgXx6L9+Z8uyyfZBgm5c+rQ0prOxRBicNJENEBCr5g0LdkxjiNhqrQ= Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by MEXPR01MB2040.ausprd01.prod.outlook.com (2603:10c6:200:34::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 27 Oct 2020 01:02:59 +0000 Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972%7]) with mapi id 15.20.3477.028; Tue, 27 Oct 2020 01:02:59 +0000 From: "Manger, James" To: =?utf-8?B?U2XDoW4gS2VsbGVoZXI=?= , Denis CC: oauth Thread-Topic: [OAUTH-WG] BCP: Client collaborative attacks Thread-Index: AQHWq8SAV39nbzcrrkCd6bB+C+9SVKmqY6IAgAAb/KA= Date: Tue, 27 Oct 2020 01:02:59 +0000 Message-ID: References: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: trustap.com; dkim=none (message not signed) header.d=none;trustap.com; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [144.132.40.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f43a04d2-89f1-484b-2c36-08d87a140c3b x-ms-traffictypediagnostic: MEXPR01MB2040: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LjNySJ7Mi4fB/qc9RvpLzmZcVu8m5yA402XVXUbuK2e2dRZOp0JIezrd5xe6M96CGHJEa1pjUvipExEE3z+76pqmldCnh7WZRUctwrYySs/dy3kOzIm5AsgChAymzcUHOrMWe0GeyvK+iYujSmEkFtQTzVga8TxzwpRASZeUkvk8/7mPij3pE00tQ+hwt4HxE0/+xFuIit2tEbwdOx92Ig128Cpowc0mWAw8er1W9RVZIRt231jY/uRIPjjnBWhBlR5oGCMRgqCjwiEhnb36tyocCf8FWUE4RWrOSUzmupIhgjCI94wfj3BhAv6+y2bEggh4y0knixlIfquqdtQiig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(9686003)(4326008)(66556008)(110136005)(8936002)(2906002)(64756008)(76116006)(66574015)(66446008)(33656002)(83380400001)(66476007)(66946007)(8676002)(316002)(86362001)(55016002)(186003)(71200400001)(52536014)(6506007)(478600001)(7696005)(26005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: M0z0tEI3rFn8/osMXcj7cshxDPr54OGEx8FQYovXiCzpZAQTy+MIX7I/as/xH2j4/cdbxYQJ/1iHm8UsMMvcrqXXX4Pkf7Fgz2X1ArJc9OCgKmKLlo7E8WvXlp/x9Bz8ousizK6bCo8v5An8fLTAskgMRfuAbsjMPJh0ka5hiA8jdiczEImIql05Cqw6DX7X6c1kDxT4ZK/j8bnwoSzi2LxNxo/k4nE0AZoX5+FVQPUC586JUA0MghNmvKcS5oIV1ZF89WbjctYfV5bDttsg4Mn63Ex55QEqx63ksUaLRD7GFqQSDQ+pxLVf3sSChQiVYy2/eIwPvYdvX6LuahpZpQ9xOEWsrNBb05bwVWL7bc+vVfxSvjXh6dhm3Rp5SHm6WQqZW5ESjZBWnQ1ZQdpPFGtZZO3hS+VymRTpklg1aQJGRXYtk6+AdpxFQvLv1XFf8TtT0r5lFHwzPp45pn10hD/VBwOm+a4IcmmZ5GN1Lroumsp6f1tDyuShPmIw5dN4WYwqHcLn5q6Iipg8h6zC2EERtkb3YExa2ZvgaljBcuhRKQvWqg/W7ln531DpASBHrznSpGXRgB/XtokniDAtAAexFq/5DBs+7CBnAZM8Nrzb3nN6bZ7n5fXN7asgQWEIVA7I+KZpIQLmkIROuvXr2w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011145F49559C4996B7E1E0E5160ME2PR01MB3011ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ME2PR01MB3011.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f43a04d2-89f1-484b-2c36-08d87a140c3b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2020 01:02:59.5624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bLHwKuG6iszdg4eLRBi6mLy/1ewfQfXzMGOt0DKOoanDR2kclleV40Cst0HWRBi93J/koTcUDGdHTxjcz6tjBLOOh6toEcVBx7wdnl+puiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB2040 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 01:04:25 -0000 --_000_ME2PR01MB3011145F49559C4996B7E1E0E5160ME2PR01MB3011ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgd29ydGggbWVudGlvbmluZyDigJxjbGllbnQgY29sbGFib3JhdGl2ZSBhdHRhY2tz4oCd IG9yIOKAnGF1dGhvcml6YXRpb24gc2hhcmluZyBhdHRhY2tz4oCdIGJlY2F1c2UgT0F1dGggY2Fu IG1ha2UgdGhlbSBlYXNpZXIgKGJ5IHBhY2thZ2luZyBhdXRob3JpdHkgaW50byBhbiBhY2Nlc3Mg dG9rZW4pLCBjb21wYXJlZCB0byB0aGUgYWx0ZXJuYXRpdmUgb2YgdXNlcuKAmXMgc2lnbmluZy1p biB0byBhbiBSUyBkaXJlY3RseS4gQnV0IGl0IGlzIHRyaWNreSB0byBkZXNjcmliZTsgbm9uZSBv ZiB0aGUgc3VnZ2VzdGlvbnMgYXJlIHF1aXRlIHJpZ2h0OyBhbmQgdGhlIOKAnHJpZ2h04oCdIHNv bHV0aW9uIGhlYXZpbHkgZGVwZW5kcyBvbiB0aGUgY29udGV4dC4NCg0KPj4gSWYgYWNjZXNzIHRv a2VucyBhcmUgdXNlZCB0byBpZGVudGlmeSBpbmRpdmlkdWFscywgYW5kIHN1Y2ggaWRlbnRpZnlp bmcgaW5mb3JtYXRpb24gKGlkZWFsbHkgdXNlciBJRHMpIGlzIHN0b3JlZCB3aXRoIGFjY2VzcyBs b2dzIGZvciBhdWRpdGluZyBwdXJwb3NlcywgdGhlbiB0aGlzIHJlZHVjZXMgdGhpcyBhdHRhY2sg dG8gYW4gYXV0aGVudGljYXRpb24gc2hhcmluZyBhdHRhY2suDQoNCldoaWxlIHRoaXMgdGV4dCBm cm9tIFNlw6FuIG1heSBiZSB0cnVlLCBpdCBpcyBiYWQgYWR2aWNlLiBJdCBpbXBsaWVzIHdlIHNo b3VsZCBtYWtlIGFjY2VzcyB0b2tlbnMgYXMgZGFuZ2Vyb3VzIGFzIHBvc3NpYmxlIChjb252ZXlp bmcgYWxsIGEgcGVyc29u4oCZcyBhdXRob3JpdHkpIGp1c3QgdG8gZGlzY291cmFnZSBzaGFyaW5n Lg0KDQo+IFNpbmNlIE9BdXRoIDIuMCBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2YgY3J5cHRv Z3JhcGhpYyBkZXZpY2VzLCB0aGlzIGtpbmQgb2YgYXR0YWNrIGNhbm5vdCBiZSBjb3VudGVyZWQg aW4gdGhlIGdlbmVyYWwgY2FzZS4NCg0KRXZlbiBjcnlwdG8gZGV2aWNlcyBhcmVu4oCZdCBhIGZ1 bGwgc29sdXRpb24uIEFsaWNlIGNhbiBzaGFyZSBoZXIgYXV0aG9yaXphdGlvbiB3aXRoIEJvYiAm IENocmlzIGJ5IHNpZ25pbmctaW4gd2l0aCB0aGVpciBjcnlwdG8gZGV2aWNlcy4NCg0KPiBhbiBh Y2Nlc3MgdG9rZW4g4oCmIG9ubHkgc3RhdGluZyB0aGF0IHRoZSBob2xkZXIg4oCmIGlzIG92ZXIg MjEg4oCmIHNob3VsZCBub3QgYmUgYWNjZXB0ZWQgYnkgdGhlIFJTDQoNCldoaWxlIHRoaXMgbWF5 IGdlbmVyYWxseSBiZSB0cnVlIGZvciBhbiDigJxvdmVyIDIx4oCdIGNsYWltLCBpdCB3aWxsIG5v dCBhbHdheXMgYmUgdHJ1ZSBmb3Igb3RoZXIgY2xhaW1zLiBJbiBzb21lIHNpdHVhdGlvbnMgdGhl IHByaXZhY3kgcmlzayBvZiBiZWluZyBwZXJzb25hbGx5IGlkZW50aWZpZWQgaXMgZmFyIG1vcmUg aW1wb3J0YW50IHRoYW4gYW55IHJpc2sgb2YgY2xpZW50IGNvbGxhYm9yYXRpb24uIFN0YWZmIGFj Y2Vzc2luZyBhIGNvbXBhbnnigJlzIHdoaXN0bGUtYmxvd2VyIHNlcnZpY2UgY291bGQgYmUgYW4g ZXhhbXBsZTogbmVlZCBhIHtzdGFmZjp0cnVlfSBjbGFpbSB0byBjb21iYXQgc3BhbS9nb3NzaXA7 IGJ1dCBkZWZpbml0ZWx5IGRvbuKAmXQgd2FudCB0byBpbmNsdWRlIGEgc3RhZmYgaWQuDQoNCg0K QSBoYW5kZnVsIG9mIHBhcnRpYWwgc3RyYXRlZ2llcyBhcHByb3ByaWF0ZSBpbiB2YXJpb3VzIGNp cmN1bXN0YW5jZXMgKGJ1dCBhbGwgd2l0aCBkb3duc2lkZXMpIGNvdWxkIGluY2x1ZGU6DQoxLiBU aGUgQVMgZW5zdXJlcyB0aGVyZSBpcyBvbmx5IDEgdmFsaWQgYWNjZXNzIHRva2VuIChvciBqdXN0 IGEgZmV3KSBhdCBhbnkgcG9pbnQgaW4gdGltZSBmb3IgYSBzcGVjaWZpYyBjbGFpbSBvZiBhIGdp dmVuIHVzZXIuDQoyLiBBY2Nlc3MgdG9rZW4gYm91bmQgdG8gYSBjcnlwdG8ga2V5IGxvY2tlZCB0 byBvbmUgZGV2aWNlLg0KMy4gRWFjaCBhY2Nlc3MgdG9rZW4gaXMgdW5pcXVlIChlZyBpbmNsdWRl cyBhICJqdGkiIGNsYWltKSBzbyBhbiBSUyBjYW4gbm90aWNlIGlmIHRoZSBzYW1lIHRva2VuIGlz IHByZXNlbnRlZCBpbiBkaWZmZXJlbnQgY29udGV4dHMuDQo0LiBBY2Nlc3MgdG9rZW4gd2l0aCAi c3ViIiAob3IgcHJvdmlkZXMgInN1YiIgdmlhIHRva2VuIGludHJvc3BlY3Rpb24pIHRvIGFpZCBh Y2NvdW50YWJpbGl0eSAoZXZlbiBpZiBvbmx5IGluIGEgbGF0ZXIgYXVkaXQvaW52ZXN0aWdhdGlv bikuDQo1LiBGcmVxdWVudCB0b2tlbiByZXBsYWNlbWVudC4NCjYuIE5vdGhpbmcgKGJleW9uZCBt aW5pbWFsIG5lY2Vzc2FyeSBjbGFpbXMpIOKAkyB0byBtYXhpbWl6ZSBwcml2YWN5Lg0KDQpXaGF0 IGlzIGFwcGxpY2FibGUgd2lkZWx5IGVub3VnaCB0byBtZW50aW9uIGluIGEgQkNQPw0KDQotLQ0K SmFtZXMgTWFuZ2VyDQo= --_000_ME2PR01MB3011145F49559C4996B7E1E0E5160ME2PR01MB3011ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE0OTYzNjQ4NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTA4MjU2NDk2ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxODkzMzgxODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjk3MzExMjk0ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMTI3MjM0MzI2Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotNTM5ODM4NDg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQwNDU3MTk0NTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTEwMTI1OTQ1Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgw LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdCBpcyB3b3J0 aCBtZW50aW9uaW5nIOKAnGNsaWVudCBjb2xsYWJvcmF0aXZlIGF0dGFja3PigJ0gb3Ig4oCcYXV0 aG9yaXphdGlvbiBzaGFyaW5nIGF0dGFja3PigJ0gYmVjYXVzZSBPQXV0aCBjYW4gbWFrZSB0aGVt IGVhc2llciAoYnkgcGFja2FnaW5nIGF1dGhvcml0eSBpbnRvIGFuIGFjY2VzcyB0b2tlbiksIGNv bXBhcmVkIHRvIHRoZSBhbHRlcm5hdGl2ZQ0KIG9mIHVzZXLigJlzIHNpZ25pbmctaW4gdG8gYW4g UlMgZGlyZWN0bHkuIEJ1dCBpdCBpcyB0cmlja3kgdG8gZGVzY3JpYmU7IG5vbmUgb2YgdGhlIHN1 Z2dlc3Rpb25zIGFyZSBxdWl0ZSByaWdodDsgYW5kIHRoZSDigJxyaWdodOKAnSBzb2x1dGlvbiBo ZWF2aWx5IGRlcGVuZHMgb24gdGhlIGNvbnRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZndDsmZ3Q7IDwvc3Bhbj5JZiBh Y2Nlc3MgdG9rZW5zIGFyZSB1c2VkIHRvIGlkZW50aWZ5IGluZGl2aWR1YWxzLCBhbmQgc3VjaCBp ZGVudGlmeWluZyBpbmZvcm1hdGlvbiAoaWRlYWxseSB1c2VyIElEcykgaXMgc3RvcmVkIHdpdGgg YWNjZXNzIGxvZ3MgZm9yIGF1ZGl0aW5nIHB1cnBvc2VzLCB0aGVuIHRoaXMgcmVkdWNlcyB0aGlz IGF0dGFjayB0bw0KIGFuIGF1dGhlbnRpY2F0aW9uIHNoYXJpbmcgYXR0YWNrLjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoaWxlIHRoaXMgdGV4dCBmcm9t DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlNlw6FuIG1heSBiZSB0cnVlLCBpdCBpcyBiYWQg YWR2aWNlLiBJdCBpbXBsaWVzIHdlIHNob3VsZCBtYWtlIGFjY2VzcyB0b2tlbnMgYXMgZGFuZ2Vy b3VzIGFzIHBvc3NpYmxlIChjb252ZXlpbmcgYWxsIGEgcGVyc29u4oCZcyBhdXRob3JpdHkpIGp1 c3QgdG8gZGlzY291cmFnZSBzaGFyaW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U2luY2UgT0F1dGggMi4wIGRvZXMgbm90 IG1hbmRhdGUgdGhlIHVzZSBvZiBjcnlwdG9ncmFwaGljIGRldmljZXMsIHRoaXMga2luZCBvZiBh dHRhY2sgY2Fubm90IGJlIGNvdW50ZXJlZCBpbiB0aGUgZ2VuZXJhbCBjYXNlLjwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FdmVuIGNyeXB0byBk ZXZpY2VzIGFyZW7igJl0IGEgZnVsbCBzb2x1dGlvbi4gQWxpY2UgY2FuIHNoYXJlIGhlciBhdXRo b3JpemF0aW9uIHdpdGggQm9iICZhbXA7IENocmlzIGJ5IHNpZ25pbmctaW4gd2l0aCB0aGVpciBj cnlwdG8gZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmFuIGFjY2VzcyB0b2tlbiDigKYgb25seSBz dGF0aW5nIHRoYXQgdGhlIGhvbGRlciDigKYgaXMgb3ZlciAyMSDigKYgc2hvdWxkIG5vdCBiZSBh Y2NlcHRlZCBieSB0aGUgUlM8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+V2hpbGUgdGhpcyBtYXkgZ2VuZXJhbGx5IGJlIHRydWUgZm9yIGFuIOKA nG92ZXIgMjHigJ0gY2xhaW0sIGl0IHdpbGwgbm90IGFsd2F5cyBiZSB0cnVlIGZvciBvdGhlciBj bGFpbXMuIEluIHNvbWUgc2l0dWF0aW9ucyB0aGUgcHJpdmFjeSByaXNrIG9mIGJlaW5nIHBlcnNv bmFsbHkgaWRlbnRpZmllZCBpcyBmYXIgbW9yZSBpbXBvcnRhbnQgdGhhbg0KIGFueSByaXNrIG9m IGNsaWVudCBjb2xsYWJvcmF0aW9uLiBTdGFmZiBhY2Nlc3NpbmcgYSBjb21wYW554oCZcyB3aGlz dGxlLWJsb3dlciBzZXJ2aWNlIGNvdWxkIGJlIGFuIGV4YW1wbGU6IG5lZWQgYSB7c3RhZmY6dHJ1 ZX0gY2xhaW0gdG8gY29tYmF0IHNwYW0vZ29zc2lwOyBidXQgZGVmaW5pdGVseSBkb27igJl0IHdh bnQgdG8gaW5jbHVkZSBhIHN0YWZmIGlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkEgaGFuZGZ1bCBvZiBwYXJ0aWFsIHN0cmF0ZWdpZXMgYXBwcm9wcmlhdGUgaW4g dmFyaW91cyBjaXJjdW1zdGFuY2VzIChidXQgYWxsIHdpdGggZG93bnNpZGVzKSBjb3VsZCBpbmNs dWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+MS4gVGhlIEFTIGVuc3VyZXMgdGhlcmUg aXMgb25seSAxIHZhbGlkIGFjY2VzcyB0b2tlbiAob3IganVzdCBhIGZldykgYXQgYW55IHBvaW50 IGluIHRpbWUgZm9yIGEgc3BlY2lmaWMgY2xhaW0gb2YgYSBnaXZlbiB1c2VyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Mi4gQWNjZXNzIHRva2VuIGJvdW5kIHRvIGEgY3J5cHRvIGtleSBs b2NrZWQgdG8gb25lIGRldmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjMuIEVhY2gg YWNjZXNzIHRva2VuIGlzIHVuaXF1ZSAoZWcgaW5jbHVkZXMgYSAmcXVvdDtqdGkmcXVvdDsgY2xh aW0pIHNvIGFuIFJTIGNhbiBub3RpY2UgaWYgdGhlIHNhbWUgdG9rZW4gaXMgcHJlc2VudGVkIGlu IGRpZmZlcmVudCBjb250ZXh0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjQuIEFjY2Vz cyB0b2tlbiB3aXRoICZxdW90O3N1YiZxdW90OyAob3IgcHJvdmlkZXMgJnF1b3Q7c3ViJnF1b3Q7 IHZpYSB0b2tlbiBpbnRyb3NwZWN0aW9uKSB0byBhaWQgYWNjb3VudGFiaWxpdHkgKGV2ZW4gaWYg b25seSBpbiBhIGxhdGVyIGF1ZGl0L2ludmVzdGlnYXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+NS4gRnJlcXVlbnQgdG9rZW4gcmVwbGFjZW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj42LiBOb3RoaW5nIChiZXlvbmQgbWluaW1hbCBuZWNlc3NhcnkgY2xhaW1zKSDi gJMgdG8gbWF4aW1pemUgcHJpdmFjeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBpcyBhcHBsaWNhYmxlIHdpZGVseSBl bm91Z2ggdG8gbWVudGlvbiBpbiBhIEJDUD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFtZXMgTWFuZ2VyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ME2PR01MB3011145F49559C4996B7E1E0E5160ME2PR01MB3011ausp_-- From nobody Mon Oct 26 23:26:53 2020 Return-Path: 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 254B03A15BD for ; Mon, 26 Oct 2020 23:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=forgerock.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 hxBH-vBq9_xz for ; Mon, 26 Oct 2020 23:26:48 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 CE0423A109F for ; Mon, 26 Oct 2020 23:26:47 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id w23so226033wmi.4 for ; Mon, 26 Oct 2020 23:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=uG25yHc4PpXPdSqMiWKG8q02qNBNjyo34suXnN1cCsk=; b=HKggniGQiS41bDb1aBlKEHDah7srXIJcuHHXdDb0R9Yn5HvZZ8oM//QpE9PA3KhhxV JlekFud4bkYgX0UYMq0xBgVvV5ayKM30iWYxygRay1I6bmD4AXg+kIfbShm+x2pRyni1 DuIfbJyxaJ14DHk3Oe+C25pWLayCQHQpM9+k0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=uG25yHc4PpXPdSqMiWKG8q02qNBNjyo34suXnN1cCsk=; b=qkMzKwJQ4hEW5M0u77kgJX4M4Rlufd2mhdYQF1dXD/bhnOFkbouTjEYTYgUNQV44vq JRaxGm0C5EDUxots1ys/lPYHqxYVKLTU/LCjIGnihIJnJe36r8/Cmd7gq+77VfbaNiuV +Q13SpkVgPeJktTqOypxQKwYslaKn6XkY84FyTkHWFxCay7gUXHa42OHjiMorNseugyD QGMSGifTf8AdRymkcf+G+WB7zdK7dEz9lEWR4ADjYIUyxHUXVjMuTqY+GmzSqdlF8Zp2 IedHYLfqJDHXRuf3pxHksX8HGk8mzyesuq7oEfJZcMuWDlOcnGpTwgE00vx0CmdbbeHI ONNQ== X-Gm-Message-State: AOAM532cCpoG4Lf+UfXrigWUXkvkbCqgIiSxfmLIdjYIX7DgTo7TMwQ7 oJhucw2ISmE5CAg4plb/vo22H9fspY3HXyvSdVWGSBnD7+/s8oEw/3solViDMQkBLrF6SBU6YA= = X-Google-Smtp-Source: ABdhPJzrJ2mYkLrByon0kSu2IaahMlU3ZL6H0abSM/zzu1oHm4bARHwGis4WJI0p6jF5Uwwd0PyIPA== X-Received: by 2002:a1c:6143:: with SMTP id v64mr850618wmb.108.1603780005453; Mon, 26 Oct 2020 23:26:45 -0700 (PDT) Received: from ?IPv6:2a02:c7d:7263:bd00:99a9:fd2a:f83d:9a2a? ([2a02:c7d:7263:bd00:99a9:fd2a:f83d:9a2a]) by smtp.gmail.com with ESMTPSA id y10sm646231wrq.73.2020.10.26.23.26.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 23:26:44 -0700 (PDT) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Tue, 27 Oct 2020 06:26:44 +0000 Message-Id: References: Cc: =?utf-8?Q?Se=C3=A1n_Kelleher?= , Denis , oauth In-Reply-To: To: "Manger, James" X-Mailer: iPhone Mail (17H35) Content-Type: multipart/alternative; boundary=Apple-Mail-BA500AA4-4CAF-4634-B7AD-A1F4336AAFFD Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 06:26:51 -0000 --Apple-Mail-BA500AA4-4CAF-4634-B7AD-A1F4336AAFFD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It sounds like we=E2=80=99re trying to redefine cooperation/delegation as a= n =E2=80=9Cattack=E2=80=9D. People delegate and you can=E2=80=99t generally= prevent it without incarceration. Anything Bob could do with Alice=E2=80= =99s access token he could also do by asking Alice to do it on his behalf. = In other words, any credential/token sharing can be replaced by proxying: I= f Alice wants to help underage Bob buy liquor she doesn=E2=80=99t have to s= hare her access token, she can just buy it herself and give it to him.=20 If the RS cares about accountability then the token (or some other means) s= hould identify the user - perhaps pseudonymously like OIDC pairwise identif= iers - and this should be logged for audit. But this can only discourage, n= ot prevent, delegation. OAuth is after all a delegation protocol.=20 (In the post-shame world we now live in, the idea that you can enforce norm= s through identification seems almost quaint, but I=E2=80=99m not sure I=E2= =80=99m ready to be that cynical). If the RS allows anonymous requests then there is obviously no accountabili= ty. Does that need to be explicitly mentioned? =E2=80=94 Neil > On 27 Oct 2020, at 01:04, Manger, James = wrote: >=20 > =EF=BB=BF > It is worth mentioning =E2=80=9Cclient collaborative attacks=E2=80=9D or = =E2=80=9Cauthorization sharing attacks=E2=80=9D because OAuth can make them= easier (by packaging authority into an access token), compared to the alte= rnative of user=E2=80=99s signing-in to an RS directly. But it is tricky to= describe; none of the suggestions are quite right; and the =E2=80=9Cright= =E2=80=9D solution heavily depends on the context. > =20 > >> If access tokens are used to identify individuals, and such identifyin= g information (ideally user IDs) is stored with access logs for auditing pu= rposes, then this reduces this attack to an authentication sharing attack. > =20 > While this text from Se=C3=A1n may be true, it is bad advice. It implies = we should make access tokens as dangerous as possible (conveying all a pers= on=E2=80=99s authority) just to discourage sharing. > =20 > > Since OAuth 2.0 does not mandate the use of cryptographic devices, this= kind of attack cannot be countered in the general case. > =20 > Even crypto devices aren=E2=80=99t a full solution. Alice can share her a= uthorization with Bob & Chris by signing-in with their crypto devices. > =20 > > an access token =E2=80=A6 only stating that the holder =E2=80=A6 is ove= r 21 =E2=80=A6 should not be accepted by the RS > =20 > While this may generally be true for an =E2=80=9Cover 21=E2=80=9D claim, = it will not always be true for other claims. In some situations the privacy= risk of being personally identified is far more important than any risk of= client collaboration. Staff accessing a company=E2=80=99s whistle-blower s= ervice could be an example: need a {staff:true} claim to combat spam/gossip= ; but definitely don=E2=80=99t want to include a staff id. > =20 > =20 > A handful of partial strategies appropriate in various circumstances (but= all with downsides) could include: > 1. The AS ensures there is only 1 valid access token (or just a few) at a= ny point in time for a specific claim of a given user. > 2. Access token bound to a crypto key locked to one device. > 3. Each access token is unique (eg includes a "jti" claim) so an RS can n= otice if the same token is presented in different contexts. > 4. Access token with "sub" (or provides "sub" via token introspection) to= aid accountability (even if only in a later audit/investigation). > 5. Frequent token replacement. > 6. Nothing (beyond minimal necessary claims) =E2=80=93 to maximize privac= y. > =20 > What is applicable widely enough to mention in a BCP? > =20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 ForgeRock values your Privacy --Apple-Mail-BA500AA4-4CAF-4634-B7AD-A1F4336AAFFD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It sounds like we=E2= =80=99re trying to redefine cooperation/delegation as an =E2=80=9Cattack=E2= =80=9D. People delegate and you can=E2=80=99t generally prevent it without = incarceration. Anything Bob could do with Alice=E2=80=99s access token he c= ould also do by asking Alice to do it on his behalf. In other words, any cr= edential/token sharing can be replaced by proxying: If Alice wants to help = underage Bob buy liquor she doesn=E2=80=99t have to share her access token,= she can just buy it herself and give it to him. 

    If the RS cares about accountability then the = token (or some other means) should identify the user - perhaps pseudonymous= ly like OIDC pairwise identifiers - and this should be logged for audit. Bu= t this can only discourage, not prevent, delegation. OAuth is after all a d= elegation protocol. 

    = (In the post-shame world we now live in, the idea that you can enforce norm= s through identification seems almost quaint, but I=E2=80=99m not sure I=E2= =80=99m ready to be that cynical).

    If the RS allows anonymous requests then there is obviously no acc= ountability. Does that need to be explicitly mentioned?

    =E2=80=94 Neil

    On 27 Oct 2020, at 01:04, Mang= er, James <James.H.Manger@team.telstra.com> wrote:

    =EF=BB=BF

    It is wor= th mentioning =E2=80=9Cclient collaborative attacks=E2=80=9D or =E2=80=9Cau= thorization sharing attacks=E2=80=9D because OAuth can make them easier (by= packaging authority into an access token), compared to the alternative of user=E2=80=99s signing-in to an RS directly. But it is tricky to descri= be; none of the suggestions are quite right; and the =E2=80=9Cright=E2=80= =9D solution heavily depends on the context.

    &nbs= p;

    >> = If access tokens are used to identify individuals, and such identify= ing information (ideally user IDs) is stored with access logs for auditing = purposes, then this reduces this attack to an authentication sharing attack.

    &nbs= p;

    While thi= s text from Se=C3=A1n may be true, it is bad advice. It imp= lies we should make access tokens as dangerous as possible (conveying all a= person=E2=80=99s authority) just to discourage sharing.

    &nbs= p;

    > Since OAuth 2.0= does not mandate the use of cryptographic devices, this kind of attack can= not be countered in the general case.

    &nbs= p;

    Even cryp= to devices aren=E2=80=99t a full solution. Alice can share her authorizatio= n with Bob & Chris by signing-in with their crypto devices.<= /span>

    &nbs= p;

    > an access token= =E2=80=A6 only stating that the holder =E2=80=A6 is over 21 =E2=80=A6 shou= ld not be accepted by the RS

    &nbs= p;

    While thi= s may generally be true for an =E2=80=9Cover 21=E2=80=9D claim, it will not= always be true for other claims. In some situations the privacy risk of be= ing personally identified is far more important than any risk of client collaboration. Staff accessing a company=E2=80=99s whis= tle-blower service could be an example: need a {staff:true} claim to combat= spam/gossip; but definitely don=E2=80=99t want to include a staff id.=

    &nbs= p;

    &nbs= p;

    A handful= of partial strategies appropriate in various circumstances (but all with d= ownsides) could include:

    1. The AS= ensures there is only 1 valid access token (or just a few) at any point in= time for a specific claim of a given user.

    2. Access= token bound to a crypto key locked to one device.

    3. Each a= ccess token is unique (eg includes a "jti" claim) so an RS can notice if th= e same token is presented in different contexts.

    4. Access= token with "sub" (or provides "sub" via token introspection) to aid accoun= tability (even if only in a later audit/investigation).

    5. Freque= nt token replacement.

    6. Nothin= g (beyond minimal necessary claims) =E2=80=93 to maximize privacy.

    &nbs= p;

    What is a= pplicable widely enough to mention in a BCP?

    &nbs= p;

    --

    James Manger

    _______________________________________________
    OAuth= mailing list
    OAuth@ietf.org
    https://www.ie= tf.org/mailman/listinfo/oauth

    ForgeRock values your Privacy --Apple-Mail-BA500AA4-4CAF-4634-B7AD-A1F4336AAFFD-- From nobody Tue Oct 27 02:00:07 2020 Return-Path: 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 1B11C3A1656 for ; Tue, 27 Oct 2020 02:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=trustap-com.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 PdAtY6oB9b5z for ; Tue, 27 Oct 2020 02:00:02 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 82B4D3A1655 for ; Tue, 27 Oct 2020 02:00:02 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id bn26so1091537ejb.6 for ; Tue, 27 Oct 2020 02:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/12DVFhAiDj6+W26dEL3MZVFBylD1yQ9VVh734lz0dA=; b=y6gJXHXhfcb5s9E77MIohyurkOkBJuz2VJdxKW0arVTzBKrXR3gLIrcRevqAecU5U+ /7c+FGhD6+7TvkoSV5EIU3vO2sDlmrL3m5Q6fzgtBocPYYQmGJRxwZ3s5D+Quxg1Qh5C 2Znx18meDwKMBkAmCf1l3mOED0pJHo6o9n18mXIqvF0rbK4gP+1PPtHTFTWjsqoNwxsf 6KJ0pGHBhgA5HbN2neVQlfooTqcJ1krbyG5R0bXEACM3SigyOKBQWVKtOlB1J+n5c8U2 6Xa8EWwZYw4/q7t+Liz/NmQhmDp0wXKuVpi/PnmpTQ46nxa9E3zrp1b6GRwxUaikDG5x fxbg== 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=/12DVFhAiDj6+W26dEL3MZVFBylD1yQ9VVh734lz0dA=; b=XBSg+U1NEMSit7JmLfsACKF2N4p2MKabqbd6g+zJ9FIe2Ev/cpXDlgz5HpZRCCrwQx 5e4TUKfsTpYNoF6uGMiqMm4RsDgwI2BR1Prg4LtXqQD0jzjFGX7iv2f0+GeZjs9kp4gm q9HtTVOm3XZrL821Gn8piJWOH/5tzYkbFnm9Jc00pKOy5iht+KoMN31ghK1bLIQE3MAM 6Oy28ZUuYa/hFQawN0LZMZAIe4f99YyrVdbs1dkBtAJcDrzauXDGNHCf7DzjTyNzFcvg AsfgJaVCBLHJOmePO8tEEkw3r0relz8OLor1NcoiWPwKnlRczhJ9nLDGxMSycovDgr65 wMDQ== X-Gm-Message-State: AOAM532yf8kL8rzwQoWboqHl5FrLJkBQBAz7NugAzFeUKB5p4Ph62Mum nJ4Bv7b+crJm4re3VZSM8T2GunbsV9KwwjqZPXk6Kw== X-Google-Smtp-Source: ABdhPJw6a7vwCq40Sadwbw6Cda+9zTq4gVguaBMADyt5ifapCZzizMwXAZuO/+lIB95gnPUoaL5e2jqYUVnBIoLc+O4= X-Received: by 2002:a17:906:1e08:: with SMTP id g8mr1363278ejj.358.1603789200879; Tue, 27 Oct 2020 02:00:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= Date: Tue, 27 Oct 2020 08:59:49 +0000 Message-ID: To: Neil Madden Cc: "Manger, James" , Denis , oauth Content-Type: multipart/alternative; boundary="0000000000009d1d1705b2a345ee" Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 09:00:05 -0000 --0000000000009d1d1705b2a345ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @James > While this text from Se=C3=A1n may be true, it is bad advice. It implies = we > should make access tokens as dangerous as possible (conveying all a > person=E2=80=99s authority) just to discourage sharing. > Is this implied because storing IDs with access logs means that ATs necessarily carry user ID information (possibly indirectly through an introspection endpoint)? I would note that the AT doesn't need to carry ID information itself, just enough information has to be stored with request logs to be able to later associate user IDs with requests. As a naive example, ATs could be stored with requests and mappings from user IDs to issued ATs could be stored on the AS. Ignoring the potential inefficiency/insecurity of such an approach, it allows user IDs to later be associated with requests without carrying such information in the AT itself= . Staff accessing a company=E2=80=99s whistle-blower service could be an exam= ple: > need a {staff:true} claim to combat spam/gossip; but definitely don=E2=80= =99t want > to include a staff id. > I think this is a good example of a scenario of wanting authZ without authN, thanks. What is applicable widely enough to mention in a BCP? And I would add, specific enough. It seems more like something that should exist in the "Security Considerations" section of a regular standard. @Neil But this can only discourage, not prevent, delegation. OAuth is after all a > delegation protocol. > Following on from your side quote, this is why I would say that it only reduces authZ sharing to authN sharing, because delegation can still be done even if it's "discouraged". If the RS allows anonymous requests then there is obviously no > accountability. Does that need to be explicitly mentioned? I think this is the crux of the issue. The "attack" then boils down to "if you don't have a means of identifying individuals that have made requests, then different individuals that know this might pretend to be the same individual". At which point the follow on would seem: if you care about this then add a "means of identifying individuals that have made requests". On Tue, 27 Oct 2020 at 06:26, Neil Madden wrote= : > It sounds like we=E2=80=99re trying to redefine cooperation/delegation as= an > =E2=80=9Cattack=E2=80=9D. People delegate and you can=E2=80=99t generally= prevent it without > incarceration. Anything Bob could do with Alice=E2=80=99s access token he= could > also do by asking Alice to do it on his behalf. In other words, any > credential/token sharing can be replaced by proxying: If Alice wants to > help underage Bob buy liquor she doesn=E2=80=99t have to share her access= token, > she can just buy it herself and give it to him. > > If the RS cares about accountability then the token (or some other means) > should identify the user - perhaps pseudonymously like OIDC pairwise > identifiers - and this should be logged for audit. But this can only > discourage, not prevent, delegation. OAuth is after all a delegation > protocol. > > (In the post-shame world we now live in, the idea that you can enforce > norms through identification seems almost quaint, but I=E2=80=99m not sur= e I=E2=80=99m > ready to be that cynical). > > If the RS allows anonymous requests then there is obviously no > accountability. Does that need to be explicitly mentioned? > > =E2=80=94 Neil > > On 27 Oct 2020, at 01:04, Manger, James > wrote: > > =EF=BB=BF > > It is worth mentioning =E2=80=9Cclient collaborative attacks=E2=80=9D or = =E2=80=9Cauthorization > sharing attacks=E2=80=9D because OAuth can make them easier (by packaging= authority > into an access token), compared to the alternative of user=E2=80=99s sign= ing-in to > an RS directly. But it is tricky to describe; none of the suggestions are > quite right; and the =E2=80=9Cright=E2=80=9D solution heavily depends on = the context. > > > > >> If access tokens are used to identify individuals, and such > identifying information (ideally user IDs) is stored with access logs for > auditing purposes, then this reduces this attack to an authentication > sharing attack. > > > > While this text from Se=C3=A1n may be true, it is bad advice. It implies = we > should make access tokens as dangerous as possible (conveying all a > person=E2=80=99s authority) just to discourage sharing. > > > > > Since OAuth 2.0 does not mandate the use of cryptographic devices, this > kind of attack cannot be countered in the general case. > > > > Even crypto devices aren=E2=80=99t a full solution. Alice can share her > authorization with Bob & Chris by signing-in with their crypto devices. > > > > > an access token =E2=80=A6 only stating that the holder =E2=80=A6 is ove= r 21 =E2=80=A6 should > not be accepted by the RS > > > > While this may generally be true for an =E2=80=9Cover 21=E2=80=9D claim, = it will not > always be true for other claims. In some situations the privacy risk of > being personally identified is far more important than any risk of client > collaboration. Staff accessing a company=E2=80=99s whistle-blower service= could be > an example: need a {staff:true} claim to combat spam/gossip; but definite= ly > don=E2=80=99t want to include a staff id. > > > > > > A handful of partial strategies appropriate in various circumstances (but > all with downsides) could include: > > 1. The AS ensures there is only 1 valid access token (or just a few) at > any point in time for a specific claim of a given user. > > 2. Access token bound to a crypto key locked to one device. > > 3. Each access token is unique (eg includes a "jti" claim) so an RS can > notice if the same token is presented in different contexts. > > 4. Access token with "sub" (or provides "sub" via token introspection) to > aid accountability (even if only in a later audit/investigation). > > 5. Frequent token replacement. > > 6. Nothing (beyond minimal necessary claims) =E2=80=93 to maximize privac= y. > > > > What is applicable widely enough to mention in a BCP? > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy --0000000000009d1d1705b2a345ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    @James
    =C2=A0
    While this text from=C2=A0Se= =C3=A1n may be true, it is bad advice. It implies we should make access tok= ens as dangerous as possible (conveying all a person=E2=80=99s authority) j= ust to discourage sharing.

    Is th= is implied because storing IDs with access logs means that ATs necessarily = carry user ID information (possibly indirectly through an introspection end= point)? I would note that the AT doesn't need to carry ID information i= tself, just enough information has to be stored with request logs to be abl= e to later associate user IDs with requests. As a naive example, ATs could = be stored with requests and mappings from user IDs to issued ATs could be s= tored on the AS. Ignoring the potential inefficiency/insecurity of such an = approach, it allows user IDs to later be associated with requests without c= arrying such information in the AT itself.

    Staff accessing a company=E2=80=99s w= histle-blower service could be an example: need a {staff:true} claim to com= bat spam/gossip; but definitely don=E2=80=99t want to include a staff id.

    I think this is a good example of a scen= ario of wanting authZ without authN, thanks.

    What is applicable widely enough to= mention in a BCP?

    And I would add, specifi= c enough. It seems more like something that should exist in the "Secur= ity Considerations" section of a regular standard.

    @Neil

    But this can only discourage, not prevent, delegation. OAuth is afte= r all a delegation protocol.

    Following = on from your side quote, this is why I would say that it only reduces authZ= sharing to authN sharing, because delegation can still be done even if it&= #39;s "discouraged".

    If the RS allows anonymous requests then there is= obviously no accountability. Does that need to be explicitly mentioned?

    I think this is the crux of the issue. The &q= uot;attack" then boils down to "if you don't have a means of = identifying individuals that have made requests, then different individuals= that know this might pretend to be the same individual". At which poi= nt the follow on would seem: if you care about this then add a "means = of identifying individuals that have made requests".

    On Tue, 27 O= ct 2020 at 06:26, Neil Madden <neil.madden@forgerock.com> wrote:
    It sounds l= ike we=E2=80=99re trying to redefine cooperation/delegation as an =E2=80=9C= attack=E2=80=9D. People delegate and you can=E2=80=99t generally prevent it= without incarceration. Anything Bob could do with Alice=E2=80=99s access t= oken he could also do by asking Alice to do it on his behalf. In other word= s, any credential/token sharing can be replaced by proxying: If Alice wants= to help underage Bob buy liquor she doesn=E2=80=99t have to share her acce= ss token, she can just buy it herself and give it to him.=C2=A0

    If the RS cares about accountability = then the token (or some other means) should identify the user - perhaps pse= udonymously like OIDC pairwise identifiers - and this should be logged for = audit. But this can only discourage, not prevent, delegation. OAuth is afte= r all a delegation protocol.=C2=A0

    (In the post-shame world we now live in, the idea that you can enf= orce norms through identification seems almost quaint, but I=E2=80=99m not = sure I=E2=80=99m ready to be that cynical).

    If the RS allows anonymous requests then there is obvious= ly no accountability. Does that need to be explicitly mentioned?

    =E2=80=94 Neil

    On 27 Oct 2020, at 01= :04, Manger, James <James.H.Manger@team.telstra.com> wrote:

    =EF=BB=BF

    It is worth mentioning =E2=80=9Cclient collabo= rative attacks=E2=80=9D or =E2=80=9Cauthorization sharing attacks=E2=80=9D = because OAuth can make them easier (by packaging authority into an access t= oken), compared to the alternative of user=E2=80=99s signing-in to an RS directly. But it is tricky to descri= be; none of the suggestions are quite right; and the =E2=80=9Cright=E2=80= =9D solution heavily depends on the context.

    =C2=A0

    >> If access tokens are used to i= dentify individuals, and such identifying information (ideally user IDs) is= stored with access logs for auditing purposes, then this reduces this atta= ck to an authentication sharing attack.

    =C2=A0

    While this text from Se=C3=A1n may be true, it is bad advice. It imp= lies we should make access tokens as dangerous as possible (conveying all a= person=E2=80=99s authority) just to discourage sharing.

    =C2=A0

    > Since OAuth 2.0 does not mandate the use of cryptographic device= s, this kind of attack cannot be countered in the general case.

    =C2=A0

    Even crypto devices aren=E2=80=99t a full solu= tion. Alice can share her authorization with Bob & Chris by signing-in = with their crypto devices.

    =C2=A0

    > an access token =E2=80=A6 only stating that the holder =E2=80=A6= is over 21 =E2=80=A6 should not be accepted by the RS<= u>

    =C2=A0

    While this may generally be true for an =E2=80= =9Cover 21=E2=80=9D claim, it will not always be true for other claims. In = some situations the privacy risk of being personally identified is far more= important than any risk of client collaboration. Staff accessing a company=E2=80=99s whis= tle-blower service could be an example: need a {staff:true} claim to combat= spam/gossip; but definitely don=E2=80=99t want to include a staff id.

    =C2=A0

    =C2=A0

    A handful of partial strategies appropriate in= various circumstances (but all with downsides) could include:

    1. The AS ensures there is only 1 valid access= token (or just a few) at any point in time for a specific claim of a given= user.

    2. Access token bound to a crypto key locked t= o one device.

    3. Each access token is unique (eg includes a = "jti" claim) so an RS can notice if the same token is presented i= n different contexts.

    4. Access token with "sub" (or provi= des "sub" via token introspection) to aid accountability (even if= only in a later audit/investigation).

    5. Frequent token replacement.

    6. Nothing (beyond minimal necessary claims) = =E2=80=93 to maximize privacy.

    =C2=A0

    What is applicable widely enough to mention in= a BCP?

    =C2=A0

    --

    James Manger

    _______________________________________________
    OAuth= mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/oauth

    ForgeRock values your Privacy
    --0000000000009d1d1705b2a345ee-- From nobody Tue Oct 27 06:17:34 2020 Return-Path: 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 D27273A09C9 for ; Tue, 27 Oct 2020 06:17:32 -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, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 D5xEgbZLw1a7 for ; Tue, 27 Oct 2020 06:17:31 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBD73A0994 for ; Tue, 27 Oct 2020 06:17:30 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 7406514624 for ; Tue, 27 Oct 2020 13:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603804647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dCZbQgfeAsa0BKN8G4PfqLW7KeMRrz8hTOYHcAHElew=; b=XocyzmCWsSXQcbkqvdFkFrzBkJORDez7jw3oq4BpnzEjkNF6HaAykE29lXZBHvgdCbVn+n zo+EF91pfgf1RmwXq3mLPrYX3RE81oViKfbhtoNPUcULbIFX6m88OnDnS7jRdF6al7zDHm TLq+aQ3lrGQjwjs7IvikTPI4Y2lpqUc= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <0e7842c8-5939-a0ce-0e24-2f7c776a3d44@danielfett.de> Date: Tue, 27 Oct 2020 14:17:26 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF742223277A178F05F6832C" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603804647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dCZbQgfeAsa0BKN8G4PfqLW7KeMRrz8hTOYHcAHElew=; b=gpjXmP5SEaLXI5fjkjpTULam5/WoWWrpW3oqcOirmzCD2fShCKZGmxwbjRPoCslep7jkLR Z0wEpD/vMR57bivs05mPrAQxDDBNHVRn9BOuQGjr0jcEjbmxK0gEYGNAB4obtV43P1a4Gs ORpRhVG/WcLE71MwtAw0hsPYtnFCIWs= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1603804647; a=rsa-sha256; cv=none; b=iaOWsPqbvB+k+GvOvdBsP8Oc2Xe8cBWkRbtd2gcpq3mJscgCG8Wsg+Z3501eXfM80J/Nwu k3JJt0v/h+lvS5zkIJwgFGNgDVNDBSdqKsOMEZ+4bBDIoXsbBq5llh/lxg7frBy64dxibD ZgUPSDIIUsjYiKb2Lpf3VAMkukGoqVI= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 13:17:33 -0000 This is a multi-part message in MIME format. --------------DF742223277A178F05F6832C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Neil, this very much sums up my thoughts on this topic. Since this has been mentioned in yesterday's call, I'll be happy to clarify in the attacker model that web attackers can collaborate to reach a common goal. I think we can also mention that sender-constraining does not prevent collaborating entities to share their tokens with each other. -Daniel Am 27.10.20 um 07:26 schrieb Neil Madden: > It sounds like we’re trying to redefine cooperation/delegation as an > “attack”. People delegate and you can’t generally prevent it without > incarceration. Anything Bob could do with Alice’s access token he > could also do by asking Alice to do it on his behalf. In other words, > any credential/token sharing can be replaced by proxying: If Alice > wants to help underage Bob buy liquor she doesn’t have to share her > access token, she can just buy it herself and give it to him.  > > If the RS cares about accountability then the token (or some other > means) should identify the user - perhaps pseudonymously like OIDC > pairwise identifiers - and this should be logged for audit. But this > can only discourage, not prevent, delegation. OAuth is after all a > delegation protocol.  > > (In the post-shame world we now live in, the idea that you can enforce > norms through identification seems almost quaint, but I’m not sure I’m > ready to be that cynical). > > If the RS allows anonymous requests then there is obviously no > accountability. Does that need to be explicitly mentioned? > > — Neil > >> On 27 Oct 2020, at 01:04, Manger, James >> wrote: >> >>  >> >> It is worth mentioning “client collaborative attacks” or >> “authorization sharing attacks” because OAuth can make them easier >> (by packaging authority into an access token), compared to the >> alternative of user’s signing-in to an RS directly. But it is tricky >> to describe; none of the suggestions are quite right; and the “right” >> solution heavily depends on the context. >> >>   >> >> >> If access tokens are used to identify individuals, and such >> identifying information (ideally user IDs) is stored with access logs >> for auditing purposes, then this reduces this attack to an >> authentication sharing attack. >> >>   >> >> While this text from Seán may be true, it is bad advice. It implies >> we should make access tokens as dangerous as possible (conveying all >> a person’s authority) just to discourage sharing. >> >>   >> >> > Since OAuth 2.0 does not mandate the use of cryptographic devices, >> this kind of attack cannot be countered in the general case. >> >>   >> >> Even crypto devices aren’t a full solution. Alice can share her >> authorization with Bob & Chris by signing-in with their crypto devices. >> >>   >> >> > an access token … only stating that the holder … is over 21 … should >> not be accepted by the RS >> >>   >> >> While this may generally be true for an “over 21” claim, it will not >> always be true for other claims. In some situations the privacy risk >> of being personally identified is far more important than any risk of >> client collaboration. Staff accessing a company’s whistle-blower >> service could be an example: need a {staff:true} claim to combat >> spam/gossip; but definitely don’t want to include a staff id. >> >>   >> >>   >> >> A handful of partial strategies appropriate in various circumstances >> (but all with downsides) could include: >> >> 1. The AS ensures there is only 1 valid access token (or just a few) >> at any point in time for a specific claim of a given user. >> >> 2. Access token bound to a crypto key locked to one device. >> >> 3. Each access token is unique (eg includes a "jti" claim) so an RS >> can notice if the same token is presented in different contexts. >> >> 4. Access token with "sub" (or provides "sub" via token >> introspection) to aid accountability (even if only in a later >> audit/investigation). >> >> 5. Frequent token replacement. >> >> 6. Nothing (beyond minimal necessary claims) – to maximize privacy. >> >>   >> >> What is applicable widely enough to mention in a BCP? >> >>   >> >> -- >> >> James Manger >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > ForgeRock values your Privacy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de --------------DF742223277A178F05F6832C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Thanks Neil, this very much sums up my thoughts on this topic.

    Since this has been mentioned in yesterday's call, I'll be happy to clarify in the attacker model that web attackers can collaborate to reach a common goal. I think we can also mention that sender-constraining does not prevent collaborating entities to share their tokens with each other.

    -Daniel

    Am 27.10.20 um 07:26 schrieb Neil Madden:
    It sounds like we’re trying to redefine cooperation/delegation as an “attack”. People delegate and you can’t generally prevent it without incarceration. Anything Bob could do with Alice’s access token he could also do by asking Alice to do it on his behalf. In other words, any credential/token sharing can be replaced by proxying: If Alice wants to help underage Bob buy liquor she doesn’t have to share her access token, she can just buy it herself and give it to him. 

    If the RS cares about accountability then the token (or some other means) should identify the user - perhaps pseudonymously like OIDC pairwise identifiers - and this should be logged for audit. But this can only discourage, not prevent, delegation. OAuth is after all a delegation protocol. 

    (In the post-shame world we now live in, the idea that you can enforce norms through identification seems almost quaint, but I’m not sure I’m ready to be that cynical).

    If the RS allows anonymous requests then there is obviously no accountability. Does that need to be explicitly mentioned?

    — Neil

    On 27 Oct 2020, at 01:04, Manger, James <James.H.Manger@team.telstra.com> wrote:

    

    It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions are quite right; and the “right” solution heavily depends on the context.

     

    >> If access tokens are used to identify individuals, and such identifying information (ideally user IDs) is stored with access logs for auditing purposes, then this reduces this attack to an authentication sharing attack.

     

    While this text from Seán may be true, it is bad advice. It implies we should make access tokens as dangerous as possible (conveying all a person’s authority) just to discourage sharing.

     

    > Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

     

    Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices.

     

    > an access token … only stating that the holder … is over 21 … should not be accepted by the RS

     

    While this may generally be true for an “over 21” claim, it will not always be true for other claims. In some situations the privacy risk of being personally identified is far more important than any risk of client collaboration. Staff accessing a company’s whistle-blower service could be an example: need a {staff:true} claim to combat spam/gossip; but definitely don’t want to include a staff id.

     

     

    A handful of partial strategies appropriate in various circumstances (but all with downsides) could include:

    1. The AS ensures there is only 1 valid access token (or just a few) at any point in time for a specific claim of a given user.

    2. Access token bound to a crypto key locked to one device.

    3. Each access token is unique (eg includes a "jti" claim) so an RS can notice if the same token is presented in different contexts.

    4. Access token with "sub" (or provides "sub" via token introspection) to aid accountability (even if only in a later audit/investigation).

    5. Frequent token replacement.

    6. Nothing (beyond minimal necessary claims) – to maximize privacy.

     

    What is applicable widely enough to mention in a BCP?

     

    --

    James Manger

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    ForgeRock values your Privacy 
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



    -- 
https://danielfett.de
    --------------DF742223277A178F05F6832C-- From nobody Tue Oct 27 07:05:22 2020 Return-Path: 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 E39D03A09EF for ; Tue, 27 Oct 2020 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 UhaLHbyOjbmQ for ; Tue, 27 Oct 2020 07:05:17 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DB23A0ACB for ; Tue, 27 Oct 2020 07:05:16 -0700 (PDT) Received: from [192.168.1.11] ([90.91.133.250]) by mwinf5d87 with ME id l25D2300e5QJY7u0325DoB; Tue, 27 Oct 2020 15:05:14 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 27 Oct 2020 15:05:14 +0100 X-ME-IP: 90.91.133.250 To: Daniel Fett , oauth@ietf.org References: <0e7842c8-5939-a0ce-0e24-2f7c776a3d44@danielfett.de> From: Denis Message-ID: Date: Tue, 27 Oct 2020 15:05:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0e7842c8-5939-a0ce-0e24-2f7c776a3d44@danielfett.de> Content-Type: multipart/alternative; boundary="------------A1CC9EC8B51113B8E5294B8B" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 14:05:21 -0000 This is a multi-part message in MIME format. --------------A1CC9EC8B51113B8E5294B8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, OK. The good news is that the BCP document will now address this issue. Let us wait to see which text you will propose. Yesterday, I wrote: "Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case". James Manger replied: "Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices". James is right. I should have use the term "secure element". When using secure elements /with specific properties/, it is possible to counter the Alice & Bob Collusion attack. A conversation took place on the OAuth mailing list on February 6, 2017. The following statements were made: "Sharing bearer tokens is a well known attack surface and there's really no way to stop that.   Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other". The same email also states: "There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing". So at this time, it seemed that one belief was "nothing can be done anyway". However, at least two solutions, using secure elements /with different specific properties/, exist. At the OAuth workshop in in Zürich in 2017, I presented a paper explaining how this could be done. It is still available at: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf For this workshop, I also proposed another paper (4 pages) with the following abstract, but only the first paper had been accepted: OAuth 2.0 was originally intended to be used for delegation but can also be used for access control. OAuth 2.0 is currently unable to defeat collusion attacks between clients, even if a secure element is being used to protect the corresponding private key or shared secret that is bound to the access token. This does not mean that OAuth 2.0 cannot be used any more, but that its applicability, in the field of access control, will be reduced to Identity-based Access Control (IBAC) which means that access tokens must contain a set of attributes that allows to unambiguously identify the token holder, otherwise a specific kind of attack, named the "Alice and Bob Collusion attack" is possible. I will create a new thread to discuss the end of my email from yesterday (/which has been deleted in this thread ... as well as the original message/): *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis > Thanks Neil, this very much sums up my thoughts on this topic. > > Since this has been mentioned in yesterday's call, I'll be happy to > clarify in the attacker model that web attackers can collaborate to > reach a common goal. I think we can also mention that > sender-constraining does not prevent collaborating entities to share > their tokens with each other. > > -Daniel > > Am 27.10.20 um 07:26 schrieb Neil Madden: >> It sounds like we’re trying to redefine cooperation/delegation as an >> “attack”. People delegate and you can’t generally prevent it without >> incarceration. Anything Bob could do with Alice’s access token he >> could also do by asking Alice to do it on his behalf. In other words, >> any credential/token sharing can be replaced by proxying: If Alice >> wants to help underage Bob buy liquor she doesn’t have to share her >> access token, she can just buy it herself and give it to him. >> >> If the RS cares about accountability then the token (or some other >> means) should identify the user - perhaps pseudonymously like OIDC >> pairwise identifiers - and this should be logged for audit. But this >> can only discourage, not prevent, delegation. OAuth is after all a >> delegation protocol. >> >> (In the post-shame world we now live in, the idea that you can >> enforce norms through identification seems almost quaint, but I’m not >> sure I’m ready to be that cynical). >> >> If the RS allows anonymous requests then there is obviously no >> accountability. Does that need to be explicitly mentioned? >> >> — Neil >> >>> On 27 Oct 2020, at 01:04, Manger, James >>> wrote: >>> >>>  >>> >>> It is worth mentioning “client collaborative attacks” or >>> “authorization sharing attacks” because OAuth can make them easier >>> (by packaging authority into an access token), compared to the >>> alternative of user’s signing-in to an RS directly. But it is tricky >>> to describe; none of the suggestions are quite right; and the >>> “right” solution heavily depends on the context. >>> >>> >> If access tokens are used to identify individuals, and such >>> identifying information (ideally user IDs) is stored with access >>> logs for auditing purposes, then this reduces this attack to an >>> authentication sharing attack. >>> >>> While this text from Seán may be true, it is bad advice. It implies >>> we should make access tokens as dangerous as possible (conveying all >>> a person’s authority) just to discourage sharing. >>> >>> > Since OAuth 2.0 does not mandate the use of cryptographic devices, >>> this kind of attack cannot be countered in the general case. >>> >>> Even crypto devices aren’t a full solution. Alice can share her >>> authorization with Bob & Chris by signing-in with their crypto devices. >>> >>> > an access token … only stating that the holder … is over 21 … should >>> not be accepted by the RS >>> >>> While this may generally be true for an “over 21” claim, it will not >>> always be true for other claims. In some situations the privacy risk >>> of being personally identified is far more important than any risk >>> of client collaboration. Staff accessing a company’s whistle-blower >>> service could be an example: need a {staff:true} claim to combat >>> spam/gossip; but definitely don’t want to include a staff id. >>> >>> A handful of partial strategies appropriate in various circumstances >>> (but all with downsides) could include: >>> >>> 1. The AS ensures there is only 1 valid access token (or just a few) >>> at any point in time for a specific claim of a given user. >>> >>> 2. Access token bound to a crypto key locked to one device. >>> >>> 3. Each access token is unique (eg includes a "jti" claim) so an RS >>> can notice if the same token is presented in different contexts. >>> >>> 4. Access token with "sub" (or provides "sub" via token >>> introspection) to aid accountability (even if only in a later >>> audit/investigation). >>> >>> 5. Frequent token replacement. >>> >>> 6. Nothing (beyond minimal necessary claims) – to maximize privacy. >>> >>> What is applicable widely enough to mention in a BCP? >>> >>> -- >>> >>> James Manger >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> ForgeRock values your Privacy >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------A1CC9EC8B51113B8E5294B8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Daniel,

    OK. The good news is that the BCP document will now address this issue. Let us wait to see which text you will propose.

    Yesterday, I wrote: "Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case".

     

    James Manger replied: "Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices".

    James is right. I should have use the term "secure element". When using secure elements with specific properties, it is possible to counter the Alice & Bob Collusion attack.

    A conversation took place on the OAuth mailing list on February 6, 2017. The following statements were made:
    "Sharing bearer tokens is a well known attack surface and there's really no way to stop that. 
      Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other".
    The same email also states:
    "There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing".
    So at this time, it seemed that one belief was "nothing can be done anyway". However, at least two solutions, using secure elements with different specific properties, exist.

    At the OAuth workshop in in Zürich in 2017, I presented a paper explaining how this could be done. It is still available at:
    https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

    For this workshop, I also proposed another paper (4 pages) with the following abstract, but only the first paper had been accepted:
    OAuth 2.0 was originally intended to be used for delegation but can also be used for access
    control. OAuth 2.0 is currently unable to defeat collusion attacks between clients, even if a secure element
    is being used to protect the corresponding private key or shared secret that is bound to the access token    .
    This does not mean that OAuth 2.0 cannot be used any more, but that its applicability, in the field of access
    control, will be reduced to Identity-based Access Control (IBAC) which means that access tokens must
    contain a set of attributes that allows to unambiguously identify the token holder, otherwise a specific kind of
    attack, named the "Alice and Bob Collusion attack" is possible.
    I will create a new thread to discuss the end of my email from yesterday (which has been deleted in this thread ... as well as the original message):
    Comment on section 4: "Validating JWT Access Tokens"

    The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token.
    However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token
    are indeed be present inside an access token.

    It might be useful to add it, so that the above text can refer to it.
    Denis

    Thanks Neil, this very much sums up my thoughts on this topic.

    Since this has been mentioned in yesterday's call, I'll be happy to clarify in the attacker model that web attackers can collaborate to reach a common goal. I think we can also mention that sender-constraining does not prevent collaborating entities to share their tokens with each other.

    -Daniel

    Am 27.10.20 um 07:26 schrieb Neil Madden:
    It sounds like we’re trying to redefine cooperation/delegation as an “attack”. People delegate and you can’t generally prevent it without incarceration. Anything Bob could do with Alice’s access token he could also do by asking Alice to do it on his behalf. In other words, any credential/token sharing can be replaced by proxying: If Alice wants to help underage Bob buy liquor she doesn’t have to share her access token, she can just buy it herself and give it to him. 

    If the RS cares about accountability then the token (or some other means) should identify the user - perhaps pseudonymously like OIDC pairwise identifiers - and this should be logged for audit. But this can only discourage, not prevent, delegation. OAuth is after all a delegation protocol. 

    (In the post-shame world we now live in, the idea that you can enforce norms through identification seems almost quaint, but I’m not sure I’m ready to be that cynical).

    If the RS allows anonymous requests then there is obviously no accountability. Does that need to be explicitly mentioned?

    — Neil

    On 27 Oct 2020, at 01:04, Manger, James <James.H.Manger@team.telstra.com> wrote:

    

    It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions are quite right; and the “right” solution heavily depends on the context.

     

    >> If access tokens are used to identify individuals, and such identifying information (ideally user IDs) is stored with access logs for auditing purposes, then this reduces this attack to an authentication sharing attack.

     

    While this text from Seán may be true, it is bad advice. It implies we should make access tokens as dangerous as possible (conveying all a person’s authority) just to discourage sharing.

     

    > Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

     

    Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices.

     

    > an access token … only stating that the holder … is over 21 … should not be accepted by the RS

     

    While this may generally be true for an “over 21” claim, it will not always be true for other claims. In some situations the privacy risk of being personally identified is far more important than any risk of client collaboration. Staff accessing a company’s whistle-blower service could be an example: need a {staff:true} claim to combat spam/gossip; but definitely don’t want to include a staff id.

     

     

    A handful of partial strategies appropriate in various circumstances (but all with downsides) could include:

    1. The AS ensures there is only 1 valid access token (or just a few) at any point in time for a specific claim of a given user.

    2. Access token bound to a crypto key locked to one device.

    3. Each access token is unique (eg includes a "jti" claim) so an RS can notice if the same token is presented in different contexts.

    4. Access token with "sub" (or provides "sub" via token introspection) to aid accountability (even if only in a later audit/investigation).

    5. Frequent token replacement.

    6. Nothing (beyond minimal necessary claims) – to maximize privacy.

     

    What is applicable widely enough to mention in a BCP?

     

    --

    James Manger

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    ForgeRock values your Privacy 
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



    -- 
https://danielfett.de

    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    --------------A1CC9EC8B51113B8E5294B8B-- From nobody Tue Oct 27 07:06:11 2020 Return-Path: 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 F37A93A0ACB for ; Tue, 27 Oct 2020 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.377 X-Spam-Level: X-Spam-Status: No, score=0.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no 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 bmZ182ZsIURq for ; Tue, 27 Oct 2020 07:06:08 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE5A3A09EF for ; Tue, 27 Oct 2020 07:06:08 -0700 (PDT) Received: from [192.168.1.11] ([90.91.133.250]) by mwinf5d87 with ME id l2662300X5QJY7u03266zV; Tue, 27 Oct 2020 15:06:06 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 27 Oct 2020 15:06:06 +0100 X-ME-IP: 90.91.133.250 To: oauth From: Denis Message-ID: <7921d02c-aba9-7e4d-692b-fa381a6bf680@free.fr> Date: Tue, 27 Oct 2020 15:06:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FC58D1613E1920001E6BFA7A" Content-Language: en-GB Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Access Token JWT Profile. Section 4: Validating JWT Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 14:06:10 -0000 This is a multi-part message in MIME format. --------------FC58D1613E1920001E6BFA7A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I create a new thread to discuss the end of my email from yesterday which has been deleted from the thread called " BCP: Client collaborative attacks": *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis --------------FC58D1613E1920001E6BFA7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    I create a new thread to discuss the end of my email from yesterday which has been deleted from the thread called " BCP: Client collaborative attacks":
    Comment on section 4: "Validating JWT Access Tokens"

    The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token.
    However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token
    are indeed be present inside an access token.

    It might be useful to add it, so that the above text can refer to it.
    Denis
    --------------FC58D1613E1920001E6BFA7A-- From nobody Wed Oct 28 03:08:30 2020 Return-Path: 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 1D1213A047D for ; Wed, 28 Oct 2020 03:08:29 -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, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 e3_BcOlefuGT for ; Wed, 28 Oct 2020 03:08:27 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABC93A0112 for ; Wed, 28 Oct 2020 03:08:27 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id DBC6814548 for ; Wed, 28 Oct 2020 10:08:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603879704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+RFc5HfQTh1iKjuR+/kRoI5ckF5QyyjnKIDleX919EA=; b=GKpL8WDMSPmVJEHUIuYwLsFz+FjMRuqCRaw67D9HXqzeRGgVA6WVizwYOyxMTX6yN8Cqmt shTln3yJBcZfferLyN1+bZs+Nx5heneH+HXShA9uhr59U02BxJ23GCCyyBC3OCUiX19o4r R6nLrRJUb9IuyuC5xmkM5kBXhXQ4edU= From: Daniel Fett To: oauth@ietf.org Message-ID: Date: Wed, 28 Oct 2020 11:08:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------58A99793222E896804F8CFAA" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603879705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=+RFc5HfQTh1iKjuR+/kRoI5ckF5QyyjnKIDleX919EA=; b=gj5ksysJzrYhmyTWBaTkfDfwPH8w1K9ZfaH6D8jXktULff+6WK6umew8rI/lV5ntqeVfwS fHiIQjcDaDdR6KkgtLgkt5d4NKzS55xR08XMdraQloLWyunUiYeo8QFD2NR9oamd7L8XoA YVeiQZgAddAR2xXhNM9HEetJhKpJvsY= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1603879705; a=rsa-sha256; cv=none; b=ie0frJCmGRYt0njbMoUpPy6I8IfPX+3RoldN215mi+RkopqZx1z5chYSU0D+GkhmiAOwi/ HC+TOl75LA+saFI3J463QgQsiFxdsTM8yHMH+MmHgRQRUHKHSpEFhkRjiUJT78DgW78MRl Z4oNatBGqiFDl0EWQzB9bkPlCAMntDQ= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: [OAUTH-WG] Mix-up mitigation is not so easy... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 10:08:29 -0000 This is a multi-part message in MIME format. --------------58A99793222E896804F8CFAA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, during my work to update the Security BCP, I stumbled upon a problem in our current recommendations against mix-up attacks. Until now, our understanding was that adding an "iss" parameter in the authorization response and using a distinct redirect URI for each configured issuer provided the same level of security. This is unfortunately not the case when mix-up is combined with a client impersonation attack. Let's start with the "iss" parameter: The assumption is, that an AS "knows" which issuer it belongs to. Therefore, an uncompromised AS will always send the identifier for this (correct) issuer in the "iss" parameter in the authorization response. The client will see that it started the process with the attacker's issuer, but receives the identifier for another issuer in the authorization response, and will abort the interaction. With the distinct redirect URIs, the situation is similar. Let's look at how the client would defend against mix-up: * For the attacker's AS configuration (attacker Authorization Endpoint, attacker Token Endpoint), the client would register https://client.com/redir/attacker as the redirection URI at the attacker's AS. * For the honest AS configuration (honest Authorization Endpoint, honest Token Endpoint), the client would register https://client.com/redir/honest as the redirection URI at the honest AS. In the normal mix-up attack, the following would happen: * The user selects "attacker" as AS. * The user is being redirected to the attacker's authorization endpoint. * The attacker redirects the user to the honest AS's authorization endpoint, replacing the client ID in the original authorization request with the client ID of the client at the honest AS. * The user authorizes the client at honest AS. * Honest AS redirects the user back to the client, using https://client.com/redir/honest as the redirect URI. * The client notices a mismatch between the redirection URI and the expected redirect URI (which would be .../attacker). Therefore, the mix-up attack is mitigated. The problem is, however, that the attacker can circumvent the protection by *registering a new client with the honest AS, giving https://client.com/redir/attacker as the redirection URI* and using this new client ID in step 3 of the attack. This would mean that the client would see the attacker's redirect URI as the incoming URI for the authorization response and would not detect the attack. It would forward the authorization code to the token endpoint of the attacker, who would be able to redeem it. Note that the user would not grant access to the honest client, but to the attacker's client. The attacker's client would need to "impersonate" the honest client, i.e., using the same name, icon, etc.; This approach is similar to existing OAuth phishing attacks with counterfeit clients, however, in this case, a *redirect URI of the honest client* is used. Therefore, the usual mitigation whereby the AS shows the redirect URI to the user would not provide any protection (see also https://tools.ietf.org/html/rfc6819#section-3.5). What can we do against this attack? * PKCE does not protect against this attack, as the attacker would be able to change the code_challenge parameter. * I think that PAR and JAR probably won't help either, since the honest client "legitimately" speaks to the attacker's AS, who in turn speaks "legitimately" to the honest AS (as the attacker's client). All sides would use the correct endpoints and keys, and the attacker would be able to receive and modify the authorization request, forwarding it to the honest AS under his own client ID. * For the same reason, a DPoP-like sender-constraining of the authorization code is unlikely to help. * What would help is if client registrations would depend on an ACME-like demonstration of control over the origin of the redirect URI. This not something mandated for OAuth today and is unlikely to be seen in broad use. * The "iss" parameter solution is robust against this attack as long as an authorization server never returns an issuer controlled by the attacker. In essence, by declaring the issuer, the AS is providing a pointer to a metadata file which points to the "correct" token endpoint - this is why this solution is robust. We have shown the robustness of the "iss" solution in our formal analysis, but never analyzed the redirect uri solution formally. For the security BCP, this means that we depend on the "iss" parameter solution even more. (It also means that OAuth 2.1 should probably include this parameter.) We need to think about how we can proceed with the security BCP without too much delay.  Sorry for poking another hole into the spec, Daniel -- https://danielfett.de --------------58A99793222E896804F8CFAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi all,

    during my work to update the Security BCP, I stumbled upon a problem in our current recommendations against mix-up attacks.

    Until now, our understanding was that adding an "iss" parameter in the authorization response and using a distinct redirect URI for each configured issuer provided the same level of security. This is unfortunately not the case when mix-up is combined with a client impersonation attack.

    Let's start with the "iss" parameter: The assumption is, that an AS "knows" which issuer it belongs to. Therefore, an uncompromised AS will always send the identifier for this (correct) issuer in the "iss" parameter in the authorization response. The client will see that it started the process with the attacker's issuer, but receives the identifier for another issuer in the authorization response, and will abort the interaction.

    With the distinct redirect URIs, the situation is similar. Let's look at how the client would defend against mix-up:

    • For the attacker's AS configuration (attacker Authorization Endpoint, attacker Token Endpoint), the client would register https://client.com/redir/attacker as the redirection URI at the attacker's AS.
    • For the honest AS configuration (honest Authorization Endpoint, honest Token Endpoint), the client would register https://client.com/redir/honest as the redirection URI at the honest AS.

    In the normal mix-up attack, the following would happen:

    • The user selects "attacker" as AS.
    • The user is being redirected to the attacker's authorization endpoint.
    • The attacker redirects the user to the honest AS's authorization endpoint, replacing the client ID in the original authorization request with the client ID of the client at the honest AS.
    • The user authorizes the client at honest AS.
    • Honest AS redirects the user back to the client, using https://client.com/redir/honest as the redirect URI.
    • The client notices a mismatch between the redirection URI and the expected redirect URI (which would be .../attacker).

    Therefore, the mix-up attack is mitigated. The problem is, however, that the attacker can circumvent the protection by registering a new client with the honest AS, giving https://client.com/redir/attacker as the redirection URI and using this new client ID in step 3 of the attack.

    This would mean that the client would see the attacker's redirect URI as the incoming URI for the authorization response and would not detect the attack. It would forward the authorization code to the token endpoint of the attacker, who would be able to redeem it.

    Note that the user would not grant access to the honest client, but to the attacker's client. The attacker's client would need to "impersonate" the honest client, i.e., using the same name, icon, etc.; This approach is similar to existing OAuth phishing attacks with counterfeit clients, however, in this case, a redirect URI of the honest client is used. Therefore, the usual mitigation whereby the AS shows the redirect URI to the user would not provide any protection (see also https://tools.ietf.org/html/rfc6819#section-3.5).

    What can we do against this attack?

    • PKCE does not protect against this attack, as the attacker would be able to change the code_challenge parameter.
    • I think that PAR and JAR probably won't help either, since the honest client "legitimately" speaks to the attacker's AS, who in turn speaks "legitimately" to the honest AS (as the attacker's client). All sides would use the correct endpoints and keys, and the attacker would be able to receive and modify the authorization request, forwarding it to the honest AS under his own client ID.
    • For the same reason, a DPoP-like sender-constraining of the authorization code is unlikely to help.
    • What would help is if client registrations would depend on an ACME-like demonstration of control over the origin of the redirect URI. This not something mandated for OAuth today and is unlikely to be seen in broad use.
    • The "iss" parameter solution is robust against this attack as long as an authorization server never returns an issuer controlled by the attacker. In essence, by declaring the issuer, the AS is providing a pointer to a metadata file which points to the "correct" token endpoint - this is why this solution is robust. We have shown the robustness of the "iss" solution in our formal analysis, but never analyzed the redirect uri solution formally.

    For the security BCP, this means that we depend on the "iss" parameter solution even more. (It also means that OAuth 2.1 should probably include this parameter.)

    We need to think about how we can proceed with the security BCP without too much delay. 

    Sorry for poking another hole into the spec,
    Daniel

    -- 
https://danielfett.de
    --------------58A99793222E896804F8CFAA-- From nobody Wed Oct 28 04:00:20 2020 Return-Path: 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 6F4943A0A82 for ; Wed, 28 Oct 2020 04:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 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, HTML_MESSAGE=0.001, SHORTENED_URL_HREF=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch 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 YO5tYc41XF-c for ; Wed, 28 Oct 2020 04:00:17 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 669813A0A80 for ; Wed, 28 Oct 2020 04:00:17 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id k6so4291225ilq.2 for ; Wed, 28 Oct 2020 04:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tfLPGuiLq9V5kASwnRvmIgu+ajlHvGtU/n3boWmGfHI=; b=IfadGvvhcUQDLNxLk/mj09QTTHTOA5fUCKnGaTpko7NrKGECCo5lxXg8JSt3YxpdFG s25Fe+Ywh6e0Q2Br0m1x8TTBwWeILXOfvW1IvWT8M7NLlLvXNgdY3bbwYLfg1h3FVZm9 w7uS/o985oBzt9Im8FfNyct9CgAxO8RWn1WRw= 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=tfLPGuiLq9V5kASwnRvmIgu+ajlHvGtU/n3boWmGfHI=; b=IATah29GN1DPYhxQq6g9x3liLjSauU5g0LvYQBlk37BN5I/MVMoKZFKXEOkoCerjTh xTpZ/Ixct5XPuBshMKXZGOO3XpbU3IeAmBWuAo3xFvjNn+s9qGZmDRMkC3zLdaRIBO1b 2JIgj9Kgw+rca4LnhnKnnzNPwwIODml2HqDypgLgvGiB7ZUAIhglBdwotWFU61chDccS XxiATt2Maj6WnjdVfpbKJNj4+qIZCerBDkMx0cphTG9zO8rJTm+Fjk0y5Q5/guwmfH+B obrB9GxJehmHeuUEdqIK0wC1+T3ffyUiUXJAlZ5hMVl+9bksy+j0Er2qUylyKXG9hMMG gQ0A== X-Gm-Message-State: AOAM530ILNzRL8DEsG3xWT6nPr+AYMuBurFsqyy3iS8Jy35GQLznSVEp ZqC4RqezHp+8kQ+6S2mQkBH7LiH/LYG84D7koxYv X-Google-Smtp-Source: ABdhPJwkNGQUKjjBvVh2Xgt2EGe00vlv0JoOj7nV68aE9kWbBjZxzwjiP3Vu0yCKhSKG/a5oYgILmGcymkA/i45iQEw= X-Received: by 2002:a92:c529:: with SMTP id m9mr5093133ili.195.1603882816470; Wed, 28 Oct 2020 04:00:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Wed, 28 Oct 2020 12:00:05 +0100 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="000000000000899a7105b2b911e7" Archived-At: Subject: Re: [OAUTH-WG] Mix-up mitigation is not so easy... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 11:00:19 -0000 --000000000000899a7105b2b911e7 Content-Type: text/plain; charset="UTF-8" I would likewise assume that issuer validation is always required. But maybe I hadn't been thinking about this enough. Is there an alternative to validating it, and implicitly trusting it? Because as you pointed out either demonstrated control over valid redirect URIs or really any other secondary mechanism would be required. Perhaps I'm missing something though. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett wrote: > Hi all, > > during my work to update the Security BCP, I stumbled upon a problem in > our current recommendations against mix-up attacks. > > Until now, our understanding was that adding an "iss" parameter in the > authorization response and using a distinct redirect URI for each > configured issuer provided the same level of security. This is > unfortunately not the case when mix-up is combined with a client > impersonation attack. > > Let's start with the "iss" parameter: The assumption is, that an AS > "knows" which issuer it belongs to. Therefore, an uncompromised AS will > always send the identifier for this (correct) issuer in the "iss" parameter > in the authorization response. The client will see that it started the > process with the attacker's issuer, but receives the identifier for another > issuer in the authorization response, and will abort the interaction. > > With the distinct redirect URIs, the situation is similar. Let's look at > how the client would defend against mix-up: > > - For the attacker's AS configuration (attacker Authorization > Endpoint, attacker Token Endpoint), the client would register > https://client.com/redir/attacker as the redirection URI at the > attacker's AS. > - For the honest AS configuration (honest Authorization Endpoint, > honest Token Endpoint), the client would register > https://client.com/redir/honest as the redirection URI at the honest > AS. > > In the normal mix-up attack, the following would happen: > > - The user selects "attacker" as AS. > - The user is being redirected to the attacker's authorization > endpoint. > - The attacker redirects the user to the honest AS's authorization > endpoint, replacing the client ID in the original authorization request > with the client ID of the client at the honest AS. > - The user authorizes the client at honest AS. > - Honest AS redirects the user back to the client, using > https://client.com/redir/honest as the redirect URI. > - The client notices a mismatch between the redirection URI and the > expected redirect URI (which would be .../attacker). > > Therefore, the mix-up attack is mitigated. The problem is, however, that > the attacker can circumvent the protection by *registering a new client > with the honest AS, giving https://client.com/redir/attacker > as the redirection URI* and using > this new client ID in step 3 of the attack. > > This would mean that the client would see the attacker's redirect URI as > the incoming URI for the authorization response and would not detect the > attack. It would forward the authorization code to the token endpoint of > the attacker, who would be able to redeem it. > > Note that the user would not grant access to the honest client, but to the > attacker's client. The attacker's client would need to "impersonate" the > honest client, i.e., using the same name, icon, etc.; This approach is > similar to existing OAuth phishing attacks with counterfeit clients, > however, in this case, a *redirect URI of the honest client* is used. > Therefore, the usual mitigation whereby the AS shows the redirect URI to > the user would not provide any protection (see also > https://tools.ietf.org/html/rfc6819#section-3.5). > > What can we do against this attack? > > - PKCE does not protect against this attack, as the attacker would be > able to change the code_challenge parameter. > - I think that PAR and JAR probably won't help either, since the > honest client "legitimately" speaks to the attacker's AS, who in turn > speaks "legitimately" to the honest AS (as the attacker's client). All > sides would use the correct endpoints and keys, and the attacker would be > able to receive and modify the authorization request, forwarding it to the > honest AS under his own client ID. > - For the same reason, a DPoP-like sender-constraining of the > authorization code is unlikely to help. > - What would help is if client registrations would depend on an > ACME-like demonstration of control over the origin of the redirect URI. > This not something mandated for OAuth today and is unlikely to be seen in > broad use. > - The "iss" parameter solution is robust against this attack as long > as an authorization server never returns an issuer controlled by the > attacker. In essence, by declaring the issuer, the AS is providing a > pointer to a metadata file which points to the "correct" token endpoint - > this is why this solution is robust. We have shown the robustness of the > "iss" solution in our formal analysis, but never analyzed the redirect uri > solution formally. > > For the security BCP, this means that we depend on the "iss" parameter > solution even more. (It also means that OAuth 2.1 should probably include > this parameter.) > > We need to think about how we can proceed with the security BCP without > too much delay. > > Sorry for poking another hole into the spec, > Daniel > > -- https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000899a7105b2b911e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I would likewise assume that issuer validation is alw= ays required. But maybe I hadn't been thinking about this enough. Is th= ere an alternative to validating it, and implicitly trusting it? Because as= you pointed out either demonstrated control over valid redirect URIs or re= ally any other secondary mechanism would be required. Perhaps I'm missi= ng something though.

    Warren Parad

    Founder, CTO

    Secure your user data and complete = your authorization architecture. Implement=C2=A0Authress.

    On Wed, O= ct 28, 2020 at 11:08 AM Daniel Fett <fett@danielfett.de> wrote:
    =20 =20 =20

    Hi all,

    during my work to update the Security BCP, I stumbled upon a problem in our current recommendations against mix-up attacks.

    Until now, our understanding was that adding an "iss" para= meter in the authorization response and using a distinct redirect URI for each configured issuer provided the same level of security. This is unfortunately not the case when mix-up is combined with a client impersonation attack.

    Let's start with the "iss" parameter: The assumption i= s, that an AS "knows" which issuer it belongs to. Therefore, an uncomp= romised AS will always send the identifier for this (correct) issuer in the "iss" parameter in the authorization response. The clie= nt will see that it started the process with the attacker's issuer, but receives the identifier for another issuer in the authorization response, and will abort the interaction.

    With the distinct redirect URIs, the situation is similar. Let's look at how the client would defend against mix-up:

    • For the attacker's AS configuration (attacker Authorization Endpoint, attacker Token Endpoint), the client would register htt= ps://client.com/redir/attacker as the redirection URI at the attacker's AS.
    • For the honest AS configuration (honest Authorization Endpoint, honest Token Endpoint), the client would register https= ://client.com/redir/honest as the redirection URI at the honest AS.

    In the normal mix-up attack, the following would happen:

    • The user selects "attacker" as AS.
    • The user is being redirected to the attacker's authorization endpoint.
    • The attacker redirects the user to the honest AS's authorization endpoint, replacing the client ID in the original authorization request with the client ID of the client at the honest AS.
    • The user authorizes the client at honest AS.
    • Honest AS redirects the user back to the client, using https= ://client.com/redir/honest as the redirect URI.
    • The client notices a mismatch between the redirection URI and the expected redirect URI (which would be .../attacker).

    Therefore, the mix-up attack is mitigated. The problem is, however, that the attacker can circumvent the protection by regist= ering a new client with the honest AS, giving htt= ps://client.com/redir/attacker as the redirection URI and using this new client ID in step 3 of the attack.

    This would mean that the client would see the attacker's redirec= t URI as the incoming URI for the authorization response and would not detect the attack. It would forward the authorization code to the token endpoint of the attacker, who would be able to redeem it.

    Note that the user would not grant access to the honest client, but to the attacker's client. The attacker's client would nee= d to "impersonate" the honest client, i.e., using the same name,= icon, etc.; This approach is similar to existing OAuth phishing attacks with counterfeit clients, however, in this case, a redirect URI of the honest client is used. Therefore, the usual mitigation whereby the AS shows the redirect URI to the user would not provide any protection (see also https://tools.ietf.org/html/rfc6819#section-3.5).

    What can we do against this attack?

    • PKCE does not protect against this attack, as the attacker would be able to change the code_challenge parameter.
    • I think that PAR and JAR probably won't help either, since th= e honest client "legitimately" speaks to the attacker's= AS, who in turn speaks "legitimately" to the honest AS (as the attac= ker's client). All sides would use the correct endpoints and keys, and the attacker would be able to receive and modify the authorization request, forwarding it to the honest AS under his own client ID.
    • For the same reason, a DPoP-like sender-constraining of the authorization code is unlikely to help.
    • What would help is if client registrations would depend on an ACME-like demonstration of control over the origin of the redirect URI. This not something mandated for OAuth today and is unlikely to be seen in broad use.
    • The "iss" parameter solution is robust against this att= ack as long as an authorization server never returns an issuer controlled by the attacker. In essence, by declaring the issuer, the AS is providing a pointer to a metadata file which points to the "correct" token endpoint - this is why this solution = is robust. We have shown the robustness of the "iss" solutio= n in our formal analysis, but never analyzed the redirect uri solution formally.

    For the security BCP, this means that we depend on the "iss&quo= t; parameter solution even more. (It also means that OAuth 2.1 should probably include this parameter.)

    We need to think about how we can proceed with the security BCP without too much delay.=C2=A0

    Sorry for poking another hole into the spec,
    Daniel

    --=20
https://danielfett.de
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --000000000000899a7105b2b911e7-- From nobody Wed Oct 28 04:58:53 2020 Return-Path: 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 211793A0EDE for ; Wed, 28 Oct 2020 04:58:52 -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, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de 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 5-qDNIpW3njL for ; Wed, 28 Oct 2020 04:58:50 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91653A0EDB for ; Wed, 28 Oct 2020 04:58:49 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id CD1F5145CC; Wed, 28 Oct 2020 11:58:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603886326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=j72Rny2Z6kGQgiSWmweUi3r/btouqF1QH82nnWmv7q8=; b=N8OgzkF1stGqUnK4dhAF6Wo7OdTNIllX+Or9k4bShwnRb+nAhdYNZd/MYujiBueJJXOPJF Fn4+Pdj3XW1ain8ik93Q8kggfnnzN6fYJcXMIOt7HPG48I9sKuclfytKTJDJ2UNsiphkj/ 3SrjAmQ/gel+1eoBLOqrwmgQvOhxKdc= To: Warren Parad Cc: oauth References: From: Daniel Fett Message-ID: <9209bd4b-1f9e-6b8e-c395-68da53b14517@danielfett.de> Date: Wed, 28 Oct 2020 12:58:46 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7230DEED32813171162EA3F8" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1603886327; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=j72Rny2Z6kGQgiSWmweUi3r/btouqF1QH82nnWmv7q8=; b=i2Fwyclq9KQt2tKNK0kjkO55x10cj/7qREu3dAyJyCIRUiXvR/NOkJh1vO2iEljqkmuskY ka4X80UL/MtcanfWAGwhyyzwi5oD0NqavZNw6iDabf7UBRxfcP81mnFxQZcheUK4SW0dEI txeyFIjdiOtim5Xw5gQndXlg6z5af7g= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1603886327; a=rsa-sha256; cv=none; b=oJ5c4M25fVA8rQvP1LLdYv49Fh6uOlnCQ+/mtXHO05uC6GDSX3f76/wi33izHBBJza4J2u RZyKGe3PebBxw0O39v7FwxUsiF+PlWnEpYER1Lmwwj9tpd7VzqnmPYIy8GUlzJqQRjcGV1 vwm3CzwnwEZoorNKLIBQ7NhmlEFfHbY= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Mix-up mitigation is not so easy... X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 11:58:52 -0000 This is a multi-part message in MIME format. --------------7230DEED32813171162EA3F8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 28.10.20 um 12:00 schrieb Warren Parad: > I would likewise assume that issuer validation is always required. But > maybe I hadn't been thinking about this enough. Is there an > alternative to validating it, and implicitly trusting it? Because as > you pointed out either demonstrated control over valid redirect URIs > or really any other secondary mechanism would be required. Perhaps I'm > missing something though. When using "iss" to mitigate mix-up attacks, we're essentially telling the client where submitting the auth code is okay. Since this chain of pointers starts at the AS (→ issuer ID → metadata document → token endpoint URL), there's no further validation needed: In this direction, we can assume that every pointer points to an uncompromised component. A malicious issuer could mix and match PAR/authorization/token/userinfo endpoint URLs and thereby build a different chain, but I think there's really not that much that can go wrong there that wouldn't be covered by the "iss" defense: https://danielfett.de/2020/05/04/mix-up-revisited/ -Daniel > On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett > wrote: > > Hi all, > > during my work to update the Security BCP, I stumbled upon a > problem in our current recommendations against mix-up attacks. > > Until now, our understanding was that adding an "iss" parameter in > the authorization response and using a distinct redirect URI for > each configured issuer provided the same level of security. This > is unfortunately not the case when mix-up is combined with a > client impersonation attack. > > Let's start with the "iss" parameter: The assumption is, that an > AS "knows" which issuer it belongs to. Therefore, an uncompromised > AS will always send the identifier for this (correct) issuer in > the "iss" parameter in the authorization response. The client will > see that it started the process with the attacker's issuer, but > receives the identifier for another issuer in the authorization > response, and will abort the interaction. > > With the distinct redirect URIs, the situation is similar. Let's > look at how the client would defend against mix-up: > > * For the attacker's AS configuration (attacker Authorization > Endpoint, attacker Token Endpoint), the client would register > https://client.com/redir/attacker as the redirection URI at > the attacker's AS. > * For the honest AS configuration (honest Authorization > Endpoint, honest Token Endpoint), the client would register > https://client.com/redir/honest as the redirection URI at the > honest AS. > > In the normal mix-up attack, the following would happen: > > * The user selects "attacker" as AS. > * The user is being redirected to the attacker's authorization > endpoint. > * The attacker redirects the user to the honest AS's > authorization endpoint, replacing the client ID in the > original authorization request with the client ID of the > client at the honest AS. > * The user authorizes the client at honest AS. > * Honest AS redirects the user back to the client, using > https://client.com/redir/honest as the redirect URI. > * The client notices a mismatch between the redirection URI and > the expected redirect URI (which would be .../attacker). > > Therefore, the mix-up attack is mitigated. The problem is, > however, that the attacker can circumvent the protection by > *registering a new client with the honest AS, giving > https://client.com/redir/attacker as the redirection URI* and > using this new client ID in step 3 of the attack. > > This would mean that the client would see the attacker's redirect > URI as the incoming URI for the authorization response and would > not detect the attack. It would forward the authorization code to > the token endpoint of the attacker, who would be able to redeem it. > > Note that the user would not grant access to the honest client, > but to the attacker's client. The attacker's client would need to > "impersonate" the honest client, i.e., using the same name, icon, > etc.; This approach is similar to existing OAuth phishing attacks > with counterfeit clients, however, in this case, a *redirect URI > of the honest client* is used. Therefore, the usual mitigation > whereby the AS shows the redirect URI to the user would not > provide any protection (see also > https://tools.ietf.org/html/rfc6819#section-3.5). > > What can we do against this attack? > > * PKCE does not protect against this attack, as the attacker > would be able to change the code_challenge parameter. > * I think that PAR and JAR probably won't help either, since the > honest client "legitimately" speaks to the attacker's AS, who > in turn speaks "legitimately" to the honest AS (as the > attacker's client). All sides would use the correct endpoints > and keys, and the attacker would be able to receive and modify > the authorization request, forwarding it to the honest AS > under his own client ID. > * For the same reason, a DPoP-like sender-constraining of the > authorization code is unlikely to help. > * What would help is if client registrations would depend on an > ACME-like demonstration of control over the origin of the > redirect URI. This not something mandated for OAuth today and > is unlikely to be seen in broad use. > * The "iss" parameter solution is robust against this attack as > long as an authorization server never returns an issuer > controlled by the attacker. In essence, by declaring the > issuer, the AS is providing a pointer to a metadata file which > points to the "correct" token endpoint - this is why this > solution is robust. We have shown the robustness of the "iss" > solution in our formal analysis, but never analyzed the > redirect uri solution formally. > > For the security BCP, this means that we depend on the "iss" > parameter solution even more. (It also means that OAuth 2.1 should > probably include this parameter.) > > We need to think about how we can proceed with the security BCP > without too much delay.  > > Sorry for poking another hole into the spec, > Daniel > > -- > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- https://danielfett.de --------------7230DEED32813171162EA3F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Am 28.10.20 um 12:00 schrieb Warren Parad:
    I would likewise assume that issuer validation is always required. But maybe I hadn't been thinking about this enough. Is there an alternative to validating it, and implicitly trusting it? Because as you pointed out either demonstrated control over valid redirect URIs or really any other secondary mechanism would be required. Perhaps I'm missing something though.

    When using "iss" to mitigate mix-up attacks, we're essentially telling the client where submitting the auth code is okay. Since this chain of pointers starts at the AS (→ issuer ID → metadata document → token endpoint URL), there's no further validation needed: In this direction, we can assume that every pointer points to an uncompromised component.

    A malicious issuer could mix and match PAR/authorization/token/userinfo endpoint URLs and thereby build a different chain, but I think there's really not that much that can go wrong there that wouldn't be covered by the "iss" defense: https://danielfett.de/2020/05/04/mix-up-revisited/

    -Daniel


    On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett <fett@danielfett.de> wrote:

    Hi all,

    during my work to update the Security BCP, I stumbled upon a problem in our current recommendations against mix-up attacks.

    Until now, our understanding was that adding an "iss" parameter in the authorization response and using a distinct redirect URI for each configured issuer provided the same level of security. This is unfortunately not the case when mix-up is combined with a client impersonation attack.

    Let's start with the "iss" parameter: The assumption is, that an AS "knows" which issuer it belongs to. Therefore, an uncompromised AS will always send the identifier for this (correct) issuer in the "iss" parameter in the authorization response. The client will see that it started the process with the attacker's issuer, but receives the identifier for another issuer in the authorization response, and will abort the interaction.

    With the distinct redirect URIs, the situation is similar. Let's look at how the client would defend against mix-up:

    • For the attacker's AS configuration (attacker Authorization Endpoint, attacker Token Endpoint), the client would register https://client.com/redir/attacker as the redirection URI at the attacker's AS.
    • For the honest AS configuration (honest Authorization Endpoint, honest Token Endpoint), the client would register https://client.com/redir/honest as the redirection URI at the honest AS.

    In the normal mix-up attack, the following would happen:

    • The user selects "attacker" as AS.
    • The user is being redirected to the attacker's authorization endpoint.
    • The attacker redirects the user to the honest AS's authorization endpoint, replacing the client ID in the original authorization request with the client ID of the client at the honest AS.
    • The user authorizes the client at honest AS.
    • Honest AS redirects the user back to the client, using https://client.com/redir/honest as the redirect URI.
    • The client notices a mismatch between the redirection URI and the expected redirect URI (which would be .../attacker).

    Therefore, the mix-up attack is mitigated. The problem is, however, that the attacker can circumvent the protection by registering a new client with the honest AS, giving https://client.com/redir/attacker as the redirection URI and using this new client ID in step 3 of the attack.

    This would mean that the client would see the attacker's redirect URI as the incoming URI for the authorization response and would not detect the attack. It would forward the authorization code to the token endpoint of the attacker, who would be able to redeem it.

    Note that the user would not grant access to the honest client, but to the attacker's client. The attacker's client would need to "impersonate" the honest client, i.e., using the same name, icon, etc.; This approach is similar to existing OAuth phishing attacks with counterfeit clients, however, in this case, a redirect URI of the honest client is used. Therefore, the usual mitigation whereby the AS shows the redirect URI to the user would not provide any protection (see also https://tools.ietf.org/html/rfc6819#section-3.5).

    What can we do against this attack?

    • PKCE does not protect against this attack, as the attacker would be able to change the code_challenge parameter.
    • I think that PAR and JAR probably won't help either, since the honest client "legitimately" speaks to the attacker's AS, who in turn speaks "legitimately" to the honest AS (as the attacker's client). All sides would use the correct endpoints and keys, and the attacker would be able to receive and modify the authorization request, forwarding it to the honest AS under his own client ID.
    • For the same reason, a DPoP-like sender-constraining of the authorization code is unlikely to help.
    • What would help is if client registrations would depend on an ACME-like demonstration of control over the origin of the redirect URI. This not something mandated for OAuth today and is unlikely to be seen in broad use.
    • The "iss" parameter solution is robust against this attack as long as an authorization server never returns an issuer controlled by the attacker. In essence, by declaring the issuer, the AS is providing a pointer to a metadata file which points to the "correct" token endpoint - this is why this solution is robust. We have shown the robustness of the "iss" solution in our formal analysis, but never analyzed the redirect uri solution formally.

    For the security BCP, this means that we depend on the "iss" parameter solution even more. (It also means that OAuth 2.1 should probably include this parameter.)

    We need to think about how we can proceed with the security BCP without too much delay. 

    Sorry for poking another hole into the spec,
    Daniel

    -- 
https://danielfett.de
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    -- 
https://danielfett.de
    --------------7230DEED32813171162EA3F8-- From nobody Wed Oct 28 09:51:37 2020 Return-Path: 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 F008D3A047D for ; Wed, 28 Oct 2020 09:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TKCatzk2uEkD for ; Wed, 28 Oct 2020 09:51:33 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 BA08B3A005E for ; Wed, 28 Oct 2020 09:51:33 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id r9so20137ioo.7 for ; Wed, 28 Oct 2020 09:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jaMrA4PH3/B8JDc64wMYYgFf9jHqVNrOsSFu8iAENYc=; b=dw0VHgL0LjhyQ+YpY053mrRrhCc0G27hSYj5gKfVOyugqJYcMpFUx+BnAo2z38lqNf WjS9aIbYn4UibfmOaUYMgGFDUqQYLBWJF/pn9QKR+0kCYhnUJJG9XsYsfM9/FyrrDs5I yktUY5dIVWTiDz9tsy++BJk5xe70OxciwkmSRw4B2XAYEPLV4vpPkhgDylmCMLZxbII8 Gj2pk1Qxue+ai8409lO2vHAKdF98nV+kLKMp2VKS2IatN1iAhRZmMgkqTdHv95QgACP7 PCPJ2srjUZvt6HyCBQZAS6s7zAHmb+HV/wpIChqgXmBaOT4/YJxZMFKUDpwzCBlC69uw 7saA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jaMrA4PH3/B8JDc64wMYYgFf9jHqVNrOsSFu8iAENYc=; b=bvOVmT5y+pEZDVqgaUa6IuUheEvBoigm1NKX2xCbAOpm9ITUi7ZxPXoqrTj0ofj5DT ZSygJy5RtOZHo+SNFZdef19+A2AWWj2EmiQX/fQjsyW5HLyVUfFd+alddeGUJeb1m4ro KVSLPfWS0cgs8JdO3ybKQmeNN1mZYM8p5AMpYpQLxaUbRECqHmJBXJ+2s/lUT8Pp3Hzn NrzUKKv3A2tJ8kcLmmITda/xbc6hzPtgvkiu73lpWumJnSLb65Kf3vo9KByYlnjqZ1kB 8FmdZdDrtZWGw6bc5+FZs7VJIIHzDh0r56gUZC8LDob9OYoIGPbeDC15kOq+Rii2qqS7 WA1A== X-Gm-Message-State: AOAM5308ogponY7EYtmrF5hBC/np1SlXI+obpfQYzehYWOS7WD2LQfnY 2Yqacqg3wHPOSpZlh3vlgIjrFViPCNd58kZJt9uwW8Ow8Y5YPQ== X-Google-Smtp-Source: ABdhPJxVz+CnnUhjpfwjZdNtjOtJj1sJiLu6SIO8olXkmQYVIqcgRLzdMbUw+UOf7c54sJ+U8rNa+30L/AbghpIbkxY= X-Received: by 2002:a6b:dc0f:: with SMTP id s15mr241767ioc.180.1603903892330; Wed, 28 Oct 2020 09:51:32 -0700 (PDT) MIME-Version: 1.0 From: Roberto Polli Date: Wed, 28 Oct 2020 17:51:21 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c19e7505b2bdf916" Archived-At: Subject: [OAUTH-WG] Providing feedback to OAuth2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:51:35 -0000 --000000000000c19e7505b2bdf916 Content-Type: text/plain; charset="UTF-8" Hi everybody, I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo (eg. like https://github.com/httpwg/http-core) where I can see the open issues, catch up with the discussion and discuss PRs? Thanks for your hard work and have a nice day, R: --000000000000c19e7505b2bdf916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi everybody,

    I'd like to provide s= ome feedback to=C2=A0draft-ietf-oauth-v2-1. Is there a repo
    (eg. = like=C2=A0https://github.co= m/httpwg/http-core) where I can see the open issues,
    catch up= with the discussion and discuss PRs?

    Thanks for y= our hard=C2=A0work and have a nice day,
    R:

    --000000000000c19e7505b2bdf916-- From nobody Wed Oct 28 09:56:19 2020 Return-Path: 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 E753C3A0799 for ; Wed, 28 Oct 2020 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=parecki.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 2W4kugIdTt4i for ; Wed, 28 Oct 2020 09:56:16 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 54B5E3A0769 for ; Wed, 28 Oct 2020 09:56:11 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id q1so122622ilt.6 for ; Wed, 28 Oct 2020 09:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MAwaqz5KdYD9jUB1PxgoOkBARS6ZL0Www1Xulyw+2bw=; b=pV9gIHK7WU7OsPrhqPeGcY9A9vx2sGyS5kWm8gTJiyVSQ7I6tTh+L1So6UsvtE0MaU jc9T73JS9kewxVtpoT4ZTgAbppn8CIgDBdYQUcCT49aHzhDOw9RNXi/CMQQVJfhFsPxm O9diZQdB374Zkrdhc/FKNvYaY+4ASs016H8Vv9/CgoA8tjci+TSzmXNAaYJ8vpl5wO8d oCUvlJh1tiRmti+tYFIT/Q/AIFnkxGN9hCOfSF0g1eBOe+8d5ojEScqsMM03rXJAVwM3 n2oZL1PtMy4ieG3aunrLDnj5hix0dliEATqlGmywoMTzuMKCd6lC4AKbgt27K3U5VviP 3DPQ== 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=MAwaqz5KdYD9jUB1PxgoOkBARS6ZL0Www1Xulyw+2bw=; b=oBR8mr+FAnkb8lhIQWe/cL7zKI3/nrVjgmkfFbOy4jmGi6t4yJeksvHR9jpTk91XiN QEglcApgoycyqu1Lx8JSycIRpmJY3at+5lBsL9hNRPExQbc8dCvCfayfzn0+XW84BAbd iSpdc9V1P00sm+/teqWnR6YrMEM+P2WHN1+iLvR5ZCDnEX7/Vh0pBi+UXw2N4NRzgL39 mXR/2dneQSgplDNyEKCeXIiDNVBh2/CnS7BQ/7Q+9JTfvFSLBvrYTN7Tvd/GZY2Oshfb dsib/T2xfb/tkPqTCNleCnF+x6ZMDQanH60iHsSiYQkxdE+EPJkNG3BvS+HkPBB6OuTX QTIQ== X-Gm-Message-State: AOAM530A/tQPpm2O9xYaIwUIgyBYSiG7flyy1HUtfTBgu0irfgLNf333 ImdbYppAdFcmzH60nmwzexjgTFDjlqyzCw== X-Google-Smtp-Source: ABdhPJxOtBVVY6Fn4qRjlLsL+Zmcl/1O1+MsZico+w0gUN3aIR3Gb77NeUGYR/L+VKebGOyz7JwiwQ== X-Received: by 2002:a92:6608:: with SMTP id a8mr7963ilc.128.1603904170055; Wed, 28 Oct 2020 09:56:10 -0700 (PDT) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com. [209.85.166.48]) by smtp.gmail.com with ESMTPSA id r4sm25794ilj.43.2020.10.28.09.56.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 09:56:09 -0700 (PDT) Received: by mail-io1-f48.google.com with SMTP id p15so84121ioh.0 for ; Wed, 28 Oct 2020 09:56:09 -0700 (PDT) X-Received: by 2002:a5d:9819:: with SMTP id a25mr267765iol.156.1603904169108; Wed, 28 Oct 2020 09:56:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 28 Oct 2020 09:55:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Roberto Polli Cc: OAuth WG Content-Type: multipart/alternative; boundary="00000000000040e91105b2be0a08" Archived-At: Subject: Re: [OAUTH-WG] Providing feedback to OAuth2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:56:18 -0000 --00000000000040e91105b2be0a08 Content-Type: text/plain; charset="UTF-8" Hi Roberto, The authors are keeping track of open discussions on this GitHub repo https://github.com/aaronpk/oauth-v2-1 If you'd like to provide feedback on the record, then this email list is the best place for that. You're also welcome to open issues on the GitHub repo, but that is an unofficial forum and will be seen by basically just the authors. --- Aaron Parecki https://aaronparecki.com On Wed, Oct 28, 2020 at 9:51 AM Roberto Polli wrote: > Hi everybody, > > I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo > (eg. like https://github.com/httpwg/http-core) where I can see the open > issues, > catch up with the discussion and discuss PRs? > > Thanks for your hard work and have a nice day, > R: > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000040e91105b2be0a08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Roberto,

    The authors are keeping track of open = discussions on this GitHub repo=C2=A0https://github.com/aaronpk/oauth-v2-1

    <= div>If you'd like to provide feedback on the record, then this email li= st is the best place for that. You're also welcome to open issues on th= e GitHub repo, but that is an unofficial forum and will be seen by basicall= y just the authors.

    ---Aaron Parecki

    =
    On Wed= , Oct 28, 2020 at 9:51 AM Roberto Polli <robipolli@gmail.com> wrote:
    Hi everybody,

    I'd like to provide some feedback to=C2=A0draft-ietf-oauth-v2-1. Is t= here a repo
    (eg. like=C2=A0https://github.com/httpwg/http-core) where = I can see the open issues,
    catch up with the discussion and discu= ss PRs?

    Thanks for your hard=C2=A0work and have a = nice day,
    R:

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --00000000000040e91105b2be0a08-- From nobody Wed Oct 28 10:45:46 2020 Return-Path: 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 AE6A53A0769 for ; Wed, 28 Oct 2020 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 0NCT8HVZcOpV for ; Wed, 28 Oct 2020 10:45:43 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 EF9173A067A for ; Wed, 28 Oct 2020 10:45:42 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id e2so120881wme.1 for ; Wed, 28 Oct 2020 10:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=NRlW+gTUtipUxv4asJZOGfLVZ6gTM7J0TSaqsJfJFq0=; b=jTMc/KE5rQ3Ea6ZANTK9GTvZ9SuxZziRTdVMpQRsGDYupF+2gf+l8Qx7OAHatJjtg3 l65R2YFk50lzb8dOW3pwk83HtLPsaCg/zzwQsH0OJHjeTGNc9mqrRUnqgEdZF+0hp3Y9 aeQ8PxQ/DaiIkf53h4Xf8IXLGv0rPSUc0S0IG/BTTrtfr5pp5NPVkr4bCjKQFZqZNPqe H2P4asAQMrp5ftPCqY8jxlylCrCSye64P5KfvfKi6nJZkE5eFQfZ3/St+c2TNln9LyHY ilq+VMaLWsKrEqPNoCQNq0jbt4uJua1S+hNrPoepzg32e39nJ36tpb+IrzoQxQdJ/qeX r4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=NRlW+gTUtipUxv4asJZOGfLVZ6gTM7J0TSaqsJfJFq0=; b=INHk2wLkGF4oekFttRk2ULtNljC6o+6Rq9mCzNOOCw8Alb8gEta+RJTU5HesN96PUA WfXv1olvpjRHg9KVBjQnSkufLS3m9Au17bu7D0NgDiFaoe2ztOAoUo0dusjatDW7HPae SX2cxqPGIDPkUSACRWEvkP2Uyoo546vtogFEWqSJLiZ7ecBSFU4uRVEYNrNkIqspOIkJ YxtiZ67MNsm4GZ4x+ZToQ6C3ZTY7irlvVwmjEuAdjd4/v5doo9lkVZKohEucrAafgWTL oWrA75Eu/RY1HsN6jx/cs9zbe2zf5rr0B50UM7KsqXY36ncMLwPHYzqVfSskdPCHiEk7 Jvuw== X-Gm-Message-State: AOAM531dKc84FNyM4WncwRpaC5hwkxIUU1TlDWbzABAhbaApUAz5kTJ3 kG9UG2b8GoKXiC8BH8PUtaU= X-Google-Smtp-Source: ABdhPJyXejIcWhegRppChvliJngxLpyszVUbddgPDPv74dHhY5ua8XYYHHwouEVzIZCCGDpZrwbqlA== X-Received: by 2002:a1c:1d92:: with SMTP id d140mr627874wmd.48.1603907141117; Wed, 28 Oct 2020 10:45:41 -0700 (PDT) Received: from [10.5.0.2] ([89.238.186.252]) by smtp.gmail.com with ESMTPSA id e25sm345845wra.71.2020.10.28.10.45.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2020 10:45:40 -0700 (PDT) Date: Wed, 28 Oct 2020 23:59:10 +0700 From: INsomplan347 To: Roberto Polli , Aaron Parecki Cc: OAuth WG Message-ID: In-Reply-To: References: X-Readdle-Message-ID: aa09af46-89eb-43c4-ba73-e70dfe628ad8@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f99ae3f_4310d5f8_2423" Archived-At: Subject: Re: [OAUTH-WG] Providing feedback to OAuth2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 17:45:45 -0000 --5f99ae3f_4310d5f8_2423 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline excusme hello all itu error kok gak selesai2 ya On 28 Okt 2020 23.56 +0700, Aaron Parecki , wrote: > Hi Roberto, > > The authors are keeping track of open discussions on this GitHub repo=C2= =A0https://github.com/aaronpk/oauth-v2-1 > > If you'd like to provide feedback on the record, then this email list i= s the best place for that. You're also welcome to open issues on the GitH= ub repo, but that is an unofficial forum and will be seen by basically ju= st the authors. > > --- > Aaron Parecki > https://aaronparecki.com > > > On Wed, Oct 28, 2020 at 9:51 AM Roberto Polli w= rote: > > Hi everybody, > > > > I'd like to provide some feedback to=C2=A0draft-ietf-oauth-v2-1. Is t= here a repo > > (eg. like=C2=A0https://github.com/httpwg/http-core) where I can see t= he open issues, > > catch up with the discussion and discuss PRs=3F > > > > Thanks for your hard=C2=A0work and have a nice day, > > R: > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth --5f99ae3f_4310d5f8_2423 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    excusme hello all itu error kok gak selesai2 ya&=23= 160;
    On 28 Okt 2020 23.56 +0700, Aaron Parecki <aaron= =40parecki.com>, wrote:
    Hi Ro= berto,

    The a= uthors are keeping track of open discussions on this GitHub repo&=23160;<= a href=3D=22https://github.com/aaronpk/oauth-v2-1=22 target=3D=22=5Fblank= =22>https://github.com/aaronpk/oauth-v2-1

    If yo= u'd like to provide feedback on the record, then this email list is the b= est place for that. You're also welcome to open issues on the GitHub repo= , but that is an unofficial forum and will be seen by basically just the = authors.

    ---
    Aaron= Parecki
    https://aaron= parecki.com


    On We= d, Oct 28, 2020 at 9:51 AM Roberto Polli <robipolli=40gmail.com> wr= ote:
    Hi e= verybody,

    I'd = like to provide some feedback to&=23160;draft-ietf-oauth-v2-1. Is there a= repo
    (eg.= like&=23160;https://github.com/httpwg/http-core) where I can see t= he open issues,
    catc= h up with the discussion and discuss PRs=3F

    Than= ks for your hard&=23160;work and have a nice day,
    R:

    =5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
    =
    OAut= h mailing list
    OAuth=40ietf.= org
    https://www.ietf.org/mailman/listinfo/oauth
    =5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
    =
    OAuth= mailing list
    OAuth= =40ietf.org
    https= ://www.ietf.org/mailman/listinfo/oauth
    --5f99ae3f_4310d5f8_2423-- From nobody Wed Oct 28 13:46:27 2020 Return-Path: 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 6A4F23A09BD for ; Wed, 28 Oct 2020 13:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 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_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 qmj6MfXSp7kw for ; Wed, 28 Oct 2020 13:46:25 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 D2A4D3A09B5 for ; Wed, 28 Oct 2020 13:46:24 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id m20so697254ljj.5 for ; Wed, 28 Oct 2020 13:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XYxNDxsJr8Dme1ahrEHK0/xugC3t5rSNjk0WPmpqVK4=; b=fOLz1v7yST+hSXXMx4+oj9L4Z+7Al+2LwuzjkvY5nt8zku66HTpNzv+3qZAsdxnYOk sJ8CcN+EZ2nailKfXWrKOD+Ue2uHO+Jd2FwFGcec5St/I5n3rQBHbn8FtyRbhDu3s9So BU+brtV7cQ30aYP8mCXChfuHS0y0xNrPpm+oJuSlieDUfRP6YEZnxyNXQ4gpJE0fMB68 3LRF1RHSS6RnlgYFsZjwWOiEw28fSTSgKIlTxKxXqkpsbP9mahqxV86NasD5P1AK2YF8 xV2rJbmQSrvBzs8uk6A0ZxjLqBkOP769jOpe8wiVkNwPjmdkkmmP42SDPHDsDG3qeiLX xLQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XYxNDxsJr8Dme1ahrEHK0/xugC3t5rSNjk0WPmpqVK4=; b=nsW+32Q9blIfoHJwgDlm8OiO3KZtOlttBi5svtgkcU76wfFMGEOg1XmJfRfYB1O/oa UCnKXckQp2pTdZ4/Aba7NTDyFYkLBG+54swmhAE7Gb5nicI0auD1IN/EllV8fhg9dTex ix9cFzeRHjo5huFonJ+qzaTF+NAXRqKiOCGOxsj5GRvHoo1aefnZ1VEy3ZgZ06HRF9EX ljKOpweGfFIuFnLAKzgRg2I/IUTRH0lPIopF6p52ediHDX1Td4sREao32E4q4hogbTe8 5657ag56em4FQmZVREI+lzDexgsQUNXp3G1w2dYgRVgRVi4X3bmkoWpDsVIEv1gsa0Qt eDWw== X-Gm-Message-State: AOAM5327u0ZJOnIMHvPLzp/CzDUTCAKl1zvKW8P1SHshE1IQoJI2vHfq ICSpPAd5d/fRnE9qazxdkzIpoROtgfgqdPUWrfpq/A9RTff51w== X-Google-Smtp-Source: ABdhPJwRMQypBws6XHwVI9XOVJNxTlB59sHtm5mS/QX3iLqZopEQ/g4h7Sq1S+jOhCrI+nl7Zl6su83KF7fBvUPKT2Q= X-Received: by 2002:a2e:9a17:: with SMTP id o23mr462106lji.242.1603917982533; Wed, 28 Oct 2020 13:46:22 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Wed, 28 Oct 2020 13:45:45 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000990bc105b2c14155" Archived-At: Subject: [OAUTH-WG] DPoP and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:46:27 -0000 --000000000000990bc105b2c14155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello I was reviewing the latest DPoP draft[1] and saw numerous mentions of using a DPoP proof for refreshing an access token, but no explicit description of how to do that, nor an example. Was this intentional? Perhaps a new section "Refreshing an Access Token"? Additionally, I can imagine that an AS can improve its security posture by adding support for DPoP *just* to token refresh and not requiring existing resource servers to upgrade. Rotating refresh tokens would not be as critical for public clients using DPoP for token refresh. Would using DPoP only for token refresh be appropriate? If so, language describing that would be helpful. :) /Dick [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 =E1=90=A7 --000000000000990bc105b2c14155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello

    I was reviewing the latest=C2=A0D= PoP draft[1] and saw numerous mentions of using a DPoP proof for refreshing= an access token, but no explicit description of how to do that, nor an exa= mple. Was this intentional?

    Perhaps=C2=A0a new sec= tion=C2=A0"Refreshing an Access Token"?

    = Additionally, I can imagine that an AS can improve its security posture by = adding support for DPoP *just* to token refresh and not requiring existing = resource servers to upgrade. Rotating refresh tokens would not be as critic= al for public clients using DPoP for token refresh.=C2=A0

    Would using DPoP only for token refresh be appropriate? If so, lang= uage describing that would be helpful. :)

    --000000000000990bc105b2c14155-- From nobody Wed Oct 28 15:20:52 2020 Return-Path: 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 EDE0A3A0925 for ; Wed, 28 Oct 2020 15:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=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 rd3ZRjkQUTkz for ; Wed, 28 Oct 2020 15:20:49 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 12AFD3A08F6 for ; Wed, 28 Oct 2020 15:20:48 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id 141so803887lfn.5 for ; Wed, 28 Oct 2020 15:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P6VGBDl4ySB1VPTg8MdmZ9BjH5oO5C1ZoAUb7nKBhU0=; b=bzaDzyONsGOhOB21cxz2HOJBvpM4dRVn5ECV0+nzbYsoq2sjrX0qHV7bN+7k9q7+3I 7MOKhiBpxLc+WUodxX4SaOrv5rGV1FVoIwj45UoB8hueMZXsIDPyTZangGld1VnYY712 0N0nef6a2hBVNQik+7MP/d8sobPn4COIZoHcnlG40Iv+7Gx9g9B45AVgFT3fQMNO0WV/ 1B9AlxKYukiegqK/cDefSpRVn16pZmY+l++JEKt7n20X0KXM4Jx8TmKSedE9q3R5TTi3 ycRN9Yfpy4tzs8qvr0gDqFIcEdexHt7e1wq/PjF+VPVb372iEo1u4P4VOrkRpGVfZUeB gzuQ== 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=P6VGBDl4ySB1VPTg8MdmZ9BjH5oO5C1ZoAUb7nKBhU0=; b=XPwb9otNV7h2QJ4pQGJN9BtyMttq9ZseJeekpD3eUqMh5YXU3NmQkZ9wvE1Muf8grf q/8LEPqF84jV8KIDKmKr288eGr0scuNlpJdeTWNsl9y42FAF6qFY4gJEPXNNSJbuYuqp mHZRWwdP8xingjXQclMDjeXLAmvrH9Ei4Gkw45YQ+B4hITOjdJ1oSGP2rvoibJSUq9eQ lKLmNMX035s8E1r9TM1MpIN8p3Co1Uu0IqfsraCIf0Ww92hzfHdfzO/8jrKY+4n4Xdip 8L1x2L9uTekm4NKpfJWj2YSslcwFoz1ziFK0oPUV1Nw5cetpMXRR98FSX4ZggGMl/zYQ ytqA== X-Gm-Message-State: AOAM531ajGfRAFMsnWVLqbsmAIzLyM+LDQgVRvc6srnmKKodiEt000lw xamwpMl9jZjboueaxWhUKNM91eK86Ie/PvJgMfuNwBWYWO5rN2m6LPiZjalt/LxAjQwpF7hYww3 kHbGhKolBsVDW9Q== X-Google-Smtp-Source: ABdhPJypbeEAdIIIWJ9P1qEyeDpDjeWVyt0UFTYVKj4430LXNSYvKAVSVOeHoUlV3mWYWsd40+bVmq2bRzA58AKvcNQ= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr406601lfe.560.1603923646992; Wed, 28 Oct 2020 15:20:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 28 Oct 2020 16:20:20 -0600 Message-ID: To: Dick Hardt Cc: oauth Content-Type: multipart/alternative; boundary="00000000000039f43705b2c2935b" Archived-At: Subject: Re: [OAUTH-WG] DPoP and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 22:20:51 -0000 --00000000000039f43705b2c2935b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm currently working on the draft and hope to have a new revision published relatively soon. Just the other day I made some changes to the text around RTs with https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d963= 11fac44986974 that maybe/hopefully makes some of it more clear? But basically the RTs are only bound for public clients and the exact mechanism to do it is left up to the AS. The AS both creates and consumes the RT so however it chooses to associate the DPoP key with the RT is its own implementation detail. Getting a new bound access token using an RT is meant to be covered in sec 5 "Token Request (Binding Tokens to a Public Key)" with RT being just one of the grants that could be presented in the token request in conjunction with the DPoP proof, and the AS would bind the AT it issues to the key in that DPoP proof. I'd sort of assumed that would just be understood. But do you think it (including the recent changes) needs more explanation? I do think using DPoP only for token refresh (only for public clients though) would be appropriate, for some cases anyway. This has come up on the list here previously and the general consensus was also that it'd be useful. I plan to add some language describing that (and loosening some language that could be perceived as prohibiting it) but haven't gotten to that item on the editing todo list yet. On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt wrote: > Hello > > I was reviewing the latest DPoP draft[1] and saw numerous mentions of > using a DPoP proof for refreshing an access token, but no explicit > description of how to do that, nor an example. Was this intentional? > > Perhaps a new section "Refreshing an Access Token"? > > Additionally, I can imagine that an AS can improve its security posture b= y > adding support for DPoP *just* to token refresh and not requiring existin= g > resource servers to upgrade. Rotating refresh tokens would not be as > critical for public clients using DPoP for token refresh. > > Would using DPoP only for token refresh be appropriate? If so, language > describing that would be helpful. :) > > /Dick > > [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 > =E1=90=A7 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000039f43705b2c2935b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm currently working on the draft and hope to ha= ve a new revision published relatively soon. Just the other day I made some= changes to the text around RTs with https://gith= ub.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac4498697= 4 that maybe/hopefully makes some of it more clear? But basically the R= Ts are only bound for public clients and the exact mechanism to do it is le= ft up to the AS. The AS both creates and consumes the RT so however it choo= ses to associate the DPoP key with the RT is its own implementation detail.= Getting a new bound access token using an RT is meant to be covered in sec= 5 "Token Request (Binding Tokens to a Public Key)" with RT being= just one of the grants that could be presented in the token request in con= junction with the DPoP proof, and the AS would bind the AT it issues to the= key in that DPoP proof. I'd sort of assumed that would just be underst= ood. But do you think it (including the recent changes) needs more explanat= ion?

    I do think using DPoP only for token ref= resh (only for public clients though) would be appropriate, for some cases = anyway. This has come up on the list here previously and the general consen= sus was also that it'd be useful. I plan to add some language describin= g that (and loosening some language that could be perceived as prohibiting = it) but haven't gotten to that item on the editing todo list yet.
    <= /div>




    On Wed, Oct 28, 2020 at 2= :46 PM Dick Hardt <dick.hardt@gm= ail.com> wrote:
    Hello

    I was reviewing the latest= =C2=A0DPoP draft[1] and saw numerous mentions of using a DPoP proof for ref= reshing an access token, but no explicit description of how to do that, nor= an example. Was this intentional?

    Perhaps=C2=A0a = new section=C2=A0"Refreshing an Access Token"?

    Additionally, I can imagine that an AS can improve its security post= ure by adding support for DPoP *just* to token refresh and not requiring ex= isting resource servers to upgrade. Rotating refresh tokens would not be as= critical for public clients using DPoP for token refresh.=C2=A0
    =
    Would using DPoP only for token refresh be appropriate? If s= o, language describing that would be helpful. :)

    /= Dick

    3D""=E1=90=A7 _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000039f43705b2c2935b-- From nobody Wed Oct 28 15:35:55 2020 Return-Path: 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 928CD3A0976 for ; Wed, 28 Oct 2020 15:35:53 -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 jjG-WGsUeEDQ for ; Wed, 28 Oct 2020 15:35:51 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 6834F3A0975 for ; Wed, 28 Oct 2020 15:35:51 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p15so959561ljj.8 for ; Wed, 28 Oct 2020 15:35:51 -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; bh=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=sGOfIB44HH78lmc4rKWWs0onHGAZbyKmTUEFCxWf14m8VPXSqiiwN+C5j+Bi2r+qiO nRvma9gC+uuFSkf8UJuIxyz5w6E3gT7gliys7m230TLIw3vRh7OAUuRlPqbE8w933ZgO rGCyoHbCzM4kKmVECVKw103UnO1326xrHR75FmtE8cZaRl1fJmzrkiI5W6CwGXmUQV9x f3WsOZ/uCszYXsP0OZErKpsMAzcnjTvEq3qYAqX51J0Bqd/SAmkAlkhfb7Key053HS7P 870yhEBQIdzTQ7ljYtYwQRHKmUSKc7+NJ5uw4MeVxmnd9NXjoL1EZT5VGMKYPSDFQP4N kucw== 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=PUgJhOO/G/Av8zYZEDQ3NJZ7yia6nTTM9patQYJyCoE=; b=KyeutyVk0kcsLqSb58wEYJjE0KoxjnUw9LGL0A/xE1DrsQkExXo3b7JUf8llbyCiO0 I8xt93YjJiXbvyaWgg1HykltdBDJ8j4hzOEbKEbe7Ax2RCLD8apa/Un3udJnPl0nH3bY wgoVP5CIjen1oMaao/Lk6zdOpneAgKvRBw0ZaX/OCvtefocaMQCRweUYKUxUnzhOzpRc vaYTZuLLAe2LhgB1Wb8BjOcWSrGiIv8oGH4jrbNDa/X3BugrrWVExyspG2EU92AOE+Q0 XUn5LAcs9sJTH6SZGdmEi5RJpSXuqPXdK96VrU3YtMwTNBOakdHHZknIeB9xg6HCqwpy gziQ== X-Gm-Message-State: AOAM531kUb+d8qWk5FgRxb35nqSbK9Aip0CRYyIdUdqoRoiZGY0Ku4+A +xCFkfj8InXVVvCj3yly3wKTIHZ+jTjOcJBVZOk= X-Google-Smtp-Source: ABdhPJwvheSroASMrCHCBVnVvKOakk0FPNECmf4pBb5wVh+V0UblxJXS1FfDM5EiXXUsIV5r9VInXP1eehmX+MC+Lzw= X-Received: by 2002:a2e:9a17:: with SMTP id o23mr612213lji.242.1603924549429; Wed, 28 Oct 2020 15:35:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 28 Oct 2020 15:35:13 -0700 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="00000000000003eeff05b2c2c906" Archived-At: Subject: Re: [OAUTH-WG] DPoP and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 22:35:54 -0000 --00000000000003eeff05b2c2c906 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Brian A refresh example would make it more clear, and would also assist in communicating that DPoP could be used just for refresh. I see in the updated text that using DPoP with confidential clients is discouraged. I understand the RT is sender constrained -- but asymmetric cryptography is much stronger than a shared secret. Why discourage its use? =E1=90=A7 On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell wrote: > I'm currently working on the draft and hope to have a new revision > published relatively soon. Just the other day I made some changes to the > text around RTs with > https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d9= 6311fac44986974 > that maybe/hopefully makes some of it more clear? But basically the RTs a= re > only bound for public clients and the exact mechanism to do it is left up > to the AS. The AS both creates and consumes the RT so however it chooses = to > associate the DPoP key with the RT is its own implementation detail. > Getting a new bound access token using an RT is meant to be covered in se= c > 5 "Token Request (Binding Tokens to a Public Key)" with RT being just one > of the grants that could be presented in the token request in conjunction > with the DPoP proof, and the AS would bind the AT it issues to the key in > that DPoP proof. I'd sort of assumed that would just be understood. But d= o > you think it (including the recent changes) needs more explanation? > > I do think using DPoP only for token refresh (only for public clients > though) would be appropriate, for some cases anyway. This has come up on > the list here previously and the general consensus was also that it'd be > useful. I plan to add some language describing that (and loosening some > language that could be perceived as prohibiting it) but haven't gotten to > that item on the editing todo list yet. > > > > > On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt wrote: > >> Hello >> >> I was reviewing the latest DPoP draft[1] and saw numerous mentions of >> using a DPoP proof for refreshing an access token, but no explicit >> description of how to do that, nor an example. Was this intentional? >> >> Perhaps a new section "Refreshing an Access Token"? >> >> Additionally, I can imagine that an AS can improve its security posture >> by adding support for DPoP *just* to token refresh and not requiring >> existing resource servers to upgrade. Rotating refresh tokens would not = be >> as critical for public clients using DPoP for token refresh. >> >> Would using DPoP only for token refresh be appropriate? If so, language >> describing that would be helpful. :) >> >> /Dick >> >> [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 >> =E1=90=A7 >> _______________________________________________ >> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --00000000000003eeff05b2c2c906 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey Brian

    A refresh example would make = it more clear, and would also assist in communicating that DPoP could be us= ed just for refresh.

    I see in the updated text tha= t using DPoP with confidential clients is discouraged. I understand the RT = is sender constrained -- but asymmetric=C2=A0cryptography is much stronger = than a shared secret. Why discourage its use?


    =


    3D""=E1=90=A7
    On Wed, = Oct 28, 2020 at 3:20 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
    I'm curre= ntly working on the draft and hope to have a new revision published relativ= ely soon. Just the other day I made some changes to the text around RTs wit= h https://github.com/danielfett= /draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974 that maybe/= hopefully makes some of it more clear? But basically the RTs are only bound= for public clients and the exact mechanism to do it is left up to the AS. = The AS both creates and consumes the RT so however it chooses to associate = the DPoP key with the RT is its own implementation detail. Getting a new bo= und access token using an RT is meant to be covered in sec 5 "Token Re= quest (Binding Tokens to a Public Key)" with RT being just one of the = grants that could be presented in the token request in conjunction with the= DPoP proof, and the AS would bind the AT it issues to the key in that DPoP= proof. I'd sort of assumed that would just be understood. But do you t= hink it (including the recent changes) needs more explanation?

    I do think using DPoP only for token refresh (only for pu= blic clients though) would be appropriate, for some cases anyway. This has = come up on the list here previously and the general consensus was also that= it'd be useful. I plan to add some language describing that (and loose= ning some language that could be perceived as prohibiting it) but haven'= ;t gotten to that item on the editing todo list yet.




    On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt= <dick.hardt@g= mail.com> wrote:
    Hello

    I was reviewing the lates= t=C2=A0DPoP draft[1] and saw numerous mentions of using a DPoP proof for re= freshing an access token, but no explicit description of how to do that, no= r an example. Was this intentional?

    Perhaps=C2=A0a= new section=C2=A0"Refreshing an Access Token"?

    Additionally, I can imagine that an AS can improve its security pos= ture by adding support for DPoP *just* to token refresh and not requiring e= xisting resource servers to upgrade. Rotating refresh tokens would not be a= s critical for public clients using DPoP for token refresh.=C2=A0

    Would using DPoP only for token refresh be appropriate? If = so, language describing that would be helpful. :)

    = /Dick

    3D""=E1=90=A7 _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
    --00000000000003eeff05b2c2c906-- From nobody Wed Oct 28 16:09:03 2020 Return-Path: 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 93B063A0A8F for ; Wed, 28 Oct 2020 16:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=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 g0U0yfllniBw for ; Wed, 28 Oct 2020 16:08:59 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 316073A0A56 for ; Wed, 28 Oct 2020 16:08:59 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 2so1001703ljj.13 for ; Wed, 28 Oct 2020 16:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sMQZpwmEOCY/r/9ryljjcA2e7CunbgIIFzh+rLc7z2U=; b=c/Fl1fZVMq6lfYC24vcMboLrbgE3670zJfhrp/QgYXQPZzGQb0T8hRwucZjqTphSGj ZPJsE9F50Hmqrg4RkRIyG6McM0MBWX3wcGVPJ71CwipJsADLLSWuHU5aaIlKV6JwRUCr CdcQLC0TqA1PmEZcBaBD5Z6+fJmdY3Dz2G1PnFXsko3t9O3lIi+KUISGhCZF0W0nyc7W Iz3FCuAsEzRxAo5KQ/KXzj0ZpU0a7h1jmyYE2x+i1Cqg1CnqM2X22S1sX2VLEh0RGMci rJpe/rfTEGc2jH8fLgwRvQJnxvZwhuJD+O34rQTePSaOC8AnD6fAEvKLhy5dROrmngk6 q2BA== 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=sMQZpwmEOCY/r/9ryljjcA2e7CunbgIIFzh+rLc7z2U=; b=uPdqOv8Zdj8mgm7bBR8paTTrNt1ObWitRsAaTxu0tKKorGQ23Eo8kl47E9Kl8Tpw3Q sKfeo+KASrQushZDYiDxOs5N6KuSxvonQ9H+6ZmwEU5DlR4tg/tvTy8mIV9WPc6l2J7T xLJLUqCGuc1hr/UwKKLV3p4iKOSOX/43MQrw6LzC2KRarrsNUJVUm/8YBxn9yuUo82JM Sl0GJMluu/1mz1p4NBJdEkN7LWdf4hBDsYW6Z326SnSI10Mg7XMyImsCYEYXuEw/foTk Qhm7hpBssncXsOkXfEIbD1KB4piIYnaf9KgRbOUj7lMGVDnAQznPIXQy934rCbjHShGQ u4qw== X-Gm-Message-State: AOAM532ifWRTdYKnqC2sP8+0ie7+IBZKNZ5uhz/K4rOx6I6BKDnm2o8I fwWPmnEzs2+6xGsGZ619I7G6GeIKbujxaGi0yeTnpL13H5HOju9SesG9Ro4iPfrbHt7xkqPOkxX uKU3Qx9GaLmNZ3A== X-Google-Smtp-Source: ABdhPJzRpGO1f7orwD0RmwZKRd8l6lmtp+CwuDFiBr4iKZ847Hfxat2VHkEXC5KzdBAKYDqwpt8qIShETsu4dWnCC5g= X-Received: by 2002:a05:651c:39a:: with SMTP id e26mr637368ljp.170.1603926537187; Wed, 28 Oct 2020 16:08:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 28 Oct 2020 17:08:31 -0600 Message-ID: To: Dick Hardt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000007f55d505b2c33f8d" Archived-At: Subject: Re: [OAUTH-WG] DPoP and refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 23:09:02 -0000 --0000000000007f55d505b2c33f8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, I'll look at adding a refresh example and some additional explanation= . There are client authentication methods that use asymmetric cryptography so sender-constraining a refresh token with an asymmetric key pair (indirectly via the client's credentials) is already possible and happening in practice (JWT client auth and MTLS client auth). Nothing in DPoP is trying to discourage that. DPoP is just avoiding the added complexity and operational problems that would come with sender-constraining the RT with two different mechanisms. On Wed, Oct 28, 2020 at 4:35 PM Dick Hardt wrote: > Hey Brian > > A refresh example would make it more clear, and would also assist in > communicating that DPoP could be used just for refresh. > > I see in the updated text that using DPoP with confidential clients is > discouraged. I understand the RT is sender constrained -- but > asymmetric cryptography is much stronger than a shared secret. Why > discourage its use? > > > > > =E1=90=A7 > > On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell > wrote: > >> I'm currently working on the draft and hope to have a new revision >> published relatively soon. Just the other day I made some changes to the >> text around RTs with >> https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d= 96311fac44986974 >> that maybe/hopefully makes some of it more clear? But basically the RTs = are >> only bound for public clients and the exact mechanism to do it is left u= p >> to the AS. The AS both creates and consumes the RT so however it chooses= to >> associate the DPoP key with the RT is its own implementation detail. >> Getting a new bound access token using an RT is meant to be covered in s= ec >> 5 "Token Request (Binding Tokens to a Public Key)" with RT being just on= e >> of the grants that could be presented in the token request in conjunctio= n >> with the DPoP proof, and the AS would bind the AT it issues to the key i= n >> that DPoP proof. I'd sort of assumed that would just be understood. But = do >> you think it (including the recent changes) needs more explanation? >> >> I do think using DPoP only for token refresh (only for public clients >> though) would be appropriate, for some cases anyway. This has come up on >> the list here previously and the general consensus was also that it'd be >> useful. I plan to add some language describing that (and loosening some >> language that could be perceived as prohibiting it) but haven't gotten t= o >> that item on the editing todo list yet. >> >> >> >> >> On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt wrote: >> >>> Hello >>> >>> I was reviewing the latest DPoP draft[1] and saw numerous mentions of >>> using a DPoP proof for refreshing an access token, but no explicit >>> description of how to do that, nor an example. Was this intentional? >>> >>> Perhaps a new section "Refreshing an Access Token"? >>> >>> Additionally, I can imagine that an AS can improve its security posture >>> by adding support for DPoP *just* to token refresh and not requiring >>> existing resource servers to upgrade. Rotating refresh tokens would not= be >>> as critical for public clients using DPoP for token refresh. >>> >>> Would using DPoP only for token refresh be appropriate? If so, language >>> describing that would be helpful. :) >>> >>> /Dick >>> >>> [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 >>> =E1=90=A7 >>> _______________________________________________ >>> 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007f55d505b2c33f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Okay, I'll look at adding a refresh example and s= ome additional explanation.

    There are client authe= ntication methods that use asymmetric=C2=A0cryptography so sender-constrain= ing a refresh token with an asymmetric key pair (indirectly via the client&= #39;s credentials) is already possible and happening in practice (JWT clien= t auth and MTLS client auth). Nothing in DPoP is trying to discourage that.= DPoP is just avoiding the added complexity and operational problems that w= ould come with sender-constraining the RT with two different mechanisms.

    On Wed, Oct 28, 2020 at 4:35 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    = Hey Brian

    A refresh example would make it more clear, an= d would also assist in communicating that DPoP could be used just for refre= sh.

    I see in the updated text that using DPoP with= confidential clients is discouraged. I understand the RT is sender constra= ined -- but asymmetric=C2=A0cryptography is much stronger than a shared sec= ret. Why discourage its use?




    3D""=E1=90=A7

    On Wed, Oct 28, 202= 0 at 3:20 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
    I'= m currently working on the draft and hope to have a new revision published = relatively soon. Just the other day I made some changes to the text around = RTs with https://github.com/dan= ielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974 that= maybe/hopefully makes some of it more clear? But basically the RTs are onl= y bound for public clients and the exact mechanism to do it is left up to t= he AS. The AS both creates and consumes the RT so however it chooses to ass= ociate the DPoP key with the RT is its own implementation detail. Getting a= new bound access token using an RT is meant to be covered in sec 5 "T= oken Request (Binding Tokens to a Public Key)" with RT being just one = of the grants that could be presented in the token request in conjunction w= ith the DPoP proof, and the AS would bind the AT it issues to the key in th= at DPoP proof. I'd sort of assumed that would just be understood. But d= o you think it (including the recent changes) needs more explanation?
    <= /div>

    I do think using DPoP only for token refresh (only= for public clients though) would be appropriate, for some cases anyway. Th= is has come up on the list here previously and the general consensus was al= so that it'd be useful. I plan to add some language describing that (an= d loosening some language that could be perceived as prohibiting it) but ha= ven't gotten to that item on the editing todo list yet.
    =



    On Wed, Oct 28, 2020 at 2:46 PM Dic= k Hardt <dick.= hardt@gmail.com> wrote:
    Hello

    I was reviewing th= e latest=C2=A0DPoP draft[1] and saw numerous mentions of using a DPoP proof= for refreshing an access token, but no explicit description of how to do t= hat, nor an example. Was this intentional?

    Perhaps= =C2=A0a new section=C2=A0"Refreshing an Access Token"?
    =
    Additionally, I can imagine that an AS can improve its secur= ity posture by adding support for DPoP *just* to token refresh and not requ= iring existing resource servers to upgrade. Rotating refresh tokens would n= ot be as critical for public clients using DPoP for token refresh.=C2=A0

    Would using DPoP only for token refresh be appropria= te? If so, language describing that would be helpful. :)
    3D""=E1=90=A7
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007f55d505b2c33f8d-- From nobody Wed Oct 28 19:25:17 2020 Return-Path: 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 E4A8C3A0B6F for ; Wed, 28 Oct 2020 19:25:14 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=team.telstra.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 x0FQ00749xOH for ; Wed, 28 Oct 2020 19:25:12 -0700 (PDT) Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (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 126533A0B66 for ; Wed, 28 Oct 2020 19:25:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.77,428,1596463200"; d="scan'208,217";a="240389701" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipodni.tcif.telstra.com.au with ESMTP; 29 Oct 2020 13:25:03 +1100 Received: from wsapp6784.srv.dir.telstra.com ([10.75.3.133]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 Oct 2020 13:25:03 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp6784.srv.dir.telstra.com (10.75.3.133) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Oct 2020 13:25:03 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by autodiscover.team.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 29 Oct 2020 13:25:03 +1100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BeBEgeHohhnaosRlQrBQgX6Hkpqiq73KavOxwBAUrCOFKQpFAa1GGzQZGA7S4oRr0Mo7xL+YICHTpdorFolVeVWP9N4KacawT8uzF2eY6q63S8IOfczDpJT5lgVCim6xp6qu/H4+hujD35g+MvtQQlNzU8FH/ir88b1YI/26TLoMv0z9M1QzGMaCSrYAV/VCQL3gW6IuncU9sMZvPs/8+BBzq2FHK1gmheLfoJK8Ss1xH0e4y1UkS+f4c9InBa/F+q++yN9295iRA0RCHyon80oPbIZ52MgPq8kT/MuO6h164gcXnDF8/zzXcATXyn1gkhmiOOptQ3HCmHSG/Ni3CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LdkqfRVw7MyrGBW9pBTQoisjypJIg+V59CuZrmqwXNU=; b=gGinu1Il9xZUczosiMhkDzzHYguh7Z2wfGx7ynmyYJgfu+g47FSu+dTtm+RYZZzILwQt/HFXdu0p3vgNBLDditaCjgvV+Tz212y+wAmZ2bMXS4IQE3c3QYlINIyi+4ucIzNM3LX2u/tlmEgvAoVmg1XxGoCLQHEjfE2CUGZTdESKQ2OMN100Q2rmvP1hIO+P9Ozat9jHKQxCBzs8X3pKgjQuhe3bJRdFhVxHb7hJt64Ov8LPx6Wizz0IxRykirdwkJczVT2sA0difBzALjepcQieGSWnEObVzBgpL8Wl6RvIOI1FW8LLE6D69+g4h2rj3p69SsLrrAIVxBbqAFtE4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LdkqfRVw7MyrGBW9pBTQoisjypJIg+V59CuZrmqwXNU=; b=tlnjZBGLL+2fjQWniS+Cp52cnNB8c07JslwyQ8JZiwE16tgtGDRpJd7z81JF71H1k/nhp/cuyJLW5vDMKQ4hSQiCJtptHr8KLVyeIgMd86OTfEnaVbJy/OG1x30hqs+Oo5DIuGD5oqYNdFHG1S+APnzch9oh/oWiUTk9vVEbcXM= Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by ME2PR01MB2466.ausprd01.prod.outlook.com (2603:10c6:201:1b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 29 Oct 2020 02:25:02 +0000 Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972%7]) with mapi id 15.20.3477.028; Thu, 29 Oct 2020 02:25:02 +0000 From: "Manger, James" To: Denis , Daniel Fett , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] BCP: Client collaborative attacks Thread-Index: AQHWq8SAV39nbzcrrkCd6bB+C+9SVKmqY6IAgAAb/KCAAH0gAIAAcr8AgAANWwCAAkti4A== Date: Thu, 29 Oct 2020 02:25:02 +0000 Message-ID: References: <0e7842c8-5939-a0ce-0e24-2f7c776a3d44@danielfett.de> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [144.132.40.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6fc41a5-d125-4d8a-8c7a-08d87bb1d75d x-ms-traffictypediagnostic: ME2PR01MB2466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /H2R2FhaFHaWy1NE6hmPkTZ5oUnlTngeIYjA13/xfSgfAquWVit9q66sJk813SEZteZHzNMzHo2YXrJKC8TTl+ZkEplZiWmCGplTK4QRy6OzbOlVpTSTXaeZS2x3r6JmQhZI0ImXhBBWTrjZDYy2+m2MsMEd2qxWurmJOmLDRnSi+IHs6rZ9WlHzk5mk8LY5mjtp4bP9s9zXHxjbdG8KyHCSg6uoelyQvUnFwk/ZhSRHKg+NzI9ddv5Yof+EU9/I8O8tsxa/TOJwc2retRkPQsVKmori6N3ldaW+G0Ca2f58VotyaPmQUVovQMsoUSDlgAIG4hx3YkQUaKUOyiAR/VxtaCUBFSJJZ2uVEcqHnR52ogukem0z82fpb3FXPuGNOgr7BZB/Xb0JtIyoSuGnDC9GfZDwvUM+7/sQ5u3HZ6S/RS6JSh7djimQ3VpSNGk00Edb8ai6S9BbEyiTQ/Sv4NxRF36VIAshLBMD0yHnD8o= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(52536014)(110136005)(7696005)(316002)(71200400001)(8676002)(9686003)(26005)(166002)(186003)(2906002)(83380400001)(5660300002)(86362001)(76116006)(83080400002)(66476007)(33656002)(55016002)(966005)(6506007)(8936002)(478600001)(66446008)(64756008)(66946007)(66556008)(15398625002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 52mURmJgl5KpdffZcvSwEqGc0bYU8IP41hxj5k9lIiKquqY9UUYJX8r+y78CnXnVK7XULHpR0dJs0AWSLYJFDcAnh+IIefEJT11paQhZIijbRY6i1VjXkciEy7wgEEVdePPWnnF01s6k3Rn2eQcehgiDDem0m9tRtu7UxF+TFO79vV/I/I/Y4JOGZbhWCWQLGKiUUhVwCX0P7f7CJ4qLPvuninA21KTS5l9Ki/o9BVTQR+LwSXOYglZKA8YIPhdSIWWq795upxOfh5RYFnd3XGJ64HhW/EHJeQWANDLR2pMOhXNkdBHzG1z52BhJIIfoAfNxaC1G8CFjjmbZkHYnmjx/z3lpKROTIUHJvU6xH6FwcAlQGfPL45rnyy35CHEh3RTnBH5cFleRW5VBTED74lfIWqyvfkAXwBtAqvhrex935BT063+CZD35xXr8H9SmZJZ4kCuvXvtqHUpqOltigC5lC0VW+0UFQUafFcSWlXwLj1wG2DFMZHigd4Vya6iqFQgxn3Ja2X5U/MpPAVFqrE8oZ2bo7LAULeQwSzsXczAHAqNfoawcCKkn8oftUmslOKYnrP+j+Rp5yHBsyT3nGRHpY9zqX9CaXt4dqLx5cdvxbc42ukeHfZDXuiPobBqTL9BPj6Nbs0M9hkRzoJfE3g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011BEC9D33427E51F2244C0E5140ME2PR01MB3011ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ME2PR01MB3011.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6fc41a5-d125-4d8a-8c7a-08d87bb1d75d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2020 02:25:02.4915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HsoshwbwcGXbzmk3TftBWBJzyfvlkpZ8KiD3z6kwjmjbo6bYg1J8mOGEBhW7bEipS9a7rHUSTfabshksy6ue4hH5LBaj1j1eVOgMuyBf3yQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2466 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 02:25:15 -0000 --_000_ME2PR01MB3011BEC9D33427E51F2244C0E5140ME2PR01MB3011ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gV2hlbiB1c2luZyBzZWN1cmUgZWxlbWVudHMgd2l0aCBzcGVjaWZpYyBwcm9wZXJ0aWVzLCBp dCBpcyBwb3NzaWJsZSB0byBjb3VudGVyIHRoZSBBbGljZSAmIEJvYiBDb2xsdXNpb24gYXR0YWNr Lg0KDQpZb3UgZG9u4oCZdCBqdXN0IG5lZWQgdGhlIFNlY3VyZSBFbGVtZW504oCZcyBwcm9wZXJ0 aWVzIChrZXktcGFpciBnZW5lcmF0ZWQgb24gU0U7IG5vbi1leHBvcnRhYmxlIHByaXZhdGUga2V5 OyBoaWdoLWVudHJvcHkga2V5LWlkIGdlbmVyYXRlZCBvbiBTRTsgY29uZm9ybWFuY2UgY2VydDsg c3BlY2lhbCBBUERVcyksIHlvdSBhbHNvIG5lZWQgdGhlIHdpZGVyIHNjaGVtZSB0byBlbmZvcmNl IHRoYXQgYW55IHVzZXIgb25seSBldmVyIGhhcyAxIFNFIGFjdGl2ZSBhdCBhIHRpbWUuDQoNCk9u bHktMS1TRS1wZXItdXNlci1hdC1hLXRpbWUgc2VlbXMgZmFpcmx5IGZ1bmRhbWVudGFsIHRvIHN0 cm9uZ2x5IGNvbWJhdGluZyBjb2xsYWJvcmF0aXZlIGF0dGFja3MuIEJ1dCBpdCBpcyB0b3RhbGx5 IGluYXBwcm9wcmlhdGUgdG8gbWFueSAobW9zdD8pIHNjZW5hcmlvcyB3aGVyZSBPQXV0aCBpcyB1 c2VkLg0KDQoNCj4+IGh0dHBzOi8vemlzYy5ldGh6LmNoL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE3 LzAyL3Bpbmthc19wcml2YWN5LWJ5LWRlc2lnbi1lSUQtc2NoZW1lLXN1cHBvcnRpbmctQXR0cmli dXRlLWJhc2VkLUFjY2Vzcy1Db250cm9sLnBkZg0KDQpUaGlzIGVJRCBzY2hlbWUgbG9va3MgcHJl dHR5IGdvb2QuIFlvdSBjYW4gc2VlIHdoeSB0aGlzIHNjaGVtZSB3b3VsZCBsaWtlIHBhcnRpY3Vs YXIgZmVhdHVyZXMgaW4gYSBwcm9maWxlIG9mIE9BdXRoLg0KDQpCdXQgdGhpcyBpcyBvbmUgaGln aGx5IHNwZWNpYWxpc2VkIHByb2ZpbGUgb2YgT0F1dGggKCsgRklETyArIFNFICsgZUlEICsg4oCm KSB0aGF0IGlzIHF1aXRlIHVubGlrZSB0aGUg4oCcdHlwaWNhbOKAnSB1c2Ugb2YgT0F1dGguIEl0 cyByZXF1aXJlbWVudHMgYXJlbuKAmXQg4oCcYmVzdCBwcmFjdGljZeKAnSBmb3IgYWxsIE9BdXRo IGRlcGxveW1lbnRzLg0KDQoNClAuUy4gSSBkb27igJl0IHRoaW5rIHlvdXIgY29udGVudCBoYXMg YmVlbiDigJxkZWxldGVkIGZyb20gdGhpcyB0aHJlYWTigJ0uIEp1c3Qgbm90IGV2ZXJ5IHJlcGx5 IGluY2x1ZGVzIHRoZSBmdWxsIGVtYWlsIHRyYWlsLiBJdCBpcyBhbGwgc3RpbGwgYXQgaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9vYXV0aC8/Z2J0PTEmaW5kZXg9IGZv ciBpbnN0YW5jZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_ME2PR01MB3011BEC9D33427E51F2244C0E5140ME2PR01MB3011ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7Jmd0 OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoZW4gdXNpbmcgc2VjdXJlIGVsZW1l bnRzDQo8aT53aXRoIHNwZWNpZmljIHByb3BlcnRpZXM8L2k+LCBpdCBpcyBwb3NzaWJsZSB0byBj b3VudGVyIHRoZSBBbGljZSAmYW1wOyBCb2IgQ29sbHVzaW9uIGF0dGFjay48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WW91IGRvbuKAmXQganVz dCBuZWVkIHRoZSBTZWN1cmUgRWxlbWVudOKAmXMgcHJvcGVydGllcyAoa2V5LXBhaXIgZ2VuZXJh dGVkIG9uIFNFOyBub24tZXhwb3J0YWJsZSBwcml2YXRlIGtleTsgaGlnaC1lbnRyb3B5IGtleS1p ZCBnZW5lcmF0ZWQgb24gU0U7IGNvbmZvcm1hbmNlIGNlcnQ7IHNwZWNpYWwgQVBEVXMpLCB5b3Ug YWxzbyBuZWVkIHRoZQ0KIHdpZGVyIHNjaGVtZSB0byBlbmZvcmNlIHRoYXQgYW55IHVzZXIgb25s eSBldmVyIGhhcyAxIFNFIGFjdGl2ZSBhdCBhIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9ubHktMS1TRS1wZXItdXNl ci1hdC1hLXRpbWUgc2VlbXMgZmFpcmx5IGZ1bmRhbWVudGFsIHRvIHN0cm9uZ2x5IGNvbWJhdGlu ZyBjb2xsYWJvcmF0aXZlIGF0dGFja3MuIEJ1dCBpdCBpcyB0b3RhbGx5IGluYXBwcm9wcmlhdGUg dG8gbWFueSAobW9zdD8pIHNjZW5hcmlvcyB3aGVyZSBPQXV0aCBpcyB1c2VkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj48 YSBocmVmPSJodHRwczovL3ppc2MuZXRoei5jaC93cC1jb250ZW50L3VwbG9hZHMvMjAxNy8wMi9w aW5rYXNfcHJpdmFjeS1ieS1kZXNpZ24tZUlELXNjaGVtZS1zdXBwb3J0aW5nLUF0dHJpYnV0ZS1i YXNlZC1BY2Nlc3MtQ29udHJvbC5wZGYiPmh0dHBzOi8vemlzYy5ldGh6LmNoL3dwLWNvbnRlbnQv dXBsb2Fkcy8yMDE3LzAyL3Bpbmthc19wcml2YWN5LWJ5LWRlc2lnbi1lSUQtc2NoZW1lLXN1cHBv cnRpbmctQXR0cmlidXRlLWJhc2VkLUFjY2Vzcy1Db250cm9sLnBkZjwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBl SUQgc2NoZW1lIGxvb2tzIHByZXR0eSBnb29kLiBZb3UgY2FuIHNlZSB3aHkgdGhpcyBzY2hlbWUg d291bGQgbGlrZSBwYXJ0aWN1bGFyIGZlYXR1cmVzIGluIGEgcHJvZmlsZSBvZiBPQXV0aC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+QnV0IHRoaXMgaXMgb25lIGhpZ2hseSBzcGVjaWFsaXNlZCBwcm9maWxlIG9mIE9BdXRoICgr IEZJRE8gKyBTRSArIGVJRCArIOKApikgdGhhdCBpcyBxdWl0ZSB1bmxpa2UgdGhlIOKAnHR5cGlj YWzigJ0gdXNlIG9mIE9BdXRoLiBJdHMgcmVxdWlyZW1lbnRzIGFyZW7igJl0IOKAnGJlc3QgcHJh Y3RpY2XigJ0gZm9yIGFsbCBPQXV0aCBkZXBsb3ltZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5QLlMuIEkgZG9u4oCZdCB0aGluayB5b3VyIGNvbnRlbnQgaGFz IGJlZW4g4oCcZGVsZXRlZCBmcm9tIHRoaXMgdGhyZWFk4oCdLiBKdXN0IG5vdCBldmVyeSByZXBs eSBpbmNsdWRlcyB0aGUgZnVsbCBlbWFpbCB0cmFpbC4gSXQgaXMgYWxsIHN0aWxsIGF0DQo8YSBo cmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL29hdXRoLz9nYnQ9 MSZhbXA7aW5kZXg9Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL29h dXRoLz9nYnQ9MSZhbXA7aW5kZXg9PC9hPiBmb3IgaW5zdGFuY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVz IE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_ME2PR01MB3011BEC9D33427E51F2244C0E5140ME2PR01MB3011ausp_-- From nobody Fri Oct 30 08:46:03 2020 Return-Path: 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 2C1B93A08AB for ; Fri, 30 Oct 2020 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 E29RRuyuML_a for ; Fri, 30 Oct 2020 08:46:00 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 8576A3A0808 for ; Fri, 30 Oct 2020 08:46:00 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id d3so3365044wma.4 for ; Fri, 30 Oct 2020 08:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z6pcTHoMHHUuByaQD0SnJIDAJLgEX7dwK8/wgNAk7cQ=; b=O+XVUPPsSRIxf5JXG6We8Q6wRU1XcaqNDyqhNROpDfOhIA4GZKHQx59yslyirVzGfF 2EklWz0emF8N1dnPRloJOt21pV3pa3w0g0CdXUCIsveXQW1Udyc+SPC61En+rHDBTS/S C/RMK10CLwy6Y2DpvrLjuSSnFv6NHmfTKvIGjVLMKbuct6AErikGUHBzRJ2dNSqev0I0 EUkq1bxk5XOozs5eZ4BJ0hA0hp8q1ow4v7hLcwb3eWUxRn1KmFys6/BjJ4brDhfL6Gzr Lnm2lGY8m4HvGoEqaEB5qc3nQc9pHA8NYgHzKy+5MbXJuMd6X7jGa/FQ0eIxZP1DygHA X5kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z6pcTHoMHHUuByaQD0SnJIDAJLgEX7dwK8/wgNAk7cQ=; b=XhQBgJmtZepeniAG83/782q9UR+IVWBl0zthYSNzVTFBLmPEEdK4/pWUsy3yKUnPMW RmiOHiOSrz6FZkg+idStedAzrfxFp9yOGRCCKcxy4ddz9wI6a/dLPEyblr25L/NLoDRn kbP7yPXI3gFEhREpqPrBIsNhySmV1hF0uF1xFM+AYFjq6xalwzdXSe63MjNPgSbgFQL8 zme9nGr+S5U1IRWaL4kaucwlYDILlWfqKq1BCg5+lYd/oDnyP9xyWEqEFMw6xIn7L4tn m9rhiB8a0Wt2w5A+UTD1TRPCZ2QtfCI9zrCNH+uFLAStv3fjUhEHZsoCS3aUmKuX9ELD LRTQ== X-Gm-Message-State: AOAM530K4V7o0RXkHjbLVwQp75nPjgqY9QPPhOmgsxtk+mzIKsaTMbaS yG1tkmoqEaVC3fPmg6I0V3AP6MUoj45Q+C0qBuAhMoWaek8= X-Google-Smtp-Source: ABdhPJxB8G0KKDP3tRcYvcQ0Mj3vibvULjOBOd5R2yTrnU2lWAJURXWl5Ng/KQxPPm7NPNGiL8EOEOtWDq8yTPEznLs= X-Received: by 2002:a7b:c3da:: with SMTP id t26mr3593402wmj.154.1604072758556; Fri, 30 Oct 2020 08:45:58 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 30 Oct 2020 11:45:47 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f7bc1805b2e54aeb" Archived-At: Subject: [OAUTH-WG] Reminder - Interim Meeting to discuss IsLoggedIn/WebId X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 15:46:02 -0000 --000000000000f7bc1805b2e54aeb Content-Type: text/plain; charset="UTF-8" All, This is a reminder that we have an Interim meeting this coming Monday, Nov 2nd @ 12:00 Eastern Time, to discuss *IsLoggedIn* and *WebId* initiatives. As mentioned before, the goal of the meeting is *not* to describe the details of these initiatives, but rather provide a summary of these initiatives and their impact on the identity use cases, and spend most of the time discussing ways that could help us address the issues cause by the IsloggedIn/WebId proposed solutions. For this reason, we encourage you to watch the following presentations as they will provide you with the background needed to allow us to have a productive discussion without spending too much time on this background information. https://identiverse.gallery.video/detail/video/6184443037001/browser-features-vs-identity-protocols https://www.niso.org/events/2020/05/browser-changes-and-identity-federation-impact-identity-flows Regards, Rifaat & Hannes --000000000000f7bc1805b2e54aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All,

    This is a reminder that we have an= Interim meeting this coming Monday, Nov 2nd @ 12:00 Eastern Time, to discu= ss IsLoggedIn and WebId initiatives.

    As mentioned before, the=C2=A0goal of the=C2=A0meeting is not to de= scribe the details of these initiatives, but rather provide a summary of th= ese initiatives=C2=A0and their impact on the identity use cases, and spend = most of the time discussing ways that could help us address the issues caus= e by the IsloggedIn/WebId proposed solutions.

    For = this reason, we encourage you to watch the following=C2=A0presentations as = they will provide you with the background needed to allow us to have a prod= uctive=C2=A0discussion without spending too=C2=A0much time on this backgrou= nd information.
    Subject: Re: [OAUTH-WG] Reminder - Interim Meeting to discuss IsLoggedIn/WebId X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 22:39:32 -0000 --000000000000924bf305b2ff2f70 Content-Type: text/plain; charset="UTF-8" All, You can find the slides for this meeting at the following link: https://datatracker.ietf.org/meeting/interim-2020-oauth-12/session/oauth Regards, Rifaat & Hannes On Fri, Oct 30, 2020 at 11:45 AM Rifaat Shekh-Yusef wrote: > All, > > This is a reminder that we have an Interim meeting this coming Monday, Nov > 2nd @ 12:00 Eastern Time, to discuss *IsLoggedIn* and *WebId* initiatives. > > As mentioned before, the goal of the meeting is *not* to describe the > details of these initiatives, but rather provide a summary of these > initiatives and their impact on the identity use cases, and spend most of > the time discussing ways that could help us address the issues cause by the > IsloggedIn/WebId proposed solutions. > > For this reason, we encourage you to watch the following presentations as > they will provide you with the background needed to allow us to have a > productive discussion without spending too much time on this background > information. > > https://identiverse.gallery.video/detail/video/6184443037001/browser-features-vs-identity-protocols > > https://www.niso.org/events/2020/05/browser-changes-and-identity-federation-impact-identity-flows > > Regards, > Rifaat & Hannes > --000000000000924bf305b2ff2f70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All,

    You can find the slides for this m= eeting at the following link:

    Regards,
    =C2=A0Rifaat & Hannes


    On F= ri, Oct 30, 2020 at 11:45 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
    All,

    This is a reminder that we have an Interim meeting this coming Mon= day, Nov 2nd @ 12:00 Eastern Time, to discuss IsLoggedIn and WebI= d initiatives.

    As mentioned before, the=C2=A0g= oal of the=C2=A0meeting is not to describe the details of these init= iatives, but rather provide a summary of these initiatives=C2=A0and their i= mpact on the identity use cases, and spend most of the time discussing ways= that could help us address the issues cause by the IsloggedIn/WebId propos= ed solutions.

    For this reason, we encourage you to= watch the following=C2=A0presentations as they will provide you with the b= ackground needed to allow us to have a productive=C2=A0discussion without s= pending too=C2=A0much time on this background information.
    <= a href=3D"https://identiverse.gallery.video/detail/video/6184443037001/brow= ser-features-vs-identity-protocols" target=3D"_blank">https://identiverse.g= allery.video/detail/video/6184443037001/browser-features-vs-identity-protoc= ols

    Regards,
    <= /div>
    =C2=A0Rifaat & Hannes
    --000000000000924bf305b2ff2f70--