From nobody Mon Jul 3 05:31:18 2017 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 2BBEF130133; Mon, 3 Jul 2017 05:31:17 -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: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149908507711.3980.1045903851968629812@ietfa.amsl.com> Date: Mon, 03 Jul 2017 05:31:17 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:31:17 -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 of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones John Bradley Brian Campbell William Denniss Filename : draft-ietf-oauth-token-binding-04.txt Pages : 27 Date : 2017-07-03 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, and Refresh Tokens. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-04 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 Jul 3 05:40:35 2017 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 DC6EA131602 for ; Mon, 3 Jul 2017 05:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_frKJiBA5bE for ; Mon, 3 Jul 2017 05:40:30 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 2F23612762F for ; Mon, 3 Jul 2017 05:40:28 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id u62so94770037pgb.3 for ; Mon, 03 Jul 2017 05:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Pa80aNB0nhY/mB2k3M1r1TAPT7xOS64ulaWE4y3myFg=; b=YJaEgqVhYZS+r7qTrxMKYuDS/2z7SCNEKEnGRsHYXfxWB05K2YRTVVgE43h3iuiI7/ 73/k7RUKZi9GbOXwEhLVafEeog0QsV2pYmYQu7P4TVbuiQxMYd9C0lED7FYC12Nrz458 p//FY2YAc6V6OjdAvfopX2RslEsy/1ZGmHCJg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Pa80aNB0nhY/mB2k3M1r1TAPT7xOS64ulaWE4y3myFg=; b=mcLANLCB/s4XJW1ffNCxQ/a9PvQc+aBmhYtR4OU7beTUOWWK5JGR7srDUcUyF4rO6K iUPVRpbRKD4F0IcGsuvnM7FJWWk0hwlaeFoU6MXwAYC6Fd2bpdIcz6uLlN9wYLMCc6xU Ci/PjQ48Cxz6QeQZQrM7NLXo3LnNMXoSInXTfvIdO28KWWyQA9ItU+o4JQlJcrBByrjK Ae8Fq+JPa0npHNQB2OM+y5uuLO1Wcr0AYVes9vJvtzmnxFxcj2g+7zlTHB70Y4wk/6P+ 8JP2oxqFxF2W6yDG4j+8crzakSv8uEd5jdAmTFMILC02cTOh2fQU/7kuMX+Lyk9n1g5f neTA== X-Gm-Message-State: AIVw1132o6kQwdv840RaHg2BMGbmb/HajUBnvbWUR5gk9ZDcbTuoKGor t2iR5R8p+WO1rDo2R+O6anUsx8ELeiZincShpuFNH9+krY7keKVZcmVd6+msLkOcUzShQx6Kv3D Zqrw2 X-Received: by 10.84.217.219 with SMTP id d27mr10408978plj.180.1499085627424; Mon, 03 Jul 2017 05:40:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Mon, 3 Jul 2017 05:39:56 -0700 (PDT) In-Reply-To: <149908507711.3980.1045903851968629812@ietfa.amsl.com> References: <149908507711.3980.1045903851968629812@ietfa.amsl.com> From: Brian Campbell Date: Mon, 3 Jul 2017 06:39:56 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="f403045cd78a4f9a860553691298" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:40:33 -0000 --f403045cd78a4f9a860553691298 Content-Type: text/plain; charset="UTF-8" Draft -04 of OAuth 2.0 Token Binding has been published with the following updates: o Define how to convey token binding information of an access token via RFC 7662 OAuth 2.0 Token Introspection (note that the Introspection Response Registration request for cnf/Confirmation is in https://tools.ietf.org/html/draft-ietf-oauth-mtls-02#section-4.3 which will likely be published and registered prior to this document). o Minor editorial fixes. o Added an open issue about needing to allow for web server clients to opt-out of having refresh tokens bound while still allowing for binding of access tokens (following from mention of the problem on slide 16 of the presentation from Chicago https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb- token-binding-00.pdf ). ---------- Forwarded message ---------- From: Date: Mon, Jul 3, 2017 at 6:31 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-04.txt To: i-d-announce@ietf.org Cc: 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 of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones John Bradley Brian Campbell William Denniss Filename : draft-ietf-oauth-token-binding-04.txt Pages : 27 Date : 2017-07-03 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, and Refresh Tokens. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-04 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 -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045cd78a4f9a860553691298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Draft -04 of OAuth 2.0 Token Binding = has been published with the following updates: 

   o  Define how to convey token bindin=
g information of an access token
      via RFC 7662 OAuth 2.0 Token Introspection (note that the
      Introspection Response Registration request for cnf/Confirmation
      is in https://tools.ietf.org/html/draft-ietf=
-oauth-mtls-02#section-4.3
=C2=A0     which will likely be publ=
ished and registered prior
      to this document).

   o  Minor editorial fixes.

   o  Added an open issue about needing to allow for web server clients
      to opt-out of having refresh tokens bound while still allowing for
      binding of access tokens (following from mention of the problem on
      slide 16 of the presentation from Chicago
      https://www.ietf.org/pr=
oceedings/98/slides/slides-98-oauth-sessb-
      token-binding-00.pdf).

---------- Forwarded message ---------= -
From: <internet-drafts@ietf= .org>
Date: Mon, Jul 3, 2017 at 6:31 AM
Subject: [OAUTH= -WG] I-D Action: draft-ietf-oauth-token-binding-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.or= g



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 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 Token Binding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=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 John Bradley
=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 Brian Campbell
=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 William Denniss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-binding-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 27
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-03

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, and Refresh Tok= ens.
=C2=A0 =C2=A0This cryptographically binds these tokens to a client's To= ken Binding
=C2=A0 =C2=A0key pair, possession of which is proven on the TLS connections= over
=C2=A0 =C2=A0which the tokens are intended to be used.=C2=A0 This use of To= ken Binding
=C2=A0 =C2=A0protects these tokens from man-in-the-middle and token export = and
=C2=A0 =C2=A0replay attacks.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-oauth-token-binding-04
https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-token-binding-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-oauth-token-binding-04


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


<= 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. --f403045cd78a4f9a860553691298-- From nobody Mon Jul 3 07:48:41 2017 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 34028126C0F; Mon, 3 Jul 2017 07:48:40 -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: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909332017.22754.15876773021557919350@ietfa.amsl.com> Date: Mon, 03 Jul 2017 07:48:40 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 14:48: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 of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-09.txt Pages : 31 Date : 2017-07-03 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-09 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 Jul 3 07:55:15 2017 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 22D96131654 for ; Mon, 3 Jul 2017 07:55: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWyJqBfDSuZH for ; Mon, 3 Jul 2017 07:55:04 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 BB13B126C0F for ; Mon, 3 Jul 2017 07:55:03 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id k14so20652672pgr.0 for ; Mon, 03 Jul 2017 07:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xnR8CRo88+OYwQ0Xe4wsB/RmXlhfAuQHhkC8x5delqk=; b=XEgQz81SLfV6wdnz00ABzJ5BNOneQJ0L6ilIhctuVVD+P/67WmwgLWU2wVHWQxEPsk 3kjsUr2FkJkUu6w79vhG4H49yioMSbPcPEnB0A5YKLDPDQv05Vsecr5FK87vpq3nUVLH MrAxlRBY4f/EM5sz1Ey9bG60aWdvL6U0TdVkE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xnR8CRo88+OYwQ0Xe4wsB/RmXlhfAuQHhkC8x5delqk=; b=tmnaHialsEufHxohi8jstFaTjwnbfoa1VXhE09W4g4aJiiiRZrJk6SY7np5eXpra1f wYzPcu4Ed2tlZsc2lBVcUBE9eD173DFBNVOPzvf/JboXlGrxw5Y8a/vlte4+8SozbcAy LmW5CKQgrGnU3/C06MuYjZLs4RBH/P+Xy1UmDZH1pF8PhFMVFDqmLmlbf7hwV5vO8fqo Udn4GPMTUCOIja4h10MUiF6KmFagVpwG1wu9eAIsAaYCRXFEMTU64ydPsASmlm9jBiFO 3Ywp4LEkrk2y4mkyDG9VNflHJU15cCLYAC0c68rKEIyENoCwB0kq3zgBwo/UdfECz5am vndw== X-Gm-Message-State: AIVw1133Y1n7DhYHex5UjeKkeaKwUu0UHkqc1WEq9fyl9kU6tI0PzUzG U5mAnQFbncrfICw0hczojuW+99XVUInFNHkWneiL0RyvYY5P3/q3Hq2n0EapzdhNr2BiQYkta/7 +XS7xoh4= X-Received: by 10.84.151.99 with SMTP id i90mr11334259pli.188.1499093703062; Mon, 03 Jul 2017 07:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.130 with HTTP; Mon, 3 Jul 2017 07:54:32 -0700 (PDT) In-Reply-To: <149909332017.22754.15876773021557919350@ietfa.amsl.com> References: <149909332017.22754.15876773021557919350@ietfa.amsl.com> From: Brian Campbell Date: Mon, 3 Jul 2017 08:54:32 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c18853aa816b205536af38b" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 14:55:14 -0000 --94eb2c18853aa816b205536af38b Content-Type: text/plain; charset="UTF-8" Draft -09 of OAuth 2.0 Token Exchange has been published with the following relatively minor changes resulting from working group last call feedback. -09 o Changed "security tokens obtained could be used in a number of contexts" to "security tokens obtained may be used in a number of contexts" per a WGLC suggestion. o Clarified that the validity of the subject or actor token have no impact on the validity of the issued token after the exchange has occurred per a WGLC comment. o Changed use of invalid_target error code to a SHOULD per a WGLC comment. o Clarified text about non-identity claims within the "act" claim being meaningless per a WGLC comment. o Added brief Privacy Considerations section per WGLC comments. ---------- Forwarded message ---------- From: Date: Mon, Jul 3, 2017 at 8:48 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-09.txt To: i-d-announce@ietf.org Cc: 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 of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-09.txt Pages : 31 Date : 2017-07-03 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-09 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 -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c18853aa816b205536af38b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Draft -09 of OAuth 2.0 Token Exchange has been publish= ed with the following relatively minor changes resulting from working group= last call feedback. 

   -09

   o  Changed "security tokens obtained could be used in a number of
      contexts" to "security tokens obtained may be used in a num=
ber of
      contexts" per a WGLC suggestion.
   o  Clarified that the validity of the subject or actor token have no
      impact on the validity of the issued token after the exchange has
      occurred per a WGLC comment.
   o  Changed use of invalid_target error code to a SHOULD per a WGLC
      comment.
   o  Clarified text about non-identity claims within the "act" c=
laim
      being meaningless per a WGLC comment.
   o  Added brief Privacy Considerations section per WGLC comments.

---------- Forwarded message ----------From: <internet-drafts@ietf.org>Date: Mon, Jul 3, 2017 at 8:48 AM
Subject: [OAUTH-WG] I-D Action: draft= -ietf-oauth-token-exchange-09.txt
To: i-d-announce@ietf.org
Cc: o= auth@ietf.org



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 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 Token Exchange
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=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 Anthony Nadalin
=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 Brian Campbell
=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 John Bradley
=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 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-03

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-oauth-token-exchange/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-oauth-token-exchange-09
https://datatracker.ietf.org= /doc/html/draft-ietf-oauth-token-exchange-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?<= wbr>url2=3Ddraft-ietf-oauth-token-exchange-09


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


<= 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. --94eb2c18853aa816b205536af38b-- From nobody Tue Jul 4 12:43:57 2017 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 6442513289A for ; Tue, 4 Jul 2017 12:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 cp2VaPhZeb-t for ; Tue, 4 Jul 2017 12:43:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0099.outbound.protection.outlook.com [104.47.38.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B451131706 for ; Tue, 4 Jul 2017 12:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ui37i1DEM5x0Iz/ISkjeY/bCJ53FfrL6mnbKibt0zJA=; b=EdLvS9/Fh0goasZR8Ltgw1Yvob9cJfk4nyxVatjhvvpcJ7LXEQM16PZ23A0mFdQzjecfS+oucOmujqtOn7V0pUFDWh70aLtrSsOFCSBhfMIMfcYF2CwmGHoW+mDDuU6GGskR3zY4t7syzQunhxDPljTjb4QeEAhLgDBgkBbxOsk= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0694.namprd21.prod.outlook.com (10.175.121.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.3; Tue, 4 Jul 2017 19:43:51 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1261.003; Tue, 4 Jul 2017 19:43:51 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JSON Web Token Best Current Practices draft describing Explicit Typing Thread-Index: AdL0+iJmgqpM9UqbSgCDmYr6GQRcNA== Date: Tue, 4 Jul 2017 19:43:51 +0000 Message-ID: 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_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-07-04T12:43:49.4591748-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0694; 7:2ouY1APGHC5M7Uz8TsQ9XlbZhLrEu/daAa6uAIUDtgsorJZRgEnuvFH+eAIpgWYyY18qIr2g1iJ+aiNgt6jSzTPMY2JcBIpb2/x94lxhn0O//0yVNxOxL5fuA7kH+ea2NZ24KyHDurM0cSf4MO+Vn5YVAdRrHBOWFuLbQvCOPGQC9pbNJn2I/oN8Os/kh1Y/t+G6gJIAXFbSPiBjJxci6tFqLW/tHXWbnOM7WcJkNZzYyDAox5JbqsB6TwBzl4BUH291Zo4Yc+N84g413cYn0p8dFTwmSu19AGXHl54dKEGMKET7gOqUcch9b8eD277wau8g4Pu2OXAlnKUaEA1tmCfBd4zQfgTr+Br3VeNFL//ZqxWNEX113XhiKYnYrY/Bk/U0ncCUrjxUi+k1upLBJqVHFFP7GgEahIMWjlL6Gvc0UaJhT0HkdNnwIUo3gQxin8MQ7qansXasONcei0kw+iEQvNLr+UCG0Tz0poigaR6BS+UcgzEEpjymrQgkIlwP6j8AhiYaCzu1ssDc526R/D5vKJCE/71bIRGudVoUyvivAFYROnv1eXgRNKKC+9e0SWb39dcfTSl+U6eqWfEyF3zYUaLHDY94EyIYt/5CE9aic6vYPFrW2Zatbe0dypsGj1vzVheKV4Teu21rUDFMHuzrIJ7imxQcXT7r0ftED6rCXWdI2hjd1xH78je3q+aca6UFwmnIiZP3NDDqDMBoFulqjtqwrQGM9qnakHaxuMswdSLw+v1bztqp8aW+zCCVn1JW/Ij92Kl8R+MMa77XhsPB8LVbd/XTpZXowjzWNw8lPWY+tfnzdQ9sZBwHqI8Y x-ms-office365-filtering-correlation-id: c329a504-c01a-4895-f38c-08d4c314ff42 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0694; x-ms-traffictypediagnostic: CY4PR21MB0694: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(192374486261705)(31418570063057)(148574349560750)(21748063052155)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910033)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0694; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0694; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39850400002)(39400400002)(39410400002)(39840400002)(209900001)(2351001)(53376002)(7736002)(38730400002)(189998001)(110136004)(33656002)(8676002)(5660300001)(966005)(5005710100001)(3280700002)(74316002)(478600001)(6916009)(72206003)(50986999)(25786009)(6306002)(2900100001)(54356999)(3660700001)(10090500001)(14454004)(790700001)(6436002)(77096006)(3846002)(6116002)(102836003)(236005)(8936002)(54896002)(2906002)(606006)(5640700003)(1730700003)(7696004)(10290500003)(2501003)(66066001)(9686003)(55016002)(99286003)(5630700001)(8990500004)(53936002)(86612001)(81166006)(86362001)(6506006)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0694; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504A6F0739B0F3EFA46AE54F5D70CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 19:43:51.4172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0694 Archived-At: Subject: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:43:55 -0000 --_000_CY4PR21MB0504A6F0739B0F3EFA46AE54F5D70CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JWT BCP draft has been updated to describe the use of explicit typing o= f JWTs as one of the ways to prevent confusion among different kinds of JWT= s. This is accomplished by including an explicit type for the JWT in the "= typ" header parameter. For instance, the Security Event Token (SET) specif= ication now uses the "application/seceve= nt+jwt" content type to explicitly type SETs. The specification is available at: * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1714 and = as @selfissued. --_000_CY4PR21MB0504A6F0739B0F3EFA46AE54F5D70CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JWT BCP draft has been updated to describe the u= se of explicit typing of JWTs as one of the ways to prevent confusion among= different kinds of JWTs.  This is accomplished by including an explic= it type for the JWT in the “typ” header parameter.  For instance, the Security Event Token (SET) specification now uses the = 220;application/seceven= t+jwt” content type to explicitly type SETs.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1714 and as @selfissued.

--_000_CY4PR21MB0504A6F0739B0F3EFA46AE54F5D70CY4PR21MB0504namp_-- From nobody Tue Jul 4 12:58:16 2017 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 E05C7131A21 for ; Tue, 4 Jul 2017 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 iwDalDDRzH8a for ; Tue, 4 Jul 2017 12:58:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3EEE413178D for ; Tue, 4 Jul 2017 12:58:13 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v64JwCNx017415 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jul 2017 19:58:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v64JwBT6003702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jul 2017 19:58:12 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v64JwBUN016450; Tue, 4 Jul 2017 19:58:11 GMT Received: from [25.163.1.58] (/72.143.232.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Jul 2017 12:58:11 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-E6FC04A8-598C-4864-806C-B77A7B866FDF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 4 Jul 2017 12:58:05 -0700 Cc: "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> References: To: Mike Jones X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:58:15 -0000 --Apple-Mail-E6FC04A8-598C-4864-806C-B77A7B866FDF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Thanks Mike.=20 Phil > On Jul 4, 2017, at 12:43 PM, Mike Jones wrot= e: >=20 > The JWT BCP draft has been updated to describe the use of explicit typing o= f JWTs as one of the ways to prevent confusion among different kinds of JWTs= . This is accomplished by including an explicit type for the JWT in the =E2= =80=9Ctyp=E2=80=9D header parameter. For instance, the Security Event Token= (SET) specification now uses the =E2=80=9Capplication/secevent+jwt=E2=80=9D= content type to explicitly type SETs. > =20 > The specification is available at: > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 > =20 > An HTML-formatted version is also available at: > http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html > =20 > -- Mike > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1714 and= as @selfissued. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E6FC04A8-598C-4864-806C-B77A7B866FDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Thanks Mike. 

Phil

On Jul 4, 2017, at 12:43 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=
=

The JWT BCP draft has been updated to describe the us= e of explicit typing of JWTs as one of the ways to prevent confusion among d= ifferent kinds of JWTs.  This is accomplished by including an explicit t= ype for the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter.  For instance, the Security Event Token (SET) specification now uses the =E2=80= =9Capplication/secevent+= jwt=E2=80=9D content type to explicitly type SETs.

 

The specification is available at:

 

An HTML-formatted version is also available at:<= /o:p>

 

         = ;            &nb= sp;            &= nbsp;            = ;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1714 and as @selfissued.

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-E6FC04A8-598C-4864-806C-B77A7B866FDF-- From nobody Wed Jul 5 03:02:53 2017 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 2100E1320F4 for ; Wed, 5 Jul 2017 03:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 7CkEGtBy8Z8f for ; Wed, 5 Jul 2017 03:02:49 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC0A131C58 for ; Wed, 5 Jul 2017 03:02:48 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v65A2lV1021419 for ; Wed, 5 Jul 2017 11:02:47 +0100 (BST) Received: from BGB01XI1016.national.core.bbc.co.uk (10.161.14.79) by BGB01XI1008.national.core.bbc.co.uk (10.161.14.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Jul 2017 11:02:46 +0100 Received: from BGB01XUD1006.national.core.bbc.co.uk ([10.184.52.85]) by BGB01XI1016.national.core.bbc.co.uk ([10.161.14.79]) with mapi id 14.03.0319.002; Wed, 5 Jul 2017 11:02:46 +0100 From: Chris Needham To: "oauth@ietf.org" Thread-Topic: Device flow feedback Thread-Index: AdL1ddkxQ9sWS93GQBKomA2Bj+H6vQ== Date: Wed, 5 Jul 2017 10:02:45 +0000 Message-ID: <590FCC451AE69B47BFB798A89474BB363D8DF396@bgb01xud1006> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] X-TM-AS-Product-Ver: SMEX-11.0.0.4255-8.100.1062-23176.006 X-TM-AS-Result: No--7.129500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: c91d45b2-6e10-4209-9543-d9970fac71b7 Archived-At: Subject: [OAUTH-WG] Device flow feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 10:02:51 -0000 Hi, I'm one of the contributors to the ETSI Cross Platform Authentication spec = [1], which was based on an early draft of the OAuth 2.0 Device Flow. One of the things we found useful, and not included in the current OAuth 2.= 0 Device Flow [2, section 3.5], is a return code for the case where the aut= horization server decides to cancel the pairing process. This may be due to= a user interaction, such as declining the presented terms and conditions, = for example. Such a return code allows the client to stop polling and to di= splay an appropriate message to the user. (I didn't find a suitable error c= ode in RFC6749.)=20 In the ETSI spec we used the error code 'cancelled' for this purpose: cancelled The authorization server has cancelled the pairing process. This can occu= r, for example, if the user declined to authorize the client, e.g., by not accepting terms and conditions presented to them by the authorization ser= ver. Best regards, Chris [1] http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts= _103407v010101p.pdf [2] https://tools.ietf.org/id/draft-ietf-oauth-device-flow-06.txt -- Chris Needham Principal Software Engineer BBC Research & Development Centre House, 56 Wood Lane, London W12 7SB From nobody Wed Jul 5 03:16:24 2017 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 9C6E7131BBB for ; Wed, 5 Jul 2017 03:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mNYD9GrJVzqk for ; Wed, 5 Jul 2017 03:16:21 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 734B5129B7F for ; Wed, 5 Jul 2017 03:16:21 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r126so122771481vkg.0 for ; Wed, 05 Jul 2017 03:16:21 -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=p3CsYSOAaj64HGqi3nkRxO9rvTMMsf/JaKcehoylPs8=; b=Gy5ZDNi7eczd3rjjE+K6NB7aqlxKkuPNQrhKFDIFFiUOYURKQfciI1rOgEP0b97HuL X2QpwONr+f2tIUSU/PwEp3lag3rDubtZMyfv8EgR7nNR6fgRzezkyPHrlRHOGl99m07c ocABpN4MNGDTPwU6m6UhES2NrLRwnPSWaN5CVcZ46eBYWqi0BmvJc2XE8GsLe3WSJl7Y 2ynQ6NYKo9bzHt6yL/DKhMyyvljma4veVCWar1td03AZq445aY4WVBQDRRxKoLfsAik5 Js0b4fuaasRR4qNal6VeUaB/7PI9/7b09BMEnTxU+LTYQ7QtAP1BjYzCfSsi6kbx/Mbl td1g== 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=p3CsYSOAaj64HGqi3nkRxO9rvTMMsf/JaKcehoylPs8=; b=FXkzQYhErKWVp+uPrLBIQol/I1PstPSkBvMfmINnGItxhIdGt5z8aBOPhYsEwKs9k1 gSoBwhhj3eL9o7qN4o50dgdjMC5Wo2iVB4tShArIuvqB9uXiprXXb6Wq2txfgqlc06G7 D0JHQrOzBmgBx1EhhQz3HQdqM5yiRHVg91ihq3YC7fVBrZahxL7E1Y41u3AG8kSNWVLr 4ol0I57kp+mG4873vp20Na5tR3NGsZP6bwIAVSrFxE3r8d1tkxQyjR6qIiPdP8CZ3Hzl 7qQXYhH4zfhr5ECb+VJjPYC3Qv9E+1uB0VITzIJBlEbwAistWbrF7nHaAC5NZFaQCnaE yCHA== X-Gm-Message-State: AIVw1109aY7cgdV4kG3xiZ4AB05jHsqJ8G1VERx7eYAR5W0YwwHwYnjQ /8WKr7sLg82aL1FfcG8LKztfG5eLIA== X-Received: by 10.31.13.141 with SMTP id 135mr8677566vkn.40.1499249780619; Wed, 05 Jul 2017 03:16:20 -0700 (PDT) MIME-Version: 1.0 References: <590FCC451AE69B47BFB798A89474BB363D8DF396@bgb01xud1006> In-Reply-To: <590FCC451AE69B47BFB798A89474BB363D8DF396@bgb01xud1006> From: Thomas Broyer Date: Wed, 05 Jul 2017 10:16:09 +0000 Message-ID: To: Chris Needham , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a114493d69a806705538f4a8b" Archived-At: Subject: Re: [OAUTH-WG] Device flow feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 10:16:23 -0000 --001a114493d69a806705538f4a8b Content-Type: text/plain; charset="UTF-8" Wouldn't expired_token be appropriate here? On Wed, Jul 5, 2017 at 12:02 PM Chris Needham wrote: > Hi, > > I'm one of the contributors to the ETSI Cross Platform Authentication spec > [1], which was based on an early draft of the OAuth 2.0 Device Flow. > > One of the things we found useful, and not included in the current OAuth > 2.0 Device Flow [2, section 3.5], is a return code for the case where the > authorization server decides to cancel the pairing process. This may be due > to a user interaction, such as declining the presented terms and > conditions, for example. Such a return code allows the client to stop > polling and to display an appropriate message to the user. (I didn't find a > suitable error code in RFC6749.) > > In the ETSI spec we used the error code 'cancelled' for this purpose: > > cancelled > > The authorization server has cancelled the pairing process. This can > occur, > for example, if the user declined to authorize the client, e.g., by not > accepting terms and conditions presented to them by the authorization > server. > > Best regards, > > Chris > > [1] > http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf > [2] https://tools.ietf.org/id/draft-ietf-oauth-device-flow-06.txt > > -- > Chris Needham > Principal Software Engineer > BBC Research & Development > Centre House, 56 Wood Lane, London W12 7SB > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114493d69a806705538f4a8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wouldn't=C2=A0exp= ired_token be appropriate here?

=
On Wed, Jul 5, 2017 at 12:02 PM Chris Needham <chris.needham@bbc.co.uk> wrote:<= br>
Hi,

I'm one of the contributors to the ETSI Cross Platform Authentication s= pec [1], which was based on an early draft of the OAuth 2.0 Device Flow.
One of the things we found useful, and not included in the current OAuth 2.= 0 Device Flow [2, section 3.5], is a return code for the case where the aut= horization server decides to cancel the pairing process. This may be due to= a user interaction, such as declining the presented terms and conditions, = for example. Such a return code allows the client to stop polling and to di= splay an appropriate message to the user. (I didn't find a suitable err= or code in RFC6749.)

In the ETSI spec we used the error code 'cancelled' for this purpos= e:

cancelled

=C2=A0 The authorization server has cancelled the pairing process. This can= occur,
=C2=A0 for example, if the user declined to authorize the client, e.g., by = not
=C2=A0 accepting terms and conditions presented to them by the authorizatio= n server.

Best regards,

Chris

[1] http:/= /www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v01= 0101p.pdf
[2] https://tools.ietf.org/id/draft-iet= f-oauth-device-flow-06.txt

--
Chris Needham
Principal Software Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London W12 7SB

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114493d69a806705538f4a8b-- From nobody Wed Jul 5 03:23:51 2017 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 E3CBD131C41 for ; Wed, 5 Jul 2017 03:23:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5fX5BgFbx9qH for ; Wed, 5 Jul 2017 03:23:48 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE67131C6E for ; Wed, 5 Jul 2017 03:23:47 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v65ANj3k029638; Wed, 5 Jul 2017 11:23:45 +0100 (BST) Received: from BGB01XUD1006.national.core.bbc.co.uk ([10.184.52.85]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0319.002; Wed, 5 Jul 2017 11:23:45 +0100 From: Chris Needham To: Thomas Broyer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Device flow feedback Thread-Index: AdL1ddkxQ9sWS93GQBKomA2Bj+H6vf//8vqA///uCBA= Date: Wed, 5 Jul 2017 10:23:44 +0000 Message-ID: <590FCC451AE69B47BFB798A89474BB363D8DF3B1@bgb01xud1006> References: <590FCC451AE69B47BFB798A89474BB363D8DF396@bgb01xud1006> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.56.249] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23176.006 x-tm-as-result: No--25.868800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_590FCC451AE69B47BFB798A89474BB363D8DF3B1bgb01xud1006_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Device flow feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 10:23:50 -0000 --_000_590FCC451AE69B47BFB798A89474BB363D8DF3B1bgb01xud1006_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIHVzZWZ1bCB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIHRob3NlIGNhc2VzIGZyb20g dGhlIGNsaWVudOKAmXMgcG9pbnQgb2Ygdmlldy4NCg0KRnJvbTogVGhvbWFzIEJyb3llciBbbWFp bHRvOnQuYnJveWVyQGdtYWlsLmNvbV0NClNlbnQ6IDA1IEp1bHkgMjAxNyAxMToxNg0KVG86IENo cmlzIE5lZWRoYW0gPGNocmlzLm5lZWRoYW1AYmJjLmNvLnVrPjsgb2F1dGhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERldmljZSBmbG93IGZlZWRiYWNrDQoNCldvdWxkbid0IGV4 cGlyZWRfdG9rZW4gYmUgYXBwcm9wcmlhdGUgaGVyZT8NCg0KT24gV2VkLCBKdWwgNSwgMjAxNyBh dCAxMjowMiBQTSBDaHJpcyBOZWVkaGFtIDxjaHJpcy5uZWVkaGFtQGJiYy5jby51azxtYWlsdG86 Y2hyaXMubmVlZGhhbUBiYmMuY28udWs+PiB3cm90ZToNCkhpLA0KDQpJJ20gb25lIG9mIHRoZSBj b250cmlidXRvcnMgdG8gdGhlIEVUU0kgQ3Jvc3MgUGxhdGZvcm0gQXV0aGVudGljYXRpb24gc3Bl YyBbMV0sIHdoaWNoIHdhcyBiYXNlZCBvbiBhbiBlYXJseSBkcmFmdCBvZiB0aGUgT0F1dGggMi4w IERldmljZSBGbG93Lg0KDQpPbmUgb2YgdGhlIHRoaW5ncyB3ZSBmb3VuZCB1c2VmdWwsIGFuZCBu b3QgaW5jbHVkZWQgaW4gdGhlIGN1cnJlbnQgT0F1dGggMi4wIERldmljZSBGbG93IFsyLCBzZWN0 aW9uIDMuNV0sIGlzIGEgcmV0dXJuIGNvZGUgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBkZWNpZGVzIHRvIGNhbmNlbCB0aGUgcGFpcmluZyBwcm9jZXNzLiBUaGlz IG1heSBiZSBkdWUgdG8gYSB1c2VyIGludGVyYWN0aW9uLCBzdWNoIGFzIGRlY2xpbmluZyB0aGUg cHJlc2VudGVkIHRlcm1zIGFuZCBjb25kaXRpb25zLCBmb3IgZXhhbXBsZS4gU3VjaCBhIHJldHVy biBjb2RlIGFsbG93cyB0aGUgY2xpZW50IHRvIHN0b3AgcG9sbGluZyBhbmQgdG8gZGlzcGxheSBh biBhcHByb3ByaWF0ZSBtZXNzYWdlIHRvIHRoZSB1c2VyLiAoSSBkaWRuJ3QgZmluZCBhIHN1aXRh YmxlIGVycm9yIGNvZGUgaW4gUkZDNjc0OS4pDQoNCkluIHRoZSBFVFNJIHNwZWMgd2UgdXNlZCB0 aGUgZXJyb3IgY29kZSAnY2FuY2VsbGVkJyBmb3IgdGhpcyBwdXJwb3NlOg0KDQpjYW5jZWxsZWQN Cg0KICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaGFzIGNhbmNlbGxlZCB0aGUgcGFpcmluZyBw cm9jZXNzLiBUaGlzIGNhbiBvY2N1ciwNCiAgZm9yIGV4YW1wbGUsIGlmIHRoZSB1c2VyIGRlY2xp bmVkIHRvIGF1dGhvcml6ZSB0aGUgY2xpZW50LCBlLmcuLCBieSBub3QNCiAgYWNjZXB0aW5nIHRl cm1zIGFuZCBjb25kaXRpb25zIHByZXNlbnRlZCB0byB0aGVtIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4NCg0KQmVzdCByZWdhcmRzLA0KDQpDaHJpcw0KDQpbMV0gaHR0cDovL3d3dy5ldHNp Lm9yZy9kZWxpdmVyL2V0c2lfdHMvMTAzNDAwXzEwMzQ5OS8xMDM0MDcvMDEuMDEuMDFfNjAvdHNf MTAzNDA3djAxMDEwMXAucGRmDQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLW9hdXRoLWRldmljZS1mbG93LTA2LnR4dA0KDQotLQ0KQ2hyaXMgTmVlZGhhbQ0KUHJpbmNp cGFsIFNvZnR3YXJlIEVuZ2luZWVyDQpCQkMgUmVzZWFyY2ggJiBEZXZlbG9wbWVudA0KQ2VudHJl IEhvdXNlLCA1NiBXb29kIExhbmUsIExvbmRvbiBXMTIgN1NCDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_590FCC451AE69B47BFB798A89474BB363D8DF3B1bgb01xud1006_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdOKAmXMgdXNlZnVsIHRvIGJl IGFibGUgdG8gZGlzdGluZ3Vpc2ggdGhvc2UgY2FzZXMgZnJvbSB0aGUgY2xpZW504oCZcyBwb2lu dCBvZiB2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gVGhvbWFzIEJyb3llciBbbWFpbHRvOnQuYnJveWVyQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNSBKdWx5IDIwMTcgMTE6MTY8YnI+DQo8Yj5Ubzo8L2I+ IENocmlzIE5lZWRoYW0gJmx0O2NocmlzLm5lZWRoYW1AYmJjLmNvLnVrJmd0Ozsgb2F1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRGV2aWNlIGZsb3cgZmVl ZGJhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V291bGRuJ3QmbmJzcDtleHBpcmVkX3Rva2VuIGJlIGFwcHJvcHJpYXRlIGhlcmU/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCA1LCAy MDE3IGF0IDEyOjAyIFBNIENocmlzIE5lZWRoYW0gJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5u ZWVkaGFtQGJiYy5jby51ayI+Y2hyaXMubmVlZGhhbUBiYmMuY28udWs8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpLDxicj4NCjxicj4NCkknbSBvbmUgb2YgdGhlIGNvbnRyaWJ1dG9ycyB0byB0aGUgRVRTSSBD cm9zcyBQbGF0Zm9ybSBBdXRoZW50aWNhdGlvbiBzcGVjIFsxXSwgd2hpY2ggd2FzIGJhc2VkIG9u IGFuIGVhcmx5IGRyYWZ0IG9mIHRoZSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cuPGJyPg0KPGJyPg0K T25lIG9mIHRoZSB0aGluZ3Mgd2UgZm91bmQgdXNlZnVsLCBhbmQgbm90IGluY2x1ZGVkIGluIHRo ZSBjdXJyZW50IE9BdXRoIDIuMCBEZXZpY2UgRmxvdyBbMiwgc2VjdGlvbiAzLjVdLCBpcyBhIHJl dHVybiBjb2RlIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVj aWRlcyB0byBjYW5jZWwgdGhlIHBhaXJpbmcgcHJvY2Vzcy4gVGhpcyBtYXkgYmUgZHVlIHRvIGEg dXNlciBpbnRlcmFjdGlvbiwgc3VjaCBhcyBkZWNsaW5pbmcNCiB0aGUgcHJlc2VudGVkIHRlcm1z IGFuZCBjb25kaXRpb25zLCBmb3IgZXhhbXBsZS4gU3VjaCBhIHJldHVybiBjb2RlIGFsbG93cyB0 aGUgY2xpZW50IHRvIHN0b3AgcG9sbGluZyBhbmQgdG8gZGlzcGxheSBhbiBhcHByb3ByaWF0ZSBt ZXNzYWdlIHRvIHRoZSB1c2VyLiAoSSBkaWRuJ3QgZmluZCBhIHN1aXRhYmxlIGVycm9yIGNvZGUg aW4gUkZDNjc0OS4pPGJyPg0KPGJyPg0KSW4gdGhlIEVUU0kgc3BlYyB3ZSB1c2VkIHRoZSBlcnJv ciBjb2RlICdjYW5jZWxsZWQnIGZvciB0aGlzIHB1cnBvc2U6PGJyPg0KPGJyPg0KY2FuY2VsbGVk PGJyPg0KPGJyPg0KJm5ic3A7IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBoYXMgY2FuY2VsbGVk IHRoZSBwYWlyaW5nIHByb2Nlc3MuIFRoaXMgY2FuIG9jY3VyLDxicj4NCiZuYnNwOyBmb3IgZXhh bXBsZSwgaWYgdGhlIHVzZXIgZGVjbGluZWQgdG8gYXV0aG9yaXplIHRoZSBjbGllbnQsIGUuZy4s IGJ5IG5vdDxicj4NCiZuYnNwOyBhY2NlcHRpbmcgdGVybXMgYW5kIGNvbmRpdGlvbnMgcHJlc2Vu dGVkIHRvIHRoZW0gYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLjxicj4NCjxicj4NCkJlc3Qg cmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpczxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwOi8v d3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV90cy8xMDM0MDBfMTAzNDk5LzEwMzQwNy8wMS4wMS4w MV82MC90c18xMDM0MDd2MDEwMTAxcC5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cu ZXRzaS5vcmcvZGVsaXZlci9ldHNpX3RzLzEwMzQwMF8xMDM0OTkvMTAzNDA3LzAxLjAxLjAxXzYw L3RzXzEwMzQwN3YwMTAxMDFwLnBkZjwvYT48YnI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA2LnR4dCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWRl dmljZS1mbG93LTA2LnR4dDwvYT48YnI+DQo8YnI+DQotLTxicj4NCkNocmlzIE5lZWRoYW08YnI+ DQpQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXI8YnI+DQpCQkMgUmVzZWFyY2ggJmFtcDsgRGV2 ZWxvcG1lbnQ8YnI+DQpDZW50cmUgSG91c2UsIDU2IFdvb2QgTGFuZSwgTG9uZG9uIFcxMiA3U0I8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_590FCC451AE69B47BFB798A89474BB363D8DF3B1bgb01xud1006_-- From nobody Wed Jul 5 10:18:21 2017 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 A6914131D8A for ; Wed, 5 Jul 2017 10:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 AFRJqP9K0SGn for ; Wed, 5 Jul 2017 10:18:10 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 875A0131D84 for ; Wed, 5 Jul 2017 10:18:10 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id b40so83490497qtb.2 for ; Wed, 05 Jul 2017 10:18: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; bh=iURA3FpTn/Q2n3G0nOYHNFHdhcwbJ3srNT+yrALS8iU=; b=OA2Wq++Ty5CfaI7TD2QTL2h/wdzEn4HSmOMGZEzuXB9diCQO0fYC5dop8tYVPdElow 0667ObVFwqNB+tC+UdwwIVr3f3bYe5PjE6lpLnHJVm5Trq/Bcpa/H5yVudxE2hC5rPCN 8pUOmFciSMdaAOSIxx5tIuy9t3ZrKHu1u9p9yeaOlzJJojawZ/+c7i5Ffbgp+6T48lLm 4v4T1rOe4gNxdG9K5SheJgLZAXMWR00okJHa8hMnpdGE2tu+Xt5j/6kUx3es75Bre3Eo EwP+hTJXj1pTBi1QAhYhKuR7iymEcE+nYk8L34AiqLzMLXkNmWGp1gH0imylPqfhvyIJ XFNg== 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=iURA3FpTn/Q2n3G0nOYHNFHdhcwbJ3srNT+yrALS8iU=; b=U8kbWzqCOueRxY3y6TkSC5VgRcXsQj/cCEuzUcM04sT8CbIRXZY+bH6Z5EQgqaZ7TM p6BEaSn7I/w5aPuYLXk5v7j6IOfS/6yS9KZkd/Qo3yOaenpS0sAgVyQhg7xKtr/AYst6 3orqWdoJy+Anq+4EDyUJ2oNrL7Sek/7iqQbQ7pJkYc/sYYCS5btrGVoiKPQrTgk/Swwl pEycYtujM0CrzOT8dcCRL9b8dPKR6UBSsFb/KAAMboqReHs0HBH18y11xxjdWWOg4ues JYL1oWJ4dtSfwBgcJb9omzyW0R/KPwPgNBCNej5i0diV7ye6bDCxv43G3C84DWYsNSGU fWJQ== X-Gm-Message-State: AIVw111xmxIRMOC1Hxp7mrPTLsC2ZAI/GlUTBVa9UjBtJ+uBfs1bTpPE k1FjwpAXgDgfWjhVcttWXck1hOe1TEEiwetDrA== X-Received: by 10.200.35.21 with SMTP id a21mr25821086qta.56.1499275089081; Wed, 05 Jul 2017 10:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Wed, 5 Jul 2017 10:17:48 -0700 (PDT) From: William Denniss Date: Wed, 5 Jul 2017 10:17:48 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a113a8f4c1b76bb0553952fb6" Archived-At: Subject: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:18:13 -0000 --001a113a8f4c1b76bb0553952fb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Earlier this week I submitted the following I-D: https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth The topic is incremental authentication (or incremental auth for short). Incremental auth is used to enable clients to request just the scopes they need when they need them =E2=80=93 rather than all upfront =E2=80=93 while = still only a maintaining a single authorization grant. The I-D details two techniques used at Google, one that has been used for a while in confidential clients, and one that we launched recently as a new solution to deliver incremental auth for public clients. I look forward to discussing this proposal with the working group. I plan to present this draft at IETF99, hope you can be there or watching the livestream! I plan to ask for a call for adoption after that presentation. If you're interested in this topic I'd encourage you to read the draft (it's fairly concise!). Best, William --001a113a8f4c1b76bb0553952fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Earlier this week I submitted the following I-D: h= ttps://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth
<= div>
The topic is incremental authentication (or incremental = auth for short).=C2=A0 Incremental auth is used to enable clients to reques= t just the scopes they need when they need them =E2=80=93 rather than all u= pfront =E2=80=93 while still only a maintaining a single authorization gran= t.

The I-D details two techniques used at Google, = one that has been used for a while in confidential clients, and one that we= launched recently as a new solution to deliver incremental auth for public= clients.

I look forward to discussing this propos= al with the working group. I plan to present this draft at IETF99, hope you= can be there or watching the livestream!

I plan t= o ask for a call for adoption after that presentation. If you're intere= sted in this topic I'd encourage you to read the draft (it's fairly= concise!).

Best,
William

=
--001a113a8f4c1b76bb0553952fb6-- From nobody Thu Jul 6 11:48:59 2017 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 A960A1316E3 for ; Thu, 6 Jul 2017 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kRltkHUsSYZv for ; Thu, 6 Jul 2017 11:48:56 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 C90D812EC18 for ; Thu, 6 Jul 2017 11:48:55 -0700 (PDT) X-AuditID: 12074425-8edff700000017cc-d3-595e8616a7f0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id EB.55.06092.6168E595; Thu, 6 Jul 2017 14:48:54 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v66ImrMZ030830 for ; Thu, 6 Jul 2017 14:48:53 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v66ImpE8015165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Jul 2017 14:48:52 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 6 Jul 2017 14:48:51 -0400 To: "" X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixCmqrSvWFhdp8LfRyOLk21dsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPPwEGvBb/mKg3ffszYwHpTqYuTkkBAwkfi6chZzFyMXh5DA YiaJBf9+QDlHGSV2b9vKDuF8ZZL48G01M0gLm4CqxPQ1LUwgNrOAusSfeZeYIWxtiWULXwPZ HBy8AvoSvc8ZQcLCAioSz25/ZAOxeQWsJA6cOgJWzgIU/3D5OzuILQI0Zs35n0wQF8lK3Jp9 iXkCI+8sJBtmIdkwC2HDAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWbGEGh xO6iuoNxzl+vQ4wCHIxKPLw7XOIihVgTy4orcw8xSnIwKYnyVpgDhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwbpUEyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKErwW rUCNgkWp6akVaZk5JQhpJg5OkOE8QMPTakGGFxck5hZnpkPkTzHqcrya8P8bkxBLXn5eqpQ4 bw3IIAGQoozSPLg5oBSQ8Paw6StGcaC3hHmntABV8QDTB9ykV0BLmICWKDbGgCwpSURISTUw en+rUbN/cGhm7eqaV5xW23czpy0KjWptKFCyOHNn2YzQrbHMX+c3Pbty1Xr3lSwmhRYh87lP Ly/2866J2CagerU76ITYlNSrJlcfPcpmfDnnsFxdvVym5CLN1illbypOXu34fud82P4vRdeq J/89v+PKo/NZb86LPXr+XPF0akD/oR83El9nmSqxFGckGmoxFxUnAgCAMWEG3AIAAA== Archived-At: Subject: [OAUTH-WG] Review of Device Flow Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 18:48:57 -0000 Finally had a chance to review the device flow draft in earnest. Overall = it=E2=80=99s really great, and we=E2=80=99ve implemented it in a few = places (see my recent post on one interesting use case). Just a few = notes: - use of =E2=80=9Cflow=E2=80=9D has largely been replaced by = =E2=80=9Cauthorization grant=E2=80=9D in other documents and we should = be consistent here - use of =E2=80=9Cend-user=E2=80=9D has been replaced by =E2=80=9Cresource= owner=E2=80=9D in other documents and we should be consistent here - =E2=80=9Cinput constrained=E2=80=9D should be =E2=80=9Cinput-constrained= =E2=80=9D as used in the title, abstract, and introduction. - =C2=A71=C2=B63 could be rewritten to a bulleted list of requirements = instead for readability - =C2=A71=C2=B64 could add something to address recent discussion on the = list: =E2=80=9CWhile this polling is usually automatic and repeated on a = regularly timed basis, the client could poll based on user action with = the device such as a button press.=E2=80=9D - =C2=A71 diagram (D) should state that the user is prompted to enter = the user code given in (C) and that the user does so =E2=80=94 leaving = it out is an optimization (see below) and the likely exception - =C2=A72 should probably be =C2=A71.1, or move the protocol flow to = =C2=A71.1 and make =C2=A72 into =C2=A71.2 - =C2=A72 should import all terms used from 6749/6750 explicitly - =C2=A72 should we define =E2=80=9Csecondary device=E2=80=9D once at = the top instead of the parenthetical definition used throughout? - =C2=A73.1=C2=B61 Wording is awkward with double =E2=80=9Cby=E2=80=9D = phrases, suggest: =E2=80=9CThe client initiates the authorization grant = request by making an HTTP POST request to the device authorization = endpoint.=E2=80=9D - =C2=A73.2 add xref to JSON (7159), response is a JSON object with the = following members (not parameters) - =C2=A73.2 is there any requirement for the verification_uri to be over = HTTPS? I can=E2=80=99t see any discussion of this anywhere and it should = probably at least be in the security considerations, if not an outright = requirement. We say that authentication is done in a tls-protected = session in =C2=A73.3 but we don=E2=80=99t say anything about the actual = URL or the page in which the user enters the code. - =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous = (timer-based) or in reaction to a user action at the device. There are = no protocol differences and the AS shouldn=E2=80=99t do try and inform = the user, but we can at least mention that in our description of = polling. - =C2=A73.3.1 I still think this optimized all-in-one URI should be a = separate parameter from the AS so as not to conflate it with the = =E2=80=9Cplain=E2=80=9D verification URI. - =C2=A73.4=C2=B63 instead of =E2=80=9Cbased on the error code in the = response=E2=80=9D perhaps =E2=80=9Cuntil the authorization server = indicates the device code has expired or was cancelled.=E2=80=9D =E2=80=94= I=E2=80=99m less sure about the wording here but as written it feels = awkward. - =C2=A73.5 I agree with the point made on the list about the error = code, =E2=80=9Caccess_denied=E2=80=9D would fit this bill but right now = it=E2=80=99s only specified on authorization endpoint response, so = let=E2=80=99s add its use to the token response here - =C2=A73.5=C2=B64 says to return =E2=80=9Cinvalid_grant=E2=80=9D if the = codes are expired, but in the same section it says to use = =E2=80=9Cexpired_code=E2=80=9D.=20 - =C2=A73.5=C2=B65 the interval between polls SHOULD be at least the = =E2=80=9Cinterval=E2=80=9D value. Also, it MUST be greater than zero =E2=80= =A6 William =E2=80=A6=20 - =C2=A75.2 =E2=80=9Cuser=E2=80=99s session and device=E2=80=9D, use of = =E2=80=9Cdevice=E2=80=9D here is confusing since this is the = =E2=80=9Cdevice=E2=80=9D flow. Maybe explicitly call out this as the = =E2=80=9Csecondary device=E2=80=9D=20 - =C2=A75.5 extra =E2=80=9Cor=E2=80=9D in list in final sentence =E2=80=94 Justin= From nobody Thu Jul 6 23:33:43 2017 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 7D9BB12EE8D for ; Thu, 6 Jul 2017 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hT2srMiI-P6L for ; Thu, 6 Jul 2017 23:33:39 -0700 (PDT) Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0829F12EE45 for ; Thu, 6 Jul 2017 23:33:38 -0700 (PDT) From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: Suggested enhancement of the OAuth Device Flow Thread-Index: AQHS9ur1grAAlq+Fl0Kqhg7ktNAjvA== Date: Fri, 7 Jul 2017 06:33:34 +0000 Message-ID: <86D2DFE8-DBAC-4B78-B471-07E246185E5F@iwelcome.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.5.138] Content-Type: text/plain; charset="utf-8" Content-ID: <3EC1A65AE9A0A142831119204F69A40E@enterexchange.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 06:33:41 -0000 SGkgYWxsLA0KDQpSZWNlbnRseSB3ZSB3ZXJlIHdvcmtpbmcgd2l0aCBvbmUgb2Ygb3VyIGN1c3Rv bWVycyB0byBpbXBsZW1lbnQgdGhlIGRldmljZSBmbG93IGFzIHBhcnQgb2Ygb3VyIElEYWFTLg0K T25lIG9mIHRoZSByZXF1aXJlbWVudHMgd2FzIHRoZSBhYmlsaXR5IHRvIHJldm9rZSB0b2tlbnMg Zm9yIG9uZSBvZiB0aGUgZGV2aWNlcyBhdCB0aGUgUmVzb3VyY2UgU2VydmVyLg0KDQpJbiBvdXIg dXNlIGNhc2UsIHdlIHVzZWQgdGhlIHRlcm1pbm9sZ3kg4oCYcGFpcmluZyBhIGRldmljZSB0byB0 aGUgZW5kdXNlcuKAmXMgYWNjb3VudOKAmSB0byBkZXNjcmliZSB0aGUgcHJvY2VzcyBvZiBhdXRo b3Jpc2luZyBhIGRldmljZSB0byBhY2Nlc3MgdGhlIHJlc291cmNlIG93bmVy4oCZcyByZXNvdXJj ZXMuDQpUaGUgcmVzb3VyY2Ugb3duZXIgbWF5IHdhbnQgdG8g4oCYdW5wYWly4oCZIGEgZGV2aWNl IGZyb20gYSBsaXN0IG9mIHBhaXJlZCBkZXZpY2VzIHdpdGhvdXQgaGF2aW5nIGFjY2VzcyB0byB0 aGUgZGV2aWNlIGl0c2VsZiAoYW55bW9yZSkuIFRoaW5rIGFib3V0IGEgc3RvbGVuL2xvc3Qga2lu ZCBvZiBzaXR1YXRpb24uDQpXZSBhcmUgbG9va2luZyBmb3Igd2F5cyB0byBhbGxvdyB0aGUgdXNl ciB0byB1bnBhaXIgb25lIG9mIGhpcyBkZXZpY2VzIGF0IHRoZSBBdXRob3Jpc2F0aW9uIFNlcnZl ci4NClNpbmNlIHRoZSBEZXZpY2UgRmxvdyBleGNoYW5nZXMgb25seSB0aGUg4oCYZ2VuZXJpY+KA mSBjbGllbnRfaWQgd2l0aCB0aGUgQXV0aG9yaXNhdGlvbiBTZXJ2ZXIsIHRoZXJlIGlzIG5vIGxv Z2ljYWwgd2F5IGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXIgdG8gbWFrZSBhIGRpc3RpbmN0aW9uIGJl dHdlZW4gdmFyaW91cyBkZXZpY2VzIChoYXZpbmcgdGhlIHNhbWUgY2xpZW50X2lkKSB0aGF0IG1h eSBiZSBwYWlyZWQgdG8gdGhlIHNhbWUgUmVzb3VyY2UgT3duZXIuDQoNCk15IHN1Z2dlc3Rpb24g aXMgdGhlIGZvbGxvd2luZw0KLSBhZGQgYW4gb3B0aW9uYWwgcGFyYW1ldGVyIHRvIHRoZSBkZXZp Y2UgYXV0aG9yaXNhdGlvbiByZXF1ZXN0IChvciBkZXZpY2UgYWNjZXNzIHRva2VuIHJlcXVlc3Qp OiAnZGV2aWNlX2lkZW50aWZpZXInLiBBIGRldmljZSBjYW4gdXNlIHRoaXMgdG8gbWFrZSAoZm9y IGV4YW1wbGUpIGl0cyBzZXJpYWwtbnVtYmVyIGtub3duIGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXIu DQotIGFkZCBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgdG8gdGhlIGRldmljZSBhY2Nlc3MgdG9rZW4g cmVzcG9uc2UgdGhhdCBhbGxvd3MgdG8gY29tbXVuaWNhdGUgYSBuYW1lIGZvciB0aGUgZGV2aWNl IGFzIG1heSBoYXZlIGJlZW4gZ2l2ZW4gdG8gaXQgYnkgdGhlIHJlc291cmNlIG93bmVyIHdoaWxl IGFsbG93aW5nIHRoZSBjbGllbnRzIGFjY2VzcyAoRSkuIFRoaXMgcGFyYW1ldGVyIGNvdWxkIGJl IHNvbWV0aGluZyBsaWtlIOKAmGRldmljZV9uYW1l4oCZLiBUaGUgZGV2aWNlIG1heSBiZSBhYmxl IHRvIGRpc3BsYXkgdGhpcyDigJhkZXZpY2VfbmFtZeKAmSBvbiBpdHMgZGlzcGxheS4NCg0KUGxl YXNlIGNvbnNpZGVyIHRoaXMgYXMgYSBzdWdnZXN0ZWQgZW5oYW5jZW1lbnQgb2YgdGhlIERldmlj ZSBGbG93IHNwZWNpZmljYXRpb25zLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCkphYXAgRnJhbmNrZQ0K UHJvZHVjdCBNYW5hZ2VyLCBpV2VsY29tZQ0KDQoNCg0K From nobody Fri Jul 7 04:55:08 2017 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 3994812EAAA for ; Fri, 7 Jul 2017 04:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 uDWoP8aqMVuW for ; Fri, 7 Jul 2017 04:55:05 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 76209129AD2 for ; Fri, 7 Jul 2017 04:55:05 -0700 (PDT) X-AuditID: 12074424-1d9ff70000001c32-d2-595f7697bb27 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id FA.75.07218.7967F595; Fri, 7 Jul 2017 07:55:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v67Bt2Kw031063 for ; Fri, 7 Jul 2017 07:55:03 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v67Bt1VE012774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 7 Jul 2017 07:55:02 -0400 To: oauth@ietf.org References: <86D2DFE8-DBAC-4B78-B471-07E246185E5F@iwelcome.com> From: Justin Richer Message-ID: <71e43e3c-2bd3-d706-2c82-6020de8ff881@mit.edu> Date: Fri, 7 Jul 2017 07:54:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <86D2DFE8-DBAC-4B78-B471-07E246185E5F@iwelcome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6noju9LD7S4MlFeYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/y112wFCwUrHi5ZxdzA2M/XxcjJISFgIrHjwH+mLkYuDiGB xUwSJw+fYgRJCAkcZZT43BwJkXjPJHHp112gBAeHsICbxO5pVSA1IgJCEs939jFB1OdJLJrc BdbLJqAqMX1NC1icV8BK4vTvG2wgNouAisT5d2fB4qICMRLXZt5hhagRlDg58wkLiM0p4CCx 5/g/sDnMAmYS8zY/ZIaw5SWat86GssUlbj2ZzzSBUWAWkvZZSFpmIWmZhaRlASPLKkbZlNwq 3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjOBQdVHZwdjd432IUYCDUYmHd4dLXKQQa2JZ cWXuIUZJDiYlUd43PvGRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4m72BcrwpiZVVqUX5MClp DhYlcV5xjcYIIYH0xJLU7NTUgtQimKwMB4eSBG9iCVCjYFFqempFWmZOCUKaiYMTZDgP0PAi cZDhxQWJucWZ6RD5U4y6HKtm/vzGJMSSl5+XKiXOexpkkABIUUZpHtwcUIpJeHvY9BWjONBb wrwbi4GqeIDpCW7SK6AlTEBLFBtjQJaUJCKkpBoYNY/tmno78c26y0GCOyLOnNPybOu/11S9 YudDsU0vV91Md80x3iQWVqwu5Dr76A+F5den+a87zqEnmLHbb0HmgpNX/q69dmBawtoNzbVq IqXbRO31Dj0QbLl1/pyIvp7D8vJfUV27j1zZxHBjyqQzG+59M1Ws66maqbzKLTWwIUzVUi5Y 4/79BCWW4oxEQy3mouJEAIygtd0MAwAA Archived-At: Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:55:07 -0000 I proposed this exact thing many years ago: https://tools.ietf.org/html/draft-richer-oauth-instance-00 At the time there wasn't very much interest in it, as people were looking at using Dynamic Registration, with its attendant unique client IDs, to solve that same problem. -- Justin On 7/7/2017 2:33 AM, Jaap Francke wrote: > Hi all, > > Recently we were working with one of our customers to implement the device flow as part of our IDaaS. > One of the requirements was the ability to revoke tokens for one of the devices at the Resource Server. > > In our use case, we used the terminolgy ‘pairing a device to the enduser’s account’ to describe the process of authorising a device to access the resource owner’s resources. > The resource owner may want to ‘unpair’ a device from a list of paired devices without having access to the device itself (anymore). Think about a stolen/lost kind of situation. > We are looking for ways to allow the user to unpair one of his devices at the Authorisation Server. > Since the Device Flow exchanges only the ‘generic’ client_id with the Authorisation Server, there is no logical way at the Resource Server to make a distinction between various devices (having the same client_id) that may be paired to the same Resource Owner. > > My suggestion is the following > - add an optional parameter to the device authorisation request (or device access token request): 'device_identifier'. A device can use this to make (for example) its serial-number known at the Resource Server. > - add an optional parameter to the device access token response that allows to communicate a name for the device as may have been given to it by the resource owner while allowing the clients access (E). This parameter could be something like ‘device_name’. The device may be able to display this ‘device_name’ on its display. > > Please consider this as a suggested enhancement of the Device Flow specifications. > > Kind regards, > > Jaap Francke > Product Manager, iWelcome > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jul 7 09:24:49 2017 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 2032E12EC04 for ; Fri, 7 Jul 2017 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SXdL982Rt32O for ; Fri, 7 Jul 2017 09:24:45 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 208D812EB21 for ; Fri, 7 Jul 2017 09:24:45 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id r103so53816074wrb.0 for ; Fri, 07 Jul 2017 09:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4x0ajMHNJpPETKE5ROulkkDLbD4+O0ndrwbDlVFEkdc=; b=gB9JIh+sRcWAESQZ7gFawqkOmgYiOAzCGI4ylvnBTI8WiCe0vpHpMhMlw87LqxVoGV knRWP4jvwfVjJFkFSLfhDBEeYjaBhDNI4j6LxmlsQpAhhrV92sjw9T2O2owDaakAZbi8 fcKnqThh4CsxbM+Ag83tttILVDvLalToU/xAQUk0dZ4RjZmSCY2/qTWmqytV/0gKST6M 3VJfNyxpMkKl8CvDBjDtrH+sQu/cJ9iKYtEh97Qw/E7AnFigyhW1CZnu0lkDlAoZ7KYb cGnDOyiSk6Va6DK3CV8G9NGY2K8E9kgo554AC5/qguc5vTZGRN0eBLSl6YEWRMApR3n1 2T+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4x0ajMHNJpPETKE5ROulkkDLbD4+O0ndrwbDlVFEkdc=; b=pH0CnE+I1zJWeePircCPeBvNXLN5Ru6tx42jBjBlFQeb/5Kic35JaroD97rQnKFwaI 5iuPmv0YRZDQJXsNUzb/kSEc/aQXQpgNy4nHl7GlWzrXwdPe2apXXIrD2x5WqgvzZonQ 4hwwjffGog8r0CvblIGu9ZQHu6ViTFpMkH6JYqSj5MvJKYuEzRix0B5dRfmZfcr5gKov /gLB25pxm7V19UvCdVshzE2mqs3FmuqOpYh6JiBvyDRZUh6rMZ0XYeuy0ItFrI7S5faC Rz3rjxgE01Mwh37VXnGVzpczboNgzNgzXKa6EQDDTEEKGZHJx3B07WT3ArmpLQ4fPTAn isgg== X-Gm-Message-State: AIVw110tLaD16dLSQ6N4dEYBPdSNhQrG4m7e9VPOF6d9wgelOAZTwtZw BsGBvNmUIOuYK9otFxw= X-Received: by 10.80.179.12 with SMTP id q12mr2817819edd.151.1499444683535; Fri, 07 Jul 2017 09:24:43 -0700 (PDT) Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id z58sm2184691edb.50.2017.07.07.09.24.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 09:24:42 -0700 (PDT) From: Sergey Beryozkin To: oauth@ietf.org References: Message-ID: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> Date: Fri, 7 Jul 2017 17:24:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 16:24:47 -0000 Hi Re the confidential client: let me explain please how we experimented with this feature when the code flow is used. 1. Client requests a scope 'a' for a given User, it gets approved by the user, the clients gets a code and exchanges it for a token. 2. At some later stage Client requests a scope 'b' for the same user and if an access token for a given Client + User combination exists and the incremental authorization is supported (we use a different term for now) than the service finds out from this token that 'a' has already been approved and offers a consent screen where a user sees 'a' being selected and needs to approve 'b'. 3. User approves 'b'. The client gets a new code back and exchanges it for a new token which now has "a" and "b". At this point a client has 2 tokens, one with the "a" scope and another with the "a" and "b" scopes and the assumption was that the client would itself remove the now redundant token with the scope "a" only. I've just updated the code for the service itself do it on the client's behalf, optionally remove the scope "a" token so that the client can simply replace a reference to its scope "a" token with the new one (scopes "a" and "b") it will get after exchanging a code grant. Is it an incremental authorization or something else completely :-) ? One obvious difference, apart from the lower level implementation details, is that it is not a client which requests to include the already authorized scopes but the service does it itself if the configuration allowing for it is enabled Thanks, Sergey On 05/07/17 18:17, William Denniss wrote: > Earlier this week I submitted the following I-D: > https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth > > The topic is incremental authentication (or incremental auth for > short). Incremental auth is used to enable clients to request just the > scopes they need when they need them – rather than all upfront – while > still only a maintaining a single authorization grant. > > The I-D details two techniques used at Google, one that has been used > for a while in confidential clients, and one that we launched recently > as a new solution to deliver incremental auth for public clients. > > I look forward to discussing this proposal with the working group. I > plan to present this draft at IETF99, hope you can be there or watching > the livestream! > > I plan to ask for a call for adoption after that presentation. If you're > interested in this topic I'd encourage you to read the draft (it's > fairly concise!). > > Best, > William > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Jul 7 10:56:50 2017 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 BA1CF13167C for ; Fri, 7 Jul 2017 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 3tOPkHSVIxtc for ; Fri, 7 Jul 2017 10:56:45 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 3F46313153B for ; Fri, 7 Jul 2017 10:56:45 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id v143so33590307qkb.0 for ; Fri, 07 Jul 2017 10:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ObS+k51WgfrqMWClm7Hfc48Cd+EfmgK3tVj2xlGp5Ek=; b=cEEoPjdc3HuGgltyOSbdNfrfAL7CWM7eU4xEtfMVZ6Y4C4Z2mYZzcEaCBcsGvQZI+d iaHhn7dc4dw8SLWl6/0PbAQpLtW5hpmPChB/l0KsK1XhSjoDHWKhqvssh+T6lS6D6HiX m1Cfe5H9BFlGKQKg6XgGPn4EN440VFm75p884U244B2dVJFSTj3GWQqRZI8x2JMIQ+89 /419FXwSkNSbjY26xlJg/sMyCuGZ8axD+YB3nSuiO8/0qcNgytlsl8NkowktBEY3id3E R/qa2WAoebFQzHeD3Yo36zAf8aiB+otwp5+j61pHDfv3XrqSJnQTMxBAvb38+pvnki34 j4Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ObS+k51WgfrqMWClm7Hfc48Cd+EfmgK3tVj2xlGp5Ek=; b=etmddMKhYWZk59Wy0Dy26BG8uM9upUKCV/dSIfTzEcqmGMfyIbNgxEYHaj4lsvRzmM qTqRlGmie+V+s18eiyAVlm0M9dSQR0nPfCu2gRaJhxXAJwXEoIAqXoJ2beC9yU0ZldIU ETrUu8c4bHCVgT2dETk+/s0WyCO6fFmpDV8eDkmb0WsG6N72VqsJxTMuMfqGPjU0WCSV RCIgBY+oCaDZehRLw8zX5EptHwtNJtXuBvgX3WFCZa6Dt7k7D2KM5AarNol10nin/5PC /sJdsD50Lu0sPtJQCdcePOHEj1GVUVL25MCQWHuLgto5Wa2xXGIzdXvBKyj6EgVn76c8 Y5zg== X-Gm-Message-State: AKS2vOxjnafxm3L7j7t56iPt7nCoDLQkbE5ILmMnJEa4wPXpOWDoqq1g 6IerWhR6/Isx5JQ/ogc++hF80gzbVL/uwny4MQ== X-Received: by 10.55.7.8 with SMTP id 8mr64351985qkh.124.1499450203920; Fri, 07 Jul 2017 10:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Fri, 7 Jul 2017 10:56:23 -0700 (PDT) In-Reply-To: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> References: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> From: William Denniss Date: Fri, 7 Jul 2017 10:56:23 -0700 Message-ID: To: Sergey Beryozkin Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a114c46f4c409650553bdf40b" Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 17:56:48 -0000 --001a114c46f4c409650553bdf40b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What you describe is incremental auth. Aside: Do you return the "scope" in the token response as required when the scope in the response is not identical to the request (=C2=A7 5.1 , parameter: scope)? My only question is: does the client expect this? The spec talks about the authorization server *reducing* scope in a few places (in =C2=A7 3.3 , "The authorization server MAY fully or partially ignore the scope requested by the client" and =C2=A7 10.3 "The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and MAY issue an access token with less rights than requested."). It never talks about *increasing* scope (other than it can't be done during refresh). So I think some normative language around the potential to increase the scope of the request for confidential clients (in either the way you describe, or the way I described in the draft) is warranted. Open question: should we require an indication from the client if they *want* the scope increase? That's what include_granted_scopes was designed to do. To allow clients to specify if this is behavior they desire. The more innovative part of the spec I think is the public (native app) client incremental auth =E2=80=93 as native apps cannot use the methods you discuss, or the ones Google has supported for a while for confidential clients. That said, if we write this =E2=80=93 I think we may as well forma= lly document approaches for confidential clients too. On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin wrote: > Hi > > Re the confidential client: let me explain please how we experimented wit= h > this feature when the code flow is used. > > 1. Client requests a scope 'a' for a given User, it gets approved by the > user, the clients gets a code and exchanges it for a token. > > 2. At some later stage Client requests a scope 'b' for the same user and > if an access token for a given Client + User combination exists and the > incremental authorization is supported (we use a different term for now) > than the service finds out from this token that 'a' has already been > approved and offers a consent screen where a user sees 'a' being selected > and needs to approve 'b'. > > 3. User approves 'b'. The client gets a new code back and exchanges it fo= r > a new token which now has "a" and "b". > > At this point a client has 2 tokens, one with the "a" scope and another > with the "a" and "b" scopes and the assumption was that the client would > itself remove the now redundant token with the scope "a" only. > > I've just updated the code for the service itself do it on the client's > behalf, optionally remove the scope "a" token so that the client can simp= ly > replace a reference to its scope "a" token with the new one (scopes "a" a= nd > "b") it will get after exchanging a code grant. > > Is it an incremental authorization or something else completely :-) ? > > One obvious difference, apart from the lower level implementation details= , > is that it is not a client which requests to include the already authoriz= ed > scopes but the service does it itself if the configuration allowing for i= t > is enabled > > Thanks, Sergey > > > > > > > On 05/07/17 18:17, William Denniss wrote: > >> Earlier this week I submitted the following I-D: >> https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth >> >> The topic is incremental authentication (or incremental auth for short). >> Incremental auth is used to enable clients to request just the scopes th= ey >> need when they need them =E2=80=93 rather than all upfront =E2=80=93 whi= le still only a >> maintaining a single authorization grant. >> >> The I-D details two techniques used at Google, one that has been used fo= r >> a while in confidential clients, and one that we launched recently as a = new >> solution to deliver incremental auth for public clients. >> >> I look forward to discussing this proposal with the working group. I pla= n >> to present this draft at IETF99, hope you can be there or watching the >> livestream! >> >> I plan to ask for a call for adoption after that presentation. If you're >> interested in this topic I'd encourage you to read the draft (it's fairl= y >> concise!). >> >> Best, >> William >> >> >> >> _______________________________________________ >> 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 > --001a114c46f4c409650553bdf40b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What you describe is incremental auth.

= Aside: Do you return the "scope" in the token response as require= d when the scope in the response is not identical to the request (=C2=A7 5.1, parame= ter: scope)?

My only question is: does the client = expect this?=C2=A0 The spec talks about the authorization server *reducing*= scope in a few places (in=C2=A0=C2=A7 3.3, "The authorization server MAY fully o= r partially ignore the scope requested by the client" and=C2=A0=C2=A7=C2=A010.3 = "The authorization server SHOULD take the client identity into account= when choosing how to honor the requested scope and MAY issue an access tok= en with less rights than requested.").=C2=A0 It never talks about *inc= reasing* scope (other than it can't be done during refresh).
=
So I think some normative language around the potential to i= ncrease the scope of the request for confidential clients (in either the wa= y you describe, or the way I described in the draft) is warranted.

Open question: should we require an indication from the cl= ient if they *want* the scope increase? That's what include_granted_sco= pes was designed to do. To allow clients to specify if this is behavior the= y desire.


The more innovative part = of the spec I think is the public (native app) client incremental auth =E2= =80=93 as native apps cannot use the methods you discuss, or the ones Googl= e has supported for a while for confidential clients. That said, if we writ= e this =E2=80=93 I think we may as well formally document approaches for co= nfidential clients too.


On Fri, Jul 7, 2017 at 9:24 AM, Sergey= Beryozkin <sberyozkin@gmail.com> wrote:
Hi

Re the confidential client: let me explain please how we experimented with = this feature when the code flow is used.

1. Client requests a scope 'a' for a given User, it gets approved b= y the user, the clients gets a code and exchanges it for a token.

2. At some later stage Client requests a scope 'b' for the same use= r and if an access token for a given Client + User combination exists and t= he incremental authorization is supported (we use a different term for now)= than the service finds out from this token that 'a' has already be= en approved and offers a consent screen where a user sees 'a' being= selected and needs to approve 'b'.

3. User approves 'b'. The client gets a new code back and exchanges= it for a new token which now has "a" and "b".

At this point a client has 2 tokens, one with the "a" scope and a= nother with the "a" and "b" scopes and the assumption w= as that the client would itself remove the now redundant token with the sco= pe "a" only.

I've just updated the code for the service itself do it on the client&#= 39;s behalf, optionally remove the scope "a" token so that the cl= ient can simply replace a reference to its scope "a" token with t= he new one (scopes "a" and "b") it will get after excha= nging a code grant.

Is it an incremental authorization or something else completely :-) ?

One obvious difference, apart from the lower level implementation details, = is that it is not a client which requests to include the already authorized= scopes but the service does it itself if the configuration allowing for it= is enabled

Thanks, Sergey






On 05/07/17 18:17, William Denniss wrote:
Earlier this week I submitted the following I-D: https://tools.ietf.org/html/draft-wdenniss-oauth-increme= ntal-auth

The topic is incremental authentication (or incremental auth for short).=C2= =A0 Incremental auth is used to enable clients to request just the scopes t= hey need when they need them =E2=80=93 rather than all upfront =E2=80=93 wh= ile still only a maintaining a single authorization grant.

The I-D details two techniques used at Google, one that has been used for a= while in confidential clients, and one that we launched recently as a new = solution to deliver incremental auth for public clients.

I look forward to discussing this proposal with the working group. I plan t= o present this draft at IETF99, hope you can be there or watching the lives= tream!

I plan to ask for a call for adoption after that presentation. If you'r= e interested in this topic I'd encourage you to read the draft (it'= s fairly concise!).

Best,
William



_______________________________________________
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

--001a114c46f4c409650553bdf40b-- From nobody Fri Jul 7 13:22:15 2017 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 323C8126C3D for ; Fri, 7 Jul 2017 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HhGdW4Y_hqkZ for ; Fri, 7 Jul 2017 13:22:12 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 A1222131678 for ; Fri, 7 Jul 2017 13:22:12 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d78so36545320qkb.1 for ; Fri, 07 Jul 2017 13:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=M29McPR1cfUdmTsytJ/L6ARbkpRAatnfOcEkMtjkp9U=; b=TyMeOr+rkeGoSaXSTSc8m7ixB8CgwtWoCLuwajpjyMX4QjDh5BScpe1sFGPZZ578o5 axJE6rf5xpAsh9XHmnnLdHdPMKdqOTLGAkSVH5ZO7q1G+K2r3XEAcSjwHVeEkmxk6k7e qgK8hCvO4xjd/hLWfoAyghoFzuNjwi+BRurK1uAyDkEhOWirxd11bKIydrzFteADus1G eRm0O+XQmo3ZWBM9OpXiRIPhx2uDMgOfnZop9934U6SxmUFhmpE55b4GYvm6a7+CCWuu mNcn7ig0PGFb9t7I+CVlwqMZoZVpF3q6dHUjJaHraMQ40fC5fsEgBqzHRilFhQSxEroy 8Byw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=M29McPR1cfUdmTsytJ/L6ARbkpRAatnfOcEkMtjkp9U=; b=oHutVB+aPE8Wi59KUgbJtF2TctEWW9ijOKezLvAJwHj37y2M9gboNOURGW65uvjY2H pofBHTUy6FmKKr9NfEk0u1KUGqRPadyfNPtQ4fCkWm7QGvoyvYY8f7qRhkUTnjexHEUv Q+4F2iJjgdT97Gt7j9LFYOjmhGSbiOZgoeaF2pdCA/uzFTkOwCK4tVrVjOwnjVxxOeoU D89cjbJigwyb103MasoVUI3UbvVQZiNfQL2WqTRTkmtBCU5m2X9bOe9+YY+Gb5khVEmy mqcPYHjEa83Q6Mjqo2CAfebrs9A2mGOQqiRy/PM2/rT9n9Yj52lDVGjHuzT/BcPiBAGD 9sbw== X-Gm-Message-State: AIVw113AqQvP93dsnEsrs2izVxXmcxgqP93trkeUQlnp3oskUc7Br6Zw exnPpkxud8bGcZmF7HN6sQhHYBcA3A== X-Received: by 10.55.144.130 with SMTP id s124mr55592086qkd.136.1499458931670; Fri, 07 Jul 2017 13:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.34.71 with HTTP; Fri, 7 Jul 2017 13:22:10 -0700 (PDT) Received: by 10.237.34.71 with HTTP; Fri, 7 Jul 2017 13:22:10 -0700 (PDT) In-Reply-To: References: From: Buhake Sindi Date: Fri, 7 Jul 2017 22:22:10 +0200 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0848acfa43da0553bffcf3" Archived-At: Subject: [OAUTH-WG] JWT: Unsecured JWS for JWS JASON Serialisation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:22:14 -0000 --94eb2c0848acfa43da0553bffcf3 Content-Type: text/plain; charset="UTF-8" Hi everyone, As I am busy implementing the JWT RFCs out there, I have noticed that there is no mention of how to handle unsecured JWS for JSON Serialisation. How would one treat Unsecured JWS in this case, also in the same case when content is detached? Thank you for your time, Kind Regards, Buhake Sindi www.sindi.co.za --94eb2c0848acfa43da0553bffcf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

As I am busy implementing the JWT RFCs out there, I have noticed that ther= e is no mention of how to handle unsecured JWS for JSON Serialisation.=C2= =A0

How would one treat = Unsecured JWS in this case, also in the same case when content is detached?=


Thank you for your time,


Kind Regards,

=

Buhake Sindi

--94eb2c0848acfa43da0553bffcf3-- From nobody Fri Jul 7 13:51:21 2017 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 CB625131530 for ; Fri, 7 Jul 2017 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 je6wAXwOPNMD for ; Fri, 7 Jul 2017 13:51:17 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 B40D11200FC for ; Fri, 7 Jul 2017 13:51:16 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id r103so62500412wrb.0 for ; Fri, 07 Jul 2017 13:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ywpSIK4hDqZBIw9bDje+Kj8WAE5Crjr9rf6tYwh3x3I=; b=iS1Roxx5LaUWyda6hSPLNY43UELCCn6qAPPbWykHX/6a1Qs0PxTXpjxSdZpOJUKp1U foRnuWkEo9s7mTh0mv4I16IyV3lFhmgO9nTxDLxVYJhq3kUmr0RVkraPUOdzO42aTPX5 Wa8vEXpJWiAVgT5tL1i3ez5fLlOm1bXOhqTzMskFrjYD8ZYwkkWKv52+wXg6FUVGRlfB XB7Z886Ds6aruMGjc/leGCgik6K8Usp7ekLvsCUiNbBN4N/Qkf9tzzahmUcnsR512N8O z6WfxZdC6UD3+TN1tTeUUxjAri4Z5Ry+rukAoiwKTgm790H3G5qtI+c7aYGPTBN56STK jf9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ywpSIK4hDqZBIw9bDje+Kj8WAE5Crjr9rf6tYwh3x3I=; b=rua4uiCUnISqA7wfN8ZMbAEsbZpjHuokvAProQ32PmV3eufmAO2jTBw9qRUQ6K64yD Ug8UcgskTVnvcELJe+uaRuh3l6m1gyjeRB5Zm6FGOZkPu8LnUfY/Zni9ggA3MLGEk0+3 WAv/y8k1tFavvdbEt7RAte1LqhFFUIC5ucMoo19H9iIjRT0ssUhBwKM8j5/pMR+fqYYU 9DJSF/t5x0AAX9IENbvDThcWbZ0tFnYPHT/vkr5dfinr5nmN48wAqH1NsY5E+lz24gt7 8yS9+zA0k0fdqnxQRv84l/3Z/6Th5iVY0kOcZaV3paF9NIGmpA2uxstKHToj3aAFBsq/ OcIQ== X-Gm-Message-State: AIVw113z1P5g1pLtXhY4kDLLdxP27kNrvqn1i0k9zrsdGwO/YkLgcHw3 dz6R1MyLL1jb1EsnELY= X-Received: by 10.80.163.102 with SMTP id 93mr3530665edn.78.1499460675061; Fri, 07 Jul 2017 13:51:15 -0700 (PDT) Received: from [192.168.2.5] ([46.7.210.148]) by smtp.googlemail.com with ESMTPSA id e54sm2308127eda.27.2017.07.07.13.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 13:51:14 -0700 (PDT) To: William Denniss Cc: "oauth@ietf.org" References: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> From: Sergey Beryozkin Message-ID: Date: Fri, 7 Jul 2017 21:50:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:51:19 -0000 Hi On 07/07/17 18:56, William Denniss wrote: > What you describe is incremental auth. > Thanks... FYI, I thought of doing some work around it after browsing through the Google docs; the line about the "asking to approve the purchase of the kitchen sink at the authentication time is a death of the modern web" (or something similar that I read on this list) was even more convincing :-) > Aside: Do you return the "scope" in the token response as required when > the scope in the response is not identical to the request (§ 5.1 > , parameter: scope)? > Yes, the token service is doing it by default for all the returned access tokens > My only question is: does the client expect this? The spec talks about > the authorization server *reducing* scope in a few places (in § 3.3 > , "The authorization > server MAY fully or partially ignore the scope requested by the client" > and § 10.3 "The > authorization server SHOULD take the client identity into account when > choosing how to honor the requested scope and MAY issue an access token > with less rights than requested."). It never talks about *increasing* > scope (other than it can't be done during refresh). > > So I think some normative language around the potential to increase the > scope of the request for confidential clients (in either the way you > describe, or the way I described in the draft) is warranted. > > Open question: should we require an indication from the client if they > *want* the scope increase? That's what include_granted_scopes was > designed to do. To allow clients to specify if this is behavior they desire. Right, I see how a proposed "include_granted_scopes" can make it non ambiguous > > > The more innovative part of the spec I think is the public (native app) > client incremental auth – as native apps cannot use the methods you > discuss, or the ones Google has supported for a while for confidential > clients. That said, if we write this – I think we may as well formally > document approaches for confidential clients too. > thanks, Sergey > > On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin > wrote: > > Hi > > Re the confidential client: let me explain please how we > experimented with this feature when the code flow is used. > > 1. Client requests a scope 'a' for a given User, it gets approved by > the user, the clients gets a code and exchanges it for a token. > > 2. At some later stage Client requests a scope 'b' for the same user > and if an access token for a given Client + User combination exists > and the incremental authorization is supported (we use a different > term for now) than the service finds out from this token that 'a' > has already been approved and offers a consent screen where a user > sees 'a' being selected and needs to approve 'b'. > > 3. User approves 'b'. The client gets a new code back and exchanges > it for a new token which now has "a" and "b". > > At this point a client has 2 tokens, one with the "a" scope and > another with the "a" and "b" scopes and the assumption was that the > client would itself remove the now redundant token with the scope > "a" only. > > I've just updated the code for the service itself do it on the > client's behalf, optionally remove the scope "a" token so that the > client can simply replace a reference to its scope "a" token with > the new one (scopes "a" and "b") it will get after exchanging a code > grant. > > Is it an incremental authorization or something else completely :-) ? > > One obvious difference, apart from the lower level implementation > details, is that it is not a client which requests to include the > already authorized scopes but the service does it itself if the > configuration allowing for it is enabled > > Thanks, Sergey > > > > > > > On 05/07/17 18:17, William Denniss wrote: > > Earlier this week I submitted the following I-D: > https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth > > The topic is incremental authentication (or incremental auth for > short). Incremental auth is used to enable clients to request > just the scopes they need when they need them – rather than all > upfront – while still only a maintaining a single authorization > grant. > > The I-D details two techniques used at Google, one that has been > used for a while in confidential clients, and one that we > launched recently as a new solution to deliver incremental auth > for public clients. > > I look forward to discussing this proposal with the working > group. I plan to present this draft at IETF99, hope you can be > there or watching the livestream! > > I plan to ask for a call for adoption after that presentation. > If you're interested in this topic I'd encourage you to read the > draft (it's fairly concise!). > > Best, > William > > > > _______________________________________________ > 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 Fri Jul 7 18:03:35 2017 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 15807131719 for ; Fri, 7 Jul 2017 18:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 3GQ6DHfeqD37 for ; Fri, 7 Jul 2017 18:03:31 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 239B412EC33 for ; Fri, 7 Jul 2017 18:03:31 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id v143so40240307qkb.0 for ; Fri, 07 Jul 2017 18:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NhrcuHgrHlxprvVwm+ixmGKVCAmPRYE9P9mA8fVYSIk=; b=AjsI5pKfDOBlL0KPhFgtZTJ7imH5tdhcrV/dhZFHryiejGP0TraPW/wIBK1KBVctGh W7PVPdw5ZxvhRP3CmDfQBYNjMjuCElrZTVFE9C1YXwKt2Dd3x8M/oTo0g2u+ZmVKKpkK /qKMIfQZXhFTxlgg5GCFWUKumwp2yzhNbdfPXMaLWsCOEPRN0rKzrXBtr/umCgT21pnm 00kaoS0hWXb5Ng+Y+0uOkSNe4C+mZmRIrWMQCcKhkr/5isA4oEOpaBW7hERBzzFb+E6f ztQGF41oDOk9JYdexaJDS11t7lJwVYvRuCjeh3NBurbxIzx0A7iI8Xzct05WmniSV+vY LTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NhrcuHgrHlxprvVwm+ixmGKVCAmPRYE9P9mA8fVYSIk=; b=bbIGc+zFZaPCLVSbb7XTKfWnejByyJknw58eedYQKBmCL83yu8Y3AEvflj9VUibb7h hqUEhr89gC3rOL6PstO5jHnpWQmcWnemzauGEQTG4iAXRlCe8y7jlVncpLD3cBcVRXT7 IE2swLUJdI+3DbSdw40wBuF6ZQ/svQbF81ah9TeuBIROTGegv8OPUUAh64IEoXOnWr5R w7KQJKz2T7kAKTS56/ulPG3Wlz3ilZAjoKvMbRQklbRJzmIMS6etoiPv5FAzgRPhH1ew bS3OZGl+b7ihUHiv5Ufkp/WmURFp19Nn3l/e0a/+7vU8fuz0QQ+EDOFkRb8GTqKaTX4i cP4A== X-Gm-Message-State: AKS2vOxSVlnyajkRshod6I+V28frn5LQCfd+DVxdzuHrLTptd5xQ81TQ f2mquuhTZcYj0iic6tINubntiMm6pytn2c/r8Q== X-Received: by 10.55.7.8 with SMTP id 8mr66065451qkh.124.1499475810115; Fri, 07 Jul 2017 18:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Fri, 7 Jul 2017 18:03:09 -0700 (PDT) In-Reply-To: References: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> From: William Denniss Date: Fri, 7 Jul 2017 18:03:09 -0700 Message-ID: To: Sergey Beryozkin Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a114c46f40370a50553c3eba1" Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 01:03:34 -0000 --001a114c46f40370a50553c3eba1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin wrote: > Hi > On 07/07/17 18:56, William Denniss wrote: > >> What you describe is incremental auth. >> >> Thanks... FYI, I thought of doing some work around it after browsing > through the Google docs; the line about the "asking to approve the purcha= se > of the kitchen sink at the authentication time is a death of the modern > web" (or something similar that I read on this list) was even more > convincing :-) > I hear ya :-) We ended up requiring that apps *don't* ask for the kitchen sink upfront in our API policies https://developers.google.com/terms/api-services-user-data-policy#request-r= elevant-permissions . Definitely makes for a bad user experience if users don't know why they are being asked to approve the request's scope. > > Aside: Do you return the "scope" in the token response as required when >> the scope in the response is not identical to the request (=C2=A7 5.1 < >> https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)? >> >> Yes, the token service is doing it by default for all the returned acces= s > tokens > > My only question is: does the client expect this? The spec talks about >> the authorization server *reducing* scope in a few places (in =C2=A7 3.3= < >> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization >> server MAY fully or partially ignore the scope requested by the client" = and >> =C2=A7 10.3 "The >> authorization server SHOULD take the client identity into account when >> choosing how to honor the requested scope and MAY issue an access token >> with less rights than requested."). It never talks about *increasing* >> scope (other than it can't be done during refresh). >> >> So I think some normative language around the potential to increase the >> scope of the request for confidential clients (in either the way you >> describe, or the way I described in the draft) is warranted. >> >> Open question: should we require an indication from the client if they >> *want* the scope increase? That's what include_granted_scopes was design= ed >> to do. To allow clients to specify if this is behavior they desire. >> > Right, I see how a proposed "include_granted_scopes" can make it non > ambiguous > >> >> >> The more innovative part of the spec I think is the public (native app) >> client incremental auth =E2=80=93 as native apps cannot use the methods = you >> discuss, or the ones Google has supported for a while for confidential >> clients. That said, if we write this =E2=80=93 I think we may as well fo= rmally >> document approaches for confidential clients too. >> >> > thanks, Sergey > >> >> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin > > wrote: >> >> Hi >> >> Re the confidential client: let me explain please how we >> experimented with this feature when the code flow is used. >> >> 1. Client requests a scope 'a' for a given User, it gets approved by >> the user, the clients gets a code and exchanges it for a token. >> >> 2. At some later stage Client requests a scope 'b' for the same user >> and if an access token for a given Client + User combination exists >> and the incremental authorization is supported (we use a different >> term for now) than the service finds out from this token that 'a' >> has already been approved and offers a consent screen where a user >> sees 'a' being selected and needs to approve 'b'. >> >> 3. User approves 'b'. The client gets a new code back and exchanges >> it for a new token which now has "a" and "b". >> >> At this point a client has 2 tokens, one with the "a" scope and >> another with the "a" and "b" scopes and the assumption was that the >> client would itself remove the now redundant token with the scope >> "a" only. >> >> I've just updated the code for the service itself do it on the >> client's behalf, optionally remove the scope "a" token so that the >> client can simply replace a reference to its scope "a" token with >> the new one (scopes "a" and "b") it will get after exchanging a code >> grant. >> >> Is it an incremental authorization or something else completely :-) = ? >> >> One obvious difference, apart from the lower level implementation >> details, is that it is not a client which requests to include the >> already authorized scopes but the service does it itself if the >> configuration allowing for it is enabled >> >> Thanks, Sergey >> >> >> >> >> >> >> On 05/07/17 18:17, William Denniss wrote: >> >> Earlier this week I submitted the following I-D: >> https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-aut= h >> >> >> The topic is incremental authentication (or incremental auth for >> short). Incremental auth is used to enable clients to request >> just the scopes they need when they need them =E2=80=93 rather t= han all >> upfront =E2=80=93 while still only a maintaining a single author= ization >> grant. >> >> The I-D details two techniques used at Google, one that has been >> used for a while in confidential clients, and one that we >> launched recently as a new solution to deliver incremental auth >> for public clients. >> >> I look forward to discussing this proposal with the working >> group. I plan to present this draft at IETF99, hope you can be >> there or watching the livestream! >> >> I plan to ask for a call for adoption after that presentation. >> If you're interested in this topic I'd encourage you to read the >> draft (it's fairly concise!). >> >> Best, >> William >> >> >> >> _______________________________________________ >> 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 >> >> >> >> --001a114c46f40370a50553c3eba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin <sberyozkin@gmail.com<= /a>> wrote:
= Hi
On 07/07/17 18:56, William Denniss wrote:
What you describe is incremental auth.

 Thanks... FYI, I thought of doing some work around it after browsing throug= h the Google docs; the line about the "asking to approve the purchase = of the kitchen sink at the authentication time is a death of the modern web= " (or something similar that I read on this list) was even more convin= cing :-)

I hear ya :-)
=C2=A0

Aside: Do you return the "scope" in the token response as require= d when the scope in the response is not identical to the request (=C2=A7 5.= 1 <https://tools.ietf.org/html/rfc6749#sectio= n-5.1>, parameter: scope)?

Yes, the token service is doing it by default for all the returned access t= okens

My only question is: does the client expect this?=C2=A0 The spec talks abou= t the authorization server *reducing* scope in a few places (in =C2=A7 3.3 = <https://tools.ietf.org/html/rfc6749#section-= 3.3>, "The authorization server MAY fully or partially ignore t= he scope requested by the client" and =C2=A7 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "= The authorization server SHOULD take the client identity into account when = choosing how to honor the requested scope and MAY issue an access token wit= h less rights than requested.").=C2=A0 It never talks about *increasin= g* scope (other than it can't be done during refresh).

So I think some normative language around the potential to increase the sco= pe of the request for confidential clients (in either the way you describe,= or the way I described in the draft) is warranted.

Open question: should we require an indication from the client if they *wan= t* the scope increase? That's what include_granted_scopes was designed = to do. To allow clients to specify if this is behavior they desire.
Right, I see how a proposed "include_granted_scopes" can make it = non ambiguous


The more innovative part of the spec I think is the public (native app) cli= ent incremental auth =E2=80=93 as native apps cannot use the methods you di= scuss, or the ones Google has supported for a while for confidential client= s. That said, if we write this =E2=80=93 I think we may as well formally do= cument approaches for confidential clients too.


 thanks, Sergey

On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com= >> wrote:

=C2=A0 =C2=A0 Hi

=C2=A0 =C2=A0 Re the confidential client: let me explain please how we
=C2=A0 =C2=A0 experimented with this feature when the code flow is used.
=C2=A0 =C2=A0 1. Client requests a scope 'a' for a given User, it g= ets approved by
=C2=A0 =C2=A0 the user, the clients gets a code and exchanges it for a toke= n.

=C2=A0 =C2=A0 2. At some later stage Client requests a scope 'b' fo= r the same user
=C2=A0 =C2=A0 and if an access token for a given Client + User combination = exists
=C2=A0 =C2=A0 and the incremental authorization is supported (we use a diff= erent
=C2=A0 =C2=A0 term for now) than the service finds out from this token that= 'a'
=C2=A0 =C2=A0 has already been approved and offers a consent screen where a= user
=C2=A0 =C2=A0 sees 'a' being selected and needs to approve 'b&#= 39;.

=C2=A0 =C2=A0 3. User approves 'b'. The client gets a new code back= and exchanges
=C2=A0 =C2=A0 it for a new token which now has "a" and "b&qu= ot;.

=C2=A0 =C2=A0 At this point a client has 2 tokens, one with the "a&quo= t; scope and
=C2=A0 =C2=A0 another with the "a" and "b" scopes and t= he assumption was that the
=C2=A0 =C2=A0 client would itself remove the now redundant token with the s= cope
=C2=A0 =C2=A0 "a" only.

=C2=A0 =C2=A0 I've just updated the code for the service itself do it o= n the
=C2=A0 =C2=A0 client's behalf, optionally remove the scope "a"= ; token so that the
=C2=A0 =C2=A0 client can simply replace a reference to its scope "a&qu= ot; token with
=C2=A0 =C2=A0 the new one (scopes "a" and "b") it will = get after exchanging a code
=C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 Is it an incremental authorization or something else complete= ly :-) ?

=C2=A0 =C2=A0 One obvious difference, apart from the lower level implementa= tion
=C2=A0 =C2=A0 details, is that it is not a client which requests to include= the
=C2=A0 =C2=A0 already authorized scopes but the service does it itself if t= he
=C2=A0 =C2=A0 configuration allowing for it is enabled

=C2=A0 =C2=A0 Thanks, Sergey






=C2=A0 =C2=A0 On 05/07/17 18:17, William Denniss wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Earlier this week I submitted the following I-D= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth &l= t;https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The topic is incremental authentication (or inc= remental auth for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 short).=C2=A0 Incremental auth is used to enabl= e clients to request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 just the scopes they need when they need them = =E2=80=93 rather than all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 upfront =E2=80=93 while still only a maintainin= g a single authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The I-D details two techniques used at Google, = one that has been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used for a while in confidential clients, and o= ne that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 launched recently as a new solution to deliver = incremental auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for public clients.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I look forward to discussing this proposal with= the working
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group. I plan to present this draft at IETF99, = hope you can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 there or watching the livestream!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I plan to ask for a call for adoption after tha= t presentation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you're interested in this topic I'd = encourage you to read the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft (it's fairly concise!).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 William



=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/oauth>


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 OAuth@iet= f.org <mailto:OA= uth@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/oauth
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/oauth>



--001a114c46f40370a50553c3eba1-- From nobody Mon Jul 10 09:15:59 2017 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 D25CB1317C4 for ; Mon, 10 Jul 2017 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-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 yhEBRW3cOBKp for ; Mon, 10 Jul 2017 09:15:55 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 99C481317D0 for ; Mon, 10 Jul 2017 09:15:54 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id a12so37787996ywh.3 for ; Mon, 10 Jul 2017 09:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=STwYlbBSAwF/zqJeP5f5GsK1NiwMxVXU3HdRmhMEKUA=; b=e6M2fOt5ZRxHNiBAFkCa50bz+U++uFFmItAXT8nrgnrfxgczawvX4crqp/gv5Q1spD zVdhX0Et9rsYx9x/xWN6dGNtSniLvRpKb1vsvHL2RDDa/11iq5su9eyXQNxdA2iAGKvR qLlY8kTtH/Id72LqDhlm+R1dieOw0tRPzfy+DWdYrhtegAZDJLfYoHC1Ko5nY1bBSGBv T7E5ap4zjXXYJv7ntB9n4FCRkI4nwkRRbIZ8f0xvmFCu4vpMqkeIBG16d8JQ/y3AmQ53 o8CW+Hj/Ocih0r+JZ4SlaK7QB4udz1knb/Arq1V1VmozwDBK7WxLTra1kae/+gy9mRrW bYeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=STwYlbBSAwF/zqJeP5f5GsK1NiwMxVXU3HdRmhMEKUA=; b=adIwZpE+379und2lvoL3ldJF8XOtbHsWnv+223hLcNxV6zN1wZgQzbkdfKUmT1v8Np tqdgn98jxpvVcxbfcax/eugu4ioNNoztWRtitNmc27Fz/Y2ysI4/CAf9HWkv5o8GjPwS EE7uAJ5D0mkMlMteWmRf1XicGJ57ggiMUxut/u3EHUQeKziOz0UGErknfiERcoDAR/Uv G7bz4zveuIK2SkfRhkyjVduK4+1dLgkDrfVp5IdPCuY2FWbJVpdv/q/EPg0fbWKQy1VG WIGsZTec/0MH1wzL1dyMZmEr/8IuyQl/q9qIwkBFluTQUSNgBKjjTbdDlXIx4toEgLmt Tx3g== X-Gm-Message-State: AIVw111u5H/1W5G764Bz7g7vKhvfaymBTiG/f3+7SqUw3O1LABtyIO6m ez4F4btv2MFWf46vW/uipiWSUPVkspU5J08= X-Received: by 10.129.40.149 with SMTP id o143mr1403675ywo.10.1499703353679; Mon, 10 Jul 2017 09:15:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.72.193 with HTTP; Mon, 10 Jul 2017 09:15:13 -0700 (PDT) In-Reply-To: References: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> From: Jim Willeke Date: Mon, 10 Jul 2017 12:15:13 -0400 Message-ID: To: William Denniss Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="001a1140865aaa7fd70553f8e5fe" Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 16:15:58 -0000 --001a1140865aaa7fd70553f8e5fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I know we add scopes based on the Authorization Server determining that the Resource Owner is also a "Paying Customer". (Well using OIDC so we KNOW they are a paying customer.) -- -jim Jim Willeke On Fri, Jul 7, 2017 at 9:03 PM, William Denniss wrote= : > > On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin > wrote: > >> Hi >> On 07/07/17 18:56, William Denniss wrote: >> >>> What you describe is incremental auth. >>> >>> Thanks... FYI, I thought of doing some work around it after browsing >> through the Google docs; the line about the "asking to approve the purch= ase >> of the kitchen sink at the authentication time is a death of the modern >> web" (or something similar that I read on this list) was even more >> convincing :-) >> > > I hear ya :-) > > We ended up requiring that apps *don't* ask for the kitchen sink upfront > in our API policies https://developers.google.com/ > terms/api-services-user-data-policy#request-relevant-permissions . > Definitely makes for a bad user experience if users don't know why they a= re > being asked to approve the request's scope. > > > >> >> Aside: Do you return the "scope" in the token response as required when >>> the scope in the response is not identical to the request (=C2=A7 5.1 < >>> https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)? >>> >>> Yes, the token service is doing it by default for all the returned >> access tokens >> >> My only question is: does the client expect this? The spec talks about >>> the authorization server *reducing* scope in a few places (in =C2=A7 3.= 3 < >>> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization >>> server MAY fully or partially ignore the scope requested by the client"= and >>> =C2=A7 10.3 "The >>> authorization server SHOULD take the client identity into account when >>> choosing how to honor the requested scope and MAY issue an access token >>> with less rights than requested."). It never talks about *increasing* >>> scope (other than it can't be done during refresh). >>> >>> So I think some normative language around the potential to increase the >>> scope of the request for confidential clients (in either the way you >>> describe, or the way I described in the draft) is warranted. >>> >>> Open question: should we require an indication from the client if they >>> *want* the scope increase? That's what include_granted_scopes was desig= ned >>> to do. To allow clients to specify if this is behavior they desire. >>> >> Right, I see how a proposed "include_granted_scopes" can make it non >> ambiguous >> >>> >>> >>> The more innovative part of the spec I think is the public (native app) >>> client incremental auth =E2=80=93 as native apps cannot use the methods= you >>> discuss, or the ones Google has supported for a while for confidential >>> clients. That said, if we write this =E2=80=93 I think we may as well f= ormally >>> document approaches for confidential clients too. >>> >>> >> thanks, Sergey >> >>> >>> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin >> > wrote: >>> >>> Hi >>> >>> Re the confidential client: let me explain please how we >>> experimented with this feature when the code flow is used. >>> >>> 1. Client requests a scope 'a' for a given User, it gets approved b= y >>> the user, the clients gets a code and exchanges it for a token. >>> >>> 2. At some later stage Client requests a scope 'b' for the same use= r >>> and if an access token for a given Client + User combination exists >>> and the incremental authorization is supported (we use a different >>> term for now) than the service finds out from this token that 'a' >>> has already been approved and offers a consent screen where a user >>> sees 'a' being selected and needs to approve 'b'. >>> >>> 3. User approves 'b'. The client gets a new code back and exchanges >>> it for a new token which now has "a" and "b". >>> >>> At this point a client has 2 tokens, one with the "a" scope and >>> another with the "a" and "b" scopes and the assumption was that the >>> client would itself remove the now redundant token with the scope >>> "a" only. >>> >>> I've just updated the code for the service itself do it on the >>> client's behalf, optionally remove the scope "a" token so that the >>> client can simply replace a reference to its scope "a" token with >>> the new one (scopes "a" and "b") it will get after exchanging a cod= e >>> grant. >>> >>> Is it an incremental authorization or something else completely :-)= ? >>> >>> One obvious difference, apart from the lower level implementation >>> details, is that it is not a client which requests to include the >>> already authorized scopes but the service does it itself if the >>> configuration allowing for it is enabled >>> >>> Thanks, Sergey >>> >>> >>> >>> >>> >>> >>> On 05/07/17 18:17, William Denniss wrote: >>> >>> Earlier this week I submitted the following I-D: >>> https://tools.ietf.org/html/draft-wdenniss-oauth-incremental >>> -auth >> > >>> >>> The topic is incremental authentication (or incremental auth fo= r >>> short). Incremental auth is used to enable clients to request >>> just the scopes they need when they need them =E2=80=93 rather = than all >>> upfront =E2=80=93 while still only a maintaining a single autho= rization >>> grant. >>> >>> The I-D details two techniques used at Google, one that has bee= n >>> used for a while in confidential clients, and one that we >>> launched recently as a new solution to deliver incremental auth >>> for public clients. >>> >>> I look forward to discussing this proposal with the working >>> group. I plan to present this draft at IETF99, hope you can be >>> there or watching the livestream! >>> >>> I plan to ask for a call for adoption after that presentation. >>> If you're interested in this topic I'd encourage you to read th= e >>> draft (it's fairly concise!). >>> >>> Best, >>> William >>> >>> >>> >>> _______________________________________________ >>> 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 > > --001a1140865aaa7fd70553f8e5fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know we add scopes based on the Authorization Server det= ermining that the Resource Owner is also a "Paying Customer". (We= ll using OIDC so we KNOW they are a paying customer.)

--
-jim<= br>Jim Willeke

On Fri, Jul 7, 2017 at 9:03 PM, William Denn= iss <wdenniss@google.com> wrote:

On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin = <sberyozkin@gmail.com> wrote:
Hi On 07/07/17 18:56, William Denniss wrote:
What you describe is incremental auth.

 Thanks... FYI, I thought of doing some work around it after browsing throug= h the Google docs; the line about the "asking to approve the purchase = of the kitchen sink at the authentication time is a death of the modern web= " (or something similar that I read on this list) was even more convin= cing :-)

I hear ya :-)

We ended up requiring that apps *don't* ask for the kit= chen sink upfront in our API policies https://developers.google.com/terms/api-services-user-dat= a-policy#request-relevant-permissions . Definitely makes for = a bad user experience if users don't know why they are being asked to a= pprove the request's scope.

=
=C2=A0

Aside: Do you return the "scope" in the token response as require= d when the scope in the response is not identical to the request (=C2=A7 5.= 1 <https://tools.ietf.org/html/rfc6749#sectio= n-5.1>, parameter: scope)?

Yes, the token service is doing it by default for all the returned access t= okens

My only question is: does the client expect this?=C2=A0 The spec talks abou= t the authorization server *reducing* scope in a few places (in =C2=A7 3.3 = <https://tools.ietf.org/html/rfc6749#section-= 3.3>, "The authorization server MAY fully or partially ignore t= he scope requested by the client" and =C2=A7 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "= The authorization server SHOULD take the client identity into account when = choosing how to honor the requested scope and MAY issue an access token wit= h less rights than requested.").=C2=A0 It never talks about *increasin= g* scope (other than it can't be done during refresh).

So I think some normative language around the potential to increase the sco= pe of the request for confidential clients (in either the way you describe,= or the way I described in the draft) is warranted.

Open question: should we require an indication from the client if they *wan= t* the scope increase? That's what include_granted_scopes was designed = to do. To allow clients to specify if this is behavior they desire.
Right, I see how a proposed "include_granted_scopes" can make it = non ambiguous


The more innovative part of the spec I think is the public (native app) cli= ent incremental auth =E2=80=93 as native apps cannot use the methods you di= scuss, or the ones Google has supported for a while for confidential client= s. That said, if we write this =E2=80=93 I think we may as well formally do= cument approaches for confidential clients too.


 thanks, Sergey

On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com= >> wrote:

=C2=A0 =C2=A0 Hi

=C2=A0 =C2=A0 Re the confidential client: let me explain please how we
=C2=A0 =C2=A0 experimented with this feature when the code flow is used.
=C2=A0 =C2=A0 1. Client requests a scope 'a' for a given User, it g= ets approved by
=C2=A0 =C2=A0 the user, the clients gets a code and exchanges it for a toke= n.

=C2=A0 =C2=A0 2. At some later stage Client requests a scope 'b' fo= r the same user
=C2=A0 =C2=A0 and if an access token for a given Client + User combination = exists
=C2=A0 =C2=A0 and the incremental authorization is supported (we use a diff= erent
=C2=A0 =C2=A0 term for now) than the service finds out from this token that= 'a'
=C2=A0 =C2=A0 has already been approved and offers a consent screen where a= user
=C2=A0 =C2=A0 sees 'a' being selected and needs to approve 'b&#= 39;.

=C2=A0 =C2=A0 3. User approves 'b'. The client gets a new code back= and exchanges
=C2=A0 =C2=A0 it for a new token which now has "a" and "b&qu= ot;.

=C2=A0 =C2=A0 At this point a client has 2 tokens, one with the "a&quo= t; scope and
=C2=A0 =C2=A0 another with the "a" and "b" scopes and t= he assumption was that the
=C2=A0 =C2=A0 client would itself remove the now redundant token with the s= cope
=C2=A0 =C2=A0 "a" only.

=C2=A0 =C2=A0 I've just updated the code for the service itself do it o= n the
=C2=A0 =C2=A0 client's behalf, optionally remove the scope "a"= ; token so that the
=C2=A0 =C2=A0 client can simply replace a reference to its scope "a&qu= ot; token with
=C2=A0 =C2=A0 the new one (scopes "a" and "b") it will = get after exchanging a code
=C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 Is it an incremental authorization or something else complete= ly :-) ?

=C2=A0 =C2=A0 One obvious difference, apart from the lower level implementa= tion
=C2=A0 =C2=A0 details, is that it is not a client which requests to include= the
=C2=A0 =C2=A0 already authorized scopes but the service does it itself if t= he
=C2=A0 =C2=A0 configuration allowing for it is enabled

=C2=A0 =C2=A0 Thanks, Sergey






=C2=A0 =C2=A0 On 05/07/17 18:17, William Denniss wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Earlier this week I submitted the following I-D= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth &l= t;https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The topic is incremental authentication (or inc= remental auth for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 short).=C2=A0 Incremental auth is used to enabl= e clients to request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 just the scopes they need when they need them = =E2=80=93 rather than all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 upfront =E2=80=93 while still only a maintainin= g a single authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The I-D details two techniques used at Google, = one that has been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used for a while in confidential clients, and o= ne that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 launched recently as a new solution to deliver = incremental auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for public clients.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I look forward to discussing this proposal with= the working
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group. I plan to present this draft at IETF99, = hope you can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 there or watching the livestream!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I plan to ask for a call for adoption after tha= t presentation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you're interested in this topic I'd = encourage you to read the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft (it's fairly concise!).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 William



=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/oauth>


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 OAuth@iet= f.org <mailto:OA= uth@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/oauth
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/oauth>




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


--001a1140865aaa7fd70553f8e5fe-- From nobody Tue Jul 11 02:49:23 2017 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 C834912EB99 for ; Tue, 11 Jul 2017 02:49:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 7X5bixpyDBGb for ; Tue, 11 Jul 2017 02:49:19 -0700 (PDT) Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBEA1242F7 for ; Tue, 11 Jul 2017 02:49:18 -0700 (PDT) From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow Thread-Index: AQHS+ir1wad97hzRckuaQgYQihFwBQ== Date: Tue, 11 Jul 2017 09:49:15 +0000 Message-ID: <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.17.5.138] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 09:49:22 -0000 SGkgSnVzdGluLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNCkkgaGFkIG1pc3NlZCB5b3Vy IHByb3Bvc2FsLCBidXQgaXTigJlzIGluZGVlZCB0aGUgc2FtZSBsaW5lLW9mLXRob3VnaHQuDQpN eSBwcm9wb3NhbCBpcyBzbGlnaHRseSBkaWZmZXJlbnQgaW4gdGhlIHNlbnNlIHRoYXQgdGhlIGRl dmljZV9uYW1lIChvcjogaW5zdGFuY2VfbmFtZSkgd291bGQgbm90IG9yaWdpbmF0ZSBmcm9tIHRo ZSBjbGllbnQgaXRzZWxmIGJ1dCBmcm9tIHRoZSBSZXNvdXJjZU93bmVyLCBlLmcuIGR1cmluZyB0 aGUgYXV0aG9yaXNhdGlvbiBwcm9jZXNzLg0KVGhpcyBpcyBwcm9iYWJseSBzcGVjaWZpYyBvciBh dCBsZWFzdCBtb3JlIHJlbGV2YW50IHRvIGRldmljZXMgd2l0aCBpbnB1dCBjb25zdHJhaW50cy4N Cg0KSSB1bmRlcnN0YW5kIHRoZSBwb2ludCBhYm91dCBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRp b24uIA0KQXQgYSBmaXJzdCBnbGFuY2UgaXQgc2VlbXMgdmVyeSDigJhvcGVu4oCZLCB3aGVyZWFz IGluIGEgbG90IG9mIGNhc2UgeW91IHdvdWxkbuKAmXQgd2FudCBhbnkgY2xpZW50IHRvIHJlZ2lz dGVyLiANCk1vcmVvdmVyLCBJIGZlZWwgdGhhdCB1c2luZyBkeW5hbWljIGNsaWVudCByZWdpc3Ry YXRpb24ganVzdCBmb3IgdGhlIHNha2Ugb2Ygc2V0dGluZyB1cCBpZGVudGlmaWVycyBmb3IgYSBj bGllbnQgaW5zdGFuY2Ugc2VlbXMgYSBiaXQg4oCYaGVhdnnigJkuDQpTbyBJIHN0aWxsIGZlZWwg aXTigJlzIHVzZWZ1bGwgdG8gZW5oYW5jZSB0aGUgRGV2aWNlIGZsb3cgd2l0aCBzb21ldGhpbmcg bGlrZTogZGV2aWNlX2lkZW50aWZpZXIgLyBkZXZpY2VfbmFtZSAvIGluc3RhbmNlX25hbWUgLyBp bnN0YW5jZV9kZXNjcmlwdGlvbg0KDQpyZWdhcmRzLCBKYWFwDQoNCg0KPiBNZXNzYWdlOiAyDQo+ IERhdGU6IEZyaSwgNyBKdWwgMjAxNyAwNzo1NDoxMyAtMDQwMA0KPiBGcm9tOiBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdC5lZHU+DQo+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBTdWdnZXN0ZWQgZW5oYW5jZW1lbnQgb2YgdGhlIE9BdXRoIERldmljZSBG bG93DQo+IE1lc3NhZ2UtSUQ6IDw3MWU0M2UzYy0yYmQzLWQ3MDYtMmM4Mi02MDIwZGU4ZmY4ODFA bWl0LmVkdT4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04OyBmb3Jt YXQ9Zmxvd2VkDQo+IA0KPiBJIHByb3Bvc2VkIHRoaXMgZXhhY3QgdGhpbmcgbWFueSB5ZWFycyBh Z286DQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLW9hdXRo LWluc3RhbmNlLTAwDQo+IA0KPiBBdCB0aGUgdGltZSB0aGVyZSB3YXNuJ3QgdmVyeSBtdWNoIGlu dGVyZXN0IGluIGl0LCBhcyBwZW9wbGUgd2VyZSANCj4gbG9va2luZyBhdCB1c2luZyBEeW5hbWlj IFJlZ2lzdHJhdGlvbiwgd2l0aCBpdHMgYXR0ZW5kYW50IHVuaXF1ZSBjbGllbnQgDQo+IElEcywg dG8gc29sdmUgdGhhdCBzYW1lIHByb2JsZW0uDQo+IA0KPiAgLS0gSnVzdGluDQoNCg== From nobody Wed Jul 12 09:24:58 2017 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 0D78012871F for ; Wed, 12 Jul 2017 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 Jt7wbWoM5gt5 for ; Wed, 12 Jul 2017 09:24:54 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.101]) (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 C8FDF126DD9 for ; Wed, 12 Jul 2017 09:24:53 -0700 (PDT) Received: from [31.221.87.81] (helo=[10.208.129.85]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dVKRW-0008Sn-SF; Wed, 12 Jul 2017 18:24:51 +0200 From: Torsten Lodderstedt Message-Id: <85C89F7B-9D03-4C21-ACAB-8F36B79FE576@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_3AECF50F-DB99-42B1-AC43-BBD058DFA513"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 17:24:50 +0100 In-Reply-To: Cc: oauth , John Bradley , Brian Campbell To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3273) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Agenda requests for Prague X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 16:24:57 -0000 --Apple-Mail=_3AECF50F-DB99-42B1-AC43-BBD058DFA513 Content-Type: multipart/alternative; boundary="Apple-Mail=_920DFC8F-F171-458A-A74A-FCC9BD785E88" --Apple-Mail=_920DFC8F-F171-458A-A74A-FCC9BD785E88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I would like to give an update on our work on = draft-ietf-oauth-security-topics (mainly access token leakage at the = RS). 10 min should be suffice. Please note: I won=E2=80=99t be able to present on Friday. Please = consider to assign me/us a slot in the Tuesday session. Thanks, Torsten. Am 29.06.2017 um 23:00 schrieb Brian Campbell = : >=20 > I'd like to please make agenda requests for the following documents = (unless, of course, any of the co-authors want to take the slot instead = of me):=20 >=20 > draft-ietf-oauth-mtls = (~15 mins?) > draft-ietf-oauth-token-exchange = (~10 = mins?) > draft-ietf-oauth-token-binding = (~10 = mins?) >=20 > Thanks, > Brian >=20 > On Mon, Jun 26, 2017 at 6:16 AM, Rifaat Shekh-Yusef = > wrote: > All, >=20 > If you have not done so already, please send us your agenda requests = for the coming meeting in Prague. >=20 > Regards, > Rifaat & Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > =09 > Brian Campbell=09 > Distinguished Engineer=09 > bcampbell@pingidentity.com =09 > w: +1 720.317.2061=09 > c: +1 303.918.9415 > Connect with us: = = = = = = = =09= >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_920DFC8F-F171-458A-A74A-FCC9BD785E88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = would like to give an update on our work on = draft-ietf-oauth-security-topics (mainly access token leakage at the = RS). 10 min should be suffice.

Please note: I won=E2=80=99t be able to = present on Friday. Please consider to assign me/us a slot in the Tuesday = session.

Thanks,
Torsten.


Am = 29.06.2017 um 23:00 schrieb Brian Campbell <bcampbell@pingidentity.com>:

I'd= like to please make agenda requests for the following documents = (unless, of course, any of the co-authors want to take the slot instead = of me):

=20 =20 =20 =20 draft-ietf-oauth-mtls (~15 mins?)
=20 =20 =20 =20 draft-ietf-oauth-token-exchange (~10 mins?)
=20 =20 =20 =20 draft-ietf-oauth-token-binding (~10 = mins?)

Thanks,
Brian

On Mon, Jun 26, 2017 at 6:16 AM, = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

If = you have not done so already, please send us your agenda requests for = the coming meeting in Prague.

Regards,
 Rifaat & Hannes

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




--
= = = = =
= 3D"Ping = = = =
= Brian Campbell =
= Distinguished Engineer =
= bcampbell@pingidentity.com =
= = w: +1 720.317.2061 =
= = c: +1 303.918.9415 =
=
=
Connect with us: 3D"Glassdoor = 3D"LinkedIn 3D"twitter = 3D"facebook = 3D"youtube = 3D"Google+ = 3D"Blog =

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_920DFC8F-F171-458A-A74A-FCC9BD785E88-- --Apple-Mail=_3AECF50F-DB99-42B1-AC43-BBD058DFA513 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAx MDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye 12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFb zz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY 17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSR SR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwID AQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPng HgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZ MBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9D UFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMw gYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v Y3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkq hkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9 CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13Ob fpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/Tc TXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmy e3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGw MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0y NTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3Px A3uZ8LQwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcwNzEyMTYyNDUwWjAjBgkqhkiG9w0BCQQxFgQUkifiKaG4KzmuSf+vBBxNKfavtqcw gcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/ BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqG SIb3DQEBAQUABIIBAJC2y669hHbQqBVEEAzFp2ZOH4ajklNjVcO73YVC5Tojgza+0Y/hm2uCL7+O KVFt6jYCjy0oIzZl/3EoMQYu9u2z0ULf+0Vh5FRxPoYslNO1Tc6lkn117NXuhm7nQ1Bh2ZemITO+ mSVvn/VlyKWJyIVt8CqLddro1DGd6unK06LdjTf4Fu07K/m/jggPA3hhIlePKh6SaPbjJ5Y/k9ce TqahY9yelWxTnLIdlcKLX0L4ujqZMgVP9/TH1AHZlwwmJNq+kM4nucTSKH7N28yi6SUPSAEjkW7U CZhTyIo95R+LwtQa3aiIyfJfjhHWd54eeTdsOJKkmaridYwpt/6CwrgAAAAAAAA= --Apple-Mail=_3AECF50F-DB99-42B1-AC43-BBD058DFA513-- From nobody Wed Jul 12 10:45:55 2017 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 AF4C613173A for ; Wed, 12 Jul 2017 10:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ovhJp2_pV92M for ; Wed, 12 Jul 2017 10:45:52 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 4A931131549 for ; Wed, 12 Jul 2017 10:45:52 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id z22so19106009uah.1 for ; Wed, 12 Jul 2017 10:45:52 -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=Qy7hoSo/kiJnH38n9L+hOl79WuROFmByT9Tf+PdbO1Y=; b=sBFZeQzmTTypLrhL7u2Oow/1dbtl49YCxASteNMd8botfvRVDecGwc2r/yydTkpM0D hT12YjgakrXmIUs4hjt+LGDiTgOYM6rzCHGcgv5Zhif14GJVxcYjiKwHePVmoiylRvKw pyRz9VtrB62syFeeGd99sCZXCutMpqGF9qgYxOAjH/XXLSfGiL+yLHKtZmGYQykcN0vh kFZFWsyCNys+Nz5b8qCjx/OAuftAkS8o42tvBpUkHYUAehyoDBjCFpPlDlDt1hoGBnfN p7AdUp6I8W00hcRyciD3U70qrc4hr3wzWRSN+waeH/1ZZteooYarApIcbWfMNeZCZv19 UWdg== 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=Qy7hoSo/kiJnH38n9L+hOl79WuROFmByT9Tf+PdbO1Y=; b=YFQPUovAs6/BeL/2fvKnN0RgBYrXrqXoUuBkZLjL3QRG/A6gVxkS6rQiwAnUH5Tm8o fCIRMfOMKb0Jt9Oz4UasPHgq1xZZjrdfjv9QFzqzXtfTEgGGPa3uj53OqocCJ2Mw3Emz vnSCxTYobpDUSchCYKgtcNcMdnhSsaCYZNFqveC7lhxLx/7sILerakhowYtCJiZmhyb1 /FA5QItFLPDBf/gLTcSZvDCiR41lN9UYrl9aGOhpNhx61MQZxZQdLJAEVGLbGnEsBVoj Ez/wi7Jqawfp2SK79AEbD5KGgDawbdMUomVRyuUk03UG3WLhujFGX0mWpbWemTKZtopo 8pvg== X-Gm-Message-State: AIVw113TrLTgPi0WWxhWI1CFiybNOfM9zH0YZSlzlpiuqbdJih4XGfR1 Z+eL70S2ei0Q4lVzDFxyQ7MgPD0+034X X-Received: by 10.176.77.223 with SMTP id b31mr4037667uah.76.1499881551306; Wed, 12 Jul 2017 10:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Wed, 12 Jul 2017 10:45:50 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Wed, 12 Jul 2017 13:45:50 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="f403043c467c122a5305542263cf" Archived-At: Subject: [OAUTH-WG] Agenda for IETF99 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 17:45:54 -0000 --f403043c467c122a5305542263cf Content-Type: text/plain; charset="UTF-8" All, We have just uploaded the agenda for the two OAuth sessions next week: https://www.ietf.org/proceedings/99/agenda/agenda-99-oauth-01 Please, take a look and let us know if you have any comments or if we missed anything. Regards, Rifaat & Hannes. P.S., I unfortunately will not be a Prague. Hannes will again run the show by himself. Hope you have a productive meetings. --f403043c467c122a5305542263cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have just uploaded t= he agenda for the two OAuth sessions next week:

Please, take a look and let us know if you ha= ve any comments or if we missed anything.


Regards,
=C2=A0Rifaat & Hannes.


P.S., I unfortunately will not be a Prague. Hannes will a= gain run the show by himself. Hope you have a productive meetings.
--f403043c467c122a5305542263cf-- From nobody Thu Jul 13 05:21:43 2017 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 DF437129B5E for ; Thu, 13 Jul 2017 05:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 yd55RrWD7iFi for ; Thu, 13 Jul 2017 05:21:40 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 0B10C127977 for ; Thu, 13 Jul 2017 05:21:40 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id g13so13664929uaj.0 for ; Thu, 13 Jul 2017 05:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gM0GtVVPIWQPefnu3RfYsv+xTavFCwFRCSpK3MCOwIE=; b=KPe8CvP9XLpF9QNOzqm8mQOhw697MyrO1GXf499edCdotlfFKyGcz69mKffqZBaBEV 5PwqX/Q68QDKhfxgYxe/dvnbGR/SLdQFFh/jShIhF7ezxLXY1OQI2N9Ok8Spb4IdbLuN EN93kXObURqRimrTR9abRZu75+9CQmkNbt0SxKym4njIBQJ487LZ4uDTHL6icMqu3+i6 5MRCNWy7aTwf0TlGEj86SNozHB6ldtI0+gnq1phkNTQxzVj3Ni33P8tzLdIAZrnosi/H l1Vr0JeGyc7lYG834T9E2LIF6gOO185FVCvtZIcTA+nJKMXZybhbpKYrU8rlmIpmqRQt G4Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gM0GtVVPIWQPefnu3RfYsv+xTavFCwFRCSpK3MCOwIE=; b=rOoMCfiF+mnE+DSCYXm+V03tdQ+9rK0gq8JpXjrNGI0JhJtMwX2B4APDJBgGKHI1VJ 9MA2gMWSUeHMZ0qwtymoNDQlb+WyCwwLhRUeDYvkWKpPHbZOzQt5DnjM8huj2Xpk27oT Lt7XzZlpkUyGvPRyMzcSmymwcPpm136Kzorbshz75eCUL2gXPIHgianSp+AtwLCIqpFu XNe3kLxYtJpESRTmirLHIoNMf5JiO5Vg+RZZUh5m0tKOYXiDAqOpDbb7BJwYa/YYpJ66 ctP6LPABnPkbuJnyrFxdJovv+GZvqtyDQKN8yoGi3f1zP62ZjAuBqcpraGZniaT1wtE1 aoaA== X-Gm-Message-State: AIVw11342x9tvJm0+Brk5rssUDjjcEx57AJAoUpeoAuMSQQjBm5hGJBj eEUyFUBtmNs26waSayJyp/ApLPbpvPVNZrU= X-Received: by 10.176.84.3 with SMTP id n3mr2218313uaa.49.1499948499122; Thu, 13 Jul 2017 05:21:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Thu, 13 Jul 2017 05:21:38 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Thu, 13 Jul 2017 08:21:38 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c1b0e2c78bfc9055431f965" Archived-At: Subject: Re: [OAUTH-WG] Agenda for IETF99 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 12:21:42 -0000 --94eb2c1b0e2c78bfc9055431f965 Content-Type: text/plain; charset="UTF-8" All, We needed to do some changes to the agenda. Here is the latest version: https://www.ietf.org/proceedings/99/agenda/agenda-99-oauth-02 Please, take a look and let us know if you have any further comments or if we missed anything. Regards, Rifaat & Hannes On Wed, Jul 12, 2017 at 1:45 PM, Rifaat Shekh-Yusef wrote: > All, > > We have just uploaded the agenda for the two OAuth sessions next week: > https://www.ietf.org/proceedings/99/agenda/agenda-99-oauth-01 > > Please, take a look and let us know if you have any comments or if we > missed anything. > > > Regards, > Rifaat & Hannes. > > > P.S., I unfortunately will not be a Prague. Hannes will again run the show > by himself. Hope you have a productive meetings. > --94eb2c1b0e2c78bfc9055431f965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We needed to do some changes to th= e agenda. Here is the latest version:

Please, = take a look and let us know if you have any further comments or if we misse= d anything.

Regards,
=C2=A0Rifaat & = Hannes


On Wed, Jul 12, 2017 at 1:45 PM, Rifaat Shekh-Yusef <= rifaat.ietf@gmail.com> wrote:

--94eb2c1b0e2c78bfc9055431f965-- From nobody Thu Jul 13 11:08:28 2017 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 A0FD4129B10 for ; Thu, 13 Jul 2017 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 oRRY21gLWgoW for ; Thu, 13 Jul 2017 11:08:22 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 DF7D4129AD7 for ; Thu, 13 Jul 2017 11:08:21 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v17so51420765qka.3 for ; Thu, 13 Jul 2017 11:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mlLMokB6/ndZwrcpiBjoNvViF5feElhBFfA96dYqBUw=; b=F4r+kk8HZ9Sm3hEgISlqGx0lkHqL98o/1sQzOxFimGIwV82cx/J/MBn9jx1OaJRopP ZrxMVghgbbKy3/84aPGZQae3yPkotISrTRd6MXokNoC4EEfze2RJX7kXQsR4tGh/oLdg NaY93v4UEHFQoJIvD6CQmjV/OmfRn9mlgp5i7fH7YwEf+ukvl7JWDPvJsvFcmCi8looy yeXizdrQ9u9+NLgTJaKTquiMUd6d6AZwQ+47mG/EuH7kdOuR3ZYicXvl/xnAE05KGly7 uoPa8nPniG23AR+T/D/A7JZX15jEoKsRfSP5eQI6xOxanIbYO7IL9CbjxJXhoO3d3MVr pqhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mlLMokB6/ndZwrcpiBjoNvViF5feElhBFfA96dYqBUw=; b=FNk1kVb3L1864J8MdrUtFq+UDqu9gRdrcdpHJoJiOdAMxOISpCKhn9qJamCGGO1FBY lzEc58W/kOvE/y4HRF/5Ok0fODrhrdKuXL7WQBYR3DLxrUwmqnGLuxaf/jfhk4fBZGaw gs/UP5TVqU9Lr/IvyL2VV3bplikBaezUdqE/VLY85r+873b2j0uPoTo2+cd+GMf7WRZv CAyMbVdETg07kfEQvQPf6sMg0ULC7K1Da31jCWqLPNjPcdzTLRY7pPfv1I0Xv01Wdkl1 cuy1R1gtql71jDQtmotiY2/27uOWQVlh/0aW7IqGyN2mZk/hrBm2nxLzaBofvqFJ5Jbr HKQg== X-Gm-Message-State: AIVw113Q+8hpwQ7sE0BxKP82vueS/IGFJrQBi6zM/c66OwySqWJ8X1wy VCc/vHeGM/6Aau/pxPepp5C5ixOtsyTLU2Y= X-Received: by 10.233.239.1 with SMTP id d1mr6064434qkg.126.1499969300656; Thu, 13 Jul 2017 11:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.147 with HTTP; Thu, 13 Jul 2017 11:08:00 -0700 (PDT) In-Reply-To: References: <59d3c1f5-01de-e419-4c4c-3115ed35e451@gmail.com> From: William Denniss Date: Thu, 13 Jul 2017 11:08:00 -0700 Message-ID: To: Jim Willeke Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1101b257ab77055436d1ac" Archived-At: Subject: Re: [OAUTH-WG] New OAuth I-D: Incremental Auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 18:08:25 -0000 --94eb2c1101b257ab77055436d1ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks everyone for your reviews and feedback so far! I'm bumping this thread one last time before IETF99. Would be great if enough people have some knowledge of the draft to put it to an adoption call :-) Once again, doc is here and it's a fairly light read! https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth I look forward to presenting it to you all in Prague. On Mon, Jul 10, 2017 at 9:15 AM, Jim Willeke wrote: > I know we add scopes based on the Authorization Server determining that > the Resource Owner is also a "Paying Customer". (Well using OIDC so we KN= OW > they are a paying customer.) > > -- > -jim > Jim Willeke > > On Fri, Jul 7, 2017 at 9:03 PM, William Denniss > wrote: > >> >> On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin >> wrote: >> >>> Hi >>> On 07/07/17 18:56, William Denniss wrote: >>> >>>> What you describe is incremental auth. >>>> >>>> Thanks... FYI, I thought of doing some work around it after browsing >>> through the Google docs; the line about the "asking to approve the purc= hase >>> of the kitchen sink at the authentication time is a death of the modern >>> web" (or something similar that I read on this list) was even more >>> convincing :-) >>> >> >> I hear ya :-) >> >> We ended up requiring that apps *don't* ask for the kitchen sink upfront >> in our API policies https://developers.google.com/ >> terms/api-services-user-data-policy#request-relevant-permissions . >> Definitely makes for a bad user experience if users don't know why they = are >> being asked to approve the request's scope. >> >> >> >>> >>> Aside: Do you return the "scope" in the token response as required when >>>> the scope in the response is not identical to the request (=C2=A7 5.1 = < >>>> https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)? >>>> >>>> Yes, the token service is doing it by default for all the returned >>> access tokens >>> >>> My only question is: does the client expect this? The spec talks about >>>> the authorization server *reducing* scope in a few places (in =C2=A7 3= .3 < >>>> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization >>>> server MAY fully or partially ignore the scope requested by the client= " and >>>> =C2=A7 10.3 "The >>>> authorization server SHOULD take the client identity into account when >>>> choosing how to honor the requested scope and MAY issue an access toke= n >>>> with less rights than requested."). It never talks about *increasing* >>>> scope (other than it can't be done during refresh). >>>> >>>> So I think some normative language around the potential to increase th= e >>>> scope of the request for confidential clients (in either the way you >>>> describe, or the way I described in the draft) is warranted. >>>> >>>> Open question: should we require an indication from the client if they >>>> *want* the scope increase? That's what include_granted_scopes was desi= gned >>>> to do. To allow clients to specify if this is behavior they desire. >>>> >>> Right, I see how a proposed "include_granted_scopes" can make it non >>> ambiguous >>> >>>> >>>> >>>> The more innovative part of the spec I think is the public (native app= ) >>>> client incremental auth =E2=80=93 as native apps cannot use the method= s you >>>> discuss, or the ones Google has supported for a while for confidential >>>> clients. That said, if we write this =E2=80=93 I think we may as well = formally >>>> document approaches for confidential clients too. >>>> >>>> >>> thanks, Sergey >>> >>>> >>>> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin >>> > wrote: >>>> >>>> Hi >>>> >>>> Re the confidential client: let me explain please how we >>>> experimented with this feature when the code flow is used. >>>> >>>> 1. Client requests a scope 'a' for a given User, it gets approved = by >>>> the user, the clients gets a code and exchanges it for a token. >>>> >>>> 2. At some later stage Client requests a scope 'b' for the same us= er >>>> and if an access token for a given Client + User combination exist= s >>>> and the incremental authorization is supported (we use a different >>>> term for now) than the service finds out from this token that 'a' >>>> has already been approved and offers a consent screen where a user >>>> sees 'a' being selected and needs to approve 'b'. >>>> >>>> 3. User approves 'b'. The client gets a new code back and exchange= s >>>> it for a new token which now has "a" and "b". >>>> >>>> At this point a client has 2 tokens, one with the "a" scope and >>>> another with the "a" and "b" scopes and the assumption was that th= e >>>> client would itself remove the now redundant token with the scope >>>> "a" only. >>>> >>>> I've just updated the code for the service itself do it on the >>>> client's behalf, optionally remove the scope "a" token so that the >>>> client can simply replace a reference to its scope "a" token with >>>> the new one (scopes "a" and "b") it will get after exchanging a co= de >>>> grant. >>>> >>>> Is it an incremental authorization or something else completely :-= ) >>>> ? >>>> >>>> One obvious difference, apart from the lower level implementation >>>> details, is that it is not a client which requests to include the >>>> already authorized scopes but the service does it itself if the >>>> configuration allowing for it is enabled >>>> >>>> Thanks, Sergey >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 05/07/17 18:17, William Denniss wrote: >>>> >>>> Earlier this week I submitted the following I-D: >>>> https://tools.ietf.org/html/draft-wdenniss-oauth-incremental >>>> -auth >>> l-auth> >>>> >>>> The topic is incremental authentication (or incremental auth f= or >>>> short). Incremental auth is used to enable clients to request >>>> just the scopes they need when they need them =E2=80=93 rather= than all >>>> upfront =E2=80=93 while still only a maintaining a single auth= orization >>>> grant. >>>> >>>> The I-D details two techniques used at Google, one that has be= en >>>> used for a while in confidential clients, and one that we >>>> launched recently as a new solution to deliver incremental aut= h >>>> for public clients. >>>> >>>> I look forward to discussing this proposal with the working >>>> group. I plan to present this draft at IETF99, hope you can be >>>> there or watching the livestream! >>>> >>>> I plan to ask for a call for adoption after that presentation. >>>> If you're interested in this topic I'd encourage you to read t= he >>>> draft (it's fairly concise!). >>>> >>>> Best, >>>> William >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --94eb2c1101b257ab77055436d1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= br>
On Mon, Jul 10, 2017 at 9:15 AM, Jim Willeke = <= jim@willeke.com> wrote:
I know we add scopes based on the Authorization Server determ= ining that the Resource Owner is also a "Paying Customer". (Well = using OIDC so we KNOW they are a paying customer.)

--
-jim
Jim Willeke

On Fri, Jul 7, 2017 a= t 9:03 PM, William Denniss <wdenniss@google.com> wrote:

On= Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
Hi=
On 07/07/17 18:56, William Denniss wrote:
What you describe is incremental auth.

 Thanks... FYI, I thought of doing some work around it after browsing throug= h the Google docs; the line about the "asking to approve the purchase = of the kitchen sink at the authentication time is a death of the modern web= " (or something similar that I read on this list) was even more convin= cing :-)



=C2=A0

Aside: Do you return the "scope" in the token response as require= d when the scope in the response is not identical to the request (=C2=A7 5.= 1 <https://tools.ietf.org/html/rfc6749#sectio= n-5.1>, parameter: scope)?

Yes, the token service is doing it by default for all the returned access t= okens

My only question is: does the client expect this?=C2=A0 The spec talks abou= t the authorization server *reducing* scope in a few places (in =C2=A7 3.3 = <https://tools.ietf.org/html/rfc6749#section-= 3.3>, "The authorization server MAY fully or partially ignore t= he scope requested by the client" and =C2=A7 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "= The authorization server SHOULD take the client identity into account when = choosing how to honor the requested scope and MAY issue an access token wit= h less rights than requested.").=C2=A0 It never talks about *increasin= g* scope (other than it can't be done during refresh).

So I think some normative language around the potential to increase the sco= pe of the request for confidential clients (in either the way you describe,= or the way I described in the draft) is warranted.

Open question: should we require an indication from the client if they *wan= t* the scope increase? That's what include_granted_scopes was designed = to do. To allow clients to specify if this is behavior they desire.
Right, I see how a proposed "include_granted_scopes" can make it = non ambiguous


The more innovative part of the spec I think is the public (native app) cli= ent incremental auth =E2=80=93 as native apps cannot use the methods you di= scuss, or the ones Google has supported for a while for confidential client= s. That said, if we write this =E2=80=93 I think we may as well formally do= cument approaches for confidential clients too.


 thanks, Sergey

On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com= >> wrote:

=C2=A0 =C2=A0 Hi

=C2=A0 =C2=A0 Re the confidential client: let me explain please how we
=C2=A0 =C2=A0 experimented with this feature when the code flow is used.
=C2=A0 =C2=A0 1. Client requests a scope 'a' for a given User, it g= ets approved by
=C2=A0 =C2=A0 the user, the clients gets a code and exchanges it for a toke= n.

=C2=A0 =C2=A0 2. At some later stage Client requests a scope 'b' fo= r the same user
=C2=A0 =C2=A0 and if an access token for a given Client + User combination = exists
=C2=A0 =C2=A0 and the incremental authorization is supported (we use a diff= erent
=C2=A0 =C2=A0 term for now) than the service finds out from this token that= 'a'
=C2=A0 =C2=A0 has already been approved and offers a consent screen where a= user
=C2=A0 =C2=A0 sees 'a' being selected and needs to approve 'b&#= 39;.

=C2=A0 =C2=A0 3. User approves 'b'. The client gets a new code back= and exchanges
=C2=A0 =C2=A0 it for a new token which now has "a" and "b&qu= ot;.

=C2=A0 =C2=A0 At this point a client has 2 tokens, one with the "a&quo= t; scope and
=C2=A0 =C2=A0 another with the "a" and "b" scopes and t= he assumption was that the
=C2=A0 =C2=A0 client would itself remove the now redundant token with the s= cope
=C2=A0 =C2=A0 "a" only.

=C2=A0 =C2=A0 I've just updated the code for the service itself do it o= n the
=C2=A0 =C2=A0 client's behalf, optionally remove the scope "a"= ; token so that the
=C2=A0 =C2=A0 client can simply replace a reference to its scope "a&qu= ot; token with
=C2=A0 =C2=A0 the new one (scopes "a" and "b") it will = get after exchanging a code
=C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 Is it an incremental authorization or something else complete= ly :-) ?

=C2=A0 =C2=A0 One obvious difference, apart from the lower level implementa= tion
=C2=A0 =C2=A0 details, is that it is not a client which requests to include= the
=C2=A0 =C2=A0 already authorized scopes but the service does it itself if t= he
=C2=A0 =C2=A0 configuration allowing for it is enabled

=C2=A0 =C2=A0 Thanks, Sergey






=C2=A0 =C2=A0 On 05/07/17 18:17, William Denniss wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Earlier this week I submitted the following I-D= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth &l= t;https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The topic is incremental authentication (or inc= remental auth for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 short).=C2=A0 Incremental auth is used to enabl= e clients to request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 just the scopes they need when they need them = =E2=80=93 rather than all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 upfront =E2=80=93 while still only a maintainin= g a single authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 grant.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The I-D details two techniques used at Google, = one that has been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used for a while in confidential clients, and o= ne that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 launched recently as a new solution to deliver = incremental auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for public clients.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I look forward to discussing this proposal with= the working
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group. I plan to present this draft at IETF99, = hope you can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 there or watching the livestream!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I plan to ask for a call for adoption after tha= t presentation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you're interested in this topic I'd = encourage you to read the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft (it's fairly concise!).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 William



=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/oauth>


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
 =C2=A0 =C2=A0 OAuth@iet= f.org <mailto:OA= uth@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/oauth
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/oauth>




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth



--94eb2c1101b257ab77055436d1ac-- From nobody Sun Jul 16 06:37:16 2017 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 3CB65128DE5 for ; Sun, 16 Jul 2017 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-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 Wqnk-1AJoT3e for ; Sun, 16 Jul 2017 06:37:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 4BFDC1204DA for ; Sun, 16 Jul 2017 06:37:12 -0700 (PDT) Received: from [192.168.91.199] ([31.133.137.21]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPDaC-1db9aI0N72-004UqT for ; Sun, 16 Jul 2017 15:37:10 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <3dab3de1-2d49-02a6-00c4-eed427ca87c8@gmx.net> Date: Sun, 16 Jul 2017 15:36:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zEYs29iqE4Xi3QuMqxTfbchDJLCZG4f6vuTyaFyy9qXrzHUumX8 2wT4nMjRh/DuVquvBzcs+nC1IDNqI+4BR/KmXZTy+RtNoXzMRUCrTYayH/YfZbhniu9mtQ3 pJi2vfjDombnq+YkHPP22lFblR1M0Ris2I8FXJBMSXjcGfhJ6+eDKznHno0ybQ1QTnKO/sQ yLxNWB/5wJHH44XQySFeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3BoNIkeGp/A=:xELkMzPNoMAryCZERxn0yK nW8bxIMW3FRiB4gTZFs/ixUSWE9rpUbm6F3AX0/f2asL8EFtrZ2i3yHQ4RVO+JwhNa0lYjZxE 7rLSpWc9SchecpJeUaDcF2OxhwUCWk2FOuZ4qTzROp6sLxXpkjuFkGgR/uHje5zx6vjdiJefA FGMS9vfQhPiiDZVEn6a5uC7P8VkwWc27BHYKcQl7C9ekVtv4rXkYWKG0KzapkO4FbpipxPfq8 P/bB50MvWxL7DvBT6G3HZYpDbdhsYylxnPduPxhzCeijDwwpFlhRfg4P/fQLYgcOLN+wVOk6+ fRZpK8ngv3fe9ZXV7PEe06axOwXOKW80F/nxDX2OmaCak4Eqz4UvfdxsJNTWeZIwIZRKwxWv+ rrf2ULmKukvuu39dj/oGblM5r9/FsxVIlUN+/mdGa7las+tYL9ewK+LnOQ311W7hz1aI+tIGu ZOl44nCOzVZqxkBb3ZilGJmGWK1loGHHmie8DW07WLFKAax8U5K4o1/5zpiXKama/G797oOzP ShwcX0CTjAsIfgl9iVVsC2Jh7k+/pBo/eiGgGzpaw3SEFkFFCTZrb88c/VjMMVStL7fepkeDp OLxeLpT2h0+FnqOkGvuFSFfy2DoofOJW6KvVFYkJ5novAxFLnj2AIxWJBkF5y8P80AO1WJqIk yLTNy0hhKckU/GMD5BVjslOLb2jzQxROzocYLLeem4nHjmQMCB1Vec3B231RPApUiRk5GvGyc j4filRG4T7PXMliMe2c5THv3O9EJkkea9x1B1oiBjxZn8UkFx7Ikg+Rv3qiBFAmqSg5qNAD3X ugO8YtPbGI2XIpTHzn/UsN8t45rpZIdR3kw++I0zw4e4vQ/3O8= Archived-At: Subject: [OAUTH-WG] Dezentralized OAuth @ Prague IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 13:37:14 -0000 Hi all, there will be a side meeting of the distributed internet infrastructure group at IETF 99. The agenda for the meeting (see https://trac.ietf.org/trac/irtf/wiki/blockchain-federation) lists also dezentralized OAuth). This meeting will take place on Monday, July 17, from 18:50 to 20:50 in the Tyrolka room of the Hilton hotel. Ciao Hannes PS: I am not the meeting organizer but I was made aware of it. From nobody Sun Jul 16 07:38:46 2017 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 EAC13126D73 for ; Sun, 16 Jul 2017 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 hnpu_ZYujzyS for ; Sun, 16 Jul 2017 07:38:40 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 46DF21200C1 for ; Sun, 16 Jul 2017 07:38:40 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 7CC277801BC; Sun, 16 Jul 2017 16:38:36 +0200 (CEST) To: Brian Campbell Cc: oauth References: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> From: Denis Message-ID: <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr> Date: Sun, 16 Jul 2017 16:38:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA3EB109CE06AD9365F04DC4" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:38:45 -0000 This is a multi-part message in MIME format. --------------EA3EB109CE06AD9365F04DC4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Brian, It took 25 days to get a response to my WGLC comments and it took me 13 days to answer to your reply. My responses are embedded in the text. At present, I only agree with the resolution of the comment numbered 6. > Thanks for the review, Denis. And I apologize for the slow reply - > I've had a lot of different things on my plate recently. And, quite > frankly, I was sort of hoping one of the co-authors on the document > might respond to your comments. But hope only goes so far. So replies > are inline below... > > On Mon, Jun 5, 2017 at 5:30 AM, Denis > wrote: > > Comments on OAuth 2.0 Token Exchange > draft-ietf-oauth-token-exchange-08 > > 1. The abstract states: > > "This specification defines a protocol for an HTTP- and > JSON- based > Security Token Service (STS) by defining how to request and > obtain > security tokens from OAuth 2.0 authorization servers, including > security tokens employing impersonation and delegation". > > The problem is that the content of the abstract does not match > with the content of the document. > > The abstract clearly states that all cases of token requests are > supported, whereas the document mandates > the use of a subject_token parameter which restricts the scope to > impersonation and delegation. > > Currently the text states: > > "subject_token > *REQUIRED*. A security token that represents the identity of the > party on behalf of whom the request is being made. > Typically, the > subject of this token will be the subject of the security token > issued in response to this request". > > The abstract should be changed to reflect the content of the document. > > > I don't see a discrepancy between the content of the abstract and the > content of the document. > > What text or changes would you suggest in the abstract? "This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers when a specific parameter is required to identify the party on behalf of whom the request is being made". However, please read the other comments, since I am not sure thatthis change will be sufficient. > > 2. The text states on page 4: > > "The scope of this specification is limited to the > definition of a > basic request and response protocol for an STS-style token > exchange > utilizing OAuth 2.0. Although a few new JWT claims are > defined that > enable delegation semantics to be expressed, the specific > syntax, > semantics and security characteristics of the tokens > themselves (both > those presented to the AS and those obtained by the client) are > explicitly out of scope and no requirements are placed on > the trust > model in which an implementation might be deployed". > > These statements are contradictory. One parameter of the request > is mandatory (i.e. subject_token) > but there is no indication of the kind of treatment which should > be done with this parameter so that > it will be taken into consideration one way or another in the > token that will be issued. > > This document by itself would be insufficient to allow any kind of > interoperability. > Conformance to this document would not mean anything. > > > The token exchange framework promotes interoperability in the form of > common patterns and parameters that can be supported in libraries, > products, and services. It facilitates deployments like this one > https://help.salesforce.com/articleView?id=remoteaccess_oauth_asset_token_flow.htm > > or this one > https://developer.box.com/docs/getting-started-with-new-box-view > , > for example. > This is not an adequate response to my comment. Text is currently missing to explain what kind of treatment should be done with this parameter. What should the STS do with this parameter when it receives it ? How, this parameter should be processed so that it can be placed in a security token ? Is there a relationship (if any) between the "subject_token" and the "cid" (Client Identifier) that will be placed in the security token ? Why shall a security_token be used instead of simply an identifier of the OAuth 2.0client that requested the token ? The current draft cannot be understood. > > > 3. On page 7, the text states: > > "subject_token > REQUIRED. A security token that represents the identity of the > party on behalf of whom the request is being made". > > It is understood that one implementation is already using this > parameter to place in it a security token. > Since this parameter is indicated as REQUIRED, it is not > understandable why a security token shall necessarily be used. > There are other means for the STS to identify the "party on behalf > of whom the request is being made". > > Please add a rational. > > > I don't understand what kind of rational you are looking for here. Can > you suggest some specific text for the document that would address the > concern you have? In order to identify "the party on behalf of whom the request is being made", there is no need to use a security token. The text does not explain the benefits, if any, of using a security token. It does not explain either the drawbacks, i.e. the complexity for using it, in particular, how a relying party can verify that the security token is protected by the right key. What kind of trust relationships would need to be pre-established is not explained. I believe that using a security token to represent the identity of the party on behalf of whom the request is being made adds an extra level of complexity and for that reason a security token should NOT be used. If you believe that it should, then you have to explain the trust relationships, the benefits and the way to handle this parameter as it is currently not the case. > > In addition, what the STS will do, can do or should do with this > parameter is left undefined. > > > 4. On page 7, the text states: > > "subject_token > REQUIRED. (...) Typically, the subject of this token will be > the subject of the security token issued in response to this > request". > > This sentence is quite hard to understand since the specific > syntax, semantics and security characteristics of the tokens > themselves > are explicitly out of scope. The key point is what the STS should > do with this parameter: this is left undefined. > > > I don't view the sentence as difficult to understand. Maybe that's > because I wrote it? But it is true that typically it is the case that > the subject of the inbound token will be the subject of the issued > token. I don't know how else to say it. Please offer suggested text, > if you believe there's a way to say it that is easier to understand. > Could we defined this parameter in the following way ? subject_token REQUIRED. An identifier of the party on behalf of whom the request is being made (...) This identifier will be copied and pasted into the security token issued in response to this request to designate the claimed holder of the issued security token designated as the "cid" (Client Identifier) claimin RFC 6749. > > 5. The text states: > > " (...) Additional > profiles may provide more detailed requirements around the > specific > nature of the parties and trust involved, such as whether > signing > and/or encryption of tokens is needed or if > proof-of-possession style > tokens will be required or issued; > > Tokens are always signed. Please modify the sentence accordingly. > > > A token might well be cryptographically secure random sequence of > characters that reference data that can be looked up by the > appropriate parties. Or a token might be an AEAD symmetrically > encrypted JWT. So no, tokens are not always signed. Could we rephrase in the following way? " (...) Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved, such as how integrity protection of the tokens shall be done and if proof-of-possession style tokens will be required or issued; > > > 6. The following sentence is important and is being noticed. > > The security tokens obtained could be used in a number of contexts, > the specifics of which are also beyond the scope of this > specification. > > Changing the "could" into a "may" would however be more appropriate. > > > Agreed, I'll make that change. Thanks. > > > 7. In section 2.1 request, the text defines: > > resource > OPTIONAL. Indicates the physical location of the target service > or resource where the client intends to use the requested > security > token. > > and > > audience > OPTIONAL. The logical name of the target service where the > client > intends to use the requested security token. > > If the resource or the audience parameter is being used, the STS > will have the ability to know exactly which individual > or entity has accessed which target service and may keep a log of > that activity. It would be in a position to act as Big Brother. > This should be clearly indicated in a section that is currently > missing : "7. Privacy Considerations". See a text proposal hereafter. > > However, there is indeed the need to restrict the use of tokens to > specific targets. The key point is that the target service > must be able to recognize itself that the token is indeed targeted > to it. As an example, a challenge may be requested to > the target service and that challenge may then be placed into a > specific filed of the token. The target service may then verify > that the value included in the token is the one that has been > recently provided. > > A parameter specifying the type of the control value and the value > of the control should be added. > This parameter would be called a target_id (tid). It would solve > the Big Brother case. > > > That is both beyond the scope of this document and potentiality > applicable to a broader context of use. I'd suggest you write an > individual draft for the concept, if you want to pursue it. This topic has been addressed twice by two presentations on July the 13 th at the end of the first day of the OAuth workshop in Zürich. During this meeting, there have been different proposals to solve the issue. I also said that other possibilities were possible. The fact is that currently no technique has been agreed to solve the issue. I see two options: a)freeze this document and wait until a technique can be agreed within the WG and defined in another RFC, so thatwe can reference it and then after continue the work on this document b)don't wait, but mention that currently no parameter has been defined to address the issue. My preference would be for option a) What would be your preference ? If we take option b), then take a look at a new text proposal for the comment numbered 10. > > > 8. The Security Considerations section states: > > "In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The > use of > the "scp" claim is suggested to mitigate potential for such > abuse, as > it restricts the contexts in which the delegated rights can be > exercised". > > Section 4.2 defines the "scp" (Scopes) claim in the following way: > > The "scp" claim is an array of strings, each of which represents an > OAuth scope granted for the issued security token. Each array entry > of the claim value is a scope-token, as defined in Section 3.3 of > OAuth 2.0 [RFC6749]. > > Section 3.3 from RFC 6749 defines the Access Token Scope as: > > "The authorization and token endpoints allow the client to > specify the > scope of the access request using the "scope" request > parameter. In > turn, the authorization server uses the "scope" response > parameter to > inform the client of the scope of the access token issued. > The value of the scope parameter is expressed as a list of space- > delimited, case-sensitive strings. The strings are defined by the > authorization server". > > Section 5.4.1 Registry Contents defines scp as: > > o Claim Name: "scp" > o Claim Description: Scope Values > o Change Controller: IESG > o Specification Document(s): Section 4.2 of [[ this > specification ]] > > Since the "strings are defined by the authorization servers", what > a scope may mean is subject to multiple interpretations. > The current definition of scp is insufficient to allow any kind of > interoperability, now or in the future. > > It is thus unclear how the use of the "scp" claim might mitigate > the risk. > > > Scoping the token restricts what the token can be used for which > limits the impact of a compromised or misused token. The scope values > are interpreted by the parties involved just as with regular OAuth. > This is not an adequate response to my comment. You say that "scope values are interpreted by the parties involved just as with regular OAuth". I suggest the following text as a full replacement of the quoted text: Both delegation and impersonation introduce unique security issues. The potential for abuse is a concern. The use of the "scp" claim allows to restrict the contexts in which the delegated rights can be exercised. Strings in the "scp" claim are defined by the authorization servers. If the client gets some knowledge on how these strings will be handled both by a resource server and by an authorization server, then the use of the "scp" claim can be used to mitigate potential for such abuse. However, at the time of the issuance of this RFC, techniques for applying such restrictions are not defined in other RFCs. In addition, users may collude and one user might be willing to allow another user to make use of a security token that it has obtained. This is not a concern in the context of a delegation scheme, but may be a serious concern in some other contexts. Whatever kind of cryptography is being used, there is no way to stop collusion between users, unless some secure hardware is required to be used by a security token requester in order to obtain a security token. In other words, a software-only implementation is unable to prevent collusion between users. A hardware solution simply protecting some secret key or some private key will also be ineffective, since one user would be able to perform all the cryptographic computations that the other user needs. Note: People that were present on July the 13 th on the first day of the OAuth workshop in Zürich may understand better what I mean. The text and the slides of this workshop should be publicly available shortly. > > 9. This document is currently targeted to become a Standards Track > document. > > RFC 6410 recognizes two maturity levels: > > - the First Maturity Level: Proposed Standard > - the Second Maturity Level: Internet Standard > > It is not believed that currently it is possible to construct two > independent interoperating implementations > looking at this document only. Unless more guidance is provided, > this document should be targeted to "Experimental". > > > I completely disagree. And would also note that the the document's > intended status has been stable and unquestioned by this WG for > several years. > Section 2.1 from RFC 6410 states: The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1].No new requirements are introduced; no existing published requirements are relaxed. Section 4.1.1 from RFC 2026 states: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be *well-understood*, has received significant community review, and appears to enjoy enough community interest to be considered valuable. (...) A Proposed Standard should have *no known technical omissions* with respect to the requirements placed upon it. I don't believe that the current text complies with the previous statements. One of the goals of this document is to define a new parameter called "subject_token". In order to use it, we need to say how the client, the AS and the RP shall handle it. The current text is insufficient to know how to handle it. Unless additional information is provided, this document should be targeted to "Experimental". > > > 10. Text proposal for a new section "7. Privacy Considerations". > > 7. Privacy Considerations > > 7.1. Resource and audience parameters > > The use of any these two parameters allow the STS to know which > target servers are being accessed by any party making a token > request. Any STS is then able to log token requests. This is not > a problem if the resource owner and the target server are > collocated, > but this document is not restricted to that case. > > For the other cases, it should be noticed that the STS will be in > position to act as Big Brother. When privacy is a concern, the > use > of these parameters is deprecated and the use of a "tid" parameter > is recommended. > > > I will add a privacy considerations with mention of being able to > track the target systems intended to be accessed by the party > requesting a token. > The privacy section that has been added is the following: Privacy Considerations Tokens typically carry personal information and their usage in Token Exchange may reveal details of the target services being accessed. As such, tokens should only be requested and sent according to the privacy policies at the respective organizations. It does not address my concern. Hereafter is a new text proposal to address my concern, ... if we follow option b) as mentioned beforehand.: 7. Privacy Considerations 7.1. Resource and audience parameters The use of the resource or of the audience parameter allows the STS to know which target servers are being accessed by any party making a tokenrequest. Any STS will then be able to log token requests. This is not a problem as long as the resource owner and the target server are collocated, but this document is not restricted to this case. For the other cases, if either the resource parameter or the audience parameter is being used, the STS will be in position to act as Big Brother. When privacy is a concern, the use of the resource parameter and of the audience parameter is deprecated and another parameter should be used to restrict the target servers that can use the security token. At the time of the issuance of this document, such a parameter was not yet defined in another RFC. 7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection) RFC7662 defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client. The use of this protocol raises some privacy concerns, since the STS is then able to identify the clients accessing the introspection endpoint. This concern will remain even when the resource parameter or the audience parameter will not be used. Such parameters might be in the future replaced by another means to restrict the use of the security tokens to specific resource servers, but a call back to the authorization server would ruin the benefits of the use of this alternative means. Denis > > > Denis > >> All, >> >> We are starting a WGLC on the Token Exchange document: >> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 >> >> >> Please, review the document and provide feedback on any issues >> you see with the document. >> >> The WGLC will end in two weeks, on June 17, 2017. >> >> Regards, >> Rifaat and Hannes >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited. If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ --------------EA3EB109CE06AD9365F04DC4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Brian,

It took 25 days to get a response to my WGLC comments and it took me 13 days to answer to your reply.

My responses are embedded in the text. At present, I only agree with the resolution of the comment numbered 6.

Thanks for the review, Denis. And I apologize for the slow reply - I've had a lot of different things on my plate recently. And, quite frankly, I was sort of hoping one of the co-authors on the document might respond to your comments. But hope only goes so far. So replies are inline below...

On Mon, Jun 5, 2017 at 5:30 AM, Denis <denis.ietf@free.fr> wrote:
Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08

1. The abstract states:
   "This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation".
The problem is that the content of the abstract does not match with the content of the document.

The abstract clearly states that all cases of token requests are supported, whereas the document mandates
the use of a subject_token parameter which restricts the scope to impersonation and delegation.

Currently the text states:

   "subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made.  Typically, the
      subject of this token will be the subject of the security token
      issued in response to this request".

The abstract should be changed to reflect the content of the document.

I don't see a discrepancy between the content of the abstract and the content of the document.

What text or changes would you suggest in the abstract?

"This specification defines a protocol for an HTTP- and JSON- based
Security Token Service (STS) by defining how to request and obtain
security tokens from OAuth 2.0 authorization servers when a specific parameter
is required to identify the party on behalf of whom the request is being made".

However, please read the other comments, since I am not sure that this change will be sufficient.



2. The text states on page 4:
   "The scope of this specification is limited to the definition of a
   basic request and response protocol for an STS-style token exchange
   utilizing OAuth 2.0.  Although a few new JWT claims are defined that
   enable delegation semantics to be expressed, the specific syntax,
   semantics and security characteristics of the tokens themselves (both
   those presented to the AS and those obtained by the client) are
   explicitly out of scope and no requirements are placed on the trust
   model in which an implementation might be deployed".
These statements are contradictory. One parameter of the request is mandatory (i.e. subject_token)
but there is no indication of the kind of treatment which should be done with this parameter so that
it will be taken into consideration one way or another in the token that will be issued.

This document by itself would be insufficient to allow any kind of interoperability.
Conformance to this document would not mean anything.

The token exchange framework promotes interoperability in the form of common patterns and parameters that can be supported in libraries, products, and services. It facilitates deployments like this one https://help.salesforce.com/articleView?id=remoteaccess_oauth_asset_token_flow.htm or this one https://developer.box.com/docs/getting-started-with-new-box-view, for example.


This is not an adequate response to my comment. Text is currently missing to explain
what kind of treatment should be done with this parameter.

 What should the STS do with this parameter when it receives it ?

 How, this parameter should be processed so that it can be placed in a security token ?

 Is there a relationship (if any) between the "subject_token" and the "cid" (Client Identifier)
 that will be placed in the security token ?

 Why shall a security_token be used instead of simply an identifier of the OAuth 2.0 client
 that requested the token ?

 The current draft cannot be understood.




3. On page 7, the text states:

   "subject_token
      REQUIRED.  A security token that represents the identity of the
      party on behalf of whom the request is being made".

It is understood that one implementation is already using this parameter to place in it a security token.
Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used.
There are other means for the STS to identify the "party on behalf of whom the request is being made".

Please add a rational.

I don't understand what kind of rational you are looking for here. Can you suggest some specific text for the document that would address the concern you have?

In order to identify "the party on behalf of whom the request is being made", there is no need to use a security token.
The text does not explain the benefits, if any, of using a security token.

It does not explain either the drawbacks, i.e. the complexity for using it, in particular, how a relying party can verify
that the security token is protected by the right key.

What kind of trust relationships would need to be pre-established is not explained.

I believe that using a security token to represent the identity of the party on behalf of whom the request is being made
adds an extra level of complexity and for that reason a security token should NOT be used.

If you believe that it should, then you have to explain the trust relationships, the benefits and the way to handle this parameter
as it is currently not the case.



In addition, what the STS will do, can do or should do with this parameter is left undefined.


4. On page 7, the text states:

   "subject_token
      REQUIRED.  (...)  Typically, the subject of this token will be
      the subject of the security token issued in response to this
      request".

This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves
are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined.

I don't view the sentence as difficult to understand.  Maybe that's because I wrote it?  But it is true that typically it is the case that the subject of the inbound token will be the subject of the issued token. I don't know how else to say it. Please offer suggested text, if you believe there's a way to say it that is easier to understand.


Could we defined this parameter in the following way ?

subject_token
      REQUIRED.  An identifier of the party on behalf of whom the request is being made (...) 
                            This identifier will be copied and pasted into the security token issued in response to this request
                            to designate the claimed holder of the issued security token designated as the "cid" (Client Identifier) claim in RFC 6749.



5. The text states:
   " (...) Additional
   profiles may provide more detailed requirements around the specific
   nature of the parties and trust involved, such as whether signing
   and/or encryption of tokens is needed or if proof-of-possession style
   tokens will be required or issued;
Tokens are always signed. Please modify the sentence accordingly.

A token might well be cryptographically secure random sequence of characters that reference data that can be looked up by the appropriate parties. Or a token might be an AEAD symmetrically encrypted JWT. So no, tokens are not always signed.

Could we rephrase in the following way?

   " (...) Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved,
     such as how integrity protection of the tokens shall be done and if proof-of-possession style tokens will be required or issued;


 


6. The following sentence is important and is being noticed.

   The security tokens obtained could be used in a number of contexts,
   the specifics of which are also beyond the scope of this
   specification.

Changing the "could" into a "may" would however be more appropriate.

Agreed, I'll make that change.

Thanks.

 


7. In section  2.1 request, the text defines:

   resource
      OPTIONAL.  Indicates the physical location of the target service
      or resource where the client intends to use the requested security
      token. 

and

   audience
      OPTIONAL.  The logical name of the target service where the client
      intends to use the requested security token. 

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual
or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother.
This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations". See a text proposal hereafter.

However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service
must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to
the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify
that the value included in the token is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control should be added.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

That is both beyond the scope of this document and potentiality applicable to a broader context of use. I'd suggest you write an individual draft for the concept, if you want to pursue it.
 

This topic has been addressed twice by two presentations on July the 13 th at the end of the first day of the OAuth workshop in Zürich.

During this meeting, there have been different proposals to solve the issue. I also said that other possibilities were possible.

The fact is that currently no technique has been agreed to solve the issue.

I see two options:

a)     freeze this document and wait until a technique can be agreed within the WG and defined in another RFC,
so that  we can reference it and then after continue the work on this document

b)     don't wait, but mention that currently no parameter has been defined to address the issue.

My preference would be for option a)

What would be your preference ?

If we take option b), then take a look at a new text proposal for the comment numbered 10.




8. The Security Considerations section states:

   "In addition, both delegation and impersonation introduce unique
   security issues.  Any time one principal is delegated the rights of
   another principal, the potential for abuse is a concern.  The use of
   the "scp" claim is suggested to mitigate potential for such abuse, as
   it restricts the contexts in which the delegated rights can be
   exercised".

Section 4.2 defines the "scp" (Scopes) claim in the following way:

   The "scp" claim is an array of strings, each of which represents an
   OAuth scope granted for the issued security token.  Each array entry
   of the claim value is a scope-token, as defined in Section 3.3 of
   OAuth 2.0 [RFC6749].

Section 3.3 from RFC 6749 defines the Access Token Scope as:

   "The authorization and token endpoints allow the client to specify the
   scope of the access request using the "scope" request parameter.  In
   turn, the authorization server uses the "scope" response parameter to
   inform the client of the scope of the access token issued.
   The value of the scope parameter is expressed as a list of space-
   delimited, case-sensitive strings.  The strings are defined by the
   authorization server".

Section 5.4.1 Registry Contents defines scp as:

   o  Claim Name: "scp"
   o  Claim Description: Scope Values
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.2 of [[ this specification ]]

Since the "strings are defined by the authorization servers", what a scope may mean is subject to multiple interpretations.
The current definition of scp is insufficient to allow any kind of interoperability, now or in the future.

It is thus unclear how the use of the "scp" claim might mitigate the risk.

Scoping the token restricts what the token can be used for which limits the impact of a compromised or misused token. The scope values are interpreted by the parties involved just as with regular OAuth.

This is not an adequate response to my comment.

You say that "scope values are interpreted by the parties involved just as with regular OAuth".

I suggest the following text as a full replacement of the quoted text:

Both delegation and impersonation introduce unique security issues.  The potential for abuse is a concern. 
The use of the "scp" claim allows to restrict the contexts in which the delegated rights can be exercised.

Strings in the "scp" claim are defined by the authorization servers. If the client gets some knowledge
on how these strings will be handled both by a resource server and by an authorization server, then the use
of the "scp" claim can be used to mitigate potential for such abuse. However, at the time of the issuance of this RFC,
techniques for applying such restrictions are not defined in other RFCs.

In addition, users may collude and one user might be willing to allow another user to make use of a security token that it has obtained.
This is not a concern in the context of a delegation scheme, but may be a serious concern in some other contexts. Whatever kind
of cryptography is being used, there is no way to stop collusion between users, unless some secure hardware is required to be used
by a security token requester in order to obtain a security token. In other words, a software-only implementation is unable to prevent
collusion between users. A hardware solution simply protecting some secret key or some private key will also be ineffective, since
one user would be able to perform all the cryptographic computations that the other user needs.

Note: People that were present on July the 13 th on the first day of the OAuth workshop in Zürich may understand better what I mean.
The text and the slides of this workshop should be publicly available shortly.

 

9. This document is currently targeted to become a Standards Track document.

RFC 6410 recognizes two maturity levels:

   - the First Maturity Level: Proposed Standard
   - the Second Maturity Level: Internet Standard

It is not believed that currently it is possible to construct two independent interoperating implementations
looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental".

I completely disagree. And would also note that the the document's intended status has been stable and unquestioned by this WG for several years.


Section 2.1 from RFC 6410 states:

   The stated requirements for Proposed Standard are not changed; they
   remain exactly as specified in RFC 2026 [1].  No new requirements are
   introduced; no existing published requirements are relaxed.

Section 4.1.1 from RFC 2026 states:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.

(...)

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.

I don't believe that the current text complies with the previous statements.

One of the goals of this document is to define a new parameter called "subject_token".

In order to use it, we need to say how the client, the AS and the RP shall handle it.
The current text is insufficient to know how to handle it.

Unless additional information is provided, this document should be targeted to "Experimental".




10. Text proposal for a new section "7. Privacy Considerations".

   7. Privacy Considerations

   7.1. Resource and audience parameters

   The use of any these two parameters allow the STS to know which
   target servers are being accessed by any party making a token
   request.  Any STS is then able to log token requests.  This is not
   a problem if the resource owner and the target server are collocated,
   but this document is not restricted to that case.

   For the other cases, it should be noticed that the STS will be in
   position to act as Big Brother.  When privacy is a concern, the use
   of these parameters is deprecated and the use of a "tid" parameter
   is recommended.


I will add a privacy considerations with mention of being able to track the target systems intended to be accessed by the party requesting a token. 


The privacy section that has been added is the following:
Privacy Considerations

Tokens typically carry personal information and their usage in Token
Exchange may reveal details of the target services being accessed.
As such, tokens should only be requested and sent according to the
privacy policies at the respective organizations.

It does not address my concern. Hereafter is a new text proposal to address my concern, ... if we follow option b) as mentioned beforehand.:

   7. Privacy Considerations

   7.1. Resource and audience parameters

   The use of the resource or of the audience parameter allows the STS to know which target servers are being accessed
   by any party making a token request.  Any STS will then be able to log token requests. This is not a problem as long as
   the resource owner and the target server are collocated, but this document is not restricted to this case.

   For the other cases, if either the resource parameter or the audience parameter is being used, the STS will be in position
   to act as Big Brother. When privacy is a concern, the use of the resource parameter and of the audience parameter is deprecated
   and another parameter should be used to restrict the target servers that can use the security token. At the time of the issuance
   of this document, such a parameter was not yet defined in another RFC.


   7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection)

   RFC7662 defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata
   for a given token that was presented to them by an OAuth 2.0 client.

   The use of this protocol raises some privacy concerns, since the STS is then able to identify the clients accessing the introspection endpoint.
   This concern will remain even when the resource parameter or the audience parameter will not be used. Such parameters might be in the future
   replaced by another means to restrict the use of the security tokens to specific resource servers, but a call back to the authorization server would
   ruin the benefits of the use of this alternative means.


Denis

 


 
Denis

All,

We are starting a WGLC on the Token Exchange document:

Please, review the document and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
 Rifaat and Hannes



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



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



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


--------------EA3EB109CE06AD9365F04DC4-- From nobody Sun Jul 16 10:23:02 2017 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 766A0124D68 for ; Sun, 16 Jul 2017 10:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 shZe5j_QSR0v for ; Sun, 16 Jul 2017 10:22:58 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 A55A2126DC2 for ; Sun, 16 Jul 2017 10:22:57 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id AFDCE78034E; Sun, 16 Jul 2017 19:22:55 +0200 (CEST) From: Denis To: Mike Jones , yaronf.ietf@gmail.com, dick@amazon.com Cc: "oauth@ietf.org" References: <178f2f7c-a12e-234d-72aa-9d49d8621489@free.fr> Message-ID: Date: Sun, 16 Jul 2017 19:22:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <178f2f7c-a12e-234d-72aa-9d49d8621489@free.fr> Content-Type: multipart/alternative; boundary="------------DA8FCD587D2660CCB1E2071F" Content-Language: fr Archived-At: Subject: Re: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 17:23:00 -0000 This is a multi-part message in MIME format. --------------DA8FCD587D2660CCB1E2071F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit draft-sheffer-oauth-jwt-bcp-01 has been issued, butnone of the co-author has responded to my comments. These comments are copied below. Both topics mentionned below have been presented and discussed during the OAuth workshop in Zürich on July the 13 th. Denis > Comments on draft-sheffer-oauth-jwt-bcp-00 > > 1. Section 2 lists 7 known and possible threats and vulnerabilities > with JWT implementations and deployments. > In the OAuth Threat Model Document (RFC 6819) collusions between users > located inside of a system are not mentioned > but nevertheless need to be considered. One threat should be added in > this document: Client collusions > > Text proposal: > > 2.8 Client collusions > > RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) > issued in January 2013 identifies security threats coming > from hostile parties but does not mention threats coming from > collaborating parties. > > JWTs are issued to a token requestor and are normally intended to > be used by that token requestor. They are cases where > the forwarding of a JWT to another party is a desirable property > so that it can be used by that other party. This is typically the > case > when a JWT is intended to be used for delegation purposes. > > However, there are cases where a JWT does not contain a "sub" > claim, but other claims that do not allow to identify the token > requestor. > This is typically the case when a JWT contains an attribute > specifying that the token holder is over 18. In such a case, the > forwarding of > such a JWT to another party would not be a desirable property and > should be detected by target servers. > > Access token binding protection methods currently developed either > by the Token Binding WG [Token Binding WG] or by the OAuth WG > [OAuth WG] > do not allow to counter the forwarding of a JWT legitimately > obtained by a party to another party. Either the legitimate party > can provide keys > to the other party, or if it can't (because private keys are > protected by a secure element) it can send requests to his secure > element to perform > the cryptographic computations that the other party needs. > > Whatever kind of cryptographic is being used, when two parties are > willing to collaborate, a software-only solution will be unable to > prevent the transfer of an attribute of a party that possesses it > to another party that does not possess it. The use of a secure > element > will be mandatory. > > However, the use of a secure element simply protecting the > confidentiality and the integrity of some secret key or private > key will be insufficient. > Additional functional and security properties will be required for > the secure elements. > > The documents related to OAuth 2.0 do not currently specify how to > support secure elements so that the forwarding of a JWT > legitimately obtained > by a party to another party can be detected by the target server. > Unless some extensions are being defined, the OAuth 2.0 framework > will be unable > to support JWTs containing attributes that do not allow to fully > identify the token holder, typically a single attribute specifying > that the token holder > is over 18. > > > 2. Section 3 lists some best practices. Section 3.8 is written as follows: > > 3.8. Use and Validate Audience > If the same issuer can issue JWTs that are intended for use by more > than one relying party or application, the JWT MUST contain an > "aud" > (audience) claim that can be used to determine whether the JWT is > being used by an intended party or was substituted by an > attacker at > an unintended party. > > JWTs may be used in a number of contexts, in particular when the > resource owner and the target server are not collocated. > > If the resource or the audience parameter is being used, the STS will > have the ability to know exactly which individual or entity > has accessed which target service and may keep a log of that activity. > It would thus be in a position to act as Big Brother. > > Mandating implementations to have built-in Big Brother properties does > not seem to be a "good practice". > > However, there is indeed the need to restrict the use of JWTs to > specific targets. The key point is that the target service must be able > to recognize itself that the token is indeed targeted to it. As an > example, a challenge may be requested to the target service and > that challenge may then be placed into a specific filed of the JWT. > The target service may then verify that the value included > in the JWT is the one that has been recently provided. > > A parameter specifying the type of the control value and the value of > the control would need to be used. > This parameter would be called a target_id (tid). It would solve the > Big Brother case. > > This parameter cannot be introduced in a BCP document, but this should > be done in another document. > > When the resource owner and the target server are not collocated and > when privacy is a concern, the use of these parameters > should be deprecated and the use of a "tid" parameter should be > recommended. > > In any case, stating that "the JWT MUST contain an "aud" (audience) > claim" is incorrect. > > Denis > >> JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption >> (JOSE) functions underlying them are now being widely used in diverse >> sets of applications. During IETF 98 in Chicago >> , we discussed reports of people >> implementing and using JOSE and JWTs insecurely, the causes of these >> problems, and ways to address them. Part of this discussion was an >> invited JOSE/JWT Security Update >> >> presentation that I gave to two working groups, which included links >> to problem reports and describes mitigations. Citing the widespread >> use of JWTs in new IETF applications, Security Area Director Kathleen >> Moriarty suggested during these discussions that a Best Current >> Practices (BCP) document be written for JSON Web Tokens (JWTs). >> >> I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have >> produced an initial draft of a JWT BCP. Its abstract is: >> >> JSON Web Tokens, also known as JWTs [RFC7519 >> ], are URL-safe JSON-based >> security tokens that contain a set of claims that can be signed >> and/or encrypted. JWTs are being widely used and deployed as a simple >> security token format in numerous protocols and applications, both in >> the area of digital identity, and in other application areas. The >> goal of this Best Current Practices document is to provide actionable >> guidance leading to secure implementation and deployment of JWTs. >> >> In Section 2, we describe threats and vulnerabilities. In Section 3, >> we describe best practices addressing those threats and >> vulnerabilities. We believe that the best practices in Sections 3.1 >> through 3.8 are ready to apply today. Section 3.9 (Use Mutually >> Exclusive Validation Rules for Different Kinds of JWTs) describes >> several possible best practices on that topic to serve as a starting >> point for a discussion on which of them we want to recommend under >> what circumstances. >> >> We invite input from the OAuth Working Group and other interested >> parties on what best practices for JSON Web Tokens and the JOSE >> functions underlying them should be. We look forward to hearing your >> thoughts and working on this specification together. >> >> The specification is available at: >> >> * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 >> >> An HTML-formatted version is also available at: >> >> * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html >> >> -- Mike >> >> P.S. This notice was also posted at http://self-issued.info/?p=1690 >> and as @selfissued >> . >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > --------------DA8FCD587D2660CCB1E2071F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

draft-sheffer-oauth-jwt-bcp-01 has been issued, but none of the co-author has responded to my comments.

These comments are copied below.

Both topics mentionned below have been presented and discussed during the OAuth workshop in Zürich on July the 13 th.

Denis

Comments on draft-sheffer-oauth-jwt-bcp-00

1. Section 2 lists 7 known and possible threats and vulnerabilities with JWT implementations and deployments.
In the OAuth Threat Model Document (RFC 6819) collusions between users located inside of a system are not mentioned
but nevertheless need to be considered. One threat should be added in this document: Client collusions

Text proposal:
2.8 Client collusions

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations) issued in January 2013 identifies security threats coming
from hostile parties but does not mention threats coming from collaborating parties.

JWTs are issued to a token requestor and are normally intended to be used by that token requestor. They are cases where
the forwarding of a JWT to another party is a desirable property so that it can be used by that other party. This is typically the case
when a JWT is intended to be used for delegation purposes.

However, there are cases where a JWT does not contain a "sub" claim, but other claims that do not allow to identify the token requestor.
This is typically the case when a JWT contains an attribute specifying that the token holder is over 18. In such a case, the forwarding of
such a JWT to another party would not be a desirable property and should be detected by target servers.

Access token binding protection methods currently developed either by the Token Binding WG [Token Binding WG] or by the OAuth WG [OAuth WG]
do not allow to counter the forwarding of a JWT legitimately obtained by a party to another party. Either the legitimate party can provide keys
to the other party, or if it can't (because private keys are protected by a secure element) it can send requests to his secure element to perform
the cryptographic computations that the other party needs.

Whatever kind of cryptographic is being used, when two parties are willing to collaborate, a software-only solution will be unable to
prevent the transfer of an attribute of a party that possesses it to another party that does not possess it. The use of a secure element
will be mandatory.

However, the use of a secure element simply protecting the confidentiality and the integrity of some secret key or private key will be insufficient.
Additional functional and security properties will be required for the secure elements.

The documents related to OAuth 2.0 do not currently specify how to support secure elements so that the forwarding of a JWT legitimately obtained
by a party to another party can be detected by the target server. Unless some extensions are being defined, the OAuth 2.0 framework will be unable
to support JWTs containing attributes that do not allow to fully identify the token holder, typically a single attribute specifying that the token holder
is over 18.

2. Section 3 lists some best practices. Section 3.8 is written as follows:
3.8.  Use and Validate Audience
   If the same issuer can issue JWTs that are intended for use by more
   than one relying party or application, the JWT MUST contain an "aud"
   (audience) claim that can be used to determine whether the JWT is
   being used by an intended party or was substituted by an attacker at
   an unintended party.
JWTs may be used in a number of contexts, in particular when the resource owner and the target server are not collocated.

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual or entity
has accessed which target service and may keep a log of that activity. It would thus be in a position to act as Big Brother.

Mandating implementations to have built-in Big Brother properties does not seem to be a "good practice".

However, there is indeed the need to restrict the use of JWTs to specific targets. The key point is that the target service must be able
to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to the target service and
that challenge may then be placed into a specific filed of the JWT. The target service may then verify that the value included
in the JWT is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control would need to be used.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

This parameter cannot be introduced in a BCP document, but this should be done in another document.

When the resource owner and the target server are not collocated and when privacy is a concern, the use of these parameters
should be deprecated and the use of a "tid" parameter should be recommended.

In any case, stating that "the JWT MUST contain an "aud" (audience) claim" is incorrect.

Denis

JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications.  During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them.  Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and describes mitigations.  Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).

 

I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP.  Its abstract is:

JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilities.  In Section 3, we describe best practices addressing those threats and vulnerabilities.  We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.

 

We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be.  We look forward to hearing your thoughts and working on this specification together.

 

The specification is available at:

 

An HTML-formatted version is also available at:

 

                                                       -- Mike

 

P.S. This notice was also posted at http://self-issued.info/?p=1690 and as @selfissued.



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



--------------DA8FCD587D2660CCB1E2071F-- From nobody Sun Jul 16 10:46:45 2017 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 ED934124C27 for ; Sun, 16 Jul 2017 10:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE74JjQV0YVj for ; Sun, 16 Jul 2017 10:46:39 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 7B5F3120724 for ; Sun, 16 Jul 2017 10:46:39 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e199so5146382pfh.2 for ; Sun, 16 Jul 2017 10:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uwK1iOKjT3taNnXT5TVdX3oMe2J5wBe0uW2lJewxzUw=; b=PrBv30KJgZZGUu7Nw6CRd8KOEFHFMS/80bo/CFjnYy9Id4OvT2SDNBcOh4PIu19bu6 +fiCRsHi5NiCp7Nadaa+uS+ZMFa+yexAinoFdlB08axJ6YbE5uBEz01w0IVhQ/Xqrwq/ y724VYdRUtlEIZtlSgC+302v52VLN01OHtolg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uwK1iOKjT3taNnXT5TVdX3oMe2J5wBe0uW2lJewxzUw=; b=ZETKD6zOuZLsITydSeZmrmS3Ls1dx5hNsEmjoehAnuYhDMXJjKRUn3fDZHmW/A8Kuw qrpf+XmuzMI0EBpHMlAYhEre4/FnlLdIFtVDGuxy9leIjXDSrlmuQL1sVNr3N/DJh+qx 05a9p7FZxo0UlaO4ap0hw+ct3sm1ZIPwc6npefzAVUyOUp3vKe307C2sYDAz9HFfdEGf 5x2uzOYegpO1JKYM0qMrOVsLIvuTCLEiyeu2YprnKSA03pTouLy8GCqeGGVD/fYvFJVl 0Kd+NUwMdJSZXMs37UqxKVAESpnhZyz9PjtH7C6brItSs8r+iNOkN5FYhSJBa62qvQth Xepg== X-Gm-Message-State: AIVw112huIm8SijmlVSTM/75SccVfWTfavu+XikMTpSdWmzQGr3SC5zi eJPefy8qPp4jkeZoRYt+/DWdngUCflkQazMzRbcWOpLNMhLqgDbPqUKUjYvr+aUDw5qwOZT9ovs ASQVM X-Received: by 10.99.101.132 with SMTP id z126mr24781694pgb.64.1500227198892; Sun, 16 Jul 2017 10:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Sun, 16 Jul 2017 10:46:08 -0700 (PDT) In-Reply-To: <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr> References: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr> From: Brian Campbell Date: Sun, 16 Jul 2017 11:46:08 -0600 Message-ID: To: Denis Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c1171e845db01055472dd81" Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 17:46:44 -0000 --94eb2c1171e845db01055472dd81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as an individual, for a number of reasons, I do not believe that any of the additional comments or suggestions should be incorporated into the document. As a document editor working within the IETF processes, my aim is for the document to reflect the (rough) consensus of this Working Group. And I don't get the sense that there's support, let alone consensus, for any of these changes. However, rather than relying on my interpretation of support or lack thereof from the WG, I'll ask more explicitly - are there other WG remembers who are in favor of working to incorporate any of these comments or suggestions? On Sun, Jul 16, 2017 at 8:38 AM, Denis wrote: > Hello Brian, > > It took 25 days to get a response to my WGLC comments and it took me 13 > days to answer to your reply. > > My responses are embedded in the text. At present, I only agree with the > resolution of the comment numbered 6. > > Thanks for the review, Denis. And I apologize for the slow reply - I've > had a lot of different things on my plate recently. And, quite frankly, I > was sort of hoping one of the co-authors on the document might respond to > your comments. But hope only goes so far. So replies are inline below... > > On Mon, Jun 5, 2017 at 5:30 AM, Denis wrote: > >> Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08 >> >> 1. The abstract states: >> >> "This specification defines a protocol for an HTTP- and JSON- based >> Security Token Service (STS) by defining how to request and obtain >> security tokens from OAuth 2.0 authorization servers, including >> security tokens employing impersonation and delegation". >> >> The problem is that the content of the abstract does not match with the >> content of the document. >> >> The abstract clearly states that all cases of token requests are >> supported, whereas the document mandates >> the use of a subject_token parameter which restricts the scope to >> impersonation and delegation. >> >> Currently the text states: >> >> "subject_token >> *REQUIRED*. A security token that represents the identity of the >> party on behalf of whom the request is being made. Typically, the >> subject of this token will be the subject of the security token >> issued in response to this request". >> >> The abstract should be changed to reflect the content of the document. >> > > I don't see a discrepancy between the content of the abstract and the > content of the document. > > What text or changes would you suggest in the abstract? > > > "This specification defines a protocol for an HTTP- and JSON- based > Security Token Service (STS) by defining how to request and obtain > security tokens from OAuth 2.0 authorization servers when a specific > parameter > is required to identify the party on behalf of whom the request is being > made". > > However, please read the other comments, since I am not sure that this > change will be sufficient. > > >> 2. The text states on page 4: >> >> "The scope of this specification is limited to the definition of a >> basic request and response protocol for an STS-style token exchange >> utilizing OAuth 2.0. Although a few new JWT claims are defined that >> enable delegation semantics to be expressed, the specific syntax, >> semantics and security characteristics of the tokens themselves (both >> those presented to the AS and those obtained by the client) are >> explicitly out of scope and no requirements are placed on the trust >> model in which an implementation might be deployed". >> >> These statements are contradictory. One parameter of the request is >> mandatory (i.e. subject_token) >> but there is no indication of the kind of treatment which should be done >> with this parameter so that >> it will be taken into consideration one way or another in the token that >> will be issued. >> >> This document by itself would be insufficient to allow any kind of >> interoperability. >> Conformance to this document would not mean anything. >> > > The token exchange framework promotes interoperability in the form of > common patterns and parameters that can be supported in libraries, > products, and services. It facilitates deployments like this one > https://help.salesforce.com/articleView?id=3Dremoteaccess_oaut > h_asset_token_flow.htm or this one https://developer.box.com/docs > /getting-started-with-new-box-view, for example. > > > This is not an adequate response to my comment. Text is currently missing > to explain > what kind of treatment should be done with this parameter. > > What should the STS do with this parameter when it receives it ? > > How, this parameter should be processed so that it can be placed in a > security token ? > > Is there a relationship (if any) between the "subject_token" and the > "cid" (Client Identifier) > that will be placed in the security token ? > > Why shall a security_token be used instead of simply an identifier of th= e > OAuth 2.0 client > that requested the token ? > > The current draft cannot be understood. > > >> >> 3. On page 7, the text states: >> >> "subject_token >> REQUIRED. A security token that represents the identity of the >> party on behalf of whom the request is being made". >> >> It is understood that one implementation is already using this parameter >> to place in it a security token. >> Since this parameter is indicated as REQUIRED, it is not understandable >> why a security token shall necessarily be used. >> There are other means for the STS to identify the "party on behalf of >> whom the request is being made". >> >> Please add a rational. >> > > I don't understand what kind of rational you are looking for here. Can yo= u > suggest some specific text for the document that would address the concer= n > you have? > > > In order to identify "the party on behalf of whom the request is being > made", there is no need to use a security token. > The text does not explain the benefits, if any, of using a security token= . > > It does not explain either the drawbacks, i.e. the complexity for using > it, in particular, how a relying party can verify > that the security token is protected by the right key. > > What kind of trust relationships would need to be pre-established is not > explained. > > I believe that using a security token to represent the identity of the > party on behalf of whom the request is being made > adds an extra level of complexity and for that reason a security token > should NOT be used. > > If you believe that it should, then you have to explain the trust > relationships, the benefits and the way to handle this parameter > as it is currently not the case. > > >> In addition, what the STS will do, can do or should do with this >> parameter is left undefined. >> >> >> 4. On page 7, the text states: >> >> "subject_token >> REQUIRED. (...) Typically, the subject of this token will be >> the subject of the security token issued in response to this >> request". >> >> This sentence is quite hard to understand since the specific syntax, >> semantics and security characteristics of the tokens themselves >> are explicitly out of scope. The key point is what the STS should do wit= h >> this parameter: this is left undefined. >> > > I don't view the sentence as difficult to understand. Maybe that's > because I wrote it? But it is true that typically it is the case that th= e > subject of the inbound token will be the subject of the issued token. I > don't know how else to say it. Please offer suggested text, if you believ= e > there's a way to say it that is easier to understand. > > > Could we defined this parameter in the following way ? > > subject_token > REQUIRED. An identifier of the party on behalf of whom the request > is being made (...) > This identifier will be copied and pasted int= o > the security token issued in response to this request > to designate the claimed holder of the issued > security token designated as the "cid" (Client Identifier) claim in RFC > 6749. > > >> 5. The text states: >> >> " (...) Additional >> profiles may provide more detailed requirements around the specific >> nature of the parties and trust involved, such as whether signing >> and/or encryption of tokens is needed or if proof-of-possession style >> tokens will be required or issued; >> >> Tokens are always signed. Please modify the sentence accordingly. >> > > A token might well be cryptographically secure random sequence of > characters that reference data that can be looked up by the appropriate > parties. Or a token might be an AEAD symmetrically encrypted JWT. So no, > tokens are not always signed. > > > Could we rephrase in the following way? > " (...) Additional profiles may provide more detailed requirements > around the specific nature of the parties and trust involved, > such as how integrity protection of the tokens shall be done and if > proof-of-possession style tokens will be required or issued; > > > > >> >> >> 6. The following sentence is important and is being noticed. >> >> The security tokens obtained could be used in a number of contexts, >> the specifics of which are also beyond the scope of this >> specification. >> >> Changing the "could" into a "may" would however be more appropriate. >> > > Agreed, I'll make that change. > > > Thanks. > > > >> >> >> 7. In section 2.1 request, the text defines: >> >> resource >> OPTIONAL. Indicates the physical location of the target service >> or resource where the client intends to use the requested security >> token. >> >> and >> >> audience >> OPTIONAL. The logical name of the target service where the client >> intends to use the requested security token. >> >> If the resource or the audience parameter is being used, the STS will >> have the ability to know exactly which individual >> or entity has accessed which target service and may keep a log of that >> activity. It would be in a position to act as Big Brother. >> This should be clearly indicated in a section that is currently missing = : >> "7. Privacy Considerations". See a text proposal hereafter. >> >> However, there is indeed the need to restrict the use of tokens to >> specific targets. The key point is that the target service >> must be able to recognize itself that the token is indeed targeted to it= . >> As an example, a challenge may be requested to >> the target service and that challenge may then be placed into a specific >> filed of the token. The target service may then verify >> that the value included in the token is the one that has been recently >> provided. >> >> A parameter specifying the type of the control value and the value of th= e >> control should be added. >> This parameter would be called a target_id (tid). It would solve the Big >> Brother case. >> > > That is both beyond the scope of this document and potentiality applicabl= e > to a broader context of use. I'd suggest you write an individual draft fo= r > the concept, if you want to pursue it. > > > > This topic has been addressed twice by two presentations on July the 13 t= h > at the end of the first day of the OAuth workshop in Z=C3=BCrich. > > During this meeting, there have been different proposals to solve the > issue. I also said that other possibilities were possible. > > The fact is that currently no technique has been agreed to solve the issu= e. > > I see two options: > > a) freeze this document and wait until a technique can be agreed > within the WG and defined in another RFC, > so that we can reference it and then after continue the work on this > document > > b) don't wait, but mention that currently no parameter has been > defined to address the issue. > > My preference would be for option a) > > What would be your preference ? > > If we take option b), then take a look at a new text proposal for the > comment numbered 10. > > >> >> 8. The Security Considerations section states: >> >> "In addition, both delegation and impersonation introduce unique >> security issues. Any time one principal is delegated the rights of >> another principal, the potential for abuse is a concern. The use of >> the "scp" claim is suggested to mitigate potential for such abuse, as >> it restricts the contexts in which the delegated rights can be >> exercised". >> >> Section 4.2 defines the "scp" (Scopes) claim in the following way: >> >> The "scp" claim is an array of strings, each of which represents an >> OAuth scope granted for the issued security token. Each array entry >> of the claim value is a scope-token, as defined in Section 3.3 of >> OAuth 2.0 [RFC6749]. >> >> Section 3.3 from RFC 6749 defines the Access Token Scope as: >> >> "The authorization and token endpoints allow the client to specify th= e >> scope of the access request using the "scope" request parameter. In >> turn, the authorization server uses the "scope" response parameter to >> inform the client of the scope of the access token issued. >> The value of the scope parameter is expressed as a list of space- >> delimited, case-sensitive strings. The strings are defined by the >> authorization server". >> >> Section 5.4.1 Registry Contents defines scp as: >> >> o Claim Name: "scp" >> o Claim Description: Scope Values >> o Change Controller: IESG >> o Specification Document(s): Section 4.2 of [[ this specification ]] >> >> Since the "strings are defined by the authorization servers", what a >> scope may mean is subject to multiple interpretations. >> The current definition of scp is insufficient to allow any kind of >> interoperability, now or in the future. >> >> It is thus unclear how the use of the "scp" claim might mitigate the ris= k. >> > > Scoping the token restricts what the token can be used for which limits > the impact of a compromised or misused token. The scope values are > interpreted by the parties involved just as with regular OAuth. > > This is not an adequate response to my comment. > > You say that "scope values are interpreted by the parties involved just a= s > with regular OAuth". > > I suggest the following text as a full replacement of the quoted text: > > Both delegation and impersonation introduce unique security issues. The > potential for abuse is a concern. > The use of the "scp" claim allows to restrict the contexts in which the > delegated rights can be exercised. > > Strings in the "scp" claim are defined by the authorization servers. If > the client gets some knowledge > on how these strings will be handled both by a resource server and by an > authorization server, then the use > of the "scp" claim can be used to mitigate potential for such abuse. > However, at the time of the issuance of this RFC, > techniques for applying such restrictions are not defined in other RFCs. > > In addition, users may collude and one user might be willing to allow > another user to make use of a security token that it has obtained. > This is not a concern in the context of a delegation scheme, but may be a > serious concern in some other contexts. Whatever kind > of cryptography is being used, there is no way to stop collusion between > users, unless some secure hardware is required to be used > by a security token requester in order to obtain a security token. In > other words, a software-only implementation is unable to prevent > collusion between users. A hardware solution simply protecting some secre= t > key or some private key will also be ineffective, since > one user would be able to perform all the cryptographic computations that > the other user needs. > > Note: People that were present on July the 13 th on the first day of the > OAuth workshop in Z=C3=BCrich may understand better what I mean. > The text and the slides of this workshop should be publicly available > shortly. > > > >> 9. This document is currently targeted to become a Standards Track >> document. >> >> RFC 6410 recognizes two maturity levels: >> >> - the First Maturity Level: Proposed Standard >> - the Second Maturity Level: Internet Standard >> >> It is not believed that currently it is possible to construct two >> independent interoperating implementations >> looking at this document only. Unless more guidance is provided, this >> document should be targeted to "Experimental". >> > > I completely disagree. And would also note that the the document's > intended status has been stable and unquestioned by this WG for several > years. > > > Section 2.1 from RFC 6410 states: > > The stated requirements for Proposed Standard are not changed; they > remain exactly as specified in RFC 2026 [1]. No new requirements are > introduced; no existing published requirements are relaxed. > > Section 4.1.1 from RFC 2026 states: > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be *well-understood*, has receive= d > significant community review, and appears to enjoy enough community > interest to be considered valuable. > > (...) > > A Proposed Standard should have *no known technical omissions* with > respect to the requirements placed upon it. > > I don't believe that the current text complies with the previous > statements. > > One of the goals of this document is to define a new parameter called > "subject_token". > > In order to use it, we need to say how the client, the AS and the RP shal= l > handle it. > The current text is insufficient to know how to handle it. > > Unless additional information is provided, this document should be > targeted to "Experimental". > > >> >> 10. Text proposal for a new section "7. Privacy Considerations". >> >> 7. Privacy Considerations >> >> 7.1. Resource and audience parameters >> >> The use of any these two parameters allow the STS to know which >> target servers are being accessed by any party making a token >> request. Any STS is then able to log token requests. This is not >> a problem if the resource owner and the target server are collocated, >> but this document is not restricted to that case. >> >> For the other cases, it should be noticed that the STS will be in >> position to act as Big Brother. When privacy is a concern, the use >> of these parameters is deprecated and the use of a "tid" parameter >> is recommended. >> >> > I will add a privacy considerations with mention of being able to track > the target systems intended to be accessed by the party requesting a > token. > > > The privacy section that has been added is the following: > > Privacy Considerations > > Tokens typically carry personal information and their usage in Token > Exchange may reveal details of the target services being accessed. > As such, tokens should only be requested and sent according to the > privacy policies at the respective organizations. > > > It does not address my concern. Hereafter is a new text proposal to > address my concern, ... if we follow option b) as mentioned beforehand.: > > 7. Privacy Considerations > > 7.1. Resource and audience parameters > > The use of the resource or of the audience parameter allows the STS to > know which target servers are being accessed > by any party making a token request. Any STS will then be able to log > token requests. This is not a problem as long as > the resource owner and the target server are collocated, but this > document is not restricted to this case. > > For the other cases, if either the resource parameter or the audience > parameter is being used, the STS will be in position > to act as Big Brother. When privacy is a concern, the use of the > resource parameter and of the audience parameter is deprecated > and another parameter should be used to restrict the target servers > that can use the security token. At the time of the issuance > of this document, such a parameter was not yet defined in another RFC. > > > 7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection) > > RFC7662 defines a protocol that allows authorized protected resources > to query the authorization server to determine the set of metadata > for a given token that was presented to them by an OAuth 2.0 client. > > The use of this protocol raises some privacy concerns, since the STS i= s > then able to identify the clients accessing the introspection endpoint. > This concern will remain even when the resource parameter or the > audience parameter will not be used. Such parameters might be in the futu= re > replaced by another means to restrict the use of the security tokens t= o > specific resource servers, but a call back to the authorization server > would > ruin the benefits of the use of this alternative means. > > > Denis > > > >> >> >> >> > Denis >> >> All, >> >> We are starting a WGLC on the Token Exchange document: >> https://www.ietf.org/id/draft-ietf-oauth-token-exchange-08 >> >> Please, review the document and provide feedback on any issues you see >> with the document. >> >> The WGLC will end in two weeks, on June 17, 2017. >> >> Regards, >> Rifaat and Hannes >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> 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.* > > > --=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. If you have= =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.* --94eb2c1171e845db01055472dd81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an individual, for a number of reasons, I= do not believe that any of the additional comments or suggestions should b= e incorporated into the document.=C2=A0

As a document editor = working within the IETF processes, my aim is for the document to reflect th= e (rough) consensus of this Working Group. And I don't get the sense th= at there's support, let alone consensus, for any of these changes. Howe= ver, rather than relying on my interpretation of support or lack thereof fr= om the WG, I'll ask more explicitly - are there other WG remembers who = are in favor of working to incorporate any of these comments or suggestions= ?

On Sun, J= ul 16, 2017 at 8:38 AM, Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello Brian,

It took 25 days to get a response to my WGLC comments and it took me 13 days to answer to your reply.

My responses are embedded in the text. At present, I only agree with the resolution of the comment numbered 6.

Thanks for the review, Denis. And I apologize for the slow reply - I've had a lot of different things on my plate recently. And, quite frankly, I was sort of hoping one of the co-authors on the document might respond to your comments. But hope only goes so far. So replies are inline below...

On Mon, Jun 5, 2017 at 5:30 AM, Denis <denis.ietf@free.fr> wrote:
Comments on OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-08

1. The abstract states:
=C2=A0=C2=A0 "This specification defines= a protocol for an HTTP- and JSON- based
=C2=A0=C2=A0 Security Token Service (STS) by defining h= ow to request and obtain
=C2=A0=C2=A0 security tokens from OAuth 2.0 authorizati= on servers, including
=C2=A0=C2=A0 security tokens employing impersonation an= d delegation".
The problem is that the content of the abstract does not match with the content of the document.

The abstract clearly states that all cases of token requests are supported, whereas the document mandates
the use of a subject_token parameter which restricts the scope to impersonation and delegation.

Currently the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 A s= ecurity token that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 party on behalf of whom th= e request is being made.=C2=A0 Typically, the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 subject of this token will= be the subject of the security token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issued in response to this= request".

The abstract should be changed to reflect the content of the document.

I don't see a discrepancy between the content of the abstract and the content of the document.

What text or changes would you suggest in the abstract?

=20

"This specification defines a protocol for an HTTP- and JSON- based
Security Token Service (STS) by defining how to request and obtain
 security tokens from OAuth 2.0 authorization servers when a specific parameter
is required to identify the party on behalf of whom the request is being made".

However, please read the other comments, since I am not sure that this change will be sufficient.



2. The text states on page 4:
=C2=A0=C2=A0 "The scope of this specific= ation is limited to the definition of a
=C2=A0=C2=A0 basic request and response protocol for an STS-style token exchange
=C2=A0=C2=A0 utilizing OAuth 2.0.=C2=A0 Although a few = new JWT claims are defined that
=C2=A0=C2=A0 enable delegation semantics to be expresse= d, the specific syntax,
=C2=A0=C2=A0 semantics and security characteristics of = the tokens themselves (both
=C2=A0=C2=A0 those presented to the AS and those obtain= ed by the client) are
=C2=A0=C2=A0 explicitly out of scope and no requirement= s are placed on the trust
=C2=A0=C2=A0 model in which an implementation might be deployed".
These statements are contradictory. One parameter of the request is mandatory (i.e. subject_token)
but there is no indication of the kind of treatment which should be done with this parameter so that
it will be taken into consideration one way or another in the token that will be issued.

This document by itself would be insufficient to allow any kind of interoperability.
Conformance to this document would not mean anything.

The token exchange framework promotes interoperability in the form of common patterns and parameters that can be supported in libraries, products, and services. It facilitates deployments like this one https://help.salesforce.com/articleView?id=3Dremoteac= cess_oauth_asset_token_flow.htm or this one https://developer.box.com/doc= s/getting-started-with-new-box-view, for example.


=20

This is not an adequate response to my comment. Text is currently missing to explain
what kind of treatment should be done with this parameter.

=C2=A0What should th= e STS do with this parameter when it receives it ?

=C2=A0How, this parameter should be processed so that it can be placed in a security token ?

=C2=A0Is there a rel= ationship (if any) between the "subject_token" and the "cid&= quot; (Client Identifier)
=C2=A0that will be placed in the security token ?

=C2=A0Why shall a security_token be used instead of simply an identifier of the OAuth 2.0 client
=C2=A0that requested the token ?

=C2=A0The current dr= aft cannot be understood.




3. On page 7, the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 A security= token that represents the identity of the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 party on behalf of whom th= e request is being made".

It is understood that one implementation is already using this parameter to place in it a security token.
Since this parameter is indicated as REQUIRED, it is not understandable why a security token shall necessarily be used.
There are other means for the STS to identify the "party on behalf of whom the request is being made&q= uot;.

Please add a rational.

I don't understand what kind of rational you are looking for here. Can you suggest some specific text for the document that would address the concern you have?

=20

In order to identify "the party on behalf of whom the request is being made", there is no need to use a security token.
The text does not explain the benefits, if any, of using a security token.

It does not explain either the drawbacks, i.e. the complexity for using it, in particular, how a relying party can verify
that the security token is protected by the right key.

What kind of trust relationships would need to be pre-established is not explained.

I believe that using a security token to represent the identity of the party on behalf of whom the request is being made
adds an extra level of complexity and for that reason a security token should NOT be used.

If you believe that it should, then you have to explain the trust relationships, the benefits and the way to handle this parameter
as it is currently not the case.



In addition, what the STS will do, can do or should do with this parameter is left undefined.


4. On page 7, the text states:

=C2=A0=C2=A0 "subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 (...)=C2= =A0 Typically, the subject of this token will be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the subject of the securit= y token issued in response to this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 request".

This sentence is quite hard to understand since the specific syntax, semantics and security characteristics of the tokens themselves
are explicitly out of scope. The key point is what the STS should do with this parameter: this is left undefined.

I don't view the sentence as difficult to understand.= =C2=A0 Maybe that's because I wrote it?=C2=A0 But it is true tha= t typically it is the case that the subject of the inbound token will be the subject of the issued token. I don't know how else to say it. Please offer suggested text, if you believe there's a way to say it that is easier to understand.


Could we defined this parameter in the following way ?

subject_token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED.=C2=A0 An identifier of the= party on behalf of whom the request is being made (...)=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=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=C2=A0=C2=A0 This identifier will be copied and pasted into the security token issued in response to this request
=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=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=C2=A0 to designate the claimed holder of the issued security token designated as the "cid" (Client Identifier) claim in RFC 6749.



5. The text states:
=C2=A0=C2=A0 " (...) Additional
=C2=A0=C2=A0 profiles may provide more detailed require= ments around the specific
=C2=A0=C2=A0 nature of the parties and trust involved, = such as whether signing
=C2=A0=C2=A0 and/or encryption of tokens is needed or i= f proof-of-possession style
=C2=A0=C2=A0 tokens will be required or issued;
Tokens are always signed. Please modify the sentence accordingly.

A token might well be cryptographically secure random sequence of characters that reference data that can be looked up by the appropriate parties. Or a token might be an AEAD symmetrically encrypted JWT. So no, tokens are not always signed.

Could we rephrase in the following way?

=C2=A0=C2=A0 " (...) Additio= nal profiles may provide more detailed requirements around the specific nature of the parties and trust involved,
=C2=A0=C2=A0=C2=A0=C2=A0 such as how integrity protection of the tokens shall be done and if proof-of-possession style tokens will be required or issued;


=C2=A0


6. The following sentence is important and is being noticed.

=C2=A0=C2=A0 The security tokens obtained could be used i= n a number of contexts,
=C2=A0=C2=A0 the specifics of which are also beyond the s= cope of this
=C2=A0=C2=A0 specification.

Changing the "could" into a "may" wou= ld however be more appropriate.

Agreed, I'll make that change.

 Thanks.

=C2=A0


7. In section=C2=A0 2.1 request, the text defines:

=C2=A0=C2=A0 resource
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 Indicates = the physical location of the target service
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or resource where the clie= nt intends to use the requested security
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 token.=C2=A0

and

=C2=A0=C2=A0 audience
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL.=C2=A0 The logica= l name of the target service where the client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intends to use the request= ed security token.=C2=A0

If the resource or the audience parameter is being used, the STS will have the ability to know exactly which individual
or entity has accessed which target service and may keep a log of that activity. It would be in a position to act as Big Brother.
This should be clearly indicated in a section that is currently missing : "7. Privacy Considerations"= . See a text proposal hereafter.

However, there is indeed the need to restrict the use of tokens to specific targets. The key point is that the target service
must be able to recognize itself that the token is indeed targeted to it. As an example, a challenge may be requested to
the target service and that challenge may then be placed into a specific filed of the token. The target service may then verify
that the value included in the token is the one that has been recently provided.

A parameter specifying the type of the control value and the value of the control should be added.
This parameter would be called a target_id (tid). It would solve the Big Brother case.

That is both beyond the scope of this document and potentiality applicable to a broader context of use. I'd suggest you write an individual draft for the concept, if you want to pursue it.
=C2=A0

This topic has = been addressed twice by two presentations on July the 13 th at the end of the first day of the OAuth workshop in Z=C3=BCrich.

During this meeting, there have been different proposals to solve the issue. I also said that other possibilities were possible.

The fact is that currently no technique has been agreed to solve the issue.

I see two options:

a)=C2=A0=C2=A0=C2=A0=C2=A0 free= ze this document and wait until a technique can be agreed within the WG and defined in another RFC,
so that=C2=A0 we can reference it and then after continue the work on this document

b)=C2=A0=C2=A0=C2=A0=C2=A0 don&= #39;t wait, but mention that currently no parameter has been defined to address the issue.

My preference would be for option a)

What would be your preference ?

If we take option b), then take a look at a new text proposal for the comment numbered 10.




8. The Security Considerations section states:

=C2=A0=C2=A0 "In addition, both delegation and imper= sonation introduce unique
=C2=A0=C2=A0 security issues.=C2=A0 Any time one principa= l is delegated the rights of
=C2=A0=C2=A0 another principal, the potential for abuse i= s a concern.=C2=A0 The use of
=C2=A0=C2=A0 the "scp" claim is suggested to mi= tigate potential for such abuse, as
=C2=A0=C2=A0 it restricts the contexts in which the deleg= ated rights can be
=C2=A0=C2=A0 exercised".

Section 4.2 defines the "scp" (Scopes) claim in= the following way:

=C2=A0=C2=A0 The "scp" claim is an array of str= ings, each of which represents an
=C2=A0=C2=A0 OAuth scope granted for the issued security = token.=C2=A0 Each array entry
=C2=A0=C2=A0 of the claim value is a scope-token, as defi= ned in Section 3.3 of
=C2=A0=C2=A0 OAuth 2.0 [RFC6749].

Section 3.3 from RFC 6749 defines the Access Token Scope as:

=C2=A0=C2=A0 "The authorization and token endpoints = allow the client to specify the
=C2=A0=C2=A0 scope of the access request using the "= scope" request parameter.=C2=A0 In
=C2=A0=C2=A0 turn, the authorization server uses the &quo= t;scope" response parameter to
=C2=A0=C2=A0 inform the client of the scope of the access= token issued.
=C2=A0=C2=A0 The value of the scope parameter is expresse= d as a list of space-
=C2=A0=C2=A0 delimited, case-sensitive strings.=C2=A0 The= strings are defined by the
=C2=A0=C2=A0 authorization server".

Section 5.4.1 Registry Contents defines scp as:

=C2=A0=C2=A0 o=C2=A0 Claim Name: "scp"
=C2=A0=C2=A0 o=C2=A0 Claim Description: Scope Values
=C2=A0=C2=A0 o=C2=A0 Change Controller: IESG
=C2=A0=C2=A0 o=C2=A0 Specification Document(s): Section 4= .2 of [[ this specification ]]

Since the "strings are defined by the authorization servers", what a scope may mean is subject to multip= le interpretations.
The current definition of scp is insufficient to allow any kind of interoperability, now or in the future.

It is thus unclear how the use of the "scp" cla= im might mitigate the risk.

Scoping the token restricts what the token can be used for which limits the impact of a compromised or misused token. The scope values are interpreted by the parties involved just as with regular OAuth.

=20

This is not an adequate response to my comment.

You say that "scope values are interpreted by the parties involved just as with regular OAuth".

I suggest the following text as a full replacement of the quoted text:

Both delegation and impersonation introduce unique security issues.=C2=A0 The potenti= al for abuse is a concern.=C2=A0
The use of the "scp" claim allows to restrict the contexts in which the delegated rights can be exercised.

Strings in the "scp" claim are defined by the authorization servers. If the client gets some knowledge
on how these strings will be handled both by a resource server and by an authorization server, then the use
of the "scp" claim can be used to mitigate potential for such abuse. However, at the time of the issuance of this RFC,
techniques for applying such restrictions are not defined in other RFCs.

In addition, users may collude and one user might be willing to allow another user to make use of a security token that it has obtained.
This is not a concern in the context of a delegation scheme, but may be a serious concern in some other contexts. Whatever kind
of cryptography is being used, there is no way to stop collusion between users, unless some secure hardware is required to be used
by a security token requester in order to obtain a security token. In other words, a software-only implementation is unable to prevent
collusion between users. A hardware solution simply protecting some secret key or some private key will also be ineffective, since
one user would be able to perform all the cryptographic computations that the other user needs.

Note: People that were present on July the 13 th on the first day of the OAuth workshop in Z=C3=BCrich may understand better what I mean.
The text and the slides of this workshop should be publicly available shortly.

=C2=A0

9. This document is currently targeted to become a Standards Track document.

RFC 6410 recognizes two maturity levels:

=C2=A0=C2=A0 - the First Maturity Level: Proposed Standar= d
=C2=A0=C2=A0 - the Second Maturity Level: Internet Standa= rd

It is not believed that currently it is possible to construct two independent interoperating implementations
looking at this document only. Unless more guidance is provided, this document should be targeted to "Experimental".

I completely disagree. And would also note that the the document's intended status has been stable and unquestioned by this WG for several years.


Section 2.1 from RFC 6410 states:

=C2=A0=C2=A0 The stated requirements for Proposed Standard are not changed; they
=C2=A0=C2=A0 remain exactly as specified in RFC 2026 [1].=C2=A0 No new requirements are
=C2=A0=C2=A0 introduced; no existing published requirements are relaxed.

Section 4.1.1 from RFC 2026 states:

=C2=A0=C2=A0 A Proposed Standard specification is generally stable, has resolved
=C2=A0=C2=A0 known design choices, is believed to be well-understood, has received
=C2=A0=C2=A0 significant community review, and appears to enjoy enough community
=C2=A0=C2=A0 interest to be considered valuable.

(...)

=C2=A0=C2=A0 A Proposed Standard should have no known technical omissions with
=C2=A0=C2=A0 respect to the requirements placed upon it.

I don't believe that the current text complies with the previou= s statements.

One of the goals of this document is to define a new parameter called "subject_token".

In order to use it, we need to say how the client, the AS and the RP shall handle it.
The current text is insufficient to know how to handle it.

Unless additional information is provided, this document should be targeted to "Experimental".




10. Text proposal for a new section "7. Privacy Considerations".

=C2=A0=C2=A0 7. Privacy Considerations

=C2=A0=C2=A0 7.1. Resource and audience parameters

=C2=A0=C2=A0 The use of any these two parameters allow th= e STS to know which
=C2=A0=C2=A0 target servers are being accessed by any par= ty making a token
=C2=A0=C2=A0 request.=C2=A0 Any STS is then able to log t= oken requests.=C2=A0 This is not
=C2=A0=C2=A0 a problem if the resource owner and the targ= et server are collocated,
=C2=A0=C2=A0 but this document is not restricted to that = case.

=C2=A0=C2=A0 For the other cases, it should be noticed th= at the STS will be in
=C2=A0=C2=A0 position to act as Big Brother.=C2=A0 When p= rivacy is a concern, the use
=C2=A0=C2=A0 of these parameters is deprecated and the us= e of a "tid" parameter
=C2=A0=C2=A0 is recommended.


I will add a privacy considerations with mention of being able to track the target systems intended to be accessed by the party requesting a token.=C2=A0


The privacy section that has been added is the following:
Privacy Considerations

Tokens typically carry personal information and their usage in Token
Exchange may reveal details of the target services being accessed.
As such, tokens should only be requested = and sent according to the
privacy policies at the respective organizations.

It does not address my concern. Hereafter is a new text proposal to address my concern, ... if we follow option b) as mentioned beforehand.:

=C2=A0=C2=A0 7. Privacy Considerations

=C2=A0=C2=A0 7.1. Resource and audience parameters

 =C2=A0=C2=A0 The use of the resource or of the audience parameter all= ows the STS to know which target servers are being accessed
=C2=A0=C2=A0 by any party making a token request.=C2=A0 Any STS will then be able to log token requests. This is not a problem as long as
=C2=A0=C2=A0 the resource owner and the target server are collocated, but this document is not restricted to this case.

=C2=A0=C2=A0 For the other cases, if either the resource parameter or= the audience parameter is being used, the STS will be in position
=C2=A0=C2=A0 to act as Big Brother. When privacy is a concern, the use of the resource parameter and of the audience parameter is deprecated
=C2=A0=C2=A0 and another parameter should be used to restrict the target servers that can use the security token. At the time of the issuance
=C2=A0=C2=A0 of this document, such a parameter was not yet defined i= n another RFC.


=C2=A0=C2=A0 7.2. Use of RFC 7662 (OAuth 2.0 Token Introspection)

=C2=A0=C2=A0 RFC7662 defines a protocol that allows authorized protec= ted resources to query the authorization server to determine the set of metadata
=C2=A0=C2=A0 for a given token that was presented to them by an OAuth= 2.0 client.

=C2=A0=C2=A0 The use of this protocol raises some privacy concerns, since the STS is then able to identify the clients accessing the introspection endpoint.
=C2=A0=C2=A0 This concern will remain even when the resource parameter or the audience parameter will not be used. Such parameters might be in the future
=C2=A0=C2=A0 replaced by another means to restrict the use of the security tokens to specific resource servers, but a call back to the authorization server would
=C2=A0=C2=A0 ruin the benefits of the use of this alternative means.<= span class=3D"HOEnZb">


Den= is

=C2=A0


=C2=A0
Denis

All,

We are starting a WGLC on the Token Exchange document:

Please, review the document and provide feedback on any issues you see with the document.

The WGLC will end in two weeks, on June 17, 2017.

Regards,
=C2=A0Rifaat and Hannes



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



_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinf= o/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.=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 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. --94eb2c1171e845db01055472dd81-- From nobody Sun Jul 16 11:02:28 2017 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 396541200ED for ; Sun, 16 Jul 2017 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 xW7wUAVihBVh for ; Sun, 16 Jul 2017 11:02:21 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0111.outbound.protection.outlook.com [104.47.40.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7492E124C27 for ; Sun, 16 Jul 2017 11:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ID3FEinJl1e08tT9c3shZPaHJGqL39J1+PuidgXC4e8=; b=IKRVGCdMmrZ2Yek4PjhJHk/RNlYsOq/TS3UlhudHUeBf1rzYFKnCRdH4I6x4dxqWZrdPw7XBNreL5fqdNCgFH85Y86ljgWsX24sNZaJTZQbeW6z0CC1g+XPby/seRNLByvtL6jPtyzspbSFwpY6wlt4QZNOqIEd3A8OCNY3LzUI= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0150.namprd21.prod.outlook.com (10.173.189.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Sun, 16 Jul 2017 18:02:19 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1282.008; Sun, 16 Jul 2017 18:02:19 +0000 From: Mike Jones To: Brian Campbell , Denis CC: oauth Thread-Topic: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 Thread-Index: AQHS3e8sSzdgwWw+H0KK2L6ssVgsNqI+FaCAgBiw8ACAADRgAIAABCFg Date: Sun, 16 Jul 2017 18:02:19 +0000 Message-ID: References: <858f5a6a-f68c-c616-487a-a64cd8278755@free.fr> <109f3b1d-c346-d294-fe6e-519c18223a7d@free.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [88.208.89.131] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0150; 7:rouvH4BHg9/+sqi+tiSdxTqeKAMTOTGbyTZXihYnb5HWExJxys0ytrh9eIlxMMj2UZ4oQ456UgknP8as694T+1GeSHP907aSXUVXrboN7Y3QUxYoP0hP5hOpjp76T0tr/s1KyDvq+SM8fMBKqMx27+1AF4NXbm/pv6yNhQaZYQzANH+3nuLF6XLZU/MxglLVHRq5N4JAeeOFVP2zNaKyp6+jhz4VFA3AqcVXOzgTZf/0XUmLMFHvu5kVvbK8Voq7r4SoztSo8RQYEPqTellrb0I0Gxf52nIUpdSB7OYvtLxD3ek+frsfsns+NWkyZT0gX/MSB5ibh4McUwaBxl1TSFzbbhmw+7XDl3ndp/xnpzEHzKocJrpxkKDyK1RfSMqnKZ7hpBKJBABI27nIZzbFDTvMza5vmYACfFvVvYxnn3799izmRFvJhLrM66takYDSwT+yygXXg8UYlzHHxvO2kiNOlOJz3XMVY5HNdfwnebZ9NBkcnTARDvub5Ro9vtRAzBl5Megm0W7bWXewVwWAEa22QlXPEqhXRj4qul2qZZzHKQf+7RHd7rg1UK14StTUKCUz5fbXkWE1ASX3omu+dUO42puMtgFPKcYtvnYERBtZABvc2doSZ+Eg8H6SAiOQlS6bURqgMdCcbwP3UVSiQUmrfCuZKkELd0JIBCrSTn1CF7LUE2qps5y2jSkkTcwGZKm48KWivOeaxRYeRtIpdlDDh67ZIrnGOJVkctrWIhCgPwT5y5CJOzMRDLjGcIZ+Yb2gcmfz9XwD8SFtsD99FBvYqhBVdyebX7sXQDK3DZzn+FAISQdSaZezpbh+WIn7 x-ms-office365-filtering-correlation-id: 14f6e5ad-7a35-44b6-1bf7-08d4cc74cd1c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0150; x-ms-traffictypediagnostic: CY4PR21MB0150: x-exchange-antispam-report-test: UriScan:(151999592597050)(125551606395959)(278178393323532)(164954298726430)(191636701735510)(158342451672863)(133145235818549)(26388249023172)(236129657087228)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0150; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0150; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(39860400002)(51914003)(50944005)(36304003)(377454003)(24454002)(55016002)(189998001)(53936002)(33656002)(38730400002)(6436002)(2900100001)(561944003)(86362001)(6246003)(53946003)(5005710100001)(76176999)(54356999)(50986999)(99286003)(478600001)(606006)(53546010)(236005)(9686003)(54896002)(6306002)(8676002)(81166006)(74316002)(19609705001)(25786009)(4000630100001)(4326008)(72206003)(3280700002)(102836003)(6506006)(790700001)(2906002)(7696004)(77096006)(6116002)(3846002)(8936002)(3660700001)(66066001)(10290500003)(230783001)(2950100002)(229853002)(5660300001)(93886004)(5890100001)(14454004)(7736002)(10090500001)(966005)(15866825006)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0150; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504049471CEBAC95962E60FF5A30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2017 18:02:19.2594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0150 Archived-At: Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-token-exchange-08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 18:02:26 -0000 --_000_CY4PR21MB0504049471CEBAC95962E60FF5A30CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHlvdSwgQnJpYW4sIHRoYXQgaW5jb3Jwb3JhdGluZyB0aGUgcHJvcG9zZWQg Y2hhbmdlcyB3b3VsZCBub3QgZnVydGhlciB0aGUgZ29hbHMgb2YgdGhlIGRvY3VtZW50LiAgUmF0 aGVyLCB0aGV5IHdvdWxkIGRldHJhY3QgZnJvbSBhY2hpZXZpbmcgdGhlbS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFN1bmRheSwgSnVseSAxNiwgMjAxNyA3OjQ2IFBNDQpUbzog RGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBXR0xDIGZvciBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4 Y2hhbmdlLTA4DQoNClNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwsIGZvciBhIG51bWJlciBvZiBy ZWFzb25zLCBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgYW55IG9mIHRoZSBhZGRpdGlvbmFsIGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zIHNob3VsZCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZG9jdW1l bnQuDQpBcyBhIGRvY3VtZW50IGVkaXRvciB3b3JraW5nIHdpdGhpbiB0aGUgSUVURiBwcm9jZXNz ZXMsIG15IGFpbSBpcyBmb3IgdGhlIGRvY3VtZW50IHRvIHJlZmxlY3QgdGhlIChyb3VnaCkgY29u c2Vuc3VzIG9mIHRoaXMgV29ya2luZyBHcm91cC4gQW5kIEkgZG9uJ3QgZ2V0IHRoZSBzZW5zZSB0 aGF0IHRoZXJlJ3Mgc3VwcG9ydCwgbGV0IGFsb25lIGNvbnNlbnN1cywgZm9yIGFueSBvZiB0aGVz ZSBjaGFuZ2VzLiBIb3dldmVyLCByYXRoZXIgdGhhbiByZWx5aW5nIG9uIG15IGludGVycHJldGF0 aW9uIG9mIHN1cHBvcnQgb3IgbGFjayB0aGVyZW9mIGZyb20gdGhlIFdHLCBJJ2xsIGFzayBtb3Jl IGV4cGxpY2l0bHkgLSBhcmUgdGhlcmUgb3RoZXIgV0cgcmVtZW1iZXJzIHdobyBhcmUgaW4gZmF2 b3Igb2Ygd29ya2luZyB0byBpbmNvcnBvcmF0ZSBhbnkgb2YgdGhlc2UgY29tbWVudHMgb3Igc3Vn Z2VzdGlvbnM/DQoNCk9uIFN1biwgSnVsIDE2LCAyMDE3IGF0IDg6MzggQU0sIERlbmlzIDxkZW5p cy5pZXRmQGZyZWUuZnI8bWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mcj4+IHdyb3RlOg0KSGVsbG8g QnJpYW4sDQoNCkl0IHRvb2sgMjUgZGF5cyB0byBnZXQgYSByZXNwb25zZSB0byBteSBXR0xDIGNv bW1lbnRzIGFuZCBpdCB0b29rIG1lIDEzIGRheXMgdG8gYW5zd2VyIHRvIHlvdXIgcmVwbHkuDQoN Ck15IHJlc3BvbnNlcyBhcmUgZW1iZWRkZWQgaW4gdGhlIHRleHQuIEF0IHByZXNlbnQsIEkgb25s eSBhZ3JlZSB3aXRoIHRoZSByZXNvbHV0aW9uIG9mIHRoZSBjb21tZW50IG51bWJlcmVkIDYuDQpU aGFua3MgZm9yIHRoZSByZXZpZXcsIERlbmlzLiBBbmQgSSBhcG9sb2dpemUgZm9yIHRoZSBzbG93 IHJlcGx5IC0gSSd2ZSBoYWQgYSBsb3Qgb2YgZGlmZmVyZW50IHRoaW5ncyBvbiBteSBwbGF0ZSBy ZWNlbnRseS4gQW5kLCBxdWl0ZSBmcmFua2x5LCBJIHdhcyBzb3J0IG9mIGhvcGluZyBvbmUgb2Yg dGhlIGNvLWF1dGhvcnMgb24gdGhlIGRvY3VtZW50IG1pZ2h0IHJlc3BvbmQgdG8geW91ciBjb21t ZW50cy4gQnV0IGhvcGUgb25seSBnb2VzIHNvIGZhci4gU28gcmVwbGllcyBhcmUgaW5saW5lIGJl bG93Li4uDQoNCk9uIE1vbiwgSnVuIDUsIDIwMTcgYXQgNTozMCBBTSwgRGVuaXMgPGRlbmlzLmll dGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyPj4gd3JvdGU6DQpDb21tZW50cyBv biBPQXV0aCAyLjAgVG9rZW4gRXhjaGFuZ2UgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5n ZS0wOA0KDQoxLiBUaGUgYWJzdHJhY3Qgc3RhdGVzOg0KICAgIlRoaXMgc3BlY2lmaWNhdGlvbiBk ZWZpbmVzIGEgcHJvdG9jb2wgZm9yIGFuIEhUVFAtIGFuZCBKU09OLSBiYXNlZA0KICAgU2VjdXJp dHkgVG9rZW4gU2VydmljZSAoU1RTKSBieSBkZWZpbmluZyBob3cgdG8gcmVxdWVzdCBhbmQgb2J0 YWluDQogICBzZWN1cml0eSB0b2tlbnMgZnJvbSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzLCBpbmNsdWRpbmcNCiAgIHNlY3VyaXR5IHRva2VucyBlbXBsb3lpbmcgaW1wZXJzb25hdGlv biBhbmQgZGVsZWdhdGlvbiIuDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBjb250ZW50IG9mIHRo ZSBhYnN0cmFjdCBkb2VzIG5vdCBtYXRjaCB3aXRoIHRoZSBjb250ZW50IG9mIHRoZSBkb2N1bWVu dC4NCg0KVGhlIGFic3RyYWN0IGNsZWFybHkgc3RhdGVzIHRoYXQgYWxsIGNhc2VzIG9mIHRva2Vu IHJlcXVlc3RzIGFyZSBzdXBwb3J0ZWQsIHdoZXJlYXMgdGhlIGRvY3VtZW50IG1hbmRhdGVzDQp0 aGUgdXNlIG9mIGEgc3ViamVjdF90b2tlbiBwYXJhbWV0ZXIgd2hpY2ggcmVzdHJpY3RzIHRoZSBz Y29wZSB0byBpbXBlcnNvbmF0aW9uIGFuZCBkZWxlZ2F0aW9uLg0KDQpDdXJyZW50bHkgdGhlIHRl eHQgc3RhdGVzOg0KDQogICAic3ViamVjdF90b2tlbg0KICAgICAgUkVRVUlSRUQuICBBIHNlY3Vy aXR5IHRva2VuIHRoYXQgcmVwcmVzZW50cyB0aGUgaWRlbnRpdHkgb2YgdGhlDQogICAgICBwYXJ0 eSBvbiBiZWhhbGYgb2Ygd2hvbSB0aGUgcmVxdWVzdCBpcyBiZWluZyBtYWRlLiAgVHlwaWNhbGx5 LCB0aGUNCiAgICAgIHN1YmplY3Qgb2YgdGhpcyB0b2tlbiB3aWxsIGJlIHRoZSBzdWJqZWN0IG9m IHRoZSBzZWN1cml0eSB0b2tlbg0KICAgICAgaXNzdWVkIGluIHJlc3BvbnNlIHRvIHRoaXMgcmVx dWVzdCIuDQoNClRoZSBhYnN0cmFjdCBzaG91bGQgYmUgY2hhbmdlZCB0byByZWZsZWN0IHRoZSBj b250ZW50IG9mIHRoZSBkb2N1bWVudC4NCg0KSSBkb24ndCBzZWUgYSBkaXNjcmVwYW5jeSBiZXR3 ZWVuIHRoZSBjb250ZW50IG9mIHRoZSBhYnN0cmFjdCBhbmQgdGhlIGNvbnRlbnQgb2YgdGhlIGRv Y3VtZW50Lg0KV2hhdCB0ZXh0IG9yIGNoYW5nZXMgd291bGQgeW91IHN1Z2dlc3QgaW4gdGhlIGFi c3RyYWN0Pw0KDQoiVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBwcm90b2NvbCBmb3IgYW4g SFRUUC0gYW5kIEpTT04tIGJhc2VkDQpTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIChTVFMpIGJ5IGRl ZmluaW5nIGhvdyB0byByZXF1ZXN0IGFuZCBvYnRhaW4NCnNlY3VyaXR5IHRva2VucyBmcm9tIE9B dXRoIDIuMCBhdXRob3JpemF0aW9uIHNlcnZlcnMgd2hlbiBhIHNwZWNpZmljIHBhcmFtZXRlcg0K aXMgcmVxdWlyZWQgdG8gaWRlbnRpZnkgdGhlIHBhcnR5IG9uIGJlaGFsZiBvZiB3aG9tIHRoZSBy ZXF1ZXN0IGlzIGJlaW5nIG1hZGUiLg0KSG93ZXZlciwgcGxlYXNlIHJlYWQgdGhlIG90aGVyIGNv bW1lbnRzLCBzaW5jZSBJIGFtIG5vdCBzdXJlIHRoYXQgdGhpcyBjaGFuZ2Ugd2lsbCBiZSBzdWZm aWNpZW50Lg0KDQoNCg0KMi4gVGhlIHRleHQgc3RhdGVzIG9uIHBhZ2UgNDoNCiAgICJUaGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGxpbWl0ZWQgdG8gdGhlIGRlZmluaXRpb24gb2Yg YQ0KICAgYmFzaWMgcmVxdWVzdCBhbmQgcmVzcG9uc2UgcHJvdG9jb2wgZm9yIGFuIFNUUy1zdHls ZSB0b2tlbiBleGNoYW5nZQ0KICAgdXRpbGl6aW5nIE9BdXRoIDIuMC4gIEFsdGhvdWdoIGEgZmV3 IG5ldyBKV1QgY2xhaW1zIGFyZSBkZWZpbmVkIHRoYXQNCiAgIGVuYWJsZSBkZWxlZ2F0aW9uIHNl bWFudGljcyB0byBiZSBleHByZXNzZWQsIHRoZSBzcGVjaWZpYyBzeW50YXgsDQogICBzZW1hbnRp Y3MgYW5kIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgdG9rZW5zIHRoZW1zZWx2ZXMg KGJvdGgNCiAgIHRob3NlIHByZXNlbnRlZCB0byB0aGUgQVMgYW5kIHRob3NlIG9idGFpbmVkIGJ5 IHRoZSBjbGllbnQpIGFyZQ0KICAgZXhwbGljaXRseSBvdXQgb2Ygc2NvcGUgYW5kIG5vIHJlcXVp cmVtZW50cyBhcmUgcGxhY2VkIG9uIHRoZSB0cnVzdA0KICAgbW9kZWwgaW4gd2hpY2ggYW4gaW1w bGVtZW50YXRpb24gbWlnaHQgYmUgZGVwbG95ZWQiLg0KVGhlc2Ugc3RhdGVtZW50cyBhcmUgY29u dHJhZGljdG9yeS4gT25lIHBhcmFtZXRlciBvZiB0aGUgcmVxdWVzdCBpcyBtYW5kYXRvcnkgKGku ZS4gc3ViamVjdF90b2tlbikNCmJ1dCB0aGVyZSBpcyBubyBpbmRpY2F0aW9uIG9mIHRoZSBraW5k IG9mIHRyZWF0bWVudCB3aGljaCBzaG91bGQgYmUgZG9uZSB3aXRoIHRoaXMgcGFyYW1ldGVyIHNv IHRoYXQNCml0IHdpbGwgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uIG9uZSB3YXkgb3IgYW5v dGhlciBpbiB0aGUgdG9rZW4gdGhhdCB3aWxsIGJlIGlzc3VlZC4NCg0KVGhpcyBkb2N1bWVudCBi eSBpdHNlbGYgd291bGQgYmUgaW5zdWZmaWNpZW50IHRvIGFsbG93IGFueSBraW5kIG9mIGludGVy b3BlcmFiaWxpdHkuDQpDb25mb3JtYW5jZSB0byB0aGlzIGRvY3VtZW50IHdvdWxkIG5vdCBtZWFu IGFueXRoaW5nLg0KDQpUaGUgdG9rZW4gZXhjaGFuZ2UgZnJhbWV3b3JrIHByb21vdGVzIGludGVy b3BlcmFiaWxpdHkgaW4gdGhlIGZvcm0gb2YgY29tbW9uIHBhdHRlcm5zIGFuZCBwYXJhbWV0ZXJz IHRoYXQgY2FuIGJlIHN1cHBvcnRlZCBpbiBsaWJyYXJpZXMsIHByb2R1Y3RzLCBhbmQgc2Vydmlj ZXMuIEl0IGZhY2lsaXRhdGVzIGRlcGxveW1lbnRzIGxpa2UgdGhpcyBvbmUgaHR0cHM6Ly9oZWxw LnNhbGVzZm9yY2UuY29tL2FydGljbGVWaWV3P2lkPXJlbW90ZWFjY2Vzc19vYXV0aF9hc3NldF90 b2tlbl9mbG93Lmh0bSBvciB0aGlzIG9uZSBodHRwczovL2RldmVsb3Blci5ib3guY29tL2RvY3Mv Z2V0dGluZy1zdGFydGVkLXdpdGgtbmV3LWJveC12aWV3LCBmb3IgZXhhbXBsZS4NCg0KVGhpcyBp cyBub3QgYW4gYWRlcXVhdGUgcmVzcG9uc2UgdG8gbXkgY29tbWVudC4gVGV4dCBpcyBjdXJyZW50 bHkgbWlzc2luZyB0byBleHBsYWluDQp3aGF0IGtpbmQgb2YgdHJlYXRtZW50IHNob3VsZCBiZSBk b25lIHdpdGggdGhpcyBwYXJhbWV0ZXIuDQogV2hhdCBzaG91bGQgdGhlIFNUUyBkbyB3aXRoIHRo aXMgcGFyYW1ldGVyIHdoZW4gaXQgcmVjZWl2ZXMgaXQgPw0KIEhvdywgdGhpcyBwYXJhbWV0ZXIg c2hvdWxkIGJlIHByb2Nlc3NlZCBzbyB0aGF0IGl0IGNhbiBiZSBwbGFjZWQgaW4gYSBzZWN1cml0 eSB0b2tlbiA/DQogSXMgdGhlcmUgYSByZWxhdGlvbnNoaXAgKGlmIGFueSkgYmV0d2VlbiB0aGUg InN1YmplY3RfdG9rZW4iIGFuZCB0aGUgImNpZCIgKENsaWVudCBJZGVudGlmaWVyKQ0KIHRoYXQg d2lsbCBiZSBwbGFjZWQgaW4gdGhlIHNlY3VyaXR5IHRva2VuID8NCiBXaHkgc2hhbGwgYSBzZWN1 cml0eV90b2tlbiBiZSB1c2VkIGluc3RlYWQgb2Ygc2ltcGx5IGFuIGlkZW50aWZpZXIgb2YgdGhl IE9BdXRoIDIuMCBjbGllbnQNCiB0aGF0IHJlcXVlc3RlZCB0aGUgdG9rZW4gPw0KIFRoZSBjdXJy ZW50IGRyYWZ0IGNhbm5vdCBiZSB1bmRlcnN0b29kLg0KDQoNCg0KDQozLiBPbiBwYWdlIDcsIHRo ZSB0ZXh0IHN0YXRlczoNCg0KICAgInN1YmplY3RfdG9rZW4NCiAgICAgIFJFUVVJUkVELiAgQSBz ZWN1cml0eSB0b2tlbiB0aGF0IHJlcHJlc2VudHMgdGhlIGlkZW50aXR5IG9mIHRoZQ0KICAgICAg cGFydHkgb24gYmVoYWxmIG9mIHdob20gdGhlIHJlcXVlc3QgaXMgYmVpbmcgbWFkZSIuDQoNCkl0 IGlzIHVuZGVyc3Rvb2QgdGhhdCBvbmUgaW1wbGVtZW50YXRpb24gaXMgYWxyZWFkeSB1c2luZyB0 aGlzIHBhcmFtZXRlciB0byBwbGFjZSBpbiBpdCBhIHNlY3VyaXR5IHRva2VuLg0KU2luY2UgdGhp cyBwYXJhbWV0ZXIgaXMgaW5kaWNhdGVkIGFzIFJFUVVJUkVELCBpdCBpcyBub3QgdW5kZXJzdGFu ZGFibGUgd2h5IGEgc2VjdXJpdHkgdG9rZW4gc2hhbGwgbmVjZXNzYXJpbHkgYmUgdXNlZC4NClRo ZXJlIGFyZSBvdGhlciBtZWFucyBmb3IgdGhlIFNUUyB0byBpZGVudGlmeSB0aGUgInBhcnR5IG9u IGJlaGFsZiBvZiB3aG9tIHRoZSByZXF1ZXN0IGlzIGJlaW5nIG1hZGUiLg0KDQpQbGVhc2UgYWRk IGEgcmF0aW9uYWwuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IGtpbmQgb2YgcmF0aW9uYWwg eW91IGFyZSBsb29raW5nIGZvciBoZXJlLiBDYW4geW91IHN1Z2dlc3Qgc29tZSBzcGVjaWZpYyB0 ZXh0IGZvciB0aGUgZG9jdW1lbnQgdGhhdCB3b3VsZCBhZGRyZXNzIHRoZSBjb25jZXJuIHlvdSBo YXZlPw0KDQpJbiBvcmRlciB0byBpZGVudGlmeSAidGhlIHBhcnR5IG9uIGJlaGFsZiBvZiB3aG9t IHRoZSByZXF1ZXN0IGlzIGJlaW5nIG1hZGUiLCB0aGVyZSBpcyBubyBuZWVkIHRvIHVzZSBhIHNl Y3VyaXR5IHRva2VuLg0KVGhlIHRleHQgZG9lcyBub3QgZXhwbGFpbiB0aGUgYmVuZWZpdHMsIGlm IGFueSwgb2YgdXNpbmcgYSBzZWN1cml0eSB0b2tlbi4NCkl0IGRvZXMgbm90IGV4cGxhaW4gZWl0 aGVyIHRoZSBkcmF3YmFja3MsIGkuZS4gdGhlIGNvbXBsZXhpdHkgZm9yIHVzaW5nIGl0LCBpbiBw YXJ0aWN1bGFyLCBob3cgYSByZWx5aW5nIHBhcnR5IGNhbiB2ZXJpZnkNCnRoYXQgdGhlIHNlY3Vy aXR5IHRva2VuIGlzIHByb3RlY3RlZCBieSB0aGUgcmlnaHQga2V5Lg0KV2hhdCBraW5kIG9mIHRy dXN0IHJlbGF0aW9uc2hpcHMgd291bGQgbmVlZCB0byBiZSBwcmUtZXN0YWJsaXNoZWQgaXMgbm90 IGV4cGxhaW5lZC4NCkkgYmVsaWV2ZSB0aGF0IHVzaW5nIGEgc2VjdXJpdHkgdG9rZW4gdG8gcmVw cmVzZW50IHRoZSBpZGVudGl0eSBvZiB0aGUgcGFydHkgb24gYmVoYWxmIG9mIHdob20gdGhlIHJl cXVlc3QgaXMgYmVpbmcgbWFkZQ0KYWRkcyBhbiBleHRyYSBsZXZlbCBvZiBjb21wbGV4aXR5IGFu ZCBmb3IgdGhhdCByZWFzb24gYSBzZWN1cml0eSB0b2tlbiBzaG91bGQgTk9UIGJlIHVzZWQuDQpJ ZiB5b3UgYmVsaWV2ZSB0aGF0IGl0IHNob3VsZCwgdGhlbiB5b3UgaGF2ZSB0byBleHBsYWluIHRo ZSB0cnVzdCByZWxhdGlvbnNoaXBzLCB0aGUgYmVuZWZpdHMgYW5kIHRoZSB3YXkgdG8gaGFuZGxl IHRoaXMgcGFyYW1ldGVyDQphcyBpdCBpcyBjdXJyZW50bHkgbm90IHRoZSBjYXNlLg0KDQoNCg0K SW4gYWRkaXRpb24sIHdoYXQgdGhlIFNUUyB3aWxsIGRvLCBjYW4gZG8gb3Igc2hvdWxkIGRvIHdp dGggdGhpcyBwYXJhbWV0ZXIgaXMgbGVmdCB1bmRlZmluZWQuDQoNCg0KNC4gT24gcGFnZSA3LCB0 aGUgdGV4dCBzdGF0ZXM6DQoNCiAgICJzdWJqZWN0X3Rva2VuDQogICAgICBSRVFVSVJFRC4gICgu Li4pICBUeXBpY2FsbHksIHRoZSBzdWJqZWN0IG9mIHRoaXMgdG9rZW4gd2lsbCBiZQ0KICAgICAg dGhlIHN1YmplY3Qgb2YgdGhlIHNlY3VyaXR5IHRva2VuIGlzc3VlZCBpbiByZXNwb25zZSB0byB0 aGlzDQogICAgICByZXF1ZXN0Ii4NCg0KVGhpcyBzZW50ZW5jZSBpcyBxdWl0ZSBoYXJkIHRvIHVu ZGVyc3RhbmQgc2luY2UgdGhlIHNwZWNpZmljIHN5bnRheCwgc2VtYW50aWNzIGFuZCBzZWN1cml0 eSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHRva2VucyB0aGVtc2VsdmVzDQphcmUgZXhwbGljaXRs eSBvdXQgb2Ygc2NvcGUuIFRoZSBrZXkgcG9pbnQgaXMgd2hhdCB0aGUgU1RTIHNob3VsZCBkbyB3 aXRoIHRoaXMgcGFyYW1ldGVyOiB0aGlzIGlzIGxlZnQgdW5kZWZpbmVkLg0KDQpJIGRvbid0IHZp ZXcgdGhlIHNlbnRlbmNlIGFzIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kLiAgTWF5YmUgdGhhdCdz IGJlY2F1c2UgSSB3cm90ZSBpdD8gIEJ1dCBpdCBpcyB0cnVlIHRoYXQgdHlwaWNhbGx5IGl0IGlz IHRoZSBjYXNlIHRoYXQgdGhlIHN1YmplY3Qgb2YgdGhlIGluYm91bmQgdG9rZW4gd2lsbCBiZSB0 aGUgc3ViamVjdCBvZiB0aGUgaXNzdWVkIHRva2VuLiBJIGRvbid0IGtub3cgaG93IGVsc2UgdG8g c2F5IGl0LiBQbGVhc2Ugb2ZmZXIgc3VnZ2VzdGVkIHRleHQsIGlmIHlvdSBiZWxpZXZlIHRoZXJl J3MgYSB3YXkgdG8gc2F5IGl0IHRoYXQgaXMgZWFzaWVyIHRvIHVuZGVyc3RhbmQuDQoNCkNvdWxk IHdlIGRlZmluZWQgdGhpcyBwYXJhbWV0ZXIgaW4gdGhlIGZvbGxvd2luZyB3YXkgPw0Kc3ViamVj dF90b2tlbg0KICAgICAgUkVRVUlSRUQuICBBbiBpZGVudGlmaWVyIG9mIHRoZSBwYXJ0eSBvbiBi ZWhhbGYgb2Ygd2hvbSB0aGUgcmVxdWVzdCBpcyBiZWluZyBtYWRlICguLi4pDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhpcyBpZGVudGlmaWVyIHdpbGwgYmUgY29waWVkIGFuZCBwYXN0 ZWQgaW50byB0aGUgc2VjdXJpdHkgdG9rZW4gaXNzdWVkIGluIHJlc3BvbnNlIHRvIHRoaXMgcmVx dWVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGRlc2lnbmF0ZSB0aGUgY2xhaW1l ZCBob2xkZXIgb2YgdGhlIGlzc3VlZCBzZWN1cml0eSB0b2tlbiBkZXNpZ25hdGVkIGFzIHRoZSAi Y2lkIiAoQ2xpZW50IElkZW50aWZpZXIpIGNsYWltIGluIFJGQyA2NzQ5Lg0KDQoNCg0KNS4gVGhl IHRleHQgc3RhdGVzOg0KICAgIiAoLi4uKSBBZGRpdGlvbmFsDQogICBwcm9maWxlcyBtYXkgcHJv dmlkZSBtb3JlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBhcm91bmQgdGhlIHNwZWNpZmljDQogICBu YXR1cmUgb2YgdGhlIHBhcnRpZXMgYW5kIHRydXN0IGludm9sdmVkLCBzdWNoIGFzIHdoZXRoZXIg c2lnbmluZw0KICAgYW5kL29yIGVuY3J5cHRpb24gb2YgdG9rZW5zIGlzIG5lZWRlZCBvciBpZiBw cm9vZi1vZi1wb3NzZXNzaW9uIHN0eWxlDQogICB0b2tlbnMgd2lsbCBiZSByZXF1aXJlZCBvciBp c3N1ZWQ7DQpUb2tlbnMgYXJlIGFsd2F5cyBzaWduZWQuIFBsZWFzZSBtb2RpZnkgdGhlIHNlbnRl bmNlIGFjY29yZGluZ2x5Lg0KDQpBIHRva2VuIG1pZ2h0IHdlbGwgYmUgY3J5cHRvZ3JhcGhpY2Fs bHkgc2VjdXJlIHJhbmRvbSBzZXF1ZW5jZSBvZiBjaGFyYWN0ZXJzIHRoYXQgcmVmZXJlbmNlIGRh dGEgdGhhdCBjYW4gYmUgbG9va2VkIHVwIGJ5IHRoZSBhcHByb3ByaWF0ZSBwYXJ0aWVzLiBPciBh IHRva2VuIG1pZ2h0IGJlIGFuIEFFQUQgc3ltbWV0cmljYWxseSBlbmNyeXB0ZWQgSldULiBTbyBu bywgdG9rZW5zIGFyZSBub3QgYWx3YXlzIHNpZ25lZC4NCg0KQ291bGQgd2UgcmVwaHJhc2UgaW4g dGhlIGZvbGxvd2luZyB3YXk/DQogICAiICguLi4pIEFkZGl0aW9uYWwgcHJvZmlsZXMgbWF5IHBy b3ZpZGUgbW9yZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgYXJvdW5kIHRoZSBzcGVjaWZpYyBuYXR1 cmUgb2YgdGhlIHBhcnRpZXMgYW5kIHRydXN0IGludm9sdmVkLA0KICAgICBzdWNoIGFzIGhvdyBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiB0aGUgdG9rZW5zIHNoYWxsIGJlIGRvbmUgYW5kIGlmIHBy b29mLW9mLXBvc3Nlc3Npb24gc3R5bGUgdG9rZW5zIHdpbGwgYmUgcmVxdWlyZWQgb3IgaXNzdWVk Ow0KDQoNCg0KDQoNCg0KNi4gVGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpcyBpbXBvcnRhbnQgYW5k IGlzIGJlaW5nIG5vdGljZWQuDQoNCiAgIFRoZSBzZWN1cml0eSB0b2tlbnMgb2J0YWluZWQgY291 bGQgYmUgdXNlZCBpbiBhIG51bWJlciBvZiBjb250ZXh0cywNCiAgIHRoZSBzcGVjaWZpY3Mgb2Yg d2hpY2ggYXJlIGFsc28gYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9u Lg0KDQpDaGFuZ2luZyB0aGUgImNvdWxkIiBpbnRvIGEgIm1heSIgd291bGQgaG93ZXZlciBiZSBt b3JlIGFwcHJvcHJpYXRlLg0KDQpBZ3JlZWQsIEknbGwgbWFrZSB0aGF0IGNoYW5nZS4NCg0KVGhh bmtzLg0KDQoNCg0KDQoNCjcuIEluIHNlY3Rpb24gIDIuMSByZXF1ZXN0LCB0aGUgdGV4dCBkZWZp bmVzOg0KDQogICByZXNvdXJjZQ0KICAgICAgT1BUSU9OQUwuICBJbmRpY2F0ZXMgdGhlIHBoeXNp Y2FsIGxvY2F0aW9uIG9mIHRoZSB0YXJnZXQgc2VydmljZQ0KICAgICAgb3IgcmVzb3VyY2Ugd2hl cmUgdGhlIGNsaWVudCBpbnRlbmRzIHRvIHVzZSB0aGUgcmVxdWVzdGVkIHNlY3VyaXR5DQogICAg ICB0b2tlbi4NCg0KYW5kDQoNCiAgIGF1ZGllbmNlDQogICAgICBPUFRJT05BTC4gIFRoZSBsb2dp Y2FsIG5hbWUgb2YgdGhlIHRhcmdldCBzZXJ2aWNlIHdoZXJlIHRoZSBjbGllbnQNCiAgICAgIGlu dGVuZHMgdG8gdXNlIHRoZSByZXF1ZXN0ZWQgc2VjdXJpdHkgdG9rZW4uDQoNCklmIHRoZSByZXNv dXJjZSBvciB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGlzIGJlaW5nIHVzZWQsIHRoZSBTVFMgd2ls bCBoYXZlIHRoZSBhYmlsaXR5IHRvIGtub3cgZXhhY3RseSB3aGljaCBpbmRpdmlkdWFsDQpvciBl bnRpdHkgaGFzIGFjY2Vzc2VkIHdoaWNoIHRhcmdldCBzZXJ2aWNlIGFuZCBtYXkga2VlcCBhIGxv ZyBvZiB0aGF0IGFjdGl2aXR5LiBJdCB3b3VsZCBiZSBpbiBhIHBvc2l0aW9uIHRvIGFjdCBhcyBC aWcgQnJvdGhlci4NClRoaXMgc2hvdWxkIGJlIGNsZWFybHkgaW5kaWNhdGVkIGluIGEgc2VjdGlv biB0aGF0IGlzIGN1cnJlbnRseSBtaXNzaW5nIDogIjcuIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMi LiBTZWUgYSB0ZXh0IHByb3Bvc2FsIGhlcmVhZnRlci4NCg0KSG93ZXZlciwgdGhlcmUgaXMgaW5k ZWVkIHRoZSBuZWVkIHRvIHJlc3RyaWN0IHRoZSB1c2Ugb2YgdG9rZW5zIHRvIHNwZWNpZmljIHRh cmdldHMuIFRoZSBrZXkgcG9pbnQgaXMgdGhhdCB0aGUgdGFyZ2V0IHNlcnZpY2UNCm11c3QgYmUg YWJsZSB0byByZWNvZ25pemUgaXRzZWxmIHRoYXQgdGhlIHRva2VuIGlzIGluZGVlZCB0YXJnZXRl ZCB0byBpdC4gQXMgYW4gZXhhbXBsZSwgYSBjaGFsbGVuZ2UgbWF5IGJlIHJlcXVlc3RlZCB0bw0K dGhlIHRhcmdldCBzZXJ2aWNlIGFuZCB0aGF0IGNoYWxsZW5nZSBtYXkgdGhlbiBiZSBwbGFjZWQg aW50byBhIHNwZWNpZmljIGZpbGVkIG9mIHRoZSB0b2tlbi4gVGhlIHRhcmdldCBzZXJ2aWNlIG1h eSB0aGVuIHZlcmlmeQ0KdGhhdCB0aGUgdmFsdWUgaW5jbHVkZWQgaW4gdGhlIHRva2VuIGlzIHRo ZSBvbmUgdGhhdCBoYXMgYmVlbiByZWNlbnRseSBwcm92aWRlZC4NCg0KQSBwYXJhbWV0ZXIgc3Bl Y2lmeWluZyB0aGUgdHlwZSBvZiB0aGUgY29udHJvbCB2YWx1ZSBhbmQgdGhlIHZhbHVlIG9mIHRo ZSBjb250cm9sIHNob3VsZCBiZSBhZGRlZC4NClRoaXMgcGFyYW1ldGVyIHdvdWxkIGJlIGNhbGxl ZCBhIHRhcmdldF9pZCAodGlkKS4gSXQgd291bGQgc29sdmUgdGhlIEJpZyBCcm90aGVyIGNhc2Uu DQoNClRoYXQgaXMgYm90aCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHBv dGVudGlhbGl0eSBhcHBsaWNhYmxlIHRvIGEgYnJvYWRlciBjb250ZXh0IG9mIHVzZS4gSSdkIHN1 Z2dlc3QgeW91IHdyaXRlIGFuIGluZGl2aWR1YWwgZHJhZnQgZm9yIHRoZSBjb25jZXB0LCBpZiB5 b3Ugd2FudCB0byBwdXJzdWUgaXQuDQoNCg0KVGhpcyB0b3BpYyBoYXMgYmVlbiBhZGRyZXNzZWQg dHdpY2UgYnkgdHdvIHByZXNlbnRhdGlvbnMgb24gSnVseSB0aGUgMTMgdGggYXQgdGhlIGVuZCBv ZiB0aGUgZmlyc3QgZGF5IG9mIHRoZSBPQXV0aCB3b3Jrc2hvcCBpbiBaw7xyaWNoLg0KRHVyaW5n IHRoaXMgbWVldGluZywgdGhlcmUgaGF2ZSBiZWVuIGRpZmZlcmVudCBwcm9wb3NhbHMgdG8gc29s dmUgdGhlIGlzc3VlLiBJIGFsc28gc2FpZCB0aGF0IG90aGVyIHBvc3NpYmlsaXRpZXMgd2VyZSBw b3NzaWJsZS4NClRoZSBmYWN0IGlzIHRoYXQgY3VycmVudGx5IG5vIHRlY2huaXF1ZSBoYXMgYmVl biBhZ3JlZWQgdG8gc29sdmUgdGhlIGlzc3VlLg0KSSBzZWUgdHdvIG9wdGlvbnM6DQphKSAgICAg ZnJlZXplIHRoaXMgZG9jdW1lbnQgYW5kIHdhaXQgdW50aWwgYSB0ZWNobmlxdWUgY2FuIGJlIGFn cmVlZCB3aXRoaW4gdGhlIFdHIGFuZCBkZWZpbmVkIGluIGFub3RoZXIgUkZDLA0Kc28gdGhhdCAg d2UgY2FuIHJlZmVyZW5jZSBpdCBhbmQgdGhlbiBhZnRlciBjb250aW51ZSB0aGUgd29yayBvbiB0 aGlzIGRvY3VtZW50DQpiKSAgICAgZG9uJ3Qgd2FpdCwgYnV0IG1lbnRpb24gdGhhdCBjdXJyZW50 bHkgbm8gcGFyYW1ldGVyIGhhcyBiZWVuIGRlZmluZWQgdG8gYWRkcmVzcyB0aGUgaXNzdWUuDQpN eSBwcmVmZXJlbmNlIHdvdWxkIGJlIGZvciBvcHRpb24gYSkNCldoYXQgd291bGQgYmUgeW91ciBw cmVmZXJlbmNlID8NCklmIHdlIHRha2Ugb3B0aW9uIGIpLCB0aGVuIHRha2UgYSBsb29rIGF0IGEg bmV3IHRleHQgcHJvcG9zYWwgZm9yIHRoZSBjb21tZW50IG51bWJlcmVkIDEwLg0KDQoNCg0KDQo4 LiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXM6DQoNCiAgICJJbiBh ZGRpdGlvbiwgYm90aCBkZWxlZ2F0aW9uIGFuZCBpbXBlcnNvbmF0aW9uIGludHJvZHVjZSB1bmlx dWUNCiAgIHNlY3VyaXR5IGlzc3Vlcy4gIEFueSB0aW1lIG9uZSBwcmluY2lwYWwgaXMgZGVsZWdh dGVkIHRoZSByaWdodHMgb2YNCiAgIGFub3RoZXIgcHJpbmNpcGFsLCB0aGUgcG90ZW50aWFsIGZv ciBhYnVzZSBpcyBhIGNvbmNlcm4uICBUaGUgdXNlIG9mDQogICB0aGUgInNjcCIgY2xhaW0gaXMg c3VnZ2VzdGVkIHRvIG1pdGlnYXRlIHBvdGVudGlhbCBmb3Igc3VjaCBhYnVzZSwgYXMNCiAgIGl0 IHJlc3RyaWN0cyB0aGUgY29udGV4dHMgaW4gd2hpY2ggdGhlIGRlbGVnYXRlZCByaWdodHMgY2Fu IGJlDQogICBleGVyY2lzZWQiLg0KDQpTZWN0aW9uIDQuMiBkZWZpbmVzIHRoZSAic2NwIiAoU2Nv cGVzKSBjbGFpbSBpbiB0aGUgZm9sbG93aW5nIHdheToNCg0KICAgVGhlICJzY3AiIGNsYWltIGlz IGFuIGFycmF5IG9mIHN0cmluZ3MsIGVhY2ggb2Ygd2hpY2ggcmVwcmVzZW50cyBhbg0KICAgT0F1 dGggc2NvcGUgZ3JhbnRlZCBmb3IgdGhlIGlzc3VlZCBzZWN1cml0eSB0b2tlbi4gIEVhY2ggYXJy YXkgZW50cnkNCiAgIG9mIHRoZSBjbGFpbSB2YWx1ZSBpcyBhIHNjb3BlLXRva2VuLCBhcyBkZWZp bmVkIGluIFNlY3Rpb24gMy4zIG9mDQogICBPQXV0aCAyLjAgW1JGQzY3NDldLg0KDQpTZWN0aW9u IDMuMyBmcm9tIFJGQyA2NzQ5IGRlZmluZXMgdGhlIEFjY2VzcyBUb2tlbiBTY29wZSBhczoNCg0K ICAgIlRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVu dCB0byBzcGVjaWZ5IHRoZQ0KICAgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IHVzaW5nIHRo ZSAic2NvcGUiIHJlcXVlc3QgcGFyYW1ldGVyLiAgSW4NCiAgIHR1cm4sIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciB1c2VzIHRoZSAic2NvcGUiIHJlc3BvbnNlIHBhcmFtZXRlciB0bw0KICAgaW5m b3JtIHRoZSBjbGllbnQgb2YgdGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkLg0K ICAgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlz dCBvZiBzcGFjZS0NCiAgIGRlbGltaXRlZCwgY2FzZS1zZW5zaXRpdmUgc3RyaW5ncy4gIFRoZSBz dHJpbmdzIGFyZSBkZWZpbmVkIGJ5IHRoZQ0KICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIiLg0KDQpT ZWN0aW9uIDUuNC4xIFJlZ2lzdHJ5IENvbnRlbnRzIGRlZmluZXMgc2NwIGFzOg0KDQogICBvICBD bGFpbSBOYW1lOiAic2NwIg0KICAgbyAgQ2xhaW0gRGVzY3JpcHRpb246IFNjb3BlIFZhbHVlcw0K ICAgbyAgQ2hhbmdlIENvbnRyb2xsZXI6IElFU0cNCiAgIG8gIFNwZWNpZmljYXRpb24gRG9jdW1l bnQocyk6IFNlY3Rpb24gNC4yIG9mIFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBdXQ0KDQpTaW5jZSB0 aGUgInN0cmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycyIsIHdo YXQgYSBzY29wZSBtYXkgbWVhbiBpcyBzdWJqZWN0IHRvIG11bHRpcGxlIGludGVycHJldGF0aW9u cy4NClRoZSBjdXJyZW50IGRlZmluaXRpb24gb2Ygc2NwIGlzIGluc3VmZmljaWVudCB0byBhbGxv dyBhbnkga2luZCBvZiBpbnRlcm9wZXJhYmlsaXR5LCBub3cgb3IgaW4gdGhlIGZ1dHVyZS4NCg0K SXQgaXMgdGh1cyB1bmNsZWFyIGhvdyB0aGUgdXNlIG9mIHRoZSAic2NwIiBjbGFpbSBtaWdodCBt aXRpZ2F0ZSB0aGUgcmlzay4NCg0KU2NvcGluZyB0aGUgdG9rZW4gcmVzdHJpY3RzIHdoYXQgdGhl IHRva2VuIGNhbiBiZSB1c2VkIGZvciB3aGljaCBsaW1pdHMgdGhlIGltcGFjdCBvZiBhIGNvbXBy b21pc2VkIG9yIG1pc3VzZWQgdG9rZW4uIFRoZSBzY29wZSB2YWx1ZXMgYXJlIGludGVycHJldGVk IGJ5IHRoZSBwYXJ0aWVzIGludm9sdmVkIGp1c3QgYXMgd2l0aCByZWd1bGFyIE9BdXRoLg0KVGhp cyBpcyBub3QgYW4gYWRlcXVhdGUgcmVzcG9uc2UgdG8gbXkgY29tbWVudC4NCllvdSBzYXkgdGhh dCAic2NvcGUgdmFsdWVzIGFyZSBpbnRlcnByZXRlZCBieSB0aGUgcGFydGllcyBpbnZvbHZlZCBq dXN0IGFzIHdpdGggcmVndWxhciBPQXV0aCIuDQpJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyB0ZXh0 IGFzIGEgZnVsbCByZXBsYWNlbWVudCBvZiB0aGUgcXVvdGVkIHRleHQ6DQpCb3RoIGRlbGVnYXRp b24gYW5kIGltcGVyc29uYXRpb24gaW50cm9kdWNlIHVuaXF1ZSBzZWN1cml0eSBpc3N1ZXMuICBU aGUgcG90ZW50aWFsIGZvciBhYnVzZSBpcyBhIGNvbmNlcm4uDQpUaGUgdXNlIG9mIHRoZSAic2Nw IiBjbGFpbSBhbGxvd3MgdG8gcmVzdHJpY3QgdGhlIGNvbnRleHRzIGluIHdoaWNoIHRoZSBkZWxl Z2F0ZWQgcmlnaHRzIGNhbiBiZSBleGVyY2lzZWQuDQoNClN0cmluZ3MgaW4gdGhlICJzY3AiIGNs YWltIGFyZSBkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMuIElmIHRoZSBjbGll bnQgZ2V0cyBzb21lIGtub3dsZWRnZQ0Kb24gaG93IHRoZXNlIHN0cmluZ3Mgd2lsbCBiZSBoYW5k bGVkIGJvdGggYnkgYSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGJ5IGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyLCB0aGVuIHRoZSB1c2UNCm9mIHRoZSAic2NwIiBjbGFpbSBjYW4gYmUgdXNlZCB0byBtaXRp Z2F0ZSBwb3RlbnRpYWwgZm9yIHN1Y2ggYWJ1c2UuIEhvd2V2ZXIsIGF0IHRoZSB0aW1lIG9mIHRo ZSBpc3N1YW5jZSBvZiB0aGlzIFJGQywNCnRlY2huaXF1ZXMgZm9yIGFwcGx5aW5nIHN1Y2ggcmVz dHJpY3Rpb25zIGFyZSBub3QgZGVmaW5lZCBpbiBvdGhlciBSRkNzLg0KSW4gYWRkaXRpb24sIHVz ZXJzIG1heSBjb2xsdWRlIGFuZCBvbmUgdXNlciBtaWdodCBiZSB3aWxsaW5nIHRvIGFsbG93IGFu b3RoZXIgdXNlciB0byBtYWtlIHVzZSBvZiBhIHNlY3VyaXR5IHRva2VuIHRoYXQgaXQgaGFzIG9i dGFpbmVkLg0KVGhpcyBpcyBub3QgYSBjb25jZXJuIGluIHRoZSBjb250ZXh0IG9mIGEgZGVsZWdh dGlvbiBzY2hlbWUsIGJ1dCBtYXkgYmUgYSBzZXJpb3VzIGNvbmNlcm4gaW4gc29tZSBvdGhlciBj b250ZXh0cy4gV2hhdGV2ZXIga2luZA0Kb2YgY3J5cHRvZ3JhcGh5IGlzIGJlaW5nIHVzZWQsIHRo ZXJlIGlzIG5vIHdheSB0byBzdG9wIGNvbGx1c2lvbiBiZXR3ZWVuIHVzZXJzLCB1bmxlc3Mgc29t ZSBzZWN1cmUgaGFyZHdhcmUgaXMgcmVxdWlyZWQgdG8gYmUgdXNlZA0KYnkgYSBzZWN1cml0eSB0 b2tlbiByZXF1ZXN0ZXIgaW4gb3JkZXIgdG8gb2J0YWluIGEgc2VjdXJpdHkgdG9rZW4uIEluIG90 aGVyIHdvcmRzLCBhIHNvZnR3YXJlLW9ubHkgaW1wbGVtZW50YXRpb24gaXMgdW5hYmxlIHRvIHBy ZXZlbnQNCmNvbGx1c2lvbiBiZXR3ZWVuIHVzZXJzLiBBIGhhcmR3YXJlIHNvbHV0aW9uIHNpbXBs eSBwcm90ZWN0aW5nIHNvbWUgc2VjcmV0IGtleSBvciBzb21lIHByaXZhdGUga2V5IHdpbGwgYWxz byBiZSBpbmVmZmVjdGl2ZSwgc2luY2UNCm9uZSB1c2VyIHdvdWxkIGJlIGFibGUgdG8gcGVyZm9y bSBhbGwgdGhlIGNyeXB0b2dyYXBoaWMgY29tcHV0YXRpb25zIHRoYXQgdGhlIG90aGVyIHVzZXIg bmVlZHMuDQpOb3RlOiBQZW9wbGUgdGhhdCB3ZXJlIHByZXNlbnQgb24gSnVseSB0aGUgMTMgdGgg b24gdGhlIGZpcnN0IGRheSBvZiB0aGUgT0F1dGggd29ya3Nob3AgaW4gWsO8cmljaCBtYXkgdW5k ZXJzdGFuZCBiZXR0ZXIgd2hhdCBJIG1lYW4uDQpUaGUgdGV4dCBhbmQgdGhlIHNsaWRlcyBvZiB0 aGlzIHdvcmtzaG9wIHNob3VsZCBiZSBwdWJsaWNseSBhdmFpbGFibGUgc2hvcnRseS4NCg0KDQo5 LiBUaGlzIGRvY3VtZW50IGlzIGN1cnJlbnRseSB0YXJnZXRlZCB0byBiZWNvbWUgYSBTdGFuZGFy ZHMgVHJhY2sgZG9jdW1lbnQuDQoNClJGQyA2NDEwIHJlY29nbml6ZXMgdHdvIG1hdHVyaXR5IGxl dmVsczoNCg0KICAgLSB0aGUgRmlyc3QgTWF0dXJpdHkgTGV2ZWw6IFByb3Bvc2VkIFN0YW5kYXJk DQogICAtIHRoZSBTZWNvbmQgTWF0dXJpdHkgTGV2ZWw6IEludGVybmV0IFN0YW5kYXJkDQoNCkl0 IGlzIG5vdCBiZWxpZXZlZCB0aGF0IGN1cnJlbnRseSBpdCBpcyBwb3NzaWJsZSB0byBjb25zdHJ1 Y3QgdHdvIGluZGVwZW5kZW50IGludGVyb3BlcmF0aW5nIGltcGxlbWVudGF0aW9ucw0KbG9va2lu ZyBhdCB0aGlzIGRvY3VtZW50IG9ubHkuIFVubGVzcyBtb3JlIGd1aWRhbmNlIGlzIHByb3ZpZGVk LCB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB0YXJnZXRlZCB0byAiRXhwZXJpbWVudGFsIi4NCg0K SSBjb21wbGV0ZWx5IGRpc2FncmVlLiBBbmQgd291bGQgYWxzbyBub3RlIHRoYXQgdGhlIHRoZSBk b2N1bWVudCdzIGludGVuZGVkIHN0YXR1cyBoYXMgYmVlbiBzdGFibGUgYW5kIHVucXVlc3Rpb25l ZCBieSB0aGlzIFdHIGZvciBzZXZlcmFsIHllYXJzLg0KDQpTZWN0aW9uIDIuMSBmcm9tIFJGQyA2 NDEwIHN0YXRlczoNCiAgIFRoZSBzdGF0ZWQgcmVxdWlyZW1lbnRzIGZvciBQcm9wb3NlZCBTdGFu ZGFyZCBhcmUgbm90IGNoYW5nZWQ7IHRoZXkNCiAgIHJlbWFpbiBleGFjdGx5IGFzIHNwZWNpZmll ZCBpbiBSRkMgMjAyNiBbMV0uICBObyBuZXcgcmVxdWlyZW1lbnRzIGFyZQ0KICAgaW50cm9kdWNl ZDsgbm8gZXhpc3RpbmcgcHVibGlzaGVkIHJlcXVpcmVtZW50cyBhcmUgcmVsYXhlZC4NCg0KU2Vj dGlvbiA0LjEuMSBmcm9tIFJGQyAyMDI2IHN0YXRlczoNCg0KICAgQSBQcm9wb3NlZCBTdGFuZGFy ZCBzcGVjaWZpY2F0aW9uIGlzIGdlbmVyYWxseSBzdGFibGUsIGhhcyByZXNvbHZlZA0KICAga25v d24gZGVzaWduIGNob2ljZXMsIGlzIGJlbGlldmVkIHRvIGJlIHdlbGwtdW5kZXJzdG9vZCwgaGFz IHJlY2VpdmVkDQogICBzaWduaWZpY2FudCBjb21tdW5pdHkgcmV2aWV3LCBhbmQgYXBwZWFycyB0 byBlbmpveSBlbm91Z2ggY29tbXVuaXR5DQogICBpbnRlcmVzdCB0byBiZSBjb25zaWRlcmVkIHZh bHVhYmxlLg0KDQooLi4uKQ0KDQogICBBIFByb3Bvc2VkIFN0YW5kYXJkIHNob3VsZCBoYXZlIG5v IGtub3duIHRlY2huaWNhbCBvbWlzc2lvbnMgd2l0aA0KICAgcmVzcGVjdCB0byB0aGUgcmVxdWly ZW1lbnRzIHBsYWNlZCB1cG9uIGl0Lg0KDQpJIGRvbid0IGJlbGlldmUgdGhhdCB0aGUgY3VycmVu dCB0ZXh0IGNvbXBsaWVzIHdpdGggdGhlIHByZXZpb3VzIHN0YXRlbWVudHMuDQoNCk9uZSBvZiB0 aGUgZ29hbHMgb2YgdGhpcyBkb2N1bWVudCBpcyB0byBkZWZpbmUgYSBuZXcgcGFyYW1ldGVyIGNh bGxlZCAic3ViamVjdF90b2tlbiIuDQoNCkluIG9yZGVyIHRvIHVzZSBpdCwgd2UgbmVlZCB0byBz YXkgaG93IHRoZSBjbGllbnQsIHRoZSBBUyBhbmQgdGhlIFJQIHNoYWxsIGhhbmRsZSBpdC4NClRo ZSBjdXJyZW50IHRleHQgaXMgaW5zdWZmaWNpZW50IHRvIGtub3cgaG93IHRvIGhhbmRsZSBpdC4N Cg0KVW5sZXNzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQsIHRoaXMgZG9jdW1l bnQgc2hvdWxkIGJlIHRhcmdldGVkIHRvICJFeHBlcmltZW50YWwiLg0KDQoNCg0KDQoxMC4gVGV4 dCBwcm9wb3NhbCBmb3IgYSBuZXcgc2VjdGlvbiAiNy4gUHJpdmFjeSBDb25zaWRlcmF0aW9ucyIu DQoNCiAgIDcuIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCg0KICAgNy4xLiBSZXNvdXJjZSBhbmQg YXVkaWVuY2UgcGFyYW1ldGVycw0KDQogICBUaGUgdXNlIG9mIGFueSB0aGVzZSB0d28gcGFyYW1l dGVycyBhbGxvdyB0aGUgU1RTIHRvIGtub3cgd2hpY2gNCiAgIHRhcmdldCBzZXJ2ZXJzIGFyZSBi ZWluZyBhY2Nlc3NlZCBieSBhbnkgcGFydHkgbWFraW5nIGEgdG9rZW4NCiAgIHJlcXVlc3QuICBB bnkgU1RTIGlzIHRoZW4gYWJsZSB0byBsb2cgdG9rZW4gcmVxdWVzdHMuICBUaGlzIGlzIG5vdA0K ICAgYSBwcm9ibGVtIGlmIHRoZSByZXNvdXJjZSBvd25lciBhbmQgdGhlIHRhcmdldCBzZXJ2ZXIg YXJlIGNvbGxvY2F0ZWQsDQogICBidXQgdGhpcyBkb2N1bWVudCBpcyBub3QgcmVzdHJpY3RlZCB0 byB0aGF0IGNhc2UuDQoNCiAgIEZvciB0aGUgb3RoZXIgY2FzZXMsIGl0IHNob3VsZCBiZSBub3Rp Y2VkIHRoYXQgdGhlIFNUUyB3aWxsIGJlIGluDQogICBwb3NpdGlvbiB0byBhY3QgYXMgQmlnIEJy b3RoZXIuICBXaGVuIHByaXZhY3kgaXMgYSBjb25jZXJuLCB0aGUgdXNlDQogICBvZiB0aGVzZSBw YXJhbWV0ZXJzIGlzIGRlcHJlY2F0ZWQgYW5kIHRoZSB1c2Ugb2YgYSAidGlkIiBwYXJhbWV0ZXIN CiAgIGlzIHJlY29tbWVuZGVkLg0KDQpJIHdpbGwgYWRkIGEgcHJpdmFjeSBjb25zaWRlcmF0aW9u cyB3aXRoIG1lbnRpb24gb2YgYmVpbmcgYWJsZSB0byB0cmFjayB0aGUgdGFyZ2V0IHN5c3RlbXMg aW50ZW5kZWQgdG8gYmUgYWNjZXNzZWQgYnkgdGhlIHBhcnR5IHJlcXVlc3RpbmcgYSB0b2tlbi4N Cg0KDQpUaGUgcHJpdmFjeSBzZWN0aW9uIHRoYXQgaGFzIGJlZW4gYWRkZWQgaXMgdGhlIGZvbGxv d2luZzoNClByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCg0KVG9rZW5zIHR5cGljYWxseSBjYXJyeSBw ZXJzb25hbCBpbmZvcm1hdGlvbiBhbmQgdGhlaXIgdXNhZ2UgaW4gVG9rZW4NCkV4Y2hhbmdlIG1h eSByZXZlYWwgZGV0YWlscyBvZiB0aGUgdGFyZ2V0IHNlcnZpY2VzIGJlaW5nIGFjY2Vzc2VkLg0K QXMgc3VjaCwgdG9rZW5zIHNob3VsZCBvbmx5IGJlIHJlcXVlc3RlZCBhbmQgc2VudCBhY2NvcmRp bmcgdG8gdGhlDQpwcml2YWN5IHBvbGljaWVzIGF0IHRoZSByZXNwZWN0aXZlIG9yZ2FuaXphdGlv bnMuDQoNCkl0IGRvZXMgbm90IGFkZHJlc3MgbXkgY29uY2Vybi4gSGVyZWFmdGVyIGlzIGEgbmV3 IHRleHQgcHJvcG9zYWwgdG8gYWRkcmVzcyBteSBjb25jZXJuLCAuLi4gaWYgd2UgZm9sbG93IG9w dGlvbiBiKSBhcyBtZW50aW9uZWQgYmVmb3JlaGFuZC46DQoNCiAgIDcuIFByaXZhY3kgQ29uc2lk ZXJhdGlvbnMNCg0KICAgNy4xLiBSZXNvdXJjZSBhbmQgYXVkaWVuY2UgcGFyYW1ldGVycw0KDQog ICBUaGUgdXNlIG9mIHRoZSByZXNvdXJjZSBvciBvZiB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGFs bG93cyB0aGUgU1RTIHRvIGtub3cgd2hpY2ggdGFyZ2V0IHNlcnZlcnMgYXJlIGJlaW5nIGFjY2Vz c2VkDQogICBieSBhbnkgcGFydHkgbWFraW5nIGEgdG9rZW4gcmVxdWVzdC4gIEFueSBTVFMgd2ls bCB0aGVuIGJlIGFibGUgdG8gbG9nIHRva2VuIHJlcXVlc3RzLiBUaGlzIGlzIG5vdCBhIHByb2Js ZW0gYXMgbG9uZyBhcw0KICAgdGhlIHJlc291cmNlIG93bmVyIGFuZCB0aGUgdGFyZ2V0IHNlcnZl ciBhcmUgY29sbG9jYXRlZCwgYnV0IHRoaXMgZG9jdW1lbnQgaXMgbm90IHJlc3RyaWN0ZWQgdG8g dGhpcyBjYXNlLg0KDQogICBGb3IgdGhlIG90aGVyIGNhc2VzLCBpZiBlaXRoZXIgdGhlIHJlc291 cmNlIHBhcmFtZXRlciBvciB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIGlzIGJlaW5nIHVzZWQsIHRo ZSBTVFMgd2lsbCBiZSBpbiBwb3NpdGlvbg0KICAgdG8gYWN0IGFzIEJpZyBCcm90aGVyLiBXaGVu IHByaXZhY3kgaXMgYSBjb25jZXJuLCB0aGUgdXNlIG9mIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIg YW5kIG9mIHRoZSBhdWRpZW5jZSBwYXJhbWV0ZXIgaXMgZGVwcmVjYXRlZA0KICAgYW5kIGFub3Ro ZXIgcGFyYW1ldGVyIHNob3VsZCBiZSB1c2VkIHRvIHJlc3RyaWN0IHRoZSB0YXJnZXQgc2VydmVy cyB0aGF0IGNhbiB1c2UgdGhlIHNlY3VyaXR5IHRva2VuLiBBdCB0aGUgdGltZSBvZiB0aGUgaXNz dWFuY2UNCiAgIG9mIHRoaXMgZG9jdW1lbnQsIHN1Y2ggYSBwYXJhbWV0ZXIgd2FzIG5vdCB5ZXQg ZGVmaW5lZCBpbiBhbm90aGVyIFJGQy4NCg0KDQogICA3LjIuIFVzZSBvZiBSRkMgNzY2MiAoT0F1 dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb24pDQoNCiAgIFJGQzc2NjIgZGVmaW5lcyBhIHByb3Rv Y29sIHRoYXQgYWxsb3dzIGF1dGhvcml6ZWQgcHJvdGVjdGVkIHJlc291cmNlcyB0byBxdWVyeSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gZGV0ZXJtaW5lIHRoZSBzZXQgb2YgbWV0YWRhdGEN CiAgIGZvciBhIGdpdmVuIHRva2VuIHRoYXQgd2FzIHByZXNlbnRlZCB0byB0aGVtIGJ5IGFuIE9B dXRoIDIuMCBjbGllbnQuDQoNCiAgIFRoZSB1c2Ugb2YgdGhpcyBwcm90b2NvbCByYWlzZXMgc29t ZSBwcml2YWN5IGNvbmNlcm5zLCBzaW5jZSB0aGUgU1RTIGlzIHRoZW4gYWJsZSB0byBpZGVudGlm eSB0aGUgY2xpZW50cyBhY2Nlc3NpbmcgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQuDQogICBU aGlzIGNvbmNlcm4gd2lsbCByZW1haW4gZXZlbiB3aGVuIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIg b3IgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciB3aWxsIG5vdCBiZSB1c2VkLiBTdWNoIHBhcmFtZXRl cnMgbWlnaHQgYmUgaW4gdGhlIGZ1dHVyZQ0KICAgcmVwbGFjZWQgYnkgYW5vdGhlciBtZWFucyB0 byByZXN0cmljdCB0aGUgdXNlIG9mIHRoZSBzZWN1cml0eSB0b2tlbnMgdG8gc3BlY2lmaWMgcmVz b3VyY2Ugc2VydmVycywgYnV0IGEgY2FsbCBiYWNrIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB3b3VsZA0KICAgcnVpbiB0aGUgYmVuZWZpdHMgb2YgdGhlIHVzZSBvZiB0aGlzIGFsdGVybmF0 aXZlIG1lYW5zLg0KDQoNCkRlbmlzDQoNCg0KDQoNCg0KDQpEZW5pcw0KQWxsLA0KDQpXZSBhcmUg c3RhcnRpbmcgYSBXR0xDIG9uIHRoZSBUb2tlbiBFeGNoYW5nZSBkb2N1bWVudDoNCmh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDgNCg0KUGxl YXNlLCByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwcm92aWRlIGZlZWRiYWNrIG9uIGFueSBpc3N1 ZXMgeW91IHNlZSB3aXRoIHRoZSBkb2N1bWVudC4NCg0KVGhlIFdHTEMgd2lsbCBlbmQgaW4gdHdv IHdlZWtzLCBvbiBKdW5lIDE3LCAyMDE3Lg0KDQpSZWdhcmRzLA0KIFJpZmFhdCBhbmQgSGFubmVz DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KQ09ORklERU5USUFM SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQoNCg0KDQpDT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku IEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_CY4PR21MB0504049471CEBAC95962E60FF5A30CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHdpdGggeW91LCBCcmlhbiwgdGhhdCBpbmNvcnBvcmF0 aW5nIHRoZSBwcm9wb3NlZCBjaGFuZ2VzIHdvdWxkIG5vdCBmdXJ0aGVyIHRoZSBnb2FscyBvZiB0 aGUgZG9jdW1lbnQuJm5ic3A7IFJhdGhlciwgdGhleSB3b3VsZCBkZXRyYWN0IGZyb20gYWNoaWV2 aW5nIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBKdWx5IDE2LCAyMDE3IDc6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IERlbmlz ICZsdDtkZW5pcy5pZXRmQGZyZWUuZnImZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1 dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdHTEMg Zm9yIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDg8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNwZWFraW5n IGFzIGFuIGluZGl2aWR1YWwsIGZvciBhIG51bWJlciBvZiByZWFzb25zLCBJIGRvIG5vdCBiZWxp ZXZlIHRoYXQgYW55IG9mIHRoZSBhZGRpdGlvbmFsIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIHNo b3VsZCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZG9jdW1lbnQuJm5ic3A7DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSBkb2N1bWVudCBlZGl0b3Ig d29ya2luZyB3aXRoaW4gdGhlIElFVEYgcHJvY2Vzc2VzLCBteSBhaW0gaXMgZm9yIHRoZSBkb2N1 bWVudCB0byByZWZsZWN0IHRoZSAocm91Z2gpIGNvbnNlbnN1cyBvZiB0aGlzIFdvcmtpbmcgR3Jv dXAuIEFuZCBJIGRvbid0IGdldCB0aGUgc2Vuc2UgdGhhdCB0aGVyZSdzIHN1cHBvcnQsIGxldCBh bG9uZSBjb25zZW5zdXMsIGZvciBhbnkgb2YgdGhlc2UgY2hhbmdlcy4gSG93ZXZlciwNCiByYXRo ZXIgdGhhbiByZWx5aW5nIG9uIG15IGludGVycHJldGF0aW9uIG9mIHN1cHBvcnQgb3IgbGFjayB0 aGVyZW9mIGZyb20gdGhlIFdHLCBJJ2xsIGFzayBtb3JlIGV4cGxpY2l0bHkgLSBhcmUgdGhlcmUg b3RoZXIgV0cgcmVtZW1iZXJzIHdobyBhcmUgaW4gZmF2b3Igb2Ygd29ya2luZyB0byBpbmNvcnBv cmF0ZSBhbnkgb2YgdGhlc2UgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnM/DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgSnVsIDE2LCAyMDE3IGF0 IDg6MzggQU0sIERlbmlzICZsdDs8YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiB0 YXJnZXQ9Il9ibGFuayI+ZGVuaXMuaWV0ZkBmcmVlLmZyPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlbGxvIEJyaWFuLDxicj4NCjxicj4NCkl0IHRv b2sgMjUgZGF5cyB0byBnZXQgYSByZXNwb25zZSB0byBteSBXR0xDIGNvbW1lbnRzIGFuZCBpdCB0 b29rIG1lIDEzIGRheXMgdG8gYW5zd2VyIHRvIHlvdXIgcmVwbHkuPGJyPg0KPGJyPg0KTXkgcmVz cG9uc2VzIGFyZSBlbWJlZGRlZCBpbiB0aGUgdGV4dC4gQXQgcHJlc2VudCwgSSBvbmx5IGFncmVl IHdpdGggdGhlIHJlc29sdXRpb24gb2YgdGhlIGNvbW1lbnQgbnVtYmVyZWQgNi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0 aGUgcmV2aWV3LCBEZW5pcy4gQW5kIEkgYXBvbG9naXplIGZvciB0aGUgc2xvdyByZXBseSAtIEkn dmUgaGFkIGEgbG90IG9mIGRpZmZlcmVudCB0aGluZ3Mgb24gbXkgcGxhdGUgcmVjZW50bHkuIEFu ZCwgcXVpdGUgZnJhbmtseSwgSSB3YXMgc29ydCBvZiBob3Bpbmcgb25lIG9mIHRoZSBjby1hdXRo b3JzIG9uIHRoZSBkb2N1bWVudCBtaWdodCByZXNwb25kIHRvIHlvdXIgY29tbWVudHMuIEJ1dA0K IGhvcGUgb25seSBnb2VzIHNvIGZhci4gU28gcmVwbGllcyBhcmUgaW5saW5lIGJlbG93Li4uPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gNSwgMjAxNyBh dCA1OjMwIEFNLCBEZW5pcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlbmlzLmlldGZAZnJlZS5mciIg dGFyZ2V0PSJfYmxhbmsiPmRlbmlzLmlldGZAZnJlZS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q29tbWVudHMgb24gT0F1dGggMi4wIFRva2VuIEV4Y2hhbmdlIGRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UtMDg8YnI+DQo8YnI+DQoxLiBUaGUgYWJzdHJhY3Qgc3RhdGVzOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJnF1b3Q7VGhpcyBz cGVjaWZpY2F0aW9uIGRlZmluZXMgYSBwcm90b2NvbCBmb3IgYW4gSFRUUC0gYW5kIEpTT04tIGJh c2VkPGJyPg0KJm5ic3A7Jm5ic3A7IFNlY3VyaXR5IFRva2VuIFNlcnZpY2UgKFNUUykgYnkgZGVm aW5pbmcgaG93IHRvIHJlcXVlc3QgYW5kIG9idGFpbjxicj4NCiZuYnNwOyZuYnNwOyBzZWN1cml0 eSB0b2tlbnMgZnJvbSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLCBpbmNsdWRpbmc8 YnI+DQombmJzcDsmbmJzcDsgc2VjdXJpdHkgdG9rZW5zIGVtcGxveWluZyBpbXBlcnNvbmF0aW9u IGFuZCBkZWxlZ2F0aW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgY29udGVudCBvZiB0aGUg YWJzdHJhY3QgZG9lcyBub3QgbWF0Y2ggd2l0aCB0aGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQu PGJyPg0KPGJyPg0KVGhlIGFic3RyYWN0IGNsZWFybHkgc3RhdGVzIHRoYXQgYWxsIGNhc2VzIG9m IHRva2VuIHJlcXVlc3RzIGFyZSBzdXBwb3J0ZWQsIHdoZXJlYXMgdGhlIGRvY3VtZW50IG1hbmRh dGVzDQo8YnI+DQp0aGUgdXNlIG9mIGEgc3ViamVjdF90b2tlbiBwYXJhbWV0ZXIgd2hpY2ggcmVz dHJpY3RzIHRoZSBzY29wZSB0byBpbXBlcnNvbmF0aW9uIGFuZCBkZWxlZ2F0aW9uLjxicj4NCjxi cj4NCkN1cnJlbnRseSB0aGUgdGV4dCBzdGF0ZXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7ICZx dW90O3N1YmplY3RfdG9rZW48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGI+ UkVRVUlSRUQ8L2I+LiZuYnNwOyBBIHNlY3VyaXR5IHRva2VuIHRoYXQgcmVwcmVzZW50cyB0aGUg aWRlbnRpdHkgb2YgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcnR5 IG9uIGJlaGFsZiBvZiB3aG9tIHRoZSByZXF1ZXN0IGlzIGJlaW5nIG1hZGUuJm5ic3A7IFR5cGlj YWxseSwgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1YmplY3Qgb2Yg dGhpcyB0b2tlbiB3aWxsIGJlIHRoZSBzdWJqZWN0IG9mIHRoZSBzZWN1cml0eSB0b2tlbjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpc3N1ZWQgaW4gcmVzcG9uc2UgdG8gdGhp cyByZXF1ZXN0JnF1b3Q7Ljxicj4NCjxicj4NClRoZSBhYnN0cmFjdCBzaG91bGQgYmUgY2hhbmdl ZCB0byByZWZsZWN0IHRoZSBjb250ZW50IG9mIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZG9uJ3Qgc2VlIGEgZGlzY3JlcGFu Y3kgYmV0d2VlbiB0aGUgY29udGVudCBvZiB0aGUgYWJzdHJhY3QgYW5kIHRoZSBjb250ZW50IG9m IHRoZSBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hhdCB0ZXh0IG9yIGNoYW5nZXMgd291bGQgeW91IHN1Z2dlc3QgaW4gdGhl IGFic3RyYWN0PyA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0Oi41aW47bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NDAuOHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtUaGlzIHNwZWNpZmlj YXRpb24gZGVmaW5lcyBhIHByb3RvY29sIGZvciBhbiBIVFRQLSBhbmQgSlNPTi0gYmFzZWQ8YnI+ DQpTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIChTVFMpIGJ5IGRlZmluaW5nIGhvdyB0byByZXF1ZXN0 IGFuZCBvYnRhaW48YnI+DQpzZWN1cml0eSB0b2tlbnMgZnJvbSBPQXV0aCAyLjAgYXV0aG9yaXph dGlvbiBzZXJ2ZXJzIHdoZW4gYSBzcGVjaWZpYyBwYXJhbWV0ZXIgPGJyPg0KaXMgcmVxdWlyZWQg dG8gaWRlbnRpZnkgdGhlIHBhcnR5IG9uIGJlaGFsZiBvZiB3aG9tIHRoZSByZXF1ZXN0IGlzIGJl aW5nIG1hZGUmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDouNWluO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Ib3dldmVyLCBwbGVhc2UgcmVhZCB0aGUgb3RoZXIgY29tbWVudHMsIHNpbmNlIEkgYW0gbm90 IHN1cmUgdGhhdCB0aGlzIGNoYW5nZSB3aWxsIGJlIHN1ZmZpY2llbnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KMi4gVGhlIHRleHQgc3RhdGVzIG9uIHBhZ2Ug NDo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZx dW90O1RoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gaXMgbGltaXRlZCB0byB0aGUgZGVm aW5pdGlvbiBvZiBhPGJyPg0KJm5ic3A7Jm5ic3A7IGJhc2ljIHJlcXVlc3QgYW5kIHJlc3BvbnNl IHByb3RvY29sIGZvciBhbiBTVFMtc3R5bGUgdG9rZW4gZXhjaGFuZ2U8YnI+DQombmJzcDsmbmJz cDsgdXRpbGl6aW5nIE9BdXRoIDIuMC4mbmJzcDsgQWx0aG91Z2ggYSBmZXcgbmV3IEpXVCBjbGFp bXMgYXJlIGRlZmluZWQgdGhhdDxicj4NCiZuYnNwOyZuYnNwOyBlbmFibGUgZGVsZWdhdGlvbiBz ZW1hbnRpY3MgdG8gYmUgZXhwcmVzc2VkLCB0aGUgc3BlY2lmaWMgc3ludGF4LDxicj4NCiZuYnNw OyZuYnNwOyBzZW1hbnRpY3MgYW5kIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgdG9r ZW5zIHRoZW1zZWx2ZXMgKGJvdGg8YnI+DQombmJzcDsmbmJzcDsgdGhvc2UgcHJlc2VudGVkIHRv IHRoZSBBUyBhbmQgdGhvc2Ugb2J0YWluZWQgYnkgdGhlIGNsaWVudCkgYXJlPGJyPg0KJm5ic3A7 Jm5ic3A7IGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlIGFuZCBubyByZXF1aXJlbWVudHMgYXJlIHBs YWNlZCBvbiB0aGUgdHJ1c3Q8YnI+DQombmJzcDsmbmJzcDsgbW9kZWwgaW4gd2hpY2ggYW4gaW1w bGVtZW50YXRpb24gbWlnaHQgYmUgZGVwbG95ZWQmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBzdGF0ZW1lbnRzIGFyZSBjb250 cmFkaWN0b3J5LiBPbmUgcGFyYW1ldGVyIG9mIHRoZSByZXF1ZXN0IGlzIG1hbmRhdG9yeSAoaS5l LiBzdWJqZWN0X3Rva2VuKQ0KPGJyPg0KYnV0IHRoZXJlIGlzIG5vIGluZGljYXRpb24gb2YgdGhl IGtpbmQgb2YgdHJlYXRtZW50IHdoaWNoIHNob3VsZCBiZSBkb25lIHdpdGggdGhpcyBwYXJhbWV0 ZXIgc28gdGhhdDxicj4NCml0IHdpbGwgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uIG9uZSB3 YXkgb3IgYW5vdGhlciBpbiB0aGUgdG9rZW4gdGhhdCB3aWxsIGJlIGlzc3VlZC4NCjxicj4NCjxi cj4NClRoaXMgZG9jdW1lbnQgYnkgaXRzZWxmIHdvdWxkIGJlIGluc3VmZmljaWVudCB0byBhbGxv dyBhbnkga2luZCBvZiBpbnRlcm9wZXJhYmlsaXR5Lg0KPGJyPg0KQ29uZm9ybWFuY2UgdG8gdGhp cyBkb2N1bWVudCB3b3VsZCBub3QgbWVhbiBhbnl0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpUaGUgdG9rZW4gZXhjaGFuZ2UgZnJhbWV3 b3JrIHByb21vdGVzIGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIGZvcm0gb2YgY29tbW9uIHBhdHRl cm5zIGFuZCBwYXJhbWV0ZXJzIHRoYXQgY2FuIGJlIHN1cHBvcnRlZCBpbiBsaWJyYXJpZXMsIHBy b2R1Y3RzLCBhbmQgc2VydmljZXMuIEl0IGZhY2lsaXRhdGVzIGRlcGxveW1lbnRzIGxpa2UgdGhp cyBvbmUNCjxhIGhyZWY9Imh0dHBzOi8vaGVscC5zYWxlc2ZvcmNlLmNvbS9hcnRpY2xlVmlldz9p ZD1yZW1vdGVhY2Nlc3Nfb2F1dGhfYXNzZXRfdG9rZW5fZmxvdy5odG0iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vaGVscC5zYWxlc2ZvcmNlLmNvbS9hcnRpY2xlVmlldz9pZD1yZW1vdGVhY2Nl c3Nfb2F1dGhfYXNzZXRfdG9rZW5fZmxvdy5odG08L2E+IG9yIHRoaXMgb25lDQo8YSBocmVmPSJo dHRwczovL2RldmVsb3Blci5ib3guY29tL2RvY3MvZ2V0dGluZy1zdGFydGVkLXdpdGgtbmV3LWJv eC12aWV3IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RldmVsb3Blci5ib3guY29tL2RvY3Mv Z2V0dGluZy1zdGFydGVkLXdpdGgtbmV3LWJveC12aWV3PC9hPiwgZm9yIGV4YW1wbGUuDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjQuOHB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5UaGlzIGlzIG5vdCBhbiBhZGVxdWF0ZSByZXNwb25zZSB0byBteSBjb21tZW50LiBUZXh0IGlz IGN1cnJlbnRseSBtaXNzaW5nIHRvIGV4cGxhaW4NCjxicj4NCndoYXQga2luZCBvZiB0cmVhdG1l bnQgc2hvdWxkIGJlIGRvbmUgd2l0aCB0aGlzIHBhcmFtZXRlci48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NC44cHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO1doYXQg c2hvdWxkIHRoZSBTVFMgZG8gd2l0aCB0aGlzIHBhcmFtZXRlciB3aGVuIGl0IHJlY2VpdmVzIGl0 ID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NC44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwO0hvdywgdGhpcyBwYXJhbWV0ZXIgc2hvdWxkIGJlIHByb2Nlc3NlZCBz byB0aGF0IGl0IGNhbiBiZSBwbGFjZWQgaW4gYSBzZWN1cml0eSB0b2tlbiA/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjQuOHB0Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDtJcyB0aGVyZSBhIHJlbGF0aW9uc2hpcCAoaWYgYW55KSBiZXR3ZWVuIHRoZSAmcXVvdDtzdWJq ZWN0X3Rva2VuJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7Y2lkJnF1b3Q7IChDbGllbnQgSWRlbnRpZmll cikNCjxicj4NCiZuYnNwO3RoYXQgd2lsbCBiZSBwbGFjZWQgaW4gdGhlIHNlY3VyaXR5IHRva2Vu ID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NC44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwO1doeSBzaGFsbCBhIHNlY3VyaXR5X3Rva2VuIGJlIHVzZWQgaW5zdGVh ZCBvZiBzaW1wbHkgYW4gaWRlbnRpZmllciBvZiB0aGUgT0F1dGggMi4wIGNsaWVudA0KPGJyPg0K Jm5ic3A7dGhhdCByZXF1ZXN0ZWQgdGhlIHRva2VuID88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NC44cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO1RoZSBjdXJyZW50 IGRyYWZ0IGNhbm5vdCBiZSB1bmRlcnN0b29kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjMuIE9uIHBhZ2UgNywgdGhlIHRleHQgc3RhdGVzOjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDtzdWJqZWN0X3Rva2VuPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJFUVVJUkVELiZuYnNwOyBBIHNlY3VyaXR5IHRva2VuIHRoYXQg cmVwcmVzZW50cyB0aGUgaWRlbnRpdHkgb2YgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBhcnR5IG9uIGJlaGFsZiBvZiB3aG9tIHRoZSByZXF1ZXN0IGlzIGJlaW5nIG1h ZGUmcXVvdDsuPGJyPg0KPGJyPg0KSXQgaXMgdW5kZXJzdG9vZCB0aGF0IG9uZSBpbXBsZW1lbnRh dGlvbiBpcyBhbHJlYWR5IHVzaW5nIHRoaXMgcGFyYW1ldGVyIHRvIHBsYWNlIGluIGl0IGEgc2Vj dXJpdHkgdG9rZW4uDQo8YnI+DQpTaW5jZSB0aGlzIHBhcmFtZXRlciBpcyBpbmRpY2F0ZWQgYXMg UkVRVUlSRUQsIGl0IGlzIG5vdCB1bmRlcnN0YW5kYWJsZSB3aHkgYSBzZWN1cml0eSB0b2tlbiBz aGFsbCBuZWNlc3NhcmlseSBiZSB1c2VkLg0KPGJyPg0KVGhlcmUgYXJlIG90aGVyIG1lYW5zIGZv ciB0aGUgU1RTIHRvIGlkZW50aWZ5IHRoZSAmcXVvdDtwYXJ0eSBvbiBiZWhhbGYgb2Ygd2hvbSB0 aGUgcmVxdWVzdCBpcyBiZWluZyBtYWRlJnF1b3Q7Ljxicj4NCjxicj4NClBsZWFzZSBhZGQgYSBy YXRpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCBraW5k IG9mIHJhdGlvbmFsIHlvdSBhcmUgbG9va2luZyBmb3IgaGVyZS4gQ2FuIHlvdSBzdWdnZXN0IHNv bWUgc3BlY2lmaWMgdGV4dCBmb3IgdGhlIGRvY3VtZW50IHRoYXQgd291bGQgYWRkcmVzcyB0aGUg Y29uY2VybiB5b3UgaGF2ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JbiBvcmRlciB0byBpZGVudGlmeSAmcXVv dDt0aGUgcGFydHkgb24gYmVoYWxmIG9mIHdob20gdGhlIHJlcXVlc3QgaXMgYmVpbmcgbWFkZSZx dW90OywgdGhlcmUgaXMgbm8gbmVlZCB0byB1c2UgYSBzZWN1cml0eSB0b2tlbi4NCjxicj4NClRo ZSB0ZXh0IGRvZXMgbm90IGV4cGxhaW4gdGhlIGJlbmVmaXRzLCBpZiBhbnksIG9mIHVzaW5nIGEg c2VjdXJpdHkgdG9rZW4uIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+SXQgZG9lcyBub3QgZXhwbGFpbiBlaXRoZXIgdGhlIGRyYXdiYWNrcywgaS5lLiB0aGUg Y29tcGxleGl0eSBmb3IgdXNpbmcgaXQsIGluIHBhcnRpY3VsYXIsIGhvdyBhIHJlbHlpbmcgcGFy dHkgY2FuIHZlcmlmeQ0KPGJyPg0KdGhhdCB0aGUgc2VjdXJpdHkgdG9rZW4gaXMgcHJvdGVjdGVk IGJ5IHRoZSByaWdodCBrZXkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPldoYXQga2luZCBvZiB0cnVzdCByZWxhdGlvbnNoaXBzIHdvdWxkIG5lZWQgdG8gYmUg cHJlLWVzdGFibGlzaGVkIGlzIG5vdCBleHBsYWluZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+SSBiZWxpZXZlIHRoYXQgdXNpbmcgYSBzZWN1cml0eSB0b2tl biB0byByZXByZXNlbnQgdGhlIGlkZW50aXR5IG9mIHRoZSBwYXJ0eSBvbiBiZWhhbGYgb2Ygd2hv bSB0aGUgcmVxdWVzdCBpcyBiZWluZyBtYWRlDQo8YnI+DQphZGRzIGFuIGV4dHJhIGxldmVsIG9m IGNvbXBsZXhpdHkgYW5kIGZvciB0aGF0IHJlYXNvbiBhIHNlY3VyaXR5IHRva2VuIHNob3VsZCBO T1QgYmUgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5J ZiB5b3UgYmVsaWV2ZSB0aGF0IGl0IHNob3VsZCwgdGhlbiB5b3UgaGF2ZSB0byBleHBsYWluIHRo ZSB0cnVzdCByZWxhdGlvbnNoaXBzLCB0aGUgYmVuZWZpdHMgYW5kIHRoZSB3YXkgdG8gaGFuZGxl IHRoaXMgcGFyYW1ldGVyDQo8YnI+DQphcyBpdCBpcyBjdXJyZW50bHkgbm90IHRoZSBjYXNlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJbiBhZGRpdGlvbiwgd2hhdCB0aGUg U1RTIHdpbGwgZG8sIGNhbiBkbyBvciBzaG91bGQgZG8gd2l0aCB0aGlzIHBhcmFtZXRlciBpcyBs ZWZ0IHVuZGVmaW5lZC48YnI+DQo8YnI+DQo8YnI+DQo0LiBPbiBwYWdlIDcsIHRoZSB0ZXh0IHN0 YXRlczo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7c3ViamVjdF90b2tlbjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSRVFVSVJFRC4mbmJzcDsgKC4uLikmbmJzcDsg VHlwaWNhbGx5LCB0aGUgc3ViamVjdCBvZiB0aGlzIHRva2VuIHdpbGwgYmUgPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBzdWJqZWN0IG9mIHRoZSBzZWN1cml0eSB0b2tl biBpc3N1ZWQgaW4gcmVzcG9uc2UgdG8gdGhpcyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVxdWVzdCZxdW90Oy48YnI+DQo8YnI+DQpUaGlzIHNlbnRlbmNlIGlzIHF1aXRl IGhhcmQgdG8gdW5kZXJzdGFuZCBzaW5jZSB0aGUgc3BlY2lmaWMgc3ludGF4LCBzZW1hbnRpY3Mg YW5kIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgdG9rZW5zIHRoZW1zZWx2ZXMNCjxi cj4NCmFyZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZS4gVGhlIGtleSBwb2ludCBpcyB3aGF0IHRo ZSBTVFMgc2hvdWxkIGRvIHdpdGggdGhpcyBwYXJhbWV0ZXI6IHRoaXMgaXMgbGVmdCB1bmRlZmlu ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGRv bid0IHZpZXcgdGhlIHNlbnRlbmNlIGFzIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kLiZuYnNwOyBN YXliZSB0aGF0J3MgYmVjYXVzZSBJIHdyb3RlIGl0PyZuYnNwOyBCdXQgaXQgaXMgdHJ1ZSB0aGF0 IHR5cGljYWxseSBpdCBpcyB0aGUgY2FzZSB0aGF0IHRoZSBzdWJqZWN0IG9mIHRoZSBpbmJvdW5k IHRva2VuIHdpbGwgYmUgdGhlIHN1YmplY3Qgb2YgdGhlIGlzc3VlZCB0b2tlbi4NCiBJIGRvbid0 IGtub3cgaG93IGVsc2UgdG8gc2F5IGl0LiBQbGVhc2Ugb2ZmZXIgc3VnZ2VzdGVkIHRleHQsIGlm IHlvdSBiZWxpZXZlIHRoZXJlJ3MgYSB3YXkgdG8gc2F5IGl0IHRoYXQgaXMgZWFzaWVyIHRvIHVu ZGVyc3RhbmQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkNvdWxkIHdlIGRlZmlu ZWQgdGhpcyBwYXJhbWV0ZXIgaW4gdGhlIGZvbGxvd2luZyB3YXkgPzwvc3Bhbj4gPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5zdWJqZWN0X3Rva2VuPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJFUVVJUkVELiZuYnNwOyBBbiBpZGVudGlmaWVyIG9mIHRo ZSBwYXJ0eSBvbiBiZWhhbGYgb2Ygd2hvbSB0aGUgcmVxdWVzdCBpcyBiZWluZyBtYWRlICguLi4p Jm5ic3A7DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcyBpZGVudGlmaWVyIHdpbGwgYmUgY29waWVkIGFuZCBwYXN0ZWQgaW50byB0aGUg c2VjdXJpdHkgdG9rZW4gaXNzdWVkIGluIHJlc3BvbnNlIHRvIHRoaXMgcmVxdWVzdA0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGRlc2ln bmF0ZSB0aGUgY2xhaW1lZCBob2xkZXIgb2YgdGhlIGlzc3VlZCBzZWN1cml0eSB0b2tlbiBkZXNp Z25hdGVkIGFzIHRoZSAmcXVvdDtjaWQmcXVvdDsgKENsaWVudCBJZGVudGlmaWVyKSBjbGFpbSBp biBSRkMgNjc0OS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KNS4gVGhlIHRl eHQgc3RhdGVzOiA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7ICZxdW90OyAoLi4uKSBBZGRpdGlvbmFsPGJyPg0KJm5ic3A7Jm5ic3A7IHByb2ZpbGVz IG1heSBwcm92aWRlIG1vcmUgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIGFyb3VuZCB0aGUgc3BlY2lm aWM8YnI+DQombmJzcDsmbmJzcDsgbmF0dXJlIG9mIHRoZSBwYXJ0aWVzIGFuZCB0cnVzdCBpbnZv bHZlZCwgc3VjaCBhcyB3aGV0aGVyIHNpZ25pbmc8YnI+DQombmJzcDsmbmJzcDsgYW5kL29yIGVu Y3J5cHRpb24gb2YgdG9rZW5zIGlzIG5lZWRlZCBvciBpZiBwcm9vZi1vZi1wb3NzZXNzaW9uIHN0 eWxlPGJyPg0KJm5ic3A7Jm5ic3A7IHRva2VucyB3aWxsIGJlIHJlcXVpcmVkIG9yIGlzc3VlZDsg PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2tl bnMgYXJlIGFsd2F5cyBzaWduZWQuIFBsZWFzZSBtb2RpZnkgdGhlIHNlbnRlbmNlIGFjY29yZGlu Z2x5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgdG9rZW4gbWlnaHQgd2VsbCBiZSBjcnlwdG9ncmFw aGljYWxseSBzZWN1cmUgcmFuZG9tIHNlcXVlbmNlIG9mIGNoYXJhY3RlcnMgdGhhdCByZWZlcmVu Y2UgZGF0YSB0aGF0IGNhbiBiZSBsb29rZWQgdXAgYnkgdGhlIGFwcHJvcHJpYXRlIHBhcnRpZXMu IE9yIGEgdG9rZW4gbWlnaHQgYmUgYW4gQUVBRCBzeW1tZXRyaWNhbGx5IGVuY3J5cHRlZCBKV1Qu IFNvIG5vLCB0b2tlbnMgYXJlIG5vdCBhbHdheXMgc2lnbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkIHdlIHJl cGhyYXNlIGluIHRoZSBmb2xsb3dpbmcgd2F5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmcXVvdDsgKC4uLikgQWRkaXRpb25hbCBwcm9m aWxlcyBtYXkgcHJvdmlkZSBtb3JlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBhcm91bmQgdGhlIHNw ZWNpZmljIG5hdHVyZSBvZiB0aGUgcGFydGllcyBhbmQgdHJ1c3QgaW52b2x2ZWQsDQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VjaCBhcyBob3cgaW50ZWdyaXR5IHByb3RlY3Rpb24g b2YgdGhlIHRva2VucyBzaGFsbCBiZSBkb25lIGFuZCBpZiBwcm9vZi1vZi1wb3NzZXNzaW9uIHN0 eWxlIHRva2VucyB3aWxsIGJlIHJlcXVpcmVkIG9yIGlzc3VlZDsNCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjYuIFRo ZSBmb2xsb3dpbmcgc2VudGVuY2UgaXMgaW1wb3J0YW50IGFuZCBpcyBiZWluZyBub3RpY2VkLjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyBUaGUgc2VjdXJpdHkgdG9rZW5zIG9idGFpbmVkIGNvdWxk IGJlIHVzZWQgaW4gYSBudW1iZXIgb2YgY29udGV4dHMsPGJyPg0KJm5ic3A7Jm5ic3A7IHRoZSBz cGVjaWZpY3Mgb2Ygd2hpY2ggYXJlIGFsc28gYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzPGJyPg0K Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24uPGJyPg0KPGJyPg0KQ2hhbmdpbmcgdGhlICZxdW90 O2NvdWxkJnF1b3Q7IGludG8gYSAmcXVvdDttYXkmcXVvdDsgd291bGQgaG93ZXZlciBiZSBtb3Jl IGFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZCwgSSdsbCBtYWtlIHRoYXQg Y2hhbmdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGFua3MuPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KNy4g SW4gc2VjdGlvbiZuYnNwOyAyLjEgcmVxdWVzdCwgdGhlIHRleHQgZGVmaW5lczo8YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsgcmVzb3VyY2U8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT1BUSU9OQUwuJm5ic3A7IEluZGljYXRlcyB0aGUgcGh5c2ljYWwgbG9jYXRpb24gb2YgdGhl IHRhcmdldCBzZXJ2aWNlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIHJl c291cmNlIHdoZXJlIHRoZSBjbGllbnQgaW50ZW5kcyB0byB1c2UgdGhlIHJlcXVlc3RlZCBzZWN1 cml0eTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tlbi4mbmJzcDsgPGJy Pg0KPGJyPg0KYW5kPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IGF1ZGllbmNlPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiZuYnNwOyBUaGUgbG9naWNhbCBuYW1l IG9mIHRoZSB0YXJnZXQgc2VydmljZSB3aGVyZSB0aGUgY2xpZW50PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVuZHMgdG8gdXNlIHRoZSByZXF1ZXN0ZWQgc2VjdXJpdHkg dG9rZW4uJm5ic3A7IDxicj4NCjxicj4NCklmIHRoZSByZXNvdXJjZSBvciB0aGUgYXVkaWVuY2Ug cGFyYW1ldGVyIGlzIGJlaW5nIHVzZWQsIHRoZSBTVFMgd2lsbCBoYXZlIHRoZSBhYmlsaXR5IHRv IGtub3cgZXhhY3RseSB3aGljaCBpbmRpdmlkdWFsDQo8YnI+DQpvciBlbnRpdHkgaGFzIGFjY2Vz c2VkIHdoaWNoIHRhcmdldCBzZXJ2aWNlIGFuZCBtYXkga2VlcCBhIGxvZyBvZiB0aGF0IGFjdGl2 aXR5LiBJdCB3b3VsZCBiZSBpbiBhIHBvc2l0aW9uIHRvIGFjdCBhcyBCaWcgQnJvdGhlci4NCjxi cj4NClRoaXMgc2hvdWxkIGJlIGNsZWFybHkgaW5kaWNhdGVkIGluIGEgc2VjdGlvbiB0aGF0IGlz IGN1cnJlbnRseSBtaXNzaW5nIDogJnF1b3Q7Ny4gUHJpdmFjeSBDb25zaWRlcmF0aW9ucyZxdW90 Oy4gU2VlIGEgdGV4dCBwcm9wb3NhbCBoZXJlYWZ0ZXIuPGJyPg0KPGJyPg0KSG93ZXZlciwgdGhl cmUgaXMgaW5kZWVkIHRoZSBuZWVkIHRvIHJlc3RyaWN0IHRoZSB1c2Ugb2YgdG9rZW5zIHRvIHNw ZWNpZmljIHRhcmdldHMuIFRoZSBrZXkgcG9pbnQgaXMgdGhhdCB0aGUgdGFyZ2V0IHNlcnZpY2UN Cjxicj4NCm11c3QgYmUgYWJsZSB0byByZWNvZ25pemUgaXRzZWxmIHRoYXQgdGhlIHRva2VuIGlz IGluZGVlZCB0YXJnZXRlZCB0byBpdC4gQXMgYW4gZXhhbXBsZSwgYSBjaGFsbGVuZ2UgbWF5IGJl IHJlcXVlc3RlZCB0bw0KPGJyPg0KdGhlIHRhcmdldCBzZXJ2aWNlIGFuZCB0aGF0IGNoYWxsZW5n ZSBtYXkgdGhlbiBiZSBwbGFjZWQgaW50byBhIHNwZWNpZmljIGZpbGVkIG9mIHRoZSB0b2tlbi4g VGhlIHRhcmdldCBzZXJ2aWNlIG1heSB0aGVuIHZlcmlmeQ0KPGJyPg0KdGhhdCB0aGUgdmFsdWUg aW5jbHVkZWQgaW4gdGhlIHRva2VuIGlzIHRoZSBvbmUgdGhhdCBoYXMgYmVlbiByZWNlbnRseSBw cm92aWRlZC48YnI+DQo8YnI+DQpBIHBhcmFtZXRlciBzcGVjaWZ5aW5nIHRoZSB0eXBlIG9mIHRo ZSBjb250cm9sIHZhbHVlIGFuZCB0aGUgdmFsdWUgb2YgdGhlIGNvbnRyb2wgc2hvdWxkIGJlIGFk ZGVkLg0KPGJyPg0KVGhpcyBwYXJhbWV0ZXIgd291bGQgYmUgY2FsbGVkIGEgdGFyZ2V0X2lkICh0 aWQpLiBJdCB3b3VsZCBzb2x2ZSB0aGUgQmlnIEJyb3RoZXIgY2FzZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IGlzIGJvdGggYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGFuZCBw b3RlbnRpYWxpdHkgYXBwbGljYWJsZSB0byBhIGJyb2FkZXIgY29udGV4dCBvZiB1c2UuIEknZCBz dWdnZXN0IHlvdSB3cml0ZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IGZvciB0aGUgY29uY2VwdCwgaWYg eW91IHdhbnQgdG8gcHVyc3VlIGl0Lg0KPGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5UaGlzIHRvcGljIGhhcyBiZWVuIGFkZHJlc3NlZCB0d2ljZSBieSB0d28gcHJl c2VudGF0aW9ucyBvbiBKdWx5IHRoZSAxMyB0aCBhdCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBkYXkg b2YgdGhlIE9BdXRoIHdvcmtzaG9wIGluIFrDvHJpY2guPC9zcGFuPg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5EdXJpbmcgdGhpcyBtZWV0aW5nLCB0aGVyZSBoYXZlIGJl ZW4gZGlmZmVyZW50IHByb3Bvc2FscyB0byBzb2x2ZSB0aGUgaXNzdWUuIEkgYWxzbyBzYWlkIHRo YXQgb3RoZXIgcG9zc2liaWxpdGllcyB3ZXJlIHBvc3NpYmxlLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGZhY3QgaXMgdGhhdCBjdXJyZW50bHkgbm8g dGVjaG5pcXVlIGhhcyBiZWVuIGFncmVlZCB0byBzb2x2ZSB0aGUgaXNzdWUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSBzZWUgdHdvIG9wdGlvbnM6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PmEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+ZnJlZXplIHRoaXMgZG9jdW1lbnQgYW5kIHdhaXQgdW50aWwgYSB0ZWNobmlxdWUgY2FuIGJl IGFncmVlZCB3aXRoaW4gdGhlIFdHIGFuZCBkZWZpbmVkIGluIGFub3RoZXIgUkZDLA0KPGJyPg0K c28gdGhhdCZuYnNwOyB3ZSBjYW4gcmVmZXJlbmNlIGl0IGFuZCB0aGVuIGFmdGVyIGNvbnRpbnVl IHRoZSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Yik8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5kb24ndCB3YWl0LCBidXQgbWVudGlv biB0aGF0IGN1cnJlbnRseSBubyBwYXJhbWV0ZXIgaGFzIGJlZW4gZGVmaW5lZCB0byBhZGRyZXNz IHRoZSBpc3N1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5N eSBwcmVmZXJlbmNlIHdvdWxkIGJlIGZvciBvcHRpb24gYSk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IHdvdWxkIGJlIHlvdXIgcHJlZmVyZW5jZSA/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SWYgd2UgdGFrZSBvcHRp b24gYiksIHRoZW4gdGFrZSBhIGxvb2sgYXQgYSBuZXcgdGV4dCBwcm9wb3NhbCBmb3IgdGhlIGNv bW1lbnQgbnVtYmVyZWQgMTAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KOC4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g c3RhdGVzOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyAmcXVvdDtJbiBhZGRpdGlvbiwgYm90aCBk ZWxlZ2F0aW9uIGFuZCBpbXBlcnNvbmF0aW9uIGludHJvZHVjZSB1bmlxdWU8YnI+DQombmJzcDsm bmJzcDsgc2VjdXJpdHkgaXNzdWVzLiZuYnNwOyBBbnkgdGltZSBvbmUgcHJpbmNpcGFsIGlzIGRl bGVnYXRlZCB0aGUgcmlnaHRzIG9mPGJyPg0KJm5ic3A7Jm5ic3A7IGFub3RoZXIgcHJpbmNpcGFs LCB0aGUgcG90ZW50aWFsIGZvciBhYnVzZSBpcyBhIGNvbmNlcm4uJm5ic3A7IFRoZSB1c2Ugb2Y8 YnI+DQombmJzcDsmbmJzcDsgdGhlICZxdW90O3NjcCZxdW90OyBjbGFpbSBpcyBzdWdnZXN0ZWQg dG8gbWl0aWdhdGUgcG90ZW50aWFsIGZvciBzdWNoIGFidXNlLCBhczxicj4NCiZuYnNwOyZuYnNw OyBpdCByZXN0cmljdHMgdGhlIGNvbnRleHRzIGluIHdoaWNoIHRoZSBkZWxlZ2F0ZWQgcmlnaHRz IGNhbiBiZTxicj4NCiZuYnNwOyZuYnNwOyBleGVyY2lzZWQmcXVvdDsuPGJyPg0KPGJyPg0KU2Vj dGlvbiA0LjIgZGVmaW5lcyB0aGUgJnF1b3Q7c2NwJnF1b3Q7IChTY29wZXMpIGNsYWltIGluIHRo ZSBmb2xsb3dpbmcgd2F5Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7c2NwJnF1 b3Q7IGNsYWltIGlzIGFuIGFycmF5IG9mIHN0cmluZ3MsIGVhY2ggb2Ygd2hpY2ggcmVwcmVzZW50 cyBhbjxicj4NCiZuYnNwOyZuYnNwOyBPQXV0aCBzY29wZSBncmFudGVkIGZvciB0aGUgaXNzdWVk IHNlY3VyaXR5IHRva2VuLiZuYnNwOyBFYWNoIGFycmF5IGVudHJ5PGJyPg0KJm5ic3A7Jm5ic3A7 IG9mIHRoZSBjbGFpbSB2YWx1ZSBpcyBhIHNjb3BlLXRva2VuLCBhcyBkZWZpbmVkIGluIFNlY3Rp b24gMy4zIG9mPGJyPg0KJm5ic3A7Jm5ic3A7IE9BdXRoIDIuMCBbUkZDNjc0OV0uPGJyPg0KPGJy Pg0KU2VjdGlvbiAzLjMgZnJvbSBSRkMgNjc0OSBkZWZpbmVzIHRoZSBBY2Nlc3MgVG9rZW4gU2Nv cGUgYXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBhdXRob3JpemF0aW9uIGFu ZCB0b2tlbiBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVudCB0byBzcGVjaWZ5IHRoZTxicj4NCiZu YnNwOyZuYnNwOyBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgdXNpbmcgdGhlICZxdW90O3Nj b3BlJnF1b3Q7IHJlcXVlc3QgcGFyYW1ldGVyLiZuYnNwOyBJbjxicj4NCiZuYnNwOyZuYnNwOyB0 dXJuLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsg cmVzcG9uc2UgcGFyYW1ldGVyIHRvPGJyPg0KJm5ic3A7Jm5ic3A7IGluZm9ybSB0aGUgY2xpZW50 IG9mIHRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZC48YnI+DQombmJzcDsmbmJz cDsgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlz dCBvZiBzcGFjZS08YnI+DQombmJzcDsmbmJzcDsgZGVsaW1pdGVkLCBjYXNlLXNlbnNpdGl2ZSBz dHJpbmdzLiZuYnNwOyBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBieSB0aGU8YnI+DQombmJzcDsm bmJzcDsgYXV0aG9yaXphdGlvbiBzZXJ2ZXImcXVvdDsuPGJyPg0KPGJyPg0KU2VjdGlvbiA1LjQu MSBSZWdpc3RyeSBDb250ZW50cyBkZWZpbmVzIHNjcCBhczo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsgbyZuYnNwOyBDbGFpbSBOYW1lOiAmcXVvdDtzY3AmcXVvdDs8YnI+DQombmJzcDsmbmJzcDsg byZuYnNwOyBDbGFpbSBEZXNjcmlwdGlvbjogU2NvcGUgVmFsdWVzPGJyPg0KJm5ic3A7Jm5ic3A7 IG8mbmJzcDsgQ2hhbmdlIENvbnRyb2xsZXI6IElFU0c8YnI+DQombmJzcDsmbmJzcDsgbyZuYnNw OyBTcGVjaWZpY2F0aW9uIERvY3VtZW50KHMpOiBTZWN0aW9uIDQuMiBvZiBbWyB0aGlzIHNwZWNp ZmljYXRpb24gXV08YnI+DQo8YnI+DQpTaW5jZSB0aGUgJnF1b3Q7c3RyaW5ncyBhcmUgZGVmaW5l ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzJnF1b3Q7LCB3aGF0IGEgc2NvcGUgbWF5IG1l YW4gaXMgc3ViamVjdCB0byBtdWx0aXBsZSBpbnRlcnByZXRhdGlvbnMuDQo8YnI+DQpUaGUgY3Vy cmVudCBkZWZpbml0aW9uIG9mIHNjcCBpcyBpbnN1ZmZpY2llbnQgdG8gYWxsb3cgYW55IGtpbmQg b2YgaW50ZXJvcGVyYWJpbGl0eSwgbm93IG9yIGluIHRoZSBmdXR1cmUuPGJyPg0KPGJyPg0KSXQg aXMgdGh1cyB1bmNsZWFyIGhvdyB0aGUgdXNlIG9mIHRoZSAmcXVvdDtzY3AmcXVvdDsgY2xhaW0g bWlnaHQgbWl0aWdhdGUgdGhlIHJpc2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5TY29waW5nIHRoZSB0b2tlbiByZXN0cmljdHMgd2hhdCB0aGUgdG9r ZW4gY2FuIGJlIHVzZWQgZm9yIHdoaWNoIGxpbWl0cyB0aGUgaW1wYWN0IG9mIGEgY29tcHJvbWlz ZWQgb3IgbWlzdXNlZCB0b2tlbi4gVGhlIHNjb3BlIHZhbHVlcyBhcmUgaW50ZXJwcmV0ZWQgYnkg dGhlIHBhcnRpZXMgaW52b2x2ZWQganVzdCBhcyB3aXRoIHJlZ3VsYXIgT0F1dGguDQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgbm90IGFuIGFkZXF1YXRlIHJl c3BvbnNlIHRvIG15IGNvbW1lbnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5Zb3Ugc2F5IHRoYXQgJnF1b3Q7c2NvcGUgdmFsdWVzIGFyZSBpbnRlcnByZXRlZCBieSB0 aGUgcGFydGllcyBpbnZvbHZlZCBqdXN0IGFzIHdpdGggcmVndWxhciBPQXV0aCZxdW90Oy4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc3VnZ2VzdCB0aGUgZm9sbG93 aW5nIHRleHQgYXMgYSBmdWxsIHJlcGxhY2VtZW50IG9mIHRoZSBxdW90ZWQgdGV4dDo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJvdGggZGVsZWdhdGlvbiBhbmQgaW1w ZXJzb25hdGlvbiBpbnRyb2R1Y2UgdW5pcXVlIHNlY3VyaXR5IGlzc3Vlcy4mbmJzcDsgVGhlIHBv dGVudGlhbCBmb3IgYWJ1c2UgaXMgYSBjb25jZXJuLiZuYnNwOw0KPGJyPg0KVGhlIHVzZSBvZiB0 aGUgJnF1b3Q7c2NwJnF1b3Q7IGNsYWltIGFsbG93cyB0byByZXN0cmljdCB0aGUgY29udGV4dHMg aW4gd2hpY2ggdGhlIGRlbGVnYXRlZCByaWdodHMgY2FuIGJlIGV4ZXJjaXNlZC4NCjxicj4NCjxi cj4NClN0cmluZ3MgaW4gdGhlICZxdW90O3NjcCZxdW90OyBjbGFpbSBhcmUgZGVmaW5lZCBieSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLiBJZiB0aGUgY2xpZW50IGdldHMgc29tZSBrbm93bGVk Z2UNCjxicj4NCm9uIGhvdyB0aGVzZSBzdHJpbmdzIHdpbGwgYmUgaGFuZGxlZCBib3RoIGJ5IGEg cmVzb3VyY2Ugc2VydmVyIGFuZCBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlbiB0aGUg dXNlDQo8YnI+DQpvZiB0aGUgJnF1b3Q7c2NwJnF1b3Q7IGNsYWltIGNhbiBiZSB1c2VkIHRvIG1p dGlnYXRlIHBvdGVudGlhbCBmb3Igc3VjaCBhYnVzZS4gSG93ZXZlciwgYXQgdGhlIHRpbWUgb2Yg dGhlIGlzc3VhbmNlIG9mIHRoaXMgUkZDLA0KPGJyPg0KdGVjaG5pcXVlcyBmb3IgYXBwbHlpbmcg c3VjaCByZXN0cmljdGlvbnMgYXJlIG5vdCBkZWZpbmVkIGluIG90aGVyIFJGQ3MuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SW4gYWRkaXRpb24sIHVzZXJzIG1heSBjb2xs dWRlIGFuZCBvbmUgdXNlciBtaWdodCBiZSB3aWxsaW5nIHRvIGFsbG93IGFub3RoZXIgdXNlciB0 byBtYWtlIHVzZSBvZiBhIHNlY3VyaXR5IHRva2VuIHRoYXQgaXQgaGFzIG9idGFpbmVkLg0KPGJy Pg0KVGhpcyBpcyBub3QgYSBjb25jZXJuIGluIHRoZSBjb250ZXh0IG9mIGEgZGVsZWdhdGlvbiBz Y2hlbWUsIGJ1dCBtYXkgYmUgYSBzZXJpb3VzIGNvbmNlcm4gaW4gc29tZSBvdGhlciBjb250ZXh0 cy4gV2hhdGV2ZXIga2luZA0KPGJyPg0Kb2YgY3J5cHRvZ3JhcGh5IGlzIGJlaW5nIHVzZWQsIHRo ZXJlIGlzIG5vIHdheSB0byBzdG9wIGNvbGx1c2lvbiBiZXR3ZWVuIHVzZXJzLCB1bmxlc3Mgc29t ZSBzZWN1cmUgaGFyZHdhcmUgaXMgcmVxdWlyZWQgdG8gYmUgdXNlZA0KPGJyPg0KYnkgYSBzZWN1 cml0eSB0b2tlbiByZXF1ZXN0ZXIgaW4gb3JkZXIgdG8gb2J0YWluIGEgc2VjdXJpdHkgdG9rZW4u IEluIG90aGVyIHdvcmRzLCBhIHNvZnR3YXJlLW9ubHkgaW1wbGVtZW50YXRpb24gaXMgdW5hYmxl IHRvIHByZXZlbnQNCjxicj4NCmNvbGx1c2lvbiBiZXR3ZWVuIHVzZXJzLiBBIGhhcmR3YXJlIHNv bHV0aW9uIHNpbXBseSBwcm90ZWN0aW5nIHNvbWUgc2VjcmV0IGtleSBvciBzb21lIHByaXZhdGUg a2V5IHdpbGwgYWxzbyBiZSBpbmVmZmVjdGl2ZSwgc2luY2UNCjxicj4NCm9uZSB1c2VyIHdvdWxk IGJlIGFibGUgdG8gcGVyZm9ybSBhbGwgdGhlIGNyeXB0b2dyYXBoaWMgY29tcHV0YXRpb25zIHRo YXQgdGhlIG90aGVyIHVzZXIgbmVlZHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+Tm90ZTogUGVvcGxlIHRoYXQgd2VyZSBwcmVzZW50IG9uIEp1 bHkgdGhlIDEzIHRoIG9uIHRoZSBmaXJzdCBkYXkgb2YgdGhlIE9BdXRoIHdvcmtzaG9wIGluIFrD vHJpY2ggbWF5IHVuZGVyc3RhbmQgYmV0dGVyIHdoYXQgSSBtZWFuLg0KPGJyPg0KVGhlIHRleHQg YW5kIHRoZSBzbGlkZXMgb2YgdGhpcyB3b3Jrc2hvcCBzaG91bGQgYmUgcHVibGljbHkgYXZhaWxh YmxlIHNob3J0bHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo5LiBUaGlzIGRvY3Vt ZW50IGlzIGN1cnJlbnRseSB0YXJnZXRlZCB0byBiZWNvbWUgYSBTdGFuZGFyZHMgVHJhY2sgZG9j dW1lbnQuPGJyPg0KPGJyPg0KUkZDIDY0MTAgcmVjb2duaXplcyB0d28gbWF0dXJpdHkgbGV2ZWxz OiA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgLSB0aGUgRmlyc3QgTWF0dXJpdHkgTGV2ZWw6IFBy b3Bvc2VkIFN0YW5kYXJkPGJyPg0KJm5ic3A7Jm5ic3A7IC0gdGhlIFNlY29uZCBNYXR1cml0eSBM ZXZlbDogSW50ZXJuZXQgU3RhbmRhcmQ8YnI+DQo8YnI+DQpJdCBpcyBub3QgYmVsaWV2ZWQgdGhh dCBjdXJyZW50bHkgaXQgaXMgcG9zc2libGUgdG8gY29uc3RydWN0IHR3byBpbmRlcGVuZGVudCBp bnRlcm9wZXJhdGluZyBpbXBsZW1lbnRhdGlvbnMNCjxicj4NCmxvb2tpbmcgYXQgdGhpcyBkb2N1 bWVudCBvbmx5LiBVbmxlc3MgbW9yZSBndWlkYW5jZSBpcyBwcm92aWRlZCwgdGhpcyBkb2N1bWVu dCBzaG91bGQgYmUgdGFyZ2V0ZWQgdG8gJnF1b3Q7RXhwZXJpbWVudGFsJnF1b3Q7LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBjb21wbGV0ZWx5IGRp c2FncmVlLiBBbmQgd291bGQgYWxzbyBub3RlIHRoYXQgdGhlIHRoZSBkb2N1bWVudCdzIGludGVu ZGVkIHN0YXR1cyBoYXMgYmVlbiBzdGFibGUgYW5kIHVucXVlc3Rpb25lZCBieSB0aGlzIFdHIGZv ciBzZXZlcmFsIHllYXJzLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpTZWN0aW9u IDIuMSBmcm9tIFJGQyA2NDEwIHN0YXRlczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgVGhlIHN0YXRlZCByZXF1aXJlbWVudHMgZm9yIFBy b3Bvc2VkIFN0YW5kYXJkIGFyZSBub3QgY2hhbmdlZDsgdGhleTxicj4NCiZuYnNwOyZuYnNwOyBy ZW1haW4gZXhhY3RseSBhcyBzcGVjaWZpZWQgaW4gUkZDIDIwMjYgWzFdLiZuYnNwOyBObyBuZXcg cmVxdWlyZW1lbnRzIGFyZTxicj4NCiZuYnNwOyZuYnNwOyBpbnRyb2R1Y2VkOyBubyBleGlzdGlu ZyBwdWJsaXNoZWQgcmVxdWlyZW1lbnRzIGFyZSByZWxheGVkLjxicj4NCjxicj4NClNlY3Rpb24g NC4xLjEgZnJvbSBSRkMgMjAyNiBzdGF0ZXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IEEgUHJv cG9zZWQgU3RhbmRhcmQgc3BlY2lmaWNhdGlvbiBpcyBnZW5lcmFsbHkgc3RhYmxlLCBoYXMgcmVz b2x2ZWQ8YnI+DQombmJzcDsmbmJzcDsga25vd24gZGVzaWduIGNob2ljZXMsIGlzIGJlbGlldmVk IHRvIGJlIDxiPndlbGwtdW5kZXJzdG9vZDwvYj4sIGhhcyByZWNlaXZlZDxicj4NCiZuYnNwOyZu YnNwOyBzaWduaWZpY2FudCBjb21tdW5pdHkgcmV2aWV3LCBhbmQgYXBwZWFycyB0byBlbmpveSBl bm91Z2ggY29tbXVuaXR5PGJyPg0KJm5ic3A7Jm5ic3A7IGludGVyZXN0IHRvIGJlIGNvbnNpZGVy ZWQgdmFsdWFibGUuPGJyPg0KPGJyPg0KKC4uLik8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgQSBQ cm9wb3NlZCBTdGFuZGFyZCBzaG91bGQgaGF2ZSA8Yj5ubyBrbm93biB0ZWNobmljYWwgb21pc3Np b25zPC9iPiB3aXRoPGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3BlY3QgdG8gdGhlIHJlcXVpcmVtZW50 cyBwbGFjZWQgdXBvbiBpdC48YnI+DQo8YnI+DQpJIGRvbid0IGJlbGlldmUgdGhhdCB0aGUgY3Vy cmVudCB0ZXh0IGNvbXBsaWVzIHdpdGggdGhlIHByZXZpb3VzIHN0YXRlbWVudHMuPGJyPg0KPGJy Pg0KT25lIG9mIHRoZSBnb2FscyBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGRlZmluZSBhIG5ldyBw YXJhbWV0ZXIgY2FsbGVkICZxdW90O3N1YmplY3RfdG9rZW4mcXVvdDsuPGJyPg0KPGJyPg0KSW4g b3JkZXIgdG8gdXNlIGl0LCB3ZSBuZWVkIHRvIHNheSBob3cgdGhlIGNsaWVudCwgdGhlIEFTIGFu ZCB0aGUgUlAgc2hhbGwgaGFuZGxlIGl0Lg0KPGJyPg0KVGhlIGN1cnJlbnQgdGV4dCBpcyBpbnN1 ZmZpY2llbnQgdG8ga25vdyBob3cgdG8gaGFuZGxlIGl0Ljxicj4NCjxicj4NClVubGVzcyBhZGRp dGlvbmFsIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkLCB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB0 YXJnZXRlZCB0byAmcXVvdDtFeHBlcmltZW50YWwmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KMTAuIFRl eHQgcHJvcG9zYWwgZm9yIGEgbmV3IHNlY3Rpb24gJnF1b3Q7Ny4gUHJpdmFjeSBDb25zaWRlcmF0 aW9ucyZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgNy4gUHJpdmFjeSBDb25zaWRlcmF0 aW9uczxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyA3LjEuIFJlc291cmNlIGFuZCBhdWRpZW5jZSBw YXJhbWV0ZXJzPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoZSB1c2Ugb2YgYW55IHRoZXNlIHR3 byBwYXJhbWV0ZXJzIGFsbG93IHRoZSBTVFMgdG8ga25vdyB3aGljaCA8YnI+DQombmJzcDsmbmJz cDsgdGFyZ2V0IHNlcnZlcnMgYXJlIGJlaW5nIGFjY2Vzc2VkIGJ5IGFueSBwYXJ0eSBtYWtpbmcg YSB0b2tlbiA8YnI+DQombmJzcDsmbmJzcDsgcmVxdWVzdC4mbmJzcDsgQW55IFNUUyBpcyB0aGVu IGFibGUgdG8gbG9nIHRva2VuIHJlcXVlc3RzLiZuYnNwOyBUaGlzIGlzIG5vdCA8YnI+DQombmJz cDsmbmJzcDsgYSBwcm9ibGVtIGlmIHRoZSByZXNvdXJjZSBvd25lciBhbmQgdGhlIHRhcmdldCBz ZXJ2ZXIgYXJlIGNvbGxvY2F0ZWQsIDxicj4NCiZuYnNwOyZuYnNwOyBidXQgdGhpcyBkb2N1bWVu dCBpcyBub3QgcmVzdHJpY3RlZCB0byB0aGF0IGNhc2UuIDxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyBGb3IgdGhlIG90aGVyIGNhc2VzLCBpdCBzaG91bGQgYmUgbm90aWNlZCB0aGF0IHRoZSBTVFMg d2lsbCBiZSBpbiA8YnI+DQombmJzcDsmbmJzcDsgcG9zaXRpb24gdG8gYWN0IGFzIEJpZyBCcm90 aGVyLiZuYnNwOyBXaGVuIHByaXZhY3kgaXMgYSBjb25jZXJuLCB0aGUgdXNlIDxicj4NCiZuYnNw OyZuYnNwOyBvZiB0aGVzZSBwYXJhbWV0ZXJzIGlzIGRlcHJlY2F0ZWQgYW5kIHRoZSB1c2Ugb2Yg YSAmcXVvdDt0aWQmcXVvdDsgcGFyYW1ldGVyIDxicj4NCiZuYnNwOyZuYnNwOyBpcyByZWNvbW1l bmRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgYWRkIGEgcHJpdmFjeSBjb25zaWRlcmF0 aW9ucyB3aXRoIG1lbnRpb24gb2YgYmVpbmcgYWJsZSB0byB0cmFjayB0aGUgdGFyZ2V0IHN5c3Rl bXMgaW50ZW5kZWQgdG8gYmUgYWNjZXNzZWQgYnkgdGhlIHBhcnR5IHJlcXVlc3RpbmcgYSB0b2tl bi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBwcml2YWN5 IHNlY3Rpb24gdGhhdCBoYXMgYmVlbiBhZGRlZCBpcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcml2YWN5IENvbnNpZGVyYXRpb25zPGJyPg0K PGJyPg0KVG9rZW5zIHR5cGljYWxseSBjYXJyeSBwZXJzb25hbCBpbmZvcm1hdGlvbiBhbmQgdGhl aXIgdXNhZ2UgaW4gVG9rZW48YnI+DQpFeGNoYW5nZSBtYXkgcmV2ZWFsIGRldGFpbHMgb2YgdGhl IHRhcmdldCBzZXJ2aWNlcyBiZWluZyBhY2Nlc3NlZC48YnI+DQpBcyBzdWNoLCB0b2tlbnMgc2hv dWxkIG9ubHkgYmUgcmVxdWVzdGVkIGFuZCBzZW50IGFjY29yZGluZyB0byB0aGU8YnI+DQpwcml2 YWN5IHBvbGljaWVzIGF0IHRoZSByZXNwZWN0aXZlIG9yZ2FuaXphdGlvbnMuPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJdCBkb2VzIG5v dCBhZGRyZXNzIG15IGNvbmNlcm4uIEhlcmVhZnRlciBpcyBhIG5ldyB0ZXh0IHByb3Bvc2FsIHRv IGFkZHJlc3MgbXkgY29uY2VybiwgLi4uIGlmIHdlIGZvbGxvdyBvcHRpb24gYikgYXMgbWVudGlv bmVkIGJlZm9yZWhhbmQuOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyA3LiBQcml2YWN5IENvbnNp ZGVyYXRpb25zPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IDcuMS4gUmVzb3VyY2UgYW5kIGF1ZGll bmNlIHBhcmFtZXRlcnM8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgVGhlIHVzZSBvZiB0aGUgcmVz b3VyY2Ugb3Igb2YgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciBhbGxvd3MgdGhlIFNUUyB0byBrbm93 IHdoaWNoIHRhcmdldCBzZXJ2ZXJzIGFyZSBiZWluZyBhY2Nlc3NlZA0KPGJyPg0KJm5ic3A7Jm5i c3A7IGJ5IGFueSBwYXJ0eSBtYWtpbmcgYSB0b2tlbiByZXF1ZXN0LiZuYnNwOyBBbnkgU1RTIHdp bGwgdGhlbiBiZSBhYmxlIHRvIGxvZyB0b2tlbiByZXF1ZXN0cy4gVGhpcyBpcyBub3QgYSBwcm9i bGVtIGFzIGxvbmcgYXMNCjxicj4NCiZuYnNwOyZuYnNwOyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5k IHRoZSB0YXJnZXQgc2VydmVyIGFyZSBjb2xsb2NhdGVkLCBidXQgdGhpcyBkb2N1bWVudCBpcyBu b3QgcmVzdHJpY3RlZCB0byB0aGlzIGNhc2UuDQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgRm9y IHRoZSBvdGhlciBjYXNlcywgaWYgZWl0aGVyIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgb3IgdGhl IGF1ZGllbmNlIHBhcmFtZXRlciBpcyBiZWluZyB1c2VkLCB0aGUgU1RTIHdpbGwgYmUgaW4gcG9z aXRpb24NCjxicj4NCiZuYnNwOyZuYnNwOyB0byBhY3QgYXMgQmlnIEJyb3RoZXIuIFdoZW4gcHJp dmFjeSBpcyBhIGNvbmNlcm4sIHRoZSB1c2Ugb2YgdGhlIHJlc291cmNlIHBhcmFtZXRlciBhbmQg b2YgdGhlIGF1ZGllbmNlIHBhcmFtZXRlciBpcyBkZXByZWNhdGVkDQo8YnI+DQombmJzcDsmbmJz cDsgYW5kIGFub3RoZXIgcGFyYW1ldGVyIHNob3VsZCBiZSB1c2VkIHRvIHJlc3RyaWN0IHRoZSB0 YXJnZXQgc2VydmVycyB0aGF0IGNhbiB1c2UgdGhlIHNlY3VyaXR5IHRva2VuLiBBdCB0aGUgdGlt ZSBvZiB0aGUgaXNzdWFuY2UNCjxicj4NCiZuYnNwOyZuYnNwOyBvZiB0aGlzIGRvY3VtZW50LCBz dWNoIGEgcGFyYW1ldGVyIHdhcyBub3QgeWV0IGRlZmluZWQgaW4gYW5vdGhlciBSRkMuPGJyPg0K PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IDcuMi4gVXNlIG9mIFJGQyA3NjYyIChPQXV0aCAyLjAg VG9rZW4gSW50cm9zcGVjdGlvbik8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgUkZDNzY2MiBkZWZp bmVzIGEgcHJvdG9jb2wgdGhhdCBhbGxvd3MgYXV0aG9yaXplZCBwcm90ZWN0ZWQgcmVzb3VyY2Vz IHRvIHF1ZXJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBkZXRlcm1pbmUgdGhlIHNldCBv ZiBtZXRhZGF0YQ0KPGJyPg0KJm5ic3A7Jm5ic3A7IGZvciBhIGdpdmVuIHRva2VuIHRoYXQgd2Fz IHByZXNlbnRlZCB0byB0aGVtIGJ5IGFuIE9BdXRoIDIuMCBjbGllbnQuIDxicj4NCjxicj4NCiZu YnNwOyZuYnNwOyBUaGUgdXNlIG9mIHRoaXMgcHJvdG9jb2wgcmFpc2VzIHNvbWUgcHJpdmFjeSBj b25jZXJucywgc2luY2UgdGhlIFNUUyBpcyB0aGVuIGFibGUgdG8gaWRlbnRpZnkgdGhlIGNsaWVu dHMgYWNjZXNzaW5nIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50Lg0KPGJyPg0KJm5ic3A7Jm5i c3A7IFRoaXMgY29uY2VybiB3aWxsIHJlbWFpbiBldmVuIHdoZW4gdGhlIHJlc291cmNlIHBhcmFt ZXRlciBvciB0aGUgYXVkaWVuY2UgcGFyYW1ldGVyIHdpbGwgbm90IGJlIHVzZWQuIFN1Y2ggcGFy YW1ldGVycyBtaWdodCBiZSBpbiB0aGUgZnV0dXJlDQo8YnI+DQombmJzcDsmbmJzcDsgcmVwbGFj ZWQgYnkgYW5vdGhlciBtZWFucyB0byByZXN0cmljdCB0aGUgdXNlIG9mIHRoZSBzZWN1cml0eSB0 b2tlbnMgdG8gc3BlY2lmaWMgcmVzb3VyY2Ugc2VydmVycywgYnV0IGEgY2FsbCBiYWNrIHRvIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB3b3VsZA0KPGJyPg0KJm5ic3A7Jm5ic3A7IHJ1aW4gdGhl IGJlbmVmaXRzIG9mIHRoZSB1c2Ugb2YgdGhpcyBhbHRlcm5hdGl2ZSBtZWFucy48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+ RGVuaXM8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGVuaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBhcmUgc3RhcnRpbmcgYSBXR0xDIG9uIHRoZSBUb2tlbiBFeGNoYW5nZSBk b2N1bWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UtMDgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTA4PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UsIHJldmlldyB0aGUgZG9j dW1lbnQgYW5kIHByb3ZpZGUgZmVlZGJhY2sgb24gYW55IGlzc3VlcyB5b3Ugc2VlIHdpdGggdGhl IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgV0dMQyB3aWxsIGVuZCBpbiB0d28gd2Vla3MsIG9uIEp1bmUgMTcsIDIwMTcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDtSaWZhYXQgYW5kIEhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1 dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5D T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkDQogdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFu eSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48 L2k+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29t cHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0504049471CEBAC95962E60FF5A30CY4PR21MB0504namp_-- From nobody Mon Jul 17 02:25:26 2017 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 9AC9312EA7C for ; Mon, 17 Jul 2017 02:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qcuH87W4PyCy for ; Mon, 17 Jul 2017 02:25:23 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 7384F129B5B for ; Mon, 17 Jul 2017 02:25:23 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 32so101315521qtv.1 for ; Mon, 17 Jul 2017 02:25: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; bh=q6slAwzCo5wvyisOD9x0JnaHGSsFfs4H05bmsZQgcOI=; b=hE/NzuKzOMEsKSbSqqHwqEsvEfNDCfIk+Q7Mx5Aa0FXK2Sa7sHEB8z9UAIF9zZMfvQ HYInNORNj1qgnL0h5inNkivUPTcl0o+PF8spmnkrNvEx+DWvpwg/+3ia+LgndYUNnyLu wf6kkEDCUR5hGg2isLMsmcjcC2HvZm/Q8y7q3RnVS5wO3ndHaQfs2Qk1mJ4u5QQlF7Dn 1UoN3cHqoZ6WLJ2naEHA+WSQCEHLvHAwpX0CZN37NskarcaRr2OnhFQlSHeHd0kcW3++ xBKrEvWp4vYgjNRvtlEvjPaYP8w96/tkrGe6sHREgdJsl9oO5ePzXlXfttHVfMHxB4ki HVNg== 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=q6slAwzCo5wvyisOD9x0JnaHGSsFfs4H05bmsZQgcOI=; b=tL5CpDNEbcqXTOOFIPbAfOGnClZqUPy0dQQ9edxnb/EYMAzch9j64cBKvyjGwv6bkv SzPQiFB/QoaxuUBIiUiX5tMeU/lluEaSknkeZOexZqyUP0OCSKfe2VP9KXt2QUOJnWAQ W9fj1KCtEIen/imyWBmEeWKoimgT09nZE/LZcuS6FPJSE/s/kDtClCZRbQiOPFHTJIL0 j4knRvZ/AI6EuvSNq1or7SBqjyrTxj9uygrqGZcc5xsVol5x6TYcSZuc+ExLLSEhTVKr CSmN4MrIIT/aoUdaOT5t/DoBks44bxb0xkdDuDC92zorZbqELqWTVEMmCxx6mNEVvIAN xbtg== X-Gm-Message-State: AIVw113UKUAW8aUasL07eC02A1eNmYYyr2nyB5a/nFbNlwGnDLBXslDq IAcOnbAuCTg2cDvd2Id38CE5/9w9Vg== X-Received: by 10.200.0.213 with SMTP id d21mr24888090qtg.28.1500283522492; Mon, 17 Jul 2017 02:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.132 with HTTP; Mon, 17 Jul 2017 02:25:02 -0700 (PDT) From: Dick Hardt Date: Mon, 17 Jul 2017 11:25:02 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="f403045f2a066bae3405547ffa2a" Archived-At: Subject: [OAUTH-WG] bidirectional authorization interest? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:25:25 -0000 --f403045f2a066bae3405547ffa2a Content-Type: text/plain; charset="UTF-8" In Alexa, we are coming across scenarios where both parties are both a resource and an authorization server, and each of them requires an access token for the other. Is anyone else interested in such scenarios and would like to get together informally in Prague this week? /Dick --f403045f2a066bae3405547ffa2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Alexa, we are coming across scenarios where both parties are both a= resource and an authorization server, and each of them requires an access = token for the other.

Is anyone else interested in = such scenarios and would like to get together informally in Prague this wee= k?

/Dick
--f403045f2a066bae3405547ffa2a-- From nobody Mon Jul 17 02:53:41 2017 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 A77EE1276AF for ; Mon, 17 Jul 2017 02:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS_OvazTww-A for ; Mon, 17 Jul 2017 02:53:37 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 86A0212EBFE for ; Mon, 17 Jul 2017 02:53:37 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q85so74028655pfq.1 for ; Mon, 17 Jul 2017 02:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VosfnUCE+HfCXNKDHz7sccWL2QA7675TsRsOv4X+FeA=; b=IRVFkwSjg1uSPzxoF/Uo1vm+7wVcv5REoFAbIzhgvw0NcOterh4IkDX6+WEcUJox0Z lkOrC6PEUBOiRnXLkjAb0LkpmY0cTyhu7qPO5n5uJ7jsD86dKa/XUCNMg4H3s2ypVYuM LnxSaAKuLMrJ8xcLBKxIQHePD08Qfx+MrGZ0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VosfnUCE+HfCXNKDHz7sccWL2QA7675TsRsOv4X+FeA=; b=IupX+0m7MSUwJK7U7Xq06cgNS5QcI55KuwC8hn9pjpWAU5o2ecalYBK5+lFz5nZmhN QuqhIiTdl31T8UBxq98tVFdQ2wn3B4dLqukIgWBl5y6KxKZO0V/ItTriC0lQNT0pExkv HaTMGaWMdxOpDFB+rUuyuRf1FpyxwtCQ1mowGhS9lBeaX99kGGXG4Ntd0ogP8nvqOCdn MwW6DvzbATZt09AZLMISd6r+NWA83gYBnahZYyWxh8Cruo/cbDSVqWhjpKj8uUgBMf/7 kqlfCZAJ8i4MKSXZmBLtzckjZ/qoiA+4B/uEgnezlRuiDpW68uucopoZDTa9FdSsPOFU MJFw== X-Gm-Message-State: AIVw112dXiijhf9to2isKPSBYZmEVtO5s/XoHwUN8XMe84rvtP+pBhcE T3AZyyUmWJ5bTvr7fsihJsOc8dJjbHezSzg1QkoYKi1Gc/xJTK/uArnGo6IfFwW6nNtV8UJn3ko d0Evh X-Received: by 10.84.194.228 with SMTP id h91mr29485629pld.46.1500285217179; Mon, 17 Jul 2017 02:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Mon, 17 Jul 2017 02:53:06 -0700 (PDT) In-Reply-To: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> References: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> From: Brian Campbell Date: Mon, 17 Jul 2017 11:53:06 +0200 Message-ID: To: "Phil Hunt (IDM)" Cc: Mike Jones , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18a30e6ea7810554805f6a" Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:53:40 -0000 --94eb2c18a30e6ea7810554805f6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could some more guidance be provided around how to use the explicit typing with nested JWTs? I'd imagine that the "typ" header should be in the header of the JWT that is integrity protected by the issuer? On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) wrote: > +1 > > Thanks Mike. > > Phil > > On Jul 4, 2017, at 12:43 PM, Mike Jones > wrote: > > The JWT BCP draft has been updated to describe the use of explicit typing > of JWTs as one of the ways to prevent confusion among different kinds of > JWTs. This is accomplished by including an explicit type for the JWT in > the =E2=80=9Ctyp=E2=80=9D header parameter. For instance, the Security E= vent Token (SET) > specification now uses the =E2=80=9C > application/secevent+jwt=E2=80=9D content type to explicitly type SETs. > > > > The specification is available at: > > - https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 > > > > An HTML-formatted version is also available at: > > - http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1714 an= d > as @selfissued . > > _______________________________________________ > 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 *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. If you have= =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.* --94eb2c18a30e6ea7810554805f6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could some more guidance be provided around how to us= e the explicit typing with nested JWTs?

I'd imagine that = the "typ" header should be in the header of the JWT that is integ= rity protected by the issuer?=C2=A0
On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM= ) <phil.hunt@oracle.com> wrote:
+1

Thanks Mike.=C2=A0

Phil

O= n Jul 4, 2017, at 12:43 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

The JWT BCP draft has been updated to describe the u= se of explicit typing of JWTs as one of the ways to prevent confusion among= different kinds of JWTs.=C2=A0 This is accomplished by including an explic= it type for the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter.=C2=A0 For instance, the Security Event Token (SET) specification now uses the =E2=80=9Capplication/secevent+jwt=E2=80=9D content type to explicitly type S= ETs.

=C2=A0

The specification is available at:

=C2=A0

An HTML-formatted version is also available at:

=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=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=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=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=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

P.S.=C2=A0 This notice was also posted at http://self-issued.info/?p=3D1714 and as @selfissued.

_______= ________________________________________
OAuth mailing= list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth

_________________________= ______________________
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. --94eb2c18a30e6ea7810554805f6a-- From nobody Mon Jul 17 02:55:24 2017 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 BAE171276AF for ; Mon, 17 Jul 2017 02:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 DSLmUfT28Tpn for ; Mon, 17 Jul 2017 02:55:20 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0096.outbound.protection.outlook.com [104.47.34.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E67B129B5B for ; Mon, 17 Jul 2017 02:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wGLqD/LEJJKFezYEUrS8uweoqEQkVQT3/+yqGqLfnbk=; b=Fco98XXC2pztKrCyfa4GXuC4Vhe7sctMIfUKbPhLyh6fOSHpnQOkGE9NsZCL5qQRSGsIiN8dMkCe45tF1TSz7ytmB0Cwuticepx+gtIW1TcnrQbNDu24ZUAMMyIMsRfRbgPXlQFpeJPfZ9k7giBLj1WsjORiE2b22Iu5WSHy+nM= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 17 Jul 2017 09:55:19 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 09:55:19 +0000 From: Mike Jones To: Brian Campbell , "Phil Hunt (IDM)" CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing Thread-Index: AdL0+iJmgqpM9UqbSgCDmYr6GQRcNAABbcaAAnio3wAAAA31QA== Date: Mon, 17 Jul 2017 09:55:18 +0000 Message-ID: References: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [31.133.131.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 7:ZMtpRYcL4NLWhY+QsMdagOZ4VFKHttfgYBZq/ga/HjSROc9amoqEDYMQRjkMeVMUmEtP3Yryw5Fe6tr5zjw25Sbb2t2Ve+RzKc4yGZTglbrfyL1KZiXqx+j0S5v7+v7oi8FRMTbTiwIAO12H/i3fHY3Kfv2CYvD2ixVq9Rma15mqG18Zf5w1DrkDJzYPqkNv4gouSBQu8hjBU4ZGaep6hp3TQCTkAWrMtRT/fObFDkyX1kULxS1if0GrBKORsBhyKA4PSNZxJlMS23ZSpDMHlkt748OyYLszAPr2DzDJ73varbZ6dJ3jpFRkl4o+iHKxyZl7ZoJn7IDnMd2TUv/UezJ6YbCl8Ji21r+W7YTGiY02+79sFYCmpVX7eBkKiJBrSjdTbSc94IhNeY5QH+mkqs5WzUTj8cPrsx9ArngqAQ7jFf5jYmmatEI9WGFLqkcilIuofk7Rb6K3Bri3JkoALcONigJPAjKCo/2jc6Yz5g0Awmun6+WL5NCZIy2187WBHU+BQb/Iz6QFhOJGcf6O393MaXiRzbtPYt3vXyQqReFVMpgdfXp1KQ3pRqiz7FIJKYsHIf23mudhu6FbTZeGRXPd/ZXRHAK9i6lNirUkQ5GtQDPiFw3i+pFXC0+WVhOpqVXobm5UGHN2dl0Bbgs3lhn0zHRlxb6szrERHHiZt7fHix4bJ8Q1JuaXC2gkXDFeB+i3mY0ulGv8G3iKiDXH3NULLS0n4T7by36TtqArPbcXvnM5CNHDdNJvqudspMJhod2305IXEWamKqij5kMU8YkZ5FWfQetau/dxzmmURPdetI1IxmFMrh/gR3II+o5v x-ms-office365-filtering-correlation-id: becdd67b-63dd-4791-3809-08d4ccf9eedf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0278; x-ms-traffictypediagnostic: CY4PR21MB0278: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(192374486261705)(31418570063057)(48057245064654)(148574349560750)(21748063052155)(146099531331640)(209349559609743); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0278; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39860400002)(39450400003)(39400400002)(39410400002)(209900001)(36304003)(24454002)(377454003)(2950100002)(72206003)(10090500001)(5005710100001)(66066001)(2900100001)(478600001)(3280700002)(86362001)(5890100001)(6116002)(3660700001)(14454004)(606006)(966005)(7696004)(3846002)(6506006)(19609705001)(102836003)(790700001)(54356999)(33656002)(81166006)(8676002)(2906002)(7736002)(77096006)(76176999)(189998001)(50986999)(53546010)(4326008)(25786009)(5660300001)(38730400002)(53376002)(10290500003)(229853002)(74316002)(53936002)(6246003)(8936002)(55016002)(54896002)(6436002)(99286003)(6306002)(236005)(9686003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05045E56B6AB61AE66AA3D6EF5A00CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 09:55:19.0370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:55:23 -0000 --_000_CY4PR21MB05045E56B6AB61AE66AA3D6EF5A00CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludC4gIEnigJlkIGhhZCB0aGF0IHRob3VnaHQgYXMgd2VsbCBhdCBvbmUgcG9pbnQg YnV0IGZhaWxlZCB0byBleHByZXNzIGl0IGluIHRoZSBkcmFmdC4gIFdpbGwgZG8uDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b21dDQpTZW50OiBNb25kYXksIEp1bHkgMTcsIDIwMTcgMTE6NTMgQU0NClRvOiBQaGlsIEh1bnQg KElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBKU09OIFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRyYWZ0IGRlc2NyaWJpbmcg RXhwbGljaXQgVHlwaW5nDQoNCkNvdWxkIHNvbWUgbW9yZSBndWlkYW5jZSBiZSBwcm92aWRlZCBh cm91bmQgaG93IHRvIHVzZSB0aGUgZXhwbGljaXQgdHlwaW5nIHdpdGggbmVzdGVkIEpXVHM/DQpJ J2QgaW1hZ2luZSB0aGF0IHRoZSAidHlwIiBoZWFkZXIgc2hvdWxkIGJlIGluIHRoZSBoZWFkZXIg b2YgdGhlIEpXVCB0aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQgYnkgdGhlIGlzc3Vlcj8NCg0K T24gVHVlLCBKdWwgNCwgMjAxNyBhdCA5OjU4IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzENCg0K VGhhbmtzIE1pa2UuDQoNClBoaWwNCg0KT24gSnVsIDQsIDIwMTcsIGF0IDEyOjQzIFBNLCBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhlIEpXVCBCQ1AgZHJhZnQgaGFzIGJlZW4gdXBkYXRl ZCB0byBkZXNjcmliZSB0aGUgdXNlIG9mIGV4cGxpY2l0IHR5cGluZyBvZiBKV1RzIGFzIG9uZSBv ZiB0aGUgd2F5cyB0byBwcmV2ZW50IGNvbmZ1c2lvbiBhbW9uZyBkaWZmZXJlbnQga2luZHMgb2Yg SldUcy4gIFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5IGluY2x1ZGluZyBhbiBleHBsaWNpdCB0eXBl IGZvciB0aGUgSldUIGluIHRoZSDigJx0eXDigJ0gaGVhZGVyIHBhcmFtZXRlci4gIEZvciBpbnN0 YW5jZSwgdGhlIFNlY3VyaXR5IEV2ZW50IFRva2VuIChTRVQpIHNwZWNpZmljYXRpb248aHR0cDov L3NlbGYtaXNzdWVkLmluZm8vP3A9MTcwOT4gbm93IHVzZXMgdGhlIOKAnGFwcGxpY2F0aW9uL3Nl Y2V2ZW50K2p3dOKAnSBjb250ZW50IHR5cGUgdG8gZXhwbGljaXRseSB0eXBlIFNFVHMuDQoNClRo ZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KICAqICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNoZWZmZXItb2F1dGgtand0LWJjcC0wMQ0KDQpBbiBIVE1MLWZv cm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Og0KDQogICogICBodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LXNoZWZmZXItb2F1dGgtand0LWJjcC0wMS5odG1sDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNClAuUy4gIFRoaXMgbm90aWNlIHdhcyBhbHNvIHBvc3RlZCBhdCBodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby8/cD0xNzE0IGFuZCBhcyBAc2VsZmlzc3VlZDxodHRwczovL3R3aXR0ZXIu Y29tL3NlbGZpc3N1ZWQ+Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KQ09ORklERU5USUFM SVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZp bGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21t dW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRz IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_CY4PR21MB05045E56B6AB61AE66AA3D6EF5A00CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo0OTAzOTIzMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg2NDYzNzE4Mjt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3MjE0MDA5ODM7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE1NTQ1Mjc0NDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkdvb2Qg cG9pbnQuJm5ic3A7IEnigJlkIGhhZCB0aGF0IHRob3VnaHQgYXMgd2VsbCBhdCBvbmUgcG9pbnQg YnV0IGZhaWxlZCB0byBleHByZXNzIGl0IGluIHRoZSBkcmFmdC4mbmJzcDsgV2lsbCBkby48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5Gcm9tOjwvYj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTcsIDIwMTcgMTE6NTMg QU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7cGhpbC5odW50QG9yYWNsZS5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBKU09OIFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRyYWZ0IGRlc2Ny aWJpbmcgRXhwbGljaXQgVHlwaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Db3VsZCBzb21lIG1vcmUgZ3VpZGFuY2Ug YmUgcHJvdmlkZWQgYXJvdW5kIGhvdyB0byB1c2UgdGhlIGV4cGxpY2l0IHR5cGluZyB3aXRoIG5l c3RlZCBKV1RzPw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkknZCBpbWFnaW5lIHRoYXQgdGhlICZxdW90O3R5cCZxdW90OyBoZWFkZXIgc2hvdWxkIGJlIGlu IHRoZSBoZWFkZXIgb2YgdGhlIEpXVCB0aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQgYnkgdGhl IGlzc3Vlcj8mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBKdWwgNCwgMjAxNyBhdCA5OjU4IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNzk4MDYyMDY1NzMxNzQ5MzQ3NUFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ibV8tNzk4MDYyMDY1NzMxNzQ5MzQ3NUFwcGxlTWFpbFNpZ25hdHVyZSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgTWlrZS4mbmJzcDs8YnI+DQo8YnI+DQpQaGls PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDQsIDIw MTcsIGF0IDEyOjQzIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBKV1QgQkNQIGRyYWZ0IGhhcyBiZWVuIHVw ZGF0ZWQgdG8gZGVzY3JpYmUgdGhlIHVzZSBvZiBleHBsaWNpdCB0eXBpbmcgb2YgSldUcyBhcyBv bmUgb2YgdGhlIHdheXMgdG8gcHJldmVudCBjb25mdXNpb24gYW1vbmcgZGlmZmVyZW50IGtpbmRz IG9mIEpXVHMuJm5ic3A7IFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5DQogaW5jbHVkaW5nIGFuIGV4 cGxpY2l0IHR5cGUgZm9yIHRoZSBKV1QgaW4gdGhlIOKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dHlwPC9zcGFuPuKAnSBoZWFkZXIgcGFyYW1ldGVy LiZuYnNwOyBGb3IgaW5zdGFuY2UsIHRoZQ0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmlu Zm8vP3A9MTcwOSIgdGFyZ2V0PSJfYmxhbmsiPlNlY3VyaXR5IEV2ZW50IFRva2VuIChTRVQpIHNw ZWNpZmljYXRpb248L2E+IG5vdyB1c2VzIHRoZSDigJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFwcGxpY2F0aW9uL3NlY2V2ZW50JiM0Mztqd3Q8L3Nw YW4+4oCdIGNvbnRlbnQgdHlwZSB0byBleHBsaWNpdGx5IHR5cGUgU0VUcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwv bzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGVmZmVyLW9hdXRoLWp3dC1iY3AtMDEiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2hlZmZlci1vYXV0aC1q d3QtYmNwLTAxPC9hPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW4gSFRNTC1m b3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZv L2RvY3MvZHJhZnQtc2hlZmZlci1vYXV0aC1qd3QtYmNwLTAxLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LXNoZWZmZXItb2F1dGgtand0LWJj cC0wMS5odG1sPC9hPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlAuUy4mbmJzcDsgVGhpcyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0DQo8YSBo cmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNzE0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTcxNDwvYT4gYW5kIGFzDQo8YSBocmVmPSJodHRwczov L3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQiIHRhcmdldD0iX2JsYW5rIj5Ac2VsZmlzc3VlZDwvYT4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+ Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Ns b3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB05045E56B6AB61AE66AA3D6EF5A00CY4PR21MB0504namp_-- From nobody Tue Jul 18 01:50:48 2017 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 DBCD7131DC1; Tue, 18 Jul 2017 01:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tPW39fd4v91h; Tue, 18 Jul 2017 01:50:33 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 A2FC9131DB8; Tue, 18 Jul 2017 01:50:30 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p73so10833234qka.2; Tue, 18 Jul 2017 01:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hG7VVGUSRsxon265JgVcUD9XXc1DLlGg4IogeqNHnOs=; b=Lgqnt1e7CU8KIP5c4RaGk5z0k1luobQc4zOUSljb2dmDXAqAmt9Pxojo2SWE5JcuPt W+VXbffoXNHTAeemb4xoeCBoFYaWn4Y0n8Ablhz27iix5NtwjBRFNqXbPu2Fsh8zx4/A HUWhk2qIwmoklMKWib87o8nJMbj2GD7iKPKe6b4U5JIz/ezAWmD2p4ml2UXABCqYG1o/ DdO3Ss3DT1g3Uul2lYNxOCp/dt6IJGwBQvUKxDAlQkEfkXisIXisxEEGkNwQN0BsdO/n u+q7Ic1j4cIQDSLSKeOMqbpsHr0Ikt4TSYU3lap1Yop7SOVe+VB6ymGdExWtLb0WaS6G K75w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hG7VVGUSRsxon265JgVcUD9XXc1DLlGg4IogeqNHnOs=; b=YuJ10QeVMf21Y4I3eoP1PI/lOJ9Sas2LnyzmXmoz6psfjbB74rDAJDWixnYMU4IQ83 ASUh/gADmkSAcVCH4cOxs/sA/eHleO95qBxiBTDP51com8vVkPg5FZ5yLMsPz7+9T2Z6 v1PHO9/tSYzuxq8MbVJWWIp03paD/AOw/R7k413gHbfpwJd0u9JpLMZbjlcF0qvgLEDl tZLL/vwmxdnGOocn2JQJyPMHN8/ZbCzkC1GWqsAct7oyhxumCW2k7JscMmcioKSJE1UM F5heAKeOsh2oD+HCMKcxHOoIHqpPf+ISFfoy3gXivJmc7N+KtMFIH7KtLYj7YGdw5OJs SrjA== X-Gm-Message-State: AIVw111kAJ67VOOkvlv7/7yMIALfRHAb37JU9SiVk2Rj+AvT7QWNSUkf pEdZt2bpCsmHHbHHJrMqyrGJEIJdhw== X-Received: by 10.55.212.3 with SMTP id l3mr659877qki.144.1500367829837; Tue, 18 Jul 2017 01:50:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.230 with HTTP; Tue, 18 Jul 2017 01:50:29 -0700 (PDT) In-Reply-To: References: <149302898487.25852.14603447850318285300.idtracker@ietfa.amsl.com> From: Nat Sakimura Date: Tue, 18 Jul 2017 17:50:29 +0900 Message-ID: To: John Bradley Cc: Alexey Melnikov , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, IESG , IETF oauth WG Content-Type: multipart/alternative; boundary="001a1147a2dc87ac3f0554939bd4" Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-13: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:50:36 -0000 --001a1147a2dc87ac3f0554939bd4 Content-Type: text/plain; charset="UTF-8" Sorry to have taken so long to fix. In my private repo, I have added Content-type: application/jwt in the example. See http://bit.ly/oauth-jar. On Mon, Apr 24, 2017 at 8:11 PM, John Bradley wrote: > Thanks. We will try to address that today. > > John B. > > On Apr 24, 2017 7:16 AM, "Alexey Melnikov" wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-oauth-jwsreq-13: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thank you for addressing my DISCUSS about use of RFC 6125. >> >> I have one new small issue from your recent change in In 5.2.3 (that was >> addressing my comment to include a response example): the example doesn't >> include Content-Type and (possibly) Transfer-Encoding header fields. >> Without these it doesn't look syntactically correct. >> >> >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1147a2dc87ac3f0554939bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry to have taken so long to fix.=C2=A0
In my privat= e repo, I have added Content-type: application/jwt in the example.=C2=A0

On Mon, Apr 24, 2017 at 8:11 PM, John Bradley <ve7jtb= @ve7jtb.com> wrote:
Thanks.=C2=A0 We will try to address that today. =C2=A0

John B. =C2=A0

On Apr 24, 2017 7:16 AM, "Alexey Melnikov" <aamelnikov@fastmail.= fm> wrote:
Al= exey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwsreq-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-oauth-jwsreq/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Thank you for addressing my DISCUSS about use of RFC 6125.

I have one=C2=A0 new small issue from your recent change in In 5.2.3 (that = was
addressing my comment to include a response example): the example doesn'= ;t
include Content-Type and (possibly) Transfer-Encoding header fields.
Without these it doesn't look syntactically correct.





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




--
Nat Sakimura (=3D= nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1147a2dc87ac3f0554939bd4-- From nobody Tue Jul 18 09:34:03 2017 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 0A9DD129B5E for ; Tue, 18 Jul 2017 09:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 V-_tDfpVkQKj for ; Tue, 18 Jul 2017 09:34:00 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 BAC6712700F for ; Tue, 18 Jul 2017 09:33:59 -0700 (PDT) X-AuditID: 1209190c-967ff70000000780-ac-596e38754ac3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C9.64.01920.5783E695; Tue, 18 Jul 2017 12:33:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6IGXuS1007161; Tue, 18 Jul 2017 12:33:56 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6IGXsxW011330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2017 12:33:55 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9E90D9F9-4904-4536-B6EA-F4B0C6F303B4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 12:33:54 -0400 In-Reply-To: Cc: "" To: Mike Jones References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixCmqrFtqkRdpMHGGtsXeaZ9YLE6+fcXm wOSxZMlPJo/WHX/ZA5iiuGxSUnMyy1KL9O0SuDL6F21gLuhPr7jwdQNbA+OLyC5GTg4JAROJ F19msHQxcnEICSxmkmiaN4cRwtnIKPF/wnJGkCohgYdMEq37ykFsNgFVielrWphAbF4BK4ml nZdZQWxmgSSJRU93A9kcQHF9id7nYK3CAgkSj691g5WwALXe/X+dBcTmFIiV2L4eZAwHUKu6 RPtJF5CwiICOxOOL39ggtsZIzDpwmx3iTlmJW7MvMU9g5J+FZNkshGUQYW2JZQtfM0PYmhL7 u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5miV5qSukmRnBIS/Ls YDzzxusQowAHoxIP7wqOvEgh1sSy4srcQ4ySHExKorxblYFCfEn5KZUZicUZ8UWlOanFhxgl OJiVRHjztIByvCmJlVWpRfkwKWkOFiVxXgmNxgghgfTEktTs1NSC1CKYrAwHh5IEb5I5UKNg UWp6akVaZk4JQpqJgxNkOA/Q8AaQGt7igsTc4sx0iPwpRnuOTTN+fmPieDXhP5A89PvEdyaO YyBSiCUvPy9VSpy3wgyoTQCkLaM0D24yKF0lvD1s+opRHOhRYd4IkOE8wFQHN/sV0FomoLXC vjkga0sSEVJSDYz2a9xm3dm3/Xvx1o/zH3Kd+HPQ8Nf//z51yUqzVmjoe021mrSubIJOx1yp Ozs9ubrZuy58/Js3J/77EeP71TrfJs/ec6UnZs22Nek3frRN4Hl4RthP5O1+kWM7dv2QsQs6 XBG+pKlJLurOtot8z9JmGVtypTK+qWLMe3ZaRPduI5ezosaGdXFrlViKMxINtZiLihMB5VQe fjIDAAA= Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:34:02 -0000 --Apple-Mail=_9E90D9F9-4904-4536-B6EA-F4B0C6F303B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike et al, Overall, this document has some really great advice for people who have = chosen to use JWT in various situations. It=E2=80=99s a needed draft and = I=E2=80=99d like to see it go forward. I have some suggestions on how it = can be improved. In this draft, I=E2=80=99d like to see some more discussion about = privacy and security issues around choosing JWTs to begin with. Namely, = putting things like subject identifiers and scope/permission information = into the JWT structure could potentially leak information about the end = user to the client, if the JWT isn=E2=80=99t encrypted, and to multiple = RS=E2=80=99s, if the JWT is encrypted with a shared key. It basically = amounts to =E2=80=9Canyone who can read the JWT can see what=E2=80=99s = in it=E2=80=9D, which on the one hand is obvious, but on the other hand = it=E2=80=99s not always considered by implementers. Since the audience = of an access token JWT is the RS and not the client, and the token is = opaque to the client, it=E2=80=99s easy to assume that the client = *won=E2=80=99t* read the token. However, that doesn=E2=80=99t mean that = it *can=E2=80=99t* read the token. It=E2=80=99s a tradeoff in design = space with other solutions. I=E2=80=99d also like to see a discussion on expiration and revocation = of self-contained JWT access tokens. Again, this is targeting the = decision space of whether or not a self-contained token is an = appropriate solution in the first place. If I=E2=80=99m issuing JWTs = that are completely self-contained, I can=E2=80=99t revoke them once = they=E2=80=99re on the wire. Yes, that=E2=80=99s an acceptable risk to = many and that=E2=80=99s fine =E2=80=94 but I would like this document to = encourage that thought and discussion.=20 Thanks, =E2=80=94 Justin > On Jul 4, 2017, at 3:43 PM, Mike Jones = wrote: >=20 > The JWT BCP draft has been updated to describe the use of explicit = typing of JWTs as one of the ways to prevent confusion among different = kinds of JWTs. This is accomplished by including an explicit type for = the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter. For instance, = the Security Event Token (SET) specification = now uses the = =E2=80=9Capplication/secevent+jwt=E2=80=9D content type to explicitly = type SETs. > =20 > The specification is available at: > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 = > =20 > An HTML-formatted version is also available at: > http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html = > =20 > -- Mike > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1714 = and as @selfissued = . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_9E90D9F9-4904-4536-B6EA-F4B0C6F303B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike et al,

Overall, this document has some really great advice for = people who have chosen to use JWT in various situations. It=E2=80=99s a = needed draft and I=E2=80=99d like to see it go forward. I have some = suggestions on how it can be improved.

In this draft, I=E2=80=99d like to see = some more discussion about privacy and security issues around choosing = JWTs to begin with. Namely, putting things like subject identifiers and = scope/permission information into the JWT structure could potentially = leak information about the end user to the client, if the JWT isn=E2=80=99= t encrypted, and to multiple RS=E2=80=99s, if the JWT is encrypted with = a shared key. It basically amounts to =E2=80=9Canyone who can read the = JWT can see what=E2=80=99s in it=E2=80=9D, which on the one hand is = obvious, but on the other hand it=E2=80=99s not always considered by = implementers. Since the audience of an access token JWT is the RS and = not the client, and the token is opaque to the client, it=E2=80=99s easy = to assume that the client *won=E2=80=99t* read the token. However, that = doesn=E2=80=99t mean that it *can=E2=80=99t* read the token. It=E2=80=99s = a tradeoff in design space with other solutions.

I=E2=80=99d also like to see a = discussion on expiration and revocation of self-contained JWT access = tokens. Again, this is targeting the decision space of whether or not a = self-contained token is an appropriate solution in the first place. If = I=E2=80=99m issuing JWTs that are completely self-contained, I can=E2=80=99= t revoke them once they=E2=80=99re on the wire. Yes, that=E2=80=99s an = acceptable risk to many and that=E2=80=99s fine =E2=80=94 but I would = like this document to encourage that thought and = discussion. 

Thanks,
 =E2=80=94 Justin

On Jul 4, 2017, at 3:43 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The JWT BCP draft has been updated to describe the use of = explicit typing of JWTs as one of the ways to prevent confusion among = different kinds of JWTs.  This is accomplished by including an = explicit type for the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter.  = For instance, the Security Event Token (SET) = specification now = uses the =E2=80=9Capplication/secevent+jwt=E2=80=9D content type to = explicitly type SETs.
 
The specification is available at:
 
An = HTML-formatted version is also available at:
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1714 and as @selfissued.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_9E90D9F9-4904-4536-B6EA-F4B0C6F303B4-- From nobody Wed Jul 19 03:53:10 2017 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 D873C131CA3 for ; Wed, 19 Jul 2017 03:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0kT682owmv63 for ; Wed, 19 Jul 2017 03:53:06 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 7E8C3131A78 for ; Wed, 19 Jul 2017 03:53:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b40so38020476qtb.2 for ; Wed, 19 Jul 2017 03:53:06 -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=yApXFyfb7+klhw+za2a2/f1W2aKxGL55OJxBYFYvxjo=; b=ntDOPQzD2Fn6vlsz2bqmwz+Hr3Ymk/g6ew36dxbPWbL+/ErWu+Z3Iii7sfQuQCRUyb sjEJsXMbrG3Izk3SZ58BdlVMMzovA9H/iW4KmYAfBo/zPgysbvmn1/7K7avYgkQGrAn3 92f6SAwyFvolzwFqdt9DvkLi1uFLLOYtmbc0/QMvJfNGAXvofOvfNGGSxtPHaS8ZymAy mJ71rvTCaUSUTd1XM/7BLkonOsYRQujpYYzTtH0ETfjLzT0h6yezRuVd1JB+6iUwhThj BaddUkvCPLdugsAxQ56yNUoDG5q0vAqX7mU5f9SL7Iz3LsnPxM+W8SOl//qgtKaxvUK+ Ch5g== 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=yApXFyfb7+klhw+za2a2/f1W2aKxGL55OJxBYFYvxjo=; b=UUcwH+3J57dskasvDbWFZUYsYgw4KHonyAw3MkvHuzkD3UwDg2Gf3wV9OcTnu6/Q8M X8i8aV5SeGpHZ4sHmzGcnTfL/Ophhw9kjIv6xVuYmbri/d6vDh/IGvuCbOW6ZtkKb1cZ Z5fFQ19DMsfZCVPB+55Sn48PUxLs7Q0URUoeNCMi2pDZHDrALVmI/vDFJYNdXMGE6GhL 6hs4LwbPVltm+fmKn8Cocgo0Yi59ztWjqf9K3MGEeFtSsMmS/uKC/gcICt47PmGzYlLg 24XWI0Zo0k6ygtFq5YQJkeLuB6h4oFw+zEsIgyTFof4cw5oVmHK9edlnGgDIRUS0tbwF mybA== X-Gm-Message-State: AIVw111eUN6bzxNFVAtdXBFzXq+to8J63q5RPTFiGmAyz1O7EzAj/its TUJsHvMWMKRmpVnszXxl724ecuBUIA== X-Received: by 10.55.128.1 with SMTP id b1mr2272127qkd.76.1500461585646; Wed, 19 Jul 2017 03:53:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 19 Jul 2017 10:52:55 +0000 Message-ID: To: Justin Richer , Mike Jones Cc: "" Content-Type: multipart/alternative; boundary="94eb2c05ff5acfcfc70554a96f29" Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:53:09 -0000 --94eb2c05ff5acfcfc70554a96f29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback Justin. Do you have any specific wording? On Tue, Jul 18, 2017 at 6:34 PM Justin Richer wrote: > Mike et al, > > Overall, this document has some really great advice for people who have > chosen to use JWT in various situations. It=E2=80=99s a needed draft and = I=E2=80=99d like > to see it go forward. I have some suggestions on how it can be improved. > > In this draft, I=E2=80=99d like to see some more discussion about privacy= and > security issues around choosing JWTs to begin with. Namely, putting thing= s > like subject identifiers and scope/permission information into the JWT > structure could potentially leak information about the end user to the > client, if the JWT isn=E2=80=99t encrypted, and to multiple RS=E2=80=99s,= if the JWT is > encrypted with a shared key. It basically amounts to =E2=80=9Canyone who = can read > the JWT can see what=E2=80=99s in it=E2=80=9D, which on the one hand is o= bvious, but on the > other hand it=E2=80=99s not always considered by implementers. Since the = audience > of an access token JWT is the RS and not the client, and the token is > opaque to the client, it=E2=80=99s easy to assume that the client *won=E2= =80=99t* read the > token. However, that doesn=E2=80=99t mean that it *can=E2=80=99t* read th= e token. It=E2=80=99s a > tradeoff in design space with other solutions. > > I=E2=80=99d also like to see a discussion on expiration and revocation of > self-contained JWT access tokens. Again, this is targeting the decision > space of whether or not a self-contained token is an appropriate solution > in the first place. If I=E2=80=99m issuing JWTs that are completely self-= contained, > I can=E2=80=99t revoke them once they=E2=80=99re on the wire. Yes, that= =E2=80=99s an acceptable > risk to many and that=E2=80=99s fine =E2=80=94 but I would like this docu= ment to encourage > that thought and discussion. > > Thanks, > =E2=80=94 Justin > > On Jul 4, 2017, at 3:43 PM, Mike Jones > wrote: > > The JWT BCP draft has been updated to describe the use of explicit typing > of JWTs as one of the ways to prevent confusion among different kinds of > JWTs. This is accomplished by including an explicit type for the JWT in > the =E2=80=9Ctyp=E2=80=9D header parameter. For instance, the Security E= vent Token (SET) > specification now uses the =E2=80=9C > application/secevent+jwt=E2=80=9D content type to explicitly type SETs. > > The specification is available at: > > - https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 > > > An HTML-formatted version is also available at: > > - http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html > > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=3D1714 an= d > as @selfissued . > _______________________________________________ > 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 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c05ff5acfcfc70554a96f29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback Justin. Do you have any spec= ific wording?

On Tue, Jul 18, 2017= at 6:34 PM Justin Richer <jricher@mi= t.edu> wrote:
Mike et al,

Overall, this document= has some really great advice for people who have chosen to use JWT in vari= ous situations. It=E2=80=99s a needed draft and I=E2=80=99d like to see it = go forward. I have some suggestions on how it can be improved.
In this draft, I=E2=80=99d like to see some more discussion ab= out privacy and security issues around choosing JWTs to begin with. Namely,= putting things like subject identifiers and scope/permission information i= nto the JWT structure could potentially leak information about the end user= to the client, if the JWT isn=E2=80=99t encrypted, and to multiple RS=E2= =80=99s, if the JWT is encrypted with a shared key. It basically amounts to= =E2=80=9Canyone who can read the JWT can see what=E2=80=99s in it=E2=80=9D= , which on the one hand is obvious, but on the other hand it=E2=80=99s not = always considered by implementers. Since the audience of an access token JW= T is the RS and not the client, and the token is opaque to the client, it= =E2=80=99s easy to assume that the client *won=E2=80=99t* read the token. H= owever, that doesn=E2=80=99t mean that it *can=E2=80=99t* read the token. I= t=E2=80=99s a tradeoff in design space with other solutions.

=
I=E2=80=99d also like to see a discussion on expiration and revo= cation of self-contained JWT access tokens. Again, this is targeting the de= cision space of whether or not a self-contained token is an appropriate sol= ution in the first place. If I=E2=80=99m issuing JWTs that are completely s= elf-contained, I can=E2=80=99t revoke them once they=E2=80=99re on the wire= . Yes, that=E2=80=99s an acceptable risk to many and that=E2=80=99s fine = =E2=80=94 but I would like this document to encourage that thought and disc= ussion.=C2=A0

Thanks,
=C2=A0=E2=80=94 Ju= stin

On Jul 4, 2017, at 3:43 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:

= The JWT BCP draft has been updated to describe the use of explicit typing o= f JWTs as one of the ways to prevent confusion among different kinds of JWT= s.=C2=A0 This is accomplished by including an explicit type for the JWT in = the =E2=80=9Ctyp= =E2=80=9D header parameter.=C2=A0 For instance, the=C2=A0Security Event Token (SET) specification=C2=A0now uses the= =E2=80=9Capplication/sec= event+jwt=E2=80=9D content type to explicitly type SETs.
=C2=A0
The specification is = available at:
  • h= ttps://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01=
=C2=A0
An HTML-formatted v= ersion is also available at:
=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=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=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=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=C2=A0=C2=A0=C2=A0 -- Mike
<= /u>=C2=A0
P.S.=C2=A0 This notice was also posted at=C2=A0http://self-issued.info/?p=3D171= 4=C2=A0and as=C2=A0= @selfissued.<= u>
____________________= ___________________________
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
--
Subscribe to the HARDTWARE mail list to learn about projects I am working on!
--94eb2c05ff5acfcfc70554a96f29-- From nobody Thu Jul 20 05:37:47 2017 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 06A9B12EB99 for ; Thu, 20 Jul 2017 05:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LGf1U0dtT-JS for ; Thu, 20 Jul 2017 05:37:44 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 76A9B129AC4 for ; Thu, 20 Jul 2017 05:37:44 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w45so21822598uac.5 for ; Thu, 20 Jul 2017 05:37:44 -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=PMS3VSqPSeL/UaE44TcLJgDofIkPAblxQfZcuGMx2rU=; b=XRkgXfwMojuBoNiFhX04w2/OamYFYgyb/h/NiftlYNUAVOjyRMgIoPQLQcNVeMDRBa vf2M9g27CLip02wzIGcg5+JC1z4FBBCYjQODKMzQGgZtPnAODjC7xXXSM3JpzAF1kGz3 r/qslDHDVVFcNkPc/Q/hNlzKSS+ntxNux52CxdJaNVI30ekmPSw5c/yrUlOqmbC0TLoQ J2y4k8nGSa3E/VJbfKukXlOmcx9SAJtNo9/MU2j2yX8qXO88gweFHG6MftnBwMQiNZVI stFzVcPyZUZEmGBM6yAtpEFZbYYgCiO7JCyCjiobmavn42BcRSxhSYWjN6PhTvhvyYFn jrxA== 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=PMS3VSqPSeL/UaE44TcLJgDofIkPAblxQfZcuGMx2rU=; b=WdoHx480nOhLHApvaU61L5zCdXLsawU0eezDLeW1nZP3xCYejvQIJktaxN5MlTFuDK IWwOe8KhtsB9XfQG08E7xTh9ZdyjlYKrMSq1ydfkYNglguSC5QsXEjqgKbvRW52m7Xpj TFa1A4DdRRPh0EW/RkENLuayIAnsgzcnMHIvYub++LfELzu+aFkhyn3KN29+b6D0aNeT P2PXM9wZS6STBmFvWJqNoY7Qi9/ku6PtxdD6o3XyhCFnX2eF16RH0Hji1f4Xoqhg5NB8 TjiDT46YTz4P9aH6wPNcjpONCnfqIHhqjjpaQ/8L641f9wLMxjS/dWWg61bfYIte7IZZ O7+w== X-Gm-Message-State: AIVw111gXrYeCrChykQw8jyQqvayY/3DEYOOo7hvgB4Pw1NBQQErIMjG 92P/RCSN6L75NyC6c0Ousj3YoXEwbyhU X-Received: by 10.31.248.79 with SMTP id w76mr1793858vkh.182.1500554263547; Thu, 20 Jul 2017 05:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.84.70 with HTTP; Thu, 20 Jul 2017 05:37:43 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Thu, 20 Jul 2017 08:37:43 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c14955ad855950554bf0325" Archived-At: Subject: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:37:46 -0000 --94eb2c14955ad855950554bf0325 Content-Type: text/plain; charset="UTF-8" All, We would like to get a confirmation on the mailing list for the adoption of the *JSON Web Token Best Current Practices* as a WG document https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ Please, let us know if you support or object to the adoption of this document. Regards, Rifaat --94eb2c14955ad855950554bf0325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We would like to get a confirmatio= n on the mailing list for the adoption of the JSON Web Token Best Curren= t Practices as a WG document
=
Please, let us know if you support or object to the adoption= of this document.

Regards,
=C2=A0Rifaat=

--94eb2c14955ad855950554bf0325-- From nobody Thu Jul 20 10:55:22 2017 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 C217D12F3CB for ; Thu, 20 Jul 2017 10:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 21CvQ35OkgoO for ; Thu, 20 Jul 2017 10:55:12 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 63720131D24 for ; Thu, 20 Jul 2017 10:55:12 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t2so14099327qkc.1 for ; Thu, 20 Jul 2017 10:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QThHdUd9vjYajovgWQGrhNYv+63+nwDaXVB5vuv3TL8=; b=p2PHmTLOVPRkGulc/MVQBsFpPZsX+46WvRttwi6PZLW9Ffo8RZ6vhLHpTdsWvxZwzA 9e+V+T6qCnLQJpIJ6XDeN8VCUa8ylvnCNN25za5xjG5hjWFp0J7Q2hZQlUeOeA1jyan0 touUAIxpBXU1YWjOQ+ux0pzVtNO0M7bFDG/VZnBl9txkYYl8s5xSho2ym1DCCXd8YMLE IAqwMeWl4mRDAxkwBeUHPo95kVbkkNpBTI3JPDtTWTk+Jx5PIQ2ojsx/++GuXYtpCsk0 NP/RXbd1gLB7eRyYl39TtirUmkKYMA1u/rzjpULwjOMfZuWb6krEx9/xjq9B2xucA5Sd qI5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QThHdUd9vjYajovgWQGrhNYv+63+nwDaXVB5vuv3TL8=; b=O6OEApggftyB1RC3xHa2P0W2lxmkwLmUOHsLVp/4nJ67RbC6zXLX6HraxWgMYsqYpm SXruxxCVb6kRWPlVEpUYknHMr+duP6veIog+a4EIux1QV4b5pvpdkiOA0UVbFGO1nHkh XjaOtvq9dF0SGsCyBzhPccAjfURU7l/J3VsKFYK26Mi+2X751PbsLUfMqSaOXpX1sOre xxQkn3PkwfXSqTUXJwo4T5HPrUAjgvIpVHfAcryfCu1XUuEn+AJOOwqAmS5dmg0IR1Wk /Phg1zgvAT7qwZbCnZYqUo7ex5taQ7o+phtoXdgTIW92pPHvSQqegxWwc5onM0b1oQAr 8Fag== X-Gm-Message-State: AIVw110sb16BRVuWBfQ41ogs8giAcBDRV/YgWIR8hH0IpV9ktGZM99wE fhAr0iV0+aTd5U5dnS9Bhx4rOkzpaAYR X-Received: by 10.55.156.134 with SMTP id f128mr5659590qke.184.1500573311189; Thu, 20 Jul 2017 10:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.144 with HTTP; Thu, 20 Jul 2017 10:54:50 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 20 Jul 2017 18:54:50 +0100 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="94eb2c05dbae2cb99e0554c373ad" Archived-At: Subject: Re: [OAUTH-WG] Review of Device Flow Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:55:21 -0000 --94eb2c05dbae2cb99e0554c373ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the review Justin. - =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous (tim= er-based) > or in reaction to a user action at the device. There are no protocol > differences and the AS shouldn=E2=80=99t do try and inform the user, but = we can at > least mention that in our description of polling. +1 and I will highlight this in the IETF99 review. - =C2=A73.3.1 I still think this optimized all-in-one URI should be a separ= ate > parameter from the AS so as not to conflate it with the =E2=80=9Cplain=E2= =80=9D > verification URI. This would allow for all-in-one URLs that differ significantly from the current composite ones, is that why you're suggesting this? (if so: to solve what use-case?) What benefits do you see in this alternative approach? I think generally it's seen as bad form to repeat information, so keen to here why you think this is the case. Are you dialing in to the WG meeting tomorrow? Other than those two topics, the rest seem pretty uncontentious, I will review and action as appropriate before the next draft. Please call out any other items in this list that you feel warrant group discussion at IETF99. William On Thu, Jul 6, 2017 at 7:48 PM, Justin Richer wrote: > Finally had a chance to review the device flow draft in earnest. Overall > it=E2=80=99s really great, and we=E2=80=99ve implemented it in a few plac= es (see my recent > post on one interesting use case). Just a few notes: > > - use of =E2=80=9Cflow=E2=80=9D has largely been replaced by =E2=80=9Caut= horization grant=E2=80=9D in > other documents and we should be consistent here > - use of =E2=80=9Cend-user=E2=80=9D has been replaced by =E2=80=9Cresourc= e owner=E2=80=9D in other > documents and we should be consistent here > - =E2=80=9Cinput constrained=E2=80=9D should be =E2=80=9Cinput-constraine= d=E2=80=9D as used in the title, > abstract, and introduction. > - =C2=A71=C2=B63 could be rewritten to a bulleted list of requirements in= stead for > readability > - =C2=A71=C2=B64 could add something to address recent discussion on the = list: > =E2=80=9CWhile this polling is usually automatic and repeated on a regula= rly timed > basis, the client could poll based on user action with the device such as= a > button press.=E2=80=9D > - =C2=A71 diagram (D) should state that the user is prompted to enter the= user > code given in (C) and that the user does so =E2=80=94 leaving it out is a= n > optimization (see below) and the likely exception > - =C2=A72 should probably be =C2=A71.1, or move the protocol flow to =C2= =A71.1 and make > =C2=A72 into =C2=A71.2 > - =C2=A72 should import all terms used from 6749/6750 explicitly > - =C2=A72 should we define =E2=80=9Csecondary device=E2=80=9D once at the= top instead of the > parenthetical definition used throughout? > - =C2=A73.1=C2=B61 Wording is awkward with double =E2=80=9Cby=E2=80=9D ph= rases, suggest: =E2=80=9CThe client > initiates the authorization grant request by making an HTTP POST request = to > the device authorization endpoint.=E2=80=9D > - =C2=A73.2 add xref to JSON (7159), response is a JSON object with the > following members (not parameters) > - =C2=A73.2 is there any requirement for the verification_uri to be over = HTTPS? > I can=E2=80=99t see any discussion of this anywhere and it should probabl= y at least > be in the security considerations, if not an outright requirement. We say > that authentication is done in a tls-protected session in =C2=A73.3 but w= e don=E2=80=99t > say anything about the actual URL or the page in which the user enters th= e > code. > - =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous (t= imer-based) > or in reaction to a user action at the device. There are no protocol > differences and the AS shouldn=E2=80=99t do try and inform the user, but = we can at > least mention that in our description of polling. > - =C2=A73.3.1 I still think this optimized all-in-one URI should be a sep= arate > parameter from the AS so as not to conflate it with the =E2=80=9Cplain=E2= =80=9D > verification URI. > - =C2=A73.4=C2=B63 instead of =E2=80=9Cbased on the error code in the res= ponse=E2=80=9D perhaps > =E2=80=9Cuntil the authorization server indicates the device code has exp= ired or > was cancelled.=E2=80=9D =E2=80=94 I=E2=80=99m less sure about the wording= here but as written it > feels awkward. > - =C2=A73.5 I agree with the point made on the list about the error code, > =E2=80=9Caccess_denied=E2=80=9D would fit this bill but right now it=E2= =80=99s only specified on > authorization endpoint response, so let=E2=80=99s add its use to the toke= n response > here > - =C2=A73.5=C2=B64 says to return =E2=80=9Cinvalid_grant=E2=80=9D if the = codes are expired, but in > the same section it says to use =E2=80=9Cexpired_code=E2=80=9D. > - =C2=A73.5=C2=B65 the interval between polls SHOULD be at least the =E2= =80=9Cinterval=E2=80=9D > value. Also, it MUST be greater than zero =E2=80=A6 William =E2=80=A6 > - =C2=A75.2 =E2=80=9Cuser=E2=80=99s session and device=E2=80=9D, use of = =E2=80=9Cdevice=E2=80=9D here is confusing > since this is the =E2=80=9Cdevice=E2=80=9D flow. Maybe explicitly call ou= t this as the > =E2=80=9Csecondary device=E2=80=9D > - =C2=A75.5 extra =E2=80=9Cor=E2=80=9D in list in final sentence > > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c05dbae2cb99e0554c373ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the review Justin.

- = =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous (timer= -based) or in reaction to a user action at the device. There are no protoco= l differences and the AS shouldn=E2=80=99t do try and inform the user, but = we can at least mention that in our description of polling.

+1 and I will highlight this in the IETF99 review.<= /div>

- =C2=A73.3.1 I still think this optimized all-= in-one URI should be a separate parameter from the AS so as not to conflate= it with the =E2=80=9Cplain=E2=80=9D verification URI.
<= div>=C2=A0
This would allow for all-in-one URLs that differ signi= ficantly from the current composite ones, is that why you're suggesting= this? =C2=A0(if so: to solve what use-case?)

What= benefits do you see in this alternative approach?

I think generally it's seen as bad form to repeat information, so keen= to here why you think this is the case.

Are you d= ialing in to the WG meeting tomorrow?

Other than t= hose two topics, the rest seem pretty uncontentious, I will review and acti= on as appropriate before the next draft. Please call out any other items in= this list that you feel warrant group discussion at IETF99.

=
William


On Thu, Jul 6, 2017 at 7:48 PM, Justin Richer <jricher@= mit.edu> wrote:
Finally had a chance to review the device flow draft in earnest. Ov= erall it=E2=80=99s really great, and we=E2=80=99ve implemented it in a few = places (see my recent post on one interesting use case). Just a few notes:<= br>
- use of =E2=80=9Cflow=E2=80=9D has largely been replaced by =E2=80=9Cautho= rization grant=E2=80=9D in other documents and we should be consistent here=
- use of =E2=80=9Cend-user=E2=80=9D has been replaced by =E2=80=9Cresource = owner=E2=80=9D in other documents and we should be consistent here
- =E2=80=9Cinput constrained=E2=80=9D should be =E2=80=9Cinput-constrained= =E2=80=9D as used in the title, abstract, and introduction.
- =C2=A71=C2=B63 could be rewritten to a bulleted list of requirements inst= ead for readability
- =C2=A71=C2=B64 could add something to address recent discussion on the li= st: =E2=80=9CWhile this polling is usually automatic and repeated on a regu= larly timed basis, the client could poll based on user action with the devi= ce such as a button press.=E2=80=9D
- =C2=A71 diagram (D) should state that the user is prompted to enter the u= ser code given in (C) and that the user does so =E2=80=94 leaving it out is= an optimization (see below) and the likely exception
- =C2=A72 should probably be =C2=A71.1, or move the protocol flow to =C2=A7= 1.1 and make =C2=A72 into =C2=A71.2
- =C2=A72 should import all terms used from 6749/6750 explicitly
- =C2=A72 should we define =E2=80=9Csecondary device=E2=80=9D once at the t= op instead of the parenthetical definition used throughout?
- =C2=A73.1=C2=B61 Wording is awkward with double =E2=80=9Cby=E2=80=9D phra= ses, suggest: =E2=80=9CThe client initiates the authorization grant request= by making an HTTP POST request to the device authorization endpoint.=E2=80= =9D
- =C2=A73.2 add xref to JSON (7159), response is a JSON object with the fol= lowing members (not parameters)
- =C2=A73.2 is there any requirement for the verification_uri to be over HT= TPS? I can=E2=80=99t see any discussion of this anywhere and it should prob= ably at least be in the security considerations, if not an outright require= ment. We say that authentication is done in a tls-protected session in =C2= =A73.3 but we don=E2=80=99t say anything about the actual URL or the page i= n which the user enters the code.
- =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous (tim= er-based) or in reaction to a user action at the device. There are no proto= col differences and the AS shouldn=E2=80=99t do try and inform the user, bu= t we can at least mention that in our description of polling.
- =C2=A73.3.1 I still think this optimized all-in-one URI should be a separ= ate parameter from the AS so as not to conflate it with the =E2=80=9Cplain= =E2=80=9D verification URI.
- =C2=A73.4=C2=B63 instead of =E2=80=9Cbased on the error code in the respo= nse=E2=80=9D perhaps =E2=80=9Cuntil the authorization server indicates the = device code has expired or was cancelled.=E2=80=9D =E2=80=94 I=E2=80=99m le= ss sure about the wording here but as written it feels awkward.
- =C2=A73.5 I agree with the point made on the list about the error code, = =E2=80=9Caccess_denied=E2=80=9D would fit this bill but right now it=E2=80= =99s only specified on authorization endpoint response, so let=E2=80=99s ad= d its use to the token response here
- =C2=A73.5=C2=B64 says to return =E2=80=9Cinvalid_grant=E2=80=9D if the co= des are expired, but in the same section it says to use =E2=80=9Cexpired_co= de=E2=80=9D.
- =C2=A73.5=C2=B65 the interval between polls SHOULD be at least the =E2=80= =9Cinterval=E2=80=9D value. Also, it MUST be greater than zero =E2=80=A6 Wi= lliam =E2=80=A6
- =C2=A75.2 =E2=80=9Cuser=E2=80=99s session and device=E2=80=9D, use of =E2= =80=9Cdevice=E2=80=9D here is confusing since this is the =E2=80=9Cdevice= =E2=80=9D flow. Maybe explicitly call out this as the =E2=80=9Csecondary de= vice=E2=80=9D
- =C2=A75.5 extra =E2=80=9Cor=E2=80=9D in list in final sentence


=C2=A0=E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--94eb2c05dbae2cb99e0554c373ad-- From nobody Thu Jul 20 11:01:42 2017 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 1257E131D22 for ; Thu, 20 Jul 2017 11:01:41 -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_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 GGeQNVynZlEX for ; Thu, 20 Jul 2017 11:01:37 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 7CF7712EC5D for ; Thu, 20 Jul 2017 11:01:37 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id o88so14867264pfk.3 for ; Thu, 20 Jul 2017 11:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=J77jhGiWKn5La+Flex4qwMTVurJmlKI4CUCbJ9RACUg=; b=mCfAToAFu0703anpGtYyfltvt+qkDgKDsdeHg6C32w4Knj+Ib/U8WMVlm3jmnmAuwk DXKSdq/d7o9lMw3vpGgRjJKGb9OjxV6k1ZyOISlv9RsCUgFewdONI4zG3716qfxXbOee vCVAKvnazxXGU/UioxT2mgG6D6/8ByTBrVFjpp8cpLNqh2fFhCLZ67bRBuwB09UoWQ7m VN5T9I+mLZSa0AhjuesC0aCxOwWG9M0v88ebvg6W8eJLK8h4Z3P3uVzIsS9kdvnMEepP RDJCQdatnyOBerHb/elNDN//W1+u1BQEWpEFcbTXzZN5Z8TuZl1Z+84CSrbQ9rmAlGfT Tmig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=J77jhGiWKn5La+Flex4qwMTVurJmlKI4CUCbJ9RACUg=; b=UVAeLYCbDjkw3E2wmhn5wAsA6Um0KmUr4P0st2PnmU72hat8/7P9MHO1efrzmKA3pV tPiinpyEsjYF6BMlepVmE4Lm5a7Tp/oyqaE+U9dDqp0pRvhuMDz4XhZunTpu9kzjCO0I ujKRekzmMaNsogCQMv8rUcckGH/xo2dJAo3srMjDY5DlrJnTKxQNRLHxl889n2wy0gcV yY9/L16SYfngr/m5l5BUD+rz9+tczP8KV1tJjmhMVB3Sj2hq+1J5+3mFSghqcheO0KGi +3vwiCdX7FUuEW7GUyrlMV5YHcOvSD2Ly69dJ8uyjWju+jWqJn2kfn1ZW6raGOfjlmJY MKPw== X-Gm-Message-State: AIVw1133716T++TrZkRvps0kiYYOnSlVXERq8DjPMgGBliXRVf3fFPtx LmWQ/5x2CUi8kXd2lB/aDw== X-Received: by 10.98.245.207 with SMTP id b76mr4699511pfm.113.1500573696958; Thu, 20 Jul 2017 11:01:36 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:c9e2:58ea:e319:1853]) by smtp.googlemail.com with ESMTPSA id w70sm5801373pfd.15.2017.07.20.11.01.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 11:01:36 -0700 (PDT) To: Rifaat Shekh-Yusef , oauth References: From: Jim Manico Message-ID: <6c92a6c4-5ccf-2790-9245-4820fea3f949@manicode.com> Date: Thu, 20 Jul 2017 08:01:34 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E109480F7EC9D01CA416FE67" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:01:41 -0000 This is a multi-part message in MIME format. --------------E109480F7EC9D01CA416FE67 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I support adoption of this document. Aloha, Jim On 7/20/17 2:37 AM, Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the > adoption of the *JSON Web Token Best Current Practices* as a WG document > https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ > > > Please, let us know if you support or object to the adoption of this > document. > > Regards, > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------E109480F7EC9D01CA416FE67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I support adoption of this document.

Aloha, Jim


On 7/20/17 2:37 AM, Rifaat Shekh-Yusef wrote:
All,

We would like to get a confirmation on the mailing list for the adoption of the JSON Web Token Best Current Practices as a WG document

Please, let us know if you support or object to the adoption of this document.

Regards,
 Rifaat



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

--------------E109480F7EC9D01CA416FE67-- From nobody Thu Jul 20 11:12:36 2017 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 74D33131A69 for ; Thu, 20 Jul 2017 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 dotS5ZstGFvk for ; Thu, 20 Jul 2017 11:12:31 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 47D8D131B7A for ; Thu, 20 Jul 2017 11:12:26 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id b40so29245239qtb.2 for ; Thu, 20 Jul 2017 11:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E+O2pvWstuOmT3P0NJUonJKhWS9ki5YsjbDs44iJqW4=; b=rGhrSUwhXr87/KXRgzcNOytijoO0LZ0qiN/oXPZDu18GgC0VEPZ7pVA4YUlNT02d+u MAc1XB5xl4VQwxGEJTvIDgWJ7QstQPEdAe+q9dY4UATSegEJbMLBf1J4WaalOiryGsJX so9FpJU+pp78BR9Gfv9f9yvjxQb4XvCiSogAW3E+0vn2ftLqvTu9et7vPtxzV7AohtLW /yA2ulNM86u1jY0X+En9x1JY1lzrsVfVy399my97P5CBaZiwgZCH1+nky6zkaZLVSfOj taUAXnzyNOyxJLG1dAqRG3yxhESByCQaTuZFSYq67GcxL3aQ+VqZ1ZQROG87nistA2+a Cr5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E+O2pvWstuOmT3P0NJUonJKhWS9ki5YsjbDs44iJqW4=; b=AVQs/reJfQBKqK0LQHo5KRQRnMqiEqlEJ2JQcAzcXdDwuiMAf1IJVLdx67GSvKbtBS TrQ1kmuRyoSNp3h6gxROKzEAmKUo5GTg0dN0rr9kB8wX+hBkY+BSUj7V6CfvjoydJqhO gWNYoAtLL6dLF6O4sS5NAAlJNgmXcxDTFkfQHgVTeYN94dmoi8/0gxYkimn+7WAYCcgp gFdzvP0a6A4NnqFXGSo/iAI7EISDGurPFbjG5PP5hDFoVbXIcJfiIrhRo9MGmsNtCeyg fk2PdzkeBYglWytzypY3xJLIQJueGzUklsjPbg2DQvAQGiLevFzqwcmjvORsd6VcM6UL Xv5g== X-Gm-Message-State: AIVw113BtUD/dvnCf+eYs6DllnU8FhzyJq2Ep912tjzV6ysYgVs0hpkV UjxW2n9JH8oi64sNiUUbR87IFm7nbQdnnFtdWQ== X-Received: by 10.200.4.140 with SMTP id s12mr6279187qtg.35.1500574344953; Thu, 20 Jul 2017 11:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.144 with HTTP; Thu, 20 Jul 2017 11:12:04 -0700 (PDT) In-Reply-To: <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com> References: <8C513CFD-FDBE-4958-952A-6D518CA22627@iwelcome.com> From: William Denniss Date: Thu, 20 Jul 2017 19:12:04 +0100 Message-ID: To: Jaap Francke Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="f4030435b49ccaf5d10554c3b0b2" Archived-At: Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:12:35 -0000 --f4030435b49ccaf5d10554c3b0b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We'd thought of this too. In fact our param names are almost identical to yours. Here is my list from last year: device_id =3D a manufacturer device id so we can link apps on the 1 device = in order to present it as a single entity for revocation device_model =3D the manufacturer's name, like "Roku 3" or "Chromecast" device_name =3D user nickname e.g "William's Chromecast" The point to ask for this information from the device would be to display a better revocation page. If you have multiple Roku devices, it's nice to know which one you want to disconnect (e.g. "Livingroom"). Also if you authorized multiple different apps (with different client_ids) the device_id can be used to revoke them all at once (great for the lost/sold device case). Since it seems the 3 of us thought of this independently, it's probably worth adding to the discussion at IETF99 tomorrow. Will you join Jaap? it's open to remote participants if you're not in Prague. Justin, I like your more generic proposal to solve this for clients with multiple instances. I think the use-case has morphed from unregistered clients to native apps =E2=80=93 but broadly the requirement is the same. I= guess there's no overlap with this (rather old) proposal since the Device Authorization endpoint is technically a different endpoint to OAuth 2.0 (even if some param names and functions are shared), but if your draft were to be ever be revived it might be nice to sync the param names. Do you see that happening? Jaap, I'm not sure how device and instance params are different in your proposal, is that just capturing the difference between the model and the user's custom name as I did with the _model and _name params here? The client itself already has different metadata too, so different device deployments can already register different clients. William On Tue, Jul 11, 2017 at 10:49 AM, Jaap Francke wrote: > Hi Justin, > > Thanks for your reply. > > I had missed your proposal, but it=E2=80=99s indeed the same line-of-thou= ght. > My proposal is slightly different in the sense that the device_name (or: > instance_name) would not originate from the client itself but from the > ResourceOwner, e.g. during the authorisation process. > This is probably specific or at least more relevant to devices with input > constraints. > > I understand the point about dynamic client registration. > At a first glance it seems very =E2=80=98open=E2=80=99, whereas in a lot = of case you > wouldn=E2=80=99t want any client to register. > Moreover, I feel that using dynamic client registration just for the sake > of setting up identifiers for a client instance seems a bit =E2=80=98heav= y=E2=80=99. > So I still feel it=E2=80=99s usefull to enhance the Device flow with some= thing > like: device_identifier / device_name / instance_name / instance_descript= ion > > regards, Jaap > > > > Message: 2 > > Date: Fri, 7 Jul 2017 07:54:13 -0400 > > From: Justin Richer > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow > > Message-ID: <71e43e3c-2bd3-d706-2c82-6020de8ff881@mit.edu> > > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > > > > I proposed this exact thing many years ago: > > > > https://tools.ietf.org/html/draft-richer-oauth-instance-00 > > > > At the time there wasn't very much interest in it, as people were > > looking at using Dynamic Registration, with its attendant unique client > > IDs, to solve that same problem. > > > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --f4030435b49ccaf5d10554c3b0b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We'd thought of this too. In fact our param names are = almost identical to yours. Here is my list from last year:

device_id =3D a manufacturer device id so we can link apps on = the 1 device in order to present it as a single entity for revocation
=
device_model =3D the manufacturer's name, like "Roku 3" = or "Chromecast"
device_name =3D user nickname e.g "= ;William's Chromecast"

The po= int to ask for this information from the device would be to display a bette= r revocation page. If you have multiple Roku devices, it's nice to know= which one you want to disconnect (e.g. "Livingroom"). Also if yo= u authorized multiple different apps (with different client_ids) the device= _id can be used to revoke them all at once (great for the lost/sold device = case).

Since it seems the 3 of us thought of this = independently, it's probably worth adding to the discussion at IETF99 t= omorrow. Will you join Jaap? it's open to remote participants if you= 9;re not in Prague.

Justin, I like your more gener= ic proposal to solve this for clients with multiple instances. I think the = use-case has morphed from unregistered clients to native apps =E2=80=93 but= broadly the requirement is the same. I guess there's no overlap with t= his (rather old) proposal since the Device Authorization endpoint is techni= cally a different endpoint to OAuth 2.0 (even if some param names and funct= ions are shared), but if your draft were to be ever be revived it might be = nice to sync the param names. Do you see that happening?

Jaap, I'm not sure how device and instance params are diffe= rent in your proposal, is that just capturing the difference between the mo= del and the user's custom name as I did with the _model and _name param= s here? The client itself already has different metadata too, so different = device deployments can already register different clients.
=
William

On Tue, Jul 11, 2017 at 10:49 AM, Jaap Francke <jaap.francke@iwelcome.com> wrote:
Hi Justin,

Thanks for your reply.

I had missed your proposal, but it=E2=80=99s indeed the same line-of-though= t.
My proposal is slightly different in the sense that the device_name (or: in= stance_name) would not originate from the client itself but from the Resour= ceOwner, e.g. during the authorisation process.
This is probably specific or at least more relevant to devices with input c= onstraints.

I understand the point about dynamic client registration.
At a first glance it seems very =E2=80=98open=E2=80=99, whereas in a lot of= case you wouldn=E2=80=99t want any client to register.
Moreover, I feel that using dynamic client registration just for the sake o= f setting up identifiers for a client instance seems a bit =E2=80=98heavy= =E2=80=99.
So I still feel it=E2=80=99s usefull to enhance the Device flow with someth= ing like: device_identifier / device_name / instance_name / instance_descri= ption

regards, Jaap


> Message: 2
> Date: Fri, 7 Jul 2017 07:54:13 -0400
> From: Justin Richer <jricher@mit= .edu>
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow=
> Message-ID: <71e43e3c-2bd3-d706-2c82-6020de8ff881@mit.edu>
> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed
>
> I proposed this exact thing many years ago:
>
> https://tools.ietf.org/html/draf= t-richer-oauth-instance-00
>
> At the time there wasn't very much interest in it, as people were<= br> > looking at using Dynamic Registration, with its attendant unique clien= t
> IDs, to solve that same problem.
>
>=C2=A0 -- Justin

____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--f4030435b49ccaf5d10554c3b0b2-- From nobody Thu Jul 20 11:26:22 2017 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 0446F131A4F for ; Thu, 20 Jul 2017 11:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 OmM5BBokW5G0 for ; Thu, 20 Jul 2017 11:26:19 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 C704413191D for ; Thu, 20 Jul 2017 11:26:18 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w126so31410959wme.0 for ; Thu, 20 Jul 2017 11:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rM5VunZlhtTvaadjWx534hffal+t3ZgxMTGIAVXcTlM=; b=d260a9MHWPFdeVhzmMMONFeNqFx+QivEaJQhqZsu+z52J6t5GFfjdqTv4usV3sAIcm HVZIs9A4heBwyO8Gt5uP9mMsCGsIibHPYxeoAQC3SKH4hYBlzO4Lb+2N3DV80/uaYIJX tDTETC3Skz4XD19VK6MOox+Zuvga/Tzf8N2fT62FjFQxgZBvt/goFDAYK499WagXKtGT pva3Wp+Wpfn3UabrxR2v0R4PCHmJrvSVWdb/Q0CDzEFCF/6yisF7+hHD3k4kXDG6MMWd FPpgU3TJ64PM4fbUFQApqkVLFjy/KMJkdqg/A9FFdYwcf7lARwUEJTkxavq1vgsduuSC u/5Q== 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=rM5VunZlhtTvaadjWx534hffal+t3ZgxMTGIAVXcTlM=; b=q5HU5z3mqm2MVH55G5bA4cj5VD99V0GRJyB6pWSTlbbZ/srUv6ODFm219viiuMyrgZ 946u0U7rzgpr0lpx4nuXOFy6pnIGpwBYrh/W5W83CS6i5NQr2XJGBFLlTZpkencOD0WS peUVe7jUTy+YwG9RBy90jE0pMZgIBQ3C62UAPWNMg8uyMM6e4ZEzXkOOVxxT9tNZgVlD POfuJKIWWMlopUDWkHP3hR+y8keLxh2JhEVQeGeHd/rAW0IRWUfXq9jcUM6W5O3fqR8U oRc9HrYYH8nWHKbN4bWmiVsS+z1T9DDcbvNnfvsokLcpvGXY9cqlK8ZOf3b3+TgTKxva 4Ufg== X-Gm-Message-State: AIVw1110DjoUxKAWTcxycjjauuR6Hpnd5Yf0WnJC31KC8Utcjh8JWRIr u13ZDLj9L4FppN3U X-Received: by 10.28.222.70 with SMTP id v67mr2815790wmg.152.1500575176898; Thu, 20 Jul 2017 11:26:16 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:184:f17c:21ca:cf9d:daa0? ([2001:67c:1232:184:f17c:21ca:cf9d:daa0]) by smtp.gmail.com with ESMTPSA id 22sm9479631wru.29.2017.07.20.11.26.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 11:26:16 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 20:26:15 +0200 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b103c65fca90554c3e283" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:26:21 -0000 --001a114b103c65fca90554c3e283 Content-Type: multipart/alternative; boundary="Apple-Mail=_0CB89212-F302-4EEA-966C-56843A08C13A" --Apple-Mail=_0CB89212-F302-4EEA-966C-56843A08C13A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adoption > On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > We would like to get a confirmation on the mailing list for the = adoption of the JSON Web Token Best Current Practices as a WG document > https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ = >=20 > Please, let us know if you support or object to the adoption of this = document. >=20 > Regards, > Rifaat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0CB89212-F302-4EEA-966C-56843A08C13A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I support adoption

On = Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

All,

We = would like to get a confirmation on the mailing list for the adoption of = the JSON Web Token Best Current Practices as a WG = document
https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/

Please, let us know if you support or object to the adoption = of this document.

Regards,
 Rifaat

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

= --Apple-Mail=_0CB89212-F302-4EEA-966C-56843A08C13A-- --001a114b103c65fca90554c3e283 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIGJv86S76zUSncCItK4kzSzlqzb6 hZcKXG+ErMOeS/GIMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDcyMDE4MjYxN1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQB2yKkElTajYFebu2XVYnRqk5Awq4ZsRbm8PZdTJsLMX6d7 MXZIoGUFyI3q8aZoGF2JMIyrxZt9uDuCGYv4J8ONE5Yea/XfS/rE+y93tkAwAIWLXyevf9HMJocj 1wBqQA6ios25wiXSFcTn0nikfHBypOxBgOej6fNtUC11fxMFxZfsbZIAFQkcrJ73Zo8C6A3kCvUp xpQ5hllllYfZe0WmcQ15xvA/mOu7Hws5ck9SFNaJ34M/39BBW2yVG5ATsE7GO/MC7FZs70Scw4AU 83eGFWSuqturcfQnFO8Iq8BgQk0TgJAdnmeZlyiCZI18kDrb8Km8mLq9mC8ygzacI+K+ --001a114b103c65fca90554c3e283-- From nobody Thu Jul 20 11:48:06 2017 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 3FD30131B91 for ; Thu, 20 Jul 2017 11:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-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 1C1jJn8SiJDu for ; Thu, 20 Jul 2017 11:48:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 D6BE3131B9D for ; Thu, 20 Jul 2017 11:48:01 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6KIlxMt024710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jul 2017 18:48:00 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6KIlwjk009709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jul 2017 18:47:59 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v6KIlpqX010244; Thu, 20 Jul 2017 18:47:57 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jul 2017 11:47:46 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-4D8A2D0F-430F-43A8-9EE0-A1DEF83E48E1 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 20 Jul 2017 11:47:44 -0700 Cc: Rifaat Shekh-Yusef , oauth Content-Transfer-Encoding: 7bit Message-Id: <95E3EB63-AD89-4FDE-A100-1F7DA8122293@oracle.com> References: To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:48:04 -0000 --Apple-Mail-4D8A2D0F-430F-43A8-9EE0-A1DEF83E48E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 adoption Phil > On Jul 20, 2017, at 11:26 AM, John Bradley wrote: >=20 > I support adoption >=20 >> On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef w= rote: >>=20 >> All, >>=20 >> We would like to get a confirmation on the mailing list for the adoption o= f the JSON Web Token Best Current Practices as a WG document >> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ >>=20 >> Please, let us know if you support or object to the adoption of this docu= ment. >>=20 >> Regards, >> Rifaat >>=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 --Apple-Mail-4D8A2D0F-430F-43A8-9EE0-A1DEF83E48E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 adoption

Phil

= On Jul 20, 2017, at 11:26 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I support adoption

On Jul 20, 2017, at 2:37 PM, Rifaat S= hekh-Yusef <rifaat.ie= tf@gmail.com> wrote:

All,

=
We would like to get a confirmation on the mailing lis= t for the adoption of the JSON Web Token Best Current Practice= s as a WG document
https= ://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/

Please, let us know if you support or object to the adoption of= this document.

Re= gards,
 Rifaat

_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
= https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
= OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-4D8A2D0F-430F-43A8-9EE0-A1DEF83E48E1-- From nobody Thu Jul 20 12:23:29 2017 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 D9937129B61 for ; Thu, 20 Jul 2017 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-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 sPwsnBiQRxXY for ; Thu, 20 Jul 2017 12:23:25 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 4539112009C for ; Thu, 20 Jul 2017 12:23:25 -0700 (PDT) X-AuditID: 1209190f-ec3ff700000053a9-35-5971032a6db8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F2.97.21417.A2301795; Thu, 20 Jul 2017 15:23:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6KJNLnG021345; Thu, 20 Jul 2017 15:23:22 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6KJNJiJ013629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jul 2017 15:23:20 -0400 From: Justin Richer Message-Id: <8B9E47DA-248D-4447-A3B2-B889D8ABCFE9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBFE5C87-06EC-4B29-8ABF-D596525A4BEC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 15:23:19 -0400 In-Reply-To: Cc: "" To: William Denniss References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixCmqrKvDXBhp8GUfo8XJt6/YLDbNaWZ3 YPJYsKnUY8mSn0wBTFFcNimpOZllqUX6dglcGUt+TWIteNnJWLFl8WfWBsYlJV2MHBwSAiYS /fcduhi5OIQEFjNJPNz2jQnC2cgocXz/Z0YI5yGTRNOkw2xdjJwcbAKqEtPXtDCB2LwCVhKn l/5kBLGZBZIkts54yQgylVdAX6L3OZgpLGAs8X5mGkgFC1Bn38zbYNWcAoESPVOnsIKUMAuo S7SfdAEJiwhoSrw8e4AFxBYSaGSU2PBSGsSWEJCVuDX7EvMERv5ZSHbNQtgFEdaWWLbwNTOE rSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6OVmluilppRuYgQH tCT/DsY5Dd6HGAU4GJV4eBnWFUQKsSaWFVfmHmKU5GBSEuVlCQQK8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuE9/RUox5uSWFmVWpQPk5LmYFES5xXXaIwQEkhPLEnNTk0tSC2CycpwcChJ8JYx FUYKCRalpqdWpGXmlCCkmTg4QYbzAA3/AFLDW1yQmFucmQ6RP8XoyrGgZ8MXJo5NM35+Y+J4 NeE/kDz0+8R3Jo5jIFKIJS8/L1VKnLebEahZAKQ5ozQPbj4ocSW8PWz6ilEc6F1h3mcgVTzA pAe34RXQciag5Y/cQD4rLklESEk1MJrcjb4gOu2x/D2zz9M7G90y3TyZTLjOCCrW/+KfwHnH UH9u/ZyGAKGtzdWu6z7zFyX6FTgyaVmW9t/8/JyV3cNyzZTvl47McZq94JJinK15Z/oT7y99 OYvNfh3ZKNY6+/STB8xFZRq1Xx/s/yDL9vbHmh3bVDUvNE5zssrd8iL8TfryzizNH0osxRmJ hlrMRcWJADKAyyM3AwAA Archived-At: Subject: Re: [OAUTH-WG] Review of Device Flow Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 19:23:28 -0000 --Apple-Mail=_CBFE5C87-06EC-4B29-8ABF-D596525A4BEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline. > On Jul 20, 2017, at 1:54 PM, William Denniss = wrote: >=20 > Thank you for the review Justin. >=20 > - =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous = (timer-based) or in reaction to a user action at the device. There are = no protocol differences and the AS shouldn=E2=80=99t do try and inform = the user, but we can at least mention that in our description of = polling. >=20 > +1 and I will highlight this in the IETF99 review. Sounds good! >=20 > - =C2=A73.3.1 I still think this optimized all-in-one URI should be a = separate parameter from the AS so as not to conflate it with the = =E2=80=9Cplain=E2=80=9D verification URI. > =20 > This would allow for all-in-one URLs that differ significantly from = the current composite ones, is that why you're suggesting this? (if so: = to solve what use-case?) >=20 > What benefits do you see in this alternative approach? >=20 > I think generally it's seen as bad form to repeat information, so keen = to here why you think this is the case. The benefit is that each item of data is good for exactly one thing. One = is something the user needs to go and interact with and type the code, = one is where the user doesn=E2=80=99t need to type the code. Right now = there=E2=80=99s no way to tell them apart. Imagine if you=E2=80=99ve got = a simple device that displays the URI and code to the user, like the = set-top-box case. It tells the user: =E2=80=9CGo to = https://foo.bar/device/CODE-HERE and = type in CODE-HERE=E2=80=9D. So the user types in the longer URL and = isn=E2=80=99t prompted to enter the code that they were told they=E2=80=99= d have to enter. Did it work like it was supposed to even though the = instructions didn=E2=80=99t line up with how the AS (correctly) = processed things? I just see it leading to confusion where you=E2=80=99ve = got one client that assumes it=E2=80=99s baked in and one server that = assumes it=E2=80=99s not, or vice versa, leading to interop issues that = could be easily avoided. >=20 > Are you dialing in to the WG meeting tomorrow? Yes, I=E2=80=99ll be dialing in. 3:30am my time so I can=E2=80=99t = guarantee how chatty I=E2=80=99ll be, but I=E2=80=99ll be on. :) >=20 > Other than those two topics, the rest seem pretty uncontentious, I = will review and action as appropriate before the next draft. Please call = out any other items in this list that you feel warrant group discussion = at IETF99. >=20 Sounds good =E2=80=94 overall it=E2=80=99s a very solid draft.=20 =E2=80=94 Justin >=20 >=20 > On Thu, Jul 6, 2017 at 7:48 PM, Justin Richer > wrote: > Finally had a chance to review the device flow draft in earnest. = Overall it=E2=80=99s really great, and we=E2=80=99ve implemented it in a = few places (see my recent post on one interesting use case). Just a few = notes: >=20 > - use of =E2=80=9Cflow=E2=80=9D has largely been replaced by = =E2=80=9Cauthorization grant=E2=80=9D in other documents and we should = be consistent here > - use of =E2=80=9Cend-user=E2=80=9D has been replaced by =E2=80=9Cresour= ce owner=E2=80=9D in other documents and we should be consistent here > - =E2=80=9Cinput constrained=E2=80=9D should be = =E2=80=9Cinput-constrained=E2=80=9D as used in the title, abstract, and = introduction. > - =C2=A71=C2=B63 could be rewritten to a bulleted list of requirements = instead for readability > - =C2=A71=C2=B64 could add something to address recent discussion on = the list: =E2=80=9CWhile this polling is usually automatic and repeated = on a regularly timed basis, the client could poll based on user action = with the device such as a button press.=E2=80=9D > - =C2=A71 diagram (D) should state that the user is prompted to enter = the user code given in (C) and that the user does so =E2=80=94 leaving = it out is an optimization (see below) and the likely exception > - =C2=A72 should probably be =C2=A71.1, or move the protocol flow to = =C2=A71.1 and make =C2=A72 into =C2=A71.2 > - =C2=A72 should import all terms used from 6749/6750 explicitly > - =C2=A72 should we define =E2=80=9Csecondary device=E2=80=9D once at = the top instead of the parenthetical definition used throughout? > - =C2=A73.1=C2=B61 Wording is awkward with double =E2=80=9Cby=E2=80=9D = phrases, suggest: =E2=80=9CThe client initiates the authorization grant = request by making an HTTP POST request to the device authorization = endpoint.=E2=80=9D > - =C2=A73.2 add xref to JSON (7159), response is a JSON object with = the following members (not parameters) > - =C2=A73.2 is there any requirement for the verification_uri to be = over HTTPS? I can=E2=80=99t see any discussion of this anywhere and it = should probably at least be in the security considerations, if not an = outright requirement. We say that authentication is done in a = tls-protected session in =C2=A73.3 but we don=E2=80=99t say anything = about the actual URL or the page in which the user enters the code. > - =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous = (timer-based) or in reaction to a user action at the device. There are = no protocol differences and the AS shouldn=E2=80=99t do try and inform = the user, but we can at least mention that in our description of = polling. > - =C2=A73.3.1 I still think this optimized all-in-one URI should be a = separate parameter from the AS so as not to conflate it with the = =E2=80=9Cplain=E2=80=9D verification URI. > - =C2=A73.4=C2=B63 instead of =E2=80=9Cbased on the error code in the = response=E2=80=9D perhaps =E2=80=9Cuntil the authorization server = indicates the device code has expired or was cancelled.=E2=80=9D =E2=80=94= I=E2=80=99m less sure about the wording here but as written it feels = awkward. > - =C2=A73.5 I agree with the point made on the list about the error = code, =E2=80=9Caccess_denied=E2=80=9D would fit this bill but right now = it=E2=80=99s only specified on authorization endpoint response, so = let=E2=80=99s add its use to the token response here > - =C2=A73.5=C2=B64 says to return =E2=80=9Cinvalid_grant=E2=80=9D if = the codes are expired, but in the same section it says to use = =E2=80=9Cexpired_code=E2=80=9D. > - =C2=A73.5=C2=B65 the interval between polls SHOULD be at least the = =E2=80=9Cinterval=E2=80=9D value. Also, it MUST be greater than zero =E2=80= =A6 William =E2=80=A6 > - =C2=A75.2 =E2=80=9Cuser=E2=80=99s session and device=E2=80=9D, use = of =E2=80=9Cdevice=E2=80=9D here is confusing since this is the = =E2=80=9Cdevice=E2=80=9D flow. Maybe explicitly call out this as the = =E2=80=9Csecondary device=E2=80=9D > - =C2=A75.5 extra =E2=80=9Cor=E2=80=9D in list in final sentence >=20 >=20 > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_CBFE5C87-06EC-4B29-8ABF-D596525A4BEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline.

On Jul 20, 2017, at 1:54 PM, = William Denniss <wdenniss@google.com> wrote:

Thank you for the review = Justin.

- =C2=A73.3=C2=B63 as mentioned above, the polling could be = continuous (timer-based) or in reaction to a user action at the device. = There are no protocol differences and the AS shouldn=E2=80=99t do try = and inform the user, but we can at least mention that in our description = of polling.

+1 and I will highlight this in the IETF99 = review.

Sounds good!


- =C2=A73.3.1 I still think this optimized all-in-one URI = should be a separate parameter from the AS so as not to conflate it with = the =E2=80=9Cplain=E2=80=9D verification URI.
 
This would allow for all-in-one = URLs that differ significantly from the current composite ones, is that = why you're suggesting this?  (if so: to solve what = use-case?)

What = benefits do you see in this alternative approach?
I think generally it's seen as bad = form to repeat information, so keen to here why you think this is the = case.

The = benefit is that each item of data is good for exactly one thing. One is = something the user needs to go and interact with and type the code, one = is where the user doesn=E2=80=99t need to type the code. Right now = there=E2=80=99s no way to tell them apart. Imagine if you=E2=80=99ve got = a simple device that displays the URI and code to the user, like the = set-top-box case. It tells the user: =E2=80=9CGo to https://foo.bar/device/CODE-HERE and type in = CODE-HERE=E2=80=9D. So the user types in the longer URL and isn=E2=80=99t = prompted to enter the code that they were told they=E2=80=99d have to = enter. Did it work like it was supposed to even though the instructions = didn=E2=80=99t line up with how the AS (correctly) processed things? I = just see it leading to confusion where you=E2=80=99ve got one client = that assumes it=E2=80=99s baked in and one server that assumes it=E2=80=99= s not, or vice versa, leading to interop issues that could be easily = avoided.


Are you dialing in to the WG meeting = tomorrow?

Yes, I=E2=80=99ll be dialing in. 3:30am my time so = I can=E2=80=99t guarantee how chatty I=E2=80=99ll be, but I=E2=80=99ll = be on. :)


Other than those two topics, the rest = seem pretty uncontentious, I will review and action as appropriate = before the next draft. Please call out any other items in this list that = you feel warrant group discussion at IETF99.


Sounds good =E2=80=94 overall it=E2=80=99s a very = solid draft. 

 =E2=80=94 = Justin


On Thu, Jul 6, 2017 at 7:48 PM, Justin Richer = <jricher@mit.edu> wrote:
Finally = had a chance to review the device flow draft in earnest. Overall it=E2=80=99= s really great, and we=E2=80=99ve implemented it in a few places (see my = recent post on one interesting use case). Just a few notes:
=
- use of =E2=80=9Cflow=E2=80=9D has largely been replaced by = =E2=80=9Cauthorization grant=E2=80=9D in other documents and we should = be consistent here
- use of =E2=80=9Cend-user=E2=80=9D has been replaced by =E2=80=9Cresource= owner=E2=80=9D in other documents and we should be consistent here
- =E2=80=9Cinput constrained=E2=80=9D should be =E2=80=9Cinput-constrained= =E2=80=9D as used in the title, abstract, and introduction.
= - =C2=A71=C2=B63 could be rewritten to a bulleted list of requirements = instead for readability
- =C2=A71=C2=B64 could add something to address recent discussion on the = list: =E2=80=9CWhile this polling is usually automatic and repeated on a = regularly timed basis, the client could poll based on user action with = the device such as a button press.=E2=80=9D
- =C2=A71 diagram (D) should state that the user is prompted to enter = the user code given in (C) and that the user does so =E2=80=94 leaving = it out is an optimization (see below) and the likely exception
- =C2=A72 should probably be =C2=A71.1, or move the protocol flow to = =C2=A71.1 and make =C2=A72 into =C2=A71.2
- =C2=A72 should import all terms used from 6749/6750 explicitly
- =C2=A72 should we define =E2=80=9Csecondary device=E2=80=9D once at = the top instead of the parenthetical definition used throughout?
- =C2=A73.1=C2=B61 Wording is awkward with double =E2=80=9Cby=E2=80=9D = phrases, suggest: =E2=80=9CThe client initiates the authorization grant = request by making an HTTP POST request to the device authorization = endpoint.=E2=80=9D
- =C2=A73.2 add xref to JSON (7159), response is a JSON object with the = following members (not parameters)
- =C2=A73.2 is there any requirement for the verification_uri to be over = HTTPS? I can=E2=80=99t see any discussion of this anywhere and it should = probably at least be in the security considerations, if not an outright = requirement. We say that authentication is done in a tls-protected = session in =C2=A73.3 but we don=E2=80=99t say anything about the actual = URL or the page in which the user enters the code.
- =C2=A73.3=C2=B63 as mentioned above, the polling could be continuous = (timer-based) or in reaction to a user action at the device. There are = no protocol differences and the AS shouldn=E2=80=99t do try and inform = the user, but we can at least mention that in our description of = polling.
- =C2=A73.3.1 I still think this optimized all-in-one URI should be a = separate parameter from the AS so as not to conflate it with the = =E2=80=9Cplain=E2=80=9D verification URI.
- =C2=A73.4=C2=B63 instead of =E2=80=9Cbased on the error code in the = response=E2=80=9D perhaps =E2=80=9Cuntil the authorization server = indicates the device code has expired or was cancelled.=E2=80=9D =E2=80=94= I=E2=80=99m less sure about the wording here but as written it feels = awkward.
- =C2=A73.5 I agree with the point made on the list about the error = code, =E2=80=9Caccess_denied=E2=80=9D would fit this bill but right now = it=E2=80=99s only specified on authorization endpoint response, so = let=E2=80=99s add its use to the token response here
- =C2=A73.5=C2=B64 says to return =E2=80=9Cinvalid_grant=E2=80=9D if the = codes are expired, but in the same section it says to use = =E2=80=9Cexpired_code=E2=80=9D.
- =C2=A73.5=C2=B65 the interval between polls SHOULD be at least the = =E2=80=9Cinterval=E2=80=9D value. Also, it MUST be greater than zero =E2=80= =A6 William =E2=80=A6
- =C2=A75.2 =E2=80=9Cuser=E2=80=99s session and device=E2=80=9D, use of = =E2=80=9Cdevice=E2=80=9D here is confusing since this is the = =E2=80=9Cdevice=E2=80=9D flow. Maybe explicitly call out this as the = =E2=80=9Csecondary device=E2=80=9D
- =C2=A75.5 extra =E2=80=9Cor=E2=80=9D in list in final sentence


 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_CBFE5C87-06EC-4B29-8ABF-D596525A4BEC-- From nobody Thu Jul 20 20:43:41 2017 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 5B7FE131DA7; Thu, 20 Jul 2017 20:43:33 -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: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150060861333.11040.14662316804367431887@ietfa.amsl.com> Date: Thu, 20 Jul 2017 20:43:33 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 03:43:33 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-14.txt Pages : 27 Date : 2017-07-20 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-14 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 Thu Jul 20 22:08:33 2017 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 33B5E12EAAA for ; Thu, 20 Jul 2017 22:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl8IhuktR_Sk for ; Thu, 20 Jul 2017 22:08:29 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 138B0126C23 for ; Thu, 20 Jul 2017 22:08:28 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 123so23858024pgj.1 for ; Thu, 20 Jul 2017 22:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUD34IIRpyI5z/MCmKRS+xTPSaiyWJLROT10g6IynIw=; b=PWg2ZazTwv4BA/ALhQjjMTnq2dNPVajo6aeZIqSIwUU8Rba+yiG/z4PDLQNaB/Znov NHy21pf3nEsqcQVa/igG5D1eilbmnLKl1lw6y8z+LqOb3N++8KBRX5nHpaBqiGq6K9M+ eEEAQOk8skfqfnaBZyYv2ZdNnO3MQvbq0bz8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MUD34IIRpyI5z/MCmKRS+xTPSaiyWJLROT10g6IynIw=; b=c3fXR6WrdbZ5JIHTpFRXC+rSCWNk4AVJSDxwfGcrY0jNehVniKHi6rO0w1iBjUZrXq 2URkIQhIQEkVBmXQ6n6wtaSGJ6lqONRVZ+NWG4nrjaveyK/rITVC/8iNMJF/1nOfIBOe dmqTpg31DsmT1Cr4/qi6oFA9A/3EKiXAf2EtP5CuXPkQLhoUWXjS4UyWzFVutekFnq/m FWYrYeUNetkvaCLIN27oDlTsULaLW9xUKYQ6GIZx1v/LLKCfHsXz4ze64zetN/ZDCftn RKoEu86BTcvlituFQN/Jhf/YFH+FyAg0DABa2MeuFsEIxvVGSSHDKKuKGKDeZ/J+t+Ol t9mg== X-Gm-Message-State: AIVw113MHLiPwbNs9/HxgG1nHcargrLV5QQnb5Eg9QXcGC5qTWg7z+kS /NUU538s+smCFHNQ6TttRe3RVvSp8T82+mcH8nPWF1mhgsoAUYYFQKrNk/Sedb4JHT/8FFWbcO7 sqjJWRlg= X-Received: by 10.98.82.87 with SMTP id g84mr6333278pfb.232.1500613708590; Thu, 20 Jul 2017 22:08:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Thu, 20 Jul 2017 22:07:57 -0700 (PDT) In-Reply-To: <95E3EB63-AD89-4FDE-A100-1F7DA8122293@oracle.com> References: <95E3EB63-AD89-4FDE-A100-1F7DA8122293@oracle.com> From: Brian Campbell Date: Fri, 21 Jul 2017 07:07:57 +0200 Message-ID: To: "Phil Hunt (IDM)" Cc: John Bradley , oauth Content-Type: multipart/alternative; boundary="94eb2c03cf2c0bd25c0554ccdb52" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 05:08:31 -0000 --94eb2c03cf2c0bd25c0554ccdb52 Content-Type: text/plain; charset="UTF-8" +1 for adoption On Thu, Jul 20, 2017 at 8:47 PM, Phil Hunt (IDM) wrote: > +1 adoption > > Phil > > On Jul 20, 2017, at 11:26 AM, John Bradley wrote: > > I support adoption > > On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef > wrote: > > All, > > We would like to get a confirmation on the mailing list for the adoption > of the *JSON Web Token Best Current Practices* as a WG document > https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ > > Please, let us know if you support or object to the adoption of this > document. > > Regards, > Rifaat > > _______________________________________________ > 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 > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c03cf2c0bd25c0554ccdb52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption

On Thu, Jul 20, 2017 at 8:47 PM, Phil Hunt (IDM) <phil= .hunt@oracle.com> wrote:
+1 adoption

Phil

On Jul = 20, 2017, at 11:26 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I support adoption

On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>= wrote:

=
All,

We would like to get a confir= mation on the mailing list for the adoption of the JSON Web Token Best C= urrent Practices as a WG document
=

Please, let us know if you support or object to the ado= ption of this document.

Regards,
=C2=A0R= ifaat

_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

__= _____________________________________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/oauth

________= _______________________________________
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. --94eb2c03cf2c0bd25c0554ccdb52-- From nobody Fri Jul 21 04:08:21 2017 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 B4AE7129B7A; Fri, 21 Jul 2017 04:08:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150063529362.11223.247358061664246970.idtracker@ietfa.amsl.com> Date: Fri, 21 Jul 2017 04:08:13 -0700 Archived-At: Subject: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-jwsreq-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:08:14 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-jwsreq-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS point. New nit: URN needs a reference to RFC 8141. From nobody Fri Jul 21 05:57:15 2017 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 81B7F131C19; Fri, 21 Jul 2017 05:57:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MsWDbxEKSjss; Fri, 21 Jul 2017 05:57:11 -0700 (PDT) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFB8131C14; Fri, 21 Jul 2017 05:57:11 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id 6C55319685B; Fri, 21 Jul 2017 21:57:10 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 073224E0046; Fri, 21 Jul 2017 21:57:10 +0900 (JST) Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v6LCv9UZ027562; Fri, 21 Jul 2017 21:57:09 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp with ESMTP id v6LCv99l027558; Fri, 21 Jul 2017 21:57:09 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LCv97G032337; Fri, 21 Jul 2017 21:57:09 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v6LCv9CT032336; Fri, 21 Jul 2017 21:57:09 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LCv9hw032333; Fri, 21 Jul 2017 21:57:09 +0900 Received: from NatRZ4 (unknown [172.21.163.103]) by nrivpnfs02.index.or.jp (Postfix) with ESMTP id 1FCE458167; Fri, 21 Jul 2017 21:57:03 +0900 (JST) From: "Nat Sakimura" To: "'Alexey Melnikov'" , "'The IESG'" Cc: , , , References: <150063529362.11223.247358061664246970.idtracker@ietfa.amsl.com> In-Reply-To: <150063529362.11223.247358061664246970.idtracker@ietfa.amsl.com> Date: Fri, 21 Jul 2017 21:57:07 +0900 Message-ID: <01a601d30220$e0336530$a09a2f90$@nri.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Thread-Index: AQHGTRawwACr7lS1Waw7uAIM0l2doKJ3p0ug Content-Language: ja Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-jwsreq-14: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 12:57:14 -0000 Thanks Alexey, and sorry for taking this long.=20 I will fix the nits about URN ASAP.=20 Best,=20 Nat -- =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6= =9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81= =AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85= =E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84 =E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81= =AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85= =E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3=81=AE=E3=81=86=E3=81=88=E3=80=81 =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3= =81=97=E3=81=A6=E4=B8=8B=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81= =86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE= =E3=81=99=E3=80=82 PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Friday, July 21, 2017 8:08 PM > To: The IESG > Cc: draft-ietf-oauth-jwsreq@ietf.org; oauth-chairs@ietf.org; > Hannes.Tschofenig@gmx.net; oauth@ietf.org > Subject: Alexey Melnikov's No Objection on draft-ietf-oauth-jwsreq-14: = (with > COMMENT) >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-jwsreq-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for addressing my DISCUSS point. >=20 > New nit: URN needs a reference to RFC 8141. From nobody Fri Jul 21 05:59:21 2017 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 DAB6E131CFD for ; Fri, 21 Jul 2017 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-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 DyWcrZYDWooK for ; Fri, 21 Jul 2017 05:59:16 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0093.outbound.protection.outlook.com [104.47.38.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8147131D1C for ; Fri, 21 Jul 2017 05:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EfvOoOZRicyfpvDjDyTxebPLkBaagYRSUNE2rnZQH7o=; b=S5FKh1uEPmeLDgmdzTOIEgnyjrJMQG/fMMGf52Aw0840J7LJ4i/JyQIvOx6TRvd0s5Jojz90MQ9eX7+qSDfiyMJl7iMznLooeKF+a4+8yngZE9u75hC5p4+uK4NWDn31n6KBTfydmggyrUpXNLaGC2meXZaLKnS99XZAi2AfjMo= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0134.namprd21.prod.outlook.com (10.173.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Fri, 21 Jul 2017 12:59:12 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1304.009; Fri, 21 Jul 2017 12:59:12 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Working Group Meeting at IETF 99 21-Jul-17 Thread-Index: AdMCIQS/uo4eihLgSNaU9zJwyl9/HA== Date: Fri, 21 Jul 2017 12:59:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:67c:1232:144:4422:9589:299f:2232] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0134; 7:S9gGoqe1YTgEizoY/yNU/rxmJEIdLu1B9FzsyImEgtPxOdeLCJrnUurQfVAZ93Uh9cFwufar0r2EdmyFP+v03hAVuMZ9dO/KYvEWBm53zM17LiQcToF1Hdo0sCjhQw38gYRkOu2S+quIRITcM+6pa8aggchilY4uMg+9zJXFt0GXq03pPJXH9y9thyULeYStyNOnU7Ssdi8qUgQeyPVLJ9dds5p+y75z4DPz68H1TeIXxttOqOeSSpkSgSoiW11iTqdzPAAPau4QuZx0Yd5v77uFQyhLBeeB3Ygzowr5m1BTI+Y2x2WM61MliDU6dBlid091BKRlH95Yp9ZExg8rE/dy0YXNFRvJPN7zq7jQL8fcfWgjWuSGK+EhINy8ChuOTJjhTPFaGFcLUZSzE/N0VfgNLon5BHsEcnVY4VCXAIA7KJlVkoO1hG65fINATOHt/HatU5o9XNg+S+KDeJnZYhYi/pbair6vEe0tgGBq/vqqxGyIb9mwyq49xzXF6MB2Oc339pm9MKfYkO6DK5QhWwzu/ekqGJ/9ZtT4kfuZQD77V6Eq5r5dEOz/Mv8k7mKP6PMMTW6ibqoIITVoE7hn3ZcCVDAjZE++LDY5P5fS9B1wbqdRcsCjFjEmqsoJMemHOlBYndn5LWAD1zuHwF+MSDAzkcCyp75SbkS10M0MF23kdSo3hUnLe8Qgt3ayDBlImqJfOXhCqnxH+tTSo2nQDaoYpURoMc7jHp06pF6VHeM+UHJgtoAnsgDDJbVVoC58UYYSyS3IvIrQ9uLZlx0/xy+IrWXG7RMDrIKQmEWUOm8zFYGWX8u8NNR/hlRKAwkk x-ms-office365-filtering-correlation-id: 38558e5a-c707-41cd-edd0-08d4d038490e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0134; x-ms-traffictypediagnostic: CY4PR21MB0134: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(26388249023172)(192374486261705)(21748063052155)(151999592597050); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0134; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0134; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39860400002)(39450400003)(39410400002)(39840400002)(39850400002)(47760400005)(199003)(189002)(51444003)(2351001)(7696004)(106356001)(3280700002)(3660700001)(54356999)(101416001)(86362001)(86612001)(50986999)(105586002)(2906002)(33656002)(189998001)(230783001)(97736004)(10090500001)(102836003)(790700001)(6116002)(5660300001)(2900100001)(74316002)(6436002)(25786009)(14454004)(99286003)(9686003)(2501003)(6306002)(8936002)(5640700003)(54896002)(5630700001)(1730700003)(8676002)(72206003)(81156014)(81166006)(6916009)(53936002)(68736007)(7736002)(10290500003)(77096006)(6506006)(38730400002)(55016002)(110136004)(478600001)(8990500004)(5005710100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0134; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504BECECAE0BFB0E13D906FF5A40CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 12:59:12.6043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0134 Archived-At: Subject: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 12:59:21 -0000 --_000_CY4PR21MB0504BECECAE0BFB0E13D906FF5A40CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth Working Group Meeting at IETF 99 21-Jul-17 William Denniss presented on the Device Flow Justin Richer discussed a suggestion to add another parameter that he'd mad= e on the list William Denniss clarified that the client constructs the URL - not the serv= er Justin withdrew his suggestion Justin will review the text and suggest clarifications to help people from = misunderstanding it in the way that he did Annabelle Backman suggested that there be a separate parameter that contain= s the clickable URL Annabelle suggested that there be a separate parameter for that URL Then we don't have to standardize the URL for the user_code It would allow the server to use a different URL for that Dick Hardt suggested that the user code be URL safe Annabelle: People implementing clients may not always be reading the specs David Robin: There's an opportunity to send people straight to the final UR= L Nat Sakimura: Our implementation sends both the URL and the user_code Nat: It's easier to enter Japanese characters than ASCII in Japan We should allow the code to be Unicode Dick Hardt: Amazon recently looked at what can be entered world wide He said that numbers work really well William: Maybe we can suggest that numbers be used as a best practice I do not want to prevent the use of letters because it would = bring our implementation out of compliance Mike Jones: Microsoft also uses letters in the codes Nat: If we are targeting QR codes, send the QR code directly QR codes are used on ATM machines in Singapore and Australia If it's going to be an image, it should be a separate paramet= er Annabelle: Trying to tailor the spec to particular delivery mechanisms wou= ld take us down a huge rathole Dick: It's not clear we're really trying to achieve interop William: Justin and I did interop testing with both of our implementations Dick: Amazon is using independently written implementations In the Alexa world, there are many third parties producing de= vices that we want to be able to make calls into Alexa John: I am influenced by the arguments that having a different endpoint fo= r the pre-composed URL than the user typeable one is a good idea I don't know that we should add the QR code directly Apps could use introspection to get a QR code or sound files = but that doesn't have to be in the standard Third party clients operate with YouTube and other services William: There are two changes we're discussing 1. Having a second endpoint for the pre-composed URL 2. Saying that the user code should be URL safe, with number= s recommended William: If we make it Unicode, we should use a different URL Mike Jones: Adding a separate endpoint is a big change John: The change is to have a separate parameter for the composed URL - no= t a separate endpoint Anything internationalized immediately leads us to sending a = composed URL Using a different endpoint is an implementation choice - not = something for the spec The client needs to know the script that it's going to displa= y A Korean printer might use Korean script in Korea but a diffe= rent script in South America Nat: Numbers are the best choice internationally Annabelle: The more complicated we make the display requirements, the more= use cases we'll exclude John: UTF-8 may not be displayable on all devices and the right fonts migh= t not even be installed Annabelle: We are suggesting a new parameter with a URL value - not a new = endpoint Leif Johansson: Has anyone done a security analysis on this? We shouldn't do these changes without another last call David Robin: Are we deprecating what's shown on the screen or is that optio= n still on the table? (On the screen, the client was shown merging the different pi= eces of information) Maybe client composition should never be done It's either opaque with the third parameter or you need to do= composition the way the draft is now Annabelle: The current draft does describe Security Considerations about r= emote phishing William: We try to prevent phishing by asking the user if they have the de= vice in their possession Lucy Lynch: These are big enough changes to require another working group = last call William: There's no requirement that you poll at any particular rate Mike Jones: From an engineering perspective, why do people want to do thin= gs differently than what's currently specified? Dick: We looked at this and saw some of the issues William: The other major change being considered is defining new authoriza= tion parameters device_id, device_model, device_name This is to support device revocation They are all optional Annabelle: This does not seem unique to the device flow William: I agree but it's worth solving for the device flow Annabelle: If we're overly prescriptive with what information is being sen= t, we could end up ruling out use cases we haven't thought of Hannes Tschofenig: This came up in Chicago We might want to do some form of authentication These parameters are intended for revocation, but they could = be used for authorization as well William: I'm not trying to capture every possible parameter for every use = case Google does have use cases for these parameters Dick: The device ID is problematic The other two new parameters are useful William: The device ID lets the authorization server group requests Annabelle: If this is happening at the AS, it could assign an ID on its ow= n Annabelle: Model and name present a potential phishing risk Hannes: The AS can't infer the device name Annabelle: The AS should match the client ID to the device type William: If we add these parameters we need to add Security Considerations William: We shouldn't enable display of random hacker-generated text Dick: The model allows multiple different things on a device For instance, enabling Netflix on your Roku - not just enabli= ng the device John: Device ID is a correlatable identifier Some manufacturers go out of their way to prevent multiple ap= plications from knowing that they're on the same device This is its own thing and should be in its own spec Let's finish the device spec and consider this a separate add= -on Lucy: I think that John summarized this correctly I could drive a truck through this Hannes: The context of this spec made discussing these possible parameters= reasonable Justin Richer: This loops back to Mike's question about why people are bri= nging this up now People have been implementing something like this for years Now people are reviewing the spec and asking if it fits the u= se cases they've had for years We are seeing more and more devices where this functionality = makes sense I think this should be a separate spec I wrote such as spec in 2010 draft-richer-oauth-instance-00 This has applicability in other places and it's a big ball of= wax It's too much to try to slip this in at the last minute Brian Campbell: Maybe we could accomplish this without device ID We would lose grouping but that would alleviate a lot of the = privacy concerns Dick: You only need a locally scoped identifier The global one is the one that's a problem William: There is running code Google's implementation complies with -06 MitreID implements it Justin and William did some interop Hannes: There are other open source implementations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Brian Campbell presented on OAuth Token Exchange It is a framework enabling token exchange The participants need to know what kinds of tokens are suitable for their u= se cases Draft -09 included small changes to address actionable WGLC feedback Hannes will review feedback that didn't appear to be actionable Brian believes it's ready for Hannes' write-up John: Write it up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Brian Campbell presented on OAuth Token Binding Provides proof of possession for OAuth tokens The 3 core Token Binding specs are very close to the request for publicatio= n The last OAuth Token Binding spec version added introspection language and = IANA registrations Brian added an open issue about the need to allow distributed Web Server cl= ients to opt out of token binding for refresh tokens Shared access to a public key may be difficult or impossible = problem Sharing on demand generated client-side keys is very hard Dick Hardt: It's not going to happen Brian: The real value is Token Binding the access token There are other means of securing the refresh token There are two ways we could do this Toggle the behavior based on client registration metadata Or provide a run-time toggle with a parameter The metadata parameters already largely exist Mike Jones: I think the metadata approach is reasonable I don't want to think about the security implications of prov= iding a parameter to disable a security feature at runtime Brian: I think the metadata approach is reasonable John Bradley: I agree with using metadata John Bradley: As a separate issue, we may eventually decide we need a para= meter to explicitly communicate the referred token binding separately from = the Sec-Token-Binding header There are more discussions needed on the parties using the bo= und tokens William Denniss: Is this only for confidential clients? Brian: Yes William: We don't want to encourage people to opt out very often John: We do have a mutual TLS option so there are more than one ways to ac= hieve proof of possession William: Authorization servers could say that access token binding is mand= atory Brian: Should the scope include standardization of Token Binding for JWT C= lient Authentication for RFC 7523 John: We should write this down because it's only self-evident how to do t= his to a very small set of people Brian: We would write down how to use the cnf/tbh claim in the context of = RFC 7523 Hannes: Please write this down Brian: We need to remove the reference to the expiring resource metadata d= raft Brian: I have ideas how to keep the intent but simplify We would still describe how to detect and respond to attacks Brian: This is still early Client library support is still sparse We have things to learn from deployments Dick: Is pushing Token Binding through to the end-application after TLS te= rmination in scope? Brian: No, but the Token Binding WG just accepted a document about this draft-campbell-tokbind-ttrp Dick: This doesn't provide the same guarantees as other application-layer = PoP mechanisms Brian: This relies upon trust between the TLS terminator and the applicati= on Brian: I don't know a way to tightly bind this end-to-end Dick: The verification is happening at the application Dick: I believe that Microsoft is encrypting the token Dick: The problem is that the TLS terminator is in a different trust domai= n than the application It's trusted to terminate TLS but not to manage the token or = do authentication or authorization Dick: What's being done in the Token Binding working group doesn't solve t= his problem John: I asked Tony Nadalin to provide information about this Including the possible use of additional Token Bindings Andrei Popov: I'm not familiar the higher-level functionality being refere= nced If you're terminating TLS, that's where end-to-end ends for T= LS functions, such as Token Binding You're trusting that the TLS terminator is passing correct in= formation to you Hannes: We need to update our OAuth PoP documents End-to-end PoP is definitely in scope for the OAuth WG Dick: You didn't solve anything Dirk Balfanz: It sounds like you already have a proof-of-possession implem= entation Dick: We have a non-standard way in which Amazon API calls are made There is a secret, you sign the request, and it's verified at= the application level Hannes: Is it HTTP signing? Dick: Yes It prevents a compromised TLS proxy from changing the request Justin Richer: I did look at the Amazon spec when writing the OAuth HTTP s= igning spec There were lots of problems with parameters being reordered, = etc. in OAuth 1 implementations Hannes: I would like Dick to look at the current OAuth HTTP signing spec Maybe that will solve the issue that Dick is describing Dick: That doesn't build on Token Binding Justin: They are orthogonal You could do both Token Binding and application-level PoP Dick: What I like about Token Binding is that you don't have to do client-= side management of a key Token Binding lets you get many of the characteristics of PoP= without client-side key management Hannes: What are the right next steps for this issue? Dick: I want Token Binding with end-to-end guarantees Dick: Most of our deployments have TLS proxies Brian: This isn't in scope for this document because the problem isn't spe= cific to OAuth Brian: This is also applicable to Token Bound cookies The same issues occur for cookies --_000_CY4PR21MB0504BECECAE0BFB0E13D906FF5A40CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OAuth Working Group Meeting at IETF 99 21-Jul-17

 

William Denniss presented on the Device Flow

 

Justin Richer discussed a suggestion to add another = parameter that he'd made on the list

William Denniss clarified that the client constructs= the URL - not the server

Justin withdrew his suggestion

Justin will review the text and suggest clarificatio= ns to help people from misunderstanding it in the way that he did

 

Annabelle Backman suggested that there be a separate= parameter that contains the clickable URL

Annabelle suggested that there be a separate paramet= er for that URL

        &nbs= p;     Then we don't have to standardize the URL for th= e user_code

        &nbs= p;     It would allow the server to use a different URL= for that

Dick Hardt suggested that the user code be URL safe<= o:p>

Annabelle:  People implementing clients may not= always be reading the specs

David Robin: There's an opportunity to send people s= traight to the final URL

Nat Sakimura: Our implementation sends both the URL = and the user_code

 

Nat: It's easier to enter Japanese characters than A= SCII in Japan

        &nbs= p;     We should allow the code to be Unicode

Dick Hardt:  Amazon recently looked at what can= be entered world wide

        &nbs= p;     He said that numbers work really well=

William:  Maybe we can suggest that numbers be = used as a best practice

        &nbs= p;     I do not want to prevent the use of letters beca= use it would bring our implementation out of compliance

Mike Jones:  Microsoft also uses letters in the= codes

 

Nat:  If we are targeting QR codes, send the QR= code directly

        &nbs= p;     QR codes are used on ATM machines in Singapore a= nd Australia

        &nbs= p;     If it's going to be an image, it should be a sep= arate parameter

 

Annabelle:  Trying to tailor the spec to partic= ular delivery mechanisms would take us down a huge rathole

Dick:  It's not clear we're really trying to ac= hieve interop

William:  Justin and I did interop testing with= both of our implementations

Dick:  Amazon is using independently written im= plementations

        &nbs= p;     In the Alexa world, there are many third parties= producing devices that we want to be able to make calls into Alexa

 

John:  I am influenced by the arguments that ha= ving a different endpoint for the pre-composed URL than the user typeable o= ne is a good idea

        &nbs= p;     I don't know that we should add the QR code dire= ctly

        &nbs= p;     Apps could use introspection to get a QR code or= sound files but that doesn't have to be in the standard

        &nbs= p;     Third party clients operate with YouTube and oth= er services

 

William:  There are two changes we're discussin= g

        &nbs= p;     1.  Having a second endpoint for the pre-co= mposed URL

        &nbs= p;     2.  Saying that the user code should be URL= safe, with numbers recommended

 

William:  If we make it Unicode, we should use = a different URL

 

Mike Jones:  Adding a separate endpoint is a bi= g change

John:  The change is to have a separate paramet= er for the composed URL - not a separate endpoint

        &nbs= p;     Anything internationalized immediately leads us = to sending a composed URL

        &nbs= p;     Using a different endpoint is an implementation = choice - not something for the spec

        &nbs= p;     The client needs to know the script that it's go= ing to display

        &nbs= p;     A Korean printer might use Korean script in Kore= a but a different script in South America

Nat:  Numbers are the best choice international= ly

Annabelle:  The more complicated we make the di= splay requirements, the more use cases we'll exclude

John:  UTF-8 may not be displayable on all devi= ces and the right fonts might not even be installed

Annabelle:  We are suggesting a new parameter w= ith a URL value - not a new endpoint

 

Leif Johansson:  Has anyone done a security ana= lysis on this?

        &nbs= p;     We shouldn't do these changes without another la= st call

 

David Robin: Are we deprecating what's shown on the = screen or is that option still on the table?

        &nbs= p;     (On the screen, the client was shown merging the= different pieces of information)

        &nbs= p;     Maybe client composition should never be done

        &nbs= p;     It's either opaque with the third parameter or y= ou need to do composition the way the draft is now

 

Annabelle:  The current draft does describe Sec= urity Considerations about remote phishing

William:  We try to prevent phishing by asking = the user if they have the device in their possession

 

Lucy Lynch:  These are big enough changes to re= quire another working group last call

 

William:  There's no requirement that you poll = at any particular rate

 

Mike Jones:  From an engineering perspective, w= hy do people want to do things differently than what's currently specified?=

Dick:  We looked at this and saw some of the is= sues

 

William:  The other major change being consider= ed is defining new authorization parameters

        &nbs= p;     device_id, device_model, device_name<= /p>

        &nbs= p;     This is to support device revocation<= /p>

        &nbs= p;     They are all optional

 

Annabelle:  This does not seem unique to the de= vice flow

William:  I agree but it's worth solving for th= e device flow

Annabelle:  If we're overly prescriptive with w= hat information is being sent, we could end up ruling out use cases we have= n't thought of

Hannes Tschofenig:  This came up in Chicago

        &nbs= p;     We might want to do some form of authentication<= o:p>

        &nbs= p;     These parameters are intended for revocation, bu= t they could be used for authorization as well

William:  I'm not trying to capture every possi= ble parameter for every use case

        &nbs= p;     Google does have use cases for these parameters<= o:p>

Dick:  The device ID is problematic<= /p>

        &nbs= p;     The other two new parameters are useful

William:  The device ID lets the authorization = server group requests

Annabelle:  If this is happening at the AS, it = could assign an ID on its own

Annabelle:  Model and name present a potential = phishing risk

Hannes:  The AS can't infer the device name

Annabelle:  The AS should match the client ID t= o the device type

 

William:  If we add these parameters we need to= add Security Considerations

William:  We shouldn't enable display of random= hacker-generated text

 

Dick:  The model allows multiple different thin= gs on a device

        &nbs= p;     For instance, enabling Netflix on your Roku - no= t just enabling the device

 

John:  Device ID is a correlatable identifier

        &nbs= p;     Some manufacturers go out of their way to preven= t multiple applications from knowing that they're on the same device

        &nbs= p;     This is its own thing and should be in its own s= pec

        &nbs= p;     Let's finish the device spec and consider this a= separate add-on

Lucy:  I think that John summarized this correc= tly

        &nbs= p;     I could drive a truck through this

Hannes:  The context of this spec made discussi= ng these possible parameters reasonable

 

Justin Richer:  This loops back to Mike's quest= ion about why people are bringing this up now

        &nbs= p;     People have been implementing something like thi= s for years

        &nbs= p;     Now people are reviewing the spec and asking if = it fits the use cases they've had for years

        &nbs= p;     We are seeing more and more devices where this f= unctionality makes sense

        &nbs= p;     I think this should be a separate spec

        &nbs= p;     I wrote such as spec in 2010 draft-richer-oauth-= instance-00

        &nbs= p;     This has applicability in other places and it's = a big ball of wax

        &nbs= p;     It's too much to try to slip this in at the last= minute

 

Brian Campbell:  Maybe we could accomplish this= without device ID

        &nbs= p;     We would lose grouping but that would alleviate = a lot of the privacy concerns

Dick:  You only need a locally scoped identifie= r

        &nbs= p;     The global one is the one that's a problem<= /o:p>

 

William:  There is running code

        &nbs= p;     Google's implementation complies with -06

        &nbs= p;     MitreID implements it

        &nbs= p;     Justin and William did some interop

Hannes:  There are other open source implementa= tions

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Brian Campbell presented on OAuth Token Exchange

 

It is a framework enabling token exchange=

The participants need to know what kinds of tokens a= re suitable for their use cases

Draft -09 included small changes to address actionab= le WGLC feedback

Hannes will review feedback that didn't appear to be= actionable

Brian believes it's ready for Hannes' write-up<= /o:p>

John:  Write it up

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Brian Campbell presented on OAuth Token Binding=

 

Provides proof of possession for OAuth tokens

The 3 core Token Binding specs are very close to the= request for publication

The last OAuth Token Binding spec version added intr= ospection language and IANA registrations

Brian added an open issue about the need to allow di= stributed Web Server clients to opt out of token binding for refresh tokens=

        &nbs= p;     Shared access to a public key may be difficult o= r impossible problem

        &nbs= p;     Sharing on demand generated client-side keys is = very hard

Dick Hardt:  It's not going to happen

Brian:  The real value is Token Binding the acc= ess token

        &nbs= p;     There are other means of securing the refresh to= ken

There are two ways we could do this

        &nbs= p;     Toggle the behavior based on client registration= metadata

        &nbs= p;     Or provide a run-time toggle with a parameter

The metadata parameters already largely exist

Mike Jones:  I think the metadata approach is r= easonable

        &nbs= p;     I don't want to think about the security implica= tions of providing a parameter to disable a security feature at runtime

Brian:  I think the metadata approach is reason= able

John Bradley:  I agree with using metadata=

 

John Bradley:  As a separate issue, we may even= tually decide we need a parameter to explicitly communicate the referred to= ken binding separately from the Sec-Token-Binding header

        &nbs= p;     There are more discussions needed on the parties= using the bound tokens

William Denniss:  Is this only for confidential= clients?

        &nbs= p;     Brian:  Yes

William:  We don't want to encourage people to = opt out very often

John:  We do have a mutual TLS option so there = are more than one ways to achieve proof of possession

William:  Authorization servers could say that = access token binding is mandatory

 

Brian:  Should the scope include standardizatio= n of Token Binding for JWT Client Authentication for RFC 7523

John:  We should write this down because it's o= nly self-evident how to do this to a very small set of people

Brian:  We would write down how to use the cnf/= tbh claim in the context of RFC 7523

Hannes:  Please write this down

 

Brian:  We need to remove the reference to the = expiring resource metadata draft

Brian:  I have ideas how to keep the intent but= simplify

        &nbs= p;     We would still describe how to detect and respon= d to attacks

 

Brian:  This is still early

        &nbs= p;     Client library support is still sparse

        &nbs= p;     We have things to learn from deployments

 

Dick:  Is pushing Token Binding through to the = end-application after TLS termination in scope?

Brian:  No, but the Token Binding WG just accep= ted a document about this

        &nbs= p;     draft-campbell-tokbind-ttrp

Dick:  This doesn't provide the same guarantees= as other application-layer PoP mechanisms

Brian:  This relies upon trust between the TLS = terminator and the application

Brian:  I don't know a way to tightly bind this= end-to-end

Dick:  The verification is happening at the app= lication

Dick:  I believe that Microsoft is encrypting t= he token

Dick:  The problem is that the TLS terminator i= s in a different trust domain than the application

        &nbs= p;     It's trusted to terminate TLS but not to manage = the token or do authentication or authorization

Dick:  What's being done in the Token Binding w= orking group doesn't solve this problem

 

John:  I asked Tony Nadalin to provide informat= ion about this

        &nbs= p;     Including the possible use of additional Token B= indings

Andrei Popov:  I'm not familiar the higher-leve= l functionality being referenced

        &nbs= p;     If you're terminating TLS, that's where end-to-e= nd ends for TLS functions, such as Token Binding

        &nbs= p;     You're trusting that the TLS terminator is passi= ng correct information to you

Hannes:  We need to update our OAuth PoP docume= nts

        &nbs= p;     End-to-end PoP is definitely in scope for the OA= uth WG

Dick:  You didn't solve anything

Dirk Balfanz:  It sounds like you already have = a proof-of-possession implementation

Dick:  We have a non-standard way in which Amaz= on API calls are made

        &nbs= p;     There is a secret, you sign the request, and it'= s verified at the application level

Hannes:  Is it HTTP signing?

Dick:  Yes

        &nbs= p;     It prevents a compromised TLS proxy from changin= g the request

Justin Richer:  I did look at the Amazon spec w= hen writing the OAuth HTTP signing spec

        &nbs= p;     There were lots of problems with parameters bein= g reordered, etc. in OAuth 1 implementations

Hannes:  I would like Dick to look at the curre= nt OAuth HTTP signing spec

        &nbs= p;     Maybe that will solve the issue that Dick is des= cribing

Dick:  That doesn't build on Token Binding=

Justin:  They are orthogonal

        &nbs= p;     You could do both Token Binding and application-= level PoP

Dick:  What I like about Token Binding is that = you don't have to do client-side management of a key

        &nbs= p;     Token Binding lets you get many of the character= istics of PoP without client-side key management

Hannes:  What are the right next steps for this= issue?

Dick:  I want Token Binding with end-to-end gua= rantees

Dick:  Most of our deployments have TLS proxies=

Brian:  This isn't in scope for this document b= ecause the problem isn't specific to OAuth

Brian:  This is also applicable to Token Bound = cookies

        &nbs= p;     The same issues occur for cookies

--_000_CY4PR21MB0504BECECAE0BFB0E13D906FF5A40CY4PR21MB0504namp_-- From nobody Fri Jul 21 06:14:36 2017 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 B1D12131E05; Fri, 21 Jul 2017 06:14:29 -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: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150064286970.11282.3667890765398413872@ietfa.amsl.com> Date: Fri, 21 Jul 2017 06:14:29 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:14:30 -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 : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-15.txt Pages : 26 Date : 2017-07-21 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-15 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-15 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 Jul 21 06:25:53 2017 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 B8C8812EBF7 for ; Fri, 21 Jul 2017 06:25:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 48AW-8BaO167 for ; Fri, 21 Jul 2017 06:25:50 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B731317D5 for ; Fri, 21 Jul 2017 06:25:49 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 37BDC472EE0 for ; Fri, 21 Jul 2017 22:25:49 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 8FD0E4E0046 for ; Fri, 21 Jul 2017 22:25:48 +0900 (JST) Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v6LDPmE0031280 for ; Fri, 21 Jul 2017 22:25:48 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp with ESMTP id v6LDPmcD031279 for ; Fri, 21 Jul 2017 22:25:48 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LDPmVi026179; Fri, 21 Jul 2017 22:25:48 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v6LDPman026178; Fri, 21 Jul 2017 22:25:48 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LDPmXj026174 for ; Fri, 21 Jul 2017 22:25:48 +0900 Received: from NatRZ4 (unknown [172.21.163.103]) by nrivpnfs02.index.or.jp (Postfix) with ESMTP id 983525816A for ; Fri, 21 Jul 2017 22:25:45 +0900 (JST) From: "Nat Sakimura" To: References: <150064286988.11282.3403961378795912731.idtracker@ietfa.amsl.com> In-Reply-To: <150064286988.11282.3403961378795912731.idtracker@ietfa.amsl.com> Date: Fri, 21 Jul 2017 22:25:49 +0900 Message-ID: <01c101d30224$e0519ec0$a0f4dc40$@nri.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Thread-Index: AQKVKIy4ShU2Xp2Er7lXbFHzf0wIqKDZ+F5g Content-Language: ja Archived-At: Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-jwsreq-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:25:52 -0000 Hi This version hopefully have addressed all the comments that I received = during IESG review.=20 I also added RFC8141 as the reference to URN.=20 The main difference from -12 that was posted in March are:=20 1) Now, all the parameters to be used MUST reside within the request = object.=20 (It is still possible to be duplicated but they are ignored from the = security point of view by the server that supports this spec.) 2) Clarified that when request object is stored by the authorization = server, `request_uri` can be a URN.=20 3) Added text on the security risks of using `request_uri` in the = security consideration.=20 Best,=20 Nat Sakimura -- PLEASE READ :This e-mail is confidential and intended for the named = recipient only. If you are not an intended recipient, please notify the = sender and delete this e-mail. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 21, 2017 10:14 PM > To: Nat Sakimura ; John Bradley=20 > > Subject: New Version Notification for draft-ietf-oauth-jwsreq-15.txt >=20 >=20 > A new version of I-D, draft-ietf-oauth-jwsreq-15.txt has been=20 > successfully submitted by Nat Sakimura and posted to the IETF = repository. >=20 > Name: draft-ietf-oauth-jwsreq > Revision: 15 > Title: The OAuth 2.0 Authorization Framework: JWT Secured > Authorization Request (JAR) > Document date: 2017-07-21 > Group: oauth > Pages: 26 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-15.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-15 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-15 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-15 >=20 > Abstract: > The authorization request in OAuth 2.0 described in RFC 6749 = utilizes > query parameter serialization, which means that Authorization = Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, = it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. >=20 > This document introduces the ability to send request parameters in = a > JSON Web Token (JWT) instead, which allows the request to be signed > with JSON Web Signature (JWS) and encrypted with JSON Web = Encryption > (JWE) so that the integrity, source authentication and > confidentiality property of the Authorization Request is attained. > The request can be sent by value or by reference. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat From nobody Fri Jul 21 08:55:15 2017 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 E5F1E13178B for ; Fri, 21 Jul 2017 08:55:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 haFRjG1WQ6DG for ; Fri, 21 Jul 2017 08:55:10 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 B3B53131935 for ; Fri, 21 Jul 2017 08:55:09 -0700 (PDT) X-AuditID: 1209190e-69dff70000004181-02-597223da7f21 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 64.05.16769.BD322795; Fri, 21 Jul 2017 11:55:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v6LFt577029138; Fri, 21 Jul 2017 11:55:06 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6LFt4jP030719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jul 2017 11:55:05 -0400 From: Justin Richer Message-Id: <7659AE15-7BB6-4106-85C7-DC780B13C424@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Jul 2017 11:55:03 -0400 In-Reply-To: Cc: "" To: Mike Jones References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixG6nontbuSjS4PxnIYu90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGX0HzQu2LGYpWL2wX72BsYXl5i7GDk4JARM JGZd8ehi5OIQEljMJDF3128WCGcjo8S10z9YIZyHTBLLP8xm72Lk5GATUJWYvqaFCcTmFbCS mHm0lRXEZhZIktg/+y4jyFReAX2J3ueMIGFhAQ+JBe9mgpWzALU+ejgHzOYUiJU4vuUcWDmz gLpE+0kXkLCIgI7E44vf2EBsIYEYia5VD1lAbAkBWYlbsy8xT2Dkn4Vk2SyEZRBhbYllC18z Q9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZG UFBzSvLtYJzU4H2IUYCDUYmH14ClKFKINbGsuDL3EKMkB5OSKO/ddYWRQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4mwSAynlTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp2ampBalFMFkZDg4l CV5BJaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGhIDW8xQWJucWZ6RD5U4z2HJtm/PzGxPFqwn8g eej3ie9MHMdApBBLXn5eqpQ4b7oiUJsASFtGaR7cZFDCSnh72PQVozjQo8K8WSDDeYDJDm72 K6C1TEBrH7kVgKwtSURISTUwttS8m3rmoe/yuayX497UGm4PYuzbdumQ0Zqz04KSTcRbFZqP LLr+IVMxX3LV1xW7X7xfuGPNM9Elb9aWzzp83XL/zEgxrfD9h54Y7Kmuuzpjz8TYnN8WGy5/ YtX5bKzUdupVzu6n3Foc8pwHXrutPZOyR3Pt4YfrcpirjO9G/zr5LNU2pdDCKVSJpTgj0VCL uag4EQAlUb8VMwMAAA== Archived-At: Subject: Re: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:55:13 -0000 --Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So even though I withdrew my suggestion of adding a parameter to device = flow, that was only because my own direct reason was addressed, and I = support adding it back in for all the reasons that Annabelle and Dick = and John and others brought up in conversation.=20 =E2=80=94 Justin > On Jul 21, 2017, at 8:59 AM, Mike Jones = wrote: >=20 > OAuth Working Group Meeting at IETF 99 21-Jul-17 > =20 > William Denniss presented on the Device Flow > =20 > Justin Richer discussed a suggestion to add another parameter that = he'd made on the list > William Denniss clarified that the client constructs the URL - not the = server > Justin withdrew his suggestion > Justin will review the text and suggest clarifications to help people = from misunderstanding it in the way that he did > =20 > Annabelle Backman suggested that there be a separate parameter that = contains the clickable URL > Annabelle suggested that there be a separate parameter for that URL > Then we don't have to standardize the URL for the = user_code > It would allow the server to use a different URL for = that > Dick Hardt suggested that the user code be URL safe > Annabelle: People implementing clients may not always be reading the = specs > David Robin: There's an opportunity to send people straight to the = final URL > Nat Sakimura: Our implementation sends both the URL and the user_code > =20 > Nat: It's easier to enter Japanese characters than ASCII in Japan > We should allow the code to be Unicode > Dick Hardt: Amazon recently looked at what can be entered world wide > He said that numbers work really well > William: Maybe we can suggest that numbers be used as a best practice > I do not want to prevent the use of letters because it = would bring our implementation out of compliance > Mike Jones: Microsoft also uses letters in the codes > =20 > Nat: If we are targeting QR codes, send the QR code directly > QR codes are used on ATM machines in Singapore and = Australia > If it's going to be an image, it should be a separate = parameter > =20 > Annabelle: Trying to tailor the spec to particular delivery = mechanisms would take us down a huge rathole > Dick: It's not clear we're really trying to achieve interop > William: Justin and I did interop testing with both of our = implementations > Dick: Amazon is using independently written implementations > In the Alexa world, there are many third parties = producing devices that we want to be able to make calls into Alexa > =20 > John: I am influenced by the arguments that having a different = endpoint for the pre-composed URL than the user typeable one is a good = idea > I don't know that we should add the QR code directly > Apps could use introspection to get a QR code or sound = files but that doesn't have to be in the standard > Third party clients operate with YouTube and other = services > =20 > William: There are two changes we're discussing > 1. Having a second endpoint for the pre-composed URL > 2. Saying that the user code should be URL safe, with = numbers recommended > =20 > William: If we make it Unicode, we should use a different URL > =20 > Mike Jones: Adding a separate endpoint is a big change > John: The change is to have a separate parameter for the composed URL = - not a separate endpoint > Anything internationalized immediately leads us to = sending a composed URL > Using a different endpoint is an implementation choice - = not something for the spec > The client needs to know the script that it's going to = display > A Korean printer might use Korean script in Korea but a = different script in South America > Nat: Numbers are the best choice internationally > Annabelle: The more complicated we make the display requirements, the = more use cases we'll exclude > John: UTF-8 may not be displayable on all devices and the right fonts = might not even be installed > Annabelle: We are suggesting a new parameter with a URL value - not a = new endpoint > =20 > Leif Johansson: Has anyone done a security analysis on this? > We shouldn't do these changes without another last call > =20 > David Robin: Are we deprecating what's shown on the screen or is that = option still on the table? > (On the screen, the client was shown merging the = different pieces of information) > Maybe client composition should never be done > It's either opaque with the third parameter or you need = to do composition the way the draft is now > =20 > Annabelle: The current draft does describe Security Considerations = about remote phishing > William: We try to prevent phishing by asking the user if they have = the device in their possession > =20 > Lucy Lynch: These are big enough changes to require another working = group last call > =20 > William: There's no requirement that you poll at any particular rate > =20 > Mike Jones: =46rom an engineering perspective, why do people want to = do things differently than what's currently specified? > Dick: We looked at this and saw some of the issues > =20 > William: The other major change being considered is defining new = authorization parameters > device_id, device_model, device_name > This is to support device revocation > They are all optional > =20 > Annabelle: This does not seem unique to the device flow > William: I agree but it's worth solving for the device flow > Annabelle: If we're overly prescriptive with what information is = being sent, we could end up ruling out use cases we haven't thought of > Hannes Tschofenig: This came up in Chicago > We might want to do some form of authentication > These parameters are intended for revocation, but they = could be used for authorization as well > William: I'm not trying to capture every possible parameter for every = use case > Google does have use cases for these parameters > Dick: The device ID is problematic > The other two new parameters are useful > William: The device ID lets the authorization server group requests > Annabelle: If this is happening at the AS, it could assign an ID on = its own > Annabelle: Model and name present a potential phishing risk > Hannes: The AS can't infer the device name > Annabelle: The AS should match the client ID to the device type > =20 > William: If we add these parameters we need to add Security = Considerations > William: We shouldn't enable display of random hacker-generated text > =20 > Dick: The model allows multiple different things on a device > For instance, enabling Netflix on your Roku - not just = enabling the device > =20 > John: Device ID is a correlatable identifier > Some manufacturers go out of their way to prevent = multiple applications from knowing that they're on the same device > This is its own thing and should be in its own spec > Let's finish the device spec and consider this a = separate add-on > Lucy: I think that John summarized this correctly > I could drive a truck through this > Hannes: The context of this spec made discussing these possible = parameters reasonable > =20 > Justin Richer: This loops back to Mike's question about why people = are bringing this up now > People have been implementing something like this for = years > Now people are reviewing the spec and asking if it fits = the use cases they've had for years > We are seeing more and more devices where this = functionality makes sense > I think this should be a separate spec > I wrote such as spec in 2010 = draft-richer-oauth-instance-00 > This has applicability in other places and it's a big = ball of wax > It's too much to try to slip this in at the last minute > =20 > Brian Campbell: Maybe we could accomplish this without device ID > We would lose grouping but that would alleviate a lot of = the privacy concerns > Dick: You only need a locally scoped identifier > The global one is the one that's a problem > =20 > William: There is running code > Google's implementation complies with -06 > MitreID implements it > Justin and William did some interop > Hannes: There are other open source implementations > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Brian Campbell presented on OAuth Token Exchange > =20 > It is a framework enabling token exchange > The participants need to know what kinds of tokens are suitable for = their use cases > Draft -09 included small changes to address actionable WGLC feedback > Hannes will review feedback that didn't appear to be actionable > Brian believes it's ready for Hannes' write-up > John: Write it up > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > Brian Campbell presented on OAuth Token Binding > =20 > Provides proof of possession for OAuth tokens > The 3 core Token Binding specs are very close to the request for = publication > The last OAuth Token Binding spec version added introspection language = and IANA registrations > Brian added an open issue about the need to allow distributed Web = Server clients to opt out of token binding for refresh tokens > Shared access to a public key may be difficult or = impossible problem > Sharing on demand generated client-side keys is very = hard > Dick Hardt: It's not going to happen > Brian: The real value is Token Binding the access token > There are other means of securing the refresh token > There are two ways we could do this > Toggle the behavior based on client registration = metadata > Or provide a run-time toggle with a parameter > The metadata parameters already largely exist > Mike Jones: I think the metadata approach is reasonable > I don't want to think about the security implications of = providing a parameter to disable a security feature at runtime > Brian: I think the metadata approach is reasonable > John Bradley: I agree with using metadata > =20 > John Bradley: As a separate issue, we may eventually decide we need a = parameter to explicitly communicate the referred token binding = separately from the Sec-Token-Binding header > There are more discussions needed on the parties using = the bound tokens > William Denniss: Is this only for confidential clients? > Brian: Yes > William: We don't want to encourage people to opt out very often > John: We do have a mutual TLS option so there are more than one ways = to achieve proof of possession > William: Authorization servers could say that access token binding is = mandatory > =20 > Brian: Should the scope include standardization of Token Binding for = JWT Client Authentication for RFC 7523 > John: We should write this down because it's only self-evident how to = do this to a very small set of people > Brian: We would write down how to use the cnf/tbh claim in the = context of RFC 7523 > Hannes: Please write this down > =20 > Brian: We need to remove the reference to the expiring resource = metadata draft > Brian: I have ideas how to keep the intent but simplify > We would still describe how to detect and respond to = attacks > =20 > Brian: This is still early > Client library support is still sparse > We have things to learn from deployments > =20 > Dick: Is pushing Token Binding through to the end-application after = TLS termination in scope? > Brian: No, but the Token Binding WG just accepted a document about = this > draft-campbell-tokbind-ttrp > Dick: This doesn't provide the same guarantees as other = application-layer PoP mechanisms > Brian: This relies upon trust between the TLS terminator and the = application > Brian: I don't know a way to tightly bind this end-to-end > Dick: The verification is happening at the application > Dick: I believe that Microsoft is encrypting the token > Dick: The problem is that the TLS terminator is in a different trust = domain than the application > It's trusted to terminate TLS but not to manage the = token or do authentication or authorization > Dick: What's being done in the Token Binding working group doesn't = solve this problem > =20 > John: I asked Tony Nadalin to provide information about this > Including the possible use of additional Token Bindings > Andrei Popov: I'm not familiar the higher-level functionality being = referenced > If you're terminating TLS, that's where end-to-end ends = for TLS functions, such as Token Binding > You're trusting that the TLS terminator is passing = correct information to you > Hannes: We need to update our OAuth PoP documents > End-to-end PoP is definitely in scope for the OAuth WG > Dick: You didn't solve anything > Dirk Balfanz: It sounds like you already have a proof-of-possession = implementation > Dick: We have a non-standard way in which Amazon API calls are made > There is a secret, you sign the request, and it's = verified at the application level > Hannes: Is it HTTP signing? > Dick: Yes > It prevents a compromised TLS proxy from changing the = request > Justin Richer: I did look at the Amazon spec when writing the OAuth = HTTP signing spec > There were lots of problems with parameters being = reordered, etc. in OAuth 1 implementations > Hannes: I would like Dick to look at the current OAuth HTTP signing = spec > Maybe that will solve the issue that Dick is describing > Dick: That doesn't build on Token Binding > Justin: They are orthogonal > You could do both Token Binding and application-level = PoP > Dick: What I like about Token Binding is that you don't have to do = client-side management of a key > Token Binding lets you get many of the characteristics = of PoP without client-side key management > Hannes: What are the right next steps for this issue? > Dick: I want Token Binding with end-to-end guarantees > Dick: Most of our deployments have TLS proxies > Brian: This isn't in scope for this document because the problem = isn't specific to OAuth > Brian: This is also applicable to Token Bound cookies > The same issues occur for cookies > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So even though I withdrew my suggestion of adding a parameter = to device flow, that was only because my own direct reason was = addressed, and I support adding it back in for all the reasons that = Annabelle and Dick and John and others brought up in = conversation. 

 =E2=80=94 Justin

On = Jul 21, 2017, at 8:59 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

OAuth Working Group Meeting at IETF 99 21-Jul-17
 
William = Denniss presented on the Device Flow
 
Justin Richer discussed a suggestion to = add another parameter that he'd made on the list
William = Denniss clarified that the client constructs the URL - not the = server
Justin withdrew his suggestion
Justin will review the text and suggest = clarifications to help people from misunderstanding it in the way that = he did
 
Annabelle Backman suggested that there be a separate = parameter that contains the clickable URL
Annabelle suggested that there be a = separate parameter for that URL
          &nb= sp;   Then we don't have to standardize the URL for the = user_code
          &nb= sp;   It would allow the server to use a different URL for = that
Dick = Hardt suggested that the user code be URL safe
Annabelle:  People implementing clients may not always = be reading the specs
David Robin: There's an opportunity to send people straight = to the final URL
Nat Sakimura: Our implementation sends both the URL and the = user_code
 
Nat: It's easier to enter Japanese characters than ASCII in = Japan
          &nb= sp;   We should allow the code to be Unicode
Dick = Hardt:  Amazon recently looked at what can be entered world = wide
          &nb= sp;   He said that numbers work really well
William:  Maybe we can suggest that numbers be used as a = best practice
          &nb= sp;   I do not want to prevent the use of letters because it = would bring our implementation out of compliance
Mike = Jones:  Microsoft also uses letters in the codes
 
Nat:  = If we are targeting QR codes, send the QR code directly
          &nb= sp;   QR codes are used on ATM machines in Singapore and = Australia
          &nb= sp;   If it's going to be an image, it should be a separate = parameter
 
Annabelle:  Trying to tailor the spec to particular = delivery mechanisms would take us down a huge rathole
Dick: = It's not clear we're really trying to achieve interop
William:  Justin and I did interop testing with both of = our implementations
Dick:  Amazon is using independently written = implementations
          &nb= sp;   In the Alexa world, there are many third parties = producing devices that we want to be able to make calls into Alexa
 
John: = I am influenced by the arguments that having a different endpoint for = the pre-composed URL than the user typeable one is a good idea
          &nb= sp;   I don't know that we should add the QR code directly
          &nb= sp;   Apps could use introspection to get a QR code or sound = files but that doesn't have to be in the standard
          &nb= sp;   Third party clients operate with YouTube and other = services
 
William:  There are two changes we're discussing
          &nb= sp;   1.  Having a second endpoint for the pre-composed = URL
          &nb= sp;   2.  Saying that the user code should be URL safe, = with numbers recommended
 
William:  If we make it Unicode, we should use a = different URL
 
Mike Jones:  Adding a separate endpoint is a big = change
John:  The change is to have a separate parameter for = the composed URL - not a separate endpoint
          &nb= sp;   Anything internationalized immediately leads us to = sending a composed URL
          &nb= sp;   Using a different endpoint is an implementation choice - = not something for the spec
          &nb= sp;   The client needs to know the script that it's going to = display
          &nb= sp;   A Korean printer might use Korean script in Korea but a = different script in South America
Nat:  Numbers are the best choice = internationally
Annabelle:  The more complicated we make the display = requirements, the more use cases we'll exclude
John: = UTF-8 may not be displayable on all devices and the right fonts might = not even be installed
Annabelle:  We are suggesting a new parameter with a URL = value - not a new endpoint
 
Leif Johansson:  Has anyone done a = security analysis on this?
          &nb= sp;   We shouldn't do these changes without another last = call
 
David = Robin: Are we deprecating what's shown on the screen or is that option = still on the table?
          &nb= sp;   (On the screen, the client was shown merging the = different pieces of information)
          &nb= sp;   Maybe client composition should never be done
          &nb= sp;   It's either opaque with the third parameter or you need = to do composition the way the draft is now
 
Annabelle:  The current draft does = describe Security Considerations about remote phishing
William:  We try to prevent phishing by asking the user = if they have the device in their possession
 
Lucy = Lynch:  These are big enough changes to require another working = group last call
 
William:  There's no requirement that you poll at any = particular rate
 
Mike Jones:  =46rom an engineering perspective, why do = people want to do things differently than what's currently = specified?
Dick:  We looked at this and saw some of the issues
 
William:  The other major change being considered is = defining new authorization parameters
          &nb= sp;   device_id, device_model, device_name
          &nb= sp;   This is to support device revocation
          &nb= sp;   They are all optional
 
Annabelle:  This does not seem = unique to the device flow
William:  I agree but it's worth solving for the device = flow
Annabelle:  If we're overly prescriptive with what = information is being sent, we could end up ruling out use cases we = haven't thought of
Hannes Tschofenig:  This came up in Chicago
          &nb= sp;   We might want to do some form of authentication
          &nb= sp;   These parameters are intended for revocation, but they = could be used for authorization as well
William:  I'm not trying to = capture every possible parameter for every use case
          &nb= sp;   Google does have use cases for these parameters
Dick: = The device ID is problematic
          &nb= sp;   The other two new parameters are useful
William:  The device ID lets the authorization server = group requests
Annabelle:  If this is happening at the AS, it could = assign an ID on its own
Annabelle:  Model and name present a potential phishing = risk
Hannes:  The AS can't infer the device name
Annabelle:  The AS should match the client ID to the = device type
 
William:  If we add these parameters we need to add = Security Considerations
William:  We shouldn't enable display of random = hacker-generated text
 
Dick:  The model allows multiple different things on a = device
          &nb= sp;   For instance, enabling Netflix on your Roku - not just = enabling the device
 
John:  Device ID is a correlatable identifier
          &nb= sp;   Some manufacturers go out of their way to prevent = multiple applications from knowing that they're on the same device
          &nb= sp;   This is its own thing and should be in its own spec
          &nb= sp;   Let's finish the device spec and consider this a = separate add-on
Lucy:  I think that John summarized this correctly
          &nb= sp;   I could drive a truck through this
Hannes:  The context of this spec made discussing these = possible parameters reasonable
 
Justin Richer:  This loops back to = Mike's question about why people are bringing this up now
          &nb= sp;   People have been implementing something like this for = years
          &nb= sp;   Now people are reviewing the spec and asking if it fits = the use cases they've had for years
          &nb= sp;   We are seeing more and more devices where this = functionality makes sense
          &nb= sp;   I think this should be a separate spec
          &nb= sp;   I wrote such as spec in 2010 = draft-richer-oauth-instance-00
          &nb= sp;   This has applicability in other places and it's a big = ball of wax
          &nb= sp;   It's too much to try to slip this in at the last = minute
 
Brian Campbell:  Maybe we could accomplish this without = device ID
          &nb= sp;   We would lose grouping but that would alleviate a lot of = the privacy concerns
Dick:  You only need a locally scoped identifier
          &nb= sp;   The global one is the one that's a problem
 
William:  There is running code
          &nb= sp;   Google's implementation complies with -06
          &nb= sp;   MitreID implements it
          &nb= sp;   Justin and William did some interop
Hannes:  There are other open source implementations
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Brian = Campbell presented on OAuth Token Exchange
 
It is a framework enabling token = exchange
The participants need to know what kinds of tokens are = suitable for their use cases
Draft -09 included small changes to = address actionable WGLC feedback
Hannes will review feedback that didn't = appear to be actionable
Brian believes it's ready for Hannes' write-up
John: = Write it up
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Brian = Campbell presented on OAuth Token Binding
 
Provides proof of possession for OAuth = tokens
The 3 core Token Binding specs are very close to the request = for publication
The last OAuth Token Binding spec version added introspection = language and IANA registrations
Brian added an open issue about the = need to allow distributed Web Server clients to opt out of token binding = for refresh tokens
          &nb= sp;   Shared access to a public key may be difficult or = impossible problem
          &nb= sp;   Sharing on demand generated client-side keys is very = hard
Dick = Hardt:  It's not going to happen
Brian:  The real value is Token = Binding the access token
          &nb= sp;   There are other means of securing the refresh token
There are = two ways we could do this
          &nb= sp;   Toggle the behavior based on client registration = metadata
          &nb= sp;   Or provide a run-time toggle with a parameter
The = metadata parameters already largely exist
Mike Jones:  I think the metadata = approach is reasonable
          &nb= sp;   I don't want to think about the security implications of = providing a parameter to disable a security feature at runtime
Brian:  I think the metadata approach is reasonable
John = Bradley:  I agree with using metadata
 
John Bradley:  As a separate = issue, we may eventually decide we need a parameter to explicitly = communicate the referred token binding separately from the = Sec-Token-Binding header
          &nb= sp;   There are more discussions needed on the parties using = the bound tokens
William Denniss:  Is this only for confidential = clients?
          &nb= sp;   Brian:  Yes
William:  We don't want to = encourage people to opt out very often
John:  We do have a mutual TLS = option so there are more than one ways to achieve proof of = possession
William:  Authorization servers could say that access = token binding is mandatory
 
Brian:  Should the scope include = standardization of Token Binding for JWT Client Authentication for RFC = 7523
John: = We should write this down because it's only self-evident how to do this = to a very small set of people
Brian:  We would write down how to = use the cnf/tbh claim in the context of RFC 7523
Hannes:  Please write this down
 
Brian:  We need to remove the reference to the expiring = resource metadata draft
Brian:  I have ideas how to keep the intent but = simplify
          &nb= sp;   We would still describe how to detect and respond to = attacks
 
Brian:  This is still early
          &nb= sp;   Client library support is still sparse
          &nb= sp;   We have things to learn from deployments
 
Dick: = Is pushing Token Binding through to the end-application after TLS = termination in scope?
Brian:  No, but the Token Binding WG just accepted a = document about this
          &nb= sp;   draft-campbell-tokbind-ttrp
Dick: = This doesn't provide the same guarantees as other application-layer PoP = mechanisms
Brian:  This relies upon trust between the TLS = terminator and the application
Brian:  I don't know a way to = tightly bind this end-to-end
Dick:  The verification is = happening at the application
Dick:  I believe that Microsoft is = encrypting the token
Dick:  The problem is that the TLS terminator is in a = different trust domain than the application
          &nb= sp;   It's trusted to terminate TLS but not to manage the = token or do authentication or authorization
Dick: = What's being done in the Token Binding working group doesn't solve this = problem
 
John:  I asked Tony Nadalin to provide information about = this
          &nb= sp;   Including the possible use of additional Token = Bindings
Andrei Popov:  I'm not familiar the higher-level = functionality being referenced
          &nb= sp;   If you're terminating TLS, that's where end-to-end ends = for TLS functions, such as Token Binding
          &nb= sp;   You're trusting that the TLS terminator is passing = correct information to you
Hannes:  We need to update our = OAuth PoP documents
          &nb= sp;   End-to-end PoP is definitely in scope for the OAuth = WG
Dick: = You didn't solve anything
Dirk Balfanz:  It sounds like you = already have a proof-of-possession implementation
Dick: = We have a non-standard way in which Amazon API calls are made
          &nb= sp;   There is a secret, you sign the request, and it's = verified at the application level
Hannes:  Is it HTTP signing?
Dick: = Yes
          &nb= sp;   It prevents a compromised TLS proxy from changing the = request
Justin Richer:  I did look at the Amazon spec when = writing the OAuth HTTP signing spec
          &nb= sp;   There were lots of problems with parameters being = reordered, etc. in OAuth 1 implementations
Hannes:  I would like Dick to look = at the current OAuth HTTP signing spec
          &nb= sp;   Maybe that will solve the issue that Dick is = describing
Dick:  That doesn't build on Token Binding
Justin:  They are orthogonal
          &nb= sp;   You could do both Token Binding and application-level = PoP
Dick: = What I like about Token Binding is that you don't have to do = client-side management of a key
          &nb= sp;   Token Binding lets you get many of the characteristics = of PoP without client-side key management
Hannes:  What are the right next = steps for this issue?
Dick:  I want Token Binding with end-to-end = guarantees
Dick:  Most of our deployments have TLS proxies
Brian:  This isn't in scope for this document because = the problem isn't specific to OAuth
Brian:  This is also applicable to = Token Bound cookies
          &nb= sp;   The same issues occur for cookies
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50-- From nobody Tue Jul 25 03:32:38 2017 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 75EE912778D for ; Tue, 25 Jul 2017 03:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 tadKqWd1AHnp for ; Tue, 25 Jul 2017 03:32:34 -0700 (PDT) Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 6A005126E3A for ; Tue, 25 Jul 2017 03:32:34 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id Zx8Dd91zRgjsMZx8Dd08Ju; Tue, 25 Jul 2017 03:32:03 -0700 To: oauth@ietf.org References: <95E3EB63-AD89-4FDE-A100-1F7DA8122293@oracle.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Tue, 25 Jul 2017 13:32:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030509030800090004090207" X-CMAE-Envelope: MS4wfAqneoPgG1iYovtOtoHde2HKYHu0DzgBQ04LeAcddXxDObvhz/BYqXOML6VLl1faZX9IHgh7ZDJd9sS0Lo0YhVlL+x78zFfxyHAwK5JpTtyjrbon9oDH eBCzPG7lZNX985mgg963/X0+/8kbbwxi2wIIW8buVE0ETAmQlR6eKnXn Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 10:32:37 -0000 This is a cryptographically signed message in MIME format. --------------ms030509030800090004090207 Content-Type: multipart/alternative; boundary="------------74035F9222678C133645A66F" Content-Language: en-US This is a multi-part message in MIME format. --------------74035F9222678C133645A66F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to have the JWT BCP doc adopted Vladimir On 21/07/17 08:07, Brian Campbell wrote: > +1 for adoption > > On Thu, Jul 20, 2017 at 8:47 PM, Phil Hunt (IDM) = > wrote: > >> +1 adoption >> >> Phil >> >> On Jul 20, 2017, at 11:26 AM, John Bradley wrote: >> >> I support adoption >> >> On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef >> wrote: >> >> All, >> >> We would like to get a confirmation on the mailing list for the adopti= on >> of the *JSON Web Token Best Current Practices* as a WG document >> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ >> >> Please, let us know if you support or object to the adoption of this >> document. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> 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 --------------74035F9222678C133645A66F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

+1 to have the JWT BCP doc adopted

Vladimir


On 21/07/17 08:07, Brian Campbell wrote:
+1 for adoption

On Thu, Jul 20, 2017 at 8:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com&=
gt;
wrote:


+1 adoption

Phil

On Jul 20, 2017, at 11:26 AM, John Bradley <ve7jtb@ve7jtb.com> wrot=
e:

I support adoption

On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com=
>
wrote:

All,

We would like to get a confirmation on the mailing list for the adoption
of the *JSON Web Token Best Current Practices* as a WG document
https://datatracker.ietf.org/doc/draft-s=
heffer-oauth-jwt-bcp/

Please, let us know if you support or object to the adoption of this
document.

Regards,
 Rifaat

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


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


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




      

      

      

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


    

    

  


--------------74035F9222678C133645A66F--

--------------ms030509030800090004090207
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2
CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD
HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa
d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5
7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY
HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN
880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5
RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU
SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i
EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5
60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzA3MjUxMDMyMDBaMC8GCSqGSIb3DQEJBDEiBCAkw0cYwJdTAb0jxcOG2Q8N5+tBSJ3c
McMNBy1AJ9fobjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCtiRbzeTtA
sgLwgI+goDsOP13xfnx3xlkOdMaG8IhI30C1UsgaCaIYEdX8fJS8S6SEKcATxv5hiAH2WQf/
5CJ/hq7p1gyvCpLb+BPqOFq+VEhBdjhyO1sF3yjTIML9ve3La17d2JiZlkxdqsxi2OfhWyoI
mMcIW4MmzKx/OPMlxSNqyMI2vLuCy0J0Qg1Rquv2PiinG+2VgMfB6yG9kmosGNmrY+780Zg9
YdrXE124MsNGxP9K7aUZzMrGqYtWu3mgp2VITu7OnSvjWrFQv1xO1swf62lSbBxc8wBcOKBF
9y/Aqs10buQq1sCwfxA6YkHNhlRXPwAuPwo75TYdvQwBAAAAAAAA
--------------ms030509030800090004090207--


From saurav.sarkar1@gmail.com  Tue Jul 25 07:48:19 2017
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 85D6D1317B1 for ; Tue, 25 Jul 2017 07:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 19iAfgA0_ToJ for ; Tue, 25 Jul 2017 07:48:18 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 037A91270B4 for ; Tue, 25 Jul 2017 07:48:18 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id x3so50393260oia.1 for ; Tue, 25 Jul 2017 07:48:17 -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=0B1vWG0bqaVs7zGZF7C7GGgOSOWbYy7+9jSkgqcmmEQ=; b=UTGxu9j29r7oESh+hWIIIZ9rJDeuF55dfvqKvbrycGoa8NfngZ043tB6B9M2Uw8Qzj McuR8C7qbtjkd8Elu4QX3fCscnmil2ppvg2mDP2KdR3Ar0B8ehITie6ctmB6b/6waoKg deiw6N4dejoKo01CyrsbhDVlpl6SD4zvWHlr82c+DmwdzxnSb85dX2G/eH1OmQPFHi1w SOgzllRnj3g/eBmkJOaHv8kIiU+0qyh2oxXvBIIr5bCyeCWIwNLB22HloOdlxFm92znM fDJg1OrG9ugeoazZ/PTuPYRV4VWgZ4kSEVOmpKk3Jf8yQp+0MeoJxebte7ewHXuVSGlz G1YA==
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=0B1vWG0bqaVs7zGZF7C7GGgOSOWbYy7+9jSkgqcmmEQ=; b=XvfJFBmb0xbvuF2aJfCDAqAxXD8iRHWNT7IUHV9+5mEpdihGU/DQ42heyo8XJYhipZ i1p03iFT6oQIm+NljP1st7xKCLBSC+VSFf3ZyXRnWLVC6QhVkJhas8NG4ktQmU8bQ3yN ITI71c5bO/b0BKMNHYNXAgHhUgz8UClLpNdxeA29xWPMhxCbgdpHQAngWvOd0dVds0wt zLYDOOTtV/PsXhplyth/tj5EIYHyA4EysABVzbg0djeY7g+5x4p9fYM1NXj3krB6ayx5 qZxkLYeu8rCNuOnofgNip0vHA52H7WoCV6H0TLKxvk63agCBuzAYs4hXl2dIl7ioFL/d 8Mxg==
X-Gm-Message-State: AIVw111i/arZS2jlLJnE/d93tKQtJtrqRF7WDlxxesMaupXptlx8p24S BbVKnlBce0Q1pQo81GdqCzmujLrMqwzh
X-Received: by 10.202.227.5 with SMTP id a5mr8500238oih.240.1500994097152; Tue, 25 Jul 2017 07:48:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.0.199 with HTTP; Tue, 25 Jul 2017 07:48:16 -0700 (PDT)
From: Saurav Sarkar 
Date: Tue, 25 Jul 2017 20:18:16 +0530
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a1141a572f889600555256b1a"
Archived-At: 
Subject: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 14:49:11 -0000

--001a1141a572f889600555256b1a
Content-Type: text/plain; charset="UTF-8"

Hi All,

We have a scenario where one of our stakeholder wants to mandatorily
initiate the authentication at certain point of time.

As per
https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
there can be an option where access token is set for certain time and
refresh token is not set. So we want to explore this option for this
scenario.

I have couple of questions regarding this

(a) Is this  option part of OAuth 2 specification ? If yes can you please
point me to the exact IETF link ?

(b) Is there any other way our scenario can be achieved ? We want this
scenario to be supported from the authorization server (platform) itself
and not in the client app or resource server.

Thanks and Best Regards,
Saurav

--001a1141a572f889600555256b1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

We have a scenario where one of=
 our stakeholder wants to mandatorily initiate the authentication at certai=
n point of time.

there can be an option where access token is set for certain time and refr=
esh token is not set. So we want to explore this option for this scenario.<=
/div>

I have couple of questions regarding this

(a) Is this =C2=A0option part of OAuth 2 specification ? I=
f yes can you please point me to the exact IETF link ?

=

(b) Is there any other way our scenario can be achieved ? We want this=
 scenario to be supported from the authorization server (platform) itself a=
nd not in the client app or resource server.

Thanks and Best Regards,
Saurav


--001a1141a572f889600555256b1a--


From nobody Tue Jul 25 08:38:49 2017
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 78E09131D0F for ; Tue, 25 Jul 2017 08:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 yyUd0aN6Uoi7 for ; Tue, 25 Jul 2017 08:38:45 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F64E131C3A for ; Tue, 25 Jul 2017 08:38:45 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 39451A037E for ; Tue, 25 Jul 2017 15:38:45 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 39451A037E
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bburke@redhat.com
Received: from ovpn-116-67.phx2.redhat.com (ovpn-116-67.phx2.redhat.com [10.3.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id DBEFF953AA for ; Tue, 25 Jul 2017 15:38:31 +0000 (UTC)
To: oauth@ietf.org
References: 
From: Bill Burke 
Message-ID: 
Date: Tue, 25 Jul 2017 11:37:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------303B66D9B24CC4787F24FE0E"
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 25 Jul 2017 15:38:45 +0000 (UTC)
Archived-At: 
Subject: Re: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 15:38:47 -0000

This is a multi-part message in MIME format.
--------------303B66D9B24CC4787F24FE0E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

For browser apps, implicit flow provides an access token but no refresh 
token.  For non-browser apps only client credentials grant doesn't 
supply a refresh token.  As for token access times, I believe only 
extensions to OAuth define those types of capabilities.  i.e. OpenID 
Connect defines a "max-age" claim that you can pass when requesting a token.


On 7/25/17 10:48 AM, Saurav Sarkar wrote:
> Hi All,
>
> We have a scenario where one of our stakeholder wants to mandatorily 
> initiate the authentication at certain point of time.
>
> As per 
> https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
> there can be an option where access token is set for certain time and 
> refresh token is not set. So we want to explore this option for this 
> scenario.
>
> I have couple of questions regarding this
>
> (a) Is this  option part of OAuth 2 specification ? If yes can you 
> please point me to the exact IETF link ?
>
> (b) Is there any other way our scenario can be achieved ? We want this 
> scenario to be supported from the authorization server (platform) 
> itself and not in the client app or resource server.
>
> Thanks and Best Regards,
> Saurav
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------303B66D9B24CC4787F24FE0E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
For browser apps, implicit flow provides an access token but no
      refresh token.  For non-browser apps only client credentials grant
      doesn't supply a refresh token.  As for token access times, I
      believe only extensions to OAuth define those types of
      capabilities.  i.e. OpenID Connect defines a "max-age" claim that
      you can pass when requesting a token.

    

    

    
On 7/25/17 10:48 AM, Saurav Sarkar
      wrote:

    

    

      
Hi All,
        


        

        
We have a scenario where one of our stakeholder wants to
          mandatorily initiate the authentication at certain point of
          time.

          


          

          
          
there can be an option where access token is set for
            certain time and refresh token is not set. So we want to
            explore this option for this scenario.

          


          

          
I have couple of questions regarding this

          


          

          
(a) Is this  option part of OAuth 2 specification ? If
            yes can you please point me to the exact IETF link ?

          


          

          
(b) Is there any other way our scenario can be achieved ?
            We want this scenario to be supported from the authorization
            server (platform) itself and not in the client app or
            resource server.

        

        


        

        
Thanks and Best Regards,

        
Saurav

      

      

      

      

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


    

    

  


--------------303B66D9B24CC4787F24FE0E--


From nobody Tue Jul 25 09:02:52 2017
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 2B129131D16 for ; Tue, 25 Jul 2017 09:02:51 -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_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 (2048-bit key) header.d=ve7jtb-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 yINAbIM4PL4C for ; Tue, 25 Jul 2017 09:02:48 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 811D8126C2F for ; Tue, 25 Jul 2017 09:02:48 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id s6so40724807qtc.1 for ; Tue, 25 Jul 2017 09:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y358Hs4WNjH7rLx9EAyJGR/QIZK9u+vIR769iFx/y40=; b=Klp9Z3GJ9B/Q3/JaJIglttfSmJtelheKkA7uk9XZiQ8mNAr/maa/rZWRp+WH5ulXOO 8JUxhchCUXYTp2l1LdiK9sEWFFJbDNrbTZYhFb4xEpP1Rsu6IZI8dQKJTfZXnCqkAgr1 +jIX8AY45D4iobxddxJns1a0N5njvv2U//Ehf8XNKJYkVZmYtj+xYuzCWy4ulzFeZFbk /IW2BOWxyJ2+1f/nlAAC4Xg45YIsQz8/8wknp9NITYqC8H5QtROvo2R3CaCnyeDVbJNE uvZcNKMBsFBs7NlmvXJeyrdxEAjv18FIN1abiIjrmbcK4W0Sc1rIltrboDMb4NvHkJJX dgkQ==
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=y358Hs4WNjH7rLx9EAyJGR/QIZK9u+vIR769iFx/y40=; b=XIFxJwUV/sE3RnBO3ll9+PHcBXNbN0EFW9NlwiC2f2eAEIle6g46/v+Vj0W4kVfOBR n2x8/MdCwKNQ0ra1SVFEVXYql5fkc54EsFR52RaNr1fN/HQSaT952xrctXTb+VpaHz3Y EPpcKZajWPo9um/1hgoHIs6l+UOINOTNZHAzatdZzVK8xlXl+dbW+/MHudETXU2L6oby RuRhZushCD3r6wZsW8l74scNtERP4z6cXU8CN5lC0G2RiAQJOSNS/6FFos6WOXlyXv1n ncZO53iYNCjj4uewXA2wJQrBIzxnBwo5XAf9vszwW1cyMOOxq7tublg2kBw1hsnxc9n2 BOXg==
X-Gm-Message-State: AIVw110cOpyqIRKdPHEfK2Nl+M+ZfZ+/N4iV0q2SzHINQ3GuZdT4uf49 cp9IvKXto0BSNu7D
X-Received: by 10.237.53.28 with SMTP id a28mr20731965qte.110.1500998567180; Tue, 25 Jul 2017 09:02:47 -0700 (PDT)
Received: from [192.168.86.121] ([191.115.159.202]) by smtp.gmail.com with ESMTPSA id f20sm2589163qta.58.2017.07.25.09.02.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 09:02:46 -0700 (PDT)
From: John Bradley 
Message-Id: <47685EB5-84E0-43FB-87CF-447C3F958588@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 25 Jul 2017 12:02:37 -0400
In-Reply-To: 
Cc: oauth@ietf.org
To: Bill Burke 
References:  
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11c01fcc6fcab9055526766b"
Archived-At: 
Subject: Re: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 16:02:51 -0000

--001a11c01fcc6fcab9055526766b
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_90948A8A-1A2A-4007-8DF9-771069F06010"


--Apple-Mail=_90948A8A-1A2A-4007-8DF9-771069F06010
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Max-age has to do with user re-auth in connect.

Some AS only give refresh tokens if a scope of offline_acess or some =
such special scope is requested.
There is no standard scope for that.

I don=E2=80=99t know of any way for the client to control the lifetime =
of the access token other than by revoking it with the AS.
https://tools.ietf.org/html/rfc7009 =


Depending on the AS you should be able to control the AT lifetime on a =
per client basis.

John B.

> On Jul 25, 2017, at 11:37 AM, Bill Burke  wrote:
>=20
> For browser apps, implicit flow provides an access token but no =
refresh token.  For non-browser apps only client credentials grant =
doesn't supply a refresh token.  As for token access times, I believe =
only extensions to OAuth define those types of capabilities.  i.e. =
OpenID Connect defines a "max-age" claim that you can pass when =
requesting a token.
>=20
> On 7/25/17 10:48 AM, Saurav Sarkar wrote:
>> Hi All,
>>=20
>> We have a scenario where one of our stakeholder wants to mandatorily =
initiate the authentication at certain point of time.
>>=20
>> As per =
https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/ =

>> there can be an option where access token is set for certain time and =
refresh token is not set. So we want to explore this option for this =
scenario.
>>=20
>> I have couple of questions regarding this
>>=20
>> (a) Is this  option part of OAuth 2 specification ? If yes can you =
please point me to the exact IETF link ?
>>=20
>> (b) Is there any other way our scenario can be achieved ? We want =
this scenario to be supported from the authorization server (platform) =
itself and not in the client app or resource server.
>>=20
>> Thanks and Best Regards,
>> Saurav
>>=20
>>=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


--Apple-Mail=_90948A8A-1A2A-4007-8DF9-771069F06010
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Max-age has to do with user re-auth in connect.

Some AS only give =
refresh tokens if a scope of offline_acess or some such special scope is =
requested.
There is no standard scope for that.

I =
don=E2=80=99t know of any way for the client to control the lifetime of =
the access token other than by revoking it with the AS.
https://tools.ietf.org/html/rfc7009

Depending on the AS you =
should be able to control the AT lifetime on a per client =
basis.

John =
B.

On Jul 25, 2017, at 11:37 AM, Bill Burke =
<bburke@redhat.com> wrote:


 =20
    
 =20
  
For =
browser apps, implicit flow provides an access token but no
      refresh token.  For non-browser apps only client credentials =
grant
      doesn't supply a refresh token.  As for token access times, I
      believe only extensions to OAuth define those types of
      capabilities.  i.e. OpenID Connect defines a "max-age" claim =
that
      you can pass when requesting a token.

    

    

    
On 7/25/17 10:48 AM, Saurav Sarkar
      wrote:

    

    

      
Hi All,
        


        

        
We have a scenario where one of our stakeholder =
wants to
          mandatorily initiate the authentication at certain point of
          time.

          


          

          
As per https://www.oauth.com/oauth2-servers/access-tokens/access-token=
-lifetime/

          
there can be an option where access token is =
set for
            certain time and refresh token is not set. So we want to
            explore this option for this scenario.

          


          

          
I have couple of questions regarding =
this

          


          

          
(a) Is this  option part of OAuth 2 =
specification ? If
            yes can you please point me to the exact IETF link ?

          


          

          
(b) Is there any other way our scenario can be =
achieved ?
            We want this scenario to be supported from the authorization
            server (platform) itself and not in the client app or
            resource server.

        

        


        

        
Thanks and Best Regards,

        
Saurav

      

      

      

      

      
_______________________________________________
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=_90948A8A-1A2A-4007-8DF9-771069F06010--

--001a11c01fcc6fcab9055526766b
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIHPGGhf+dGHpElri6ReHBIHYg5Us
Ql7htNLnMd7jYAwhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDcyNTE2MDI0N1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQAdBMnAEnmJcSBnJazIwQa8b+isqNOAXTiQKkiUD7TvqgdQ
Dh7L/5xfReec43wZ34MaieOCueTseMhjwxswmkli7PRdK1JwqRZWztZ+772hUHz4vcStfXzxomIv
/WIHnmg7T0KWYrAlXKVllvcUunXo1W9Q9PrrcSin9gEDn8Uu2XYhFHfRuLgG9zgVMjcNf8TejDWC
GmUS8pg47ANj64ewKBtjlSCQrIPBh724DwbCUDPLMn3pogDp1k52Stp3tWyeJXSTGPlFXqavAA5o
m/3Hnb2HkXnNAW9jf5cTJVw1eAzmopHB3nHYm23LM0UR5LxU+rOfUPechUDmNu26Op/E
--001a11c01fcc6fcab9055526766b--


From nobody Tue Jul 25 09:47:30 2017
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 3DBFF131D69 for ; Tue, 25 Jul 2017 09:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=solucomonline.onmicrosoft.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 6ePr9Vykc7jZ for ; Tue, 25 Jul 2017 09:47:24 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0069.outbound.protection.outlook.com [104.47.2.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7F7131D7A for ; Tue, 25 Jul 2017 09:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solucomonline.onmicrosoft.com; s=selector1-solucomonline-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g8K4UDSyIjO4YU729oXRI2Ica2/pDZEjqgmt1FuXW3Q=; b=NEUTJPAHNKCpLzkYuJCd9Z288NC7X3wFS7UPi5qGgK2vxhSNU/UKtAZsMamh+OhQZ24gDsc5P4KF2qh5W9FRU0lGqVgKeB0l4///wYMT55C0UKWOqW0TVwVaS2wG6fIL3Zdr1QDVg3Vvap8Cxt3KR6TNMf2FSKOHFVk/kn0fBIg=
Received: from HE1PR0301MB2138.eurprd03.prod.outlook.com (10.168.31.15) by HE1PR0301MB2137.eurprd03.prod.outlook.com (10.168.31.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1304.14; Tue, 25 Jul 2017 16:47:19 +0000
Received: from HE1PR0301MB2138.eurprd03.prod.outlook.com ([fe80::a97f:7499:a6f3:7806]) by HE1PR0301MB2138.eurprd03.prod.outlook.com ([fe80::a97f:7499:a6f3:7806%13]) with mapi id 15.01.1282.020; Tue, 25 Jul 2017 16:47:19 +0000
From: CARLIER Bertrand 
To: John Bradley , Bill Burke 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Short lived access token and no refresh token
Thread-Index: AQHTBVUyhZLOQWUpkUi1/TB0YRnQIqJkrUwAgAAG6ICAAAiUgA==
Date: Tue, 25 Jul 2017 16:47:19 +0000
Message-ID: 
References:   <47685EB5-84E0-43FB-87CF-447C3F958588@ve7jtb.com>
In-Reply-To: <47685EB5-84E0-43FB-87CF-447C3F958588@ve7jtb.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bertrand.CARLIER@wavestone.com; 
x-originating-ip: [212.99.112.100]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2137; 7:U07ELP1vpTfloy6CZSwc9zqc2H42cUSpW/wJeF+94ZFV7pCs3oVDnAA+RgDQvuIsNiTGKjmxMUnly31cfFj7pMdL5HZLNDHn5cLwztSNKss/4WcaP/dRIUJm65aybjzUXbmqSNSzubgn1dFgEu48Ro5nPI2GWZ+RGBu0zkZGPV77HSiNNEz1Fk3RMr+xW2TJ4XX1QYYuOVoYFMB23mhPahEZfxcP4iw2yQ4j9dqqW9efQt1EctN8fJIumEvItKNoSkNg5r+uShj8pPnmiaLpHOAkzKErXMcGcHXFH64azZ7OWY3m5Zubqok/z4ggZILEnAiaRbXM+CpuqrvY1WALK9kVHbkx629O0/42pubjWTM4xwnHIxZNWSXqIx/8QyRJOhddDAVeJ3hIrXULiOyRm466jiDLk/0UhjRwsKo16j4T98eNIxwB4XYKcXDDSuhNds1L1hkO/ZeRPNII5Dom1v44Tp9R9VsIxOk/Z7Ju/DjoOPyOE3w/4DUiA1cjqiSGQgzUkhuDWhA8zxdy/+L2KMa5CYlvHGMeHI4qvRCgIsxS31ZstluL3rg2T3/cD0r3GqmtRMTACZJJCLI68f5xYeV/JRonL4PFFJ9klHA3Orq5kbDCBglxmy9qIGqa23SoN4ZzmjAMq3rfVG2xD3jz4IqKtDm7pb71kVqP64gMrQUcFbgF3q8AoWI3Q/6xqvcOqpu84AXPxuM/FmAwqlqAeKDfktAZwqa/nhSN59XidQqDO3q5UEsBP0/u7hWWWxXmU3+CCUxipNyZ0i6VFYKWXc8tKFjaTepraIpqNPyBoks=
x-ms-office365-filtering-correlation-id: 6ca5a85a-37de-4ac5-57e9-08d4d37cd0aa
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0301MB2137; 
x-ms-traffictypediagnostic: HE1PR0301MB2137:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(21532816269658); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0301MB2137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0301MB2137; 
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(26244003)(24454002)(199003)(189002)(377454003)(53754006)(97736004)(101416001)(189998001)(8676002)(8936002)(68736007)(106356001)(105586002)(33656002)(81166006)(81156014)(55016002)(6436002)(3280700002)(5250100002)(74316002)(3660700001)(9686003)(5890100001)(99286003)(6306002)(54896002)(229853002)(2900100001)(2950100002)(2906002)(6246003)(25786009)(3846002)(6116002)(102836003)(790700001)(53946003)(53936002)(66066001)(236005)(6506006)(4326008)(54356999)(86362001)(50986999)(53546010)(76176999)(5660300001)(7696004)(38730400002)(14454004)(7736002)(606006)(966005)(72206003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0301MB2137; H:HE1PR0301MB2138.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: wavestone.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB213884E812F89B529EC5FE5887B80HE1PR0301MB2138_"
MIME-Version: 1.0
X-OriginatorOrg: wavestone.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 16:47:19.4281 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5de96c96-c87c-4dce-aad9-f5c557b52ac1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2137
Archived-At: 
Subject: Re: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 16:47:28 -0000

--_000_HE1PR0301MB213884E812F89B529EC5FE5887B80HE1PR0301MB2138_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8sDQoNCkRlcGVuZGluZyBvbiB3aGF0IGlzIG1lYW50IGJ5IOKAnHNjZW5hcmlvIHRvIGJl
IHN1cHBvcnRlZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAocGxhdGZvcm0pIGl0c2Vs
ZiBhbmQgbm90IGluIHRoZSBjbGllbnQgYXBwIG9yIHJlc291cmNlIHNlcnZlcuKAnSwgaXQgbWF5
IGJlIGl0IGRpZmZpY3VsdCAob3IgaW1wb3NzaWJsZSkgdG8gYWNoaWV2ZS4NCkluIHRoZSBlbmQs
IHRoZSByZXNvdXJjZSBzZXJ2ZXIgb25seSBhcHBsaWVzIHRva2VuIGxpZmV0aW1lIHBvbGljeSAq
aWYgaXQgZGVjaWRlcyB0byBkbyBzbyosIHdoYXRldmVyIHRoZSBBUyBraW5kbHkgYXNrZWQgaGlt
IHRvIGRvDQoNCi0tDQpCZXJ0cmFuZCBDQVJMSUVSDQoNCg0KRGUgOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9obiBCcmFkbGV5DQpFbnZvecOp
IDogbWFyZGkgMjUganVpbGxldCAyMDE3IDE4OjAzDQrDgCA6IEJpbGwgQnVya2UgPGJidXJrZUBy
ZWRoYXQuY29tPg0KQ2MgOiBvYXV0aEBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW09BVVRILVdHXSBT
aG9ydCBsaXZlZCBhY2Nlc3MgdG9rZW4gYW5kIG5vIHJlZnJlc2ggdG9rZW4NCg0KTWF4LWFnZSBo
YXMgdG8gZG8gd2l0aCB1c2VyIHJlLWF1dGggaW4gY29ubmVjdC4NCg0KU29tZSBBUyBvbmx5IGdp
dmUgcmVmcmVzaCB0b2tlbnMgaWYgYSBzY29wZSBvZiBvZmZsaW5lX2FjZXNzIG9yIHNvbWUgc3Vj
aCBzcGVjaWFsIHNjb3BlIGlzIHJlcXVlc3RlZC4NClRoZXJlIGlzIG5vIHN0YW5kYXJkIHNjb3Bl
IGZvciB0aGF0Lg0KDQpJIGRvbuKAmXQga25vdyBvZiBhbnkgd2F5IGZvciB0aGUgY2xpZW50IHRv
IGNvbnRyb2wgdGhlIGxpZmV0aW1lIG9mIHRoZSBhY2Nlc3MgdG9rZW4gb3RoZXIgdGhhbiBieSBy
ZXZva2luZyBpdCB3aXRoIHRoZSBBUy4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3
MDA5DQoNCkRlcGVuZGluZyBvbiB0aGUgQVMgeW91IHNob3VsZCBiZSBhYmxlIHRvIGNvbnRyb2wg
dGhlIEFUIGxpZmV0aW1lIG9uIGEgcGVyIGNsaWVudCBiYXNpcy4NCg0KSm9obiBCLg0KDQpPbiBK
dWwgMjUsIDIwMTcsIGF0IDExOjM3IEFNLCBCaWxsIEJ1cmtlIDxiYnVya2VAcmVkaGF0LmNvbTxt
YWlsdG86YmJ1cmtlQHJlZGhhdC5jb20+PiB3cm90ZToNCg0KRm9yIGJyb3dzZXIgYXBwcywgaW1w
bGljaXQgZmxvdyBwcm92aWRlcyBhbiBhY2Nlc3MgdG9rZW4gYnV0IG5vIHJlZnJlc2ggdG9rZW4u
ICBGb3Igbm9uLWJyb3dzZXIgYXBwcyBvbmx5IGNsaWVudCBjcmVkZW50aWFscyBncmFudCBkb2Vz
bid0IHN1cHBseSBhIHJlZnJlc2ggdG9rZW4uICBBcyBmb3IgdG9rZW4gYWNjZXNzIHRpbWVzLCBJ
IGJlbGlldmUgb25seSBleHRlbnNpb25zIHRvIE9BdXRoIGRlZmluZSB0aG9zZSB0eXBlcyBvZiBj
YXBhYmlsaXRpZXMuICBpLmUuIE9wZW5JRCBDb25uZWN0IGRlZmluZXMgYSAibWF4LWFnZSIgY2xh
aW0gdGhhdCB5b3UgY2FuIHBhc3Mgd2hlbiByZXF1ZXN0aW5nIGEgdG9rZW4uDQoNCk9uIDcvMjUv
MTcgMTA6NDggQU0sIFNhdXJhdiBTYXJrYXIgd3JvdGU6DQpIaSBBbGwsDQoNCldlIGhhdmUgYSBz
Y2VuYXJpbyB3aGVyZSBvbmUgb2Ygb3VyIHN0YWtlaG9sZGVyIHdhbnRzIHRvIG1hbmRhdG9yaWx5
IGluaXRpYXRlIHRoZSBhdXRoZW50aWNhdGlvbiBhdCBjZXJ0YWluIHBvaW50IG9mIHRpbWUuDQoN
CkFzIHBlciBodHRwczovL3d3dy5vYXV0aC5jb20vb2F1dGgyLXNlcnZlcnMvYWNjZXNzLXRva2Vu
cy9hY2Nlc3MtdG9rZW4tbGlmZXRpbWUvDQp0aGVyZSBjYW4gYmUgYW4gb3B0aW9uIHdoZXJlIGFj
Y2VzcyB0b2tlbiBpcyBzZXQgZm9yIGNlcnRhaW4gdGltZSBhbmQgcmVmcmVzaCB0b2tlbiBpcyBu
b3Qgc2V0LiBTbyB3ZSB3YW50IHRvIGV4cGxvcmUgdGhpcyBvcHRpb24gZm9yIHRoaXMgc2NlbmFy
aW8uDQoNCkkgaGF2ZSBjb3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGlzDQoNCihhKSBJ
cyB0aGlzICBvcHRpb24gcGFydCBvZiBPQXV0aCAyIHNwZWNpZmljYXRpb24gPyBJZiB5ZXMgY2Fu
IHlvdSBwbGVhc2UgcG9pbnQgbWUgdG8gdGhlIGV4YWN0IElFVEYgbGluayA/DQoNCihiKSBJcyB0
aGVyZSBhbnkgb3RoZXIgd2F5IG91ciBzY2VuYXJpbyBjYW4gYmUgYWNoaWV2ZWQgPyBXZSB3YW50
IHRoaXMgc2NlbmFyaW8gdG8gYmUgc3VwcG9ydGVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2Vy
dmVyIChwbGF0Zm9ybSkgaXRzZWxmIGFuZCBub3QgaW4gdGhlIGNsaWVudCBhcHAgb3IgcmVzb3Vy
Y2Ugc2VydmVyLg0KDQpUaGFua3MgYW5kIEJlc3QgUmVnYXJkcywNClNhdXJhdg0KDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBt
YWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN
Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVk
IGluIHRoZSBwcmVzZW50IGVtYWlsIGluY2x1ZGluZyB0aGUgYXR0YWNobWVudCBpcyBpbnRlbmRl
ZCBvbmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk
ZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG1h
dGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhl
ciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24gdGhpcyBp
bmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVuZGVk
IHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwg
cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1h
dGVyaWFsLg0KDQpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBxdWkgeSBzb250IMOp
dmVudHVlbGxlbWVudCBqb2ludGVzIHNvbnQgY29uZmlkZW50aWVscyBldCB0cmFuc21pcyDDoCBs
J2ludGVudGlvbiBleGNsdXNpdmUgZGUgc29uIGRlc3RpbmF0YWlyZS4gVG91dGUgbW9kaWZpY2F0
aW9uLCDDqWRpdGlvbiwgdXRpbGlzYXRpb24gb3UgZGlmZnVzaW9uIHBhciB0b3V0ZSBwZXJzb25u
ZSBvdSBlbnRpdMOpIGF1dHJlIHF1ZSBsZSBkZXN0aW5hdGFpcmUgZXN0IGludGVyZGl0ZS4gU2kg
dm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbm91cyB2b3VzIHJlbWVyY2lv
bnMgZGUgbm91cyBlbiBpbmZvcm1lciBpbW3DqWRpYXRlbWVudCBldCBkZSBsZSBzdXBwcmltZXIg
YWluc2kgcXVlIGxlcyBwacOoY2VzIHF1aSB5IHNvbnQgw6l2ZW50dWVsbGVtZW50IGpvaW50ZXMu
DQo=

--_000_HE1PR0301MB213884E812F89B529EC5FE5887B80HE1PR0301MB2138_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldlYmRpbmdzOw0K
CXBhbm9zZS0xOjUgMyAxIDIgMSA1IDkgNiA3IDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiQXJpYWwgR3JhcyI7DQoJcGFub3NlLTE6MiAxMSA3IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eToxOw0KCW1zby1zdHlsZS1saW5r
OiJUaXRyZSAxIENhciI7DQoJbWFyZ2luLXRvcDoyNC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDotNDIuNTVwdDsNCglwYWdlLWJyZWFrLWJlZm9yZTph
bHdheXM7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCgltc28tbGlzdDpsNCBsZXZlbDMgbGZv
NjsNCglib3JkZXI6bm9uZTsNCglwYWRkaW5nOjBjbTsNCglmb250LXNpemU6MjQuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDQ3N0Y7DQoJZm9udC13
ZWlnaHQ6bm9ybWFsO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eToyOw0KCW1zby1zdHlsZS1s
aW5rOiJUaXRyZSAyIENhciI7DQoJbWFyZ2luLXRvcDoxOC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBj
bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTQyLjU1
cHQ7DQoJbXNvLWxpc3Q6bDQgbGV2ZWw0IGxmbzY7DQoJZm9udC1zaXplOjE0LjBwdDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDA0NzdGOw0KCWZvbnQtd2Vp
Z2h0Om5vcm1hbDt9DQpoMw0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzsNCgltc28tc3R5bGUtbGlu
azoiVGl0cmUgMyBDYXIiOw0KCW1hcmdpbi10b3A6MTIuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207
DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6NDIuNTVwdDsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50Oi00Mi41NXB0
Ow0KCW1zby1saXN0Omw0IGxldmVsNSBsZm82Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwNDc3RjsNCglmb250LXdlaWdo
dDpub3JtYWw7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjQ7DQoJbXNvLXN0eWxlLWxpbms6
IlRpdHJlIDQgQ2FyIjsNCgltYXJnaW4tdG9wOjE4LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjQyLjU1cHQ7DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMTkuODVwdDsN
Cgltc28tbGlzdDpsNCBsZXZlbDYgbGZvNjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDQ3N0Y7DQoJZm9udC13ZWlnaHQ6
bm9ybWFsO30NCnAuTXNvTm9ybWFsSW5kZW50LCBsaS5Nc29Ob3JtYWxJbmRlbnQsIGRpdi5Nc29O
b3JtYWxJbmRlbnQNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjE0Ow0KCW1hcmdpbi10b3A6MTIuMHB0
Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6
NDIuNTVwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJn
aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29Ob1NwYWNpbmcsIGxpLk1zb05vU3BhY2lu
ZywgZGl2Lk1zb05vU3BhY2luZw0KCXttc28tc3R5bGUtcHJpb3JpdHk6MTsNCgltYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv
TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5
OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv
bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglt
c28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xp
c3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0DQoJe21z
by1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJn
aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h
cmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFj
ZTphdXRvOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFw
aEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZQ0KCXttc28tc3R5bGUt
cHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRvcDow
Y207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVm
dDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qs
IGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K
CW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1y
aWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjEx
LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb1F1b3RlLCBs
aS5Nc29RdW90ZSwgZGl2Lk1zb1F1b3RlDQoJe21zby1zdHlsZS1wcmlvcml0eToyOTsNCgltc28t
c3R5bGUtbGluazoiQ2l0YXRpb24gQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOiM1RjVGNUY7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5Nc29JbnRl
bnNlUXVvdGUsIGxpLk1zb0ludGVuc2VRdW90ZSwgZGl2Lk1zb0ludGVuc2VRdW90ZQ0KCXttc28t
c3R5bGUtcHJpb3JpdHk6MzA7DQoJbXNvLXN0eWxlLWxpbms6IkNpdGF0aW9uIGludGVuc2UgQ2Fy
IjsNCgltYXJnaW4tdG9wOjEwLjBwdDsNCgltYXJnaW4tcmlnaHQ6NDYuOHB0Ow0KCW1hcmdpbi1i
b3R0b206MTQuMHB0Ow0KCW1hcmdpbi1sZWZ0OjQ2LjhwdDsNCglib3JkZXI6bm9uZTsNCglwYWRk
aW5nOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOiM5Q0I5RDg7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCglmb250LXN0eWxl
Oml0YWxpYzt9DQpzcGFuLk1zb1N1YnRsZVJlZmVyZW5jZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzE7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJY29sb3I6IzVGNUY1RjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uTXNvSW50ZW5zZVJlZmVyZW5jZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6MzI7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJY29sb3I6IzVGNUY1
RjsNCglsZXR0ZXItc3BhY2luZzouMjVwdDsNCglmb250LXdlaWdodDpib2xkOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5Nc29Cb29rVGl0bGUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5OjMzOw0KCWZvbnQtdmFyaWFudDpzbWFsbC1jYXBzOw0KCWxldHRlci1zcGFjaW5nOi4yNXB0
Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5FbnVtMSwgbGkuRW51bTEsIGRpdi5FbnVtMQ0KCXtt
c28tc3R5bGUtbmFtZTpFbnVtMTsNCgltc28tc3R5bGUtcHJpb3JpdHk6ODsNCgltYXJnaW4tdG9w
OjkuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu
LWxlZnQ6MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7
DQoJdGV4dC1pbmRlbnQ6MGNtOw0KCW1zby1saXN0OmwwIGxldmVsMSBsZm83Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5FbnVtMVN1
aXRlLCBsaS5FbnVtMVN1aXRlLCBkaXYuRW51bTFTdWl0ZQ0KCXttc28tc3R5bGUtbmFtZToiRW51
bTEgU3VpdGUiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1hcmdpbi10b3A6OS4wcHQ7DQoJ
bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDo3MC45
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuRW51
bTIsIGxpLkVudW0yLCBkaXYuRW51bTINCgl7bXNvLXN0eWxlLW5hbWU6RW51bTI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5OjEwOw0KCW1hcmdpbi10b3A6Ni4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDo5OS4yNXB0Ow0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTE0LjJwdDsN
Cgltc28tbGlzdDpsNiBsZXZlbDEgbGZvOTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuRW51bTJTdWl0ZSwgbGkuRW51bTJTdWl0ZSwg
ZGl2LkVudW0yU3VpdGUNCgl7bXNvLXN0eWxlLW5hbWU6IkVudW0yIFN1aXRlIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6MTE7DQoJbWFyZ2luLXRvcDo2LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0Ojk5LjI1cHQ7DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuRW51bTJUaXRyZSwgbGkuRW51bTJU
aXRyZSwgZGl2LkVudW0yVGl0cmUNCgl7bXNvLXN0eWxlLW5hbWU6IkVudW0yIFRpdHJlIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luLXRvcDo2LjBwdDsNCgltYXJnaW4tcmlnaHQ6
MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0Ojk5LjI1cHQ7DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMTQu
MnB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDExIGxldmVsMSBsZm8x
Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6Z3JheTsNCglmb250LXdlaWdodDpib2xkO30NCnAuRW51bTMsIGxpLkVudW0zLCBk
aXYuRW51bTMNCgl7bXNvLXN0eWxlLW5hbWU6RW51bTM7DQoJbXNvLXN0eWxlLXByaW9yaXR5OjEy
Ow0KCW1hcmdpbi10b3A6My4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t
OjBjbTsNCgltYXJnaW4tbGVmdDoxMjcuNTVwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
dGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50Oi0xNC4xNXB0Ow0KCW1zby1saXN0Omwy
IGxldmVsMSBsZm8xMTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnAuRW51bTNTdWl0ZSwgbGkuRW51bTNTdWl0ZSwgZGl2LkVudW0zU3Vp
dGUNCgl7bXNvLXN0eWxlLW5hbWU6IkVudW0zIFN1aXRlIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
MTM7DQoJbWFyZ2luLXRvcDozLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0
b206MGNtOw0KCW1hcmdpbi1sZWZ0OjEyNy42cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmO30NCnAuRW51bTNUaXRyZSwgbGkuRW51bTNUaXRyZSwgZGl2LkVu
dW0zVGl0cmUNCgl7bXNvLXN0eWxlLW5hbWU6IkVudW0zIFRpdHJlIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbWFyZ2luLXRvcDozLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp
bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjEyNy42cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMTQuMnB0Ow0KCXBhZ2Ut
YnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzI7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpncmF5
Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5FbnVtMVRpdHJlLCBsaS5FbnVtMVRpdHJlLCBkaXYu
RW51bTFUaXRyZQ0KCXttc28tc3R5bGUtbmFtZToiRW51bTEgVGl0cmUiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltYXJnaW4tdG9wOjkuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy
Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6NzAuOXB0Ow0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTE0LjJwdDsNCglwYWdl
LWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1saXN0OmwzIGxldmVsMSBsZm8zOw0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6Z3Jh
eTsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uTWlzZWVudmFsZXVyDQoJe21zby1zdHlsZS1u
YW1lOiJNaXNlIGVuIHZhbGV1ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojc7DQoJY29sb3I6IzAw
NDc3RjsNCglmb250LXdlaWdodDpib2xkO30NCnAuRW51bTRTdWl0ZSwgbGkuRW51bTRTdWl0ZSwg
ZGl2LkVudW00U3VpdGUNCgl7bXNvLXN0eWxlLW5hbWU6IkVudW00IFN1aXRlIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luLXRvcDozLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjE1NS45NXB0Ow0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLkVudW00VGl0cmUsIGxpLkVudW00
VGl0cmUsIGRpdi5FbnVtNFRpdHJlDQoJe21zby1zdHlsZS1uYW1lOiJFbnVtNCBUaXRyZSI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbi10b3A6My4wcHQ7DQoJbWFyZ2luLXJpZ2h0
OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDoxNTUuOTVwdDsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtaW5kZW50Oi0x
NC4ycHQ7DQoJbXNvLWxpc3Q6bDEwIGxldmVsMSBsZm80Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkFyaWFsIEdyYXMiLHNlcmlmOw0KCWNvbG9yOmdyYXk7DQoJZm9udC13ZWln
aHQ6Ym9sZDt9DQpwLkVudW00LCBsaS5FbnVtNCwgZGl2LkVudW00DQoJe21zby1zdHlsZS1uYW1l
OkVudW00Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW4tdG9wOjMuMHB0Ow0KCW1h
cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MTU1Ljk1
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0
LWluZGVudDotMTQuMnB0Ow0KCW1zby1saXN0Omw1IGxldmVsMSBsZm81Ow0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5UaXRyZTFD
YXINCgl7bXNvLXN0eWxlLW5hbWU6IlRpdHJlIDEgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
MTsNCgltc28tc3R5bGUtbGluazoiVGl0cmUgMSI7DQoJY29sb3I6IzAwNDc3Rjt9DQpzcGFuLlRp
dHJlMkNhcg0KCXttc28tc3R5bGUtbmFtZToiVGl0cmUgMiBDYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eToyOw0KCW1zby1zdHlsZS1saW5rOiJUaXRyZSAyIjsNCgljb2xvcjojMDA0NzdGO30NCnNw
YW4uVGl0cmUzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUaXRyZSAzIENhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5OjM7DQoJbXNvLXN0eWxlLWxpbms6IlRpdHJlIDMiOw0KCWNvbG9yOiMwMDQ3N0Y7
fQ0Kc3Bhbi5DaXRhdGlvbmludGVuc2VDYXINCgl7bXNvLXN0eWxlLW5hbWU6IkNpdGF0aW9uIGlu
dGVuc2UgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6MzA7DQoJbXNvLXN0eWxlLWxpbms6IkNp
dGF0aW9uIGludGVuc2UiOw0KCWNvbG9yOiM5Q0I5RDg7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCglm
b250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkNpdGF0aW9uQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJD
aXRhdGlvbiBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eToyOTsNCgltc28tc3R5bGUtbGluazpD
aXRhdGlvbjsNCgljb2xvcjojNUY1RjVGOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnAuVGl0cmVh
bGluYSwgbGkuVGl0cmVhbGluYSwgZGl2LlRpdHJlYWxpbmENCgl7bXNvLXN0eWxlLW5hbWU6IlRp
dHJlIGFsaW7DqWEiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo1Ow0KCW1hcmdpbi10b3A6MjQuMHB0
Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6
NDIuNTVwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJcGFnZS1icmVhay1hZnRlcjphdm9p
ZDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOiMwMDQ3N0Y7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpwLlRpdHJlZmlndXJlLCBs
aS5UaXRyZWZpZ3VyZSwgZGl2LlRpdHJlZmlndXJlDQoJe21zby1zdHlsZS1uYW1lOiJUaXRyZSBm
aWd1cmUiOw0KCW1zby1zdHlsZS1wcmlvcml0eToxOTsNCgltYXJnaW4tdG9wOjEyLjBwdDsNCglt
YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglmb250LXN0eWxl
Oml0YWxpYzt9DQpwLlRpdHJldGFibGVhdSwgbGkuVGl0cmV0YWJsZWF1LCBkaXYuVGl0cmV0YWJs
ZWF1DQoJe21zby1zdHlsZS1uYW1lOiJUaXRyZSB0YWJsZWF1IjsNCgltc28tc3R5bGUtcHJpb3Jp
dHk6MTg7DQoJbWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4t
Ym90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CXRleHQtYWxpZ246Y2VudGVyOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5FbnVtMVRhYmxlYXUs
IGxpLkVudW0xVGFibGVhdSwgZGl2LkVudW0xVGFibGVhdQ0KCXttc28tc3R5bGUtbmFtZToiRW51
bTEgVGFibGVhdSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5OjE1Ow0KCW1hcmdpbi10b3A6Ni4wcHQ7
DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDox
LjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRl
eHQtaW5kZW50Oi0xNC4xNXB0Ow0KCW1zby1saXN0Omw4IGxldmVsMSBsZm84Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5FbnVtMlRh
YmxlYXUsIGxpLkVudW0yVGFibGVhdSwgZGl2LkVudW0yVGFibGVhdQ0KCXttc28tc3R5bGUtbmFt
ZToiRW51bTIgVGFibGVhdSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5OjE2Ow0KCW1hcmdpbi10b3A6
Ni4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t
bGVmdDo0Mi41NXB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3Rp
Znk7DQoJdGV4dC1pbmRlbnQ6LTE0LjJwdDsNCgltc28tbGlzdDpsMSBsZXZlbDEgbGZvMTA7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw
LkVudW0zVGFibGVhdSwgbGkuRW51bTNUYWJsZWF1LCBkaXYuRW51bTNUYWJsZWF1DQoJe21zby1z
dHlsZS1uYW1lOiJFbnVtMyBUYWJsZWF1IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6MTc7DQoJbWFy
Z2luLXRvcDozLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0K
CW1hcmdpbi1sZWZ0OjIuMGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu
Omp1c3RpZnk7DQoJdGV4dC1pbmRlbnQ6LTE0LjE1cHQ7DQoJbXNvLWxpc3Q6bDkgbGV2ZWwxIGxm
bzEyOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KcC5UaXRyZWFsaW5hMiwgbGkuVGl0cmVhbGluYTIsIGRpdi5UaXRyZWFsaW5hMg0KCXtt
c28tc3R5bGUtbmFtZToiVGl0cmUgYWxpbsOpYSAyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6NjsN
CgltYXJnaW4tdG9wOjI0LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206
MGNtOw0KCW1hcmdpbi1sZWZ0OjQyLjU1cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXBh
Z2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpncmF5Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0K
c3Bhbi5UaXRyZTRDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRpdHJlIDQgQ2FyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6NDsNCgltc28tc3R5bGUtbGluazoiVGl0cmUgNCI7DQoJY29sb3I6IzAwNDc3
Rjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z
dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t
cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj
bTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kg
SFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD
qWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls
ZTU3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlh
bCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDA0NzdGO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg
NzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDIxMDAw
Mzg7DQoJbXNvLWxpc3QtdHlwZTpzaW1wbGU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDIx
MDc2MTYyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXN0eWxlLWxpbms6RW51bTE7DQoJbXNvLWxldmVsLXRleHQ674GuOw0K
CW1zby1sZXZlbC10YWItc3RvcDo3MC44NXB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgltYXJnaW4tbGVmdDo3MC44NXB0Ow0KCXRleHQtaW5kZW50Oi0xNC4xNXB0Ow0KCW1z
by1hbnNpLWZvbnQtc2l6ZTo4LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6OC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzOw0KCWNvbG9yOiMwMDQ3N0Y7fQ0KQGxpc3QgbDENCgl7bXNvLWxp
c3QtaWQ6NDQ3ODk4NDQ3Ow0KCW1zby1saXN0LXR5cGU6c2ltcGxlOw0KCW1zby1saXN0LXRlbXBs
YXRlLWlkczotNDgzNjAwMjg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtc3R5bGUtbGluazoiRW51bTIgVGFibGVhdSI7DQoJ
bXNvLWxldmVsLXRleHQ674C0Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0Mi41NXB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCXRleHQt
aW5kZW50Oi0xNC4ycHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpXZWJkaW5nczsNCgljb2xvcjojMDA0NzdGO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjYz
MTUyMzE2MTsNCgltc28tbGlzdC10eXBlOnNpbXBsZTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6
MjAyMTgyMzEwMjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC1zdHlsZS1saW5rOkVudW0zOw0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTI3LjZwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI3LjU1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE0LjE1cHQ7
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJY29s
b3I6IzAwNDc3Rjt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo3MTY1ODU4ODI7DQoJbXNvLWxp
c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ0ODgwMTI2IDExOTE1ODI1
NjQgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcg
Njc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtcmVzZXQtbGV2ZWw6bGV2ZWwxOw0KCW1zby1sZXZl
bC1zdHlsZS1saW5rOiJFbnVtMSBUaXRyZSI7DQoJbXNvLWxldmVsLXRleHQ674GuOw0KCW1zby1s
ZXZlbC10YWItc3RvcDo3MC45cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CW1hcmdpbi1sZWZ0OjcwLjlwdDsNCgl0ZXh0LWluZGVudDotMTQuMnB0Ow0KCW1zby1hbnNpLWZv
bnQtc2l6ZTo4LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNv
bG9yOiMwMDQ3N0Y7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMjguN3B0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjguN3B0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA
bGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTY0LjdwdDsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjdwdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6MjAwLjdwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJbWFyZ2luLWxlZnQ6MjAwLjdwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt
ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIzNi43
cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi43
cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNzIuN3B0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzIuN3B0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDozMDguN3B0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgltYXJnaW4tbGVmdDozMDguN3B0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzQ0
LjdwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzQ0
LjdwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM4MC43cHQ7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM4MC43cHQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNv
LWxpc3QtaWQ6ODExMjkwNDExOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5MjQ4NTg4MTQ7fQ0K
QGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0Om5vbmU7DQoJbXNvLWxl
dmVsLXRleHQ6JTE7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjBjbTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCXRleHQtaW5kZW50OjBjbTt9DQpA
bGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLXRleHQ6IkFubmV4ZSAlMlwuIjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6Ny4wY207DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h
cmdpbi1sZWZ0OjMuMGNtOw0KCXRleHQtaW5kZW50OjBjbTt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7
bXNvLWxldmVsLXN0eWxlLWxpbms6IlRpdHJlIDEiOw0KCW1zby1sZXZlbC10YWItc3RvcDo0Mi41
NXB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi41
NXB0Ow0KCXRleHQtaW5kZW50Oi00Mi41NXB0O30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2
ZWwtc3R5bGUtbGluazoiVGl0cmUgMiI7DQoJbXNvLWxldmVsLXRleHQ6IiUzXC4lNFwuIjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6NDIuNTVwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJbWFyZ2luLWxlZnQ6NDIuNTVwdDsNCgl0ZXh0LWluZGVudDotNDIuNTVwdDt9DQpAbGlz
dCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLXN0eWxlLWxpbms6IlRpdHJlIDMiOw0KCW1zby1sZXZl
bC10ZXh0OiIlM1wuJTRcLiU1XC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDo0Mi41NXB0Ow0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi41NXB0Ow0KCXRl
eHQtaW5kZW50Oi00Mi41NXB0O30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtc3R5bGUt
bGluazoiVGl0cmUgNCI7DQoJbXNvLWxldmVsLXRleHQ6IiU2XCkiOw0KCW1zby1sZXZlbC10YWIt
c3RvcDo0Mi41NXB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t
bGVmdDo0Mi41NXB0Ow0KCXRleHQtaW5kZW50Oi0xOS44NXB0O30NCkBsaXN0IGw0OmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpub25lOw0KCW1zby1sZXZlbC10ZXh0OiIiOw0KCW1z
by1sZXZlbC10YWItc3RvcDowY207DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CW1hcmdpbi1sZWZ0OjBjbTsNCgl0ZXh0LWluZGVudDowY207fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0Om5vbmU7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjBjbTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
bWFyZ2luLWxlZnQ6MGNtOw0KCXRleHQtaW5kZW50OjBjbTt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6bm9uZTsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6MGNtOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt
YXJnaW4tbGVmdDowY207DQoJdGV4dC1pbmRlbnQ6MGNtO30NCkBsaXN0IGw1DQoJe21zby1saXN0
LWlkOjk1NjcxNTA3MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0
ZS1pZHM6MTY1NTU4NDE0NCAtMTczNTUxNjg3NCAtMTI4MTU2NTI4IDUzMDI0Mjg1MCAtMjI2MjA2
NzIyIC0xNTA2NTA2MTQwIC0xMTAzNjIzODgyIC0xMTIxMTI2MzAwIC0xMjUwMjQ3NTM4IDEyOTAx
NjgyOTQ7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtc3R5bGUtbGluazpFbnVtNDsNCgltc28tbGV2ZWwtdGV4dDrCrTsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6NzAuODVwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJbWFyZ2luLWxlZnQ6NzAuODVwdDsNCgl0ZXh0LWluZGVudDotMTQuMTVwdDsNCgltc28t
YW5zaS1mb250LXNpemU6OC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIjsNCgljb2xvcjojMDA0NzdGO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDU6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4
MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp
c3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNg0KCXtt
c28tbGlzdC1pZDoxMTc5ODA3OTg0Ow0KCW1zby1saXN0LXR5cGU6c2ltcGxlOw0KCW1zby1saXN0
LXRlbXBsYXRlLWlkczotNjU1OTcyMzk4O30NCkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXN0eWxlLWxpbms6RW51bTI7DQoJbXNv
LWxldmVsLXRleHQ674C0Ow0KCW1zby1sZXZlbC10YWItc3RvcDo5OS4yNXB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5OS4yNXB0Ow0KCXRleHQtaW5k
ZW50Oi0xNC4ycHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX
ZWJkaW5nczsNCgljb2xvcjojMDA0NzdGO30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE1Mjg0
NDI1NTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x
OTY4MjYzMjM4IDY1MTcyMTEyMiA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2
Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsNzpsZXZlbDENCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC1zdHlsZS1saW5rOiJF
bnVtMyBUaXRyZSI7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox
MjcuNnB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDox
MjcuNnB0Ow0KCXRleHQtaW5kZW50Oi0xNC4ycHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJY29sb3I6IzAwNDc3Rjt9DQpAbGlzdCBsNzpsZXZl
bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl
bC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNzpsZXZlbDkN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
QGxpc3QgbDgNCgl7bXNvLWxpc3QtaWQ6MTcyOTcxOTM5MDsNCgltc28tbGlzdC10eXBlOnNpbXBs
ZTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA3NjMxOTU2ODt9DQpAbGlzdCBsODpsZXZlbDEN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC1zdHlsZS1saW5r
OiJFbnVtMSBUYWJsZWF1IjsNCgltc28tbGV2ZWwtdGV4dDrvga47DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjEuMGNtOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm
dDoxLjBjbTsNCgl0ZXh0LWluZGVudDotMTQuMTVwdDsNCgltc28tYW5zaS1mb250LXNpemU6OC4w
cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCWNvbG9yOiMwMDQ3N0Y7fQ0KQGxpc3QgbDkN
Cgl7bXNvLWxpc3QtaWQ6MTk0MTMyODQyMTsNCgltc28tbGlzdC10eXBlOnNpbXBsZTsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6LTg5MDQ4ODEwNDt9DQpAbGlzdCBsOTpsZXZlbDENCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC1zdHlsZS1saW5rOiJFbnVtMyBU
YWJsZWF1IjsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGNt
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjBjbTsN
Cgl0ZXh0LWluZGVudDotMTQuMTVwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1z
by1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCWNvbG9yOiMw
MDQ3N0Y7fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjE5OTQzMzE0ODg7DQoJbXNvLWxpc3Qt
dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MzgwMzkwNjQgLTEyNTY2NjM5
NDggNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcg
Njc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDEwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXJlc2V0LWxldmVsOmxldmVsMTsNCgltc28tbGV2
ZWwtc3R5bGUtbGluazoiRW51bTQgVGl0cmUiOw0KCW1zby1sZXZlbC10ZXh0OsKtOw0KCW1zby1s
ZXZlbC10YWItc3RvcDoxNTUuOTVwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJbWFyZ2luLWxlZnQ6MTU1Ljk1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE0LjJwdDsNCgltc28tYW5z
aS1mb250LXNpemU6OC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOiMwMDQ3N0Y7fQ0KQGxpc3QgbDEw
OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7fQ0KQGxpc3QgbDEwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw0DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMDpsZXZlbDUN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMTA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEwOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwxMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0LWlkOjIxMjY4MDU2OTg7DQoJbXNvLWxp
c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjExODU3NTAyIC0xMTA4
OTU1MTI2IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1
Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwxMTpsZXZlbDENCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC1yZXNldC1sZXZlbDpsZXZlbDE7DQoJbXNv
LWxldmVsLXN0eWxlLWxpbms6IkVudW0yIFRpdHJlIjsNCgltc28tbGV2ZWwtdGV4dDrvgLQ7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjQyLjU1cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQyLjU1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE0LjJwdDsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldlYmRpbmdzOw0KCW1zby1iaWRp
LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMwMDQ3N0Y7fQ0KQGxpc3Qg
bDExOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KQGxpc3QgbDExOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw0DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMTpsZXZl
bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijt9DQpAbGlzdCBsMTE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs
aXN0IGwxMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv
dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t
LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N
CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s
PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlcGVuZGlu
ZyBvbiB3aGF0IGlzIG1lYW50IGJ5IOKAnHNjZW5hcmlvIHRvIGJlIHN1cHBvcnRlZCBmcm9tIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciAocGxhdGZvcm0pIGl0c2VsZiBhbmQgbm90IGluIHRoZSBj
bGllbnQgYXBwIG9yIHJlc291cmNlIHNlcnZlcuKAnSwgaXQgbWF5IGJlIGl0IGRpZmZpY3VsdCAo
b3IgaW1wb3NzaWJsZSkgdG8gYWNoaWV2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIGVuZCwgdGhlIHJlc291cmNl
IHNlcnZlciBvbmx5IGFwcGxpZXMgdG9rZW4gbGlmZXRpbWUgcG9saWN5ICo8Yj5pZiBpdCBkZWNp
ZGVzIHRvIGRvIHNvPC9iPiosIHdoYXRldmVyIHRoZSBBUyBraW5kbHkgYXNrZWQgaGltIHRvIGRv
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA0NzdGO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwNDc3Rjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6d2hpdGUiPi0tPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzUwMzA3
OCI+QmVydHJhbmQgQ0FSTElFUjxicj4NCjxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNDc3RiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA0
NzdGO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+RGUmbmJzcDs6PC9iPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd
IDxiPkRlIGxhIHBhcnQgZGU8L2I+IEpvaG4gQnJhZGxleTxicj4NCjxiPkVudm95w6kmbmJzcDs6
PC9iPiBtYXJkaSAyNSBqdWlsbGV0IDIwMTcgMTg6MDM8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJp
bGwgQnVya2UgJmx0O2JidXJrZUByZWRoYXQuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4g
b2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbT0FVVEgtV0ddIFNo
b3J0IGxpdmVkIGFjY2VzcyB0b2tlbiBhbmQgbm8gcmVmcmVzaCB0b2tlbjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF4LWFnZSBoYXMgdG8gZG8gd2l0aCB1c2VyIHJl
LWF1dGggaW4gY29ubmVjdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlNvbWUgQVMgb25seSBnaXZlIHJlZnJlc2ggdG9rZW5zIGlmIGEgc2NvcGUgb2Ygb2Zm
bGluZV9hY2VzcyBvciBzb21lIHN1Y2ggc3BlY2lhbCBzY29wZSBpcyByZXF1ZXN0ZWQuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBu
byBzdGFuZGFyZCBzY29wZSBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IG9mIGFueSB3YXkgZm9yIHRoZSBjbGllbnQg
dG8gY29udHJvbCB0aGUgbGlmZXRpbWUgb2YgdGhlIGFjY2VzcyB0b2tlbiBvdGhlciB0aGFuIGJ5
IHJldm9raW5nIGl0IHdpdGggdGhlIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzcwMDkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDA5PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZXBlbmRpbmcg
b24gdGhlIEFTIHlvdSBzaG91bGQgYmUgYWJsZSB0byBjb250cm9sIHRoZSBBVCBsaWZldGltZSBv
biBhIHBlciBjbGllbnQgYmFzaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyNSwgMjAxNywgYXQgMTE6MzcgQU0sIEJp
bGwgQnVya2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiYnVya2VAcmVkaGF0LmNvbSI+YmJ1cmtlQHJl
ZGhhdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Rm9yIGJyb3dzZXIgYXBwcywgaW1wbGljaXQgZmxvdyBwcm92aWRlcyBh
biBhY2Nlc3MgdG9rZW4gYnV0IG5vIHJlZnJlc2ggdG9rZW4uJm5ic3A7IEZvciBub24tYnJvd3Nl
ciBhcHBzIG9ubHkgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IGRvZXNuJ3Qgc3VwcGx5IGEgcmVm
cmVzaCB0b2tlbi4mbmJzcDsgQXMgZm9yIHRva2VuDQogYWNjZXNzIHRpbWVzLCBJIGJlbGlldmUg
b25seSBleHRlbnNpb25zIHRvIE9BdXRoIGRlZmluZSB0aG9zZSB0eXBlcyBvZiBjYXBhYmlsaXRp
ZXMuJm5ic3A7IGkuZS4gT3BlbklEIENvbm5lY3QgZGVmaW5lcyBhICZxdW90O21heC1hZ2UmcXVv
dDsgY2xhaW0gdGhhdCB5b3UgY2FuIHBhc3Mgd2hlbiByZXF1ZXN0aW5nIGEgdG9rZW4uPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzI1LzE3IDEwOjQ4IEFNLCBTYXVyYXYgU2Fy
a2FyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSBBbGwsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+V2UgaGF2ZSBhIHNjZW5hcmlvIHdoZXJlIG9uZSBvZiBvdXIgc3Rha2Vob2xkZXIgd2Fu
dHMgdG8gbWFuZGF0b3JpbHkgaW5pdGlhdGUgdGhlIGF1dGhlbnRpY2F0aW9uIGF0IGNlcnRhaW4g
cG9pbnQgb2YgdGltZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkFzIHBlciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3Lm9hdXRoLmNvbS9vYXV0aDItc2Vy
dmVycy9hY2Nlc3MtdG9rZW5zL2FjY2Vzcy10b2tlbi1saWZldGltZS8iPmh0dHBzOi8vd3d3Lm9h
dXRoLmNvbS9vYXV0aDItc2VydmVycy9hY2Nlc3MtdG9rZW5zL2FjY2Vzcy10b2tlbi1saWZldGlt
ZS88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij50aGVyZSBjYW4gYmUgYW4gb3B0aW9uIHdoZXJlIGFjY2VzcyB0b2tlbiBpcyBzZXQgZm9yIGNl
cnRhaW4gdGltZSBhbmQgcmVmcmVzaCB0b2tlbiBpcyBub3Qgc2V0LiBTbyB3ZSB3YW50IHRvIGV4
cGxvcmUgdGhpcyBvcHRpb24gZm9yIHRoaXMgc2NlbmFyaW8uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBjb3VwbGUgb2YgcXVlc3Rp
b25zIHJlZ2FyZGluZyB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPihhKSBJcyB0aGlzICZuYnNwO29wdGlvbiBwYXJ0IG9mIE9BdXRoIDIg
c3BlY2lmaWNhdGlvbiA/IElmIHllcyBjYW4geW91IHBsZWFzZSBwb2ludCBtZSB0byB0aGUgZXhh
Y3QgSUVURiBsaW5rID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+KGIpIElzIHRoZXJlIGFueSBvdGhlciB3YXkgb3VyIHNjZW5hcmlvIGNhbiBi
ZSBhY2hpZXZlZCA/IFdlIHdhbnQgdGhpcyBzY2VuYXJpbyB0byBiZSBzdXBwb3J0ZWQgZnJvbSB0
aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHBsYXRmb3JtKSBpdHNlbGYgYW5kIG5vdCBpbiB0aGUg
Y2xpZW50IGFwcCBvciByZXNvdXJjZSBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFuZCBCZXN0IFJlZ2Fy
ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
YXVyYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5P
QXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTp0YWhvbWE7Zm9udC1zaXplOjlweDtjb2xvcjpncmF5OyI+VGhlIGluZm9y
bWF0aW9uIHRyYW5zbWl0dGVkIGluIHRoZSBwcmVzZW50IGVtYWlsIGluY2x1ZGluZyB0aGUgYXR0
YWNobWVudCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gb3IgZW50aXR5
IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu
ZC9vciBwcml2aWxlZ2VkIG1hdGVyaWFsLg0KIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBk
aXNzZW1pbmF0aW9uIG9yIG90aGVyIHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4g
cmVsaWFuY2UgdXBvbiB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3Ro
ZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNl
aXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUN
CiBhbGwgY29waWVzIG9mIHRoZSBtYXRlcmlhbC4gPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCB0
b3V0ZXMgbGVzIHBpw6hjZXMgcXVpIHkgc29udCDDqXZlbnR1ZWxsZW1lbnQgam9pbnRlcyBzb250
IGNvbmZpZGVudGllbHMgZXQgdHJhbnNtaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNv
biBkZXN0aW5hdGFpcmUuIFRvdXRlIG1vZGlmaWNhdGlvbiwgw6lkaXRpb24sIHV0aWxpc2F0aW9u
IG91IGRpZmZ1c2lvbiBwYXIgdG91dGUgcGVyc29ubmUgb3UgZW50aXTDqSBhdXRyZSBxdWUgbGUg
ZGVzdGluYXRhaXJlIGVzdCBpbnRlcmRpdGUuDQogU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3Nh
Z2UgcGFyIGVycmV1ciwgbm91cyB2b3VzIHJlbWVyY2lvbnMgZGUgbm91cyBlbiBpbmZvcm1lciBp
bW3DqWRpYXRlbWVudCBldCBkZSBsZSBzdXBwcmltZXIgYWluc2kgcXVlIGxlcyBwacOoY2VzIHF1
aSB5IHNvbnQgw6l2ZW50dWVsbGVtZW50IGpvaW50ZXMuPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_HE1PR0301MB213884E812F89B529EC5FE5887B80HE1PR0301MB2138_--


From nobody Tue Jul 25 11:04:34 2017
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 8C751126CD8 for ; Tue, 25 Jul 2017 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=willeke-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 Bub5Di1JuZao for ; Tue, 25 Jul 2017 11:04:30 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 95D2B12426E for ; Tue, 25 Jul 2017 11:04:30 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id l82so15182116ywc.2 for ; Tue, 25 Jul 2017 11:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kFvhqPdrsiem5KsmlCSm2tN1is7llibMqFuphD1mxXA=; b=jtnt2x7b9QDYCUxmpIUPY3b+1s0Alh7Vt4zRTLaKFPe9Z8hIkw1ZDXprMZnqj2EgsY qXDbFTO5Mh5Cbr+wWenSGU7s3aGrJpwPklduGRjK1kchv3nqnea2PvAJgCcpEg1Ijd0M z7iqvZ+czrRKbrwA4tkwFOBBzwhA89nob3GA4h9ahJEflLF/ANp41Apl+H9Zp8DRKL+y JL5EIgMmvqtTeQHiqb5XqlLTcOrvtDH+9RaSXDMMnlPm2UTrH7dIrkd3Q6Re6TWC1lF7 t12P0hnnlooSGcB2fbNJ59AAl1PxCL3CpN9OsaAhUye74cDQCi8SM05fc0gPNy0XzuPy 7dNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kFvhqPdrsiem5KsmlCSm2tN1is7llibMqFuphD1mxXA=; b=OfCcZnMkBAUD0oM2z3tITh39tx2RkRt+WNlwuVxQ9a9QIHEvRP9ANayGTrV4kZAAc0 9QZuzf/mB29lHE9sWz+XVw92sTe2foVML9n6C1QIdDjL5NBgm29zAJ370xNMypQrtvWw PmnKhrMqpWyhFdX84iLE+xEqbnK1G9fxT2jLm6hoc5O6TLqJvdGiTfNGScbgQiqrmrzE er6Cjg1Sz76AJlATk2XkyT0xPYquftMsAOXyH9gm0HuaQuiDC8ei9ddXDiq9bGI/ppHh MX0K46o9Q20xYhEn0GeU5qJOCHpscFo429fTv2xF6W1eX0fKyKaXHUCjZsydBlOdE3Vv X6tQ==
X-Gm-Message-State: AIVw110mqtgtVnoSf7R/DLop48xJ6t7x0HfqrubEdhCb9IoVSFk94YTW NNMPCTfHSboRVOVxz5Fz3jzEqUoy1hES
X-Received: by 10.129.170.74 with SMTP id z10mr14157808ywk.63.1501005869184; Tue, 25 Jul 2017 11:04:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.72.193 with HTTP; Tue, 25 Jul 2017 11:03:48 -0700 (PDT)
In-Reply-To: 
References: 
From: Jim Willeke 
Date: Tue, 25 Jul 2017 14:03:48 -0400
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="089e0825a318a3ba960555282920"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 18:04:33 -0000

--089e0825a318a3ba960555282920
Content-Type: text/plain; charset="UTF-8"

+1 for adoption

--
-jim
Jim Willeke

On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef 
wrote:

> All,
>
> We would like to get a confirmation on the mailing list for the adoption
> of the *JSON Web Token Best Current Practices* as a WG document
> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/
>
> Please, let us know if you support or object to the adoption of this
> document.
>
> Regards,
>  Rifaat
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--089e0825a318a3ba960555282920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1 for adoption

--
-jim
Jim Willeke


On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shek=
h-Yusef <rifaat.ietf@gmail.com> wrote:
All,

We would like to =
get a confirmation on the mailing list for the adoption of the JSON Web =
Token Best Current Practices as a WG document


=

=C2=A0Rifaat



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--089e0825a318a3ba960555282920--


From nobody Tue Jul 25 11:21:11 2017
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 023F412ECF0 for ; Tue, 25 Jul 2017 11:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level: 
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 JtAlE2MGKk0u for ; Tue, 25 Jul 2017 11:21:06 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3BDCD131E9B for ; Tue, 25 Jul 2017 11:21:04 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6PIL25f006041 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jul 2017 18:21:02 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6PIL1Fm024483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jul 2017 18:21:02 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6PIKxJx023179; Tue, 25 Jul 2017 18:21:00 GMT
Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jul 2017 11:20:59 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-5ACC0C5E-0279-4925-A125-492D8B9C388E
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (14G60)
In-Reply-To: 
Date: Tue, 25 Jul 2017 11:20:56 -0700
Cc: John Bradley , Bill Burke , "oauth@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <47685EB5-84E0-43FB-87CF-447C3F958588@ve7jtb.com> 
To: CARLIER Bertrand 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Subject: Re: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 18:21:09 -0000

--Apple-Mail-5ACC0C5E-0279-4925-A125-492D8B9C388E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

In OAuth, the audience for the token is the resource server and not the clie=
nt. OAuth delegates a client to act for a user. OIDC issues an ID token whos=
e audience is the client.=20

Assuming OAuth...

The life of the token is dependent on the risk at the resource.=20

Refresh token lets the client do a proof of possession authentication test t=
o ensure confidence when user not necessarily present.=20

Re-authorize forces the user context in browser to be reverified.=20

Note that many implementations at this stage just re-evaluate cookie state t=
o determine if SSO and grant state is still valid and either authorization i=
s regranted or user is re-authenticated etc.=20

As John mentions, OIDC layers on additional features since it role is user a=
uthen for the client rather than delegation to the client.=20

Phil

> On Jul 25, 2017, at 9:47 AM, CARLIER Bertrand  wrote:
>=20
> Hello,
> =20
> Depending on what is meant by =E2=80=9Cscenario to be supported from the a=
uthorization server (platform) itself and not in the client app or resource s=
erver=E2=80=9D, it may be it difficult (or impossible) to achieve.
> In the end, the resource server only applies token lifetime policy *if it d=
ecides to do so*, whatever the AS kindly asked him to do
> =20
> --
> Bertrand CARLIER
>=20
> =20
> De : OAuth [mailto:oauth-bounces@ietf.org] De la part de John Bradley
> Envoy=C3=A9 : mardi 25 juillet 2017 18:03
> =C3=80 : Bill Burke 
> Cc : oauth@ietf.org
> Objet : Re: [OAUTH-WG] Short lived access token and no refresh token
> =20
> Max-age has to do with user re-auth in connect.
> =20
> Some AS only give refresh tokens if a scope of offline_acess or some such s=
pecial scope is requested.
> There is no standard scope for that.
> =20
> I don=E2=80=99t know of any way for the client to control the lifetime of t=
he access token other than by revoking it with the AS.
> https://tools.ietf.org/html/rfc7009
> =20
> Depending on the AS you should be able to control the AT lifetime on a per=
 client basis.
> =20
> John B.
> =20
> On Jul 25, 2017, at 11:37 AM, Bill Burke  wrote:
> =20
> For browser apps, implicit flow provides an access token but no refresh to=
ken.  For non-browser apps only client credentials grant doesn't supply a re=
fresh token.  As for token access times, I believe only extensions to OAuth d=
efine those types of capabilities.  i.e. OpenID Connect defines a "max-age" c=
laim that you can pass when requesting a token.
> =20
> On 7/25/17 10:48 AM, Saurav Sarkar wrote:
> Hi All,
> =20
> We have a scenario where one of our stakeholder wants to mandatorily initi=
ate the authentication at certain point of time.
> =20
> As per https://www.oauth.com/oauth2-servers/access-tokens/access-token-lif=
etime/
> there can be an option where access token is set for certain time and refr=
esh token is not set. So we want to explore this option for this scenario.
> =20
> I have couple of questions regarding this
> =20
> (a) Is this  option part of OAuth 2 specification ? If yes can you please p=
oint me to the exact IETF link ?
> =20
> (b) Is there any other way our scenario can be achieved ? We want this sce=
nario to be supported from the authorization server (platform) itself and no=
t in the client app or resource server.
> =20
> Thanks and Best Regards,
> Saurav
>=20
>=20
>=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
> The information transmitted in the present email including the attachment i=
s intended only for the person to whom or entity to which it is addressed an=
d may contain confidential and/or privileged material. Any review, retransmi=
ssion, dissemination or other use of, or taking of any action in reliance up=
on this information by persons or entities other than the intended recipient=
 is prohibited. If you received this in error, please contact the sender and=
 delete all copies of the material.=20
>=20
> Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement jointe=
s sont confidentiels et transmis =C3=A0 l'intention exclusive de son destina=
taire. Toute modification, =C3=A9dition, utilisation ou diffusion par toute p=
ersonne ou entit=C3=A9 autre que le destinataire est interdite. Si vous avez=
 re=C3=A7u ce message par erreur, nous vous remercions de nous en informer i=
mm=C3=A9diatement et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=
=A9ventuellement jointes.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-5ACC0C5E-0279-4925-A125-492D8B9C388E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


In OAuth, the audience for the token i=
s the resource server and not the client. OAuth delegates a client to act fo=
r a user. OIDC issues an ID token whose audience is the client. 
<=
div id=3D"AppleMailSignature">
Assum=
ing OAuth...

The life of the token is dependent on the risk at the resource=
. 

Refresh token lets the client do a proof of possession authenticati=
on test to ensure confidence when user not necessarily present. 
<=
div id=3D"AppleMailSignature">
Re-au=
thorize forces the user context in browser to be reverified. 

Note tha=
t many implementations at this stage just re-evaluate cookie state to determ=
ine if SSO and grant state is still valid and either authorization is regran=
ted or user is re-authenticated etc. 

As John mentions, OIDC layers on=
 additional features since it role is user authen for the client rather than=
 delegation to the client. 

Phil

On Jul 25, 2017, a=
t 9:47 AM, CARLIER Bertrand <Bertrand.CARLIER@wavestone.com> wrote:











Hello,


 


Depending on what is meant by =E2=
=80=9Cscenario to be supported from the authorization server (platform) itse=
lf and not in the client app or resource server=E2=80=9D, it may be it diffi=
cult (or impossible) to achieve.


In the end, the resource server o=
nly applies token lifetime policy *if it decides to do so*, whatever t=
he AS kindly asked him to do


 




--

Bertrand CARLIER








 






De : OAuth [mailto:oauth-bounces@ietf.org] De la part de John Br=
adley

Envoy=C3=A9 : mardi 25 juillet 2017 18:03

=C3=80 : Bill Burke <bbu=
rke@redhat.com>

Cc : oauth@ietf.org

Objet : Re: [OAUTH-WG] Short lived access token and no refresh t=
oken






 


Max-age has to do with user re-auth in connect.<=
/o:p>




 






Some AS only give refresh tokens if a scope of offlin=
e_acess or some such special scope is requested.






There is no standard scope for that.




 






I don=E2=80=99t know of any way for the client to con=
trol the lifetime of the access token other than by revoking it with the AS.=








 






Depending on the AS you should be able to control the=
 AT lifetime on a per client basis.






 






John B.






 








On Jul 25, 2017, at 11:37 AM, Bill Burke <bburke@redhat.com> wrote:




 






For browser apps, implicit flow provides an access token but no refr=
esh token.  For non-browser apps only client credentials grant doesn't s=
upply a refresh token.  As for token
 access times, I believe only extensions to OAuth define those types of capa=
bilities.  i.e. OpenID Connect defines a "max-age" claim that you can p=
ass when requesting a token.


 




On 7/25/17 10:48 AM, Saurav Sarkar wrote:<=
/p>







Hi All, 




 






We have a scenario where one of our stakeholder wants=
 to mandatorily initiate the authentication at certain point of time.




 







there can be an option where access token is set for c=
ertain time and refresh token is not set. So we want to explore this option f=
or this scenario.






 






I have couple of questions regarding this<=
/p>





 






(a) Is this  option part of OAuth 2 specificatio=
n ? If yes can you please point me to the exact IETF link ?






 






(b) Is there any other way our scenario can be achiev=
ed ? We want this scenario to be supported from the authorization server (pl=
atform) itself and not in the client app or resource server.








 






Thanks and Best Regards,






Saurav















_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.iet=
f.org/mailman/listinfo/oauth




 




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org=
/mailman/listinfo/oauth








 







The information=
 transmitted in the present email including the attachment is intended only f=
or the person to whom or entity to which it is addressed and may contain con=
fidential and/or privileged material.
 Any review, retransmission, dissemination or other use of, or taking of any=
 action in reliance upon this information by persons or entities other than t=
he intended recipient is prohibited. If you received this in error, please c=
ontact the sender and delete
 all copies of the material. 



Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement jointes s=
ont confidentiels et transmis =C3=A0 l'intention exclusive de son destinatai=
re. Toute modification, =C3=A9dition, utilisation ou diffusion par toute per=
sonne ou entit=C3=A9 autre que le destinataire est interdite.
 Si vous avez re=C3=A7u ce message par erreur, nous vous remercions de nous e=
n informer imm=C3=A9diatement et de le supprimer ainsi que les pi=C3=A8ces q=
ui y sont =C3=A9ventuellement jointes.



____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-5ACC0C5E-0279-4925-A125-492D8B9C388E--


From nobody Tue Jul 25 11:42:26 2017
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 20FC6131EB8 for ; Tue, 25 Jul 2017 11:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 CdvXu3CMauoC for ; Tue, 25 Jul 2017 11:42:23 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 93DED131C56 for ; Tue, 25 Jul 2017 11:32:40 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id u139so12049282qka.1 for ; Tue, 25 Jul 2017 11:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TcDMdqZMa+LFcjdikKjiwn7ttjawPkFC6Z2k+A6aOyA=; b=Ujsac2uDq59IZICTYWa4kgVqHJZaSU1d+b6EgTB+rsCzy2xtUVyOv1tEaYpBz4MOVd gMbf5siuz+Fd4pmkkxdn3rU17z7GsdEKLLr8OxZLa0heNL04M0UOqx4svrtOJEcCdMaF 9x7bDsaVX107YoXiV0ad8zDMEfR6EjATkCswnK26HheHVI7dmMY2+YllRzWTwaT68bA+ Tbhprns2k+NXx6qbABZQLruYnz4RL+MVM+Qku3tyNRVudC8LIFUa+T8qt1hSWcK5vDHb pAsnkzfchDYO6PdpcSUBhdVAqs/ku4qyTDhPrPBXTf5q69goymcUtwelLK93DSTM9UDY YcdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TcDMdqZMa+LFcjdikKjiwn7ttjawPkFC6Z2k+A6aOyA=; b=aBgoAN7bNp4qwFPrUNrcNPjpgvgrOOcUmQxVPF1tOSdSyAANCw0wu3HANIi8vQcc/5 7BuoOKFTCyUk+qyBHDrrmqgct+sJfRPAFs4x9D530j1i8daRGiYYCPh622B3h0R53G9p cUcC9TY7c1cVU2I8mw3/jmCCHj+ismK+M82BjHM59fxilicNq/gZFjR+aD5JW9+PrKLu 5qa9dlnhcysVRoibl1a+mdgyOfeCCK4tqCjmrVTzyXusPPwM2axknyam7LzXtSb/AZAE gTgvH1NltX1r245dP8P6UmlmZ0sBofIG9BLXXowLNfx94DCuOpQ1ENdHrqyk0yTRG2er QUjw==
X-Gm-Message-State: AIVw111iik6CVIE2OIpIcNflKJVYrNb8EYxQ6BtBxq6oGdabbd6K9yWM PhgNeCPGIEcvhASZsM6iq1x4bIu3p53X
X-Received: by 10.55.19.13 with SMTP id d13mr24936017qkh.214.1501007559289; Tue, 25 Jul 2017 11:32:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.18.144 with HTTP; Tue, 25 Jul 2017 11:32:18 -0700 (PDT)
In-Reply-To: 
References:  
From: William Denniss 
Date: Tue, 25 Jul 2017 11:32:18 -0700
Message-ID: 
To: Jim Willeke 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="001a113fff466102ee0555288ecc"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 18:42:25 -0000

--001a113fff466102ee0555288ecc
Content-Type: text/plain; charset="UTF-8"

I support adoption of this document by the working group.

On Tue, Jul 25, 2017 at 11:03 AM, Jim Willeke  wrote:

> +1 for adoption
>
> --
> -jim
> Jim Willeke
>
> On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef  > wrote:
>
>> All,
>>
>> We would like to get a confirmation on the mailing list for the adoption
>> of the *JSON Web Token Best Current Practices* as a WG document
>> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/
>>
>> Please, let us know if you support or object to the adoption of this
>> document.
>>
>> Regards,
>>  Rifaat
>>
>>
>> _______________________________________________
>> 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
>
>

--001a113fff466102ee0555288ecc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I support adoption of this document by the working group.<=
br>

On Tue, =
Jul 25, 2017 at 11:03 AM, Jim Willeke <jim@willeke.com> wrote:=

+1 for adoption

--
-=
jim
Jim Willeke


On Thu, Jul 20, 2017 =
at 8:37 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> w=
rote:
=

All,

We would like to get a confirmatio=
n on the mailing list for the adoption of the JSON Web Token Best Curren=
t Practices as a WG document
=

Please, let us know if you support or object to the adoption=
 of this document.

Regards,
=C2=A0Rifaat=




_____________________________________=
__________

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





--001a113fff466102ee0555288ecc--


From nobody Tue Jul 25 12:36:23 2017
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 357E6131E9C for ; Tue, 25 Jul 2017 12:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GIARovx8NkBX for ; Tue, 25 Jul 2017 12:36:20 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 AE024129B61 for ; Tue, 25 Jul 2017 12:36:19 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id m86so53215087lfi.4 for ; Tue, 25 Jul 2017 12:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=a+g+BhypivapFCqQH0wYabvsvSZnM8nYye/xpDNJSms=; b=eliLZpOrUPq8RodXjoVZW4KfTs35CKkn7ZYfwc4+holum8/lO75AGtU/8RzE/e7nJV kQxhANBMbGbUbTqhKsFAwGq3O1w6tpkGcc1lHWLVxZST1wC3z8QAgZO27m3oWFpVXKos yznG2wIh+z7P080eUA7oPQ0Zr0awaQ6qxbQvdXdsztTC4r3gvaclrNYu7rY6++bZWKZV Tpu5+IqpyKcn2E7i7Jv7FRLXs+29z1GMjIjd01f4/Z9KY4zysKsH9EZTvG1USj2MQzpQ eWRGG9kWG5oRhB7DJVwpR2Ok4otu6hGMQ+/+0j3wogxuYV6jN9B/0aJemZ9aFWNZZng5 Z09A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=a+g+BhypivapFCqQH0wYabvsvSZnM8nYye/xpDNJSms=; b=S0531wzNxU0qHJovNHEzifsMb4pw4nbOvSD5s50r1KZt9qbBvoKU0vW7rKSxEkXSOw SWLJvjVe0G6U4YKWAwfqGQ5nMtsXBRJs1/PvbKu4DNAF4xnxCaCzZacmHuGPSnXG0wqs grF1ueLc1+ragyfZ2NYDSPgUF2J37dNdI8CnP9/4yCxSY6AqbTb//3fbTdGxZWLzsy8G ETKc0JBtKQjYUJg6ozsMzA7M1i5141xB+KYkzWy1lM91bSB/LHeVr2cipB2eL7QM+5w4 U+spXfPMaI0O+P5sFzB493C5xFtbVV+rMsSdfV4fazdP+mp2pEHHh1N+PvL3lMPsGVMy krPg==
X-Gm-Message-State: AIVw112UrmCGPbkRnE+VMTJhwCJp1lM8oXuxFxbhxRsw9bWwSkBSK+um FHCn/FbAqYhqrfx5dRXTacDmcwYGdUpg
X-Received: by 10.46.8.2 with SMTP id 2mr7180275lji.53.1501011377932; Tue, 25 Jul 2017 12:36:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.202.83 with HTTP; Tue, 25 Jul 2017 12:36:17 -0700 (PDT)
In-Reply-To: 
References:   
From: Steve Hutchinson 
Date: Tue, 25 Jul 2017 15:36:17 -0400
Message-ID: 
To: Jim Willeke , oauth 
Content-Type: multipart/alternative; boundary="f403045ec682fc4dd70555297121"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Jul 2017 19:36:22 -0000

--f403045ec682fc4dd70555297121
Content-Type: text/plain; charset="UTF-8"

+1 for adoption

Hutch



On Tue, Jul 25, 2017 at 2:32 PM, William Denniss 
wrote:

> I support adoption of this document by the working group.
>
> On Tue, Jul 25, 2017 at 11:03 AM, Jim Willeke  wrote:
>
>> +1 for adoption
>>
>> --
>> -jim
>> Jim Willeke
>>
>> On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef <
>> rifaat.ietf@gmail.com> wrote:
>>
>>> All,
>>>
>>> We would like to get a confirmation on the mailing list for the adoption
>>> of the *JSON Web Token Best Current Practices* as a WG document
>>> https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/
>>>
>>> Please, let us know if you support or object to the adoption of this
>>> document.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> _______________________________________________
>>> 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
>
>

--f403045ec682fc4dd70555297121
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1 for adoption

Hutch



On Tue, Jul 25, 2017 at 2:32 PM, William Denniss &=
lt;wdenniss@google=
.com> wrote:
I support adoption of this document by the working group.

On Tue, Jul 25, 2017 a=
t 11:03 AM, Jim Willeke <jim@willeke.com> wrote:
+1 f=
or adoption

--
-jim
Jim Willeke


On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef <=
rifaat.ietf@gmai=
l.com> wrote:
<=
div>
All,

<=
/div>
We would like to get a confirmation on the mailing list for the a=
doption of the JSON Web Token Best Current Practices as a WG documen=
t

Please, let us k=
now if you support or object to the adoption of this document.
Regards,
=C2=A0Rifaat



_______________________________________________<=
br>
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





--f403045ec682fc4dd70555297121--


From nobody Wed Jul 26 11:53:23 2017
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 759B4129B14 for ; Wed, 26 Jul 2017 11:53:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 NZgbkn21xmGh for ; Wed, 26 Jul 2017 11:53:20 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 61C7A12426E for ; Wed, 26 Jul 2017 11:53:20 -0700 (PDT)
Received: from [192.168.91.201] ([80.92.121.224]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lp3x6-1e6DPO2I1U-00euAZ for ; Wed, 26 Jul 2017 20:53:18 +0200
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: 
Date: Wed, 26 Jul 2017 20:53:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:wWrUx9W0s9xUdQ8DK0ZaIRfKOSsb1oaa90g1cFqHzQHeZj5r9IO xdK9eBp+XxGZOXTshvrWroRuRc3GiA9UOy6D/0oaZCOr0zSSFgpdoIxqbH1W7ozQo0vmQ9z NdNlW4vjk9XQhaTWM/4KaNiMnEPYb3WL7s5q/aOPkZs7hx+l72xh0j30d+7S0pUM/c+8ivE QseiTCkEHxYkU9wcioCsQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:SmfJOsVnCFE=:ogoJyFKN3th1jbsZKYMJtA f6Lqbbmf6vErt+buf2oQaaEwDbdypqKk0Uxm6dqCVNooiH0bw7DJilPGC0FVVLtwUjbiTox4a 9c22W016Z+33lK5vXvWhuwVCPp5H1yosv27lx54KDvjHk66muW31XKIG3eqv+72cT4Dvdx5aK sxJ03dQuVM8Iao8C7+p/CtZOYdkLZ+11sLpfcayXRZhYgOamUNEP8MZ/0Pvu7ThIcAJ/VKEG0 9dgN7JG7vGH2wuCgLRFDXwT7Z6iTzJ2dUkCFk6YTmcWPERIF5ik1dFM25FqM0W+yBZYmiNGqv aGow55Kx4tBRZoudHm9ivG0EYmWBc9bOfe4dwTnkoG/ZXdXg6YtwUuDwuwt/Pqx76ohd4xbc8 ENIX3rv5+EuwMoFmcq2IR3yHSXpT6YRPMlLhV5n7MWhb3w2/t3RuKvSCZwKk3NbDrtwe5el6l PKB9Gh3VqeXCTaDKLlCQfzt3T7M8fmS51LE5YmCUc8hEeVshVc4gWawp2hogAo6I+B+VZn0qa /g906plJazoQYSx9KWTkymd/1Avj80Uc+Mii8nOp1DSFrA+PzbjaXaQa5z3W5c24Zs72WqEYA 7+qPgnbdV1j68y2rsP6qCTFMT2cN5eDuiX1LHKlof+s7LluS1Wt6gQeuPex7N1eAl7BB7WULd dZxS3ALqU01iu5/Ot/yRaqlJZIt1uhgzu3VCclfYRMLjPkgENm6bHHinTMuVBlU9dG/mMEeAq lyMgqc/51bIy7FcA9L3W5A6RRmKQ14fSdA1qremOMaFOZDKuMFa7obQEBGEUOaHokopUMjNLb +799mPiIIcAOynXJMQJvd/K3mLjFNeoqynYP1nFw4OBLSD/QpY=
Archived-At: 
Subject: [OAUTH-WG] Meeting Notes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jul 2017 18:53:22 -0000

Hi all,

the first set of meeting notes are available for review at
https://datatracker.ietf.org/doc/minutes-99-oauth/00/

I will upload the second part asap.

Ciao
Hannes


From nobody Wed Jul 26 15:44:59 2017
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 73ABF131E98 for ; Wed, 26 Jul 2017 15:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 zqVp3goR6BPd for ; Wed, 26 Jul 2017 15:44:56 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3147D131E8E for ; Wed, 26 Jul 2017 15:44:56 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75B28A1F43 for ; Wed, 26 Jul 2017 22:44:55 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 75B28A1F43
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=bburke@redhat.com
Received: from ovpn-116-148.phx2.redhat.com (ovpn-116-148.phx2.redhat.com [10.3.116.148]) by smtp.corp.redhat.com (Postfix) with ESMTP id 42B2B61F3F for ; Wed, 26 Jul 2017 22:44:55 +0000 (UTC)
To: OAuth WG 
From: Bill Burke 
Message-ID: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com>
Date: Wed, 26 Jul 2017 18:44:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 26 Jul 2017 22:44:55 +0000 (UTC)
Archived-At: 
Subject: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Jul 2017 22:44:57 -0000

Hi all,

I'm looking at Draft 9 of the token-exchange spec.  How would one build 
a request to:

* exchange a token issued by a different domain to a client managed by 
the authorization server.

* exchange a token issued by the authorization server (the STS) for a 
token of a different issuer and different client.  In other words, for a 
token targeted to a specific client in a different authorization server 
or realm or domain or whatever you want to call it.

* exchange a token issued by a different issuer for a token of a 
different issuer and client.

Is the spec missing something like a "requested_issuer" identifier?  
Seems that audience is too opaque of a parameter for the authz server to 
determine how to exchange the token.

Thanks,

Bill




From nobody Thu Jul 27 11:50:38 2017
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 418CF1320CD for ; Thu, 27 Jul 2017 11:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNwgq_PlZSqg for ; Thu, 27 Jul 2017 11:50:29 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 519AB1320D3 for ; Thu, 27 Jul 2017 11:50:28 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id e75so8571003pfj.2 for ; Thu, 27 Jul 2017 11:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=Pizl4/Q8s57Q0QQSjWypPCivU2zAoYXlyCeSDJuNOa6iJOptGBJIzQLo5n0FS/uJBR BxRZ7eRU3xmZa92W4Kc1OceD48h/Ugg7f2pWrazrj+y6F6VFku5o/yt2VIaXuCN+ZF0C cRcu4xZbwMTyjbSTbzR42OE6hlpgHF9F2tGmY=
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=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=i+cOuJjLCU67Z5hpNwiFBwMtlpL2QUXme+xCX4kg/mg+WhXlYNrHUJ4tKIrdlQhPvt HVubtoQMmQ8zImkSjnpoxsbGiRiv4VOmlDTqxBf0aAtNYfWYuPTjiyCAr5bf1XXDXs2U cz/jXjIQzJpcyIGHai0K0aGCr5YMr3tgUDO7SGRnk5LI88Gl30eHX7JeGqUf0L9ROZG6 F9UODA9e3sbVhK+ZTqSunmcLOqZq0ucwyavwpPnN6Budz4mzvCXqUc/tSRFwHPmLcIIr yzz8R4qhgs8KtFL13x1ADf70oSKovKV7IvdzfEMXWVreq3YpghsM/os0FWb2ZL7pSEkV yAPA==
X-Gm-Message-State: AIVw113mmxGUyFXBWkW+Okk2KTbprFdfNJ30vn+R4uSmzvpyW9kOhj5l rqFKokVx4PtESyzSve653AiFtpu4HkqDmr0jPaf1qh0MXv7wVhxXhL2OZC1V6LDV6jnCaadGhg4 4SVT5S1c=
X-Received: by 10.84.232.143 with SMTP id i15mr5409741plk.248.1501181427707; Thu, 27 Jul 2017 11:50:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 11:49:57 -0700 (PDT)
From: Brian Campbell 
Date: Thu, 27 Jul 2017 12:49:57 -0600
Message-ID: 
To: oauth , "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="f40304361ef4be0b9d05555109bf"
Archived-At: 
Subject: [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 18:50:31 -0000

--f40304361ef4be0b9d05555109bf
Content-Type: text/plain; charset="UTF-8"

During the first WG meeting last week
 I asked if use of the
JOSE "crit" (Critical) Header Parameter had been considered as a
recommendation for preventing confusion of one kind of JWT for another.
Time was running short in the meeting so there wasn't much discussion and
it was requested that I take the question to the list. And so here on the
list is that.

Section 3.9
 of
the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE
header parameter but does concede that 'the use of explicit typing may not
achieve disambiguation from existing kinds of JWTs, as the validation rules
for existing kinds JWTs often do not use the "typ" header parameter
value.'  And the recommendations for how to use the Type Header Parameter
in JWT  strongly suggest
that it's not currently being used for any validation.

Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
 to signal the
type/intent/profile/application of a JWT could achieve disambiguation even
in validation of existing kinds of JWTs. The critical header lists other
headers which must be understood and processed by the receiver and that the
JWS/JWE is invalid if those listed aren't understood. So a new type/profile
of JWT that uses the "crit" header would produce JWTs that would be
rejected even by existing applications of JWT validation (that actually
implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction with a
profile/application/type specific header. Or it could provide a bit more of
a framework like defining a registering a new JOSE header "p" (strawman of
p as a very short name for profile) and create a registry for its values. A
JWT header using that approach might look like the following where the
value 1 is registered as some cool new JWT profile/application. The
consumer of such a JWT would have to understand and process the "p" header,
which would mean checking that it had the value expected.

     {
      "alg":"ES256",
      "crit":["p"],
      "p":1
     }

A JOSE compliant JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't known or
understood but is marked as critical.

To me, that seems like an approach to preventing confusion that has more
teeth than the "typ" header. Which is why I asked about it last week and am
now bringing it to the list.

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

--f40304361ef4be0b9d05555109bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


During the first WG meeting last week I a=
sked if use of the JOSE "crit" (Critical) Header Parameter had be=
en considered as a recommendation for preventing confusion of one kind of J=
WT for another. Time was running short in the meeting so there wasn't m=
uch discussion and it was requested that I take the question to the list. A=
nd so here on the list is that. 

Section 3.9 of th=
e JWT BCP draft now recommends explicit typing using the "typ" JW=
S/JWE header parameter but does concede that 'the use of explicit typin=
g may not achieve disambiguation from existing kinds of JWTs, as the valida=
tion rules for existing kinds JWTs often do not use the "typ" hea=
der parameter value.'=C2=A0 And the recommendations for how to use the =
Type Header Par=
ameter in JWT strongly suggest that it's not currently being used f=
or any validation. 

Alternatively using the JWS/JWE "crit" (Crit=
ical) Header Parameter to signal the type/intent/profile/application of=
 a JWT could achieve disambiguation even in validation of existing kinds of=
 JWTs. The critical header lists other headers which must be understood and=
 processed by the receiver and that the JWS/JWE is invalid if those listed =
aren't understood. So a new type/profile of JWT that uses the "cri=
t" header would produce JWTs that would be rejected even by existing a=
pplications of JWT validation (that actually implement "crit" pro=
perly anyway).

The JWT BCP could suggest the use of "crit=
" in conjunction with a profile/application/type specific header. Or i=
t could provide a bit more of a framework like defining a registering a new=
 JOSE header "p" (strawman of p as a very short name for profile)=
 and create a registry for its values. A JWT header using that approach mig=
ht look like the following where the value 1 is registered as some cool new=
 JWT profile/application. The consumer of such a JWT would have to understa=
nd and process the "p" header, which would mean checking that it =
had the value expected. 
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "alg":"ES256",
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 "crit":["p"],
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "p":1
=C2=A0=C2=A0=C2=A0=C2=A0 }

A J=
OSE compliant JWT validator would reject such a JWT even for an OAuth acces=
s token or OIDC id_token because the "p" header isn't known o=
r understood but is marked as critical. 

To me, that seems lik=
e an approach to preventing confusion that has more teeth than the "ty=
p" header. Which is why I asked about it last week and am now bringing=
 it to the list. 












<=
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.
--f40304361ef4be0b9d05555109bf--


From nobody Thu Jul 27 12:31:01 2017
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 019D0131CD7 for ; Thu, 27 Jul 2017 12:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level: 
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 hWfSc397JR95 for ; Thu, 27 Jul 2017 12:30:58 -0700 (PDT)
Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (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 E1A29131C31 for ; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
Received: by mail-it0-f45.google.com with SMTP id v205so71038282itf.1 for ; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxqnsmY86lDsmVHlQ4LcmGoFHKwPin2R2bfMlQxKjVE=; b=tG+R/AHasJf1rfCv4xoLk57KLtas2djKmubE9QBulimpnyvIxBlUHsg4lM2YehxgQp 4phD5pGfGoYuNYGW7yngVAmtAMbNnOzQevQOepC1gpuMslVRgjEjH5er1uIJPkBDMuIq rENCTpMdFMvm+eMwEEt1MrZBa5hZtj7iINwLahpPHy/rj7233UzVqdadsulG9X9wxXqW i0/hC2XrHkGb8vrhfLXRZ4EHaZA9TVruX+AN6NgGbJlyfGR01e2B0RnjFzFDlHl/Eg2I /vohoHnEicE9fFZFr1ucJqMYKHcabAiTP9+cPt4/jNBF+FIDxdVig81SOcE1lwEGMxkf 3SYg==
X-Gm-Message-State: AIVw112MVpN62FeGmZerPezuT6kLR1cqbwuw9oRNj+1VtXn7E/M3hqYk zsjGU5+tXANBKUOgNK6luLhI9q5ug/T93us=
X-Received: by 10.36.185.14 with SMTP id w14mr6557593ite.76.1501183857107; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 12:30:56 -0700 (PDT)
In-Reply-To: 
References: 
From: Nathaniel McCallum 
Date: Thu, 27 Jul 2017 15:30:56 -0400
Message-ID: 
To: Brian Campbell 
Cc: oauth , "jose@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 19:31:00 -0000

What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
 wrote:
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running short
> in the meeting so there wasn't much discussion and it was requested that I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as the
> validation rules for existing kinds JWTs often do not use the "typ" header
> parameter value.'  And the recommendations for how to use the Type Header
> Parameter in JWT strongly suggest that it's not currently being used for any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal
> the type/intent/profile/application of a JWT could achieve disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more of
> a framework like defining a registering a new JOSE header "p" (strawman of p
> as a very short name for profile) and create a registry for its values. A
> JWT header using that approach might look like the following where the value
> 1 is registered as some cool new JWT profile/application. The consumer of
> such a JWT would have to understand and process the "p" header, which would
> mean checking that it had the value expected.
>
>      {
>       "alg":"ES256",
>       "crit":["p"],
>       "p":1
>      }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>


From nobody Thu Jul 27 12:34:50 2017
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 543DC12F290 for ; Thu, 27 Jul 2017 12:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV3XSloH7pw7 for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 1652B129B55 for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id 123so101790430pgj.1 for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnhRzdoimbqhOwwyNhZHA9pWM1yyLBI7aSS1N48vdoY=; b=SelcqJ/rTLxB02yXyhD8ixVLZeuY+kwHNwzU0wSAadpRotn1sPizESw4vv8SexVW1P Lced2VBHl6C26O2UjO7UpI8WfPSPOy/KYRmUCGOkprq5mViwJJ4BAtodOKIBfVCqVZFY THRQm9L65GUIWQbhrENEZJk5jeWyWABD/iwJo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lnhRzdoimbqhOwwyNhZHA9pWM1yyLBI7aSS1N48vdoY=; b=HMGnGG3M1ZuL4GB8rhatdNt4OMhf/15LY4SR0EPK0Mx6OZY5BNiXBhxP2ME5FCJoUy PUro3pTxxMjlhNPddxG+lgPlyEXSURTkhkJlqgOF/GZmrzhC0WEIqjkGr++FOOyd8FUe Yl00Znilbrnc1qsRknnZjMM35DtyQsfab/g1GKT50rDWkpmXRStvHMJ3OjAH/ADTT5O4 jS6qqijX1sBDb+hz821bVdoijump2Bwv9mL7Fm57j7E/9fHxnlJtb9AHiz0Htt+weMKh 006oGqminwIVv65ZUzJiFV4e8+B/X9F8ZmHDl+JnqbOBgL0Twv3N+CZqDnNniEZsltfN oNKg==
X-Gm-Message-State: AIVw1118JoBt+PgFxWgFvZS511vAf/X1GGrdkMHe3b2sQDc/J6TDmWbM O/SIItPaFpdmRFT4/d/+Y9gvcTAtE+5vb94mShmjeHOwX0hrlzTbwKcb7s8tKhbkwcNXvSaRSE3 MDJBY
X-Received: by 10.84.212.1 with SMTP id d1mr5579071pli.17.1501184086633; Thu, 27 Jul 2017 12:34:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 12:34:16 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Thu, 27 Jul 2017 13:34:16 -0600
Message-ID: 
To: Nathaniel McCallum 
Cc: oauth , "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045d1f5e3a0e49055551a86e"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 19:34:49 -0000

--f403045d1f5e3a0e49055551a86e
Content-Type: text/plain; charset="UTF-8"

The draft describes it in
https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum 
wrote:

> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
> ignorant.
>
> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>  wrote:
> > During the first WG meeting last week I asked if use of the JOSE "crit"
> > (Critical) Header Parameter had been considered as a recommendation for
> > preventing confusion of one kind of JWT for another. Time was running
> short
> > in the meeting so there wasn't much discussion and it was requested that
> I
> > take the question to the list. And so here on the list is that.
> >
> > Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> > "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> > typing may not achieve disambiguation from existing kinds of JWTs, as the
> > validation rules for existing kinds JWTs often do not use the "typ"
> header
> > parameter value.'  And the recommendations for how to use the Type Header
> > Parameter in JWT strongly suggest that it's not currently being used for
> any
> > validation.
> >
> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> signal
> > the type/intent/profile/application of a JWT could achieve
> disambiguation
> > even in validation of existing kinds of JWTs. The critical header lists
> > other headers which must be understood and processed by the receiver and
> > that the JWS/JWE is invalid if those listed aren't understood. So a new
> > type/profile of JWT that uses the "crit" header would produce JWTs that
> > would be rejected even by existing applications of JWT validation (that
> > actually implement "crit" properly anyway).
> >
> > The JWT BCP could suggest the use of "crit" in conjunction with a
> > profile/application/type specific header. Or it could provide a bit more
> of
> > a framework like defining a registering a new JOSE header "p" (strawman
> of p
> > as a very short name for profile) and create a registry for its values. A
> > JWT header using that approach might look like the following where the
> value
> > 1 is registered as some cool new JWT profile/application. The consumer of
> > such a JWT would have to understand and process the "p" header, which
> would
> > mean checking that it had the value expected.
> >
> >      {
> >       "alg":"ES256",
> >       "crit":["p"],
> >       "p":1
> >      }
> >
> > A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> > access token or OIDC id_token because the "p" header isn't known or
> > understood but is marked as critical.
> >
> > To me, that seems like an approach to preventing confusion that has more
> > teeth than the "typ" header. Which is why I asked about it last week and
> am
> > now bringing it to the list.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> > material for the sole use of the intended recipient(s). Any review, use,
> > distribution or disclosure by others is strictly prohibited.  If you have
> > received this communication in error, please notify the sender
> immediately
> > by e-mail and delete the message and any file attachments from your
> > computer. Thank you.
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> >
>

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

--f403045d1f5e3a0e49055551a86e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thu, Jul 27, 2017 at 1:30 PM=
, Nathaniel McCallum <npmccallum@redhat.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">What class of attacks is this trying to preve=
nt? I frankly don't see a

problem with confusing different types of JWT. But I may just be

ignorant.




On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell

<bcampbell@pingidentity.co=
m> wrote:

> During the first WG meeting last week I asked if use of the JOSE "=
;crit"

> (Critical) Header Parameter had been considered as a recommendation fo=
r

> preventing confusion of one kind of JWT for another. Time was running =
short

> in the meeting so there wasn't much discussion and it was requeste=
d that I

> take the question to the list. And so here on the list is that.

>

> Section 3.9 of the JWT BCP draft now recommends explicit typing using =
the

> "typ" JWS/JWE header parameter but does concede that 'th=
e use of explicit

> typing may not achieve disambiguation from existing kinds of JWTs, as =
the

> validation rules for existing kinds JWTs often do not use the "ty=
p" header

> parameter value.'=C2=A0 And the recommendations for how to use the=
 Type Header

> Parameter in JWT strongly suggest that it's not currently being us=
ed for any

> validation.

>

> Alternatively using the JWS/JWE "crit" (Critical) Header Par=
ameter to signal

> the type/intent/profile/application of a JWT could achieve disamb=
iguation

> even in validation of existing kinds of JWTs. The critical header list=
s

> other headers which must be understood and processed by the receiver a=
nd

> that the JWS/JWE is invalid if those listed aren't understood. So =
a new

> type/profile of JWT that uses the "crit" header would produc=
e JWTs that

> would be rejected even by existing applications of JWT validation (tha=
t

> actually implement "crit" properly anyway).

>

> The JWT BCP could suggest the use of "crit" in conjunction w=
ith a

> profile/application/type specific header. Or it could provide a bit mo=
re of

> a framework like defining a registering a new JOSE header "p"=
; (strawman of p

> as a very short name for profile) and create a registry for its values=
. A

> JWT header using that approach might look like the following where the=
 value

> 1 is registered as some cool new JWT profile/application. The consumer=
 of

> such a JWT would have to understand and process the "p" head=
er, which would

> mean checking that it had the value expected.

>

>=C2=A0 =C2=A0 =C2=A0 {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"alg":"ES256",

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"crit":["p"],

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"p":1

>=C2=A0 =C2=A0 =C2=A0 }

>

> A JOSE compliant JWT validator would reject such a JWT even for an OAu=
th

> access token or OIDC id_token because the "p" header isn'=
;t known or

> understood but is marked as critical.

>

> To me, that seems like an approach to preventing confusion that has mo=
re

> teeth than the "typ" header. Which is why I asked about it l=
ast week and am

> now bringing it to the list.

>

>

>

>

>

>

>

>

>

>


> CONFIDENTIALITY NOTICE: This email may contain confidentia=
l and privileged

> material for the sole use of the intended recipient(s). Any review, us=
e,

> distribution or disclosure by others is strictly prohibited.=C2=A0 If =
you have

> received this communication in error, please notify the sender immedia=
tely

> by e-mail and delete the message and any file attachments from your
> computer. Thank you.

> _______________________________________________

> jose mailing list

> jose@ietf.org

> https://www.ietf.org/mailman/listinfo/jose
>







<=
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.
--f403045d1f5e3a0e49055551a86e--


From nobody Thu Jul 27 13:27:39 2017
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 0DE88132198; Thu, 27 Jul 2017 13:27:35 -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: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150118725501.11482.12009248355500993067@ietfa.amsl.com>
Date: Thu, 27 Jul 2017 13:27:35 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 20:27:35 -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           : JSON Web Token Best Current Practices
        Authors         : Yaron Sheffer
                          Dick Hardt
                          Michael B. Jones
	Filename        : draft-ietf-oauth-jwt-bcp-00.txt
	Pages           : 11
	Date            : 2017-07-19

Abstract:
   JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-
   based security tokens that contain a set of claims that can be signed
   and/or encrypted.  JWTs are being widely used and deployed as a
   simple security token format in numerous protocols and applications,
   both in the area of digital identity, and in other application areas.
   The goal of this Best Current Practices document is to provide
   actionable guidance leading to secure implementation and deployment
   of JWTs.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-00


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 Thu Jul 27 14:00:10 2017
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 0BBC11321B5 for ; Thu, 27 Jul 2017 14:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level: 
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 liG__1bEx8ZI for ; Thu, 27 Jul 2017 14:00:07 -0700 (PDT)
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (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 007F81321B1 for ; Thu, 27 Jul 2017 14:00:06 -0700 (PDT)
Received: by mail-it0-f48.google.com with SMTP id v205so3385958itf.1 for ; Thu, 27 Jul 2017 14:00:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XxgZ/BpiJRPSmPuIyBMEikiwlmKnTswyKvdgDeqRxmg=; b=fhTr/S8Wo/oW2tB6EExdfQ3cOjsy6LuabvDgnYprq1ufVjRUgf+1w6PzwwH2M6fT/W SmDn7D8G4mEWoFv3oskz+U6xMUlg+RtLgVu4OxwXV56CkGxue1D3gxNWR6fEb8HzExs0 /1ggGb1I28emWVyIVCCxyC4TstFoh7JBnVVyxyiDKfbKNzHkmS1rdlDR7eOLhX7TPGvg MWECw8rAc5TfeYRXLzasvK9E1XXJDvTv0ZCO6Es6vCgAOwFpKkJuZMAWiI666KkmDmG5 Brp49xw93vTbdT0K/IIG/AoK88cy/IMDvRLSvYL2PBlBme09xUQun3G+DpvHSRC8K+Kp WG2w==
X-Gm-Message-State: AIVw113Bxa8iNLCYc28HDZpSXV1ZWbKXILg2UNOjvISJJwC0ArPwA/1B U+oZvC/y4/erxQEtwku5TbokddByHPf5
X-Received: by 10.36.185.14 with SMTP id w14mr6837480ite.76.1501189206161; Thu, 27 Jul 2017 14:00:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 14:00:05 -0700 (PDT)
In-Reply-To: 
References:   
From: Nathaniel McCallum 
Date: Thu, 27 Jul 2017 17:00:05 -0400
Message-ID: 
To: Brian Campbell 
Cc: oauth , "jose@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:00:09 -0000

Even after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
 wrote:
> The draft describes it in
> https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum 
> wrote:
>>
>> What class of attacks is this trying to prevent? I frankly don't see a
>> problem with confusing different types of JWT. But I may just be
>> ignorant.
>>
>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>>  wrote:
>> > During the first WG meeting last week I asked if use of the JOSE "crit"
>> > (Critical) Header Parameter had been considered as a recommendation for
>> > preventing confusion of one kind of JWT for another. Time was running
>> > short
>> > in the meeting so there wasn't much discussion and it was requested that
>> > I
>> > take the question to the list. And so here on the list is that.
>> >
>> > Section 3.9 of the JWT BCP draft now recommends explicit typing using
>> > the
>> > "typ" JWS/JWE header parameter but does concede that 'the use of
>> > explicit
>> > typing may not achieve disambiguation from existing kinds of JWTs, as
>> > the
>> > validation rules for existing kinds JWTs often do not use the "typ"
>> > header
>> > parameter value.'  And the recommendations for how to use the Type
>> > Header
>> > Parameter in JWT strongly suggest that it's not currently being used for
>> > any
>> > validation.
>> >
>> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
>> > signal
>> > the type/intent/profile/application of a JWT could achieve
>> > disambiguation
>> > even in validation of existing kinds of JWTs. The critical header lists
>> > other headers which must be understood and processed by the receiver and
>> > that the JWS/JWE is invalid if those listed aren't understood. So a new
>> > type/profile of JWT that uses the "crit" header would produce JWTs that
>> > would be rejected even by existing applications of JWT validation (that
>> > actually implement "crit" properly anyway).
>> >
>> > The JWT BCP could suggest the use of "crit" in conjunction with a
>> > profile/application/type specific header. Or it could provide a bit more
>> > of
>> > a framework like defining a registering a new JOSE header "p" (strawman
>> > of p
>> > as a very short name for profile) and create a registry for its values.
>> > A
>> > JWT header using that approach might look like the following where the
>> > value
>> > 1 is registered as some cool new JWT profile/application. The consumer
>> > of
>> > such a JWT would have to understand and process the "p" header, which
>> > would
>> > mean checking that it had the value expected.
>> >
>> >      {
>> >       "alg":"ES256",
>> >       "crit":["p"],
>> >       "p":1
>> >      }
>> >
>> > A JOSE compliant JWT validator would reject such a JWT even for an OAuth
>> > access token or OIDC id_token because the "p" header isn't known or
>> > understood but is marked as critical.
>> >
>> > To me, that seems like an approach to preventing confusion that has more
>> > teeth than the "typ" header. Which is why I asked about it last week and
>> > am
>> > now bringing it to the list.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and
>> > privileged
>> > material for the sole use of the intended recipient(s). Any review, use,
>> > distribution or disclosure by others is strictly prohibited.  If you
>> > have
>> > received this communication in error, please notify the sender
>> > immediately
>> > by e-mail and delete the message and any file attachments from your
>> > computer. Thank you.
>> > _______________________________________________
>> > jose mailing list
>> > jose@ietf.org
>> > https://www.ietf.org/mailman/listinfo/jose
>> >
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.


From nobody Thu Jul 27 14:17:53 2017
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 AE402131761; Thu, 27 Jul 2017 14:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2H8r98A1ZnkI; Thu, 27 Jul 2017 14:17:49 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 BBE3C131563; Thu, 27 Jul 2017 14:17:48 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id d136so113996717qkg.3; Thu, 27 Jul 2017 14:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=YUh0/Sbs/PO/kjA1eaoQm7tUnJLTN3No2dRiAIZv2RwbS3NfJNtzGPFOhqmPBBRNJH ujjHfZH6iBV87QVHM+HzPUKR0UVDomY+J1d3C7vPsRFLU/LYjgPB6Q/67RJANk5funrQ s2Mbd0VUAlix4RKefe5JcVSrqdARqLCzhcda9IDxD8jYLNDq3UL01o4VrXqVyZ+5tKKf DM4qsFOVm1mQ3ppwK9jzefT8/dwy8hUqJlVXL89cZCyzFaqTcPCzsbYHuuz5rCdYx51u rI6tLwekk6uI55r4Vc2EowOrv/qeeaBpRoh9j96T38wLqymzb9pJB6Ff4zcRS/0mWW0D T8wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=Tc2RNUuXgpZ+ImtGqqMmyk+CFM+99pLOa4BXKr3NXmXQlAbL8hGIuthbn3k5+iibYH i3R5m6juv9eC+hSnofKGfLBJ5IFOygX7GPFwktwVSM/K9nKQSPkS05nBOWb+NogzGucu 96/wqTHyXZWsqHZCdT6BD3HE1dJQ1BqWnqbn6ram6QD52/Z14qAH47E008PNmdQM4L2L +mLYgaYTmiYhKGCS5hXsDjqsPb9p6UNCZ2CWhanV7IijvTL4i70bvqgshUcXM9/rsc/5 qPwYrYd3Jr9TMRqDzkfX/ul+YKpheS5+gWWNQ3r50oYqYg8kTaLQY0tibS4eEsJhW57t dwxQ==
X-Gm-Message-State: AIVw112AY77cZWoJboJFCrcmbFuFF4rOP4EAU73tM5Fe0RRj2SavCYoU uuOgx2sjUisUEZV3blXyOp4m1oRpCQ==
X-Received: by 10.55.124.67 with SMTP id x64mr7710969qkc.98.1501190267828; Thu, 27 Jul 2017 14:17:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:17:27 -0700 (PDT)
In-Reply-To: 
References:    
From: Dick Hardt 
Date: Thu, 27 Jul 2017 22:17:27 +0100
Message-ID: 
To: Nathaniel McCallum 
Cc: Brian Campbell , oauth ,  "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c062748a7852e0555531832"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:17:51 -0000

--94eb2c062748a7852e0555531832
Content-Type: text/plain; charset="UTF-8"

Only if the audience is different.

On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum 
wrote:

> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> context. But isn't this resolved by audience validation?
>
> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>  wrote:
> > The draft describes it in
> > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7
> >
> > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <
> npmccallum@redhat.com>
> > wrote:
> >>
> >> What class of attacks is this trying to prevent? I frankly don't see a
> >> problem with confusing different types of JWT. But I may just be
> >> ignorant.
> >>
> >> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
> >>  wrote:
> >> > During the first WG meeting last week I asked if use of the JOSE
> "crit"
> >> > (Critical) Header Parameter had been considered as a recommendation
> for
> >> > preventing confusion of one kind of JWT for another. Time was running
> >> > short
> >> > in the meeting so there wasn't much discussion and it was requested
> that
> >> > I
> >> > take the question to the list. And so here on the list is that.
> >> >
> >> > Section 3.9 of the JWT BCP draft now recommends explicit typing using
> >> > the
> >> > "typ" JWS/JWE header parameter but does concede that 'the use of
> >> > explicit
> >> > typing may not achieve disambiguation from existing kinds of JWTs, as
> >> > the
> >> > validation rules for existing kinds JWTs often do not use the "typ"
> >> > header
> >> > parameter value.'  And the recommendations for how to use the Type
> >> > Header
> >> > Parameter in JWT strongly suggest that it's not currently being used
> for
> >> > any
> >> > validation.
> >> >
> >> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> >> > signal
> >> > the type/intent/profile/application of a JWT could achieve
> >> > disambiguation
> >> > even in validation of existing kinds of JWTs. The critical header
> lists
> >> > other headers which must be understood and processed by the receiver
> and
> >> > that the JWS/JWE is invalid if those listed aren't understood. So a
> new
> >> > type/profile of JWT that uses the "crit" header would produce JWTs
> that
> >> > would be rejected even by existing applications of JWT validation
> (that
> >> > actually implement "crit" properly anyway).
> >> >
> >> > The JWT BCP could suggest the use of "crit" in conjunction with a
> >> > profile/application/type specific header. Or it could provide a bit
> more
> >> > of
> >> > a framework like defining a registering a new JOSE header "p"
> (strawman
> >> > of p
> >> > as a very short name for profile) and create a registry for its
> values.
> >> > A
> >> > JWT header using that approach might look like the following where the
> >> > value
> >> > 1 is registered as some cool new JWT profile/application. The consumer
> >> > of
> >> > such a JWT would have to understand and process the "p" header, which
> >> > would
> >> > mean checking that it had the value expected.
> >> >
> >> >      {
> >> >       "alg":"ES256",
> >> >       "crit":["p"],
> >> >       "p":1
> >> >      }
> >> >
> >> > A JOSE compliant JWT validator would reject such a JWT even for an
> OAuth
> >> > access token or OIDC id_token because the "p" header isn't known or
> >> > understood but is marked as critical.
> >> >
> >> > To me, that seems like an approach to preventing confusion that has
> more
> >> > teeth than the "typ" header. Which is why I asked about it last week
> and
> >> > am
> >> > now bringing it to the list.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> >> > privileged
> >> > material for the sole use of the intended recipient(s). Any review,
> use,
> >> > distribution or disclosure by others is strictly prohibited.  If you
> >> > have
> >> > received this communication in error, please notify the sender
> >> > immediately
> >> > by e-mail and delete the message and any file attachments from your
> >> > computer. Thank you.
> >> > _______________________________________________
> >> > jose mailing list
> >> > jose@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/jose
> >> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> > material for the sole use of the intended recipient(s). Any review, use,
> > distribution or disclosure by others is strictly prohibited.  If you have
> > received this communication in error, please notify the sender
> immediately
> > by e-mail and delete the message and any file attachments from your
> > computer. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Subscribe to the HARDTWARE  mail list to learn about
projects I am working on!

--94eb2c062748a7852e0555531832
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Only if the audience is different.=C2=A0

On Thu, Jul 27, 2017 at 10:=
00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:=

Even after reading the whole section, I =
still don't understand the

problem. Yes, a class of attack could exist where an attacker

substitutes a valid JWT from one security context into another

context. But isn't this resolved by audience validation?



On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell


<bcampbell@pingidentity.com> wrote:

> The draft describes it in

> https://tools.ietf.org/ht=
ml/draft-sheffer-oauth-jwt-bcp-01#section-2.7

>

> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>

> wrote:

>>

>> What class of attacks is this trying to prevent? I frankly don'=
;t see a

>> problem with confusing different types of JWT. But I may just be
>> ignorant.

>>

>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell

>> <bcampbell@pingid=
entity.com> wrote:

>> > During the first WG meeting last week I asked if use of the J=
OSE "crit"

>> > (Critical) Header Parameter had been considered as a recommen=
dation for

>> > preventing confusion of one kind of JWT for another. Time was=
 running

>> > short

>> > in the meeting so there wasn't much discussion and it was=
 requested that

>> > I

>> > take the question to the list. And so here on the list is tha=
t.

>> >

>> > Section 3.9 of the JWT BCP draft now recommends explicit typi=
ng using

>> > the

>> > "typ" JWS/JWE header parameter but does concede tha=
t 'the use of

>> > explicit

>> > typing may not achieve disambiguation from existing kinds of =
JWTs, as

>> > the

>> > validation rules for existing kinds JWTs often do not use the=
 "typ"

>> > header

>> > parameter value.'=C2=A0 And the recommendations for how t=
o use the Type

>> > Header

>> > Parameter in JWT strongly suggest that it's not currently=
 being used for

>> > any

>> > validation.

>> >

>> > Alternatively using the JWS/JWE "crit" (Critical) H=
eader Parameter to

>> > signal

>> > the type/intent/profile/application of a JWT could achie=
ve

>> > disambiguation

>> > even in validation of existing kinds of JWTs. The critical he=
ader lists

>> > other headers which must be understood and processed by the r=
eceiver and

>> > that the JWS/JWE is invalid if those listed aren't unders=
tood. So a new

>> > type/profile of JWT that uses the "crit" header wou=
ld produce JWTs that

>> > would be rejected even by existing applications of JWT valida=
tion (that

>> > actually implement "crit" properly anyway).

>> >

>> > The JWT BCP could suggest the use of "crit" in conj=
unction with a

>> > profile/application/type specific header. Or it could provide=
 a bit more

>> > of

>> > a framework like defining a registering a new JOSE header &qu=
ot;p" (strawman

>> > of p

>> > as a very short name for profile) and create a registry for i=
ts values.

>> > A

>> > JWT header using that approach might look like the following =
where the

>> > value

>> > 1 is registered as some cool new JWT profile/application. The=
 consumer

>> > of

>> > such a JWT would have to understand and process the "p&q=
uot; header, which

>> > would

>> > mean checking that it had the value expected.

>> >

>> >=C2=A0 =C2=A0 =C2=A0 {

>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"alg":"ES256",<=
br>
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"crit":["p"],
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"p":1

>> >=C2=A0 =C2=A0 =C2=A0 }

>> >

>> > A JOSE compliant JWT validator would reject such a JWT even f=
or an OAuth

>> > access token or OIDC id_token because the "p" heade=
r isn't known or

>> > understood but is marked as critical.

>> >

>> > To me, that seems like an approach to preventing confusion th=
at has more

>> > teeth than the "typ" header. Which is why I asked a=
bout it last week and

>> > am

>> > now bringing it to the list.

>> >

>> >

>> >

>> >

>> >

>> >

>> >

>> >

>> >

>> >

>> > CONFIDENTIALITY NOTICE: This email may contain confidential a=
nd

>> > privileged

>> > material for the sole use of the intended recipient(s). Any r=
eview, use,

>> > distribution or disclosure by others is strictly prohibited.=
=C2=A0 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.

>> > _______________________________________________

>> > jose mailing list

>> > jose@ietf.org

>> > https://www.ietf.org/mailman/listinfo/j=
ose

>> >

>

>

>

> CONFIDENTIALITY NOTICE: This email may contain confidential and privil=
eged

> material for the sole use of the intended recipient(s). Any review, us=
e,

> distribution or disclosure by others is strictly prohibited.=C2=A0 If =
you have

> received this communication in error, please notify the sender immedia=
tely

> by e-mail and delete the message and any file attachments from your
> computer. Thank you.




_______________________=
________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





-- 
=

Subscribe to the HARDTWARE mail list to l=
earn about projects I am working on!




--94eb2c062748a7852e0555531832--


From nobody Thu Jul 27 14:19:58 2017
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 67B7C131771; Thu, 27 Jul 2017 14:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8,  RP_MATCHES_RCVD=-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 rtR8bQjO1m31; Thu, 27 Jul 2017 14:19:53 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 92431131563; Thu, 27 Jul 2017 14:19:53 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6RLJpca029999 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 21:19:51 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6RLJpC1006758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 21:19:51 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6RLJokN002416; Thu, 27 Jul 2017 21:19:50 GMT
Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jul 2017 14:19:50 -0700
From: Phil Hunt 
Message-Id: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 27 Jul 2017 14:19:48 -0700
In-Reply-To: 
Cc: Brian Campbell , oauth , "jose@ietf.org" 
To: Nathaniel McCallum 
References:    
X-Mailer: Apple Mail (2.3273)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:19:56 -0000

--Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We have the use case in SECEVENTS where a logout event (e.g. OIDF =
backchannel logout) is extremely close to an ID_TOKEN.=20

Older relying parties who are do not yet support logout could be tricked =
into accepting a logout assertion as an ID_TOKEN since they are too =
similar, and  because a valid ID_TOKEN parser is in theory allowed to =
ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - =
leading to a possible erroneous acceptance of the logout event AS and =
ID_TOKEN.

Because of this the issue of distinguishing classes or types of JWTs =
emerged.

We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =
=E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help.  But that =
really lead to the idea there there should be some best practices in the =
JWT BCP covering the issue(s).

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com =
phil.hunt@oracle.com =

> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum =
 wrote:
>=20
> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> context. But isn't this resolved by audience validation?
>=20
> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>  wrote:
>> The draft describes it in
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html=
_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR=
oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv=
zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC=
ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D=20
>>=20
>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum =

>> wrote:
>>>=20
>>> What class of attacks is this trying to prevent? I frankly don't see =
a
>>> problem with confusing different types of JWT. But I may just be
>>> ignorant.
>>>=20
>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>>>  wrote:
>>>> During the first WG meeting last week I asked if use of the JOSE =
"crit"
>>>> (Critical) Header Parameter had been considered as a recommendation =
for
>>>> preventing confusion of one kind of JWT for another. Time was =
running
>>>> short
>>>> in the meeting so there wasn't much discussion and it was requested =
that
>>>> I
>>>> take the question to the list. And so here on the list is that.
>>>>=20
>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing =
using
>>>> the
>>>> "typ" JWS/JWE header parameter but does concede that 'the use of
>>>> explicit
>>>> typing may not achieve disambiguation from existing kinds of JWTs, =
as
>>>> the
>>>> validation rules for existing kinds JWTs often do not use the "typ"
>>>> header
>>>> parameter value.'  And the recommendations for how to use the Type
>>>> Header
>>>> Parameter in JWT strongly suggest that it's not currently being =
used for
>>>> any
>>>> validation.
>>>>=20
>>>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter =
to
>>>> signal
>>>> the type/intent/profile/application of a JWT could achieve
>>>> disambiguation
>>>> even in validation of existing kinds of JWTs. The critical header =
lists
>>>> other headers which must be understood and processed by the =
receiver and
>>>> that the JWS/JWE is invalid if those listed aren't understood. So a =
new
>>>> type/profile of JWT that uses the "crit" header would produce JWTs =
that
>>>> would be rejected even by existing applications of JWT validation =
(that
>>>> actually implement "crit" properly anyway).
>>>>=20
>>>> The JWT BCP could suggest the use of "crit" in conjunction with a
>>>> profile/application/type specific header. Or it could provide a bit =
more
>>>> of
>>>> a framework like defining a registering a new JOSE header "p" =
(strawman
>>>> of p
>>>> as a very short name for profile) and create a registry for its =
values.
>>>> A
>>>> JWT header using that approach might look like the following where =
the
>>>> value
>>>> 1 is registered as some cool new JWT profile/application. The =
consumer
>>>> of
>>>> such a JWT would have to understand and process the "p" header, =
which
>>>> would
>>>> mean checking that it had the value expected.
>>>>=20
>>>>     {
>>>>      "alg":"ES256",
>>>>      "crit":["p"],
>>>>      "p":1
>>>>     }
>>>>=20
>>>> A JOSE compliant JWT validator would reject such a JWT even for an =
OAuth
>>>> access token or OIDC id_token because the "p" header isn't known or
>>>> understood but is marked as critical.
>>>>=20
>>>> To me, that seems like an approach to preventing confusion that has =
more
>>>> teeth than the "typ" header. Which is why I asked about it last =
week and
>>>> am
>>>> now bringing it to the list.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged
>>>> material for the sole use of the intended recipient(s). Any review, =
use,
>>>> distribution or disclosure by others is strictly prohibited.  If =
you
>>>> have
>>>> received this communication in error, please notify the sender
>>>> immediately
>>>> by e-mail and delete the message and any file attachments from your
>>>> computer. Thank you.
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
=20
>>>>=20
>>=20
>>=20
>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged
>> material for the sole use of the intended recipient(s). Any review, =
use,
>> distribution or disclosure by others is strictly prohibited.  If you =
have
>> received this communication in error, please notify the sender =
immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
=20


--Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We have the use case in SECEVENTS where a logout event (e.g. =
OIDF backchannel logout) is extremely close to an ID_TOKEN. 

Older relying parties =
who are do not yet support logout could be tricked into accepting a =
logout assertion as an ID_TOKEN since they are too similar, and =
 because a valid ID_TOKEN parser is in theory allowed to ignore =
claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading =
to a possible erroneous acceptance of the logout event AS and =
ID_TOKEN.

Because of this the issue of distinguishing classes or types =
of JWTs emerged.

We discussed a number of differentiators like =E2=80=9Caud=E2=80=
=9D, =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. =
 But that really lead to the idea there there should be some best =
practices in the JWT BCP covering the issue(s).



Phil

Oracle Corporation, Identity Cloud =
Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com




On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even =
after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an =
attacker
substitutes a valid JWT from one security context =
into another
context. But isn't this resolved by audience =
validation?

On Thu, Jul 27, 2017 at 3:34 =
PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it =
in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie=
tf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=
=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5=
biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b=
9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&=
e=3D 

On Thu, Jul 27, 2017 at 1:30 PM, =
Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What =
class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just =
be
ignorant.

On Thu, Jul 27, =
2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG =
meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a =
recommendation for
preventing confusion of one kind of JWT =
for another. Time was running
short
in the =
meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on =
the list is that.

Section 3.9 of the JWT =
BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use =
of
explicit
typing may not achieve =
disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the =
"typ"
header
parameter value.'  And the =
recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently =
being used for
any
validation.

Alternatively using the JWS/JWE "crit" =
(Critical) Header Parameter to
signal
the =
type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing =
kinds of JWTs. The critical header lists
other headers =
which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't =
understood. So a new
type/profile of JWT that uses the =
"crit" header would produce JWTs that
would be rejected =
even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction =
with a
profile/application/type specific header. Or it =
could provide a bit more
of
a framework like =
defining a registering a new JOSE header "p" (strawman
of =
p
as a very short name for profile) and create a registry =
for its values.
A
JWT header using that =
approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The =
consumer
of
such a JWT would have to =
understand and process the "p" header, which
would
mean checking that it had the value expected.
     {
 =
     "alg":"ES256",
 =
     "crit":["p"],
 =
     "p":1
 =
    }

A JOSE compliant =
JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't =
known or
understood but is marked as critical.

To me, that seems like an approach to =
preventing confusion that has more
teeth than the "typ" =
header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY =
NOTICE: This email may contain confidential and
privileged
material for the sole use of the =
intended recipient(s). Any review, use,
distribution or =
disclosure by others is strictly prohibited.  If you
have
received this communication in error, =
please notify the sender
immediately
by =
e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx=
BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am=
p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_=
E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 




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

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx=
BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am=
p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_=
E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 

=

--Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219--


From nobody Thu Jul 27 14:29:44 2017
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 5F1431321BB; Thu, 27 Jul 2017 14:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 q-xh4Gj3Qq9n; Thu, 27 Jul 2017 14:29:34 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 0158D1321BD; Thu, 27 Jul 2017 14:29:33 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id p3so68181167qtg.2; Thu, 27 Jul 2017 14:29:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=UpO8xZzuHo4vtbTfiN2K+TSoXSCin+2JqXkt++jbzaXsaXdWIE7R95wCj+/myOK4Uc nd0/8VH4+lFuWFBQlSvp7/ltcsHxVqJbDGffESRh5P4gVMk+U6mCwAqR5dbNvl27Irmw fHv4xh5VNifsi4TbRyvmh58NgeVqD2QWqE5Og7yjwQxQyXnX1BnZV03Rej/kHD7DKzWY YN6wWriizYFk+1vtObex5LLELxRUEr+WZH/uDcJIulQc+0Y+Vukbb9HmgJWXgheFrLK4 dApngr1FDMXOCh675WWeIn8cBfwhTeQGV1eXLnvmr8J+nBb6Zy23KFgTvqAdKLFy1MJE yOYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=Y+oz7a7J3F8EYIJycLS8R5Kz9udUoULHJ4dMHPXP292E6PDzOscK3SBR+c6F3IQvxl MhLCbdxUG2FjGLa8mVE82dat69KMDEtExq4KzrphANn9O4v5HzpMlVHV6tvB1bwmu0SX Cdt2dpU5vCXT3YpAMONyGj82gVlMhc56tO4xWgm6EjDOwcw//14JYjPHJRuK8rYBzw0D xX61wSKDxNBH8CGAMmIm8KKgrHS/Zbcqd12B7R0U8MONTBLEZ09KWWZ7ZUMCvgQa2B7h zAh/yubROlGPOS+cs1pZAWzwTea05xBIhT4KdAnpe3WNScx7QRyYfhF3TVKiZirOkZkk ntYQ==
X-Gm-Message-State: AIVw112qzOLPcvgAfBNe4ubX3Pvzk1d4UU4Gq7jVWWClk14jOu4Kg1mq 3K/9d1gLUH73IxAbDPrSCPW+D1sGLQ==
X-Received: by 10.237.63.92 with SMTP id q28mr8355802qtf.49.1501190973101; Thu, 27 Jul 2017 14:29:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:29:09 -0700 (PDT)
In-Reply-To: 
References: 
From: Dick Hardt 
Date: Thu, 27 Jul 2017 22:29:09 +0100
Message-ID: 
To: Brian Campbell 
Cc: oauth , "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1146e496b11e36055553428c"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:29:37 -0000

--001a1146e496b11e36055553428c
Content-Type: text/plain; charset="UTF-8"

Brian: I did not think that 'crit' processing is required in JWT
https://tools.ietf.org/html/rfc7519

We have two goals:

Preventing new JWT profiles from being confused with older JWTs, which
'typ' solves (as does your proposal of 'crit' and 'p', but requires more
bytes)

Preventing existing JWT implementations from being confused with new JWT
profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs.



On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell 
wrote:

> During the first WG meeting last week
>  I asked if use of
> the JOSE "crit" (Critical) Header Parameter had been considered as a
> recommendation for preventing confusion of one kind of JWT for another.
> Time was running short in the meeting so there wasn't much discussion and
> it was requested that I take the question to the list. And so here on the
> list is that.
>
> Section 3.9
> 
> of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE
> header parameter but does concede that 'the use of explicit typing may not
> achieve disambiguation from existing kinds of JWTs, as the validation rules
> for existing kinds JWTs often do not use the "typ" header parameter
> value.'  And the recommendations for how to use the Type Header Parameter
> in JWT  strongly suggest
> that it's not currently being used for any validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
>  to signal the
> type/intent/profile/application of a JWT could achieve disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more of
> a framework like defining a registering a new JOSE header "p" (strawman of
> p as a very short name for profile) and create a registry for its values. A
> JWT header using that approach might look like the following where the
> value 1 is registered as some cool new JWT profile/application. The
> consumer of such a JWT would have to understand and process the "p" header,
> which would mean checking that it had the value expected.
>
>      {
>       "alg":"ES256",
>       "crit":["p"],
>       "p":1
>      }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>


-- 
Subscribe to the HARDTWARE  mail list to learn about
projects I am working on!

--001a1146e496b11e36055553428c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Brian: I did not think that 'crit' processing is r=
equired in JWT=C2=A0https:/=
/tools.ietf.org/html/rfc7519

We have two goals:=C2=
=A0

Preventing new JWT profiles from being confuse=
d with older JWTs, which 'typ' solves (as does your proposal of =
9;crit' and 'p', but requires more bytes)

<=
div>Preventing existing JWT implementations from being confused with new JW=
T profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs=
.



<=
div class=3D"gmail_quote">On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <=
span dir=3D"ltr"><bcampbell@pingidentity.com> wrote:
During the first WG meeting last week I asked if use of the JOSE "crit&qu=
ot; (Critical) Header Parameter had been considered as a recommendation for=
 preventing confusion of one kind of JWT for another. Time was running shor=
t in the meeting so there wasn't much discussion and it was requested t=
hat I take the question to the list. And so here on the list is that. 
<=
br>
Section 3.9 of the JWT BCP draft now=
 recommends explicit typing using the "typ" JWS/JWE header parame=
ter but does concede that 'the use of explicit typing may not achieve d=
isambiguation from existing kinds of JWTs, as the validation rules for exis=
ting kinds JWTs often do not use the "typ" header parameter value=
.'=C2=A0 And the recommendations for how to use the Type Header Para=
meter in JWT strongly suggest that it's not currently being used fo=
r any validation. 

Alternatively using the JWS/JWE "=
;crit" (Critical) Header Parameter to signal the type/intent/profi=
le/application of a JWT could achieve disambiguation even in validatio=
n of existing kinds of JWTs. The critical header lists other headers which =
must be understood and processed by the receiver and that the JWS/JWE is in=
valid if those listed aren't understood. So a new type/profile of JWT t=
hat uses the "crit" header would produce JWTs that would be rejec=
ted even by existing applications of JWT validation (that actually implemen=
t "crit" properly anyway).

The JWT BCP could suggest=
 the use of "crit" in conjunction with a profile/application/type=
 specific header. Or it could provide a bit more of a framework like defini=
ng a registering a new JOSE header "p" (strawman of p as a very s=
hort name for profile) and create a registry for its values. A JWT header u=
sing that approach might look like the following where the value 1 is regis=
tered as some cool new JWT profile/application. The consumer of such a JWT =
would have to understand and process the "p" header, which would =
mean checking that it had the value expected. 
=C2=A0
=C2=A0=C2=A0=C2=
=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alg":"ES256&q=
uot;,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "crit":["p"],=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p":1
=C2=A0=C2=A0=C2=A0=C2=
=A0 }

A JOSE compliant JWT validator would reject such a JWT e=
ven for an OAuth access token or OIDC id_token because the "p" he=
ader isn't known or understood but is marked as critical. 

To me, that seems like an approach to preventing confusion that has more t=
eeth than the "typ" header. Which is why I asked about it last we=
ek and am now bringing it to the list. 









=





<=
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.
____________________=
___________________________

jose mailing list

jose@ietf.org

https://www.ietf.org/mailman/listinfo/jose





-- 
=

Subscribe to the HARDTWARE mail list to learn abou=
t projects I am working on!



--001a1146e496b11e36055553428c--


From nobody Thu Jul 27 14:40:19 2017
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 55274131DA4 for ; Thu, 27 Jul 2017 14:40:17 -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_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 (2048-bit key) header.d=ve7jtb-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 stjjDaXFgh50 for ; Thu, 27 Jul 2017 14:40:12 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 C15EA131CEB for ; Thu, 27 Jul 2017 14:40:11 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id s6so80096783qtc.1 for ; Thu, 27 Jul 2017 14:40:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lRqINnBfSDKOYnRH/pIecXdzOUPgrVS7Wtps9cq/gWo=; b=X/yXZ9qF5YraVfFWXAcUxeYtutbPOYYr6pA23PqzjzVpdgxh0aBHxAkV2HftLpaQQZ GLjrzUzx2lKxPLi2jW6CwvIMX8VH1CXDM7kC2mBnJBx10vyq4xrMLuQ76tLAQkLsWLga lkTLdG8fYGkR3cwh9x8BELAjCKGV3tQ+ZfBcLXGsfRrv/2kwTSVs0H9dv0EWCcZNBhMj nVM3AWjxuUoMP7ovKNIJbnPiSKPWapEjC8yKnFU97T3AIFUw5CSssRLgWnMm8wD4KlRb f8zR6wkkW07DHSp9kffABnPqgkFZrmOevRwyfw+eZfX+evl92cU2wOQIg4Dn+7ZCNXqC c6cA==
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=lRqINnBfSDKOYnRH/pIecXdzOUPgrVS7Wtps9cq/gWo=; b=J2xNz9G7mBWFoGrfcuuf9TACZXUeSMfSeZq58Ps5b0/Dhst+UhbH2+RHwMaGUDkdJ3 6iF/nPhWJ5zg7v5J4NpTBNiF+xwtQHdlQyhPuvbNA5ASRcrZJ9BG401LPAzg5XbGUZtT nn4Z4ET39fjBIXjpKXoNWPXT1yms4SMpeOrT/SU3gswszkYeYfYkW4D097logYAnW6uT fXeUtb/WCn/mhUT9D6ib9oBkPZ76j+FAxFfL2C1ZBIymgjyeFKWA+K37qKkpTQNFAdq+ 99MSeHxIu9Q1IYwVUuaG89ZBti1+t3i0oL6j7WtrDAnHTr8TkomjHOVs1PWkWDqHJD7T LTew==
X-Gm-Message-State: AIVw110RD0Ol3i4L1o45gtP7b5r+sK2NOjPMNqEKbEDp0em2FcBVOGbL o9OkwLjnA635DQ5VOARdOw==
X-Received: by 10.200.3.135 with SMTP id t7mr7593721qtg.216.1501191610483; Thu, 27 Jul 2017 14:40:10 -0700 (PDT)
Received: from [192.168.86.103] ([191.115.36.222]) by smtp.gmail.com with ESMTPSA id m123sm13847245qke.12.2017.07.27.14.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 14:40:09 -0700 (PDT)
From: John Bradley 
Message-Id: <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 27 Jul 2017 17:40:02 -0400
In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
Cc: Nathaniel McCallum , oauth , "jose@ietf.org" 
To: Phil Hunt 
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030435c300b6249e05555368f8"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:40:17 -0000

--f4030435c300b6249e05555368f8
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313"


--Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Not that I am against the general desire for JWT not to be confused, but =
the attack surface for someone to take a sec event from one context and =
replay it as a id_token to login is very small and if the client is =
correctly configured would not work as it is now.

The only way you could replay the sec event JWT is via the implicit =
flow.   The other flows would require a malicious AS and at that point =
you have bigger problems with a compromised token endpoint.

If you were to create a implicit response with the sec event token that =
has the correct issuer and aud, connect requires that nonce value from =
the request be present in the id_token.   This would require that the =
attacker somehow get the AS to put not only the claim but the correct =
value from the request into the token.

All in all I think that it is more likely (not 100% I admit) that a =
client will do that rather than checking the typ or a new crit JWT =
header parameter.

I am all for a general solution for this but I think the issue with =
Connect is overstated sometimes.

John B.
=20
> On Jul 27, 2017, at 5:19 PM, Phil Hunt  wrote:
>=20
> We have the use case in SECEVENTS where a logout event (e.g. OIDF =
backchannel logout) is extremely close to an ID_TOKEN.=20
>=20
> Older relying parties who are do not yet support logout could be =
tricked into accepting a logout assertion as an ID_TOKEN since they are =
too similar, and  because a valid ID_TOKEN parser is in theory allowed =
to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) =
- leading to a possible erroneous acceptance of the logout event AS and =
ID_TOKEN.
>=20
> Because of this the issue of distinguishing classes or types of JWTs =
emerged.
>=20
> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =
=E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help.  But that =
really lead to the idea there there should be some best practices in the =
JWT BCP covering the issue(s).
>=20
> Phil
>=20
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum =
> wrote:
>>=20
>> Even after reading the whole section, I still don't understand the
>> problem. Yes, a class of attack could exist where an attacker
>> substitutes a valid JWT from one security context into another
>> context. But isn't this resolved by audience validation?
>>=20
>> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>> > =
wrote:
>>> The draft describes it in
>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html=
_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR=
oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv=
zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC=
ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D =
=20
>>>=20
>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum =
>
>>> wrote:
>>>>=20
>>>> What class of attacks is this trying to prevent? I frankly don't =
see a
>>>> problem with confusing different types of JWT. But I may just be
>>>> ignorant.
>>>>=20
>>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>>>> > =
wrote:
>>>>> During the first WG meeting last week I asked if use of the JOSE =
"crit"
>>>>> (Critical) Header Parameter had been considered as a =
recommendation for
>>>>> preventing confusion of one kind of JWT for another. Time was =
running
>>>>> short
>>>>> in the meeting so there wasn't much discussion and it was =
requested that
>>>>> I
>>>>> take the question to the list. And so here on the list is that.
>>>>>=20
>>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing =
using
>>>>> the
>>>>> "typ" JWS/JWE header parameter but does concede that 'the use of
>>>>> explicit
>>>>> typing may not achieve disambiguation from existing kinds of JWTs, =
as
>>>>> the
>>>>> validation rules for existing kinds JWTs often do not use the =
"typ"
>>>>> header
>>>>> parameter value.'  And the recommendations for how to use the Type
>>>>> Header
>>>>> Parameter in JWT strongly suggest that it's not currently being =
used for
>>>>> any
>>>>> validation.
>>>>>=20
>>>>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter =
to
>>>>> signal
>>>>> the type/intent/profile/application of a JWT could achieve
>>>>> disambiguation
>>>>> even in validation of existing kinds of JWTs. The critical header =
lists
>>>>> other headers which must be understood and processed by the =
receiver and
>>>>> that the JWS/JWE is invalid if those listed aren't understood. So =
a new
>>>>> type/profile of JWT that uses the "crit" header would produce JWTs =
that
>>>>> would be rejected even by existing applications of JWT validation =
(that
>>>>> actually implement "crit" properly anyway).
>>>>>=20
>>>>> The JWT BCP could suggest the use of "crit" in conjunction with a
>>>>> profile/application/type specific header. Or it could provide a =
bit more
>>>>> of
>>>>> a framework like defining a registering a new JOSE header "p" =
(strawman
>>>>> of p
>>>>> as a very short name for profile) and create a registry for its =
values.
>>>>> A
>>>>> JWT header using that approach might look like the following where =
the
>>>>> value
>>>>> 1 is registered as some cool new JWT profile/application. The =
consumer
>>>>> of
>>>>> such a JWT would have to understand and process the "p" header, =
which
>>>>> would
>>>>> mean checking that it had the value expected.
>>>>>=20
>>>>>     {
>>>>>      "alg":"ES256",
>>>>>      "crit":["p"],
>>>>>      "p":1
>>>>>     }
>>>>>=20
>>>>> A JOSE compliant JWT validator would reject such a JWT even for an =
OAuth
>>>>> access token or OIDC id_token because the "p" header isn't known =
or
>>>>> understood but is marked as critical.
>>>>>=20
>>>>> To me, that seems like an approach to preventing confusion that =
has more
>>>>> teeth than the "typ" header. Which is why I asked about it last =
week and
>>>>> am
>>>>> now bringing it to the list.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged
>>>>> material for the sole use of the intended recipient(s). Any =
review, use,
>>>>> distribution or disclosure by others is strictly prohibited.  If =
you
>>>>> have
>>>>> received this communication in error, please notify the sender
>>>>> immediately
>>>>> by e-mail and delete the message and any file attachments from =
your
>>>>> computer. Thank you.
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org 
>>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
=20
>>>>>=20
>>>=20
>>>=20
>>>=20
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged
>>> material for the sole use of the intended recipient(s). Any review, =
use,
>>> distribution or disclosure by others is strictly prohibited.  If you =
have
>>> received this communication in error, please notify the sender =
immediately
>>> by e-mail and delete the message and any file attachments from your
>>> computer. Thank you.
>>=20
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org 
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Not that I am against the general desire for JWT not to be =
confused, but the attack surface for someone to take a sec event from =
one context and replay it as a id_token to login is very small and if =
the client is correctly configured would not work as it is now.

The only way you could =
replay the sec event JWT is via the implicit flow.   The other =
flows would require a malicious AS and at that point you have bigger =
problems with a compromised token endpoint.

If you were to create a implicit =
response with the sec event token that has the correct issuer and aud, =
connect requires that nonce value from the request be present in the =
id_token.   This would require that the attacker somehow get the AS =
to put not only the claim but the correct value from the request into =
the token.

All =
in all I think that it is more likely (not 100% I admit) that a client =
will do that rather than checking the typ or a new crit JWT header =
parameter.

I =
am all for a general solution for this but I think the issue with =
Connect is overstated sometimes.

John B.
 
On =
Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

We have the =
use case in SECEVENTS where a logout event (e.g. OIDF backchannel =
logout) is extremely close to an ID_TOKEN. 

Older relying parties who are do not =
yet support logout could be tricked into accepting a logout assertion as =
an ID_TOKEN since they are too similar, and  because a valid =
ID_TOKEN parser is in theory allowed to ignore claims it does not =
understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible =
erroneous acceptance of the logout event AS and ID_TOKEN.

Because of this the =
issue of distinguishing classes or types of JWTs emerged.

We discussed a number of =
differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =
=E2=80=9Ccrit", etc that would help.  But that really lead to the =
idea there there should be some best practices in the JWT BCP covering =
the issue(s).



Phil

Oracle Corporation, Identity Cloud =
Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com




On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even =
after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an =
attacker
substitutes a valid JWT from one security context =
into another
context. But isn't this resolved by audience =
validation?

On Thu, Jul 27, 2017 at 3:34 =
PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it =
in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie=
tf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=
=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5=
biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b=
9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&=
e=3D 

On Thu, Jul 27, 2017 at 1:30 PM, =
Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What =
class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just =
be
ignorant.

On Thu, Jul 27, =
2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG =
meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a =
recommendation for
preventing confusion of one kind of JWT =
for another. Time was running
short
in the =
meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on =
the list is that.

Section 3.9 of the JWT =
BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use =
of
explicit
typing may not achieve =
disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the =
"typ"
header
parameter value.'  And the =
recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently =
being used for
any
validation.

Alternatively using the JWS/JWE "crit" =
(Critical) Header Parameter to
signal
the =
type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing =
kinds of JWTs. The critical header lists
other headers =
which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't =
understood. So a new
type/profile of JWT that uses the =
"crit" header would produce JWTs that
would be rejected =
even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction =
with a
profile/application/type specific header. Or it =
could provide a bit more
of
a framework like =
defining a registering a new JOSE header "p" (strawman
of =
p
as a very short name for profile) and create a registry =
for its values.
A
JWT header using that =
approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The =
consumer
of
such a JWT would have to =
understand and process the "p" header, which
would
mean checking that it had the value expected.
     {
 =
     "alg":"ES256",
 =
     "crit":["p"],
 =
     "p":1
 =
    }

A JOSE compliant =
JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't =
known or
understood but is marked as critical.

To me, that seems like an approach to =
preventing confusion that has more
teeth than the "typ" =
header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY =
NOTICE: This email may contain confidential and
privileged
material for the sole use of the =
intended recipient(s). Any review, use,
distribution or =
disclosure by others is strictly prohibited.  If you
have
received this communication in error, =
please notify the sender
immediately
by =
e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx=
BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am=
p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_=
E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 




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

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx=
BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am=
p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_=
E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 

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

=

--Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313--

--f4030435c300b6249e05555368f8
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ1xFYS7MrgF3lLk36gSb/KECXXU
9knFVYcWAFZhr0TUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDcyNzIxNDAxMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQA+AqAwENp4pGqubUlPK8rVZ2OODqhZH2gS6g47YwZEHti9
Y8I0us0GekHX/HbV3wII0DtVlpQN0RxBzvjcJYh/rs+Kzwpo5Pv4pKV+5vd5zHRHQN84h1chJqYb
1d/9Bd1CKGPEsQAEQNBrFNvvdNm1vBpqm644XuYDI4hLzvN7TPcL6yLGt5+oMBqWi5cppmjIhwlH
7IOoLUGQc53GBGemCtLKMfxtWOkI6QIaen8L5TrBxi9qPOQ1YCikkR76UnA7Gal4JHziaLu/I7cl
DdIxG1UCWWE/Kca48sUWxprz6fcp4kkLDgdq4dRb+XaQZzeuo83ZrmdyXABdDfcKrAe7
--f4030435c300b6249e05555368f8--


From nobody Thu Jul 27 14:40:59 2017
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 1D356131E7B for ; Thu, 27 Jul 2017 14:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level: 
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 tUcpbyiEHAsp for ; Thu, 27 Jul 2017 14:40:39 -0700 (PDT)
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) (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 B4D18131E83 for ; Thu, 27 Jul 2017 14:40:34 -0700 (PDT)
Received: by mail-io0-f182.google.com with SMTP id l7so84454649iof.1 for ; Thu, 27 Jul 2017 14:40:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bTj0GreIjY2Z6CAFJXyQ4sMJxFw7xj2vJ6jiSeYE8pA=; b=Sics3Qd5aJKuLl0yFOAvSxSiN1uEpQ4avzmJbfYmvTDL5CboOIwn0VPg7HSDthLlTI OcG5UUEVzbH4NJ3aXoOZyVetuLRMFS2Bvw5IG4qOE8GODPT1QMSCAjwjqTyTmAulszwJ NCopk0wReG7K+TE7bg1mfXC1vIw1zqP123r9adCWWRG8eQ97xfNHdFrL2ZYAXjhq6FKf 9JXgXPJrYdkFJ12BZhnUaKn0R7I6JT5hTGKaqzAMy60cZE6b7g307/2Fp2oY/KKRUUdf i1xv7SM2ikod/BTJa92bezow3wfHtufpMdolIM/+rkimYtW66EPX+JzP7a9vDN34Hkbw ZYhQ==
X-Gm-Message-State: AIVw113uxtTo/1l74iqBR+GDi4rQOaUt41DU1/cOOdQGskGq+tcAaTEx ZJfG2A1E8oGjpxXolGtm40pGEa2Pg8pB
X-Received: by 10.107.40.212 with SMTP id o203mr6559216ioo.181.1501191633862;  Thu, 27 Jul 2017 14:40:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 14:40:33 -0700 (PDT)
In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com>
From: Nathaniel McCallum 
Date: Thu, 27 Jul 2017 17:40:33 -0400
Message-ID: 
To: Phil Hunt 
Cc: Brian Campbell , oauth ,  "jose@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 21:40:55 -0000

Right. And this is precisely what I find strange. We are attempting to
define the differentiation between state transitions without defining
the state transitions themselves.

I want to be clear that I think there is a real need here. But it
seems to me that this need is not well defined. So I'm not against it
in theory. I'm just against ambiguous standards.

On Thu, Jul 27, 2017 at 5:19 PM, Phil Hunt  wrote:
> We have the use case in SECEVENTS where a logout event (e.g. OIDF
> backchannel logout) is extremely close to an ID_TOKEN.
>
> Older relying parties who are do not yet support logout could be tricked
> into accepting a logout assertion as an ID_TOKEN since they are too simil=
ar,
> and  because a valid ID_TOKEN parser is in theory allowed to ignore claim=
s
> it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a pos=
sible erroneous
> acceptance of the logout event AS and ID_TOKEN.
>
> Because of this the issue of distinguishing classes or types of JWTs
> emerged.
>
> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2=
=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that
> would help.  But that really lead to the idea there there should be some
> best practices in the JWT BCP covering the issue(s).
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum 
> wrote:
>
> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> context. But isn't this resolved by audience validation?
>
> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>  wrote:
>
> The draft describes it in
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm=
l_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR=
oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz=
jWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCou=
CMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum 
> wrote:
>
>
> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
> ignorant.
>
> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>  wrote:
>
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running
> short
> in the meeting so there wasn't much discussion and it was requested that
> I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using
> the
> "typ" JWS/JWE header parameter but does concede that 'the use of
> explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as
> the
> validation rules for existing kinds JWTs often do not use the "typ"
> header
> parameter value.'  And the recommendations for how to use the Type
> Header
> Parameter in JWT strongly suggest that it's not currently being used for
> any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> signal
> the type/intent/profile/application of a JWT could achieve
> disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more
> of
> a framework like defining a registering a new JOSE header "p" (strawman
> of p
> as a very short name for profile) and create a registry for its values.
> A
> JWT header using that approach might look like the following where the
> value
> 1 is registered as some cool new JWT profile/application. The consumer
> of
> such a JWT would have to understand and process the "p" header, which
> would
> mean checking that it had the value expected.
>
>     {
>      "alg":"ES256",
>      "crit":["p"],
>      "p":1
>     }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and
> am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you
> have
> received this communication in error, please notify the sender
> immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSnc=
Xu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege=
d
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediatel=
y
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSnc=
Xu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>


From nobody Thu Jul 27 15:00:07 2017
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 5D0CB1321D0 for ; Thu, 27 Jul 2017 15:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYxcV3O-NLeM for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 C3A311321C2 for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id d67so20399978pfc.0 for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5+8ihVdfpE82C+K9989j7igeQWSH9Y49ZkzM6qwHd6E=; b=i0BcDjDjEIuJrzjv+Ynp0nK46UO66NdNzgV+IspqDxjrUJ72ut60mL1sUZOtbLD/K3 13FlVWDtxx/VILXYBVnwOVQwD5Y51dy4e3XJRnqdYEvpKLprPA9fxpFGQduQayAolXX3 MNOFLSrNNxMkUf6YHzuqovB7J8RiAWouu6ZmQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5+8ihVdfpE82C+K9989j7igeQWSH9Y49ZkzM6qwHd6E=; b=JcvvIqbjeTQ0L5HpyEgF90K4auOzjVaHAv4SiOaNuSVHqTzb9veSOTGqzO2YiXAbwG 3aZroL+98V93ysHq5bADw0JVgpLN+zPZric2sBAVzVvJhr0k5qcnd1BmfWZQdcFPK2dW qP898qICVGcKJO0gjWdS3mIRSIHmj0TLzO9hszRcldxwe975+TxFKF10vdAEbfR0B5K5 ql1QjKbXKUpE5t1PZCNW0kevJBwE0XhDuHPuyGgTih9Q0XnDfwiBAeM4GJdlBxR6YLW1 L8aLKNo7ClqHNjQbsQej0mz1yxZ5po0K3U9+00cMCOhz8hRXV7vAUPJYvMAHI3kx/d2q 81BA==
X-Gm-Message-State: AIVw112MrWhwmWuq8hQRvoHtvDbdAerAH4BVt5ZAWaFMiyNUKct92sqR dWt7DA9GahDaiaD0DUiuLVD7htu32xSPA0CY20vKXHLf6o7CIvMVel72sXpUGU6h0/Cw0Gl5j+a 25QuR+h8=
X-Received: by 10.84.167.230 with SMTP id i35mr5817268plg.181.1501192796316; Thu, 27 Jul 2017 14:59:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 14:59:25 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Thu, 27 Jul 2017 15:59:25 -0600
Message-ID: 
To: Dick Hardt 
Cc: oauth , "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c145cd65d468a055553af8b"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 22:00:00 -0000

--94eb2c145cd65d468a055553af8b
Content-Type: text/plain; charset="UTF-8"

What other JWTs are there?

All JWTs use JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT
requires 'crit' processing by virtue of using JWS and JWE for signing and
encryption. The extent to which that processing is actually implemented is
a different and fair question but it's normative requirement per spec and
implementations that don't would be non-compliant.

The byte usage actually is pretty similar depending on the the values used
(admittedly because I chose very compact names/values).  Compare to
secevent, for example,

   "crit":["p"],"p":1
   "typ":"secevent+jwt"


On Thu, Jul 27, 2017 at 3:29 PM, Dick Hardt  wrote:

> Brian: I did not think that 'crit' processing is required in JWT
> https://tools.ietf.org/html/rfc7519
>
> We have two goals:
>
> Preventing new JWT profiles from being confused with older JWTs, which
> 'typ' solves (as does your proposal of 'crit' and 'p', but requires more
> bytes)
>
> Preventing existing JWT implementations from being confused with new JWT
> profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs.
>
>
>
> On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
>
>> During the first WG meeting last week
>>  I asked if use of
>> the JOSE "crit" (Critical) Header Parameter had been considered as a
>> recommendation for preventing confusion of one kind of JWT for another.
>> Time was running short in the meeting so there wasn't much discussion and
>> it was requested that I take the question to the list. And so here on the
>> list is that.
>>
>> Section 3.9
>> 
>> of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE
>> header parameter but does concede that 'the use of explicit typing may not
>> achieve disambiguation from existing kinds of JWTs, as the validation rules
>> for existing kinds JWTs often do not use the "typ" header parameter
>> value.'  And the recommendations for how to use the Type Header
>> Parameter in JWT 
>> strongly suggest that it's not currently being used for any validation.
>>
>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
>>  to signal the
>> type/intent/profile/application of a JWT could achieve disambiguation
>> even in validation of existing kinds of JWTs. The critical header lists
>> other headers which must be understood and processed by the receiver and
>> that the JWS/JWE is invalid if those listed aren't understood. So a new
>> type/profile of JWT that uses the "crit" header would produce JWTs that
>> would be rejected even by existing applications of JWT validation (that
>> actually implement "crit" properly anyway).
>>
>> The JWT BCP could suggest the use of "crit" in conjunction with a
>> profile/application/type specific header. Or it could provide a bit more of
>> a framework like defining a registering a new JOSE header "p" (strawman of
>> p as a very short name for profile) and create a registry for its values. A
>> JWT header using that approach might look like the following where the
>> value 1 is registered as some cool new JWT profile/application. The
>> consumer of such a JWT would have to understand and process the "p" header,
>> which would mean checking that it had the value expected.
>>
>>      {
>>       "alg":"ES256",
>>       "crit":["p"],
>>       "p":1
>>      }
>>
>> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
>> access token or OIDC id_token because the "p" header isn't known or
>> understood but is marked as critical.
>>
>> To me, that seems like an approach to preventing confusion that has more
>> teeth than the "typ" header. Which is why I asked about it last week and am
>> now bringing it to the list.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
>
> --
> Subscribe to the HARDTWARE  mail list to learn
> about projects I am working on!
>

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

--94eb2c145cd65d468a055553af8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What other JWTs are there?
=C2=A0
All JWTs use =
JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT requires  'cr=
it' processing by virtue of using JWS and JWE for signing and encryptio=
n. The extent to which that processing is actually implemented is a differe=
nt and fair question but it's normative requirement per spec and implem=
entations that don't would be non-compliant. 

The byte usa=
ge actually is pretty similar depending on the the values used (admittedly =
because I chose very compact names/values).=C2=A0 Compare to secevent, for =
example, 

=C2=A0=C2=A0 "crit":["p"],&q=
uot;p":1
=C2=A0=C2=A0 "typ":"secevent+jwt" 
=

=C2=A0
On=
 Thu, Jul 27, 2017 at 3:29 PM, Dick Hardt <dick.hardt@gmail.com>=
 wrote:
Brian: I did not think that 'crit' processing is required=
 in JWT=C2=A0https://tools.ietf.org/html/rfc7519

We have=
 two goals:=C2=A0

Preventing new JWT profiles from=
 being confused with older JWTs, which 'typ' solves (as does your p=
roposal of 'crit' and 'p', but requires more bytes)

Preventing existing JWT implementations from being confus=
ed with new JWT profiles. 'crit' can solve that for JOSE JWTs, but =
not other JWTs.



On Thu=
, Jul 27, 2017 at 7:49 PM, Brian Campbell <bcampbell@pingidentity=
.com> wrote:
During the first WG meeting last week I asked if use=
 of the JOSE "crit" (Critical) Header Parameter had been consider=
ed as a recommendation for preventing confusion of one kind of JWT for anot=
her. Time was running short in the meeting so there wasn't much discuss=
ion and it was requested that I take the question to the list. And so here =
on the list is that. 

Section 3.9 of the JWT BCP draft now recommends explicit typing using the "typ&q=
uot; JWS/JWE header parameter but does concede that 'the use of explici=
t typing may not achieve disambiguation from existing kinds of JWTs, as the=
 validation rules for existing kinds JWTs often do not use the "typ&qu=
ot; header parameter value.'=C2=A0 And the recommendations for how to u=
se the Type Header Parameter in JWT strongly suggest that it's=
 not currently being used for any validation. 

Alternatively u=
sing the JWS/JWE "crit" (Critical) Header Parameter to =
signal the type/intent/profile/application of a JWT could achieve disa=
mbiguation even in validation of existing kinds of JWTs. The critical heade=
r lists other headers which must be understood and processed by the receive=
r and that the JWS/JWE is invalid if those listed aren't understood. So=
 a new type/profile of JWT that uses the "crit" header would prod=
uce JWTs that would be rejected even by existing applications of JWT valida=
tion (that actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction wit=
h a profile/application/type specific header. Or it could provide a bit mor=
e of a framework like defining a registering a new JOSE header "p"=
; (strawman of p as a very short name for profile) and create a registry fo=
r its values. A JWT header using that approach might look like the followin=
g where the value 1 is registered as some cool new JWT profile/application.=
 The consumer of such a JWT would have to understand and process the "=
p" header, which would mean checking that it had the value expected. <=
br>=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &=
quot;alg":"ES256",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "c=
rit":["p"],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p":=
1
=C2=A0=C2=A0=C2=A0=C2=A0 }

A JOSE compliant JWT validator=
 would reject such a JWT even for an OAuth access token or OIDC id_token be=
cause the "p" header isn't known or understood but is marked =
as critical. 

To me, that seems like an approach to preventing=
 confusion that has more teeth than the "typ" header. Which is wh=
y I asked about it last week and am now bringing it to the list. 
<=
div>













CONFIDENTIAL=
ITY NOTICE: This email may contain confidential and privileged material for=
 the sole use of the intended recipient(s). Any review, use, distribution o=
r disclosure by others is strictly prohibited.=C2=A0 If you have received t=
his communication in error, please notify the sender immediately by e-mail =
and delete the message and any file attachments from your computer. Thank y=
ou.
_____________________________________________=
__

jose mailing list

jose@ietf.org

https://www.ietf.org/mailman/listinfo/jose=





-- 
Subscribe to the=
 HARDTWARE mail lis=
t to learn about projects I am working on!









<=
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.
--94eb2c145cd65d468a055553af8b--


From nobody Thu Jul 27 15:10:40 2017
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 EECB6132112 for ; Thu, 27 Jul 2017 15:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8yaAiOszt1b for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 2C31A131E5E for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id k190so37619709pgk.5 for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AcxLqZz/P4+/aAq9qy4XRTUmORo0OGhpqeDbgsW/s8E=; b=bjl8i45/6duFsOUg3VjzRI7evGq1ULwCNAlLgwll6oquNpBIJhPNsJsVLLAt0QbmQm Fx3ostUvswKcSgecVsFl846p/PfYTjDkd4+L+HcbtoWGUP6A38Nua+uIrJpFCDJ9GCie cCaeNab659lDmLJY1AflujGxSCHDnv0fjuG2c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AcxLqZz/P4+/aAq9qy4XRTUmORo0OGhpqeDbgsW/s8E=; b=BgOnH3m7RbkbjpyolK34Gs/Lem78YokLFlH+Q4/JrZWBwVPap0FkA6operkjunpOd8 lzUVbsvUHIObtCh+9x7SMdKt3B2q5OHS7IKV9BPa7VVHFX0osA821PYGp1tv5QYGReSS hIZyjwDntgnhfbZr68efityQuPnuU8fZmTGq7CkPyRJ5aFjczngFYCgzv09joal46A1Z MlJWhqTuOojo0tCFrP+vEPc79NO/qoFM9zhlSQHmJEBj1F/gvmytmgx1XebHVZb0Ikb8 iUDKsBZ6N26v9txntpRpv6D5tsYPboCnHYoD8PcPrcLIGvFbmhENbGiFNVgn5PwrXaiD YG9g==
X-Gm-Message-State: AIVw1104MFUbdYHlZgBI3s05hBd+HbcXkOreRJvvpBvnMJ/qYW+APWPL TJzGt0lSZ15x0o8dRCTZ2J8Ar9hvtVCSM1rl2+3qRZAAHwuMDuV5Dc7wGXgmh4abArhFqmcKTGf TFzEo
X-Received: by 10.99.117.68 with SMTP id f4mr5397586pgn.56.1501193434456; Thu, 27 Jul 2017 15:10:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 15:10:03 -0700 (PDT)
In-Reply-To: <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>
From: Brian Campbell 
Date: Thu, 27 Jul 2017 16:10:03 -0600
Message-ID: 
To: John Bradley 
Cc: Phil Hunt , Nathaniel McCallum , oauth ,  "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045cdcc4668e18055553d548"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 22:10:39 -0000

--f403045cdcc4668e18055553d548
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I wouldn't disagree that the issue with Connect is overstated sometimes.
And it's a non-issue with sec event due to the "nonce" claim (as you point
out) as well as the omission of the "exp" claim. Assuming correct
validation anyway.

The BCP draft suggests explicit typing to prevent Cross-JWT Confusion more
generally (not just sec events and id tokens). I was wondering if some use
of "crit" might accomplish the same thing but also cover the case of
existing JWT implementations being confused with new JWT profiles.

On Thu, Jul 27, 2017 at 3:40 PM, John Bradley  wrote:

> Not that I am against the general desire for JWT not to be confused, but
> the attack surface for someone to take a sec event from one context and
> replay it as a id_token to login is very small and if the client is
> correctly configured would not work as it is now.
>
> The only way you could replay the sec event JWT is via the implicit flow.
>   The other flows would require a malicious AS and at that point you have
> bigger problems with a compromised token endpoint.
>
> If you were to create a implicit response with the sec event token that
> has the correct issuer and aud, connect requires that nonce value from th=
e
> request be present in the id_token.   This would require that the attacke=
r
> somehow get the AS to put not only the claim but the correct value from t=
he
> request into the token.
>
> All in all I think that it is more likely (not 100% I admit) that a clien=
t
> will do that rather than checking the typ or a new crit JWT header
> parameter.
>
> I am all for a general solution for this but I think the issue with
> Connect is overstated sometimes.
>
> John B.
>
>
> On Jul 27, 2017, at 5:19 PM, Phil Hunt  wrote:
>
> We have the use case in SECEVENTS where a logout event (e.g. OIDF
> backchannel logout) is extremely close to an ID_TOKEN.
>
> Older relying parties who are do not yet support logout could be tricked
> into accepting a logout assertion as an ID_TOKEN since they are too
> similar, and  because a valid ID_TOKEN parser is in theory allowed to
> ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - le=
ading to a
> possible erroneous acceptance of the logout event AS and ID_TOKEN.
>
> Because of this the issue of distinguishing classes or types of JWTs
> emerged.
>
> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2=
=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc
> that would help.  But that really lead to the idea there there should be
> some best practices in the JWT BCP covering the issue(s).
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum 
> wrote:
>
> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> context. But isn't this resolved by audience validation?
>
> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>  wrote:
>
> The draft describes it in
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.
> ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-
> 23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1=
0&r=3D
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D
> 9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum  >
> wrote:
>
>
> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
> ignorant.
>
> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>  wrote:
>
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running
> short
> in the meeting so there wasn't much discussion and it was requested that
> I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using
> the
> "typ" JWS/JWE header parameter but does concede that 'the use of
> explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as
> the
> validation rules for existing kinds JWTs often do not use the "typ"
> header
> parameter value.'  And the recommendations for how to use the Type
> Header
> Parameter in JWT strongly suggest that it's not currently being used for
> any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> signal
> the type/intent/profile/application of a JWT could achieve
> disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more
> of
> a framework like defining a registering a new JOSE header "p" (strawman
> of p
> as a very short name for profile) and create a registry for its values.
> A
> JWT header using that approach might look like the following where the
> value
> 1 is registered as some cool new JWT profile/application. The consumer
> of
> such a JWT would have to understand and process the "p" header, which
> would
> mean checking that it had the value expected.
>
>     {
>      "alg":"ES256",
>      "crit":["p"],
>      "p":1
>     }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and
> am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you
> have
> received this communication in error, please notify the sender
> immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.
> ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC=
X5Y
> TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege=
d
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediatel=
y
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.
> ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC=
X5Y
> TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
> _______________________________________________
> 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
*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.  If you have=
=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.*

--f403045cdcc4668e18055553d548
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I wouldn't disagree that the  issue with Connect =
is overstated sometimes. And it's a non-issue with sec event due to the=
 "nonce" claim (as you point out) as well as the omission of the =
"exp" claim. Assuming correct validation anyway. 

Th=
e BCP draft suggests explicit typing to prevent Cross-JWT Confusion more ge=
nerally (not just sec events and id tokens). I was wondering if some use of=
 "crit" might accomplish the same thing but also cover the case o=
f existing JWT implementations being confused with new JWT profiles. 

On Thu, Jul 2=
7, 2017 at 3:40 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<=
br>
Not t=
hat I am against the general desire for JWT not to be confused, but the att=
ack surface for someone to take a sec event from one context and replay it =
as a id_token to login is very small and if the client is correctly configu=
red would not work as it is now.

The only way you could =
replay the sec event JWT is via the implicit flow. =C2=A0 The other flows w=
ould require a malicious AS and at that point you have bigger problems with=
 a compromised token endpoint.

If you were to crea=
te a implicit response with the sec event token that has the correct issuer=
 and aud, connect requires that nonce value from the request be present in =
the id_token. =C2=A0 This would require that the attacker somehow get the A=
S to put not only the claim but the correct value from the request into the=
 token.

All in all I think that it is more likely =
(not 100% I admit) that a client will do that rather than checking the typ =
or a new crit JWT header parameter.

I am all for a=
 general solution for this but I think the issue with Connect is overstated=
 sometimes.

John B.
=C2=A0
On Jul 27, 2017, at 5:19 P=
M, Phil Hunt <=
phil.hunt@oracle.com> wrote:

We have the use case in SECEVENTS where a logout=
 event (e.g. OIDF backchannel logout) is extremely close to an ID_TOKEN.=C2=
=A0

Older relying parties who are do not yet support log=
out could be tricked into accepting a logout assertion as an ID_TOKEN since=
 they are too similar, and =C2=A0because a valid ID_TOKEN parser is in theo=
ry allowed to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=
=80=9D) - leading to a possible erroneous acceptance of the logout event AS=
 and ID_TOKEN.

Because of this the issue of distin=
guishing classes or types of JWTs emerged.

We disc=
ussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=
=E2=80=9D, =E2=80=9Ccrit", etc that would help.=C2=A0 But that really =
lead to the idea there there should be some best practices in the JWT BCP c=
overing the issue(s).



Phil

Oracle Corporation, Identity Cloud Services =
Architect & Standards
@independentid
phil.hunt@oracle.com




On Jul 27, 2017, at 2:00 PM, Nathan=
iel McCallum <npmccallum@redhat.com> wrote:

Even after reading the whole section,=
 I still don't understand the
problem. Yes, a class of attack could =
exist where an attacker
substitutes a valid JWT from one security contex=
t into another
context. But isn't this resolved by audience validati=
on?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
<bcampbell@pingiden=
tity.com> wrote:
The draft describes it=
 in
https://urldefense.proofpoint.com/v2/url?u=
=3Dhttps-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2D=
bcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZ=
YR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjW=
wlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQ=
sC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=
=3D 

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.c=
om>
wrote:

What class of attacks=
 is this trying to prevent? I frankly don't see a
problem with confu=
sing different types of JWT. But I may just be
ignorant.

On Thu, =
Jul 27, 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrot=
e:
During the first WG meeting last week I ask=
ed if use of the JOSE "crit"
(Critical) Header Parameter had b=
een considered as a recommendation for
preventing confusion of one kind =
of JWT for another. Time was running
short
in the meeting so there wa=
sn't much discussion and it was requested that
I
take the questio=
n to the list. And so here on the list is that.

Section 3.9 of the J=
WT BCP draft now recommends explicit typing using
the
"typ"=
 JWS/JWE header parameter but does concede that 'the use of
explicit=

typing may not achieve disambiguation from existing kinds of JWTs, asthe
validation rules for existing kinds JWTs often do not use the &quo=
t;typ"
header
parameter value.' =C2=A0And the recommendation=
s for how to use the Type
Header
Parameter in JWT strongly suggest th=
at it's not currently being used for
any
validation.

Alter=
natively using the JWS/JWE "crit" (Critical) Header Parameter to<=
br>signal
the type/intent/profile/application of a JWT could achiev=
e
disambiguation
even in validation of existing kinds of JWTs. The cr=
itical header lists
other headers which must be understood and processed=
 by the receiver and
that the JWS/JWE is invalid if those listed aren=
9;t understood. So a new
type/profile of JWT that uses the "crit&qu=
ot; header would produce JWTs that
would be rejected even by existing ap=
plications of JWT validation (that
actually implement "crit" p=
roperly anyway).

The JWT BCP could suggest the use of "crit&quo=
t; in conjunction with a
profile/application/type specific header. Or it=
 could provide a bit more
of
a framework like defining a registering =
a new JOSE header "p" (strawman
of p
as a very short name f=
or profile) and create a registry for its values.
A
JWT header using =
that approach might look like the following where the
value
1 is regi=
stered as some cool new JWT profile/application. The consumer
of
such=
 a JWT would have to understand and process the "p" header, which=

would
mean checking that it had the value expected.

 =C2=A0=
=C2=A0=C2=A0=C2=A0{
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alg":"=
;ES256",
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"crit":["p&q=
uot;],
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"p":1
 =C2=A0=C2=A0=
=C2=A0=C2=A0}

A JOSE compliant JWT validator would reject such a JWT=
 even for an OAuth
access token or OIDC id_token because the "p&quo=
t; header isn't known or
understood but is marked as critical.
To me, that seems like an approach to preventing confusion that has more<=
br>teeth than the "typ" header. Which is why I asked about it las=
t week and
am
now bringing it to the list.









CONFIDENTIALITY NOTICE: This email may contain confidentia=
l and
privileged
material for the sole use of the intended recipient(=
s). Any review, use,
distribution or disclosure by others is strictly pr=
ohibited.=C2=A0 If you
have
received this communication in error, ple=
ase notify the sender
immediately
by e-mail and delete the message an=
d any file attachments from your
computer. Thank you.
_______________=
________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/=
v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DD=
wICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWn=
zzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E1=
6U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 




CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged
material for the sole use of the intended recipient(s). A=
ny review, use,
distribution or disclosure by others is strictly prohibi=
ted.=C2=A0 If you have
received this communication in error, please noti=
fy the sender immediately
by e-mail and delete the message and any file =
attachments from your
computer. Thank you.

_________=
______________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&=
;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&a=
mp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D0=
2yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RD=
l_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D 

______________________=
_________________________
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







<=
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.
--f403045cdcc4668e18055553d548--


From nobody Thu Jul 27 15:24:23 2017
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 9F957131D06 for ; Thu, 27 Jul 2017 15:24:12 -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_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 (2048-bit key) header.d=ve7jtb-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 MGtl17B-vnhr for ; Thu, 27 Jul 2017 15:24:07 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 14243131471 for ; Thu, 27 Jul 2017 15:24:06 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id v29so50299085qtv.3 for ; Thu, 27 Jul 2017 15:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VEC5frCaonJIch5R0dYy/gGYnJc4tfh3l7Fk6DOW+4Q=; b=kmm8zNXuBl4nE/uqPUPNh70TUpDopw2AApOc2oeklxTm+2NkbM3sme0eLYsd1DWALB +SyfZikvH/HK1zZss8GiIKY7ydbFW/0Loerstrg4gFKQ+4dXdWwayu1oKIl3azLAgdFO /X/ng7jGCVs7uIVW1xs0/4xUR8HrsQb9QvJJ4+JPgP3rEGG2ClM4zScbzlRYxrHG3s2P KkF5p22sRa5Btd/khBSVHd5tBopeaNGX6a3Ik+hYKBuSot57+b92E5+JxyXtKBWiFyc4 2nBLVThoy8lGj8H4qjFDqN03mmfBKaeb3fdHqEEVaYf/nZgzVYiL9OrWJ5Epp+zNzVyE 7EZQ==
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=VEC5frCaonJIch5R0dYy/gGYnJc4tfh3l7Fk6DOW+4Q=; b=NncbKyNuhKy7dS8UvMVxJhSEtblR9QL36hGFljtyqyfqzSl7p+oyyNBQj9a136XCFy lG6Xat3SU2KNvmSmG/X4MorpTJto+eQkd7B8VGf7NwUsE9P+0dgi/LHfp++4jieyMz+M IoC7IFSF9c3TpLzLESql732Nael+RecaLS3gsWWsxfyOU+WbbwzMsvqcfrBILYP2mZyL 7nWYmFOl6h5178fR0abaOsF2WYXeCw7WXQ2Zq9pN0tXFKNlc3CgDpZKQ2NOVA8jThDT3 7xuqmOwkqx9oyjYQYSkrgJhLfXtdWnXQKf5DB8Yhopfd1gBXmCihyfVNMLDBOJjHBOlO D9Ig==
X-Gm-Message-State: AIVw113bv+N7j10ETb0yJ1kCQWYNuqg5FhVCyzXU3AWDitLp0HSo0IzP Yjic6YAiXoFRpQDx
X-Received: by 10.200.47.93 with SMTP id k29mr8230563qta.18.1501194245859; Thu, 27 Jul 2017 15:24:05 -0700 (PDT)
Received: from johns-mbp.lan ([191.115.36.222]) by smtp.gmail.com with ESMTPSA id j95sm5797721qte.4.2017.07.27.15.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 15:24:05 -0700 (PDT)
From: John Bradley 
Message-Id: <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 27 Jul 2017 18:23:55 -0400
In-Reply-To: 
Cc: Phil Hunt , Nathaniel McCallum , oauth , "jose@ietf.org" 
To: Brian Campbell 
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> 
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11356e54ca290c055554053c"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 22:24:13 -0000

--001a11356e54ca290c055554053c
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB"


--Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

My only concern with a crit header is that it is potentially another =
layering violation.

It really should be the application and not JWS/JWE that determines if =
the content of the JWT is correct at a application layer.

To get your idea to work the application would need to push down to the =
JWT layer some value/s of p that it was willing to accept.   Without =
crit the application could just pass along typ or p to the application =
layer for matching.

I don=E2=80=99t hate the idea but it seems like it is likely to work =
against having generic JOSE libs separate from JWT. Perhaps that is the =
reality anyway.

How would you implement it?

John B.

> On Jul 27, 2017, at 6:10 PM, Brian Campbell =
 wrote:
>=20
> I wouldn't disagree that the issue with Connect is overstated =
sometimes. And it's a non-issue with sec event due to the "nonce" claim =
(as you point out) as well as the omission of the "exp" claim. Assuming =
correct validation anyway.=20
>=20
> The BCP draft suggests explicit typing to prevent Cross-JWT Confusion =
more generally (not just sec events and id tokens). I was wondering if =
some use of "crit" might accomplish the same thing but also cover the =
case of existing JWT implementations being confused with new JWT =
profiles.=20
>=20
> On Thu, Jul 27, 2017 at 3:40 PM, John Bradley > wrote:
> Not that I am against the general desire for JWT not to be confused, =
but the attack surface for someone to take a sec event from one context =
and replay it as a id_token to login is very small and if the client is =
correctly configured would not work as it is now.
>=20
> The only way you could replay the sec event JWT is via the implicit =
flow.   The other flows would require a malicious AS and at that point =
you have bigger problems with a compromised token endpoint.
>=20
> If you were to create a implicit response with the sec event token =
that has the correct issuer and aud, connect requires that nonce value =
from the request be present in the id_token.   This would require that =
the attacker somehow get the AS to put not only the claim but the =
correct value from the request into the token.
>=20
> All in all I think that it is more likely (not 100% I admit) that a =
client will do that rather than checking the typ or a new crit JWT =
header parameter.
>=20
> I am all for a general solution for this but I think the issue with =
Connect is overstated sometimes.
>=20
> John B.
> =20
>> On Jul 27, 2017, at 5:19 PM, Phil Hunt > wrote:
>>=20
>> We have the use case in SECEVENTS where a logout event (e.g. OIDF =
backchannel logout) is extremely close to an ID_TOKEN.=20
>>=20
>> Older relying parties who are do not yet support logout could be =
tricked into accepting a logout assertion as an ID_TOKEN since they are =
too similar, and  because a valid ID_TOKEN parser is in theory allowed =
to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) =
- leading to a possible erroneous acceptance of the logout event AS and =
ID_TOKEN.
>>=20
>> Because of this the issue of distinguishing classes or types of JWTs =
emerged.
>>=20
>> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =
=E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help.  But that =
really lead to the idea there there should be some best practices in the =
JWT BCP covering the issue(s).
>>=20
>> Phil
>>=20
>> Oracle Corporation, Identity Cloud Services Architect & Standards
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum =
> wrote:
>>>=20
>>> Even after reading the whole section, I still don't understand the
>>> problem. Yes, a class of attack could exist where an attacker
>>> substitutes a valid JWT from one security context into another
>>> context. But isn't this resolved by audience validation?
>>>=20
>>> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>>> > =
wrote:
>>>> The draft describes it in
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html=
_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR=
oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv=
zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC=
ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D =
=20
>>>>=20
>>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum =
>
>>>> wrote:
>>>>>=20
>>>>> What class of attacks is this trying to prevent? I frankly don't =
see a
>>>>> problem with confusing different types of JWT. But I may just be
>>>>> ignorant.
>>>>>=20
>>>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>>>>> > =
wrote:
>>>>>> During the first WG meeting last week I asked if use of the JOSE =
"crit"
>>>>>> (Critical) Header Parameter had been considered as a =
recommendation for
>>>>>> preventing confusion of one kind of JWT for another. Time was =
running
>>>>>> short
>>>>>> in the meeting so there wasn't much discussion and it was =
requested that
>>>>>> I
>>>>>> take the question to the list. And so here on the list is that.
>>>>>>=20
>>>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing =
using
>>>>>> the
>>>>>> "typ" JWS/JWE header parameter but does concede that 'the use of
>>>>>> explicit
>>>>>> typing may not achieve disambiguation from existing kinds of =
JWTs, as
>>>>>> the
>>>>>> validation rules for existing kinds JWTs often do not use the =
"typ"
>>>>>> header
>>>>>> parameter value.'  And the recommendations for how to use the =
Type
>>>>>> Header
>>>>>> Parameter in JWT strongly suggest that it's not currently being =
used for
>>>>>> any
>>>>>> validation.
>>>>>>=20
>>>>>> Alternatively using the JWS/JWE "crit" (Critical) Header =
Parameter to
>>>>>> signal
>>>>>> the type/intent/profile/application of a JWT could achieve
>>>>>> disambiguation
>>>>>> even in validation of existing kinds of JWTs. The critical header =
lists
>>>>>> other headers which must be understood and processed by the =
receiver and
>>>>>> that the JWS/JWE is invalid if those listed aren't understood. So =
a new
>>>>>> type/profile of JWT that uses the "crit" header would produce =
JWTs that
>>>>>> would be rejected even by existing applications of JWT validation =
(that
>>>>>> actually implement "crit" properly anyway).
>>>>>>=20
>>>>>> The JWT BCP could suggest the use of "crit" in conjunction with a
>>>>>> profile/application/type specific header. Or it could provide a =
bit more
>>>>>> of
>>>>>> a framework like defining a registering a new JOSE header "p" =
(strawman
>>>>>> of p
>>>>>> as a very short name for profile) and create a registry for its =
values.
>>>>>> A
>>>>>> JWT header using that approach might look like the following =
where the
>>>>>> value
>>>>>> 1 is registered as some cool new JWT profile/application. The =
consumer
>>>>>> of
>>>>>> such a JWT would have to understand and process the "p" header, =
which
>>>>>> would
>>>>>> mean checking that it had the value expected.
>>>>>>=20
>>>>>>     {
>>>>>>      "alg":"ES256",
>>>>>>      "crit":["p"],
>>>>>>      "p":1
>>>>>>     }
>>>>>>=20
>>>>>> A JOSE compliant JWT validator would reject such a JWT even for =
an OAuth
>>>>>> access token or OIDC id_token because the "p" header isn't known =
or
>>>>>> understood but is marked as critical.
>>>>>>=20
>>>>>> To me, that seems like an approach to preventing confusion that =
has more
>>>>>> teeth than the "typ" header. Which is why I asked about it last =
week and
>>>>>> am
>>>>>> now bringing it to the list.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>>> privileged
>>>>>> material for the sole use of the intended recipient(s). Any =
review, use,
>>>>>> distribution or disclosure by others is strictly prohibited.  If =
you
>>>>>> have
>>>>>> received this communication in error, please notify the sender
>>>>>> immediately
>>>>>> by e-mail and delete the message and any file attachments from =
your
>>>>>> computer. Thank you.
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org 
>>>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
 =
=20
>>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged
>>>> material for the sole use of the intended recipient(s). Any review, =
use,
>>>> distribution or disclosure by others is strictly prohibited.  If =
you have
>>>> received this communication in error, please notify the sender =
immediately
>>>> by e-mail and delete the message and any file attachments from your
>>>> computer. Thank you.
>>>=20
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org 
>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn=
cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=
 =
=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

My only concern with a crit header is that it is potentially =
another layering violation.

It really should be the application and not JWS/JWE that =
determines if the content of the JWT is correct at a application =
layer.

To get =
your idea to work the application would need to push down to the JWT =
layer some value/s of p that it was willing to accept.   Without =
crit the application could just pass along typ or p to the application =
layer for matching.

I don=E2=80=99t hate the idea but it seems like it is likely =
to work against having generic JOSE libs separate from JWT. Perhaps that =
is the reality anyway.

How would you implement it?

John B.

On =
Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I wouldn't disagree that the  issue with =
Connect is overstated sometimes. And it's a non-issue with sec event due =
to the "nonce" claim (as you point out) as well as the omission of the =
"exp" claim. Assuming correct validation anyway. 

The BCP draft suggests explicit typing to prevent =
Cross-JWT Confusion more generally (not just sec events and id tokens). =
I was wondering if some use of "crit" might accomplish the same thing =
but also cover the case of existing JWT implementations being confused =
with new JWT profiles. 
On Thu, Jul 27, 2017 at 3:40 PM, =
John Bradley <ve7jtb@ve7jtb.com> wrote:
Not that I am against the =
general desire for JWT not to be confused, but the attack surface for =
someone to take a sec event from one context and replay it as a id_token =
to login is very small and if the client is correctly configured would =
not work as it is now.

The only way you could replay the sec event JWT is via the =
implicit flow.   The other flows would require a malicious AS and =
at that point you have bigger problems with a compromised token =
endpoint.

If =
you were to create a implicit response with the sec event token that has =
the correct issuer and aud, connect requires that nonce value from the =
request be present in the id_token.   This would require that the =
attacker somehow get the AS to put not only the claim but the correct =
value from the request into the token.

All in all I think that it is more =
likely (not 100% I admit) that a client will do that rather than =
checking the typ or a new crit JWT header parameter.

I am all for a general =
solution for this but I think the issue with Connect is overstated =
sometimes.

John =
B.
 
On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

We have the use case in =
SECEVENTS where a logout event (e.g. OIDF backchannel logout) is =
extremely close to an ID_TOKEN. 

Older relying parties who are do not =
yet support logout could be tricked into accepting a logout assertion as =
an ID_TOKEN since they are too similar, and  because a valid =
ID_TOKEN parser is in theory allowed to ignore claims it does not =
understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible =
erroneous acceptance of the logout event AS and ID_TOKEN.

Because of this the =
issue of distinguishing classes or types of JWTs emerged.

We discussed a number of =
differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =
=E2=80=9Ccrit", etc that would help.  But that really lead to the =
idea there there should be some best practices in the JWT BCP covering =
the issue(s).



<=
div style=3D"word-wrap:break-word" class=3D"">
Phil

Oracle Corporation, Identity Cloud =
Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com




On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even after reading the whole section, I still =
don't understand the
problem. Yes, a class of attack could =
exist where an attacker
substitutes a valid JWT from one =
security context into another
context. But isn't this =
resolved by audience validation?

On Thu, =
Jul 27, 2017 at 3:34 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it =
in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D 

On =
Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What =
class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just =
be
ignorant.

On Thu, Jul 27, =
2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG =
meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a =
recommendation for
preventing confusion of one kind of JWT =
for another. Time was running
short
in the =
meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on =
the list is that.

Section 3.9 of the JWT =
BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use =
of
explicit
typing may not achieve =
disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the =
"typ"
header
parameter value.'  And the =
recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently =
being used for
any
validation.

Alternatively using the JWS/JWE "crit" =
(Critical) Header Parameter to
signal
the =
type/intent/profile/application of a JWT could =
achieve
disambiguation
even in validation of =
existing kinds of JWTs. The critical header lists
other =
headers which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't =
understood. So a new
type/profile of JWT that uses the =
"crit" header would produce JWTs that
would be rejected =
even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction =
with a
profile/application/type specific header. Or it =
could provide a bit more
of
a framework like =
defining a registering a new JOSE header "p" (strawman
of =
p
as a very short name for profile) and create a registry =
for its values.
A
JWT header using that =
approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The =
consumer
of
such a JWT would have to =
understand and process the "p" header, which
would
mean checking that it had the value expected.
     {
 =
     "alg":"ES256",
 =
     "crit":["p"],
 =
     "p":1
 =
    }

A JOSE compliant =
JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't =
known or
understood but is marked as critical.

To me, that seems like an approach to =
preventing confusion that has more
teeth than the "typ" =
header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY =
NOTICE: This email may contain confidential and
privileged
material for the sole use of the =
intended recipient(s). Any review, use,
distribution or =
disclosure by others is strictly prohibited.  If you
have
received this communication in error, =
please notify the sender
immediately
by =
e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =




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

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =


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


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth







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

=

--Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB--

--001a11356e54ca290c055554053c
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIF83m8R13XOmBGOo6sruG+fqc4yK
pfdJWmVpQZ7bS1blMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDcyNzIyMjQwNlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQC10Ju56P9mVjQInaY5UU0xepweILOK4wYXBGHKY1/30MIs
kg5coT54EsawpVfqG/Y/1Bb45VgJAJ6K9ahkkZdaUWaV5vEb9U6dEb/phDrgcAqIVf4HEg1iMxfF
qAbV+BugMTs3ugVN7sNH3edqDeW6JB7gAfOAFTnp156zucFVOZgey6BJYduhHcRqzQniCJENr32B
SvYHOsrH7b6cuXq7kytbYjbOdifuH24ocaC/7wOfJIFTFYFNvnSyTeYV79TXWRS91+/LAwkUfdzo
qphnghFppirPr3t1PzjxSPc4vq1VrPPwwDI561JM46F1dFXgPcdtyM0sYTD6Xl6Nt/S/
--001a11356e54ca290c055554053c--


From nobody Thu Jul 27 15:56:59 2017
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 09D4A1321F6; Thu, 27 Jul 2017 15:56:58 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=augustcellars.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 5fCVa4EUm6Y3; Thu, 27 Jul 2017 15:56:53 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1CA1321F3; Thu, 27 Jul 2017 15:56:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_022F_01D306F0.ED22B9B0"
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501196183; h=from:subject:to:date:message-id; bh=PhfY0UlwMtbO14uZbH5xY1zDC3lAf3oSHjYmbwGP5Uc=; b=EaVaYdrUZUjVo+38y8NHqO2pCpPT/1GI5oPWOonlS5+40zbyWTS9XpRSffJ2hfL4NBRhsLyBgaz 9i+UQOBt7Vz5i/PJwqV3gP1pZqGYAbNV22x59fdGAf7joYkeT+yJgO6BktEMjp4JKrJO7klZKCMEC op2r6cbJtiU3p4+NBJZ7dW6FGBQfHRx8qgvGQsIieWH4xwK0pARiGFF+5+NqueE06ZYoVgVV0Z/LO oqxgV31lDE/8HVC1AFENsLEdB5cULP0AYR84qn8jPIiFHCkZEmmrzCFZk4NllNtc4uQc3STVWkL+P 7whX31V8l1c6qIYSmRc6WodGvvWNpiIZv69g==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 15:56:22 -0700
Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 15:56:16 -0700
From: Jim Schaad 
To: 'John Bradley' , 'Brian Campbell' 
CC: 'Nathaniel McCallum' , 'oauth' , , 'Phil Hunt' 
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>  <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com>
In-Reply-To: <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com>
Date: Thu, 27 Jul 2017 15:56:31 -0700
Message-ID: <022e01d3072b$997eab80$cc7c0280$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKHH2VI+OeMwPc+ZUkxtnVaGSt4zgKKIEysAp0kgMUCgqvlGAE7vSrFAkDebrACu261lgGhbu7joIP805A=
X-Originating-IP: [24.21.96.37]
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Jul 2017 22:56:58 -0000

------=_NextPart_000_022F_01D306F0.ED22B9B0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

One simple way to implement it would be to have an call which says =
=E2=80=9CI will deal with the following items if they exist=E2=80=9D.  =
This means that all the application needs to do is to say that it will =
process p and not what values are acceptable.

=20

Jim

=20

=20

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 27, 2017 3:24 PM
To: Brian Campbell 
Cc: Nathaniel McCallum ; oauth ; =
jose@ietf.org; Phil Hunt 
Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT =
for another in JWT BCP

=20

My only concern with a crit header is that it is potentially another =
layering violation.

=20

It really should be the application and not JWS/JWE that determines if =
the content of the JWT is correct at a application layer.

=20

To get your idea to work the application would need to push down to the =
JWT layer some value/s of p that it was willing to accept.   Without =
crit the application could just pass along typ or p to the application =
layer for matching.

=20

I don=E2=80=99t hate the idea but it seems like it is likely to work =
against having generic JOSE libs separate from JWT. Perhaps that is the =
reality anyway.

=20

How would you implement it?

=20

John B.

=20

On Jul 27, 2017, at 6:10 PM, Brian Campbell  > wrote:

=20

I wouldn't disagree that the issue with Connect is overstated sometimes. =
And it's a non-issue with sec event due to the "nonce" claim (as you =
point out) as well as the omission of the "exp" claim. Assuming correct =
validation anyway.=20

The BCP draft suggests explicit typing to prevent Cross-JWT Confusion =
more generally (not just sec events and id tokens). I was wondering if =
some use of "crit" might accomplish the same thing but also cover the =
case of existing JWT implementations being confused with new JWT =
profiles.=20

=20

On Thu, Jul 27, 2017 at 3:40 PM, John Bradley  > wrote:

Not that I am against the general desire for JWT not to be confused, but =
the attack surface for someone to take a sec event from one context and =
replay it as a id_token to login is very small and if the client is =
correctly configured would not work as it is now.

=20

The only way you could replay the sec event JWT is via the implicit =
flow.   The other flows would require a malicious AS and at that point =
you have bigger problems with a compromised token endpoint.

=20

If you were to create a implicit response with the sec event token that =
has the correct issuer and aud, connect requires that nonce value from =
the request be present in the id_token.   This would require that the =
attacker somehow get the AS to put not only the claim but the correct =
value from the request into the token.

=20

All in all I think that it is more likely (not 100% I admit) that a =
client will do that rather than checking the typ or a new crit JWT =
header parameter.

=20

I am all for a general solution for this but I think the issue with =
Connect is overstated sometimes.

=20

John B.

=20

On Jul 27, 2017, at 5:19 PM, Phil Hunt  > wrote:

=20

We have the use case in SECEVENTS where a logout event (e.g. OIDF =
backchannel logout) is extremely close to an ID_TOKEN.=20

=20

Older relying parties who are do not yet support logout could be tricked =
into accepting a logout assertion as an ID_TOKEN since they are too =
similar, and  because a valid ID_TOKEN parser is in theory allowed to =
ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - =
leading to a possible erroneous acceptance of the logout event AS and =
ID_TOKEN.

=20

Because of this the issue of distinguishing classes or types of JWTs =
emerged.

=20

We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =
=E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help.  But that =
really lead to the idea there there should be some best practices in the =
JWT BCP covering the issue(s).

=20

Phil

=20

Oracle Corporation, Identity Cloud Services Architect & Standards

@independentid

www.independentid.com =20

phil.hunt@oracle.com =20

=20

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum  > wrote:

=20

Even after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
 > wrote:



The draft describes it in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm=
l_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7 =
 =
&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK=
ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr=
tBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D=20

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum =
 >
wrote:




What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
 > wrote:



During the first WG meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a recommendation for
preventing confusion of one kind of JWT for another. Time was running
short
in the meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on the list is that.

Section 3.9 of the JWT BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use of
explicit
typing may not achieve disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the "typ"
header
parameter value.'  And the recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently being used for
any
validation.

Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
signal
the type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing kinds of JWTs. The critical header lists
other headers which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't understood. So a new
type/profile of JWT that uses the "crit" header would produce JWTs that
would be rejected even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction with a
profile/application/type specific header. Or it could provide a bit more
of
a framework like defining a registering a new JOSE header "p" (strawman
of p
as a very short name for profile) and create a registry for its values.
A
JWT header using that approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The consumer
of
such a JWT would have to understand and process the "p" header, which
would
mean checking that it had the value expected.

    {
     "alg":"ES256",
     "crit":["p"],
     "p":1
    }

A JOSE compliant JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't known or
understood but is marked as critical.

To me, that seems like an approach to preventing confusion that has more
teeth than the "typ" header. Which is why I asked about it last week and
am
now bringing it to the list.










CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.  If you
have
received this communication in error, please notify the sender
immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org =20
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_jose =
 =
&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK=
ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr=
tBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=20




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


_______________________________________________
jose mailing list
jose@ietf.org =20
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_jose =
 =
&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK=
ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr=
tBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=20

=20

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

=20


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

=20


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

=20


------=_NextPart_000_022F_01D306F0.ED22B9B0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable


One simple =
way to implement it would be to have an call which says =E2=80=9CI will =
deal with the following items if they exist=E2=80=9D.=C2=A0 This means =
that all the application needs to do is to say that it will process p =
and not what values are acceptable.
 
Jim
 
 
From: jose =
[mailto:jose-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Thursday, July 27, 2017 3:24 PM
To: =
Brian Campbell <bcampbell@pingidentity.com>
Cc: =
Nathaniel McCallum <npmccallum@redhat.com>; oauth =
<oauth@ietf.org>; jose@ietf.org; Phil Hunt =
<phil.hunt@oracle.com>
Subject: Re: [jose] [OAUTH-WG] =
preventing confusion of one kind of JWT for another in JWT =
BCP
 
My only =
concern with a crit header is that it is potentially another layering =
violation.
 
It really should be the application and not JWS/JWE =
that determines if the content of the JWT is correct at a application =
layer.
 
To get your idea to work the application would need to =
push down to the JWT layer some value/s of p that it was willing to =
accept.   Without crit the application could just pass along typ or =
p to the application layer for matching.
 
I =
don=E2=80=99t hate the idea but it seems like it is likely to work =
against having generic JOSE libs separate from JWT. Perhaps that is the =
reality anyway.
 
How would you implement =
it?
 
John B.
 
On Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com=
> wrote:
 
I wouldn't disagree =
that the issue with Connect is overstated sometimes. And it's a =
non-issue with sec event due to the "nonce" claim (as you =
point out) as well as the omission of the "exp" claim. =
Assuming correct validation anyway. 
The BCP draft suggests explicit typing to prevent =
Cross-JWT Confusion more generally (not just sec events and id tokens). =
I was wondering if some use of "crit" might accomplish the =
same thing but also cover the case of existing JWT implementations being =
confused with new JWT profiles. 
 
On Thu, =
Jul 27, 2017 at 3:40 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:
Not =
that I am against the general desire for JWT not to be confused, but the =
attack surface for someone to take a sec event from one context and =
replay it as a id_token to login is very small and if the client is =
correctly configured would not work as it is now.
 
The only way you could replay the sec event JWT is via =
the implicit flow.   The other flows would require a malicious AS =
and at that point you have bigger problems with a compromised token =
endpoint.
 
If you were to create a implicit response with the sec =
event token that has the correct issuer and aud, connect requires that =
nonce value from the request be present in the id_token.   This =
would require that the attacker somehow get the AS to put not only the =
claim but the correct value from the request into the =
token.
 
All in all I think that it is more likely (not 100% I =
admit) that a client will do that rather than checking the typ or a new =
crit JWT header parameter.
 
I =
am all for a general solution for this but I think the issue with =
Connect is overstated sometimes.
 
John B.
 
On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
 
We have the use case in SECEVENTS where a logout =
event (e.g. OIDF backchannel logout) is extremely close to an =
ID_TOKEN. 
 
Older relying parties who are do not yet support =
logout could be tricked into accepting a logout assertion as an ID_TOKEN =
since they are too similar, and  because a valid ID_TOKEN parser is =
in theory allowed to ignore claims it does not understand (e.g. =
=E2=80=9Cevents=E2=80=9D) - leading to a possible erroneous acceptance =
of the logout event AS and ID_TOKEN.
 
Because of this the issue of distinguishing classes or =
types of JWTs emerged.
 
We discussed a number of differentiators like =
=E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc =
that would help.  But that really lead to the idea there there =
should be some best practices in the JWT BCP covering the =
issue(s).
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect =
& Standards
@independentid
phil.hunt@oracle.com
 
On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> =
wrote:
 
Even after reading the whole section, I still don't =
understand the
problem. Yes, a class of attack could exist where an =
attacker
substitutes a valid JWT from one security context into =
another
context. But isn't this resolved by audience =
validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian =
Campbell
<bcampbell@pingidentity.com> =
wrote:

The =
draft describes it in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__=
tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D=
2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&am=
p;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgV=
regxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQ=
CVja_kY&e=3D 

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel =
McCallum <npmccallum@redhat.com>
wrote:


What class of attacks is this trying to prevent? I =
frankly don't see a
problem with confusing different types of JWT. =
But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, =
Brian Campbell
<bcampbell@pingidentity.com> =
wrote:

During the first WG meeting last week I =
asked if use of the JOSE "crit"
(Critical) Header Parameter =
had been considered as a recommendation for
preventing confusion of =
one kind of JWT for another. Time was running
short
in the meeting =
so there wasn't much discussion and it was requested that
I
take =
the question to the list. And so here on the list is =
that.

Section 3.9 of the JWT BCP draft now recommends explicit =
typing using
the
"typ" JWS/JWE header parameter but does =
concede that 'the use of
explicit
typing may not achieve =
disambiguation from existing kinds of JWTs, as
the
validation =
rules for existing kinds JWTs often do not use the =
"typ"
header
parameter value.'  And the =
recommendations for how to use the Type
Header
Parameter in JWT =
strongly suggest that it's not currently being used =
for
any
validation.

Alternatively using the JWS/JWE =
"crit" (Critical) Header Parameter to
signal
the =
type/intent/profile/application of a JWT could =
achieve
disambiguation
even in validation of existing kinds of =
JWTs. The critical header lists
other headers which must be =
understood and processed by the receiver and
that the JWS/JWE is =
invalid if those listed aren't understood. So a new
type/profile of =
JWT that uses the "crit" header would produce JWTs =
that
would be rejected even by existing applications of JWT =
validation (that
actually implement "crit" properly =
anyway).

The JWT BCP could suggest the use of "crit" in =
conjunction with a
profile/application/type specific header. Or it =
could provide a bit more
of
a framework like defining a =
registering a new JOSE header "p" (strawman
of p
as a =
very short name for profile) and create a registry for its =
values.
A
JWT header using that approach might look like the =
following where the
value
1 is registered as some cool new JWT =
profile/application. The consumer
of
such a JWT would have to =
understand and process the "p" header, which
would
mean =
checking that it had the value =
expected.

    {
    &nb=
sp;"alg":"ES256",
     &q=
uot;crit":["p"],
     "p&=
quot;:1
    }

A JOSE compliant JWT =
validator would reject such a JWT even for an OAuth
access token or =
OIDC id_token because the "p" header isn't known =
or
understood but is marked as critical.

To me, that seems =
like an approach to preventing confusion that has more
teeth than the =
"typ" header. Which is why I asked about it last week =
and
am
now bringing it to the =
list.










CONFIDENTIALITY NOTICE: =
This email may contain confidential and
privileged
material for =
the sole use of the intended recipient(s). Any review, =
use,
distribution or disclosure by others is strictly =
prohibited.  If you
have
received this communication in =
error, please notify the sender
immediately
by e-mail and delete =
the message and any file attachments from your
computer. Thank =
you.
_______________________________________________
jose mailing =
list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__=
www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHv=
lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4=
C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZ=
Bwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =




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

_______________________________________________
=
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__=
www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHv=
lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4=
C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZ=
Bwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =

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

______________________________________=
_________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 

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

------=_NextPart_000_022F_01D306F0.ED22B9B0--


From nobody Fri Jul 28 05:23:27 2017
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 538B1131DB6 for ; Fri, 28 Jul 2017 05:23:17 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ryqdU3D9N2 for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 7443A131B99 for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id e75so17209353pfj.2 for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1VHFSh1xJRM1p8np8Su+U7MoO8GhVpMrH5tkhPSx9iM=; b=G1KiyyPyCuhZ2g1dKc83ML+AOonyit3aw8Z19fReLuAZ2UE5BMw9gqf1s5ITczaQb0 yxOSjO58GJO3hAPRNBjkxXgksfWAmDJHmXyZYbt1CyenqmlUvDfkw8a9RkPXWqmIIuZk S9rPwXL+Mt7YgkdpRs+N3m11JeMp8XukA7sCA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1VHFSh1xJRM1p8np8Su+U7MoO8GhVpMrH5tkhPSx9iM=; b=eqp17xpqzKcb5cP+qX91kbOb8Cz2ib6+JQ0ZUZpm1vncRgJ+DulpLKTWafAt6+8c5g HGTZflt5Rhfmm1MgL3thKTPIwx/WuRCK85B5YvXiOeg56CBmo1cfX22Cg7mfGaY2ADMs Spny6bdQvW4yMay5wINiB117LXTXdCBPFr+UzCMmgKF85Au5vbaoUS9Ob8W47ILfRMZs QcwmJxmmicDGaBpLRuza+Q1d7FlJqAm6zhWmOv0DyfmXjGwu804S126bqnTNH8TEGjzq KdTcQVCV3InACvYLyQ1IavIyEDvBG2dDoVCxAMIytS8dBt/Lo1eNZHdbKOTAIhMPBVoj mzyQ==
X-Gm-Message-State: AIVw111oqiZ+6QCCXvA0BAokH7VOBUmLzi+gt6+X6395BNB4EZOmJScL KMRQ/UHF+5wKViGtDUWxtvg2S0lO/OkxqN7Jgq4qoy6VxZ7NpRUc8iwFVMvY2YdUuNy2MdjPQjN kD7ic
X-Received: by 10.84.236.4 with SMTP id q4mr7667987plk.423.1501244592887; Fri, 28 Jul 2017 05:23:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 05:22:42 -0700 (PDT)
In-Reply-To: <022e01d3072b$997eab80$cc7c0280$@augustcellars.com>
References:     <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com>  <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com> <022e01d3072b$997eab80$cc7c0280$@augustcellars.com>
From: Brian Campbell 
Date: Fri, 28 Jul 2017 06:22:42 -0600
Message-ID: 
To: Jim Schaad 
Cc: John Bradley , Nathaniel McCallum , oauth ,  "jose@ietf.org" , Phil Hunt 
Content-Type: multipart/alternative; boundary="f403045fe2d4ae3b3605555fbe89"
Archived-At: 
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 12:23:19 -0000

--f403045fe2d4ae3b3605555fbe89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah, I've implemented it in pretty much in the way Jim describes.

In my implementation of JWT validation the application sets things up by
pushing down all the info needed for validation (things like expected
audience & issuer, keys, allowed algorithms, etc.). So I'm probably biased
by that but also telling it that 'p' is okay as a critical header doesn't
feel like any more of a layering violation than anything else.

This example

shows how to use the library for regular JWT validation. This method

would be used to tell the JWT validator/consumer that the 'p' as a critical
header should be accepted. And then the JWT validator/consumer could be
told what value of 'p' is acceptable or required by adding a validator for
it

or the application code could just look at the headers after and check it
that way. That's how it could be done now with the existing general API. If
the BCP was to formalize something, I'd probably enhance the API with
something specific for it to make it even easier.




On Thu, Jul 27, 2017 at 4:56 PM, Jim Schaad  wrote:

> One simple way to implement it would be to have an call which says =E2=80=
=9CI will
> deal with the following items if they exist=E2=80=9D.  This means that al=
l the
> application needs to do is to say that it will process p and not what
> values are acceptable.
>
>
>
> Jim
>
>
>
>
>
> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Thursday, July 27, 2017 3:24 PM
> *To:* Brian Campbell 
> *Cc:* Nathaniel McCallum ; oauth ;
> jose@ietf.org; Phil Hunt 
> *Subject:* Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT
> for another in JWT BCP
>
>
>
> My only concern with a crit header is that it is potentially another
> layering violation.
>
>
>
> It really should be the application and not JWS/JWE that determines if th=
e
> content of the JWT is correct at a application layer.
>
>
>
> To get your idea to work the application would need to push down to the
> JWT layer some value/s of p that it was willing to accept.   Without crit
> the application could just pass along typ or p to the application layer f=
or
> matching.
>
>
>
> I don=E2=80=99t hate the idea but it seems like it is likely to work agai=
nst
> having generic JOSE libs separate from JWT. Perhaps that is the reality
> anyway.
>
>
>
> How would you implement it?
>
>
>
> John B.
>
>
>
> On Jul 27, 2017, at 6:10 PM, Brian Campbell 
> wrote:
>
>
>
> I wouldn't disagree that the issue with Connect is overstated sometimes.
> And it's a non-issue with sec event due to the "nonce" claim (as you poin=
t
> out) as well as the omission of the "exp" claim. Assuming correct
> validation anyway.
>
> The BCP draft suggests explicit typing to prevent Cross-JWT Confusion mor=
e
> generally (not just sec events and id tokens). I was wondering if some us=
e
> of "crit" might accomplish the same thing but also cover the case of
> existing JWT implementations being confused with new JWT profiles.
>
>
>
> On Thu, Jul 27, 2017 at 3:40 PM, John Bradley  wrote:
>
> Not that I am against the general desire for JWT not to be confused, but
> the attack surface for someone to take a sec event from one context and
> replay it as a id_token to login is very small and if the client is
> correctly configured would not work as it is now.
>
>
>
> The only way you could replay the sec event JWT is via the implicit flow.
>   The other flows would require a malicious AS and at that point you have
> bigger problems with a compromised token endpoint.
>
>
>
> If you were to create a implicit response with the sec event token that
> has the correct issuer and aud, connect requires that nonce value from th=
e
> request be present in the id_token.   This would require that the attacke=
r
> somehow get the AS to put not only the claim but the correct value from t=
he
> request into the token.
>
>
>
> All in all I think that it is more likely (not 100% I admit) that a clien=
t
> will do that rather than checking the typ or a new crit JWT header
> parameter.
>
>
>
> I am all for a general solution for this but I think the issue with
> Connect is overstated sometimes.
>
>
>
> John B.
>
>
>
> On Jul 27, 2017, at 5:19 PM, Phil Hunt  wrote:
>
>
>
> We have the use case in SECEVENTS where a logout event (e.g. OIDF
> backchannel logout) is extremely close to an ID_TOKEN.
>
>
>
> Older relying parties who are do not yet support logout could be tricked
> into accepting a logout assertion as an ID_TOKEN since they are too
> similar, and  because a valid ID_TOKEN parser is in theory allowed to
> ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - le=
ading to a
> possible erroneous acceptance of the logout event AS and ID_TOKEN.
>
>
>
> Because of this the issue of distinguishing classes or types of JWTs
> emerged.
>
>
>
> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2=
=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc
> that would help.  But that really lead to the idea there there should be
> some best practices in the JWT BCP covering the issue(s).
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services Architect & Standards
>
> @independentid
>
> www.independentid.com
>
> phil.hunt@oracle.com
>
>
>
> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum 
> wrote:
>
>
>
> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> context. But isn't this resolved by audience validation?
>
> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
>  wrote:
>
> The draft describes it in
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.
> ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-
> 23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1=
0&r=3D
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D
> 9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum  >
> wrote:
>
>
> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
> ignorant.
>
> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>  wrote:
>
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running
> short
> in the meeting so there wasn't much discussion and it was requested that
> I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using
> the
> "typ" JWS/JWE header parameter but does concede that 'the use of
> explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as
> the
> validation rules for existing kinds JWTs often do not use the "typ"
> header
> parameter value.'  And the recommendations for how to use the Type
> Header
> Parameter in JWT strongly suggest that it's not currently being used for
> any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to
> signal
> the type/intent/profile/application of a JWT could achieve
> disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more
> of
> a framework like defining a registering a new JOSE header "p" (strawman
> of p
> as a very short name for profile) and create a registry for its values.
> A
> JWT header using that approach might look like the following where the
> value
> 1 is registered as some cool new JWT profile/application. The consumer
> of
> such a JWT would have to understand and process the "p" header, which
> would
> mean checking that it had the value expected.
>
>     {
>      "alg":"ES256",
>      "crit":["p"],
>      "p":1
>     }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and
> am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you
> have
> received this communication in error, please notify the sender
> immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.
> ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC=
X5Y
> TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege=
d
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediatel=
y
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.
> ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC=
X5Y
> TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D
> 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-
> RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> 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.  If you have=
=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.*

--f403045fe2d4ae3b3605555fbe89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yeah, I've implemented it in pretty much in the w=
ay Jim describes.=C2=A0 

In my implementation of JWT vali=
dation the application sets things up by pushing down all the info needed f=
or validation (things like expected audience & issuer, keys, allowed al=
gorithms, etc.). So I'm probably biased by that but also telling it tha=
t 'p' is okay as a critical header doesn't feel like any more o=
f a layering violation than anything else. 

This example shows how to use the library for regula=
r JWT validation. This method would be used t=
o tell the JWT validator/consumer that the 'p' as a critical header=
 should be accepted. And then the JWT validator/consumer could be told what=
 value of 'p' is acceptable or required by adding a validator for it or the application code could just look at the hea=
ders after and check it that way. That's how it could be done now with =
the existing general API. If the BCP was to formalize something, I'd pr=
obably enhance the API with something specific for it to make it even easie=
r. 




On Thu, Jul 27, 2017 at 4:56 PM, Jim Sc=
haad <ietf@augustcellars.com> wrote:
One simple=
 way to implement it would be to have an call which says =E2=80=9CI will de=
al with the following items if they exist=E2=80=9D.=C2=A0 This means that a=
ll the application needs to do is to say that it will process p and not wha=
t values are acceptable.
=C2=
=A0
Jim
=C2=A0
=C2=A0
From: jose [mailto:jose-bounces@ietf.o=
rg] On Behalf Of John Bradley
Sent: Thursday, July 27,=
 2017 3:24 PM
To: Brian Campbell <bcampbell@pingidentity.com>
<=
b>Cc: Nathaniel McCallum <npmccallum@redhat.com>; oauth <oauth@ietf.org>; jose@ietf.org; Phil Hunt <phil.hunt@oracle.com=
>
Subject: Re: [jose] [OAUTH-WG] preventing confusion of one k=
ind of JWT for another in JWT BCP
=C2=A0
My only concern with a crit header is that it is potentially another =
layering violation.
=C2=
=A0
It really should be the app=
lication and not JWS/JWE that determines if the content of the JWT is corre=
ct at a application layer.
=C2=A0
To get your id=
ea to work the application would need to push down to the JWT layer some va=
lue/s of p that it was willing to accept. =C2=A0 Without crit the applicati=
on could just pass along typ or p to the application layer for matching.=

=C2=A0
I don=E2=80=99t hate the idea but it seems =
like it is likely to work against having generic JOSE libs separate from JW=
T. Perhaps that is the reality anyway.
=C2=A0
Ho=
w would you implement it?
=C2=A0
John B.<=
u>
=C2=A0
On Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
=C2=A0
=C2=A0=

On Thu, Jul 27, 2017 at 3:40 PM, John B=
radley <ve7jtb@ve=
7jtb.com> wrote:
Not that I am against the gen=
eral desire for JWT not to be confused, but the attack surface for someone =
to take a sec event from one context and replay it as a id_token to login i=
s very small and if the client is correctly configured would not work as it=
 is now.
=C2=A0<=
/p>
The only way you could replay the sec =
event JWT is via the implicit flow. =C2=A0 The other flows would require a =
malicious AS and at that point you have bigger problems with a compromised =
token endpoint.
=
=C2=A0
If you were to create a =
implicit response with the sec event token that has the correct issuer and =
aud, connect requires that nonce value from the request be present in the i=
d_token. =C2=A0 This would require that the attacker somehow get the AS to =
put not only the claim but the correct value from the request into the toke=
n.
=C2=A0<=
/p>
All in all I think that it is more lik=
ely (not 100% I admit) that a client will do that rather than checking the =
typ or a new crit JWT header parameter.
=C2=A0
I=
 am all for a general solution for this but I think the issue with Connect =
is overstated sometimes.
=C2=A0
John B.
=C2=A0
On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> w=
rote:
=C2=A0
We have the use cas=
e in SECEVENTS where a logout event (e.g. OIDF backchannel logout) is extre=
mely close to an ID_TOKEN.=C2=A0
=C2=A0
Older relying =
parties who are do not yet support logout could be tricked into accepting a=
 logout assertion as an ID_TOKEN since they are too similar, and =C2=A0beca=
use a valid ID_TOKEN parser is in theory allowed to ignore claims it does n=
ot understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible erron=
eous acceptance of the logout event AS and ID_TOKEN.
=C2=A0
Because of this the issue of distinguishing classes or types of=
 JWTs emerged.
=
=C2=A0
We discussed a number of=
 differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =E2=80=
=9Ccrit", etc that would help.=C2=A0 But that really lead to the idea =
there there should be some best practices in the JWT BCP covering the issue=
(s).
=C2=A0
=

Phil
=C2=A0
Oracle Corporation, Identity Cloud Services Architect & Standards<=
/u>
@independentid
phil.hunt@oracle.com
=C2=A0
On Jul 27, 2017, at=
 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:
=C2=A0
Even after reading the whole section, I still don't understand t=
he
problem. Yes, a class of attack could exist where an attacker
subs=
titutes a valid JWT from one security context into another
context. But =
isn't this resolved by audience validation?

On Thu, Jul 27, 2017=
 at 3:34 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:

=

The draft describes it in
http=
s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org=
_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&am=
p;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&=
amp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D=
02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4e=
nC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D 

On Thu, Jul 27, 20=
17 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>
wrote:


What class of attacks is this trying to prevent? I f=
rankly don't see a
problem with confusing different types of JWT. Bu=
t I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian =
Campbell
<bcampbell@pingidentity.com> wrote:

During the first WG meeting last week I =
asked if use of the JOSE "crit"
(Critical) Header Parameter ha=
d been considered as a recommendation for
preventing confusion of one ki=
nd of JWT for another. Time was running
short
in the meeting so there=
 wasn't much discussion and it was requested that
I
take the ques=
tion to the list. And so here on the list is that.

Section 3.9 of th=
e JWT BCP draft now recommends explicit typing using
the
"typ&qu=
ot; JWS/JWE header parameter but does concede that 'the use of
expli=
cit
typing may not achieve disambiguation from existing kinds of JWTs, a=
s
the
validation rules for existing kinds JWTs often do not use the &=
quot;typ"
header
parameter value.' =C2=A0And the recommendat=
ions for how to use the Type
Header
Parameter in JWT strongly suggest=
 that it's not currently being used for
any
validation.

Al=
ternatively using the JWS/JWE "crit" (Critical) Header Parameter =
to
signal
the type/intent/profile/application of a JWT could ach=
ieve
disambiguation
even in validation of existing kinds of JWTs. The=
 critical header lists
other headers which must be understood and proces=
sed by the receiver and
that the JWS/JWE is invalid if those listed aren=
't understood. So a new
type/profile of JWT that uses the "crit=
" header would produce JWTs that
would be rejected even by existing=
 applications of JWT validation (that
actually implement "crit"=
; properly anyway).

The JWT BCP could suggest the use of "crit&=
quot; in conjunction with a
profile/application/type specific header. Or=
 it could provide a bit more
of
a framework like defining a registeri=
ng a new JOSE header "p" (strawman
of p
as a very short nam=
e for profile) and create a registry for its values.
A
JWT header usi=
ng that approach might look like the following where the
value
1 is r=
egistered as some cool new JWT profile/application. The consumer
of
s=
uch a JWT would have to understand and process the "p" header, wh=
ich
would
mean checking that it had the value expected.

=C2=A0=
=C2=A0=C2=A0=C2=A0{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alg":"=
ES256",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"crit":["p&quo=
t;],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"p":1
=C2=A0=C2=A0=C2=A0=
=C2=A0}

A JOSE compliant JWT validator would reject such a JWT even =
for an OAuth
access token or OIDC id_token because the "p" hea=
der isn't known or
understood but is marked as critical.

To m=
e, that seems like an approach to preventing confusion that has more
tee=
th than the "typ" header. Which is why I asked about it last week=
 and
am
now bringing it to the list.







<=
br>

CONFIDENTIALITY NOTICE: This email may contain confidential and<=
br>privileged
material for the sole use of the intended recipient(s). An=
y review, use,
distribution or disclosure by others is strictly prohibit=
ed.=C2=A0 If you
have
received this communication in error, please no=
tify the sender
immediately
by e-mail and delete the message and any =
file attachments from your
computer. Thank you.
_____________________=
__________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url=
?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&=
amp;c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D=
JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlef=
gVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_Kpo=
baeSRUP4Cp2W-_jJU&e=3D 



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 o=
thers is strictly prohibited.=C2=A0 If you have
received this communicat=
ion in error, please notify the sender immediately
by e-mail and delete =
the message and any file attachments from your
computer. Thank you.

______________________=
_________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?=
u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&a=
mp;c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJ=
Bm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefg=
VregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_Kpob=
aeSRUP4Cp2W-_jJU&e=3D 
=C2=A0
<=
/div>
__________________________________________=
_____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau=
th
=
=C2=A0

_______________________________________________
OAu=
th mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0<=
/p>

CONFIDENTIALITY NOTICE: This email may contain conf=
idential and privileged material for the sole use of the intended recipient=
(s). Any review, use, distribution or disclosure by others is strictly proh=
ibited.=C2=A0 If you have received this communication in error, please noti=
fy the sender immediately by e-mail and delete the message and any file att=
achments from your computer. Thank you.
=C2=A0
=





<=
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.
--f403045fe2d4ae3b3605555fbe89--


From nobody Fri Jul 28 08:06:53 2017
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 B8AC7131CA4 for ; Fri, 28 Jul 2017 08:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level: 
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 eIqQociCdkC0 for ; Fri, 28 Jul 2017 08:06:50 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20483131D24 for ; Fri, 28 Jul 2017 08:06:49 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 056D05C167 for ; Fri, 28 Jul 2017 15:06:49 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 056D05C167
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=bburke@redhat.com
Received: from ovpn-116-148.phx2.redhat.com (ovpn-116-148.phx2.redhat.com [10.3.116.148]) by smtp.corp.redhat.com (Postfix) with ESMTP id C0FBF6C20A for ; Fri, 28 Jul 2017 15:06:48 +0000 (UTC)
To: oauth@ietf.org
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com>
From: Bill Burke 
Message-ID: <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>
Date: Fri, 28 Jul 2017 11:06:48 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 28 Jul 2017 15:06:49 +0000 (UTC)
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 15:06:52 -0000

Should probably have a "subject_issuer" and "actor_issuer" as well as 
the "requested_issuer" too.

FYI, I'm actually applying this spec to write a token exchange service 
to connect various product stacks that have different and often 
proprietary token formats and architectures.


On 7/26/17 6:44 PM, Bill Burke wrote:
> Hi all,
>
> I'm looking at Draft 9 of the token-exchange spec.  How would one 
> build a request to:
>
> * exchange a token issued by a different domain to a client managed by 
> the authorization server.
>
> * exchange a token issued by the authorization server (the STS) for a 
> token of a different issuer and different client.  In other words, for 
> a token targeted to a specific client in a different authorization 
> server or realm or domain or whatever you want to call it.
>
> * exchange a token issued by a different issuer for a token of a 
> different issuer and client.
>
> Is the spec missing something like a "requested_issuer" identifier?  
> Seems that audience is too opaque of a parameter for the authz server 
> to determine how to exchange the token.
>
> Thanks,
>
> Bill
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jul 28 11:26:01 2017
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 C28AC131E08; Fri, 28 Jul 2017 11:25:50 -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: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150126635076.25225.3854025136006448469@ietfa.amsl.com>
Date: Fri, 28 Jul 2017 11:25:50 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 18:25:51 -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           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
	Filename        : draft-ietf-oauth-mtls-03.txt
	Pages           : 17
	Date            : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the token endpoint as well as for
   certificate bound sender constrained access tokens.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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 Fri Jul 28 11:34:19 2017
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 EA28D132026 for ; Fri, 28 Jul 2017 11:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Level: 
X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgoakRSgM-Ae for ; Fri, 28 Jul 2017 11:34:16 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 64914131D69 for ; Fri, 28 Jul 2017 11:34:16 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id q85so98729961pfq.1 for ; Fri, 28 Jul 2017 11:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XVRCxH2gVtqNA/rz+H2sM4ROoApqX9sslWFrNtWbe18=; b=ht+Mx5vi3unne4bEjz2IILCjRbIb6WC0e/1NPaJoUC1dJXkza2DN9eKwNyKPgyyPtU 6Ul1AErWZ36FypLXpQQ4/aNV0S/1NpxxrL4hlkeo+LKmls+WMkDjJBoKpRotbN8w+v2G 2Pj8YLHGHBGlQKlcQp6REBMO5qlOv4ObuniDE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XVRCxH2gVtqNA/rz+H2sM4ROoApqX9sslWFrNtWbe18=; b=eBlmL1EOjBkvDSenevkECZhdqO0WHYdjiryVrX4328ATzYdXyFxh4MKWYUSKMaGypz oqC2+huRL5QNxE/6jhThei4PFNrVCgzKp9RrtEejEk0gom90ynY2dv0XnXvndxO8Mtas eEEMn4j1X43rRHwaQOqDKh8dnevotUpJRZR3CKG32PCFOFLZJqaXxXUdkQIobH+tEg4R oUfAhR4dWQhv6pnh+KfkA4aEpMWq1rX3/yreLf+DeGVQQv49+hdzSTtrv1T/GegxtDcz Yw/jFobxK+4ISJK7YrJlX5SEGPU44ejYu7uSgYP1w4NEy+adTnspHpTZTUBD18ySJsJa cV5g==
X-Gm-Message-State: AIVw110FGY4Y95/zTLnEb0Ste5b8yGCrqwuI9P/cDaSuWNHY7nZQhKQ7 /BHwd4p70vmapl3NNmIFe0E0fK/ESG+TGflWJ0pTFtZ0Q271bwmPNTF/FTKavj+hxU0ykH2LPqj cXDpz
X-Received: by 10.99.67.2 with SMTP id q2mr8291858pga.332.1501266855741; Fri, 28 Jul 2017 11:34:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 11:33:45 -0700 (PDT)
In-Reply-To: <150126635076.25225.3854025136006448469@ietfa.amsl.com>
References: <150126635076.25225.3854025136006448469@ietfa.amsl.com>
From: Brian Campbell 
Date: Fri, 28 Jul 2017 12:33:45 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="94eb2c08da74a66cfd055564ed4d"
Archived-At: 
Subject: [OAUTH-WG] Fwd:  I-D Action: draft-ietf-oauth-mtls-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 18:34:19 -0000

--94eb2c08da74a66cfd055564ed4d
Content-Type: text/plain; charset="UTF-8"

A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
the changes listed below based on comments and dissuasion in Prague.

   draft-ietf-oauth-mtls-03


   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints



---------- Forwarded message ----------
From: 
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: 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           : Mutual TLS Profile for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-03.txt
        Pages           : 17
        Date            : 2017-07-28

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for OAuth
   client authentication to the token endpoint as well as for
   certificate bound sender constrained access tokens.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-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/

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

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

--94eb2c08da74a66cfd055564ed4d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


A new draft of "Mutual TLS Profile for OAuth 2.0"=
; has been published with the changes listed below based on comments and di=
ssuasion in Prague. 

   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method =
is for
      the PKI method and introduced "pub_key_tls_client_auth" for=
 the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


-----=
----- Forwarded message ----------
From: <=
/b> <internet-drafts@ietf.org>
Date: Fri, Jul 28, =
2017 at 12:25 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-0=
3.txt
To: i-d=
-announce@ietf.org
Cc: oauth@ietf.org




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:=
 Mutual TLS Profile for OAuth 2.0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria=
n Campbell

=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 John Bradley

=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 Nat Sakimura

=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 Torsten Lodderstedt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-mtls-03.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 17

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-07-28



Abstract:

=C2=A0 =C2=A0This document describes Transport Layer Security (TLS) mutual<=
br>
=C2=A0 =C2=A0authentication using X.509 certificates as a mechanism for OAu=
th

=C2=A0 =C2=A0client authentication to the token endpoint as well as for

=C2=A0 =C2=A0certificate bound sender constrained access tokens.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-i=
etf-oauth-mtls/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-oaut=
h-mtls-03

https://datatracker.ietf.org/doc/=
html/draft-ietf-oauth-mtls-03



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-oauth-mtls-03





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







<=
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.
--94eb2c08da74a66cfd055564ed4d--


From nobody Fri Jul 28 13:00:23 2017
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 EAA181320EB for ; Fri, 28 Jul 2017 13:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46_dEHlq00GO for ; Fri, 28 Jul 2017 13:00:08 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 CDE31131E30 for ; Fri, 28 Jul 2017 13:00:05 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id e75so21176073pfj.2 for ; Fri, 28 Jul 2017 13:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=pjO7hzbo6zNlaPUI7+nwEY7wkHZlb6ExrDTXlZ7WVUw=; b=ROtyYfacZ2MKvHMbuyxuDFIst1Q9qCuYopAaK1OIqH0WQ8V7ppNO7tzTm7xnyXJT1q y2Vtlp/HwskH91XF2w7A/lRBQ7dE4WRbQxpp72iVjcdKQ9bBCUQ87glnX37dKtoBK5kY 1lebDw9OVeGqb2q8uIfh0OJ+20WaAM1/8gJMM=
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=pjO7hzbo6zNlaPUI7+nwEY7wkHZlb6ExrDTXlZ7WVUw=; b=qNS7T3lvNxjRYXpCaBbTd4SyQ676DcOvKdfwvXse3kl3fjN00Kp8MJjbPcAIPskyVX W8Y68vx3WDvsrp+IVG3pPVEfWpdD78yRHwoa7/SHBia67QODnQPaSjdNK4ncvPI+w8Ji 2EQ0st+BAC2nMvFVUmQ2VpkhYaBVoCgF4GO6UR1wwUUXbXlePBJFLrSXt2negYzDbpvq dKREBoNZJnuQ6DQXhwF0Uuoooktnq6w1/nvWVKkX0qMrVFEB5BVXn2rDLA4h2A6C8vLW xV5+54dJaL7m8RvNMU6vSN0q5Mg9y/ewj17YRbXscstibRidMiOYcyThtplldr2t6moM spmQ==
X-Gm-Message-State: AIVw113cKHz+4078wzH0CttaAhw9azAf2trG55tw4jLEN/uBeszyTUcm vTfmCJyHy1SFrS3k7M2IT9GzhXEHdVkp2Nwf31AVjyXfH14MixKF932gVhfjTwf09OqdWOxHhXx 5Yynn
X-Received: by 10.98.204.144 with SMTP id j16mr8641324pfk.25.1501272005267; Fri, 28 Jul 2017 13:00:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 12:59:34 -0700 (PDT)
From: Brian Campbell 
Date: Fri, 28 Jul 2017 13:59:34 -0600
Message-ID: 
To: oauth , "jose@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c11d6e295f60d0555662028"
Archived-At: 
Subject: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 20:00:10 -0000

--94eb2c11d6e295f60d0555662028
Content-Type: text/plain; charset="UTF-8"

On critique of JWT I've seen a few times can be paraphrased as "JWT
supports compressed plaintext so, because of CRIME and BREACH, it is
dangerous and stupid."  It's very possible that I am stupid (many on this
list will likely attest to it) but I don't see the applicability of those
kinds of chosen plaintext attacks aimed at recovering sensitive data to how
JWT/JWE are typically used.

I think it would be useful, if during the development of the JWT BCP, the
authors or chairs or WG could somehow engage some experts (CFRG?) to
understand if there's any real practical advice that can be given about
using compression with JWE and the risks involved.

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

--94eb2c11d6e295f60d0555662028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On critique of JWT I've seen a few times can be p=
araphrased as "JWT supports compressed plaintext so, because of CRIME and BREACH, it is dangerous and stupid."=
=C2=A0 It's very possible that I am stupid (many on this list will like=
ly attest to it) but I don't see the applicability of those kinds of ch=
osen plaintext attacks aimed at recovering sensitive data to how JWT/JWE ar=
e typically used.=C2=A0 

I think it would be useful, if during=
 the development of the JWT BCP, the authors or chairs or WG could somehow =
engage some experts (CFRG?) to understand if there's any real practical=
 advice that can be given about using compression with JWE and the risks in=
volved. 






<=
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.
--94eb2c11d6e295f60d0555662028--


From nobody Fri Jul 28 13:40:14 2017
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 318D51318A0 for ; Fri, 28 Jul 2017 13:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqtNW2FY1art for ; Fri, 28 Jul 2017 13:40:10 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 A3B6D12EA7C for ; Fri, 28 Jul 2017 13:40:10 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id e75so21472684pfj.2 for ; Fri, 28 Jul 2017 13:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xr7UjMXz6m3Z5lRZ0VNCkJTSHrXeDMWT01BfzDhd58Y=; b=QG+uKdlq3Crl3B8ooROVDduWN469owG7QvASjDgAnoSl8FUGsbBJmmxcZhBPitN9il 8/5Ktc3Pnin3Wcvjwgy2JFxOMoU6fuxGVjMXfPdn7BrmzA96l0/0QWgM6buU6xArAfLB wtA0NkHTXdAuJRXxfp1xtVdvpP8uY1rqJELLc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xr7UjMXz6m3Z5lRZ0VNCkJTSHrXeDMWT01BfzDhd58Y=; b=QIBJqLCnaf2UyD/N7CTZRfBUd62VPi/e5tLL+V6AgjBDwltuYsAbuuWriGJPDjtjEG 4pw+EHmY1o3FvMm5Kpvwm6owImKN9xQHhg0xjAUp5vwlWeB4QoO9XjowWIe6+0zVp5sX 6x9PYKFedKeupkvLZSwoWbQeIDxsTLBCcR0a+I1o74a21WuykPFz28gxEZ4UC12NlrZ2 PwkoskTNVlKLJCwUPdITZrdMyYFxZO2fZ97CgFziYH5TSRUwC8p/vIDEj74LiTCzUqnk +kM81dkFlGAWg+GMnZDa2aNhhLddCD87HGWD/rww4tEnqm/k0qyFh2mGFE+pDRR2iDeK kWKg==
X-Gm-Message-State: AIVw113mBcCbVNvajSEnLgCcn7ispuoZr0JLUlkl2HHJLlcDoxPYMvp7 x3P8e5eBMwXAP22TTxtt72e2iB+NUnkYfIuHCTVO93EyoN7ZTSo3MLJfrqHHTbuyMdgd4xLqvk/ gyzll
X-Received: by 10.98.204.144 with SMTP id j16mr8730266pfk.25.1501274410217; Fri, 28 Jul 2017 13:40:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 13:39:39 -0700 (PDT)
In-Reply-To: <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>
From: Brian Campbell 
Date: Fri, 28 Jul 2017 14:39:39 -0600
Message-ID: 
To: Bill Burke 
Cc: oauth 
Content-Type: multipart/alternative; boundary="94eb2c11d6e2ee8d27055566af8c"
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 20:40:13 -0000

--94eb2c11d6e2ee8d27055566af8c
Content-Type: text/plain; charset="UTF-8"

In general, an instance of an AS/STS can only issue tokens from itself. The
audience/resource parameters tell the AS/STS where the requested token will
be used, which will influence the audience of the token (and maybe other
aspects). But the issuer of the requested token will be the AS/STS that
issued it. A cross domain exchange could happen by a client presenting a
subject_token from a different domain/issuer (that the AS/STS trusts) and
receiving a token issued by that AS/STS suitable for the target domain.



On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke  wrote:

> Should probably have a "subject_issuer" and "actor_issuer" as well as the
> "requested_issuer" too.
>
> FYI, I'm actually applying this spec to write a token exchange service to
> connect various product stacks that have different and often proprietary
> token formats and architectures.
>
>
>
> On 7/26/17 6:44 PM, Bill Burke wrote:
>
>> Hi all,
>>
>> I'm looking at Draft 9 of the token-exchange spec.  How would one build a
>> request to:
>>
>> * exchange a token issued by a different domain to a client managed by
>> the authorization server.
>>
>> * exchange a token issued by the authorization server (the STS) for a
>> token of a different issuer and different client.  In other words, for a
>> token targeted to a specific client in a different authorization server or
>> realm or domain or whatever you want to call it.
>>
>> * exchange a token issued by a different issuer for a token of a
>> different issuer and client.
>>
>> Is the spec missing something like a "requested_issuer" identifier?
>> Seems that audience is too opaque of a parameter for the authz server to
>> determine how to exchange the token.
>>
>> Thanks,
>>
>> Bill
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--94eb2c11d6e2ee8d27055566af8c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In general, an instance of an AS/STS can only issue tokens=
 from itself. The audience/resource parameters tell the AS/STS  where the r=
equested token will be used, which will influence the audience of the token=
 (and maybe other aspects). But the issuer of the requested token will be t=
he AS/STS that issued it.  A cross domain exchange could happen by a client=
 presenting a subject_token from a different domain/issuer (that the AS/STS=
 trusts) and receiving a token issued by that AS/STS suitable for the targe=
t domain. 



On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke &l=
t;bburke@redhat.com<=
/a>> wrote:
Should probably hav=
e a "subject_issuer" and "actor_issuer" as well as the =
"requested_issuer" too.



FYI, I'm actually applying this spec to write a token exchange service =
to connect various product stacks that have different and often proprietary=
 token formats and architectures.





On 7/26/17 6:44 PM, Bill Burke wrote:



Hi all,



I'm looking at Draft 9 of the token-exchange spec.=C2=A0 How would one =
build a request to:



* exchange a token issued by a different domain to a client managed by the =
authorization server.



* exchange a token issued by the authorization server (the STS) for a token=
 of a different issuer and different client.=C2=A0 In other words, for a to=
ken targeted to a specific client in a different authorization server or re=
alm or domain or whatever you want to call it.



* exchange a token issued by a different issuer for a token of a different =
issuer and client.



Is the spec missing something like a "requested_issuer" identifie=
r?=C2=A0 Seems that audience is too opaque of a parameter for the authz ser=
ver to determine how to exchange the token.



Thanks,



Bill







_______________________________________________

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







<=
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.
--94eb2c11d6e2ee8d27055566af8c--


From nobody Fri Jul 28 14:27:12 2017
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 EBEF212FEE2 for ; Fri, 28 Jul 2017 14:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 8ryhrPwEU_IZ for ; Fri, 28 Jul 2017 14:27:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022DC1321A6 for ; Fri, 28 Jul 2017 14:27:06 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9127E13739; Fri, 28 Jul 2017 21:27:05 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9127E13739
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=bburke@redhat.com
Received: from ovpn-116-148.phx2.redhat.com (ovpn-116-148.phx2.redhat.com [10.3.116.148]) by smtp.corp.redhat.com (Postfix) with ESMTP id 26121600C2; Fri, 28 Jul 2017 21:27:05 +0000 (UTC)
To: Brian Campbell 
Cc: oauth 
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com> 
From: Bill Burke 
Message-ID: 
Date: Fri, 28 Jul 2017 17:27:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DC6324D9DC0FEC124513F173"
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 28 Jul 2017 21:27:05 +0000 (UTC)
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 21:27:10 -0000

This is a multi-part message in MIME format.
--------------DC6324D9DC0FEC124513F173
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for replying,

The Introduction of the spec implies that inter-security-domain exchange 
is supported: "

  A Security Token Service (STS) is a service capable of validating and
    issuing security tokens, which enables clients to obtain appropriate
    access credentials for resources in heterogeneous environments or
    across security domains.
"

But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?

i.e

subject_token: 

subject_token_type: urn:ietf:params:oauth:token-type:access-token

There's just no way for the STS to know where the subject_token came 
from because the subject_token can be completely opaque.

Now, on the flip side, if you are converting from an internal token to 
an external one, the audience parameter is just too undefined.  For 
example, how could you specify that you want a token for an external 
client of an external issuer.  Client ids are opaque in OAuth, and 
issuer id isn't even something that is defined at all.  In OpenID 
connect, an issuer id can be any URL.

IMO, adding optional "subject_token_issuer" and "requested_issuer" 
parameters only clarifies and simplifies the cross-domain case.   If you 
don't like "issuer" maybe "domain" is a better word?

Thanks for replying,

Bill





On 7/28/17 4:39 PM, Brian Campbell wrote:
> In general, an instance of an AS/STS can only issue tokens from 
> itself. The audience/resource parameters tell the AS/STS where the 
> requested token will be used, which will influence the audience of the 
> token (and maybe other aspects). But the issuer of the requested token 
> will be the AS/STS that issued it. A cross domain exchange could 
> happen by a client presenting a subject_token from a different 
> domain/issuer (that the AS/STS trusts) and receiving a token issued by 
> that AS/STS suitable for the target domain.
>
>
>
> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke  > wrote:
>
>     Should probably have a "subject_issuer" and "actor_issuer" as well
>     as the "requested_issuer" too.
>
>     FYI, I'm actually applying this spec to write a token exchange
>     service to connect various product stacks that have different and
>     often proprietary token formats and architectures.
>
>
>
>     On 7/26/17 6:44 PM, Bill Burke wrote:
>
>         Hi all,
>
>         I'm looking at Draft 9 of the token-exchange spec. How would
>         one build a request to:
>
>         * exchange a token issued by a different domain to a client
>         managed by the authorization server.
>
>         * exchange a token issued by the authorization server (the
>         STS) for a token of a different issuer and different client. 
>         In other words, for a token targeted to a specific client in a
>         different authorization server or realm or domain or whatever
>         you want to call it.
>
>         * exchange a token issued by a different issuer for a token of
>         a different issuer and client.
>
>         Is the spec missing something like a "requested_issuer"
>         identifier?  Seems that audience is too opaque of a parameter
>         for the authz server to determine how to exchange the token.
>
>         Thanks,
>
>         Bill
>
>
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org 
>         https://www.ietf.org/mailman/listinfo/oauth
>         
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>     
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./ 


--------------DC6324D9DC0FEC124513F173
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks for replying,

    

    
The Introduction of the spec implies that inter-security-domain
      exchange is supported: "

    

    
 A Security Token Service (STS) is a service capable of validating and
   issuing security tokens, which enables clients to obtain appropriate
   access credentials for resources in heterogeneous environments or
   across security domains.
"

But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?


    
i.e

    
subject_token: <opaque-string>

    
subject_token_type: urn:ietf:params:oauth:token-type:access-token

    
There's just no way for the STS to know where the subject_token
      came from because the subject_token can be completely opaque.  

    

    
Now, on the flip side, if you are converting from an internal
      token to an external one, the audience parameter is just too
      undefined.  For example, how could you specify that you want a
      token for an external client of an external issuer.  Client ids
      are opaque in OAuth, and issuer id isn't even something that is
      defined at all.  In OpenID connect, an issuer id can be any URL.

    

    
IMO, adding optional "subject_token_issuer" and
      "requested_issuer" parameters only clarifies and simplifies the
      cross-domain case.   If you don't like "issuer" maybe "domain" is
      a better word?

    
Thanks for replying,

    
Bill

    

    


    

    

    

    

    
On 7/28/17 4:39 PM, Brian Campbell
      wrote:

    

    

      
In general, an instance of an AS/STS can only issue
        tokens from itself. The audience/resource parameters tell the
        AS/STS where the requested token will be used, which will
        influence the audience of the token (and maybe other aspects).
        But the issuer of the requested token will be the AS/STS that
        issued it. A cross domain exchange could happen by a client
        presenting a subject_token from a different domain/issuer (that
        the AS/STS trusts) and receiving a token issued by that AS/STS
        suitable for the target domain. 

        

        

      

      


        
On Fri, Jul 28, 2017 at 9:06 AM, Bill
          Burke <bburke@redhat.com>
          wrote:

          
Should
            probably have a "subject_issuer" and "actor_issuer" as well
            as the "requested_issuer" too.

            

            FYI, I'm actually applying this spec to write a token
            exchange service to connect various product stacks that have
            different and often proprietary token formats and
            architectures.
            

              


                

                

                On 7/26/17 6:44 PM, Bill Burke wrote:

                

                  Hi all,

                  

                  I'm looking at Draft 9 of the token-exchange spec. 
                  How would one build a request to:

                  

                  * exchange a token issued by a different domain to a
                  client managed by the authorization server.

                  

                  * exchange a token issued by the authorization server
                  (the STS) for a token of a different issuer and
                  different client.  In other words, for a token
                  targeted to a specific client in a different
                  authorization server or realm or domain or whatever
                  you want to call it.

                  

                  * exchange a token issued by a different issuer for a
                  token of a different issuer and client.

                  

                  Is the spec missing something like a
                  "requested_issuer" identifier?  Seems that audience is
                  too opaque of a parameter for the authz server to
                  determine how to exchange the token.

                  

                  Thanks,

                  

                  Bill

                  

                  

                  

                  _______________________________________________

                  OAuth mailing list

                  OAuth@ietf.org

                  https://www.ietf.org/mailman/listinfo/oauth

                

                

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org

                https://www.ietf.org/mailman/listinfo/oauth

              

            

          

        

        

      

      

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

    

  


--------------DC6324D9DC0FEC124513F173--


From nobody Fri Jul 28 15:29:10 2017
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 165CB13230E for ; Fri, 28 Jul 2017 15:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i92afWHVyu7x for ; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 7DF7F1322FB for ; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id d67so32554554pfc.0 for ; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JElRXVogZovj70PbkPGPWlDU2mfQcGHyD6d7m+9u920=; b=Aw7ho0UNV5zf2w7aZKDBFP8gpb+wDLVLf+fy+EtVk3IjdxbaIBRmFerOVXRD2AEzia Xl4Mp26+yitl168AqQMQoCvEVlXCbQGjEelzIj8Mxg1iW4t6hAwDjYq7IygdI8WBv7N5 ZMzNuv0b3HvOV3MmKPV/hbXPS9qBqwum0j8co=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JElRXVogZovj70PbkPGPWlDU2mfQcGHyD6d7m+9u920=; b=QPJhjpYrB49L/mIvD079N32BVdWcLjgOOaVOGTTM00/f89FKZuhW967/eNocD5PG2J 0NmDwduh9xddiYZGxToyitXt/TE7rAzzZkFzXRO5SR5zaWmNpNgcL3LcziIKXr2eayU8 VQAWsWHFAjVrae8SgwMGWKFsbV7iNvGGOsnlzeRMxswxKg3TZDDvBWivWdRsF9j5ha6a B/+DKI/b2J+2f82X7YqTzi+EN7xQ5AXrRZ0p1lVIOzfRoUQOjmiv61hLGxxZBIPb45sg C+H37vaqEIV6dQSCvLL6VO1N8zSccgjrKqOQca+3ISw1j/qkXI0LBMmQq1WC8pjyHK/O RuuA==
X-Gm-Message-State: AIVw112ZQEdLoRgtAQ2lfZ+Z1IndqO/1AbtSsAN1P6zACfwwcqNOg/1b 1qUu0OkKxx+V9dHo5MLzfWEhYuzD6gEhUITJlfGRyou9haF+IHyNFe66XXRPcHZQDmcIpG5JbEh NA18H
X-Received: by 10.84.232.143 with SMTP id i15mr9343562plk.248.1501280946105; Fri, 28 Jul 2017 15:29:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 15:28:35 -0700 (PDT)
In-Reply-To: 
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>  
From: Brian Campbell 
Date: Fri, 28 Jul 2017 16:28:35 -0600
Message-ID: 
To: Bill Burke 
Cc: oauth 
Content-Type: multipart/alternative; boundary="f40304361ef480582805556835f8"
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jul 2017 22:29:09 -0000

--f40304361ef480582805556835f8
Content-Type: text/plain; charset="UTF-8"

The urn:ietf:params:oauth:token-type:access_token type is an "indicator
that the token is a typical OAuth access token issued by the authorization
server in question" (see near the end of section 3
)
so the issuer is the given STS in that case. Cross domain is possible by
use of other token types that are not opaque to the STS where the issuer
can be inferred from the token.

On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke  wrote:

> Thanks for replying,
>
> The Introduction of the spec implies that inter-security-domain exchange
> is supported: "
>
>  A Security Token Service (STS) is a service capable of validating and
>    issuing security tokens, which enables clients to obtain appropriate
>    access credentials for resources in heterogeneous environments or
>    across security domains.
> "
>
> But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?
>
> i.e
>
> subject_token: 
>
> subject_token_type: urn:ietf:params:oauth:token-type:access-token
>
> There's just no way for the STS to know where the subject_token came from
> because the subject_token can be completely opaque.
>
> Now, on the flip side, if you are converting from an internal token to an
> external one, the audience parameter is just too undefined.  For example,
> how could you specify that you want a token for an external client of an
> external issuer.  Client ids are opaque in OAuth, and issuer id isn't even
> something that is defined at all.  In OpenID connect, an issuer id can be
> any URL.
>
> IMO, adding optional "subject_token_issuer" and "requested_issuer"
> parameters only clarifies and simplifies the cross-domain case.   If you
> don't like "issuer" maybe "domain" is a better word?
>
> Thanks for replying,
>
> Bill
>
>
>
>
>
> On 7/28/17 4:39 PM, Brian Campbell wrote:
>
> In general, an instance of an AS/STS can only issue tokens from itself.
> The audience/resource parameters tell the AS/STS where the requested token
> will be used, which will influence the audience of the token (and maybe
> other aspects). But the issuer of the requested token will be the AS/STS
> that issued it. A cross domain exchange could happen by a client presenting
> a subject_token from a different domain/issuer (that the AS/STS trusts) and
> receiving a token issued by that AS/STS suitable for the target domain.
>
>
>
> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke  wrote:
>
>> Should probably have a "subject_issuer" and "actor_issuer" as well as the
>> "requested_issuer" too.
>>
>> FYI, I'm actually applying this spec to write a token exchange service to
>> connect various product stacks that have different and often proprietary
>> token formats and architectures.
>>
>>
>>
>> On 7/26/17 6:44 PM, Bill Burke wrote:
>>
>>> Hi all,
>>>
>>> I'm looking at Draft 9 of the token-exchange spec.  How would one build
>>> a request to:
>>>
>>> * exchange a token issued by a different domain to a client managed by
>>> the authorization server.
>>>
>>> * exchange a token issued by the authorization server (the STS) for a
>>> token of a different issuer and different client.  In other words, for a
>>> token targeted to a specific client in a different authorization server or
>>> realm or domain or whatever you want to call it.
>>>
>>> * exchange a token issued by a different issuer for a token of a
>>> different issuer and client.
>>>
>>> Is the spec missing something like a "requested_issuer" identifier?
>>> Seems that audience is too opaque of a parameter for the authz server to
>>> determine how to exchange the token.
>>>
>>> Thanks,
>>>
>>> Bill
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

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

--f40304361ef480582805556835f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The urn:ietf:params:oauth:token-type:access_token typ=
e is an "indicator that the token is a typical OAuth access token issu=
ed by the authorization server in question" (see near the end of section 3) so the issuer is the given STS in tha=
t case. Cross domain is possible by use of other token types that are not o=
paque to the STS where the issuer can be inferred from the token.
=


On Fri, Jul 28, 2=
017 at 3:27 PM, Bill Burke <bburke@redhat.com> wrote:

 =20
   =20
 =20
  

    
Thanks for replying,

    

    
The Introduction of the spec implies that inter-security-domain
      exchange is supported: "

    

    
 A Security Token Service (STS) is a service capable =
of validating and
   issuing security tokens, which enables clients to obtain appropriate
   access credentials for resources in heterogeneous environments or
   across security domains.
"

But with the current API if you want to exchange an external token to an in=
ternal one, there is no way for the STS to identify where the subject_token=
 originated.  Are you saying that an STS cannot accept tokens from an exter=
nal domain?


    
i.e

    
subject_token: <opaque-string>

    
subject_token_type: urn:ietf:params:oauth:token-type:access-tok=
en

    
There's just no way for the STS to know where the subject_token
      came from because the subject_token can be completely opaque.=C2=A0 <=
br>
    

    
Now, on the flip side, if you are converting from an internal
      token to an external one, the audience parameter is just too
      undefined.=C2=A0 For example, how could you specify that you want a
      token for an external client of an external issuer.=C2=A0 Client ids
      are opaque in OAuth, and issuer id isn't even something that is
      defined at all.=C2=A0 In OpenID connect, an issuer id can be any URL.=


    

    
IMO, adding optional "subject_token_issuer" and
      "requested_issuer" parameters only clarifies and simplifies=
 the
      cross-domain case.=C2=A0=C2=A0 If you don't like "issuer&quo=
t; maybe "domain" is
      a better word?

    
Thanks for replying,

    
Bill

    

    


    

    

    

    

    
On 7/28/17 4:39 PM,=
 Brian Campbell
      wrote:

    

    

      
In general, an instance of an AS/STS can only issue
        tokens from itself. The audience/resource parameters tell the
        AS/STS where the requested token will be used, which will
        influence the audience of the token (and maybe other aspects).
        But the issuer of the requested token will be the AS/STS that
        issued it. A cross domain exchange could happen by a client
        presenting a subject_token from a different domain/issuer (that
        the AS/STS trusts) and receiving a token issued by that AS/STS
        suitable for the target domain. 

        

        

      

      


        
On Fri, Jul 28, 2017 at 9:06 AM, Bill
          Burke <bburke@redhat.com>
          wrote:

          
Should
            probably have a "subject_issuer" and "actor_issu=
er" as well
            as the "requested_issuer" too.

            

            FYI, I'm actually applying this spec to write a token
            exchange service to connect various product stacks that have
            different and often proprietary token formats and
            architectures.
            

              


                

                

                On 7/26/17 6:44 PM, Bill Burke wrote:

                

                  Hi all,

                  

                  I'm looking at Draft 9 of the token-exchange spec.=C2=
=A0
                  How would one build a request to:

                  

                  * exchange a token issued by a different domain to a
                  client managed by the authorization server.

                  

                  * exchange a token issued by the authorization server
                  (the STS) for a token of a different issuer and
                  different client.=C2=A0 In other words, for a token
                  targeted to a specific client in a different
                  authorization server or realm or domain or whatever
                  you want to call it.

                  

                  * exchange a token issued by a different issuer for a
                  token of a different issuer and client.

                  

                  Is the spec missing something like a
                  "requested_issuer" identifier?=C2=A0 Seems that=
 audience is
                  too opaque of a parameter for the authz server to
                  determine how to exchange the token.

                  

                  Thanks,

                  

                  Bill

                  

                  

                  

                  _______________________________________________

                  OAuth mailing list

                  OAuth=
@ietf.org

                  https://www.ietf.org/mailman/listi=
nfo/oauth

                

                

                _______________________________________________

                OAuth mailing list

                OAuth@i=
etf.org

                https://www.ietf.org/mailman/listinf=
o/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.=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 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.
--f40304361ef480582805556835f8--


From nobody Fri Jul 28 22:58:00 2017
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 5E16712EC05 for ; Fri, 28 Jul 2017 22:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 DdS2HR2qCG8G for ; Fri, 28 Jul 2017 22:57:58 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 B6D3B127735 for ; Fri, 28 Jul 2017 22:57:57 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id 33so104911334wrz.4 for ; Fri, 28 Jul 2017 22:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KRnMEVZcv9PJVwkifIEeR7jIoOXGO9VNllZBNi9H0E8=; b=rbvW/qxX2gR6B8m9PGUdtSybNT6JjeHED0Cfaw+4n3O+foL1FGp3G9hUzh3uMukxG4 bcRlksnyYmsnCrTzKVWL5uPiuaDs9+i1lluXnwn76VxqFZ38s2C5h71VN8DSe9foOTDg 5d5aSwBFndGR6XaCL4WJR72vvTT6qHXKf47Ayg53KuMZSsMIQwur68d9B7+792IG3WyM XelRuNtjRBckE+we0Tk2IQSM3soqfaqy9WoHSn2UKSE8yc4TYff/p+/et7TQCszmoqu2 XZHShd9OVxNFCmbs/ayEwQ6c6qQ+Y8qd2no2DjPkkhjEvHm8BZLXAVQ3uZYjOooig5ym GpXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KRnMEVZcv9PJVwkifIEeR7jIoOXGO9VNllZBNi9H0E8=; b=bkkmsGgoErM9V2FC1UMiObMaaqXEHXTLuDzATIZyfGUgTOGNCGoGq2160jAcSne7ob GJRuGCHTgc8oHb/T2PTyci9dPlam36lYLbhS74ZGz7nj0Xp5v2uXBg2GqakC4OEFxwF0 FRbB/SV9m9ZnGZiRZ7G8e+Vw43fzfQSC+9hDeuV2NDY0Olq3ogE1QVA0vu2mypWCKAkB kfvhxoAVhrZt4XeYcufaK9krhr+ghGVWIzKEfF16te7HsHuqs9q6ifGtcRFGNQNcPZE0 dAoV1XXwjTxK8YV0oLSopUcoSZgKJ3v5ygniiRdiJ/uiTS4yuTKTfXFPfo67ut2AdTrr W6Yg==
X-Gm-Message-State: AIVw113k4rssSWOYx6Y18F42NvrBYj33Dn5kN8SqcaQactAudE7M8Hcb goRa1xrQisFl+Oz/1b4=
X-Received: by 10.223.130.137 with SMTP id 9mr7750201wrc.0.1501307875962; Fri, 28 Jul 2017 22:57:55 -0700 (PDT)
Received: from [10.0.0.9] (bzq-109-65-176-114.red.bezeqint.net. [109.65.176.114]) by smtp.gmail.com with ESMTPSA id u11sm5708495wma.22.2017.07.28.22.57.54 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 22:57:54 -0700 (PDT)
To: oauth@ietf.org
References: 
From: Yaron Sheffer 
Message-ID: <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
Date: Sat, 29 Jul 2017 08:57:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 05:57:59 -0000

Hi Brian,

These two attacks on TLS are only examples of the breakage that can 
occur when the adversary can control the plaintext to some degree (even 
a small piece of the plaintext, e.g. a malleable HTTP cookie can result 
in decryption of the whole message). Similar attacks were demonstrated 
in IPsec. Can you please add details on why typical use of JWT would not 
be susceptible to these attacks?

Thanks,
     Yaron

> On critique of JWT I've seen a few times can be paraphrased as "JWT
> supports compressed plaintext so, because of CRIME and BREACH, it is
> dangerous and stupid."  It's very possible that I am stupid (many on this
> list will likely attest to it) but I don't see the applicability of those
> kinds of chosen plaintext attacks aimed at recovering sensitive data to how
> JWT/JWE are typically used.
>
> I think it would be useful, if during the development of the JWT BCP, the
> authors or chairs or WG could somehow engage some experts (CFRG?) to
> understand if there's any real practical advice that can be given about
> using compression with JWE and the risks involved.
>


From nobody Sat Jul 29 07:46:29 2017
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 09C81126E3A for ; Sat, 29 Jul 2017 07:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.021
X-Spam-Level: 
X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 8uY8WsPZrQUY for ; Sat, 29 Jul 2017 07:46:24 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CA2126C7A for ; Sat, 29 Jul 2017 07:46:24 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EFC9BC11B93C; Sat, 29 Jul 2017 14:46:23 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EFC9BC11B93C
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=bburke@redhat.com
Received: from ovpn-116-148.phx2.redhat.com (ovpn-116-148.phx2.redhat.com [10.3.116.148]) by smtp.corp.redhat.com (Postfix) with ESMTP id 742195C8AB; Sat, 29 Jul 2017 14:46:23 +0000 (UTC)
To: Brian Campbell 
Cc: oauth 
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>   
From: Bill Burke 
Message-ID: 
Date: Sat, 29 Jul 2017 10:46:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FD89C76AA63C9F7EBD3F0522"
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Sat, 29 Jul 2017 14:46:24 +0000 (UTC)
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 14:46:27 -0000

This is a multi-part message in MIME format.
--------------FD89C76AA63C9F7EBD3F0522
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

So, you're saying the STS has to define a subject_type for each external 
token the client wants to exchange from?  A type that is potentially 
proprietary and different between each and every STS? On the opposite 
end, when you want to convert to an external token, the STS either has 3 
options for the client to specify that it wants an external token.  1) a 
proprietary response type, 2) a proprietary resource scheme, 3) a 
proprietary audience scheme.

Don't you think at minimum, the token-exchange spec should define a 
standard way to do OAuth to OAuth cross-domain exchanges?  Right now 
cross-domain exchanges are proprietary and completely up to the target 
STS on how it wants the client to formulate a cross-domain exchange.  I 
still think a "subject_issuer" and "requested_issuer" are the clearest 
and simplest way to enable such an interaction.


On 7/28/17 6:28 PM, Brian Campbell wrote:
> The urn:ietf:params:oauth:token-type:access_token type is an 
> "indicator that the token is a typical OAuth access token issued by 
> the authorization server in question" (see near the end of section 3 
> ) 
> so the issuer is the given STS in that case. Cross domain is possible 
> by use of other token types that are not opaque to the STS where the 
> issuer can be inferred from the token.
>
> On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke  > wrote:
>
>     Thanks for replying,
>
>     The Introduction of the spec implies that inter-security-domain
>     exchange is supported: "
>
>       A Security Token Service (STS) is a service capable of validating and
>         issuing security tokens, which enables clients to obtain appropriate
>         access credentials for resources in heterogeneous environments or
>         across security domains.
>     "
>
>     But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?
>
>     i.e
>
>     subject_token: 
>
>     subject_token_type: urn:ietf:params:oauth:token-type:access-token
>
>     There's just no way for the STS to know where the subject_token
>     came from because the subject_token can be completely opaque.
>
>     Now, on the flip side, if you are converting from an internal
>     token to an external one, the audience parameter is just too
>     undefined.  For example, how could you specify that you want a
>     token for an external client of an external issuer.  Client ids
>     are opaque in OAuth, and issuer id isn't even something that is
>     defined at all.  In OpenID connect, an issuer id can be any URL.
>
>     IMO, adding optional "subject_token_issuer" and "requested_issuer"
>     parameters only clarifies and simplifies the cross-domain case.  
>     If you don't like "issuer" maybe "domain" is a better word?
>
>     Thanks for replying,
>
>     Bill
>
>
>
>
>
>     On 7/28/17 4:39 PM, Brian Campbell wrote:
>>     In general, an instance of an AS/STS can only issue tokens from
>>     itself. The audience/resource parameters tell the AS/STS where
>>     the requested token will be used, which will influence the
>>     audience of the token (and maybe other aspects). But the issuer
>>     of the requested token will be the AS/STS that issued it. A cross
>>     domain exchange could happen by a client presenting a
>>     subject_token from a different domain/issuer (that the AS/STS
>>     trusts) and receiving a token issued by that AS/STS suitable for
>>     the target domain.
>>
>>
>>
>>     On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke >     > wrote:
>>
>>         Should probably have a "subject_issuer" and "actor_issuer" as
>>         well as the "requested_issuer" too.
>>
>>         FYI, I'm actually applying this spec to write a token
>>         exchange service to connect various product stacks that have
>>         different and often proprietary token formats and architectures.
>>
>>
>>
>>         On 7/26/17 6:44 PM, Bill Burke wrote:
>>
>>             Hi all,
>>
>>             I'm looking at Draft 9 of the token-exchange spec.  How
>>             would one build a request to:
>>
>>             * exchange a token issued by a different domain to a
>>             client managed by the authorization server.
>>
>>             * exchange a token issued by the authorization server
>>             (the STS) for a token of a different issuer and different
>>             client.  In other words, for a token targeted to a
>>             specific client in a different authorization server or
>>             realm or domain or whatever you want to call it.
>>
>>             * exchange a token issued by a different issuer for a
>>             token of a different issuer and client.
>>
>>             Is the spec missing something like a "requested_issuer"
>>             identifier?  Seems that audience is too opaque of a
>>             parameter for the authz server to determine how to
>>             exchange the token.
>>
>>             Thanks,
>>
>>             Bill
>>
>>
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             OAuth@ietf.org 
>>             https://www.ietf.org/mailman/listinfo/oauth
>>             
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         
>>
>>
>>
>>     /CONFIDENTIALITY NOTICE: This email may contain confidential and
>>     privileged material for the sole use of the intended
>>     recipient(s). Any review, use, distribution or disclosure by
>>     others is strictly prohibited.  If you have received this
>>     communication in error, please notify the sender immediately by
>>     e-mail and delete the message and any file attachments from your
>>     computer. Thank you./ 
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./ 


--------------FD89C76AA63C9F7EBD3F0522
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
So, you're saying the STS has to define a subject_type for each
      external token the client wants to exchange from?  A type that is
      potentially proprietary and different between each and every STS? 
      On the opposite end, when you want to convert to an external
      token, the STS either has 3 options for the client to specify that
      it wants an external token.  1) a proprietary response type, 2) a
      proprietary resource scheme, 3) a proprietary audience scheme.

    

    
Don't you think at minimum, the token-exchange spec should define
      a standard way to do OAuth to OAuth cross-domain exchanges?  Right
      now cross-domain exchanges are proprietary and completely up to
      the target STS on how it wants the client to formulate a
      cross-domain exchange.  I still think a "subject_issuer" and
      "requested_issuer" are the clearest and simplest way to enable
      such an interaction.

    

    
On 7/28/17 6:28 PM, Brian Campbell
      wrote:

    

    

      
The urn:ietf:params:oauth:token-type:access_token
        type is an "indicator that the token is a typical OAuth access
        token issued by the authorization server in question" (see near
        the end of section 3) so the
        issuer is the given STS in that case. Cross domain is possible
        by use of other token types that are not opaque to the STS where
        the issuer can be inferred from the token.

      

      


        
On Fri, Jul 28, 2017 at 3:27 PM, Bill
          Burke <bburke@redhat.com>
          wrote:

          

            

              
Thanks for replying,

              

              
The Introduction of the spec implies that
                inter-security-domain exchange is supported: "

              

              
 A Security Token Service (STS) is a service capable of validating and
   issuing security tokens, which enables clients to obtain appropriate
   access credentials for resources in heterogeneous environments or
   across security domains.
"

But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?


              
i.e

              
subject_token: <opaque-string>

              
subject_token_type: urn:ietf:params:oauth:token-type:access-token

              
There's just no way for the STS to know where the
                subject_token came from because the subject_token can be
                completely opaque.  

              

              
Now, on the flip side, if you are converting from an
                internal token to an external one, the audience
                parameter is just too undefined.  For example, how could
                you specify that you want a token for an external client
                of an external issuer.  Client ids are opaque in OAuth,
                and issuer id isn't even something that is defined at
                all.  In OpenID connect, an issuer id can be any URL.

              

              
IMO, adding optional "subject_token_issuer" and
                "requested_issuer" parameters only clarifies and
                simplifies the cross-domain case.   If you don't like
                "issuer" maybe "domain" is a better word?

              
Thanks for replying,

              
Bill

              

              

                

                  


                  

                  

                  

                  

                  
On
                    7/28/17 4:39 PM, Brian Campbell wrote:

                  

                

              

              

                

                  

                    
In general, an instance of an AS/STS
                      can only issue tokens from itself. The
                      audience/resource parameters tell the AS/STS where
                      the requested token will be used, which will
                      influence the audience of the token (and maybe
                      other aspects). But the issuer of the requested
                      token will be the AS/STS that issued it. A cross
                      domain exchange could happen by a client
                      presenting a subject_token from a different
                      domain/issuer (that the AS/STS trusts) and
                      receiving a token issued by that AS/STS suitable
                      for the target domain. 

                      

                      

                    

                    


                      
On Fri, Jul 28, 2017 at
                        9:06 AM, Bill Burke <bburke@redhat.com>
                        wrote:

                        
Should probably have a
                          "subject_issuer" and "actor_issuer" as well as
                          the "requested_issuer" too.

                          

                          FYI, I'm actually applying this spec to write
                          a token exchange service to connect various
                          product stacks that have different and often
                          proprietary token formats and architectures.
                          

                            


                              

                              

                              On 7/26/17 6:44 PM, Bill Burke wrote:

                              
 Hi all,

                                

                                I'm looking at Draft 9 of the
                                token-exchange spec.  How would one
                                build a request to:

                                

                                * exchange a token issued by a different
                                domain to a client managed by the
                                authorization server.

                                

                                * exchange a token issued by the
                                authorization server (the STS) for a
                                token of a different issuer and
                                different client.  In other words, for a
                                token targeted to a specific client in a
                                different authorization server or realm
                                or domain or whatever you want to call
                                it.

                                

                                * exchange a token issued by a different
                                issuer for a token of a different issuer
                                and client.

                                

                                Is the spec missing something like a
                                "requested_issuer" identifier?  Seems
                                that audience is too opaque of a
                                parameter for the authz server to
                                determine how to exchange the token.

                                

                                Thanks,

                                

                                Bill

                                

                                

                                

                                _______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

                                https://www.ietf.org/mailman/listinfo/oauth

                              

                              

                              _______________________________________________

                              OAuth mailing list

                              OAuth@ietf.org

                              https://www.ietf.org/mailman/listinfo/oauth

                            

                          

                        

                      

                      

                    

                    

                  

                

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

              

            

          

        

        

      

      

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

    

  


--------------FD89C76AA63C9F7EBD3F0522--


From nobody Sat Jul 29 11:32:58 2017
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 E6B6F131DA2 for ; Sat, 29 Jul 2017 11:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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.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 qto1_xWmGP8k for ; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 2C54D131CFD for ; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id k190so57523952pgk.5 for ; Sat, 29 Jul 2017 11:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9A5XMmvzXgFiL6XMdyy0ELoVz1UTBSToMebGNLbhpkk=; b=SVUXeXuabQfDrZ3q7oOSLO7yty+sACggKj+fKK5VbioKJw7hFUso4Vc7J4zumnJUAF yEFH1J7M2NnHRQMzQVVSvC8pQmVTxwuo3d0iL1UeorPFbG/js43gN/lrtDufVJPtJHil m6JO5DXL9FQSTFef1YYcEgFRO8V35G4PPDJgBV2Xto61WiDpWFmpuf4ZS9/AnurRirdM OKxTSblrqchxxLtOulygNV2+FuEJJyF28BYA8IAt1hIcjKwPrSxdD36skOGyMIr86eHZ BUkf05qv2nQNTp/IuYhqi7aEvk3KaUmxiytIprSU8CD6c7TlpMyun7XK7d9vYOx4MVk7 hTOA==
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=9A5XMmvzXgFiL6XMdyy0ELoVz1UTBSToMebGNLbhpkk=; b=KzfAPUqOWMFqO+CghxN01QcoASLTL4hNhmTIjaQQQSAJyLu8fTkYv+34WtRJBKaWTz Cf9qTJz0GYIhpxJybQg5WRO9en2BGly0OOw21RxJUbGm9wfQZyb5rtxtEbfNJGBQgBQY QJBHHbjUV89QLZSShVw5d9NOo6PS0gA0tTVCp3OsggUaZKHVrPatXYyGndLeEi+kN0sv zjVZ4suqYF3SrnRVYO7QRybWm4pIuOUGcQlp74xpnD/+2TQPOSxblu1kpozE9fWKHA96 SX8JK++i4HXjNiVNwLM7nPEV+fy1RTOSt69oILfZfB1oyEPdhzXo3oqP7NRsWExrhG4h hyYA==
X-Gm-Message-State: AIVw112JPOdvune4RNOYjeSUOjRt+1bjp/Pe3oFbad+Q8gG1rNcHMO9G xpWLfso4AM3JMh83yh8psQ==
X-Received: by 10.84.229.136 with SMTP id c8mr12047696plk.27.1501353174327; Sat, 29 Jul 2017 11:32:54 -0700 (PDT)
Received: from ?IPv6:2605:e000:112b:c167:5c99:7884:e707:db7c? ([2605:e000:112b:c167:5c99:7884:e707:db7c]) by smtp.gmail.com with ESMTPSA id u67sm1358736pfd.164.2017.07.29.11.32.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 11:32:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jim Manico 
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
Date: Sat, 29 Jul 2017 08:32:51 -1000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
To: Yaron Sheffer 
Archived-At: 
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 18:32:57 -0000

Yaron,

As a developer, I can think of many scenarios where the attacker controls so=
me of the plaintext yet I still need encryption services of some kind. What a=
re the proper crypto controls that allow developers to do this safely? I thi=
nk that's the better question right now.

Aloha,
--
Jim Manico
@Manicode

> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer  wrote:
>=20
> Hi Brian,
>=20
> These two attacks on TLS are only examples of the breakage that can occur w=
hen the adversary can control the plaintext to some degree (even a small pie=
ce of the plaintext, e.g. a malleable HTTP cookie can result in decryption o=
f the whole message). Similar attacks were demonstrated in IPsec. Can you pl=
ease add details on why typical use of JWT would not be susceptible to these=
 attacks?
>=20
> Thanks,
>    Yaron
>=20
>> On critique of JWT I've seen a few times can be paraphrased as "JWT
>> supports compressed plaintext so, because of CRIME and BREACH, it is
>> dangerous and stupid."  It's very possible that I am stupid (many on this=

>> list will likely attest to it) but I don't see the applicability of those=

>> kinds of chosen plaintext attacks aimed at recovering sensitive data to h=
ow
>> JWT/JWE are typically used.
>>=20
>> I think it would be useful, if during the development of the JWT BCP, the=

>> authors or chairs or WG could somehow engage some experts (CFRG?) to
>> understand if there's any real practical advice that can be given about
>> using compression with JWE and the risks involved.
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sat Jul 29 13:22:27 2017
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 BE2DA131E0B for ; Sat, 29 Jul 2017 13:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 K_tcbVITqnCm for ; Sat, 29 Jul 2017 13:22:24 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 C849A131DFD for ; Sat, 29 Jul 2017 13:22:23 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id 12so165985394wrb.1 for ; Sat, 29 Jul 2017 13:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G9hLNLa8lipQTjorwLjl8JN+MWEnt4vku7irGqeCmDI=; b=f807Ny7kpyzE3NaHDHLzV+esle5OEGQNNh/aYttw9MQJo0VVabcYc5f1HHlswXLGo8 9SXtz/iQ9JwPdym1sJEpQXTNY/im2CZe6mHu1m0LgSRokyEbMOuAzP79Zi3NbtUgLgI9 tY48M3O13/KYc2coLcOn0XntFIeppgCxZF9402Oq4E6VzhGCV7mQLDTcLfp4V+VCPNBY nApm0Hr2CWd5W+VK7w9FB5r7W9WSp4iC2cX1RGE1k/lwZlWDO7Ek8b/fy7PeWt9YIJf1 CMIKW9PgWMDRPDKjF45yRZkBEqkBDk4nYBYpX24Z8zHlz0s8tBFLixYg8Tz/RjW7qC8f VOvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G9hLNLa8lipQTjorwLjl8JN+MWEnt4vku7irGqeCmDI=; b=qZMpIx04QDEZ0zYV7WbGaZZzgEiMTjkJhMo8YZMqn93Qnc9wpI9WCBkMAZgNXr0ph9 gMHhouZCLL1uPiiVo1YhVzIdRbW2d5Q9cxjuHUUwDY3aIbY/tt2jH6ehY1Jx3sbo2cje 6QFfXGxn5KZb00t72uuxKPQ2Xe4X3tWjzxR047osEiKOelEKkmd4SHHIhdpFIstxJzli nwECsgFNf6w21rCUFJmY98vzby72OH1pg7OCgS0sMYHTeqg3Si+ZdB1dM1TolWeHkECf WcMSShbXlXHS9dPbbaVU5GPQnDloMnkhSn/ZQUCR/ayUWgQTxzuIrcEKK2Ln3dnVHNE9 9lqQ==
X-Gm-Message-State: AIVw110ThlpkcT6Ny2II2ESNJwMr3Q3LiMaZzEox4yAAOFT2lXnTkfu3 GaR8l9Nwa+UVUK/k5KY=
X-Received: by 10.223.141.131 with SMTP id o3mr8646696wrb.110.1501359742052; Sat, 29 Jul 2017 13:22:22 -0700 (PDT)
Received: from [10.0.0.9] (bzq-109-65-176-114.red.bezeqint.net. [109.65.176.114]) by smtp.gmail.com with ESMTPSA id v8sm26083019wrd.28.2017.07.29.13.22.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 13:22:21 -0700 (PDT)
To: Jim Manico 
Cc: oauth@ietf.org
References:  <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com> 
From: Yaron Sheffer 
Message-ID: 
Date: Sat, 29 Jul 2017 23:22:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 20:22:26 -0000

Hi Jim,

The problem is not the encryption of attacker-controlled data. The 
problem is the interaction between this encryption and compression.

If you don't need compression, you're good. You're mostly OK if you can 
compress only the non-attacker controlled data, however this could 
potentially leak information about ciphertext.

This is all very use-case specific and fragile, so I think a reasonable 
recommendation is:

- Avoid transparent compression in generic JWS/JWE libraries.
- Only compress data at the application layer, but bear in mind that the 
length of compressed+encrypted data leaks information about cleartext.

Thanks,
	Yaron

On 29/07/17 21:32, Jim Manico wrote:
> Yaron,
> 
> As a developer, I can think of many scenarios where the attacker controls some of the plaintext yet I still need encryption services of some kind. What are the proper crypto controls that allow developers to do this safely? I think that's the better question right now.
> 
> Aloha,
> --
> Jim Manico
> @Manicode
> 
>> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer  wrote:
>>
>> Hi Brian,
>>
>> These two attacks on TLS are only examples of the breakage that can occur when the adversary can control the plaintext to some degree (even a small piece of the plaintext, e.g. a malleable HTTP cookie can result in decryption of the whole message). Similar attacks were demonstrated in IPsec. Can you please add details on why typical use of JWT would not be susceptible to these attacks?
>>
>> Thanks,
>>     Yaron
>>
>>> On critique of JWT I've seen a few times can be paraphrased as "JWT
>>> supports compressed plaintext so, because of CRIME and BREACH, it is
>>> dangerous and stupid."  It's very possible that I am stupid (many on this
>>> list will likely attest to it) but I don't see the applicability of those
>>> kinds of chosen plaintext attacks aimed at recovering sensitive data to how
>>> JWT/JWE are typically used.
>>>
>>> I think it would be useful, if during the development of the JWT BCP, the
>>> authors or chairs or WG could somehow engage some experts (CFRG?) to
>>> understand if there's any real practical advice that can be given about
>>> using compression with JWE and the risks involved.
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sat Jul 29 13:44:27 2017
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 32535129ADD for ; Sat, 29 Jul 2017 13:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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.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 WoXTzHze8WxF for ; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 8420F126CD8 for ; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id u185so17863617pgb.1 for ; Sat, 29 Jul 2017 13:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=sLB70FbeUTzNVbcR6gyZf20n7AUjG5X86SvGZo69/ds=; b=pI6kCLqRl46XXqTlStha/Af0YlJzNa4oQLxKMmAJ8xJme3mF+/lzQojnyBEd+YvyKN IE7vnJ2oidhRcXBfkSBX1ZdVS1NcrwWvdq5rJt3Vqeku1K8hKLVzGfaxedgMee9rNUhC TYRS4q9FD/7EVZwKC3jK4U+MFsWvYNJDuiNKDwk6Gg81ujWd+tFLawhkNRnGdsfqdPdO DVr2CuJZuE2GOerUIXw/hxG+2HlF23mreFz31IYN5qFIK4ALJbp+Vapm8wdDWJSPRoHk GtZWykv1qkBTe995mOmy3FjZctg7Vn+QyHV/Gwk0jeusHujrmsoP+rANc4S42TJg7bJ4 Xy9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=sLB70FbeUTzNVbcR6gyZf20n7AUjG5X86SvGZo69/ds=; b=ZCr013l6cbTb6mw2BJdegkgk/3ROYkii+7xtkYL3Hent5KOiDNFu2YVm2ESv+3qc+V vZNYlenGjUc+iDMzHeAsRFuRp42GHWZkg+9W5k1EsVogW8m1Qi58GMzNB2+dDdhG7oG/ QvuHKY6QZUD/M+Ky7E61PY+3y42t40ahFuFK6ZpgvE1c/fSkaadK7rfusZ7Aa3cKciln D7giSZcM4k6reCbHSbD6DCvkFACly/fUkm4Q7eG6ik8oOAT+eYtsvZ1DZJ5upG2oyLWJ XJ7rHoseR3MLHvXVi0EPYGsxPaxjz39AfTvJNrT/b2fmlcYrHnzGP5p/gmvBLOxpQqQb pQsg==
X-Gm-Message-State: AIVw110WTJ7zg4/ITdjMaL4r6gfYiICPCGMdMuy+7BoJ/sFGCRSW9U+d sfcg/TLwBqSIBu4prX1T/A==
X-Received: by 10.99.98.3 with SMTP id w3mr11401418pgb.350.1501361063716; Sat, 29 Jul 2017 13:44:23 -0700 (PDT)
Received: from heembo.local ([2605:e000:112b:c167:bc89:293d:29e9:6603]) by smtp.googlemail.com with ESMTPSA id f2sm40870231pgc.17.2017.07.29.13.44.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jul 2017 13:44:22 -0700 (PDT)
To: Yaron Sheffer 
Cc: oauth@ietf.org
References:  <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>  
From: Jim Manico 
Message-ID: 
Date: Sat, 29 Jul 2017 10:44:19 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jul 2017 20:44:26 -0000

This looks like a very reasonable and fairly achievable security defense
feature.

So would you suggest that the core JWE standard provide clear guidance
to library authors about when to use compression? Would you also suggest
that we need additional flags on JWT elements that do or do not need to
be compressed so libraries can selectively compress JWT?

We can't fix the past but we can certainly provide more targeted advice
as to how to handle this risk. I'd be glad to help.

- Jim



On 7/29/17 10:22 AM, Yaron Sheffer wrote:
> Hi Jim,
>
> The problem is not the encryption of attacker-controlled data. The
> problem is the interaction between this encryption and compression.
>
> If you don't need compression, you're good. You're mostly OK if you
> can compress only the non-attacker controlled data, however this could
> potentially leak information about ciphertext.
>
> This is all very use-case specific and fragile, so I think a
> reasonable recommendation is:
>
> - Avoid transparent compression in generic JWS/JWE libraries.
> - Only compress data at the application layer, but bear in mind that
> the length of compressed+encrypted data leaks information about
> cleartext.
>
> Thanks,
>     Yaron
>
> On 29/07/17 21:32, Jim Manico wrote:
>> Yaron,
>>
>> As a developer, I can think of many scenarios where the attacker
>> controls some of the plaintext yet I still need encryption services
>> of some kind. What are the proper crypto controls that allow
>> developers to do this safely? I think that's the better question
>> right now.
>>
>> Aloha,
>> --=20
>> Jim Manico
>> @Manicode
>>
>>> On Jul 28, 2017, at 7:57 PM, Yaron Sheffer 
>>> wrote:
>>>
>>> Hi Brian,
>>>
>>> These two attacks on TLS are only examples of the breakage that can
>>> occur when the adversary can control the plaintext to some degree
>>> (even a small piece of the plaintext, e.g. a malleable HTTP cookie
>>> can result in decryption of the whole message). Similar attacks were
>>> demonstrated in IPsec. Can you please add details on why typical use
>>> of JWT would not be susceptible to these attacks?
>>>
>>> Thanks,
>>>     Yaron
>>>
>>>> On critique of JWT I've seen a few times can be paraphrased as "JWT
>>>> supports compressed plaintext so, because of CRIME and BREACH, it is=

>>>> dangerous and stupid."  It's very possible that I am stupid (many
>>>> on this
>>>> list will likely attest to it) but I don't see the applicability of
>>>> those
>>>> kinds of chosen plaintext attacks aimed at recovering sensitive
>>>> data to how
>>>> JWT/JWE are typically used.
>>>>
>>>> I think it would be useful, if during the development of the JWT
>>>> BCP, the
>>>> authors or chairs or WG could somehow engage some experts (CFRG?) to=

>>>> understand if there's any real practical advice that can be given
>>>> about
>>>> using compression with JWE and the risks involved.
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth

--=20
Jim Manico
Manicode Security
https://www.manicode.com



From nobody Mon Jul 31 00:28:03 2017
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 EF863131EA7 for ; Mon, 31 Jul 2017 00:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 AGlmJcC8qIln for ; Mon, 31 Jul 2017 00:27:58 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 023E1131EA9 for ; Mon, 31 Jul 2017 00:27:58 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 111AB7802B2 for ; Mon, 31 Jul 2017 09:27:55 +0200 (CEST)
To: oauth 
From: Denis 
Message-ID: 
Date: Mon, 31 Jul 2017 09:27:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------4F95769C6E072A9EE77B91F6"
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 07:28:01 -0000

This is a multi-part message in MIME format.
--------------4F95769C6E072A9EE77B91F6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This is a follow-up of the OAuth workshop held in Zurich on July 13 th.

At the end of the first day, Sven Hammann made a presentation on the 
following topic:
"A private mode for OpenID Connect"

Slide 14 indicated the motivation of the presentation :

The IdP learns at which Relying Parties (RPs) the user logs in

This does not respect the user's privacy

User's activities over multiple RPs can be tracked

User might not want anyone to know which service they are using

Especially if using the RP might provide sensitive information

I Alcoholics Anonymous

I Medical Forums

Slide 22 indicated:

Privacy and Security Goals

Privacy towards IdP: IdP cannot distinguish between logins to different RPs.

Slides 33 indicated the problem to be solved (hence the title of this 
email):

How can the IdP create an id token for one audience RP without knowing 
for which RP?


In the previous presentation from John Bradley and Torsten Lodderstedt 
(Access token phishing),
made on the same day, the same problem was considered with the final 
slide asking: " What do you think ? "

I believe that it is the time to agree on a solution for this problem.

As I already said on the WG list, the audience parameter does not allow 
to respect privacy.
However, there are cases where both an access token MUST be targeted and 
privacy MUST be supported.

Draft "JSON Web Token Best Current Practices" recently became 
draft-ietf-oauth-jwt-bcp-00.
One major problem (with respect to privacy) is that it mandates the use 
of the audience parameter:

3.8.Use and Validate Audience

If the same issuer can issue JWTs that are intended for use by more than 
one relying party or application,
the JWT MUST contain an "aud"(audience) claim that can be used to 
determine whether the JWT is being
used by an intended party or was substituted by an attacker at an 
unintended party.

With such a wording, as soon as the "aud" claim will be used, privacy 
will be violated since the AS will be able
to act as Big Brother.

Similarly, in a token request the use of the OPTIONAL resource parameter 
is also violating privacy : it indicates
the physical location of the target service or resource where the client 
intends to use the requested security token.
The value of the "resource" parameter MUST be an absolute URI, as 
specified by Section 4.3 of [RFC3986],

During the workshop, it has been proposed to use some signature on some 
data placed /outside/ the access token.

I propose a different approach where both a new parameter placed 
*inside* the access token will be used and
a new structure placed *outside* the access token will be used. This means :

-the addition of a tid (target identifier) parameter *inside* the access 
token, and

-the definition of a new data structure placed *outside* the access 
token (which does not require the computation
  of a digital signature and does not require the demonstration of a 
proof of possession of a key).

Once the basic principles have been explained, let us now explain how 
the mechanism would work.

The client chooses the URI of the target service. For every access token 
request (and for every target service, see later on
the case of multiple targets), it generates a random number (rdn). It 
then computes tid = OWHF (rdn, URI) where the rdn
comes first and where the URI comes after. OWHF is a One Way Hash Function.

The client communicates to the Authorisation Server a method which 
includes two parameters: the OID of the OWHF to be used
(e.g. SHA 256) and the value of tid that it has computed. The AS blindly 
copies and pastes this information into the access token.

The client communicates to the Target Server (outside the access token): 
the method, the OID of the OWHF, the value of the rdn
and the value for the URI.

The Target Server first verifies that the data structure placed 
*outside* the access token matches with the data placed *inside*
the access token: same method and same OID for the OWHF. Then after, it 
verifies that the URI (placed *outside* the access token)
matches with one of the expected values and then using the method, the 
designated OID of the OWHF, the received rdn and
the received URI computes OWHF (rdn, URI). It finally verifies that the 
result of this computation is identical to the tid parameter
contained in the access token. If the verification is successful, the 
access token is accepted by the Target Server, otherwise it is rejected.

Note that an access token MAY include several target identifiers. This 
should be used with care since such an access token might be usable
by one designated Target Server towards another designated Target 
Server. However, there are circumstances where this is a desirable feature.
As indicated earlier, each target identifier (tid) is computed using a 
different rdn.

Comments ?

Denis


--------------4F95769C6E072A9EE77B91F6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    

    

    
This is a follow-up
        of the OAuth workshop held
        in Zurich on July 13 th.

    
At the end of the
        first day, Sven Hammann made a
        presentation on the following topic: 

        "A private mode for OpenID
        Connect"

    
Slide 14 indicated
          the motivation of the presentation :

    
The IdP
        learns at which Relying
        Parties (RPs) the user logs in

    
This does
        not respect the user's
        privacy

    
User's
        activities over multiple RPs
        can be tracked

    
User
        might not want anyone to know
        which service they are using

    
Especially
        if using the RP might
        provide sensitive information

    
I
        Alcoholics Anonymous

    
I Medical
        Forums

    
 Slide 22 indicated:
    

    
Privacy
        and Security Goals

    
Privacy
        towards IdP: IdP cannot
        distinguish between logins to different RPs.

        

      

    
 Slides 33 indicated
        the problem to be solved (hence the title of this email):
    

    
How can
        the IdP create an id token
        for one audience RP without knowing for which RP?

    
 

        In the previous presentation from John Bradley
        and Torsten Lodderstedt (Access token phishing), 

        made on the same day, the same problem was considered
        with the final slide asking: " What do you think ? "
    

    
I believe that it is
        the time to agree on a
        solution for this problem.

    
As I already said on
        the WG list, the audience
        parameter does not allow to respect privacy. 

        However, there are cases
          where both an access token MUST be
        targeted and privacy MUST be supported.

      

    
Draft "JSON Web
        Token Best Current
        Practices" recently became draft-ietf-oauth-jwt-bcp-00. 

        One major problem (with
        respect to privacy) is that it mandates the use of the audience
        parameter:

    
3.8. 
        Use and Validate Audience

    
If the
        same issuer can issue JWTs
        that are intended for use by more than one relying party or
        application, 

        the
        JWT MUST contain an "aud"(audience) claim that can be used to
        determine whether the JWT is being 

        used by an intended party or was substituted
        by an attacker at an unintended party. 

    
With such a wording,
        as soon as the "aud" claim will be used, privacy will be
        violated since the AS will be able 

        to act as Big Brother.

      

    
Similarly, in a
        token request the use of the
        OPTIONAL resource parameter is also violating privacy : it
        indicates 

        the
        physical location of the target service or resource where the
        client intends to
        use the requested security token. 

        The value of the "resource"
        parameter MUST be an absolute URI, as specified by Section 4.3
        of [RFC3986],

    During the workshop,
      it has been proposed to use
      some signature on some data placed outside the access
      token.

    
    
I propose a
        different approach where both a new
        parameter placed inside the access token will be used
        and 

        a new structure
        placed outside the access token will be used. This means
        :

    
-         
        the addition of a tid (target identifier)
        parameter inside the access token, and

    
-         
        the definition of a new data structure
        placed outside the access
        token (which does not require the computation 

         of a digital signature and does
        not require the demonstration of a proof of possession of a
        key).

        

      

    Once the basic
      principles have been explained,
      let us now explain how the mechanism would work.
    
The client chooses
        the URI of the target
        service. For every access
          token request (and for every target service, see later on 

          the case of multiple targets), it generates a random
        number (rdn). It then computes tid = OWHF (rdn, URI) where the
        rdn 

        comes first and where the
        URI comes after. OWHF is a One Way Hash Function.

    
The client
        communicates to the Authorisation
        Server a method which includes two parameters: the OID of the
        OWHF to be used 

        (e.g.
        SHA 256) and the value of tid that it has computed. The AS
        blindly copies and pastes this information into the access
        token.

    
The client
        communicates to the Target Server
        (outside the access token): the method, the OID of the OWHF, the
        value of the
        rdn 

        and the value for the URI. 

    
The Target Server
        first verifies that the data
        structure placed outside the access token matches with
        the data placed inside
        

        the access token: same method and same OID for the OWHF. Then
        after, it verifies
        that the URI (placed outside the access token) 

        matches with one of the
        expected values and then using the method, the designated OID of
        the OWHF, the
        received rdn and 

        the received URI computes OWHF (rdn, URI). It finally verifies
        that the result of this computation is identical to the tid
        parameter 

        contained
        in the access token. If the verification is successful, the
        access token is accepted by the Target Server, otherwise
        it is rejected.

      

    Note that an access token MAY include several target
      identifiers. This
      should be used with care since such an access token might be
      usable 

      by one
      designated Target Server towards another designated Target Server.
      However, there are circumstances where this is a desirable
      feature.

      As indicated earlier, each target identifier (tid) is computed
      using a different rdn.

      

      Comments ?

      

      Denis

      

    
  


--------------4F95769C6E072A9EE77B91F6--


From nobody Mon Jul 31 05:24:42 2017
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 7BB861321BB for ; Mon, 31 Jul 2017 05:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fEOR32bB_Wq for ; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 2CCD81321B4 for ; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id t86so10494185pfe.2 for ; Mon, 31 Jul 2017 05:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6GJ5NxxVLMJieD5FQgDfsFdDr4hobMRPZVv7sGWHQ6Q=; b=IMkBpG0W9LFSjJ5Rtm2dyKIe26xAmD3Y4jxuNODQb6QSPGX9sGo+qUjVyRgmY+UZ2i qbBUUDf6xxqdncGoVtFwMgUzQFbvo0+rGa2sEQxyOlvvybTODwtQEC9lNsoykWk9NJc/ FhRgLGqWxX+gKb1zZaDd54JwA6UbUlO3FZNvk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6GJ5NxxVLMJieD5FQgDfsFdDr4hobMRPZVv7sGWHQ6Q=; b=tr3pMqS7VnvAYW4iYr9iT3KwMHbA+PHh2NtmaoWqIkEGwYzKZ/3WW08t9mTyaw2CCz g5hTuosBgf1It7KjJ9Lg1a+pycCD7gjRSSCaiU5St/nqFsQvIxLq92+8LU8e9HdBoJiz Id2JIrC3wfECgVTYh8WetsGKep7VLJMkkL1lj6Qtzkn2sAOOf8+iCq1FiTmIEW26axEw ijEA7+2bi9m24mCKkIVf864BERSbF6If4luWElx9xIi6gqP+/vIz5qvUe3+T+W33lDiy WEx3yxSAH1Hl4pk8Y1ueAOdCrF3+gFu9I5LW/ebmJx/BCTdAxqA4RO5Lfo1Is73jQYff QTCA==
X-Gm-Message-State: AIVw113huaZhMK/APltMTZdGMSz5mHlVjcA8zZ02iI2kK2RmhVGKyhRf kd48F6PjVnqoiUWgs2rWd78/ulH8LSkMSqC2TJnKoyeVHjIRhBPYwugIjVKfLqLNKJea2bGZl7Y TFwo3
X-Received: by 10.84.212.1 with SMTP id d1mr17155734pli.17.1501503878655; Mon, 31 Jul 2017 05:24:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Mon, 31 Jul 2017 05:24:08 -0700 (PDT)
In-Reply-To: <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
References:  <08197d4f-7512-d877-f99c-fe0ca03d3e19@gmail.com>
From: Brian Campbell 
Date: Mon, 31 Jul 2017 06:24:08 -0600
Message-ID: 
To: Yaron Sheffer 
Cc: oauth 
Content-Type: multipart/alternative; boundary="f403045d1f5e512d0505559c1dd6"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT BCP on Compression in JWE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 12:24:41 -0000

--f403045d1f5e512d0505559c1dd6
Content-Type: text/plain; charset="UTF-8"

Hi Yaron,

I don't actually know, which is why I raised the question in hopes that, if
possible, the BCP could provide some practical and actionable advice. But
I'll try and explain my (maybe naive) thoughts.

As I understand it CRIME/BREACH are adaptive-chosen-plaintext attacks that
work via malicious scrip in the user's browser that makes requests to the
target domain. By observing the size of the compressed data relative to
specifically crafted data in requests and adjusting subsequent requests
based on the observation, it's possible to deduce the value of the session
cookie with a few thousand requests (the few thousand number comes from
"How practical is it?" at http://breachattack.com/).

Typical JWT usage is an id_token, OAuth access token, or session token
where the content of the token is user data and context info. The issuer of
the token controls the claims in the token, which are likely user info
sourced from a directory or similar. Some of that data might be
controllable by the user though the ability to manage pieces of their own
profile data (like address, phone, etc.) or maybe particular aspects of the
session. But the opportunity for an attacker to control the encrypted data
with repeated adaptive values isn't present in the same way that it is in
the TLS HTTP case.

The two situations seemed distinct enough that it wasn't clear to me that a
line should be drawn from CRIME/BREACH to the use of compression in JWE/JWT
being automatically bad.



On Fri, Jul 28, 2017 at 11:57 PM, Yaron Sheffer 
wrote:

> Hi Brian,
>
> These two attacks on TLS are only examples of the breakage that can occur
> when the adversary can control the plaintext to some degree (even a small
> piece of the plaintext, e.g. a malleable HTTP cookie can result in
> decryption of the whole message). Similar attacks were demonstrated in
> IPsec. Can you please add details on why typical use of JWT would not be
> susceptible to these attacks?
>
> Thanks,
>     Yaron
>
>
> On critique of JWT I've seen a few times can be paraphrased as "JWT
>> supports compressed plaintext so, because of CRIME and BREACH, it is
>> dangerous and stupid."  It's very possible that I am stupid (many on this
>> list will likely attest to it) but I don't see the applicability of those
>> kinds of chosen plaintext attacks aimed at recovering sensitive data to
>> how
>> JWT/JWE are typically used.
>>
>> I think it would be useful, if during the development of the JWT BCP, the
>> authors or chairs or WG could somehow engage some experts (CFRG?) to
>> understand if there's any real practical advice that can be given about
>> using compression with JWE and the risks involved.
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

--f403045d1f5e512d0505559c1dd6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Yaron,

I don't actually know, whic=
h is why I raised the question in hopes that, if possible, the BCP could pr=
ovide some practical and actionable advice. But I'll try and explain my=
 (maybe naive) thoughts. 

As I understand it C=
RIME/BREACH are adaptive-chosen-plaintext attacks that work via mali=
cious scrip in the user's browser that makes requests to the target dom=
ain. By observing the size of the compressed data relative to specifically =
crafted data in requests and adjusting subsequent requests based on the obs=
ervation, it's possible to deduce the value of the session cookie with =
a few thousand requests (the few thousand number comes from "How pract=
ical is it?" at http://breachattack.com/).

Typical JWT usage is an id_tok=
en, OAuth access token, or session token where the content of the token is =
user data and context info. The issuer of the token controls the claims in =
the token, which are likely user info sourced from a directory or similar. =
Some of that data might be controllable by the user though the ability to m=
anage pieces of their own profile data (like address, phone, etc.) or maybe=
 particular aspects of the session. But the opportunity for an attacker to =
control the encrypted data with repeated adaptive values isn't present =
in the same way that it is in the TLS HTTP case. 

The two situ=
ations seemed distinct enough that it wasn't clear to me that a line sh=
ould be drawn from CRIME/BREACH to the use of =
compression in JWE/JWT being automatically bad.=C2=A0 



On Fri, Jul 28,=
 2017 at 11:57 PM, Yaron Sheffer <yaronf.ietf@gmail.com>=
 wrote:
Hi Brian,



These two attacks on TLS are only examples of the breakage that can occur w=
hen the adversary can control the plaintext to some degree (even a small pi=
ece of the plaintext, e.g. a malleable HTTP cookie can result in decryption=
 of the whole message). Similar attacks were demonstrated in IPsec. Can you=
 please add details on why typical use of JWT would not be susceptible to t=
hese attacks?



Thanks,

=C2=A0 =C2=A0 Yaron






On critique of JWT I've seen a few times can be paraphrased as "JW=
T

supports compressed plaintext so, because of CRIME and BREACH, it is

dangerous and stupid."=C2=A0 It's very possible that I am stupid (=
many on this

list will likely attest to it) but I don't see the applicability of tho=
se

kinds of chosen plaintext attacks aimed at recovering sensitive data to how=


JWT/JWE are typically used.



I think it would be useful, if during the development of the JWT BCP, the
authors or chairs or WG could somehow engage some experts (CFRG?) to

understand if there's any real practical advice that can be given about=


using compression with JWE and the risks involved.







_______________________________________________

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.
--f403045d1f5e512d0505559c1dd6--


From nobody Mon Jul 31 07:01:20 2017
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 BC39E131D1D for ; Mon, 31 Jul 2017 07:01:17 -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_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 (2048-bit key) header.d=ve7jtb-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 cqclEI5NFi5Q for ; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 247201275F4 for ; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id v29so88047606qtv.3 for ; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=coT4XV656fFDlg/KI7/JYq0DNYWvHf83Jol8wRtVp3w=; b=u9IWxx9P8NNh4NdCFvM4brwdQR3uedhYGYbnsQXlgALqrLcP8xVFApSGaTuerpn6hJ Vc5Q5TU1fB3D0UTHMIyXmBpV0zxyPxRa1ECmiG9oDtxoSotQgKMUzLZupCLuyZ/ZaLRf n+Zt8IttmTanjivUsXozf4sSAPk8UVrRREXg7rn/5wZoHlhf8T4vEflChe0SsLmttWhw ertSVloEpnZVhx9aAgq12toZJyj5boS2f4ob7wc+LQ9emyRMEb5jCv3HjBBUgQd8dlTj BxkIqfMCxxbCKVd41qf1JfMfMitv1Lf1o7Iuj1Y3x0bYQH1sGtTwIW/xakv+HDdePUcf ExEA==
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=coT4XV656fFDlg/KI7/JYq0DNYWvHf83Jol8wRtVp3w=; b=Q3y7PXLFn0bbds1T0X1CO3NOUQ9+RwLfpFxgaE0Dotz7x6x4k8NHm8IwQKQjKv2nL2 lv10wZUqUqvic4kvI4PJy9uDcGULyH7pMwkORo4Jf9o1rGy0YncL6S1DB/0oklZxU9aG IdN+Q4Y50XEnJxPgkX502uG15SX3Hm1C2cCUt0Fustx5GDY4lSWbTSsiAZ4+ubtMnlS2 0msZhh0SrfCLN8Chx5rQN+bf+3fPAFDhXQMNVl9nUQKqJ6PhPtP4y5Zeh91tL9T2/2Et SeA3f3ixe1yqKZhBW4x0qzKwsu7EKceDK2O0YefGcRq1ltmIEWcb/PnDbNe4mLq5lUp3 s72g==
X-Gm-Message-State: AIVw113EiboH+J5ZcVQf47vgwSmg+RTDoGYwowE8UmBy9e6fLPzJgPrs gm/aRXUFZoos2BW5QtIxxg==
X-Received: by 10.200.39.212 with SMTP id x20mr22893095qtx.157.1501509672759;  Mon, 31 Jul 2017 07:01:12 -0700 (PDT)
Received: from johns-mbp.lan ([191.115.5.74]) by smtp.gmail.com with ESMTPSA id f32sm22799313qkf.4.2017.07.31.07.01.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 07:01:11 -0700 (PDT)
From: John Bradley 
Message-Id: <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 10:01:05 -0400
In-Reply-To: 
Cc: oauth 
To: Denis 
References: 
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1135b542c4469b05559d762d"
Archived-At: 
Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 14:01:18 -0000

--001a1135b542c4469b05559d762d
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_2AAB0774-FA7D-4207-BBBD-F312C9558914"


--Apple-Mail=_2AAB0774-FA7D-4207-BBBD-F312C9558914
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think there may be some confusion between two different things that =
can use JWT.

In OAuth a client asks for authorization to access some API set of =
resources.  The AS is supposed to gather consent.
In principal to construct some reasonable dialog for the user to grant =
the consent and to be able to produce the correct format access token it =
is should know what the RS is.  =20

I need to be convinced that this is a real privacy issue.

It is also likely covered with token binding if it were a problem.

The other is Authentication in openID Connect.  This is using id_token =
JWT that are returned to the client.

In principal it may be desirable in some cases to hide the client from =
the AS.   That impacts client_id and redirect registration.  The aud is =
already the client_id so there is no new resource parameter for that.

How to do this securely for Connect is a big question.

For access tokens I would like to see a use case for a completely =
decoupled and anonymous RS that is not just a misuse of OAuth for =
Authentication, before trying to add a feature like this.

John B.


> On Jul 31, 2017, at 3:27 AM, Denis  wrote:
>=20
> This is a follow-up of the OAuth workshop held in Zurich on July 13 =
th.
>=20
> At the end of the first day, Sven Hammann made a presentation on the =
following topic:=20
> "A private mode for OpenID Connect"
>=20
> Slide 14 indicated the motivation of the presentation :
>=20
> The IdP learns at which Relying Parties (RPs) the user logs in
> This does not respect the user's privacy
> User's activities over multiple RPs can be tracked
> User might not want anyone to know which service they are using
> Especially if using the RP might provide sensitive information
> I Alcoholics Anonymous
> I Medical Forums
>  Slide 22 indicated:
>=20
> Privacy and Security Goals
> Privacy towards IdP: IdP cannot distinguish between logins to =
different RPs.
>=20
>  Slides 33 indicated the problem to be solved (hence the title of this =
email):
>=20
> How can the IdP create an id token for one audience RP without knowing =
for which RP?
> =20
> In the previous presentation from John Bradley and Torsten Lodderstedt =
(Access token phishing),=20
> made on the same day, the same problem was considered with the final =
slide asking: " What do you think ? "
>=20
> I believe that it is the time to agree on a solution for this problem.
>=20
> As I already said on the WG list, the audience parameter does not =
allow to respect privacy.=20
> However, there are cases where both an access token MUST be targeted =
and privacy MUST be supported.
>=20
> Draft "JSON Web Token Best Current Practices" recently became =
draft-ietf-oauth-jwt-bcp-00.=20
> One major problem (with respect to privacy) is that it mandates the =
use of the audience parameter:
>=20
> 3.8.  Use and Validate Audience
> If the same issuer can issue JWTs that are intended for use by more =
than one relying party or application,=20
> the JWT MUST contain an "aud"(audience) claim that can be used to =
determine whether the JWT is being=20
> used by an intended party or was substituted by an attacker at an =
unintended party.
> With such a wording, as soon as the "aud" claim will be used, privacy =
will be violated since the AS will be able=20
> to act as Big Brother.
>=20
> Similarly, in a token request the use of the OPTIONAL resource =
parameter is also violating privacy : it indicates=20
> the physical location of the target service or resource where the =
client intends to use the requested security token.=20
> The value of the "resource" parameter MUST be an absolute URI, as =
specified by Section 4.3 of [RFC3986],
>=20
> During the workshop, it has been proposed to use some signature on =
some data placed outside the access token.
> I propose a different approach where both a new parameter placed =
inside the access token will be used and=20
> a new structure placed outside the access token will be used. This =
means :
>=20
> -          the addition of a tid (target identifier) parameter inside =
the access token, and
> -          the definition of a new data structure placed outside the =
access token (which does not require the computation=20
>  of a digital signature and does not require the demonstration of a =
proof of possession of a key).
>=20
> Once the basic principles have been explained, let us now explain how =
the mechanism would work.
> The client chooses the URI of the target service. For every access =
token request (and for every target service, see later on=20
> the case of multiple targets), it generates a random number (rdn). It =
then computes tid =3D OWHF (rdn, URI) where the rdn=20
> comes first and where the URI comes after. OWHF is a One Way Hash =
Function.
>=20
> The client communicates to the Authorisation Server a method which =
includes two parameters: the OID of the OWHF to be used=20
> (e.g. SHA 256) and the value of tid that it has computed. The AS =
blindly copies and pastes this information into the access         =
token.
>=20
> The client communicates to the Target Server (outside the access =
token): the method, the OID of the OWHF, the value of the rdn=20
> and the value for the URI.
>=20
> The Target Server first verifies that the data structure placed =
outside the access token matches with the data placed inside=20
> the access token: same method and same OID for the OWHF. Then after, =
it verifies that the URI (placed outside the access token)=20
> matches with one of the expected values and then using the method, the =
designated OID of the OWHF, the received rdn and=20
> the received URI computes OWHF (rdn, URI). It finally verifies that =
the result of this computation is identical to the tid parameter=20
> contained in the access token. If the verification is successful, the =
access token is accepted by the Target Server, otherwise it is rejected.
>=20
> Note that an access token MAY include several target identifiers. This =
should be used with care since such an access token might be usable=20
> by one designated Target Server towards another designated Target =
Server. However, there are circumstances where this is a desirable =
feature.
> As indicated earlier, each target identifier (tid) is computed using a =
different rdn.
>=20
> Comments ?
>=20
> Denis
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_2AAB0774-FA7D-4207-BBBD-F312C9558914
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I think there may be some confusion between two different =
things that can use JWT.

In OAuth a client asks for authorization to access some API =
set of resources.  The AS is supposed to gather consent.
In principal to construct some reasonable dialog for the user =
to grant the consent and to be able to produce the correct format access =
token it is should know what the RS is.   

I need to be convinced =
that this is a real privacy issue.

It is also likely covered with token =
binding if it were a problem.

The other is Authentication in openID =
Connect.  This is using id_token JWT that are returned to the =
client.

In =
principal it may be desirable in some cases to hide the client from the =
AS.   That impacts client_id and redirect registration.  The =
aud is already the client_id so there is no new resource parameter for =
that.

How to =
do this securely for Connect is a big question.

For access tokens I would like to see a =
use case for a completely decoupled and anonymous RS that is not just a =
misuse of OAuth for Authentication, before trying to add a feature like =
this.

John =
B.


On Jul 31, 2017, at 3:27 AM, Denis <denis.ietf@free.fr> =
wrote:


 =20

    
 =20
  

    
This is =
a follow-up
        of the OAuth workshop held
        in Zurich on July 13 th.
At the =
end of the
        first day, Sven Hammann made a
        presentation on the following topic: 

        "A private mode for OpenID
        Connect"
Slide =
14 indicated
          the motivation of the presentation :
The IdP
        learns at which Relying
        Parties (RPs) the user logs in
This does
        not respect the user's
        privacy
User's
        activities over multiple RPs
        can be tracked
User
        might not want anyone to know
        which service they are using
Especially
        if using the RP might
        provide sensitive information
I
        Alcoholics Anonymous
I Medical
        Forums
 Slide =
22 indicated:
    
Privacy
        and Security Goals
Privacy
        towards IdP: IdP cannot
        distinguish between logins to different RPs.

        

      
 Slides =
33 indicated
        the problem to be solved (hence the title of this email):
    
How can
        the IdP create an id token
        for one audience RP without knowing for which RP?
 

        In the previous presentation from John Bradley
        and Torsten Lodderstedt (Access token phishing), 

        made on the same day, the same problem was considered
        with the final slide asking: " What do you think ? "
    
I =
believe that it is
        the time to agree on a
        solution for this problem.
As I =
already said on
        the WG list, the audience
        parameter does not allow to respect privacy. 

        However, there =
are cases
          where both an access token MUST be
        targeted and privacy MUST be supported.

      
Draft =
"JSON Web
        Token Best Current
        Practices" recently became draft-ietf-oauth-jwt-bcp-00. 

        One major problem (with
        respect to privacy) is that it mandates the use of the audience
        parameter:
3.8. 
        Use and Validate Audience
If the
        same issuer can issue JWTs
        that are intended for use by more than one relying party or
        application, 

        the
        JWT MUST contain an "aud"(audience) claim that can be used to
        determine whether the JWT is being 

        used by an intended party or was substituted
        by an attacker at an unintended party. 
With =
such a wording,
        as soon as the "aud" claim will be used, privacy will be
        violated since the AS will be able 

        to act as Big Brother.

      
Similarly, in a
        token request the use of the
        OPTIONAL resource parameter is also violating privacy : it
        indicates 

        the
        physical location of the target service or resource where the
        client intends to
        use the requested security token. 

        The value of the "resource"
        parameter MUST be an absolute URI, as specified by Section 4.3
        of [RFC3986],

    During =
the workshop,
      it has been proposed to use
      some signature on some data placed outside the =
access
      token.

    
I =
propose a
        different approach where both a new
        parameter placed inside the access token will =
be used
        and 

        a new structure
        placed outside the access token will be used. =
This means
        :
-         
        the addition of a tid (target =
identifier)
        parameter inside the access token, =
and
-         
        the definition of a new data =
structure
        placed outside the access
        token (which does not require the computation 

         of a digital signature and does
        not require the demonstration of a proof of possession of a
        key).

        

      

    Once the =
basic
      principles have been explained,
      let us now explain how the mechanism would work.
The =
client chooses
        the URI of the target
        service. For =
every access
          token request (and for every target service, see later on 

          the case of multiple targets), it generates a random
        number (rdn). It then computes tid =3D OWHF (rdn, URI) where the
        rdn 

        comes first and where the
        URI comes after. OWHF is a One Way Hash Function.
The =
client
        communicates to the Authorisation
        Server a method which includes two parameters: the OID of the
        OWHF to be used 

        (e.g.
        SHA 256) and the value of tid that it has computed. The AS
        blindly copies and pastes this information into the access
        token.
The =
client
        communicates to the Target Server
        (outside the access token): the method, the OID of the OWHF, the
        value of the
        rdn 

        and the value for the URI. 
The =
Target Server
        first verifies that the data
        structure placed outside the access token =
matches with
        the data placed inside
        

        the access token: same method and same OID for the OWHF. Then
        after, it verifies
        that the URI (placed outside the access token) =


        matches with one of the
        expected values and then using the method, the designated OID of
        the OWHF, the
        received rdn and 

        the received URI computes OWHF (rdn, URI). It finally verifies
        that the result of this computation is identical to the tid
        parameter 

        contained
        in the access token. If the verification is successful, the
        access token is accepted by the Target =
Server, otherwise
        it is rejected.

      

    Note that an access token MAY =
include several target
      identifiers. This
      should be used with care since such an access token might be
      usable 

      by one
      designated Target Server towards another designated Target Server.
      However, there are circumstances where this is a desirable
      feature.

      As indicated earlier, each target identifier (tid) is computed
      using a different rdn.

      

      Comments ?

      

      Denis

      

    
  


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

=

--Apple-Mail=_2AAB0774-FA7D-4207-BBBD-F312C9558914--

--001a1135b542c4469b05559d762d
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIBiTspHjZp6fZwEH6Ftb09Wgkv0E
R2YKcJYG7YlBYs5UMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDczMTE0MDExNFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQBgX3wakb1rg/hzSQ8mMYvzMRkuxokD+qPjALpNOSs1yv4N
YGv1pIjw0urd6OUosvpXxY5TKaD0qkIB6ZnHTyvqPnZdoeyu2+E5pV7S9NK/LwnUkbx3Td3GjxnQ
JOZ15xC+FNup/fnqs9sKO1CgDavBYkRsI6gqxzvFmjwkyarieBgraNqQE0A8zAaQ1PqpV37ceCwE
6AM3XtXOQxaNagzD9jjB0RWE4FoSRFsWcJghOBslO0+wSvMyAcmWjkt10mPGYQtsriahDuRWG5hz
GtVmHlvSwkQ6FebDHg9vOcJsqfgPz2tAHF4Z448i8AVuyU+e0gIoUF0DDD9NaiRhAYAV
--001a1135b542c4469b05559d762d--


From nobody Mon Jul 31 11:23:50 2017
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 A6168132765 for ; Mon, 31 Jul 2017 11:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO4S_BgdC9-W for ; Mon, 31 Jul 2017 11:23:45 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 41305132764 for ; Mon, 31 Jul 2017 11:23:45 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id c14so48960333pgn.0 for ; Mon, 31 Jul 2017 11:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tMOk2lAKLYE1VecUSavyTZcu0ffATxoHeNhWJTc0Swc=; b=KSCHhUYTOuYQuVErX7TQFyYRrWVHA9vsNcxEqm5usJGDIgqH2OgPvjqMPVUh+hnIzd v3m25FQ5v2YhuJKE7iSAYU5GMWUt+YKp1ce77guSRAjdtrJDQEMlzjs5NWX1vNzFXo/9 Uv30cIaF/EDNYrBpti3cXE6wP0AJSh2LVWs0U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tMOk2lAKLYE1VecUSavyTZcu0ffATxoHeNhWJTc0Swc=; b=hNPN4qrambKnepGtVUq4ENKyqRiRqvMMkghptvAK0UvYcrfm47kgT51kKQXo3gywIk /8tqagJ91Ds09qz+9kR1zbwsjOwuckbzegj3xGon99NHnTYsyUX/VyvQpqBL6iphykpm DB4BUUvTPwTgkojGu/bTVC+IOHLtwSLWz+EzHxFuj6Ub1HIYWisR+wLRxijyDr1cmAGy 2NG2fsDLCjCelRAkqGFxCC/XMqNVnSeWtprTJj2NqkSrm5DduLLXYCgK4wUMdneTewA6 5w+0YvMdA7oH+esnOCHM5bfY+1y8S23VOGk36ywFlJuBj+Al8oxw76wdMeIwItsJMIOp DUMQ==
X-Gm-Message-State: AIVw113CfQUngTrIHXM3DFFOYr9ITnRH0qW716yg2JD+kRlP1Pn84nIx G9uHYPVzS2wrKj0trPYDvd3lm6lBWbxGFoPgwMbuLM6TjywNjnfJC+oj8vbHNHFsxWXHSwgIXMw mX4kN
X-Received: by 10.99.117.68 with SMTP id f4mr16221371pgn.56.1501525424663; Mon, 31 Jul 2017 11:23:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.87 with HTTP; Mon, 31 Jul 2017 11:23:14 -0700 (PDT)
In-Reply-To: 
References: <1b5f403e-aa93-3cfe-ab39-a471cf864e5d@redhat.com> <46fff444-9107-7a43-1854-88c92aaccd90@redhat.com>    
From: Brian Campbell 
Date: Mon, 31 Jul 2017 12:23:14 -0600
Message-ID: 
To: Bill Burke 
Cc: oauth 
Content-Type: multipart/alternative; boundary="f403045cdcc48f0e670555a12198"
Archived-At: 
Subject: Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 18:23:49 -0000

--f403045cdcc48f0e670555a12198
Content-Type: text/plain; charset="UTF-8"

I don't think that's what I'm saying. Some of these concepts are difficult
to reason about on a mailing list so I apologize for any miss or poor
communication.

When requesting a token, the resource or audience parameter can be used to
indicate the target service where the client intends to use the token that
it is requesting.  Audience is a logical name that says where the client
wants to use the requested token. As a a logical name, the parties involved
do need to know about the name. The resource parameter lets the client
indicate to the AS/STS where it intends to use the issued token by
providing the location, typically as an https URL, in the token exchange
request in the same form that will be used to access that resource (again,
an HTTPS URL). And the resource URL or audience can certinally indicate
something that's external. Those parameters allow the AS/STS to determine
where the token is going to be used (including externally) and produce the
the appropriate token for that target based on configuration and policy.
The text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-
09#section-2.1 about those parameters attempts to describe that in an
intelligible way. Though there's likely always room for improvement.

In general OAuth, the structure, content, style, etc. of access tokens is
not defined. That stuff has to be agreed on between the AS and RS. Although
Token Introspection (RFC 7662)  has
since been defined to give a more standardized option for the RS to query
the AS for status and meta-information about an access token. Even with
introspection, however, an RS effectively can only use access tokens from
one AS because there's nothing standard provided by OAuth to indicate where
the token is from when it's presented to the RS.

For an AS/STS to validate an OAuth access token from a different AS, it is
in a similar situation as an RS. It would need to know the issuer of the
access token - this is, I think, what you've pointed out with suggesting
"subject_issuer" and "actor_issuer". There are maybe different ways that
could be conveyed but some means at least would be needed to indicate the
access token issuer. Then the receiving AS/STS would have to call the
issuing AS's token introspection
endpoint (unless it somehow knew how to validate an access token from that
issuer locally). The complexity of all that is one reason why token
exchange scoped validation (and issuance) of access tokens to only access
tokens from the AS/STS involved in the exchange (and not directly
supporting OAuth access token to OAuth access token cross-domain
exchanges). Also the assertion based authorization grants (RFC 7523
 & 7522
) are largely intended to facilitate
acquiring an access token from an external AS. The thinking (fro me anyway)
was that token exchange would be used with a local STS to obtain an
assertion suitable to be used at an external AS with an assertion grant to
get an access token from that AS. That pattern is something that exists
today. Cross domain could also be achieved with JWTs, for which a token
type value of "urn:ietf:params:oauth:token-type:jwt" is defined.

It's difficult to articulate but that's an attempt to explain how things
are in the draft today and why.

I guess I would have to defer to the larger working group here as to the
question of if token exchange should support exchanges of an OAuth access
token from a different AS for an OAuth access token issued by the AS/STS
doing the exchange?





On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke  wrote:

> So, you're saying the STS has to define a subject_type for each external
> token the client wants to exchange from?  A type that is potentially
> proprietary and different between each and every STS?  On the opposite end,
> when you want to convert to an external token, the STS either has 3 options
> for the client to specify that it wants an external token.  1) a
> proprietary response type, 2) a proprietary resource scheme, 3) a
> proprietary audience scheme.
>
> Don't you think at minimum, the token-exchange spec should define a
> standard way to do OAuth to OAuth cross-domain exchanges?  Right now
> cross-domain exchanges are proprietary and completely up to the target STS
> on how it wants the client to formulate a cross-domain exchange.  I still
> think a "subject_issuer" and "requested_issuer" are the clearest and
> simplest way to enable such an interaction.
>
> On 7/28/17 6:28 PM, Brian Campbell wrote:
>
> The urn:ietf:params:oauth:token-type:access_token type is an "indicator
> that the token is a typical OAuth access token issued by the authorization
> server in question" (see near the end of section 3
> )
> so the issuer is the given STS in that case. Cross domain is possible by
> use of other token types that are not opaque to the STS where the issuer
> can be inferred from the token.
>
> On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke  wrote:
>
>> Thanks for replying,
>>
>> The Introduction of the spec implies that inter-security-domain exchange
>> is supported: "
>>
>>  A Security Token Service (STS) is a service capable of validating and
>>    issuing security tokens, which enables clients to obtain appropriate
>>    access credentials for resources in heterogeneous environments or
>>    across security domains.
>> "
>>
>> But with the current API if you want to exchange an external token to an internal one, there is no way for the STS to identify where the subject_token originated.  Are you saying that an STS cannot accept tokens from an external domain?
>>
>> i.e
>>
>> subject_token: 
>>
>> subject_token_type: urn:ietf:params:oauth:token-type:access-token
>>
>> There's just no way for the STS to know where the subject_token came from
>> because the subject_token can be completely opaque.
>>
>> Now, on the flip side, if you are converting from an internal token to an
>> external one, the audience parameter is just too undefined.  For example,
>> how could you specify that you want a token for an external client of an
>> external issuer.  Client ids are opaque in OAuth, and issuer id isn't even
>> something that is defined at all.  In OpenID connect, an issuer id can be
>> any URL.
>>
>> IMO, adding optional "subject_token_issuer" and "requested_issuer"
>> parameters only clarifies and simplifies the cross-domain case.   If you
>> don't like "issuer" maybe "domain" is a better word?
>>
>> Thanks for replying,
>>
>> Bill
>>
>>
>>
>>
>>
>> On 7/28/17 4:39 PM, Brian Campbell wrote:
>>
>> In general, an instance of an AS/STS can only issue tokens from itself.
>> The audience/resource parameters tell the AS/STS where the requested token
>> will be used, which will influence the audience of the token (and maybe
>> other aspects). But the issuer of the requested token will be the AS/STS
>> that issued it. A cross domain exchange could happen by a client presenting
>> a subject_token from a different domain/issuer (that the AS/STS trusts) and
>> receiving a token issued by that AS/STS suitable for the target domain.
>>
>>
>>
>> On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke  wrote:
>>
>>> Should probably have a "subject_issuer" and "actor_issuer" as well as
>>> the "requested_issuer" too.
>>>
>>> FYI, I'm actually applying this spec to write a token exchange service
>>> to connect various product stacks that have different and often proprietary
>>> token formats and architectures.
>>>
>>>
>>>
>>> On 7/26/17 6:44 PM, Bill Burke wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm looking at Draft 9 of the token-exchange spec.  How would one build
>>>> a request to:
>>>>
>>>> * exchange a token issued by a different domain to a client managed by
>>>> the authorization server.
>>>>
>>>> * exchange a token issued by the authorization server (the STS) for a
>>>> token of a different issuer and different client.  In other words, for a
>>>> token targeted to a specific client in a different authorization server or
>>>> realm or domain or whatever you want to call it.
>>>>
>>>> * exchange a token issued by a different issuer for a token of a
>>>> different issuer and client.
>>>>
>>>> Is the spec missing something like a "requested_issuer" identifier?
>>>> Seems that audience is too opaque of a parameter for the authz server to
>>>> determine how to exchange the token.
>>>>
>>>> Thanks,
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

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

--f403045cdcc48f0e670555a12198
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't think that's what I'm saying=
. Some of these concepts are difficult to reason about on a mailing list so=
 I apologize for any miss or poor communication. 

When request=
ing a token, the resource or audience parameter can be used to indicate the=
 target service where the client intends to use the token that it is reques=
ting.=C2=A0 Audience is a logical name that says where the client wants to =
use the requested token. As a a logical name, the parties involved do need =
to know about the name. The resource parameter lets the client indicate to =
the AS/STS where it intends to use the issued token by providing the locati=
on, typically as an https URL, in the token exchange request in the same fo=
rm that will be used to access that resource (again, an HTTPS URL). And the=
 resource URL or audience can certinally indicate something that's exte=
rnal. Those parameters allow the AS/STS to determine where the token is goi=
ng to be used (including externally) and produce the the appropriate token =
for that target based on configuration and policy.=C2=A0 The text in https://tools.ietf.org/html/draft-ietf-oauth-t=
oken-exchange-09#section-2.1 about those parameters attempts to de=
scribe that in an intelligible way. Though there's likely always room f=
or improvement.

In general OAuth, the structure, content,=
 style, etc. of access tokens is not defined. That stuff has to be agreed o=
n between the AS and RS. Although Token Introspection (RFC 7662) has since been =
defined to give a more standardized option for the RS to query the AS for s=
tatus and meta-information about an access token. Even with introspection, =
however, an RS effectively can only use access tokens from one AS because t=
here's nothing standard provided by OAuth to indicate where the token i=
s from when it's presented to the RS. 

For an AS/STS to validate=
 an OAuth access token from a different AS, it is in a similar situation as=
 an RS. It would need to know the issuer of the access token - this is, I t=
hink, what you've pointed out with suggesting "subject_issuer"=
; and "actor_issuer". There are maybe different ways that could b=
e conveyed but some means at least would be needed to indicate the access t=
oken issuer. Then the receiving AS/STS  would have to call the issuing AS&#=
39;s token introspection <=
br>endpoint (unless it somehow knew how to validate an access token =
from that issuer locally). The complexity of all that is one reason why tok=
en exchange scoped validation (and issuance) of access tokens to only acces=
s tokens from the AS/STS involved in the exchange (and not directly support=
ing OAuth access token to OAuth access token cross-domain exchanges). Also =
the assertion based authorization grants (RFC 7523 & 7522) are largely intended t=
o facilitate acquiring an access token from an external AS. The thinking (f=
ro me anyway) was that token exchange would be used with a local STS to obt=
ain an assertion suitable to be used at an external AS with an assertion gr=
ant to get an access token from that AS. That pattern is something that exi=
sts today. Cross domain could also be achieved with JWTs, for which a token=
 type value of "urn:ietf:params:oauth:token-type:jwt" is defined.=
=C2=A0 

It's difficult to articulate but that's a=
n attempt to explain how things are in the draft today and why.=C2=A0 
<=
/div>

I guess I would have to defer to the larger workin=
g group here as to the question of if token exchange should support exchang=
es of an OAuth access token from a different AS for an OAuth access token i=
ssued by the AS/STS  doing the exchange?




On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke =
<bburke@redhat.co=
m> wrote:

 =20
   =20
 =20
  

    
So, you're saying the STS has to define a subject_type for each
      external token the client wants to exchange from?=C2=A0 A type that i=
s
      potentially proprietary and different between each and every STS?=C2=
=A0
      On the opposite end, when you want to convert to an external
      token, the STS either has 3 options for the client to specify that
      it wants an external token.=C2=A0 1) a proprietary response type, 2) =
a
      proprietary resource scheme, 3) a proprietary audience scheme.

    

    
Don't you think at minimum, the token-exchange spec should defin=
e
      a standard way to do OAuth to OAuth cross-domain exchanges?=C2=A0 Rig=
ht
      now cross-domain exchanges are proprietary and completely up to
      the target STS on how it wants the client to formulate a
      cross-domain exchange.=C2=A0 I still think a "subject_issuer&quo=
t; and
      "requested_issuer" are the clearest and simplest way to ena=
ble
      such an interaction.

    

    
On 7/28/17 6:28 PM,=
 Brian Campbell
      wrote:

    

    

      
The urn:ietf:params:oauth:token-type:access_tok=
en
        type is an "indicator that the token is a typical OAuth access
        token issued by the authorization server in question" (see nea=
r
        the end of section 3) so the
        issuer is the given STS in that case. Cross domain is possible
        by use of other token types that are not opaque to the STS where
        the issuer can be inferred from the token.

      

      


        
On Fri, Jul 28, 2017 at 3:27 PM, Bill
          Burke <bburke@redhat.com>
          wrote:

          

            

              
Thanks for replying,

              

              
The Introduction of the spec implies that
                inter-security-domain exchange is supported: "

              

              
 A Security Token Service (STS) is a servic=
e capable of validating and
   issuing security tokens, which enables clients to obtain appropriate
   access credentials for resources in heterogeneous environments or
   across security domains.
"

But with the current API if you want to exchange an external token to an in=
ternal one, there is no way for the STS to identify where the subject_token=
 originated.  Are you saying that an STS cannot accept tokens from an exter=
nal domain?


              
i.e

              
subject_token: <opaque-string>

              
subject_token_type: urn:ietf:params:oauth:token-type:=
access-token

              
There's just no way for the STS to know where the
                subject_token came from because the subject_token can be
                completely opaque.=C2=A0 

              

              
Now, on the flip side, if you are converting from an
                internal token to an external one, the audience
                parameter is just too undefined.=C2=A0 For example, how cou=
ld
                you specify that you want a token for an external client
                of an external issuer.=C2=A0 Client ids are opaque in OAuth=
,
                and issuer id isn't even something that is defined at
                all.=C2=A0 In OpenID connect, an issuer id can be any URL.<=
br>
              

              
IMO, adding optional "subject_token_issuer" and
                "requested_issuer" parameters only clarifies and
                simplifies the cross-domain case.=C2=A0=C2=A0 If you don=
9;t like
                "issuer" maybe "domain" is a better wor=
d?

              
Thanks for replying,

              
Bill

              

              

                

                  


                  

                  

                  

                  

                  
On
                    7/28/17 4:39 PM, Brian Campbell wrote:

                  

                

              

              

                

                  

                    
In general, an instance of an AS/STS
                      can only issue tokens from itself. The
                      audience/resource parameters tell the AS/STS where
                      the requested token will be used, which will
                      influence the audience of the token (and maybe
                      other aspects). But the issuer of the requested
                      token will be the AS/STS that issued it. A cross
                      domain exchange could happen by a client
                      presenting a subject_token from a different
                      domain/issuer (that the AS/STS trusts) and
                      receiving a token issued by that AS/STS suitable
                      for the target domain. 

                      

                      

                    

                    


                      
On Fri, Jul 28, 2017 at
                        9:06 AM, Bill Burke <bburke@redhat.com>
                        wrote:

                        
Should probably have=
 a
                          "subject_issuer" and "actor_issuer=
" as well as
                          the "requested_issuer" too.

                          

                          FYI, I'm actually applying this spec to write
                          a token exchange service to connect various
                          product stacks that have different and often
                          proprietary token formats and architectures.
                          

                            


                              

                              

                              On 7/26/17 6:44 PM, Bill Burke wrote:

                              
 Hi all,

                                

                                I'm looking at Draft 9 of the
                                token-exchange spec.=C2=A0 How would one
                                build a request to:

                                

                                * exchange a token issued by a different
                                domain to a client managed by the
                                authorization server.

                                

                                * exchange a token issued by the
                                authorization server (the STS) for a
                                token of a different issuer and
                                different client.=C2=A0 In other words, for=
 a
                                token targeted to a specific client in a
                                different authorization server or realm
                                or domain or whatever you want to call
                                it.

                                

                                * exchange a token issued by a different
                                issuer for a token of a different issuer
                                and client.

                                

                                Is the spec missing something like a
                                "requested_issuer" identifier?=C2=
=A0 Seems
                                that audience is too opaque of a
                                parameter for the authz server to
                                determine how to exchange the token.

                                

                                Thanks,

                                

                                Bill

                                

                                

                                

                                ______________________________________=
_________

                                OAuth mailing list

                                OAuth@ietf.org

                                https://www.ietf.org/mail=
man/listinfo/oauth

                              

                              

                              ________________________________________=
_______

                              OAuth mailing list

                              OAuth@ietf.org

                              https://www.ietf.org/mailma=
n/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.=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 attachments from
                      your computer. Thank you. 
              

            

          

        

        

      

      

      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.=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 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.
--f403045cdcc48f0e670555a12198--


From nobody Mon Jul 31 13:18:12 2017
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 D81A4127735 for ; Mon, 31 Jul 2017 13:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 OXtYABkIIGVw for ; Mon, 31 Jul 2017 13:18:09 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 002AC131CB2 for ; Mon, 31 Jul 2017 13:18:08 -0700 (PDT)
X-AuditID: 1209190e-00fff70000000aae-68-597f907f65f1
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F6.8B.02734.F709F795; Mon, 31 Jul 2017 16:18:07 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v6VKI6mG025517; Mon, 31 Jul 2017 16:18:07 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6VKI45D010343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jul 2017 16:18:06 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_F487960C-52DD-462F-A4AF-A26C49260FEA"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 16:18:04 -0400
In-Reply-To: 
Cc: "" 
To: Brian Campbell 
References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nols/oT7S4Ps1HYvV/28yWpx8+4rN gcljyZKfTB53j15kCWCK4rJJSc3JLEst0rdL4Mpomj+NueDXYsaKhwdnszcw/upk7GLk4JAQ MJFon+XSxcjFISSwmElidt9pVghnI6PE879H2SGch0wSG7/fAMpwcrAJqEpMX9PCBGLzClhJ bPrcyAZiMwskSfx+/4IZZCqvgL5E73NGkLCwgKPE594DYDYLUOu1u79ZQGxOgUCJnw0NrCDl zALqEu0nXUDCIkCdt5/OgVrbxSjxauoJsF4JAVmJW7MvMU9g5J+FZNsshG0QYW2JZQtfM0PY mhL7u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlBg c0ry7WCc1OB9iFGAg1GJh7fDtD5SiDWxrLgy9xCjJAeTkiivYg9QiC8pP6UyI7E4I76oNCe1 +BCjBAezkgivfS9QjjclsbIqtSgfJiXNwaIkziuu0RghJJCeWJKanZpakFoEk5Xh4FCS4LXv B2oULEpNT61Iy8wpQUgzcXCCDOcBGj4ZpIa3uCAxtzgzHSJ/itGS49WE/9+YOA79PvGdieMY iBRiycvPS5US570Pco0ASENGaR7cTFCiSnh72PQVozjQi8K8wSBjeYBJDm7qK6CFTEALJUtr QRaWJCKkpBoYDRsexm/MjeF96Nsafb3CMkd+6ZfFZQF5VkkKMjvviBw6syXG/8w1fQMHQX6l AsWipYzSC/icytmFObf+2Oj5qfGImPvFC7t+OxYfmFy/55DtS/FNDxL+Pb3BIFAnoL5mh+ap gMIHKeWr0i4ePnjx0aE1IhufKO1SepymMs9iwpbo/+JpfOHLlViKMxINtZiLihMBNkICSi8D AAA=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jul 2017 20:18:12 -0000

--Apple-Mail=_F487960C-52DD-462F-A4AF-A26C49260FEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Brian, thanks for the update. This is really coming along!

I think the spec would benefit from a more clear separation of the =
client authentication and resource access sections. They=E2=80=99re =
really almost two different but related specs, but there=E2=80=99s =
enough overlap that I think that keeping them in the same document is =
fine with some structural changes applied. I think the content is by and =
large all here, it=E2=80=99s just jumbled together.

To that end, I think there might be three major sections to this =
document (not counting the IANA, security, privacy, and other =
boilerplate bits). A suggested breakdown:

1) Types of mTLS client auth under consideration. This is where the =
definition of public key vs. pki comes in, and where the two =
authentication methods are defined for both registration and discovery. =
Some implementor=E2=80=99s notes on what kinds of things you need to =
store here, including the tls_client_auth_ client metadata extensions. =
For better or worse, 7591 defines OAuth=E2=80=99s client model, and not =
just for dynamic registration.

2) How to use mTLS to authenticate a client. This can be a relatively =
short section that says use (1) in the context of getting an access =
token at the token endpoint. Here is where you point out that you still =
need to send client_id and that the association with the cert=E2=80=99s =
DN and the client_id is done at the AS (there=E2=80=99s existing text =
for this).

3) How to use mTLS to bind an access token. This is a bit more =
complicated because it=E2=80=99s the RS that needs to know the binding =
between the token and the cert=E2=80=99s DN, so that=E2=80=99s where =
you=E2=80=99d define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate =
side effect of spec history means that the =E2=80=9Ccnf=E2=80=9D claim =
for 7662 also gets defined here. This is also where you=E2=80=99d put =
the bits about mutual_tls_sender_constrained_access_tokens for discovery =
and registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D?
=20

A few more comments:

=C2=A72.3 really should break out all registered parameters into their =
own hanging list items (even if you break them up into different =
sections like suggested above)

=C2=A73 seems to say that you can only do mTLS-bound access tokens at an =
RS if you do mTLS authentication at the token endpoint. Is that an =
intentional restriction? To me these two functions seem to be more =
orthogonal than the spec is hinting at. Like, I could use =
private_key_jwt or PKCE or magic to authenticate at the RS but use mTLS =
at the RS, for whatever esoteric reason, like the AS and RS being in =
different security domains. Still, functionally, if the client=E2=80=99s =
registered parameters are enough to trust for token issuance, they =
should be enough to trust for token usage. In other words, have the RS =
depend on tls_client_auth_subject_dn etc. instead of "the same =
certificate that was used for mutual TLS at the token endpoint".=20

Along those lines, =C2=A73 also depends entirely on matching a specific =
certificate hash instead of validating a certificate (and possibly =
it=E2=80=99s chain) and associated DN. This isn=E2=80=99t in parallel =
with the client authentication at the token endpoint, and I=E2=80=99d =
like to see these come together. Should we have a third certificate =
validation method in =C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or =
maybe we should have a separate list for =
=E2=80=9Cresource_server_auth_method=E2=80=9D for the client?

In any event, it still feels like there are two things that are fighting =
for attention in this spec: cert-based authentication of the client at =
the token endpoint, and cert-based PoP of the token at the resource.

 =E2=80=94 Justin

> On Jul 28, 2017, at 2:33 PM, Brian Campbell =
 wrote:
>=20
> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published =
with the changes listed below based on comments and dissuasion in =
Prague.=20
>=20
>    draft-ietf-oauth-mtls-03 =

>=20
>    o  Introduced metadata and client registration parameter to publish
>       and request support for mutual TLS sender constrained access
>       tokens
>    o  Added description of two methods of binding the cert and client,
>       PKI and Public Key.
>    o  Indicated that the "tls_client_auth" authentication method is =
for
>       the PKI method and introduced "pub_key_tls_client_auth" for the
>       Public Key method
>    o  Added implementation considerations, mainly regarding TLS stack
>       configuration and trust chain validation, as well as how to to =
do
>       binding of access tokens to a TLS client certificate for public
>       clients, and considerations around certificate bound access =
tokens
>    o  Added new section to security considerations on cert spoofing
>    o  Add text suggesting that a new cnf member be defined in the
>       future, if hash function(s) other than SHA-256 need to be used =
for
>       certificate thumbprints
>=20
>=20
> ---------- Forwarded message ----------
> From: >
> Date: Fri, Jul 28, 2017 at 12:25 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
> To: i-d-announce@ietf.org 
> Cc: oauth@ietf.org 
>=20
>=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           : Mutual TLS Profile for OAuth 2.0
>         Authors         : Brian Campbell
>                           John Bradley
>                           Nat Sakimura
>                           Torsten Lodderstedt
>         Filename        : draft-ietf-oauth-mtls-03.txt
>         Pages           : 17
>         Date            : 2017-07-28
>=20
> Abstract:
>    This document describes Transport Layer Security (TLS) mutual
>    authentication using X.509 certificates as a mechanism for OAuth
>    client authentication to the token endpoint as well as for
>    certificate bound sender constrained access tokens.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ =

>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 =

> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 =

>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-03 =

>=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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

>=20
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_F487960C-52DD-462F-A4AF-A26C49260FEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Brian, thanks for the update. This is really coming =
along!

I think the =
spec would benefit from a more clear separation of the client =
authentication and resource access sections. They=E2=80=99re really =
almost two different but related specs, but there=E2=80=99s enough =
overlap that I think that keeping them in the same document is fine with =
some structural changes applied. I think the content is by and large all =
here, it=E2=80=99s just jumbled together.

To that end, I think there might be =
three major sections to this document (not counting the IANA, security, =
privacy, and other boilerplate bits). A suggested breakdown:

1) Types of mTLS client =
auth under consideration. This is where the definition of public key vs. =
pki comes in, and where the two authentication methods are defined for =
both registration and discovery. Some implementor=E2=80=99s notes on =
what kinds of things you need to store here, including the =
tls_client_auth_ client metadata extensions. For better or worse, 7591 =
defines OAuth=E2=80=99s client model, and not just for dynamic =
registration.

2)=
 How to use mTLS to authenticate a client. This can be a relatively =
short section that says use (1) in the context of getting an access =
token at the token endpoint. Here is where you point out that you still =
need to send client_id and that the association with the cert=E2=80=99s =
DN and the client_id is done at the AS (there=E2=80=99s existing text =
for this).

3) =
How to use mTLS to bind an access token. This is a bit more complicated =
because it=E2=80=99s the RS that needs to know the binding between the =
token and the cert=E2=80=99s DN, so that=E2=80=99s where you=E2=80=99d =
define the =E2=80=9Ccnf=E2=80=9D stuff. An unfortunate side effect of =
spec history means that the =E2=80=9Ccnf=E2=80=9D claim for 7662 also =
gets defined here. This is also where you=E2=80=99d put the bits about =
mutual_tls_sender_constrained_access_tokens for discovery and =
registration. Should this be a new =E2=80=9Ctoken_type=E2=80=9D?
 

A few more comments:

=C2=A72.3 really should break out all =
registered parameters into their own hanging list items (even if you =
break them up into different sections like suggested above)

=C2=A73 seems to say =
that you can only do mTLS-bound access tokens at an RS if you do mTLS =
authentication at the token endpoint. Is that an intentional =
restriction? To me these two functions seem to be more orthogonal than =
the spec is hinting at. Like, I could use private_key_jwt or PKCE or =
magic to authenticate at the RS but use mTLS at the RS, for whatever =
esoteric reason, like the AS and RS being in different security domains. =
Still, functionally, if the client=E2=80=99s registered parameters are =
enough to trust for token issuance, they should be enough to trust for =
token usage. In other words, have the RS depend on =
tls_client_auth_subject_dn etc. instead of "the same certificate that =
was used for mutual TLS at the token endpoint". 

Along those lines, =C2=A73=
 also depends entirely on matching a specific certificate hash instead =
of validating a certificate (and possibly it=E2=80=99s chain) and =
associated DN. This isn=E2=80=99t in parallel with the client =
authentication at the token endpoint, and I=E2=80=99d like to see these =
come together. Should we have a third certificate validation method in =
=C2=A72 for =E2=80=9Ccertificate hash=E2=80=9D? Or maybe we should have =
a separate list for =E2=80=9Cresource_server_auth_method=E2=80=9D for =
the client?

In =
any event, it still feels like there are two things that are fighting =
for attention in this spec: cert-based authentication of the client at =
the token endpoint, and cert-based PoP of the token at the =
resource.

 =E2=80=94 Justin
On =
Jul 28, 2017, at 2:33 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

A new draft of "Mutual TLS =
Profile for OAuth 2.0" has been published with the changes listed below =
based on comments and dissuasion in Prague. 

   draft-ietf-oauth-mtls-03

   o  Introduced metadata and client registration parameter to publish
      and request support for mutual TLS sender constrained access
      tokens
   o  Added description of two methods of binding the cert and client,
      PKI and Public Key.
   o  Indicated that the "tls_client_auth" authentication method is for
      the PKI method and introduced "pub_key_tls_client_auth" for the
      Public Key method
   o  Added implementation considerations, mainly regarding TLS stack
      configuration and trust chain validation, as well as how to to do
      binding of access tokens to a TLS client certificate for public
      clients, and considerations around certificate bound access tokens
   o  Added new section to security considerations on cert spoofing
   o  Add text suggesting that a new cnf member be defined in the
      future, if hash function(s) other than SHA-256 need to be used for
      certificate thumbprints


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Fri, Jul 28, 2017 at 12:25 PM
Subject: =
[OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
To: i-d-announce@ietf.org
Cc: 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          =
 : Mutual TLS Profile for OAuth 2.0

        Authors         : =
Brian Campbell

                    =
      John Bradley

                    =
      Nat Sakimura

                    =
      Torsten Lodderstedt

        Filename        : =
draft-ietf-oauth-mtls-03.txt

        Pages          =
 : 17

        Date          =
  : 2017-07-28



Abstract:

   This document describes Transport Layer Security (TLS) =
mutual

   authentication using X.509 certificates as a mechanism for =
OAuth

   client authentication to the token endpoint as well as =
for

   certificate bound sender constrained access tokens.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-oauth-mtls-03

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-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/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth







CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged material for the sole use of the intended recipient(s). =
Any review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, =
please notify the sender immediately by e-mail and delete the message =
and any file attachments from your computer. Thank =
you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_F487960C-52DD-462F-A4AF-A26C49260FEA--