From nobody Thu Mar 1 11:44:37 2018 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 12D7212F4C9; Thu, 1 Mar 2018 11:44:35 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151993347494.21702.12630085891654675451@ietfa.amsl.com> Date: Thu, 01 Mar 2018 11:44:35 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-06.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, 01 Mar 2018 19:44: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 : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-06.txt Pages : 30 Date : 2018-03-01 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-06 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 Mar 1 11:52:44 2018 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 3082212F9A5 for ; Thu, 1 Mar 2018 11:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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_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 (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 TIvcrw_e6tuV for ; Thu, 1 Mar 2018 11:52:41 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 E7C8D127010 for ; Thu, 1 Mar 2018 11:52:40 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id u5so9286744itc.1 for ; Thu, 01 Mar 2018 11:52:40 -0800 (PST) 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=SE/NF/0Po9TQMPMMlp30oN5CmTauqrJDDIWsSg6P3mU=; b=a+13hRdKlhSiJWCf+YUm7+6Hi04S501V1lDKtzk2urzA1iEmrn8ZTFGp1qymIBKKTz YxjMyTfa/NQ2MgGc/1dgjsWz51pi5zD47w9otmvN4rhQzQepRdww1Gzmhc51DYlLVhI6 ZwuAdXMlspF7+sgU/vVzN2618fPtGj18zuLfQ= 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=SE/NF/0Po9TQMPMMlp30oN5CmTauqrJDDIWsSg6P3mU=; b=i1twEq2ucHw+64Tlx+rLxUivFmHI2W4J7Pd8P0TcqGFE3IvzyF9CG0vdttXURbcA7J O+6q5B0hrisk1VwZDL/qCT3QCURjiyC2iTRnpZD1c4Kxsk6YCDEpGFeenOLtuCHbYIw7 9Eul8uAaLfzjncTyTuCLD/MEmsDqcz9sJnU9tbIqskEA5uPJHOnRGF9FAEqF4qSC/3Qs C+qB25aKtcqJ5DVv16qLeusDaALaGvsxvhcNtWvdMvnc9GCrXJlgIB9S3ox7f7ZlPbp2 2JMX8Mv8ELV3sd1bv+zYJ2F9xfglEdNmFzLgX0h8ctPyCRe23uQu8r0mkKZj8+8/1kQj mf9g== X-Gm-Message-State: APf1xPBulAMMQ5R0ObnWrmBgqyrI9SqQXKAASb78TQYfXxA7XZpx7Zlo +U6/S674ooomMTgYxFV2SaGZDMIAztEc4XxfyGPa/8BI3FkLHuD7FCSvjNMZpCR9JcH0nzhYufR pnbaM3ZXE2VmyOA== X-Google-Smtp-Source: AG47ELtMYNBuA2Lsh78htmJgnAscBE7gpzaxod1pBSe68aEdiXTLgzv4swbPUbm6+PhgI22YmTFhswHlkLPDhVSZwlM= X-Received: by 10.36.9.84 with SMTP id 81mr3910778itm.89.1519933959775; Thu, 01 Mar 2018 11:52:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.73.200 with HTTP; Thu, 1 Mar 2018 11:52:09 -0800 (PST) In-Reply-To: <151993347494.21702.12630085891654675451@ietfa.amsl.com> References: <151993347494.21702.12630085891654675451@ietfa.amsl.com> From: Brian Campbell Date: Thu, 1 Mar 2018 12:52:09 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a11478b9cc1775605665f3340" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-06.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: Thu, 01 Mar 2018 19:52:43 -0000 --001a11478b9cc1775605665f3340 Content-Type: text/plain; charset="UTF-8" Draft -06 is a fairly minor update to "OAuth 2.0 Token Binding". A summary of the changes are listed below: -06 o Use the boilerplate from RFC 8174. o Update reference for draft-ietf-tokbind-https to -12 and draft- ietf-oauth-discovery to -09. o Minor editorial fixes. ---------- Forwarded message ---------- From: Date: Thu, Mar 1, 2018 at 12:44 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-06.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 : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-06.txt Pages : 30 Date : 2018-03-01 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-06 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.* --001a11478b9cc1775605665f3340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Draft -06 is a fairly minor update to "OAuth 2.0 Toke= n Binding".=C2=A0 A summary of the changes are listed below:

= =C2=A0-06
=C2=A0=C2=A0 o=C2=A0 Use the boilerplate from RFC 8174.
=C2= =A0=C2=A0 o=C2=A0 Update reference for draft-ietf-tokbind-https to -12 and = draft-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ietf-oauth-discovery to -09.
= =C2=A0=C2=A0 o=C2=A0 Minor editorial fixes.


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Da= te: Thu, Mar 1, 2018 at 12:44 PM
Subject: [OAUTH-WG] I-D Action: draft-i= etf-oauth-token-binding-06.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:= 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 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 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-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-03-01

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, Refresh Tokens,= JWT
=C2=A0 =C2=A0Authorization Grants, and JWT Client Authentication.=C2=A0 Thi= s
=C2=A0 =C2=A0cryptographically binds these tokens to a client's Token B= inding key
=C2=A0 =C2=A0pair, possession of which is proven on the TLS connections ove= r which
=C2=A0 =C2=A0the tokens are intended to be used.=C2=A0 This use of Token Bi= nding
=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-06
https://datatracker.ietf.org/= doc/html/draft-ietf-oauth-token-binding-06

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


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. --001a11478b9cc1775605665f3340-- From nobody Thu Mar 1 12:32:24 2018 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 9714612FA89; Thu, 1 Mar 2018 12:32:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151993633860.21568.12268183110765509072.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2018 12:32:18 -0800 Archived-At: Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-discovery-09: (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: Thu, 01 Mar 2018 20:32:19 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-discovery-09: 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-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. From nobody Fri Mar 2 11:01:30 2018 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 C14E61275F4; Fri, 2 Mar 2018 11:01:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8YU5SkD5CpNR; Fri, 2 Mar 2018 11:01:25 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B810C124217; Fri, 2 Mar 2018 11:01:24 -0800 (PST) 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=Hd9nsgytZlbXr86xKO/opfWL5mUlTB2TSN+jlSkhgZA=; b=Pt5CPF8ZWn4Y4lZIapYtOItMrYMoJPjVSGJtqX0tYJya+ag7IkBBImewiB6U7B0ck0OI6UMIgmBVTvKemjNXkP2YBj7ekGf6prIH8RyVz566DSidwuUQEzr5DcxWh6gtde7DKGwSO0m5NtrYC1XDGUIbSsmL3qDgM50zoe2nc0o= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1085.namprd21.prod.outlook.com (52.132.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Fri, 2 Mar 2018 19:01:22 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0567.006; Fri, 2 Mar 2018 19:01:22 +0000 From: Mike Jones To: Alexey Melnikov , The IESG CC: "draft-ietf-oauth-discovery@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT) Thread-Index: AQHTsKKMrlpj/FsDKEO0KKpCHm5EIKO6MjGggAMdgEA= Date: Fri, 2 Mar 2018 19:01:22 +0000 Message-ID: References: <151982902113.5155.16065862366702262286.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-28T19:44:44.4456863Z; 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 x-originating-ip: [2001:4898:80e8:c::42e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1085; 7:HDJNUUzHyvGJlQYO/EH7Trl+ii+aS7CY0btFoYp90KKCzok/xsnyCKyjUMigjvupZAHDqjoFqlM+yumGaHeL0m/n7YFNeKVRKHsRs8GwOKXZ/rTKN6qmET+2P4oDxV8PhqNq3ga9OhQdKO8DxFXhLpT82+dAQ/ohl9BBzG12v5oEa0THJMFHwE5b07drfCqk2bL0yaL5NYQ1qZwTMVQU9OLNhxPZFJuFXuOXyvWMcNxwvX2HGWjhFeMAy3uYpo1r x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4258cf27-4b6a-4ec5-2dbf-08d5806ffdb2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1085; x-ms-traffictypediagnostic: SN6PR2101MB1085: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(3231220)(944501236)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:SN6PR2101MB1085; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1085; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(376002)(396003)(346002)(13464003)(199004)(69234005)(189003)(53936002)(8936002)(86362001)(478600001)(8676002)(86612001)(2950100002)(110136005)(10090500001)(316002)(54906003)(106356001)(81166006)(7736002)(55016002)(81156014)(6246003)(305945005)(229853002)(6306002)(8666007)(3660700001)(33656002)(74316002)(9686003)(6436002)(8990500004)(22452003)(186003)(5250100002)(59450400001)(6506007)(25786009)(53546011)(2906002)(102836004)(6346003)(3280700002)(46003)(345774005)(966005)(97736004)(105586002)(72206003)(14454004)(7696005)(4326008)(99286004)(5660300001)(68736007)(2900100001)(10290500003)(76176011)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1085; H:SN6PR2101MB0943.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: 3Ve20d+6SDtEPPOm3rYbQSNRYyNwS1J67Ov47UlvnmXxJBSan1qZDsclXyW/6ITmim4ruHRqqb5TlmnncHTxLcSnZ2DXo2OpckvJD8Nxlwt33R25Q3k5/Y3Uv3JARjaqaqaVgHv3hRZBEQNg7n21OD5MH5UH5MTiQtvfUCC+3B8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4258cf27-4b6a-4ec5-2dbf-08d5806ffdb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 19:01:22.7510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1085 Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and 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, 02 Mar 2018 19:01:29 -0000 Hi again, Alexey. I'd like to update the document before Monday's submissi= on deadline if you still want the proposed change below. Please let me kno= w one way or the other. Thanks, -- Mike P.S. You'll see that Adam now considers his DISCUSS satisfied, so yours is= the last one remaining. -----Original Message----- From: Mike Jones =20 Sent: Wednesday, February 28, 2018 11:45 AM To: Alexey Melnikov ; The IESG Cc: draft-ietf-oauth-discovery@ietf.org; oauth-chairs@ietf.org; oauth@ietf.= org Subject: RE: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-disco= very-09: (with DISCUSS and COMMENT) Hi Alexey, FYI, the only place in the spec that case-insensitive comparisons exist are= comparisons done by the Designated Experts when considering IANA registrat= ions. If implementations had to do case-insensitive comparisons, then yes,= recommending toLowerCase() would absolutely make sense, but it's human bei= ngs doing the case folding when evaluating proposed registrations. I'll al= so note that this is exactly the same language used in the instructions to = Designated Experts in related registries. For instance, you can see it in = use at these (and many other) locations: https://tools.ietf.org/html/rfc7515#section-9.1.1 https://tools.ietf.org/html/rfc7517#section-8.1.1 https://tools.ietf.org/html/rfc7518#section-7.1.1 https://tools.ietf.org/html/rfc7519#section-10.1.1 https://tools.ietf.org/html/rfc7800#section-6.2.1 Whereas the use of toLowerCase() in https://tools.ietf.org/html/rfc8265#sec= tion-3.3.1 makes perfect sense, because it's a transformation performed by = computer programs. That said, I'll leave it up to you. If you still want me to make a change,= I'd propose making this one: Change "Names may not match other registered= names in a case-insensitive manner unless the Designated Experts state tha= t there is a compelling reason to allow an exception" to "Names may not mat= ch other registered names in a case-insensitive manner (one that would caus= e a match if the Unicode toLowerCase() operation were applied to both strin= gs) unless the Designated Experts state that there is a compelling reason t= o allow an exception". If you still want a change, I'll add this parenthetical remark during the n= ext set of edits. (However, I'll wait for Adam to weigh in on his DISCUSS = before republishing.) Let me know. Thanks again, -- Mike -----Original Message----- From: OAuth On Behalf Of Alexey Melnikov Sent: Wednesday, February 28, 2018 6:44 AM To: The IESG Cc: draft-ietf-oauth-discovery@ietf.org; oauth-chairs@ietf.org; oauth@ietf.= org Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery= -09: (with DISCUSS and COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-discovery-09: 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 introduc= tory 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-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the well written IANA Considerations section. I have one comm= ent on it which should be easy to resolve: The document doesn't seem to say anything about allowed characters in Metad= ata names. When the document talks about "case-insensitive matching", it is= not clear how to implement the matching, because it is not clear whether o= r not Metadata names are ASCII only. If they are not, then you need to bett= er define what "case insensitive" means. You've made a change in section 7.1, which looks good. However there is sti= ll the following text in 7.1.1: Metadata Name: The name requested (e.g., "issuer"). This name is case-sensitive. Names may not match other registered names in a case-insensitive I suggest replacing "in a case-insensitive manner" with something like "if = when applying Unicode toLowerCase() to both, they compare equal". Or maybe keep "case-insensitive" and just add a sentence explaining what it= is. I think you should use toLowerCase(), as it is already recommended in other= IETF specs, like RFC 8265. manner unless the Designated Experts state that there is a compelling reason to allow an exception. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with Adam's DISCUSS. I believe it was addressed in the latest= version. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Mar 4 05:54:34 2018 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 6EFD712D88C; Sun, 4 Mar 2018 05:54:26 -0800 (PST) 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, FREEMAIL_FROM=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=fastmail.fm header.b=0lA2WvXw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a0NyiOc/ 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 krk91SFN4770; Sun, 4 Mar 2018 05:54:23 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2707127419; Sun, 4 Mar 2018 05:54:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CE26120ACE; Sun, 4 Mar 2018 08:54:22 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Sun, 04 Mar 2018 08:54:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=5pLnbzGXOTmd+WDS85zBM0hdKFkR7 KpjwARlLQ53Y6U=; b=0lA2WvXw16odEHQSmmI6Pv1+rtGNXppYcmXPmjcTmuxMb NojsGNzCG0S5EafX+sb68Jd+XFp+GzphoCq0ywo2CP3KZLKfdPCvIoMVCZO9NFfE NUshcvR5WpRWuk2Gn2PrJ0ZyBaEJiUm37MyR6bBb+c/LcclW796edp4/mTe5OUFT raG/xngY+M45RJrc1t87KvNjjFlBf7oc1YnIA/bn8mQxgUoRaqfzq4ePDNkkYo4U Ea94BcwRs+6RdGfOVbCRSRyOUVim26q0Zh0ow8k1JmD+7OXNYNm/kPFK5vLeXYGH BXsX2zF1ntW/G//QmDFhHzNx1kQmrDHhIlSioU42A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5pLnbz GXOTmd+WDS85zBM0hdKFkR7KpjwARlLQ53Y6U=; b=a0NyiOc/ytkIfIPGaNBra3 Rz5MB6dB9cs16kTmkbtJlt7uTVtvdg7ERflXASo5Pbhojif8DwI3GuT0qrFogpQM cEZ/LSpRF2I3/Qeq+ORCGNeFvJNfDpWelI54TexhC5ayfUgBHuDlyDwU86G7nbXN u7ECdF+GJIAXiAWfFB/ABIrnngbMOTkdlQjkst3NzHnSsQxqPzkx0Yu7rZGrq+5p XH/V/AzXftyud8FSYODpfkSe/doXT3hVyQpRJkhzjQ9FOT5ZznYwa74W/maHwFBu lVZMeTs7fyGR8hDcGdEi+3SoOhDj+/oqC6tVf3H+s+jXR5OoQKQ2HZkaK5Vu4DGw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9FAF1621BF; Sun, 4 Mar 2018 08:54:22 -0500 (EST) Message-Id: <1520171662.1990144.1290896928.2DD0F37B@webmail.messagingengine.com> From: Alexey Melnikov To: Mike Jones , The IESG Cc: draft-ietf-oauth-discovery@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 In-Reply-To: References: <151982902113.5155.16065862366702262286.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2018 13:54:22 +0000 Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and 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: Sun, 04 Mar 2018 13:54:27 -0000 Hi Mike, Sorry for the slow response, I forgot (for a moment) about the Monday draft submission deadline. On Wed, Feb 28, 2018, at 7:44 PM, Mike Jones wrote: > Hi Alexey, > > FYI, the only place in the spec that case-insensitive comparisons exist > are comparisons done by the Designated Experts when considering IANA > registrations. If implementations had to do case-insensitive > comparisons, then yes, recommending toLowerCase() would absolutely make > sense, but it's human beings doing the case folding when evaluating > proposed registrations. I was thinking more about this and came to conclusions that this distinction doesn't make a difference in practice. The problem is that Unicode case insensitive comparison means that Designated Experts need to be experts in Unicode or they have to use tools that will do comparision for them. I can show several examples of strings that are case insensitive according to toLowerCase(), but people not knowing corresponding scripts (or having more general idea about Unicode) wouldn't be able to evaluate for case insensitivity just by looking at them. > I'll also note that this is exactly the same > language used in the instructions to Designated Experts in related > registries. For instance, you can see it in use at these (and many > other) locations: > https://tools.ietf.org/html/rfc7515#section-9.1.1 > https://tools.ietf.org/html/rfc7517#section-8.1.1 > https://tools.ietf.org/html/rfc7518#section-7.1.1 > https://tools.ietf.org/html/rfc7519#section-10.1.1 > https://tools.ietf.org/html/rfc7800#section-6.2.1 > > Whereas the use of toLowerCase() in > https://tools.ietf.org/html/rfc8265#section-3.3.1 makes perfect sense, > because it's a transformation performed by computer programs. > > That said, I'll leave it up to you. If you still want me to make a > change, I'd propose making this one: Change "Names may not match other > registered names in a case-insensitive manner unless the Designated > Experts state that there is a compelling reason to allow an exception" > to "Names may not match other registered names in a case-insensitive > manner (one that would cause a match if the Unicode toLowerCase() > operation were applied to both strings) unless the Designated Experts > state that there is a compelling reason to allow an exception". I still prefer the above version. Thank you, Alexey > If you still want a change, I'll add this parenthetical remark during > the next set of edits. (However, I'll wait for Adam to weigh in on his > DISCUSS before republishing.) > > Let me know. > > Thanks again, > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Alexey Melnikov > Sent: Wednesday, February 28, 2018 6:44 AM > To: The IESG > Cc: draft-ietf-oauth-discovery@ietf.org; oauth-chairs@ietf.org; > oauth@ietf.org > Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth- > discovery-09: (with DISCUSS and COMMENT) > > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-discovery-09: 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-discovery/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the well written IANA Considerations section. I have one > comment on it which should be easy to resolve: > > The document doesn't seem to say anything about allowed characters in > Metadata names. When the document talks about "case-insensitive > matching", it is not clear how to implement the matching, because it is > not clear whether or not Metadata names are ASCII only. If they are not, > then you need to better define what "case insensitive" means. > > You've made a change in section 7.1, which looks good. However there is > still the following text in 7.1.1: > > Metadata Name: > The name requested (e.g., "issuer"). This name is case-sensitive. > Names may not match other registered names in a case-insensitive > > I suggest replacing "in a case-insensitive manner" with something like > "if when applying Unicode toLowerCase() to both, they compare equal". > > Or maybe keep "case-insensitive" and just add a sentence explaining what > it is. > I think you should use toLowerCase(), as it is already recommended in > other IETF specs, like RFC 8265. > > manner unless the Designated Experts state that there is a > compelling reason to allow an exception. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am agreeing with Adam's DISCUSS. I believe it was addressed in the > latest version. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Mar 4 10:26:33 2018 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 6F35A1242F7; Sun, 4 Mar 2018 10:26:26 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152018798641.12021.1910472021451791357@ietfa.amsl.com> Date: Sun, 04 Mar 2018 10:26:26 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-10.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: Sun, 04 Mar 2018 18:26:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Authorization Server Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-10.txt Pages : 25 Date : 2018-03-04 Abstract: This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-discovery-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 4 10:38:30 2018 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 E8CC6126CBF for ; Sun, 4 Mar 2018 10:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dRo_1fKYeqx3 for ; Sun, 4 Mar 2018 10:38:27 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D1A126B6D for ; Sun, 4 Mar 2018 10:38:18 -0800 (PST) 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=Wc2T++ETCFnDwWU3kPMRhrUgOwAad5flMRw5u3SspFc=; b=cTLG8wPJY1N85dzHjLLMsM8bvZzLbP6LQn+/W/uihH4+u2GBUQ8jdTXsLVxSDVmUUJkfkeRj+5FDYRzIGMvhNnen8bm7quGCkOOKksyLqBMQRZqWupmEG/jwstX/dppGK6F9CSSmzN0VRsmxRmMIE1kMmGQX4H0Cct7sEyDq/oY= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1039.namprd21.prod.outlook.com (52.132.115.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Sun, 4 Mar 2018 18:38:12 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0588.001; Sun, 4 Mar 2018 18:38:12 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Authorization Server Metadata spec addressing additional IESG feedback Thread-Index: AdOz5oObRNGH0HUcQbmGvI4i02p5JA== Date: Sun, 4 Mar 2018 18:38:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.88.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1039; 7:t4gD8AjLosx+hV405V1KFTkzZMhvSk5ctA3ksRBYKBqJSNbbMo7C/mIf8IDu3LcvxOK55F+A4x5GC6nKWVM4O7WW97Gog73Uuum51xeug1874WIM2VX0dqZmEqHvAaGrIAgSwqjt3b2+DT96HnOsdUTr1DZmJyuhucvKHuw2ytyMXrN0YmVO2UKNX4oXg8mbgVY3iHAO//NE7xAGYLAxql6kG1zXDVQ/0J6xT9vFUJ9b9iUVmWAc1uDX3eZccrYo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dda8f58c-5188-41f3-5df0-08d581ff1602 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:SN6PR2101MB1039; x-ms-traffictypediagnostic: SN6PR2101MB1039: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB1039; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1039; x-forefront-prvs: 060166847D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(39860400002)(39380400002)(366004)(209900001)(199004)(189003)(2351001)(26005)(25786009)(53376002)(3280700002)(10290500003)(1730700003)(81156014)(5660300001)(5630700001)(8676002)(54896002)(6306002)(236005)(6916009)(9686003)(59450400001)(7696005)(6436002)(97736004)(186003)(7736002)(72206003)(55016002)(106356001)(6506007)(86362001)(606006)(5640700003)(102836004)(74316002)(966005)(66066001)(3846002)(790700001)(6116002)(14454004)(105586002)(99286004)(478600001)(3660700001)(2906002)(33656002)(10090500001)(86612001)(5250100002)(81166006)(2900100001)(8936002)(68736007)(8990500004)(316002)(2501003)(53936002)(22452003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1039; H:SN6PR2101MB0943.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) x-microsoft-antispam-message-info: bam66eoXHHoO28vpd8vidqigD0MVkk50vtV5QEeqImiG6eZmloV5rS36A669PvTTdj+++abqt1SuWGlPxl7B5xHUuqmbDYqCM3MWiyRZfniu+FZkQejByWRfDMG/A1fdQlhyQFcZD8OekGuHoAOkZzwzl6DFc2DW0AEuB1QY2Yp+wFWZ8wT34CgyVd67+d302ei2fRYrtrDpOAI8yqalviq8h/HmiUlqsoV51r8YEGPe0t9U4zfjajcP0Qppkogl9fP0pnc3/RBHKotBSgLruqsVN75ROv8+wr541xIif6EfpEWkC59VooZnYwni+5yRkAnpKY6wG7rwhpx9gGHvww== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB09431420E8CC4686129DF2BEF5DB0SN6PR2101MB0943_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dda8f58c-5188-41f3-5df0-08d581ff1602 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2018 18:38:12.6959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1039 Archived-At: Subject: [OAUTH-WG] OAuth Authorization Server Metadata spec addressing additional IESG 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: Sun, 04 Mar 2018 18:38:29 -0000 --_000_SN6PR2101MB09431420E8CC4686129DF2BEF5DB0SN6PR2101MB0943_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Authorization Server Metadata specification has been updated to a= ddress additional IESG feedback. The only change was to clarify the meanin= g of "case-insensitive", as suggested by Alexey Melnikov. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-discovery-10 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-10.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1786 and = as @selfissued. --_000_SN6PR2101MB09431420E8CC4686129DF2BEF5DB0SN6PR2101MB0943_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Authorization Server Metadata specificatio= n has been updated to address additional IESG feedback.  The only chan= ge was to clarify the meaning of "case-insensitive", as suggested= by Alexey Melnikov.

 

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=3D1786 and as @selfissued.

 

--_000_SN6PR2101MB09431420E8CC4686129DF2BEF5DB0SN6PR2101MB0943_-- From nobody Sun Mar 4 10:40:58 2018 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 430EF124BAC; Sun, 4 Mar 2018 10:40:50 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 22BIIGPYQmdm; Sun, 4 Mar 2018 10:40:47 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792631242F7; Sun, 4 Mar 2018 10:40:47 -0800 (PST) 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=OQzxct5xH8OVNAraA+RwWEXdJPM5mfyYCjWnPmn9tOc=; b=My5uWI6I1zstYyEItSph0im7wLfeg3RrIPhr8sTgeZrswYiSfh1fim8U6mGlhCr22cuSIGtb5YYLmGixaBaom9M9xuCH6hKcdfvjqW6k1zRCrE2FKhH8TnzZ6vc5vzlcwjfU2VRqBi/YwoR7idVFK1DUXA/9GIiCzHGSXgbg1rU= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1039.namprd21.prod.outlook.com (52.132.115.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Sun, 4 Mar 2018 18:40:46 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0588.001; Sun, 4 Mar 2018 18:40:46 +0000 From: Mike Jones To: Alexey Melnikov , The IESG CC: "draft-ietf-oauth-discovery@ietf.org" , "oauth-chairs@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and COMMENT) Thread-Index: AQHTsKKMrlpj/FsDKEO0KKpCHm5EIKO6MjGggAXtIgCAAE+F8A== Date: Sun, 4 Mar 2018 18:40:45 +0000 Message-ID: References: <151982902113.5155.16065862366702262286.idtracker@ietfa.amsl.com> <1520171662.1990144.1290896928.2DD0F37B@webmail.messagingengine.com> In-Reply-To: <1520171662.1990144.1290896928.2DD0F37B@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.88.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1039; 7:sQWdp3TJglTZN9hnLe3UCvA16G6cph26Rubc7QMzvuUzDrAWJlLMOflwscmwhhu4ByXyc20T2w18sBo0nMOhEG6o1Gq0dr9i2f4jKX+OuDtR5kNJjdAqXus3oVcRc80lqsTEGsDGc7Z5e9RbhrSOXL3ELfU+qUa16dOZXanDSHl0RCXkS9puQx2RMpK5+n8ADovzoVgFeyBeSnKoufvCzj9b2xNxIEN5Lz7lYVU61lLaY7oPThF7yBNQFIUfw/oG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2b5d4e50-9c18-40b3-a5ad-08d581ff7148 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:SN6PR2101MB1039; x-ms-traffictypediagnostic: SN6PR2101MB1039: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB1039; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1039; x-forefront-prvs: 060166847D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(39860400002)(39380400002)(366004)(13464003)(199004)(189003)(69234005)(26005)(25786009)(3280700002)(229853002)(4326008)(10290500003)(6246003)(81156014)(5660300001)(8676002)(6306002)(2950100002)(9686003)(7696005)(6436002)(305945005)(97736004)(54906003)(186003)(7736002)(72206003)(55016002)(53546011)(106356001)(110136005)(6506007)(86362001)(102836004)(74316002)(345774005)(966005)(76176011)(8666007)(66066001)(3846002)(6116002)(14454004)(105586002)(99286004)(478600001)(3660700001)(2906002)(33656002)(10090500001)(86612001)(5250100002)(81166006)(2900100001)(8936002)(68736007)(8990500004)(316002)(53936002)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1039; H:SN6PR2101MB0943.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) x-microsoft-antispam-message-info: dwZBDNnaUVA3VEs2Ijvzk07B88BQt6lvAZPUoWAcysQ49OPtHTsVHzTikKu+HB6LjG70673U4F7JxJoDaA6PdwwsTm0BDpsoh69GofmtHtcS1d3n/DkQsgSXE46Y8oT30mJt8nNswOfQ2WKdTjxFbhFLvkoILNGwrGeOibgra7ah8XmFmTM61JfViBVeIZXvZagIheIWQwDDbXnOILkFglezQV4XkyBFmc7L8cY2qBnlG/UIR7JVg0eC8IF4xfnGQt5VbMjrgsH//fqA5whK2Ci34z4Y79z2Ee8LPuI6lIEHCxkvBrp+0gDJVlNdzdNvW9Oyw3/mTLuKtXhb/KjLIQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b5d4e50-9c18-40b3-a5ad-08d581ff7148 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2018 18:40:45.9042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1039 Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-discovery-09: (with DISCUSS and 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: Sun, 04 Mar 2018 18:40:51 -0000 VGhhbmtzIGZvciBnZXR0aW5nIGJhY2sgdG8gbWUsIEFsZXhleS4gIERyYWZ0IC0xMCwgaW4gdGhl IHRoaXJkIHNlbnRlbmNlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLWRpc2NvdmVyeS0xMCNzZWN0aW9uLTcuMS4xLCBjb250YWlucyB0aGUgcmVxdWVzdGVk IGNsYXJpZmljYXRpb24uICBIb3BlZnVsbHkgdGhpcyBzYXRpc2ZpZXMgdGhlIGludGVudCBvZiB5 b3VyIERJU0NVU1MuDQoNClNlZSB5b3UgaW4gTG9uZG9uIQ0KDQoJCQkJLS0gTWlrZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGV5IE1lbG5pa292IDxhYW1lbG5pa292 QGZhc3RtYWlsLmZtPiANClNlbnQ6IFN1bmRheSwgTWFyY2ggNCwgMjAxOCA1OjU0IEFNDQpUbzog TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgVGhlIElFU0cgPGllc2dA aWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnlAaWV0Zi5vcmc7IG9hdXRo LWNoYWlyc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEFsZXhleSBNZWxuaWtvdidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnkt MDk6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkhpIE1pa2UsDQpTb3JyeSBmb3IgdGhl IHNsb3cgcmVzcG9uc2UsIEkgZm9yZ290IChmb3IgYSBtb21lbnQpIGFib3V0IHRoZSBNb25kYXkg ZHJhZnQgc3VibWlzc2lvbiBkZWFkbGluZS4NCg0KT24gV2VkLCBGZWIgMjgsIDIwMTgsIGF0IDc6 NDQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEhpIEFsZXhleSwNCj4gDQo+IEZZSSwgdGhlIG9u bHkgcGxhY2UgaW4gdGhlIHNwZWMgdGhhdCBjYXNlLWluc2Vuc2l0aXZlIGNvbXBhcmlzb25zIA0K PiBleGlzdCBhcmUgY29tcGFyaXNvbnMgZG9uZSBieSB0aGUgRGVzaWduYXRlZCBFeHBlcnRzIHdo ZW4gY29uc2lkZXJpbmcgDQo+IElBTkEgcmVnaXN0cmF0aW9ucy4gIElmIGltcGxlbWVudGF0aW9u cyBoYWQgdG8gZG8gY2FzZS1pbnNlbnNpdGl2ZSANCj4gY29tcGFyaXNvbnMsIHRoZW4geWVzLCBy ZWNvbW1lbmRpbmcgdG9Mb3dlckNhc2UoKSB3b3VsZCBhYnNvbHV0ZWx5IA0KPiBtYWtlIHNlbnNl LCBidXQgaXQncyBodW1hbiBiZWluZ3MgZG9pbmcgdGhlIGNhc2UgZm9sZGluZyB3aGVuIA0KPiBl dmFsdWF0aW5nIHByb3Bvc2VkIHJlZ2lzdHJhdGlvbnMuDQoNCkkgd2FzIHRoaW5raW5nIG1vcmUg YWJvdXQgdGhpcyBhbmQgY2FtZSB0byBjb25jbHVzaW9ucyB0aGF0IHRoaXMgZGlzdGluY3Rpb24g ZG9lc24ndCBtYWtlIGEgZGlmZmVyZW5jZSBpbiBwcmFjdGljZS4gVGhlIHByb2JsZW0gaXMgdGhh dCBVbmljb2RlIGNhc2UgaW5zZW5zaXRpdmUgY29tcGFyaXNvbiBtZWFucyB0aGF0IERlc2lnbmF0 ZWQgRXhwZXJ0cyBuZWVkIHRvIGJlIGV4cGVydHMgaW4gVW5pY29kZSBvciB0aGV5IGhhdmUgdG8g dXNlIHRvb2xzIHRoYXQgd2lsbCBkbyBjb21wYXJpc2lvbiBmb3IgdGhlbS4gSSBjYW4gc2hvdyBz ZXZlcmFsIGV4YW1wbGVzIG9mIHN0cmluZ3MgdGhhdCBhcmUgY2FzZSBpbnNlbnNpdGl2ZSBhY2Nv cmRpbmcgdG8gdG9Mb3dlckNhc2UoKSwgYnV0IHBlb3BsZSBub3Qga25vd2luZyBjb3JyZXNwb25k aW5nIHNjcmlwdHMgKG9yIGhhdmluZyBtb3JlIGdlbmVyYWwgaWRlYSBhYm91dCBVbmljb2RlKSB3 b3VsZG4ndCBiZSBhYmxlIHRvIGV2YWx1YXRlIGZvciBjYXNlIGluc2Vuc2l0aXZpdHkganVzdCBi eSBsb29raW5nIGF0IHRoZW0uDQoNCj4gIEknbGwgYWxzbyBub3RlIHRoYXQgdGhpcyBpcyBleGFj dGx5IHRoZSBzYW1lIGxhbmd1YWdlIHVzZWQgaW4gdGhlIA0KPiBpbnN0cnVjdGlvbnMgdG8gRGVz aWduYXRlZCBFeHBlcnRzIGluIHJlbGF0ZWQgcmVnaXN0cmllcy4gIEZvciANCj4gaW5zdGFuY2Us IHlvdSBjYW4gc2VlIGl0IGluIHVzZSBhdCB0aGVzZSAoYW5kIG1hbnkNCj4gb3RoZXIpIGxvY2F0 aW9uczoNCj4gCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE1I3NlY3Rpb24tOS4x LjENCj4gCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE3I3NlY3Rpb24tOC4xLjEN Cj4gCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE4I3NlY3Rpb24tNy4xLjENCj4g CWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tMTAuMS4xDQo+IAlo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzgwMCNzZWN0aW9uLTYuMi4xDQo+IA0KPiBX aGVyZWFzIHRoZSB1c2Ugb2YgdG9Mb3dlckNhc2UoKSBpbg0KPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODI2NSNzZWN0aW9uLTMuMy4xIG1ha2VzIHBlcmZlY3Qgc2Vuc2UsIA0KPiBi ZWNhdXNlIGl0J3MgYSB0cmFuc2Zvcm1hdGlvbiBwZXJmb3JtZWQgYnkgY29tcHV0ZXIgcHJvZ3Jh bXMuDQo+IA0KPiBUaGF0IHNhaWQsIEknbGwgbGVhdmUgaXQgdXAgdG8geW91LiAgSWYgeW91IHN0 aWxsIHdhbnQgbWUgdG8gbWFrZSBhIA0KPiBjaGFuZ2UsIEknZCBwcm9wb3NlIG1ha2luZyB0aGlz IG9uZTogIENoYW5nZSAiTmFtZXMgbWF5IG5vdCBtYXRjaCANCj4gb3RoZXIgcmVnaXN0ZXJlZCBu YW1lcyBpbiBhIGNhc2UtaW5zZW5zaXRpdmUgbWFubmVyIHVubGVzcyB0aGUgDQo+IERlc2lnbmF0 ZWQgRXhwZXJ0cyBzdGF0ZSB0aGF0IHRoZXJlIGlzIGEgY29tcGVsbGluZyByZWFzb24gdG8gYWxs b3cgYW4gZXhjZXB0aW9uIg0KPiB0byAiTmFtZXMgbWF5IG5vdCBtYXRjaCBvdGhlciByZWdpc3Rl cmVkIG5hbWVzIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSANCj4gbWFubmVyIChvbmUgdGhhdCB3b3Vs ZCBjYXVzZSBhIG1hdGNoIGlmIHRoZSBVbmljb2RlIHRvTG93ZXJDYXNlKCkgDQo+IG9wZXJhdGlv biB3ZXJlIGFwcGxpZWQgdG8gYm90aCBzdHJpbmdzKSB1bmxlc3MgdGhlIERlc2lnbmF0ZWQgRXhw ZXJ0cyANCj4gc3RhdGUgdGhhdCB0aGVyZSBpcyBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGFsbG93 IGFuIGV4Y2VwdGlvbiIuDQoNCkkgc3RpbGwgcHJlZmVyIHRoZSBhYm92ZSB2ZXJzaW9uLg0KDQpU aGFuayB5b3UsDQpBbGV4ZXkNCg0KPiBJZiB5b3Ugc3RpbGwgd2FudCBhIGNoYW5nZSwgSSdsbCBh ZGQgdGhpcyBwYXJlbnRoZXRpY2FsIHJlbWFyayBkdXJpbmcgDQo+IHRoZSBuZXh0IHNldCBvZiBl ZGl0cy4gIChIb3dldmVyLCBJJ2xsIHdhaXQgZm9yIEFkYW0gdG8gd2VpZ2ggaW4gb24gDQo+IGhp cyBESVNDVVNTIGJlZm9yZSByZXB1Ymxpc2hpbmcuKQ0KPiANCj4gTGV0IG1lIGtub3cuDQo+IA0K PiAJCQkJVGhhbmtzIGFnYWluLA0KPiAJCQkJLS0gTWlrZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBBbGV4ZXkgTWVsbmlrb3YNCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOCwg MjAxOCA2OjQ0IEFNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0 LWlldGYtb2F1dGgtZGlzY292ZXJ5QGlldGYub3JnOyBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IA0K PiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIEFsZXhleSBNZWxuaWtvdidz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC0NCj4gZGlzY292ZXJ5LTA5OiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gQWxleGV5IE1lbG5pa292IGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVy eS0wOTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgDQo+IHRoaXMg aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVy IHRvIA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5Lw0KPiANCj4gDQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRo YW5rIHlvdSBmb3IgdGhlIHdlbGwgd3JpdHRlbiBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24u IEkgaGF2ZSBvbmUgDQo+IGNvbW1lbnQgb24gaXQgd2hpY2ggc2hvdWxkIGJlIGVhc3kgdG8gcmVz b2x2ZToNCj4gDQo+IFRoZSBkb2N1bWVudCBkb2Vzbid0IHNlZW0gdG8gc2F5IGFueXRoaW5nIGFi b3V0IGFsbG93ZWQgY2hhcmFjdGVycyBpbiANCj4gTWV0YWRhdGEgbmFtZXMuIFdoZW4gdGhlIGRv Y3VtZW50IHRhbGtzIGFib3V0ICJjYXNlLWluc2Vuc2l0aXZlIA0KPiBtYXRjaGluZyIsIGl0IGlz IG5vdCBjbGVhciBob3cgdG8gaW1wbGVtZW50IHRoZSBtYXRjaGluZywgYmVjYXVzZSBpdCANCj4g aXMgbm90IGNsZWFyIHdoZXRoZXIgb3Igbm90IE1ldGFkYXRhIG5hbWVzIGFyZSBBU0NJSSBvbmx5 LiBJZiB0aGV5IGFyZSANCj4gbm90LCB0aGVuIHlvdSBuZWVkIHRvIGJldHRlciBkZWZpbmUgd2hh dCAiY2FzZSBpbnNlbnNpdGl2ZSIgbWVhbnMuDQo+IA0KPiBZb3UndmUgbWFkZSBhIGNoYW5nZSBp biBzZWN0aW9uIDcuMSwgd2hpY2ggbG9va3MgZ29vZC4gSG93ZXZlciB0aGVyZSANCj4gaXMgc3Rp bGwgdGhlIGZvbGxvd2luZyB0ZXh0IGluIDcuMS4xOg0KPiANCj4gICAgTWV0YWRhdGEgTmFtZToN Cj4gICAgICAgVGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiaXNzdWVyIikuICBUaGlzIG5hbWUg aXMgY2FzZS1zZW5zaXRpdmUuDQo+ICAgICAgIE5hbWVzIG1heSBub3QgbWF0Y2ggb3RoZXIgcmVn aXN0ZXJlZCBuYW1lcyBpbiBhIGNhc2UtaW5zZW5zaXRpdmUNCj4gDQo+IEkgc3VnZ2VzdCByZXBs YWNpbmcgImluIGEgY2FzZS1pbnNlbnNpdGl2ZSBtYW5uZXIiIHdpdGggc29tZXRoaW5nIGxpa2Ug DQo+ICJpZiB3aGVuIGFwcGx5aW5nIFVuaWNvZGUgdG9Mb3dlckNhc2UoKSB0byBib3RoLCB0aGV5 IGNvbXBhcmUgZXF1YWwiLg0KPiANCj4gT3IgbWF5YmUga2VlcCAiY2FzZS1pbnNlbnNpdGl2ZSIg YW5kIGp1c3QgYWRkIGEgc2VudGVuY2UgZXhwbGFpbmluZyANCj4gd2hhdCBpdCBpcy4NCj4gSSB0 aGluayB5b3Ugc2hvdWxkIHVzZSB0b0xvd2VyQ2FzZSgpLCBhcyBpdCBpcyBhbHJlYWR5IHJlY29t bWVuZGVkIGluIA0KPiBvdGhlciBJRVRGIHNwZWNzLCBsaWtlIFJGQyA4MjY1Lg0KPiANCj4gICAg ICAgbWFubmVyIHVubGVzcyB0aGUgRGVzaWduYXRlZCBFeHBlcnRzIHN0YXRlIHRoYXQgdGhlcmUg aXMgYQ0KPiAgICAgICBjb21wZWxsaW5nIHJlYXNvbiB0byBhbGxvdyBhbiBleGNlcHRpb24uDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBJIGFtIGFncmVlaW5nIHdpdGggQWRhbSdzIERJU0NVU1MuIEkgYmVsaWV2ZSBpdCB3YXMgYWRk cmVzc2VkIGluIHRoZSANCj4gbGF0ZXN0IHZlcnNpb24uDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg== From nobody Mon Mar 5 09:17:56 2018 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 8AC1C12D94F; Mon, 5 Mar 2018 09:17:48 -0800 (PST) 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-discovery@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152027026855.14620.214309010373734912.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2018 09:17:48 -0800 Archived-At: Subject: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-discovery-10: (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: Mon, 05 Mar 2018 17:17:49 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-discovery-10: 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-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. From nobody Mon Mar 5 10:30:39 2018 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 BD30812DA42 for ; Mon, 5 Mar 2018 10:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 zthwAMGqochU for ; Mon, 5 Mar 2018 10:30:35 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 5C68712DA2B for ; Mon, 5 Mar 2018 10:30:35 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id s1so10539251vke.5 for ; Mon, 05 Mar 2018 10:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yIJcBWL4CbFxa6srVm3jn0aJ23g2PqFNRAEbb64vjE4=; b=jyVN+N0WhXFZdZXIi1MS++tBC3GCmSq97EuN0jlEo2AYjf14bPW19wiAqmkrVgpPY+ 2EfQrBC7gcCFratwL357gSnaWKRmh5+ByoAl0wOH6/iFicLzp+PB5z4aJlCYQesw27oA Ai7w+asIbik1L5wIcaXy8/9LUu79S284FWvOc5ctda4Q7eqv678BGrlzim3Z/pTxtk8D SnfPM7tGXQK5PMqtly2ObQrGeuRbqv1buNRUXM1lMDlT6M7k1JPXvY6mmuUDa5zyW8at kQwDzLGwQzf99Lxww0/kxGPXWfqKcTB2dFXf0XFT66cPwyvYELg6xtcb2PnCAl7UPR27 TRaA== 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=yIJcBWL4CbFxa6srVm3jn0aJ23g2PqFNRAEbb64vjE4=; b=T6JBNyhG1CGQ6nv+M9n6cBPbP4q1i3w/kLcMfieawCDAtAheN3h4LyJU1kF97chr3s UVpKWejFth+ssKdj1Z4HNJQWsnTbmYvcO/8QyCldO2cVw6nvT23/vgsxT0D1KJzu1go8 Sr34En6E8xyinMqd8zhawWg7P7wM779IrW/RlDpH9IFzvycYuruiuH8f8agW/jKqhLIF Qo9YpffoLn3a3znidk6jZNFpiE+Rvvy/Zg79wGMPTUGQUM/TgicVSbRdOYZGguIIs0V3 FrnTB47Ol1u4tw5eASneQSv+8ckgCGfFY7L3Ymf7jC927eL/FHr23ftZbmpcTrUBooIy PrQg== X-Gm-Message-State: APf1xPCseJiMnavZTppgcFghmw7dCrmpkVX+wid20tPLuPSJuwr9ZOWn 0To401Uyqs7+2Jw6eHU3i7DMZBAK130HtcmiQR4KICL+6eU= X-Google-Smtp-Source: AG47ELvrllHbXoofjSqtkW9ZzzkfB1+r+Skhrm7mIzz8J7oMhR9FSb6ip3ZtJ9Kz6sEHGMtdd0N8TdfgQxfKmmGehB4= X-Received: by 10.31.84.70 with SMTP id i67mr10675224vkb.56.1520274633438; Mon, 05 Mar 2018 10:30:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Mon, 05 Mar 2018 18:30:22 +0000 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="001a114e61907d74540566ae850f" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 05 Mar 2018 18:30:38 -0000 --001a114e61907d74540566ae850f Content-Type: text/plain; charset="UTF-8" Hannes & Rifaat, I would like the opportunity to present on OAuth 2.0 Incremental Authorization (draft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and "OAuth 2.0 Device Posture Signals" (draft-wdenniss-oauth-device-posture). I can also give an update on the status of Device Flow (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has concluded and the document has advanced. Little late to this thread and I see we already have 2 sessions in the draft agenda, but I'd like to add my support to keeping both sessions, there's always a lot to discuss and in the past we've been able to use any spare time to discuss the security topics of the day. Regards, William On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig wrote: > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new milestone > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114e61907d74540566ae850f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hannes & Rifaat,

I would like the o= pportunity to present on=C2=A0OAuth 2.0 Incremental Auth= orization (draft-wdenniss-oauth-incremental-auth) [an update for which will= be posted today] and=C2=A0"OAuth 2.0 Device Posture Signals&qu= ot; (draft-wdenniss-oauth-device-posture).

I can a= lso give an update on the status of Device Flow (draft-ietf-oauth-device-fl= ow). I expect that to be short now that WGLC has concluded and the document= has advanced.

Little late to this thread and I se= e we already have 2 sessions in the draft agenda, but I'd like to add m= y support to keeping both sessions, there's always a lot to discuss and= in the past we've been able to use any spare time to discuss the secur= ity topics of the day.

Regards,
William<= /div>




On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>= wrote:

Hi all,

=C2=A0

It is time already to think about the agenda for the= next IETF meeting. Rifaat and I were wondering whether we need one or two = sessions. We would like to make the decision based on the topics we will di= scuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

= OAuth Agenda

= ------------

= =C2=A0

= - Welcome and Status Update=C2=A0 (Chairs)

= =C2=A0

= =C2=A0 * OAuth Security Workshop Report

= =C2=A0

= =C2=A0=C2=A0* Documents in IESG processing

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-08

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-exchange-11=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates only if needed.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

= -=C2=A0 JSON Web Token Best Current Practices

= =C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

= =C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this document.

= =C2=A0=C2=A0 Most likely we will not get them during the f2f meeting

= =C2=A0=C2=A0=C2=A0but rather by reaching out to individuals ahead of time.

= =C2=A0=C2=A0=C2=A0

= -=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Ac= cess Tokens

= =C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

= =C2=A0

= =C2=A0=C2=A0 Remark: Could be completed by the time of the IETF meeting.

= =C2=A0=C2=A0=C2=A0

= - OAuth Security Topics

= =C2=A0 # draft-ietf-oauth-security-topics-04

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: We could do a consensus call on parts of the document s= oon.

= =C2=A0=C2=A0

= - OAuth 2.0 Token Binding

= =C2=A0 # draft-ietf-oauth-token-binding-05

= =C2=A0

= =C2=A0=C2=A0Remark: Document is moving along but we are lacking implementat= ions.

= =C2=A0=C2=A0

= - OAuth 2.0 Device Posture Signals

= =C2=A0 # draft-wdenniss-oauth-device-posture-01

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: Interest in the work but we are lacking content (maybe = even

= =C2=A0=C2=A0expertise in the group)

= =C2=A0

= - Reciprocal OAuth

= =C2=A0 # draft-hardt-oauth-mutual-02

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work and apparently no competing solutions. Th= e plan

= =C2=A0 is to run a call for adoption once we are allowed to add a new miles= tone

= =C2=A0=C2=A0to our charter.

= =C2=A0=C2=A0

= - Distributed OAuth

= =C2=A0 # draft-hardt-oauth-distributed-00

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work. Further work on the scope is needed.<= /u>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114e61907d74540566ae850f-- From nobody Mon Mar 5 11:53:41 2018 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 9E2C712DB6D for ; Mon, 5 Mar 2018 11:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_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 EtlmFzY_bx1h for ; Mon, 5 Mar 2018 11:53:37 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0112.outbound.protection.outlook.com [104.47.33.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0002712D874 for ; Mon, 5 Mar 2018 11:53:36 -0800 (PST) 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=FzfpVwiHe8xeZUbnrjzfd/W1vHMu1c44iOxV0dA6yRY=; b=RiXgfSE9pVVTiY1Tim2no6b41K/aZhm/SLvNZGTSjAmuTk1Bv6RRf/zyaJxx45McqYC2AQJ7dwKP+uVxPNtlrs0QHpcbWsm4DTc9geByzONcENSyLjM4vG2qPv8l7tfs/Aha9asPPUC6YCAMG2VJtWeRe3fxAn5+NE3DTBtEQcU= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB0944.namprd21.prod.outlook.com (52.132.114.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.3; Mon, 5 Mar 2018 19:53:35 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0588.001; Mon, 5 Mar 2018 19:53:34 +0000 From: Mike Jones To: William Denniss , Hannes Tschofenig CC: oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAALa0qA= Date: Mon, 5 Mar 2018 19:53:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-05T19:53:32.7582718Z; 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 x-originating-ip: [2001:4898:80e8:b::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB0944; 7:hZAgVyScnPjUz6fxZIxFFn14/TaCEZMeWjOatTB2Lrpogz2DJAlwnd1qMx3eSMoBqf5gQNJEEzLZX+pg6oZtyh//m86yPSxVrqm4/+cbh7m5hp+QajeiyEjviiNNGxZzwzNBTBB3GDsLby7hNNbmWgbHMokmtbhaHTdKQFSGI2c7m5ViDvPbKN908QIjBto2LwZPZEc2YwBCnURDbcFD7mOQaVHeHEuX0I/cMruPV2P8NXhl55/pztRGIYKdqvhX; 20:gCA8PXFBWGEa2j5PV0xZi47j7RC3eu071IUsaeuW364QRb4+g8/+HgPGO2QonrLcuH3PQHHRokFhpRCPETF1Eist4tJ2DhTQgBwkNrcOGDEd7y+1Ax1lomLugP8lQIGWwNVHE4nerSqs1SW9ffxPV6gL6fdfj/O2ojmD3sKwdSs= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 85d1caf3-61f3-4556-b0fd-08d582d2c7d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603322)(7193020); SRVR:SN6PR2101MB0944; x-ms-traffictypediagnostic: SN6PR2101MB0944: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR2101MB0944; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB0944; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(346002)(376002)(366004)(53754006)(199004)(189003)(40434004)(6306002)(229853002)(68736007)(7736002)(2900100001)(74316002)(105586002)(2950100002)(606006)(106356001)(46003)(3660700001)(5660300001)(76176011)(97736004)(7696005)(3280700002)(10290500003)(478600001)(2906002)(22452003)(72206003)(53546011)(6506007)(54896002)(6116002)(9686003)(14454004)(99286004)(25786009)(236005)(86612001)(55016002)(110136005)(790700001)(5250100002)(966005)(102836004)(5890100001)(6246003)(8990500004)(316002)(19609705001)(186003)(10090500001)(4326008)(8936002)(81166006)(81156014)(33656002)(8676002)(59450400001)(86362001)(6436002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB0944; H:SN6PR2101MB0943.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) x-microsoft-antispam-message-info: pR7+xTpiA9HlZUIE3OfIT24zhU3U96Nf8dA9SIwHeTmCcK9jrlKkty2B3ZFsmPHVbLvvVgH9DG9/CSiJ7dn0TSTnOjYD8Rs47ZuC7pzvLlFL3fiWOPWHl7mKV2xJqUPWTTyBPGED+UiTHv/xAFZvkBZFMTXPoU4Ho/9iPRFAvFMz85AFDxRqfbL0AJwSN/3h2LRAjAnp3xrbzDOHnl2zqjptKEJ1827eCnpQYNJ85AdROP0tk3+RxIRRx9EmLkYhNZQ1iiSDfF3QaMakRD2zs/Lb8rvFjEwav7PlmE62B/a66O2fmDh2eTpt8gLBA2JRupEsl5717xng+BVB5Q9mRw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB094395ABEA258CA0F0D378D2F5DA0SN6PR2101MB0943_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85d1caf3-61f3-4556-b0fd-08d582d2c7d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 19:53:34.8367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB0944 Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 05 Mar 2018 19:53:40 -0000 --_000_SN6PR2101MB094395ABEA258CA0F0D378D2F5DA0SN6PR2101MB0943_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaG91bGQgbWFrZSBhIHByZXNlbnRhdGlvbiBhYm91dCBjaGFuZ2VzIGluIGRyYWZ0LWlldGYt b2F1dGgtZGlzY292ZXJ5IHRoYXQgb2NjdXJyZWQgYmVjYXVzZSBvZiBJRVNHIGZlZWRiYWNrLiAg MTAtMTUgbWludXRlcy4NCg0KSSB3aWxsIHRyeSB0byBoYXZlIHNvbWV0aGluZyB0byBzYXkgYWJv dXQgdGhlIEpXVCBCQ1AgZHJhZnQsIHdoaWNoIGlzIGN1cnJlbnRseSBleHBpcmVkLiAgSSB3aWxs IHBsYW4gdG8gYWRkcmVzcyBCcmlhbiBDYW1wYmVsbOKAmXMgY29tbWVudHMgYmVmb3JlIExvbmRv bi4gIChOb3QgZW5vdWdoIHRpbWUgcmVtYWlucyB0byBkbyBpdCB0b2RheS4pICAxMC0xNSBtaW51 dGVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIFdpbGxpYW0gRGVubmlzcw0KU2VudDogTW9uZGF5LCBNYXJjaCA1 LCAyMDE4IDEwOjMwIEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zlbmln QGFybS5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCkhhbm5lcyAmIFJpZmFhdCwNCg0KSSB3b3Vs ZCBsaWtlIHRoZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IG9uIE9BdXRoIDIuMCBJbmNyZW1lbnRh bCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNyZW1lbnRhbC1hdXRoKSBb YW4gdXBkYXRlIGZvciB3aGljaCB3aWxsIGJlIHBvc3RlZCB0b2RheV0gYW5kICJPQXV0aCAyLjAg RGV2aWNlIFBvc3R1cmUgU2lnbmFscyIgKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1wb3N0 dXJlKS4NCg0KSSBjYW4gYWxzbyBnaXZlIGFuIHVwZGF0ZSBvbiB0aGUgc3RhdHVzIG9mIERldmlj ZSBGbG93IChkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93KS4gSSBleHBlY3QgdGhhdCB0byBi ZSBzaG9ydCBub3cgdGhhdCBXR0xDIGhhcyBjb25jbHVkZWQgYW5kIHRoZSBkb2N1bWVudCBoYXMg YWR2YW5jZWQuDQoNCkxpdHRsZSBsYXRlIHRvIHRoaXMgdGhyZWFkIGFuZCBJIHNlZSB3ZSBhbHJl YWR5IGhhdmUgMiBzZXNzaW9ucyBpbiB0aGUgZHJhZnQgYWdlbmRhLCBidXQgSSdkIGxpa2UgdG8g YWRkIG15IHN1cHBvcnQgdG8ga2VlcGluZyBib3RoIHNlc3Npb25zLCB0aGVyZSdzIGFsd2F5cyBh IGxvdCB0byBkaXNjdXNzIGFuZCBpbiB0aGUgcGFzdCB3ZSd2ZSBiZWVuIGFibGUgdG8gdXNlIGFu eSBzcGFyZSB0aW1lIHRvIGRpc2N1c3MgdGhlIHNlY3VyaXR5IHRvcGljcyBvZiB0aGUgZGF5Lg0K DQpSZWdhcmRzLA0KV2lsbGlhbQ0KDQoNCg0KT24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0MCBB TSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFu bmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpJdCBpcyB0aW1lIGFs cmVhZHkgdG8gdGhpbmsgYWJvdXQgdGhlIGFnZW5kYSBmb3IgdGhlIG5leHQgSUVURiBtZWV0aW5n LiBSaWZhYXQgYW5kIEkgd2VyZSB3b25kZXJpbmcgd2hldGhlciB3ZSBuZWVkIG9uZSBvciB0d28g c2Vzc2lvbnMuIFdlIHdvdWxkIGxpa2UgdG8gbWFrZSB0aGUgZGVjaXNpb24gYmFzZWQgb24gdGhl IHRvcGljcyB3ZSB3aWxsIGRpc2N1c3MuIEJlbG93IHlvdSBjYW4gZmluZCBhIGZpcnN0IHZlcnNp b24gb2YgdGhlIGFnZW5kYSB3aXRoIGEgZmV3IHJlbWFya3MuIExldCB1cyBrbm93IGlmIHlvdSBo YXZlIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGZvciBhZGRpdGlvbmFsIGFnZW5kYSBpdGVtcy4N Cg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQoNCk9BdXRoIEFnZW5kYQ0KLS0tLS0tLS0tLS0tDQoN Ci0gV2VsY29tZSBhbmQgU3RhdHVzIFVwZGF0ZSAgKENoYWlycykNCg0KICAqIE9BdXRoIFNlY3Vy aXR5IFdvcmtzaG9wIFJlcG9ydA0KDQogICogRG9jdW1lbnRzIGluIElFU0cgcHJvY2Vzc2luZw0K ICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDcNCiAgICAgIyBkcmFmdC1pZXRm LW9hdXRoLWRpc2NvdmVyeS0wOA0KICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE1DQog ICAgICMgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMQ0KDQogICAgICAgUmVtYXJr OiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlmIG5lZWRlZC4NCg0KLSAgSlNPTiBXZWIgVG9rZW4gQmVz dCBDdXJyZW50IFByYWN0aWNlcw0KICAgIyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDANCg0K ICAgUmVtYXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1lbnQuDQogICBN b3N0IGxpa2VseSB3ZSB3aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcgdGhlIGYyZiBtZWV0aW5nDQog ICBidXQgcmF0aGVyIGJ5IHJlYWNoaW5nIG91dCB0byBpbmRpdmlkdWFscyBhaGVhZCBvZiB0aW1l Lg0KDQotICBPQXV0aCAyLjAgTXV0dWFsIFRMUyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIENl cnRpZmljYXRlIEJvdW5kIEFjY2VzcyBUb2tlbnMNCiAgICMgZHJhZnQtaWV0Zi1vYXV0aC1tdGxz LTA2DQoNCiAgIFJlbWFyazogQ291bGQgYmUgY29tcGxldGVkIGJ5IHRoZSB0aW1lIG9mIHRoZSBJ RVRGIG1lZXRpbmcuDQoNCi0gT0F1dGggU2VjdXJpdHkgVG9waWNzDQogICMgZHJhZnQtaWV0Zi1v YXV0aC1zZWN1cml0eS10b3BpY3MtMDQNCg0KICBSZW1hcms6IFdlIGNvdWxkIGRvIGEgY29uc2Vu c3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQoNCi0gT0F1dGggMi4wIFRv a2VuIEJpbmRpbmcNCiAgIyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmctMDUNCg0KICBS ZW1hcms6IERvY3VtZW50IGlzIG1vdmluZyBhbG9uZyBidXQgd2UgYXJlIGxhY2tpbmcgaW1wbGVt ZW50YXRpb25zLg0KDQotIE9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzDQogICMgZHJh ZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCg0KICBSZW1hcms6IEludGVyZXN0 IGluIHRoZSB3b3JrIGJ1dCB3ZSBhcmUgbGFja2luZyBjb250ZW50IChtYXliZSBldmVuDQogIGV4 cGVydGlzZSBpbiB0aGUgZ3JvdXApDQoNCi0gUmVjaXByb2NhbCBPQXV0aA0KICAjIGRyYWZ0LWhh cmR0LW9hdXRoLW11dHVhbC0wMg0KDQogIFJlbWFyazogV2UgaGFkIGEgdmlydHVhbCBpbnRlcmlt IG1lZXRpbmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCiAgaW50ZXJlc3QgaW4gdGhpcyB3 b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGluZyBzb2x1dGlvbnMuIFRoZSBwbGFuDQogIGlz IHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFsbG93ZWQgdG8gYWRkIGEg bmV3IG1pbGVzdG9uZQ0KICB0byBvdXIgY2hhcnRlci4NCg0KLSBEaXN0cmlidXRlZCBPQXV0aA0K ICAjIGRyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLTAwDQoNCiAgUmVtYXJrOiBXZSBoYWQg YSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFuZCB0aGVyZSBpcw0KICBp bnRlcmVzdCBpbiB0aGlzIHdvcmsuIEZ1cnRoZXIgd29yayBvbiB0aGUgc2NvcGUgaXMgbmVlZGVk Lg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55 IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0 aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_SN6PR2101MB094395ABEA258CA0F0D378D2F5DA0SN6PR2101MB0943_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBzaG91bGQgbWFrZSBhIHByZXNlbnRhdGlvbiBhYm91 dCBjaGFuZ2VzIGluIGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5IHRoYXQgb2NjdXJyZWQgYmVj YXVzZSBvZiBJRVNHIGZlZWRiYWNrLiZuYnNwOyAxMC0xNSBtaW51dGVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSB3aWxsIHRyeSB0byBoYXZlIHNvbWV0aGluZyB0byBz YXkgYWJvdXQgdGhlIEpXVCBCQ1AgZHJhZnQsIHdoaWNoIGlzIGN1cnJlbnRseSBleHBpcmVkLiZu YnNwOyBJIHdpbGwgcGxhbiB0byBhZGRyZXNzIEJyaWFuIENhbXBiZWxs4oCZcyBjb21tZW50cyBi ZWZvcmUgTG9uZG9uLiZuYnNwOyAoTm90IGVub3VnaCB0aW1lIHJlbWFpbnMgdG8gZG8gaXQgdG9k YXkuKSZuYnNwOyAxMC0xNSBtaW51dGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5P biBCZWhhbGYgT2YgPC9iPg0KV2lsbGlhbSBEZW5uaXNzPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgTWFyY2ggNSwgMjAxOCAxMDozMCBBTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVu aWcgJmx0O0hhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt V0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhhbm5lcyAmYW1wOyBSaWZhYXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHdvdWxkIGxpa2UgdGhlIG9wcG9ydHVuaXR5 IHRvIHByZXNlbnQgb24mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3Vu ZDp3aGl0ZSI+T0F1dGggMi4wIEluY3JlbWVudGFsIEF1dGhvcml6YXRpb24gKGRyYWZ0LXdkZW5u aXNzLW9hdXRoLWluY3JlbWVudGFsLWF1dGgpIFthbiB1cGRhdGUgZm9yIHdoaWNoIHdpbGwgYmUg cG9zdGVkIHRvZGF5XSBhbmQ8L3NwYW4+Jm5ic3A7JnF1b3Q7T0F1dGgNCiAyLjAgRGV2aWNlIFBv c3R1cmUgU2lnbmFscyZxdW90OyAoZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGNhbiBhbHNvIGdpdmUgYW4gdXBkYXRlIG9uIHRoZSBzdGF0dXMgb2YgRGV2aWNlIEZsb3cgKGRy YWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3cpLiBJIGV4cGVjdCB0aGF0IHRvIGJlIHNob3J0IG5v dyB0aGF0IFdHTEMgaGFzIGNvbmNsdWRlZCBhbmQgdGhlIGRvY3VtZW50IGhhcyBhZHZhbmNlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGl0 dGxlIGxhdGUgdG8gdGhpcyB0aHJlYWQgYW5kIEkgc2VlIHdlIGFscmVhZHkgaGF2ZSAyIHNlc3Np b25zIGluIHRoZSBkcmFmdCBhZ2VuZGEsIGJ1dCBJJ2QgbGlrZSB0byBhZGQgbXkgc3VwcG9ydCB0 byBrZWVwaW5nIGJvdGggc2Vzc2lvbnMsIHRoZXJlJ3MgYWx3YXlzIGEgbG90IHRvIGRpc2N1c3Mg YW5kIGluIHRoZSBwYXN0IHdlJ3ZlIGJlZW4gYWJsZSB0byB1c2UgYW55IHNwYXJlIHRpbWUgdG8g ZGlzY3Vzcw0KIHRoZSBzZWN1cml0eSB0b3BpY3Mgb2YgdGhlIGRheS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpbGxpYW08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0MCBBTSBI YW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb20iPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SGkgYWxsLA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+SXQgaXMgdGltZSBhbHJlYWR5IHRvIHRoaW5rIGFib3V0IHRoZSBhZ2VuZGEgZm9yIHRoZSBu ZXh0IElFVEYgbWVldGluZy4gUmlmYWF0IGFuZCBJIHdlcmUgd29uZGVyaW5nIHdoZXRoZXIgd2Ug bmVlZCBvbmUgb3IgdHdvIHNlc3Npb25zLiBXZSB3b3VsZCBsaWtlIHRvIG1ha2UNCiB0aGUgZGVj aXNpb24gYmFzZWQgb24gdGhlIHRvcGljcyB3ZSB3aWxsIGRpc2N1c3MuIEJlbG93IHlvdSBjYW4g ZmluZCBhIGZpcnN0IHZlcnNpb24gb2YgdGhlIGFnZW5kYSB3aXRoIGEgZmV3IHJlbWFya3MuIExl dCB1cyBrbm93IGlmIHlvdSBoYXZlIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGZvciBhZGRpdGlv bmFsIGFnZW5kYSBpdGVtcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkNpYW88YnI+DQpIYW5u ZXMgJmFtcDsgUmlmYWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PQXV0aCBBZ2VuZGE8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+LS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4tIFdlbGNvbWUgYW5kIFN0YXR1cyBVcGRhdGUmbmJzcDsgKENoYWlycyk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAqIE9BdXRo IFNlY3VyaXR5IFdvcmtzaG9wIFJlcG9ydDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsqIERvY3VtZW50cyBpbiBJRVNHIHByb2Nl c3Npbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJh ZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wNw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDgN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsjIGRy YWZ0LWlldGYtb2F1dGgtandzcmVxLTE1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAjIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMTE8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1JlbWFyazog U3RhdHVzIHVwZGF0ZXMgb25seSBpZiBuZWVkZWQuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t Jm5ic3A7IEpTT04gV2ViIFRva2VuIEJlc3QgQ3VycmVudCBQcmFjdGljZXM8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTAwDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwO1JlbWFyazogV2UgYXJlIGxhY2tpbmcgcmV2aWV3cyBvbiB0aGlz IGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTW9zdCBsaWtlbHkg d2Ugd2lsbCBub3QgZ2V0IHRoZW0gZHVyaW5nIHRoZSBmMmYgbWVldGluZw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwO2J1dCByYXRoZXIgYnkgcmVhY2hpbmcgb3V0IHRv IGluZGl2aWR1YWxzIGFoZWFkIG9mIHRpbWUuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0mbmJzcDsgT0F1dGggMi4wIE11dHVh bCBUTFMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBDZXJ0aWZpY2F0ZSBCb3VuZCBBY2Nlc3Mg VG9rZW5zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAjIGRyYWZ0LWlldGYtb2F1 dGgtbXRscy0wNg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgUmVtYXJrOiBDb3VsZCBiZSBjb21wbGV0ZWQgYnkgdGhlIHRpbWUg b2YgdGhlIElFVEYgbWVldGluZy4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBPQXV0aCBTZWN1cml0eSBUb3BpY3M8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3Mt MDQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7UmVtYXJrOiBXZSBjb3VsZCBkbyBhIGNvbnNlbnN1cyBjYWxsIG9uIHBh cnRzIG9mIHRoZSBkb2N1bWVudCBzb29uLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9BdXRoIDIuMCBUb2tlbiBCaW5kaW5nPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tYmluZGluZy0w NTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDtSZW1hcms6IERvY3VtZW50IGlzIG1vdmluZyBhbG9uZyBidXQgd2UgYXJlIGxhY2tp bmcgaW1wbGVtZW50YXRpb25zLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1w b3N0dXJlLTAxDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazogSW50ZXJlc3QgaW4gdGhlIHdvcmsgYnV0IHdl IGFyZSBsYWNraW5nIGNvbnRlbnQgKG1heWJlIGV2ZW4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDtleHBlcnRpc2UgaW4gdGhlIGdyb3VwKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIFJlY2lwcm9jYWwgT0F1dGg8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaGFyZHQtb2F1dGgtbXV0dWFsLTAyDQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBSZW1hcms6 IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJl IGlzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7aW50ZXJlc3QgaW4gdGhpcyB3 b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGluZyBzb2x1dGlvbnMuIFRoZSBwbGFuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyBpcyB0byBydW4gYSBjYWxsIGZvciBhZG9wdGlvbiBvbmNl IHdlIGFyZSBhbGxvd2VkIHRvIGFkZCBhIG5ldyBtaWxlc3RvbmUNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDt0byBvdXIgY2hhcnRlci4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBEaXN0cmlidXRlZCBPQXV0aDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC0w MA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsgUmVtYXJrOiBXZSBoYWQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGlj IGFuZCB0aGVyZSBpcw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO2ludGVyZXN0 IGluIHRoaXMgd29yay4gRnVydGhlciB3b3JrIG9uIHRoZSBzY29wZSBpcyBuZWVkZWQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cw0KIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_SN6PR2101MB094395ABEA258CA0F0D378D2F5DA0SN6PR2101MB0943_-- From nobody Mon Mar 5 17:10:02 2018 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 5EB6B127601 for ; Mon, 5 Mar 2018 17:10:01 -0800 (PST) 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 W-glcJom8eXC for ; Mon, 5 Mar 2018 17:09:58 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 691521241F5 for ; Mon, 5 Mar 2018 17:09:58 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id 139so19157189wmn.2 for ; Mon, 05 Mar 2018 17:09:58 -0800 (PST) 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=lfxJbX6O+VKi7DS/r3PpVy6IwJN6D0393FMrOQTJW4U=; b=j8jOvT9J1PxZcyenAErto0cX6daH1eTRQKmpA8sNQTAde0txdr2OzFzWUydaKZ0CuD bPhAMcvVKDltOgHVjyWhXwz9WXrgWwbgtNGg+/KLaNUta4kC0b6l+cU/nMyKMYkBAktA DtUZBAkUb3UAVf9cXf6OcS4kz/pDfCqXKyCdlIWoGQPQy1DSHyWLHkzDMBjM0a5SkPN1 +7SmMgFR04nym7C6BZArQD3r98xl5CRCRwDWioAMZKhsEZgPSaLrWohW6eq6u0viCfpw JfktIwlg1hVsrEB7OzPrDen2xfLKIBqqBHsEcCPG1NlqFD7KrNf1PngtCM20ORa/SLDQ 9XRg== 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=lfxJbX6O+VKi7DS/r3PpVy6IwJN6D0393FMrOQTJW4U=; b=IihJu4WA9zOvrqYp7Q+gNkPAW7bUIL9iylXznf6UJL/2a9JXm4ztcon8yRzowKVVJ9 T7YNc0/O4lMUOgcAsh6CqL5YoMdMFnjbAqoPZnTYVMAti/SDWBAOko6NGMK7mtDGpPhO IRWxfiXFPOki5tNbozUl0H5be7iTY8MUKDdzt4/YcCFHtTdNKMG6ZNSedI+cJLuML2dg DppXpBE7B4yD4Zq7t4u7NiQa/8qsLxs7GX8BfXjvpMdyV3mRmyJ+Sdt7dd8H3QSrp0g6 T6oD/WTIfVVuD/SH8cCDbor9NuzJ5+8PGVJMJzSzzdJdltRaws+L5hOtxfpSrf/MV9op JMBw== X-Gm-Message-State: AElRT7EQaqLw55TbkrdjvNbMZGsclZTyjGp6Hr2GhitvUCcpypWTAICH unAWfX1wLxqkTpDP6v5VK2DfNJKjix9k3ETROms= X-Google-Smtp-Source: AG47ELvlqHkPnQnAIklk2RI/fuKnmC8Q+DNr9Z72iibIi8eO8YPU4YP9aoIJHQutlf1Fi6wyuPy/wv080hyfZn0oiYI= X-Received: by 10.28.103.9 with SMTP id b9mr9259602wmc.32.1520298596771; Mon, 05 Mar 2018 17:09:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Tue, 06 Mar 2018 01:09:46 +0000 Message-ID: To: Hannes Tschofenig , William Denniss Cc: oauth , Brian Campbell Content-Type: multipart/alternative; boundary="001a114b2eced0315f0566b419b2" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 06 Mar 2018 01:10:01 -0000 --001a114b2eced0315f0566b419b2 Content-Type: text/plain; charset="UTF-8" I would be interested in hearing that. Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of the previous drafts on the similar topic as we discussed in the interim? i.e., Brian's draft (where is the link now?) and my draft ( draft-sakimura-oauth-meta )? Best, Nat On Tue, Mar 6, 2018 at 3:30 AM William Denniss wrote: > Hannes & Rifaat, > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for which > will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has > concluded and the document has advanced. > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use any > spare time to discuss the security topics of the day. > > Regards, > William > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > >> Hi all, >> >> >> >> It is time already to think about the agenda for the next IETF meeting. >> Rifaat and I were wondering whether we need one or two sessions. We would >> like to make the decision based on the topics we will discuss. Below you >> can find a first version of the agenda with a few remarks. Let us know if >> you have comments or suggestions for additional agenda items. >> >> >> >> Ciao >> Hannes & Rifaat >> >> >> >> OAuth Agenda >> >> ------------ >> >> >> >> - Welcome and Status Update (Chairs) >> >> >> >> * OAuth Security Workshop Report >> >> >> >> * Documents in IESG processing >> >> # draft-ietf-oauth-device-flow-07 >> >> # draft-ietf-oauth-discovery-08 >> >> # draft-ietf-oauth-jwsreq-15 >> >> # draft-ietf-oauth-token-exchange-11 >> >> >> >> Remark: Status updates only if needed. >> >> >> >> - JSON Web Token Best Current Practices >> >> # draft-ietf-oauth-jwt-bcp-00 >> >> >> >> Remark: We are lacking reviews on this document. >> >> Most likely we will not get them during the f2f meeting >> >> but rather by reaching out to individuals ahead of time. >> >> >> >> - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound >> Access Tokens >> >> # draft-ietf-oauth-mtls-06 >> >> >> >> Remark: Could be completed by the time of the IETF meeting. >> >> >> >> - OAuth Security Topics >> >> # draft-ietf-oauth-security-topics-04 >> >> >> >> Remark: We could do a consensus call on parts of the document soon. >> >> >> >> - OAuth 2.0 Token Binding >> >> # draft-ietf-oauth-token-binding-05 >> >> >> >> Remark: Document is moving along but we are lacking implementations. >> >> >> >> - OAuth 2.0 Device Posture Signals >> >> # draft-wdenniss-oauth-device-posture-01 >> >> >> >> Remark: Interest in the work but we are lacking content (maybe even >> >> expertise in the group) >> >> >> >> - Reciprocal OAuth >> >> # draft-hardt-oauth-mutual-02 >> >> >> >> Remark: We had a virtual interim meeting on this topic and there is >> >> interest in this work and apparently no competing solutions. The plan >> >> is to run a call for adoption once we are allowed to add a new >> milestone >> >> to our charter. >> >> >> >> - Distributed OAuth >> >> # draft-hardt-oauth-distributed-00 >> >> >> >> Remark: We had a virtual interim meeting on this topic and there is >> >> interest in this work. Further work on the scope is needed. >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> _______________________________________________ >> 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 > -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a114b2eced0315f0566b419b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be interested in hearing that.=C2=A0

= Also, as part of "Distributed OAuth", can we do a bit of re-cap o= n some of the previous drafts on the similar topic as we discussed in the i= nterim? i.e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oauth-meta)?=C2=A0<= /div>

Best,=C2=A0

Nat

On Tue, Mar 6, 2018 at 3:= 30 AM William Denniss <wdenniss@g= oogle.com> wrote:
Hannes & Rifaat,

I would like the opportuni= ty to present on=C2=A0OAuth 2.0 Incremental Authorizatio= n (draft-wdenniss-oauth-incremental-auth) [an update for which will be post= ed today] and=C2=A0"OAuth 2.0 Device Posture Signals" (dra= ft-wdenniss-oauth-device-posture).

I can also give= an update on the status of Device Flow (draft-ietf-oauth-device-flow). I e= xpect that to be short now that WGLC has concluded and the document has adv= anced.

Little late to this thread and I see we alr= eady have 2 sessions in the draft agenda, but I'd like to add my suppor= t to keeping both sessions, there's always a lot to discuss and in the = past we've been able to use any spare time to discuss the security topi= cs of the day.

Regards,
William




On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig <Hannes.Tschofenig@arm.c= om> wrote:

Hi all,

=C2=A0

It is time already to think about the agenda for the= next IETF meeting. Rifaat and I were wondering whether we need one or two = sessions. We would like to make the decision based on the topics we will di= scuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

= OAuth Agenda

= ------------

= =C2=A0

= - Welcome and Status Update=C2=A0 (Chairs)

= =C2=A0

= =C2=A0 * OAuth Security Workshop Report

= =C2=A0

= =C2=A0=C2=A0* Documents in IESG processing

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-08

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-exchange-11=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates only if needed.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

= -=C2=A0 JSON Web Token Best Current Practices

= =C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

= =C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this document.

= =C2=A0=C2=A0 Most likely we will not get them during the f2f meeting

= =C2=A0=C2=A0=C2=A0but rather by reaching out to individuals ahead of time.

= =C2=A0=C2=A0=C2=A0

= -=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Ac= cess Tokens

= =C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

= =C2=A0

= =C2=A0=C2=A0 Remark: Could be completed by the time of the IETF meeting.

= =C2=A0=C2=A0=C2=A0

= - OAuth Security Topics

= =C2=A0 # draft-ietf-oauth-security-topics-04

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: We could do a consensus call on parts of the document s= oon.

= =C2=A0=C2=A0

= - OAuth 2.0 Token Binding

= =C2=A0 # draft-ietf-oauth-token-binding-05

= =C2=A0

= =C2=A0=C2=A0Remark: Document is moving along but we are lacking implementat= ions.

= =C2=A0=C2=A0

= - OAuth 2.0 Device Posture Signals

= =C2=A0 # draft-wdenniss-oauth-device-posture-01

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: Interest in the work but we are lacking content (maybe = even

= =C2=A0=C2=A0expertise in the group)

= =C2=A0

= - Reciprocal OAuth

= =C2=A0 # draft-hardt-oauth-mutual-02

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work and apparently no competing solutions. Th= e plan

= =C2=A0 is to run a call for adoption once we are allowed to add a new miles= tone

= =C2=A0=C2=A0to our charter.

= =C2=A0=C2=A0

= - Distributed OAuth

= =C2=A0 # draft-hardt-oauth-distributed-00

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work. Further work on the scope is needed.<= /u>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114b2eced0315f0566b419b2-- From nobody Mon Mar 5 22:24:07 2018 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 2497D124235 for ; Mon, 5 Mar 2018 22:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kaFFgAogwtA4 for ; Mon, 5 Mar 2018 22:24:04 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 B03A1124B0A for ; Mon, 5 Mar 2018 22:24:00 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id m43so12289470uah.1 for ; Mon, 05 Mar 2018 22:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lgey3thDrRwnEVih61hYwKECVcEf6OSzCs/OyJx5/tw=; b=cQceELsMiTAvCs5Nghs1ZaTTM3RJTUQFw8imWueOwPk4M1McRm0dpsJidVThZXsTUV eRIVX7llAtIAWjl1/NaELODB/yJTKVkdigSo+Ydq85Ls6/nSCMVkPThDF13MqplnpWs4 2KSK90WprMupO/t+e//aG2BzHuoK5Rw2J/za/OY331LAbDkZktymS4TcRv3xWT2x7khB UFrrUjGqQJXl1hHk476DwynKNW+CalTnWhOuuAEtgpg/d2f2WJgsJ5rkpIFrndn1GK9X 1V93No8gv2LmnAFWYLIeBR7D5W1tkpm9EK507QrAaj0P21KW7IiDtopnS2naTEThT57f YAVQ== 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=Lgey3thDrRwnEVih61hYwKECVcEf6OSzCs/OyJx5/tw=; b=PlHkkDQ8D1LUwi+FQVv/Id6w704WMrKPgzmWAjYlTXCMzR8T3hqhlse3ToGwzC9zWj gMu1fpQwY6kmydNcR9WRfIk3//ILkuAp8UBlOpIAHYNnUgLQ96D8AkEXMp5bvVSw04we CNcTDJasRMxKWdGsIzxUpHCZyBJtyqzaqd7fpLT+1aBtjIRdhIF+syi+oeJ3yCRe5hEN sand5BJTSZil+hugFFpxVFhMNA68cxBDOYfHbbdbt55zL7yTBkJzzpaC3/VUTIuL9xr+ LxC+OKNxg3+/5QY3AtrT/DXMeg1vI9a7aJFGlcWp7TPSuK6ThhY0R0BfMXO1YFDNnsAT qp9g== X-Gm-Message-State: AElRT7HtnnUv5xK4DMU1R3A7cXWOFSP4cTHfe9i6V0/SJAH8ErV7B7i9 TmRiZtkpFGKZM1rJTRlbakv1nlr1Ty2aDps45Wlyww== X-Google-Smtp-Source: AG47ELuKal8PWXfV5jGbYMhLT5BQtRWNwLAqwooeckTf8ZMP5JjKBVnGP9YM+6GlkGDZrY+EK8UD31ZnTGyKrKxO/Ok= X-Received: by 10.176.6.10 with SMTP id f10mr12536649uaf.181.1520317439008; Mon, 05 Mar 2018 22:23:59 -0800 (PST) MIME-Version: 1.0 References: <151517342925.14706.13583633097065531665.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F7F91B492@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: From: William Denniss Date: Tue, 06 Mar 2018 06:23:47 +0000 Message-ID: To: Rifaat Shekh-Yusef Cc: "Hollenbeck, Scott" , iesg-secretary@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c122e6ce6b2aa0566b87cc3" Archived-At: Subject: Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07 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, 06 Mar 2018 06:24:06 -0000 --94eb2c122e6ce6b2aa0566b87cc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again for the feedback Scott. I've staged an update here: https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6 It expands on the brute force attack section to include some detail on this attack, as it is quite unique for OAuth brute-force attacks (since the victim actually ends up with the attacker's grant on the device, instead of the other way around =E2=80=93 not that this is totally safe of course, it'= s just unique). It also adds some further discussion around what factors need to be considered by authorization servers when creating the user code format. I'll post this once my co-authors have reviewed, and the submission tool re-opens. On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef wrote: > Hi Scott, > > Sorry, I missed that last discussion that you had with William. > > > *William,* > > Can you please update the document based on your last discussion with > Scott? > I will then update the request for publication to use the new updated > version. > > Regards, > Rifaat > > > > On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott < > shollenbeck@verisign.com> wrote: > >> > -----Original Message----- >> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh- >> > Yusef >> > Sent: Friday, January 05, 2018 12:30 PM >> > To: ekr@rtfm.com >> > Cc: oauth@ietf.org; iesg-secretary@ietf.org; oauth-chairs@ietf.org >> > Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for draf= t- >> > ietf-oauth-device-flow-07 >> > >> > Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-devic= e- >> > flow-07 as Proposed Standard on behalf of the OAUTH working group. >> > >> > Please verify the document's state at >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >> >> The document really should be updated to reflect the last call >> discussions prior to requesting publication for the -07 version that nee= ds >> to be updated. >> >> Scott >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c122e6ce6b2aa0566b87cc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again for the feedback Scott. I've staged an up= date here:=C2=A0https://github.com/WilliamDenniss/draft-ietf-oauth-d= evice-flow/pull/6

It expands on the brute force atta= ck section to include some detail on this attack, as it is quite unique for= OAuth brute-force attacks (since the victim actually ends up with the atta= cker's grant on the device, instead of the other way around =E2=80=93 n= ot that this is totally safe of course, it's just unique).=C2=A0 It als= o adds some further discussion around what factors need to be considered by= authorization servers when creating the user code format.

I'll post this once my co-authors have reviewed, and the submi= ssion tool re-opens.


On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi Scott,

Sorry, I missed that last discussion that you had with William.


William,

Ca= n you please update the document based on your last discussion with Scott?<= /div>
I will then update the request for publication to use the new upd= ated version.

Regards,
=C2=A0Rifaat



On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh-
> Yusef
> Sent: Friday, January 05, 2018 12:30 PM
> To: ekr@rtfm.com=
> Cc: oauth@ietf.org= ; iesg-sec= retary@ietf.org; oauth-chairs@ietf.org
> Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for draf= t-
> ietf-oauth-device-flow-07
>
> Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-devic= e-
> flow-07 as Proposed Standard on behalf of the OAUTH working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

The document really should be updated to reflect the last call = discussions prior to requesting publication for the -07 version that needs = to be updated.

Scott

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--94eb2c122e6ce6b2aa0566b87cc3-- From nobody Mon Mar 5 23:49:46 2018 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 8918C126C89 for ; Mon, 5 Mar 2018 23:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 sThmX24nc61x for ; Mon, 5 Mar 2018 23:49:43 -0800 (PST) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0A4120724 for ; Mon, 5 Mar 2018 23:49:42 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id EEEA977EEF for ; Tue, 6 Mar 2018 16:49:41 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id C0FE74E0046 for ; Tue, 6 Mar 2018 16:49:41 +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 w267nfc9007793 for ; Tue, 6 Mar 2018 16:49:41 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id w267nf5G007778 for ; Tue, 06 Mar 2018 16:49:41 +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 w267nf4f026848; Tue, 6 Mar 2018 16:49:41 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w267nfuD026847; Tue, 6 Mar 2018 16:49:41 +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 w267nfer026844 for ; Tue, 6 Mar 2018 16:49:41 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM03PA.cu.nri.co.jp (172.159.253.23) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 6 Mar 2018 16:49:40 +0900 Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.150) by ex.nri.co.jp (192.51.23.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 6 Mar 2018 16:49:39 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0bCnFxzeXsjyvW638pneDWZ9408Z+y36vNueLOZCb5o=; b=ZOO93QWp6BZo7N9pvQ0RRLunoB6RZ/pbBSUSKeyvr3ccFs1rXN9/cUz57woYcohSADCeKeBOCAZYm3ciO0cEFK+J+NCZjpDlaTxVXfbgoFImhU4YnqBVAkFkUvUhLGHWbXL0vpEq+n1YX8fV0hCdHxh5GN01td8myF/uD/xL6A4= Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com (10.174.225.12) by TY1PR01MB0828.jpnprd01.prod.outlook.com (10.167.159.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 07:49:39 +0000 Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) by TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 07:49:39 +0000 From: n-sakimura To: "oauth@ietf.org" Thread-Topic: Call for Participation - Third OAuth Security Workshop (OSW 2018) Thread-Index: AQHTtKzZflnS57OXxUuzVEu8wbWdNaPC1a3A Date: Tue, 6 Mar 2018 07:49:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [210.149.253.213] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB0828; 7:IuH69TkcU7N2cbGOLlNffwH/WKvD4MdOnRBIpxHUxebBqkxgOzx865NW9r5yObchL3U8eeGkZFf2bYVnJCU5ZIpe0lGJd4GLl/1UKBVtAf11QOqIP25j7H9dKnkGW8ptqzq3XPCzRYzSAX0kCVJdlp8wActkqkSmKhSFpdIthpY++ypmkhXJg4Tf//DMPuFCcwc/u3PqnsWXhtvlSIv8OyARAPTmLGoSwtUIG6jQu41/VTUC0wC9DYszLXK56/3I x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: eae65873-9459-4c2c-c5f2-08d58336d09a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB0828; x-ms-traffictypediagnostic: TY1PR01MB0828: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231220)(944501244)(52105095)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:TY1PR01MB0828; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0828; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(366004)(396003)(39380400002)(346002)(376002)(55885003)(26244003)(26234003)(13464003)(50854003)(69234005)(199004)(189003)(2473003)(59450400001)(478600001)(316002)(6506007)(55236004)(102836004)(14454004)(33656002)(966005)(53546011)(5640700003)(2900100001)(25786009)(2351001)(3280700002)(106356001)(66066001)(3660700001)(81156014)(81166006)(1730700003)(15650500001)(74482002)(8676002)(6436002)(77096007)(8936002)(9686003)(45080400002)(53936002)(55016002)(3846002)(6116002)(2501003)(305945005)(6306002)(2906002)(99286004)(105586002)(2950100002)(5660300001)(7736002)(6916009)(26005)(229853002)(7696005)(186003)(97736004)(86362001)(76176011)(68736007)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0828; H:TY1PR01MB1054.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: xljBjtaIm3eQCBMJFw3JDwawFBCyL0R+VMpRoVWLTqMYtyj3qIIvsBI80F8Kt47v8nB7j5L4w5Q4JxAAYLp08TpWOHHir407FiTCxOVXMvOzvbIO681QchRhn0KkfyHnbihO+NxrELdfbNtmBHo7IdXjtVyjtzOhQSARd3LP9orPACFUuqECBZ7rM/o2DtKIBZjyzqYcTtt2y//DVOUKJUXa8t/M4ktnPnpBLxkmnzCt95OLT9p+lIxSIkY6n4UpSpx2wC/pCanUeaJC/hU6osX7OZ0nq+TqqFlXO+ir42LCaEAuB2/35RQ5E6uf6GvKWugih0vpqhBvMH0FzcfuHA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eae65873-9459-4c2c-c5f2-08d58336d09a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 07:49:39.3288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0828 X-OrganizationHeadersPreserved: TY1PR01MB0828.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: [OAUTH-WG] FW: Call for Participation - Third OAuth Security Workshop (OSW 2018) 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, 06 Mar 2018 07:49:44 -0000 RllJLiBJdCBpcyBvbiB0aGUgd2VlayBiZWZvcmUgdGhlIElFVEYgMTAxIExvbmRvbi4gDQoNCkJ1 bmNoIG9mIHVzIGFyZSBnb2luZyB0byBiZSB0aGVyZSBkaXNjdXNzaW5nIHNlY3VyaXR5IGFzcGVj dCBvZiBPQXV0aC4gDQoNCk5hdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Um9iZXJ0byBDYXJib25lICANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDE4IDM6MDcgQU0N Cg0KU3ViamVjdDogQ2FsbCBmb3IgUGFydGljaXBhdGlvbiAtIFRoaXJkIE9BdXRoIFNlY3VyaXR5 IFdvcmtzaG9wIChPU1cgMjAxOCkNCg0KRGVhciBhbGwsDQoNCmxldCBtZSByZW1pbmQgeW91IHRo YXQgdGhlIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIDIwMTggd2lsbCB0YWtlIHBsYWNlIG5leHQg d2VlayBpbiBUcmVudG8gKEl0YWx5KS4NClBsZWFzZSBmaW5kIGJlbG93IHRoZSBjYWxsIGZvciBw YXJ0aWNpcGF0aW9uLg0KU2VlIHlvdSBpbiBUcmVudG8sDQoNCkJlc3QgcmVnYXJkcywNClJvYmVy dG8NCg0KLS0tDQoNCkNhbGwgZm9yIFBhcnRpY2lwYXRpb24NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg0KVGhpcmQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKE9TVyAyMDE4KSBGb25k YXppb25lIEJydW5vIEtlc3NsZXIgVHJlbnRvLCBJdGFseSBNYXJjaCAxNC0xNiwgMjAxOCBXb3Jr c2hvcCB3ZWJzaXRlOiBodHRwczovL3N0LmZiay5ldS9vc3cyMDE4DQoNCg0KPT0gQWJvdXQgT1NX IDIwMTggPT0NCg0KVGhlIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIChPU1cpIGFpbSBpcyB0byBp bXByb3ZlIHRoZSBzZWN1cml0eSBvZiBPQXV0aCBhbmQgcmVsYXRlZCBJbnRlcm5ldCBwcm90b2Nv bHMgYnkgYSBkaXJlY3QgZXhjaGFuZ2Ugb2Ygdmlld3MgYmV0d2VlbiBhY2FkZW1pYyByZXNlYXJj aGVycywgSUVURiBPQXV0aCBXb3JraW5nIEdyb3VwIG1lbWJlcnMgYW5kIGluZHVzdHJ5LiBUaGUg d29ya3Nob3AgaXMgaG9zdGVkIGJ5IHRoZSBTZWN1cml0eSBhbmQgVHJ1c3QgcmVzZWFyY2ggdW5p dCBvZiB0aGUgQnJ1bm8gS2Vzc2xlciBGb3VuZGF0aW9uIChGQkspLg0KDQpXaGlsZSB0aGUgc3Rh bmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgT0F1dGggZW5zdXJlcyBleHRlbnNpdmUgcmV2aWV3cyAo Ym90aCBzZWN1cml0eSBhbmQgbm9uLXNlY3VyaXR5IHJlbGF0ZWQpLCBmdXJ0aGVyIGFuYWx5c2lz IGJ5IHNlY3VyaXR5IGV4cGVydHMgZnJvbSBhY2FkZW1pYSBhbmQgaW5kdXN0cnkgaXMgZXNzZW50 aWFsIHRvIGVuc3VyZSBoaWdoIHF1YWxpdHkgc3BlY2lmaWNhdGlvbnMuIENvbnRyaWJ1dGlvbnMg dG8gdGhpcyB3b3Jrc2hvcCBjYW4gaGVscCB0byBpbXByb3ZlIHRoZSBzZWN1cml0eSBvZiB0aGUg V2ViIGFuZCB0aGUgSW50ZXJuZXQuDQoNCg0KPT1Qcm9ncmFtPT0NCg0KVGhlIHByb2dyYW0gaXMg YXZhaWxhYmxlIGF0IGh0dHBzOi8vc3QuZmJrLmV1L29zdzIwMTgvcHJvZ3JhbQ0KDQoNCj09UmVn aXN0cmF0aW9uPT0NCg0KUmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBhdCBo dHRwczovL3N0LmZiay5ldS9vc3cyMDE4L3JlZ2lzdHJhdGlvbg0KDQoNCj09IEltcG9ydGFudCBE YXRlcyA9PQ0KDQotIE9ubGluZSBSZWdpc3RyYXRpb246IHVudGlsIE1hcmNoIDExLCAyMDE4DQot IFdvcmtzaG9wOiBXZWQsIE1hcmNoIDE0LCAyMDE4IChoYWxmLWRheSksIFRodSwgTWFyY2ggMTUs IDIwMTggKGZ1bGwtZGF5KSwNCiAgYW5kIEZyaSwgTWFyY2ggMTYsIDIwMTggKGhhbGYgZGF5KQ0K DQoNCj09IFdvcmtzaG9wIENoYWlyID09DQoNCi0gU2lsdmlvIFJhbmlzZSAoU2VjdXJpdHkgJiBU cnVzdCwgRm9uZGF6aW9uZSBCcnVubyBLZXNzbGVyKQ0KDQoNCj09IFByb2dyYW0gQ29tbWl0dGVl ID09DQoNCkNoYWlycw0KLSBSb2JlcnRvIENhcmJvbmUgKFNlY3VyaXR5ICYgVHJ1c3QsIEZvbmRh emlvbmUgQnJ1bm8gS2Vzc2xlcikNCi0gSGFubmVzIFRzY2hvZmVuaWcgKElFVEYgT0F1dGggV29y a2luZyBHcm91cCBDby1DaGFpcikNCg0KTWVtYmVycw0KLSBNaWNoYWVsIEpvbmVzIChNaWNyb3Nv ZnQpDQotIFJhbGYgS3Vlc3RlcnMgKFVuaXZlcnNpdHkgb2YgU3R1dHRnYXJ0KQ0KLSBUb3JzdGVu IExvZGRlcnN0ZWR0IChZRVMgRXVyb3BlIEFHKQ0KLSBDaHJpcyBNaXRjaGVsbCAoUm95YWwgSG9s bG93YXksIFVuaXZlcnNpdHkgb2YgTG9uZG9uKQ0KLSBBbnRob255IE5hZGFsaW4gKE1pY3Jvc29m dCkNCi0gTmF0IFNha2ltdXJhIChOb211cmEgUmVzZWFyY2ggSW5zdGl0dXRlKQ0KLSBBbnRvbmlv IFNhbnNvIChBZG9iZSkNCi0gUmFsZiBTYXNzZSAoRVRIIFp1cmljaCkNCi0gSm9lcmcgU2Nod2Vu ayAoUnVoci1Vbml2ZXJzaXTDpHQgQm9jaHVtKQ0KLSBHaWFkYSBTY2lhcnJldHRhIChTZWN1cml0 eSAmIFRydXN0LCBGb25kYXppb25lIEJydW5vIEtlc3NsZXIgYW5kIFVuaXYuIG9mIFRyZW50bykN Cg0KDQo9PSBDb25mZXJlbmNlIHNpdGUgYW5kIGNvbnRhY3RzID09DQoNCkZvciBtb3JlIGRldGFp bGVkIGluZm9ybWF0aW9uIHBsZWFzZSByZWZlciB0byB0aGUgd29ya3Nob3Agd2ViIHNpdGU6DQpo dHRwczovL3N0LmZiay5ldS9vc3cyMDE4DQoNCklmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgb24g T1NXMTgsIHBsZWFzZSBjb250YWN0IGNhcmJvbmUgW2F0XSBmYmsgW2RvdF0gZXUsIGdpYWRhLnNj aWFycmV0dGEgW2F0XSBmYmsgW2RvdF0gZXUNCg0KLS0NCi0tDQpMZSBpbmZvcm1hemlvbmkgY29u dGVudXRlIG5lbGxhIHByZXNlbnRlIGNvbXVuaWNhemlvbmUgc29ubyBkaSBuYXR1cmEgcHJpdmF0 YSBlIGNvbWUgdGFsaSBzb25vIGRhIGNvbnNpZGVyYXJzaSByaXNlcnZhdGUgZWQgaW5kaXJpenph dGUgZXNjbHVzaXZhbWVudGUgYWkgZGVzdGluYXRhcmkgaW5kaWNhdGkgZSBwZXIgbGUgZmluYWxp dMOgIHN0cmV0dGFtZW50ZSBsZWdhdGUgYWwgcmVsYXRpdm8gY29udGVudXRvLiBTZSBhdmV0ZSBy aWNldnV0byBxdWVzdG8gbWVzc2FnZ2lvIHBlciBlcnJvcmUsIHZpIHByZWdoaWFtbyBkaSBlbGlt aW5hcmxvIGUgZGkgaW52aWFyZSB1bmEgY29tdW5pY2F6aW9uZSBhbGzigJlpbmRpcml6em8gZS1t YWlsIGRlbCBtaXR0ZW50ZS4NCi0tDQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaXMgaW50 ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgbWF0ZXJp YWwuIElmIHlvdSByZWNlaXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhlIG1hdGVyaWFsLg0K From nobody Tue Mar 6 00:13:20 2018 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 93B73126CF6 for ; Tue, 6 Mar 2018 00:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 T_ZVWj19Mxd7 for ; Tue, 6 Mar 2018 00:13:15 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0074.outbound.protection.outlook.com [104.47.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1E1120724 for ; Tue, 6 Mar 2018 00:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EaHSepUHEclc4F/qYA3XRF4k7oC7VANyO2WeCxvLJds=; b=ki0nHrTd0usVXQ0SKBJ7h4MN+LYju14BEBAutgm8mJeKE+5nDesA52znsf79J+szpa/GKxEA1OtQxDmsmyWaFIt/5+qj7yMygREt86VKpx6AbTuN9RpEzQXW7o8Z0VfWCSL9akrYYvA1nAvT1BURo9duCSD5Q7Or6wmnNIfNpas= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1917.eurprd08.prod.outlook.com (10.173.73.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 08:13:11 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 08:13:11 +0000 From: Hannes Tschofenig To: n-sakimura , "oauth@ietf.org" Thread-Topic: Call for Participation - Third OAuth Security Workshop (OSW 2018) Thread-Index: AQHTtKzWf0a+5Uf8EUOC7eP4PbPknqPC1gKAgAAF+mA= Date: Tue, 6 Mar 2018 08:13:11 +0000 Message-ID: References: In-Reply-To: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.126] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1917; 7:JOJfD4d++icCk9oIkHFGOLaEar4dtKEjDmAzx9YEpyGoBNj5hKRpxZNDPIxyxSlM+yZ/8ks+4yNxG/dkckjQZDDLqRsQf1/gNFa+cnX4XFOc8F2wm6iVDY4cqOKSTjs+6NpD5MShbuT1sMOG3gTMxMC+aMCqfn905htxjNm+V/Ofsvnfz34tyBB3GkhJ+z05kKyj7I85ACkqrsq6iNoAhKzBl4jLevImFnFfwmpmqPkyEqJiBTh1Nzmigddg1+AL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 66305b27-25d5-4212-a105-08d5833a1a75 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1917; x-ms-traffictypediagnostic: VI1PR0801MB1917: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231220)(944501244)(52105095)(6055026)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1917; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1917; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(39380400002)(39860400002)(346002)(50854003)(189003)(26234003)(13464003)(26244003)(40434004)(69234005)(199004)(55885003)(2950100002)(99286004)(8676002)(25786009)(105586002)(6306002)(3660700001)(81156014)(229853002)(110136005)(81166006)(316002)(9686003)(7696005)(53546011)(66066001)(6506007)(59450400001)(6246003)(2900100001)(55016002)(5660300001)(53936002)(26005)(966005)(14454004)(76176011)(74316002)(3280700002)(186003)(72206003)(97736004)(6436002)(2501003)(86362001)(33656002)(5250100002)(106356001)(102836004)(3846002)(6116002)(7736002)(15650500001)(8936002)(68736007)(45080400002)(5890100001)(305945005)(2906002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1917; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uv4KND9unvUXOSG2TC53H2GSkzueIT3t5xiz6t/BSOAvplOvj0hq+4J1r14KQX6tJeBfMp3N/2FQ7Wq4Ns+t0mZhu++RNNpEHLTvvKOfSdDwm4kS9JhOrGsa8MolVYF5gDfrGMjp4cwPYeBghkfkVghmAWN+hJpoD3Z89fpkDMAs/QetUDnp6zmZkoI8znXAEyYglSAFOLFGEK6B+K1JrT7AWNIeoi12XSHRHY/WkLRGDDT5aQGMHB5eCLCkQ3jJ2C0V6SohGCv1BNUOHZlHsS+MPQ0HEQ0PuWDEpRLbMvL/UfBkTOct0hDhKLb+1fkFB4nm209honC8A1YSzDZzAA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66305b27-25d5-4212-a105-08d5833a1a75 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 08:13:11.6801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1917 Archived-At: Subject: Re: [OAUTH-WG] Call for Participation - Third OAuth Security Workshop (OSW 2018) 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, 06 Mar 2018 08:13:19 -0000 VGhhbmtzIGZvciBzaGFyaW5nLCBOYXQuDQoNCkkgc2Vjb25kIHRoZSBpbnZpdGF0aW9uIGZyb20g TmF0LiBPdXIgT0F1dGggc2VjdXJpdHkgd29ya3Nob3BzIGhhdmUgdHJpZ2dlcmVkIGEgbG90IG9m IGRpc2N1c3Npb24gaW4gdGhlIHBhc3QgYW5kIHRoZXJlIGlzIGFsd2F5cyBzb21ldGhpbmcgbmV3 IHRvIGxlYXJuLiBBbHNvIGZvciB0aGlzIHdvcmtzaG9wIHdlIGhhdmUgbWFuZ2VkIHRvIGludml0 ZSBzb21lIGdyZWF0IGtleW5vdGUgc3BlYWtlcnMuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2Ygbi1zYWtpbXVyYQ0KU2VudDogMDYgTWFyY2ggMjAxOCAwODo1 MA0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIEZXOiBDYWxsIGZvciBQ YXJ0aWNpcGF0aW9uIC0gVGhpcmQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgKE9TVyAyMDE4KQ0K DQpGWUkuIEl0IGlzIG9uIHRoZSB3ZWVrIGJlZm9yZSB0aGUgSUVURiAxMDEgTG9uZG9uLg0KDQpC dW5jaCBvZiB1cyBhcmUgZ29pbmcgdG8gYmUgdGhlcmUgZGlzY3Vzc2luZyBzZWN1cml0eSBhc3Bl Y3Qgb2YgT0F1dGguDQoNCk5hdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Um9iZXJ0byBDYXJib25lDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwNiwgMjAxOCAzOjA3IEFNDQoN ClN1YmplY3Q6IENhbGwgZm9yIFBhcnRpY2lwYXRpb24gLSBUaGlyZCBPQXV0aCBTZWN1cml0eSBX b3Jrc2hvcCAoT1NXIDIwMTgpDQoNCkRlYXIgYWxsLA0KDQpsZXQgbWUgcmVtaW5kIHlvdSB0aGF0 IHRoZSBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcCAyMDE4IHdpbGwgdGFrZSBwbGFjZSBuZXh0IHdl ZWsgaW4gVHJlbnRvIChJdGFseSkuDQpQbGVhc2UgZmluZCBiZWxvdyB0aGUgY2FsbCBmb3IgcGFy dGljaXBhdGlvbi4NClNlZSB5b3UgaW4gVHJlbnRvLA0KDQpCZXN0IHJlZ2FyZHMsDQpSb2JlcnRv DQoNCi0tLQ0KDQpDYWxsIGZvciBQYXJ0aWNpcGF0aW9uDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQoNClRoaXJkIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIChPU1cgMjAxOCkgRm9uZGF6 aW9uZSBCcnVubyBLZXNzbGVyIFRyZW50bywgSXRhbHkgTWFyY2ggMTQtMTYsIDIwMTggV29ya3No b3Agd2Vic2l0ZTogaHR0cHM6Ly9zdC5mYmsuZXUvb3N3MjAxOA0KDQoNCj09IEFib3V0IE9TVyAy MDE4ID09DQoNClRoZSBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcCAoT1NXKSBhaW0gaXMgdG8gaW1w cm92ZSB0aGUgc2VjdXJpdHkgb2YgT0F1dGggYW5kIHJlbGF0ZWQgSW50ZXJuZXQgcHJvdG9jb2xz IGJ5IGEgZGlyZWN0IGV4Y2hhbmdlIG9mIHZpZXdzIGJldHdlZW4gYWNhZGVtaWMgcmVzZWFyY2hl cnMsIElFVEYgT0F1dGggV29ya2luZyBHcm91cCBtZW1iZXJzIGFuZCBpbmR1c3RyeS4gVGhlIHdv cmtzaG9wIGlzIGhvc3RlZCBieSB0aGUgU2VjdXJpdHkgYW5kIFRydXN0IHJlc2VhcmNoIHVuaXQg b2YgdGhlIEJydW5vIEtlc3NsZXIgRm91bmRhdGlvbiAoRkJLKS4NCg0KV2hpbGUgdGhlIHN0YW5k YXJkaXphdGlvbiBwcm9jZXNzIG9mIE9BdXRoIGVuc3VyZXMgZXh0ZW5zaXZlIHJldmlld3MgKGJv dGggc2VjdXJpdHkgYW5kIG5vbi1zZWN1cml0eSByZWxhdGVkKSwgZnVydGhlciBhbmFseXNpcyBi eSBzZWN1cml0eSBleHBlcnRzIGZyb20gYWNhZGVtaWEgYW5kIGluZHVzdHJ5IGlzIGVzc2VudGlh bCB0byBlbnN1cmUgaGlnaCBxdWFsaXR5IHNwZWNpZmljYXRpb25zLiBDb250cmlidXRpb25zIHRv IHRoaXMgd29ya3Nob3AgY2FuIGhlbHAgdG8gaW1wcm92ZSB0aGUgc2VjdXJpdHkgb2YgdGhlIFdl YiBhbmQgdGhlIEludGVybmV0Lg0KDQoNCj09UHJvZ3JhbT09DQoNClRoZSBwcm9ncmFtIGlzIGF2 YWlsYWJsZSBhdCBodHRwczovL3N0LmZiay5ldS9vc3cyMDE4L3Byb2dyYW0NCg0KDQo9PVJlZ2lz dHJhdGlvbj09DQoNClJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgYXQgaHR0 cHM6Ly9zdC5mYmsuZXUvb3N3MjAxOC9yZWdpc3RyYXRpb24NCg0KDQo9PSBJbXBvcnRhbnQgRGF0 ZXMgPT0NCg0KLSBPbmxpbmUgUmVnaXN0cmF0aW9uOiB1bnRpbCBNYXJjaCAxMSwgMjAxOA0KLSBX b3Jrc2hvcDogV2VkLCBNYXJjaCAxNCwgMjAxOCAoaGFsZi1kYXkpLCBUaHUsIE1hcmNoIDE1LCAy MDE4IChmdWxsLWRheSksDQogIGFuZCBGcmksIE1hcmNoIDE2LCAyMDE4IChoYWxmIGRheSkNCg0K DQo9PSBXb3Jrc2hvcCBDaGFpciA9PQ0KDQotIFNpbHZpbyBSYW5pc2UgKFNlY3VyaXR5ICYgVHJ1 c3QsIEZvbmRhemlvbmUgQnJ1bm8gS2Vzc2xlcikNCg0KDQo9PSBQcm9ncmFtIENvbW1pdHRlZSA9 PQ0KDQpDaGFpcnMNCi0gUm9iZXJ0byBDYXJib25lIChTZWN1cml0eSAmIFRydXN0LCBGb25kYXpp b25lIEJydW5vIEtlc3NsZXIpDQotIEhhbm5lcyBUc2Nob2ZlbmlnIChJRVRGIE9BdXRoIFdvcmtp bmcgR3JvdXAgQ28tQ2hhaXIpDQoNCk1lbWJlcnMNCi0gTWljaGFlbCBKb25lcyAoTWljcm9zb2Z0 KQ0KLSBSYWxmIEt1ZXN0ZXJzIChVbml2ZXJzaXR5IG9mIFN0dXR0Z2FydCkNCi0gVG9yc3RlbiBM b2RkZXJzdGVkdCAoWUVTIEV1cm9wZSBBRykNCi0gQ2hyaXMgTWl0Y2hlbGwgKFJveWFsIEhvbGxv d2F5LCBVbml2ZXJzaXR5IG9mIExvbmRvbikNCi0gQW50aG9ueSBOYWRhbGluIChNaWNyb3NvZnQp DQotIE5hdCBTYWtpbXVyYSAoTm9tdXJhIFJlc2VhcmNoIEluc3RpdHV0ZSkNCi0gQW50b25pbyBT YW5zbyAoQWRvYmUpDQotIFJhbGYgU2Fzc2UgKEVUSCBadXJpY2gpDQotIEpvZXJnIFNjaHdlbmsg KFJ1aHItVW5pdmVyc2l0w6R0IEJvY2h1bSkNCi0gR2lhZGEgU2NpYXJyZXR0YSAoU2VjdXJpdHkg JiBUcnVzdCwgRm9uZGF6aW9uZSBCcnVubyBLZXNzbGVyIGFuZCBVbml2LiBvZiBUcmVudG8pDQoN Cg0KPT0gQ29uZmVyZW5jZSBzaXRlIGFuZCBjb250YWN0cyA9PQ0KDQpGb3IgbW9yZSBkZXRhaWxl ZCBpbmZvcm1hdGlvbiBwbGVhc2UgcmVmZXIgdG8gdGhlIHdvcmtzaG9wIHdlYiBzaXRlOg0KaHR0 cHM6Ly9zdC5mYmsuZXUvb3N3MjAxOA0KDQpJZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIG9uIE9T VzE4LCBwbGVhc2UgY29udGFjdCBjYXJib25lIFthdF0gZmJrIFtkb3RdIGV1LCBnaWFkYS5zY2lh cnJldHRhIFthdF0gZmJrIFtkb3RdIGV1DQoNCi0tDQotLQ0KTGUgaW5mb3JtYXppb25pIGNvbnRl bnV0ZSBuZWxsYSBwcmVzZW50ZSBjb211bmljYXppb25lIHNvbm8gZGkgbmF0dXJhIHByaXZhdGEg ZSBjb21lIHRhbGkgc29ubyBkYSBjb25zaWRlcmFyc2kgcmlzZXJ2YXRlIGVkIGluZGlyaXp6YXRl IGVzY2x1c2l2YW1lbnRlIGFpIGRlc3RpbmF0YXJpIGluZGljYXRpIGUgcGVyIGxlIGZpbmFsaXTD oCBzdHJldHRhbWVudGUgbGVnYXRlIGFsIHJlbGF0aXZvIGNvbnRlbnV0by4gU2UgYXZldGUgcmlj ZXZ1dG8gcXVlc3RvIG1lc3NhZ2dpbyBwZXIgZXJyb3JlLCB2aSBwcmVnaGlhbW8gZGkgZWxpbWlu YXJsbyBlIGRpIGludmlhcmUgdW5hIGNvbXVuaWNhemlvbmUgYWxs4oCZaW5kaXJpenpvIGUtbWFp bCBkZWwgbWl0dGVudGUuDQotLQ0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG1hdGVyaWFs LiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoZSBtYXRlcmlhbC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Tue Mar 6 02:10:07 2018 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 57CCC127076 for ; Tue, 6 Mar 2018 02:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5] 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 NY_V33LcMuVw for ; Tue, 6 Mar 2018 02:10:05 -0800 (PST) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 71CBC126FDC for ; Tue, 6 Mar 2018 02:10:05 -0800 (PST) Received: from [192.168.43.252] ([212.39.89.128]) by :SMTPAUTH: with SMTP id t9XmevbWLuFnnt9Xne9UC9; Tue, 06 Mar 2018 03:10:04 -0700 To: "oauth@ietf.org" From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <342677c3-2370-413e-efbc-f0a03da509f4@connect2id.com> Date: Tue, 6 Mar 2018 12:10:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020907030703080502000905" X-CMAE-Envelope: MS4wfJG1eb6G9HqI/15wzfyJoj6fetmH66vyNyfAHCAUNZIo+7Nu/S51JOYJND+wR/r6ofyUKD0htbBuiK4R2WfcGjH06q5AcWnUZWjuXG2mpdhL+IUeM7Fu 2zUGDW/14IBHBUH+Of9MUmHr6H6pOipeHP6wtbvzvR9ucxRzal954xsY Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-mtls-07: jwks_uri with registered x5t#S256 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, 06 Mar 2018 10:10:06 -0000 This is a cryptographically signed message in MIME format. --------------ms020907030703080502000905 Content-Type: multipart/alternative; boundary="------------66A15B1C1976D90A8CE862E7" Content-Language: en-US This is a multi-part message in MIME format. --------------66A15B1C1976D90A8CE862E7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A question came up in a conversation with a developer: https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.2.2 What should the AS do when authenticating a client when the client has registered a JWK (jwks_uri) with a "x5t#S256" parameter instead of a "x5c= "? 1. Ignore the registered cert "x5t#S256" and match the key material of the received cert with the key material of the registered JWK. 2. Match the registered cert "x5t#S256" with the "x5t#S256" of the received cert. 3. Something else? Thanks, Vladimir --------------66A15B1C1976D90A8CE862E7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable A question came up in a conversation with a developer:

https://tools.ietf.org/html/dra= ft-ietf-oauth-mtls-07#section-2.2.2

What should the AS do when authenticating a client when the client has registered a JWK (jwks_uri) with a "x5t#S256" parameter instead of a "x5c"?

  1. Ignore the registered cert "x5t#S256" and match the key material of the received cert with the key material of the registered JWK.

  2. Match the registered cert "x5t#S256" with the "x5t#S256" of the received cert.

  3. Something else?

Thanks,

Vladimir
--------------66A15B1C1976D90A8CE862E7-- --------------ms020907030703080502000905 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 Fw0xODAzMDYxMDEwMDFaMC8GCSqGSIb3DQEJBDEiBCASGvuf7kDW1ypEK6/IB/7+viYaXx2O sJigJ1KA+Qr+HDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQDAKnJ8Lomm fJq53aGLLh9yzw4hqg7z2PC4/Hwl6cggM5kG96bCc3mklTepVPjpvIU+iOBXf3Tfx61QUQqd PQky6G0NIRIO+0ilqnPWeTOAipyX94yeAif6Vdbtt2CV1Z684MSdeFpV/IqmerMsazPnSBa7 qMzMcXDiak5SdoO8fMCYoU29Ausx1usFJHSIKMX7qsFjD0MFGjAHzF8su90GI2WB74H9hlFG BK33DnrTBJIc6fVKBdTG9vS0JvOtVwnW9UHNZUH42g0JFGpzjIj+4mqlN+vCXnMYZb3QAZ+p aU3B1jvu5P1Gv9jU0Q2vb50qJXwO6EDi1Puw+V4h6aKuAAAAAAAA --------------ms020907030703080502000905-- From nobody Tue Mar 6 07:22:39 2018 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 14AF2124D68 for ; Tue, 6 Mar 2018 07:22:37 -0800 (PST) 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 wn-3gOjXuYG7 for ; Tue, 6 Mar 2018 07:22:34 -0800 (PST) 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 5B3A0120454 for ; Tue, 6 Mar 2018 07:22:34 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id f5so13283986uam.5 for ; Tue, 06 Mar 2018 07:22:34 -0800 (PST) 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=BE3QAJQK9zHO7DCO2NZTQmuuVy0TikJ4LTGQOuK7nDs=; b=oDZnNz5c3hHYbS0YGE9jo31QhJfvW72KJXfOYKJZAMwH4ifUdlXhNyKUtTKLh59/qi VAgxauQCZm/9kreT6rD5Vewm45+jMqeL28FGsJQfoiIyl+ovSNd7S1DgXG0pwr8/1+vJ ZKECUvawRUjlVmEdgrHi06JoA2IkrQMZWOPyhMHxtMp2OdtTY53SfcOVbCeiqke9SXd0 IHXKdeGSXd4dWNAbme8br6RyFwp1VkiWOa1mXPxjuhu3htCz+mkAinBB0Zk+zBANyamt myFivWH2ysv28HIi37TSOJY8y2+CKRExGl2kLUI4vjmbFAU5pMtpcuEseVtjMbuGkyFs HGfg== 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=BE3QAJQK9zHO7DCO2NZTQmuuVy0TikJ4LTGQOuK7nDs=; b=nCcRJfIPVwiOoARjgi78OckxrenFZGqJIVlGw9tm799gt8beURXhxHaX5pg2PIu/lJ 03pfrRhd9dTftZC86f1G5QjoNrqnV+ne5qJQlCeRLrG1maP7imtsegIFhOSgb/b7Zuxi QYmNGaopEI2xNMw4oLoQSbdKqD+mUYfXDcr+9NdzXWF3kQtycMVYTSzW0kdguCa5nhoe +QI9/RQGdTSBGgPSIE/aNy+GRHO56laZ72T84PPW3s11BwpH15/3RzQWY+5m+RY9FsE7 I5CMvZTgXE8BA4nX5P91N61sbCaEHlIJQPtqVgEVxM5Q2PIEvmEH2f/haWCPdccS+bdH DKbw== X-Gm-Message-State: APf1xPAw2EVY7W9rHpuBC5zcGkDlaeRDyjI3Bin45YjfsXw3bRFfYEbh hBNAQkTOjdvTpD6Rny97pAKTY7nWkLFlT70Vuf4= X-Google-Smtp-Source: AG47ELtmWGBDzOgeE8AzcUsytUvFiAuy9iiJL5vVFTS8Lvqznzy1/vlMme+janze/JpEiGGtj6oEhTaoSAgPzKBhpRI= X-Received: by 10.176.73.145 with SMTP id e17mr13729695uad.157.1520349753266; Tue, 06 Mar 2018 07:22:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.45.148 with HTTP; Tue, 6 Mar 2018 07:22:32 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Tue, 6 Mar 2018 10:22:32 -0500 Message-ID: To: Nat Sakimura Cc: Hannes Tschofenig , William Denniss , oauth Content-Type: multipart/alternative; boundary="001a1144fd04fa57f50566c0021c" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 06 Mar 2018 15:22:37 -0000 --001a1144fd04fa57f50566c0021c Content-Type: text/plain; charset="UTF-8" Nat, During the interim meeting, 3 drafts mentioned in the context of *Distributed OAuth*: https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 *Brian, Hannes,* Are you planning on presenting your documents? Regards, Rifaat On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > I would be interested in hearing that. > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > Best, > > Nat > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > >> Hannes & Rifaat, >> >> I would like the opportunity to present on OAuth 2.0 Incremental >> Authorization (draft-wdenniss-oauth-incremental-auth) [an update for >> which will be posted today] and "OAuth 2.0 Device Posture Signals" >> (draft-wdenniss-oauth-device-posture). >> >> I can also give an update on the status of Device Flow >> (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC >> has concluded and the document has advanced. >> >> Little late to this thread and I see we already have 2 sessions in the >> draft agenda, but I'd like to add my support to keeping both sessions, >> there's always a lot to discuss and in the past we've been able to use any >> spare time to discuss the security topics of the day. >> >> Regards, >> William >> >> >> >> >> On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < >> Hannes.Tschofenig@arm.com> wrote: >> >>> Hi all, >>> >>> >>> >>> It is time already to think about the agenda for the next IETF meeting. >>> Rifaat and I were wondering whether we need one or two sessions. We would >>> like to make the decision based on the topics we will discuss. Below you >>> can find a first version of the agenda with a few remarks. Let us know if >>> you have comments or suggestions for additional agenda items. >>> >>> >>> >>> Ciao >>> Hannes & Rifaat >>> >>> >>> >>> OAuth Agenda >>> >>> ------------ >>> >>> >>> >>> - Welcome and Status Update (Chairs) >>> >>> >>> >>> * OAuth Security Workshop Report >>> >>> >>> >>> * Documents in IESG processing >>> >>> # draft-ietf-oauth-device-flow-07 >>> >>> # draft-ietf-oauth-discovery-08 >>> >>> # draft-ietf-oauth-jwsreq-15 >>> >>> # draft-ietf-oauth-token-exchange-11 >>> >>> >>> >>> Remark: Status updates only if needed. >>> >>> >>> >>> - JSON Web Token Best Current Practices >>> >>> # draft-ietf-oauth-jwt-bcp-00 >>> >>> >>> >>> Remark: We are lacking reviews on this document. >>> >>> Most likely we will not get them during the f2f meeting >>> >>> but rather by reaching out to individuals ahead of time. >>> >>> >>> >>> - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound >>> Access Tokens >>> >>> # draft-ietf-oauth-mtls-06 >>> >>> >>> >>> Remark: Could be completed by the time of the IETF meeting. >>> >>> >>> >>> - OAuth Security Topics >>> >>> # draft-ietf-oauth-security-topics-04 >>> >>> >>> >>> Remark: We could do a consensus call on parts of the document soon. >>> >>> >>> >>> - OAuth 2.0 Token Binding >>> >>> # draft-ietf-oauth-token-binding-05 >>> >>> >>> >>> Remark: Document is moving along but we are lacking implementations. >>> >>> >>> >>> - OAuth 2.0 Device Posture Signals >>> >>> # draft-wdenniss-oauth-device-posture-01 >>> >>> >>> >>> Remark: Interest in the work but we are lacking content (maybe even >>> >>> expertise in the group) >>> >>> >>> >>> - Reciprocal OAuth >>> >>> # draft-hardt-oauth-mutual-02 >>> >>> >>> >>> Remark: We had a virtual interim meeting on this topic and there is >>> >>> interest in this work and apparently no competing solutions. The plan >>> >>> is to run a call for adoption once we are allowed to add a new >>> milestone >>> >>> to our charter. >>> >>> >>> >>> - Distributed OAuth >>> >>> # draft-hardt-oauth-distributed-00 >>> >>> >>> >>> Remark: We had a virtual interim meeting on this topic and there is >>> >>> interest in this work. Further work on the scope is needed. >>> IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose the >>> contents to any other person, use it for any purpose, or store or copy the >>> information in any medium. Thank you. >>> _______________________________________________ >>> 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 >> > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1144fd04fa57f50566c0021c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nat,

= Brian, Hannes,

Are you planning on presenting = your documents?

Regards,
=C2=A0Rifaat






On Mon, = Mar 5, 2018 at 8:09 PM, Nat Sakimura <sakimura@gmail.com> w= rote:
I would be interes= ted in hearing that.=C2=A0

Also, as part of "Distributed = OAuth", can we do a bit of re-cap on some of the previous drafts on th= e similar topic as we discussed in the interim? i.e., Brian's draft (wh= ere is the link now?) and my draft (draft-sakimura-oauth-meta)?=C2=A0

Best,=C2=A0

Nat

On Tue, Mar 6, 2018= at 3:30 AM William Denniss <wdenniss@google.com> wrote:
Hannes & Rifaat,

I wo= uld like the opportunity to present on=C2=A0OAuth 2.0 In= cremental Authorization (draft-wdenniss-oauth-incremental-auth) [an up= date for which will be posted today] and=C2=A0"OAuth 2.0 Device= Posture Signals" (draft-wdenniss-oauth-device-posture).

I can also give an update on the status of Device Flow (dr= aft-ietf-oauth-device-flow). I expect that to be short now that WGLC h= as concluded and the document has advanced.

Little= late to this thread and I see we already have 2 sessions in the draft agen= da, but I'd like to add my support to keeping both sessions, there'= s always a lot to discuss and in the past we've been able to use any sp= are time to discuss the security topics of the day.

Regards,
William



<= br>
On Tue, Jan 30, 2018 at 4:40= AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think about the agenda for the= next IETF meeting. Rifaat and I were wondering whether we need one or two = sessions. We would like to make the decision based on the topics we will di= scuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

= OAuth Agenda

= ------------

= =C2=A0

= - Welcome and Status Update=C2=A0 (Chairs)

= =C2=A0

= =C2=A0 * OAuth Security Workshop Report

= =C2=A0

= =C2=A0=C2=A0* Documents in IESG processing

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-08

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-exchange-11

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates only if needed.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

= -=C2=A0 JSON Web Token Best Current Practices

= =C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

= =C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this document.

= =C2=A0=C2=A0 Most likely we will not get them during the f2f meeting

= =C2=A0=C2=A0=C2=A0but rather by reaching out to individuals ahead of time.

= =C2=A0=C2=A0=C2=A0

= -=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Ac= cess Tokens

= =C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

= =C2=A0

= =C2=A0=C2=A0 Remark: Could be completed by the time of the IETF meeting.

= =C2=A0=C2=A0=C2=A0

= - OAuth Security Topics

= =C2=A0 # draft-ietf-oauth-security-topics-04

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: We could do a consensus call on parts of the document s= oon.

= =C2=A0=C2=A0

= - OAuth 2.0 Token Binding

= =C2=A0 # draft-ietf-oauth-token-binding-05

= =C2=A0

= =C2=A0=C2=A0Remark: Document is moving along but we are lacking implementat= ions.

= =C2=A0=C2=A0

= - OAuth 2.0 Device Posture Signals

= =C2=A0 # draft-wdenniss-oauth-device-posture-01

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: Interest in the work but we are lacking content (maybe = even

= =C2=A0=C2=A0expertise in the group)

= =C2=A0

= - Reciprocal OAuth

= =C2=A0 # draft-hardt-oauth-mutual-02

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work and apparently no competing solutions. Th= e plan

= =C2=A0 is to run a call for adoption once we are allowed to add a new miles= tone

= =C2=A0=C2=A0to our charter.

= =C2=A0=C2=A0

= - Distributed OAuth

= =C2=A0 # draft-hardt-oauth-distributed-00

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work. Further work on the scope is needed.<= /u>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


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


--001a1144fd04fa57f50566c0021c-- From nobody Tue Mar 6 07:34:43 2018 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 ED615124E15 for ; Tue, 6 Mar 2018 07:34:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 1NspHF31AgEF for ; Tue, 6 Mar 2018 07:34:39 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50050.outbound.protection.outlook.com [40.107.5.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50410120454 for ; Tue, 6 Mar 2018 07:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e7AVNDEkMBge/i4IziJVCA8wUQyjQv8c6b4inv+JtgU=; b=of7OEXLe8kGCU0QfYf4+brgfBsoOMOiP0RcXaInlPmf+NrgCrTKE8KNS+YiEVkrQuHbjbdlamfPCOv++9p5KxT0+gaH/+/cuhnb7K//PF2FZdD/aCBZcTadImr6ZWctdgLW9aIh7nm5Nl4qchxtc3V+XaHZ7miSa2CKvXr7l56o= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1520.eurprd08.prod.outlook.com (10.167.210.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 6 Mar 2018 15:34:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::783f:d09c:fea6:f83d%17]) with mapi id 15.20.0548.016; Tue, 6 Mar 2018 15:34:35 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , Nat Sakimura CC: William Denniss , oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAAAZ8Gg Date: Tue, 6 Mar 2018 15:34:35 +0000 Message-ID: References: In-Reply-To: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.122.126] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1520; 7:W+Y+oXkvGJabjezALMsJEHun512qA3kQiOwBJ1sriaEpMeXLfCqVBAIljYR7+qisKlufjb1MM4kmjjE85XmLrUiWDQny046fcbDhdljuwCm6o+NfdCIMlfLiNLx7XJ8d67l7ap60XiXA0q5Yepx9oVOnqLiPjFDOb9IBbAlcvQLyCYhUfjliBg7Gl1I6HDubUJhc9C5gLQCET7Fpopi4iINxGUYX3ykXwrAVK7EB6wFZgVN3PTGUC5d+1riOBIir x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d6906327-e432-42cf-b8d6-08d58377c3f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1520; x-ms-traffictypediagnostic: VI1PR0801MB1520: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501244)(52105095)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1520; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1520; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(39380400002)(39860400002)(40434004)(53754006)(189003)(199004)(54896002)(66066001)(6506007)(6246003)(229853002)(54906003)(2900100001)(7736002)(110136005)(59450400001)(5660300001)(93886005)(105586002)(2950100002)(53546011)(33656002)(97736004)(5890100001)(5250100002)(76176011)(102836004)(316002)(106356001)(81156014)(6306002)(8676002)(186003)(7696005)(81166006)(86362001)(25786009)(606006)(99286004)(6116002)(3846002)(790700001)(478600001)(74316002)(68736007)(72206003)(3660700001)(26005)(9686003)(14454004)(2906002)(39060400002)(6436002)(236005)(55016002)(8936002)(3280700002)(53936002)(4326008)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1520; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eARLpzZFmJi+cIuiHspEdxwXl405LH1Ai/d9PFR5d1XtoYvDvR1AE+bsAUlj2binRU78RRxEzdiSPn1/iwK7xOwmPkR6sRqiiGu7DbyTEEBEfqN3XZDV7DYHE3ikHjaSVQPP1DZ9M/SdrPgGnvu+jeHsI26XAZdDSKTzpGglzfeXkjncQMeV+cIFITCRYwN/fVLgisymLHJPICZ+9uAcfon54Hh7l8mPh8L3kAsOENWk8nJcesCgw2B9cCbyfgf/VzSstPHWwgN5FA/yBn+BJVM2Mqyfsdl1D0vWaYM0TVhdffbrYSr5yY+r7MTf2WXMDoZuKyqLoz3J1jDLeotmMQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120BD4306848AA0D7D487AFAD90VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6906327-e432-42cf-b8d6-08d58377c3f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 15:34:35.4085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1520 Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 06 Mar 2018 15:34:42 -0000 --_000_VI1PR0801MB21120BD4306848AA0D7D487AFAD90VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb3VsZCBkbyB0aGF0LCBpZiBpdCBoZWxwcy4NCg0KRnJvbTogUmlmYWF0IFNoZWtoLVl1c2Vm IFttYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tXQ0KU2VudDogMDYgTWFyY2ggMjAxOCAxNjoy Mw0KVG86IE5hdCBTYWtpbXVyYQ0KQ2M6IEhhbm5lcyBUc2Nob2ZlbmlnOyBXaWxsaWFtIERlbm5p c3M7IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXMN Cg0KTmF0LA0KDQpEdXJpbmcgdGhlIGludGVyaW0gbWVldGluZywgMyBkcmFmdHMgbWVudGlvbmVk IGluIHRoZSBjb250ZXh0IG9mIERpc3RyaWJ1dGVkIE9BdXRoOg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wOA0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDIN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGll bmNlLTAwDQoNCg0KQnJpYW4sIEhhbm5lcywNCg0KQXJlIHlvdSBwbGFubmluZyBvbiBwcmVzZW50 aW5nIHlvdXIgZG9jdW1lbnRzPw0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCg0KDQoNCg0KT24g TW9uLCBNYXIgNSwgMjAxOCBhdCA4OjA5IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWls LmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpJIHdvdWxkIGJlIGludGVy ZXN0ZWQgaW4gaGVhcmluZyB0aGF0Lg0KDQpBbHNvLCBhcyBwYXJ0IG9mICJEaXN0cmlidXRlZCBP QXV0aCIsIGNhbiB3ZSBkbyBhIGJpdCBvZiByZS1jYXAgb24gc29tZSBvZiB0aGUgcHJldmlvdXMg ZHJhZnRzIG9uIHRoZSBzaW1pbGFyIHRvcGljIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJp bT8gaS5lLiwgQnJpYW4ncyBkcmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5kIG15IGRy YWZ0IChkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wOC50eHQ+KT8NCg0KQmVzdCwNCg0KTmF0DQoNCk9u IFR1ZSwgTWFyIDYsIDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdv b2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCkhhbm5lcyAmIFJp ZmFhdCwNCg0KSSB3b3VsZCBsaWtlIHRoZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IG9uIE9BdXRo IDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNy ZW1lbnRhbC1hdXRoKSBbYW4gdXBkYXRlIGZvciB3aGljaCB3aWxsIGJlIHBvc3RlZCB0b2RheV0g YW5kICJPQXV0aCAyLjAgRGV2aWNlIFBvc3R1cmUgU2lnbmFscyIgKGRyYWZ0LXdkZW5uaXNzLW9h dXRoLWRldmljZS1wb3N0dXJlKS4NCg0KSSBjYW4gYWxzbyBnaXZlIGFuIHVwZGF0ZSBvbiB0aGUg c3RhdHVzIG9mIERldmljZSBGbG93IChkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93KS4gSSBl eHBlY3QgdGhhdCB0byBiZSBzaG9ydCBub3cgdGhhdCBXR0xDIGhhcyBjb25jbHVkZWQgYW5kIHRo ZSBkb2N1bWVudCBoYXMgYWR2YW5jZWQuDQoNCkxpdHRsZSBsYXRlIHRvIHRoaXMgdGhyZWFkIGFu ZCBJIHNlZSB3ZSBhbHJlYWR5IGhhdmUgMiBzZXNzaW9ucyBpbiB0aGUgZHJhZnQgYWdlbmRhLCBi dXQgSSdkIGxpa2UgdG8gYWRkIG15IHN1cHBvcnQgdG8ga2VlcGluZyBib3RoIHNlc3Npb25zLCB0 aGVyZSdzIGFsd2F5cyBhIGxvdCB0byBkaXNjdXNzIGFuZCBpbiB0aGUgcGFzdCB3ZSd2ZSBiZWVu IGFibGUgdG8gdXNlIGFueSBzcGFyZSB0aW1lIHRvIGRpc2N1c3MgdGhlIHNlY3VyaXR5IHRvcGlj cyBvZiB0aGUgZGF5Lg0KDQpSZWdhcmRzLA0KV2lsbGlhbQ0KDQoNCg0KT24gVHVlLCBKYW4gMzAs IDIwMTggYXQgNDo0MCBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJt LmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0K DQpJdCBpcyB0aW1lIGFscmVhZHkgdG8gdGhpbmsgYWJvdXQgdGhlIGFnZW5kYSBmb3IgdGhlIG5l eHQgSUVURiBtZWV0aW5nLiBSaWZhYXQgYW5kIEkgd2VyZSB3b25kZXJpbmcgd2hldGhlciB3ZSBu ZWVkIG9uZSBvciB0d28gc2Vzc2lvbnMuIFdlIHdvdWxkIGxpa2UgdG8gbWFrZSB0aGUgZGVjaXNp b24gYmFzZWQgb24gdGhlIHRvcGljcyB3ZSB3aWxsIGRpc2N1c3MuIEJlbG93IHlvdSBjYW4gZmlu ZCBhIGZpcnN0IHZlcnNpb24gb2YgdGhlIGFnZW5kYSB3aXRoIGEgZmV3IHJlbWFya3MuIExldCB1 cyBrbm93IGlmIHlvdSBoYXZlIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGZvciBhZGRpdGlvbmFs IGFnZW5kYSBpdGVtcy4NCg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQoNCk9BdXRoIEFnZW5kYQ0K LS0tLS0tLS0tLS0tDQoNCi0gV2VsY29tZSBhbmQgU3RhdHVzIFVwZGF0ZSAgKENoYWlycykNCg0K ICAqIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIFJlcG9ydA0KDQogICogRG9jdW1lbnRzIGluIElF U0cgcHJvY2Vzc2luZw0KICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDcNCiAg ICAgIyBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wOA0KICAgICAjIGRyYWZ0LWlldGYtb2F1 dGgtandzcmVxLTE1DQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMQ0K DQogICAgICAgUmVtYXJrOiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlmIG5lZWRlZC4NCg0KLSAgSlNP TiBXZWIgVG9rZW4gQmVzdCBDdXJyZW50IFByYWN0aWNlcw0KICAgIyBkcmFmdC1pZXRmLW9hdXRo LWp3dC1iY3AtMDANCg0KICAgUmVtYXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMg ZG9jdW1lbnQuDQogICBNb3N0IGxpa2VseSB3ZSB3aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcgdGhl IGYyZiBtZWV0aW5nDQogICBidXQgcmF0aGVyIGJ5IHJlYWNoaW5nIG91dCB0byBpbmRpdmlkdWFs cyBhaGVhZCBvZiB0aW1lLg0KDQotICBPQXV0aCAyLjAgTXV0dWFsIFRMUyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIENlcnRpZmljYXRlIEJvdW5kIEFjY2VzcyBUb2tlbnMNCiAgICMgZHJhZnQt aWV0Zi1vYXV0aC1tdGxzLTA2DQoNCiAgIFJlbWFyazogQ291bGQgYmUgY29tcGxldGVkIGJ5IHRo ZSB0aW1lIG9mIHRoZSBJRVRGIG1lZXRpbmcuDQoNCi0gT0F1dGggU2VjdXJpdHkgVG9waWNzDQog ICMgZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDQNCg0KICBSZW1hcms6IFdlIGNv dWxkIGRvIGEgY29uc2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQoN Ci0gT0F1dGggMi4wIFRva2VuIEJpbmRpbmcNCiAgIyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJp bmRpbmctMDUNCg0KICBSZW1hcms6IERvY3VtZW50IGlzIG1vdmluZyBhbG9uZyBidXQgd2UgYXJl IGxhY2tpbmcgaW1wbGVtZW50YXRpb25zLg0KDQotIE9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBT aWduYWxzDQogICMgZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCg0KICBS ZW1hcms6IEludGVyZXN0IGluIHRoZSB3b3JrIGJ1dCB3ZSBhcmUgbGFja2luZyBjb250ZW50ICht YXliZSBldmVuDQogIGV4cGVydGlzZSBpbiB0aGUgZ3JvdXApDQoNCi0gUmVjaXByb2NhbCBPQXV0 aA0KICAjIGRyYWZ0LWhhcmR0LW9hdXRoLW11dHVhbC0wMg0KDQogIFJlbWFyazogV2UgaGFkIGEg dmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCiAgaW50 ZXJlc3QgaW4gdGhpcyB3b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGluZyBzb2x1dGlvbnMu IFRoZSBwbGFuDQogIGlzIHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFs bG93ZWQgdG8gYWRkIGEgbmV3IG1pbGVzdG9uZQ0KICB0byBvdXIgY2hhcnRlci4NCg0KLSBEaXN0 cmlidXRlZCBPQXV0aA0KICAjIGRyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLTAwDQoNCiAg UmVtYXJrOiBXZSBoYWQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFu ZCB0aGVyZSBpcw0KICBpbnRlcmVzdCBpbiB0aGlzIHdvcmsuIEZ1cnRoZXIgd29yayBvbiB0aGUg c2NvcGUgaXMgbmVlZGVkLg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KLS0NCg0KTmF0IFNha2ltdXJhDQoNCkNoYWlybWFuIG9mIHRo ZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB21120BD4306848AA0D7D487AFAD90VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9l bnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjb3VsZCBkbyB0aGF0LCBpZiBpdCBoZWxwcy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSaWZhYXQgU2hla2gtWXVzZWYg W21haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYgTWFy Y2ggMjAxOCAxNjoyMzxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2ltdXJhPGJyPg0KPGI+Q2M6PC9i PiBIYW5uZXMgVHNjaG9mZW5pZzsgV2lsbGlhbSBEZW5uaXNzOyBvYXV0aDxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EdXJpbmcgdGhlIGludGVyaW0gbWVldGluZywgMyBkcmFmdHMg bWVudGlvbmVkIGluIHRoZSBjb250ZXh0IG9mDQo8Yj5EaXN0cmlidXRlZCBPQXV0aDwvYj46PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wODwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3JzLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ft cGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5CcmlhbiwgSGFubmVzLDwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBwbGFu bmluZyBvbiBwcmVzZW50aW5nIHlvdXIgZG9jdW1lbnRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIE1hciA1LCAyMDE4IGF0IDg6MDkgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHRoYXQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYXMgcGFydCBvZiAmcXVvdDtE aXN0cmlidXRlZCBPQXV0aCZxdW90OywgY2FuIHdlIGRvIGEgYml0IG9mIHJlLWNhcCBvbiBzb21l IG9mIHRoZSBwcmV2aW91cyBkcmFmdHMgb24gdGhlIHNpbWlsYXIgdG9waWMgYXMgd2UgZGlzY3Vz c2VkIGluIHRoZSBpbnRlcmltPyBpLmUuLCBCcmlhbidzIGRyYWZ0ICh3aGVyZSBpcyB0aGUgbGlu ayBub3c/KSBhbmQgbXkgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQv ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wOC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNDQwMDg4Ij5kcmFmdC1zYWtpbXVyYS1vYXV0 aC1tZXRhPC9zcGFuPjwvYT4pPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1h ciA2LCAyMDE4IGF0IDM6MzAgQU0gV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86 d2Rlbm5pc3NAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzICZhbXA7IFJpZmFhdCw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkkgd291 bGQgbGlrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBvbiZuYnNwOzxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5PQXV0aCAyLjAgSW5j cmVtZW50YWwgQXV0aG9yaXphdGlvbiAoZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtaW5jcmVtZW50YWwt YXV0aCkgW2FuIHVwZGF0ZSBmb3Igd2hpY2ggd2lsbCBiZSBwb3N0ZWQgdG9kYXldDQogYW5kPC9z cGFuPiZuYnNwOyZxdW90O09BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzJnF1b3Q7IChk cmFmdC13ZGVubmlzcy1vYXV0aC1kZXZpY2UtcG9zdHVyZSkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIGFsc28gZ2l2ZSBhbiB1cGRh dGUgb24gdGhlIHN0YXR1cyBvZiBEZXZpY2UgRmxvdyAoZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2Ut ZmxvdykuIEkgZXhwZWN0IHRoYXQgdG8gYmUgc2hvcnQgbm93IHRoYXQgV0dMQyBoYXMgY29uY2x1 ZGVkIGFuZCB0aGUgZG9jdW1lbnQgaGFzIGFkdmFuY2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaXR0bGUgbGF0ZSB0byB0aGlzIHRocmVh ZCBhbmQgSSBzZWUgd2UgYWxyZWFkeSBoYXZlIDIgc2Vzc2lvbnMgaW4gdGhlIGRyYWZ0IGFnZW5k YSwgYnV0IEknZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRvIGtlZXBpbmcgYm90aCBzZXNzaW9u cywgdGhlcmUncyBhbHdheXMgYSBsb3QgdG8gZGlzY3VzcyBhbmQgaW4gdGhlIHBhc3Qgd2UndmUg YmVlbiBhYmxlIHRvIHVzZSBhbnkgc3BhcmUgdGltZSB0byBkaXNjdXNzDQogdGhlIHNlY3VyaXR5 IHRvcGljcyBvZiB0aGUgZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbGlhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUdWUsIEphbiAzMCwgMjAxOCBhdCA0OjQwIEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8 YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IaSBhbGwsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIHRpbWUgYWxyZWFk eSB0byB0aGluayBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgbmV4dCBJRVRGIG1lZXRpbmcuIFJp ZmFhdCBhbmQgSSB3ZXJlIHdvbmRlcmluZyB3aGV0aGVyIHdlIG5lZWQgb25lIG9yIHR3byBzZXNz aW9ucy4gV2Ugd291bGQgbGlrZSB0byBtYWtlIHRoZSBkZWNpc2lvbiBiYXNlZA0KIG9uIHRoZSB0 b3BpY3Mgd2Ugd2lsbCBkaXNjdXNzLiBCZWxvdyB5b3UgY2FuIGZpbmQgYSBmaXJzdCB2ZXJzaW9u IG9mIHRoZSBhZ2VuZGEgd2l0aCBhIGZldyByZW1hcmtzLiBMZXQgdXMga25vdyBpZiB5b3UgaGF2 ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBmb3IgYWRkaXRpb25hbCBhZ2VuZGEgaXRlbXMuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgUmlmYWF0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPk9BdXRoIEFnZW5kYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi0gV2VsY29tZSBhbmQgU3RhdHVzIFVwZGF0ZSZuYnNwOyAoQ2hhaXJzKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICogT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgUmVwb3J0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyogRG9jdW1lbnRzIGluIElF U0cgcHJvY2Vzc2luZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA3DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IyBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wOA0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyMgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC10 b2tlbi1leGNoYW5nZS0xMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7UmVtYXJr OiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlmIG5lZWRlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0mbmJzcDsgSlNPTiBXZWIgVG9r ZW4gQmVzdCBDdXJyZW50IFByYWN0aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDANCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVt YXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBNb3N0IGxpa2VseSB3ZSB3 aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcgdGhlIGYyZiBtZWV0aW5nDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YnV0IHJhdGhlciBieSBy ZWFjaGluZyBvdXQgdG8gaW5kaXZpZHVhbHMgYWhlYWQgb2YgdGltZS4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSZuYnNwOyBPQXV0aCAyLjAgTXV0dWFsIFRMUyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIENlcnRpZmljYXRlIEJvdW5kIEFjY2VzcyBUb2tlbnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICMgZHJh ZnQtaWV0Zi1vYXV0aC1tdGxzLTA2DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBSZW1hcms6IENvdWxkIGJlIGNvbXBsZXRlZCBieSB0aGUgdGltZSBvZiB0aGUgSUVU RiBtZWV0aW5nLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9B dXRoIFNlY3VyaXR5IFRvcGljczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wNA0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtSZW1hcms6IFdlIGNvdWxkIGRv IGEgY29uc2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gT0F1dGggMi4wIFRva2VuIEJpbmRpbmc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaWV0Zi1v YXV0aC10b2tlbi1iaW5kaW5nLTA1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwO1JlbWFyazogRG9jdW1lbnQgaXMgbW92aW5nIGFsb25nIGJ1dCB3ZSBhcmUgbGFja2lu ZyBpbXBsZW1lbnRhdGlvbnMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0g T0F1dGggMi4wIERldmljZSBQb3N0dXJlIFNpZ25hbHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1 cmUtMDENCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7UmVt YXJrOiBJbnRlcmVzdCBpbiB0aGUgd29yayBidXQgd2UgYXJlIGxhY2tpbmcgY29udGVudCAobWF5 YmUgZXZlbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwO2V4cGVydGlzZSBpbiB0aGUgZ3JvdXApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi0gUmVjaXByb2NhbCBPQXV0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgIyBkcmFmdC1oYXJkdC1vYXV0aC1tdXR1YWwtMDINCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7IFJlbWFyazogV2UgaGFkIGEgdmlydHVhbCBpbnRlcmltIG1lZXRp bmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtpbnRlcmVzdCBpbiB0aGlzIHdvcmsgYW5kIGFwcGFy ZW50bHkgbm8gY29tcGV0aW5nIHNvbHV0aW9ucy4gVGhlIHBsYW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IGlzIHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9u IG9uY2Ugd2UgYXJlIGFsbG93ZWQgdG8gYWRkIGEgbmV3IG1pbGVzdG9uZQ0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO3RvIG91ciBjaGFydGVyLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIERpc3RyaWJ1dGVkIE9BdXRoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRyYWZ0LWhhcmR0 LW9hdXRoLWRpc3RyaWJ1dGVkLTAwDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyBSZW1hcms6IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMg YW5kIHRoZXJlIGlzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7aW50ZXJlc3QgaW4gdGhpcyB3b3JrLiBGdXJ0aGVyIHdvcmsgb24gdGhlIHNjb3Bl IGlzIG5lZWRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sDQogdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5OYXQgU2FraW11cmE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Q2hhaXJtYW4g b2YgdGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB21120BD4306848AA0D7D487AFAD90VI1PR0801MB2112_-- From nobody Tue Mar 6 08:31:51 2018 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 47F7B1274D2 for ; Tue, 6 Mar 2018 08:31:50 -0800 (PST) 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, 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 cjaiIypyj3xk for ; Tue, 6 Mar 2018 08:31:47 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 7EE0C127076 for ; Tue, 6 Mar 2018 08:31:47 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id q24so22672875ioh.8 for ; Tue, 06 Mar 2018 08:31:47 -0800 (PST) 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=CeILREAm9Je+mQ2skkMK2+2s1+9wSKATlsT/F1daqiU=; b=fYKsnO80nRcy9BzpWxsuibKfyP4kO1c+iiC8dZ9uWfzcapI9dz+TjaRLFCYcbQ4gwr A6n0uDUVlLgnjuxMfOFbKzHz9p21w0gWwstLcbev4p4OauxRH58KI/PfUNWhhj3IqLjG 7BxrAagXKQtKpdA6HunK4yKZLXwaPQSn9rF7k= 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=CeILREAm9Je+mQ2skkMK2+2s1+9wSKATlsT/F1daqiU=; b=VdcFGqhJKX9MUDnUQO9B2XRYmO6a5a7wxhAXGKtyK6ErHV1X3Zhgt80ZlJN36Sc21z 7QOAFThTiUMppcvS3ce4CDnUcuM4SeILZabY/hGwrteADak1ZVZWaWLNMjRAcqTgrtyR boH02TBmuzilDKJ8pAJXhl3J71l0clQBlvpRvNmQ6MGlN3azBqY0xkpK2e9MbsdKShLy 9v6YAdHoKjTUZrCNNRZP3nQhCDTcO5KARQu+BeVA7W3/jz0ZyOTjyciCEJ4Ht8IYBMIU 0bE1c22LMsTmKcQ1Sb17IIQN4D18+v5e2Yt0nCVxnAxcoDTpkSFB+xOIYsDNHUWklPRo Q9+Q== X-Gm-Message-State: APf1xPDVWbva9Fs+nGKlwzZcUR682u2cyI5ujdGojxh22Dj4xSmRB/bR hgzf1tmUeepkQnfsFrt1IHm7A1QMQQmLkugRMlzGqV9Kad1B3EpUJXiXVMiJesbxom5c39AReBr TDCy4HD1BZfU7NA== X-Google-Smtp-Source: AG47ELtGBLi3LfaNM/BMNOqQY03C5xuu7szRTkvIMz43s6NAUcGPP89RoE85+phcta6ZGjgtmSTgl9d8C3RAF4eu5gM= X-Received: by 10.107.173.12 with SMTP id w12mr20654677ioe.282.1520353906634; Tue, 06 Mar 2018 08:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.73.200 with HTTP; Tue, 6 Mar 2018 08:31:16 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Tue, 6 Mar 2018 09:31:16 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: Nat Sakimura , oauth Content-Type: multipart/alternative; boundary="001a114468f689ce990566c0fa9d" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 06 Mar 2018 16:31:50 -0000 --001a114468f689ce990566c0fa9d Content-Type: text/plain; charset="UTF-8" I hadn't previously been planning on it but am happy to do so. On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef wrote: > Nat, > > During the interim meeting, 3 drafts mentioned in the context of *Distributed > OAuth*: > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > *Brian, Hannes,* > > Are you planning on presenting your documents? > > Regards, > Rifaat > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > >> I would be interested in hearing that. >> >> Also, as part of "Distributed OAuth", can we do a bit of re-cap on some >> of the previous drafts on the similar topic as we discussed in the interim? >> i.e., Brian's draft (where is the link now?) and my draft ( >> draft-sakimura-oauth-meta >> )? >> >> Best, >> >> Nat >> >> On Tue, Mar 6, 2018 at 3:30 AM William Denniss >> wrote: >> >>> Hannes & Rifaat, >>> >>> I would like the opportunity to present on OAuth 2.0 Incremental >>> Authorization (draft-wdenniss-oauth-incremental-auth) [an update for >>> which will be posted today] and "OAuth 2.0 Device Posture Signals" >>> (draft-wdenniss-oauth-device-posture). >>> >>> I can also give an update on the status of Device Flow >>> (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC >>> has concluded and the document has advanced. >>> >>> Little late to this thread and I see we already have 2 sessions in the >>> draft agenda, but I'd like to add my support to keeping both sessions, >>> there's always a lot to discuss and in the past we've been able to use any >>> spare time to discuss the security topics of the day. >>> >>> Regards, >>> William >>> >>> >>> >>> >>> On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < >>> Hannes.Tschofenig@arm.com> wrote: >>> >>>> Hi all, >>>> >>>> >>>> >>>> It is time already to think about the agenda for the next IETF meeting. >>>> Rifaat and I were wondering whether we need one or two sessions. We would >>>> like to make the decision based on the topics we will discuss. Below you >>>> can find a first version of the agenda with a few remarks. Let us know if >>>> you have comments or suggestions for additional agenda items. >>>> >>>> >>>> >>>> Ciao >>>> Hannes & Rifaat >>>> >>>> >>>> >>>> OAuth Agenda >>>> >>>> ------------ >>>> >>>> >>>> >>>> - Welcome and Status Update (Chairs) >>>> >>>> >>>> >>>> * OAuth Security Workshop Report >>>> >>>> >>>> >>>> * Documents in IESG processing >>>> >>>> # draft-ietf-oauth-device-flow-07 >>>> >>>> # draft-ietf-oauth-discovery-08 >>>> >>>> # draft-ietf-oauth-jwsreq-15 >>>> >>>> # draft-ietf-oauth-token-exchange-11 >>>> >>>> >>>> >>>> Remark: Status updates only if needed. >>>> >>>> >>>> >>>> - JSON Web Token Best Current Practices >>>> >>>> # draft-ietf-oauth-jwt-bcp-00 >>>> >>>> >>>> >>>> Remark: We are lacking reviews on this document. >>>> >>>> Most likely we will not get them during the f2f meeting >>>> >>>> but rather by reaching out to individuals ahead of time. >>>> >>>> >>>> >>>> - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound >>>> Access Tokens >>>> >>>> # draft-ietf-oauth-mtls-06 >>>> >>>> >>>> >>>> Remark: Could be completed by the time of the IETF meeting. >>>> >>>> >>>> >>>> - OAuth Security Topics >>>> >>>> # draft-ietf-oauth-security-topics-04 >>>> >>>> >>>> >>>> Remark: We could do a consensus call on parts of the document soon. >>>> >>>> >>>> >>>> - OAuth 2.0 Token Binding >>>> >>>> # draft-ietf-oauth-token-binding-05 >>>> >>>> >>>> >>>> Remark: Document is moving along but we are lacking implementations. >>>> >>>> >>>> >>>> - OAuth 2.0 Device Posture Signals >>>> >>>> # draft-wdenniss-oauth-device-posture-01 >>>> >>>> >>>> >>>> Remark: Interest in the work but we are lacking content (maybe even >>>> >>>> expertise in the group) >>>> >>>> >>>> >>>> - Reciprocal OAuth >>>> >>>> # draft-hardt-oauth-mutual-02 >>>> >>>> >>>> >>>> Remark: We had a virtual interim meeting on this topic and there is >>>> >>>> interest in this work and apparently no competing solutions. The plan >>>> >>>> is to run a call for adoption once we are allowed to add a new >>>> milestone >>>> >>>> to our charter. >>>> >>>> >>>> >>>> - Distributed OAuth >>>> >>>> # draft-hardt-oauth-distributed-00 >>>> >>>> >>>> >>>> Remark: We had a virtual interim meeting on this topic and there is >>>> >>>> interest in this work. Further work on the scope is needed. >>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>> confidential and may also be privileged. If you are not the intended >>>> recipient, please notify the sender immediately and do not disclose the >>>> contents to any other person, use it for any purpose, or store or copy the >>>> information in any medium. Thank you. >>>> _______________________________________________ >>>> 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 >>> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> >> _______________________________________________ >> 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.* --001a114468f689ce990566c0fa9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hadn't previously been planning on it but am happy t= o do so.

On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef <= rifaat.ietf@gmai= l.com> wrote:
Brian, Ha= nnes,

Are you planning on presenting your docu= ments?

Regards,
=C2=A0Rifaat
<= br>




=

On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura <saki= mura@gmail.com> wrote:
I would be interested in hearing that.=C2=A0

Also= , as part of "Distributed OAuth", can we do a bit of re-cap on so= me of the previous drafts on the similar topic as we discussed in the inter= im? i.e., Brian's draft (where is the link now?) and my draft (draft-sakimura-oauth-me= ta)?=C2=A0

Best,=C2=A0

Nat

On Tue, Mar 6, 2018 at 3:30 AM William De= nniss <wdenniss= @google.com> wrote:
Hannes & Rifaat,

I would like the opportuni= ty to present on=C2=A0OAuth 2.0 Incremental Authorizatio= n (draft-wdenniss-oauth-incremental-auth) [an update for which will be= posted today] and=C2=A0"OAuth 2.0 Device Posture Signals"= (draft-wdenniss-oauth-device-posture).

I can= also give an update on the status of Device Flow (draft-ietf-oauth-device-= flow). I expect that to be short now that WGLC has concluded and the d= ocument has advanced.

Little late to this thread a= nd I see we already have 2 sessions in the draft agenda, but I'd like t= o add my support to keeping both sessions, there's always a lot to disc= uss and in the past we've been able to use any spare time to discuss th= e security topics of the day.

Regards,
W= illiam




On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig = <Hannes.T= schofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think about the agenda for the= next IETF meeting. Rifaat and I were wondering whether we need one or two = sessions. We would like to make the decision based on the topics we will di= scuss. Below you can find a first version of the agenda with a few remarks. Let us know if you have comments= or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

= OAuth Agenda

= ------------

= =C2=A0

= - Welcome and Status Update=C2=A0 (Chairs)

= =C2=A0

= =C2=A0 * OAuth Security Workshop Report

= =C2=A0

= =C2=A0=C2=A0* Documents in IESG processing

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-08

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

= =C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-exchange-11

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates only if needed.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

= -=C2=A0 JSON Web Token Best Current Practices

= =C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

= =C2=A0=C2=A0=C2=A0

= =C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this document.

= =C2=A0=C2=A0 Most likely we will not get them during the f2f meeting

= =C2=A0=C2=A0=C2=A0but rather by reaching out to individuals ahead of time.

= =C2=A0=C2=A0=C2=A0

= -=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Ac= cess Tokens

= =C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

= =C2=A0

= =C2=A0=C2=A0 Remark: Could be completed by the time of the IETF meeting.

= =C2=A0=C2=A0=C2=A0

= - OAuth Security Topics

= =C2=A0 # draft-ietf-oauth-security-topics-04

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: We could do a consensus call on parts of the document s= oon.

= =C2=A0=C2=A0

= - OAuth 2.0 Token Binding

= =C2=A0 # draft-ietf-oauth-token-binding-05

= =C2=A0

= =C2=A0=C2=A0Remark: Document is moving along but we are lacking implementat= ions.

= =C2=A0=C2=A0

= - OAuth 2.0 Device Posture Signals

= =C2=A0 # draft-wdenniss-oauth-device-posture-01

= =C2=A0=C2=A0

= =C2=A0=C2=A0Remark: Interest in the work but we are lacking content (maybe = even

= =C2=A0=C2=A0expertise in the group)

= =C2=A0

= - Reciprocal OAuth

= =C2=A0 # draft-hardt-oauth-mutual-02

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work and apparently no competing solutions. Th= e plan

= =C2=A0 is to run a call for adoption once we are allowed to add a new miles= tone

= =C2=A0=C2=A0to our charter.

= =C2=A0=C2=A0

= - Distributed OAuth

= =C2=A0 # draft-hardt-oauth-distributed-00

= =C2=A0

= =C2=A0 Remark: We had a virtual interim meeting on this topic and there is

= =C2=A0=C2=A0interest in this work. Further work on the scope is needed.<= /u>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


_______________________________________________
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. --001a114468f689ce990566c0fa9d-- From nobody Tue Mar 6 15:33:32 2018 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 6AAF012D880 for ; Tue, 6 Mar 2018 15:33:20 -0800 (PST) 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, 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 cwcJcsKl1wEa for ; Tue, 6 Mar 2018 15:33:16 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 2E8B912DA06 for ; Tue, 6 Mar 2018 15:33:16 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id v194so1069555itb.0 for ; Tue, 06 Mar 2018 15:33:16 -0800 (PST) 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=YV8zSEpYhtvj9yHSLsRiNj2NpSYHS+vxjZXeTI2PEjE=; b=FKp6cOy7s4WqC/MXx2OtZicn2brBC/VTQjqbrPieABDrqvZWi8sl3w9nZMbylCwyXp dooV/ZhYr3GfwabBAv8mNjRpvZ7ZP2QTf4F7JtSbZ3CgIyfOG0Yz/b/9SGerTLPomuYL rLShoXcEB+Y1KRTpM9BcFxHFz0590n4Pdvl4A= 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=YV8zSEpYhtvj9yHSLsRiNj2NpSYHS+vxjZXeTI2PEjE=; b=X7hHmGR7CJmKefy2yzuISNUskpW3a7XacHV9Gs3VYijz8EsXKPPl81KjdM5VdHjLuc 4ia1fFRFlNbcCY8J6uZgAmkX5IdkkYPSAAhB/FRLQGHDKiy+ZM/F69VdnC2anCuw6WYh HZMJQYl5hJnBRDb0jlw7BbderatBmTFpkolzLpSspfBCCyok/hcpVquz7G7JUShaLZlo UC9+AhECPlsI3B/6floUXssdT4E0lF/AQWBHlS6DZz3t/Hm4AZlVkMy8JBPll7H+0nCq KXYw23tXsVgUEAMoq9jdOr5wlAWEzgnzXB3PtZSfOXqN6NJOfLsmSmS+OKUcOHkC/Yrx 9UHw== X-Gm-Message-State: AElRT7F/xspQ0gwLW8omnhiUwzBPQrmkzuezxEBsydF/qfGX3TaJeHAT k9eb+gFN4zq6F7ueNUZnDBgMhlgc5hNUdZyzsSJWDGNi4gQLVyTG72NJoAT5wNkM15YJqL1eeJj 51/G2/kcaPh6xCg== X-Google-Smtp-Source: AG47ELtzH0wFpZ1yBdxB3JtIs8JPx5KGaYAFrTZ6kFq3obzc5BFMfKlM3pddN5y7JbIvT4JZZu98UCVKZUc/k1emDWk= X-Received: by 10.36.160.136 with SMTP id o130mr20185942ite.37.1520379195408; Tue, 06 Mar 2018 15:33:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.73.200 with HTTP; Tue, 6 Mar 2018 15:32:44 -0800 (PST) In-Reply-To: <342677c3-2370-413e-efbc-f0a03da509f4@connect2id.com> References: <342677c3-2370-413e-efbc-f0a03da509f4@connect2id.com> From: Brian Campbell Date: Tue, 6 Mar 2018 16:32:44 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c04a148dde29c0566c6dda5" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-07: jwks_uri with registered x5t#S256 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, 06 Mar 2018 23:33:24 -0000 --94eb2c04a148dde29c0566c6dda5 Content-Type: text/plain; charset="UTF-8" I'd say it's really an implementation detail. But I think both 1 or 2 would work. I'd probably opt for 1 because a JWK will always have the key while "x5t#S256" is optional so some more work needs to happen to ensure it is present and/or deal with it being absent. This harks back to the question you raised in August last year[1] about weather the JWK x5c parameter was needed vs. just using the JWK's public key. I still kinda feel that matching on the key material is preferable but there was push-back on that. [1] https://www.ietf.org/mail-archive/web/oauth/current/msg17482.html On Tue, Mar 6, 2018 at 3:10 AM, Vladimir Dzhuvinov wrote: > A question came up in a conversation with a developer: > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.2.2 > > What should the AS do when authenticating a client when the client has > registered a JWK (jwks_uri) with a "x5t#S256" parameter instead of a "x5c"? > > > 1. Ignore the registered cert "x5t#S256" and match the key material of > the received cert with the key material of the registered JWK. > > 2. Match the registered cert "x5t#S256" with the "x5t#S256" of the > received cert. > > 3. Something else? > > > Thanks, > > Vladimir > > _______________________________________________ > 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.* --94eb2c04a148dde29c0566c6dda5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd say it's really an implementation detail.= But I think both 1 or 2 would work. I'd probably opt for 1 because a J= WK will always have the key while "x5t#S256" is optional so some = more work needs to happen to ensure it is present and/or deal with it being= absent.

This harks back to the question you raised in August= last year[1] about weather the JWK x5c parameter was needed vs. just using= the=C2=A0JWK's public key. I still kinda feel that matching on the key= material is preferable but there was push-back on that.

=C2=A0[1] = https://www.ietf.org/mail-archive/web/oauth/current/msg17482.html

On Tue, Ma= r 6, 2018 at 3:10 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20
A question came up in a conversation with a developer:

https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section= -2.2.2

What should the AS do when authenticating a client when the client has registered a JWK (jwks_uri) with a "x5t#S256" parameter i= nstead of a "x5c"?

  1. Ignore the registered cert "x5t#S256" and match the key material of the received cert with the key material of the registered JWK.

  2. Match the registered cert "x5t#S256" with the "x5t= #S256" of the received cert.

  3. Something else?

Thanks,

Vladimir

_______________________________________________
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. --94eb2c04a148dde29c0566c6dda5-- From nobody Tue Mar 6 23:00:18 2018 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 890FC127601 for ; Tue, 6 Mar 2018 23:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 JVeLmyGTtRX8 for ; Tue, 6 Mar 2018 23:00:10 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479AF124C27 for ; Tue, 6 Mar 2018 23:00:09 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id 9FAD1196886; Wed, 7 Mar 2018 16:00:08 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 3EF5E4E0046; Wed, 7 Mar 2018 16:00:08 +0900 (JST) Received: from nriea03.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w27708d8028224; Wed, 7 Mar 2018 16:00:08 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp with ESMTP id w277077Y028221; Wed, 07 Mar 2018 16:00:08 +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 w27707rC054514; Wed, 7 Mar 2018 16:00:07 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w27707Tg054513; Wed, 7 Mar 2018 16:00:07 +0900 X-Authentication-Warning: nrims00a.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 nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w27707X4054510; Wed, 7 Mar 2018 16:00:07 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM02PA.cu.nri.co.jp (172.159.253.20) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 7 Mar 2018 16:00:06 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.179) by ex.nri.co.jp (192.51.23.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 7 Mar 2018 16:00:04 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ETo8GLZHBik9vg1f1FU4r7rPdhG0bAWbDNToet+0638=; b=BiOTj4eHv+j263FvqNJmsoCthHpTzCzGp1lsbzAArTqnBiReARRmFxEG52VfoWmvhFA23avc4OZrXVsUJExW/knOTccg9y2Hg+dd/vwQgsXAREh14CNYbREWQIUEGfTjS+oa4zVco6qlC05UL7W5ikuo9oSkw7abj+xripSMflg= Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com (10.174.225.12) by TY1PR01MB1865.jpnprd01.prod.outlook.com (52.133.161.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 7 Mar 2018 07:00:05 +0000 Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) by TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) with mapi id 15.20.0548.016; Wed, 7 Mar 2018 07:00:05 +0000 From: n-sakimura To: Brian Campbell , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXA= Date: Wed, 7 Mar 2018 07:00:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB1865; 7:SbpXj1/WB9f66RG7Py7i33lacFHc/2nrsGxse8ypgoVqC8kB00fxJmKM4m5BbyvEjx7AqISVLa1nHrlOvdRvm+Bqc+Q/jqgkiot7EVQ8gK+hZkYOopTB3XlPEKpfKJpQu9qypZSOcZMRZR6SxVSxDFhKnt16vzmLxILHnlpBR9vUwxhLEl/4m0b90SB6cjaOMB+ygBlfoExxU0GZbp4aqAy0v0qJjK0A6Ay3OKzl3LTG9/oaeBmQCD/8Eq0JOw33 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4168b3ab-44da-47ef-7a6d-08d583f90e77 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB1865; x-ms-traffictypediagnostic: TY1PR01MB1865: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231220)(944501244)(52105095)(6041288)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:TY1PR01MB1865; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB1865; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(376002)(39380400002)(366004)(346002)(199004)(189003)(36304003)(40434004)(53754006)(2906002)(33656002)(105586002)(26005)(3280700002)(25786009)(77096007)(76176011)(6246003)(316002)(59450400001)(53936002)(4326008)(102836004)(106356001)(6436002)(236005)(9686003)(53546011)(6506007)(54896002)(6306002)(55016002)(2950100002)(5890100001)(186003)(68736007)(606006)(86362001)(81156014)(81166006)(8676002)(5660300001)(8936002)(2900100001)(229853002)(110136005)(66066001)(966005)(14454004)(478600001)(3660700001)(74316002)(74482002)(7736002)(7696005)(99286004)(97736004)(3846002)(39060400002)(93886005)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB1865; H:TY1PR01MB1054.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: herYmjxgCAjS/wwPPT1u4HVe9cp6WA6DwHNqzMuyblnBKrbA9CdPLe2dN+t6WkVdBfsryiAkwdh/0T1NG+CUrRrhBU+cSSEAJvnRwn5dWevbIAXzR2ecYiCRsduKIJuWFroYkiYiAjJXZmJzB2cMcKSehqLjXbzTV8yT6f6yK+CSZ7+V9ERW4IpGQXhWD4KnFXqmdRAUKCiEUWFNUHW8+uzkTEdzNe9WWuqC1UHeboC85EhUcitNz/kI5P2qwZcc0lmYaldRu8vk6/iuD/VO9gK4W2j6VqmQxdyTXdW3isQE9jKqDKJQlFSGO235h128dpZ6xrxdsPr4qL7+62xbYg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY1PR01MB1054A105034F55F6B810D7C3F9D80TY1PR01MB1054jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4168b3ab-44da-47ef-7a6d-08d583f90e77 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2018 07:00:05.4818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1865 X-OrganizationHeadersPreserved: TY1PR01MB1865.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 07 Mar 2018 07:00:17 -0000 --_000_TY1PR01MB1054A105034F55F6B810D7C3F9D80TY1PR01MB1054jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlbiBsZXQgdXMgZG8gaXQuIFdlIG5lZWQgdG8gcHV0IGFsbCB0aGUgcHJvcG9zYWxzIG9uIHRo ZSB0YWJsZSBhbmQgc3RyYXRlZ2l6ZSB0aGUgZGVzaWduLg0KUGVyaGFwcyB3ZSBuZWVkIGEgc2lk ZSBtZWV0aW5nIGFzIHdlbGwuDQoNCm5hdA0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAwNywgMjAxOCAxOjMxIEFNDQpUbzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZh YXQuaWV0ZkBnbWFpbC5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCkkgaGFkbid0IHByZXZpb3Vz bHkgYmVlbiBwbGFubmluZyBvbiBpdCBidXQgYW0gaGFwcHkgdG8gZG8gc28uDQoNCk9uIFR1ZSwg TWFyIDYsIDIwMTggYXQgODoyMiBBTSwgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KTmF0LA0KDQpE dXJpbmcgdGhlIGludGVyaW0gbWVldGluZywgMyBkcmFmdHMgbWVudGlvbmVkIGluIHRoZSBjb250 ZXh0IG9mIERpc3RyaWJ1dGVkIE9BdXRoOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wOA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDINCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwDQoNCg0K QnJpYW4sIEhhbm5lcywNCg0KQXJlIHlvdSBwbGFubmluZyBvbiBwcmVzZW50aW5nIHlvdXIgZG9j dW1lbnRzPw0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCg0KDQoNCg0KT24gTW9uLCBNYXIgNSwg MjAxOCBhdCA4OjA5IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86 c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gaGVh cmluZyB0aGF0Lg0KDQpBbHNvLCBhcyBwYXJ0IG9mICJEaXN0cmlidXRlZCBPQXV0aCIsIGNhbiB3 ZSBkbyBhIGJpdCBvZiByZS1jYXAgb24gc29tZSBvZiB0aGUgcHJldmlvdXMgZHJhZnRzIG9uIHRo ZSBzaW1pbGFyIHRvcGljIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJpbT8gaS5lLiwgQnJp YW4ncyBkcmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5kIG15IGRyYWZ0IChkcmFmdC1z YWtpbXVyYS1vYXV0aC1tZXRhPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtc2FraW11 cmEtb2F1dGgtbWV0YS0wOC50eHQ+KT8NCg0KQmVzdCwNCg0KTmF0DQoNCk9uIFR1ZSwgTWFyIDYs IDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFp bHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCkhhbm5lcyAmIFJpZmFhdCwNCg0KSSB3 b3VsZCBsaWtlIHRoZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IG9uIE9BdXRoIDIuMCBJbmNyZW1l bnRhbCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNyZW1lbnRhbC1hdXRo KSBbYW4gdXBkYXRlIGZvciB3aGljaCB3aWxsIGJlIHBvc3RlZCB0b2RheV0gYW5kICJPQXV0aCAy LjAgRGV2aWNlIFBvc3R1cmUgU2lnbmFscyIgKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1w b3N0dXJlKS4NCg0KSSBjYW4gYWxzbyBnaXZlIGFuIHVwZGF0ZSBvbiB0aGUgc3RhdHVzIG9mIERl dmljZSBGbG93IChkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93KS4gSSBleHBlY3QgdGhhdCB0 byBiZSBzaG9ydCBub3cgdGhhdCBXR0xDIGhhcyBjb25jbHVkZWQgYW5kIHRoZSBkb2N1bWVudCBo YXMgYWR2YW5jZWQuDQoNCkxpdHRsZSBsYXRlIHRvIHRoaXMgdGhyZWFkIGFuZCBJIHNlZSB3ZSBh bHJlYWR5IGhhdmUgMiBzZXNzaW9ucyBpbiB0aGUgZHJhZnQgYWdlbmRhLCBidXQgSSdkIGxpa2Ug dG8gYWRkIG15IHN1cHBvcnQgdG8ga2VlcGluZyBib3RoIHNlc3Npb25zLCB0aGVyZSdzIGFsd2F5 cyBhIGxvdCB0byBkaXNjdXNzIGFuZCBpbiB0aGUgcGFzdCB3ZSd2ZSBiZWVuIGFibGUgdG8gdXNl IGFueSBzcGFyZSB0aW1lIHRvIGRpc2N1c3MgdGhlIHNlY3VyaXR5IHRvcGljcyBvZiB0aGUgZGF5 Lg0KDQpSZWdhcmRzLA0KV2lsbGlhbQ0KDQoNCg0KT24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0 MCBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpJdCBpcyB0aW1l IGFscmVhZHkgdG8gdGhpbmsgYWJvdXQgdGhlIGFnZW5kYSBmb3IgdGhlIG5leHQgSUVURiBtZWV0 aW5nLiBSaWZhYXQgYW5kIEkgd2VyZSB3b25kZXJpbmcgd2hldGhlciB3ZSBuZWVkIG9uZSBvciB0 d28gc2Vzc2lvbnMuIFdlIHdvdWxkIGxpa2UgdG8gbWFrZSB0aGUgZGVjaXNpb24gYmFzZWQgb24g dGhlIHRvcGljcyB3ZSB3aWxsIGRpc2N1c3MuIEJlbG93IHlvdSBjYW4gZmluZCBhIGZpcnN0IHZl cnNpb24gb2YgdGhlIGFnZW5kYSB3aXRoIGEgZmV3IHJlbWFya3MuIExldCB1cyBrbm93IGlmIHlv dSBoYXZlIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGZvciBhZGRpdGlvbmFsIGFnZW5kYSBpdGVt cy4NCg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQoNCk9BdXRoIEFnZW5kYQ0KLS0tLS0tLS0tLS0t DQoNCi0gV2VsY29tZSBhbmQgU3RhdHVzIFVwZGF0ZSAgKENoYWlycykNCg0KICAqIE9BdXRoIFNl Y3VyaXR5IFdvcmtzaG9wIFJlcG9ydA0KDQogICogRG9jdW1lbnRzIGluIElFU0cgcHJvY2Vzc2lu Zw0KICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDcNCiAgICAgIyBkcmFmdC1p ZXRmLW9hdXRoLWRpc2NvdmVyeS0wOA0KICAgICAjIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE1 DQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZS0xMQ0KDQogICAgICAgUmVt YXJrOiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlmIG5lZWRlZC4NCg0KLSAgSlNPTiBXZWIgVG9rZW4g QmVzdCBDdXJyZW50IFByYWN0aWNlcw0KICAgIyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iY3AtMDAN Cg0KICAgUmVtYXJrOiBXZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1lbnQuDQog ICBNb3N0IGxpa2VseSB3ZSB3aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcgdGhlIGYyZiBtZWV0aW5n DQogICBidXQgcmF0aGVyIGJ5IHJlYWNoaW5nIG91dCB0byBpbmRpdmlkdWFscyBhaGVhZCBvZiB0 aW1lLg0KDQotICBPQXV0aCAyLjAgTXV0dWFsIFRMUyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IENlcnRpZmljYXRlIEJvdW5kIEFjY2VzcyBUb2tlbnMNCiAgICMgZHJhZnQtaWV0Zi1vYXV0aC1t dGxzLTA2DQoNCiAgIFJlbWFyazogQ291bGQgYmUgY29tcGxldGVkIGJ5IHRoZSB0aW1lIG9mIHRo ZSBJRVRGIG1lZXRpbmcuDQoNCi0gT0F1dGggU2VjdXJpdHkgVG9waWNzDQogICMgZHJhZnQtaWV0 Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDQNCg0KICBSZW1hcms6IFdlIGNvdWxkIGRvIGEgY29u c2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQoNCi0gT0F1dGggMi4w IFRva2VuIEJpbmRpbmcNCiAgIyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWJpbmRpbmctMDUNCg0K ICBSZW1hcms6IERvY3VtZW50IGlzIG1vdmluZyBhbG9uZyBidXQgd2UgYXJlIGxhY2tpbmcgaW1w bGVtZW50YXRpb25zLg0KDQotIE9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzDQogICMg ZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCg0KICBSZW1hcms6IEludGVy ZXN0IGluIHRoZSB3b3JrIGJ1dCB3ZSBhcmUgbGFja2luZyBjb250ZW50IChtYXliZSBldmVuDQog IGV4cGVydGlzZSBpbiB0aGUgZ3JvdXApDQoNCi0gUmVjaXByb2NhbCBPQXV0aA0KICAjIGRyYWZ0 LWhhcmR0LW9hdXRoLW11dHVhbC0wMg0KDQogIFJlbWFyazogV2UgaGFkIGEgdmlydHVhbCBpbnRl cmltIG1lZXRpbmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCiAgaW50ZXJlc3QgaW4gdGhp cyB3b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGluZyBzb2x1dGlvbnMuIFRoZSBwbGFuDQog IGlzIHRvIHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFsbG93ZWQgdG8gYWRk IGEgbmV3IG1pbGVzdG9uZQ0KICB0byBvdXIgY2hhcnRlci4NCg0KLSBEaXN0cmlidXRlZCBPQXV0 aA0KICAjIGRyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLTAwDQoNCiAgUmVtYXJrOiBXZSBo YWQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFuZCB0aGVyZSBpcw0K ICBpbnRlcmVzdCBpbiB0aGlzIHdvcmsuIEZ1cnRoZXIgd29yayBvbiB0aGUgc2NvcGUgaXMgbmVl ZGVkLg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KLS0NCg0KTmF0IFNha2ltdXJhDQoNCkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3Bl bklEIEZvdW5kYXRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3Ro ZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNv bW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVu dHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_TY1PR01MB1054A105034F55F6B810D7C3F9D80TY1PR01MB1054jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglwYW5vc2UtMToy IDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJOb3RvIFNh bnMgQ0pLIEpQIE1lZGl1bSI7DQoJcGFub3NlLTE6MiAxMSA2IDAgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBOb3RvIFNhbnMgQ0pLIEpQIE1lZGl1bSI7DQoJcGFu b3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJ cGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBtbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowbW07DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi77yt 77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0Kc3Bhbi5tMjQyNDM5MDQ0MDM3Mjk3Nzk4OGhvZW56Yg0K CXttc28tc3R5bGUtbmFtZTptXzI0MjQzOTA0NDAzNzI5Nzc5ODhob2VuemI7fQ0Kc3Bhbi4xOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0 IDMwLjBtbSAzMC4wbW0gMzAuMG1tO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiPg0KPHY6dGV4dGJveCBpbnNldD0iNS44 NXB0LC43cHQsNS44NXB0LC43cHQiIC8+DQo8L286c2hhcGVkZWZhdWx0cz48L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iSkEiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZW4gbGV0 IHVzIGRvIGl0LiBXZSBuZWVkIHRvIHB1dCBhbGwgdGhlIHByb3Bvc2FscyBvbiB0aGUgdGFibGUg YW5kIHN0cmF0ZWdpemUgdGhlIGRlc2lnbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlBlcmhhcHMgd2UgbmVlZCBhIHNpZGUgbWVldGluZyBhcyB3ZWxsLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bmF0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggMTozMSBBTTxi cj4NCjxiPlRvOjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGFkbid0IHByZXZpb3VzbHkgYmVlbiBwbGFubmluZyBv biBpdCBidXQgYW0gaGFwcHkgdG8gZG8gc28uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5PbiBUdWUsIE1hciA2LCAyMDE4IGF0IDg6MjIgQU0sIFJpZmFhdCBTaGVr aC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk5hdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5EdXJpbmcgdGhlIGludGVyaW0gbWVldGluZywgMyBkcmFmdHMgbWVudGlvbmVkIGluIHRo ZSBjb250ZXh0IG9mDQo8Yj5EaXN0cmlidXRlZCBPQXV0aDwvYj46PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wOCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2Zl bmlnLW9hdXRoLWF1ZGllbmNlLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiPkJyaWFuLCBIYW5uZXMsPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcmUg eW91IHBsYW5uaW5nIG9uIHByZXNlbnRpbmcgeW91ciBkb2N1bWVudHM/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBN b24sIE1hciA1LCAyMDE4IGF0IDg6MDkgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1t IDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgYmUgaW50 ZXJlc3RlZCBpbiBoZWFyaW5nIHRoYXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFsc28sIGFzIHBhcnQgb2YgJnF1b3Q7RGlzdHJpYnV0ZWQgT0F1dGgmcXVvdDssIGNh biB3ZSBkbyBhIGJpdCBvZiByZS1jYXAgb24gc29tZSBvZiB0aGUgcHJldmlvdXMgZHJhZnRzIG9u IHRoZSBzaW1pbGFyIHRvcGljIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUgaW50ZXJpbT8gaS5lLiwg QnJpYW4ncyBkcmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5kIG15IGRyYWZ0ICg8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEt MDgudHh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiM0NDAwODgi PmRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGE8L3NwYW4+PC9hPik/Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0LCZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TmF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1 ZSwgTWFyIDYsIDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1h aWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MG1tIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkhhbm5lcyAmYW1wOyBSaWZhYXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkkgd291 bGQgbGlrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCBvbiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPk9BdXRo IDIuMCBJbmNyZW1lbnRhbCBBdXRob3JpemF0aW9uIChkcmFmdC13ZGVubmlzcy1vYXV0aC1pbmNy ZW1lbnRhbC1hdXRoKSBbYW4gdXBkYXRlIGZvciB3aGljaCB3aWxsDQogYmUgcG9zdGVkIHRvZGF5 XSBhbmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZxdW90O09BdXRoIDIuMCBEZXZp Y2UgUG9zdHVyZSBTaWduYWxzJnF1b3Q7IChkcmFmdC13ZGVubmlzcy1vYXV0aC1kZXZpY2UtcG9z dHVyZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J IGNhbiBhbHNvIGdpdmUgYW4gdXBkYXRlIG9uIHRoZSBzdGF0dXMgb2YgRGV2aWNlIEZsb3cgKGRy YWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3cpLiBJIGV4cGVjdCB0aGF0IHRvIGJlIHNob3J0IG5v dyB0aGF0IFdHTEMgaGFzIGNvbmNsdWRlZCBhbmQgdGhlIGRvY3VtZW50IGhhcyBhZHZhbmNlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxpdHRsZSBs YXRlIHRvIHRoaXMgdGhyZWFkIGFuZCBJIHNlZSB3ZSBhbHJlYWR5IGhhdmUgMiBzZXNzaW9ucyBp biB0aGUgZHJhZnQgYWdlbmRhLCBidXQgSSdkIGxpa2UgdG8gYWRkIG15IHN1cHBvcnQgdG8ga2Vl cGluZyBib3RoIHNlc3Npb25zLCB0aGVyZSdzIGFsd2F5cyBhIGxvdCB0byBkaXNjdXNzIGFuZCBp biB0aGUgcGFzdCB3ZSd2ZSBiZWVuIGFibGUgdG8gdXNlIGFueQ0KIHNwYXJlIHRpbWUgdG8gZGlz Y3VzcyB0aGUgc2VjdXJpdHkgdG9waWNzIG9mIHRoZSBkYXkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5XaWxsaWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0 MCBBTSBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5I aSBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JdCBpcyB0aW1lIGFscmVhZHkgdG8gdGhp bmsgYWJvdXQgdGhlIGFnZW5kYSBmb3IgdGhlIG5leHQgSUVURiBtZWV0aW5nLiBSaWZhYXQgYW5k IEkgd2VyZSB3b25kZXJpbmcgd2hldGhlciB3ZSBuZWVkIG9uZSBvciB0d28gc2Vzc2lvbnMuIFdl IHdvdWxkIGxpa2UgdG8gbWFrZQ0KIHRoZSBkZWNpc2lvbiBiYXNlZCBvbiB0aGUgdG9waWNzIHdl IHdpbGwgZGlzY3Vzcy4gQmVsb3cgeW91IGNhbiBmaW5kIGEgZmlyc3QgdmVyc2lvbiBvZiB0aGUg YWdlbmRhIHdpdGggYSBmZXcgcmVtYXJrcy4gTGV0IHVzIGtub3cgaWYgeW91IGhhdmUgY29tbWVu dHMgb3Igc3VnZ2VzdGlvbnMgZm9yIGFkZGl0aW9uYWwgYWdlbmRhIGl0ZW1zLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+Q2lhbzxicj4NCkhhbm5lcyAmYW1wOyBSaWZhYXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk9B dXRoIEFnZW5kYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLS0tLS0tLS0tLS08L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gV2VsY29tZSBhbmQgU3RhdHVz IFVwZGF0ZSZuYnNwOyAoQ2hhaXJzKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICogT0F1dGggU2VjdXJpdHkgV29ya3Nob3AgUmVwb3J0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyogRG9jdW1lbnRzIGluIElFU0cgcHJvY2Vzc2luZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBkcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA3 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IyBk cmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wOA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMTU8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1v YXV0aC10b2tlbi1leGNoYW5nZS0xMTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7UmVtYXJrOiBTdGF0dXMgdXBkYXRlcyBvbmx5IGlmIG5lZWRl ZC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0mbmJzcDsgSlNPTiBXZWIgVG9rZW4gQmVzdCBD dXJyZW50IFByYWN0aWNlczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgIyBkcmFm dC1pZXRmLW9hdXRoLWp3dC1iY3AtMDANCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVtYXJrOiBX ZSBhcmUgbGFja2luZyByZXZpZXdzIG9uIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBNb3N0IGxpa2VseSB3ZSB3aWxsIG5vdCBnZXQgdGhlbSBkdXJpbmcg dGhlIGYyZiBtZWV0aW5nDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 YnV0IHJhdGhlciBieSByZWFjaGluZyBvdXQgdG8gaW5kaXZpZHVhbHMgYWhlYWQgb2YgdGltZS4N Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+LSZuYnNwOyBPQXV0aCAyLjAgTXV0dWFsIFRMUyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIENlcnRpZmljYXRlIEJvdW5kIEFjY2VzcyBUb2tlbnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1tdGxzLTA2DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBSZW1hcms6IENv dWxkIGJlIGNvbXBsZXRlZCBieSB0aGUgdGltZSBvZiB0aGUgSUVURiBtZWV0aW5nLg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t IE9BdXRoIFNlY3VyaXR5IFRvcGljczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFm dC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wNA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtSZW1hcms6IFdlIGNv dWxkIGRvIGEgY29uc2Vuc3VzIGNhbGwgb24gcGFydHMgb2YgdGhlIGRvY3VtZW50IHNvb24uDQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0g T0F1dGggMi4wIFRva2VuIEJpbmRpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJh ZnQtaWV0Zi1vYXV0aC10b2tlbi1iaW5kaW5nLTA1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazogRG9jdW1lbnQgaXMg bW92aW5nIGFsb25nIGJ1dCB3ZSBhcmUgbGFja2luZyBpbXBsZW1lbnRhdGlvbnMuDQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gT0F1dGgg Mi4wIERldmljZSBQb3N0dXJlIFNpZ25hbHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMg ZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtZGV2aWNlLXBvc3R1cmUtMDENCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7UmVtYXJr OiBJbnRlcmVzdCBpbiB0aGUgd29yayBidXQgd2UgYXJlIGxhY2tpbmcgY29udGVudCAobWF5YmUg ZXZlbg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO2V4cGVydGlzZSBpbiB0aGUg Z3JvdXApPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi0gUmVjaXByb2NhbCBPQXV0aDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFmdC1o YXJkdC1vYXV0aC1tdXR1YWwtMDINCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7IFJlbWFyazogV2UgaGFkIGEgdmlydHVhbCBpbnRlcmltIG1l ZXRpbmcgb24gdGhpcyB0b3BpYyBhbmQgdGhlcmUgaXMNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDtpbnRlcmVzdCBpbiB0aGlzIHdvcmsgYW5kIGFwcGFyZW50bHkgbm8gY29tcGV0 aW5nIHNvbHV0aW9ucy4gVGhlIHBsYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IGlzIHRv IHJ1biBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uY2Ugd2UgYXJlIGFsbG93ZWQgdG8gYWRkIGEgbmV3 IG1pbGVzdG9uZQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO3RvIG91ciBjaGFy dGVyLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4tIERpc3RyaWJ1dGVkIE9BdXRoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRy YWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLTAwDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBSZW1hcms6IFdlIGhhZCBhIHZpcnR1YWwg aW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJlIGlzDQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7aW50ZXJlc3QgaW4gdGhpcyB3b3JrLiBGdXJ0aGVyIHdvcmsg b24gdGhlIHNjb3BlIGlzIG5lZWRlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzDQog dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9Im0yNDI0MzkwNDQw MzcyOTc3OTg4aG9lbnpiIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TmF0IFNha2ltdXJhPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5k YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowbW0iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRo aXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkDQogcmVjaXBpZW50KHMpLiBBbnkgcmV2 aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp b24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyLg0KIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_TY1PR01MB1054A105034F55F6B810D7C3F9D80TY1PR01MB1054jpnp_-- From nobody Wed Mar 7 04:22:29 2018 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 C4ED512D870 for ; Wed, 7 Mar 2018 04:22:27 -0800 (PST) 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 bI3GrJbhVC2l for ; Wed, 7 Mar 2018 04:22:25 -0800 (PST) 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 D346312D7FC for ; Wed, 7 Mar 2018 04:22:24 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id s92so357634uas.11 for ; Wed, 07 Mar 2018 04:22:24 -0800 (PST) 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=87efynePIv5nXDk7IW00WN9W9WOroPWjw9oATc38cjQ=; b=jkxXa4naob8FlkXVTg9Fo7wfbuUg9dAUGiVvBRYtPNf4EdrVAIBP4/J0N7woBrzRw4 MuW62lb4mjpwBcFk+FI64xX2K8p92fj8Xkjtj+OZlCfO0k4DsidrDTsFdy4HmmGZSM1i fMvFdNhOs3undNE4n/lL8HS70ZV1w73n0ikYbyeFx0U2fo8CQ7YEsIqgI/86Rf/0I4BI 6J0CWp3xvqa2fWOn5/TedNMNopUvCog4BhhopPQknJC8DXb1j7gcAamczoFBx09PmRE/ odaP87SDU4g+JpyzeI3I6t86T9FOZawOcEV6GunfMh5b/npiNCB3ss7YldnVpbvnrgvK DaMQ== 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=87efynePIv5nXDk7IW00WN9W9WOroPWjw9oATc38cjQ=; b=SNNdwqHKs7dshTsQ/vU+tC+/8Wtss4u69urrAUybMoCbXqFe4MBHUU8FTxZbLS9jvT vqwb0V2i3nvxGbB3AKtsQ8qlju4DSfSqXiAUAAt5EiPaGHTHXOoV55dNhbk5WNht7pXL fp3ru1HZ0+PERxeJMVJKHhkH5WxbDyHgIntJCeqUGKaoHwODq5C+7EB4ayiuCysNso9v UAo646R8I+86RUvKjNtodIGQ/GXvrCpKReRliZCxM804ncR6ua0BuMASQXMUvdR+wwga NNjlLS6FRNTde0tu2NZyJVImU6c7JaNTUGzw84qMK/pXXX8SZOIH/aEHGfdi9us1wCCn KYYA== X-Gm-Message-State: APf1xPDau8N/g0R0ZtcUAmatmcqa13185vZwYDSSwajRAbxjgNYTx2wg 9e7twOVtnWb36gvCgOrFuio9igw1mwfPZqaYEPE= X-Google-Smtp-Source: AG47ELuSzwU0/CLG8eW3NvgEtYFHSd3roLjIGjaqv7Rxd3FGOrIsm8RqJq2lJFhPCRZe20i7VIH6P3buPQcVt8lGLuQ= X-Received: by 10.176.71.234 with SMTP id w42mr16192687uac.132.1520425343726; Wed, 07 Mar 2018 04:22:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.45.148 with HTTP; Wed, 7 Mar 2018 04:22:23 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Wed, 7 Mar 2018 07:22:23 -0500 Message-ID: To: n-sakimura Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="f40304378a78853a880566d19cfe" Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 07 Mar 2018 12:22:28 -0000 --f40304378a78853a880566d19cfe Content-Type: text/plain; charset="UTF-8" Nat, Are you asking for an interim meeting? We could schedule the Distributed OAuth discussion for the Wednesday meeting; that will give you guys sometime to discuss these face-to-face in London. Regards, Rifaat On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura wrote: > Then let us do it. We need to put all the proposals on the table and > strategize the design. > > Perhaps we need a side meeting as well. > > > > nat > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Wednesday, March 07, 2018 1:31 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for agenda items > > > > I hadn't previously been planning on it but am happy to do so. > > > > On Tue, Mar 6, 2018 at 8:22 AM, Rifaat Shekh-Yusef > wrote: > > Nat, > > > > During the interim meeting, 3 drafts mentioned in the context of *Distributed > OAuth*: > > > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-08 > > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > > > *Brian, Hannes,* > > > > Are you planning on presenting your documents? > > > > Regards, > > Rifaat > > > > > > > > > > > > > > On Mon, Mar 5, 2018 at 8:09 PM, Nat Sakimura wrote: > > I would be interested in hearing that. > > > > Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of > the previous drafts on the similar topic as we discussed in the interim? > i.e., Brian's draft (where is the link now?) and my draft ( > draft-sakimura-oauth-meta > )? > > > > Best, > > > > Nat > > > > On Tue, Mar 6, 2018 at 3:30 AM William Denniss > wrote: > > Hannes & Rifaat, > > > I would like the opportunity to present on OAuth 2.0 Incremental > Authorization (draft-wdenniss-oauth-incremental-auth) [an update for > which will be posted today] and "OAuth 2.0 Device Posture Signals" > (draft-wdenniss-oauth-device-posture). > > > > I can also give an update on the status of Device Flow > (draft-ietf-oauth-device-flow). I expect that to be short now that WGLC > has concluded and the document has advanced. > > > > Little late to this thread and I see we already have 2 sessions in the > draft agenda, but I'd like to add my support to keeping both sessions, > there's always a lot to discuss and in the past we've been able to use any > spare time to discuss the security topics of the day. > > > > Regards, > > William > > > > > > > > On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > > > It is time already to think about the agenda for the next IETF meeting. > Rifaat and I were wondering whether we need one or two sessions. We would > like to make the decision based on the topics we will discuss. Below you > can find a first version of the agenda with a few remarks. Let us know if > you have comments or suggestions for additional agenda items. > > > > Ciao > Hannes & Rifaat > > > > OAuth Agenda > > ------------ > > > > - Welcome and Status Update (Chairs) > > > > * OAuth Security Workshop Report > > > > * Documents in IESG processing > > # draft-ietf-oauth-device-flow-07 > > # draft-ietf-oauth-discovery-08 > > # draft-ietf-oauth-jwsreq-15 > > # draft-ietf-oauth-token-exchange-11 > > > > Remark: Status updates only if needed. > > > > - JSON Web Token Best Current Practices > > # draft-ietf-oauth-jwt-bcp-00 > > > > Remark: We are lacking reviews on this document. > > Most likely we will not get them during the f2f meeting > > but rather by reaching out to individuals ahead of time. > > > > - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access > Tokens > > # draft-ietf-oauth-mtls-06 > > > > Remark: Could be completed by the time of the IETF meeting. > > > > - OAuth Security Topics > > # draft-ietf-oauth-security-topics-04 > > > > Remark: We could do a consensus call on parts of the document soon. > > > > - OAuth 2.0 Token Binding > > # draft-ietf-oauth-token-binding-05 > > > > Remark: Document is moving along but we are lacking implementations. > > > > - OAuth 2.0 Device Posture Signals > > # draft-wdenniss-oauth-device-posture-01 > > > > Remark: Interest in the work but we are lacking content (maybe even > > expertise in the group) > > > > - Reciprocal OAuth > > # draft-hardt-oauth-mutual-02 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work and apparently no competing solutions. The plan > > is to run a call for adoption once we are allowed to add a new milestone > > to our charter. > > > > - Distributed OAuth > > # draft-hardt-oauth-distributed-00 > > > > Remark: We had a virtual interim meeting on this topic and there is > > interest in this work. Further work on the scope is needed. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > 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 > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > 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.* > --f40304378a78853a880566d19cfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nat,

Are you asking for an interim meet= ing?
We could schedule the Distributed OAuth discussion for the W= ednesday meeting; that will give you guys sometime to discuss these face-to= -face in London.

Regards,
=C2=A0Rifaat



On Wed, Mar 7, 2018 at 2:00 AM, n-sakimura <n-sa= kimura@nri.co.jp> wrote:

Then let us do it. We ne= ed to put all the proposals on the table and strategize the design.

Perhaps we need a side m= eeting as well.

=C2=A0

nat=

=C2=A0

From: = OAuth [mailto:o= auth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for agenda items

=C2=A0

I hadn't previously been pl= anning on it but am happy to do so.

=C2=A0

On Tue, Mar 6, 2018 at 8:22 AM,= Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Nat,

=C2=A0

Brian, Hannes,

=C2=A0

Are you planning on presenting = your documents?

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 5, 2018 at 8:09 PM,= Nat Sakimura <s= akimura@gmail.com> wrote:

I would be interested in hearin= g that.=C2=A0

=C2=A0

Also, as part of "Distribu= ted OAuth", can we do a bit of re-cap on some of the previous drafts o= n the similar topic as we discussed in the interim? i.e., Brian's draft= (where is the link now?) and my draft (dra= ft-sakimura-oauth-meta)?=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

On Tue, Mar 6, 2018 at 3:30 AM = William Denniss <wdenniss@google.com> wrote:

Hannes & Rifaat,<= /u>


I would like the opportunity to present on=C2=A0OAuth 2.0 Incremental Authorization (draft-wdennis= s-oauth-incremental-auth) [an update for which will be posted today] and=C2=A0"OAuth 2.0 Devi= ce Posture Signals" (draft-wdenniss-oauth-device-posture).=

=C2=A0

I can also give an update on th= e status of Device Flow (draft-ietf-oauth-device-flow). I expect that = to be short now that WGLC has concluded and the document has advanced.

=C2=A0

Little late to this thread and = I see we already have 2 sessions in the draft agenda, but I'd like to a= dd my support to keeping both sessions, there's always a lot to discuss= and in the past we've been able to use any spare time to discuss the security topics of the day.=

=C2=A0

Regards,

William

=C2=A0

=C2=A0

= =C2=A0

On Tue, Jan 30, 2018 at 4:40 AM= Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

It is time already to think abo= ut the agenda for the next IETF meeting. Rifaat and I were wondering whethe= r we need one or two sessions. We would like to make the decision based on the topics we will discuss. Below you can find a fir= st version of the agenda with a few remarks. Let us know if you have commen= ts or suggestions for additional agenda items.

=C2=A0

Ciao
Hannes & Rifaat

=C2=A0

OAuth Agenda

------------

=C2=A0

- Welcome and Status Update=C2=A0 (Chairs)

=C2=A0

=C2=A0 * OAuth Security Workshop Report

=C2=A0

=C2=A0=C2=A0* Documents in IESG processing

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-device-flow-07

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-discovery-0= 8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# draft-ietf-oauth-jwsreq-15

=C2=A0=C2=A0=C2=A0=C2=A0 # draft-ietf-oauth-token-excha= nge-11

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Remark: Status updates = only if needed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

-=C2=A0 JSON Web Token Best Current Practices

=C2=A0=C2=A0 # draft-ietf-oauth-jwt-bcp-00

=C2=A0=C2=A0=C2=A0=

=C2=A0=C2=A0=C2=A0Remark: We are lacking reviews on this doc= ument.

=C2=A0=C2=A0 Most likely we will not get them during the f2f= meeting

=C2=A0=C2=A0=C2=A0but rather by reaching out to individuals = ahead of time.

=C2=A0=C2=A0=C2=A0=

-=C2=A0 OAuth 2.0 Mutual TLS Client Authentication and Certi= ficate Bound Access Tokens=

=C2=A0=C2=A0 # draft-ietf-oauth-mtls-06

=C2=A0

=C2=A0=C2=A0 Remark: Could be completed by the time of the I= ETF meeting.

=C2=A0=C2=A0=C2=A0=

- OAuth Security Topics

=C2=A0 # draft-ietf-oauth-security-topics-04

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: We could do a consensus call on parts of= the document soon.

=C2=A0=C2=A0

- OAuth 2.0 Token Binding=

=C2=A0 # draft-ietf-oauth-token-binding-05

=C2=A0

=C2=A0=C2=A0Remark: Document is moving along but we are lack= ing implementations.

=C2=A0=C2=A0

- OAuth 2.0 Device Posture Signals

=C2=A0 # draft-wdenniss-oauth-device-posture-01

=C2=A0=C2=A0

=C2=A0=C2=A0Remark: Interest in the work but we are lacking = content (maybe even

=C2=A0=C2=A0expertise in the group)

=C2=A0

- Reciprocal OAuth=

=C2=A0 # draft-hardt-oauth-mutual-02

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on this topi= c and there is

=C2=A0=C2=A0interest in this work and apparently no competin= g solutions. The plan

=C2=A0 is to run a call for adoption once we are allowed to = add a new milestone

=C2=A0=C2=A0to our charter.

=C2=A0=C2=A0

- Distributed OAuth

=C2=A0 # draft-hardt-oauth-distributed-00

=C2=A0

=C2=A0 Remark: We had a virtual interim meeting on this topi= c and there is

=C2=A0=C2=A0interest in this work. Further work on the scope= is needed.

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

______________________________<= wbr>_________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

______________________________<= wbr>_________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--

Nat Sakimura

Chairman of the Board, Open= ID Foundation

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

=C2=A0

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

=C2=A0


CONFIDENTIALITY NOTICE: This email may contain confidential and p= rivileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is str= ictly prohibited.=C2=A0 If you have received this communication in error, p= lease notify the sender immediately by e-mail and delete the message and an= y file attachments from your computer. Thank you.


--f40304378a78853a880566d19cfe-- From nobody Wed Mar 7 10:53:34 2018 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 D0E86129C5D for ; Wed, 7 Mar 2018 10:53:32 -0800 (PST) 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 grtJPpgwPkOr for ; Wed, 7 Mar 2018 10:53:31 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 1C580120721 for ; Wed, 7 Mar 2018 10:53:31 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id f6so1986447vkh.6 for ; Wed, 07 Mar 2018 10:53:31 -0800 (PST) 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=LSpPnruXCWV0HzvgcM0cx/TfBSFqA8ng6yBTRmJBH/c=; b=jiJZ8/bZJTtPY6t2py+5aKOKdBZcZr4TrRwYq02uThaiGvb4ARsPmf3/C2G4m2OO7+ er2EoNav9KWrLbkg3nXIHp62I9uVF+L//7kAVarJEzKx9BZvql3ww8jEQMY00pS26Zw+ RClDJlJ6dKyCxfVCBFv+D/NcP+0yCneKqIFEvRzc7ohej8Emkjcg9xusliFN+hvUPrt9 Lg1mx3GdzRRx0fciO/cDXS/N0HJzCzKeeN7DbJnoQIUIM4osOO2lfXe64tQIVcE+b+RP X1ZBLwSHwlH16RpbeY+wH2HaeEgrXDbcsUkj2Mj1n0TjaGFQdt9cutO/BRU3+dZD1MQY BYNQ== 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=LSpPnruXCWV0HzvgcM0cx/TfBSFqA8ng6yBTRmJBH/c=; b=pMeLH+ANLoFcEVSkE5D4u+A134qpo1M+5OYcNavivSGbjtfnX6iaEVq0QHYQVzUb16 3gU8SApjIHMzViaIoQN86JVZ2H8NkHwmZWDa3gIvHDMEWPO4AmfSGpPc2pNb4utCiWf9 RC5uoBn6cwbkVH6xu4c5WLv+Z2BOrPLEP1zZan+g44UJW5kYPZWPB3p62wHr3bvUaw2I Oj4KapSaF2yg6o/voEIwSvyQLFDG4yFd4jPgVQVoh7h6LIlgvW7RodEHUW1CFzjuo9nw K0zZaxz1/p3ybEEIi7kfFv4GCj8wnnAVBxqHjpBa7GxS1ZDkjNT2vHp7uzu66mLVd1w+ VlGQ== X-Gm-Message-State: APf1xPBl8JaptwvnM2mfnw2oeNHhvQ5ejSVkb3p5uy3ULNmRaZykKPG7 jWetyxJJVEb8mohrn2B0l4n2dbU3Lgohm9CJPAqIvBgo X-Google-Smtp-Source: AG47ELuBYNDR9uREPLp0+XPdqmzMJ979HFgpHsh2P9grSVePhObiVDsftf81m6V208Q5QdfdAWPSosO7zugCzhsqXtA= X-Received: by 10.31.95.5 with SMTP id t5mr16248595vkb.169.1520448809937; Wed, 07 Mar 2018 10:53:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.45.148 with HTTP; Wed, 7 Mar 2018 10:53:29 -0800 (PST) From: Rifaat Shekh-Yusef Date: Wed, 7 Mar 2018 13:53:29 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114e5d1e372e7b0566d7137d" Archived-At: Subject: [OAUTH-WG] IETF101 Draft Agenda 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, 07 Mar 2018 18:53:33 -0000 --001a114e5d1e372e7b0566d7137d Content-Type: text/plain; charset="UTF-8" Here is the draft agenda for our two sessions: *Monday* https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa *Wednesday* *https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessb * Please, let us know if you have any comments. Regards, Rifaat & Hannes --001a114e5d1e372e7b0566d7137d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is the draft agenda for our two sessions:
<= div>
Monday

Wednesday

Please, let us= know if you have any comments.

Regards,
=
=C2=A0Rifaat & Hannes
--001a114e5d1e372e7b0566d7137d-- From nobody Wed Mar 7 10:58:27 2018 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 624E9129C53 for ; Wed, 7 Mar 2018 10:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 q7PL_Fk2H96J for ; Wed, 7 Mar 2018 10:58:24 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 9C6C5120721 for ; Wed, 7 Mar 2018 10:58:24 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id x125so1988920vkc.13 for ; Wed, 07 Mar 2018 10:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IQrMEuv1lCq+Q3r4J81BRxMbiEuRUAPiVz8cgdB/D9Q=; b=XKgW/6zg0Ojijm+jg815MTWLPMfHA/6YBe7Qgdh1jQnkcgbHZJGGKN+ouc4orQfALU 4gTT9wHphaJw6A7O5g11kHu3ICVrVdXv+TcVwcPZ1SBxGaSFLieneHm3GQCldkUVcaKJ ncksiFiYWup7rgfDjtSnv159gjwuTyH9/74OzIqVbLUd/5F9n71oWawgCz7VLvxkaGTG 3HKddp0K+/QeuCe1hTRw+dThqIhF7ryCTRBZrIjbXoE2Gr3OXkn+F7sVMSQ5ut0vYPCD W6g1ZgFLQUxPlMN1b5UrmZ0sq/kqZ61iF5Z31klBRrnnVxc+67fsXlJcSdmQbAwN1dDO mQqA== 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=IQrMEuv1lCq+Q3r4J81BRxMbiEuRUAPiVz8cgdB/D9Q=; b=bP8+rIVbzVdMcWVgANNJPyfTo4T4aEH/7rMcydioSgRPadxP/NqJYMaCGibjd4uOQp wpqmZi/z/r5jK+qLpmfNjSY1ubbTz5N4/zmCVvCN4lZRcGBX8QQkr57kHs6S1xCs/EpC 8sSEkgiDYGz3fVPOCd9Ugb9CWNHNkIMTRCP78a4FXWPflwdxidnfX12rgxLsUgdNBFd7 Q2oi1Pf6/QejWdLqmfF3vEhUufGBfgyxmjAO5OS54VexMofCKUGF0Z7aSo+Az4TF6fbo n0CaxEyctR8rzDsJK/zW24WDtTXFFrJYWeLwAyFo5WouaOzuzDXU52IeepwFmCog619p 7mVw== X-Gm-Message-State: APf1xPCJXaiIWxt4/Hljr4m0B9LJr+BB5k4Ljli7k9oAMf3loWeCCAEP JCWoIFOGpsfYo8HiiiZG6wRXG6mkc85+K97A5qii8SVg X-Google-Smtp-Source: AG47ELvkJV6Y2MvdCsYhdxBDbz0Hf9+ymDNWDgqFGuQ9kFJGATce2MhRpzW62MU002WrEQYEAud/YymPkZHI93PTNyY= X-Received: by 10.31.165.213 with SMTP id o204mr16424250vke.163.1520449103119; Wed, 07 Mar 2018 10:58:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Wed, 07 Mar 2018 18:58:12 +0000 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="001a11427c94b192360566d72425" Archived-At: Subject: Re: [OAUTH-WG] IETF101 Draft Agenda 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, 07 Mar 2018 18:58:26 -0000 --001a11427c94b192360566d72425 Content-Type: text/plain; charset="UTF-8" Looks good to me. On Wed, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef wrote: > Here is the draft agenda for our two sessions: > > *Monday* > https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa > > *Wednesday* > *https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessb > * > > Please, let us know if you have any comments. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11427c94b192360566d72425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks good to me.


=
On Wed, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= br>
Here is the d= raft agenda for our two sessions:

Monday

Wednesday<= /div>

Please, let us know if you have any comme= nts.

Regards,
=C2=A0Rifaat & Han= nes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11427c94b192360566d72425-- From nobody Wed Mar 7 11:58:34 2018 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 E5A71129C6B for ; Wed, 7 Mar 2018 11:58:32 -0800 (PST) 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, 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 (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 PzMxgEexoX7L for ; Wed, 7 Mar 2018 11:58:31 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 1654C12D869 for ; Wed, 7 Mar 2018 11:58:31 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 30so4400743iog.2 for ; Wed, 07 Mar 2018 11:58:31 -0800 (PST) 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=OEJeIyqlUyqvtPkVVLPxFuzi3DHBu5M3gCyITouWo4Y=; b=Mf9tPachBiDlmvD/VcRxb/CRSY56EEIjfBICSETlZNiImvjR/BLuHOUGVMEIfkzt0/ KCR80A2SPi2itep9RIpg9q35/UZaxeKyii9WLm9nHKmKQRSMTONO6FUQgXXy6BwfM0Jc 34uTsnWny2fIzxOYMfC5ZeR3vcjXN+SrYleZc= 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=OEJeIyqlUyqvtPkVVLPxFuzi3DHBu5M3gCyITouWo4Y=; b=QxoeR6t6D9GseKP37J5VPEZcAdygwMv69xMUNJJ2CdohNfe19fI4nYvQMeUZQz30uv /7/+7mxWSK/qNq+p8JsjafpjAQCtfB3Zs6JyqFkZJrfu6XF9uCSDZaNh3fMPjFZd8qJg 0PySiDmYZ6otGAvsCSJkY88SzOVp6ayquAf+NqULkpo2i6zGMrAmxlO+6cfUVW+aHdQ6 qEQPa37H/cVEyEnjy5jEYwtDEXvKhkM3NufaFAGeWVp9YzxP3M0Z2Fcu5YetgIB/PlL6 zDRKc1lxtAu+OOK82nulvCigUY+pQDexwm7wBAZ7FfqPBJZMthZDye/TGnyhjrV3or3v nSBg== X-Gm-Message-State: AElRT7HihUU2wVa5UfVg/bSbaIZ1tjaSVaiFJo2eVbTOY2oMW+7JmebD ekf/O5E0t2WkIgJrkOiD1C0fZcqPNIhtWbQCUyiY6eMxRWvgNv7xKRV6xrEPA3h77gs8BoGqCr7 1Vk3QWvHVEE0zvw== X-Google-Smtp-Source: AG47ELsZU6Q+OiBV+HQjgDDa8Zwhq1fkn5/uen5NLS7IqXDaB2s7So96zPmDRzPvTvInq9pCN1URFFSTka925dBwQEg= X-Received: by 10.107.180.83 with SMTP id d80mr27111822iof.168.1520452710248; Wed, 07 Mar 2018 11:58:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.73.200 with HTTP; Wed, 7 Mar 2018 11:57:59 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 7 Mar 2018 12:57:59 -0700 Message-ID: To: William Denniss Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="94eb2c05c4d2b14bac0566d7fb01" Archived-At: Subject: Re: [OAUTH-WG] IETF101 Draft Agenda 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, 07 Mar 2018 19:58:33 -0000 --94eb2c05c4d2b14bac0566d7fb01 Content-Type: text/plain; charset="UTF-8" Looks okay to me too. I don't think I'll have anywhere close to 20 minutes on draft-ietf-oauth-token-bindingfor this meeting. But having some extra time isn't a bad thing. On Wed, Mar 7, 2018 at 11:58 AM, William Denniss wrote: > Looks good to me. > > > On Wed, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef > wrote: > >> Here is the draft agenda for our two sessions: >> >> *Monday* >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa >> >> *Wednesday* >> *https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessb >> * >> >> Please, let us know if you have any comments. >> >> Regards, >> Rifaat & 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.* --94eb2c05c4d2b14bac0566d7fb01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks okay to me too.

I don't think= I'll have anywhere close to 20 minutes on draft-ietf-oauth-token-bindi= ngfor this meeting. But having some extra time isn't a bad thing.
<= /div>

On Wed, Mar = 7, 2018 at 11:58 AM, William Denniss <wdenniss@google.com>= wrote:
Looks good to me= .


On Wed, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t; wrote:
Here is the draft agenda for our two sessio= ns:

Monday

Wednesday
https://datatracker.ietf.org/= meeting/101/materials/agenda-101-oauth-sessb

Please, let us know if you have any comments.

Regards,
=C2=A0Rifaat & Hannes
<= /div>
_______________________________________________
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. --94eb2c05c4d2b14bac0566d7fb01-- From nobody Wed Mar 7 14:42:43 2018 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 D175012D88C for ; Wed, 7 Mar 2018 14:42:41 -0800 (PST) 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 HpIKPdTDt8Td for ; Wed, 7 Mar 2018 14:42:40 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 D328F127419 for ; Wed, 7 Mar 2018 14:42:39 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v90so4606113qte.12 for ; Wed, 07 Mar 2018 14:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=adbQqtB6udMBArEC3xfU1KW82Lc0uvvgWMfbWDa26GM=; b=KSIFblvlXbh8CjQuprWbQJN89q16ruHHEEEHJMVCL1Q3cnfVW+cPtMYjIqmbRORTk1 4mI3umHiU2DtE9X85+k6kkIFkSAiZwaPx8YjV5CWeEA/8atojr4qFi2eN1uZtYzo0Icd cqfnlmJp0p5Lu8OpFs/UcbYyFD1HijyvO9qpXdhACxZBeQwqNah1e1qlhz3TUc9oykxa cfN3qPL+yX4herIiQjaFhUbXjjRkUdJtH12/kbDvQb24kq2h/OVi9I4BpmsGnAVXorYK FFqJFABOKNkMf1rGB8b1GWKO4S8PZIvOowgUBx8uoYPZmaikzJcCWPgUhPQ/YTi3BtbT DOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=adbQqtB6udMBArEC3xfU1KW82Lc0uvvgWMfbWDa26GM=; b=h5XZRAVbu+7ELPwtlLAp3fndUJ2lgiKarY+uqOvZY6/1nVVscsvqYRvqGw3bWxyb5w GJtGoLHQZbS/Ds76/dIccYaEUbcu4GCd1GMyQvUBXyXuEjBhrHX6j8ux/VVR9EsYkkS1 JKiJAxVplvPxlWRyXExAkYyir+ZIbsOYibdtD6OTRl2Z7jx+hNIbxZe27QMMP/4z1Ppd w1TqcbVJrLMHpU9OA3pa1jgZYTIRyzL0Vhq+LaK5XS1S3fF1BiSezVj3j3rZ8hDYmfUB XSiyPIgdgRcylQgHO/NqIAMSCpDbjDFO9HSgSkAdKN63Qri0DQ869GHNW/Q0O/9TmplJ 1cLw== X-Gm-Message-State: AElRT7GQ12M3ESF+T+hCWWPomjZ2eaFtEF8vN61nAEY0Ykr+HJqr6eE6 bKfp2k/MAk+w7v+RPQ+5liY= X-Google-Smtp-Source: AG47ELswwbInrrJSvYKKgiEX0SElf9RozmYSsrCl7gXyWKTTHvmB7TpH6O4PMSsVGP2BqrOINpBvPQ== X-Received: by 10.200.39.6 with SMTP id g6mr36678153qtg.169.1520462558778; Wed, 07 Mar 2018 14:42:38 -0800 (PST) Received: from mail.outlook.com ([52.186.84.65]) by smtp.gmail.com with ESMTPSA id b25sm12648919qte.40.2018.03.07.14.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 14:42:37 -0800 (PST) Date: Wed, 7 Mar 2018 22:42:36 +0000 (UTC) From: Nat Sakimura To: Brian Campbell , William Denniss Cc: oauth Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_696_1230337182.1520462556966" X-Mailer: Outlook for iOS and Android Archived-At: Subject: Re: [OAUTH-WG] IETF101 Draft Agenda 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, 07 Mar 2018 22:42:42 -0000 ------=_Part_696_1230337182.1520462556966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =09 =09=09 =09=09 =09 =09=09Lgtm =09=09 =09=09 =09=09 =09 On Thu, Mar 8, 2018 at 4:58 AM +0900, "Brian Campbell" wrote: Looks okay to me too.=20 I don't think I'll have anywhere close to 20 minutes on draft-ietf-oauth-to= ken-bindingfor this meeting. But having some extra time isn't a bad thing.= =20 On Wed, Mar 7, 2018 at 11:58 AM, William Denniss wrot= e: Looks good to me. On Wed, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef = wrote: Here is the draft agenda for our two sessions: Mondayhttps://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-s= essa Wednesdayhttps://datatracker.ietf.org/meeting/101/materials/agenda-101-oaut= h-sessb Please, let us know if you have any comments. Regards,=C2=A0Rifaat & 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, di= stribution or disclosure by others is strictly prohibited.=C2=A0 If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you. ------=_Part_696_1230337182.1520462556966 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=09 =09=09 =09=09 =09
=09=09
Lgtm
=09=09 =09=09

=09=09
=09



On Thu, Mar 8, 2018 at 4:58 AM +0900, "Brian Cam= pbell" <bcampbell@pingidentity.com> wrote:

Looks okay to me too.

I don't think I'l= l have anywhere close to 20 minutes on draft-ietf-oauth-token-bindingfor th= is meeting. But having some extra time isn't a bad thing.

On Wed, Mar 7, 2018 at 1= 1:58 AM, William Denniss <wdenniss@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Looks good to me.

<= br>
On We= d, Mar 7, 2018 at 10:53 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= /div>
Here is the draft agenda for our two sessions:
=
Monday
https://datatracke= r.ietf.org/meeting/101/materials/agenda-101-oauth-sessa

Wednesday

<= /div>
Please, let us know if you have any comments.

<= /div>
Regards,
 Rifaat & 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



<= 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= .  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. ------=_Part_696_1230337182.1520462556966-- From nobody Wed Mar 7 17:52:47 2018 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 633F6120227 for ; Wed, 7 Mar 2018 17:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 oZ_Hp0pigVvP for ; Wed, 7 Mar 2018 17:52:43 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CDB1200E5 for ; Wed, 7 Mar 2018 17:52:42 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id DC87E19685B; Thu, 8 Mar 2018 10:52:41 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id B690D4E0046; Thu, 8 Mar 2018 10:52:41 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w281mb6j012290; Thu, 8 Mar 2018 10:52:41 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id w281qfEG016580; Thu, 08 Mar 2018 10:52:41 +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 w281qfFG064690; Thu, 8 Mar 2018 10:52:41 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w281qf23064688; Thu, 8 Mar 2018 10:52:41 +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 w281qf5j064685; Thu, 8 Mar 2018 10:52:41 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM05PA.cu.nri.co.jp (172.159.253.47) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 8 Mar 2018 10:52:40 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (23.103.139.180) by ex.nri.co.jp (192.51.23.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 8 Mar 2018 10:52:37 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jpK2+RZ/T9+AvgF6u4/7Scs0NO2T094B5QXr/SaAa9A=; b=DuqgrW+VubKBFiA/H96qGHpsD60OG3xfUos96AgytYRgcA6C+0vNKfH3s8uocR6L77h+mVuu5Str9csMquHHOGHLvpl64MWwfi5euEACHxDG4bej6U0MVti3nP0u8RVEUgoxnfVBU5tSMHSXndcuDJdHmYYqECXfSWo/tvawZlk= Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com (10.174.225.12) by TY1PR01MB1296.jpnprd01.prod.outlook.com (10.174.226.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Thu, 8 Mar 2018 01:52:38 +0000 Received: from TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) by TY1PR01MB1054.jpnprd01.prod.outlook.com ([10.174.225.12]) with mapi id 15.20.0548.016; Thu, 8 Mar 2018 01:52:38 +0000 From: n-sakimura To: Rifaat Shekh-Yusef , n-sakimura CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Call for agenda items Thread-Index: AdOZokfkKl3QavjXR5+VNijf+3VIVAbDb1oAAA3y6gAAHchUAAACZoYAAB5NaXAAC0wAgAAcFChA Date: Thu, 8 Mar 2018 01:52:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [180.43.136.41] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY1PR01MB1296; 7:3Ko3AaA5bG2tp6BN0GOrZoXcVnvKiPVJJiGWrcTeuzYiU0QoojFN6DPmq20lqm5N3BkbZMsMY8bRqd5g2Nx4INhQmhrcN4ciB6ZZ+hscWajp8OeVSEdWiubsto3jP27JTJauEwNAsQkHyPTF1Wiyue9zNy7lcDNpjF7URfl/GFPp80zRT9g8hInDllQKBkeTzke+Arql1/HR1mbIw7MgaxVHTw55swqYeRI02mKwZAnQYMH6IUsB1Rk7aWwx/O20 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2fe7461a-3e2d-4288-baa8-08d5849745d4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:TY1PR01MB1296; x-ms-traffictypediagnostic: TY1PR01MB1296: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(192374486261705)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501244)(52105095)(3002001)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:TY1PR01MB1296; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB1296; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39380400002)(396003)(39840400004)(189003)(199004)(53754006)(40434004)(36304003)(97736004)(59450400001)(8936002)(26005)(5890100001)(2950100002)(77096007)(186003)(93886005)(8676002)(105586002)(3846002)(86362001)(2906002)(7736002)(5660300001)(2900100001)(33656002)(3280700002)(53546011)(6506007)(102836004)(81166006)(74316002)(81156014)(6116002)(229853002)(54906003)(966005)(110136005)(99286004)(316002)(7696005)(39060400002)(53936002)(4326008)(236005)(6306002)(6246003)(606006)(54896002)(55016002)(25786009)(6436002)(74482002)(68736007)(76176011)(9686003)(53946003)(3660700001)(478600001)(106356001)(14454004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB1296; H:TY1PR01MB1054.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: hNHGQVherPPMFUN+sOGTbxSKtWnFsXfYr0tMxXT1vqY1sbo5x9YcWRe2Arw5tDPKXrxxXmxcnaVpFpjVO8EV38P0tizN+d5Ll7Y81kB3Bb4h4Rt/wHT4YR1U+9V1J6/q/ACmetRdasM81y87juvM/hc+AymDeOWS58c4ob73W9bRPeDPJOAhxANlOqjgdMJyXuf02ksYaYZ5eO+TORoQBf5ZVenfUqxCuokeSnIhqYulzGAE3a5bB5TK9edxFw7QwlVjY9MyRxq6NAG4K/Wi5rlK6U0da0+HuDJLE7xtiTz03N9W/imp1XONwwn+IXtPv2igLsRhcRVBKNelqFeRxg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY1PR01MB1054C1D6EBB6B6180E31F610F9DF0TY1PR01MB1054jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2fe7461a-3e2d-4288-baa8-08d5849745d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2018 01:52:38.8509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1296 X-OrganizationHeadersPreserved: TY1PR01MB1296.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for agenda items 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, 08 Mar 2018 01:52:45 -0000 --_000_TY1PR01MB1054C1D6EBB6B6180E31F610F9DF0TY1PR01MB1054jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIG5vdCByZWFsbHkuIEkgd2FzIHRoaW5raW5nIG9mIG1vcmUgaW5mb3JtYWwgdGhpbmcuIFRo ZSBzZXNzaW9uIGlzIHN1cHBvc2VkIHRvIGJlIFdlZG5lc2RheSBhZnRlcm5vb24sIHNvIEkgd2Fz IHRoaW5raW5nIHRoYXQgaXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gZG8gYSBiaXQgb2YgcmVj YXAgYW1vbmcgY29udHJpYnV0b3JzIHRvIGRyYXcgdXAgYSBiYXR0bGUgcGxhbiB0b3dhcmRzIElF VEYgMTAyLg0KDQpOYXQNCg0KRnJvbTogUmlmYWF0IFNoZWtoLVl1c2VmIFttYWlsdG86cmlmYWF0 LmlldGZAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxOCA5OjIyIFBN DQpUbzogbi1zYWtpbXVyYSA8bi1zYWtpbXVyYUBucmkuY28uanA+DQpDYzogQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPjsgb2F1dGggPG9hdXRoQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWdlbmRhIGl0ZW1zDQoNCk5hdCwNCg0K QXJlIHlvdSBhc2tpbmcgZm9yIGFuIGludGVyaW0gbWVldGluZz8NCldlIGNvdWxkIHNjaGVkdWxl IHRoZSBEaXN0cmlidXRlZCBPQXV0aCBkaXNjdXNzaW9uIGZvciB0aGUgV2VkbmVzZGF5IG1lZXRp bmc7IHRoYXQgd2lsbCBnaXZlIHlvdSBndXlzIHNvbWV0aW1lIHRvIGRpc2N1c3MgdGhlc2UgZmFj ZS10by1mYWNlIGluIExvbmRvbi4NCg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQoNCk9uIFdlZCwg TWFyIDcsIDIwMTggYXQgMjowMCBBTSwgbi1zYWtpbXVyYSA8bi1zYWtpbXVyYUBucmkuY28uanA8 bWFpbHRvOm4tc2FraW11cmFAbnJpLmNvLmpwPj4gd3JvdGU6DQpUaGVuIGxldCB1cyBkbyBpdC4g V2UgbmVlZCB0byBwdXQgYWxsIHRoZSBwcm9wb3NhbHMgb24gdGhlIHRhYmxlIGFuZCBzdHJhdGVn aXplIHRoZSBkZXNpZ24uDQpQZXJoYXBzIHdlIG5lZWQgYSBzaWRlIG1lZXRpbmcgYXMgd2VsbC4N Cg0KbmF0DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0K U2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxOCAxOjMxIEFNDQpUbzogUmlmYWF0IFNoZWto LVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNv bT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZ2VuZGEgaXRlbXMNCg0KSSBoYWRuJ3Qg cHJldmlvdXNseSBiZWVuIHBsYW5uaW5nIG9uIGl0IGJ1dCBhbSBoYXBweSB0byBkbyBzby4NCg0K T24gVHVlLCBNYXIgNiwgMjAxOCBhdCA4OjIyIEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFh dC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpO YXQsDQoNCkR1cmluZyB0aGUgaW50ZXJpbSBtZWV0aW5nLCAzIGRyYWZ0cyBtZW50aW9uZWQgaW4g dGhlIGNvbnRleHQgb2YgRGlzdHJpYnV0ZWQgT0F1dGg6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2Ut MDANCg0KDQpCcmlhbiwgSGFubmVzLA0KDQpBcmUgeW91IHBsYW5uaW5nIG9uIHByZXNlbnRpbmcg eW91ciBkb2N1bWVudHM/DQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KDQoNCg0KDQpPbiBNb24s IE1hciA1LCAyMDE4IGF0IDg6MDkgUE0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29t PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkkgd291bGQgYmUgaW50ZXJlc3Rl ZCBpbiBoZWFyaW5nIHRoYXQuDQoNCkFsc28sIGFzIHBhcnQgb2YgIkRpc3RyaWJ1dGVkIE9BdXRo IiwgY2FuIHdlIGRvIGEgYml0IG9mIHJlLWNhcCBvbiBzb21lIG9mIHRoZSBwcmV2aW91cyBkcmFm dHMgb24gdGhlIHNpbWlsYXIgdG9waWMgYXMgd2UgZGlzY3Vzc2VkIGluIHRoZSBpbnRlcmltPyBp LmUuLCBCcmlhbidzIGRyYWZ0ICh3aGVyZSBpcyB0aGUgbGluayBub3c/KSBhbmQgbXkgZHJhZnQg KGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4LnR4dD4pPw0KDQpCZXN0LA0KDQpOYXQNCg0KT24gVHVl LCBNYXIgNiwgMjAxOCBhdCAzOjMwIEFNIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xl LmNvbTxtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSGFubmVzICYgUmlmYWF0 LA0KDQpJIHdvdWxkIGxpa2UgdGhlIG9wcG9ydHVuaXR5IHRvIHByZXNlbnQgb24gT0F1dGggMi4w IEluY3JlbWVudGFsIEF1dGhvcml6YXRpb24gKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWluY3JlbWVu dGFsLWF1dGgpIFthbiB1cGRhdGUgZm9yIHdoaWNoIHdpbGwgYmUgcG9zdGVkIHRvZGF5XSBhbmQg Ik9BdXRoIDIuMCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzIiAoZHJhZnQtd2Rlbm5pc3Mtb2F1dGgt ZGV2aWNlLXBvc3R1cmUpLg0KDQpJIGNhbiBhbHNvIGdpdmUgYW4gdXBkYXRlIG9uIHRoZSBzdGF0 dXMgb2YgRGV2aWNlIEZsb3cgKGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3cpLiBJIGV4cGVj dCB0aGF0IHRvIGJlIHNob3J0IG5vdyB0aGF0IFdHTEMgaGFzIGNvbmNsdWRlZCBhbmQgdGhlIGRv Y3VtZW50IGhhcyBhZHZhbmNlZC4NCg0KTGl0dGxlIGxhdGUgdG8gdGhpcyB0aHJlYWQgYW5kIEkg c2VlIHdlIGFscmVhZHkgaGF2ZSAyIHNlc3Npb25zIGluIHRoZSBkcmFmdCBhZ2VuZGEsIGJ1dCBJ J2QgbGlrZSB0byBhZGQgbXkgc3VwcG9ydCB0byBrZWVwaW5nIGJvdGggc2Vzc2lvbnMsIHRoZXJl J3MgYWx3YXlzIGEgbG90IHRvIGRpc2N1c3MgYW5kIGluIHRoZSBwYXN0IHdlJ3ZlIGJlZW4gYWJs ZSB0byB1c2UgYW55IHNwYXJlIHRpbWUgdG8gZGlzY3VzcyB0aGUgc2VjdXJpdHkgdG9waWNzIG9m IHRoZSBkYXkuDQoNClJlZ2FyZHMsDQpXaWxsaWFtDQoNCg0KDQpPbiBUdWUsIEphbiAzMCwgMjAx OCBhdCA0OjQwIEFNIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t PG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkl0 IGlzIHRpbWUgYWxyZWFkeSB0byB0aGluayBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgbmV4dCBJ RVRGIG1lZXRpbmcuIFJpZmFhdCBhbmQgSSB3ZXJlIHdvbmRlcmluZyB3aGV0aGVyIHdlIG5lZWQg b25lIG9yIHR3byBzZXNzaW9ucy4gV2Ugd291bGQgbGlrZSB0byBtYWtlIHRoZSBkZWNpc2lvbiBi YXNlZCBvbiB0aGUgdG9waWNzIHdlIHdpbGwgZGlzY3Vzcy4gQmVsb3cgeW91IGNhbiBmaW5kIGEg Zmlyc3QgdmVyc2lvbiBvZiB0aGUgYWdlbmRhIHdpdGggYSBmZXcgcmVtYXJrcy4gTGV0IHVzIGtu b3cgaWYgeW91IGhhdmUgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgZm9yIGFkZGl0aW9uYWwgYWdl bmRhIGl0ZW1zLg0KDQpDaWFvDQpIYW5uZXMgJiBSaWZhYXQNCg0KT0F1dGggQWdlbmRhDQotLS0t LS0tLS0tLS0NCg0KLSBXZWxjb21lIGFuZCBTdGF0dXMgVXBkYXRlICAoQ2hhaXJzKQ0KDQogICog T0F1dGggU2VjdXJpdHkgV29ya3Nob3AgUmVwb3J0DQoNCiAgKiBEb2N1bWVudHMgaW4gSUVTRyBw cm9jZXNzaW5nDQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wNw0KICAgICAj IGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA4DQogICAgICMgZHJhZnQtaWV0Zi1vYXV0aC1q d3NyZXEtMTUNCiAgICAgIyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTExDQoNCiAg ICAgICBSZW1hcms6IFN0YXR1cyB1cGRhdGVzIG9ubHkgaWYgbmVlZGVkLg0KDQotICBKU09OIFdl YiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzDQogICAjIGRyYWZ0LWlldGYtb2F1dGgtand0 LWJjcC0wMA0KDQogICBSZW1hcms6IFdlIGFyZSBsYWNraW5nIHJldmlld3Mgb24gdGhpcyBkb2N1 bWVudC4NCiAgIE1vc3QgbGlrZWx5IHdlIHdpbGwgbm90IGdldCB0aGVtIGR1cmluZyB0aGUgZjJm IG1lZXRpbmcNCiAgIGJ1dCByYXRoZXIgYnkgcmVhY2hpbmcgb3V0IHRvIGluZGl2aWR1YWxzIGFo ZWFkIG9mIHRpbWUuDQoNCi0gIE9BdXRoIDIuMCBNdXR1YWwgVExTIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgQ2VydGlmaWNhdGUgQm91bmQgQWNjZXNzIFRva2Vucw0KICAgIyBkcmFmdC1pZXRm LW9hdXRoLW10bHMtMDYNCg0KICAgUmVtYXJrOiBDb3VsZCBiZSBjb21wbGV0ZWQgYnkgdGhlIHRp bWUgb2YgdGhlIElFVEYgbWVldGluZy4NCg0KLSBPQXV0aCBTZWN1cml0eSBUb3BpY3MNCiAgIyBk cmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0wNA0KDQogIFJlbWFyazogV2UgY291bGQg ZG8gYSBjb25zZW5zdXMgY2FsbCBvbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgc29vbi4NCg0KLSBP QXV0aCAyLjAgVG9rZW4gQmluZGluZw0KICAjIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tYmluZGlu Zy0wNQ0KDQogIFJlbWFyazogRG9jdW1lbnQgaXMgbW92aW5nIGFsb25nIGJ1dCB3ZSBhcmUgbGFj a2luZyBpbXBsZW1lbnRhdGlvbnMuDQoNCi0gT0F1dGggMi4wIERldmljZSBQb3N0dXJlIFNpZ25h bHMNCiAgIyBkcmFmdC13ZGVubmlzcy1vYXV0aC1kZXZpY2UtcG9zdHVyZS0wMQ0KDQogIFJlbWFy azogSW50ZXJlc3QgaW4gdGhlIHdvcmsgYnV0IHdlIGFyZSBsYWNraW5nIGNvbnRlbnQgKG1heWJl IGV2ZW4NCiAgZXhwZXJ0aXNlIGluIHRoZSBncm91cCkNCg0KLSBSZWNpcHJvY2FsIE9BdXRoDQog ICMgZHJhZnQtaGFyZHQtb2F1dGgtbXV0dWFsLTAyDQoNCiAgUmVtYXJrOiBXZSBoYWQgYSB2aXJ0 dWFsIGludGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFuZCB0aGVyZSBpcw0KICBpbnRlcmVz dCBpbiB0aGlzIHdvcmsgYW5kIGFwcGFyZW50bHkgbm8gY29tcGV0aW5nIHNvbHV0aW9ucy4gVGhl IHBsYW4NCiAgaXMgdG8gcnVuIGEgY2FsbCBmb3IgYWRvcHRpb24gb25jZSB3ZSBhcmUgYWxsb3dl ZCB0byBhZGQgYSBuZXcgbWlsZXN0b25lDQogIHRvIG91ciBjaGFydGVyLg0KDQotIERpc3RyaWJ1 dGVkIE9BdXRoDQogICMgZHJhZnQtaGFyZHQtb2F1dGgtZGlzdHJpYnV0ZWQtMDANCg0KICBSZW1h cms6IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRo ZXJlIGlzDQogIGludGVyZXN0IGluIHRoaXMgd29yay4gRnVydGhlciB3b3JrIG9uIHRoZSBzY29w ZSBpcyBuZWVkZWQuDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQotLQ0KDQpOYXQgU2FraW11cmENCg0KQ2hhaXJtYW4gb2YgdGhlIEJv YXJkLCBPcGVuSUQgRm91bmRhdGlvbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCkNP TkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBh dHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg0K --_000_TY1PR01MB1054C1D6EBB6B6180E31F610F9DF0TY1PR01MB1054jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglwYW5vc2UtMToy IDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJOb3RvIFNh bnMgQ0pLIEpQIE1lZGl1bSI7DQoJcGFub3NlLTE6MiAxMSA2IDAgMCAwIDAgMCAwIDA7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBOb3RvIFNhbnMgQ0pLIEpQIE1lZGl1bSI7DQoJcGFu b3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJ cGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBtbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowbW07DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi77yt 77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0Kc3Bhbi5tNjE5MzUxMTQwNTExNDU3NjY1NW0yNDI0Mzkw NDQwMzcyOTc3OTg4aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fNjE5MzUxMTQwNTExNDU3NjY1 NW0yNDI0MzkwNDQwMzcyOTc3OTg4aG9lbnpiO30NCnNwYW4uMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTkuMjVwdCAzMC4wbW0gMzAuMG1tIDMw LjBtbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2Ij4NCjx2OnRleHRib3ggaW5zZXQ9IjUuODVwdCwuN3B0LDUuODVwdCwu N3B0IiAvPg0KPC9vOnNoYXBlZGVmYXVsdHM+PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkpBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Obywgbm90IHJlYWxseS4gSSB3YXMgdGhp bmtpbmcgb2YgbW9yZSBpbmZvcm1hbCB0aGluZy4gVGhlIHNlc3Npb24gaXMgc3VwcG9zZWQgdG8g YmUgV2VkbmVzZGF5IGFmdGVybm9vbiwgc28gSSB3YXMgdGhpbmtpbmcgdGhhdCBpdCBtaWdodCBi ZSBhIGdvb2QNCiBpZGVhIHRvIGRvIGEgYml0IG9mIHJlY2FwIGFtb25nIGNvbnRyaWJ1dG9ycyB0 byBkcmF3IHVwIGEgYmF0dGxlIHBsYW4gdG93YXJkcyBJRVRGIDEwMi4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5hdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUmlmYWF0IFNoZWto LVl1c2VmIFttYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggOToyMiBQTTxicj4NCjxiPlRvOjwvYj4gbi1zYWtp bXVyYSAmbHQ7bi1zYWtpbXVyYUBucmkuY28uanAmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBD YW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7OyBvYXV0aCAmbHQ7b2F1 dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwg Zm9yIGFnZW5kYSBpdGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcmUgeW91IGFza2luZyBmb3IgYW4gaW50 ZXJpbSBtZWV0aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBjb3VsZCBzY2hlZHVsZSB0aGUg RGlzdHJpYnV0ZWQgT0F1dGggZGlzY3Vzc2lvbiBmb3IgdGhlIFdlZG5lc2RheSBtZWV0aW5nOyB0 aGF0IHdpbGwgZ2l2ZSB5b3UgZ3V5cyBzb21ldGltZSB0byBkaXNjdXNzIHRoZXNlIGZhY2UtdG8t ZmFjZSBpbiBMb25kb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtSaWZhYXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBNYXIgNywg MjAxOCBhdCAyOjAwIEFNLCBuLXNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86bi1zYWtpbXVy YUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2ltdXJhQG5yaS5jby5qcDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MG1tIDBtbSAwbW0g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBtbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhlbiBsZXQgdXMgZG8gaXQuIFdlIG5lZWQgdG8gcHV0IGFsbCB0aGUgcHJvcG9z YWxzIG9uIHRoZSB0YWJsZSBhbmQgc3RyYXRlZ2l6ZSB0aGUgZGVzaWduLg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlcmhhcHMgd2Ug bmVlZCBhIHNpZGUgbWVldGluZyBhcyB3ZWxsLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5uYXQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGgNCiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTggMTozMSBBTTxicj4NCjxiPlRv OjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFnZW5kYSBpdGVtczwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGFkbid0IHByZXZpb3Vz bHkgYmVlbiBwbGFubmluZyBvbiBpdCBidXQgYW0gaGFwcHkgdG8gZG8gc28uDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUs IE1hciA2LCAyMDE4IGF0IDg6MjIgQU0sIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MG1tIDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MG1tO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+RHVyaW5nIHRoZSBpbnRlcmltIG1lZXRpbmcsIDMg ZHJhZnRzIG1lbnRpb25lZCBpbiB0aGUgY29udGV4dCBvZg0KPGI+RGlzdHJpYnV0ZWQgT0F1dGg8 L2I+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA4 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2lt dXJhLW9hdXRoLW1ldGEtMDg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcnMtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkJyaWFu LCBIYW5uZXMsPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QXJlIHlvdSBwbGFubmluZyBvbiBw cmVzZW50aW5nIHlvdXIgZG9jdW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7UmlmYWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5P biBNb24sIE1hciA1LCAyMDE4IGF0IDg6MDkgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MG1tIDBtbSAwbW0gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MG1tO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFy aW5nIHRoYXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHNv LCBhcyBwYXJ0IG9mICZxdW90O0Rpc3RyaWJ1dGVkIE9BdXRoJnF1b3Q7LCBjYW4gd2UgZG8gYSBi aXQgb2YgcmUtY2FwIG9uIHNvbWUgb2YgdGhlIHByZXZpb3VzIGRyYWZ0cyBvbiB0aGUgc2ltaWxh ciB0b3BpYyBhcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIGludGVyaW0/IGkuZS4sIEJyaWFuJ3MNCiBk cmFmdCAod2hlcmUgaXMgdGhlIGxpbmsgbm93PykgYW5kIG15IGRyYWZ0ICg8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDgudHh0IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiM0NDAwODgiPmRyYWZ0LXNh a2ltdXJhLW9hdXRoLW1ldGE8L3NwYW4+PC9hPik/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCwmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5OYXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IFR1ZSwgTWFyIDYsIDIwMTggYXQgMzozMCBBTSBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9 Im1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowbW07bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhbm5lcyAmYW1w OyBSaWZhYXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KSSB3b3VsZCBsaWtlIHRoZSBv cHBvcnR1bml0eSB0byBwcmVzZW50IG9uJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+T0F1dGggMi4wIEluY3JlbWVu dGFsIEF1dGhvcml6YXRpb24gKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWluY3JlbWVudGFsLWF1dGgp IFthbiB1cGRhdGUgZm9yIHdoaWNoIHdpbGwNCiBiZSBwb3N0ZWQgdG9kYXldIGFuZDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7JnF1b3Q7T0F1dGggMi4wIERldmljZSBQb3N0dXJlIFNp Z25hbHMmcXVvdDsgKGRyYWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1wb3N0dXJlKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGNhbiBhbHNv IGdpdmUgYW4gdXBkYXRlIG9uIHRoZSBzdGF0dXMgb2YgRGV2aWNlIEZsb3cgKGRyYWZ0LWlldGYt b2F1dGgtZGV2aWNlLWZsb3cpLiBJIGV4cGVjdCB0aGF0IHRvIGJlIHNob3J0IG5vdyB0aGF0IFdH TEMgaGFzIGNvbmNsdWRlZCBhbmQgdGhlIGRvY3VtZW50DQogaGFzIGFkdmFuY2VkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkxpdHRsZSBsYXRl IHRvIHRoaXMgdGhyZWFkIGFuZCBJIHNlZSB3ZSBhbHJlYWR5IGhhdmUgMiBzZXNzaW9ucyBpbiB0 aGUgZHJhZnQgYWdlbmRhLCBidXQgSSdkIGxpa2UgdG8gYWRkIG15IHN1cHBvcnQgdG8ga2VlcGlu ZyBib3RoIHNlc3Npb25zLCB0aGVyZSdzIGFsd2F5cyBhDQogbG90IHRvIGRpc2N1c3MgYW5kIGlu IHRoZSBwYXN0IHdlJ3ZlIGJlZW4gYWJsZSB0byB1c2UgYW55IHNwYXJlIHRpbWUgdG8gZGlzY3Vz cyB0aGUgc2VjdXJpdHkgdG9waWNzIG9mIHRoZSBkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5XaWxsaWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gVHVlLCBKYW4gMzAsIDIwMTggYXQgNDo0MCBBTSBIYW5uZXMgVHNjaG9mZW5pZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2Js YW5rIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBtbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiI+SGkgYWxsLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IGlzIHRpbWUgYWxyZWFk eSB0byB0aGluayBhYm91dCB0aGUgYWdlbmRhIGZvciB0aGUgbmV4dCBJRVRGIG1lZXRpbmcuIFJp ZmFhdCBhbmQgSSB3ZXJlIHdvbmRlcmluZyB3aGV0aGVyIHdlIG5lZWQgb25lIG9yIHR3byBzZXNz aW9ucy4gV2Ugd291bGQgbGlrZSB0byBtYWtlDQogdGhlIGRlY2lzaW9uIGJhc2VkIG9uIHRoZSB0 b3BpY3Mgd2Ugd2lsbCBkaXNjdXNzLiBCZWxvdyB5b3UgY2FuIGZpbmQgYSBmaXJzdCB2ZXJzaW9u IG9mIHRoZSBhZ2VuZGEgd2l0aCBhIGZldyByZW1hcmtzLiBMZXQgdXMga25vdyBpZiB5b3UgaGF2 ZSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBmb3IgYWRkaXRpb25hbCBhZ2VuZGEgaXRlbXMuDQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+Q2lhbzxicj4NCkhhbm5lcyAmYW1wOyBSaWZhYXQ8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5PQXV0 aCBBZ2VuZGE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIFdlbGNvbWUgYW5kIFN0YXR1cyBV cGRhdGUmbmJzcDsgKENoYWlycyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAqIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIFJlcG9ydDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsqIERvY3VtZW50cyBpbiBJRVNHIHByb2Nlc3Npbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wNw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyMgZHJh ZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDgNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsjIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTE1PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjIGRyYWZ0LWlldGYtb2F1 dGgtdG9rZW4tZXhjaGFuZ2UtMTE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwO1JlbWFyazogU3RhdHVzIHVwZGF0ZXMgb25seSBpZiBuZWVkZWQu DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tJm5ic3A7IEpTT04gV2ViIFRva2VuIEJlc3QgQ3Vy cmVudCBQcmFjdGljZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICMgZHJhZnQt aWV0Zi1vYXV0aC1qd3QtYmNwLTAwDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwO1JlbWFyazogV2Ug YXJlIGxhY2tpbmcgcmV2aWV3cyBvbiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgTW9zdCBsaWtlbHkgd2Ugd2lsbCBub3QgZ2V0IHRoZW0gZHVyaW5nIHRo ZSBmMmYgbWVldGluZw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwO2J1 dCByYXRoZXIgYnkgcmVhY2hpbmcgb3V0IHRvIGluZGl2aWR1YWxzIGFoZWFkIG9mIHRpbWUuDQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPi0mbmJzcDsgT0F1dGggMi4wIE11dHVhbCBUTFMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBDZXJ0aWZpY2F0ZSBCb3VuZCBBY2Nlc3MgVG9rZW5zPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyAjIGRyYWZ0LWlldGYtb2F1dGgtbXRscy0wNg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUmVtYXJrOiBDb3Vs ZCBiZSBjb21wbGV0ZWQgYnkgdGhlIHRpbWUgb2YgdGhlIElFVEYgbWVldGluZy4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBP QXV0aCBTZWN1cml0eSBUb3BpY3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQt aWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMDQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7UmVtYXJrOiBXZSBjb3Vs ZCBkbyBhIGNvbnNlbnN1cyBjYWxsIG9uIHBhcnRzIG9mIHRoZSBkb2N1bWVudCBzb29uLg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9B dXRoIDIuMCBUb2tlbiBCaW5kaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRyYWZ0 LWlldGYtb2F1dGgtdG9rZW4tYmluZGluZy0wNTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtSZW1hcms6IERvY3VtZW50IGlzIG1v dmluZyBhbG9uZyBidXQgd2UgYXJlIGxhY2tpbmcgaW1wbGVtZW50YXRpb25zLg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIE9BdXRoIDIu MCBEZXZpY2UgUG9zdHVyZSBTaWduYWxzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAjIGRy YWZ0LXdkZW5uaXNzLW9hdXRoLWRldmljZS1wb3N0dXJlLTAxDQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwO1JlbWFyazog SW50ZXJlc3QgaW4gdGhlIHdvcmsgYnV0IHdlIGFyZSBsYWNraW5nIGNvbnRlbnQgKG1heWJlIGV2 ZW4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtleHBlcnRpc2UgaW4gdGhlIGdy b3VwKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t IFJlY2lwcm9jYWwgT0F1dGg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICMgZHJhZnQtaGFy ZHQtb2F1dGgtbXV0dWFsLTAyDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyBSZW1hcms6IFdlIGhhZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0 aW5nIG9uIHRoaXMgdG9waWMgYW5kIHRoZXJlIGlzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7aW50ZXJlc3QgaW4gdGhpcyB3b3JrIGFuZCBhcHBhcmVudGx5IG5vIGNvbXBldGlu ZyBzb2x1dGlvbnMuIFRoZSBwbGFuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBpcyB0byBy dW4gYSBjYWxsIGZvciBhZG9wdGlvbiBvbmNlIHdlIGFyZSBhbGxvd2VkIHRvIGFkZCBhIG5ldyBt aWxlc3RvbmUNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDt0byBvdXIgY2hhcnRl ci4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+LSBEaXN0cmlidXRlZCBPQXV0aDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgIyBkcmFm dC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC0wMA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgUmVtYXJrOiBXZSBoYWQgYSB2aXJ0dWFsIGlu dGVyaW0gbWVldGluZyBvbiB0aGlzIHRvcGljIGFuZCB0aGVyZSBpcw0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwO2ludGVyZXN0IGluIHRoaXMgd29yay4gRnVydGhlciB3b3JrIG9u IHRoZSBzY29wZSBpcyBuZWVkZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeQ0K IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBjbGFzcz0ibTYxOTM1MTE0MDUxMTQ1NzY2NTVtMjQyNDM5MDQ0MDM3Mjk3 Nzk4OGhvZW56YiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLQ0K PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TmF0IFNh a2ltdXJhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNoYWlybWFuIG9mIHRo ZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48 Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpu b25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowbW0iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6 IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVy aWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkDQogcmVjaXBpZW50KHMpLiBBbnkg cmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLg0KIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_TY1PR01MB1054C1D6EBB6B6180E31F610F9DF0TY1PR01MB1054jpnp_-- From nobody Thu Mar 8 10:20:02 2018 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 7A8081243F6; Thu, 8 Mar 2018 10:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 jCXeGU8YJJyA; Thu, 8 Mar 2018 10:19:57 -0800 (PST) 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 81A3B120725; Thu, 8 Mar 2018 10:19:57 -0800 (PST) X-AuditID: 1209190e-5f3ff7000000336e-b6-5aa17ecb97d3 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 0C.78.13166.BCE71AA5; Thu, 8 Mar 2018 13:19:56 -0500 (EST) 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 w28IJpd5009969; Thu, 8 Mar 2018 13:19:52 -0500 Received: from [192.168.2.61] (108-202-177-16.lightspeed.sntcca.sbcglobal.net [108.202.177.16]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w28IJk9W027626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2018 13:19:48 -0500 From: Justin Richer Message-Id: <49D385E2-0E71-4913-8012-E6F479EF318F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F85B0362-DBBC-41AC-9ACC-917BFFEAE3AA" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 8 Mar 2018 10:19:45 -0800 In-Reply-To: Cc: Rifaat Shekh-Yusef , iesg-secretary@ietf.org, "" , oauth-chairs@ietf.org To: William Denniss References: <151517342925.14706.13583633097065531665.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F7F91B492@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsUixG6nonumbmGUwcyj0hb9/x0tbs9dyWZx 8u0rNoudL1rZLDbNaWZ3YPXYOesuu8eCTaUeS5b8ZApgjuKySUnNySxLLdK3S+DKWHKHvWCC a8XhqQ1MDYznbboYOTkkBEwkuj49Ye5i5OIQEljMJDH39V52CGcDo8Tkrj9MEM5tJok9Exax gLSwCahKTF/TwgRi8wpYSbw6/RbMZhZIkpjYcQIqbiLx/u1DMFtYIEbi7f817CA2i4CKxJVF D8FsToFAiY6+xVC9PYwSq++AnSQioCnx8uwBFojFK5kk+iYdZYG4VUli+vfbbBMY+Wch2TcL yT6IuLbEsoWvmSFsTYn93ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdY LzezRC81pXQTIyj8OSX5djBOavA+xCjAwajEw/vAcWGUEGtiWXFl7iFGSQ4mJVFe36wFUUJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeHuzgcp5UxIrq1KL8mFS0hwsSuK87ibaUUIC6Yklqdmp qQWpRTBZGQ4OJQne67VAjYJFqempFWmZOSUIaSYOTpDhPEDDXatBhhcXJOYWZ6ZD5E8xWnJs efSyjZnjAJi88eJ1G7MQS15+XqqUOO9NkKECIA0ZpXlwM0HpLOfURoFXjOJALwrzpoCM5QGm Qripr4AWMgEt3Ht5AcjCkkSElFQD4x6rY8/nMS09K8+vs/tvqZ7sjZlnWW1fZSksclReMkF9 4uwlHAvv6bX9lty/8pP6qQ3Nftyl65SWux3i3tlouD5Z70WqdHXfyaXfZjtrfFxk+vjm810B ATq669c/uPf09pUPgfoFMTNVAm+fiOsJbHyiarTpdPSCvTMMZxbeYg/qy+szfTid66sSS3FG oqEWc1FxIgBL7fklQgMAAA== Archived-At: Subject: Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07 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, 08 Mar 2018 18:20:00 -0000 --Apple-Mail=_F85B0362-DBBC-41AC-9ACC-917BFFEAE3AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Mar 5, 2018, at 10:23 PM, William Denniss = wrote: >=20 > Thanks again for the feedback Scott. I've staged an update here: = https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6 = >=20 > It expands on the brute force attack section to include some detail on = this attack, as it is quite unique for OAuth brute-force attacks (since = the victim actually ends up with the attacker's grant on the device, = instead of the other way around =E2=80=93 not that this is totally safe = of course, it's just unique). It also adds some further discussion = around what factors need to be considered by authorization servers when = creating the user code format. >=20 > I'll post this once my co-authors have reviewed, and the submission = tool re-opens. >=20 >=20 > On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef = > wrote: > Hi Scott, >=20 > Sorry, I missed that last discussion that you had with William. >=20 >=20 > William, >=20 > Can you please update the document based on your last discussion with = Scott? > I will then update the request for publication to use the new updated = version. >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott = > wrote: > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Rifaat Shekh- > > Yusef > > Sent: Friday, January 05, 2018 12:30 PM > > To: ekr@rtfm.com > > Cc: oauth@ietf.org ; iesg-secretary@ietf.org = ; oauth-chairs@ietf.org = > > Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for = draft- > > ietf-oauth-device-flow-07 > > > > Rifaat Shekh-Yusef has requested publication of = draft-ietf-oauth-device- > > flow-07 as Proposed Standard on behalf of the OAUTH working group. > > > > Please verify the document's state at > > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ = >=20 > The document really should be updated to reflect the last call = discussions prior to requesting publication for the -07 version that = needs to be updated. >=20 > Scott >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F85B0362-DBBC-41AC-9ACC-917BFFEAE3AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On Mar 5, 2018, at 10:23 PM, William Denniss <wdenniss@google.com>= wrote:

Thanks again for the feedback = Scott. I've staged an update here: https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/= pull/6

It = expands on the brute force attack section to include some detail on this = attack, as it is quite unique for OAuth brute-force attacks (since the = victim actually ends up with the attacker's grant on the device, instead = of the other way around =E2=80=93 not that this is totally safe of = course, it's just unique).  It also adds some further discussion = around what factors need to be considered by authorization servers when = creating the user code format.

I'll post this once my co-authors have = reviewed, and the submission tool re-opens.


On = Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi Scott,

Sorry, I missed that last discussion that you had with = William.


William,

Can you please update = the document based on your last discussion with Scott?
I will then update the request for publication to use the new = updated version.

Regards,
 Rifaat



On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott = <shollenbeck@verisign.com> wrote:
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Rifaat Shekh-
> Yusef
> Sent: Friday, January 05, 2018 12:30 PM
> To: ekr@rtfm.com
> Cc: oauth@ietf.org; iesg-secretary@ietf.org; oauth-chairs@ietf.org
> Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for = draft-
> ietf-oauth-device-flow-07
>
> Rifaat Shekh-Yusef has requested publication of = draft-ietf-oauth-device-
> flow-07 as Proposed Standard on behalf of the OAUTH working = group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/<= /a>

The document really should be updated to reflect the last = call discussions prior to requesting publication for the -07 version = that needs to be updated.

Scott

_______________________________________________
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=_F85B0362-DBBC-41AC-9ACC-917BFFEAE3AA-- From nobody Fri Mar 9 09:49:29 2018 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 D783F1241FC for ; Fri, 9 Mar 2018 09:49:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fxUSAeFlNd02 for ; Fri, 9 Mar 2018 09:49:26 -0800 (PST) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.104]) (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 F04471275AB for ; Fri, 9 Mar 2018 09:49:21 -0800 (PST) Received: from [79.253.43.202] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1euM8v-0003by-CL; Fri, 09 Mar 2018 18:49:21 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6105202C-51D5-4745-9DEE-9B41463AA6B4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 9 Mar 2018 18:49:17 +0100 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] IETF101 Draft Agenda 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, 09 Mar 2018 17:49:29 -0000 --Apple-Mail=_6105202C-51D5-4745-9DEE-9B41463AA6B4 Content-Type: multipart/alternative; boundary="Apple-Mail=_56E43B59-AAC1-4C6A-B30D-EF2D0FA597CC" --Apple-Mail=_56E43B59-AAC1-4C6A-B30D-EF2D0FA597CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you please add the security topics to the agenda for Wednesday?=20 I will publish -05 soon and I support your proposal to talk about a = consensus call.=20 Thanks, Torsten.=20 > Am 07.03.2018 um 19:53 schrieb Rifaat Shekh-Yusef = : >=20 > Here is the draft agenda for our two sessions: >=20 > Monday > = https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa = >=20 > Wednesday > = https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessb = >=20 > Please, let us know if you have any comments. >=20 > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_56E43B59-AAC1-4C6A-B30D-EF2D0FA597CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Can = you please add the security topics to the agenda for = Wednesday? 

I = will publish -05 soon and I support your proposal to talk about a = consensus call. 

Thanks, Torsten. 

Am 07.03.2018 um 19:53 schrieb = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

Here is the draft agenda for our two = sessions:

Monday
https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa

Wednesday
https://datatracker.ietf.org/meeting/101/materials/agenda-101-o= auth-sessb

Please, let us know if you have any = comments.

Regards,
 Rifaat & = Hannes
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_56E43B59-AAC1-4C6A-B30D-EF2D0FA597CC-- --Apple-Mail=_6105202C-51D5-4745-9DEE-9B41463AA6B4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzA5MTc0OTE4WjAjBgkqhkiG9w0BCQQxFgQUhCC49yprrElQ IW7m8wRDaNN2eJswgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAHdI+1BBpXSge/+BjBFWCp4r0D/+8X//7pfshBVx4sKGvWAcHVkl U9noVhLAETPUcTr50R3CMQ9rV8jGAbFUYH9bxJc0Q3w9NcluOH/ZieJ+/u3aKmQOShdt3YSLnFw9 CFuNsRNCPdWAHZmPq9E1YfNhbXmVh33md30glj1z+6wzY7efK8WE/KfFlemCHoI8D/E+Qashv/8C 9PH0FyPleDwrObQcrLnvheObe0o6MFh1IrJglwkVV+GBWp6PSY45C1f+DdQDdjYMHThJ8vJocmhM nzfnnuaY5o0PfNULZFVEU8oD0bgdXHXcEFggVqvkV74pYabP51cQxv7ozZ3T9/sAAAAAAAA= --Apple-Mail=_6105202C-51D5-4745-9DEE-9B41463AA6B4-- From nobody Sun Mar 11 10:06:27 2018 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 2F09A126B7E for ; Sun, 11 Mar 2018 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=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 oGRsLdrfuvmY for ; Sun, 11 Mar 2018 10:06:22 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (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 9334912426E for ; Sun, 11 Mar 2018 10:06:22 -0700 (PDT) Received: from [79.253.43.202] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ev4QM-0003eq-Ub; Sun, 11 Mar 2018 18:06:19 +0100 From: Torsten Lodderstedt Message-Id: <66B283FD-7336-45AF-A28F-71A28D11E502@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D6D1E8AB-7850-4320-9EAB-4D5CF8CE6B1C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 11 Mar 2018 18:06:17 +0100 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] IETF101 Draft Agenda 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, 11 Mar 2018 17:06:25 -0000 --Apple-Mail=_D6D1E8AB-7850-4320-9EAB-4D5CF8CE6B1C Content-Type: multipart/alternative; boundary="Apple-Mail=_3BAACE88-4D0D-44B1-9244-2DF5354154C3" --Apple-Mail=_3BAACE88-4D0D-44B1-9244-2DF5354154C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you please add another item to the Agenda of the Wednesday session? = I just created a new draft, which adds a JWT-based response mode to the = OAuth Token Introspection Endpoint (see attachment). I would like to = present this topic to the working group. 10 min should be enough.=20 I will submit the draft as soon as the submission tool re-opens. > Am 09.03.2018 um 18:49 schrieb Torsten Lodderstedt = : >=20 > Can you please add the security topics to the agenda for Wednesday?=20 >=20 > I will publish -05 soon and I support your proposal to talk about a = consensus call.=20 >=20 > Thanks, Torsten.=20 >=20 >> Am 07.03.2018 um 19:53 schrieb Rifaat Shekh-Yusef = >: >>=20 >> Here is the draft agenda for our two sessions: >>=20 >> Monday >> = https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa = >>=20 >> Wednesday >> = https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessb = >>=20 >> Please, let us know if you have any comments. >>=20 >> Regards, >> Rifaat & Hannes >> _______________________________________________ >> 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=_3BAACE88-4D0D-44B1-9244-2DF5354154C3 Content-Type: multipart/mixed; boundary="Apple-Mail=_76A51DD7-1437-47D0-8C89-253708BD307E" --Apple-Mail=_76A51DD7-1437-47D0-8C89-253708BD307E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Can you please add another item to the Agenda of the Wednesday session? I just created a new draft, which adds a JWT-based response mode to the OAuth Token Introspection Endpoint (see attachment). I would like to present this topic to the working group. 10 min should be enough. 

I will submit the draft as soon as the submission tool re-opens.

--Apple-Mail=_76A51DD7-1437-47D0-8C89-253708BD307E Content-Disposition: attachment; filename=draft-lodderstedt-oauth-jwt-introspection-response.html Content-Type: text/html; x-unix-mode=0644; name="draft-lodderstedt-oauth-jwt-introspection-response.html" Content-Transfer-Encoding: 7bit JWT Response for OAuth Token Introspection
Open Authentication Protocol T. Lodderstedt, Ed.
Internet-Draft YSES.com AG
Intended status: Standards Track March 11, 2018
Expires: September 10, 2018

JWT Response for OAuth Token Introspection
draft-lodderstedt-oauth-jwt-introspection-response-00

Abstract

This draft proposes an additional JWT-based response type for the OAuth 2.0 Token Introspection endpoint.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 10, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

OAuth 2.0 Token Introspection [RFC7662] introduces a mechanisms to query data associated with a certain access token and its status at the respective authorization server. This allows deployments to implement handle-based access tokens in an interoperable way.

The introspection endpoint as specified in OAuth 2.0 Token Introspection [RFC7662] returns the token data as a plain JSON object in "application/json" format. However, there are use cases where the resource server needs evidence about the fact the AS minted the access token and is liable for its contents. An example is a resource server using verified person data to create qualified electronic signatures.

In such use cases, it would be useful to return a signed JWT as introspection response. This draft extends the Introspection Endpoint by the capability to return responses as JWTs.

2. JWT Response

The introspection endpoint may respond with a JWT in "application/jwt" format.

This JWT may contain all the members describes in Section 2.2. of [RFC7662].

TBD: is the status needed in this format?

3. Client Metadata

The authorization server determines what format to use for a particular introspection response. The decision can be based on the mechanisms described in this section.

The proposal is to register resource servers as client and let them determine the response format by utilizing new parameters for dynamic client registration.

The new parameters follow the pattern established by the OpenID Connect Dynamic Client registration [OpenID.Registration] specification for configuring signing and encryption algorithms for the user info endpoint.

The following parameters are introduced by this specification:

introspection_response_signed_response_alg
JWS [RFC7515] alg algorithm JWA [RFC7518] REQUIRED for signing introspection responses. If this is specified, the response will be JWT [RFC7519] serialized, and signed using JWS. The default, if omitted, is for the introspection response to return the Claims as a UTF-8 encoded JSON object using the application/json content-type as defined in [RFC7662].
introspection_response_encrypted_response_alg
JWE [RFC7516] alg algorithm JWA [RFC7518] REQUIRED for encrypting introspection responses. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in JWT [RFC7519]. The default, if omitted, is that no encryption is performed.
introspection_response_encrypted_response_enc
JWE [RFC7516] enc algorithm JWA [RFC7518] REQUIRED for encrypting introspection responses. If introspection_response_encrypted_response_algy is specified, the default for this value is A128CBC-HS256. When introspection_response_encrypted_response_enc is included, introspection_response_encrypted_response_alg MUST also be provided.

4. Acknowledgements

We would like to thank ...

5. IANA Considerations

TBD

6. Security Considerations

TBD

7. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999.
[RFC7519] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015.
[RFC7591] Richer, J., Jones, M., Bradley, J., Machulak, M. and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015.
[RFC7662] Richer, J., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015.
[RFC7515] Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015.
[OpenID.Registration] NRIPing IdentityMicrosoft, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", Nov 2014.

Author's Address

Torsten Lodderstedt editor YSES.com AG EMail: torsten@lodderstedt.net
--Apple-Mail=_76A51DD7-1437-47D0-8C89-253708BD307E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Am 09.03.2018 um 18:49 schrieb = Torsten Lodderstedt <torsten@lodderstedt.net>:

Can you please add the = security topics to the agenda for Wednesday? 

I will publish -05 soon and I support = your proposal to talk about a consensus call. 

Thanks, = Torsten. 

Am 07.03.2018 um 19:53 schrieb = Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

Here is the draft agenda for our two = sessions:

Monday
https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa

Wednesday
https://datatracker.ietf.org/meeting/101/materials/agenda-101-o= auth-sessb

Please, let us know if you have any = comments.

Regards,
 Rifaat & = 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

= --Apple-Mail=_76A51DD7-1437-47D0-8C89-253708BD307E-- --Apple-Mail=_3BAACE88-4D0D-44B1-9244-2DF5354154C3-- --Apple-Mail=_D6D1E8AB-7850-4320-9EAB-4D5CF8CE6B1C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzExMTcwNjE4WjAjBgkqhkiG9w0BCQQxFgQUDe5BlJb6RGNK rRI205cwBb7Z3F8wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBALESWFcbReVLnKwuT2rYeu/s2jbP0z0YXr0KaKqG6iluPZviGGz5 BAzidX3J5jzo2CiBECl8i0+qpPkZN8TPWA3WOPmQHn4PWHXhXiymfe3Pt1B0HpDmlSJeAPz19eLi dkjWqwY5jIFeHooJUwyw8H4ja7iKdu0tjMVK8fH3IuarzgjonTnHVmh5jPUyzsjxI/6iFy8BgUzP bMxVYCsTsLtkoRZtD/RMHWtA07EaJuexB9wFzKvkH1oT90PtlmBQyeZpP8GI4cXDdnm2QzBS3i+A hcOQ9R926C9CSgO6gK23bzCItLvF8CHAgsSe3sFnnAgOgrPwC3fRGniDGNNEAAIAAAAAAAA= --Apple-Mail=_D6D1E8AB-7850-4320-9EAB-4D5CF8CE6B1C-- From nobody Mon Mar 12 13:28:43 2018 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 B2629126CF9 for ; Mon, 12 Mar 2018 13:28:40 -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 U1VdlF8_IH_P for ; Mon, 12 Mar 2018 13:28:39 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 0EED51241FC for ; Mon, 12 Mar 2018 13:28:39 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id f6so7100106vkh.6 for ; Mon, 12 Mar 2018 13:28:39 -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=LFbngSoHsFgGxTRcVltiG9kFpJoYS23n2Kw9CBer5uA=; b=QdypCUD+E/Fpf5HTYJO7AwHs0tvd+qYiR/kdT3HvG8mPG9lUUfVVHAIbV8+m1A6K8h rshM4rDwy+3ZrskOLAzx6NHb0gNkS7XM7lR2WeZwwdPOGX7/0+UOGgcTU/uMSqgzuZ99 KXRq27MAQyjCNMJ/1NVfs5YdSxorc6oj1PQweyqEANwiGQxlzmC2/5AgaEIldumMv6tI WBD5Ekpc0kts7s1wH2+PHrMysO4lMx96f73VjubdFOpvlzeULzqOK+IKcJ6Ht9ZHJj3j K2iz4eFSfLq1msMBQ4ucvEkDrwHwqoO7FSVM88OwqJq1GIgMLgUwAP2L/mEfsLEfNgUe kvZg== 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=LFbngSoHsFgGxTRcVltiG9kFpJoYS23n2Kw9CBer5uA=; b=rHG5J7CNYrK/jiyzbamMKp5PwTeOZFy3y7pHK/hVaC3rucWQMYvtxp959wa8QsS7pj kh0thi/lw0wS/LQnNFym1NNRtS0AkMRYFTVlYdgYcRKzydc4jKrBd+RDEAyUi6q57Wg9 WCndeNLkY2AZl6tkeCu8WTh0vMWJyOlV/FqaPhR73S33pYaRXyDx0Fw5egaBB1bnQjrj 7nUQXtxCgtXj9gw+QcQ2QB0PrzFcSfvl0aSXJasHp3Au9jIZa5UEx0IWF2oZzBRvJaT7 t4wEQsmJmRb6lLHigB3VJ/fsvd+3jOZ701Y2FmXHsjWOs+0eobUhQDytwcIcsaeIwJGd G52w== X-Gm-Message-State: AElRT7EsISrsGF2+6z9d6ChF6Ez6Ny9onbL0Dyze5xGNHWI3Nmk3KD9R aKDzHjtrGTaWp4OaIIlQaVYnAmypWePECOYhiOajpljy X-Google-Smtp-Source: AG47ELuRfavxm4X1tXX4sJo1HIWLRPpqmIzTaTH0rYK3DazgHmDZqbz/D+bQ78FXUtorfmIbcW1Bb4kfIF+i+KgIM2w= X-Received: by 10.31.95.5 with SMTP id t5mr5902130vkb.169.1520886517773; Mon, 12 Mar 2018 13:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.45.148 with HTTP; Mon, 12 Mar 2018 13:28:37 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 12 Mar 2018 16:28:37 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="001a114e5d1ea2ba4305673cfcaa" Archived-At: Subject: [OAUTH-WG] IETF101 Agenda 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, 12 Mar 2018 20:28:41 -0000 --001a114e5d1ea2ba4305673cfcaa Content-Type: text/plain; charset="UTF-8" Hi, Here is the updated agenda for our two sessions: https://datatracker.ietf.org/meeting/101/materials/agenda-101-oauth-sessa Please, take a look and let us know if you have any comments. Regards, Rifaat & Hannes. --001a114e5d1ea2ba4305673cfcaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here is the updated agenda fo= r our two sessions:

Please, = take a look and let us know if you have any comments.

<= div>Regards,
=C2=A0Rifaat & Hannes.
--001a114e5d1ea2ba4305673cfcaa-- From nobody Sun Mar 18 01:16:14 2018 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 4FCD9127010 for ; Sun, 18 Mar 2018 01:16:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=curity-io.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 Y7uADq8kWHji for ; Sun, 18 Mar 2018 01:16:10 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 82BDE124BFA for ; Sun, 18 Mar 2018 01:16:10 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id i28-v6so9736254otf.8 for ; Sun, 18 Mar 2018 01:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dSs6o6xorZ+11EL54wutO6+DrHmf9RPAw0IoPFxGzmk=; b=oAlnWtbXsHYkoqQuerDgZUIN4ZjFRsc4eluAcUI/teUfT6tqk9R0xX4RUks8Hz3hMg +glNhIIyLau8W5AqFmfM4C7d52omcndYeqGine+uX7mWkcqB3Xxof6OmZmXqZZrNyM1/ kFyIKU3zHUA3rttLFTrXAItkU5Z3DCHb1Jz4D+URxY1CoZZOY9BEeSekNSAzjrGA6llG C9Tr1RNc93Et6V7dSjR15Nl+f3tU2KqBW1zTsJakpEvymeHBCbntt4zUGFu3DLXRCVCs zoc6vTHmWjlvvq+nDHNqRvxEI/t7w1LjiS2jqAn5jm5ovkLfGoAfakvg1g9K4HfCMPCl 4pLg== 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=dSs6o6xorZ+11EL54wutO6+DrHmf9RPAw0IoPFxGzmk=; b=d2T6KoNovQG76H9RG9OcJ3tpJ4Jc3CpNiWH+JLP/UZdqEzf4xdn+AaJgprIBiAbrjV RZL7RUOaKBGhxluz2j8AVf0UszgxPRnLl+MUnRh0A06ap2N20NJF3pm9iNFh239q1hJA aSKBktNi3u5KYhOpoyIpW9drJquDB0C5bKsCqGfr+eba9C0kZH6YvZy3ImOJjP4DXlRU nToL9IpcBtE69Y6qo18ZdPAm9vHoIPNkA9CjsqpyNgsnO3v1FGAIRzxhzu35nEcVVRcZ 2sRQiyoBb6S9iviEMJchOg8e0iAaSrYvGS8zY+DROsUs+CxGmcKCAMgQU4BngUApnS1I wvYg== X-Gm-Message-State: AElRT7F+4QYSOaFNdKm4p/Y8jnNN1g1veM/xiYIXZmuE46hOyVQY6nlK cSUAhUVzR4zpuC19U+oVfk405yeIC2IV8KrOqa3n6GHY8ZY= X-Google-Smtp-Source: AG47ELs9sfrQNkeQc+hEqK2HStI33s35H45NQ88kvpqikmDR8PHYpZCtyHZuMNqbX44hA5eN/G0KsUG0tnvt3uEySzk= X-Received: by 2002:a9d:b5a:: with SMTP id p26-v6mr4773423otd.290.1521360969886; Sun, 18 Mar 2018 01:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.70.135 with HTTP; Sun, 18 Mar 2018 01:15:49 -0700 (PDT) From: Travis Spencer Date: Sun, 18 Mar 2018 09:15:49 +0100 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Assisted token 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: Sun, 18 Mar 2018 08:16:12 -0000 Good Morning All, We have submitted a draft of our "assisted token flow", which my colleague, Jacob Ideskog, presented at the OAuth Security Workshop in Zurich last summer.[1] The submission can be found here: https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ Some more detailed slides explaining the protocol can be found at [2]. There are a couple open source examples on GitHub as well.[3][4] Mark Dobrinc and myself will be at the IETF event in London Monday through Wednesday. If anyone has interest and time, we would love to talk more about this. We can give a demo as well; just grab us. We're eager to receive feedback on this new proposal, and hope to discuss more in London. -- Regards, Travis Spencer [1] https://zisc.ethz.ch/oauth-security-workshop-2017/ [2] https://zisc.ethz.ch/wp-content/uploads/2017/02/ideskog_assisted-token.pdf [3] https://github.com/curityio/react-assisted-token-website [4] https://github.com/curityio/angular-assisted-token-website From nobody Sun Mar 18 12:12:51 2018 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 6585B126D73; Sun, 18 Mar 2018 12:12: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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152140037038.15884.10827592494483262164@ietfa.amsl.com> Date: Sun, 18 Mar 2018 12:12:50 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Sun, 18 Mar 2018 19:12:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Filename : draft-ietf-oauth-security-topics-05.txt Pages : 27 Date : 2018-03-18 Abstract: This document describes best current security practices for OAuth 2.0.. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and cover new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 18 12:18:24 2018 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 02C98129C6D for ; Sun, 18 Mar 2018 12:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.492 X-Spam-Level: X-Spam-Status: No, score=0.492 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_L5=3.082, SPF_PASS=-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 W_eX09E4vJMy for ; Sun, 18 Mar 2018 12:18:20 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.108]) (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 65A09126D73 for ; Sun, 18 Mar 2018 12:18:20 -0700 (PDT) Received: from [79.253.43.202] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1exdp6-0002td-S8 for oauth@ietf.org; Sun, 18 Mar 2018 20:18:28 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_1861558C-A6FC-4015-A220-6A68DAB7C58D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 20:18:16 +0100 References: <152140037038.15884.10827592494483262164@ietfa.amsl.com> To: oauth In-Reply-To: <152140037038.15884.10827592494483262164@ietfa.amsl.com> Message-Id: <53F717B8-B21C-4563-8D01-44DAA88BF1F2@lodderstedt.net> X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Sun, 18 Mar 2018 19:18:23 -0000 --Apple-Mail=_1861558C-A6FC-4015-A220-6A68DAB7C58D Content-Type: multipart/alternative; boundary="Apple-Mail=_3520FA8E-9AFA-4A9F-A238-845A1EC262AE" --Apple-Mail=_3520FA8E-9AFA-4A9F-A238-845A1EC262AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, The new revision contains the following changes:=20 Completed sections on code leakage via referrer header, attacks in = browser, mix-up, and CSRF Reworked Code Injection Section Added reference to OpenID Connect spec removed refresh token leakage as respective considerations have been = given in section 10.4 of RFC 6749 first version on open redirection incorporated Christian Mainka's review feedback We think the document now covers recommendation on all (currently) = relevant threats and is useful for all OAuth implementors and should be = moved forward.=20 kind regards, Torsten.=20 > Am 18.03.2018 um 20:12 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename : draft-ietf-oauth-security-topics-05.txt > Pages : 27 > Date : 2018-03-18 >=20 > Abstract: > This document describes best current security practices for OAuth > 2.0.. It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and cover new threats relevant due to the broader > application of OAuth 2.0. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-topics-05 >=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 --Apple-Mail=_3520FA8E-9AFA-4A9F-A238-845A1EC262AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

The new = revision contains the following changes: 

  • Completed sections on code leakage via referrer header, = attacks in browser, mix-up, and CSRF
  • Reworked Code = Injection Section
  • Added reference to OpenID Connect = spec
  • removed refresh token leakage as respective = considerations have been given in section 10.4 of RFC 6749
  • first version on open redirection
  • incorporated Christian Mainka's review feedback

We think the = document now covers recommendation on all (currently) relevant threats = and is useful for all OAuth implementors and should be moved = forward. 

kind regards,
Torsten. 

Am 18.03.2018 um 20:12 schrieb internet-drafts@ietf.org:


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

       Title =           : OAuth 2.0 = Security Best Current Practice
=        Authors =         : Torsten Lodderstedt
=             &n= bsp;           &nbs= p;John Bradley
=             &n= bsp;           &nbs= p;Andrey Labunets
Filename =        : = draft-ietf-oauth-security-topics-05.txt
Pages =           : 27
= Date =            : = 2018-03-18

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


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

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05=
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security= -topics-05

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-security-t= opics-05


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

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

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

= --Apple-Mail=_3520FA8E-9AFA-4A9F-A238-845A1EC262AE-- --Apple-Mail=_1861558C-A6FC-4015-A220-6A68DAB7C58D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzE4MTkxODE2WjAjBgkqhkiG9w0BCQQxFgQU76iWazRQHbot 1p8/DjRyeNYZVBUwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBACut0nxQZQ8pJg6sTvYA08XiCs2S71290bgkRHiVRaeOsaPUCOJv QtZIzikMyFsE9RseQ4dbl7awpQoOnsDJhhzJROaP76C2p+aD3EvbahcO5lBQCkf+2kaMLsHCh+CD 1YGfzgANErulgp+0KedM65RlFCYnUaQJDGDggaAKZ7bNxAxogSSPwaLsFInJP8+iswVluSm4QlQI E9iYzSpuBP5WPgZuljdujn5qv628TilJ4r/3bm12smeRsN884IkNsnbORSozZNiY05+euIgHSLqE Ckjr9CHqnsimcldW26cq9uDDWgr8MHhmhtKxRZD0By0XKuMgCTXFo6UHglygoWUAAAAAAAA= --Apple-Mail=_1861558C-A6FC-4015-A220-6A68DAB7C58D-- From nobody Sun Mar 18 12:33:10 2018 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 EB757129C59 for ; Sun, 18 Mar 2018 12:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2uktvsOrEEwI for ; Sun, 18 Mar 2018 12:33:07 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 B4BE01270A0 for ; Sun, 18 Mar 2018 12:33:06 -0700 (PDT) Received: from [79.253.43.202] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1exe3D-0000Pe-KH; Sun, 18 Mar 2018 20:33:03 +0100 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_AA6C73BC-DF1C-4732-8FB6-A01070ECA32E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 20:33:01 +0100 References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> To: oauth Message-Id: <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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: Sun, 18 Mar 2018 19:33:09 -0000 --Apple-Mail=_AA6C73BC-DF1C-4732-8FB6-A01070ECA32E Content-Type: multipart/alternative; boundary="Apple-Mail=_826E0392-FB79-4518-B3C9-B77C9889AE33" --Apple-Mail=_826E0392-FB79-4518-B3C9-B77C9889AE33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I just submitted a new draft that Vladimir Dzhuvinov and I have written. = It proposes a JWT-based response type for Token Introspection. The = objective is to provide resource servers with signed tokens in case they = need cryptographic evidence that the AS created the token (e.g. for = liability).=20 I will present the new draft in the session on Wednesday. kind regards, Torsten.=20 > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ > An: "Vladimir Dzhuvinov" , "Torsten = Lodderstedt" >=20 >=20 > A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-lodderstedt-oauth-jwt-introspection-response > Revision: 00 > Title: JWT Response for OAuth Token Introspection > Document date: 2018-03-15 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response >=20 >=20 > Abstract: > This draft proposes an additional JSON Web Token (JWT) based = response > for OAuth 2.0 Token Introspection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_826E0392-FB79-4518-B3C9-B77C9889AE33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

I just = submitted a new draft that Vladimir Dzhuvinov and I have written. It = proposes a JWT-based response type for Token Introspection. The = objective is to provide resource servers with signed tokens in case they = need cryptographic evidence that the AS created the token (e.g. for = liability). 

I will present the new draft in the session on = Wednesday.

kind = regards,
Torsten. 

Anfang = der weitergeleiteten Nachricht:

Von: = internet-drafts@ietf.org
Betreff: = New Version = Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: = 18. M=C3=A4rz 2018 um 20:19:37 = MEZ
An: = "Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>


A new version = of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name: = = draft-lodderstedt-oauth-jwt-introspection-response
Revision: 00
Title: JWT = Response for OAuth Token Introspection
Document date: = 2018-03-15
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat


= --Apple-Mail=_826E0392-FB79-4518-B3C9-B77C9889AE33-- --Apple-Mail=_AA6C73BC-DF1C-4732-8FB6-A01070ECA32E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzE4MTkzMzAyWjAjBgkqhkiG9w0BCQQxFgQUdLqbxxRsCGkg 7hQi6IplvviZfYYwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAIcjP15OaQsJOMYd8CFDsIUwOoiWT/W9hnmIkcU4wz7mlsFkNzPE VzTNQX0EGwt776UOaBJxs7hIgzh2YuVTTNV4DagVgOhJsnrEjLe0qZQoCYwVJKLEqpG7blR7kFEt NiQzdwa78UtpKCGIGZsj2+27/NAtrb3OBVFHEsqQ2gd9DTctLP3igqoI639ohKN/RrIcf0BAUCWx AxryldDRFXWAGMqO89YAuEt+PPKPRQdc8L285v60sEYjt1Xsft6iHrpXUVL2ougXezWBqVW/a5S9 PWxSWN50zYSfMiF3HsVYvQ7/Do5ZpRDXzJ1HQqiwHctJilQVSQ8H6DHTdkFeKagAAAAAAAA= --Apple-Mail=_AA6C73BC-DF1C-4732-8FB6-A01070ECA32E-- From nobody Sun Mar 18 12:40:16 2018 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 BCC0D129C6D for ; Sun, 18 Mar 2018 12:40:14 -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 f9VjVm9m5d7v for ; Sun, 18 Mar 2018 12:40:12 -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 72D3F129C59 for ; Sun, 18 Mar 2018 12:40:12 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id 132so16239776qkd.5 for ; Sun, 18 Mar 2018 12:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:in-reply-to:references :user-agent; bh=ZqVNvYdYVGEp0rgy84dFHVC3KWvm/z8MLPhffovEYag=; b=Oq/nwwA+F1JLwlz/tHuFc/mrTSp+oU8LlwD4fuvqj6iAUezL9yh/HEIXYZ9ed0VSqC ioGIxlIpvQBTwR+fcpd0h8kA5ct0xmXbVX+rjrValjXSNoZzKxUcs0cHw93zX1uJou1t +gqUWm4b7QEEaBliwVtZOM3Lc/zW4f0lZu850ZEQHVcMNIEvtI3ffcwrToVAJzeuBuRK GNoVYMjUrsh+pQkIu/gB4ocvtU0kGHs79MLKUSyGoQLPAr77EXABZUnNJuSZbFPWhO6z PUrXw/KHfVbm8FnjmmaCWQyWd0Fwdm00ni6Gh/dCTobtIS74hOdhyMrh8tNiFP2PmUXO EhQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :in-reply-to:references:user-agent; bh=ZqVNvYdYVGEp0rgy84dFHVC3KWvm/z8MLPhffovEYag=; b=HOrxfd/+hiMffUa/NAu8J+Jkx0jS2iXviJC4MrWB/7DZgyOdHwFfrDLfjNF3r7FPES Xl37qNn6bsUOQIFIyCOuh0tsYlquV/KYb9Q4p9sEcrrvTl893Og/tIXyiA9YzmcIIlIW 09xH8bgCIwyR/3+qBKBurYnekHT9zgCxgtvHKOtEqRBWCyY2t7KLSiUNE5bsmyfFrbvb ktVEPZE7aa7j/aviuwf9e3bHTn9uJJnM+oJ85PPRfHVwr6S6DHbPrXw7DFcsEyxLH6l8 9MxweleqE73aMYmvm78rUXO6P5C2mgBHh7yhq2uLDjjSJy//OZrR0edRVrEK2EDy86BW 5EBg== X-Gm-Message-State: AElRT7HLvP+7ln0siH6XPA3cqb+Fp4q6kPwnCKRxvU/Wo/k18c0AGJ8O JU0T/oTqo1ntbiky4VXH123BQsXk X-Google-Smtp-Source: AG47ELt8HpgzDSToEXrQW+RZ7Lqz5Qw3m4r9/89QvkciavVH9MYOWPXcj/jcCAxYJ9BF30sPNtdyNw== X-Received: by 10.55.143.199 with SMTP id r190mr14256996qkd.329.1521402011481; Sun, 18 Mar 2018 12:40:11 -0700 (PDT) Received: from [10.0.1.2] ([24.38.185.147]) by smtp.gmail.com with ESMTPSA id b55sm9375078qta.27.2018.03.18.12.40.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 12:40:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_21587636.773652091302" MIME-Version: 1.0 Date: Sun, 18 Mar 2018 15:40:07 -0400 Message-ID: <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> From: "Brock Allen" To: "Torsten Lodderstedt" , "" In-Reply-To: <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> User-Agent: Mailbird/2.5.1.0 X-Mailbird-ID: 308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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: Sun, 18 Mar 2018 19:40:15 -0000 ------=_NextPart_21587636.773652091302 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Why is TLS to the intospection endpoint not sufficient? Are you thinking th= ere needs to be some multi-tenancy support of some kind? -Brock On 3/18/2018 3:33:16 PM, Torsten Lodderstedt wrot= e: Hi all, I just submitted a new draft that Vladimir Dzhuvinov and I have written. It= proposes a JWT-based response type for Token Introspection. The objective = is to provide resource servers with signed tokens in case they need cryptog= raphic evidence that the AS created the token (e.g. for liability).=C2=A0 I will present the new draft in the session on Wednesday. kind regards, Torsten.=C2=A0 Anfang der weitergeleiteten Nachricht: Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ An: "Vladimir Dzhuvinov" , "Torsten Lodderstedt" A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00= .txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Name: draft-lodderstedt-oauth-jwt-introspection-response Revision: 00 Title: JWT Response for OAuth Token Introspection Document date: 2018-03-15 Group: Individual Submission Pages: 5 URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http= s://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-= response-00.txt [https://www.ietf.org/internet-drafts/draft-lodderstedt-oau= th-jwt-introspection-response-00.txt] Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker= .ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ [https://= datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response= /] Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/d= raft-lodderstedt-oauth-jwt-introspection-response-00 [https://tools.ietf.or= g/html/draft-lodderstedt-oauth-jwt-introspection-response-00] Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/= doc/html/draft-lodderstedt-oauth-jwt-introspection-response [https://datatr= acker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response] Abstract: =C2=A0=C2=A0This draft proposes an additional JSON Web Token (JWT) based re= sponse =C2=A0=C2=A0for OAuth 2.0 Token Introspection. 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 [http:/= /tools.ietf.org]. The IETF Secretariat ------=_NextPart_21587636.773652091302 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A Why is TL= S to the intospection endpoint not sufficient? Are you thinking there needs= to be some multi-tenancy support of some kind?

-Brock
=
=0A

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <tor= sten@lodderstedt.net> wrote:

Hi all,

I just submitted a new draft that Vladimir Dzhuvinov an= d I have written. It proposes a JWT-based response type for Token Introspec= tion. The objective is to provide resource servers with signed tokens in ca= se they need cryptographic evidence that the AS created the token (e.g. for= liability). 

I will present the new draft in the session on Wednesday.

kind regards,
Torsten. 

Anfang der weitergeleiteten Nachricht:
<= br class=3D"Apple-interchange-newline">
Von: = internet-drafts@ietf.org
Betr= eff: New Version Notifica= tion for draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com= >, "Torsten Lodderstedt" <torsten@lodderstedt.net>
<= br class=3D"">

A new version = of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and posted to = the
IETF repository.

Name: draft-lodderstedt-oauth-jw= t-introspection-response
Revision: 00
Title: JWT Response for OAuth Token Intro= spection
Document date: 2018-03-15
Group: Individual Submission
Pages: 5
URL:            <= a href=3D"https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-= introspection-response-00.txt" class=3D"">https://www.ietf.org/internet-dra= fts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oaut= h-jwt-introspection-response/
Htmlized:    = ;   https://tools.ietf.org/htm= l/draft-lodderstedt-oauth-jwt-introspection-response-00
H= tmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-in= trospection-response


Abstra= ct:
  This draft proposes an additional JSON Web T= oken (JWT) based response
  for OAuth 2.0 Token In= trospection.



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

The IETF Secretariat

=

=0A =
=0A =0A =
------=_NextPart_21587636.773652091302-- From nobody Sun Mar 18 23:03:10 2018 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 E8616126CD8 for ; Sun, 18 Mar 2018 23:03: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 4OQwdV-RSsoH for ; Sun, 18 Mar 2018 23:03:07 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 55F66124207 for ; Sun, 18 Mar 2018 23:03:07 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id m22-v6so16175797otf.10 for ; Sun, 18 Mar 2018 23:03:07 -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=HP183QNBEJiajWgCpPtzTBcYMKm21WLWeYM/4pWmrzA=; b=ZNbnqpB25yV5VbkHViAgSI3uP/6cvO9g+9z9PCgl6ijwwq3eLzZQEYqnsgwANWXPRB ZEWemYZuiQCwjPdOyUGXfSAqtNTiBv0sGEyePHTN0pyXA8KyUEx4sqDQh7+D3UNVdrJO +41CaReqr3XxQf52TlvMY2zHrjytIQQKHZqxqktu51h2uWlPWHIO0sy4Chgt0ygTv6u+ mvaRyLzxGxSfUJ5YaIkpBgWVrahKcHo5kqk4D3DZlCmlnfv+a8d3nKBrmQrVqWNXgZ/R YJLEjBxWoxlpbaIQ9+aZptcU+1R4ckhUPBNFtmGan6AtIzEvUTHMBMmr5LPzicxBcXZJ vTNw== 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=HP183QNBEJiajWgCpPtzTBcYMKm21WLWeYM/4pWmrzA=; b=d4NVQSYHMgdGXDm3xj6R044h0yAvyOPRF3mNVdHfDgM2eJTPcj3pgpASM0eviUHcaM SfWiNAVm02Jr91gVoKtoON0+5BsRVSIU/s9aPQ5pqyu6ol8n5f2gwpgdA8dMV4NUpt1L o8KemY/kUswOYKCqqwxImtvbzP0lcbtnk/wBxwTph0ovgsKK5EMKoVIznkAr5HKx3aaR +Sgyujvf8X2EHIrodt0vJc0Mjn/cQ+QmMwHNd50lYESRryEiJtPbuFim5B7h1M0wTMSJ V6yGwZVEmZnlr8augImizvWIr/+NSbX8k78XB2SdAHOQovC7G3kpbJ1uSeBMun6NcpOL CkKA== X-Gm-Message-State: AElRT7EX8KJ+I9b84yyW7rWHndey179KI1eXsZ3pvCGmbinqPNXlv8o/ dchQITJo5itsP4nDXBeszkx+1z84frfw4JwGliI3rHj6 X-Google-Smtp-Source: AG47ELvs0O+z8ksK/DWIaTdcEyPCoTXJm5CCGAKwFUrWrag1a91Anbzy+D9AEy3H5JsEVyYFvFdif+IGGzaclT7e2QY= X-Received: by 2002:a9d:4a77:: with SMTP id d52-v6mr3965815otj.136.1521439386459; Sun, 18 Mar 2018 23:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:518e:0:0:0:0:0 with HTTP; Sun, 18 Mar 2018 23:02:46 -0700 (PDT) From: Omer Levi Hevroni Date: Mon, 19 Mar 2018 08:02:46 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002d62800567bdb6bd" Archived-At: Subject: [OAUTH-WG] First version (pre-draft) of OAuth 2.0 seamless protocol 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, 19 Mar 2018 06:03:09 -0000 --0000000000002d62800567bdb6bd Content-Type: text/plain; charset="UTF-8" Hey and Good Morning I've created a first version of the draft, hope to finish it and send a draft soon. This is the protocol I'm going to present on Wednesday OAuth WG meeting. Feedback is highly appreciated - this is the first time I'm writing a draft. You can find it here: https://soluto.github.io/oauth-jwt-otp-client-assertion/draft-oauth-jwt-otp-client-assertion.html Also the name is still work in progress. Thanks Omer --0000000000002d62800567bdb6bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey and Good Morning
I've created a first version = of the draft, hope to finish it and send a draft soon. This is the protocol= I'm going to present on Wednesday OAuth WG meeting. Feedback is highly= appreciated - this is the first time I'm writing a draft.=C2=A0
<= div>You can find it here:=C2=A0
<= /div>
_______________________________________________ OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--f403045e3bd09d59290567c26eaa-- From nobody Mon Mar 19 04:55:58 2018 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 BDC09124234 for ; Mon, 19 Mar 2018 04:55:56 -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, 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 (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 aJnmA78z_-l9 for ; Mon, 19 Mar 2018 04:55:53 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 3DC3412741D for ; Mon, 19 Mar 2018 04:55:53 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id b20so3780367iof.5 for ; Mon, 19 Mar 2018 04:55:53 -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=jbkPXgwvBnPTROo5+8Es1Ctvz72ghldgEW8k3MDiBZU=; b=g386TEWBd9L3cefQQIitz95Q/b0bflRluOjYQaGVsuWuxPtJaZbyZY/l3MNPMefAOO 4BcCUnrYe8mnEsAEtf+tXVChjY+lJ8JNGe5QdXZY8mibEXufXcgD475npdJ039lvNttg KhE/8Qw4BdWx1JJ3xazzwmGxoK1UG6+xdRxyc= 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=jbkPXgwvBnPTROo5+8Es1Ctvz72ghldgEW8k3MDiBZU=; b=BCh4TTWgW9poNbqd7EkHm9V8bGnpDnsnGlku4rFJB5Git3SM0Eqn6KNxyy8TPoA0/7 u71ySTK2XU/IFDvVm+gCSmJFJqLBIzV3bbVyJT789zPCLrSrR39QpcP0/oPhJUE9Bdp2 y0sM57Nr+UdwRCeye5GJKmlX5DxiEJc8Jj34vYc2+hrQKnx+tkfdn/S5oQgGgIIJMwAF iVqwdmWJxpxBXIN+bFfu3RT5Fa/SCdkrn+Dt2NTPGY0YEnv2NUEUOTXa/+utS/qWv20N dcbaBCIuczjKQEqah4xzrskvhBovcuLJCIuNUmdYidRDlnUHctik2+a1NazcbT719ZUf ZemQ== X-Gm-Message-State: AElRT7HTo/dHu2otuLtwKs4PEwp2yYCVPszMrETe0wGeHHKLFKWGn+oW 1trCm24kS5DWtsFUDDQZgVA48N2tOXdpck+x6wHWOHtZZpi+zXkQeBxUUY/Dj09MgRso8S1iXCd pks03S4wqfZglWA== X-Google-Smtp-Source: AG47ELthzO9Cwfu2mwX60WsBvdbHt1NVwSBfgdq+f0P2kvLbsFJEsS4mMI4VrLMpkbAnmTGbLeZLsHa+l0Y4/6dlwNY= X-Received: by 10.107.18.162 with SMTP id 34mr11254504ios.168.1521460552389; Mon, 19 Mar 2018 04:55:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Mon, 19 Mar 2018 04:55:51 -0700 (PDT) Received: by 10.2.73.214 with HTTP; Mon, 19 Mar 2018 04:55:51 -0700 (PDT) In-Reply-To: References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> <84E8CEAD-98D3-48D2-AC48-0899BAC4419C@oracle.com> From: Brian Campbell Date: Mon, 19 Mar 2018 11:55:51 +0000 Message-ID: To: Samuel Erdtman Cc: phil.hunt@oracle.com, oauth Content-Type: multipart/alternative; boundary="001a113f6216c411d30567c2a346" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 11:55:57 -0000 --001a113f6216c411d30567c2a346 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And let us not forget about JWS unencoded payload https://tools.ietf.org/html/rfc7797 On Mar 19, 2018 11:41 AM, "Samuel Erdtman" wrote: > Hi, > > Adding an additional proposal to the table. Mike Jones, Anders Rundgren > and I have created a version of JWS there the signed JSON data does not > have to be Base64url encoded (the JSON is signed using ES6 serialization > rules). One of the benefits to this approach would be that the > introspection data is transferred in cleartext while still fully protecte= d. > Since it is transferred in the response body and not in a URL there is no > need for the Base64url encoding. > > The draft can be fond here > https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 > > And the example from your draft would look like this (the signature is no= t > valid, I just copied it from another place) > { > "sub": "Z5O3upPC88QrAjx00dis", > "aud": "https://protected.example.net/resource", > "extension_field": "twenty-seven", > "scope": "read write dolphin", > "iss": "https://server.example.com/", > "active": true, > "exp": 1419356238, > "iat": 1419350238, > "client_id": "l238j323ds-23ij4", > "username": "jdoe" > "__cleartext_signature": { > "alg": "ES256", > "kid": "example.com:p256", > "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI > AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHHZjsYdT96JZw" > } > } > > > > > On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt wrote: > >> +1. This is what I expected. >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> We explicitly want the token (JSON object) to be signed not the HTTP >> response. I think using JWS is the most generic way to achieve that goal= . >> >> Am 19.03..2018 um 09:57 schrieb Phil Hunt : >> >> This draft has similar issues to https://tools.ietf.org/html >> /draft-richer-oauth-signed-http-request-01 >> >> Rather than *try* sign HTTP, a signed JWT object is more reliably >> returned. >> >> Phil >> >> >> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis < >> Louis.LARMIGNAT@wavestone.com> wrote: >> >> Hi, >> >> The draft *Signing HTTP Messages** (https://tools.ietf.org/html/draft-ca= vage-http-signatures-09 >> )* could >> not meet this requirement in a more generic way ? >> >> Regards, >> Louis >> >> *De :* OAuth *De la part de* Brock Allen >> *Envoy=C3=A9 :* dimanche 18 mars 2018 20:40 >> *=C3=80 :* Torsten Lodderstedt ; oauth@ietf.org >> *Objet :* Re: [OAUTH-WG] Fwd: New Version Notification for >> draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> >> Why is TLS to the intospection endpoint not sufficient? Are you thinking >> there needs to be some multi-tenancy support of some kind? >> >> -Brock >> >> >> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt >> wrote: >> Hi all, >> >> I just submitted a new draft that Vladimir Dzhuvinov and I have written. >> It proposes a JWT-based response type for Token Introspection. The >> objective is to provide resource servers with signed tokens in case they >> need cryptographic evidence that the AS created the token (e.g. for >> liability). >> >> I will present the new draft in the session on Wednesday. >> >> kind regards, >> Torsten. >> >> >> Anfang der weitergeleiteten Nachricht: >> >> *Von: *internet-drafts@ietf.org >> *Betreff: New Version Notification for >> draft-lodderstedt-oauth-jwt-introspection-response-00.txt* >> *Datum: *18. M=C3=A4rz 2018 um 20:19:37 MEZ >> *An: *"Vladimir Dzhuvinov" , "Torsten >> Lodderstedt" >> >> >> >> A new version of I-D, draft-lodderstedt-oauth-jwt-in >> trospection-response-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-jwt-introspection-response >> Revision: 00 >> Title: JWT Response for OAuth Token Introspection >> Document date: 2018-03-15 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/internet-drafts/draft-lodder >> stedt-oauth-jwt-introspection-response-00.txt >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt- >> oauth-jwt-introspection-response/ >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-jw >> t-introspection-response-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-loddersted >> t-oauth-jwt-introspection-response >> >> >> >> Abstract: >> This draft proposes an additional JSON Web Token (JWT) based response >> for OAuth 2.0 Token Introspection. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> The information transmitted in the present email including the attachmen= t >> is intended only for the person to whom or entity to which it is address= ed >> and may contain confidential and/or privileged material. Any review, >> retransmission, dissemination or other use of, or taking of any action i= n >> reliance upon 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. >> >> Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement join= tes sont >> 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 en informer imm=C3=A9di= atement >> et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=A9ventuellem= ent jointes. >> _______________________________________________ >> 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 > > --=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.* --001a113f6216c411d30567c2a346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And let us not forget about JWS unencoded payload=C2=A0https://tools.ietf.org/html/rfc7797

On Mar 19, 2018 11:41 AM, &quo= t;Samuel Erdtman" <samuel@erdt= man.se> wrote:
Hi,

Adding an additional proposal= to the table. Mike Jones, Anders Rundgren and I have created a version of = JWS there the signed JSON data does not have to be Base64url encoded (the J= SON is signed using ES6 serialization rules). One of the benefits to this a= pproach would be that the introspection data is transferred in cleartext wh= ile still fully protected. Since it is transferred in the response body and= not in a URL there is no need for the Base64url encoding.
The draft can be fond here

And the example from your draft would look like t= his (the signature is not valid, I just copied it from another place)
{<= br>=C2=A0 "sub": "Z5O3upPC88QrAjx00dis",
=C2=A0 &quo= t;aud": "https://protected.example.net/resource",
=C2= =A0 "extension_field": "twenty-seven",
=C2=A0 "= scope": "read write dolphin",
=C2=A0 "iss": &qu= ot;https://server= .example.com/",
=C2=A0 "active": true,
=C2=A0 &quo= t;exp": 1419356238,
=C2=A0 "iat": 1419350238,
=C2=A0 &= quot;client_id": "l238j323ds-23ij4",
=C2=A0 "usernam= e": "jdoe"
=C2=A0 "__cleartext_signature": {=C2=A0=C2=A0=C2=A0 "alg": "ES256",
=C2=A0=C2=A0=C2= =A0 "kid": "example.com:p256",
=C2=A0=C2=A0= =C2=A0 "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI
=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 AckzX7wZJIJNlsBzmJ1_7LmKATiW-= YHHZjsYdT96JZw"
=C2=A0 }
}


<=
/pre>

On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt <phil= .hunt@oracle.com> wrote:
+1.=C2=A0 Th= is is what I expected.

Ph= il

Oracle Corporation, Identity Cloud Services Arc= hitect
@independentid
= phil.hunt@= oracle.com
<= /div>

On Mar 19, 2018, at 10:16 AM, Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:

We explicitly want the = token (JSON object) to be signed not the HTTP response. I think using JWS i= s the most generic way to achieve that goal.

Am 19.03..2018 um 09:57 schrieb Phil Hunt <phil.hunt@oracle.com>:
This draft has similar issues to=C2=A0https= ://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01<= /a>

Rather than *try* sign HTTP, a signed JWT object is = more reliably returned.

Phil


=

Hi,<= /u>
=C2=A0
The draft=C2=A0Signing HTTP Message= s=C2=A0(https://tools.ietf.org/html/draft-cavage-http-sig= natures-09)=C2=A0could not meet this requirement = in a more generic way ?
=C2=A0
Regar= ds,
Louis
=C2=A0
De=C2=A0:=C2=A0OAuth <oauth= -bounces@ietf.org>=C2=A0De la part de=C2= =A0Brock Allen
Envoy=C3=A9=C2=A0:=C2=A0dimanc= he 18 mars 2018 20:40
=C3=80=C2=A0:=C2=A0Torsten Lod= derstedt <torsten@lodderstedt.net= >;=C2=A0oauth@ietf.orgObjet=C2=A0:=C2=A0Re: [OAUTH-WG] Fwd: New Version Not= ification for draft-lodderstedt-oauth-jwt-introspection-response-00.tx= t
=C2=A0=
Why is TLS to the intospection endpoint not suffic= ient? Are you thinking there needs to be some multi-tenancy support of some= kind?
=C2=A0
-Brock
=C2=A0

On 3/18/2018 3:33:16 PM, Torsten Lodderst= edt <torsten@lodderstedt.net> = wrote:

Hi all,
=
=C2=A0
I just submitted a ne= w draft that Vladimir Dzhuvinov and I have written. It proposes a JWT-based= response type for Token Introspection. The objective is to provide resourc= e servers with signed tokens in case they need cryptographic evidence that = the AS created the token (e.g. for liability).=C2=A0
=C2=A0
= I wil= l present the new draft in the session on Wednesday.
=C2=A0
= kind = regards,
Torsten.=C2=A0=


Anfang der weitergeleit= eten Nachricht:
=C2=A0
Bet= reff: New Version Notification for draft-lodderstedt-oauth-jwt-introsp= ection-response-00.txt
Datum:<= span class=3D"m_5037037638032820141m_-3781873561376588703Apple-converted-sp= ace">=C2=A018. M=C3=A4rz 2018 um 20:19:37 MEZ=
An:=C2=A0"Vladimir Dzhuvinov" <= ;vladimir@connect2id.com>, "= Torsten Lodderstedt" <torsten@lo= dderstedt.net>
=C2=A0<= u>


A new version of I-D, d= raft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been s= uccessfully submitted by Torsten Lodderstedt and posted to the
IETF repo= sitory.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0draft-lodderstedt-oauth-jwt-introspect= ion-response
Revision:=C2=A000
Title:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0JWT = Response for OAuth Token Introspection
Document date:=C2=A0=C2=A02018-03-15
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Individual Submission
Pages:=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05=
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= https://www.ietf.org/internet-drafts/draft-lod= derstedt-oauth-jwt-introspection-response-00.txt
Status: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datat= racker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspe= ction-response-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-loddersted<= wbr>t-oauth-jwt-introspection-response


Abstract:
=C2= =A0=C2=A0This draft proposes an additional JSON Web Token (JWT) based respo= nse
=C2=A0=C2=A0for OAuth 2.0 Token Introspection.




Pl= ease note that it may take a couple of minutes from the time of submission<= br>until the htmlized version and diff are available at=C2=A0<= a href=3D"http://tools.ietf.org/" style=3D"color:purple;text-decoration:und= erline" target=3D"_blank">tools.ietf.org.

The IETF Secretariat

=C2=A0=
The information tra= nsmitted in the present email including the attachment is intended only for= the person to whom or entity to which it is addressed and may contain conf= idential and/or privileged material. Any review, retransmission, disseminat= ion or other use of, or taking of any action in reliance upon this informat= ion by persons or entities other than the intended recipient is prohibited.= If you received this in error, please contact the sender and delete all co= pies of the material.=C2=A0

Ce message et toutes les pi= =C3=A8ces qui y sont =C3=A9ventuellement jointes sont confidentiels et tran= smis =C3=A0 l'intention exclusive de son destinataire. Toute modificati= on, =C3=A9dition, utilisation ou diffusion par toute personne ou entit=C3= =A9 autre que le destinataire est interdite. Si vous avez re=C3=A7u ce mess= age par erreur, nous vous remercions de nous en informer imm=C3=A9diatement= et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=A9ventuellemen= t jointes.=C2=A0____________________________= ___________________
OAuth mailing= list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth

<= /div>

_________________________________= ______________
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. --001a113f6216c411d30567c2a346-- From nobody Mon Mar 19 05:03:16 2018 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 40753127867; Mon, 19 Mar 2018 05:03:11 -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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152146099110.15884.9787271966579403603@ietfa.amsl.com> Date: Mon, 19 Mar 2018 05:03:11 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-08.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, 19 Mar 2018 12:03:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-08.txt Pages : 18 Date : 2018-03-19 Abstract: This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-08 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-08 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 Mar 19 05:06:20 2018 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 35B621275F4 for ; Mon, 19 Mar 2018 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 IoR6eD6n2yWT for ; Mon, 19 Mar 2018 05:06:16 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 4E0C012785F for ; Mon, 19 Mar 2018 05:06:16 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id v9so8524874uaj.3 for ; Mon, 19 Mar 2018 05:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OupMhlGS4kZStBqAKk808yJ9U3SoekfWeLB8isbxcIA=; b=TxSFzFRigKQy2eJAscTeycXi0EUT5u6gk8Ev+GVQv0JxbyeEpWjemYlVB/26OnjSEe ga+6Obx4MUS0mRrkbInXMEdgrr+Kd3Vd+99qea8ZmifV8dgeSU3S4hBWT7cSxPUubrOK Cu04V5GhLrTFjTU78cuHe1DcbwnfD19SyIujIO9blAxguC0f+Cv9ghCESxyGWKdyw0/f LzoqtcHhIwnWF8V9GmaP3ORr9x0TSXSQgZh71aJvsXdtv8JdQHSQBxRkq/qsBbJSvgVt X6cnvHZPUdqpTu+8h0BQtrgzTKxu+ucz891RhCbIc6gpAjJiQ3JUNL2pDQml1mOdqjP9 4z7w== 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=OupMhlGS4kZStBqAKk808yJ9U3SoekfWeLB8isbxcIA=; b=tdYDYaw1yX6NiujDddoFuqQdsngh/Ojj4+hy3XpCaVGUUFitEaL71z0RlUQQ4KAAPG 4su2/JJxQn+X/PkJzcdKrnh/Y1GV50SxJawhRBdjYYOD7i2RLj31I6pJz/JFUFGP3iHE J9VRwMWWB2kqUmmswKr2xG9DaKcCPOQ9lveN89IKWx6Glw5INA50ZPBdLDT5i/+bxGeq DTwmgqIxhWd/xbUJLIri/FD2BN8KYPf3/+vnJGpwP2DMeVbmhy9PVj1kfs1xZEa0mbXr aK8Vzp6CjmleCpO9rhKNE/yC/mbEeZeoMIc+7k6CXXMMPVUqQxr5+QbQBWFk5evJWIA8 rkDA== X-Gm-Message-State: AElRT7GS58DvRPPl8nom/cvgxPBKMxPOS4R1e1JwmnGAqhDt01NDax0+ 6bR8mMDGDzmzwrU1xFbDCdVgCsCtXeLMVNw7JDcI+A== X-Google-Smtp-Source: AG47ELvYWBjamiCjpiGGHvQRPUPP0bgJpZ4DgnB7O/3xnB5qRSd9OofWeP50dHLNEq1e2ZqPaSgcsZAFuVk6p5EEHO4= X-Received: by 10.176.23.74 with SMTP id k10mr8215408uaf.161.1521461175010; Mon, 19 Mar 2018 05:06:15 -0700 (PDT) MIME-Version: 1.0 References: <151517342925.14706.13583633097065531665.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F7F91B492@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <49D385E2-0E71-4913-8012-E6F479EF318F@mit.edu> In-Reply-To: <49D385E2-0E71-4913-8012-E6F479EF318F@mit.edu> From: William Denniss Date: Mon, 19 Mar 2018 12:06:04 +0000 Message-ID: To: Justin Richer Cc: Rifaat Shekh-Yusef , iesg-secretary@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="f40304361994e0d6a40567c2c8a8" Archived-At: Subject: Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07 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, 19 Mar 2018 12:06:19 -0000 --f40304361994e0d6a40567c2c8a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The update has been posted and is now available. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-08 Thanks Scott for the feedback, and Justin for reviewing! On Thu, Mar 8, 2018 at 6:19 PM Justin Richer wrote: > +1 > > On Mar 5, 2018, at 10:23 PM, William Denniss wrote: > > Thanks again for the feedback Scott. I've staged an update here: > https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6 > > It expands on the brute force attack section to include some detail on > this attack, as it is quite unique for OAuth brute-force attacks (since t= he > victim actually ends up with the attacker's grant on the device, instead = of > the other way around =E2=80=93 not that this is totally safe of course, i= t's just > unique). It also adds some further discussion around what factors need t= o > be considered by authorization servers when creating the user code format= . > > I'll post this once my co-authors have reviewed, and the submission tool > re-opens. > > > On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef > wrote: > >> Hi Scott, >> >> Sorry, I missed that last discussion that you had with William. >> >> >> *William,* >> >> Can you please update the document based on your last discussion with >> Scott? >> I will then update the request for publication to use the new updated >> version. >> >> Regards, >> Rifaat >> >> >> >> On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott < >> shollenbeck@verisign.com> wrote: >> >>> > -----Original Message----- >>> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh= - >>> > Yusef >>> > Sent: Friday, January 05, 2018 12:30 PM >>> > To: ekr@rtfm.com >>> > Cc: oauth@ietf.org; iesg-secretary@ietf.org; oauth-chairs@ietf.org >>> > Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for >>> draft- >>> > ietf-oauth-device-flow-07 >>> > >>> > Rifaat Shekh-Yusef has requested publication of >>> draft-ietf-oauth-device- >>> > flow-07 as Proposed Standard on behalf of the OAUTH working group. >>> > >>> > Please verify the document's state at >>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ >>> >>> The document really should be updated to reflect the last call >>> discussions prior to requesting publication for the -07 version that ne= eds >>> to be updated. >>> >>> Scott >>> >> >> _______________________________________________ >> 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 > > > --f40304361994e0d6a40567c2c8a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The update has been posted and is now available.=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-device-flow-08=

Thanks Scott for the feedback, and Justin for reviewing= !


On Thu, Mar 8, 2= 018 at 6:19 PM Justin Richer <jricher@mit.edu> wrote:
+1=

On Mar 5, 2018, at 10:23 PM, Wi= lliam Denniss <= wdenniss@google.com> wrote:

Thank= s again for the feedback Scott. I've staged an update here:=C2=A0https://github.com/WilliamDenniss/draft-ietf-oauth-devic= e-flow/pull/6

It expands on the brute force attack s= ection to include some detail on this attack, as it is quite unique for OAu= th brute-force attacks (since the victim actually ends up with the attacker= 's grant on the device, instead of the other way around =E2=80=93 not t= hat this is totally safe of course, it's just unique).=C2=A0 It also ad= ds some further discussion around what factors need to be considered by aut= horization servers when creating the user code format.

=
I'll post this once my co-authors have reviewed, and the submissio= n tool re-opens.


On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> w= rote:
Hi Scott,
Sorry, I missed that last discussion that you had with Wil= liam.


William,
Can you please update the document based on your last discussio= n with Scott?
I will then update the request for publication to u= se the new updated version.

Regards,
=C2= =A0Rifaat



On Fri, Jan 5, 2018 at 12:40 PM, Hollenbe= ck, Scott <shollenbeck@verisign.com> wrote:
> -----Original Message-----<= br> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Rifaat Shekh-
> Yusef
> Sent: Friday, January 05, 2018 12:30 PM
> To: ekr@rtfm.com=
> Cc: oauth@ietf.org= ; iesg-sec= retary@ietf.org; oauth-chairs@ietf.org
> Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for draf= t-
> ietf-oauth-device-flow-07
>
> Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-devic= e-
> flow-07 as Proposed Standard on behalf of the OAUTH working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/= draft-ietf-oauth-device-flow/

The document really should be updated to reflect the last call = discussions prior to requesting publication for the -07 version that needs = to be updated.

Scott

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--f40304361994e0d6a40567c2c8a8-- From nobody Mon Mar 19 08:19:19 2018 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 D8DBD129C5D for ; Mon, 19 Mar 2018 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oncbU05f9Fr6 for ; Mon, 19 Mar 2018 08:19:14 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 0EBD3128D2E for ; Mon, 19 Mar 2018 08:19:13 -0700 (PDT) X-AuditID: 1209190d-149ff70000007c82-0a-5aafd4ef50a5 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 87.75.31874.0F4DFAA5; Mon, 19 Mar 2018 11:19:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w2JFJ8YA023994; Mon, 19 Mar 2018 11:19:09 -0400 Received: from dhcp-90dd.meeting.ietf.org (dhcp-90dd.meeting.ietf.org [31.133.144.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2JFJ5m0001363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Mar 2018 11:19:06 -0400 From: Justin Richer Message-Id: <109E791D-B34A-45C9-80C5-9A94B0540335@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_79FE328E-FD1E-49B9-A4D6-D0A71293490B" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 15:19:04 +0000 In-Reply-To: Cc: Rifaat Shekh-Yusef , "" To: William Denniss References: <151517342925.14706.13583633097065531665.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F7F91B492@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <49D385E2-0E71-4913-8012-E6F479EF318F@mit.edu> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixG6nrvvxyvoog0lTmCxOvn3FZrHzRSub xaY5zewOzB47Z91l91iwqdRjyZKfTAHMUVw2Kak5mWWpRfp2CVwZnbs/sRdsS6jYvPI+cwPj yZAuRk4OCQETialvG9i7GLk4hAQWM0ncvdcN5WxklJh/eBIThHOFSWL1k+nMIC1sAqoS09e0 MIHYvAJWEuuObGQHsZkFkiT2TnvLChE3kXj/9iFYjbBAjMTb/2vAaliAeucv7GEBsTkFAiVO z10A1RsjMfXdWrB6EQFNiZdnD7BALF7ILLHhSA87xK1KEtO/32abwMg/C8m+WUj2QcS1JZYt fM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSml mxhB4c4pybuD8d9dr0OMAhyMSjy8DkfXRQmxJpYVV+YeYpTkYFIS5c2fuD5KiC8pP6UyI7E4 I76oNCe1+BCjBAezkgjv0ytA5bwpiZVVqUX5MClpDhYlcV53E+0oIYH0xJLU7NTUgtQimKwM B4eSBO/Ny0BDBYtS01Mr0jJzShDSTBycIMN5gIZrA9ODEG9xQWJucWY6RP4UoyXHlkcv25g5 DoDJGy9etzELseTl56VKifM6gTQIgDRklObBzQSlL/nWCXdfMYoDvSjMexlkNQ8w9cFNfQW0 kAlooc/SNSALSxIRUlINjL4Pd0ZJrTMz8t6zvXZPbszKx0v4Dbz59T+e+rHfOogxLY/T28HV ak9crPvnrcEpbGHvg1NEZ13JlrzY8y32qdBJE41H5bmcaREps016S48X2TuH/mc8eOKqkIJL 7fYXD31sTNSuxi9417vXYSHPYbHlcm0CQfvzpbyYJzObiZvvinik/1hRiaU4I9FQi7moOBEA xvMfDjoDAAA= Archived-At: Subject: Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07 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, 19 Mar 2018 15:19:18 -0000 --Apple-Mail=_79FE328E-FD1E-49B9-A4D6-D0A71293490B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Something to consider in the new security text that=E2=80=99s just = occurred to me:=20 If an attacker gets their account tied to a user=E2=80=99s device, = there=E2=80=99s a risk that the attacker would potentially be able to = get that user=E2=80=99s information as input through the device. Setting = aside the obvious alexa-style panopticon boxes for a minute, just think = of a set-top box that allows you to enter your credit card information = through the device itself. You=E2=80=99d then be buying your attacker = the new season of Stargate, or whatever. =E2=80=94 Justin > On Mar 19, 2018, at 12:06 PM, William Denniss = wrote: >=20 > The update has been posted and is now available. = https://tools.ietf.org/html/draft-ietf-oauth-device-flow-08 = >=20 > Thanks Scott for the feedback, and Justin for reviewing! >=20 >=20 > On Thu, Mar 8, 2018 at 6:19 PM Justin Richer > wrote: > +1 >=20 >> On Mar 5, 2018, at 10:23 PM, William Denniss > wrote: >>=20 >> Thanks again for the feedback Scott. I've staged an update here: = https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6 = >>=20 >> It expands on the brute force attack section to include some detail = on this attack, as it is quite unique for OAuth brute-force attacks = (since the victim actually ends up with the attacker's grant on the = device, instead of the other way around =E2=80=93 not that this is = totally safe of course, it's just unique). It also adds some further = discussion around what factors need to be considered by authorization = servers when creating the user code format. >>=20 >> I'll post this once my co-authors have reviewed, and the submission = tool re-opens. >>=20 >>=20 >> On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef = > wrote: >> Hi Scott, >>=20 >> Sorry, I missed that last discussion that you had with William. >>=20 >>=20 >> William, >>=20 >> Can you please update the document based on your last discussion with = Scott? >> I will then update the request for publication to use the new updated = version. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >>=20 >> On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott = > wrote: >> > -----Original Message----- >> > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Rifaat Shekh- >> > Yusef >> > Sent: Friday, January 05, 2018 12:30 PM >> > To: ekr@rtfm.com >> > Cc: oauth@ietf.org ; iesg-secretary@ietf.org = ; oauth-chairs@ietf.org = >> > Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for = draft- >> > ietf-oauth-device-flow-07 >> > >> > Rifaat Shekh-Yusef has requested publication of = draft-ietf-oauth-device- >> > flow-07 as Proposed Standard on behalf of the OAUTH working group. >> > >> > Please verify the document's state at >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ = >>=20 >> The document really should be updated to reflect the last call = discussions prior to requesting publication for the -07 version that = needs to be updated. >>=20 >> Scott >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_79FE328E-FD1E-49B9-A4D6-D0A71293490B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Something to consider in the new security text that=E2=80=99s = just occurred to me: 

If an attacker gets their account tied to a user=E2=80=99s = device, there=E2=80=99s a risk that the attacker would potentially be = able to get that user=E2=80=99s information as input through the device. = Setting aside the obvious alexa-style panopticon boxes for a minute, = just think of a set-top box that allows you to enter your credit card = information through the device itself. You=E2=80=99d then be buying your = attacker the new season of Stargate, or whatever.
 =E2=80=94 Justin

On Mar 19, 2018, at 12:06 PM, William Denniss <wdenniss@google.com>= wrote:

The update has been posted and is = now available. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-08=

Thanks Scott for = the feedback, and Justin for reviewing!


On = Thu, Mar 8, 2018 at 6:19 PM Justin Richer <jricher@mit.edu> wrote:
+1

On Mar 5, 2018, at 10:23 PM, = William Denniss <wdenniss@google.com> wrote:

Thanks again for the = feedback Scott. I've staged an update here: https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/= pull/6

It = expands on the brute force attack section to include some detail on this = attack, as it is quite unique for OAuth brute-force attacks (since the = victim actually ends up with the attacker's grant on the device, instead = of the other way around =E2=80=93 not that this is totally safe of = course, it's just unique).  It also adds some further discussion = around what factors need to be considered by authorization servers when = creating the user code format.

I'll post this once my co-authors have = reviewed, and the submission tool re-opens.


On = Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi Scott,

Sorry, I missed that last discussion that you had with = William.


William,

Can you please update = the document based on your last discussion with Scott?
I will then update the request for publication to use the new = updated version.

Regards,
 Rifaat



On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott = <shollenbeck@verisign.com> wrote:
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = Rifaat Shekh-
> Yusef
> Sent: Friday, January 05, 2018 12:30 PM
> To: ekr@rtfm.com
> Cc: oauth@ietf.org; iesg-secretary@ietf.org; oauth-chairs@ietf.org
> Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for = draft-
> ietf-oauth-device-flow-07
>
> Rifaat Shekh-Yusef has requested publication of = draft-ietf-oauth-device-
> flow-07 as Proposed Standard on behalf of the OAUTH working = group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/<= /a>

The document really should be updated to reflect the last = call discussions prior to requesting publication for the -07 version = that needs to be updated.

Scott

_______________________________________________
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=_79FE328E-FD1E-49B9-A4D6-D0A71293490B-- From joseph@authlete.com Mon Mar 19 15:16:27 2018 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 5F609124D37 for ; Mon, 19 Mar 2018 15:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnXjVjKfbxh4 for ; Mon, 19 Mar 2018 15:16:25 -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 70C3A120727 for ; Mon, 19 Mar 2018 15:16:25 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id h2so20162972wre.12 for ; Mon, 19 Mar 2018 15:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=uZF3iblpKhetzptlkUkWynXiaidceqL9wGsbbWOAFpk=; b=1DNHxuuCAHeyVXuHqh3UfDYC3sPl//CmI02C8kuLheI0E2BnzFz44+ZE7I1IsWn+Y2 ZUtcJnvgRFiSvTAbDBTS6N/A3Lv3TdqeRmvS6O4k1Qji8AihDIAB7ZSlr4vfbYz8dQ+p T1hIpxXmgz4NrwBkQuDU3jO2nwuFZy7J/HQCbiY/oO/FGCSg1S5c3pXy7erxkbC9fKJa EYHTOYLjLhWu/iS+wBeK3M33TNDFpbOVwD/hgTQSCYyK7BeTi/BctB0rZNYdmmpiFtiH 4id8sumuBC9laohXIYsf21YPJuVphVtDlPhlFm+wNRI6crkEWDimT6OEqFNRP43cMk7U IF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=uZF3iblpKhetzptlkUkWynXiaidceqL9wGsbbWOAFpk=; b=gthAzBJFzYPKWnLxRxnKWO9x+tnZpQpVXty31Lj2CCoDAYc6cNrQCu0tvZ+KdvlsqP GWJnjV0jzidzrnJUHrRwzJR9t3fPE6oCfbjDL1nTdv6xMw0NH3f5z7M8qtEp0/p2xTrG J+Nnm7E7Vdj0QIzoj9z+IAsZqlDo7i8UbSKZi9yjoyz45MoxPki+b8b3rzdynnkWZ5pB XuPuLYEwCwhebl5rhg+lgOhfp89JfBQDDeScKL2nsDLg0J+r5Md10Tg61iOKT+GY8Bhu lRLmWBV7BjOd/m0jQ1FL1mzk8b3/5TywllxPzleyiRR5wX3Yoqhw7sdneFFMlgy03BYK DAMg== X-Gm-Message-State: AElRT7HSC8bxoSf+n8QMIilDNoinlwOuE2QWaOECYquh0ETDxDn9YTTw P29/rvwmZoanvcFpV1DpNJXWK5MCiyw= X-Google-Smtp-Source: AG47ELu3NkUs2QGnjXg4moyh2fbU6EL8ezLagesoELIjUhDl73Gyys2NxhuTiPEr9Uxfijh8hK6jZQ== X-Received: by 10.223.133.133 with SMTP id 5mr11588678wrt.195.1521497783902; Mon, 19 Mar 2018 15:16:23 -0700 (PDT) Received: from [10.0.29.11] ([89.206.247.118]) by smtp.gmail.com with ESMTPSA id q21sm248753wra.24.2018.03.19.15.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 15:16:23 -0700 (PDT) From: Joseph Heenan Content-Type: multipart/alternative; boundary="Apple-Mail=_58A6A1EA-5F29-42A1-9166-28BEEB0FA719" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Mon, 19 Mar 2018 22:16:21 +0000 Cc: oauth@ietf.org To: torsten@lodderstedt.net X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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, 19 Mar 2018 22:24:00 -0000 --Apple-Mail=_58A6A1EA-5F29-42A1-9166-28BEEB0FA719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Torsten, As we briefly spoke about earlier, "3.8.1. Authorization Server as Open = Redirector" could I think be made more explicit. Currently it explicitly mentions the invalid_request and invalid_scope = errors must not redirect back to the client's registered redirect uri. https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more = potential errors that appear to fall into the same category. I = understand to block the attack fully we need 'must not redirect's for = all the kinds of error that could cause an automatic redirect back to = the client's registered redirect uri without any user interaction - = 'unauthorized_client' and 'unsupported_response_type' seem to fall into = that category. 'server_error' also seems dodgy (I would wager that on = some servers that are known ways to provoke server errors), and I would = have doubts about 'temporarily_unavailable' too. Thanks Joseph --Apple-Mail=_58A6A1EA-5F29-42A1-9166-28BEEB0FA719 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Torsten,

As we briefly spoke about earlier, "3.8.1. Authorization = Server as Open Redirector" could I think be made more explicit.

Currently it explicitly mentions the = invalid_request and invalid_scope errors must not redirect back to the = client's registered redirect uri.

https://tools.ietf.org/html/rfc6749#section-4.1.2.1 = defines several more potential errors that appear to fall into the same = category. I understand to block the attack fully we need 'must not = redirect's for all the kinds of error that could cause an automatic = redirect back to the client's registered redirect uri without any user = interaction - 'unauthorized_client' and 'unsupported_response_type' = seem to fall into that category. 'server_error' also seems dodgy (I = would wager that on some servers that are known ways to provoke server = errors), and I would have doubts about 'temporarily_unavailable' too.

Thanks

Joseph

= --Apple-Mail=_58A6A1EA-5F29-42A1-9166-28BEEB0FA719-- From nobody Mon Mar 19 15:34:50 2018 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 DD13712D94D for ; Mon, 19 Mar 2018 15:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, HTML_OBFUSCATE_05_10=0.26, 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 XTywWFvBYuWf for ; Mon, 19 Mar 2018 15:34:47 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 DA3B7124BAC for ; Mon, 19 Mar 2018 15:34:46 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id u200so11299059vke.4 for ; Mon, 19 Mar 2018 15:34:46 -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=pfNPy2fyH/Zt7RCWxOryZGOgKpQhl0+mWregSx7rvPI=; b=mNRefX+WDuJxxuvyu786iGbz+s/rjxZMFkn04idTbHJJLxJMZuj4VJjm0trVbA0KXV 7wNxjg0OF/DgjCv5ipApkhGlj8mflKeCGSe05oGeEUVf0G5I2jBlsXaoHZc4cr48RezS c7juxlsXM8iDQIrEOdA5jLmaG+/73RFcTIz5Ku8QUBWMd9N0EiYyFhKjhlT0wmY9c1El 6TrzDrmQnUDhgO4jFg6IzK12CVkzU7cRngHMFcaaHZf4ZvZtDDARuik5+ZfU2fq7nZvy kwm2W955NL1bqDyp6hRzAfak5uZUU5bfCdr+lv+3jmFCfZ+2hz4VvEG04ss9Ny9GTUbo bMuw== 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=pfNPy2fyH/Zt7RCWxOryZGOgKpQhl0+mWregSx7rvPI=; b=diuKSweWvAQggsJc9pkjNZ8hviFiSKC1m5aXjYPxlxrza9fxcd+q7H8xXAvL9eHOhN V0lvok2HhAzCxMSnvbxmt950fXXxLPO+5wrnZOPi1Np5pG23Wm/1Jm8k2R6oXWccHgoI v1eUJVRYBg9dJQkOvaRtsRcsC7NoNp1ACwuFni9yGTqZFk7MkkncpvSxhlNi2WwUVUKG sybI9jf86TtYKrozvmm/i91CnhM/t1sGID1FSpSxOCH/bnVi6hsIfP4lHLfrsoXI4q9u oI02gITCVyNIfv+ivEvXWiWiOXJ3+lWW7kyEPxipU5Yhi+WaPeJHKsRREPWQe6Apf2cN F6fA== X-Gm-Message-State: AElRT7E8DhX4hJnNIcc3Lu+6/NXIvDd/yJbzzI7gS3yb2yjHbIM1VtVH Q+By7DvU7TCW2+HNRY3ueaRTwP+WIDiT5s573yO4QQ== X-Google-Smtp-Source: AG47ELvw7JfpswyEoD8SQglFQcnoBdnzCdJG/niqnz81Yy26DzPMvZU+asMYSV+rqaV7gcGMaIjxXuKVXrW+BWUpFgQ= X-Received: by 10.31.238.72 with SMTP id m69mr5861150vkh.92.1521498885699; Mon, 19 Mar 2018 15:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.45.148 with HTTP; Mon, 19 Mar 2018 15:34:45 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Mon, 19 Mar 2018 22:34:45 +0000 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="94eb2c14a9989bbb500567cb90c8" Archived-At: Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 19 Mar 2018 22:34:49 -0000 --94eb2c14a9989bbb500567cb90c8 Content-Type: text/plain; charset="UTF-8" All, As discussed during the meeting today, we are starting a WGLC on the MTLS document: *https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 * Please, review the document and provide feedback on any issues you see with the document. The WGLC will end in two weeks, on April 2, 2018. Regards, Rifaat and Hannes --94eb2c14a9989bbb500567cb90c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As discussed during the mee= ting today, we are starting a=C2=A0WGLC=C2=A0on t= he MTLS document:

Please, review the document and provide fee= dback on any issues you see with the document.

The WGLC will= end in two weeks, on April 2, 2018.

Regards,
=C2= =A0Rifaat and Hannes

--94eb2c14a9989bbb500567cb90c8-- From nobody Tue Mar 20 01:40:35 2018 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 228871205D3 for ; Tue, 20 Mar 2018 01:40:34 -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, 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 Xb4USfunow62 for ; Tue, 20 Mar 2018 01:40:32 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47941200C5 for ; Tue, 20 Mar 2018 01:40:31 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id e7so1329929iof.2 for ; Tue, 20 Mar 2018 01:40:31 -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=++wNyBt2WSh9OcpQCY0MsYBvkzYElVEitdS33iBEc3M=; b=dbXLEPha4piIXIpiMMt3rDRxIrAwYGuBSP7hJwag9eHkeG7JtRxZKMBpGEXmsLmBuy /4YCMQAjAcCSnmwWpWCl/vyvQmjaB7Aqj1NCKJ5csXZVA1bJhL6dtSYYn8GHFmbzFV5h UTPmhk4o10fXf/0+uqoW7nOJFVks7u5cgGN3g= 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=++wNyBt2WSh9OcpQCY0MsYBvkzYElVEitdS33iBEc3M=; b=itnhLcYVa3YZUfQv4vcJ4+VpgimwfbZZ6yNpDlblnCnQJul0XfQPobjubORq3Pa17z sVjzkbI6XNB3pGvraX44c6/c1FnJr5yeSR3Vf50iVaByEzRgn0cSvpjcywB+d5X4o3+Q RvtvdEpY5zaD5lvespemU/6lFb492is5uKVYWH8Wn27geuspWop5U7+LpQyY9SLS30w5 OaB/fTZoL37V47e6qJ9hEaM2VDAc+D1/0KGceWm2SyqLNhTvuJSao5t1/FCBE/B00Ikl mKv9yvWEhYKxISfu/3/tKPM+J7jhyuJssKybNdB4lyRbKiE/lG70ItPHYccaTrvxSq9D md5g== X-Gm-Message-State: AElRT7GsFL7bV16jpikIxUoeFSnIEBPRw1um3f1loIFb3XbqFJxXFO8H c4QMV2LjJNRNt4NVq6pa4kIcU8RfMlFScZjJJ+ql5qbWDlmlpkPQEXkZkYuI+P8LyhvAVvYS9v+ ksA5DbkIJj2EDpA== X-Google-Smtp-Source: AG47ELuT1ORjEjagIGPQhlLlrBVRqfd9tiSdZZ4PFMd1lWBo/zHZ9GMB1VBTQEh5EI448SVa+kNnbO9IlCcAy3dXdAU= X-Received: by 10.107.147.198 with SMTP id v189mr13851573iod.282.1521535230978; Tue, 20 Mar 2018 01:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Tue, 20 Mar 2018 01:40:00 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 20 Mar 2018 08:40:00 +0000 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="94eb2c0560a8f4c8230567d40652" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 20 Mar 2018 08:40:34 -0000 --94eb2c0560a8f4c8230567d40652 Content-Type: text/plain; charset="UTF-8" I talked with Justin briefly yesterday after the meeting and he pointed out that the document is currently rather ambiguous about whether or not the base64 pad "=" character is to be used on the encoding of "x5t#S256" member. The intent was that padding be omitted and I'll take it as a WGLC comment to be explicit about that in the next draft revision. On Mon, Mar 19, 2018 at 10:34 PM, Rifaat Shekh-Yusef wrote: > All, > > As discussed during the meeting today, we are starting a WGLC on the MTLS > document: > *https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > * > > Please, review the document and provide feedback on any issues you see > with the document. > > The WGLC will end in two weeks, on April 2, 2018. > > Regards, > Rifaat and Hannes > > > _______________________________________________ > 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.* --94eb2c0560a8f4c8230567d40652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I talked with Justin briefly yesterday after the meeting a= nd he pointed out that the document is currently rather ambiguous about whe= ther or not the base64 pad "=3D" character is to be used on the e= ncoding of "x5t#S256" member. The intent was that padding be omit= ted and I'll take it as a WGLC comment to be explicit about that in the= next draft revision.

On Mon, Mar 19, 2018 at 10:34 PM, Rifaat Shekh-Yusef <rifaat.= ietf@gmail.com> wrote:
All,

As discussed during the mee= ting today, we are starting a=C2=A0WGLC=C2=A0on the MTLS document:

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

The WGLC will end in two weeks, on April 2, 2= 018.

Regards,
=C2=A0Rifaat and Hannes


_______________________________________________
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. --94eb2c0560a8f4c8230567d40652-- From nobody Tue Mar 20 04:48:53 2018 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 38A7012702E for ; Tue, 20 Mar 2018 04:48:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=curity-io.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 81clkxj49gBU for ; Tue, 20 Mar 2018 04:48:50 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 5FC47126DED for ; Tue, 20 Mar 2018 04:48:45 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id v23-v6so1341120oth.9 for ; Tue, 20 Mar 2018 04:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DQxB1yNeHcrdL3RdpCaEydYQlWNaqElO8o9vPJ3KBHo=; b=1sMtvARuyuIXN++rIBkdzjb/04mi4SuBH7xK1ChdlSZ4vAXoeFxxvILrWWR/WuAd5Q pzeiVQtUFAyfh6m//xivOkjHNG10NMK2pDNDA+oeASg0k9b0floXh+YC5TI61+6TpCSB Fta7Zm3AoIFU0A87kH13iw0slhvNI8wIECFAv8GyutuO/f8cmijw049pWvT8xOXBlmJC KcbIQ6Z5xmlrQxI/oZrX2xSgR7QF6VHL6NIHeOb2d8J/Bd+Ie+hi9wPMd9zbvf+1OhVU BKxWehvyyWjE3ES3d0z/o+gtC3A5CXN7VPdkJMi0UaOks6Ib7TvW76W7zDdOKY3V+Nzz GRHQ== 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=DQxB1yNeHcrdL3RdpCaEydYQlWNaqElO8o9vPJ3KBHo=; b=SIPvKe2Iyu2cSe9sxX0C7VX6tad0zTQaeIDedM8MHatyvuhtXKkSRSz3HvZx4MdXpj tcz058ANQriRbapQpwkNHqoaUt2MX69cRZk0byVX3DfTGn27HcGmas+F0odPV78E4h2j yyV5qk4CdimRugNQ9lpzAQK1hdrnBpL2N0GYarPv4fejVohgqF3k6YqS4WpFGIVE4yc/ o2y+egpG4gxF0z7CRCWFeD1WOA2Yc7JpNL4n6V7frtqKSV6luWqLD1g7LpWf7vL+egKz nT4bDKs4mJPAXJ2YKJBGQT0M6dSYSs8BQCiqf4srkynkcleeNVruFdR0k2VbGoQgdA6G 2p8w== X-Gm-Message-State: AElRT7EEmUgsxXAqSm1DuUarjLqS4MepVlPywi25FYrNpKPmy0pGzHty //mgK1olHSIYG1LZwG2+w55wc5oEqLn3y3QBaZ/bvlOl X-Google-Smtp-Source: AG47ELtjNyCUO+URAwMH2jFkiz0S3jEBM3AO7RHEhGVvnKxEM7GjQnJEI8GasqYVQx8D16DLM6VaET14oNlOn7CY3z8= X-Received: by 2002:a9d:4992:: with SMTP id g18-v6mr9695405otf.238.1521546524589; Tue, 20 Mar 2018 04:48:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.70.193 with HTTP; Tue, 20 Mar 2018 04:48:24 -0700 (PDT) In-Reply-To: References: From: Travis Spencer Date: Tue, 20 Mar 2018 12:48:24 +0100 Message-ID: To: Joseph Heenan Cc: torsten@lodderstedt.net, oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Tue, 20 Mar 2018 11:48:52 -0000 I read through this doc and would like to share a bit of feedback in hopes that it helps: * There is no mention of Content Security Policy (CSP). This is a very helpful security mechanism that all OAuth servers and web-based clients should implement. I think this needs to be addressed in this doc. - No mention of frame breaking scripts for non-CSP aware user agents - No mention of X-Frame-Options * There's no mention of HSTS which all OAuth servers and web-based client should implement (or the reverse proxies in front of them should) * The examples only use 302 and don't mention that 303 is safer[1] - Despite what it says in section 1.7 of RFC 6749, many people think that a 302 is mandated by OAuth. It would be good to recommend a 303 and use examples with other status codes. * 3.3.1 refers to client.com in the example. This is a real domain. Suggest client.example.com instead. Same issue in 3.1.2 where client.evil.com is used * 3.1.3 (proposed countermeasures) - native clients that use a web server with a dynamic port should use dynamic client registration and dynamic client management rather than allowing wildcards on the port matching of the OAuth server. * 3.8.1 says "Therefore this draft recommends that every invalid authorization request MUST NOT automatically redirect the user agent to the client's redirect URI" -- This is gonna break a lot of stuff including other specs! I don't think that's warranted, and I am not looking forward to the fallout this could cause. Anyway, my $0.02. Hope it helps. [1] https://arxiv.org/pdf/1601.01229v2.pdf On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan wrote: > Hi Torsten, > > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open > Redirector" could I think be made more explicit. > > Currently it explicitly mentions the invalid_request and invalid_scope > errors must not redirect back to the client's registered redirect uri. > > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more > potential errors that appear to fall into the same category. I understand to > block the attack fully we need 'must not redirect's for all the kinds of > error that could cause an automatic redirect back to the client's registered > redirect uri without any user interaction - 'unauthorized_client' and > 'unsupported_response_type' seem to fall into that category. 'server_error' > also seems dodgy (I would wager that on some servers that are known ways to > provoke server errors), and I would have doubts about > 'temporarily_unavailable' too. > > Thanks > > Joseph > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Mar 20 08:38:10 2018 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 36DD1126D74 for ; Tue, 20 Mar 2018 08:38:09 -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, 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 6_lYkqBuAu85 for ; Tue, 20 Mar 2018 08:38:01 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 52332126579 for ; Tue, 20 Mar 2018 08:38:01 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g14so2864314iob.13 for ; Tue, 20 Mar 2018 08:38:01 -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=aNsZ7Q6EeBoeE4qicwEB2BFPMGhbcd+Zqyftm340Bhw=; b=T7JyzY0YsVhcq3EzbCk7D5ORd6Qw8qsMJ/ZbYB+fcJKwHo/MYI/pzxBpOXmk+G6+YA U8we65fmDb6W56Oy5O9a+y/c4u+q/RBqLSBg14RFtb80WIYC23/dSAMxsscrIGSRjbbU lSt83sYbMOcef/y6uRF5y2XI1eM9Y6pTniXj8= 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=aNsZ7Q6EeBoeE4qicwEB2BFPMGhbcd+Zqyftm340Bhw=; b=TycAR3huhRN2pf0BAovre/S+jviQhBiqm+jr9hPml5hW/chFzphjb4Ie4qinrdA72R h1dKjScKPQf7QT73I7i28dWI6VStJMmZ1aRvi9nrhK3uLaaVJ7KkPflFz4vD3LY5aWsJ cxD0g+GXdOSazpRyt/wA97rsm0iBdyzgFgJlobf19sYWwSwXLE4NEU4y0Ovmu+QVS/Uq i+5t5lGDrvI1mlfL+gIHAFSGuaailkAWW/p1tHkc4skoi8FcSzW2bVTchqt/13tFx4jd 8jr0UxfPJPrJN4uya35U6m6T/5V/qbtY3VeAawwaKxC5RbK3ue26cycMoUOpkjK5lXPX 6a4A== X-Gm-Message-State: AElRT7GUN9yef75mlJls0IWgSMKKMt4kXcsFoNqqEux4N3dlvAHs7wnG rlDMThAdALPSXJTA4nQCi8rCmL15QcMiljlW8Rqi753QqSUsXXfQ5mKxri0vYLaTHmEn2Eo5S2I NXfejlaUo11RZIA== X-Google-Smtp-Source: AG47ELuU0PLynaotk0k5n+iTMdH7KVKiCS9cRHop8eJzREFttFrUgOox/9UdiC88jLMT+hFCIDOPQOnYqEx3LKs3N84= X-Received: by 10.107.147.198 with SMTP id v189mr15208928iod.282.1521560280472; Tue, 20 Mar 2018 08:38:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Tue, 20 Mar 2018 08:37:29 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 20 Mar 2018 15:37:29 +0000 Message-ID: To: Travis Spencer Cc: Joseph Heenan , oauth Content-Type: multipart/alternative; boundary="94eb2c0560a805bf4b0567d9dc66" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Tue, 20 Mar 2018 15:38:09 -0000 --94eb2c0560a805bf4b0567d9dc66 Content-Type: text/plain; charset="UTF-8" +1 to what Travis said about 3.8.1 The text in 3.8 about Open Redirection is new in this most recent -05 version of the draft so this is really the first time it's been reviewed. I believe 3.8.1 goes too far in saying "this draft recommends that every invalid authorization request MUST NOT automatically redirect the user agent to the client's redirect URI." I understand that text was informed by https://tools.ietf.org/html/ draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential mitigation discussed there in section 3 (the one which happens to contradict RFC 6749) and elevates it to a "MUST". I don't think something that drastic is warranted. I think there are other mitigations - like strict redirect_uri matching, referrer-policy headers, and appending a dummy fragment on error redirects - that can protect against the more serious redirection issues without -security-topics trying to introduce normative breaking changes to the behavior from the original OAuth 2.0 Authorization Framework. Perhaps there are some error cases not mentioned in RFC 6749 where returning an HTTP error code to the browser would be better or more appropriate than redirecting back to the OAuth client (my opinion on this has gone in circles and I'm honestly not sure anymore). But saying that authorization requests never automatically redirect back to the client's redirect URI is excessive. On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer wrote: > I read through this doc and would like to share a bit of feedback in > hopes that it helps: > > * There is no mention of Content Security Policy (CSP). This is a very > helpful security mechanism that all OAuth servers and web-based > clients should implement. I think this needs to be addressed in this > doc. > - No mention of frame breaking scripts for non-CSP aware user agents > - No mention of X-Frame-Options > * There's no mention of HSTS which all OAuth servers and web-based > client should implement (or the reverse proxies in front of them > should) > * The examples only use 302 and don't mention that 303 is safer[1] > - Despite what it says in section 1.7 of RFC 6749, many people > think that a 302 is mandated by OAuth. It would be good to recommend a > 303 and use examples with other status codes. > * 3.3.1 refers to client.com in the example. This is a real domain. > Suggest client.example.com instead. Same issue in 3.1.2 where > client.evil.com is used > * 3.1.3 (proposed countermeasures) - native clients that use a web > server with a dynamic port should use dynamic client registration and > dynamic client management rather than allowing wildcards on the port > matching of the OAuth server. > * 3.8.1 says "Therefore this draft recommends that every invalid > authorization request MUST NOT automatically redirect the user agent > to the client's redirect URI" -- This is gonna break a lot of stuff > including other specs! I don't think that's warranted, and I am not > looking forward to the fallout this could cause. > > Anyway, my $0.02. Hope it helps. > > [1] https://arxiv.org/pdf/1601.01229v2.pdf > > On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan > wrote: > > Hi Torsten, > > > > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open > > Redirector" could I think be made more explicit. > > > > Currently it explicitly mentions the invalid_request and invalid_scope > > errors must not redirect back to the client's registered redirect uri. > > > > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more > > potential errors that appear to fall into the same category. I > understand to > > block the attack fully we need 'must not redirect's for all the kinds of > > error that could cause an automatic redirect back to the client's > registered > > redirect uri without any user interaction - 'unauthorized_client' and > > 'unsupported_response_type' seem to fall into that category. > 'server_error' > > also seems dodgy (I would wager that on some servers that are known ways > to > > provoke server errors), and I would have doubts about > > 'temporarily_unavailable' too. > > > > Thanks > > > > Joseph > > > > > > _______________________________________________ > > 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.* --94eb2c0560a805bf4b0567d9dc66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to what Travis said about 3.8.1

The text in= 3.8 about Open Redirection is new in this most recent -05 version of the d= raft so this is really the first time it's been reviewed. I believe 3.8= .1 goes too far in saying "this draft recommends that every invalid au= thorization request MUST NOT automatically redirect the user agent to the c= lient's redirect URI."

I understand that text w= as informed by https://tools.ietf.org/html/draf= t-ietf-oauth-closing-redirectors-00 but it takes one of the potent= ial mitigation discussed there in section 3 (the one w= hich happens to contradict RFC 6749) and elevates it to a "MUST".= I don't think something that drastic is warranted. I think there are o= ther mitigations - like strict redirect_uri matching, referrer-policy heade= rs, and appending a dummy fragment on error redirects - that can protect ag= ainst the more serious redirection issues without -security-topics trying t= o introduce normative breaking changes to the behavior from the original OA= uth 2.0 Authorization Framework.

Perhaps there are some = error cases not mentioned in RFC 6749 where returning an HTTP error code to= the browser would be better or more appropriate than redirecting back to t= he OAuth client (my opinion on this has gone in circles and I'm honestl= y not sure anymore). But saying that authorization requests never automatic= ally redirect back to the client's redirect URI is excessive.
=


On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <= travis.spence= r@curity.io> wrote:
I read = through this doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
=C2=A0 =C2=A0 - No mention of frame breaking scripts for non-CSP aware user= agents
=C2=A0 =C2=A0 -=C2=A0 No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
=C2=A0 =C2=A0- Despite what it says in section 1.7 of RFC 6749, many people=
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
cli= ent.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuf= f
including other specs! I don't think that's warranted, and I am not=
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <joseph@authlete.com> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server a= s Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope=
> errors must not redirect back to the client's registered redirect = uri.
>
> https://tools.ietf.org/html/rfc6749#sec= tion-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I underst= and to
> block the attack fully we need 'must not redirect's for all th= e kinds of
> error that could cause an automatic redirect back to the client's = registered
> redirect uri without any user interaction - 'unauthorized_client&#= 39; and
> 'unsupported_response_type' seem to fall into that category. &= #39;server_error'
> also seems dodgy (I would wager that on some servers that are known wa= ys to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> __________________= _____________________________
> 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. --94eb2c0560a805bf4b0567d9dc66-- From nobody Tue Mar 20 09:44:19 2018 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 218D712778D for ; Tue, 20 Mar 2018 09:44:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 pFWVlTMBzfVg for ; Tue, 20 Mar 2018 09:44:13 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.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 79E7012762F for ; Tue, 20 Mar 2018 09:44:13 -0700 (PDT) Received: from [86.187.94.109] (helo=[10.207.197.143]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1eyKMt-0003eD-8Z; Tue, 20 Mar 2018 17:44:11 +0100 From: Torsten Lodderstedt Message-Id: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_19C9B2F3-422E-448F-AAA5-115DDA85425D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 16:44:08 +0000 In-Reply-To: Cc: Travis Spencer , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Tue, 20 Mar 2018 16:44:18 -0000 --Apple-Mail=_19C9B2F3-422E-448F-AAA5-115DDA85425D Content-Type: multipart/alternative; boundary="Apple-Mail=_03E2C428-A750-4244-9FA0-411467A12A84" --Apple-Mail=_03E2C428-A750-4244-9FA0-411467A12A84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, > Am 20.03.2018 um 15:37 schrieb Brian Campbell = : >=20 > +1 to what Travis said about 3.8.1 >=20 > The text in 3.8 about Open Redirection is new in this most recent -05 = version of the draft so this is really the first time it's been = reviewed. I believe 3.8..1 goes too far in saying "this draft recommends = that every invalid authorization request MUST NOT automatically redirect = the user agent to the client's redirect URI."=20 >=20 > I understand that text was informed by = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 = = but it takes one of the potential mitigation discussed there in section = 3 = (the one which happens to contradict RFC 6749) and elevates it = to a "MUST". I don't think something that drastic is warranted. I think = there are other mitigations - like strict redirect_uri matching, In the attack described in = https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 = = section 2.1. the attacker dynamically registers a client with the AS. So = exact redirect URI matching won=E2=80=99t stop the open redirection = attack since the attacker uses the correct URI. The problem is with the = change in the underlying trust model. RFC 6749 assumes every configured = client to be legit. This might have been ok at the time RFC 6749 was = published. Open dynamic client registration collides with this = assumption. =20 We could distinguish between cases where the AS is confident the client = is legit and other cases. But how does the AS determine it? > referrer-policy headers, and appending a dummy fragment on error = redirects - Can you please explain how this protects from open redirection?=20 > that can protect against the more serious redirection issues without = -security-topics trying to introduce normative breaking changes to the = behavior from the original OAuth 2.0 Authorization Framework.=20 >=20 > Perhaps there are some error cases not mentioned in RFC 6749 where = returning an HTTP error code to the browser would be better or more = appropriate than redirecting back to the OAuth client (my opinion on = this has gone in circles and I'm honestly not sure anymore). But saying = that authorization requests never automatically redirect back to the = client's redirect URI is excessive. Probably. Let=E2=80=99s discuss in detail.=20 I think the AS should not automatically redirect the user in case of the = following error conditions because an attacker could cause this errors = via request parameters or its configuration: - unsupported_response_type - invalid_scope - unauthorized_client - invalid_request kind regards, Torsten.=20 >=20 >=20 > On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer = > wrote: > I read through this doc and would like to share a bit of feedback in > hopes that it helps: >=20 > * There is no mention of Content Security Policy (CSP). This is a very > helpful security mechanism that all OAuth servers and web-based > clients should implement. I think this needs to be addressed in this > doc. > - No mention of frame breaking scripts for non-CSP aware user = agents > - No mention of X-Frame-Options > * There's no mention of HSTS which all OAuth servers and web-based > client should implement (or the reverse proxies in front of them > should) > * The examples only use 302 and don't mention that 303 is safer[1] > - Despite what it says in section 1.7 of RFC 6749, many people > think that a 302 is mandated by OAuth. It would be good to recommend a > 303 and use examples with other status codes. > * 3.3.1 refers to client.com in the example. This = is a real domain. > Suggest client.example.com instead. Same = issue in 3.1.2 where > client.evil.com is used > * 3.1.3 (proposed countermeasures) - native clients that use a web > server with a dynamic port should use dynamic client registration and > dynamic client management rather than allowing wildcards on the port > matching of the OAuth server. > * 3.8.1 says "Therefore this draft recommends that every invalid > authorization request MUST NOT automatically redirect the user agent > to the client's redirect URI" -- This is gonna break a lot of stuff > including other specs! I don't think that's warranted, and I am not > looking forward to the fallout this could cause. >=20 > Anyway, my $0.02. Hope it helps. >=20 > [1] https://arxiv.org/pdf/1601.01229v2.pdf = >=20 > On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan > wrote: > > Hi Torsten, > > > > As we briefly spoke about earlier, "3.8.1. Authorization Server as = Open > > Redirector" could I think be made more explicit. > > > > Currently it explicitly mentions the invalid_request and = invalid_scope > > errors must not redirect back to the client's registered redirect = uri. > > > > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 = defines several = more > > potential errors that appear to fall into the same category. I = understand to > > block the attack fully we need 'must not redirect's for all the = kinds of > > error that could cause an automatic redirect back to the client's = registered > > redirect uri without any user interaction - 'unauthorized_client' = and > > 'unsupported_response_type' seem to fall into that category. = 'server_error' > > also seems dodgy (I would wager that on some servers that are known = ways to > > provoke server errors), and I would have doubts about > > 'temporarily_unavailable' too. > > > > Thanks > > > > Joseph > > > > > > _______________________________________________ > > 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 >=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=_03E2C428-A750-4244-9FA0-411467A12A84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian,

Am 20.03.2018 um 15:37 schrieb Brian Campbell = <bcampbell@pingidentity.com>:

+1 to what Travis said about 3.8.1

The text in 3.8 about Open Redirection is new = in this most recent -05 version of the draft so this is really the first = time it's been reviewed. I believe 3.8..1 goes too far in saying "this = draft recommends that every invalid authorization request MUST NOT = automatically redirect the user agent to the client's redirect URI."

I understand that text = was informed by https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 = but it takes one of the potential mitigation discussed there in section 3 (the one which happens to = contradict RFC 6749) and elevates it to a "MUST". I don't think = something that drastic is warranted. I think there are other mitigations = - like strict redirect_uri matching, =

In the = attack described in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker dynamically = registers a client with the AS. So exact redirect URI matching won=E2=80=99= t stop the open redirection attack since the attacker uses the correct = URI. The problem is with the change in the underlying trust model. RFC = 6749 assumes every configured client to be legit. This might have been = ok at the time RFC 6749 was published. Open dynamic client registration = collides with this assumption.   

We could distinguish between cases where the AS is = confident the client is legit and other cases. But how does the AS = determine it?

referrer-policy headers, and appending a dummy fragment on = error redirects -

Can you please explain how this protects from open = redirection? 

that can protect against the more serious redirection issues = without -security-topics trying to introduce normative breaking changes = to the behavior from the original OAuth 2.0 Authorization = Framework. 


Perhaps there are some error cases not mentioned in RFC 6749 = where returning an HTTP error code to the browser would be better or = more appropriate than redirecting back to the OAuth client (my opinion = on this has gone in circles and I'm honestly not sure anymore). But = saying that authorization requests never automatically redirect back to = the client's redirect URI is excessive.

Probably. Let=E2=80=99s discuss in = detail. 

I think the AS should = not automatically redirect the user in case of the following error = conditions because an attacker could cause this errors via request = parameters or its = configuration:
- unsupported_response_type
- = ;invalid_scope
- unauthorized_client
- inval= id_request

kind = regards,
Torsten. 



On Tue, Mar 20, 2018 at 11:48 AM, = Travis Spencer <travis.spencer@curity.io> wrote:
I read through this = doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a = very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
    - No mention of frame breaking scripts for non-CSP aware = user agents
    -  No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
   - Despite what it says in section 1.7 of RFC 6749, many = people
think that a 302 is mandated by OAuth. It would be good to recommend = a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a = real domain.
Suggest client.example.com instead. Same issue = in 3.1.2 where
client.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <joseph@authlete.com>= wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server as = Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and = invalid_scope
> errors must not redirect back to the client's registered redirect = uri.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
= > potential errors that appear to fall into the same category. I = understand to
> block the attack fully we need 'must not redirect's for all the = kinds of
> error that could cause an automatic redirect back to the client's = registered
> redirect uri without any user interaction - 'unauthorized_client' = and
> 'unsupported_response_type' seem to fall into that category. = 'server_error'
> also seems dodgy (I would wager that on some servers that are known = ways to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> = _______________________________________________
> 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._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_03E2C428-A750-4244-9FA0-411467A12A84-- --Apple-Mail=_19C9B2F3-422E-448F-AAA5-115DDA85425D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzIwMTY0NDA4WjAjBgkqhkiG9w0BCQQxFgQUpGgj7n6YuJBs Xih9NaFbpaBSs5kwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAExnJqqt34iIunox/asX2wxp1IA6O9CgnYIuZKjNO11trAnO3CUG ZJ8RE5YqPnEHxUjPwFNsBxe45wscEytNsLpB7qrhkQwW4kRht/yCSlWahZZ7VlXZW4ATQABuFTvL ok+DAjHIIPvhhgmyZtSBPDKVShCsf2dlOaj1krQ9gpqkezY2xuKsuKLPriQAgSDjQLE3ru+LN0gp Dl3bWhnJnxxHL2kAG5YLHAfgF/AsWbnbYavqblleMAhSJi6ogsRzN1w1Y6NSnuMk/ZXKCkQYF/jq YzqhgxR18X80ggGjT7u9Tf94+e5Hn0Fb/gHw3z0z27T0t0lcsS1XCCPeonNMKbkAAAAAAAA= --Apple-Mail=_19C9B2F3-422E-448F-AAA5-115DDA85425D-- From nobody Tue Mar 20 10:53:09 2018 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 C7025126CB6 for ; Tue, 20 Mar 2018 10:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 O4P1-RcraOtt for ; Tue, 20 Mar 2018 10:53:05 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 99E04126BF7 for ; Tue, 20 Mar 2018 10:53:04 -0700 (PDT) X-AuditID: 12074422-80bff700000057b1-4a-5ab14a7dbe7a 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 96.8B.22449.E7A41BA5; Tue, 20 Mar 2018 13:53:02 -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 w2KHqv1A025436 for ; Tue, 20 Mar 2018 13:52:59 -0400 Received: from [192.168.65.25] (89-197-166-66.virtual1.co.uk [89.197.166.66] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2KHqsgF012409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 20 Mar 2018 13:52:56 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_DAA6A88B-9E40-4DFB-B3D4-B839133FFDD7" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> Date: Tue, 20 Mar 2018 17:52:54 +0000 To: "" X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6nolvntTHK4P1SU4uTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49nbj4wFv7Iq5hzZwtbAeCeqi5GDQ0LARKL5qm4XIxeHkMBi JokN3y6xQDjHGCWu7//DDuG8Z5K4fHsuUxcjJwebgKrE9DUtYDazQJLElfY17CA2L9Ck928f gsWFBRQkpnatYgPZwCtgJfFiEg9ImAWo9fXyxYwgtoiAusSa8z/ByiUElCSmf7/NNoGRZxaS qbOQTIWIa0ssW/iaGcLWlNjfvZwFU1xDovPbRNYFjGyrGGVTcqt0cxMzc4pTk3WLkxPz8lKL dE31cjNL9FJTSjcxgkPPRWkH48R/XocYBTgYlXh4J0hsjBJiTSwrrsw9xCjJwaQkyhuoCBTi S8pPqcxILM6ILyrNSS0+xCjBwawkwpupAJTjTUmsrEotyodJSXOwKInzephoRwkJpCeWpGan phakFsFkZTg4lCR4Ez2BGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG54PU8BYXJOYWZ6ZD5E8x2nN8 6nnQxsyx5dFLIHkATN548bqNWYglLz8vVUqcVw2kTQCkLaM0D24yKK1EHl3m9IpRHOhRYd55 IFU8wJQEN/sV0FomoLXZMzeArC1JREhJNTDy3VcIFf3hobw3rtWsVvB6i3GpS1Uui/06ec+j 0wREFsj8ZQl8vsXZnf/DR8vtWwVecHuVhfexb3x8wnOdVZvfi+8Oi3hP+dw6IfiJz2mlkVAu A2vesf5zil9+LogOdvPMlF0nvuGkoPHG9TeeCVnu+2ejsWveSeN9U6zKF+0/GP9ogmqH0WIl luKMREMt5qLiRACulsveBgMAAA== Archived-At: Subject: [OAUTH-WG] Review of oauth-mtls-07 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, 20 Mar 2018 17:53:08 -0000 --Apple-Mail=_DAA6A88B-9E40-4DFB-B3D4-B839133FFDD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As promised in yesterday=E2=80=99s meeting, here=E2=80=99s my review of = the oauth-mtls draft. We=E2=80=99ve recently implemented the spec from = the AS and RS side for an as-yet-unreleased version of the Authlete = service, and overall it=E2=80=99s in really good shape and very = implementable as it stands today. Great work, and usable right now! Comments, nits, and suggestions as follows: =C2=A7Abstract: Single sentence is a bit of a run-on that=E2=80=99s hard = to follow. Suggested rewrite: This document describes OAuth client authentication and = sender-constrained tokens using Transport Layer Security (TLS) mutual = authentication with X.509 certificates. OAuth clients are provided a = mechanism for authentication to the authorization sever using mutual = TLS, based on either single certificates or public key infrastructure = (PKI). OAuth authorization servers are provided a mechanism for binding = access tokens to a client=E2=80=99s mutual TLS certificate, and OAuth = protected resources are provided a method for ensuring that such an = access token presented to it was issued to the client presenting the = token. =C2=A71=C2=B61 (and throughout): The document goes back and forth = between =E2=80=9Cmutual TLS authentication=E2=80=9D and =E2=80=9CTLS = mutual authentication=E2=80=9D, one should be picked and used = consistently throughout. I realize this is spelled out in 1.2 but it = might be worth the effort to use one form most of the time. =C2=A71=C2=B63: maybe don=E2=80=99t call it a =E2=80=9Cbasic bearer = token=E2=80=9D and instead just a =E2=80=9Cbearer token=E2=80=9D to = avoid sounding judgmental=09 =C2=A72=C2=B61: suggest turning parenthetical into a list: = =E2=80=9C(regardless of whether the client was dynamically registered, = statically configured, or otherwise established)=E2=80=9D =C2=A72=C2=B63: It seems this paragraph is trying to leave the door open = to other MTLS bound client auth methods, but such methods would require = the definition of a different auth method parameter value and a new = spec, not really an extension of what=E2=80=99s here. Therefore, suggest = changing the end of the paragraph into a single compact sentence: The authorization server MUST enforce the binding a certificate to a specific client as described in either = Section 2.1 = or Section 2.2 = = below. =C2=A72.1=C2=B61: It would be helpful to have a pointer on methods of = comparing DNs. In our implementation we serialize them to strings using = a canonical format (RFC2253) and doing a string comparison based on = that. There are probably other ways, but it would be good to help = developers avoid doing something naive like comparing two different = serializations as strings.=20 =C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an = unnecessary distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D = regardless of how it got there =C2=A72.1.1=C2=B61: Is it necessary to introduce the registry here = instead of just pointing to it? I=E2=80=99m fine with stating that the = values are used in both discovery and client registration.=20 =C2=A72.1.2: I=E2=80=99m only just now seeing the reference to RFC4514 = here so this reference needs to be in the parent section as well. I was = previously under the impression that no format was prescribed.=20 =C2=A72.2=C2=B61: Might want to say explicitly in here that the cert is = in the JWK for the client (instead of lower down), as it would make the = description of the JWKS_URI method make more sense upfront. This could = also live in the parent section. =C2=A72.2=C2=B61: "certificate chain is not validated=E2=80=9D should = probably more explicitly point to the *client=E2=80=99s* certificate not = being validated to prevent clients from not validating the *server=E2=80=99= s* certificate chain. =C2=A72.2=C2=B61: Extraneous comma: "successfully authenticated, if the = subject=E2=80=9D =C2=A72.2.1: Same comment as =C2=A72.1.1 =C2=A73.1=C2=B62: As Brian mentioned in another message, this should = specify =E2=80=9Cno padding=E2=80=9D. =C2=A74.1=C2=B61: Probably intend =E2=80=9Cset up=E2=80=9D instead of = =E2=80=9Csetup=E2=80=9D =C2=A74.1=C2=B64: =E2=80=9Cseparate host name=E2=80=9D should be = =E2=80=9Cseparate host name or port=E2=80=9D =C2=A74.2=C2=B61: Wording is a bit awkward, suggest: Since the resource server relies on the authorization server to perform = client authentication, there is no need for the resource server to = validate the trust chain of the client's certificate in any of the methods defined in this document. =20 =C2=A74.3=C2=B61: I get what this section is trying to say but it is = confusingly laid out. Might be better to say something like =E2=80=9CMTLS = client auth and sender-constrained MTLS bound tokens can be used = independently of each other=E2=80=9D.=20 =C2=A74.3=C2=B61: This advice doesn=E2=80=99t just apply to public = clients, so we probably don=E2=80=99t mean =E2=80=9Cwould not = authenticate the client=E2=80=9D here but instead =E2=80=9Cwould not = authenticate the client using mutual TLS=E2=80=9D, since the client = could authenticate in other methods. Though it is important to point out = that public clients can do this :too:, it=E2=80=99s just as important to = allow a client to use private_key_jwt or client_secret_basic and still = get a constrained token. =C2=A7A=C2=B62: This paragraph reads a bit overly defensive. I = understand the need to position the two drafts in relationship to each = other, but the tone here could be adjusted significantly without losing = the thrust of the main argument. --Apple-Mail=_DAA6A88B-9E40-4DFB-B3D4-B839133FFDD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = promised in yesterday=E2=80=99s meeting, here=E2=80=99s my review of the = oauth-mtls draft. We=E2=80=99ve recently implemented the spec from the = AS and RS side for an as-yet-unreleased version of the Authlete service, = and overall it=E2=80=99s in really good shape and very implementable as = it stands today. Great work, and usable right now!



Comments, nits, and suggestions as = follows:

=C2=A7Abstract: Single sentence is a bit of a run-on that=E2=80= =99s hard to follow. Suggested rewrite:

This document describes OAuth = client authentication and sender-constrained tokens using Transport = Layer Security (TLS) mutual authentication with X.509 certificates. = OAuth clients are provided a mechanism for authentication to the = authorization sever using mutual TLS, based on either single = certificates or public key infrastructure (PKI). OAuth authorization = servers are provided a mechanism for binding access tokens to a = client=E2=80=99s mutual TLS certificate, and OAuth protected resources = are provided a method for ensuring that such an access token presented = to it was issued to the client presenting the = token.

=C2=A71=C2=B61 (and throughout): The document goes back and = forth between =E2=80=9Cmutual TLS authentication=E2=80=9D and =E2=80=9CTLS= mutual authentication=E2=80=9D, one should be picked and used = consistently throughout. I realize this is spelled out in 1.2 but it = might be worth the effort to use one form most of the time.
=C2=A71=C2=B63: maybe don=E2=80=99t call it a =E2=80=9Cbasic = bearer token=E2=80=9D and instead just a =E2=80=9Cbearer token=E2=80=9D = to avoid sounding judgmental
=C2=A72=C2=B6= 1: suggest turning parenthetical into a list: =E2=80=9C(regardless of = whether the client was dynamically registered, statically configured, or = otherwise established)=E2=80=9D
=C2=A72=C2=B63: It = seems this paragraph is trying to leave the door open to other MTLS = bound client auth methods, but such methods would require the definition = of a different auth method parameter value and a new spec, not really an = extension of what=E2=80=99s here. Therefore, suggest changing the end of = the paragraph into a single compact sentence:

 The =
authorization server MUST enforce the
   binding a certificate to a specific client as described in either Section 2.1 or
   Section 2.2 below.

=C2=A72.1=C2=B61: It = would be helpful to have a pointer on methods of comparing DNs. In our = implementation we serialize them to strings using a canonical format = (RFC2253) and doing a string comparison based on that. There are = probably other ways, but it would be good to help developers avoid doing = something naive like comparing two different serializations as = strings. 
=C2=A72.1=C2=B61: =E2=80=9Cconfigured = or registered=E2=80=9D is an unnecessary distinction, 6749 calls it = =E2=80=9Cregistered=E2=80=9D regardless of how it got there
=C2=A72.1.1=C2=B61: Is it necessary to introduce the registry = here instead of just pointing to it? I=E2=80=99m fine with stating that = the values are used in both discovery and client = registration. 
=C2=A72.1.2: I=E2=80=99m only = just now seeing the reference to RFC4514 here so this reference needs to = be in the parent section as well. I was previously under the impression = that no format was prescribed. 
=C2=A72.2=C2=B61= : Might want to say explicitly in here that the cert is in the JWK for = the client (instead of lower down), as it would make the description of = the JWKS_URI method make more sense upfront. This could also live in the = parent section.
=C2=A72.2=C2=B61: "certificate = chain is not validated=E2=80=9D should probably more explicitly point to = the *client=E2=80=99s* certificate not being validated to prevent = clients from not validating the *server=E2=80=99s* certificate = chain.
=C2=A72.2=C2=B61: Extraneous comma: = "successfully authenticated, if the subject=E2=80=9D
=C2=A72.2.1: Same comment as =C2=A72.1.1
=C2=A73.1=C2=B62: As Brian mentioned in another message, this = should specify =E2=80=9Cno padding=E2=80=9D.
=C2=A74.1=C2=B61: Probably intend =E2=80=9Cset up=E2=80=9D = instead of =E2=80=9Csetup=E2=80=9D
=C2=A74.1=C2=B64: = =E2=80=9Cseparate host name=E2=80=9D should be =E2=80=9Cseparate host = name or port=E2=80=9D
=C2=A74.2=C2=B61: Wording is = a bit awkward, suggest:

Since =
the resource server relies on the authorization server to perform client =
authentication, there is no need for the resource server to validate
   the trust chain of the client's certificate in any of the methods
   defined in this document.
=C2=A74.3=C2=B61: I get what this section is trying to say = but it is confusingly laid out. Might be better to say something like = =E2=80=9CMTLS client auth and sender-constrained MTLS bound tokens can = be used independently of each other=E2=80=9D. 
=C2=A74.3=C2=B61: This advice doesn=E2=80=99t just apply to = public clients, so we probably don=E2=80=99t mean =E2=80=9Cwould not = authenticate the client=E2=80=9D here but instead =E2=80=9Cwould not = authenticate the client using mutual TLS=E2=80=9D, since the client = could authenticate in other methods. Though it is important to point out = that public clients can do this :too:, it=E2=80=99s just as important to = allow a client to use private_key_jwt or client_secret_basic and still = get a constrained token.
=C2=A7A=C2=B62: This = paragraph reads a bit overly defensive. I understand the need to = position the two drafts in relationship to each other, but the tone here = could be adjusted significantly without losing the thrust of the main = argument.


= --Apple-Mail=_DAA6A88B-9E40-4DFB-B3D4-B839133FFDD7-- From nobody Tue Mar 20 12:39:13 2018 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 D2E8C1289B0 for ; Tue, 20 Mar 2018 12:39:12 -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, 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 6xgHkqFqrLvc for ; Tue, 20 Mar 2018 12:39:09 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38D41241F5 for ; Tue, 20 Mar 2018 12:39:08 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v194-v6so3887946itb.0 for ; Tue, 20 Mar 2018 12:39:08 -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=D/QuaGapR9R3txcfU3Dz6KmG3/Bm/kTApUU9+qWRfi8=; b=Z/kqWkK1q0w4xzbq+JSYLLjVXSgDrDzyyGJZ/B3jTAxPpuEsLxKcqti7uc+OFQWq/J 7NSFijWZ/QIxTb0fwYOytBbLlehW3nRYoCa/UoA1ukORbkYoH5IdEdRZKLBMUF5ZXC8d uiY/XIZ0mDUwHqotDCWDmHV2q9uBhJwtmNvsY= 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=D/QuaGapR9R3txcfU3Dz6KmG3/Bm/kTApUU9+qWRfi8=; b=qaKJdVlUDoxhw00TkymCLvXMmnwj2Qv4iqXREv6P1jg3cJWjOoqIu+uB1GgrOINISF 6vxBtomJhAFqSwJJm+8p3CA1gBvqwI0aPf0PNRzn8y1vWBBv84LcGeHGoypgpCJlxc/X NmJMa89Cwo0nEnqq4lWRQgCDM1boPq8Fr4xk+OYuhJTNKjqehYyLlSrMh0i/vWH1R4YB M8tbL7MmM9I93gNq2wqKxZZh1KUuc8qM+cRBtXguZi8Hej1PXXPP+6clDUqI80fiaYFo 0t+YKt6ZG5ZVmFNbQvgYgi8mgXCdY9BrSYC0V5jRp46O/lqVYc34bF6V5NzrID+kLe5L SJGA== X-Gm-Message-State: AElRT7EUXlQlR65oEcYOCcvwhdVih2sAJbRwp6IfyOieDc7brUEhnNGG 5jf6Q86sqvxdvTGpVr2ZH02eZNiFBEpVcS4jFPQ75cqWHJ1KsyFdcmOjK4xUX7vArXtUhXbwoOI 3LUJNYQIg815I/g== X-Google-Smtp-Source: AG47ELuc+AH8WKOyO/WDOUQH28UP/A4ovCwNfXN15bOHoEdzAO6hNsgWhOuuNfLaBED73gr9hXUXYfmZ2YVjxIqmhTY= X-Received: by 2002:a24:5491:: with SMTP id t139-v6mr971005ita.89.1521574748087; Tue, 20 Mar 2018 12:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Tue, 20 Mar 2018 12:38:37 -0700 (PDT) In-Reply-To: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> From: Brian Campbell Date: Tue, 20 Mar 2018 19:38:37 +0000 Message-ID: To: Torsten Lodderstedt Cc: Travis Spencer , oauth Content-Type: multipart/alternative; boundary="0000000000005c05620567dd3a37" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Tue, 20 Mar 2018 19:39:13 -0000 --0000000000005c05620567dd3a37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The strict redirect_uri matching, referrer-policy headers, and appending a dummy fragment on error redirects are things that protect from token leakage/interception resulting from redirection on error, which is the threat in section 2.2 of -closing-redirectors-00 . It's true that they don't protect against the kind of open redirection based on malicious client registration that's described in section 2.1 . But I don't believe that abuse (as that document calls it) is serious enough to warrant trying to introduce a breaking change to the original behavior of RFC 6749 in this security topics document. On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Brian, > > Am 20.03.2018 um 15:37 schrieb Brian Campbell >: > > +1 to what Travis said about 3.8.1 > > The text in 3.8 about Open Redirection is new in this most recent -05 > version of the draft so this is really the first time it's been reviewed.= I > believe 3.8..1 goes too far in saying "this draft recommends that every > invalid authorization request MUST NOT automatically redirect the user > agent to the client's redirect URI." > > I understand that text was informed by https://tools.ietf.org/html/dr > aft-ietf-oauth-closing-redirectors-00 but it takes one of the potential > mitigation discussed there in section 3 > > (the one which happens to contradict RFC 6749) and elevates it to a "MUST= ". > I don't think something that drastic is warranted. I think there are othe= r > mitigations - like strict redirect_uri matching, > > > In the attack described in https://tools.ietf.org/ > html/draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker > dynamically registers a client with the AS. So exact redirect URI matchin= g > won=E2=80=99t stop the open redirection attack since the attacker uses th= e correct > URI. The problem is with the change in the underlying trust model. RFC 67= 49 > assumes every configured client to be legit. This might have been ok at t= he > time RFC 6749 was published. Open dynamic client registration collides wi= th > this assumption. > > We could distinguish between cases where the AS is confident the client i= s > legit and other cases. But how does the AS determine it? > > referrer-policy headers, and appending a dummy fragment on error redirect= s > - > > > Can you please explain how this protects from open redirection? > > that can protect against the more serious redirection issues without > -security-topics trying to introduce normative breaking changes to the > behavior from the original OAuth 2.0 Authorization Framework. > > > > Perhaps there are some error cases not mentioned in RFC 6749 where > returning an HTTP error code to the browser would be better or more > appropriate than redirecting back to the OAuth client (my opinion on this > has gone in circles and I'm honestly not sure anymore). But saying that > authorization requests never automatically redirect back to the client's > redirect URI is excessive. > > > Probably. Let=E2=80=99s discuss in detail. > > I think the AS should not automatically redirect the user in case of the > following error conditions because an attacker could cause this errors vi= a > request parameters or its configuration: > - unsupported_response_type > - invalid_scope > - unauthorized_client > - invalid_request > > kind regards, > Torsten. > > > > On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer > wrote: > >> I read through this doc and would like to share a bit of feedback in >> hopes that it helps: >> >> * There is no mention of Content Security Policy (CSP). This is a very >> helpful security mechanism that all OAuth servers and web-based >> clients should implement. I think this needs to be addressed in this >> doc. >> - No mention of frame breaking scripts for non-CSP aware user agents >> - No mention of X-Frame-Options >> * There's no mention of HSTS which all OAuth servers and web-based >> client should implement (or the reverse proxies in front of them >> should) >> * The examples only use 302 and don't mention that 303 is safer[1] >> - Despite what it says in section 1.7 of RFC 6749, many people >> think that a 302 is mandated by OAuth. It would be good to recommend a >> 303 and use examples with other status codes. >> * 3.3.1 refers to client.com in the example. This is a real domain. >> Suggest client.example.com instead. Same issue in 3.1.2 where >> client.evil.com is used >> * 3.1.3 (proposed countermeasures) - native clients that use a web >> server with a dynamic port should use dynamic client registration and >> dynamic client management rather than allowing wildcards on the port >> matching of the OAuth server. >> * 3.8.1 says "Therefore this draft recommends that every invalid >> authorization request MUST NOT automatically redirect the user agent >> to the client's redirect URI" -- This is gonna break a lot of stuff >> including other specs! I don't think that's warranted, and I am not >> looking forward to the fallout this could cause. >> >> Anyway, my $0.02. Hope it helps. >> >> [1] https://arxiv.org/pdf/1601.01229v2.pdf >> >> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan >> wrote: >> > Hi Torsten, >> > >> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Ope= n >> > Redirector" could I think be made more explicit. >> > >> > Currently it explicitly mentions the invalid_request and invalid_scope >> > errors must not redirect back to the client's registered redirect uri. >> > >> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several >> more >> > potential errors that appear to fall into the same category. I >> understand to >> > block the attack fully we need 'must not redirect's for all the kinds = of >> > error that could cause an automatic redirect back to the client's >> registered >> > redirect uri without any user interaction - 'unauthorized_client' and >> > 'unsupported_response_type' seem to fall into that category. >> 'server_error' >> > also seems dodgy (I would wager that on some servers that are known >> ways to >> > provoke server errors), and I would have doubts about >> > 'temporarily_unavailable' too. >> > >> > Thanks >> > >> > Joseph >> > >> > >> > _______________________________________________ >> > 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.*_______________________________________________ > 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.* --0000000000005c05620567dd3a37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The strict redirect_uri matching, referrer-policy hea= ders, and appending a dummy fragment on error redirects are things that pro= tect from token leakage/interception resulting from redirection on error, w= hich is the threat in section 2.2 of -cl= osing-redirectors-00. It's true that they don't protect against= the kind of open redirection based on malicious client registration that&#= 39;s described in section 2.1.=C2=A0= But I don't believe that abuse (as that document calls it) is serious = enough to warrant trying to introduce a breaking change to the origi= nal behavior of=C2=A0RFC 6749 in this security topics document.

=




On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:
Hi Brian,

A= m 20.03.2018 um 15:37 schrieb Brian Campbell <bcampbell@pingidentity.com>:
+1 to what Travis said about 3.8.1
<= br>
The text in 3.8 about Open Redirection is new in this most r= ecent -05 version of the draft so this is really the first time it's be= en reviewed. I believe 3.8..1 goes too far in saying "this draft recom= mends that every invalid authorization request MUST NOT automatically redir= ect the user agent to the client's redirect URI."

I understand that text was informed by https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential mitigation discussed there = in section 3 (the one which happens = to contradict RFC 6749) and elevates it to a "MUST". I don't = think something that drastic is warranted. I think there are other mitigati= ons - like strict redirect_uri matching,

In the attack described in=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-closing-redirect= ors-00=C2=A0section 2.1. the attacker dynamically registers a client wi= th the AS. So exact redirect URI matching won=E2=80=99t stop the open redir= ection attack since the attacker uses the correct URI. The problem is with = the change in the underlying trust model. RFC 6749 assumes every configured= client to be legit. This might have been ok at the time RFC 6749 was publi= shed. Open dynamic client registration collides with this assumption. =C2= =A0=C2=A0

We could distinguish between cases where= the AS is confident the client is legit and other cases. But how does the = AS determine it?

<= div dir=3D"ltr">
referrer-policy headers, and appending a dummy fragmen= t on error redirects -

Can you please explain how this protects from open redirection?=C2=A0=

=
that can protect against the more serious redirection issues without -= security-topics trying to introduce normative breaking changes to the behav= ior from the original OAuth 2.0 Authorization Framework.=C2=A0
<= /div>


Perhaps there are some = error cases not mentioned in RFC 6749 where returning an HTTP error code to= the browser would be better or more appropriate than redirecting back to t= he OAuth client (my opinion on this has gone in circles and I'm honestl= y not sure anymore). But saying that authorization requests never automatic= ally redirect back to the client's redirect URI is excessive.
=

Probably. Let=E2=80=99s disc= uss in detail.=C2=A0

I think the AS should not aut= omatically redirect the user in case of the following error conditions beca= use an attacker could cause this errors via request parameters or its confi= guration:
-=C2=A0unsupported_response_type
-=C2=A0inval= id_scope
-=C2=A0unauthorized_client
-=C2=A0invalid_requ= est

kind regards,
Torsten.=C2=A0



On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer &= lt;travis.spe= ncer@curity.io> wrote:
I re= ad through this doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
=C2=A0 =C2=A0 - No mention of frame breaking scripts for non-CSP aware user= agents
=C2=A0 =C2=A0 -=C2=A0 No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
=C2=A0 =C2=A0- Despite what it says in section 1.7 of RFC 6749, many people=
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
cl= ient.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuf= f
including other specs! I don't think that's warranted, and I am not=
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <joseph@authlete.com> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server a= s Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope=
> errors must not redirect back to the client's registered redirect = uri.
>
> https://tools.ietf.org/html/rfc6749#sec= tion-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I underst= and to
> block the attack fully we need 'must not redirect's for all th= e kinds of
> error that could cause an automatic redirect back to the client's = registered
> redirect uri without any user interaction - 'unauthorized_client&#= 39; and
> 'unsupported_response_type' seem to fall into that category. &= #39;server_error'
> also seems dodgy (I would wager that on some servers that are known wa= ys to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> ______________________________________________= _
> 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 contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited..=C2=A0 If you have received this communication in error, plea= se notify the sender immediately by e-mail and delete the message and any f= ile attachments from your computer. Thank you.___________= ____________________________________
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. --0000000000005c05620567dd3a37-- From nobody Tue Mar 20 12:41:56 2018 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 8AEC91273B1 for ; Tue, 20 Mar 2018 12:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 SEaBeJbZNrD5 for ; Tue, 20 Mar 2018 12:41:50 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 B0B711241F5 for ; Tue, 20 Mar 2018 12:41:50 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id n15-v6so1637795plp.12 for ; Tue, 20 Mar 2018 12:41:50 -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=Rzq2DcYRuL0l2De4oG8WJyK+yyUlrHSf2rfLt32SmFE=; b=TC7mK3yd2sPs6YMacKq+92bQxxRViNLp+OSrTSs/cLITDSQfseLlGhMan2Lf0VfoIM CfLvU6iz0se59Ha4Zp3AchADCVWwO00emKwTNzNa2xHTQTnhTWXxfpqZz3DVnMz1hB9x OscwjKJyl5sQSHlGD38eY8cQw37uQqaODX7j8stDvIZZG6cckDhGtatG6X2Xew/n/Tk8 B6Mlu7eg6sK8JI4EXGXSLYI1elK3mw6UsFqQJ8KkHZs+Ng4xEqkdiPR5ZytoC/U/sMtA 1pImZugBDFOssFUbp4z+c5UQwkduc5iaS8MrxnHcR48M8ufpL/L8j0xZchHGiWXv/d5j PJyw== 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=Rzq2DcYRuL0l2De4oG8WJyK+yyUlrHSf2rfLt32SmFE=; b=KZNVtV0mTrbbbCMSP5yfLwIg8ew1yTEKqhEHd8WXA2Zzb7uarv+wUzASa6SKm8vv9J jxW6r8mXJJcpnLJJAB+TAWm1ZnA7Bj3FFB8uJims4W2Eri2NjVUxGXzVL6v4T81mqYtJ wqdO9+KkLEQj6FDDIP02nx2bpCFHV9zkM17VByAUuVXiPVyA/MO2G6JXVWdgxQuVupPp 2S1xMPjFj+R+tWySZLydptCRNzon+7MyzMareS7YyIPXg9IrcNpefgFksK89wa844Zaw U96ElwyXFYDSdBtMaVLZ5eB6buPwqBIEIfGTlGoPD4/4XP15vIxfENVdEuf/tWk9V+8g 7cog== X-Gm-Message-State: AElRT7EMEfDGRV9W/pg57dksNaalSSWQzmVDfcXYbaGd5Qu6H17v7vRV RIrIBTEFBSm7rCStDKj9stksGDc50HI= X-Google-Smtp-Source: AG47ELuJl6f5ghDX7fdb0wTYCDc9Z3Y71j+fECjXI3FWRwLNj9AuA0lZLoIRBgcn0V0+aR2R67uZ6w== X-Received: by 2002:a17:902:b943:: with SMTP id h3-v6mr17748515pls.1.1521574910236; Tue, 20 Mar 2018 12:41:50 -0700 (PDT) Received: from [10.201.222.239] (mobile-166-176-59-105.mycingular.net. [166.176.59.105]) by smtp.gmail.com with ESMTPSA id r9sm2925293pfg.128.2018.03.20.12.41.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 12:41:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C0E85C71-361A-4E2C-9537-958D5D9529A2 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Tue, 20 Mar 2018 09:41:48 -1000 Cc: Travis Spencer , oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Tue, 20 Mar 2018 19:41:54 -0000 --Apple-Mail-C0E85C71-361A-4E2C-9537-958D5D9529A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you plan on adding these web layer security suggestions into the OAuth st= andard I can think of 100-200 more requirements to add. I thought =E2=80=9Cd= o web security right=E2=80=9D was an implied recommendation? -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Mar 20, 2018, at 5:37 AM, Brian Campbell w= rote: >=20 > +1 to what Travis said about 3.8.1 >=20 > The text in 3.8 about Open Redirection is new in this most recent -05 vers= ion of the draft so this is really the first time it's been reviewed. I beli= eve 3.8..1 goes too far in saying "this draft recommends that every invalid a= uthorization request MUST NOT automatically redirect the user agent to the c= lient's redirect URI."=20 >=20 > I understand that text was informed by https://tools.ietf.org/html/draft-i= etf-oauth-closing-redirectors-00 but it takes one of the potential mitigatio= n discussed there in section 3 (the one which happens to contradict RFC 6749= ) and elevates it to a "MUST". I don't think something that drastic is warra= nted. I think there are other mitigations - like strict redirect_uri matchin= g, referrer-policy headers, and appending a dummy fragment on error redirect= s - that can protect against the more serious redirection issues without -se= curity-topics trying to introduce normative breaking changes to the behavior= from the original OAuth 2.0 Authorization Framework.=20 >=20 > Perhaps there are some error cases not mentioned in RFC 6749 where returni= ng an HTTP error code to the browser would be better or more appropriate tha= n redirecting back to the OAuth client (my opinion on this has gone in circl= es and I'm honestly not sure anymore). But saying that authorization request= s never automatically redirect back to the client's redirect URI is excessiv= e. >=20 >=20 >> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer wrote: >> I read through this doc and would like to share a bit of feedback in >> hopes that it helps: >>=20 >> * There is no mention of Content Security Policy (CSP). This is a very >> helpful security mechanism that all OAuth servers and web-based >> clients should implement. I think this needs to be addressed in this >> doc. >> - No mention of frame breaking scripts for non-CSP aware user agents >> - No mention of X-Frame-Options >> * There's no mention of HSTS which all OAuth servers and web-based >> client should implement (or the reverse proxies in front of them >> should) >> * The examples only use 302 and don't mention that 303 is safer[1] >> - Despite what it says in section 1.7 of RFC 6749, many people >> think that a 302 is mandated by OAuth. It would be good to recommend a >> 303 and use examples with other status codes. >> * 3.3.1 refers to client.com in the example. This is a real domain. >> Suggest client.example.com instead. Same issue in 3.1.2 where >> client.evil.com is used >> * 3.1.3 (proposed countermeasures) - native clients that use a web >> server with a dynamic port should use dynamic client registration and >> dynamic client management rather than allowing wildcards on the port >> matching of the OAuth server. >> * 3.8.1 says "Therefore this draft recommends that every invalid >> authorization request MUST NOT automatically redirect the user agent >> to the client's redirect URI" -- This is gonna break a lot of stuff >> including other specs! I don't think that's warranted, and I am not >> looking forward to the fallout this could cause. >>=20 >> Anyway, my $0.02. Hope it helps. >>=20 >> [1] https://arxiv.org/pdf/1601.01229v2.pdf >>=20 >> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan wro= te: >> > Hi Torsten, >> > >> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open= >> > Redirector" could I think be made more explicit. >> > >> > Currently it explicitly mentions the invalid_request and invalid_scope >> > errors must not redirect back to the client's registered redirect uri. >> > >> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several mor= e >> > potential errors that appear to fall into the same category. I understa= nd to >> > block the attack fully we need 'must not redirect's for all the kinds o= f >> > error that could cause an automatic redirect back to the client's regis= tered >> > redirect uri without any user interaction - 'unauthorized_client' and >> > 'unsupported_response_type' seem to fall into that category. 'server_er= ror' >> > also seems dodgy (I would wager that on some servers that are known way= s to >> > provoke server errors), and I would have doubts about >> > 'temporarily_unavailable' too. >> > >> > Thanks >> > >> > Joseph >> > >> > >> > _______________________________________________ >> > 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 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.. If you have rec= eived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C0E85C71-361A-4E2C-9537-958D5D9529A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you plan on adding these web layer secur= ity suggestions into the OAuth standard I can think of 100-200 more requirem= ents to add. I thought =E2=80=9Cdo web security right=E2=80=9D was an implie= d recommendation?

--
Ji= m Manico
@Manicode
Secure Coding Education
+1 (= 808) 652-3805

On Mar 20, 2018, at 5:37 AM, Brian Campbel= l <bcampbell@pingidentity.c= om> wrote:

+1 to what Travis said about 3.8.1

The text in 3.8 about Open= Redirection is new in this most recent -05 version of the draft so this is r= eally the first time it's been reviewed. I believe 3.8..1 goes too far in sa= ying "this draft recommends that every invalid authorization request MUST NO= T automatically redirect the user agent to the client's redirect URI."
<= br>
I understand that text was informed by h= ttps://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00= but it takes one of the potential mitigation discussed there in section 3 (the one which happens to contradict RFC 6749) and el= evates it to a "MUST". I don't think something that drastic is warranted. I t= hink there are other mitigations - like strict redirect_uri matching, referr= er-policy headers, and appending a dummy fragment on error redirects - that c= an protect against the more serious redirection issues without -security-top= ics trying to introduce normative breaking changes to the behavior from the o= riginal OAuth 2.0 Authorization Framework.

Perhaps there a= re some error cases not mentioned in RFC 6749 where returning an HTTP error c= ode to the browser would be better or more appropriate than redirecting back= to the OAuth client (my opinion on this has gone in circles and I'm honestl= y not sure anymore). But saying that authorization requests never automatica= lly redirect back to the client's redirect URI is excessive.
<= br>

On T= ue, Mar 20, 2018 at 11:48 AM, Travis Spencer <travis.spencer@curity.io= > wrote:
I read through this d= oc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
    - No mention of frame breaking scripts for non-CSP aware user a= gents
    -  No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
   - Despite what it says in section 1.7 of RFC 6749, many people<= br> think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
clie= nt.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <joseph@authlete.com> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server as Open=
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope<= br> > errors must not redirect back to the client's registered redirect uri.<= br> >
> https://tools.ietf.org/html/rfc6749#secti= on-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I understa= nd to
> block the attack fully we need 'must not redirect's for all the kinds o= f
> error that could cause an automatic redirect back to the client's regis= tered
> redirect uri without any user interaction - 'unauthorized_client' and > 'unsupported_response_type' seem to fall into that category. 'server_er= ror'
> also seems dodgy (I would wager that on some servers that are known way= s to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> ___________________= ____________________________
> 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 pr= ivileged 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 imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-C0E85C71-361A-4E2C-9537-958D5D9529A2-- From nobody Wed Mar 21 00:37:12 2018 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 D30A51250B8 for ; Wed, 21 Mar 2018 00:37:10 -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 HyyHUySsf3E7 for ; Wed, 21 Mar 2018 00:37:07 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 BB6A11201FA for ; Wed, 21 Mar 2018 00:37:07 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id b136-v6so5679984iti.3 for ; Wed, 21 Mar 2018 00:37:07 -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=gcUJBkypZFxG9CCxrYBiFVqaeFK/S8l2w729FWbgVdQ=; b=m7sVl6t0xpyr6M+lgwkEkLxiRBssNMQ7WXzuO8t/0lQdhLFAT/7vY3VPCep55VLC9m 4Po4+0ikxqxHw4cbC1z9Tj3MBs3Noqhj9fTajqb1sfItud0W1lZFAnE3cW8mtqIqSTPG qX0eFi4iW+K/cImqkQ+Ltplo882032FfFSmwo= 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=gcUJBkypZFxG9CCxrYBiFVqaeFK/S8l2w729FWbgVdQ=; b=mVtGLPbKgFeK6O552vHvHHet9O6Nsjt3vFLrHdilmx0r44JfqXlG5rg1xqFNoIlM0K SyWfS0Ajrbtf4nPTg46BLGGup0LTcBtwJ7MdJ3WvwS5n+8XW+EJusZeVi41IU6xN7UHi VkFpaCLqGmX+y85SScdtzogOadgL/Vg/BEecTyfrNSSA+P+TF6vUppFICTahATjQnH7j LTio072yqOGlVmQWXgcDoSIVpLyazdgiH9BSR1iRXR0VlFmABV9/Vs2vyzudC8I2AXX6 kEVsFX+QBUf4Mb6eIVs2Yoy56pNy7h1dkyjo31MRhldRsmYeNb0newpYmZxSNuljrPs6 tMvA== X-Gm-Message-State: AElRT7FSoZUzwZrbweja7JwqH1K4lvIhG45B+g6/cfLGIq29QmWaXUCy 2sg6j6Lq2WIed7uX3eA9s+pLeqWro9r9ZoCU8O2JK9aa5TPawOCDQTbIFHhOxT6xmQ5pdLB2RHQ trkiUlW5mKZr2ow== X-Google-Smtp-Source: AG47ELsIscmB0Px/Zdm1LZL2jxrqX19Y9z8/VIf7YkGz6eOdFFxiJPGyG94+AA+dqGtGJrZgGOrEQWOkKZVKSIGBGQE= X-Received: by 2002:a24:2f8d:: with SMTP id j135-v6mr3011556itj.53.1521617826909; Wed, 21 Mar 2018 00:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Wed, 21 Mar 2018 00:36:36 -0700 (PDT) In-Reply-To: References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> From: Brian Campbell Date: Wed, 21 Mar 2018 07:36:36 +0000 Message-ID: To: Torsten Lodderstedt Cc: Travis Spencer , oauth Content-Type: multipart/alternative; boundary="0000000000000eaf240567e7428e" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Wed, 21 Mar 2018 07:37:11 -0000 --0000000000000eaf240567e7428e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doing redirection in error conditions relates to OpenID Connect flows too. There's been some related discussion recently about it in this issue: https://bitbucket.org/openid/connect/issues/1023/clarify- that-returning-errors-to-the On Tue, Mar 20, 2018 at 7:38 PM, Brian Campbell wrote: > The strict redirect_uri matching, referrer-policy headers, and appending = a > dummy fragment on error redirects are things that protect from token > leakage/interception resulting from redirection on error, which is the > threat in section 2.2 of -closing-redirectors-00 > . > It's true that they don't protect against the kind of open redirection > based on malicious client registration that's described in section 2.1 > . > But I don't believe that abuse (as that document calls it) is serious > enough to warrant trying to introduce a breaking change to the original > behavior of RFC 6749 > in this security topics document. > > > > > > > On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Brian, >> >> Am 20.03.2018 um 15:37 schrieb Brian Campbell > >: >> >> +1 to what Travis said about 3.8.1 >> >> The text in 3.8 about Open Redirection is new in this most recent -05 >> version of the draft so this is really the first time it's been reviewed= . I >> believe 3.8..1 goes too far in saying "this draft recommends that every >> invalid authorization request MUST NOT automatically redirect the user >> agent to the client's redirect URI." >> >> I understand that text was informed by https://tools.ietf.org/html/dr >> aft-ietf-oauth-closing-redirectors-00 but it takes one of the potential >> mitigation discussed there in section 3 >> >> (the one which happens to contradict RFC 6749) and elevates it to a "MUS= T". >> I don't think something that drastic is warranted. I think there are oth= er >> mitigations - like strict redirect_uri matching, >> >> >> In the attack described in https://tools.ietf.org/html >> /draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker >> dynamically registers a client with the AS. So exact redirect URI matchi= ng >> won=E2=80=99t stop the open redirection attack since the attacker uses t= he correct >> URI. The problem is with the change in the underlying trust model. RFC 6= 749 >> assumes every configured client to be legit. This might have been ok at = the >> time RFC 6749 was published. Open dynamic client registration collides w= ith >> this assumption. >> >> We could distinguish between cases where the AS is confident the client >> is legit and other cases. But how does the AS determine it? >> >> referrer-policy headers, and appending a dummy fragment on error >> redirects - >> >> >> Can you please explain how this protects from open redirection? >> >> that can protect against the more serious redirection issues without >> -security-topics trying to introduce normative breaking changes to the >> behavior from the original OAuth 2.0 Authorization Framework. >> >> >> >> Perhaps there are some error cases not mentioned in RFC 6749 where >> returning an HTTP error code to the browser would be better or more >> appropriate than redirecting back to the OAuth client (my opinion on thi= s >> has gone in circles and I'm honestly not sure anymore). But saying that >> authorization requests never automatically redirect back to the client's >> redirect URI is excessive. >> >> >> Probably. Let=E2=80=99s discuss in detail. >> >> I think the AS should not automatically redirect the user in case of the >> following error conditions because an attacker could cause this errors v= ia >> request parameters or its configuration: >> - unsupported_response_type >> - invalid_scope >> - unauthorized_client >> - invalid_request >> >> kind regards, >> Torsten. >> >> >> >> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer < >> travis.spencer@curity.io> wrote: >> >>> I read through this doc and would like to share a bit of feedback in >>> hopes that it helps: >>> >>> * There is no mention of Content Security Policy (CSP). This is a very >>> helpful security mechanism that all OAuth servers and web-based >>> clients should implement. I think this needs to be addressed in this >>> doc. >>> - No mention of frame breaking scripts for non-CSP aware user agent= s >>> - No mention of X-Frame-Options >>> * There's no mention of HSTS which all OAuth servers and web-based >>> client should implement (or the reverse proxies in front of them >>> should) >>> * The examples only use 302 and don't mention that 303 is safer[1] >>> - Despite what it says in section 1.7 of RFC 6749, many people >>> think that a 302 is mandated by OAuth. It would be good to recommend a >>> 303 and use examples with other status codes. >>> * 3.3.1 refers to client.com in the example. This is a real domain. >>> Suggest client.example.com instead. Same issue in 3.1.2 where >>> client.evil.com is used >>> * 3.1.3 (proposed countermeasures) - native clients that use a web >>> server with a dynamic port should use dynamic client registration and >>> dynamic client management rather than allowing wildcards on the port >>> matching of the OAuth server. >>> * 3.8.1 says "Therefore this draft recommends that every invalid >>> authorization request MUST NOT automatically redirect the user agent >>> to the client's redirect URI" -- This is gonna break a lot of stuff >>> including other specs! I don't think that's warranted, and I am not >>> looking forward to the fallout this could cause. >>> >>> Anyway, my $0.02. Hope it helps. >>> >>> [1] https://arxiv.org/pdf/1601.01229v2.pdf >>> >>> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan >>> wrote: >>> > Hi Torsten, >>> > >>> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Op= en >>> > Redirector" could I think be made more explicit. >>> > >>> > Currently it explicitly mentions the invalid_request and invalid_scop= e >>> > errors must not redirect back to the client's registered redirect uri= . >>> > >>> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several >>> more >>> > potential errors that appear to fall into the same category. I >>> understand to >>> > block the attack fully we need 'must not redirect's for all the kinds >>> of >>> > error that could cause an automatic redirect back to the client's >>> registered >>> > redirect uri without any user interaction - 'unauthorized_client' and >>> > 'unsupported_response_type' seem to fall into that category. >>> 'server_error' >>> > also seems dodgy (I would wager that on some servers that are known >>> ways to >>> > provoke server errors), and I would have doubts about >>> > 'temporarily_unavailable' too. >>> > >>> > Thanks >>> > >>> > Joseph >>> > >>> > >>> > _______________________________________________ >>> > 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> 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.* --0000000000000eaf240567e7428e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doing redirection in error conditions relates to OpenID Co= nnect flows too. There's been some related discussion recently about it= in this issue: https://bitbucket.= org/openid/connect/issues/1023/clarify-that-returning-errors-to-t= he

O= n Tue, Mar 20, 2018 at 7:38 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
The strict redirect_uri matching, referrer-policy headers, an= d appending a dummy fragment on error redirects are things that protect fro= m token leakage/interception resulting from redirection on error, which is = the threat in section 2.2 of -closing-re= directors-00. It's true that they don't protect against the kin= d of open redirection based on malicious client registration that's des= cribed in section 2.1.=C2=A0 But I d= on't believe that abuse (as that document calls it) is serious enough t= o warrant trying to introduce a breaking change to the original beha= vior of=C2=A0RFC 6749 in this security topics document.






On Tue, Mar 20, 2018 = at 4:44 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Brian,

Am 20.03.2018 um 15:37 schrieb Brian Campbell <bcampbell@pingi= dentity.com>:

+1 to w= hat Travis said about 3.8.1

The text in 3.8 about Open R= edirection is new in this most recent -05 version of the draft so this is r= eally the first time it's been reviewed. I believe 3.8..1 goes too far = in saying "this draft recommends that every invalid authorization requ= est MUST NOT automatically redirect the user agent to the client's redi= rect URI."

I understand that text was informe= d by https://tools.ietf.org/html/draft-ietf-oau= th-closing-redirectors-00 but it takes one of the potential mitiga= tion discussed there in section 3 (t= he one which happens to contradict RFC 6749) and elevates it to a "MUS= T". I don't think something that drastic is warranted. I think the= re are other mitigations - like strict redirect_uri matching,
=

In the attack described in=C2= =A0https://tools.ietf.org/html/draft-ietf-oauth= -closing-redirectors-00=C2=A0section 2.1. the attacker dynamically= registers a client with the AS. So exact redirect URI matching won=E2=80= =99t stop the open redirection attack since the attacker uses the correct U= RI. The problem is with the change in the underlying trust model. RFC 6749 = assumes every configured client to be legit. This might have been ok at the= time RFC 6749 was published. Open dynamic client registration collides wit= h this assumption. =C2=A0=C2=A0

We could distingui= sh between cases where the AS is confident the client is legit and other ca= ses. But how does the AS determine it?

referrer-policy headers, and appending a du= mmy fragment on error redirects -

<= /div>
Can you please explain how this protects from open redirec= tion?=C2=A0

=
that can protect against the more serious redirection issues without -= security-topics trying to introduce normative breaking changes to the behav= ior from the original OAuth 2.0 Authorization Framework.=C2=A0
<= /div>


Perhaps there are some error cases n= ot mentioned in RFC 6749 where returning an HTTP error code to the browser = would be better or more appropriate than redirecting back to the OAuth clie= nt (my opinion on this has gone in circles and I'm honestly not sure an= ymore). But saying that authorization requests never automatically redirect= back to the client's redirect URI is excessive.
<= /blockquote>

Probably. Let=E2=80=99s discuss in detail= .=C2=A0

I think the AS should not automatically re= direct the user in case of the following error conditions because an attack= er could cause this errors via request parameters or its configuration:
-=C2=A0unsupported_response_type
-=C2=A0invalid_scope
-=C2=A0unauthorized_client
-=C2=A0invalid_request

kind regards,
Torsten.=C2=A0



On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <= travis.spencer@curity.io> wrote:
I read through this doc and would like to share a bit of feedback in<= br> hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
=C2=A0 =C2=A0 - No mention of frame breaking scripts for non-CSP aware user= agents
=C2=A0 =C2=A0 -=C2=A0 No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
=C2=A0 =C2=A0- Despite what it says in section 1.7 of RFC 6749, many people=
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
cl= ient.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuf= f
including other specs! I don't think that's warranted, and I am not=
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <joseph@authlete.com> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server a= s Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope=
> errors must not redirect back to the client's registered redirect = uri.
>
> https://tools.ietf.org/html/rfc6749#sec= tion-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I underst= and to
> block the attack fully we need 'must not redirect's for all th= e kinds of
> error that could cause an automatic redirect back to the client's = registered
> redirect uri without any user interaction - 'unauthorized_client&#= 39; and
> 'unsupported_response_type' seem to fall into that category. &= #39;server_error'
> also seems dodgy (I would wager that on some servers that are known wa= ys to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> _________= ______________________________________
> 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 contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited..=C2=A0 If you have received this communication in error, plea= se notify the sender immediately by e-mail and delete the message and any f= ile attachments from your computer. Thank you.___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
http= s://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. --0000000000000eaf240567e7428e-- From nobody Wed Mar 21 04:29:07 2018 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 B587A12D7F8 for ; Wed, 21 Mar 2018 04:29:05 -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, 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=curity-io.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 pAK5GAjAj3l3 for ; Wed, 21 Mar 2018 04:29:04 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 6365C1242F7 for ; Wed, 21 Mar 2018 04:29:04 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id c12-v6so3985281oic.7 for ; Wed, 21 Mar 2018 04:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q9VKghtSKHfMAUetklv0HmabLpzWmamUUu/uHUrTnso=; b=nQ+3Ee9BgUxKnbiM47CCpmmHJk+wuBcKVphDl4gO9FtQuCpLVWuk1smeQlYNYqQiiW APOq4EGW2oWk6M2X5FYDPilwMVz+0bShq5GZqEs5huZw+27fZulDfDbTmy5MAWenJUbU OJvRaoeP9cInvp9haFav3r/97rUx6/TMpAcsdMj4uvqQWy+c1cvpwbL/qc9k3RbcX6bG w6X2IVbQQ2nBVoorcLlTJJjiuJLx5K1OOOFTGK3sM9MaedBs3lK8R43ZLAGUTbeDSjZQ KaTwReoLOejqAFpCrwJYpL8o+1EXKM9iMhAJVIpQH1pJ5BTGHjj+9uyCkpz3NEw4TsXu EZoA== 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=q9VKghtSKHfMAUetklv0HmabLpzWmamUUu/uHUrTnso=; b=hhKwWsVv9aoiZJYOGZifQhfNwYQgz1/GLtU3dQhZeBpfAaWYERTYnp0U8cqfDDCwsJ w0+TfJTJlVojK1fFyKtJ/ULSAooorwFFqCg9IlB7zgyx6kb84dxs+ajxb+sn6uORhA6Q ZKWymm1RW9zKw/88Y5GvDxZZ46uw30bQ6npNDMnDFYiCdqS0x1WFW0vPuHVUJUitzpFo vWmpQoGTpGVj1ldOHW50+Ie9c+unkwqvN4sPH+8MOjdoK2CNBVKxZQnwd2OE28siCINC tUyi64q9wwlFGLO6srhT26bSwek0m3cYvU7qTI//UalHKujwKSWQhhxU6EIb1YQhu3Nu fQCA== X-Gm-Message-State: AElRT7G3W3yU27WmRiVnnI0dSjhMAQXixkIphU4tR2sWKKhiy6YvK7cH +5d2YogAKwnybeM7shlRJXYRm7dR0yLRxFZPsIRxbA== X-Google-Smtp-Source: AG47ELu4mNy1UY0EGInWxIMmIefnv1ZE71l4a5ZT6RQlI6B9s3K+SPrWRXWZYqiCgkXU2PYrvlOg9p+3z+UVLTzii2Y= X-Received: by 10.202.104.170 with SMTP id o42mr8460651oik.296.1521631743897; Wed, 21 Mar 2018 04:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.70.193 with HTTP; Wed, 21 Mar 2018 04:28:43 -0700 (PDT) In-Reply-To: References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> From: Travis Spencer Date: Wed, 21 Mar 2018 12:28:43 +0100 Message-ID: To: Brian Campbell Cc: Torsten Lodderstedt , oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Wed, 21 Mar 2018 11:29:06 -0000 On Wed, Mar 21, 2018 at 8:36 AM, Brian Campbell wrote: > Doing redirection in error conditions relates to OpenID Connect flows too. Also Mobile Connect. Those folks will be very upset by this change, I'm sure. From nobody Wed Mar 21 05:51:09 2018 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 9C7E212DA1C for ; Wed, 21 Mar 2018 05:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.369 X-Spam-Level: **** X-Spam-Status: No, score=4.369 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 w7GakC7JjEuX for ; Wed, 21 Mar 2018 05:51:06 -0700 (PDT) Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [37.140.190.182]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092EA127522 for ; Wed, 21 Mar 2018 05:51:06 -0700 (PDT) Received: from mxback15g.mail.yandex.net (mxback15g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:94]) by forward102o.mail.yandex.net (Yandex) with ESMTP id 97CF25A030EA; Wed, 21 Mar 2018 15:51:03 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback15g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Hen90Wdj94-p1DCf85C; Wed, 21 Mar 2018 15:51:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1521636662; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=From:To:Message-Id:Date; b=HYZOOOHDwHqQcgI9fvXhjfGHpmvq7DWZicsMxPG7XQoH2+0sYMEHjhnQK+0yqP7CX +dgyYO1rkXPUH67MFUpQJihPXiR9075l+xNkIy+2ttRsKMCJyugwLXriZaz3x9KEXR 3kG6ioMDg+Tbae+JwkAlqIjBaT2+tgS6l4nD3eGU= Authentication-Results: mxback15g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web10j.yandex.ru with HTTP; Wed, 21 Mar 2018 15:51:01 +0300 From: =?utf-8?B?0JLQu9Cw0LTQuNC80LjRgCDQmtGA0LDQstGH0YPQug==?= To: oauth@ietf.org, Mail Delivery Subsystem MIME-Version: 1.0 Message-Id: <3885391521636661@web10j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 21 Mar 2018 15:51:01 +0300 Content-Type: text/plain Archived-At: Subject: [OAUTH-WG] (no subject) 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, 21 Mar 2018 12:51:08 -0000 From nobody Wed Mar 21 07:36:48 2018 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 41CC912DA6D; Wed, 21 Mar 2018 07:36:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.76.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, oauth@ietf.org, draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig , Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152164300026.7507.13873266401942906419.idtracker@ietfa.amsl.com> Date: Wed, 21 Mar 2018 07:36:40 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Authorization Server Metadata' to Proposed Standard (draft-ietf-oauth-discovery-10.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: Wed, 21 Mar 2018 14:36:40 -0000 The IESG has approved the following document: - 'OAuth 2.0 Authorization Server Metadata' (draft-ietf-oauth-discovery-10.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ Technical Summary This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. Working Group Summary Work on a discovery mechanism for OAuth was planned since a long time but it took till late 2015 before a document was submitted to the group, which re-used work done in the OpenID Foundation. When the WGLC was started in 2016, see https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html, feedback resulted in refocusing the scope of the specification, removing everything except for the authorization server metadata. Now, almost a year later these concerns have been resolved and the document is ready for publication. Document Quality The document scope has been changed to capture current deployment practice. There are 34 authorization server and 9 OAuth client implementations listed at http://openid.net/certification/ that implement metadata compatible with the AS metadata specification. (See the "Config OP" and "Config RP" columns.) Microsoft and Google are using this specification in deployment. Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Eric Rescorla. From nobody Wed Mar 21 12:34:46 2018 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 C3C9E12785F for ; Wed, 21 Mar 2018 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 92i-h-bzVFxv for ; Wed, 21 Mar 2018 12:34:41 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 E9685127369 for ; Wed, 21 Mar 2018 12:34:40 -0700 (PDT) Received: from [31.133.150.105] (helo=dhcp-9669.meeting.ietf.org) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1eyjVN-0006cx-GZ; Wed, 21 Mar 2018 20:34:37 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8DEBBCD5-9AB5-49C9-9F5C-0937FBAC7902"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 19:34:33 +0000 In-Reply-To: To: oauth References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Wed, 21 Mar 2018 19:34:45 -0000 --Apple-Mail=_8DEBBCD5-9AB5-49C9-9F5C-0937FBAC7902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, thanks for your feedback. Here is my text proposal for section 3.8.1.=20 =E2=80=94=E2=80=94 Attackers could try to utilize a user's trust in the authorization server (and its URL in particular) for performing phishing attacks.=20= RFC 6749 already prevents open redirects by stating the AS MUST NOT automatically redirect the user agent in case=20 of an invalid combination of client_id and redirect_uri. =20 However, as described in [I-D.ietf-oauth-closing-redirectors], an attacker could also utilize a correctly registered redirect URI to=20 perform phishing attacks. It could for example register a client via dynamic client registration and intentionally send an=20 erroneous authorization request, e.g. by using an invalid=20 scope value, to cause the AS to automatically redirect the user agent to its phishing site.=20 The AS MUST take precautions to prevent this threat.=20 Based on its risk assessment the AS needs to decide whether=20 it can trust the redirect URI or not and should only automatically=20 redirect the user agent, if it trusts the redirect URI. If not, it could inform the user that it is about to redirect her to the another site=20 and rely on the user to decide or just inform the user about the=20 error.=20 =E2=80=94=E2=80=94 kind regards, Torsten.=20 =20 --Apple-Mail=_8DEBBCD5-9AB5-49C9-9F5C-0937FBAC7902 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzIxMTkzNDM0WjAjBgkqhkiG9w0BCQQxFgQUiXAeOdsI4XEb XaIagRjqWl5m9ZAwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAEbtbe1HAiJt8tTIUzvrswCwocQM2Az8ujnJby7v48Lwqgmrss9S Fn5V2qOpcfVLcO2F5F+kq5xuzEDqh1v5CMZtO8sJdmlqfqcJT2biNWFjSLi9W4Dil85e9ayAM0fo w69OqtjYtqlIwK5IVoZLJ/7gDyXCMDl6ml/i0w50n/29EBttfxV/aQig5Uj/dTbaT/sqG7Ahoo9D LfWR1NfgkpIcSSDBpfsH4UTGhAzHm4A4pBZng3llIf/2/swtfnmWvpvibgvHELj9hf1IA9N71zAR zp9q6ftzR6mMMh0vedx0mA2ZVCe8eHSL6tb4vdfJlw34TR8ioYDv/el5geOWZh4AAAAAAAA= --Apple-Mail=_8DEBBCD5-9AB5-49C9-9F5C-0937FBAC7902-- From nobody Thu Mar 22 01:17:09 2018 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 8FB88120454 for ; Thu, 22 Mar 2018 01:17:07 -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, 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 QW7swL_Iic2U for ; Thu, 22 Mar 2018 01:17:01 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 02EDD1243F3 for ; Thu, 22 Mar 2018 01:17:01 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id z7-v6so1093399iti.1 for ; Thu, 22 Mar 2018 01:17:00 -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=G1nYJS0r5YupAoEoHCZad2Qz0Pz9LP+ti/2veRI/iME=; b=B2Bh3Nbcb6lT+DLdGqJHs7YwtmuSI7SJm2MHdZikbBMUYNY9GVTPfKQQvNyeYuX7yJ ftw+jLTA1DEv9UpcJqSLDyov3/edNcH9vXT96D89KL7w4Do0JyI5XUzMuOoa25FSshdk N+2BxmzO8MyqyXnyquFa2l0sSKluzVlvuzChY= 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=G1nYJS0r5YupAoEoHCZad2Qz0Pz9LP+ti/2veRI/iME=; b=fq3nDi9iYc3orTDe8Fxzf1bgIDI06NWmCktDZTZ6xFjaaTXmvV1O7RcBslOVPn4Cd5 jwi5e34im8SXLP2zJaTnm+GbHR7TAW/n9PLRFGpYiWsWyggb0IeYWRn8bw6p1y/+W2nG eP+0DbFsrHEVeoCDXzsT9oOMsaE0CMYHrU+okZjjZdBcugeVmBMdC2fPhdBRZxXQKpKX +eFy5t1L8iFtXAWZ1Q5kHCkqowLnSRPzNyj40VtwDGkxIwqtTWB/H6jh00kt5Pfo1qf8 X/dCBi62W7FWOphUSWiekcMlihRQt3t9+lwa/KhYkMMj+GNNwzipqMbvPHCO7XDJGmHA oBfw== X-Gm-Message-State: AElRT7GryLVhkem/DrIIfxjQOclRZJ+YPb8LVcMbfwsJJyMjwewYX5Qk DQ/WGEUVb1X5DgxOLUIYzi7HSHN8HDSAohE8ietN1CVZEwT9XvDhpPpibUWD//YPO89i2r3r2Xt yYTRVfX+y5SohQmeu X-Google-Smtp-Source: AG47ELuxjD307YhkiSmNvhg1MCdqgeSUyKbyiCrt5p6ysKoFy9mssWprWnM1dsUWUUlp8QNoczmF7rLVGF3i4ANpL4w= X-Received: by 2002:a24:e4c2:: with SMTP id o185-v6mr7667745ith.37.1521706620249; Thu, 22 Mar 2018 01:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Thu, 22 Mar 2018 01:16:29 -0700 (PDT) In-Reply-To: References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> From: Brian Campbell Date: Thu, 22 Mar 2018 08:16:29 +0000 Message-ID: To: Torsten Lodderstedt Cc: oauth , Travis Spencer Content-Type: multipart/alternative; boundary="0000000000008d84840567fbee48" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Thu, 22 Mar 2018 08:17:07 -0000 --0000000000008d84840567fbee48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That works for me On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > thanks for your feedback. Here is my text proposal for section 3.8.1. > > =E2=80=94=E2=80=94 > > Attackers could try to utilize a user's trust in the authorization > server (and its URL in particular) for performing phishing attacks. > > RFC 6749 already prevents open redirects by stating the AS > MUST NOT automatically redirect the user agent in case > of an invalid combination of client_id and redirect_uri. > > However, as described in [I-D.ietf-oauth-closing-redirectors], an > attacker could also utilize a correctly registered redirect URI to > perform phishing attacks. It could for example register a client > via dynamic client registration and intentionally send an > erroneous authorization request, e.g. by using an invalid > scope value, to cause the AS to automatically redirect the user > agent to its phishing site. > > The AS MUST take precautions to prevent this threat. > Based on its risk assessment the AS needs to decide whether > it can trust the redirect URI or not and should only automatically > redirect the user agent, if it trusts the redirect URI. If not, it could > inform the user that it is about to redirect her to the another site > and rely on the user to decide or just inform the user about the > error. > > =E2=80=94=E2=80=94 > > kind regards, > Torsten. > > > --=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.* --0000000000008d84840567fbee48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me

=
On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodders= tedt <torsten@lodderstedt.net> wrote:
Hi all,

thanks for your feedback. Here is my text proposal for section 3.8.1.

=E2=80=94=E2=80=94

Attackers could try to utilize a user's trust in the authorization
=C2=A0 =C2=A0server (and its URL in particular) for performing phishing att= acks.

RFC 6749 already prevents open redirects by stating the AS
MUST NOT automatically redirect the user agent in case
of an invalid combination of client_id and redirect_uri.

However, as described in [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect URI to
perform phishing attacks. It could for example register a client
via dynamic client registration and intentionally send an
erroneous authorization request, e.g. by using an invalid
scope value, to cause the AS to automatically redirect the user
agent to its phishing site.

The AS MUST take precautions to prevent this threat.
Based on its risk assessment the AS needs to decide whether
it can trust the redirect URI or not and should only automatically
redirect the user agent, if it trusts the redirect URI. If not, it could inform the user that it is about to redirect her to the another site
and rely on the user to decide or just inform the user about the
error.

=E2=80=94=E2=80=94

kind regards,
Torsten.




<= 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. --0000000000008d84840567fbee48-- From nobody Thu Mar 22 02:52:19 2018 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 B6457126C19 for ; Thu, 22 Mar 2018 02:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 8WjHXmPBsDAY for ; Thu, 22 Mar 2018 02:52:16 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 84A831205D3 for ; Thu, 22 Mar 2018 02:52:13 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2M9itmj056476 for ; Thu, 22 Mar 2018 09:52:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2017-10-26; bh=Drcrr9szsMIXdxyrBXzGRWWb4Oqy1ft6PL/ca6N0ZjI=; b=o+o6SHNGi9XGuWN4TZUgzKqSzC44qYKeWPk7NNZbfjZ3N3xBh/qtDYXePWES2faPUEwZ AVmd2dCoC7d52fuuF5luVQ1G9hAjgUCESH5yJGE7oGuBkV49hUpavBccgkiLA7SKkJ8F B9KQWdojYsmhWJBpeLyWaBxzkGd6PbcyeIskgVqhS2BQCXKw4wBHi0OcPEVEdR0hECce Bwa+0CYdGOZgboxjCr6xSp8lYsj0qvE4LYJMuZRbpeinoPCHnCRUpBxBwFpejDRHpygE 2jJYWZo+yBlEBhwSSRy/FS6a0NfK5NFk4D8/s9EBzmLxzPC3DL2/2zePx73VSZyEkgNP ig== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2gva3mr17u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Mar 2018 09:52:12 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2M9qBkQ032165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Mar 2018 09:52:11 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2M9qBwi001271 for ; Thu, 22 Mar 2018 09:52:11 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2018 02:52:11 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D251A6B3-AF70-4B36-B9A6-1ED2C359A6E2" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <261C62EA-2327-4EF5-8585-542AA7672893@oracle.com> Date: Thu, 22 Mar 2018 09:52:08 +0000 To: OAuth WG X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8839 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05 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, 22 Mar 2018 09:52:18 -0000 --Apple-Mail=_D251A6B3-AF70-4B36-B9A6-1ED2C359A6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Torsten, Great document! Some minor nits and comments: Abstract - double period after first sentence. > It updates and extends the OAuth 2.0 Security Threat Model to > incorporate practical experiences gathered since OAuth 2.0 was > published and cover new threats relevant due to the broader > application of OAuth 2.0. When I first read, it sounds like this is a replacement for the threat = model or at least could be read that way. I think you mean readers still = need to read 6819. How about... "This specification uses the OAuth 2.0 Security Threat Model and = supplements it to incorporate practical experiences gathered"... Section 1. The paragraph starting =E2=80=9COAuth initially assumed a static=E2=80=A6=E2= =80=9D appears to continue the previous bullet point. Should the = paragraph be indented? Last paragraph 3.1.1 > This kind of injections is covered in > Section Code Injection. Should this say Section 3.5? Section 3.1.5 This paragraph seems unfinished... >=20 > Question: Does redirect uri validation solve any problem for > native apps? Effective against impersonation when used in > conjunction with claimed HTTPS redirect URIs only. > For Windows token broker exact redirect URI matching is = important > as the redirect URI encodes the app identity. For custom scheme > redirects there is a question however it is probably a useful = part > of defense in depth. Section 3.4 > AS returns client_id and its iss in the response. Client compares > this data to AS it believed it sent the user agent to. =E2=80=9Cclient_id=E2=80=9D and =E2=80=9Ciss=E2=80=9D attributes do not = appear to have any marking () in = multiple locations in the document. Section 3.5 > How does an attack look like? How about: "An attack looks like:=E2=80=9D Writing style of the following comment seems like an editors note rather = than a comment for the reader. Rephrase? > But this approach conflicts with the idea to enforce exact redirect > URI matching at the authorization endpoint. Moreover, it has been > observed that providers very often ignore the redirect_uri check > requirement at this stage, maybe, because it doesn't seem to be > security-critical from reading the spec. Is this appropriate for a BCP (seems like a WG discussion item)? > The authors therefore propose to the working group to drop this > feature in favor of more effective and (hopefully) simpler = approaches > to code injection prevention as described in the following section. Section 3.5.1 This seems a bit tentatively worded=E2=80=A6 > PKCE seem to be the most obvious solution for OAuth clients as it > available and effectively used today for similar purposes for OAuth > native apps whereas "nonce" is appropriate for OpenId Connect > clients. Formatting problem (missing line between paragraphs)? > Note on pre-warmed secrets: An attacker can circumvent the > countermeasures described above if he is able to create or capture > the respective secret or code_challenge on a device under his > control, which is then used in the victim's authorization request. > Exact redirect URI matching of authorization requests can prevent = the > attacker from using the pre-warmed secret in the faked = authorization > transaction on the victim's device. > Unfortunately it does not work for all kinds of OAuth clients. It = is > effective for web and JS apps and for native apps with claimed = URLs. > Attacks on native apps using custom schemes or redirect URIs on > localhost cannot be prevented this way, except if the AS enforces > one-time use for PKCE verifier or Nonce values. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_D251A6B3-AF70-4B36-B9A6-1ED2C359A6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Torsten,

Great document!

Some minor nits and comments:

Abstract - double period after first = sentence.

It =
updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and cover new threats relevant due to the broader
   application of OAuth 2.0.

When I first read, it sounds like = this is a replacement for the threat model or at least could be read = that way. I think you mean readers still need to read 6819. How = about...

"This = specification uses the OAuth 2.0 Security Threat Model and supplements = it to incorporate practical experiences gathered"...

Section 1.

The paragraph starting = =E2=80=9COAuth initially assumed a static=E2=80=A6=E2=80=9D appears to = continue the previous bullet point.  Should the paragraph be = indented?

Last = paragraph 3.1.1
This kind of injections is covered in
   Section Code Injection.

Should this say Section = 3.5?

Section = 3.1.5
This paragraph seems unfinished...

 Question: Does redirect =
uri validation solve any problem for
      native apps?  Effective against impersonation when used in
      conjunction with claimed HTTPS redirect URIs only.
      For Windows token broker exact redirect URI matching is important
      as the redirect URI encodes the app identity.  For custom scheme
      redirects there is a question however it is probably a useful part
      of defense in depth.

Section 3.4
AS returns client_id and its =
iss in the response.  Client compares
      this data to AS it believed it sent the user agent =
to.
=E2=80=9Cclient_id=E2=80=9D and = =E2=80=9Ciss=E2=80=9D attributes do not appear to have any marking = (<spanx style=3D=E2=80=9Cverb=E2=80=9D>) in multiple locations in = the document.

Section 3.5
How does an attack look like?
How= about:
"An attack looks like:=E2=80=9D

Writing style of the = following comment seems like an editors note rather than a comment for = the reader.  Rephrase?

   But this approach conflicts =
with the idea to enforce exact redirect
   URI matching at the authorization endpoint.  Moreover, it has been
   observed that providers very often ignore the redirect_uri check
   requirement at this stage, maybe, because it doesn't seem to be
   security-critical from reading the spec.

Is this = appropriate for a BCP (seems like a WG discussion item)?
   The authors therefore =
propose to the working group to drop this
   feature in favor of more effective and (hopefully) simpler approaches
   to code injection prevention as described in the following =
section.

Section 3.5.1

This seems a bit tentatively worded=E2=80=A6
   PKCE seem to be the most =
obvious solution for OAuth clients as it
   available and effectively used today for similar purposes for OAuth
   native apps whereas "nonce" is appropriate for OpenId Connect
   clients.

Formatting problem (missing line = between paragraphs)?
   Note on pre-warmed secrets: An attacker can circumvent the
   countermeasures described above if he is able to create or capture
   the respective secret or code_challenge on a device under his
   control, which is then used in the victim's authorization request.
   Exact redirect URI matching of authorization requests can prevent the
   attacker from using the pre-warmed secret in the faked authorization
   transaction on the victim's device.
   Unfortunately it does not work for all kinds of OAuth clients.  It is
   effective for web and JS apps and for native apps with claimed URLs.
   Attacks on native apps using custom schemes or redirect URIs on
   localhost cannot be prevented this way, except if the AS enforces
   one-time use for PKCE verifier or Nonce values.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_D251A6B3-AF70-4B36-B9A6-1ED2C359A6E2-- From nobody Thu Mar 22 07:16:29 2018 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 1D43A124319 for ; Thu, 22 Mar 2018 07:16:28 -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, RCVD_IN_MSPIKE_H2=-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 eWRMPwmnIhw0 for ; Thu, 22 Mar 2018 07:16:25 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0115.outbound.protection.outlook.com [104.47.37.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9F61200C5 for ; Thu, 22 Mar 2018 07:16:25 -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=nqMUCnEN8tAUJ72emhkmsna3A8X7xUxKGP60vAKPbQc=; b=RPJs6PgCPTDiXL5RIne8POLPfSaZ2SqeDgeQsursFLOBIBXlhr7rri9Kg3KVMXsXeNGLbJfdOyi1Zh1JtdEDsPeSeGdX8+J+sBt+WOauI66AumAVVGNfMCLGD8w5Kl4K9R6SKZpjrOx7d2NYpBOf1yrpy62h3+bqtiqz3a/zMU0= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (52.132.128.37) by DM5PR00MB0440.namprd00.prod.outlook.com (52.132.129.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Thu, 22 Mar 2018 14:16:04 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::4505:9110:25d:a5e0]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::4505:9110:25d:a5e0%2]) with mapi id 15.20.0652.000; Thu, 22 Mar 2018 14:16:04 +0000 From: Mike Jones To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing Thread-Index: AdL0+iJmgqpM9UqbSgCDmYr6GQRcNAABbcaAAnio3wAwwVS0oA== Date: Thu, 22 Mar 2018 14:16:04 +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: x-originating-ip: [31.133.132.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0440; 7:m1PNl3r97LVtTlgKFRZYiHGAsZVmbZ4PdP+Zbn7vYrY14vzIiNm3sXfDk5XngFdTL3CpOKhA5ppUgrMwff2iydG0G1Qm7K9acACjuUbunwHIBnITVbl3XrxT8FbMiG74jk83tGEuq0rOxNko5zMTIarb5x0Kc1z68rN8Cbwe22/jcVx2jNDKu+T7ZetdEUAkG3UIFCoDn4gjXLqMjg0rmSbQNAkMdwhi56VFbuNXRE3tfid3etD8/BJGbSjPNUEK; 20:SrJfzcPrt7WJwU5kAT9VE54W/wquBJZJt6mYmJXRrlqbh2xoZZ8wCCekIGbHYSn0f1ZbWMPLd7pjwWLHNRi3BQN+4K2ZpAqflK5lc86hF74MqObG0319zq6g6DhMbH70RU+xk1sKgDn/foLTCxvgrr5ub5gGlrP+NZFIwz2JuBE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4404fa96-edbe-4917-0331-08d58fff72c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0440; x-ms-traffictypediagnostic: DM5PR00MB0440: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(192374486261705)(31418570063057)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0440; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0440; x-forefront-prvs: 0619D53754 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39380400002)(396003)(39860400002)(209900001)(199004)(189003)(36304003)(5890100001)(106356001)(5250100002)(99286004)(2906002)(33656002)(66066001)(3280700002)(105586002)(790700001)(6116002)(3846002)(22452003)(26005)(316002)(68736007)(102836004)(6346003)(59450400001)(53546011)(19609705001)(6506007)(186003)(7736002)(229853002)(74316002)(2900100001)(72206003)(966005)(5660300001)(478600001)(4326008)(25786009)(10290500003)(2950100002)(6916009)(97736004)(8676002)(446003)(81156014)(81166006)(8936002)(10090500001)(606006)(14454004)(8990500004)(86362001)(7696005)(3660700001)(76176011)(53376002)(53936002)(6246003)(236005)(86612001)(55016002)(6306002)(54896002)(9686003)(6436002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0440; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: 4P7A30Ass1XXw3NdJShLxPfzW7M1ISLHRKLFpoahaeK4VEYkR5CxodMPccVnfSB9HnKndEWESpvGkBK77j3xsazc/B9SDD5+S7I2eqfRTn0oyOzIqMdZwAsWGdcJzskj/l3uSQqfOxc/e45ZCNgh1j/mwC0MV3ABQJ+YZKsBmDmP8D+flONEm8VWB/cn/+6+jehKSnsKdTJ9msebCQ3KX9g4w8jHcdL+3faMRxVuzhNGpTdMXeVF68hNa7ULUXRR2QPDWOjY55smyFNQf+XxeBKVavQGLTK+DoQ1fTH4HIxlmlvfUt3dNmYRYpMEktEVm0lBt2JI2WQjldG2wYLlUA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296D7E956944A0CBF148D7AF5A90DM5PR00MB0296namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4404fa96-edbe-4917-0331-08d58fff72c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 14:16:04.5596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0440 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: Thu, 22 Mar 2018 14:16:28 -0000 --_000_DM5PR00MB0296D7E956944A0CBF148D7AF5A90DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcm9wb3NlIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGJlIGFkZGVkIHRvIGFkZHJlc3MgeW91 ciBjb21tZW50LCBCcmlhbi4gIERvZXMgdGhpcyB0ZXh0IHdvcmsgZm9yIHlvdT8NCg0KV2hlbiBh cHBseWluZyBleHBsaWNpdCB0eXBpbmcgdG8gYSBOZXN0ZWQgSldULCB0aGUgInR5cCIgaGVhZGVy IHBhcmFtZXRlciBjb250YWluaW5nIHRoZSBleHBsaWNpdCB0eXBlIHZhbHVlIE1VU1QgYmUgcHJl c2VudCBpbiB0aGUgaW5uZXIgSldUIG9mIHRoZSBOZXN0ZWQgSldUICh0aGUgSldUIHdob3NlIHBh eWxvYWQgaXMgdGhlIEpXVCBDbGFpbXMgU2V0KS4gIFRoZSBzYW1lICJ0eXAiIGhlYWRlciBwYXJh bWV0ZXIgdmFsdWUgTUFZIGJlIHByZXNlbnQgaW4gdGhlIG91dGVyIEpXVCBhcyB3ZWxsLCB0byBl eHBsaWNpdGx5IHR5cGUgdGhlIGVudGlyZSBOZXN0ZWQgSldULg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+DQpTZW50OiBNb25kYXks IEp1bHkgMTcsIDIwMTcgMTA6NTMgQU0NClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBv cmFjbGUuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47 IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBKU09OIFdlYiBUb2tlbiBC ZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRyYWZ0IGRlc2NyaWJpbmcgRXhwbGljaXQgVHlwaW5nDQoN CkNvdWxkIHNvbWUgbW9yZSBndWlkYW5jZSBiZSBwcm92aWRlZCBhcm91bmQgaG93IHRvIHVzZSB0 aGUgZXhwbGljaXQgdHlwaW5nIHdpdGggbmVzdGVkIEpXVHM/DQpJJ2QgaW1hZ2luZSB0aGF0IHRo ZSAidHlwIiBoZWFkZXIgc2hvdWxkIGJlIGluIHRoZSBoZWFkZXIgb2YgdGhlIEpXVCB0aGF0IGlz IGludGVncml0eSBwcm90ZWN0ZWQgYnkgdGhlIGlzc3Vlcj8NCg0KT24gVHVlLCBKdWwgNCwgMjAx NyBhdCA5OjU4IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzENCg0KVGhhbmtzIE1pa2UuDQoNClBo aWwNCg0KT24gSnVsIDQsIDIwMTcsIGF0IDEyOjQzIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KVGhlIEpXVCBCQ1AgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCB0byBkZXNjcmliZSB0aGUg dXNlIG9mIGV4cGxpY2l0IHR5cGluZyBvZiBKV1RzIGFzIG9uZSBvZiB0aGUgd2F5cyB0byBwcmV2 ZW50IGNvbmZ1c2lvbiBhbW9uZyBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4gIFRoaXMgaXMgYWNj b21wbGlzaGVkIGJ5IGluY2x1ZGluZyBhbiBleHBsaWNpdCB0eXBlIGZvciB0aGUgSldUIGluIHRo ZSDigJx0eXDigJ0gaGVhZGVyIHBhcmFtZXRlci4gIEZvciBpbnN0YW5jZSwgdGhlIFNlY3VyaXR5 IEV2ZW50IFRva2VuIChTRVQpIHNwZWNpZmljYXRpb248aHR0cDovL3NlbGYtaXNzdWVkLmluZm8v P3A9MTcwOT4gbm93IHVzZXMgdGhlIOKAnGFwcGxpY2F0aW9uL3NlY2V2ZW50K2p3dOKAnSBjb250 ZW50IHR5cGUgdG8gZXhwbGljaXRseSB0eXBlIFNFVHMuDQoNClRoZSBzcGVjaWZpY2F0aW9uIGlz IGF2YWlsYWJsZSBhdDoNCg0KICAqICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNoZWZmZXItb2F1dGgtand0LWJjcC0wMQ0KDQpBbiBIVE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlz IGFsc28gYXZhaWxhYmxlIGF0Og0KDQogICogICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2Nz L2RyYWZ0LXNoZWZmZXItb2F1dGgtand0LWJjcC0wMS5odG1sDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNClAuUy4gIFRo aXMgbm90aWNlIHdhcyBhbHNvIHBvc3RlZCBhdCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0x NzE0IGFuZCBhcyBAc2VsZmlzc3VlZDxodHRwczovL3R3aXR0ZXIuY29tL3NlbGZpc3N1ZWQ+Lg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Lg0K --_000_DM5PR00MB0296D7E956944A0CBF148D7AF5A90DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotYXBwbGUtc3lzdGVtOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjg1MDgwMzMxNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzQwMDcwNTY4O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTAyMDQ3MTUyNjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjEwNDkyMDMyNDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBw cm9wb3NlIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGJlIGFkZGVkIHRvIGFkZHJlc3MgeW91ciBj b21tZW50LCBCcmlhbi4mbmJzcDsgRG9lcyB0aGlzIHRleHQgd29yayBmb3IgeW91PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPldo ZW4gYXBwbHlpbmcgZXhwbGljaXQgdHlwaW5nIHRvIGEgTmVzdGVkIEpXVCwgdGhlICZxdW90O3R5 cCZxdW90OyBoZWFkZXIgcGFyYW1ldGVyIGNvbnRhaW5pbmcgdGhlIGV4cGxpY2l0IHR5cGUgdmFs dWUgTVVTVCBiZSBwcmVzZW50IGluIHRoZSBpbm5lciBKV1Qgb2YgdGhlIE5lc3RlZCBKV1QgKHRo ZSBKV1Qgd2hvc2UgcGF5bG9hZA0KIGlzIHRoZSBKV1QgQ2xhaW1zIFNldCkuJm5ic3A7IFRoZSBz YW1lICZxdW90O3R5cCZxdW90OyBoZWFkZXIgcGFyYW1ldGVyIHZhbHVlIE1BWSBiZSBwcmVzZW50 IGluIHRoZSBvdXRlciBKV1QgYXMgd2VsbCwgdG8gZXhwbGljaXRseSB0eXBlIHRoZSBlbnRpcmUg TmVzdGVkIEpXVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7IDxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTcsIDIwMTcgMTA6NTMgQU08YnI+DQo8Yj5U bzo8L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7 OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBKU09O IFdlYiBUb2tlbiBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRyYWZ0IGRlc2NyaWJpbmcgRXhwbGlj aXQgVHlwaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5Db3VsZCBzb21lIG1vcmUgZ3VpZGFuY2UgYmUgcHJvdmlkZWQg YXJvdW5kIGhvdyB0byB1c2UgdGhlIGV4cGxpY2l0IHR5cGluZyB3aXRoIG5lc3RlZCBKV1RzPw0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBpbWFnaW5l IHRoYXQgdGhlICZxdW90O3R5cCZxdW90OyBoZWFkZXIgc2hvdWxkIGJlIGluIHRoZSBoZWFkZXIg b2YgdGhlIEpXVCB0aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQgYnkgdGhlIGlzc3Vlcj8mbmJz cDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVl LCBKdWwgNCwgMjAxNyBhdCA5OjU4IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV8tNzk4MDYyMDY1NzMxNzQ5MzQ3NUFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ibV8tNzk4MDYyMDY1NzMxNzQ5MzQ3NUFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MgTWlrZS4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVsIDQsIDIwMTcsIGF0IDEyOjQz IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBKV1QgQkNQIGRyYWZ0IGhhcyBiZWVuIHVwZGF0ZWQgdG8gZGVz Y3JpYmUgdGhlIHVzZSBvZiBleHBsaWNpdCB0eXBpbmcgb2YgSldUcyBhcyBvbmUgb2YgdGhlIHdh eXMgdG8gcHJldmVudCBjb25mdXNpb24gYW1vbmcgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuJm5i c3A7IFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5DQogaW5jbHVkaW5nIGFuIGV4cGxpY2l0IHR5cGUg Zm9yIHRoZSBKV1QgaW4gdGhlIOKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+dHlwPC9zcGFuPuKAnSBoZWFkZXIgcGFyYW1ldGVyLiZuYnNwOyBGb3Ig aW5zdGFuY2UsIHRoZQ0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTcwOSIg dGFyZ2V0PSJfYmxhbmsiPlNlY3VyaXR5IEV2ZW50IFRva2VuIChTRVQpIHNwZWNpZmljYXRpb248 L2E+IG5vdyB1c2VzIHRoZSDigJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPmFwcGxpY2F0aW9uL3NlY2V2ZW50JiM0Mztqd3Q8L3NwYW4+4oCdIGNvbnRl bnQgdHlwZSB0byBleHBsaWNpdGx5IHR5cGUgU0VUcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZWZm ZXItb2F1dGgtand0LWJjcC0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zaGVmZmVyLW9hdXRoLWp3dC1iY3AtMDE8L2E+PG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BbiBIVE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZh aWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8YSBocmVmPSJodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LXNoZWZmZXItb2F1dGgtand0LWJjcC0wMS5odG1sIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1zaGVmZmVy LW9hdXRoLWp3dC1iY3AtMDEuaHRtbDwvYT48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5QLlMuJm5ic3A7IFRoaXMgbm90aWNlIHdhcyBhbHNvIHBv c3RlZCBhdA0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTcxNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE3MTQ8L2E+IGFuZCBhcw0KPGEg aHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIiB0YXJnZXQ9Il9ibGFuayI+QHNl bGZpc3N1ZWQ8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LWFwcGxlLXN5c3Rl bSZxdW90OyxzZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1 dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNw OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu ayB5b3UuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_DM5PR00MB0296D7E956944A0CBF148D7AF5A90DM5PR00MB0296namp_-- From nobody Thu Mar 22 07:36:38 2018 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 8D7C4127078 for ; Thu, 22 Mar 2018 07:36:36 -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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 pM-8QhEVw0pX for ; Thu, 22 Mar 2018 07:36:34 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 65600126DFB for ; Thu, 22 Mar 2018 07:36:34 -0700 (PDT) X-AuditID: 1209190d-0bbff7000000431c-0a-5ab3bf701477 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 83.D1.17180.07FB3BA5; Thu, 22 Mar 2018 10:36:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w2MEaSxX016242; Thu, 22 Mar 2018 10:36:30 -0400 Received: from [10.209.230.205] (77-108-155-3.brightstar.limited [77.108.155.3] (may be forged)) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2MEaOV6023311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Mar 2018 10:36:26 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B33F2D-C2BB-4564-BFE0-379A6446DB29" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 22 Mar 2018 14:36:23 +0000 In-Reply-To: Cc: Torsten Lodderstadt , "" To: Brian Campbell References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixG6nrlu4f3OUwdIHEhar/99ktDj59hWb xatjT1kcmD2WLPnJ5HGsp5/V4+7RiywBzFFcNimpOZllqUX6dglcGYenrGcrOBFR8f7wAfYG xp8+XYycHBICJhKf535n72Lk4hASWMwk8e3tVTYIZyOjxI2OM1DOXSaJiwta2EFa2ARUJaav aWECsXkFrCQ2TPvDAmIzCyRJ3F50kwUibiLx/u1DsBphAW+Jed8fsIHYLEC9d/sagOIcHJwC gRIv7rOCmMwC8RJPD6qAVIgI6EvcfjoH6qDbLBJrLy5jhbhUSWL699tsExj5ZyHZNgvJNoi4 tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NE LzWldBMjKNg5JXl3MP6763WIUYCDUYmHNyNnU5QQa2JZcWXuIUZJDiYlUd5PL4BCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHjz126OEuJNSaysSi3Kh0lJc7AoifO6m2hHCQmkJ5akZqemFqQW wWRlODiUJHhn7gNqFCxKTU+tSMvMKUFIM3FwggznARp+GKSGt7ggMbc4Mx0if4rRnuPPw5dt zBxbHoHIA2DyxovXbcxCLHn5ealS4ryT9wK1CYC0ZZTmwU0GJTLfnNnMrxjFgR4V5n0NUsUD TIJws18BrWUCWps9cwPI2pJEhJRUA+P67JIVnKzR03ijoqelLVVyd9+q+d47WPgdv1mzmtBc 39UO1X2dl9bctTQud7mZwrZAjevg9ycTT3/elalz38/w5p3l/0+tWvHcMXTnsTs/MwSeCbM1 H5O36fIMrdvKuGTHenP1usCbk/Rn5652eNbIMJPLeNbish/8IQybrt08ortKqjxM7rASS3FG oqEWc1FxIgBmoXfyPwMAAA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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: Thu, 22 Mar 2018 14:36:36 -0000 --Apple-Mail=_E3B33F2D-C2BB-4564-BFE0-379A6446DB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I like the new text, it frames the error better and puts it in the = context where it=E2=80=99s likely to be exploited. IE, newly dynamically = registered clients shouldn=E2=80=99t be trusted as much as others. =E2=80=94 Justin > On Mar 22, 2018, at 8:16 AM, Brian Campbell = wrote: >=20 > That works for me >=20 > On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt = > wrote: > Hi all, >=20 > thanks for your feedback. Here is my text proposal for section 3.8.1. >=20 > =E2=80=94=E2=80=94 >=20 > Attackers could try to utilize a user's trust in the authorization > server (and its URL in particular) for performing phishing attacks. >=20 > RFC 6749 already prevents open redirects by stating the AS > MUST NOT automatically redirect the user agent in case > of an invalid combination of client_id and redirect_uri. >=20 > However, as described in [I-D.ietf-oauth-closing-redirectors], an > attacker could also utilize a correctly registered redirect URI to > perform phishing attacks. It could for example register a client > via dynamic client registration and intentionally send an > erroneous authorization request, e.g. by using an invalid > scope value, to cause the AS to automatically redirect the user > agent to its phishing site. >=20 > The AS MUST take precautions to prevent this threat. > Based on its risk assessment the AS needs to decide whether > it can trust the redirect URI or not and should only automatically > redirect the user agent, if it trusts the redirect URI. If not, it = could > inform the user that it is about to redirect her to the another site > and rely on the user to decide or just inform the user about the > error. >=20 > =E2=80=94=E2=80=94 >=20 > kind regards, > Torsten. >=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._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_E3B33F2D-C2BB-4564-BFE0-379A6446DB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = like the new text, it frames the error better and puts it in the context = where it=E2=80=99s likely to be exploited. IE, newly dynamically = registered clients shouldn=E2=80=99t be trusted as much as others.

 =E2=80=94 = Justin

On Mar 22, 2018, at 8:16 AM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

That works for me

On Wed, Mar 21, 2018 at 7:34 PM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

thanks for your feedback. Here is my text = proposal for section 3.8.1.

=E2=80=94=E2=80=94=

Attackers could try to utilize a user's = trust in the authorization
   server (and its = URL in particular) for performing phishing attacks.

RFC 6749 already prevents open redirects by stating the AS
MUST NOT automatically redirect the user agent in case
of an invalid combination of client_id and redirect_uri.

However, as described in = [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect = URI to
perform phishing attacks. It could for example = register a client
via dynamic client registration and = intentionally send an
erroneous authorization request, = e.g. by using an invalid
scope value, to cause the AS to = automatically redirect the user
agent to its phishing = site.

The AS MUST take precautions to = prevent this threat.
Based on its risk assessment the AS = needs to decide whether
it can trust the redirect URI or = not and should only automatically
redirect the user agent, = if it trusts the redirect URI. If not, it could
inform the = user that it is about to redirect her to the another site
and rely on the user to decide or just inform the user about = the
error.

=E2=80=94=E2=80=94
kind regards,
Torsten.




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=_E3B33F2D-C2BB-4564-BFE0-379A6446DB29-- From nobody Thu Mar 22 08:29:58 2018 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 87EA3126E64 for ; Thu, 22 Mar 2018 08:29:57 -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, 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 zBrAjhLaSx8n for ; Thu, 22 Mar 2018 08:29:53 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C0A12D871 for ; Thu, 22 Mar 2018 08:29:53 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id b136-v6so11854853iti.3 for ; Thu, 22 Mar 2018 08:29:53 -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=WbFdwQ0GpjZy+NFNiwekUmWd7TOuz9g5mwaa30ts9k8=; b=NQ1/mfyZVUwablMsgwH0vuaLWmkTShYHtX+eJ5nAI573nAKrKnD5G2bZV88cDXM2g8 e0lxhOw0WKDrfZk7ZF1Z2lWtAYxUG7EWdL12JHTNFqZ3CLRtOZZCj//kURCtX6hRlBuE JOlh1H0pUw2TMrLHzKpFLAWzNAzu/UaImYnh8= 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=WbFdwQ0GpjZy+NFNiwekUmWd7TOuz9g5mwaa30ts9k8=; b=Jf1aFCH2Jq4z1QyxauWt/VQyfXfU0Z9O/RY02GZbAdRWQB27qP8BWR6Gb4UFaWsHbe CLRUARJGUMErZXHG3ent+ZcDaSrxcYXTMM0wjkduPU8A8L6JzfLqFzC7X6l4SbOh25CZ 6TJDJwGJjus4IOuCo+BmpWylFc5qSX2+TX/0cOyTpCNZ+S7Vz7pYDjccDT5+stFv+sTF D2nnheY4s3oZ0aDllrg84+nkAXXyGBgRG32ozo/BP+nWwmAmy7YDtr2Cv6Vj+ieXohny XOG44b4CycqDYDroMtEcsAmlLiwlBY3vXX1nULDw9yJqALK0advMuDIVal0GBrC5AU8b ZSnA== X-Gm-Message-State: AElRT7ENMknjRGLDch3dMVTAfqXopvpz0ptWaMjL/uQjgFx8MkfFFRzb 6WK27T6DGaJl6wgEVf6QypSTZGmmzjOC2v8jd3Nnw3swjBbPShl6SJ50x1Bwoa59qojRDgAc5U6 xumNKmjCRa5nRIQ== X-Google-Smtp-Source: AG47ELtSfzhSO2SSOaPsBcepkHWJoiVrDiqJX5DNBNsxqDcOLNSK0lJNraRvWHFAIj+0JeCsuN15Pzywk4kghhdeO5w= X-Received: by 2002:a24:2f8d:: with SMTP id j135-v6mr9476556itj.53.1521732592128; Thu, 22 Mar 2018 08:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Thu, 22 Mar 2018 08:29:21 -0700 (PDT) In-Reply-To: References: <4524B6AF-E350-4D58-8ACC-1554D2506191@oracle.com> From: Brian Campbell Date: Thu, 22 Mar 2018 15:29:21 +0000 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000098f0c9056801faf5" 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: Thu, 22 Mar 2018 15:29:57 -0000 --00000000000098f0c9056801faf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I think that works. Thanks. On Thu, Mar 22, 2018 at 2:16 PM, Mike Jones wrote: > I propose that the following text be added to address your comment, > Brian. Does this text work for you? > > > > When applying explicit typing to a Nested JWT, the "typ" header parameter > containing the explicit type value MUST be present in the inner JWT of th= e > Nested JWT (the JWT whose payload is the JWT Claims Set). The same "typ" > header parameter value MAY be present in the outer JWT as well, to > explicitly type the entire Nested JWT. > > > > -- Mike > > > > *From:* Brian Campbell > *Sent:* Monday, July 17, 2017 10:53 AM > *To:* Phil Hunt (IDM) > *Cc:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] JSON Web Token Best Current Practices draft > describing Explicit Typing > > > > Could some more guidance be provided around how to use the explicit typin= g > 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 > > > > > *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.* --00000000000098f0c9056801faf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I think that works. Thanks.

On Thu, Mar 22, 2018 at 2:16 PM= , Mike Jones <Michael.Jones@microsoft.com> wrote:<= br>

I propose that the fol= lowing text be added to address your comment, Brian.=C2=A0 Does this text w= ork for you?

=C2=A0

When applying explicit typing to a Nested JWT, the "typ" hea= der parameter containing the explicit type value MUST be present in the inn= er JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set).=C2=A0 The same "typ" header parameter va= lue MAY be present in the outer JWT as well, to explicitly type the entire = Nested JWT.

=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

From: Brian Campbell <bcampbell@pingidentity.com&= gt;
Sent: Monday, July 17, 2017 10:53 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft = describing Explicit Typing

=C2=A0

Could some more guida= nce be provided around how to use the explicit typing with nested JWTs?

I'd imagine that the "typ" header shou= ld be in the header of the JWT that is integrity protected by the issuer?= =C2=A0

=C2=A0

On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) <= phil.hunt@oracle.= com> wrote:

+1

=C2=A0

Thanks Mike.=C2=A0

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 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 explicit type for the JWT in the =E2=80=9Ctyp=E2=80=9D header parameter.=C2= =A0 For instance, the Security Ev= ent Token (SET) specification now uses the =E2=80=9Capplication/secevent+jwt=E2=80=9D c= ontent type to explicitly type SETs.

=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
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIAL= ITY 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 prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents 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. --00000000000098f0c9056801faf5-- From nobody Thu Mar 22 09:27:11 2018 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 10068124B18 for ; Thu, 22 Mar 2018 09:27:10 -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 EApDbGILTRRC for ; Thu, 22 Mar 2018 09:27:08 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 076EC1200A0 for ; Thu, 22 Mar 2018 09:27:08 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id 108-v6so10101282otv.3 for ; Thu, 22 Mar 2018 09:27:07 -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=H3GOKZfQLJT4DHUQwps3ZLNrC8/UcsVlpa7HWX1gMlk=; b=mnVmr1+Jhec2YJLwKyfQX4KfclsAfNFvZDp1bzcfctQRtjZ8FGSYqLVKFPuxMaAQAy aJp2SzZHKKFDuZLZZhr0LOhFRQ+VJMtXkjKz/dIaZwrqcPmxFEWiK7aXdCPQUfmy9+bA isk5QDp38UbSX/bfqMNMt18l4mZbwey8BnqV4rNcMettJoK9ku/7l+7SCvEPA7Hx3TjA EFyzvtRxu1Z6h/EgoV1bv5qoA22g5xi8nzLGO3yS10UQ0aRrx1GSpSwejB5HypwA08mF djTY+4li4kYLaN8TjUbKcbCzs+6jByX/MdWzoFWiuDbvLof62WNcK/bhLVG+e6FV3pF8 QdxA== 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=H3GOKZfQLJT4DHUQwps3ZLNrC8/UcsVlpa7HWX1gMlk=; b=ULxKjDaK6m2YnV6LU1G2sRT5eQcngvOWuzF9dXxkwmQjbkMq47ANuRL1yos1bSwrY/ 5KwRKFHUOBkFIPdxfZX0XL6u0693Dt6bJI1/Dbn+FowBGUpT6pHO4iCmJlwPYvAVd2YZ ts9Q0y6YnW4UeUj/ae21zqb2SsYRwtRRkRcwmyT7QZ3n6uqVET5IRMzLWT9CH+G9GJPq PmbEcKxwOhBKYd8EB8obzJJNV+lySaxdsENAWlT6BBRSrA0tG4ZyKaq0ipYXxBkF+Y11 v2yXBrb6bYqYF+uQ2YPmQ6D3c7wZT3BGBpXXUSfvExfgu7QQTb50quLawjuPZJk5VnIg ZqjA== X-Gm-Message-State: AElRT7HCXfAWX1BgXPPtpYUS2CCtCOzNKX+h5CM/v8i4LTvSoHwcUZ2B FKgjBp1+WoZsjLdKpwbrKAnHV4LEmwFI3F4ZmvWmcjul X-Google-Smtp-Source: AG47ELsRe6vNErJeAHrPU2UnGGfyTSz0+bDkpIInZaKK9S1dSM+GiNRA5AXZ0klvz1WM1ep050fXlf4WBC/KIO+AkWk= X-Received: by 2002:a9d:923:: with SMTP id 32-v6mr15853419otp.225.1521736027081; Thu, 22 Mar 2018 09:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:518e:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 09:26:46 -0700 (PDT) From: Omer Levi Hevroni Date: Thu, 22 Mar 2018 18:26:46 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000561d16056802c7ab" Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Seamless Flow - first 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, 22 Mar 2018 16:27:10 -0000 --000000000000561d16056802c7ab Content-Type: text/plain; charset="UTF-8" Hey After presenting the flow yesterday, I've submitted the first draft: https://tools.ietf.org/html/draft-seamless-flow-00 I tried to answer all the question that raised during the session. Looking forward to hear your feedback. Omer --000000000000561d16056802c7ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey
After presenting the flow yesterday, I've subm= itted the first draft:
I tried to answer all the question that raised during the se= ssion.
Looking forward to hear your feedback.
Omer
--000000000000561d16056802c7ab-- From nobody Thu Mar 22 17:41:17 2018 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 07A27127137; Thu, 22 Mar 2018 17:41:10 -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.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152176566997.17675.7172691504392852817@ietfa.amsl.com> Date: Thu, 22 Mar 2018 17:41:10 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-01.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, 23 Mar 2018 00:41:10 -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-01.txt Pages : 12 Date : 2018-03-22 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-01 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 Mar 23 04:21:00 2018 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 1A22612D7E5 for ; Fri, 23 Mar 2018 04:20:59 -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=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 kO53oeDC0a0Q for ; Fri, 23 Mar 2018 04:20:57 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com [104.47.37.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD6712D86B for ; Fri, 23 Mar 2018 04:20:56 -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=hDO94RFPn596xZCIeGT0EAz3W28nfZV5jv55djZNYmY=; b=oh4iofcVbb+ZQhGiF95X+F1pfaenSXFY/7sJqQd9k9eNyxqr3pVC38z0d8vpnFVY9u6XivQpp41l8uQ8Cs/bFlLPQNXiP53fYayuyldxmLPC5WUoUHUsmFyr2/GhPWsYr1HLXTvKaIPAVlQuoVaYCZYPL9E77H08P7Zmbeq30Dc= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.656.0; Fri, 23 Mar 2018 11:20:50 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::58c9:a553:b191:62b8]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::58c9:a553:b191:62b8%3]) with mapi id 15.20.0656.000; Fri, 23 Mar 2018 11:20:50 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JWT BCP draft adding Nested JWT guidance Thread-Index: AdPCk7THDCD7nFSjTMWpE1HcWPo5pw== Date: Fri, 23 Mar 2018 11:20:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.132.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0292; 7:KYXa/c+l9kJ436ONgyneRw3DoBcEIKpWb1lStphxAr76qQLOFfEvdtKnd4RzrmmlaYn3wAGkPg66v+vIvGr9Nj03aWKKI3LffyqaZUdVrpPNeP36sYPH288QwGeZ4NcKj5rWhZAyHMvhEoI/gSy+P78dkgSO2wjgnkC5pMRgQHMeEcuF3QI4OYxzG4q8fyMgLdvo5JZam0Z0vA13W0kkSLrx34mNSJR/JDKN7wP5klEGcp3XcAlrLttlcZ11olAB; 20:SYhjGJx566nAbhGYKZtS0RYARrx6zGfgkvgUXAeLv2fsUUKg//P5MqQnppL2EhIT3q7tPAZsZVFckolEhnBe0O4KCQUJn1AGr3sGLIh5ICceBov/tLJo6OUJx6yvwNhtC+3dygnW8CaFhog7Rll1fR1sVFBgi9ETXpn8txHg9Zs= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c97605a3-27ae-4e91-62f3-08d590b02252 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0292; x-ms-traffictypediagnostic: BL0PR00MB0292: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BL0PR00MB0292; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0292; x-forefront-prvs: 0620CADDF3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(366004)(376002)(39380400002)(209900001)(199004)(189003)(3846002)(790700001)(22452003)(66066001)(102836004)(186003)(74316002)(6506007)(5640700003)(6116002)(2501003)(86612001)(7696005)(59450400001)(97736004)(5660300001)(316002)(26005)(606006)(14454004)(99286004)(7736002)(86362001)(2900100001)(2906002)(478600001)(10090500001)(6916009)(5630700001)(33656002)(8936002)(53376002)(8990500004)(25786009)(1730700003)(53936002)(3280700002)(81156014)(10290500003)(8676002)(81166006)(2351001)(106356001)(3660700001)(6436002)(5250100002)(72206003)(236005)(966005)(9686003)(105586002)(6306002)(54896002)(55016002)(68736007)(217873001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dJx90uI3FUMAhuc5U1mFD8zSa8susiM5BzDBSmtn3TY7e2J31uwZF3iRjBELXmcNZf1SSL+XiKcEme05+39G7hdh7Yc7uoZDUeeIJcd/2aRsXvem3pwUiK+NLlWCy+gNR3c5U2HMfkCRQW/lNY7Ukx7k8Hh32g6vkz3CkbO8LJBDbFBT6IIa1QAEADOx01Iy9f13iBPnt2fR1hkmPNUMq+Da50I8vq3x6vet/nxs+qIr94GQBahXgKu5QNC2rb/AKi63jg/FozZAWEdOEp0Bg0EbXWWO9avKa80yw8QjHOt21Zo4yyszRlGRxP8T34PNIoKE8lM7nNrr+hmFSuqWOA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292A9171AFC43A86F616A24F5A80BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c97605a3-27ae-4e91-62f3-08d590b02252 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2018 11:20:50.6501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: [OAUTH-WG] JWT BCP draft adding Nested JWT guidance 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, 23 Mar 2018 11:20:59 -0000 --_000_BL0PR00MB0292A9171AFC43A86F616A24F5A80BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JSON Web Token (JWT) Best Current Practices (BCP) specification has bee= n updated to add guidance on how to explicitly type Nested JWTs. Thanks to= Brian Campbell for suggesting the addition. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-01.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1801 and a= s @selfissued. --_000_BL0PR00MB0292A9171AFC43A86F616A24F5A80BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JSON Web Token (JWT) Best Current Practices (BCP= ) specification has been updated to add guidance on how to explicitly type = Nested JWTs.  Thanks to Brian Campbell for suggesting the addition.

 

The specification is available at:

--_000_BL0PR00MB0292A9171AFC43A86F616A24F5A80BL0PR00MB0292namp_-- From nobody Fri Mar 23 06:28:30 2018 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 7C0B212D958 for ; Fri, 23 Mar 2018 06:28:28 -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=curity-io.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 rhtVqFqwfyP2 for ; Fri, 23 Mar 2018 06:28:27 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 B83F212D955 for ; Fri, 23 Mar 2018 06:28:22 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id v23-v6so13220876oth.9 for ; Fri, 23 Mar 2018 06:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QhUK+8pv9IbaITuvxv+mcxIxq5NxzFC5x9poKm//FNo=; b=rn5IbW0dHNxIq34FlLbDbtR3CVt4R2H7Sr4fCXHl1qI1u1b5kbwdFJuuHJUZ2VfsA3 8YuqT04BuhTl33o3T3ahEay+P+ZgZdZbKWDhl8HCCjFLRdlPvnU+yR9M6g+PSFEYoz2R d/XRLNjA4Ai+ORFjtFPz61dnOG0lIZM5N3Xgw/l6ugjLtb9ctKj8hgrvHIRs5CeICiTv 38S75A8vwW2CUe7Vr+1jYsLtn975mqLAZ9ANwWUBS2AoB1ShTrOtlzlLBLe8A+yDhD9O 5QXSOWT3RY/vXJu8fPNuCoz05/d9Mbo1/3MeyyrjN/6mKjjoh9Yt/I7a9eSiUYKnqFOG ateA== 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=QhUK+8pv9IbaITuvxv+mcxIxq5NxzFC5x9poKm//FNo=; b=r+iQ+US4z7bIZn0eoUTZwibjU/ReQcW1IPeBcFxaqtleXlKYC/bIX1vw6Fc6Sc3V+u 5uFMpHL1jNaOQLJjOojOjOJ6HdSSZhsNVbzSNn4qJVtXsBewxk56880JjfblNGNh6pgj d5jLT0PUUFzLGKjgOmalM9NONSQmM+zS0KVRUk7rCpUhwQVg1pcm65qK6ovHEnDufzj3 XFY1V98NZpDsgVWhr8Iu+z0AD7LpWytudmTUI1JBOK+GGOkOEgYSjwzpT0RB9NoH8B4c nsF6lPuqDt5BBqCRjjxa4xYMaOBzAi8Fx4fC8s43HNns8xLkHV4s0oSSW3YUlbyPlDaX f7GQ== X-Gm-Message-State: AElRT7F5KEhBr8mbrvu9+5ref/7kXYwPcDPuRhTmbNvmur264Yj73ixt X75yXiJEFV1kRDuRlkQEQCoU8txy04VQoQHt1ewsXg== X-Google-Smtp-Source: AG47ELtONJKXkwhZyd9xTX+DnZ3PgLG1B4V07FOf6yWm5jMXEKbfYvmIwf+P2j+k3AmHtf7O7TGmez+jEdCXFDVF3Vk= X-Received: by 2002:a9d:2ce2:: with SMTP id e31-v6mr13499119otd.135.1521811701848; Fri, 23 Mar 2018 06:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.70.193 with HTTP; Fri, 23 Mar 2018 06:28:01 -0700 (PDT) In-Reply-To: References: <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> From: Travis Spencer Date: Fri, 23 Mar 2018 14:28:01 +0100 Message-ID: To: Torsten Lodderstedt Cc: oauth , Brian Campbell Content-Type: multipart/alternative; boundary="000000000000e76d2805681465e0" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.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, 23 Mar 2018 13:28:28 -0000 --000000000000e76d2805681465e0 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 8:34 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > The AS MUST take precautions to prevent this threat. > Based on its risk assessment the AS needs to decide whether > it can trust the redirect URI or not and should only automatically > redirect the user agent, if it trusts the redirect URI. If not, it could > inform the user that it is about to redirect her to the another site > The "...and should..." and "...it could inform..." don't directly line up with the MUST at the beginning of that paragraph. It makes the MTI precautions only and the rest is optional. If that's desired, OK, but I'd suggest using all caps to make that clear -- MAY/OPTIONAL or MUST/REQUIRED or SHOULD/RECOMMENDED --000000000000e76d2805681465e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 21, 2018 at 8:34 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
The AS MUST t= ake precautions to prevent this threat.
Based on its risk assessment the AS needs to decide whether
it can trust the redirect URI or not and should only automatically
redirect the user agent, if it trusts the redirect URI. If not, it could inform the user that it is about to redirect her to the another site

The "...and should..." and "..= .it could inform..." don't directly line up with the MUST at the b= eginning of that paragraph. It makes the MTI precautions only and the rest = is optional. If that's desired, OK, but I'd suggest using all caps= to make that clear -- MAY/OPTIONAL or MUST/REQUIRED or SHOULD/RECOMMENDED =
=C2=A0
--000000000000e76d2805681465e0-- From nobody Fri Mar 23 09:12:47 2018 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 56FFD12D871 for ; Fri, 23 Mar 2018 09:12:46 -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, 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 (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 EscfYXHKzO_e for ; Fri, 23 Mar 2018 09:12:42 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 005BD12D868 for ; Fri, 23 Mar 2018 09:12:41 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id z143-v6so5720053itc.0 for ; Fri, 23 Mar 2018 09:12:41 -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=/MH8XY9soBbEIltW8wH6pFeDXBKHh/NSFlT+POxz25o=; b=OB3u4tN8SmIjJ7Uuq/Eroek7Dd4iltzheP0hGuPmXNzQoZAmfEcn/VbB06a6e+7kri K05UAdKkHpLvE71g9knK1G/2tWBJBdQJEIumTyxNTGGhm+gI3x+fv1DHuMpGipk+ZDkL zdoRsR7vHnbyF7kwBTHz87foWfh+ugw35dIsc= 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=/MH8XY9soBbEIltW8wH6pFeDXBKHh/NSFlT+POxz25o=; b=WgKDpAh1noBZHWKR8qVw39ubVa0ETBNmD7cIFRVfGvto/QC/mz8AL10lqx5ffbEN6n zCGXm8yyevGdfaqQhniLypOORtAb79w0Ik/zYUkdiXo7WGNpmaJ71kLyU3xeeRNisuGK AXv/Of2hQifrckaf/Qm/NSnKBd52rAfLm20sooIVitoKdiyQkbVZSA4Anda2JEZDINRI Goun2BBzcnDEfwv5ALu9aj9c8VHb7KNXa99RMvqvktcsuVbxIHAoUKaqJNY4t5eSIsiw ehR2Zai1JV9glLntqiuW686ok/GHGNsBTGAWfGh0IJdaWqErReBlVm2X1knkqHKQy0TL PO1g== X-Gm-Message-State: AElRT7HtCX7QEzXnuSY4mJj4YKlicAaE5o1ItiPimeOj9FWCjPpPEMcw 893h7oE8fqCz8FoItLqptcYvrTJ1v7Wi8CZojHdH6CeDiIHHi01BQ5KU0nPWEGDOz7EAvH4seV8 GJiBsZ0ECLDANfg== X-Google-Smtp-Source: AG47ELsaY3RosyMUhreCFoB2/0qCLdXvh3O2rTyc0dY/flnZgf3HOMTwAfz+nJuNOQrds9UDlZQmgUiQ0wWUMzCEREg= X-Received: by 2002:a24:85c1:: with SMTP id r184-v6mr14303792itd.76.1521821561057; Fri, 23 Mar 2018 09:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.214 with HTTP; Fri, 23 Mar 2018 09:12:10 -0700 (PDT) In-Reply-To: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> References: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> From: Brian Campbell Date: Fri, 23 Mar 2018 16:12:10 +0000 Message-ID: To: Justin Richer Cc: "" Content-Type: multipart/alternative; boundary="0000000000008f1205056816b139" Archived-At: Subject: Re: [OAUTH-WG] Review of oauth-mtls-07 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, 23 Mar 2018 16:12:46 -0000 --0000000000008f1205056816b139 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the detailed review, Justin. Replies are inline below... On Tue, Mar 20, 2018 at 5:52 PM, Justin Richer wrote: > As promised in yesterday=E2=80=99s meeting, here=E2=80=99s my review of t= he oauth-mtls > draft. We=E2=80=99ve recently implemented the spec from the AS and RS sid= e for an > as-yet-unreleased version of the Authlete service, and overall it=E2=80= =99s in > really good shape and very implementable as it stands today. Great work, > and usable right now! > That's great to hear! Thanks. > > > Comments, nits, and suggestions as follows: > > =C2=A7Abstract: Single sentence is a bit of a run-on that=E2=80=99s hard = to follow. > Suggested rewrite: > > This document describes OAuth client authentication and sender-constraine= d > tokens using Transport Layer Security (TLS) mutual authentication with > X.509 certificates. OAuth clients are provided a mechanism for > authentication to the authorization sever using mutual TLS, based on eith= er > single certificates or public key infrastructure (PKI). OAuth authorizati= on > servers are provided a mechanism for binding access tokens to a client=E2= =80=99s > mutual TLS certificate, and OAuth protected resources are provided a meth= od > for ensuring that such an access token presented to it was issued to the > client presenting the token. > > Yeah, that one sentence in the abstract is maybe more than just a bit of a run-on. Your rewrite is easier to read. > > =C2=A71=C2=B61 (and throughout): The document goes back and forth between= =E2=80=9Cmutual > TLS authentication=E2=80=9D and =E2=80=9CTLS mutual authentication=E2=80= =9D, one should be picked > and used consistently throughout. I realize this is spelled out in 1.2 bu= t > it might be worth the effort to use one form most of the time. > I'll take another pass at this. Prior efforts to reconcile have proven to be more difficult than one might expect. But I'll try. > =C2=A71=C2=B63: maybe don=E2=80=99t call it a =E2=80=9Cbasic bearer token= =E2=80=9D and instead just a > =E2=80=9Cbearer token=E2=80=9D to avoid sounding judgmental > Okay. > =C2=A72=C2=B61: suggest turning parenthetical into a list: =E2=80=9C(rega= rdless of whether > the client was dynamically registered, statically configured, or otherwis= e > established)=E2=80=9D > Will do. > =C2=A72=C2=B63: It seems this paragraph is trying to leave the door open = to other > MTLS bound client auth methods, but such methods would require the > definition of a different auth method parameter value and a new spec, not > really an extension of what=E2=80=99s here. Therefore, suggest changing t= he end of > the paragraph into a single compact sentence: > > The authorization server MUST enforce the > binding a certificate to a specific client as described in either Sect= ion 2.1 = or > Section 2.2 below. > > Yeah, the current language in that paragraph is a bit of a carry over fro= m previous revisions that didn't yet have the defined auth methods. I think the text you suggest is better and more clear given the content of the draft now. > > =C2=A72.1=C2=B61: It would be helpful to have a pointer on methods of com= paring DNs. > In our implementation we serialize them to strings using a canonical form= at > (RFC2253) and doing a string comparison based on that. There are probably > other ways, but it would be good to help developers avoid doing something > naive like comparing two different serializations as strings. > That's really an implementation detail but I can note that some kind of normalization is likely needed in comparing DNs. > =C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an unnece= ssary distinction, 6749 > calls it =E2=80=9Cregistered=E2=80=9D regardless of how it got there > While I suppose that's true about 6749, I think colloquially 'registered' and 'configured' have come to have more meaning to some/many people about how the client came to be setup at the AS. So it might be strictly unnecessary but I'd prefer to keep the "configured or registered" just to help say that it doesn't matter how the AS came to get the expected DN for client. > =C2=A72.1.1=C2=B61: Is it necessary to introduce the registry here instea= d of just > pointing to it? I=E2=80=99m fine with stating that the values are used in= both > discovery and client registration. > I had a hard time describing things concisely here because of the history of how and when the authentication methods registry came to be, it's name, and where it's used. That text in =C2=B61 is what I was able to come up wi= th that I thought adequately explained it. It's admittedly not the most elegant prose ever written but it does convey the info and I'm inclined to leave it. However, I would be happy to consider alternative text here, if you've got something specific to propose. > =C2=A72.1.2: I=E2=80=99m only just now seeing the reference to RFC4514 he= re so this > reference needs to be in the parent section as well. I was previously und= er > the impression that no format was prescribed. > =C2=A72.1.2 is meant just to prescribe a format for value of the client met= adata parameter. Not necessarily how comparison should done. > =C2=A72.2=C2=B61: Might want to say explicitly in here that the cert is i= n the JWK > for the client (instead of lower down), as it would make the description = of > the JWKS_URI method make more sense upfront. This could also live in the > parent section. > Makes sense. I'll add mention of that there. > =C2=A72.2=C2=B61: "certificate chain is not validated=E2=80=9D should pro= bably more > explicitly point to the *client=E2=80=99s* certificate not being validate= d to > prevent clients from not validating the *server=E2=80=99s* certificate ch= ain. > Yes, good point. It is probably worthwhile to be very explicit about that. > =C2=A72.2=C2=B61: Extraneous comma: "successfully authenticated, if the s= ubject=E2=80=9D > Will remove the extraneous comma. > =C2=A72.2.1: Same comment as =C2=A72.1.1 > Also same. > =C2=A73.1=C2=B62: As Brian mentioned in another message, this should spec= ify =E2=80=9Cno > padding=E2=80=9D. > Yes, will specify more specifically. > =C2=A74.1=C2=B61: Probably intend =E2=80=9Cset up=E2=80=9D instead of =E2= =80=9Csetup=E2=80=9D > Probably, yes. > =C2=A74.1=C2=B64: =E2=80=9Cseparate host name=E2=80=9D should be =E2=80= =9Cseparate host name or port=E2=80=9D > Good point. Will change. > =C2=A74.2=C2=B61: Wording is a bit awkward, suggest: > > Since the resource server relies on the authorization server to perform c= lient authentication, there is no need for the resource server to validate > the trust chain of the client's certificate in any of the methods > defined in this document. > > I'll endeavor to make =C2=A74.2=C2=B61 a little less awkward. > =C2=A74.3=C2=B61: I get what this section is trying to say but it is conf= usingly > laid out. Might be better to say something like =E2=80=9CMTLS client auth= and > sender-constrained MTLS bound tokens can be used independently of each > other=E2=80=9D. > Will incorporate something along those lines in place of the current first sentence. > =C2=A74.3=C2=B61: This advice doesn=E2=80=99t just apply to public client= s, so we probably > don=E2=80=99t mean =E2=80=9Cwould not authenticate the client=E2=80=9D he= re but instead =E2=80=9Cwould not > authenticate the client using mutual TLS=E2=80=9D, since the client could > authenticate in other methods. Though it is important to point out that > public clients can do this :too:, it=E2=80=99s just as important to allow= a client > to use private_key_jwt or client_secret_basic and still get a constrained > token. > Makes sense. I'll adjust it accordingly. =C2=A7A=C2=B62: This paragraph reads a bit overly defensive. I understand t= he need to > position the two drafts in relationship to each other, but the tone here > could be adjusted significantly without losing the thrust of the main > argument. > The line about Token Binding not having a monopoly on the binding of tokens is admittedly a bit tongue-in-cheek and also a nod to the point you made the other day about running out of names. Honestly though, this text wasn't intended to be defensive and, even when I read it again, it doesn't come off that way to me. As usual, if you've got specific text to propose that you think would be better, I'd be happy to consider it. But I don't feel like the current text is particularly problematic or in need of change. --=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.* --0000000000008f1205056816b139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the detailed review, Justin. Replies are inline= below...


On Tue, Mar 20, 2018 at 5:52 PM, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
As= promised in yesterday=E2=80=99s meeting, here=E2=80=99s my review of the o= auth-mtls draft. We=E2=80=99ve recently implemented the spec from the AS an= d RS side for an as-yet-unreleased version of the Authlete service, and ove= rall it=E2=80=99s in really good shape and very implementable as it stands = today. Great work, and usable right now!

<= div>That's great to hear! Thanks.
=C2=A0
=C2=A0
=

Comments, nits, and suggestions as follows:

=C2=A7Abstract: Single sentence is a bit of a run-on that= =E2=80=99s hard to follow. Suggested rewrite:

Th= is document describes OAuth client authentication and sender-constrained to= kens using Transport Layer Security (TLS) mutual authentication with X.509 = certificates. OAuth clients are provided a mechanism for authentication to = the authorization sever using mutual TLS, based on either single certificat= es or public key infrastructure (PKI). OAuth authorization servers are prov= ided a mechanism for binding access tokens to a client=E2=80=99s mutual TLS= certificate, and OAuth protected resources are provided a method for ensur= ing that such an access token presented to it was issued to the client pres= enting the token.

Yeah, that one sentence in the abstract is maybe more than just a bit= of a run-on. Your rewrite is easier to read.

=C2=A0

=C2=A71=C2=B61 (and throughout): The document goes back and forth be= tween =E2=80=9Cmutual TLS authentication=E2=80=9D and =E2=80=9CTLS mutual a= uthentication=E2=80=9D, one should be picked and used consistently througho= ut. I realize this is spelled out in 1.2 but it might be worth the effort t= o use one form most of the time.

I'll take another pass at this. Prior efforts to reconcile have= proven to be more difficult than one might expect. But I'll try.
<= br>
=C2=A0
=C2=A71=C2=B63: maybe don=E2=80=99t call it a =E2=80=9Cbasi= c bearer token=E2=80=9D and instead just a =E2=80=9Cbearer token=E2=80=9D t= o avoid sounding judgmental

Okay.

=C2=A0
=C2=A72= =C2=B61: suggest turning parenthetical into a list: =E2=80=9C(regardless of= whether the client was dynamically registered, statically configured, or o= therwise established)=E2=80=9D

Will do.

=C2=A0
=C2=A72=C2=B63: It seems this paragraph = is trying to leave the door open to other MTLS bound client auth methods, b= ut such methods would require the definition of a different auth method par= ameter value and a new spec, not really an extension of what=E2=80=99s here= . Therefore, suggest changing the end of the paragraph into a single compac= t sentence:

 The authorization server MUST enforce the
   binding a certificate to a specific client as described in either Section 2.1 or
   Section 2.2 below.
Yeah, the current language in that paragraph is a = bit of a carry over from previous revisions that didn't yet have the de= fined auth methods. I think the text you suggest is better and more clear g= iven the content of the draft now.

=C2=A0

=C2=A72.1=C2=B61: It would be helpful to have a point= er on methods of comparing DNs. In our implementation we serialize them to = strings using a canonical format (RFC2253) and doing a string comparison ba= sed on that. There are probably other ways, but it would be good to help de= velopers avoid doing something naive like comparing two different serializa= tions as strings.=C2=A0

T= hat's really an implementation detail but I can note that some kind of = normalization is likely needed in comparing DNs.

=C2=A0<= /div>
=C2= =A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an unnecessary= distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D regardless of how = it got there

While I supp= ose that's true about 6749, I think colloquially 'registered' a= nd 'configured' have come to have more meaning to some/many people = about how the client came to be setup at the AS. So it might be strictly un= necessary but I'd prefer to keep the "configured or registered&quo= t; just to help say that it doesn't matter how the AS came to get the e= xpected DN for client.
=C2=A0 =C2=A0 =C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A72.1.1= =C2=B61: Is it necessary to introduce the registry here instead of just poi= nting to it? I=E2=80=99m fine with stating that the values are used in both= discovery and client registration.=C2=A0

I had a hard time describing things concisely here because= of the history of how and when the authentication methods registry came to= be, it's name, and where it's used.=C2=A0 That text in=C2=A0=C2=B6= 1 is what I was able to come up with that I thought adequately explained it= . It's admittedly not the most elegant prose ever written but it does c= onvey the info and I'm inclined to leave it. However, I would be happy = to consider alternative text here, if you've got something specific to = propose.

=C2=A0
=C2=A72.1.2: I=E2=80=99m only just now seeing = the reference to RFC4514 here so this reference needs to be in the parent s= ection as well. I was previously under the impression that no format was pr= escribed.=C2=A0

=C2=A72.1= .2 is meant just to prescribe a format for value of the client metadata par= ameter. Not necessarily how comparison should done.

=C2= =A0
= =C2=A72.2=C2=B61: Might want to say explicitly in here that the cert is in = the JWK for the client (instead of lower down), as it would make the descri= ption of the JWKS_URI method make more sense upfront. This could also live = in the parent section.

Ma= kes sense. I'll add mention of that there.

=C2=A0
=C2=A72= .2=C2=B61: "certificate chain is not validated=E2=80=9D should probabl= y more explicitly point to the *client=E2=80=99s* certificate not being val= idated to prevent clients from not validating the *server=E2=80=99s* certif= icate chain.

Yes, good po= int. It is probably worthwhile to be very explicit about that.

=C2=A0
<= div>
=C2=A72.2=C2=B61: Extraneous comma: "successfully authenticat= ed, if the subject=E2=80=9D

Will remove the extraneous comma.

=C2=A0
=C2=A72.2.1: Same = comment as =C2=A72.1.1

Al= so same.

=C2=A0
=C2=A73.1=C2=B62: As Brian mentioned in anothe= r message, this should specify =E2=80=9Cno padding=E2=80=9D.

Yes, will specify more specifically.
=C2=A0
=C2=A74.1=C2=B61: Probably intend =E2=80=9Cset up=E2=80= =9D instead of =E2=80=9Csetup=E2=80=9D
<= br>
Probably, yes.

=C2=A0
=C2=A74.1=C2=B64: =E2=80= =9Cseparate host name=E2=80=9D should be =E2=80=9Cseparate host name or por= t=E2=80=9D

Good point. Wi= ll change.

=C2=A0
=C2=A74.2=C2=B61: Wording is a bit awkward, = suggest:

Since the resource server relies on the authoriza=
tion server to perform client authentication, there is no need for the reso=
urce server to validate
   the trust chain of the client's certificate in any of the methods
   defined in this document.
I'll endeavor to make=C2=A0=C2=A74.2=C2=B61 a litt= le less awkward.

=C2=A0
=C2=A74.3=C2=B61: I get what this sec= tion is trying to say but it is confusingly laid out. Might be better to sa= y something like =E2=80=9CMTLS client auth and sender-constrained MTLS boun= d tokens can be used independently of each other=E2=80=9D.=C2=A0

Will incorporate something along th= ose lines in place of the current first sentence.

=C2=A0=
=C2= =A74.3=C2=B61: This advice doesn=E2=80=99t just apply to public clients, so= we probably don=E2=80=99t mean =E2=80=9Cwould not authenticate the client= =E2=80=9D here but instead =E2=80=9Cwould not authenticate the client using= mutual TLS=E2=80=9D, since the client could authenticate in other methods.= Though it is important to point out that public clients can do this :too:,= it=E2=80=99s just as important to allow a client to use private_key_jwt or= client_secret_basic and still get a constrained token.

Makes sense. I'll adjust it accordingly.=
=C2=A0

=C2=A7A=C2=B62: This paragraph reads a bit overly= defensive. I understand the need to position the two drafts in relationshi= p to each other, but the tone here could be adjusted significantly without = losing the thrust of the main argument.
=
The line about Token Binding not having a monopoly on the bi= nding of tokens is admittedly a bit tongue-in-cheek and also a nod to the p= oint you made the other day about running out of names.

= Honestly though, this text wasn't intended to be=C2=A0defensive and, ev= en when I read it again, it doesn't come off that way to me. As usual, = if you've got specific text to propose that you think would be better, = I'd be happy to consider it. But I don't feel like the current text= is particularly problematic or in need of change.

<= 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. --0000000000008f1205056816b139-- From nobody Mon Mar 26 02:03:08 2018 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 3E5C51243F6 for ; Mon, 26 Mar 2018 02:03:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ubisecure.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 3EHJCLKzBMYI for ; Mon, 26 Mar 2018 02:03:04 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::61b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E5A1205F0 for ; Mon, 26 Mar 2018 02:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubisecure.onmicrosoft.com; s=selector1-ubisecure-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kwrxn/UBSM+g2tQS5AIPYT2k68uresYEIH4A8YMDrIM=; b=Dg1XsP8vwMmEjDi5iq4rRVuiOtg3PC2YKdfctG8M+YybTOwdU8i0kKZ/I8IqadoQFDd1YuAlU73IlrsJOm2bB38RFe3mrj8QUAMAKxyiLT10uKD4NiV7DHNtpexMaCjlquCi2zeZAz5KVcSKibPLomFJOJDYdZrUGtJoNgXOpjc= Received: from DB5PR05MB1704.eurprd05.prod.outlook.com (10.165.7.10) by DB5PR05MB1416.eurprd05.prod.outlook.com (10.162.153.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Mon, 26 Mar 2018 09:02:59 +0000 Received: from DB5PR05MB1704.eurprd05.prod.outlook.com ([fe80::859d:6c62:6195:d058]) by DB5PR05MB1704.eurprd05.prod.outlook.com ([fe80::859d:6c62:6195:d058%13]) with mapi id 15.20.0609.012; Mon, 26 Mar 2018 09:02:59 +0000 From: Petteri Stenius To: Torsten Lodderstedt CC: oauth Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt Thread-Index: AQHTvu/6yA3kQFDT30uYm5/Ds5X/DqPiQ2ag Date: Mon, 26 Mar 2018 09:02:59 +0000 Message-ID: References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> In-Reply-To: <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> 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=Petteri.Stenius@ubisecure.com; x-originating-ip: [195.197.205.34] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR05MB1416; 7:jYWRmtr+Yzua3FZv6rtSPK6Pct2M3ypV94axwep1QGHW0nNR6w+KwO2fxeq40Qt2sbI/ipW6k+uWZzUDkgNqSHN4D055fHRTRLfif8XOYVKVkpDZwFtkMVqdv1c86Uazo3iKuLiaUVhrL1xqueWDLgxFcdcKuBN3JYalp3PlUhaIy65keRw3wNIa7Aj+8Yg5zUT/y3KLhLWpoKSuuChLm7B0fV51IBtUz4BXtbBNE4dfXRvPhxhCtEOPDwE5HK+L x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0e310492-1c3b-4968-58af-08d592f85fa2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DB5PR05MB1416; x-ms-traffictypediagnostic: DB5PR05MB1416: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(788757137089)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(2016111802025)(20161123558120)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:DB5PR05MB1416; BCL:0; PCL:0; RULEID:; SRVR:DB5PR05MB1416; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(39830400003)(366004)(396003)(53754006)(189003)(199004)(377424004)(7696005)(186003)(3660700001)(4326008)(59450400001)(5660300001)(9686003)(97736004)(54896002)(6306002)(236005)(790700001)(105586002)(1680700002)(106356001)(3846002)(6116002)(102836004)(86362001)(6436002)(6506007)(26005)(55016002)(7110500001)(2900100001)(14454004)(25786009)(74316002)(76176011)(10710500007)(316002)(68736007)(11346002)(33656002)(81166006)(446003)(81156014)(99286004)(561944003)(15650500001)(2420400007)(6916009)(6246003)(5250100002)(8936002)(14971765001)(3280700002)(53386004)(66066001)(53936002)(2906002)(8676002)(606006)(7736002)(72206003)(966005)(229853002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR05MB1416; H:DB5PR05MB1704.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ubisecure.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: z5L9UAKf/lmxbtlDGzhJfhtKtiuOD+h20+apX4dQk0volvMVJ6Bs0WrrTAxvuFO/cNybjsw0oHp05ohDxvIo0VgWl4e3Z2cVEDAggmFHS8p1vMj9mnALY+6MfJnqXFj2M6KQkBf2wWL8FmBWsMawnHvsLBEwfxnGPzgFu377wqTqLEA6FKvvVL1lCUTpEjEqYKAfBXceO6he8PCJQutDXlrdjErJkczFXwW7O1bgThCP/2CcUnzVqjq5J8KT18ze0Y2COzjxHlPB6vyyuIVdJS3meyd/E4ix5euTvctByC7QIxp5+u9bguRCyRC7FoN4bdZ0FUAq1QG8Eg9x9emqzQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR05MB1704D9C2A95F37D4B5E6F118FAAD0DB5PR05MB1704eurp_" MIME-Version: 1.0 X-OriginatorOrg: ubisecure.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e310492-1c3b-4968-58af-08d592f85fa2 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2018 09:02:59.5875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: feaa1139-6ffc-4422-9c7b-980ad003c1a7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1416 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 26 Mar 2018 09:03:06 -0000 --_000_DB5PR05MB1704D9C2A95F37D4B5E6F118FAAD0DB5PR05MB1704eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHdhbnQgdG8gc2hvdyBteSBzdXBwb3J0IGZvciB0aGlzIHByb3Bvc2FsDQoN Cg0KSSBiZWxpZXZlIHRoZSB0d28gdXNlIGNhc2VzIHByZXNlbnRlZCBhdCB0aGUgSUVURiBtZWV0 aW5nIFsxXSBhcmUgaW1wb3J0YW50Og0KDQoxLiBpbXBsZW1lbnRpbmcgYXBwbGljYXRpb24gbGV2 ZWwgZW5kLXRvLWVuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiB0aGUgaW50cm9zcGVjdGlvbiBy ZXNwb25zZQ0KMi4gc2ltcGxlIGNvbnZlcnNpb24gb2YgYnktcmVmZXJlbmNlIGFjY2VzcyB0b2tl bnMgaW50byBieS12YWx1ZSBKV1QgZW5jb2RlZCB0b2tlbnMNCg0KDQpUaGlzIHByb3Bvc2FsIGFk ZHMgdGhyZWUgZmllbGRzIHRvIHRoZSBjbGllbnQgbWV0YWRhdGEuIEkgdGhpbmsgdGhlcmUgYXJl IHR3byBpc3N1ZXMgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkOg0KDQoxLiBSZW1vdmUgZG91Ymxl ICJyZXNwb25zZSIgZnJvbSBmaWVsZCBuYW1lcy4gUmVwbGFjZSAiaW50cm9zcGVjdGlvbl9yZXNw b25zZV9zaWduZWRfcmVzcG9uc2VfYWxnIiB3aXRoICJpbnRyb3NwZWN0aW9uX3NpZ25lZF9yZXNw b25zZV9hbGciLiBBbHNvIGFkZHJlc3MgdHdvIG90aGVyIGZpZWxkcw0KMi4gQWRkIGNvcnJlc3Bv bmRpbmcgZmllbGRzIHRvIHByb3ZpZGVyIG1ldGFkYXRhLiBGb3IgY2xpZW50IG1ldGFkYXRhIGZp ZWxkICJpbnRyb3NwZWN0aW9uX3NpZ25lZF9yZXNwb25zZV9hbGciIHRoZXJlIHNob3VsZCBleGlz dCAiaW50cm9zcGVjdGlvbl9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkIiBpbiBwcm92aWRl ciBtZXRhZGF0YS4gVGhlIHR3byBvdGhlciBmaWVsZHMgbmVlZCBjb3JyZXNwb25kaW5nIGZpZWxk cyBhcyB3ZWxsLg0KDQoNClJlbGF0aW9uc2hpcCB3aXRoIE9wZW5JRCBDb25uZWN0DQoNCkluIE9w ZW5JRCBDb25uZWN0IHRoZSB1c2VyaW5mbyBlbmRwb2ludCBpcyB2ZXJ5IHNpbWlsYXIgdG8gaW50 cm9zcGVjdGlvbiBlbmRwb2ludCBvZiBPQXV0aC4gVXNlcmluZm8gc3VwcG9ydHMgSldUIHNpZ25p bmcgYW5kIGVuY3J5cHRpb24uIEFkZGluZyBKV1Qgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiB0byBp bnRyb3NwZWN0aW9uIGVuZHBvaW50IGZpbGxzIHRoZSBnYXAgYmV0d2VlbiB0aGUgdHdvIHNwZWNp ZmljYXRpb25zLg0KDQoNCkJlc3QgcmVnYXJkcywNClBldHRlcmkgU3Rlbml1cw0KDQpbMV0gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvc2xpZGVzLTEw MS1vYXV0aC1zZXNzYi1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMQ0KDQoNCg0KRnJvbTog T0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb3JzdGVuIExvZGRl cnN0ZWR0DQpTZW50OiBzdW5udW50YWkgMTguIG1hYWxpc2t1dXRhIDIwMTggMjEuMzMNClRvOiBv YXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEZ3ZDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVj dGlvbi1yZXNwb25zZS0wMC50eHQNCg0KSGkgYWxsLA0KDQpJIGp1c3Qgc3VibWl0dGVkIGEgbmV3 IGRyYWZ0IHRoYXQgVmxhZGltaXIgRHpodXZpbm92IGFuZCBJIGhhdmUgd3JpdHRlbi4gSXQgcHJv cG9zZXMgYSBKV1QtYmFzZWQgcmVzcG9uc2UgdHlwZSBmb3IgVG9rZW4gSW50cm9zcGVjdGlvbi4g VGhlIG9iamVjdGl2ZSBpcyB0byBwcm92aWRlIHJlc291cmNlIHNlcnZlcnMgd2l0aCBzaWduZWQg dG9rZW5zIGluIGNhc2UgdGhleSBuZWVkIGNyeXB0b2dyYXBoaWMgZXZpZGVuY2UgdGhhdCB0aGUg QVMgY3JlYXRlZCB0aGUgdG9rZW4gKGUuZy4gZm9yIGxpYWJpbGl0eSkuDQoNCkkgd2lsbCBwcmVz ZW50IHRoZSBuZXcgZHJhZnQgaW4gdGhlIHNlc3Npb24gb24gV2VkbmVzZGF5Lg0KDQpraW5kIHJl Z2FyZHMsDQpUb3JzdGVuLg0KDQoNCkFuZmFuZyBkZXIgd2VpdGVyZ2VsZWl0ZXRlbiBOYWNocmlj aHQ6DQoNClZvbjogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQpCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTAwLnR4dA0KRGF0 dW06IDE4LiBNw6RyeiAyMDE4IHVtIDIwOjE5OjM3IE1FWg0KQW46ICJWbGFkaW1pciBEemh1dmlu b3YiIDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5j b20+PiwgIlRvcnN0ZW4gTG9kZGVyc3RlZHQiIDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWls dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3Qt aW50cm9zcGVjdGlvbi1yZXNwb25zZQ0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAwMA0KVGl0 bGU6ICAgICAgICAgICAgICAgICAgICAgICBKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIElu dHJvc3BlY3Rpb24NCkRvY3VtZW50IGRhdGU6ICAgICAgMjAxOC0wMy0xNQ0KR3JvdXA6ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNQ0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s b2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJz dGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS8NCkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWlu dHJvc3BlY3Rpb24tcmVzcG9uc2UtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3Nw ZWN0aW9uLXJlc3BvbnNlDQoNCg0KQWJzdHJhY3Q6DQogIFRoaXMgZHJhZnQgcHJvcG9zZXMgYW4g YWRkaXRpb25hbCBKU09OIFdlYiBUb2tlbiAoSldUKSBiYXNlZCByZXNwb25zZQ0KICBmb3IgT0F1 dGggMi4wIFRva2VuIEludHJvc3BlY3Rpb24uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K --_000_DB5PR05MB1704D9C2A95F37D4B5E6F118FAAD0DB5PR05MB1704eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdhbnQgdG8gc2hvdyBteSBzdXBw b3J0IGZvciB0aGlzIHByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBiZWxpZXZlIHRoZSB0d28g dXNlIGNhc2VzIHByZXNlbnRlZCBhdCB0aGUgSUVURiBtZWV0aW5nIFsxXSBhcmUgaW1wb3J0YW50 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4xLiBpbXBsZW1lbnRpbmcgYXBwbGljYXRpb24gbGV2ZWwgZW5kLXRvLWVuZCBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Mi4gc2lt cGxlIGNvbnZlcnNpb24gb2YgYnktcmVmZXJlbmNlIGFjY2VzcyB0b2tlbnMgaW50byBieS12YWx1 ZSBKV1QgZW5jb2RlZCB0b2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlzIHByb3Bvc2FsIGFkZHMg dGhyZWUgZmllbGRzIHRvIHRoZSBjbGllbnQgbWV0YWRhdGEuIEkgdGhpbmsgdGhlcmUgYXJlIHR3 byBpc3N1ZXMgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4xLiBSZW1vdmUgZG91 YmxlICZxdW90O3Jlc3BvbnNlJnF1b3Q7IGZyb20gZmllbGQgbmFtZXMuIFJlcGxhY2UgJnF1b3Q7 aW50cm9zcGVjdGlvbl9yZXNwb25zZV9zaWduZWRfcmVzcG9uc2VfYWxnJnF1b3Q7IHdpdGggJnF1 b3Q7aW50cm9zcGVjdGlvbl9zaWduZWRfcmVzcG9uc2VfYWxnJnF1b3Q7Lg0KIEFsc28gYWRkcmVz cyB0d28gb3RoZXIgZmllbGRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4yLiBBZGQgY29ycmVzcG9uZGluZyBmaWVsZHMgdG8gcHJvdmlk ZXIgbWV0YWRhdGEuIEZvciBjbGllbnQgbWV0YWRhdGEgZmllbGQgJnF1b3Q7aW50cm9zcGVjdGlv bl9zaWduZWRfcmVzcG9uc2VfYWxnJnF1b3Q7IHRoZXJlDQogc2hvdWxkIGV4aXN0ICZxdW90O2lu dHJvc3BlY3Rpb25fc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCZxdW90OyBpbiBwcm92aWRl ciBtZXRhZGF0YS4gVGhlIHR3byBvdGhlciBmaWVsZHMgbmVlZCBjb3JyZXNwb25kaW5nIGZpZWxk cyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlbGF0aW9uc2hpcCB3aXRoIE9wZW5JRCBDb25u ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkluIE9wZW5JRCBDb25uZWN0IHRoZSB1c2VyaW5mbyBlbmRwb2ludCBpcyB2 ZXJ5IHNpbWlsYXIgdG8gaW50cm9zcGVjdGlvbiBlbmRwb2ludCBvZiBPQXV0aC4gVXNlcmluZm8g c3VwcG9ydHMgSldUIHNpZ25pbmcNCiBhbmQgZW5jcnlwdGlvbi4gQWRkaW5nIEpXVCBzaWduaW5n IGFuZCBlbmNyeXB0aW9uIHRvIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgZmlsbHMgdGhlIGdhcCBi ZXR3ZWVuIHRoZSB0d28gc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+UGV0dGVyaSBTdGVuaXVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlsxXQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvc2xpZGVzLTEwMS1vYXV0aC1z ZXNzYi1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMSI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFscy9zbGlkZXMtMTAxLW9hdXRoLXNlc3NiLWp3 dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTAxPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24g QmVoYWxmIE9mIDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+IHN1bm51 bnRhaSAxOC4gbWFhbGlza3V1dGEgMjAxOCAyMS4zMzxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0 O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3Qt aW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRoYXQgVmxhZGlt aXIgRHpodXZpbm92IGFuZCBJIGhhdmUgd3JpdHRlbi4gSXQgcHJvcG9zZXMgYSBKV1QtYmFzZWQg cmVzcG9uc2UgdHlwZSBmb3IgVG9rZW4gSW50cm9zcGVjdGlvbi4gVGhlIG9iamVjdGl2ZSBpcyB0 byBwcm92aWRlIHJlc291cmNlIHNlcnZlcnMgd2l0aCBzaWduZWQgdG9rZW5zIGluIGNhc2UgdGhl eSBuZWVkIGNyeXB0b2dyYXBoaWMgZXZpZGVuY2UNCiB0aGF0IHRoZSBBUyBjcmVhdGVkIHRoZSB0 b2tlbiAoZS5nLiBmb3IgbGlhYmlsaXR5KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aWxsIHByZXNlbnQgdGhlIG5ldyBkcmFm dCBpbiB0aGUgc2Vzc2lvbiBvbiBXZWRuZXNkYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmtpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvcnN0ZW4uJm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmZhbmcgZGVyIHdlaXRl cmdlbGVpdGV0ZW4gTmFjaHJpY2h0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlZvbjogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QmV0cmVm ZjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1q d3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMC50eHQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5EYXR1bTogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+MTguIE3DpHJ6IDIwMTggdW0gMjA6MTk6MzcgTUVaPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BbjogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+JnF1b3Q7VmxhZGltaXIgRHpodXZpbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPiZn dDssICZxdW90O1RvcnN0ZW4gTG9kZGVyc3RlZHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTAwLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBh bmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj4NCmRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlPGJy Pg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjAwPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkpXVCBSZXNwb25zZSBm b3IgT0F1dGggVG9rZW4gSW50cm9zcGVjdGlvbjxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PjIwMTgtMDMtMTU8YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczo8 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+DQo1PGJyPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24t cmVzcG9uc2UtMDAudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDAudHh0PC9h Pjxicj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9k ZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UvIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVj dGlvbi1yZXNwb25zZS88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s b2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMCI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0 aW9uLXJlc3BvbnNlLTAwPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9h dXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlPC9hPjxicj4NCjxicj4NCjxicj4NCkFic3Ry YWN0Ojxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZHJhZnQgcHJvcG9zZXMgYW4gYWRkaXRpb25hbCBK U09OIFdlYiBUb2tlbiAoSldUKSBiYXNlZCByZXNwb25zZTxicj4NCiZuYnNwOyZuYnNwO2ZvciBP QXV0aCAyLjAgVG9rZW4gSW50cm9zcGVjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciPg0K dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DB5PR05MB1704D9C2A95F37D4B5E6F118FAAD0DB5PR05MB1704eurp_-- From nobody Mon Mar 26 03:57:51 2018 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 1B2BA12711E for ; Mon, 26 Mar 2018 03:57:50 -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 whOSOsvQq9xe for ; Mon, 26 Mar 2018 03:57:48 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 AB496120713 for ; Mon, 26 Mar 2018 03:57:48 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h26-v6so12650597otj.12 for ; Mon, 26 Mar 2018 03:57: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; bh=VErlL4YHHUR/5sWdGPliFrh3ywKT2unfrUALF00h9Pc=; b=R+ObG7q9tzzH2nIqwegSo2xqUS4JvF+3K3w8tFCOBTmSA7uDymJsgXVQI2ScUImljw yPb5ASSYKBXxw2GSI+WKoerdgMXlD9byZE3q/W2U/KpPOYZUb0pigLgsGp4ZLQHB39r4 T1yVWVQ3IBUNlIgCaqHVHjKaHTGexYHoOgd0a7Oa+2qJDcEhzBtDJQCCw88QDQ2FitfF ROzIeFYSapeo2FfHnUqO90ror97w+HurN8RX1Tfcz6fV2oS6aa4moEi4yVrUxv53uLqw FSuGPTCgwNFDZCer8+FvQaYycrZ8wrATcIrMUm1SqJMcABr63rImbD5uzErBfJIghvdJ EuwQ== 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=VErlL4YHHUR/5sWdGPliFrh3ywKT2unfrUALF00h9Pc=; b=pQwaoD1BwJm3j7wnj4p2bBHNQC91Q4tRAPIofV6sr0h6tIy3ctBXgiAHxqcamPpMN3 0IX7FOXs1+/6jd99Tmm6RDaMgAuTc6lY7lmCo1g8hsULsHpiTfxbXUSBFp8cAv/SBXv6 Zb6emqSeD8qK3+uGSB3jZ6e4CnddSyqkgJSQJFwttm/fGW+tuCBEW9k0Z6W/+9dTrTJB CQZrzKXST1gDd4EWofsdqQWgmpevGgqyVvMQQqDevKRT/pY+PSA3MMdGuoDEan4KhtCS QXz+6l9KNwy7SU+GfgCCbMdV8fgYnrYAY+0GdCeW8NjnVsw1yChS08OKikAa0QWgzAJ9 SH/w== X-Gm-Message-State: AElRT7ESnGyETGNhLH1o7gCiiZgEme8AcxvZB3xMMGF9AG8E0xJfF94s yZmoZw3IUAqefTYLdn43V9Q8xK8nlXGGgL92nrXmeA== X-Google-Smtp-Source: AG47ELv39TefLI1C5AJMYlvFgR2xYQ6MCB/bDCa0+JTSic9+JvU/8JbGYdnJtT3f+/YthbMcTHxMLWl2PEQG02XkYwA= X-Received: by 2002:a9d:4a77:: with SMTP id d52-v6mr22790923otj.136.1522061867766; Mon, 26 Mar 2018 03:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:7087:0:0:0:0:0 with HTTP; Mon, 26 Mar 2018 03:57:27 -0700 (PDT) In-Reply-To: <152195092400.481.12269806420495112458.idtracker@ietfa.amsl.com> References: <152195092400.481.12269806420495112458.idtracker@ietfa.amsl.com> From: Omer Levi Hevroni Date: Mon, 26 Mar 2018 13:57:27 +0300 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4579f05684ea4c8" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hevroni-oauth-seamless-flow-00.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, 26 Mar 2018 10:57:50 -0000 --000000000000f4579f05684ea4c8 Content-Type: text/plain; charset="UTF-8" Good afternoon :) I've submitted the draft again, this time with the WG name in it. Would appreciate review and feedback. Thanks Omer ---------- Forwarded message ---------- From: Date: Sun, Mar 25, 2018 at 7:08 AM Subject: New Version Notification for draft-hevroni-oauth-seamless-flow-00.txt To: Omer Levi Hevroni A new version of I-D, draft-hevroni-oauth-seamless-flow-00.txt has been successfully submitted by Omer Hevroni and posted to the IETF repository. Name: draft-hevroni-oauth-seamless-flow Revision: 00 Title: Seamless OAuth 2.0 Client Assertion Grant Document date: 2018-03-25 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hevroni-oauth- seamless-flow-00.txt Status: https://datatracker.ietf.org/doc/draft-hevroni-oauth- seamless-flow/ Htmlized: https://tools.ietf.org/html/draft-hevroni-oauth-seamless- flow-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hevroni-oauth- seamless-flow Abstract: This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000f4579f05684ea4c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good afternoon :)

I've submitted th= e draft again, this time with the WG name in it.

W= ould appreciate review and feedback.

Thanks
<= div>Omer
---------- Forwarded message = ----------
From: &l= t;internet-drafts@ietf.org&= gt;
Date: Sun, Mar 25, 2018 at 7:08 AM
Subject: New Version No= tification for draft-hevroni-oauth-seamless-flow-00.txt
To: Omer Levi He= vroni <omerlh@gmail.com>
<= br>

A new version of I-D, draft-hevroni-oauth-seamless-flow-00.txt
has been successfully submitted by Omer Hevroni and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hevroni-oauth-seamless-= flow
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seamless OAuth 2.0 Client Assertio= n Grant
Document date:=C2=A0 2018-03-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hevr= oni-oauth-seamless-flow-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hevroni-oauth-seam= less-flow/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-00<= /a>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hevroni-oauth-= seamless-flow


Abstract:
=C2=A0 =C2=A0This specification defines the use of a One Time Password, enc= oded as
=C2=A0 =C2=A0JSON Web Token (JWS) Bearer Token, as a means for requesting a= n OAuth
=C2=A0 =C2=A02.0 access token as well as for client authentication.




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.

The IETF Secretariat


--000000000000f4579f05684ea4c8-- From nobody Wed Mar 28 06:53:25 2018 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 4A38A12711E for ; Wed, 28 Mar 2018 06:53:24 -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=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 coxnml5tvY2p for ; Wed, 28 Mar 2018 06:53:20 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0120.outbound.protection.outlook.com [104.47.32.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308ED1270AC for ; Wed, 28 Mar 2018 06:53: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=h26TSQCkbzVxqYpkgZJkS4pjm28rCDN7OHA8+c0oCSQ=; b=g4RalYdNUzqjXbe0CVR1tk/4f1Ir+k040YS1X3WkiGGkTgeAkfD0C7yy5EAVvBIrjHmjKEo5/k0wz6JZhY9Do5Vp9kPApXiebb2DZnkF/cUIaasxn4P1w4erHr4U8bZUFJ52VWE13JYukjbjkUW89plEN4Lg5Wwl2Fif4wSor1k= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.671.0; Wed, 28 Mar 2018 13:53:14 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::3967:3414:4dfc:8eae]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::3967:3414:4dfc:8eae%4]) with mapi id 15.20.0671.000; Wed, 28 Mar 2018 13:53:14 +0000 From: Mike Jones To: "oauth@ietf.org" CC: "brockallen@gmail.com" , Nat Sakimura , Roberto Carbone , Giada Sciarretta Thread-Topic: What Does Logout Mean? Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvg== Date: Wed, 28 Mar 2018 13:53:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.211.129.242] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0293; 7:kSrE3tqdsJ0MPojTFieFqmmFHNl+3J3HVKQ2Y6rpzY8QuG2g02h3X7hqM4UeQFRta7I3ioxE5FaUxCcsRYb3u/tbakXgHAjAEeqPVqbtmgpQkdb2cszildU/iG2wVsnMarjh1hfbeWA6/rFhatSlX8+6X1U0pz5MVMOQE5IePEsbsB7eln7Sa1M0gi0ta3K2djfXC85/kTulu2zskDhdzmGlyy03UFpJ1goKW2xHY8L+me1lpS5nIiw+VJ9WxY+y; 20:jOUJwUqhaz5I8xr9kWyAVTx6LmBlSTySt666OFCngsZX5R44EQqsTDgB/VXfl0QUaCB9sdsDjrWxocfuGwqAoA/HB5n0JIhgMewAap769JYYGEP3kYzhr2kLasxEk0LOUuMmP/stNfb6VNEIzC75jyEE2XgfiwweTjeLdnCp9aI= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 019a6891-7820-49f9-3efb-08d594b34070 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0293; x-ms-traffictypediagnostic: DM5PR00MB0293: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(192374486261705)(31418570063057)(63843785518722)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0293; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0293; x-forefront-prvs: 06259BA5A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(39860400002)(39380400002)(209900001)(199004)(189003)(3280700002)(186003)(8990500004)(25786009)(2351001)(6346003)(478600001)(790700001)(99286004)(10090500001)(3660700001)(10290500003)(74316002)(106356001)(7736002)(5660300001)(6916009)(476003)(486005)(4326008)(486005)(7066003)(102836004)(59450400001)(3846002)(97736004)(5250100002)(7696005)(2501003)(26005)(6116002)(2900100001)(6506007)(606006)(14454004)(39060400002)(86362001)(3480700004)(316002)(66066001)(72206003)(54906003)(6436002)(53376002)(22452003)(8676002)(5630700001)(1730700003)(81166006)(81156014)(33656002)(105586002)(54896002)(9686003)(6306002)(8936002)(236005)(53936002)(68736007)(966005)(5640700003)(2906002)(55016002)(86612001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0293; H:DM5PR00MB0293.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: NnnJnaXhwSK5mtSdi7YzAclVgaFH/LoLoToASHX9tF441tze8nT7FtHQewiT9WBN2eR6IZgWPEjw8A9pzEtS7sX3cjhrTszi+PBaz5CQJcE1x+tWq/k392r9GyQL4gj0egkJZMWrydmTrfTBZBl7jWUU2v58heyzpIxOOSd6OTGiCEwEsWJUnUyCPbqm+EO1n2Fe0c3HxDUu1bFOyzzsDu6OnZJwqdhq2IEbcdT3Kca5bxR/C9sx/XRqgmVdsbHJuoGibKV0BaIcbVF+1Ndlh4nQI9CoshceBza5ac9ESIb4vaBU0PJk2vZAFO9NukMR+Syp35mwOZY8Ef31GxTT2A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02932B889807DF883C006512F5A30DM5PR00MB0293namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 019a6891-7820-49f9-3efb-08d594b34070 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2018 13:53:14.2216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0293 Archived-At: Subject: [OAUTH-WG] What Does Logout Mean? 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, 28 Mar 2018 13:53:24 -0000 --_000_DM5PR00MB02932B889807DF883C006512F5A30DM5PR00MB0293namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Digital identity systems almost universally support end-users logging into = applications and many also support logging out of them. But while login is= reasonable well understood, there are many different kinds of semantics fo= r "logout" in different use cases and a wide variety of mechanisms for effe= cting logouts. I led a discussion on the topic "What Does Logout Mean?" at the 2018 OAuth = Security Workshop in Trento, Italy, which was hel= d the week before IETF 101, to= explore this topic. The session was intentionally a highly interactive co= nversation, gathering information from the experts at the workshop to expan= d our collective understanding of the topic. Brock Allen - a practicing application security architect (and MVP for AS= P.NET/IIS) - significantly contributed to the materials used to seed the di= scussion. And Nat Sakimura took detail= ed notes to record what we learned during the discussion. Feedback on the discussion was uniformly positive. It seemed that all the = participants learned things about logout use cases, mechanisms, and limitat= ions that they previously hadn't previously considered. Materials related to the session are: * Presentation used to bootstrap the discussions (pptx) (pdf) * Notes from the session * Workshop submission (pdf) * OpenID Connect issue "Create a document explaining "single logout" se= mantics" -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1804 and as = @selfissued. --_000_DM5PR00MB02932B889807DF883C006512F5A30DM5PR00MB0293namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Digital identity systems almost universally support = end-users logging into applications and many also support logging out of th= em.  But while login is reasonable well understood, there are many dif= ferent kinds of semantics for “logout” in different use cases and a wide variety of mechanisms for effecting logo= uts.

 

I led a discussion on the topic “What Does Log= out Mean?” at the 2018 OAuth Security Workshop in Tr= ento, Italy, which was held the week before IETF 101, to ex= plore this topic.  The session was intentionally a highly interactive = conversation, gathering information from the experts at the workshop to exp= and our collective understanding of the topic.  Brock Allen = 211; a practicing application security architect (and MVP for ASP.NET/IIS) = – significantly contributed to the materials used to seed the discuss= ion.  And Nat Sakimura took detail= ed notes to record what we learned during the discussion.

 

Feedback on the discussion was uniformly positive.&n= bsp; It seemed that all the participants learned things about logout use ca= ses, mechanisms, and limitations that they previously hadn’t previous= ly considered.

 

Materials related to the session are:

--_000_DM5PR00MB02932B889807DF883C006512F5A30DM5PR00MB0293namp_-- From nobody Wed Mar 28 08:18:41 2018 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 06C631201FA for ; Wed, 28 Mar 2018 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hXs7EdDOnAe4 for ; Wed, 28 Mar 2018 08:18:37 -0700 (PDT) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) (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 29FB91273B1 for ; Wed, 28 Mar 2018 08:18:35 -0700 (PDT) Received: by mail-vk0-f49.google.com with SMTP id v205so137646vkv.13 for ; Wed, 28 Mar 2018 08:18:35 -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=Cgl6rtoCHSyaxXsQyGumFfSrMnJJtU6syI4VGgvXio4=; b=La5fwuItMvU9l6r9jhTbxXEWLmvYIYS/5zdWSVbwjz4ZM7Y4yh7bBrRi47Cf8Xvaow 982pWgDj6F57mtKYgE2lroBI/NosQdbWxTSkmiJYB5vK01B4YlNeLIine9Ej3hDDyuc3 oj3yWpoYMVWHZHNY7MhjaOstpk2S4imaqUCqJ+N00E8igjEDlJUsCdUvpdlkJl3cDQvF FvgBo1xoyrafpS6rZO65Kkz3gw02WcgDOXCf3iGTBcdYlWTelKyNCCnp4VLlasiKjbuL UqQfF9LexNgz5vwOyJpAg/ca2urz+4nJMZZShnUGq/fPTXMH6W27JRij+tRXAdg0BcG+ m1Wg== X-Gm-Message-State: AElRT7GTe7pnm2LvD1SU8pjiTYPMMYiHJotexpztgHsoBt71TJTX89lp Pi3C9M13r/RBpvk49MBXRI789lqHqCaonxt8xHxvzg== X-Google-Smtp-Source: AIpwx49FMN1jklcdsJTWIQokUrHN/N3vYrvbKAOPDUoGj6OvGfo65iOGws6G6l+2vuTyBlKbuOYTO38fWsDaPEJ2GmI= X-Received: by 10.31.181.141 with SMTP id e135mr2575541vkf.186.1522250314109; Wed, 28 Mar 2018 08:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.13.199 with HTTP; Wed, 28 Mar 2018 08:18:33 -0700 (PDT) In-Reply-To: References: From: Bill Burke Date: Wed, 28 Mar 2018 11:18:33 -0400 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" , Roberto Carbone , Nat Sakimura Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 28 Mar 2018 15:18:40 -0000 The biggest problem for us [1] is backchannel logout and we had to add a lot of proprietary protocols on top of OIDC's backchannel logout protocol. Specifically for "traditional" non-Javascript applications that have multiple endpoints behind a load balancer. You are really at the mercy of the application frameworks and infrastructure used to secure and cluster the application. If the framework has no way of invalidating a session across the cluster, then you're forced to register each endpoint and have the OP make a logout request to each of those endpoints. Even if the framework has a way to invalidate a session across a cluster, the the Session ID is owned and asserted by the OP. This means that the application framework has to have a way to associate the OP's Session ID with a local session. If there's no way to do this cross cluster, then you're often forced to fallback to registering each endpoint and the OP making individual backchannel logout requests to each RP endpoint. >From a product point of view, the only viable solution is to front apps with a security proxy. Otherwise you're resolving the problem for each and every application framework you'd provide an adapter/library for. [1] https://keycloak.org On Wed, Mar 28, 2018 at 9:53 AM, Mike Jones w= rote: > Digital identity systems almost universally support end-users logging int= o > applications and many also support logging out of them. But while login = is > reasonable well understood, there are many different kinds of semantics f= or > =E2=80=9Clogout=E2=80=9D in different use cases and a wide variety of mec= hanisms for > effecting logouts. > > > > I led a discussion on the topic =E2=80=9CWhat Does Logout Mean?=E2=80=9D = at the 2018 OAuth > Security Workshop in Trento, Italy, which was held the week before IETF 1= 01, > to explore this topic. The session was intentionally a highly interactiv= e > conversation, gathering information from the experts at the workshop to > expand our collective understanding of the topic. Brock Allen =E2=80=93 = a > practicing application security architect (and MVP for ASP.NET/IIS) =E2= =80=93 > significantly contributed to the materials used to seed the discussion. = And > Nat Sakimura took detailed notes to record what we learned during the > discussion. > > > > Feedback on the discussion was uniformly positive. It seemed that all th= e > participants learned things about logout use cases, mechanisms, and > limitations that they previously hadn=E2=80=99t previously considered. > > > > Materials related to the session are: > > Presentation used to bootstrap the discussions (pptx) (pdf) > Notes from the session > Workshop submission (pdf) > OpenID Connect issue =E2=80=9CCreate a document explaining "single logout= " > semantics=E2=80=9D > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1804 and a= s > @selfissued. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Bill Burke Red Hat From nobody Wed Mar 28 08:42:03 2018 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 288FD127369 for ; Wed, 28 Mar 2018 08:42:01 -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=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_Py2UkHIZcx for ; Wed, 28 Mar 2018 08:41:58 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 782C8120047 for ; Wed, 28 Mar 2018 08:41:57 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id p53so2667926wrc.10 for ; Wed, 28 Mar 2018 08:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=apvO8QymRLIF3OWltW3ta86MwrkMQZTxUENNpEQaLK4=; b=MV+0m+Aq4ToTQmTsk6b7t8Ssum2aNAMtMhG+TJMDhGPTQIjnprGoP+WhVM+mV3N7tD 7uln0WIJrV3L5g4nfS7UjKMF7Ol7WgrxxzG7opyFdEroK+5XK8xLNHSstNBEnfaNsR1L i3RudBHcMgnAsPfFUuCzBRefWY1i0+zfg+ngA= 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=apvO8QymRLIF3OWltW3ta86MwrkMQZTxUENNpEQaLK4=; b=BWjI+o6Xl3gLzaBtF+D2xPJvwAajT0YSYnpblJ2sHlB/G0b0nLMKlsj1CcLEzROOEm PWsu1UBayukMQPP5UdcfaBlSHpXsCH9SFvY6ec00klNxofvh9PZOEeg6CoYW3CivmmOY HzqcofwBPEdmdE2GGMZiWDt397chgnbpH4yAOVYCq4mW/fOG0hYh/2ctGUnzY37mqw2f C7DGr0UyAjysDuFylp3dUW3XyRo019zCj5Kgz4dyF4+pZYkEFEzg+9x9AmT81KQamIau nhHWZqD7XoSL6up5Qvp2Rwaivu8cE1AZH2syagCDMOspNAkiIR+fUnMeI9QH1CIERyrl g+oA== X-Gm-Message-State: AElRT7FmwVtvGOzwO/tRsVHepJoSkjPl+p/Tynn9E3jPp46S8wUPet3/ bWSSxXUdK0BIeZ7LwIOOZlu0WjRLmic= X-Google-Smtp-Source: AIpwx49Rz3X4w1u7FpKEt5BK+Euf/F3w9Q6sEpZUZT4fKHn4pC7p7s5FYWdNdmX2ISTg/CdVFq3Tlw== X-Received: by 10.223.158.6 with SMTP id u6mr3399391wre.142.1522251715835; Wed, 28 Mar 2018 08:41:55 -0700 (PDT) Received: from guest2s-mbp.home (148.199.93.209.dyn.plus.net. [209.93.199.148]) by smtp.gmail.com with ESMTPSA id l22sm5423064wmi.39.2018.03.28.08.41.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 08:41:54 -0700 (PDT) From: Neil Madden Message-Id: <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8B3DE103-8BE9-4A9E-802B-05B795F66E65"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 16:41:50 +0100 In-Reply-To: <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> Cc: oauth To: Torsten Lodderstedt References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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: Wed, 28 Mar 2018 15:42:01 -0000 --Apple-Mail=_8B3DE103-8BE9-4A9E-802B-05B795F66E65 Content-Type: multipart/alternative; boundary="Apple-Mail=_498D383B-8C65-4A12-AE52-42D6AA3A8BB5" --Apple-Mail=_498D383B-8C65-4A12-AE52-42D6AA3A8BB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I like this draft, but I want to clarify if it is intended that the = response JWT could be interpreted as an OpenID Connect ID Token? As the = set of claims can overlap (in particular, all required ID token claims = are valid token introspection response fields) and it seems highly = likely that an AS will use the same keys for signing both (and it = definitely will when the client_secret is used for signing), the signed = response JWT could well be indistinguishable from an ID token (for the = resource owner) with some additional claims. If this is not the case, then maybe consider adding a =E2=80=9Ccrit=E2=80=9D= : [=E2=80=9Cscope=E2=80=9D] claim to the response = (https://tools.ietf.org/html/rfc7515#section-4.1.11 = ) to indicate that = the scope claim must be understood. I can think of one potential use-case (I=E2=80=99ll let you decide the = merits of it) where it might actually be useful to explicitly allow the = response to be an ID Token. Consider an application (RS) that uses a = traditional authorization model: it authenticates a user, sets a cookie, = and then based on who that user is makes dynamic access control = decisions to see what they are allowed to do (e.g., ACLs, RBAC, = whatever). An easy way to upgrade this app to modern standards would be = to replace the home-spun authentication system with OIDC, but leave the = rest in place. Now the system uses OIDC to authenticate the user, sets = the ID token as the cookie, and then still applies the same access = control decisions that it always has done. Now imagine that a new requirement comes in to support OAuth 2.0 access = tokens to allow delegation to third-party apps. A really simple way to = achieve that would be to put a filter/reverse proxy in front of the RS = that extracts access tokens coming in, performs signed JWT token = introspection against the AS to validate the token and then checks the = the scopes are appropriate for the request. It can then simply replace = the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original = RS server. As the introspection response is a valid ID token for the = resource owner, the RS will then apply all its normal access control = checks to ensure that the resource owner actually has the permissions = that they have delegated to the client. I think potentially that is quite an interesting application of this = draft, but I don=E2=80=99t think it was intended! I think probably a = decision should be made as to whether that kind of usage should be = allowed and explicitly adjust the draft to either allow or deny it. If = it is allowed, then possibly there should be a way for the caller to = hint that they want the response to be a valid ID token. Kind regards, Neil > On 18 Mar 2018, at 19:33, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability). >=20 > I will present the new draft in the session on Wednesday. >=20 > kind regards, > Torsten. >=20 >> Anfang der weitergeleiteten Nachricht: >>=20 >> Von: internet-drafts@ietf.org >> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ >> An: "Vladimir Dzhuvinov" >, "Torsten Lodderstedt" = > >>=20 >>=20 >> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to = the >> IETF repository. >>=20 >> Name: = draft-lodderstedt-oauth-jwt-introspection-response >> Revision: 00 >> Title: JWT Response for OAuth Token Introspection >> Document date: 2018-03-15 >> Group: Individual Submission >> Pages: 5 >> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ = >> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response = >>=20 >>=20 >> Abstract: >> This draft proposes an additional JSON Web Token (JWT) based = response >> for OAuth 2.0 Token Introspection. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_498D383B-8C65-4A12-AE52-42D6AA3A8BB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = like this draft, but I want to clarify if it is intended that the = response JWT could be interpreted as an OpenID Connect ID Token? As the = set of claims can overlap (in particular, all required ID token claims = are valid token introspection response fields) and it seems highly = likely that an AS will use the same keys for signing both (and it = definitely will when the client_secret is used for signing), the signed = response JWT could well be indistinguishable from an ID token (for the = resource owner) with some additional claims.

If this is not the case, then maybe = consider adding a =E2=80=9Ccrit=E2=80=9D: [=E2=80=9Cscope=E2=80=9D] = claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) to = indicate that the scope claim must be understood.
I can think of one potential use-case = (I=E2=80=99ll let you decide the merits of it) where it might actually = be useful to explicitly allow the response to be an ID Token. Consider = an application (RS) that uses a traditional authorization model: it = authenticates a user, sets a cookie, and then based on who that user is = makes dynamic access control decisions to see what they are allowed to = do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to = modern standards would be to replace the home-spun authentication system = with OIDC, but leave the rest in place. Now the system uses OIDC to = authenticate the user, sets the ID token as the cookie, and then still = applies the same access control decisions that it always has = done.

Now = imagine that a new requirement comes in to support OAuth 2.0 access = tokens to allow delegation to third-party apps. A really simple way to = achieve that would be to put a filter/reverse proxy in front of the RS = that extracts access tokens coming in, performs signed JWT token = introspection against the AS to validate the token and then checks the = the scopes are appropriate for the request. It can then simply replace = the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original = RS server. As the introspection response is a valid ID token for the = resource owner, the RS will then apply all its normal access control = checks to ensure that the resource owner actually has the permissions = that they have delegated to the client.

I think potentially that is quite an = interesting application of this draft, but I don=E2=80=99t think it was = intended! I think probably a decision should be made as to whether that = kind of usage should be allowed and explicitly adjust the draft to = either allow or deny it. If it is allowed, then possibly there should be = a way for the caller to hint that they want the response to be a valid = ID token.

Kind = regards,

Neil

On 18 Mar 2018, at 19:33, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

I just submitted a new = draft that Vladimir Dzhuvinov and I have written. It proposes a = JWT-based response type for Token Introspection. The objective is to = provide resource servers with signed tokens in case they need = cryptographic evidence that the AS created the token (e.g. for = liability). 

I will present the new draft in the session on = Wednesday.

kind = regards,
Torsten. 

Anfang der weitergeleiteten Nachricht:

Von: internet-drafts@ietf.org
Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>


A new version = of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name: = = draft-lodderstedt-oauth-jwt-introspection-response
Revision: 00
Title: JWT = Response for OAuth Token Introspection
Document date: = 2018-03-15
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat


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

= --Apple-Mail=_498D383B-8C65-4A12-AE52-42D6AA3A8BB5-- --Apple-Mail=_8B3DE103-8BE9-4A9E-802B-05B795F66E65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy9aOUQwiH2bf8TjhkPhD307drF0FAlq7t74ACgkQkPhD307d rF2mhQ//Swv27DV3Zh599cFZWJsOk78HPMpguM4F4kkxUDA4fIPPOKzExmI/mBbJ gkQ3TYyaQwoYDoJ4YBlK/41PotVZGmt3PAbPM9+9/zwq3ghUd0kLzEg1deXTMqhI KrRN0GaT1QBZAsCvWg/MmqFZ9G7wIf5WVsN05mBKFOVYwfOGEOXNSQuJcAhwG05d YFdpU3BMFflEQakfknie8aM5Wsgcn6RNUX3vTr2ZUVoYW5Mv/QMSV74YSP0fopFK 1fz9kieBx42D9NqBhwvu+2bxS/y9OK648CL0DdJaTnFqOWuaijO8OANVOyb/0jZ9 s3Xe61cqIlHJgCI1KWeKTUtpKcLGd7PWVkcGHF+KkkerqiDqhzizuuOdBBS0BM5a 2GW3l/aOgw5qVeX/RfD09z2/2Ee48Xgca7OvwIVKviEHGsx2Symu/9TaAHqMWq2a otAqpd2XPfuFn+2vlNy0Aq55ZmFflT+RHLwE0KouUS9V1juZKeYp3CDYcc6RLp/a nRdTkRF/5r5GaBo+x6A8mcVt/gYYdr2AvTcjkm1LSGhGQhR381th2UybPVE75CzJ 1UwppqTS1Leusyg69gqsAYfe+JlneLVpEWLaL8OE8cY90QAxl4vhhDMBaiRUMscX V2mYgNp1WAkqyqWxvsdDS/hhG4oW4n1igG3WLbGbrbhf29Fxhis= =NAVD -----END PGP SIGNATURE----- --Apple-Mail=_8B3DE103-8BE9-4A9E-802B-05B795F66E65-- From nobody Wed Mar 28 10:40:56 2018 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 107291270B4 for ; Wed, 28 Mar 2018 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 elQu8HHz_sIK for ; Wed, 28 Mar 2018 10:40:50 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE39E126DED for ; Wed, 28 Mar 2018 10:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1522258850; x=1553794850; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3N3alRpH8CvfWNLjoKkWyEE6GM+kOa5iI2c80KbPw4g=; b=f5nV5aqJlx1WjRqMmdoWLsXjzbmMxpzufsnlXDj/B+2mr0ZL4/NHLBwu jLQMLtL6OG0xBuwEM7veEc+X/m1ECH5Itavn5n4BkREa7OTPrdlbKYXot eIcmcHXH+8i+VJpG0Sx+d+TcvT5/o+IkJRVzlIDqkueJVOVjy2ok//Ozp Q=; X-IronPort-AV: E=Sophos;i="5.48,372,1517875200"; d="scan'208,217";a="731608085" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2018 17:40:48 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w2SHekN4079427 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Mar 2018 17:40:48 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 17:40:47 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 17:40:47 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 28 Mar 2018 17:40:47 +0000 From: "Richard Backman, Annabelle" To: Bill Burke , Mike Jones CC: Roberto Carbone , "oauth@ietf.org" , "Nat Sakimura" Thread-Topic: [OAUTH-WG] What Does Logout Mean? Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvgA7mmyA//+yZIA= Date: Wed, 28 Mar 2018 17:40:47 +0000 Message-ID: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.20] Content-Type: multipart/alternative; boundary="_000_9A072F0C96A04F5C8FD076110AA2FA3Eamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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: Wed, 28 Mar 2018 17:40:54 -0000 --_000_9A072F0C96A04F5C8FD076110AA2FA3Eamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIHJlbWluZGVkIG9mIHRoaXMgc2Vzc2lvbiBmcm9tIElJVyAyMTxodHRwOi8vaWl3LmlkY29t bW9ucy5uZXQvV2hhdF9Eb2VzXyVFMiU4MCU5Q0xvZ09VVCVFMiU4MCU5OV9tZWFuJTNGPi4g4pi6 IEkgbG9vayBmb3J3YXJkIHRvIHJlYWRpbmcgdGhlIGRvY3VtZW50IGRpc3RpbGxpbmcgdGhlIHZh cmlvdXMgY29tcGV0aW5nIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGludG8gc29tZSBzZW1i bGFuY2Ugb2Ygc2FuaXR5Lg0KDQoNCg0KPiBJZiB0aGUgZnJhbWV3b3JrIGhhcyBubyB3YXkgb2Yg aW52YWxpZGF0aW5nIGEgc2Vzc2lvbiBhY3Jvc3MgdGhlIGNsdXN0ZXLigKYNCg0KDQoNCklzIHRo aXMgYSBjb21tb24gZGVmaWNpZW5jeSBpbiBhcHBsaWNhdGlvbiBmcmFtZXdvcmtzPyBJdCBzZWVt cyB0byBtZSB0aGF0IG11Y2ggb2YgdGhlIHZhbHVlIG9mIGEgc2VydmVyLXNpZGUgc2Vzc2lvbiBy ZWNvcmQgaXMgbG9zdCBpZiBpdHMgc3RhdGUgaXNu4oCZdCBzeW5jaHJvbml6ZWQgYWNyb3NzIHRo ZSBmbGVldC4NCg0KDQoNCi0tDQoNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCg0KQW1hem9u IOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQrvu79PbiAzLzI4LzE4LCA4OjE5IEFNLCAiT0F1dGgg b24gYmVoYWxmIG9mIEJpbGwgQnVya2UiIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBiYnVya2VAcmVkaGF0LmNvbT4gd3JvdGU6DQoNCg0KDQogICAgVGhlIGJpZ2dlc3QgcHJv YmxlbSBmb3IgdXMgWzFdIGlzIGJhY2tjaGFubmVsIGxvZ291dCBhbmQgd2UgaGFkIHRvIGFkZA0K DQogICAgYSBsb3Qgb2YgcHJvcHJpZXRhcnkgcHJvdG9jb2xzIG9uIHRvcCBvZiBPSURDJ3MgYmFj a2NoYW5uZWwgbG9nb3V0DQoNCiAgICBwcm90b2NvbC4gIFNwZWNpZmljYWxseSBmb3IgInRyYWRp dGlvbmFsIiBub24tSmF2YXNjcmlwdCBhcHBsaWNhdGlvbnMNCg0KICAgIHRoYXQgaGF2ZSBtdWx0 aXBsZSBlbmRwb2ludHMgYmVoaW5kIGEgbG9hZCBiYWxhbmNlci4gICBZb3UgYXJlIHJlYWxseQ0K DQogICAgYXQgdGhlIG1lcmN5IG9mIHRoZSBhcHBsaWNhdGlvbiBmcmFtZXdvcmtzIGFuZCBpbmZy YXN0cnVjdHVyZSB1c2VkIHRvDQoNCiAgICBzZWN1cmUgYW5kIGNsdXN0ZXIgdGhlIGFwcGxpY2F0 aW9uLiAgIElmIHRoZSBmcmFtZXdvcmsgaGFzIG5vIHdheSBvZg0KDQogICAgaW52YWxpZGF0aW5n IGEgc2Vzc2lvbiBhY3Jvc3MgdGhlIGNsdXN0ZXIsIHRoZW4geW91J3JlIGZvcmNlZCB0bw0KDQog ICAgcmVnaXN0ZXIgZWFjaCBlbmRwb2ludCBhbmQgaGF2ZSB0aGUgT1AgbWFrZSBhIGxvZ291dCBy ZXF1ZXN0IHRvIGVhY2gNCg0KICAgIG9mIHRob3NlIGVuZHBvaW50cy4gIEV2ZW4gaWYgdGhlIGZy YW1ld29yayBoYXMgYSB3YXkgdG8gaW52YWxpZGF0ZSBhDQoNCiAgICBzZXNzaW9uIGFjcm9zcyBh IGNsdXN0ZXIsIHRoZSB0aGUgU2Vzc2lvbiBJRCBpcyBvd25lZCBhbmQgYXNzZXJ0ZWQgYnkNCg0K ICAgIHRoZSBPUC4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgYXBwbGljYXRpb24gZnJhbWV3b3JrIGhh cyB0byBoYXZlIGEgd2F5DQoNCiAgICB0byBhc3NvY2lhdGUgdGhlIE9QJ3MgU2Vzc2lvbiBJRCB3 aXRoIGEgbG9jYWwgc2Vzc2lvbi4gIElmIHRoZXJlJ3Mgbm8NCg0KICAgIHdheSB0byBkbyB0aGlz IGNyb3NzIGNsdXN0ZXIsIHRoZW4geW91J3JlIG9mdGVuIGZvcmNlZCB0byBmYWxsYmFjayB0bw0K DQogICAgcmVnaXN0ZXJpbmcgZWFjaCBlbmRwb2ludCBhbmQgdGhlIE9QIG1ha2luZyBpbmRpdmlk dWFsIGJhY2tjaGFubmVsDQoNCiAgICBsb2dvdXQgcmVxdWVzdHMgdG8gZWFjaCBSUCBlbmRwb2lu dC4NCg0KDQoNCiAgICA+RnJvbSBhIHByb2R1Y3QgcG9pbnQgb2YgdmlldywgdGhlIG9ubHkgdmlh YmxlIHNvbHV0aW9uIGlzIHRvIGZyb250DQoNCiAgICBhcHBzIHdpdGggYSBzZWN1cml0eSBwcm94 eS4gIE90aGVyd2lzZSB5b3UncmUgcmVzb2x2aW5nIHRoZSBwcm9ibGVtDQoNCiAgICBmb3IgZWFj aCBhbmQgZXZlcnkgYXBwbGljYXRpb24gZnJhbWV3b3JrIHlvdSdkIHByb3ZpZGUgYW4NCg0KICAg IGFkYXB0ZXIvbGlicmFyeSBmb3IuDQoNCg0KDQogICAgWzFdIGh0dHBzOi8va2V5Y2xvYWsub3Jn DQoNCg0KDQogICAgT24gV2VkLCBNYXIgMjgsIDIwMTggYXQgOTo1MyBBTSwgTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KICAgID4gRGlnaXRhbCBpZGVu dGl0eSBzeXN0ZW1zIGFsbW9zdCB1bml2ZXJzYWxseSBzdXBwb3J0IGVuZC11c2VycyBsb2dnaW5n IGludG8NCg0KICAgID4gYXBwbGljYXRpb25zIGFuZCBtYW55IGFsc28gc3VwcG9ydCBsb2dnaW5n IG91dCBvZiB0aGVtLiAgQnV0IHdoaWxlIGxvZ2luIGlzDQoNCiAgICA+IHJlYXNvbmFibGUgd2Vs bCB1bmRlcnN0b29kLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQga2luZHMgb2Ygc2VtYW50aWNz IGZvcg0KDQogICAgPiDigJxsb2dvdXTigJ0gaW4gZGlmZmVyZW50IHVzZSBjYXNlcyBhbmQgYSB3 aWRlIHZhcmlldHkgb2YgbWVjaGFuaXNtcyBmb3INCg0KICAgID4gZWZmZWN0aW5nIGxvZ291dHMu DQoNCiAgICA+DQoNCiAgICA+DQoNCiAgICA+DQoNCiAgICA+IEkgbGVkIGEgZGlzY3Vzc2lvbiBv biB0aGUgdG9waWMg4oCcV2hhdCBEb2VzIExvZ291dCBNZWFuP+KAnSBhdCB0aGUgMjAxOCBPQXV0 aA0KDQogICAgPiBTZWN1cml0eSBXb3Jrc2hvcCBpbiBUcmVudG8sIEl0YWx5LCB3aGljaCB3YXMg aGVsZCB0aGUgd2VlayBiZWZvcmUgSUVURiAxMDEsDQoNCiAgICA+IHRvIGV4cGxvcmUgdGhpcyB0 b3BpYy4gIFRoZSBzZXNzaW9uIHdhcyBpbnRlbnRpb25hbGx5IGEgaGlnaGx5IGludGVyYWN0aXZl DQoNCiAgICA+IGNvbnZlcnNhdGlvbiwgZ2F0aGVyaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIGV4 cGVydHMgYXQgdGhlIHdvcmtzaG9wIHRvDQoNCiAgICA+IGV4cGFuZCBvdXIgY29sbGVjdGl2ZSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSB0b3BpYy4gIEJyb2NrIEFsbGVuIOKAkyBhDQoNCiAgICA+IHBy YWN0aWNpbmcgYXBwbGljYXRpb24gc2VjdXJpdHkgYXJjaGl0ZWN0IChhbmQgTVZQIGZvciBBU1Au TkVUL0lJUykg4oCTDQoNCiAgICA+IHNpZ25pZmljYW50bHkgY29udHJpYnV0ZWQgdG8gdGhlIG1h dGVyaWFscyB1c2VkIHRvIHNlZWQgdGhlIGRpc2N1c3Npb24uICBBbmQNCg0KICAgID4gTmF0IFNh a2ltdXJhIHRvb2sgZGV0YWlsZWQgbm90ZXMgdG8gcmVjb3JkIHdoYXQgd2UgbGVhcm5lZCBkdXJp bmcgdGhlDQoNCiAgICA+IGRpc2N1c3Npb24uDQoNCiAgICA+DQoNCiAgICA+DQoNCiAgICA+DQoN CiAgICA+IEZlZWRiYWNrIG9uIHRoZSBkaXNjdXNzaW9uIHdhcyB1bmlmb3JtbHkgcG9zaXRpdmUu ICBJdCBzZWVtZWQgdGhhdCBhbGwgdGhlDQoNCiAgICA+IHBhcnRpY2lwYW50cyBsZWFybmVkIHRo aW5ncyBhYm91dCBsb2dvdXQgdXNlIGNhc2VzLCBtZWNoYW5pc21zLCBhbmQNCg0KICAgID4gbGlt aXRhdGlvbnMgdGhhdCB0aGV5IHByZXZpb3VzbHkgaGFkbuKAmXQgcHJldmlvdXNseSBjb25zaWRl cmVkLg0KDQogICAgPg0KDQogICAgPg0KDQogICAgPg0KDQogICAgPiBNYXRlcmlhbHMgcmVsYXRl ZCB0byB0aGUgc2Vzc2lvbiBhcmU6DQoNCiAgICA+DQoNCiAgICA+IFByZXNlbnRhdGlvbiB1c2Vk IHRvIGJvb3RzdHJhcCB0aGUgZGlzY3Vzc2lvbnMgKHBwdHgpIChwZGYpDQoNCiAgICA+IE5vdGVz IGZyb20gdGhlIHNlc3Npb24NCg0KICAgID4gV29ya3Nob3Agc3VibWlzc2lvbiAocGRmKQ0KDQog ICAgPiBPcGVuSUQgQ29ubmVjdCBpc3N1ZSDigJxDcmVhdGUgYSBkb2N1bWVudCBleHBsYWluaW5n ICJzaW5nbGUgbG9nb3V0Ig0KDQogICAgPiBzZW1hbnRpY3PigJ0NCg0KICAgID4NCg0KICAgID4N Cg0KICAgID4NCg0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KICAgID4NCg0KICAgID4NCg0KICAgID4NCg0KICAg ID4gUC5TLiBUaGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0IGh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvLz9wPTE4MDQgYW5kIGFzDQoNCiAgICA+IEBzZWxmaXNzdWVkLg0KDQogICAgPg0KDQogICAg Pg0KDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQogICAgPiBPQXV0aCBtYWlsaW5nIGxpc3QNCg0KICAgID4gT0F1dGhAaWV0Zi5vcmcNCg0K ICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQogICAg Pg0KDQoNCg0KDQoNCg0KDQogICAgLS0NCg0KICAgIEJpbGwgQnVya2UNCg0KICAgIFJlZCBIYXQN Cg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQogICAgT0F1dGggbWFpbGluZyBsaXN0DQoNCiAgICBPQXV0aEBpZXRmLm9yZw0KDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg== --_000_9A072F0C96A04F5C8FD076110AA2FA3Eamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6AB68117280AE043A77274912EAAF166@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBD b2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ20gcmVtaW5kZWQgb2YgPGEgaHJlZj0iaHR0cDov L2lpdy5pZGNvbW1vbnMubmV0L1doYXRfRG9lc18lRTIlODAlOUNMb2dPVVQlRTIlODAlOTlfbWVh biUzRiI+DQp0aGlzIHNlc3Npb24gZnJvbSBJSVcgMjE8L2E+LiA8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPuKYujwvc3Bhbj4gSSBsb29rIGZv cndhcmQgdG8gcmVhZGluZyB0aGUgZG9jdW1lbnQgZGlzdGlsbGluZyB0aGUgdmFyaW91cyBjb21w ZXRpbmcgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgaW50byBzb21lIHNlbWJsYW5jZSBvZiBz YW5pdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSWYgdGhlIGZyYW1ld29y ayBoYXMgbm8gd2F5IG9mIGludmFsaWRhdGluZyBhIHNlc3Npb24gYWNyb3NzIHRoZSBjbHVzdGVy 4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklzIHRoaXMgYSBjb21tb24gZGVmaWNp ZW5jeSBpbiBhcHBsaWNhdGlvbiBmcmFtZXdvcmtzPyBJdCBzZWVtcyB0byBtZSB0aGF0IG11Y2gg b2YgdGhlIHZhbHVlIG9mIGEgc2VydmVyLXNpZGUgc2Vzc2lvbiByZWNvcmQgaXMgbG9zdCBpZiBp dHMgc3RhdGUgaXNu4oCZdCBzeW5jaHJvbml6ZWQgYWNyb3NzIHRoZSBmbGVldC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5BbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPu+7v09uIDMvMjgvMTgsIDg6MTkgQU0sICZxdW90O09BdXRoIG9uIGJlaGFs ZiBvZiBCaWxsIEJ1cmtlJnF1b3Q7ICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBiYnVya2VAcmVkaGF0LmNvbSZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgYmlnZ2VzdCBwcm9ibGVtIGZvciB1cyBbMV0g aXMgYmFja2NoYW5uZWwgbG9nb3V0IGFuZCB3ZSBoYWQgdG8gYWRkPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYSBsb3Qgb2YgcHJvcHJp ZXRhcnkgcHJvdG9jb2xzIG9uIHRvcCBvZiBPSURDJ3MgYmFja2NoYW5uZWwgbG9nb3V0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcHJv dG9jb2wuJm5ic3A7IFNwZWNpZmljYWxseSBmb3IgJnF1b3Q7dHJhZGl0aW9uYWwmcXVvdDsgbm9u LUphdmFzY3JpcHQgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBoYXZlIG11bHRpcGxlIGVuZHBvaW50cyBi ZWhpbmQgYSBsb2FkIGJhbGFuY2VyLiZuYnNwOyZuYnNwOyBZb3UgYXJlIHJlYWxseTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IHRo ZSBtZXJjeSBvZiB0aGUgYXBwbGljYXRpb24gZnJhbWV3b3JrcyBhbmQgaW5mcmFzdHJ1Y3R1cmUg dXNlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IHNlY3VyZSBhbmQgY2x1c3RlciB0aGUgYXBwbGljYXRpb24uJm5ic3A7Jm5ic3A7 IElmIHRoZSBmcmFtZXdvcmsgaGFzIG5vIHdheSBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludmFsaWRhdGluZyBhIHNlc3Npb24g YWNyb3NzIHRoZSBjbHVzdGVyLCB0aGVuIHlvdSdyZSBmb3JjZWQgdG88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyByZWdpc3RlciBlYWNo IGVuZHBvaW50IGFuZCBoYXZlIHRoZSBPUCBtYWtlIGEgbG9nb3V0IHJlcXVlc3QgdG8gZWFjaDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG9mIHRob3NlIGVuZHBvaW50cy4mbmJzcDsgRXZlbiBpZiB0aGUgZnJhbWV3b3JrIGhhcyBhIHdh eSB0byBpbnZhbGlkYXRlIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9uIGFjcm9zcyBhIGNsdXN0ZXIsIHRoZSB0aGUgU2Vz c2lvbiBJRCBpcyBvd25lZCBhbmQgYXNzZXJ0ZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgT1AuJm5ic3A7IFRoaXMgbWVh bnMgdGhhdCB0aGUgYXBwbGljYXRpb24gZnJhbWV3b3JrIGhhcyB0byBoYXZlIGEgd2F5PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdG8g YXNzb2NpYXRlIHRoZSBPUCdzIFNlc3Npb24gSUQgd2l0aCBhIGxvY2FsIHNlc3Npb24uJm5ic3A7 IElmIHRoZXJlJ3Mgbm88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyB3YXkgdG8gZG8gdGhpcyBjcm9zcyBjbHVzdGVyLCB0aGVuIHlvdSdy ZSBvZnRlbiBmb3JjZWQgdG8gZmFsbGJhY2sgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyByZWdpc3RlcmluZyBlYWNoIGVuZHBvaW50 IGFuZCB0aGUgT1AgbWFraW5nIGluZGl2aWR1YWwgYmFja2NoYW5uZWw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBsb2dvdXQgcmVxdWVz dHMgdG8gZWFjaCBSUCBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDtGcm9tIGEgcHJvZHVjdCBwb2lu dCBvZiB2aWV3LCB0aGUgb25seSB2aWFibGUgc29sdXRpb24gaXMgdG8gZnJvbnQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBhcHBzIHdp dGggYSBzZWN1cml0eSBwcm94eS4mbmJzcDsgT3RoZXJ3aXNlIHlvdSdyZSByZXNvbHZpbmcgdGhl IHByb2JsZW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBmb3IgZWFjaCBhbmQgZXZlcnkgYXBwbGljYXRpb24gZnJhbWV3b3JrIHlvdSdk IHByb3ZpZGUgYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyBhZGFwdGVyL2xpYnJhcnkgZm9yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7WzFdIGh0dHBzOi8v a2V5Y2xvYWsub3JnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPbiBXZWQsIE1hciAyOCwgMjAxOCBhdCA5OjUzIEFNLCBN aWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgRGlnaXRhbCBpZGVudGl0eSBzeXN0ZW1zIGFsbW9zdCB1bml2ZXJzYWxseSBzdXBwb3J0IGVu ZC11c2VycyBsb2dnaW5nIGludG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFwcGxpY2F0aW9ucyBhbmQgbWFueSBhbHNvIHN1 cHBvcnQgbG9nZ2luZyBvdXQgb2YgdGhlbS4mbmJzcDsgQnV0IHdoaWxlIGxvZ2luIGlzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyByZWFzb25hYmxlIHdlbGwgdW5kZXJzdG9vZCwgdGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IGtp bmRzIG9mIHNlbWFudGljcyBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IOKAnGxvZ291dOKAnSBpbiBkaWZmZXJlbnQgdXNl IGNhc2VzIGFuZCBhIHdpZGUgdmFyaWV0eSBvZiBtZWNoYW5pc21zIGZvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZWZmZWN0 aW5nIGxvZ291dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJIGxlZCBhIGRpc2N1c3Np b24gb24gdGhlIHRvcGljIOKAnFdoYXQgRG9lcyBMb2dvdXQgTWVhbj/igJ0gYXQgdGhlIDIwMTgg T0F1dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IFNlY3VyaXR5IFdvcmtzaG9wIGluIFRyZW50bywgSXRhbHksIHdoaWNoIHdh cyBoZWxkIHRoZSB3ZWVrIGJlZm9yZSBJRVRGIDEwMSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRvIGV4cGxvcmUgdGhpcyB0 b3BpYy4mbmJzcDsgVGhlIHNlc3Npb24gd2FzIGludGVudGlvbmFsbHkgYSBoaWdobHkgaW50ZXJh Y3RpdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGNvbnZlcnNhdGlvbiwgZ2F0aGVyaW5nIGluZm9ybWF0aW9uIGZyb20gdGhl IGV4cGVydHMgYXQgdGhlIHdvcmtzaG9wIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBleHBhbmQgb3VyIGNvbGxlY3RpdmUg dW5kZXJzdGFuZGluZyBvZiB0aGUgdG9waWMuJm5ic3A7IEJyb2NrIEFsbGVuIOKAkyBhPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBwcmFjdGljaW5nIGFwcGxpY2F0aW9uIHNlY3VyaXR5IGFyY2hpdGVjdCAoYW5kIE1WUCBmb3Ig QVNQLk5FVC9JSVMpIOKAkzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc2lnbmlmaWNhbnRseSBjb250cmlidXRlZCB0byB0aGUg bWF0ZXJpYWxzIHVzZWQgdG8gc2VlZCB0aGUgZGlzY3Vzc2lvbi4mbmJzcDsgQW5kPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBO YXQgU2FraW11cmEgdG9vayBkZXRhaWxlZCBub3RlcyB0byByZWNvcmQgd2hhdCB3ZSBsZWFybmVk IGR1cmluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBGZWVkYmFjayBvbiB0aGUgZGlzY3Vzc2lvbiB3YXMgdW5pZm9ybWx5IHBvc2l0aXZlLiZuYnNw OyBJdCBzZWVtZWQgdGhhdCBhbGwgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwYXJ0aWNpcGFudHMgbGVhcm5lZCB0aGlu Z3MgYWJvdXQgbG9nb3V0IHVzZSBjYXNlcywgbWVjaGFuaXNtcywgYW5kPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBsaW1pdGF0 aW9ucyB0aGF0IHRoZXkgcHJldmlvdXNseSBoYWRu4oCZdCBwcmV2aW91c2x5IGNvbnNpZGVyZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBNYXRlcmlhbHMgcmVsYXRlZCB0byB0aGUgc2Vz c2lvbiBhcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUHJlc2VudGF0aW9uIHVzZWQgdG8gYm9vdHN0cmFwIHRo ZSBkaXNjdXNzaW9ucyAocHB0eCkgKHBkZik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE5vdGVzIGZyb20gdGhlIHNlc3Npb248 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IFdvcmtzaG9wIHN1Ym1pc3Npb24gKHBkZik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9wZW5JRCBDb25uZWN0IGlz c3VlIOKAnENyZWF0ZSBhIGRvY3VtZW50IGV4cGxhaW5pbmcgJnF1b3Q7c2luZ2xlIGxvZ291dCZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgc2VtYW50aWNz4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBQLlMuIFRoaXMgbm90ZSB3YXMgYWxzbyBwb3N0ZWQgYXQgaHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTgwNCBhbmQgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEBzZWxmaXNzdWVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBPQXV0aEBpZXRmLm9y ZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JpbGwgQnVya2U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBSZWQg SGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYub3JnPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9A072F0C96A04F5C8FD076110AA2FA3Eamazoncom_-- From nobody Wed Mar 28 11:25:32 2018 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 4CC161201F2 for ; Wed, 28 Mar 2018 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jzXsrfpU94pq for ; Wed, 28 Mar 2018 11:25:28 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id B3221124E15 for ; Wed, 28 Mar 2018 11:25:28 -0700 (PDT) Received: from [IPv6:2601:282:281:2e95:4911:e1e9:fd59:ca0a] (unknown [IPv6:2601:282:281:2e95:4911:e1e9:fd59:ca0a]) by alkaline-solutions.com (Postfix) with ESMTPSA id 6AA2D3160C; Wed, 28 Mar 2018 18:25:25 +0000 (UTC) From: David Waite Message-Id: <3531401A-6D49-4447-AC05-B93E7798C5FA@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D1BE0F43-68A9-4728-8134-E05E4AC83580" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 12:25:23 -0600 In-Reply-To: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> Cc: Bill Burke , Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura To: "Richard Backman, Annabelle" References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 28 Mar 2018 18:25:31 -0000 --Apple-Mail=_D1BE0F43-68A9-4728-8134-E05E4AC83580 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle = wrote: >=20 > I'm reminded of this session from IIW 21 = . = =E2=98=BA I look forward to reading the document distilling the various = competing use cases and requirements into some semblance of sanity. I was just thinking how much I=E2=80=99d like to discuss this at an IIW. = While developing the DTVA submission I wound up taking IMHO a different = stance on sessions and logout, both technically and conceptually. > =20 > > If the framework has no way of invalidating a session across the = cluster=E2=80=A6 > =20 > Is this a common deficiency in application frameworks? It seems to me = that much of the value of a server-side session record is lost if its = state isn=E2=80=99t synchronized across the fleet. Most application frameworks are relatively simple - they initiate a = session and maintain it locally. They don=E2=80=99t have a single = session record that is maintained across all applications in a domain. = Even frameworks with native support for federation protocols or = form-based SSO wind up using this authentication to create an = application-specific session. Many also attempt to maintain the session information in an ideally = integrity-protected, time limited, etc cookie, similar to an access = token, rather than having a database within their application for = synchronizing the session state. You wind up needing an additional state = mechanism in this case to record invalidated sessions/tokens, which is = typically not provided by frameworks. This was one of the primary focuses of my DTVA submission - a REST API = where you could submit the `sid` of a token in order to find out if it = had been invalidated. If you were using some cookie-based storage = mechanism, tossing the `sid` in let you make this API call after = discarding the id_token - hopefully allowing for application developers = to add checks for an invalidated session as part of their global = pipeline. -DW= --Apple-Mail=_D1BE0F43-68A9-4728-8134-E05E4AC83580 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

I'm reminded of this session from IIW 21. =E2=98=BA I look forward to reading = the document distilling the various competing use cases and requirements = into some semblance of sanity.

I was just thinking how much I=E2=80=99d like to = discuss this at an IIW. While developing the DTVA submission I wound up = taking IMHO a different stance on sessions and logout, both technically = and conceptually.

 
> If = the framework has no way of invalidating a session across the = cluster=E2=80=A6
 
Is this a common deficiency in application frameworks? It = seems to me that much of the value of a server-side session record is = lost if its state isn=E2=80=99t synchronized across the = fleet.

Most = application frameworks are relatively simple - they initiate a session = and maintain it locally. They don=E2=80=99t have a single session record = that is maintained across all applications in a domain. Even frameworks = with native support for federation protocols or form-based SSO wind up = using this authentication to create an application-specific = session.

Many also attempt to = maintain the session information in an ideally integrity-protected, time = limited, etc cookie, similar to an access token, rather than having a = database within their application for synchronizing the session state. = You wind up needing an additional state mechanism in this case to record = invalidated sessions/tokens, which is typically not provided by = frameworks.

This was one of the = primary focuses of my DTVA submission - a REST API where you could = submit the `sid` of a token in order to find out if it had been = invalidated. If you were using some cookie-based storage mechanism, = tossing the `sid` in let you make this API call after discarding the = id_token - hopefully allowing for application developers to add checks = for an invalidated session as part of their global = pipeline.

-DW
= --Apple-Mail=_D1BE0F43-68A9-4728-8134-E05E4AC83580-- From nobody Wed Mar 28 12:09:16 2018 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 B2E5B1275AB for ; Wed, 28 Mar 2018 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QmK6JyPLmath for ; Wed, 28 Mar 2018 12:09:13 -0700 (PDT) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) (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 1700A1274D2 for ; Wed, 28 Mar 2018 12:09:13 -0700 (PDT) Received: by mail-ua0-f177.google.com with SMTP id n20so2207024ual.7 for ; Wed, 28 Mar 2018 12:09:13 -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=Y4Ueb+0GaQqH+PwqAFVjs8gkg4Z79ukE3PL1eINHueM=; b=r2wAvEN/OWXuZlEMxble8m3E+EWIoQazt7otp6eeC/nf7U0c/fhbnJjnhG3U/1Qhy5 HHIS1Ad6ZV4D0KpHUzpAycUTeJisFLKoHnkiUPhrYQrmuh+Ws5vY3Pe9j30dtbuIAYHd 8IXhg4kRc4XUTi+vbe3AFhQYIP1x8B6F6c+cJTwuOBP1ATtHaQnEmgjeLauoEqPCD195 gaZR0n0l4Rl6R4n5evEZ5vCmA3p7VJHPUyfV/z9yzypOZlZWM8ODgRkZnMWiYp7hOadD mJbZ+qUr0USuQxmX5L1Hul9LGCxsLz9DbGOmePKdamiaEcFQnglQtmb+rkDOAghqnEmL xeKg== X-Gm-Message-State: AElRT7EAwyq6ya9pS4rY42EqO1fRe2jSbgrRuHrHEX+5n+uy5vN+rzCg hR8Cp/NkizFt4El4RTS9iXnsskHJHmgLDB76wL+DZw== X-Google-Smtp-Source: AIpwx4/sZUHsJTFubXalgshjemxcLBwY+v5w0v7RzqXWXxdL9h3hw++EEJFtn1IX2faac/0vaQiMoXYPrbhEO4rdSfw= X-Received: by 10.176.78.203 with SMTP id x11mr3239546uah.91.1522264152120; Wed, 28 Mar 2018 12:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.13.199 with HTTP; Wed, 28 Mar 2018 12:09:11 -0700 (PDT) In-Reply-To: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> From: Bill Burke Date: Wed, 28 Mar 2018 15:09:11 -0400 Message-ID: To: "Richard Backman, Annabelle" Cc: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Content-Type: multipart/alternative; boundary="089e08e4f9930ab68a05687dbeba" Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 28 Mar 2018 19:09:16 -0000 --089e08e4f9930ab68a05687dbeba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle < richanna@amazon.com> wrote: > I'm reminded of this session from IIW 21 > . = =E2=98=BA > I look forward to reading the document distilling the various competing u= se > cases and requirements into some semblance of sanity. > > > > > If the framework has no way of invalidating a session across the cluste= r=E2=80=A6 > > > > Is this a common deficiency in application frameworks? It seems to me tha= t > much of the value of a server-side session record is lost if its state > isn=E2=80=99t synchronized across the fleet. > > > "modern" apps are REST based with Javascript frontends, but there's still a ton of "old school" developers out there. Was involved with developing an application server for over a decade (JBoss)...There were many app developers that didn't want to store app session information in a database (as David says) or deal with the headaches of session replication so they just set up their load balancer to do session affinity (sticky sessions). That way the login session was always local. If the oidc logout spec allowed the client to register logout callback tied to the token's session (like maybe during code to token), that might be a simple way to solve many of these issues too. --089e08e4f9930ab68a05687dbeba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle <richa= nna@amazon.com> wrote:

I'm reminded of this session from IIW 21. =E2=98=BA I look forward to reading the document distil= ling the various competing use cases and requirements into some semblance o= f sanity.

=C2=A0

> If the framework has no= way of invalidating a session across the cluster=E2=80=A6

=C2=A0

Is this a common deficiency = in application frameworks? It seems to me that much of the value of a serve= r-side session record is lost if its state isn=E2=80=99t synchronized acros= s the fleet.

=C2=A0

"modern" apps are REST based with Javas= cript frontends, but there's still a ton of "old school" deve= lopers out there.

Was involved with developing an application s= erver for over a decade (JBoss)...There were many app developers that didn&= #39;t want to store app session information in a database (as David says) o= r deal with the headaches of session replication so they just set up their = load balancer to do session affinity (sticky sessions).=C2=A0 That way the = login session was always local.=C2=A0 If the oidc logout spec allowed the c= lient to register logout callback tied to the token's session (like may= be during code to token), that might be a simple way to solve many of these= issues too.


--089e08e4f9930ab68a05687dbeba-- From nobody Wed Mar 28 13:10:09 2018 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 6A127120227 for ; Wed, 28 Mar 2018 13:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 RThjxJ8tGsu3 for ; Wed, 28 Mar 2018 13:10:04 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5423F1200F1 for ; Wed, 28 Mar 2018 13:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1522267804; x=1553803804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xdUkRpNZbmbdFU9fJhVp4jJG/c/pQDbrQhQKqFUYm7I=; b=TBG4l3wsN1HmGgQwbBUiwqQXfuwDIADq3MCxBsYsIhlibLQWSP8kHA49 4ePGrjJYnHYgudVkVvonKV6TcIkFwPkuqRWwWKVyGbx20c/o9b5qiDhb+ OfyznP3rVN+zvt1o9t2xIhoevu1e/lZ1y5XaeyfWBbG06fdO+AwM/J0CP s=; X-IronPort-AV: E=Sophos;i="5.48,372,1517875200"; d="scan'208,217";a="713827208" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2018 20:10:02 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2SK9wFO023797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Mar 2018 20:10:00 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 20:10:00 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 20:09:59 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 28 Mar 2018 20:09:59 +0000 From: "Richard Backman, Annabelle" To: Bill Burke CC: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Thread-Topic: [OAUTH-WG] What Does Logout Mean? Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvgA7mmyA//+yZICAAI4MgP//m6SA Date: Wed, 28 Mar 2018 20:09:59 +0000 Message-ID: References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.16] Content-Type: multipart/alternative; boundary="_000_BA42F798A4E643D99A93D85C6C5AF4AAamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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: Wed, 28 Mar 2018 20:10:07 -0000 --_000_BA42F798A4E643D99A93D85C6C5AF4AAamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBtYWtlcyBzb21ld2hhdCBtb3JlIHNlbnNlIHRvIG1lIGlmIHdl4oCZcmUgdGFsa2luZyBh Ym91dCBhcHBsaWNhdGlvbnMgd2l0aCBzdGlja3kgc2Vzc2lvbnMuIEFkZGluZyBhIHNlc3Npb24t c3BlY2lmaWMgbG9nb3V0IFVSSSBpbnRyb2R1Y2VzIHNlY3VyaXR5IGNvbmNlcm5zIChlLmcuIGhv dyBkb2VzIHRoZSBPUCB2YWxpZGF0ZSB0aGUgVVJJKSBhbmQgb25seSB3b3JrcyBpZiB0aGUgUlAg Y2FuIHByb3ZpZGUgVVJJcyB0aGF0IHRhcmdldCBpbmRpdmlkdWFsIGhvc3RzIGluIHRoZWlyIGZs ZWV0LiBUaGUg4oCcaXMgdGhpcyBTSUQgdmFsaWQ/4oCdIGVuZHBvaW50IHNvbHV0aW9uIHRoYXQg RGF2aWQgZGVzY3JpYmVkIGRvZXNu4oCZdCBzY2FsZSBhbmQgZGVwZW5kcyBvbiBTSUQgKHdoaWNo IGlzIE9QVElPTkFMKS4gQm90aCBzaGlmdCB0aGUgYnVyZGVuIG9mIHN0YXRlIG1hbmFnZW1lbnQg b250byB0aGUgT1AsIHdoaWNoIG1heSBub3QgYmUgaW4gYW55IGJldHRlciBwb3NpdGlvbiB0byBo YW5kbGUgaXQuDQoNClRoaXMgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBh ZGRyZXNzZWQgaW4gdGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgcmF0aGVyIHRoYW4gaW4gdGhl IHNwZWNpZmljYXRpb24uIEVzcGVjaWFsbHkgd2hlbiB3ZSBjb25zaWRlciB0aGF0IHRoZXJlIGFy ZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBxdWVzdGlvbnMgbHVya2luZyBpbiB0aGUgZWRnZSBj YXNlcy4gKGUuZy4gd2hhdCBoYXBwZW5zIHdoZW4gYSB1c2VyIGNvbWVzIGluIHdpdGggdmFsaWQg Y29va2llcywgYnV0IG5vIHNlcnZlci1zaWRlIHNlc3Npb24gc3RhdGU/KQ0KDQotLQ0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9t OiBCaWxsIEJ1cmtlIDxiYnVya2VAcmVkaGF0LmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTWFyY2gg MjgsIDIwMTggYXQgMTI6MTAgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxy aWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4sIFJvYmVydG8gQ2FyYm9uZSA8Y2FyYm9uZUBmYmsuZXU+LCAib2F1dGhAaWV0Zi5v cmciIDxvYXV0aEBpZXRmLm9yZz4sIE5hdCBTYWtpbXVyYSA8bmF0QHNha2ltdXJhLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdoYXQgRG9lcyBMb2dvdXQgTWVhbj8NCg0KDQoNCk9uIFdl ZCwgTWFyIDI4LCAyMDE4IGF0IDE6NDAgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxy aWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQoN CkknbSByZW1pbmRlZCBvZiB0aGlzIHNlc3Npb24gZnJvbSBJSVcgMjE8aHR0cDovL2lpdy5pZGNv bW1vbnMubmV0L1doYXRfRG9lc18lRTIlODAlOUNMb2dPVVQlRTIlODAlOTlfbWVhbiUzRj4uIOKY uiBJIGxvb2sgZm9yd2FyZCB0byByZWFkaW5nIHRoZSBkb2N1bWVudCBkaXN0aWxsaW5nIHRoZSB2 YXJpb3VzIGNvbXBldGluZyB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBpbnRvIHNvbWUgc2Vt YmxhbmNlIG9mIHNhbml0eS4NCg0KDQoNCj4gSWYgdGhlIGZyYW1ld29yayBoYXMgbm8gd2F5IG9m IGludmFsaWRhdGluZyBhIHNlc3Npb24gYWNyb3NzIHRoZSBjbHVzdGVy4oCmDQoNCg0KDQpJcyB0 aGlzIGEgY29tbW9uIGRlZmljaWVuY3kgaW4gYXBwbGljYXRpb24gZnJhbWV3b3Jrcz8gSXQgc2Vl bXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSB2YWx1ZSBvZiBhIHNlcnZlci1zaWRlIHNlc3Npb24g cmVjb3JkIGlzIGxvc3QgaWYgaXRzIHN0YXRlIGlzbuKAmXQgc3luY2hyb25pemVkIGFjcm9zcyB0 aGUgZmxlZXQuDQoNCg0KIm1vZGVybiIgYXBwcyBhcmUgUkVTVCBiYXNlZCB3aXRoIEphdmFzY3Jp cHQgZnJvbnRlbmRzLCBidXQgdGhlcmUncyBzdGlsbCBhIHRvbiBvZiAib2xkIHNjaG9vbCIgZGV2 ZWxvcGVycyBvdXQgdGhlcmUuDQoNCldhcyBpbnZvbHZlZCB3aXRoIGRldmVsb3BpbmcgYW4gYXBw bGljYXRpb24gc2VydmVyIGZvciBvdmVyIGEgZGVjYWRlIChKQm9zcykuLi5UaGVyZSB3ZXJlIG1h bnkgYXBwIGRldmVsb3BlcnMgdGhhdCBkaWRuJ3Qgd2FudCB0byBzdG9yZSBhcHAgc2Vzc2lvbiBp bmZvcm1hdGlvbiBpbiBhIGRhdGFiYXNlIChhcyBEYXZpZCBzYXlzKSBvciBkZWFsIHdpdGggdGhl IGhlYWRhY2hlcyBvZiBzZXNzaW9uIHJlcGxpY2F0aW9uIHNvIHRoZXkganVzdCBzZXQgdXAgdGhl aXIgbG9hZCBiYWxhbmNlciB0byBkbyBzZXNzaW9uIGFmZmluaXR5IChzdGlja3kgc2Vzc2lvbnMp LiAgVGhhdCB3YXkgdGhlIGxvZ2luIHNlc3Npb24gd2FzIGFsd2F5cyBsb2NhbC4gIElmIHRoZSBv aWRjIGxvZ291dCBzcGVjIGFsbG93ZWQgdGhlIGNsaWVudCB0byByZWdpc3RlciBsb2dvdXQgY2Fs bGJhY2sgdGllZCB0byB0aGUgdG9rZW4ncyBzZXNzaW9uIChsaWtlIG1heWJlIGR1cmluZyBjb2Rl IHRvIHRva2VuKSwgdGhhdCBtaWdodCBiZSBhIHNpbXBsZSB3YXkgdG8gc29sdmUgbWFueSBvZiB0 aGVzZSBpc3N1ZXMgdG9vLg0KDQoNCg== --_000_BA42F798A4E643D99A93D85C6C5AF4AAamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5AE28F7561518B49ACED9B6E5BBA3D43@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkFwcGxlIENvbG9yIEVtb2ppIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5t MTc2MTYzMTQxMTIxMzQzNDQ4Mm1zb3BsYWludGV4dCwgbGkubTE3NjE2MzE0MTEyMTM0MzQ0ODJt c29wbGFpbnRleHQsIGRpdi5tMTc2MTYzMTQxMTIxMzQzNDQ4Mm1zb3BsYWludGV4dA0KCXttc28t c3R5bGUtbmFtZTptXzE3NjE2MzE0MTEyMTM0MzQ0ODJtc29wbGFpbnRleHQ7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc0MjA3NDA0Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5NzA3MTk2ODAgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDg0OTMwOTY4Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5MjIyMjk0NDggNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGF0IG1ha2VzIHNvbWV3aGF0IG1vcmUgc2Vuc2UgdG8gbWUgaWYgd2XigJlyZSB0YWxraW5n IGFib3V0IGFwcGxpY2F0aW9ucyB3aXRoIHN0aWNreSBzZXNzaW9ucy4gQWRkaW5nIGEgc2Vzc2lv bi1zcGVjaWZpYyBsb2dvdXQgVVJJIGludHJvZHVjZXMgc2VjdXJpdHkgY29uY2VybnMgKGUuZy4g aG93IGRvZXMgdGhlIE9QIHZhbGlkYXRlIHRoZSBVUkkpIGFuZCBvbmx5IHdvcmtzIGlmIHRoZSBS UCBjYW4gcHJvdmlkZQ0KIFVSSXMgdGhhdCB0YXJnZXQgaW5kaXZpZHVhbCBob3N0cyBpbiB0aGVp ciBmbGVldC4gVGhlIOKAnGlzIHRoaXMgU0lEIHZhbGlkP+KAnSBlbmRwb2ludCBzb2x1dGlvbiB0 aGF0IERhdmlkIGRlc2NyaWJlZCBkb2VzbuKAmXQgc2NhbGUgYW5kIGRlcGVuZHMgb24gU0lEICh3 aGljaCBpcyBPUFRJT05BTCkuIEJvdGggc2hpZnQgdGhlIGJ1cmRlbiBvZiBzdGF0ZSBtYW5hZ2Vt ZW50IG9udG8gdGhlIE9QLCB3aGljaCBtYXkgbm90IGJlIGluIGFueSBiZXR0ZXIgcG9zaXRpb24N CiB0byBoYW5kbGUgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2VlbXMgbGlrZSBz b21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4gdGhlIGNsaWVudCBpbXBsZW1l bnRhdGlvbnMgcmF0aGVyIHRoYW4gaW4gdGhlIHNwZWNpZmljYXRpb24uIEVzcGVjaWFsbHkgd2hl biB3ZSBjb25zaWRlciB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBxdWVz dGlvbnMgbHVya2luZyBpbiB0aGUgZWRnZSBjYXNlcy4gKGUuZy4gd2hhdCBoYXBwZW5zDQogd2hl biBhIHVzZXIgY29tZXMgaW4gd2l0aCB2YWxpZCBjb29raWVzLCBidXQgbm8gc2VydmVyLXNpZGUg c2Vzc2lvbiBzdGF0ZT8pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij5BbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CaWxsIEJ1cmtlICZsdDtiYnVya2VAcmVk aGF0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxOCBh dCAxMjoxMCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5NaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7LCBSb2JlcnRvIENhcmJv bmUgJmx0O2NhcmJvbmVAZmJrLmV1Jmd0OywgJnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0 O29hdXRoQGlldGYub3JnJmd0OywgTmF0IFNha2ltdXJhICZsdDtuYXRAc2FraW11cmEub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBXaGF0IERvZXMgTG9nb3V0IE1l YW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L2E+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5PbiBXZWQsIE1hciAyOCwgMjAxOCBhdCAxOjQwIFBNLCBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTE3NjE2MzE0MTEyMTM0MzQ0 ODJtc29wbGFpbnRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPkknbSByZW1pbmRlZCBvZg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9paXcuaWRjb21tb25z Lm5ldC9XaGF0X0RvZXNfJUUyJTgwJTlDTG9nT1VUJUUyJTgwJTk5X21lYW4lM0YiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij50aGlz IHNlc3Npb24gZnJvbSBJSVcgMjE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4uDQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVt b2ppJnF1b3Q7Ij7imLo8L3NwYW4+IEkgbG9vayBmb3J3YXJkIHRvIHJlYWRpbmcgdGhlIGRvY3Vt ZW50IGRpc3RpbGxpbmcgdGhlIHZhcmlvdXMgY29tcGV0aW5nIHVzZSBjYXNlcyBhbmQgcmVxdWly ZW1lbnRzIGludG8gc29tZSBzZW1ibGFuY2Ugb2Ygc2FuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJtMTc2MTYzMTQxMTIxMzQzNDQ4Mm1zb3BsYWludGV4dCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Im0xNzYxNjMxNDExMjEzNDM0NDgybXNvcGxhaW50ZXh0Ij48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7IElmIHRoZSBmcmFt ZXdvcmsgaGFzIG5vIHdheSBvZiBpbnZhbGlkYXRpbmcgYSBzZXNzaW9uIGFjcm9zcyB0aGUgY2x1 c3RlcuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtMTc2MTYzMTQxMTIxMzQz NDQ4Mm1zb3BsYWludGV4dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im0xNzYxNjMxNDEx MjEzNDM0NDgybXNvcGxhaW50ZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5JcyB0aGlzIGEgY29tbW9uIGRlZmljaWVuY3kgaW4gYXBwbGljYXRpb24gZnJh bWV3b3Jrcz8gSXQgc2VlbXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSB2YWx1ZSBvZiBhIHNlcnZl ci1zaWRlIHNlc3Npb24gcmVjb3JkIGlzIGxvc3QgaWYgaXRzIHN0YXRlIGlzbuKAmXQgc3luY2hy b25pemVkIGFjcm9zcw0KIHRoZSBmbGVldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0ibTE3NjE2MzE0MTEyMTM0MzQ0ODJtc29wbGFpbnRleHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZxdW90O21vZGVybiZxdW90OyBhcHBz IGFyZSBSRVNUIGJhc2VkIHdpdGggSmF2YXNjcmlwdCBmcm9udGVuZHMsIGJ1dCB0aGVyZSdzIHN0 aWxsIGEgdG9uIG9mICZxdW90O29sZCBzY2hvb2wmcXVvdDsgZGV2ZWxvcGVycw0KIG91dCB0aGVy ZS48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5XYXMgaW52 b2x2ZWQgd2l0aCBkZXZlbG9waW5nIGFuIGFwcGxpY2F0aW9uIHNlcnZlciBmb3Igb3ZlciBhIGRl Y2FkZSAoSkJvc3MpLi4uVGhlcmUgd2VyZSBtYW55IGFwcCBkZXZlbG9wZXJzIHRoYXQgZGlkbid0 IHdhbnQgdG8gc3RvcmUgYXBwIHNlc3Npb24gaW5mb3JtYXRpb24gaW4gYSBkYXRhYmFzZSAoYXMg RGF2aWQgc2F5cykgb3INCiBkZWFsIHdpdGggdGhlIGhlYWRhY2hlcyBvZiBzZXNzaW9uIHJlcGxp Y2F0aW9uIHNvIHRoZXkganVzdCBzZXQgdXAgdGhlaXIgbG9hZCBiYWxhbmNlciB0byBkbyBzZXNz aW9uIGFmZmluaXR5IChzdGlja3kgc2Vzc2lvbnMpLiZuYnNwOyBUaGF0IHdheSB0aGUgbG9naW4g c2Vzc2lvbiB3YXMgYWx3YXlzIGxvY2FsLiZuYnNwOyBJZiB0aGUgb2lkYyBsb2dvdXQgc3BlYyBh bGxvd2VkIHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgbG9nb3V0IGNhbGxiYWNrIHRpZWQgdG8gdGhl DQogdG9rZW4ncyBzZXNzaW9uIChsaWtlIG1heWJlIGR1cmluZyBjb2RlIHRvIHRva2VuKSwgdGhh dCBtaWdodCBiZSBhIHNpbXBsZSB3YXkgdG8gc29sdmUgbWFueSBvZiB0aGVzZSBpc3N1ZXMgdG9v LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BA42F798A4E643D99A93D85C6C5AF4AAamazoncom_-- From nobody Wed Mar 28 14:35:05 2018 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 8E8301273E2 for ; Wed, 28 Mar 2018 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XSLnUN3PFf9f for ; Wed, 28 Mar 2018 14:35:02 -0700 (PDT) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) (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 2DF2D127337 for ; Wed, 28 Mar 2018 14:35:02 -0700 (PDT) Received: by mail-ua0-f180.google.com with SMTP id u9so2445424ual.13 for ; Wed, 28 Mar 2018 14:35:02 -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=fW4beA6THzJ6STXcxbBT4i8PVMrZ31hHVFeSQmB4mQ4=; b=P1JfuBK3nDnSmO0jovE+iZWRQGKA/lHudFw/Pykw2zfyQtQBOBnEHhl5F9peacCLVr LfI7f5AL0Nc8jBFLOqTdYWlp+y2BEY3D70nVYMTemqvHp9yTDJX/qlju2UD0tQergA+l GXOdpON1bezgWKGsDfH6ooIyw7fAcXbibqe2EBxhcBnsV+m7vMILo9gaSgrk/d/1VUcN T8uZRQpQPkMX1yDJNMhZTY00MO+mvX7SilsmfzJp1nWJTQ/Tt8TPbYmdq9vYQrYnpBAM PYBHIpVXL2sB6Qyv/luOjevkWcJN7kpRYahe+YQyGahBwwDTkwwi5VuT3Ak5a4nGyaY0 9oUQ== X-Gm-Message-State: AElRT7FiOfknUafnMp6QfF0h7HndQPoSJ6lLajy0cmWTfaHHge5hambd tcI3rY8Xiuob5nh7ch+KJv9deBMthc9nm0jKpe+/yQ== X-Google-Smtp-Source: AIpwx4+RaY8WT4lbleTP11NTA6MLL7oULV7TGiF0TOS5CYhT3Ai6lyulSSuwq0rcXl+HMGg1RnQ1qle/0+sBL3y6MIs= X-Received: by 10.159.37.133 with SMTP id 5mr3785598uaf.1.1522272901092; Wed, 28 Mar 2018 14:35:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.13.199 with HTTP; Wed, 28 Mar 2018 14:35:00 -0700 (PDT) In-Reply-To: References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> From: Bill Burke Date: Wed, 28 Mar 2018 17:35:00 -0400 Message-ID: To: "Richard Backman, Annabelle" Cc: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Content-Type: multipart/alternative; boundary="001a1142966c8573c705687fc707" Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 28 Mar 2018 21:35:04 -0000 --001a1142966c8573c705687fc707 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle < richanna@amazon.com> wrote: > That makes somewhat more sense to me if we=E2=80=99re talking about appli= cations > with sticky sessions. Adding a session-specific logout URI introduces > security concerns (e.g. how does the OP validate the URI) and only works = if > the RP can provide URIs that target individual hosts in their fleet. The > =E2=80=9Cis this SID valid?=E2=80=9D endpoint solution that David describ= ed doesn=E2=80=99t scale > and depends on SID (which is OPTIONAL). Both shift the burden of state > management onto the OP, which may not be in any better position to handle > it. > > > FWIW, our OP implementation allows RPs to register their node specific logout endpoints at boot. This request is authenticated via client authentication. We also extended code to token request to transmit the local session id. The OP stores this information. Backchannel logout POSTS to each and every registered node and transmits a JWS signed by the OP containing the local session ids to invalidate. That's been enough to cover all the weirdness out there so far. > This seems like something that needs to be addressed in the client > implementations rather than in the specification. Especially when we > consider that there are implementation-specific questions lurking in the > edge cases. (e.g. what happens when a user comes in with valid cookies, b= ut > no server-side session state?) > > > Then,isn't any backchannel logout specification more of a framework than an actual protocol? --=20 Bill Burke Red Hat --001a1142966c8573c705687fc707 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= br>
On Wed, Mar 28, 2018 at 4:09 PM, Richard Back= man, Annabelle <richanna@amazon.com> wrote:

That makes somewhat more sense to me if we=E2=80=99r= e talking about applications with sticky sessions. Adding a session-specifi= c logout URI introduces security concerns (e.g. how does the OP validate th= e URI) and only works if the RP can provide URIs that target individual hosts in their fleet. The =E2=80=9Cis this SID= valid?=E2=80=9D endpoint solution that David described doesn=E2=80=99t sca= le and depends on SID (which is OPTIONAL). Both shift the burden of state m= anagement onto the OP, which may not be in any better position to handle it.

=C2=A0


<= /div>
FWIW, our OP implementation allows RPs to register their node spe= cific logout endpoints at boot.=C2=A0 This request is authenticated via cli= ent authentication.=C2=A0 We also extended code to token request to transmi= t the local session id.=C2=A0 The OP stores this information.=C2=A0 Backcha= nnel logout POSTS to each and every registered node and transmits a JWS sig= ned by the OP containing the local session ids to invalidate.=C2=A0 That= 9;s been enough to cover all the weirdness out there so far.
=C2= =A0

This seems like something that needs to be addressed= in the client implementations rather than in the specification. Especially= when we consider that there are implementation-specific questions lurking = in the edge cases. (e.g. what happens when a user comes in with valid cookies, but no server-side session state?= )

=C2=A0


Then,isn't any backchannel logout specification more o= f a framework than an actual protocol?


<= /div>--
Bill Burke
Red Hat
--001a1142966c8573c705687fc707-- From nobody Wed Mar 28 14:57:30 2018 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 E589D127863 for ; Wed, 28 Mar 2018 14:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0cKTbs-jugFZ for ; Wed, 28 Mar 2018 14:57:25 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 014EA127775 for ; Wed, 28 Mar 2018 14:57:24 -0700 (PDT) X-AuditID: 12074423-627ff70000005664-dc-5abc0fc2f8d7 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.1E.22116.2CF0CBA5; Wed, 28 Mar 2018 17:57:23 -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 w2SLvLVI026165; Wed, 28 Mar 2018 17:57:21 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2SLvJqH029549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2018 17:57:20 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_957F5D66-4870-41D3-A478-C0B3E7869397" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Mar 2018 17:57:18 -0400 In-Reply-To: Cc: "" To: Brian Campbell References: <86368D0D-EB6D-4803-8AC3-C587405BAA32@mit.edu> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrXuYf0+UwdJrwhar/99ktDj59hWb A5PHkiU/mTzuHr3IEsAUxWWTkpqTWZZapG+XwJUx785vloK/+RXP5qxiamCcFtfFyMkhIWAi cfbZI+YuRi4OIYHFTBI969+wgSSEBDYySpzc7QaRuM4kseDcKlaQBJuAqsT0NS1MIDavgJXE pdfn2EFsZoEkiYNrf7NAxE0k3r99CFYjLKAvsezlWbChLEC9e3c1AW3j4OAUCJR41sEPYjIL qEu0n3QBqRABqr79dA47xNpGRolrD96yQxyqJDH9+222CYz8s5Bsm4VkG0RcW2LZwtfMELam xP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mil5pSuokRFNbs Lso7GF/2eR9iFOBgVOLhtVi0O0qINbGsuDL3EKMkB5OSKO/hN0AhvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrzvNYByvCmJlVWpRfkwKWkOFiVxXg8T7SghgfTEktTs1NSC1CKYrAwHh5IE7ze+ PVFCgkWp6akVaZk5JQhpJg5OkOE8QMOvg9TwFhck5hZnpkPkTzHacxx6P6WHmeMcmJyyZBqQ PHYZSAqx5OXnpUqJ8+4HaRMAacsozYObDEpZ7uvsLF4xigM9Ksy7G6SKB5ju4Ga/AlrLBLR2 W9MOkLUliQgpqQZGI/b0ltiNOzhWLZkZXGvhlnCt/sTZ3LMXPnb9aU5il03zUbzAtKeC/9VC x/IfVz9n9N39nukzzVfl8TuDnswXXArqZ4Oj7RsvtbX9FBL2t3xXUv54C9PZqHWG7mnS8wWf R87X6T0wu5v9y+pIq/0LKztUv1isYVLMsgyqfWTGKP5a7doVpkAlluKMREMt5qLiRAC50nQW NAMAAA== Archived-At: Subject: Re: [OAUTH-WG] Review of oauth-mtls-07 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, 28 Mar 2018 21:57:28 -0000 --Apple-Mail=_957F5D66-4870-41D3-A478-C0B3E7869397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the responses. I=E2=80=99ve cut out places where we seem to = agree here and responded to the rest inline below.=20 > =20 >=20 > =C2=A72.1=C2=B61: It would be helpful to have a pointer on methods of = comparing DNs. In our implementation we serialize them to strings using = a canonical format (RFC2253) and doing a string comparison based on = that. There are probably other ways, but it would be good to help = developers avoid doing something naive like comparing two different = serializations as strings.=20 >=20 > That's really an implementation detail but I can note that some kind = of normalization is likely needed in comparing DNs.=20 Might be worth pointing to to RFC4514 in a non-normative example here. = The thing is, there are equivalent DNs that aren=E2=80=99t exact string = copies of each other. We=E2=80=99ll want to avoid developers either = doing a naive string comparison (leading to false negatives) or doing = their own home-made regexes (leading to probable breakage and = potentially security holes). >=20 > =20 > =C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D is an = unnecessary distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D = regardless of how it got there >=20 > While I suppose that's true about 6749, I think colloquially = 'registered' and 'configured' have come to have more meaning to = some/many people about how the client came to be setup at the AS. So it = might be strictly unnecessary but I'd prefer to keep the "configured or = registered" just to help say that it doesn't matter how the AS came to = get the expected DN for client. That=E2=80=99s a fair assessment, and I=E2=80=99m fine with it as-is in = that case. > =20 > =20 > =C2=A72.1.1=C2=B61: Is it necessary to introduce the registry here = instead of just pointing to it? I=E2=80=99m fine with stating that the = values are used in both discovery and client registration.=20 >=20 > I had a hard time describing things concisely here because of the = history of how and when the authentication methods registry came to be, = it's name, and where it's used. That text in =C2=B61 is what I was able = to come up with that I thought adequately explained it. It's admittedly = not the most elegant prose ever written but it does convey the info and = I'm inclined to leave it. However, I would be happy to consider = alternative text here, if you've got something specific to propose. I guess I just don=E2=80=99t think all that history is really needed = right here. So I=E2=80=99d replace it with: For the PKI method of mutual TLS client authentication, this = specification defines and registers the following authentication method metadata value into the "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters = ]. If you feel it needs a reference, you can potentially put it in intro = paragraph of the IANA section that sets the values, maybe? (=C2=A76.3) In the end I=E2=80=99m fine if the text stays =E2=80=94 it=E2=80=99s not = incorrect, I just feel it=E2=80=99s superfluous. Same comments apply to = the other sections so I=E2=80=99m not going to copy them here. > =20 >=20 > =C2=A7A=C2=B62: This paragraph reads a bit overly defensive. I = understand the need to position the two drafts in relationship to each = other, but the tone here could be adjusted significantly without losing = the thrust of the main argument. >=20 > The line about Token Binding not having a monopoly on the binding of = tokens is admittedly a bit tongue-in-cheek and also a nod to the point = you made the other day about running out of names.=20 >=20 > Honestly though, this text wasn't intended to be defensive and, even = when I read it again, it doesn't come off that way to me. As usual, if = you've got specific text to propose that you think would be better, I'd = be happy to consider it. But I don't feel like the current text is = particularly problematic or in need of change.=20 I took a crack at rewriting the second paragraph (note that I removed = the first sentence entirely), but in the end it=E2=80=99s up to you how = you want to present the comparison between the documents: Token Binding uses bare keys that are generated on the client, which = avoids many of the difficulties of creating, distributing, and managing the = certificates used in this specification. However, Token Binding requires support across different portions of = the application stack, including TLS and browser implementations. At the time of this = writing, there is relatively little support for it in available application development platforms and tooling. On the other hand, mutual TLS has = been around for some time and enjoys widespread support in web servers and development platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built = and deployed now using existing platforms and tools. In the future, the two = specifications are likely to be deployed in parallel for solving similar problems in different = environments. =E2=80=94 Justin --Apple-Mail=_957F5D66-4870-41D3-A478-C0B3E7869397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the responses. I=E2=80=99ve cut out places where = we seem to agree here and responded to the rest inline below. 

 

=C2=A72.1=C2=B61: It = would be helpful to have a pointer on methods of comparing DNs. In our = implementation we serialize them to strings using a canonical format = (RFC2253) and doing a string comparison based on that. There are = probably other ways, but it would be good to help developers avoid doing = something naive like comparing two different serializations as = strings. 

That's really an implementation detail = but I can note that some kind of normalization is likely needed in = comparing DNs.

Might be worth pointing to to RFC4514 in a = non-normative example here. The thing is, there are equivalent DNs that = aren=E2=80=99t exact string copies of each other. We=E2=80=99ll want to = avoid developers either doing a naive string comparison (leading to = false negatives) or doing their own home-made regexes (leading to = probable breakage and potentially security holes).


 
=C2=A72.1=C2=B61: =E2=80=9Cconfigured or registered=E2=80=9D = is an unnecessary distinction, 6749 calls it =E2=80=9Cregistered=E2=80=9D = regardless of how it got there

While I suppose that's = true about 6749, I think colloquially 'registered' and 'configured' have = come to have more meaning to some/many people about how the client came = to be setup at the AS. So it might be strictly unnecessary but I'd = prefer to keep the "configured or registered" just to help say that it = doesn't matter how the AS came to get the expected DN for client.

That=E2=80=99s a fair assessment, and I=E2=80=99m = fine with it as-is in that case.

     
 
=C2=A72.1.1=C2=B61: Is it necessary to introduce the registry = here instead of just pointing to it? I=E2=80=99m fine with stating that = the values are used in both discovery and client = registration. 

I had a hard time describing things = concisely here because of the history of how and when the authentication = methods registry came to be, it's name, and where it's used.  That = text in =C2=B61 is what I was able to come up with that I thought = adequately explained it. It's admittedly not the most elegant prose ever = written but it does convey the info and I'm inclined to leave it. = However, I would be happy to consider alternative text here, if you've = got something specific to propose.

I guess I just don=E2=80=99t think all that = history is really needed right here. So I=E2=80=99d replace it = with:

For the PKI method of mutual TLS client =
authentication, this specification
   defines and registers the following authentication method metadata
   value into the "OAuth Token Endpoint Authentication Methods" =
registry
   [IANA.OAuth.Parameters].
=
If you feel it needs a reference, you can potentially put it in = intro paragraph of the IANA section that sets the values, maybe? = (=C2=A76.3)

In the end I=E2=80=99m = fine if the text stays =E2=80=94 it=E2=80=99s not incorrect, I just feel = it=E2=80=99s superfluous. Same comments apply to the other sections so = I=E2=80=99m not going to copy them here.

 

=C2=A7A=C2=B62: This paragraph reads a bit = overly defensive. I understand the need to position the two drafts in = relationship to each other, but the tone here could be adjusted = significantly without losing the thrust of the main = argument.

The line about Token Binding not having = a monopoly on the binding of tokens is admittedly a bit tongue-in-cheek = and also a nod to the point you made the other day about running out of = names.

Honestly = though, this text wasn't intended to be defensive and, even when I = read it again, it doesn't come off that way to me. As usual, if you've = got specific text to propose that you think would be better, I'd be = happy to consider it. But I don't feel like the current text is = particularly problematic or in need of change.

I took a crack at = rewriting the second paragraph (note that I removed the first sentence = entirely), but in the end it=E2=80=99s up to you how you want to present = the comparison between the documents:

   Token Binding uses =
bare keys that are generated on the client, which avoids many of
   the difficulties of creating, distributing, and managing the =
certificates used in this specification.
   =
However, Token Binding requires support across different portions of the =
application
   stack, including TLS and =
browser implementations. At the time of this writing,
   there is relatively little support for it in =
available application
   development platforms and tooling.  On the other hand, mutual TLS has =
been around for some time
   and enjoys widespread support in web servers and development
   platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built =
and deployed now
   using existing platforms and tools. In the future, the two =
specifications are likely to be
   deployed =
in parallel for solving similar problems in different =
environments.

=E2=80=94 Justin


= --Apple-Mail=_957F5D66-4870-41D3-A478-C0B3E7869397-- From nobody Thu Mar 29 08:19:08 2018 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 5335E127241 for ; Thu, 29 Mar 2018 08:19:07 -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, 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 (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_hSOWzPj0QM for ; Thu, 29 Mar 2018 08:19:04 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 5F6DA126BF0 for ; Thu, 29 Mar 2018 08:19:04 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id v21so11507276wmc.1 for ; Thu, 29 Mar 2018 08:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MWu7I7pswaG77C0KKCZrF9h+9WaHthDO0WKRnXVYxHk=; b=PgDWJCHhBlg58S0byBL6xP9st0e/Fn8m9H15EsfDfjbiUYxdNfxnihh0vm4O2X+v+c XkxicYU7E2UQzQ0XlBRUgWfZc6KSNaLYJqk0g4rd2bILa3UO7/q2HoQlJvVgcovRAfS7 Kt0Wfg30NMHadVgJaP/ccZBVAGTE7Hw93TgjU= 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=MWu7I7pswaG77C0KKCZrF9h+9WaHthDO0WKRnXVYxHk=; b=Ce9rRQxla0tVRLf2kveP/TxmPP7h1XBSNG5WGuVVIoexqCCrtQm83qK44uV/ruRMGs MQb5H8V92PGTivFP1ZCI9lcR797BiqDGAddBYuVyi5OunQ1HrndegUiERlZEh+nz13bh 92lFekR92WiykSkKxh+13SXcGidlJr7SKtkXGiv8WnnTNYLh7HreOYMGLum9lEMh7JNi quZCIku9mq+2ylB2A4l+tE/LCEGWBFmp7DbUxHn8xpgdXb8/rZbF5qrz8zLw5Y2mtYmu Laj7zi7+nGsCeMN+NFGf8zWhJlQTJU9iDS5lhXqRAnwFQ3v9FiVg2+jQi2HzImdOJ7be 0Ecw== X-Gm-Message-State: AElRT7F+lLrYlk2RjCkXej+n5A3djbdnWvV/RM8K7uMfWj89tl7MYxPD 3qqtnguXt7VdqMqAJdUi0tJrgg== X-Google-Smtp-Source: AIpwx49OGeO2d25ZyAJRdHHFFwPmcbccxkBdRZ4VDuz4tiMItdLmzyMjaAbcl9E5yN6F9HJE6+GWIQ== X-Received: by 10.28.9.68 with SMTP id 65mr6383776wmj.29.1522336742445; Thu, 29 Mar 2018 08:19:02 -0700 (PDT) Received: from guest2s-mbp.home (148.199.93.209.dyn.plus.net. [209.93.199.148]) by smtp.gmail.com with ESMTPSA id n49sm10065729wrn.90.2018.03.29.08.19.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 08:19:01 -0700 (PDT) From: Neil Madden Message-Id: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8366DBC1-39B6-4AE8-B95C-6F73FCB5EDB2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 29 Mar 2018 16:18:59 +0100 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 29 Mar 2018 15:19:07 -0000 --Apple-Mail=_8366DBC1-39B6-4AE8-B95C-6F73FCB5EDB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc). 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes: { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2= =80=A6=E2=80=9D } } but you can already do: { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } If the intent is just to save some space and avoid the mandatory fields = of the existing JWK types, maybe this would be better addressed by = defining a new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2= =80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80= =A6=E2=80=9D }. 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D= a bit of a misnomer: it=E2=80=99s really only the client authentication = that we are interested here, and the fact that the server also = authenticates with a certificate is not hugely relevant to this = particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types = (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d prefer that the = draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99. This is especially confusing in section 3 on sender constrained access = tokens, as there are two different servers involved: the AS and the = protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D = authentication between them, only between each of them and the client. 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC = only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The = wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be = used with TLS 1.0 or 1.1, or whether it is only referring to future TLS = versions. 4. It might be useful to have a discussion for implementors of whether = TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the use of client certificates, if at all? 5. Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2). The draft should decide which of those it is implementing and if = sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so = should drop the language about sender constrained tokens). 6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5): Strong, fresh session keys: Session keys MUST be strong and fresh. Each session = deserves an independent session key, i.e., one that is generated = specifically for the intended use. In context of OAuth this means = that keying material is created in such a way that can only be used = by the combination of a client instance, protected resource, = and authorization scope. However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) says: The client makes protected resource requests as described in [RFC6750], however, those requests MUST be made over a mutually authenticated TLS connection using the same certificate that was = used for mutual TLS at the token endpoint. These two statements are contradictory: the OAuth 2.0 PoP architecture = effectively requires a fresh key-pair to be used for every access token = request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server. In the self-signed case (and even in the CA case, with a bit of work - = e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is = perfectly possible for the client to generate a fresh key-pair for each = access token and include the certificate on the token request (e.g., as = per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#secti= on-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D value should = probably be described). This should probably at least be an option. 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it = allows correlation of activity. 8. This is maybe a more general point, but RFC 6750 defines the = Authorization: Bearer scheme = (https://tools.ietf.org/html/rfc6750#section-2) for a client to = communicate it=E2=80=99s access token to the RS in a standard way. As = sender-constrained access tokens are not strictly bearer tokens any = more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme? 9. The Security Considerations should really make some mention of the = long history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation. 10. The PKI client authentication method = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes = no mention at all of certificate revocation and how to handle checking = for that (CRLs, OCSP - with stapling?). Neither does the Security = Considerations. If this is a detail to be agreed between then AS and the = CA (or just left up to the AS TLS stack) then that should perhaps be = made explicit. Again, there are privacy considerations with some of = these mechanisms, as OCSP requests are typically sent in the clear = (plain HTTP) and so allow an observer to see which clients are = connecting to which AS. 11. The same comment applies to how the protected resource checks for = revocation of the certificate presented during sender constrained access = token usage. Should the RS make its own revocation checks based on the = information in the certificate presented, or should it trust the = certificate while the access token is still valid? If the latter case, = is the AS responsible for revoking any access tokens whose certificate = have been revoked (if so, should it be doing an OCSP call on every token = introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the = RS verify the signature on that if it does not have a separate trust = relationship with the CA already? 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. Cheers, Neil > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef = wrote: >=20 > All, >=20 > As discussed during the meeting today, we are starting a WGLC on the = MTLS document: > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >=20 > Please, review the document and provide feedback on any issues you see = with the document. >=20 > The WGLC will end in two weeks, on April 2, 2018. >=20 > Regards, > Rifaat and Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8366DBC1-39B6-4AE8-B95C-6F73FCB5EDB2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy9aOUQwiH2bf8TjhkPhD307drF0FAlq9A+MACgkQkPhD307d rF2BdA//Qa1VLNPTHnzigF6JUltfw1Lhw5dSKAl9pjuGwm1VzHVcoZy88TDJPoMV uMN+xcf3uPlqbcKyJ1bIuKWpSz3j1zgE+ErEpHkvBB3MM1Y4y06TifyE/TIlL8NB CbKi9eooubRBDRyHGYUz8x1x+eXj4l4P8D+5UIyyxZsTHrfI3ppypAODl9bVp3jO HUwaaOIuB7SfMEi4hSD3mK0E9ZcxK2+crGSD/hmxo7u8rIVZlRxlEC8yUjCAZLev hATiQ9WdIyP7A4Dr8bgc1Qr7mWtG0pp8o2ude8zjIixYso5W9H+00ExzgBmuSDnV AjzRhZ+Vt9oLdLVE4Fcj4aaz+5Fj35maRvbQ2rokXqQTuCIO0rXO8e85aplwpUyB pfzptUVYoZpfjrzM7FgMJ3Wb00utC8M0XQUidkrevqHgYrClvaY5n2CWa2Ymc+NM jx1i1/ZqSlfPuK7fu0Y7X3cD8qm7og6LJi2dus7FdvojJhjqqrAxRGKo753YMp+L pMRMHrw701DEyY/AOIUYqYPUgJAPCCfJAL7rQLamLuV2oh+hq0fpprBm6Tob7FAD mNERZFCZZC2tu5giPjX+Cf26pNH1PRSg9947vRNz1xxMV/p+kSFIrjoxMNPkasxU zG1zLscfL3yG45CrxxzIKqZetpHYoVW+DNgcwc3fVPIyjNvc9Vc= =Ne1l -----END PGP SIGNATURE----- --Apple-Mail=_8366DBC1-39B6-4AE8-B95C-6F73FCB5EDB2-- From nobody Thu Mar 29 08:47:47 2018 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 2B4EB12DA25 for ; Thu, 29 Mar 2018 08:47:45 -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, 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=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 cYn5zJUhFVk5 for ; Thu, 29 Mar 2018 08:47:40 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 4372E12DA2B for ; Thu, 29 Mar 2018 08:47:40 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s78so6423381qkl.8 for ; Thu, 29 Mar 2018 08:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=phnC7Qiz8MPmeAoVvnNSTiMrS6PAvJgVql0N4QRyuMo=; b=ZTy+VkMikXaz50Gu8Fx7q+n9mCRyfdhGGdeHI4Rlm8rdlekTkf0kJbACGjquiyU9ze Sg/Io0q7zKpLileZJiSjx4G0axLoCqK4qiA8fOZ9PG5n/+AGx2bnEyABobu/ZSz5ZHsC PmhQHx4LpmKPMYXihB7hsCz7lZ/faOUfBN3Iu/OJyUu7UX6S5SCxMeSdS2PUDVd0wzAC pHK9F/v8vo1D+t9xzmnNpT2w1U41jrZS1PcSQ+yY0fMQeZVdU26wyJHYP3OceEoxs3nF HLW6om36C+0kVl63LT4K/hr0pFIW1JylcHOZqhVZh5MK4iD+B53oPNX1szmV90Pofs3R epog== 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=phnC7Qiz8MPmeAoVvnNSTiMrS6PAvJgVql0N4QRyuMo=; b=E7TxQHwrSBHHXggEkenZEuhf3J1io/MH1b9Eu1rrPlRfEYuwvco9F7CCgtxw1eqru8 E7d/cHYxS9R2voOVRRoIOg9PfIIyBq555uvJD1ZiIgioiJSiIH5zRC9VkbQDQDCe1LqJ cu9MxeA1JPSH7xQHmwUlNtpBw9hrKyrUQiyUKfaUvNxHlSnJGIfstgaiUClgy7VzOlhX 0SAXP+wDDqOG39KnNkPI34e2miOWiYOnVoaem70BLp5z/iO+RTo3EvtraTsUbILdHGoL DugADvHkVcbvESKH1ZPKoULCyeMjMFMySfEO6OgJ8fKHM0l/L2Axt+XoxuJQ80NqNAf9 go1Q== X-Gm-Message-State: AElRT7Efl8EYfLwIafr6EZbzS0CZpG3B9pgaNecjZcZFPKOicTAZJBA4 2M+k88kMu6EKyhrAHTrzFc2bnA== X-Google-Smtp-Source: AIpwx49Jt+jxQJcXv9WMwW7J9PtGb+20CELmrdqtTG4tB1QBqZDklCdOS0gRWv1pYUgQPvIQ3DnaMQ== X-Received: by 10.55.27.20 with SMTP id b20mr11614869qkb.253.1522338458598; Thu, 29 Mar 2018 08:47:38 -0700 (PDT) Received: from [192.168.8.100] ([181.201.215.42]) by smtp.gmail.com with ESMTPSA id c7sm4468050qkm.87.2018.03.29.08.47.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 08:47:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: John Bradley In-Reply-To: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> Date: Thu, 29 Mar 2018 12:47:32 -0300 Cc: Rifaat Shekh-Yusef , oauth Content-Transfer-Encoding: quoted-printable Message-Id: <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> To: Neil Madden X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 29 Mar 2018 15:47:45 -0000 Thanks for the feedback. We will review your comments and reply. One data point is that this will not be the only POP spec. The spec = using token binding vs mtls has better privacy properties. It is UK = Open banking that has pressed us to come up with a standard to help with = interoperability.=20 This spec has been simplified in some ways to facilitate the majority of = likely deployments. I understand that in future certificates may have better than SHA256 = hashes. Regards John B. > On Mar 29, 2018, at 12:18 PM, Neil Madden = wrote: >=20 > Hi, >=20 > I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc). >=20 > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes: >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2= =80=A6=E2=80=9D } } >=20 > but you can already do: >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } >=20 > If the intent is just to save some space and avoid the mandatory = fields of the existing JWK types, maybe this would be better addressed = by defining a new JWK type which only has a thumbprint? e.g., { = =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D }. >=20 > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client = authentication that we are interested here, and the fact that the server = also authenticates with a certificate is not hugely relevant to this = particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types = (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d prefer that the = draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99. >=20 > This is especially confusing in section 3 on sender constrained access = tokens, as there are two different servers involved: the AS and the = protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D = authentication between them, only between each of them and the client. >=20 > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 = RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? = The wording in Section 5.1 doesn=E2=80=99t seem clear if this could also = be used with TLS 1.0 or 1.1, or whether it is only referring to future = TLS versions. >=20 > 4. It might be useful to have a discussion for implementors of whether = TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the use of client certificates, if at all? >=20 > 5. Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2). The draft should decide which of those it is implementing and if = sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so = should drop the language about sender constrained tokens). >=20 > 6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5): >=20 > Strong, fresh session keys: >=20 > Session keys MUST be strong and fresh. Each session = deserves an > independent session key, i.e., one that is generated = specifically > for the intended use. In context of OAuth this means = that keying > material is created in such a way that can only be used = by the > combination of a client instance, protected resource, = and > authorization scope. >=20 >=20 > However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) says: >=20 > The client makes protected resource requests as described in > [RFC6750], however, those requests MUST be made over a mutually > authenticated TLS connection using the same certificate that was = used > for mutual TLS at the token endpoint. >=20 > These two statements are contradictory: the OAuth 2.0 PoP architecture = effectively requires a fresh key-pair to be used for every access token = request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server. >=20 > In the self-signed case (and even in the CA case, with a bit of work - = e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is = perfectly possible for the client to generate a fresh key-pair for each = access token and include the certificate on the token request (e.g., as = per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#secti= on-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D value should = probably be described). This should probably at least be an option. >=20 > 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it = allows correlation of activity. >=20 > 8. This is maybe a more general point, but RFC 6750 defines the = Authorization: Bearer scheme = (https://tools.ietf.org/html/rfc6750#section-2) for a client to = communicate it=E2=80=99s access token to the RS in a standard way. As = sender-constrained access tokens are not strictly bearer tokens any = more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme? >=20 > 9. The Security Considerations should really make some mention of the = long history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation. >=20 > 10. The PKI client authentication method = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes = no mention at all of certificate revocation and how to handle checking = for that (CRLs, OCSP - with stapling?). Neither does the Security = Considerations. If this is a detail to be agreed between then AS and the = CA (or just left up to the AS TLS stack) then that should perhaps be = made explicit. Again, there are privacy considerations with some of = these mechanisms, as OCSP requests are typically sent in the clear = (plain HTTP) and so allow an observer to see which clients are = connecting to which AS. >=20 > 11. The same comment applies to how the protected resource checks for = revocation of the certificate presented during sender constrained access = token usage. Should the RS make its own revocation checks based on the = information in the certificate presented, or should it trust the = certificate while the access token is still valid? If the latter case, = is the AS responsible for revoking any access tokens whose certificate = have been revoked (if so, should it be doing an OCSP call on every token = introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the = RS verify the signature on that if it does not have a separate trust = relationship with the CA already? >=20 > 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. >=20 > Cheers, >=20 > Neil >=20 >=20 >> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef = wrote: >>=20 >> All, >>=20 >> As discussed during the meeting today, we are starting a WGLC on the = MTLS document: >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 >>=20 >> Please, review the document and provide feedback on any issues you = see with the document. >>=20 >> The WGLC will end in two weeks, on April 2, 2018. >>=20 >> Regards, >> Rifaat and Hannes >>=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 From nobody Thu Mar 29 09:41:59 2018 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 9182C12DA12 for ; Thu, 29 Mar 2018 09:41:57 -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, 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 (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noHwbtjAIA11 for ; Thu, 29 Mar 2018 09:41:54 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 9D3F9127522 for ; Thu, 29 Mar 2018 09:41:53 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a20so31001632wmd.1 for ; Thu, 29 Mar 2018 09:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=r5ym7bJYHsdSGRmCr6FEpq9/KfJhXTEtLi/rv0WPoZ8=; b=T1TCr7cFHOH7FFOBZb8obl+/zaC0dybQ37WgnCR/EJ3YZ3KCk3LhbkkbzHHvNJt6vi Bl3lMmgX2Hce9fCT8z9f8vfW+THqW7xxvO6cPhYfjhJ3b16XaZhzi5y6QgJhgOu2FCMG 9TMmr9odUJy1xCv5Riz78M7UBZFGv1eJLucDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=r5ym7bJYHsdSGRmCr6FEpq9/KfJhXTEtLi/rv0WPoZ8=; b=tQje6uFsgSrA0xzNTzJkLSa9hYN/O2t8AJrfcd7ZfWyoY+xgkHjDMqOJQTKM8wpSBp tAirDQBd2xZSH0vD5zOh0CIwMNdMFIkO7QQvvX179vW3wg5SVvejMxKwI2uj34vbouZt ROKaeV9iBng5IfB/VTckM8T3ymVjZKGA9x9dDDgGcyCwXEb4265bFqn043dnDRNdQAOH 0PRH+45wtqGCR8Hgxy7TlmS/M8G6+KsQwC3NoQ2SqLmiu6DkOXxe61KEAX1YFUikr+3J tPYxsGYLukS7fR/7FtPvSJ5OPpw6XfrE/De5KccDeGJ1tZIDVlhFRSkCmqHijuWAVqvb i3dA== X-Gm-Message-State: AElRT7GZZ27I0LirNUHhVWLNjv9XKMHtud6qWBHQx0EiZYws79NFlt+s CS7n9umAsl1AKZ2Qg/6vRqnmFrP9RKY= X-Google-Smtp-Source: AIpwx49fy+QDHYgd0d6QU8uYBrPhE7lxuDoO4f4g6CBEr14/6xCxodtSbXRmBustwRIRtf/ApDzd7g== X-Received: by 10.28.158.10 with SMTP id h10mr362638wme.105.1522341711838; Thu, 29 Mar 2018 09:41:51 -0700 (PDT) Received: from [192.168.1.81] (148.199.93.209.dyn.plus.net. [209.93.199.148]) by smtp.gmail.com with ESMTPSA id t8sm2915050wmc.20.2018.03.29.09.41.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 09:41:50 -0700 (PDT) Date: Thu, 29 Mar 2018 17:41:48 +0100 From: Neil Madden To: Torsten Lodderstedt Cc: oauth Message-ID: <6395c148-6b46-4964-b56b-e9e3fd2839d1@Canary> In-Reply-To: <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <1452DCC9-3D8A-42E5-94A4-87B5D2B291AC@forgerock.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5abd174d_625558ec_2e4d"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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: Thu, 29 Mar 2018 16:41:58 -0000 --5abd174d_625558ec_2e4d Content-Type: multipart/alternative; boundary="5abd174d_2ae8944a_2e4d" --5abd174d_2ae8944a_2e4d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I=E2=80=99ve just realised that =E2=80=9Ccrit=E2=80=9D is for headers whi= le the =E2=80=9Cscope=E2=80=9D claim is in the payload, so a different ap= proach would be needed in that case (or the scope would need to be duplic= ated into the headers). Kind regards, Neil -- > On Wednesday, Mar 28, 2018 at 4:41 pm, Neil Madden wrote: > I like this draft, but I want to clarify if it is intended that the res= ponse JWT could be interpreted as an OpenID Connect ID Token=3F As the se= t of claims can overlap (in particular, all required ID token claims are = valid token introspection response fields) and it seems highly likely tha= t an AS will use the same keys for signing both (and it definitely will w= hen the client=5Fsecret is used for signing), the signed response JWT cou= ld well be indistinguishable from an ID token (for the resource owner) wi= th some additional claims. > > If this is not the case, then maybe consider adding a =E2=80=9Ccrit=E2=80= =9D: =5B=E2=80=9Cscope=E2=80=9D=5D claim to the response (https://tools.i= etf.org/html/rfc7515=23section-4.1.11) to indicate that the scope claim m= ust be understood. > > I can think of one potential use-case (I=E2=80=99ll let you decide the = merits of it) where it might actually be useful to explicitly allow the r= esponse to be an ID Token. Consider an application (RS) that uses a tradi= tional authorization model: it authenticates a user, sets a cookie, and t= hen based on who that user is makes dynamic access control decisions to s= ee what they are allowed to do (e.g., ACLs, RBAC, whatever). An easy way = to upgrade this app to modern standards would be to replace the home-spun= authentication system with OIDC, but leave the rest in place. Now the sy= stem uses OIDC to authenticate the user, sets the ID token as the cookie,= and then still applies the same access control decisions that it always = has done. > > Now imagine that a new requirement comes in to support OAuth 2.0 access= tokens to allow delegation to third-party apps. A really simple way to a= chieve that would be to put a filter/reverse proxy in front of the RS tha= t extracts access tokens coming in, performs signed JWT token introspecti= on against the AS to validate the token and then checks the the scopes ar= e appropriate for the request. It can then simply replace the access toke= n in the original request with the signed token introspection response (a= s ID token) and forward it on to the original RS server. As the introspec= tion response is a valid ID token for the resource owner, the RS will the= n apply all its normal access control checks to ensure that the resource = owner actually has the permissions that they have delegated to the client= . > > I think potentially that is quite an interesting application of this dr= aft, but I don=E2=80=99t think it was intended=21 I think probably a deci= sion should be made as to whether that kind of usage should be allowed an= d explicitly adjust the draft to either allow or deny it. If it is allowe= d, then possibly there should be a way for the caller to hint that they w= ant the response to be a valid ID token. > > Kind regards, > > Neil > > > On 18 Mar 2018, at 19:33, Torsten Lodderstedt wrote: > > Hi all, > > > > I just submitted a new draft that Vladimir Dzhuvinov and I have writt= en. It proposes a JWT-based response type for Token Introspection. The ob= jective is to provide resource servers with signed tokens in case they ne= ed cryptographic evidence that the AS created the token (e.g. for liabili= ty). > > > > I will present the new draft in the session on Wednesday. > > > > kind regards, > > Torsten. > > > > > Anfang der weitergeleiteten Nachricht: > > > Von: internet-drafts=40ietf.org (mailto:internet-drafts=40ietf.org)= > > > Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-i= ntrospection-response-00.txt > > > Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ > > > An: =22Vladimir Dzhuvinov=22 , =22Torsten Lodderstedt=22 > > > > > > > > > A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-res= ponse-00.txt > > > has been successfully submitted by Torsten Lodderstedt and posted t= o the > > > IET=46 repository. > > > > > > Name: draft-lodderstedt-oauth-jwt-introspection-response > > > Revision: 00 > > > Title: JWT Response for OAuth Token Introspection > > > Document date: 2018-03-15 > > > Group: Individual Submission > > > Pages: 5 > > > URL: https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-j= wt-introspection-response-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jw= t-introspection-response/ > > > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-i= ntrospection-response-00 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-lodderstedt-o= auth-jwt-introspection-response > > > > > > > > > Abstract: > > > This draft proposes an additional JSON Web Token (JWT) based respon= se > > > for OAuth 2.0 Token Introspection. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of s= ubmission > > > until the htmlized version and diff are available at tools.ietf.org= (http://tools.ietf.org/). > > > > > > The IET=46 Secretariat > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org (mailto:OAuth=40ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth > --5abd174d_2ae8944a_2e4d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
I=E2=80=99ve just realised that =E2=80=9Ccrit=E2=80=9D is for headers = while the =E2=80=9Cscope=E2=80=9D claim is in the payload, so a different= approach would be needed in that case (or the scope would need to be dup= licated into the headers).=C2=A0

Kind regards,

Neil

--

On= Wednesday, Mar 28, 2018 at 4:41 pm, Neil Madden <neil.madden=40forgerock.com> wrote:=
I like this draft, bu= t I want to clarify if it is intended that the response JWT could be inte= rpreted as an OpenID Connect ID Token=3F As the set of claims can overlap= (in particular, all required ID token claims are valid token introspecti= on response fields) and it seems highly likely that an AS will use the sa= me keys for signing both (and it definitely will when the client=5Fsecret= is used for signing), the signed response JWT could well be indistinguis= hable from an ID token (for the resource owner) with some additional clai= ms.

If th= is is not the case, then maybe consider adding a =E2=80=9Ccrit=E2=80=9D: = =5B=E2=80=9Cscope=E2=80=9D=5D claim to the response (https://t= ools.ietf.org/html/rfc7515=23section-4.1.11) to indicate that the sco= pe claim must be understood.

=
I can think of one potential use-case (I=E2=80=99= ll let you decide the merits of it) where it might actually be useful to = explicitly allow the response to be an ID Token. Consider an application = (RS) that uses a traditional authorization model: it authenticates a user= , sets a cookie, and then based on who that user is makes dynamic access = control decisions to see what they are allowed to do (e.g., ACLs, RBAC, w= hatever). An easy way to upgrade this app to modern standards would be to= replace the home-spun authentication system with OIDC, but leave the res= t in place. Now the system uses OIDC to authenticate the user, sets the I= D token as the cookie, and then still applies the same access control dec= isions that it always has done.

Now imagine that a new requirement comes in to= support OAuth 2.0 access tokens to allow delegation to third-party apps.= A really simple way to achieve that would be to put a filter/reverse pro= xy in front of the RS that extracts access tokens coming in, performs sig= ned JWT token introspection against the AS to validate the token and then= checks the the scopes are appropriate for the request. It can then simpl= y replace the access token in the original request with the signed token = introspection response (as ID token) and forward it on to the original RS= server. As the introspection response is a valid ID token for the resour= ce owner, the RS will then apply all its normal access control checks to = ensure that the resource owner actually has the permissions that they hav= e delegated to the client.

I think potentially that is quite an interesting = application of this draft, but I don=E2=80=99t think it was intended=21 I= think probably a decision should be made as to whether that kind of usag= e should be allowed and explicitly adjust the draft to either allow or de= ny it. If it is allowed, then possibly there should be a way for the call= er to hint that they want the response to be a valid ID token.

Kind regards,=

Ne= il

On 18 Mar 2018, at 19:33, Torsten Lod= derstedt <torsten=40lodderstedt.net> wrote:

Hi all,

I just submitted a new draft that Vladimir = Dzhuvinov and I have written. It proposes a JWT-based response type for T= oken Introspection. The objective is to provide resource servers with sig= ned tokens in case they need cryptographic evidence that the AS created t= he token (e.g. for liability).=C2=A0

I will present the new draft in the sess= ion on Wednesday.

kind regards,
Torsten.=C2=A0

Anfang der weitergeleiteten Na= chricht:

Von: internet-drafts=40iet= f.org
Betreff= : New Ver= sion Notification for draft-lodderstedt-oauth-jwt-introspection-response-= 00.txt
Datu= m: 18. M=C3=A4rz 2018 um 20= :19:37 MEZ
An: = =22Vladimir Dzhuvinov=22 &l= t;vladimi= r=40connect2id.com>, =22Torsten Lodderstedt=22 <torsten=40lodderstedt.ne= t>


A new version of I-D, draft= -lodderstedt-oauth-jwt-introspection-response-00.txt
ha= s been successfully submitted by Torsten Lodderstedt and posted to theIET=46 repository.

N= ame: draft-lodderstedt-oauth-jwt-introspection-response
= Revision: 00
Title: JWT Response for OAuth Token Introspe= ction
Document date: 2018-03-15
Group:= = = Individual Submission
Pages: 5
URL: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-= drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/= draft-lodderstedt-oauth-jwt-introspection-response/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-int= rospection-response-00
Htmlized: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://= datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-r= esponse


Abstr= act:
=C2=A0=C2=A0This draft proposes an additional JSO= N Web Token (JWT) based response
=C2=A0=C2=A0for OAuth= 2.0 Token Introspection.




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

The IET=46 Secretariat

<= /div>

=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
= OAuth mailing list
OAuth=40ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
<= br class=3D=22=22>
--5abd174d_2ae8944a_2e4d-- --5abd174d_625558ec_2e4d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJavRdNAAoJEJD4Q99O3axdrBcP/RQUliBDp0esQUOcWuk76tOszBu683HBYm7g SzpwsuJefjNPD+mK7oUr3iRX2ydvemLhGnI1k3WIKHAPYh7Qvy6DFlHslDr2h2OpjOyoM1quNXra +CGJMTLXRHTdAt56XMPdzj9O8FrJUsutaQWAnH5/YghhCbLrdhxVX8TZlCQzSy8qOZtw1GMcPW5H FQYlNR4qnLK+U+BWftqdPUXVXRkYqGkzsfZSpOtjo2uXtpcBGZnhqC5M7unS4DLuKTDLA4j0bFST Wr6DiVWCRc5v70SQEG7xe09hel0CLz2+xE0K0dWN4o0gm0OpISvYPsJJjHKkx833c646y1lzqcdf ovsMhThHc0H51XSIiTIELo86NNyzsCd7iD8Tf9Xzj8KayspGGbJMRGfN5nYhYkdt/yCoAwTUKV2f ZNXmdA4eVhdsfs6KIem2grYBmqpNBX5XskaZ3V2EdO0UnaRikuyB4/42XX/aHG2YdGHDXAooH7Nl bpfHn8Pgijn706PgjHSmEjzaj9CiZ67ZqPWRUv7BRpXjt4p2zQWV+sij1u8uwzyGKJZKM7ccfWxZ XKZK1S9Pacd08Zj3yHGoBlDSQDtSJSR7S0OO6Uavh05ahoiIjEyA0vU6yk+Vs8GIqYphBh645FnX 3SO2ypBnwrH6nrOX6tBsh383JMOXik0uVZvwzZu6 =asl+ -----END PGP SIGNATURE----- --5abd174d_625558ec_2e4d-- From nobody Thu Mar 29 10:55:12 2018 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 8CE0612D949 for ; Thu, 29 Mar 2018 10:55:10 -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=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwdpkD0dO123 for ; Thu, 29 Mar 2018 10:55:05 -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 038FF12D7E6 for ; Thu, 29 Mar 2018 10:55:04 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z73so6162142wrb.0 for ; Thu, 29 Mar 2018 10:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=PlUSi4U9tgEG3Akk4Nz4Qv0JhW8gmFsthORWuu7YTTw=; b=bU8Nqw/0vr287Pcbas/W2/+Oq/CcI7N+rtHr4Kek/apBFO6OaAGudWLPm7UlY0QLm6 +EiinGoUzCo2jv8i1r7qTY89DFRNEqLrTUwpa/HGi0A7WNwuqDLJKRg8q+7MeO5NMBiF FDM/j2/TEkVO47S8y3PLTEaS0uU6ebqykXYqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=PlUSi4U9tgEG3Akk4Nz4Qv0JhW8gmFsthORWuu7YTTw=; b=McaBpLgm1PADp0AiEoXgvEqVgZ6L1ULVK/+0NdOaIU3Z4sEDI4C/5ERqH6npMl/WO/ 7uWzORVhE4mS3ujoJ9Cw6beQv8bbb/a7N9tr2rNVVYjXHj74IshN8qA5oj8aAEQHxRer nRRO8IZneoOLrC+D76/uGZ/3rEpBemafcM64pte/b+rWZssxDNQIu/rpRIVhSWI/x3sk Ua01lRdRaY62Pr4hHN/trqqznROAQkh6j3GFY9GSPcgT/ypshpWp4VH2lnRoE0J+Q2Dp qZ40W4FSx1VGLrR4EYxGZTcOJJD4s8Ztm+dXr2vP15pqx4OSXXONTF5vfsKiFfaVtBkN mSAg== X-Gm-Message-State: AElRT7F89cH8mXZFACn7rfRBbutt5whdchgkXVZL3BFhdwglnO/2fEUX zOcd5pHSFwjEtb4Qa3vKNFNwWJWmbXc= X-Google-Smtp-Source: AIpwx4/Yupgp084RADKkGBuCHCgG9mrObCrsGdfz28GR0aAqLBNI7IeJE7360VwrquxJ27NLeGiaYA== X-Received: by 10.223.225.4 with SMTP id d4mr6932397wri.24.1522346103058; Thu, 29 Mar 2018 10:55:03 -0700 (PDT) Received: from [192.168.1.81] (148.199.93.209.dyn.plus.net. [209.93.199.148]) by smtp.gmail.com with ESMTPSA id l1sm1399989wmh.25.2018.03.29.10.55.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 10:55:01 -0700 (PDT) Date: Thu, 29 Mar 2018 18:54:04 +0100 From: Neil Madden To: John Bradley Cc: oauth , Rifaat Shekh-Yusef Message-ID: <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> In-Reply-To: <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="5abd283d_46e87ccd_2e4d"; protocol="application/pgp-signature" Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 29 Mar 2018 17:55:10 -0000 --5abd283d_46e87ccd_2e4d Content-Type: multipart/alternative; boundary="5abd283c_238e1f29_2e4d" --5abd283c_238e1f29_2e4d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks, and understood. The privacy concerns are mostly around correlating activity of *clients*,= which may or may not reveal activity patterns of users using those clien= ts. I don=E2=80=99t know how much of a concern that is in reality, but th= ought it should be mentioned. A colleague also made the following comment about the draft: =E2=80=9CIt is still quite common to terminate TLS in a load balancer or = proxy, and to deploy authorization servers in a secure network zone behin= d an intermediate in a DMZ. In these cases, TLS would not be established = between the client and authorization server as per =C2=A72, but informati= on about the TLS handshake may be made available by other means (typicall= y adding to a downstream header) allowing lookup and verification of the = client certificate as otherwise described. Given the prevalence of this a= pproach it would be good to know whether such a deployment would be compl= iant or not.=E2=80=9D Kind regards, Neil -- > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley wrote: > Thanks for the feedback. We will review your comments and reply. > > One data point is that this will not be the only POP spec. The spec usi= ng token binding vs mtls has better privacy properties. It is UK Open ban= king that has pressed us to come up with a standard to help with interope= rability. > > This spec has been simplified in some ways to facilitate the majority o= f likely deployments. > > I understand that in future certificates may have better than SHA256 ha= shes. > > Regards > John B. > > > > On Mar 29, 2018, at 12:18 PM, Neil Madden wrote: > > > > Hi, > > > > I have reviewed this draft and have a number of comments, below. =46o= rgeRock have not yet implemented this draft, but there is interest in imp= lementing it at some point. (Disclaimer: We have no firm commitments on t= his at the moment, I do not speak for =46orgeRock, etc). > > > > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23section-3.1= defines a new confirmation method =E2=80=9Cx5t=23S256=E2=80=9D. However,= there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can co= ntain a JSON Web Key, which itself can contain a =E2=80=9Cx5t=23S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft proposes:= > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D =7D =7D > > > > but you can already do: > > > > =7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80=9D: =7B =E2=80=A6 ,= =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D =7D > > > > If the intent is just to save some space and avoid the mandatory fiel= ds of the existing JWK types, maybe this would be better addressed by def= ining a new JWK type which only has a thumbprint=3F e.g., =7B =E2=80=9Ckt= y=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C= =E2=80=A6=E2=80=9D =7D. > > > > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2= =80=9D a bit of a misnomer: it=E2=80=99s really only the client authentic= ation that we are interested here, and the fact that the server also auth= enticates with a certificate is not hugely relevant to this particular sp= ec (although it is to the overall security of OAuth). Also, TLS defines n= on-certificate based authentication mechanisms (e.g. TLS-SRP extension fo= r password authenticated key exchange, PSK for pre-shared key authenticat= ion) and even non-X.509 certificate types (https://www.iana.org/assignmen= ts/tls-extensiontype-values/tls-extensiontype-values.xhtml=23tls-extensio= ntype-values-3). I=E2=80=99d prefer that the draft explicitly referred to= =E2=80=9CX.509 Client Certificate Authentication=E2=80=9D rather than mu= tual TLS, and changed identifiers like =E2=80=98tls=5Fclient=5Fauth=E2=80= =99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23section-2.1.1= ) to something more explicit like =E2=80=98tls=5Fx509=5Fpki=5Fclient=5Fau= th=E2=80=99. > > > > This is especially confusing in section 3 on sender constrained acces= s tokens, as there are two different servers involved: the AS and the pro= tected resource server, but there is no =E2=80=9Cmutual=E2=80=9D authenti= cation between them, only between each of them and the client. > > > > 3. The draft links to the TLS 1.2 R=46C, while the original OAuth 2.0= R=46C only specifies TLS 1.0. Is the intention that TLS 1.2+ is required= =3F The wording in Section 5.1 doesn=E2=80=99t seem clear if this could a= lso be used with TLS 1.0 or 1.1, or whether it is only referring to futur= e TLS versions. > > > > 4. It might be useful to have a discussion for implementors of whethe= r TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact= the use of client certificates, if at all=3F > > > > 5. Section 3 defines sender-constrained access tokens in terms of the= confirmation key claims (e.g., R=46C 7800 for JWT). However, the OAuth 2= .0 Pop Architecture draft defines sender constraint and key confirmation = as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-arc= hitecture-08=23section-6.2). The draft should decide which of those it is= implementing and if sender constraint is intended, then reusing the conf= irmation key claims seems misleading. (I think this mTLS draft is doing k= ey confirmation so should drop the language about sender constrained toke= ns). > > > > 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/= html/draft-ietf-oauth-pop-architecture-08=23section-5): > > > > Strong, fresh session keys: > > > > Session keys MUST be strong and fresh. Each session deserves an > > independent session key, i.e., one that is generated specifically > > for the intended use. In context of OAuth this means that keying > > material is created in such a way that can only be used by the > > combination of a client instance, protected resource, and > > authorization scope. > > > > > > However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-= ietf-oauth-mtls-07=23section-3) says: > > > > The client makes protected resource requests as described in > > =5BR=46C6750=5D, however, those requests MUST be made over a mutually= > > authenticated TLS connection using the same certificate that was used= > > for mutual TLS at the token endpoint. > > > > These two statements are contradictory: the OAuth 2.0 PoP architectur= e effectively requires a fresh key-pair to be used for every access token= request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server. > > > > In the self-signed case (and even in the CA case, with a bit of work = - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is pe= rfectly possible for the client to generate a fresh key-pair for each acc= ess token and include the certificate on the token request (e.g., as per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03=23se= ction-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D value shou= ld probably be described). This should probably at least be an option. > > > > 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it allo= ws correlation of activity. > > > > 8. This is maybe a more general point, but R=46C 6750 defines the Aut= horization: Bearer scheme (https://tools.ietf.org/html/rfc6750=23section-= 2) for a client to communicate it=E2=80=99s access token to the RS in a s= tandard way. As sender-constrained access tokens are not strictly bearer = tokens any more, should this draft also register a new scheme for that=3F= Should there be a generic PoP scheme=3F > > > > 9. The Security Considerations should really make some mention of the= long history of attacks against X.509 certificate chain validation, e.g.= failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an exi= sting TLS library to perform these checks rather than implementing your o= wn checks. This relates to Justin=E2=80=99s comments around DN parsing an= d normalisation. > > > > 10. The PKI client authentication method (https://tools.ietf.org/html= /draft-ietf-oauth-mtls-07=23section-2.1) makes no mention at all of certi= ficate revocation and how to handle checking for that (CRLs, OCSP - with = stapling=3F). Neither does the Security Considerations. If this is a deta= il to be agreed between then AS and the CA (or just left up to the AS TLS= stack) then that should perhaps be made explicit. Again, there are priva= cy considerations with some of these mechanisms, as OCSP requests are typ= ically sent in the clear (plain HTTP) and so allow an observer to see whi= ch clients are connecting to which AS. > > > > 11. The same comment applies to how the protected resource checks for= revocation of the certificate presented during sender constrained access= token usage. Should the RS make its own revocation checks based on the i= nformation in the certificate presented, or should it trust the certifica= te while the access token is still valid=3F If the latter case, is the AS= responsible for revoking any access tokens whose certificate have been r= evoked (if so, should it be doing an OCSP call on every token introspecti= on request, and should the RS be passing on the certificate/serial number= on that request)=3F If the Client request uses OCSP Stapling (https://en= .wikipedia.org/wiki/OCSP=5Fstapling) how can the RS verify the signature = on that if it does not have a separate trust relationship with the CA alr= eady=3F > > > > 12. The use of only SHA-256 fingerprints means that the security stre= ngth of the sender-constrained access tokens is limited by the collision = resistance of SHA-256 - roughly =E2=80=9C128-bit security=22 - without a = new specification for a new thumbprint algorithm. An implication of this = is that is is fairly pointless for the protected resource TLS stack to ev= er negotiate cipher suites/keys with a higher level of security. In more = crystal ball territory, if a practical quantum computer becomes a possibi= lity within the lifetime of this spec, then the expected collision resist= ance of SHA-256 would drop quadratically, allowing an attacker to find a = colliding certificate in =7E2=5E64 effort. If we are going to pick just o= ne thumbprint hash algorithm, I would prefer we pick SHA-512. > > > > Cheers, > > > > Neil > > > > > > > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef wrote: > > > > > > All, > > > > > > As discussed during the meeting today, we are starting a WGLC on th= e MTLS document: > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 > > > > > > Please, review the document and provide feedback on any issues you = see with the document. > > > > > > The WGLC will end in two weeks, on April 2, 2018. > > > > > > Regards, > > > Rifaat and Hannes > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > OAuth mailing list > > > OAuth=40ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > OAuth mailing list > > OAuth=40ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --5abd283c_238e1f29_2e4d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22>
Thanks, and understood.=C2=A0

The privacy con= cerns are mostly around correlating activity of *clients*, which may or m= ay not reveal activity patterns of users using those clients. I don=E2=80= =99t know how much of a concern that is in reality, but thought it should= be mentioned.=C2=A0

A colleague also made the f= ollowing comment about the draft:

=E2=80=9CIt is still quite common to terminate TLS in a load balancer or p= roxy, and to deploy authorization servers in a secure network zone behind= an intermediate in a DMZ. In these cases, TLS would not be established b= etween the client and authorization server as per =C2=A72, but informatio= n about the TLS handshake may be made available by other means (typically= adding to a downstream header) allowing lookup and verification of the c= lient certificate as otherwise described. Given the prevalence of this ap= proach it would be good to know whether such a deployment would be compli= ant or not.=E2=80=9D

= Kind regards,
Neil
--

On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley = <ve7jtb=40ve7jtb.com>= ; wrote:
Thanks for the feedback. We will review your comm= ents and reply.

One data point is that this will not be the only= POP spec. The spec using token binding vs mtls has better privacy proper= ties. It is UK Open banking that has pressed us to come up with a standar= d to help with interoperability.

This spec has been simplified i= n some ways to facilitate the majority of likely deployments.

I = understand that in future certificates may have better than SHA256 hashes= .

Regards
John B.


On Mar 29, 2018, at 12:18 PM, Neil Madden <neil.madden=40forgerock.co= m> wrote:

Hi,

I have reviewed this draft and have a = number of comments, below. =46orgeRock have not yet implemented this draf= t, but there is interest in implementing it at some point. (Disclaimer: W= e have no firm commitments on this at the moment, I do not speak for =46o= rgeRock, etc).

1. https://tools.ietf.org/html/draft-ietf-oauth-m= tls-07=23section-3.1 defines a new confirmation method =E2=80=9Cx5t=23S25= 6=E2=80=9D. However, there is already a confirmation method =E2=80=9Cjwk=E2= =80=9D that can contain a JSON Web Key, which itself can contain a =E2=80= =9Cx5t=23S526=E2=80=9D claim with exactly the same syntax and semantics. = The draft proposes:

=7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cx5t= =23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D =7D

but you ca= n already do:

=7B =E2=80=9Ccnf=E2=80=9D: =7B =E2=80=9Cjwk=E2=80= =9D: =7B =E2=80=A6 , =E2=80=9Cx5t=23S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80= =9D =7D =7D =7D

If the intent is just to save some space and avo= id the mandatory fields of the existing JWK types, maybe this would be be= tter addressed by defining a new JWK type which only has a thumbprint=3F = e.g., =7B =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t=23S2= 56=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D =7D.

2. I find the nami= ng =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a bit of a mis= nomer: it=E2=80=99s really only the client authentication that we are int= erested here, and the fact that the server also authenticates with a cert= ificate is not hugely relevant to this particular spec (although it is to= the overall security of OAuth). Also, TLS defines non-certificate based = authentication mechanisms (e.g. TLS-SRP extension for password authentica= ted key exchange, PSK for pre-shared key authentication) and even non-X.5= 09 certificate types (https://www.iana.org/assignments/tls-extensiontype-= values/tls-extensiontype-values.xhtml=23tls-extensiontype-values-3). I=E2= =80=99d prefer that the draft explicitly referred to =E2=80=9CX.509 Clien= t Certificate Authentication=E2=80=9D rather than mutual TLS, and changed= identifiers like =E2=80=98tls=5Fclient=5Fauth=E2=80=99 (https://tools.ie= tf.org/html/draft-ietf-oauth-mtls-07=23section-2.1.1) to something more e= xplicit like =E2=80=98tls=5Fx509=5Fpki=5Fclient=5Fauth=E2=80=99.
This is especially confusing in section 3 on sender constrained access t= okens, as there are two different servers involved: the AS and the protec= ted resource server, but there is no =E2=80=9Cmutual=E2=80=9D authenticat= ion between them, only between each of them and the client.

3. T= he draft links to the TLS 1.2 R=46C, while the original OAuth 2.0 R=46C o= nly specifies TLS 1.0. Is the intention that TLS 1.2+ is required=3F The = wording in Section 5.1 doesn=E2=80=99t seem clear if this could also be u= sed with TLS 1.0 or 1.1, or whether it is only referring to future TLS ve= rsions.

4. It might be useful to have a discussion for implement= ors of whether TLS session resumption (and PSK in TLS 1.3) and/or renegot= iation impact the use of client certificates, if at all=3F

5. Se= ction 3 defines sender-constrained access tokens in terms of the confirma= tion key claims (e.g., R=46C 7800 for JWT). However, the OAuth 2.0 Pop Ar= chitecture draft defines sender constraint and key confirmation as differ= ent things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture= -08=23section-6.2). The draft should decide which of those it is implemen= ting and if sender constraint is intended, then reusing the confirmation = key claims seems misleading. (I think this mTLS draft is doing key confir= mation so should drop the language about sender constrained tokens).
=
6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org= /html/draft-ietf-oauth-pop-architecture-08=23section-5):

Strong= , fresh session keys:

Session keys MUST be strong and fresh. Ea= ch session deserves an
independent session key, i.e., one that is ge= nerated specifically
for the intended use. In context of OAuth this = means that keying
material is created in such a way that can only be= used by the
combination of a client instance, protected resource, a= nd
authorization scope.


However, the mTLS draft sectio= n 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=23section-3) sa= ys:

The client makes protected resource requests as described i= n
=5BR=46C6750=5D, however, those requests MUST be made over a mutua= lly
authenticated TLS connection using the same certificate that was= used
for mutual TLS at the token endpoint.

These two state= ments are contradictory: the OAuth 2.0 PoP architecture effectively requi= res a fresh key-pair to be used for every access token request, whereas t= his draft proposes reusing the same long-lived client certificate for eve= ry single access token and every resource server.

In the self-si= gned case (and even in the CA case, with a bit of work - e.g., https://ww= w.vaultproject.io/docs/secrets/pki/index.html) it is perfectly possible f= or the client to generate a fresh key-pair for each access token and incl= ude the certificate on the token request (e.g., as per https://tools.ietf= .org/html/draft-ietf-oauth-pop-key-distribution-03=23section-5.1 - in whi= ch case an appropriate =E2=80=9Calg=E2=80=9D value should probably be des= cribed). This should probably at least be an option.

7. The use = of a single client certificate with every resource server (RS) should be = called out in a Privacy Considerations section, as it allows correlation = of activity.

8. This is maybe a more general point, but R=46C 67= 50 defines the Authorization: Bearer scheme (https://tools.ietf.org/html/= rfc6750=23section-2) for a client to communicate it=E2=80=99s access toke= n to the RS in a standard way. As sender-constrained access tokens are no= t strictly bearer tokens any more, should this draft also register a new = scheme for that=3F Should there be a generic PoP scheme=3F

9. Th= e Security Considerations should really make some mention of the long his= tory of attacks against X.509 certificate chain validation, e.g. failure = to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in= parsing DNs, etc. It should be strongly suggested to use an existing TLS= library to perform these checks rather than implementing your own checks= . This relates to Justin=E2=80=99s comments around DN parsing and normali= sation.

10. The PKI client authentication method (https://tools.= ietf.org/html/draft-ietf-oauth-mtls-07=23section-2.1) makes no mention at= all of certificate revocation and how to handle checking for that (CRLs,= OCSP - with stapling=3F). Neither does the Security Considerations. If t= his is a detail to be agreed between then AS and the CA (or just left up = to the AS TLS stack) then that should perhaps be made explicit. Again, th= ere are privacy considerations with some of these mechanisms, as OCSP req= uests are typically sent in the clear (plain HTTP) and so allow an observ= er to see which clients are connecting to which AS.

11. The same= comment applies to how the protected resource checks for revocation of t= he certificate presented during sender constrained access token usage. Sh= ould the RS make its own revocation checks based on the information in th= e certificate presented, or should it trust the certificate while the acc= ess token is still valid=3F If the latter case, is the AS responsible for= revoking any access tokens whose certificate have been revoked (if so, s= hould it be doing an OCSP call on every token introspection request, and = should the RS be passing on the certificate/serial number on that request= )=3F If the Client request uses OCSP Stapling (https://en.wikipedia.org/w= iki/OCSP=5Fstapling) how can the RS verify the signature on that if it do= es not have a separate trust relationship with the CA already=3F
12. The use of only SHA-256 fingerprints means that the security strengt= h of the sender-constrained access tokens is limited by the collision res= istance of SHA-256 - roughly =E2=80=9C128-bit security=22 - without a new= specification for a new thumbprint algorithm. An implication of this is = that is is fairly pointless for the protected resource TLS stack to ever = negotiate cipher suites/keys with a higher level of security. In more cry= stal ball territory, if a practical quantum computer becomes a possibilit= y within the lifetime of this spec, then the expected collision resistanc= e of SHA-256 would drop quadratically, allowing an attacker to find a col= liding certificate in =7E2=5E64 effort. If we are going to pick just one = thumbprint hash algorithm, I would prefer we pick SHA-512.

Cheer= s,

Neil


On 19 Mar 20= 18, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf=40gmail.com> wrote: <= br>
All,

As discussed during the meeting today, we are start= ing a WGLC on the MTLS document:
https://tools.ietf.org/html/draft-ie= tf-oauth-mtls-07

Please, review the document and provide feedbac= k on any issues you see with the document.

The WGLC will end in = two weeks, on April 2, 2018.

Regards,
Rifaat and Hannes
=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf= .org
https://www.ietf.org/mailman/listinfo/oauth
--5abd283c_238e1f29_2e4d-- --5abd283d_46e87ccd_2e4d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary Comment: https://www.canarymail.io Charset: UTF-8 wsFcBAABCgAGBQJavSg8AAoJEJD4Q99O3axdh8YQAK8o2FKqGfG2qi/OQbsl2Xbp7srvOxVIEaQB MhuuELvDg/auXc0n6BgaybSYkoTWDDZ3byUoGSgFcRXTTjcbX0+3mlN1xySWDuNeeKCFhOqNiP+3 buDwumDuCFFq78DwCmOUK4zu9172GAQAOGGVaM7xPJZ8IOJ6zJbHcCacFelaXQMxHze/Y/ToUUr6 GG5QVdESrpVOThrYJfoLoXatkwoUd5xpQDqgwf0LNd1ftXLrSabVMZUnvJeXkUm8MnXmHIRM+bra pe8m7bnwfHXejoxyx7SUZZseCLfiXvaXxVgYQR4b01W14CN2AwQvuNs8vSCuZgTsx+e8e21+adw+ d/70o0SuYyNIgkuK9f69hGAY+alFtAo3R+BTf2eU0JCC/UlL3mq3jmqzMymtg9UY/Ss0xuase1fl jAUVRt3wt1I7o5FQujD94bmOYCDT3UP6saDR/kBjQ5Q5/x+++rVw1QLI0U/1QvhdWhaRNj8GlTLe /e03lDEeg0VNAZ5pJgVboyhKs/69YQHUPfqdG5Wxn4+GU12fsayh0hwnNhVT6KTHNzx9zTf2uGCb D7XoDAYfaUCmkeey0fX0EwwO/AwMZt1rOze6MOl5JqZVkhqsU9Fwqfzs9sn9yXCIn7rDHpk2dEzm AZL0oa3HXu/59KM4TjTtY45t27tOq9ziH+NL+Kl+ =3hRW -----END PGP SIGNATURE----- --5abd283d_46e87ccd_2e4d-- From nobody Thu Mar 29 11:57:20 2018 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 3280A12DA42 for ; Thu, 29 Mar 2018 11:57:18 -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 Joz3EmNZLfKN for ; Thu, 29 Mar 2018 11:57:13 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 9333D120725 for ; Thu, 29 Mar 2018 11:57:13 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w12so7303572qti.4 for ; Thu, 29 Mar 2018 11:57:13 -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=UIQDz3mAvgWMts+Jt5k4sErq1L4vlCaW/Kr3xopUoAA=; b=VIScV3nQupPIN6/EaBS71+jAAfFHFM/ooSUevRxo5TFOYVrSMuts2prKH0/HlOcYls d04xeTzbOPl9ErwtlfKCs6vvuMWVkegKPr32eCGMsWhnuvjQYj/x16yqy/C8/KoYbMmU HmJHH7/toJyN95iu/LLHDxraeX+BNlF7uW7Ue3qlVDXZv8r7cUNuSy/luqeM8vLhz4Xr 49dfmCkiNZnwKN9lxloDFDT/+vk30SGx1TM338snTtr3FriPE9jJHKLAlqvuI/Fb6LtY 3/g9O6qhKQpgNJe17/FFBj2he1lbQGPmgjsyNK6YTeVshizI3594EVNpwdKAPlfffSKI YzcA== 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=UIQDz3mAvgWMts+Jt5k4sErq1L4vlCaW/Kr3xopUoAA=; b=pwuuyecG72aHa/tmBL9u06kGksQPFm/Z3P2qWsNNmI8L+f3tamJ56I8QyppCX7+Cp6 UIEN6Er87/QAlt6/1bGn1cqNSC9xDAQcEwJtY6T9MKqDJBOVi609j0nOmz7trFh8WQK0 SnirhRNOw4zk5o0N6jHvMph5GLiQWlay4zZ8Os5qMQKRmzfgsKdAk2BTA+YMKJmPqeyH TGxba67wKj7VdVjsesn/UHd4gPnlyc3MJPuEWWsE7So7fQhtV5yL+EI3d6NVsZ5DuWZe J48q/AyYVoCXDa2Tuk+zzC7BDxY8ERzpkk9aXQWQ0JU50S0Ru7KAzpgid8v/zQX3Qkft eO7g== X-Gm-Message-State: ALQs6tA2r3f4HN6wJpIzDWDMDeUKJX1LzWYLeTmCgrj393sfyhlK28PG lP0XtH6VurwuA9VHHR79ffEt9A== X-Google-Smtp-Source: AIpwx488lZPD7oVkfU696bnXoPJIIL+BWIp/o1GXxRtW+y9EA5UcDCRjauWaAg0CDIf4E/FKBi77zg== X-Received: by 10.200.23.213 with SMTP id r21mr13089203qtk.314.1522349831353; Thu, 29 Mar 2018 11:57:11 -0700 (PDT) Received: from [192.168.8.100] ([181.201.215.42]) by smtp.gmail.com with ESMTPSA id r51sm5604381qtr.23.2018.03.29.11.57.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 11:57:10 -0700 (PDT) From: John Bradley Message-Id: <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DD3D5F6D-F5C1-4486-95E5-6448B77C48A0" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 29 Mar 2018 15:57:06 -0300 In-Reply-To: <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> Cc: oauth , Rifaat Shekh-Yusef To: Neil Madden References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 29 Mar 2018 18:57:18 -0000 --Apple-Mail=_DD3D5F6D-F5C1-4486-95E5-6448B77C48A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes that is quite a common deployment scenario. I think that is the = way most of the Open Banking implementations have deployed it currently. = =20 The intent is to support that. One problem is that how the certificate = is transmitted to the application tends to be load balancer/reverse = proxy specific as no real standard exists. If you think that needs to be clarified text is welcome. John B. > On Mar 29, 2018, at 2:54 PM, Neil Madden = wrote: >=20 > Thanks, and understood.=20 >=20 > The privacy concerns are mostly around correlating activity of = *clients*, which may or may not reveal activity patterns of users using = those clients. I don=E2=80=99t know how much of a concern that is in = reality, but thought it should be mentioned.=20 >=20 > A colleague also made the following comment about the draft: >=20 > =E2=80=9CIt is still quite common to terminate TLS in a load balancer = or proxy, and to deploy authorization servers in a secure network zone = behind an intermediate in a DMZ. In these cases, TLS would not be = established between the client and authorization server as per =C2=A72, = but information about the TLS handshake may be made available by other = means (typically adding to a downstream header) allowing lookup and = verification of the client certificate as otherwise described. Given the = prevalence of this approach it would be good to know whether such a = deployment would be compliant or not.=E2=80=9D >=20 > Kind regards, > Neil > -- >=20 > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley > wrote: > Thanks for the feedback. We will review your comments and reply.=20 >=20 > One data point is that this will not be the only POP spec. The spec = using token binding vs mtls has better privacy properties. It is UK Open = banking that has pressed us to come up with a standard to help with = interoperability.=20 >=20 > This spec has been simplified in some ways to facilitate the majority = of likely deployments.=20 >=20 > I understand that in future certificates may have better than SHA256 = hashes.=20 >=20 > Regards=20 > John B.=20 >=20 >=20 >> On Mar 29, 2018, at 12:18 PM, Neil Madden = wrote:=20 >>=20 >> Hi,=20 >>=20 >> I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc).=20 >>=20 >> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes:=20 >>=20 >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6= =E2=80=9D } }=20 >>=20 >> but you can already do:=20 >>=20 >> { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }=20 >>=20 >> If the intent is just to save some space and avoid the mandatory = fields of the existing JWK types, maybe this would be better addressed = by defining a new JWK type which only has a thumbprint? e.g., { = =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D }.=20 >>=20 >> 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client = authentication that we are interested here, and the fact that the server = also authenticates with a certificate is not hugely relevant to this = particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types = (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d prefer that the = draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.=20= >>=20 >> This is especially confusing in section 3 on sender constrained = access tokens, as there are two different servers involved: the AS and = the protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D = authentication between them, only between each of them and the client.=20= >>=20 >> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 = RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? = The wording in Section 5.1 doesn=E2=80=99t seem clear if this could also = be used with TLS 1.0 or 1.1, or whether it is only referring to future = TLS versions.=20 >>=20 >> 4. It might be useful to have a discussion for implementors of = whether TLS session resumption (and PSK in TLS 1.3) and/or renegotiation = impact the use of client certificates, if at all?=20 >>=20 >> 5. Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2). The draft should decide which of those it is implementing and if = sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so = should drop the language about sender constrained tokens).=20 >>=20 >> 6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5):=20 >>=20 >> Strong, fresh session keys:=20 >>=20 >> Session keys MUST be strong and fresh. Each session deserves an=20 >> independent session key, i.e., one that is generated specifically=20 >> for the intended use. In context of OAuth this means that keying=20 >> material is created in such a way that can only be used by the=20 >> combination of a client instance, protected resource, and=20 >> authorization scope.=20 >>=20 >>=20 >> However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) says:=20= >>=20 >> The client makes protected resource requests as described in=20 >> [RFC6750], however, those requests MUST be made over a mutually=20 >> authenticated TLS connection using the same certificate that was used=20= >> for mutual TLS at the token endpoint.=20 >>=20 >> These two statements are contradictory: the OAuth 2.0 PoP = architecture effectively requires a fresh key-pair to be used for every = access token request, whereas this draft proposes reusing the same = long-lived client certificate for every single access token and every = resource server.=20 >>=20 >> In the self-signed case (and even in the CA case, with a bit of work = - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is = perfectly possible for the client to generate a fresh key-pair for each = access token and include the certificate on the token request (e.g., as = per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#secti= on-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D value should = probably be described). This should probably at least be an option.=20 >>=20 >> 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it = allows correlation of activity.=20 >>=20 >> 8. This is maybe a more general point, but RFC 6750 defines the = Authorization: Bearer scheme = (https://tools.ietf.org/html/rfc6750#section-2) for a client to = communicate it=E2=80=99s access token to the RS in a standard way. As = sender-constrained access tokens are not strictly bearer tokens any = more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme?=20 >>=20 >> 9. The Security Considerations should really make some mention of the = long history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation.=20 >>=20 >> 10. The PKI client authentication method = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes = no mention at all of certificate revocation and how to handle checking = for that (CRLs, OCSP - with stapling?). Neither does the Security = Considerations. If this is a detail to be agreed between then AS and the = CA (or just left up to the AS TLS stack) then that should perhaps be = made explicit. Again, there are privacy considerations with some of = these mechanisms, as OCSP requests are typically sent in the clear = (plain HTTP) and so allow an observer to see which clients are = connecting to which AS.=20 >>=20 >> 11. The same comment applies to how the protected resource checks for = revocation of the certificate presented during sender constrained access = token usage. Should the RS make its own revocation checks based on the = information in the certificate presented, or should it trust the = certificate while the access token is still valid? If the latter case, = is the AS responsible for revoking any access tokens whose certificate = have been revoked (if so, should it be doing an OCSP call on every token = introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the = RS verify the signature on that if it does not have a separate trust = relationship with the CA already?=20 >>=20 >> 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512.=20 >>=20 >> Cheers,=20 >>=20 >> Neil=20 >>=20 >>=20 >>> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef = wrote:=20 >>>=20 >>> All,=20 >>>=20 >>> As discussed during the meeting today, we are starting a WGLC on the = MTLS document:=20 >>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=20 >>>=20 >>> Please, review the document and provide feedback on any issues you = see with the document.=20 >>>=20 >>> The WGLC will end in two weeks, on April 2, 2018.=20 >>>=20 >>> Regards,=20 >>> Rifaat and Hannes=20 >>>=20 >>> _______________________________________________=20 >>> OAuth mailing list=20 >>> OAuth@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/oauth=20 >>=20 >> _______________________________________________=20 >> OAuth mailing list=20 >> OAuth@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/oauth=20 >=20 --Apple-Mail=_DD3D5F6D-F5C1-4486-95E5-6448B77C48A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes = that is quite a common deployment scenario.   I think that is the = way most of the Open Banking implementations have deployed it currently. =   

The = intent is to support that.   One problem is that how the = certificate is transmitted to the application tends to be load = balancer/reverse proxy specific as no real standard exists.

If you think that needs = to be clarified text is welcome.

John B.



On Mar = 29, 2018, at 2:54 PM, Neil Madden <neil.madden@forgerock.com> wrote:

Thanks, and = understood. 

The privacy concerns are mostly around correlating activity = of *clients*, which may or may not reveal activity patterns of users = using those clients. I don=E2=80=99t know how much of a concern that is = in reality, but thought it should be mentioned. 

A colleague also made = the following comment about the draft:

=E2=80=9CIt is still quite common = to terminate TLS in a load balancer or proxy, and to deploy = authorization servers in a secure network zone behind an intermediate in = a DMZ. In these cases, TLS would not be established between the client = and authorization server as per =C2=A72, but information about the TLS = handshake may be made available by other means (typically adding to a = downstream header) allowing lookup and verification of the client = certificate as otherwise described. Given the prevalence of this = approach it would be good to know whether such a deployment would be = compliant or not.=E2=80=9D

Kind = regards,
Neil
=
--

=
On = Thursday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7jtb@ve7jtb.com> = wrote:
Thanks for the feedback. We = will review your comments and reply.

One = data point is that this will not be the only POP spec. The spec using = token binding vs mtls has better privacy properties. It is UK Open = banking that has pressed us to come up with a standard to help with = interoperability.

This spec has been = simplified in some ways to facilitate the majority of likely = deployments.

I understand that in future = certificates may have better than SHA256 hashes.

Regards
John B.

=
On Mar 29, 2018, at = 12:18 PM, Neil Madden <neil.madden@forgerock.com> wrote:

Hi,

I have reviewed this draft = and have a number of comments, below. ForgeRock have not yet implemented = this draft, but there is interest in implementing it at some point. = (Disclaimer: We have no firm commitments on this at the moment, I do not = speak for ForgeRock, etc).

1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.= 1 defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. = However, there is already a confirmation method =E2=80=9Cjwk=E2=80=9D = that can contain a JSON Web Key, which itself can contain a = =E2=80=9Cx5t#S526=E2=80=9D claim with exactly the same syntax and = semantics. The draft proposes:

{ = =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2= =80=9D } }

but you can already do:

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D= : { =E2=80=A6 , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D = } } }

If the intent is just to save some = space and avoid the mandatory fields of the existing JWK types, maybe = this would be better addressed by defining a new JWK type which only has = a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }.
=
2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and = =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really only the = client authentication that we are interested here, and the fact that the = server also authenticates with a certificate is not hugely relevant to = this particular spec (although it is to the overall security of OAuth). = Also, TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d = prefer that the draft explicitly referred to =E2=80=9CX.509 Client = Certificate Authentication=E2=80=9D rather than mutual TLS, and changed = identifiers like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.= 1.1) to something more explicit like =E2=80=98tls_x509_pki_client_auth= =E2=80=99.

This is especially confusing = in section 3 on sender constrained access tokens, as there are two = different servers involved: the AS and the protected resource server, = but there is no =E2=80=9Cmutual=E2=80=9D authentication between them, = only between each of them and the client.

3. The draft links to the TLS 1.2 RFC, while the original = OAuth 2.0 RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is = required? The wording in Section 5.1 doesn=E2=80=99t seem clear if this = could also be used with TLS 1.0 or 1.1, or whether it is only referring = to future TLS versions.

4. It might be = useful to have a discussion for implementors of whether TLS session = resumption (and PSK in TLS 1.3) and/or renegotiation impact the use of = client certificates, if at all?

5. = Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 8#section-6.2). The draft should decide which of those it is = implementing and if sender constraint is intended, then reusing the = confirmation key claims seems misleading. (I think this mTLS draft is = doing key confirmation so should drop the language about sender = constrained tokens).

6. The OAuth 2.0 PoP = Architecture draft says (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 8#section-5):

Strong, fresh session = keys:

Session keys MUST be strong and = fresh. Each session deserves an
independent session key, = i.e., one that is generated specifically
for the = intended use. In context of OAuth this means that keying
= material is created in such a way that can only be used by the
combination of a client instance, protected resource, and =
authorization scope.


However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3<= /a>) says:

The client makes protected = resource requests as described in
[RFC6750], however, = those requests MUST be made over a mutually
= authenticated TLS connection using the same certificate that was used =
for mutual TLS at the token endpoint.
=
These two statements are contradictory: the OAuth 2.0 PoP = architecture effectively requires a fresh key-pair to be used for every = access token request, whereas this draft proposes reusing the same = long-lived client certificate for every single access token and every = resource server.

In the self-signed case = (and even in the CA case, with a bit of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) = it is perfectly possible for the client to generate a fresh key-pair for = each access token and include the certificate on the token request = (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-03#section-5.1 - in which case an appropriate =E2=80=9Calg=E2=80=9D= value should probably be described). This should probably at least be = an option.

7. The use of a single client = certificate with every resource server (RS) should be called out in a = Privacy Considerations section, as it allows correlation of activity. =

8. This is maybe a more general point, = but RFC 6750 defines the Authorization: Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2) for a = client to communicate it=E2=80=99s access token to the RS in a standard = way. As sender-constrained access tokens are not strictly bearer tokens = any more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme?

9. The = Security Considerations should really make some mention of the long = history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation.

10. The PKI = client authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.= 1) makes no mention at all of certificate revocation and how to = handle checking for that (CRLs, OCSP - with stapling?). Neither does the = Security Considerations. If this is a detail to be agreed between then = AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with = some of these mechanisms, as OCSP requests are typically sent in the = clear (plain HTTP) and so allow an observer to see which clients are = connecting to which AS.

11. The same = comment applies to how the protected resource checks for revocation of = the certificate presented during sender constrained access token usage. = Should the RS make its own revocation checks based on the information in = the certificate presented, or should it trust the certificate while the = access token is still valid? If the latter case, is the AS responsible = for revoking any access tokens whose certificate have been revoked (if = so, should it be doing an OCSP call on every token introspection = request, and should the RS be passing on the certificate/serial number = on that request)? If the Client request uses OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the = RS verify the signature on that if it does not have a separate trust = relationship with the CA already?

12. The = use of only SHA-256 fingerprints means that the security strength of the = sender-constrained access tokens is limited by the collision resistance = of SHA-256 - roughly =E2=80=9C128-bit security" - without a new = specification for a new thumbprint algorithm. An implication of this is = that is is fairly pointless for the protected resource TLS stack to ever = negotiate cipher suites/keys with a higher level of security. In more = crystal ball territory, if a practical quantum computer becomes a = possibility within the lifetime of this spec, then the expected = collision resistance of SHA-256 would drop quadratically, allowing an = attacker to find a colliding certificate in ~2^64 effort. If we are = going to pick just one thumbprint hash algorithm, I would prefer we pick = SHA-512.

Cheers,

Neil


On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

All,

As discussed during the = meeting today, we are starting a WGLC on the MTLS document:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-07

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

The WGLC will end in two weeks, on April 2, 2018.

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

=

= --Apple-Mail=_DD3D5F6D-F5C1-4486-95E5-6448B77C48A0-- From nobody Fri Mar 30 09:57:35 2018 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 2F486124F57 for ; Fri, 30 Mar 2018 09:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 XiTwvLY5wwEE for ; Fri, 30 Mar 2018 09:57:30 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB181201FA for ; Fri, 30 Mar 2018 09:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1522429050; x=1553965050; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N9FMF28u3d2hMMJuf6n97IqgzuoMHvNGLyb6KfgP3oQ=; b=mJ51/uHEdy8hIWbgk9lu8k94Vp+ch9M9lvQalNAirsOmNk170qCzGG8k SkgrqbDtFNtFQ2SyE7cOczzo6DqKalV64vJfZ1uOPXnLx1jFc9SmZBpnG hClxpRc18SrDa3WP2AmSICrKRw5uD3qqK0Si5lLmxkcIWC6QrfTDHsbWk o=; X-IronPort-AV: E=Sophos;i="5.48,382,1517875200"; d="scan'208,217";a="714103869" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2018 16:57:28 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2UGvMP5034310 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2018 16:57:27 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 30 Mar 2018 16:57:26 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 30 Mar 2018 16:57:26 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 30 Mar 2018 16:57:26 +0000 From: "Richard Backman, Annabelle" To: Bill Burke CC: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Thread-Topic: [OAUTH-WG] What Does Logout Mean? Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvgA7mmyA//+yZICAAI4MgP//m6SAgACNGQCAAmHFgA== Date: Fri, 30 Mar 2018 16:57:26 +0000 Message-ID: <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.20] Content-Type: multipart/alternative; boundary="_000_7B1638A7ADAD4AE18AF86E26853D32C7amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 30 Mar 2018 16:57:33 -0000 --_000_7B1638A7ADAD4AE18AF86E26853D32C7amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGVuLGlzbid0IGFueSBiYWNrY2hhbm5lbCBsb2dvdXQgc3BlY2lmaWNhdGlvbiBtb3JlIG9m IGEgZnJhbWV3b3JrIHRoYW4gYW4gYWN0dWFsIHByb3RvY29sPw0KDQpDb21tZW50cyBpbmxpbmUu DQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNl cnZpY2VzDQoNCkZyb206IEJpbGwgQnVya2UgPGJidXJrZUByZWRoYXQuY29tPg0KRGF0ZTogV2Vk bmVzZGF5LCBNYXJjaCAyOCwgMjAxOCBhdCAyOjM1IFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+LCBSb2JlcnRvIENhcmJvbmUgPGNhcmJvbmVAZmJrLmV1Piwg Im9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+LCBOYXQgU2FraW11cmEgPG5hdEBzYWtp bXVyYS5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBXaGF0IERvZXMgTG9nb3V0IE1lYW4/ DQoNCg0KDQoNCk9uIFdlZCwgTWFyIDI4LCAyMDE4IGF0IDQ6MDkgUE0sIFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tPj4gd3JvdGU6DQpUaGF0IG1ha2VzIHNvbWV3aGF0IG1vcmUgc2Vuc2UgdG8gbWUgaWYgd2Xi gJlyZSB0YWxraW5nIGFib3V0IGFwcGxpY2F0aW9ucyB3aXRoIHN0aWNreSBzZXNzaW9ucy4gQWRk aW5nIGEgc2Vzc2lvbi1zcGVjaWZpYyBsb2dvdXQgVVJJIGludHJvZHVjZXMgc2VjdXJpdHkgY29u Y2VybnMgKGUuZy4gaG93IGRvZXMgdGhlIE9QIHZhbGlkYXRlIHRoZSBVUkkpIGFuZCBvbmx5IHdv cmtzIGlmIHRoZSBSUCBjYW4gcHJvdmlkZSBVUklzIHRoYXQgdGFyZ2V0IGluZGl2aWR1YWwgaG9z dHMgaW4gdGhlaXIgZmxlZXQuIFRoZSDigJxpcyB0aGlzIFNJRCB2YWxpZD/igJ0gZW5kcG9pbnQg c29sdXRpb24gdGhhdCBEYXZpZCBkZXNjcmliZWQgZG9lc27igJl0IHNjYWxlIGFuZCBkZXBlbmRz IG9uIFNJRCAod2hpY2ggaXMgT1BUSU9OQUwpLiBCb3RoIHNoaWZ0IHRoZSBidXJkZW4gb2Ygc3Rh dGUgbWFuYWdlbWVudCBvbnRvIHRoZSBPUCwgd2hpY2ggbWF5IG5vdCBiZSBpbiBhbnkgYmV0dGVy IHBvc2l0aW9uIHRvIGhhbmRsZSBpdC4NCg0KDQpGV0lXLCBvdXIgT1AgaW1wbGVtZW50YXRpb24g YWxsb3dzIFJQcyB0byByZWdpc3RlciB0aGVpciBub2RlIHNwZWNpZmljIGxvZ291dCBlbmRwb2lu dHMgYXQgYm9vdC4gIFRoaXMgcmVxdWVzdCBpcyBhdXRoZW50aWNhdGVkIHZpYSBjbGllbnQgYXV0 aGVudGljYXRpb24uICBXZSBhbHNvIGV4dGVuZGVkIGNvZGUgdG8gdG9rZW4gcmVxdWVzdCB0byB0 cmFuc21pdCB0aGUgbG9jYWwgc2Vzc2lvbiBpZC4gIFRoZSBPUCBzdG9yZXMgdGhpcyBpbmZvcm1h dGlvbi4gIEJhY2tjaGFubmVsIGxvZ291dCBQT1NUUyB0byBlYWNoIGFuZCBldmVyeSByZWdpc3Rl cmVkIG5vZGUgYW5kIHRyYW5zbWl0cyBhIEpXUyBzaWduZWQgYnkgdGhlIE9QIGNvbnRhaW5pbmcg dGhlIGxvY2FsIHNlc3Npb24gaWRzIHRvIGludmFsaWRhdGUuICBUaGF0J3MgYmVlbiBlbm91Z2gg dG8gY292ZXIgYWxsIHRoZSB3ZWlyZG5lc3Mgb3V0IHRoZXJlIHNvIGZhci4NCltyaWNoYW5uYV0N CldoYXQgZG9lcyDigJxhdCBib2904oCdIG1lYW4gaW4gdGhlIGNvbnRleHQgb2YgT3BlbklEIENv bm5lY3Q/IERvIHlvdSBtZWFuIHRoYXQgZm9yIGV2ZXJ5IGxvZ291dCwgdGhlIE9QIG1ha2VzIGEg QmFja2NoYW5uZWwgTG9nb3V0IHJlcXVlc3QgdG8gZWFjaCBvZiB0aGUgY2xpZW504oCZcyBub2Rl LXNwZWNpZmljIGxvZ291dCBlbmRwb2ludHM/IElmIHRoYXTigJlzIHRoZSBjYXNlLCB3aHkgY2Fu 4oCZdCB0aGUgY2xpZW50IG1ha2UgdGhvc2UgY2FsbHMgdGhlbXNlbHZlcywgZnJvbSB3aGljaGV2 ZXIgaG9zdCBoYXBwZW5zIHRvIHJlY2VpdmUgdGhlIEJhY2tjaGFubmVsIExvZ291dCByZXF1ZXN0 Pw0KDQpTaW5jZSB0aGUgY2xpZW50IG9ubHkgY2FyZXMgYWJvdXQgbm9kZS1sb2NhbCBzdGF0ZSwg dGhleSBzaG91bGQgYmUgYWJsZSB0byBtYWludGFpbiB0aGUgbWFwcGluZyBiZXR3ZWVuIE9QIHNl c3Npb24gSURzIGFuZCBsb2NhbCBzZXNzaW9uIElEcyBvbiB0aGVpciBzaWRlLg0KWy9yaWNoYW5u YV0NClRoaXMgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQg aW4gdGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgcmF0aGVyIHRoYW4gaW4gdGhlIHNwZWNpZmlj YXRpb24uIEVzcGVjaWFsbHkgd2hlbiB3ZSBjb25zaWRlciB0aGF0IHRoZXJlIGFyZSBpbXBsZW1l bnRhdGlvbi1zcGVjaWZpYyBxdWVzdGlvbnMgbHVya2luZyBpbiB0aGUgZWRnZSBjYXNlcy4gKGUu Zy4gd2hhdCBoYXBwZW5zIHdoZW4gYSB1c2VyIGNvbWVzIGluIHdpdGggdmFsaWQgY29va2llcywg YnV0IG5vIHNlcnZlci1zaWRlIHNlc3Npb24gc3RhdGU/KQ0KDQoNClRoZW4saXNuJ3QgYW55IGJh Y2tjaGFubmVsIGxvZ291dCBzcGVjaWZpY2F0aW9uIG1vcmUgb2YgYSBmcmFtZXdvcmsgdGhhbiBh biBhY3R1YWwgcHJvdG9jb2w/DQpbcmljaGFubmFdDQpJdOKAmXMgbmVpdGhlci4gVG8gcXVvdGUg dGhlIGFic3RyYWN0LCBpdOKAmXMg4oCc4oCmYSBsb2dvdXQgbWVjaGFuaXNt4oCmLuKAnSBJIHRo aW5rIGl04oCZcyBhcHByb3ByaWF0ZSBmb3IgdGhlIHNwZWNpZmljYXRpb24gdG8gZm9jdXMgb24g dGhvc2UgYXNwZWN0cyBvZiB0aGUgbWVjaG5hbmlzbSB0aGF0IG11c3QgYmUgc3RhbmRhcmRpemVk IGluIG9yZGVyIHRvIGhhdmUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIE9QcyBhbmQgUlBzLiBX aGF0IHdl4oCZcmUgZGlzY3Vzc2luZyBmYWxscyBvdXRzaWRlIG9mIHRoYXQsIGFzIHN0aWNreSBz ZXNzaW9uIGltcGxlbWVudGF0aW9ucyBhcmUgdGhlbXNlbHZlcyBwcm9wcmlldGFyeSBhbmQgdGhl IGNsaWVudCBjYW4gYWRkcmVzcyB0aGlzIGlzc3VlIGludGVybmFsbHkgd2l0aG91dCBpbXBhY3Rp bmcgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIGxvZ291dCBtZWNoYW5pc20uDQoNClB1dCBh bm90aGVyIHdheSwgdGhlIHJlcXVpcmVtZW50IGlzIHRvIGdldCB0aGUgbG9nb3V0IHNpZ25hbCBm cm9tIE9QIHRvIFJQLiBXaGF0IHRoZSBSUCBkb2VzIHdpdGggaXQgYXQgdGhhdCBwb2ludCBpcyB1 cCB0byBpdC4NClsvcmljaGFubmFdDQoNCi0tDQpCaWxsIEJ1cmtlDQpSZWQgSGF0DQo= --_000_7B1638A7ADAD4AE18AF86E26853D32C7amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <171A85BE70541341BE023037F6028066@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZW4saXNuJ3QgYW55IGJhY2tj aGFubmVsIGxvZ291dCBzcGVjaWZpY2F0aW9uIG1vcmUgb2YgYSBmcmFtZXdvcmsgdGhhbiBhbiBh Y3R1YWwgcHJvdG9jb2w/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojREY0NkZGIj5Db21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QmlsbCBC dXJrZSAmbHQ7YmJ1cmtlQHJlZGhhdC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2Rh eSwgTWFyY2ggMjgsIDIwMTggYXQgMjozNSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5NaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20m Z3Q7LCBSb2JlcnRvIENhcmJvbmUgJmx0O2NhcmJvbmVAZmJrLmV1Jmd0OywgJnF1b3Q7b2F1dGhA aWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0OywgTmF0IFNha2ltdXJhICZsdDtu YXRAc2FraW11cmEub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBX aGF0IERvZXMgTG9nb3V0IE1lYW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBXZWQsIE1hciAyOCwg MjAxOCBhdCA0OjA5IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+cmljaGFubmFAYW1hem9uLmNv bTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsN CiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPlRoYXQgbWFrZXMgc29tZXdoYXQgbW9yZSBzZW5zZSB0byBtZSBpZiB3ZeKA mXJlIHRhbGtpbmcgYWJvdXQgYXBwbGljYXRpb25zIHdpdGggc3RpY2t5IHNlc3Npb25zLiBBZGRp bmcgYSBzZXNzaW9uLXNwZWNpZmljIGxvZ291dCBVUkkNCiBpbnRyb2R1Y2VzIHNlY3VyaXR5IGNv bmNlcm5zIChlLmcuIGhvdyBkb2VzIHRoZSBPUCB2YWxpZGF0ZSB0aGUgVVJJKSBhbmQgb25seSB3 b3JrcyBpZiB0aGUgUlAgY2FuIHByb3ZpZGUgVVJJcyB0aGF0IHRhcmdldCBpbmRpdmlkdWFsIGhv c3RzIGluIHRoZWlyIGZsZWV0LiBUaGUg4oCcaXMgdGhpcyBTSUQgdmFsaWQ/4oCdIGVuZHBvaW50 IHNvbHV0aW9uIHRoYXQgRGF2aWQgZGVzY3JpYmVkIGRvZXNu4oCZdCBzY2FsZSBhbmQgZGVwZW5k cyBvbiBTSUQgKHdoaWNoDQogaXMgT1BUSU9OQUwpLiBCb3RoIHNoaWZ0IHRoZSBidXJkZW4gb2Yg c3RhdGUgbWFuYWdlbWVudCBvbnRvIHRoZSBPUCwgd2hpY2ggbWF5IG5vdCBiZSBpbiBhbnkgYmV0 dGVyIHBvc2l0aW9uIHRvIGhhbmRsZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+RldJVywgb3VyIE9QIGltcGxlbWVudGF0aW9uIGFsbG93cyBS UHMgdG8gcmVnaXN0ZXIgdGhlaXIgbm9kZSBzcGVjaWZpYyBsb2dvdXQgZW5kcG9pbnRzIGF0IGJv b3QuJm5ic3A7IFRoaXMgcmVxdWVzdCBpcyBhdXRoZW50aWNhdGVkIHZpYSBjbGllbnQgYXV0aGVu dGljYXRpb24uJm5ic3A7IFdlIGFsc28gZXh0ZW5kZWQgY29kZSB0byB0b2tlbiByZXF1ZXN0DQog dG8gdHJhbnNtaXQgdGhlIGxvY2FsIHNlc3Npb24gaWQuJm5ic3A7IFRoZSBPUCBzdG9yZXMgdGhp cyBpbmZvcm1hdGlvbi4mbmJzcDsgQmFja2NoYW5uZWwgbG9nb3V0IFBPU1RTIHRvIGVhY2ggYW5k IGV2ZXJ5IHJlZ2lzdGVyZWQgbm9kZSBhbmQgdHJhbnNtaXRzIGEgSldTIHNpZ25lZCBieSB0aGUg T1AgY29udGFpbmluZyB0aGUgbG9jYWwgc2Vzc2lvbiBpZHMgdG8gaW52YWxpZGF0ZS4mbmJzcDsg VGhhdCdzIGJlZW4gZW5vdWdoIHRvIGNvdmVyIGFsbCB0aGUgd2VpcmRuZXNzDQogb3V0IHRoZXJl IHNvIGZhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iY29sb3I6I0RGNDZGRiI+W3JpY2hhbm5hXTxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6I0RGNDZGRiI+V2hhdCBkb2Vz IOKAnGF0IGJvb3TigJ0gbWVhbiBpbiB0aGUgY29udGV4dCBvZiBPcGVuSUQgQ29ubmVjdD8gRG8g eW91IG1lYW4gdGhhdCBmb3IgZXZlcnkgbG9nb3V0LCB0aGUgT1AgbWFrZXMgYSBCYWNrY2hhbm5l bCBMb2dvdXQgcmVxdWVzdCB0byBlYWNoIG9mIHRoZSBjbGllbnTigJlzIG5vZGUtc3BlY2lmaWMN CiBsb2dvdXQgZW5kcG9pbnRzPyBJZiB0aGF04oCZcyB0aGUgY2FzZSwgd2h5IGNhbuKAmXQgdGhl IGNsaWVudCBtYWtlIHRob3NlIGNhbGxzIHRoZW1zZWx2ZXMsIGZyb20gd2hpY2hldmVyIGhvc3Qg aGFwcGVucyB0byByZWNlaXZlIHRoZSBCYWNrY2hhbm5lbCBMb2dvdXQgcmVxdWVzdD88bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiNERjQ2 RkYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iY29sb3I6I0RGNDZGRiI+U2luY2UgdGhlIGNsaWVudCBvbmx5IGNhcmVzIGFib3V0IG5v ZGUtbG9jYWwgc3RhdGUsIHRoZXkgc2hvdWxkIGJlIGFibGUgdG8gbWFpbnRhaW4gdGhlIG1hcHBp bmcgYmV0d2VlbiBPUCBzZXNzaW9uIElEcyBhbmQgbG9jYWwgc2Vzc2lvbiBJRHMgb24gdGhlaXIg c2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiNERjQ2RkYiPlsvcmljaGFubmFdPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGlzIHNlZW1z IGxpa2Ugc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIGluIHRoZSBjbGllbnQg aW1wbGVtZW50YXRpb25zIHJhdGhlciB0aGFuIGluIHRoZSBzcGVjaWZpY2F0aW9uLiBFc3BlY2lh bGx5IHdoZW4NCiB3ZSBjb25zaWRlciB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbi1zcGVj aWZpYyBxdWVzdGlvbnMgbHVya2luZyBpbiB0aGUgZWRnZSBjYXNlcy4gKGUuZy4gd2hhdCBoYXBw ZW5zIHdoZW4gYSB1c2VyIGNvbWVzIGluIHdpdGggdmFsaWQgY29va2llcywgYnV0IG5vIHNlcnZl ci1zaWRlIHNlc3Npb24gc3RhdGU/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5UaGVuLGlzbid0IGFueSBiYWNrY2hhbm5lbCBsb2dvdXQgc3BlY2lm aWNhdGlvbiBtb3JlIG9mIGEgZnJhbWV3b3JrIHRoYW4gYW4gYWN0dWFsIHByb3RvY29sPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJj b2xvcjojREY0NkZGIj5bcmljaGFubmFdPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojREY0NkZGIj5JdOKAmXMgbmVpdGhlci4gVG8gcXVv dGUgdGhlIGFic3RyYWN0LCBpdOKAmXMg4oCc4oCmYSBsb2dvdXQgbWVjaGFuaXNt4oCmLuKAnSBJ IHRoaW5rIGl04oCZcyBhcHByb3ByaWF0ZSBmb3IgdGhlIHNwZWNpZmljYXRpb24gdG8gZm9jdXMg b24gdGhvc2UgYXNwZWN0cyBvZiB0aGUgbWVjaG5hbmlzbSB0aGF0IG11c3QNCiBiZSBzdGFuZGFy ZGl6ZWQgaW4gb3JkZXIgdG8gaGF2ZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gT1BzIGFuZCBS UHMuIFdoYXQgd2XigJlyZSBkaXNjdXNzaW5nIGZhbGxzIG91dHNpZGUgb2YgdGhhdCwgYXMgc3Rp Y2t5IHNlc3Npb24gaW1wbGVtZW50YXRpb25zIGFyZSB0aGVtc2VsdmVzIHByb3ByaWV0YXJ5IGFu ZCB0aGUgY2xpZW50IGNhbiBhZGRyZXNzIHRoaXMgaXNzdWUgaW50ZXJuYWxseSB3aXRob3V0IGlt cGFjdGluZyB0aGUgaW50ZXJvcGVyYWJpbGl0eQ0KIG9mIHRoZSBsb2dvdXQgbWVjaGFuaXNtLjxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6 I0RGNDZGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJjb2xvcjojREY0NkZGIj5QdXQgYW5vdGhlciB3YXksIHRoZSByZXF1aXJlbWVu dCBpcyB0byBnZXQgdGhlIGxvZ291dCBzaWduYWwgZnJvbSBPUCB0byBSUC4gV2hhdCB0aGUgUlAg ZG9lcyB3aXRoIGl0IGF0IHRoYXQgcG9pbnQgaXMgdXAgdG8gaXQuPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojREY0NkZGIj5bL3JpY2hh bm5hXTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkJpbGwgQnVya2U8YnI+ DQpSZWQgSGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7B1638A7ADAD4AE18AF86E26853D32C7amazoncom_-- From nobody Fri Mar 30 10:41:32 2018 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 00175127077 for ; Fri, 30 Mar 2018 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lmUnZGEO9Gyp for ; Fri, 30 Mar 2018 10:41:27 -0700 (PDT) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173]) (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 B80DF12704A for ; Fri, 30 Mar 2018 10:41:27 -0700 (PDT) Received: by mail-ua0-f173.google.com with SMTP id i2so5747081uak.8 for ; Fri, 30 Mar 2018 10:41:27 -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=mexwhlK02hdWHFuCwZ2Yv1KAUVQIJ4KE3btZOchjQOQ=; b=rB+W17cWzHsvorEU/H31Jz23vnxaNr7j/iA23ukZsTB4jsUnUvboGN5PHpOtXHWfd8 GcshB/G63FrnJDs6zU+U+dLYewfvAbSpbQlpA8qT0VasVd3idQfMJjYqVG9gTDn9guqd 8hI6NqcCm3TkMwdf6diyItYVS/cITzSnQocOGGJiLAPDr7qqwH6zRKFU+OshZBdAeXE2 nhF6sf/ohw8Ilb/xeERNiO5e++Vw7fMrvZjPKa/KxzM2oSlmzJiXY+10ZeD40oyOqZIP YlJpXhWtu+jU/89TReCDeu+BR1H1vR8umEYGeHFe5JijMDt3A3u675RWi5ndc4fXFPIG CEiw== X-Gm-Message-State: AElRT7EDLILFoB2XEUsPoPq1wEn0Gf6pHWewHSOcFbKsRgKsRGDRLG3X LnIeR5MkcmSLlbTwCwNiTIhx6Ocfq56dOtayPMejlA== X-Google-Smtp-Source: AIpwx4+84QAAM+UK6gYSqS8rJxBbuNsSw8JjCraS3ffVB69W4HshMdX5J0FR/FJrxSW5DCfZZRcbY1CZaXIzsz5XEPQ= X-Received: by 10.176.78.203 with SMTP id x11mr8307854uah.91.1522431686384; Fri, 30 Mar 2018 10:41:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.13.199 with HTTP; Fri, 30 Mar 2018 10:41:25 -0700 (PDT) In-Reply-To: <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> From: Bill Burke Date: Fri, 30 Mar 2018 13:41:25 -0400 Message-ID: To: "Richard Backman, Annabelle" Cc: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 30 Mar 2018 17:41:31 -0000 On Fri, Mar 30, 2018 at 12:57 PM, Richard Backman, Annabelle wrote: > > FWIW, our OP implementation allows RPs to register their node specific > logout endpoints at boot. This request is authenticated via client > authentication. We also extended code to token request to transmit the > local session id. The OP stores this information. Backchannel logout PO= STS > to each and every registered node and transmits a JWS signed by the OP > containing the local session ids to invalidate. That's been enough to co= ver > all the weirdness out there so far. > > [richanna] > > What does =E2=80=9Cat boot=E2=80=9D mean in the context of OpenID Connect= ? Do you mean that > for every logout, the OP makes a Backchannel Logout request to each of th= e > client=E2=80=99s node-specific logout endpoints? Just in case....This is all for backchannel logouts which are out of band from the browser. Node boots up and registers with the Auth Server its logout endpoint. POST /authserver/node_registration client_id=3Dmyclient& client_secret=3Dgeheim& node=3Dhttps://node.internal:8443/app/oidc/_logout As I mentioned earlier, the node doing code to token request will also pass its local session id so it can be associated with the Auth server's SID. When an admin initiates a forced logout, a backchannel logout request is sent to each client's logout endpoint. If the client has nodes that have registered, this request is duplicated to each node. > If that=E2=80=99s the case, why can=E2=80=99t the > client make those calls themselves, from whichever host happens to receiv= e > the Backchannel Logout request? > Your assuming that each node has knowledge of cluster topology which isn't neccesarily true. Each additional proprietary extension we've made is optional. Nodes can optionally register themselves. Nodes can optionally send local session ids with the code to token request. > > > Since the client only cares about node-local state, they should be able t= o > maintain the mapping between OP session IDs and local session IDs on thei= r > side. > Considering a cluster of load balanced web applications that dont' have session replication and don't have knowledge of cluster topology. The only way for the Auth Server to perform backchannel logout is to send the same backchannel logout to each and every node. There's also the case where the nodes do support session replication, but don't have a way to get at topology or a way to store the association between the SID and application session id. In this case you don't need node registration, but you do need a way to associate the SID with the local session id. As a IDP vendor, you have to support all these types of clients. Telling developers that they are just going to have to manage this themselves is not really an option if you want adoption. Bill From nobody Fri Mar 30 11:16:04 2018 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 1336612420B for ; Fri, 30 Mar 2018 11:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 qrT3_kmGGlsa for ; Fri, 30 Mar 2018 11:15:56 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 1260312711B for ; Fri, 30 Mar 2018 11:15:39 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2UI4FKP019887; Fri, 30 Mar 2018 18:15:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type; s=corp-2017-10-26; bh=EfxzK+WzCehs/E0v3QAPJC+9xt9DxzGBNppkPqC0J1k=; b=S4wJOAUu1vEIljQepp4uzUCyJWcsWly+eQ78oufp4YqSt7fHXzs74a2f0YUuNW2KsGGA lFWeI8J1ZyPkSyGsQg6gnBwxUWLbA8MfaB85dwbBQbrK6Tn7MdnkgNQctRWcV7KvA3cD mI8mMGxLMHOClWcdoaQ5uY0RCLBusMlDOWQJW9x6+xXHtlA1M9Nk8+QpUbJ6x/1O7Fm8 mVc+SXmw7RRuYNVodae/FAPF8g3j+7ZkiERp0qQAg4WxjYNsWwlubOgM/qi/8+C/gxEw g0CHbUaXIy70sJE0ZgFHUEG7aXzU3C79L2MlTNSNFZCnJrpMj4BSXeC804Mjm2d566GI +A== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2h1t5kg2hb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 18:15:35 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2UI3Vsh018059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 18:03:32 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2UI3TPF007333; Fri, 30 Mar 2018 18:03:30 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 30 Mar 2018 11:03:27 -0700 (PDT) From: Vivek Biswas Sender: Vivek Biswas To: John Bradley , Neil Madden Cc: oauth References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> In-Reply-To: <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.4551.0 (x86)] Content-Type: multipart/alternative; boundary="__1522433009517188891abhmp0013.oracle.com" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8848 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300184 Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 30 Mar 2018 18:16:02 -0000 --__1522433009517188891abhmp0013.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are additional challenges which we have faced. =C2=A0 A.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Most of the Mutual SSL communication as me= ntioned below terminates at the LBR and the LBR needs to have client certif= icates to trust the client. But lot of times the connection from LBR to Aut= horization server may be non-SSL. =C2=A0 The CN, SHA-256 thumprint and serial number of the Client Cert are sent as = header to the AuthzServer/Backend Server. However, if the connection from L= BR to AuthzServer/Backend Server is unencrypted it is prone to MIM attacks.= Hence, it=E2=80=99s a MUST requirement to have one-way SSL from LBR to Aut= hzServer/Backend Server, so that the headers passed are not compromised. =C2=A0 This is a MOST common scenario in a real world. And we don=E2=80=99t want e= veryone come up with their own names for the header. There should be some k= ind of standardization around the header names. =C2=A0 Regards Vivek Biswas, CISSP =C2=A0 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Thursday, March 29, 2018 11:57 AM To: Neil Madden Cc: oauth Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 =C2=A0 Yes that is quite a common deployment scenario. =C2=A0 I think that is the = way most of the Open Banking implementations have deployed it currently. = =C2=A0=C2=A0 =C2=A0 The intent is to support that. =C2=A0 One problem is that how the certifica= te is transmitted to the application tends to be load balancer/reverse prox= y specific as no real standard exists. =C2=A0 If you think that needs to be clarified text is welcome. =C2=A0 John B. =C2=A0 =C2=A0 On Mar 29, 2018, at 2:54 PM, Neil Madden wrote: =C2=A0 Thanks, and understood.=C2=A0 =C2=A0 The privacy concerns are mostly around correlating activity of *clients*, w= hich may or may not reveal activity patterns of users using those clients. = I don=E2=80=99t know how much of a concern that is in reality, but thought = it should be mentioned.=C2=A0 =C2=A0 A colleague also made the following comment about the draft: =C2=A0 =E2=80=9CIt is still quite common to terminate TLS in a load balancer or pr= oxy, and to deploy authorization servers in a secure network zone behind an= intermediate in a DMZ. In these cases, TLS would not be established betwee= n the client and authorization server as per =C2=A72, but information about= the TLS handshake may be made available by other means (typically adding t= o a downstream header) allowing lookup and verification of the client certi= ficate as otherwise described. Given the prevalence of this approach it wou= ld be good to know whether such a deployment would be compliant or not.=E2= =80=9D =C2=A0 Kind regards, Neil -- =C2=A0 On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley wrote: Thanks for the feedback. We will review your comments and reply.=20 One data point is that this will not be the only POP spec. The spec using t= oken binding vs mtls has better privacy properties. It is UK Open banking t= hat has pressed us to come up with a standard to help with interoperability= .=20 This spec has been simplified in some ways to facilitate the majority of li= kely deployments.=20 I understand that in future certificates may have better than SHA256 hashes= .=20 Regards=20 John B.=20 On Mar 29, 2018, at 12:18 PM, Neil Madden wrote:=20 Hi,=20 I have reviewed this draft and have a number of comments, below. ForgeRock = have not yet implemented this draft, but there is interest in implementing = it at some point. (Disclaimer: We have no firm commitments on this at the m= oment, I do not speak for ForgeRock, etc).=20 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defines= a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is al= ready a confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a JSON W= eb Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80=9D claim with ex= actly the same syntax and semantics. The draft proposes:=20 { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6= =E2=80=9D } }=20 but you can already do:=20 { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5= t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }=20 If the intent is just to save some space and avoid the mandatory fields of = the existing JWK types, maybe this would be better addressed by defining a = new JWK type which only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80= =9D }.=20 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client authentication= that we are interested here, and the fact that the server also authenticat= es with a certificate is not hugely relevant to this particular spec (altho= ugh it is to the overall security of OAuth). Also, TLS defines non-certific= ate based authentication mechanisms (e.g. TLS-SRP extension for password au= thenticated key exchange, PSK for pre-shared key authentication) and even n= on-X.509 certificate types (https://www.iana.org/assignments/tls-extensiont= ype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3). I=E2= =80=99d prefer that the draft explicitly referred to =E2=80=9CX.509 Client = Certificate Authentication=E2=80=9D rather than mutual TLS, and changed ide= ntifiers like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/htm= l/draft-ietf-oauth-mtls-07#section-2.1.1) to something more explicit like = =E2=80=98tls_x509_pki_client_auth=E2=80=99.=20 This is especially confusing in section 3 on sender constrained access toke= ns, as there are two different servers involved: the AS and the protected r= esource server, but there is no =E2=80=9Cmutual=E2=80=9D authentication bet= ween them, only between each of them and the client.=20 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC onl= y specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The wordin= g in Section 5.1 doesn=E2=80=99t seem clear if this could also be used with= TLS 1.0 or 1.1, or whether it is only referring to future TLS versions.=20 4. It might be useful to have a discussion for implementors of whether TLS = session resumption (and PSK in TLS 1.3) and/or renegotiation impact the use= of client certificates, if at all?=20 5. Section 3 defines sender-constrained access tokens in terms of the confi= rmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 Pop Arc= hitecture draft defines sender constraint and key confirmation as different= things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#s= ection-6.2). The draft should decide which of those it is implementing and = if sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so sho= uld drop the language about sender constrained tokens).=20 6. The OAuth 2.0 PoP Architecture draft says (https://tools.ietf.org/html/d= raft-ietf-oauth-pop-architecture-08#section-5):=20 Strong, fresh session keys:=20 Session keys MUST be strong and fresh. Each session deserves an=20 independent session key, i.e., one that is generated specifically=20 for the intended use. In context of OAuth this means that keying=20 material is created in such a way that can only be used by the=20 combination of a client instance, protected resource, and=20 authorization scope.=20 However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-o= auth-mtls-07#section-3) says:=20 The client makes protected resource requests as described in=20 [RFC6750], however, those requests MUST be made over a mutually=20 authenticated TLS connection using the same certificate that was used=20 for mutual TLS at the token endpoint.=20 These two statements are contradictory: the OAuth 2.0 PoP architecture effe= ctively requires a fresh key-pair to be used for every access token request= , whereas this draft proposes reusing the same long-lived client certificat= e for every single access token and every resource server.=20 In the self-signed case (and even in the CA case, with a bit of work - e.g.= , https://www.vaultproject.io/docs/secrets/pki/index.html) it is perfectly = possible for the client to generate a fresh key-pair for each access token = and include the certificate on the token request (e.g., as per https://tool= s.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#section-5.1 - in w= hich case an appropriate =E2=80=9Calg=E2=80=9D value should probably be des= cribed). This should probably at least be an option.=20 7. The use of a single client certificate with every resource server (RS) s= hould be called out in a Privacy Considerations section, as it allows corre= lation of activity.=20 8. This is maybe a more general point, but RFC 6750 defines the Authorizati= on: Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2) for a cli= ent to communicate it=E2=80=99s access token to the RS in a standard way. A= s sender-constrained access tokens are not strictly bearer tokens any more,= should this draft also register a new scheme for that? Should there be a g= eneric PoP scheme?=20 9. The Security Considerations should really make some mention of the long = history of attacks against X.509 certificate chain validation, e.g. failure= to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in = parsing DNs, etc. It should be strongly suggested to use an existing TLS li= brary to perform these checks rather than implementing your own checks. Thi= s relates to Justin=E2=80=99s comments around DN parsing and normalisation.= =20 10. The PKI client authentication method (https://tools.ietf.org/html/draft= -ietf-oauth-mtls-07#section-2.1) makes no mention at all of certificate rev= ocation and how to handle checking for that (CRLs, OCSP - with stapling?). = Neither does the Security Considerations. If this is a detail to be agreed = between then AS and the CA (or just left up to the AS TLS stack) then that = should perhaps be made explicit. Again, there are privacy considerations wi= th some of these mechanisms, as OCSP requests are typically sent in the cle= ar (plain HTTP) and so allow an observer to see which clients are connectin= g to which AS.=20 11. The same comment applies to how the protected resource checks for revoc= ation of the certificate presented during sender constrained access token u= sage. Should the RS make its own revocation checks based on the information= in the certificate presented, or should it trust the certificate while the= access token is still valid? If the latter case, is the AS responsible for= revoking any access tokens whose certificate have been revoked (if so, sho= uld it be doing an OCSP call on every token introspection request, and shou= ld the RS be passing on the certificate/serial number on that request)? If = the Client request uses OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_s= tapling) how can the RS verify the signature on that if it does not have a = separate trust relationship with the CA already?=20 12. The use of only SHA-256 fingerprints means that the security strength o= f the sender-constrained access tokens is limited by the collision resistan= ce of SHA-256 - roughly =E2=80=9C128-bit security" - without a new specific= ation for a new thumbprint algorithm. An implication of this is that is is = fairly pointless for the protected resource TLS stack to ever negotiate cip= her suites/keys with a higher level of security. In more crystal ball terri= tory, if a practical quantum computer becomes a possibility within the life= time of this spec, then the expected collision resistance of SHA-256 would = drop quadratically, allowing an attacker to find a colliding certificate in= ~2^64 effort. If we are going to pick just one thumbprint hash algorithm, = I would prefer we pick SHA-512.=20 Cheers,=20 Neil=20 On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef wrote:=20 All,=20 As discussed during the meeting today, we are starting a WGLC on the MTLS d= ocument:=20 https://tools.ietf.org/html/draft-ietf-oauth-mtls-07=20 Please, review the document and provide feedback on any issues you see with= the document.=20 The WGLC will end in two weeks, on April 2, 2018.=20 Regards,=20 Rifaat and Hannes=20 _______________________________________________=20 OAuth mailing list=20 HYPERLINK "mailto:OAuth@ietf.org"OAuth@ietf.org=20 https://www.ietf.org/mailman/listinfo/oauth=20 _______________________________________________=20 OAuth mailing list=20 HYPERLINK "mailto:OAuth@ietf.org"OAuth@ietf.org=20 https://www.ietf.org/mailman/listinfo/oauth=20 =C2=A0 =C2=A0 --__1522433009517188891abhmp0013.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

There are= additional challenges which we have faced.

 

= A.      Most of the Mutual SSL communication as mentioned below terminates at = the LBR and the LBR needs to have client certificates to trust the client. = But lot of times the connection from LBR to Authorization server may be non= -SSL.

 

The = CN, SHA-256 thumprint and serial number of the Client Cert are sent as head= er to the AuthzServer/Backend Server. However, if the connection from LBR t= o AuthzServer/Backend Server is unencrypted it is prone to MIM attacks. Hen= ce, it=E2=80=99s a MUST requirement to have one-way SSL from LBR to AuthzSe= rver/Backend Server, so that the headers passed are not compromised.

 

This is a MOST common scenario in a real world. And we don=E2=80=99t wa= nt everyone come up with their own names for the header. There should be so= me kind of standardization around the header names.

 

Regards

Vive= k Biswas, CISSP

 = ;

From: John Bradley [ma= ilto:ve7jtb@ve7jtb.com]
Sent: Thursday, March 29, 2018 11:57 AM<= br>To: Neil Madden
Cc: oauth
Subject: Re: [OAUTH= -WG] WGLC on draft-ietf-oauth-mtls-07

 

Yes that is quit= e a common deployment scenario.   I think that is the way most of the = Open Banking implementations have deployed it currently.   <= /o:p>

 

The intent is to support that.   One problem is that how = the certificate is transmitted to the application tends to be load balancer= /reverse proxy specific as no real standard exists.

 

If you think that needs to be clarified text is welcome.

 

John B.

 

 



On Mar 29, 2018, at 2:54 PM, = Neil Madden <neil.madden@fo= rgerock.com> wrote:

&n= bsp;

Thanks, a= nd understood. 

<= span style=3D'font-size:10.0pt;font-family:"Helvetica","sans-serif"'>&= nbsp;

The privacy concerns are m= ostly around correlating activity of *clients*, which may or may not reveal= activity patterns of users using those clients. I don=E2=80=99t know how m= uch of a concern that is in reality, but thought it should be mentioned.&nb= sp;

 

A colleague also made the following comment= about the draft:

&nbs= p;

=E2=80=9CIt is still qui= te common to terminate TLS in a load balancer or proxy, and to deploy autho= rization servers in a secure network zone behind an intermediate in a DMZ. = In these cases, TLS would not be established between the client and authori= zation server as per =C2=A72, but information about the TLS handshake may b= e made available by other means (typically adding to a downstream header) a= llowing lookup and verification of the client certificate as otherwise desc= ribed. Given the prevalence of this approach it would be good to know wheth= er such a deployment would be compliant or not.=E2=80=9D

 

Kind regards,

Neil

<= p class=3DMsoNormal>--

&nbs= p;

<= span style=3D'font-size:10.0pt;font-family:"Helvetica","sans-serif"'>On Thu= rsday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the feedback. We will review your comments and = reply.

One data point is that this will not be the only POP spec. T= he spec using token binding vs mtls has better privacy properties. It is UK= Open banking that has pressed us to come up with a standard to help with i= nteroperability.

This spec has been simplified in some ways to faci= litate the majority of likely deployments.

I understand that in fut= ure certificates may have better than SHA256 hashes.

Regards
Jo= hn B.



On Mar 29, 2018, at 12:18 PM, N= eil Madden <neil.madden@for= gerock.com> wrote:

Hi,

I have reviewed this draft an= d have a number of comments, below. ForgeRock have not yet implemented this= draft, but there is interest in implementing it at some point. (Disclaimer= : We have no firm commitments on this at the moment, I do not speak for For= geRock, etc).

1. https://tools.ietf.org/html/draft-ietf-oauth-mtl= s-07#section-3.1 defines a new confirmation method =E2=80=9Cx5t#S256=E2= =80=9D. However, there is already a confirmation method =E2=80=9Cjwk=E2=80= =9D that can contain a JSON Web Key, which itself can contain a =E2=80=9Cx5= t#S526=E2=80=9D claim with exactly the same syntax and semantics. The draft= proposes:

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D } }

but you can already do:

{ = =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , =E2=80=9Cx5t#= S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }

If the intent is j= ust to save some space and avoid the mandatory fields of the existing JWK t= ypes, maybe this would be better addressed by defining a new JWK type which= only has a thumbprint? e.g., { =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80= =9D, =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D }.

2. = I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80=9D a= bit of a misnomer: it=E2=80=99s really only the client authentication that= we are interested here, and the fact that the server also authenticates wi= th a certificate is not hugely relevant to this particular spec (although i= t is to the overall security of OAuth). Also, TLS defines non-certificate b= ased authentication mechanisms (e.g. TLS-SRP extension for password authent= icated key exchange, PSK for pre-shared key authentication) and even non-X.= 509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d prefer that the= draft explicitly referred to =E2=80=9CX.509 Client Certificate Authenticat= ion=E2=80=9D rather than mutual TLS, and changed identifiers like =E2=80=98= tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-= mtls-07#section-2.1.1) to something more explicit like =E2=80=98tls_x50= 9_pki_client_auth=E2=80=99.

This is especially confusing in section= 3 on sender constrained access tokens, as there are two different servers = involved: the AS and the protected resource server, but there is no =E2=80= =9Cmutual=E2=80=9D authentication between them, only between each of them a= nd the client.

3. The draft links to the TLS 1.2 RFC, while the ori= ginal OAuth 2.0 RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ = is required? The wording in Section 5.1 doesn=E2=80=99t seem clear if this = could also be used with TLS 1.0 or 1.1, or whether it is only referring to = future TLS versions.

4. It might be useful to have a discussion for= implementors of whether TLS session resumption (and PSK in TLS 1.3) and/or= renegotiation impact the use of client certificates, if at all?

5.= Section 3 defines sender-constrained access tokens in terms of the confirm= ation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 Pop Archi= tecture draft defines sender constraint and key confirmation as different t= hings (https://tools.ietf.org/html/draft-ietf-oauth-pop-archi= tecture-08#section-6.2). The draft should decide which of those it is i= mplementing and if sender constraint is intended, then reusing the confirma= tion key claims seems misleading. (I think this mTLS draft is doing key con= firmation so should drop the language about sender constrained tokens).
6. The OAuth 2.0 PoP Architecture draft says (https://tool= s.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-5):
Strong, fresh session keys:

Session keys MUST be strong and fresh= . Each session deserves an
independent session key, i.e., one that is g= enerated specifically
for the intended use. In context of OAuth this me= ans that keying
material is created in such a way that can only be used= by the
combination of a client instance, protected resource, and
a= uthorization scope.


However, the mTLS draft section 3 (https:/= /tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3) says:

= The client makes protected resource requests as described in
[RFC6750],= however, those requests MUST be made over a mutually
authenticated TLS= connection using the same certificate that was used
for mutual TLS at = the token endpoint.

These two statements are contradictory: the OAu= th 2.0 PoP architecture effectively requires a fresh key-pair to be used fo= r every access token request, whereas this draft proposes reusing the same = long-lived client certificate for every single access token and every resou= rce server.

In the self-signed case (and even in the CA case, with = a bit of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html)= it is perfectly possible for the client to generate a fresh key-pair for e= ach access token and include the certificate on the token request (e.g., as= per https://tools.ietf.org/html/draft-ietf-oauth-pop-key= -distribution-03#section-5.1 - in which case an appropriate =E2=80=9Cal= g=E2=80=9D value should probably be described). This should probably at lea= st be an option.

7. The use of a single client certificate with eve= ry resource server (RS) should be called out in a Privacy Considerations se= ction, as it allows correlation of activity.

8. This is maybe a mor= e general point, but RFC 6750 defines the Authorization: Bearer scheme (https://tools.ietf.o= rg/html/rfc6750#section-2) for a client to communicate it=E2=80=99s acc= ess token to the RS in a standard way. As sender-constrained access tokens = are not strictly bearer tokens any more, should this draft also register a = new scheme for that? Should there be a generic PoP scheme?

9. The S= ecurity Considerations should really make some mention of the long history = of attacks against X.509 certificate chain validation, e.g. failure to chec= k the =E2=80=9CCA=E2=80=9D bit in the basic constraints, errors in parsing = DNs, etc. It should be strongly suggested to use an existing TLS library to= perform these checks rather than implementing your own checks. This relate= s to Justin=E2=80=99s comments around DN parsing and normalisation.
10. The PKI client authentication method (https://tools.ietf.org/html/dr= aft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of certific= ate revocation and how to handle checking for that (CRLs, OCSP - with stapl= ing?). Neither does the Security Considerations. If this is a detail to be = agreed between then AS and the CA (or just left up to the AS TLS stack) the= n that should perhaps be made explicit. Again, there are privacy considerat= ions with some of these mechanisms, as OCSP requests are typically sent in = the clear (plain HTTP) and so allow an observer to see which clients are co= nnecting to which AS.

11. The same comment applies to how the prote= cted resource checks for revocation of the certificate presented during sen= der constrained access token usage. Should the RS make its own revocation c= hecks based on the information in the certificate presented, or should it t= rust the certificate while the access token is still valid? If the latter c= ase, is the AS responsible for revoking any access tokens whose certificate= have been revoked (if so, should it be doing an OCSP call on every token i= ntrospection request, and should the RS be passing on the certificate/seria= l number on that request)? If the Client request uses OCSP Stapling (https://en.wikipedia.org/= wiki/OCSP_stapling) how can the RS verify the signature on that if it d= oes not have a separate trust relationship with the CA already?

12.= The use of only SHA-256 fingerprints means that the security strength of t= he sender-constrained access tokens is limited by the collision resistance = of SHA-256 - roughly =E2=80=9C128-bit security" - without a new specif= ication for a new thumbprint algorithm. An implication of this is that is i= s fairly pointless for the protected resource TLS stack to ever negotiate c= ipher suites/keys with a higher level of security. In more crystal ball ter= ritory, if a practical quantum computer becomes a possibility within the li= fetime of this spec, then the expected collision resistance of SHA-256 woul= d drop quadratically, allowing an attacker to find a colliding certificate = in ~2^64 effort. If we are going to pick just one thumbprint hash algorithm= , I would prefer we pick SHA-512.

Cheers,

Neil


=

On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <= rifaat.ietf@gmail.com> wrot= e:

All,

As discussed during the meeting today, we are start= ing a WGLC on the MTLS document:
https://tools.ietf.org/html/draft-ietf-oauth-mtl= s-07

Please, review the document and provide feedback on any is= sues you see with the document.

The WGLC will end in two weeks, on = April 2, 2018.

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 =

 

<= /div>

=  

--__1522433009517188891abhmp0013.oracle.com-- From nobody Fri Mar 30 11:48:14 2018 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 534EF1273B1 for ; Fri, 30 Mar 2018 11:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 xkHBg7uWA0mp for ; Fri, 30 Mar 2018 11:48:07 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B241A12711E for ; Fri, 30 Mar 2018 11:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1522435684; x=1553971684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N5vEIV5zY5haEUjhanWQXkAL2jBEBvTXrIznSrhopKo=; b=Un1ZBuH063+H7HyTRGhF5mciHYYmGik9ziTBcZ1P7Es74f+XHP6NdzBk Ur0d39xh/F5iEKCSqdn227mrwKts67sPJGVEkpzKYcjQMtIudspH6khQ5 gki9Zt9RHs6WhjWDddPVMQGh2Jrr7vHRK6ZrFIFuuCURJuqvUHhgKimau k=; X-IronPort-AV: E=Sophos;i="5.48,382,1517875200"; d="scan'208";a="603968690" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2018 18:48:02 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2UIluIb049477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2018 18:48:00 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 30 Mar 2018 18:47:59 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 30 Mar 2018 18:47:59 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 30 Mar 2018 18:47:59 +0000 From: "Richard Backman, Annabelle" To: Bill Burke CC: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Thread-Topic: [OAUTH-WG] What Does Logout Mean? Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvgA7mmyA//+yZICAAI4MgP//m6SAgACNGQCAAmHFgIAAgaKA//+dPwA= Date: Fri, 30 Mar 2018 18:47:59 +0000 Message-ID: <2D841B39-7A79-42C0-AB3C-E6C473CC6977@amazon.com> References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.20] Content-Type: text/plain; charset="utf-8" Content-ID: <1B92B40F6621D94EB9A14AEBC9F8C71F@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 30 Mar 2018 18:48:09 -0000 SXQgc291bmRzIGxpa2UgeW91J3JlIGFza2luZyB0aGUgT1AgdG8gcHJvdmlkZSBjbGllbnQtc2lk ZSBzZXNzaW9uIG1hbmFnZW1lbnQgYXMgYSBzZXJ2aWNlLiBUaGVyZSBtYXkgYmUgdmFsdWUgaW4g c3RhbmRhcmRpemluZyB0aGF0LCBidXQgSSB0aGluayBpdCBnb2VzIGJleW9uZCB3aGF0IEJhY2tj aGFubmVsIExvZ291dCBpcyBpbnRlbmRlZCB0byBkby4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCiANCu+7v09uIDMvMzAvMTgs IDEwOjQyIEFNLCAiQmlsbCBCdXJrZSIgPGJidXJrZUByZWRoYXQuY29tPiB3cm90ZToNCg0KICAg IE9uIEZyaSwgTWFyIDMwLCAyMDE4IGF0IDEyOjU3IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZQ0KICAgIDxyaWNoYW5uYUBhbWF6b24uY29tPiB3cm90ZToNCiAgICA+DQogICAgPiBGV0lX LCBvdXIgT1AgaW1wbGVtZW50YXRpb24gYWxsb3dzIFJQcyB0byByZWdpc3RlciB0aGVpciBub2Rl IHNwZWNpZmljDQogICAgPiBsb2dvdXQgZW5kcG9pbnRzIGF0IGJvb3QuICBUaGlzIHJlcXVlc3Qg aXMgYXV0aGVudGljYXRlZCB2aWEgY2xpZW50DQogICAgPiBhdXRoZW50aWNhdGlvbi4gIFdlIGFs c28gZXh0ZW5kZWQgY29kZSB0byB0b2tlbiByZXF1ZXN0IHRvIHRyYW5zbWl0IHRoZQ0KICAgID4g bG9jYWwgc2Vzc2lvbiBpZC4gIFRoZSBPUCBzdG9yZXMgdGhpcyBpbmZvcm1hdGlvbi4gIEJhY2tj aGFubmVsIGxvZ291dCBQT1NUUw0KICAgID4gdG8gZWFjaCBhbmQgZXZlcnkgcmVnaXN0ZXJlZCBu b2RlIGFuZCB0cmFuc21pdHMgYSBKV1Mgc2lnbmVkIGJ5IHRoZSBPUA0KICAgID4gY29udGFpbmlu ZyB0aGUgbG9jYWwgc2Vzc2lvbiBpZHMgdG8gaW52YWxpZGF0ZS4gIFRoYXQncyBiZWVuIGVub3Vn aCB0byBjb3Zlcg0KICAgID4gYWxsIHRoZSB3ZWlyZG5lc3Mgb3V0IHRoZXJlIHNvIGZhci4NCiAg ICA+DQogICAgPiBbcmljaGFubmFdDQogICAgPg0KICAgID4gV2hhdCBkb2VzIOKAnGF0IGJvb3Ti gJ0gbWVhbiBpbiB0aGUgY29udGV4dCBvZiBPcGVuSUQgQ29ubmVjdD8gRG8geW91IG1lYW4gdGhh dA0KICAgID4gZm9yIGV2ZXJ5IGxvZ291dCwgdGhlIE9QIG1ha2VzIGEgQmFja2NoYW5uZWwgTG9n b3V0IHJlcXVlc3QgdG8gZWFjaCBvZiB0aGUNCiAgICA+IGNsaWVudOKAmXMgbm9kZS1zcGVjaWZp YyBsb2dvdXQgZW5kcG9pbnRzPw0KICAgIA0KICAgIEp1c3QgaW4gY2FzZS4uLi5UaGlzIGlzIGFs bCBmb3IgYmFja2NoYW5uZWwgbG9nb3V0cyB3aGljaCBhcmUgb3V0IG9mDQogICAgYmFuZCBmcm9t IHRoZSBicm93c2VyLg0KICAgIA0KICAgIE5vZGUgYm9vdHMgdXAgYW5kIHJlZ2lzdGVycyB3aXRo IHRoZSBBdXRoIFNlcnZlciBpdHMgbG9nb3V0IGVuZHBvaW50Lg0KICAgIA0KICAgIFBPU1QgL2F1 dGhzZXJ2ZXIvbm9kZV9yZWdpc3RyYXRpb24NCiAgICANCiAgICBjbGllbnRfaWQ9bXljbGllbnQm DQogICAgY2xpZW50X3NlY3JldD1nZWhlaW0mDQogICAgbm9kZT1odHRwczovL25vZGUuaW50ZXJu YWw6ODQ0My9hcHAvb2lkYy9fbG9nb3V0DQogICAgDQogICAgIEFzIEkgbWVudGlvbmVkIGVhcmxp ZXIsIHRoZSBub2RlIGRvaW5nIGNvZGUgdG8gdG9rZW4gcmVxdWVzdCB3aWxsDQogICAgYWxzbyBw YXNzIGl0cyBsb2NhbCBzZXNzaW9uIGlkIHNvIGl0IGNhbiBiZSBhc3NvY2lhdGVkIHdpdGggdGhl IEF1dGgNCiAgICBzZXJ2ZXIncyBTSUQuICBXaGVuIGFuIGFkbWluIGluaXRpYXRlcyBhIGZvcmNl ZCBsb2dvdXQsIGEgYmFja2NoYW5uZWwNCiAgICBsb2dvdXQgcmVxdWVzdCBpcyBzZW50IHRvIGVh Y2ggY2xpZW50J3MgbG9nb3V0IGVuZHBvaW50LiAgSWYgdGhlDQogICAgY2xpZW50IGhhcyBub2Rl cyB0aGF0IGhhdmUgcmVnaXN0ZXJlZCwgdGhpcyByZXF1ZXN0IGlzIGR1cGxpY2F0ZWQgdG8NCiAg ICBlYWNoIG5vZGUuDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgPiBJZiB0aGF0 4oCZcyB0aGUgY2FzZSwgd2h5IGNhbuKAmXQgdGhlDQogICAgPiBjbGllbnQgbWFrZSB0aG9zZSBj YWxscyB0aGVtc2VsdmVzLCBmcm9tIHdoaWNoZXZlciBob3N0IGhhcHBlbnMgdG8gcmVjZWl2ZQ0K ICAgID4gdGhlIEJhY2tjaGFubmVsIExvZ291dCByZXF1ZXN0Pw0KICAgID4NCiAgICANCiAgICBZ b3VyIGFzc3VtaW5nIHRoYXQgZWFjaCBub2RlIGhhcyBrbm93bGVkZ2Ugb2YgY2x1c3RlciB0b3Bv bG9neSB3aGljaA0KICAgIGlzbid0IG5lY2Nlc2FyaWx5IHRydWUuICBFYWNoIGFkZGl0aW9uYWwg cHJvcHJpZXRhcnkgZXh0ZW5zaW9uIHdlJ3ZlDQogICAgbWFkZSBpcyBvcHRpb25hbC4gIE5vZGVz IGNhbiBvcHRpb25hbGx5IHJlZ2lzdGVyIHRoZW1zZWx2ZXMuICBOb2Rlcw0KICAgIGNhbiBvcHRp b25hbGx5IHNlbmQgbG9jYWwgc2Vzc2lvbiBpZHMgd2l0aCB0aGUgY29kZSB0byB0b2tlbiByZXF1 ZXN0Lg0KICAgIA0KICAgIA0KICAgID4NCiAgICA+DQogICAgPiBTaW5jZSB0aGUgY2xpZW50IG9u bHkgY2FyZXMgYWJvdXQgbm9kZS1sb2NhbCBzdGF0ZSwgdGhleSBzaG91bGQgYmUgYWJsZSB0bw0K ICAgID4gbWFpbnRhaW4gdGhlIG1hcHBpbmcgYmV0d2VlbiBPUCBzZXNzaW9uIElEcyBhbmQgbG9j YWwgc2Vzc2lvbiBJRHMgb24gdGhlaXINCiAgICA+IHNpZGUuDQogICAgPg0KICAgIA0KICAgIENv bnNpZGVyaW5nIGEgY2x1c3RlciBvZiBsb2FkIGJhbGFuY2VkIHdlYiBhcHBsaWNhdGlvbnMgdGhh dCBkb250Jw0KICAgIGhhdmUgc2Vzc2lvbiByZXBsaWNhdGlvbiBhbmQgZG9uJ3QgaGF2ZSBrbm93 bGVkZ2Ugb2YgY2x1c3RlciB0b3BvbG9neS4NCiAgICBUaGUgb25seSB3YXkgZm9yIHRoZSBBdXRo IFNlcnZlciB0byBwZXJmb3JtIGJhY2tjaGFubmVsIGxvZ291dCBpcyB0bw0KICAgIHNlbmQgdGhl IHNhbWUgYmFja2NoYW5uZWwgbG9nb3V0IHRvIGVhY2ggYW5kIGV2ZXJ5IG5vZGUuDQogICAgDQog ICAgVGhlcmUncyBhbHNvIHRoZSBjYXNlIHdoZXJlIHRoZSBub2RlcyBkbyBzdXBwb3J0IHNlc3Np b24gcmVwbGljYXRpb24sDQogICAgYnV0IGRvbid0IGhhdmUgYSB3YXkgdG8gZ2V0IGF0IHRvcG9s b2d5IG9yIGEgd2F5IHRvIHN0b3JlIHRoZQ0KICAgIGFzc29jaWF0aW9uIGJldHdlZW4gdGhlIFNJ RCBhbmQgYXBwbGljYXRpb24gc2Vzc2lvbiBpZC4gIEluIHRoaXMgY2FzZQ0KICAgIHlvdSBkb24n dCBuZWVkIG5vZGUgcmVnaXN0cmF0aW9uLCBidXQgeW91IGRvIG5lZWQgYSB3YXkgdG8gYXNzb2Np YXRlDQogICAgdGhlIFNJRCB3aXRoIHRoZSBsb2NhbCBzZXNzaW9uIGlkLg0KICAgIA0KICAgIEFz IGEgSURQIHZlbmRvciwgeW91IGhhdmUgdG8gc3VwcG9ydCBhbGwgdGhlc2UgdHlwZXMgb2YgY2xp ZW50cy4NCiAgICBUZWxsaW5nIGRldmVsb3BlcnMgdGhhdCB0aGV5IGFyZSBqdXN0IGdvaW5nIHRv IGhhdmUgdG8gbWFuYWdlIHRoaXMNCiAgICB0aGVtc2VsdmVzIGlzIG5vdCByZWFsbHkgYW4gb3B0 aW9uIGlmIHlvdSB3YW50IGFkb3B0aW9uLg0KICAgIA0KICAgIEJpbGwNCiAgICANCg0K From nobody Fri Mar 30 12:02:53 2018 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 5F9B51243F6 for ; Fri, 30 Mar 2018 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 BhXnzGY08cq9 for ; Fri, 30 Mar 2018 12:02:47 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9AF2C1200C5 for ; Fri, 30 Mar 2018 12:02:46 -0700 (PDT) X-AuditID: 1209190d-04bff70000003f3f-95-5abe89d49762 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id CA.1F.16191.4D98EBA5; Fri, 30 Mar 2018 15:02:45 -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 w2UJ2hlA027648; Fri, 30 Mar 2018 15:02:44 -0400 Received: from [192.168.1.12] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2UJ2eSK003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2018 15:02:42 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2F1DB161-0AA8-4155-A6AE-347A581842D2" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 30 Mar 2018 15:02:39 -0400 In-Reply-To: Cc: John Bradley , Neil Madden , "" To: Vivek Biswas References: <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixCmqrHu1c1+UQf83Los5836xWZx8+4rN YvXdv2wW8/r2MjmweNxoW8DosWTJTyaPj09vsXjcvr2RJYAlissmJTUnsyy1SN8ugSvjUMt3 loKJU5grDr74y9zA2HqfqYuRk0NCwESi8+tsti5GLg4hgcVMEocfvmWBcDYySkxt+MYM4Vxn kni5/yYzSAubgKrE9DUtYO28AlYSU/61MoLYzAJJEkf3/GKHiJtIvH/7EKxGWMBC4tSjH2A2 C1DvqjfHweo5Bawltpz5zgbRWy3xdN0MsF4RAS2JfSfa2SEWX2CSaFx2nRHiViWJ6d9vs01g 5J+FZN8sJPsg4toSyxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkbZlNwq3dzEzJzi1GTd4uTE vLzUIl0jvdzMEr3UlNJNjOBIkOTdwfjvrtchRgEORiUeXob4fVFCrIllxZW5hxglOZiURHnz 2oBCfEn5KZUZicUZ8UWlOanFhxglOJiVRHitTu6NEuJNSaysSi3Kh0lJc7AoifMu2g+UEkhP LEnNTk0tSC2CycpwcChJ8IZ2AA0VLEpNT61Iy8wpQUgzcXCCDOcBGu4PUsNbXJCYW5yZDpE/ xWjJMW1ZTw8zx6H3U4DkORApxJKXn5cqJc7rBdIgANKQUZoHNxOU2NzX2Vm8YhQHelGYdyNI FQ8wKcJNfQW0kAlooUjNHpCFJYkIKakGxkpGjcIv2hXC5nXr/wYd93BrrLs7XfWc1XR7az+/ xU2qffdcbk1Zu9pVJVPrXseLu2u9Q1Le8q6JmiAlc2MGz7noNfvffjv/cKLPsy2r3rJXMSyu 1XR4b/6o66DTUSHjy3E8m23lP5zq33N1/kGeOYWzmyr93x/JrXTm3Sv4TOhv+JrJSZ8fPVVi Kc5INNRiLipOBACJBRZERwMAAA== Archived-At: Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 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, 30 Mar 2018 19:02:51 -0000 --Apple-Mail=_2F1DB161-0AA8-4155-A6AE-347A581842D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t believe this is the spec to define TLS header forwarding = standards in. =E2=80=94 Justin > On Mar 30, 2018, at 2:03 PM, Vivek Biswas = wrote: >=20 > There are additional challenges which we have faced. > =20 > A. Most of the Mutual SSL communication as mentioned below = terminates at the LBR and the LBR needs to have client certificates to = trust the client. But lot of times the connection from LBR to = Authorization server may be non-SSL. > =20 > The CN, SHA-256 thumprint and serial number of the Client Cert are = sent as header to the AuthzServer/Backend Server. However, if the = connection from LBR to AuthzServer/Backend Server is unencrypted it is = prone to MIM attacks. Hence, it=E2=80=99s a MUST requirement to have = one-way SSL from LBR to AuthzServer/Backend Server, so that the headers = passed are not compromised. > =20 > This is a MOST common scenario in a real world. And we don=E2=80=99t = want everyone come up with their own names for the header. There should = be some kind of standardization around the header names. > =20 > Regards > Vivek Biswas, CISSP > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, March 29, 2018 11:57 AM > To: Neil Madden > Cc: oauth > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 > =20 > Yes that is quite a common deployment scenario. I think that is the = way most of the Open Banking implementations have deployed it currently. = =20 > =20 > The intent is to support that. One problem is that how the = certificate is transmitted to the application tends to be load = balancer/reverse proxy specific as no real standard exists. > =20 > If you think that needs to be clarified text is welcome. > =20 > John B. > =20 > =20 >=20 >=20 > On Mar 29, 2018, at 2:54 PM, Neil Madden > wrote: > =20 > Thanks, and understood.=20 > =20 > The privacy concerns are mostly around correlating activity of = *clients*, which may or may not reveal activity patterns of users using = those clients. I don=E2=80=99t know how much of a concern that is in = reality, but thought it should be mentioned.=20 > =20 > A colleague also made the following comment about the draft: > =20 > =E2=80=9CIt is still quite common to terminate TLS in a load balancer = or proxy, and to deploy authorization servers in a secure network zone = behind an intermediate in a DMZ. In these cases, TLS would not be = established between the client and authorization server as per =C2=A72, = but information about the TLS handshake may be made available by other = means (typically adding to a downstream header) allowing lookup and = verification of the client certificate as otherwise described. Given the = prevalence of this approach it would be good to know whether such a = deployment would be compliant or not.=E2=80=9D > =20 > Kind regards, > Neil > -- > =20 > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley > wrote: > Thanks for the feedback. We will review your comments and reply.=20 >=20 > One data point is that this will not be the only POP spec. The spec = using token binding vs mtls has better privacy properties. It is UK Open = banking that has pressed us to come up with a standard to help with = interoperability.=20 >=20 > This spec has been simplified in some ways to facilitate the majority = of likely deployments.=20 >=20 > I understand that in future certificates may have better than SHA256 = hashes.=20 >=20 > Regards=20 > John B.=20 >=20 >=20 >=20 > On Mar 29, 2018, at 12:18 PM, Neil Madden > wrote:=20 >=20 > Hi,=20 >=20 > I have reviewed this draft and have a number of comments, below. = ForgeRock have not yet implemented this draft, but there is interest in = implementing it at some point. (Disclaimer: We have no firm commitments = on this at the moment, I do not speak for ForgeRock, etc).=20 >=20 > 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 = = defines a new confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, = there is already a confirmation method =E2=80=9Cjwk=E2=80=9D that can = contain a JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80= =9D claim with exactly the same syntax and semantics. The draft = proposes:=20 >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6= =E2=80=9D } }=20 >=20 > but you can already do:=20 >=20 > { =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 , = =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } }=20 >=20 > If the intent is just to save some space and avoid the mandatory = fields of the existing JWK types, maybe this would be better addressed = by defining a new JWK type which only has a thumbprint? e.g., { = =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D: = =E2=80=9C=E2=80=A6=E2=80=9D }.=20 >=20 > 2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and =E2=80=9CmTLS=E2=80= =9D a bit of a misnomer: it=E2=80=99s really only the client = authentication that we are interested here, and the fact that the server = also authenticates with a certificate is not hugely relevant to this = particular spec (although it is to the overall security of OAuth). Also, = TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types = (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-3 = ). I=E2=80=99d prefer that = the draft explicitly referred to =E2=80=9CX.509 Client Certificate = Authentication=E2=80=9D rather than mutual TLS, and changed identifiers = like =E2=80=98tls_client_auth=E2=80=99 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1.1 = ) to = something more explicit like =E2=80=98tls_x509_pki_client_auth=E2=80=99.=20= >=20 > This is especially confusing in section 3 on sender constrained access = tokens, as there are two different servers involved: the AS and the = protected resource server, but there is no =E2=80=9Cmutual=E2=80=9D = authentication between them, only between each of them and the client.=20= >=20 > 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 = RFC only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? = The wording in Section 5.1 doesn=E2=80=99t seem clear if this could also = be used with TLS 1.0 or 1.1, or whether it is only referring to future = TLS versions.=20 >=20 > 4. It might be useful to have a discussion for implementors of whether = TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact = the use of client certificates, if at all?=20 >=20 > 5. Section 3 defines sender-constrained access tokens in terms of the = confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0 = Pop Architecture draft defines sender constraint and key confirmation as = different things = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 6.2 = ). The draft should decide which of those it is implementing and if = sender constraint is intended, then reusing the confirmation key claims = seems misleading. (I think this mTLS draft is doing key confirmation so = should drop the language about sender constrained tokens).=20 >=20 > 6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-= 5 = ):=20 >=20 > Strong, fresh session keys:=20 >=20 > Session keys MUST be strong and fresh.. Each session deserves an=20 > independent session key, i.e., one that is generated specifically=20 > for the intended use. In context of OAuth this means that keying=20 > material is created in such a way that can only be used by the=20 > combination of a client instance, protected resource, and=20 > authorization scope.=20 >=20 >=20 > However, the mTLS draft section 3 = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3 = ) says:=20= >=20 > The client makes protected resource requests as described in=20 > [RFC6750], however, those requests MUST be made over a mutually=20 > authenticated TLS connection using the same certificate that was used=20= > for mutual TLS at the token endpoint.=20 >=20 > These two statements are contradictory: the OAuth 2.0 PoP architecture = effectively requires a fresh key-pair to be used for every access token = request, whereas this draft proposes reusing the same long-lived client = certificate for every single access token and every resource server.=20 >=20 > In the self-signed case (and even in the CA case, with a bit of work - = e.g., https://www.vaultproject.io/docs/secrets/pki/index.html = ) it is = perfectly possible for the client to generate a fresh key-pair for each = access token and include the certificate on the token request (e.g., as = per = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03#secti= on-5.1 = - in which case an appropriate =E2=80=9Calg=E2=80=9D value = should probably be described). This should probably at least be an = option.=20 >=20 > 7. The use of a single client certificate with every resource server = (RS) should be called out in a Privacy Considerations section, as it = allows correlation of activity.=20 >=20 > 8. This is maybe a more general point, but RFC 6750 defines the = Authorization: Bearer scheme = (https://tools.ietf.org/html/rfc6750#section-2 = ) for a client to = communicate it=E2=80=99s access token to the RS in a standard way. As = sender-constrained access tokens are not strictly bearer tokens any = more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme?=20 >=20 > 9. The Security Considerations should really make some mention of the = long history of attacks against X.509 certificate chain validation, e.g. = failure to check the =E2=80=9CCA=E2=80=9D bit in the basic constraints, = errors in parsing DNs, etc. It should be strongly suggested to use an = existing TLS library to perform these checks rather than implementing = your own checks. This relates to Justin=E2=80=99s comments around DN = parsing and normalisation.=20 >=20 > 10. The PKI client authentication method = (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 = ) = makes no mention at all of certificate revocation and how to handle = checking for that (CRLs, OCSP - with stapling?). Neither does the = Security Considerations. If this is a detail to be agreed between then = AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with = some of these mechanisms, as OCSP requests are typically sent in the = clear (plain HTTP) and so allow an observer to see which clients are = connecting to which AS.=20 >=20 > 11. The same comment applies to how the protected resource checks for = revocation of the certificate presented during sender constrained access = token usage. Should the RS make its own revocation checks based on the = information in the certificate presented, or should it trust the = certificate while the access token is still valid? If the latter case, = is the AS responsible for revoking any access tokens whose certificate = have been revoked (if so, should it be doing an OCSP call on every token = introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling = ) how can the RS verify the = signature on that if it does not have a separate trust relationship with = the CA already?=20 >=20 > 12. The use of only SHA-256 fingerprints means that the security = strength of the sender-constrained access tokens is limited by the = collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" - = without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512.=20 >=20 > Cheers,=20 >=20 > Neil=20 >=20 >=20 >=20 > On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef > wrote:=20 >=20 > All,=20 >=20 > As discussed during the meeting today, we are starting a WGLC on the = MTLS document:=20 > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 = =20 >=20 > Please, review the document and provide feedback on any issues you see = with the document.=20 >=20 > The WGLC will end in two weeks, on April 2, 2018.=20 >=20 > Regards,=20 > Rifaat and Hannes=20 >=20 > _______________________________________________=20 > OAuth mailing list=20 > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________=20 > OAuth mailing list=20 > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth = > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2F1DB161-0AA8-4155-A6AE-347A581842D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t believe this is the spec to define TLS header forwarding = standards in.

 =E2=80=94 Justin

On Mar = 30, 2018, at 2:03 PM, Vivek Biswas <vivek.biswas@oracle.com> wrote:

There are additional challenges which we have faced.
 
A.      Most of the Mutual SSL communication as = mentioned below terminates at the LBR and the LBR needs to have client = certificates to trust the client. But lot of times the connection from = LBR to Authorization server may be non-SSL.
 
The= CN, SHA-256 thumprint and serial number of the Client Cert are sent as = header to the AuthzServer/Backend Server. However, if the connection = from LBR to AuthzServer/Backend Server is unencrypted it is prone to MIM = attacks. Hence, it=E2=80=99s a MUST requirement to have one-way SSL from = LBR to AuthzServer/Backend Server, so that the headers passed are not = compromised.
 
This is a MOST common scenario in a real world. And we = don=E2=80=99t want everyone come up with their own names for the header. = There should be some kind of standardization around the header = names.
 
Regards
Vivek Biswas, CISSP
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, March 29, 2018 = 11:57 AM
To: Neil Madden
Cc: oauth
Subject: Re: [OAUTH-WG] WGLC on = draft-ietf-oauth-mtls-07
 
Yes that is quite a common deployment = scenario.   I think that is the way most of the Open Banking = implementations have deployed it currently.   
 
The intent = is to support that.   One problem is that how the certificate is = transmitted to the application tends to be load balancer/reverse proxy = specific as no real standard exists.
 
If you think that needs to be clarified = text is welcome.
 
John B.
 
 


On Mar 29, 2018, at 2:54 PM, Neil Madden = <neil.madden@forgerock.com> = wrote:
 
Thanks, and = understood. 
 
The privacy concerns are mostly around correlating activity = of *clients*, which may or may not reveal activity patterns of users = using those clients. I don=E2=80=99t know how much of a concern that is = in reality, but thought it should be mentioned. 
 
A colleague also = made the following comment about the draft:
 
=E2=80=9CIt is still quite common to terminate TLS in a load balancer = or proxy, and to deploy authorization servers in a secure network zone = behind an intermediate in a DMZ. In these cases, TLS would not be = established between the client and authorization server as per =C2=A72, = but information about the TLS handshake may be made available by other = means (typically adding to a downstream header) allowing lookup and = verification of the client certificate as otherwise described. Given the = prevalence of this approach it would be good to know whether such a = deployment would be compliant or not.=E2=80=9D
 
Kind = regards,
Neil
--
 
On Thursday, Mar 29, 2018 at 4:47 pm, = John Bradley <ve7jtb@ve7jtb.com> = wrote:
Thanks for the = feedback. We will review your comments and reply. 

One data point is that this will not be the only POP spec. = The spec using token binding vs mtls has better privacy properties. It = is UK Open banking that has pressed us to come up with a standard to = help with interoperability. 

This spec has been simplified in some ways to facilitate the = majority of likely deployments. 

I understand that in future certificates may have better than = SHA256 hashes. 

Regards 
John B. 



On Mar 29, 2018, at 12:18 PM, Neil Madden <neil.madden@forgerock.com> = wrote: 

Hi, 

I have reviewed this draft and have a number of comments, = below. ForgeRock have not yet implemented this draft, but there is = interest in implementing it at some point. (Disclaimer: We have no firm = commitments on this at the moment, I do not speak for ForgeRock, = etc). 
1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.= 1 defines a new = confirmation method =E2=80=9Cx5t#S256=E2=80=9D. However, there is = already a confirmation method =E2=80=9Cjwk=E2=80=9D that can contain a = JSON Web Key, which itself can contain a =E2=80=9Cx5t#S526=E2=80=9D = claim with exactly the same syntax and semantics. The draft = proposes: 

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cx5t#S256=E2=80= =9D: =E2=80=9C=E2=80=A6=E2=80=9D } } 

but you can already do: 

{ =E2=80=9Ccnf=E2=80=9D: { =E2=80=9Cjwk=E2=80=9D: { =E2=80=A6 = , =E2=80=9Cx5t#S256=E2=80=9D: =E2=80=9C=E2=80=A6=E2=80=9D } } } 

If the intent is just to save some space and avoid the = mandatory fields of the existing JWK types, maybe this would be better = addressed by defining a new JWK type which only has a thumbprint? e.g., = { =E2=80=9Ckty=E2=80=9D: =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cx5t#S256=E2=80=9D= : =E2=80=9C=E2=80=A6=E2=80=9D }. 

2. I find the naming =E2=80=9Cmutual TLS=E2=80=9D and = =E2=80=9CmTLS=E2=80=9D a bit of a misnomer: it=E2=80=99s really only the = client authentication that we are interested here, and the fact that the = server also authenticates with a certificate is not hugely relevant to = this particular spec (although it is to the overall security of OAuth). = Also, TLS defines non-certificate based authentication mechanisms (e.g. = TLS-SRP extension for password authenticated key exchange, PSK for = pre-shared key authentication) and even non-X.509 certificate types (https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml#tls-extensiontype-values-3). I=E2=80=99d = prefer that the draft explicitly referred to =E2=80=9CX.509 Client = Certificate Authentication=E2=80=9D rather than mutual TLS, and changed = identifiers like =E2=80=98tls_client_auth=E2=80=99 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.= 1.1) to something more explicit like = =E2=80=98tls_x509_pki_client_auth=E2=80=99. 

This is especially confusing in section 3 on sender = constrained access tokens, as there are two different servers involved: = the AS and the protected resource server, but there is no =E2=80=9Cmutual=E2= =80=9D authentication between them, only between each of them and the = client. 

3. The draft links to the TLS 1.2 RFC, while = the original OAuth 2.0 RFC only specifies TLS 1.0. Is the intention that = TLS 1.2+ is required? The wording in Section 5.1 doesn=E2=80=99t seem = clear if this could also be used with TLS 1.0 or 1.1, or whether it is = only referring to future TLS versions. 

4. It might be useful to have a discussion for implementors = of whether TLS session resumption (and PSK in TLS 1.3) and/or = renegotiation impact the use of client certificates, if at all? 

5. Section 3 defines sender-constrained access tokens in = terms of the confirmation key claims (e.g., RFC 7800 for JWT). However, = the OAuth 2.0 Pop Architecture draft defines sender constraint and key = confirmation as different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 8#section-6.2). The draft should decide which of those it is = implementing and if sender constraint is intended, then reusing the = confirmation key claims seems misleading. (I think this mTLS draft is = doing key confirmation so should drop the language about sender = constrained tokens). 
6. The OAuth 2.0 PoP Architecture draft says = (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-0= 8#section-5): 

Strong, fresh session keys: 

Session keys MUST be strong and fresh.. Each session deserves = an 
independent session key, i.e., one that is generated = specifically 
for the intended use. In context of OAuth this means that = keying 
material is created in such a way that can only be used by = the 
combination of a client instance, protected resource, = and 
authorization scope. 


However, the mTLS draft section 3 (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3<= /a>) says: 

The client makes protected resource requests = as described in 
[RFC6750], however, those requests MUST be made over a = mutually 
authenticated TLS connection using the same certificate that = was used 
for mutual TLS at the token endpoint. 

These two statements are contradictory: the OAuth 2.0 PoP = architecture effectively requires a fresh key-pair to be used for every = access token request, whereas this draft proposes reusing the same = long-lived client certificate for every single access token and every = resource server. 

In the self-signed case (and even in the CA = case, with a bit of work - e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) = it is perfectly possible for the client to generate a fresh key-pair for = each access token and include the certificate on the token request = (e.g., as per https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-03#section-5.1 - = in which case an appropriate =E2=80=9Calg=E2=80=9D value should probably = be described). This should probably at least be an option. 

7. The use of a single client certificate with every resource = server (RS) should be called out in a Privacy Considerations section, as = it allows correlation of activity. 

8. This is maybe a more general point, but RFC 6750 defines = the Authorization: Bearer scheme (https://tools.ietf.org/html/rfc6750#section-2) for a = client to communicate it=E2=80=99s access token to the RS in a standard = way. As sender-constrained access tokens are not strictly bearer tokens = any more, should this draft also register a new scheme for that? Should = there be a generic PoP scheme? 

9. The Security Considerations should really make some = mention of the long history of attacks against X.509 certificate chain = validation, e.g. failure to check the =E2=80=9CCA=E2=80=9D bit in the = basic constraints, errors in parsing DNs, etc. It should be strongly = suggested to use an existing TLS library to perform these checks rather = than implementing your own checks. This relates to Justin=E2=80=99s = comments around DN parsing and normalisation. 

10. The PKI client authentication method (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.= 1) makes no mention at all of certificate revocation and how to = handle checking for that (CRLs, OCSP - with stapling?). Neither does the = Security Considerations. If this is a detail to be agreed between then = AS and the CA (or just left up to the AS TLS stack) then that should = perhaps be made explicit. Again, there are privacy considerations with = some of these mechanisms, as OCSP requests are typically sent in the = clear (plain HTTP) and so allow an observer to see which clients are = connecting to which AS. 

11. The same comment applies to how the protected resource = checks for revocation of the certificate presented during sender = constrained access token usage. Should the RS make its own revocation = checks based on the information in the certificate presented, or should = it trust the certificate while the access token is still valid? If the = latter case, is the AS responsible for revoking any access tokens whose = certificate have been revoked (if so, should it be doing an OCSP call on = every token introspection request, and should the RS be passing on the = certificate/serial number on that request)? If the Client request uses = OCSP Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the = RS verify the signature on that if it does not have a separate trust = relationship with the CA already? 

12. The use of only SHA-256 fingerprints means that the = security strength of the sender-constrained access tokens is limited by = the collision resistance of SHA-256 - roughly =E2=80=9C128-bit security" = - without a new specification for a new thumbprint algorithm. An = implication of this is that is is fairly pointless for the protected = resource TLS stack to ever negotiate cipher suites/keys with a higher = level of security. In more crystal ball territory, if a practical = quantum computer becomes a possibility within the lifetime of this spec, = then the expected collision resistance of SHA-256 would drop = quadratically, allowing an attacker to find a colliding certificate in = ~2^64 effort. If we are going to pick just one thumbprint hash = algorithm, I would prefer we pick SHA-512. 

Cheers, 

Neil 



On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> = wrote: 

All, 

As discussed during the meeting today, we are starting a WGLC = on the MTLS document: 
https://tools.ietf.org/html/draft-ietf-oauth-mtls-07 

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

The WGLC will end in two weeks, on April 2, 2018. 

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
 
<= /blockquote>
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_2F1DB161-0AA8-4155-A6AE-347A581842D2-- From nobody Sat Mar 31 07:15:44 2018 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 0D62512D86A for ; Sat, 31 Mar 2018 07:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4MucqINolHcl for ; Sat, 31 Mar 2018 07:15:41 -0700 (PDT) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 D43DF126E64 for ; Sat, 31 Mar 2018 07:15:40 -0700 (PDT) Received: by mail-ua0-f181.google.com with SMTP id u4so6735431uaf.10 for ; Sat, 31 Mar 2018 07:15:40 -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=c2Zv0oM0SZ/gUDRZX7HbTElKd/ZubTZjgon3FKQejeI=; b=CioCV/zDOxq/ewsGg2KTtTROtSKB9VV1Wh+E9/Uw6x2i/Q4FCQLaxD9RgixwbgMraY 8lLLqeimX693q+/KRd7XKrc5aYwkQkESANWBS7Q7t58H8KnlsXcYynuBiRc/u0EoyGBu 59nPratsKjHsO+yiV5E8rjrkzS5BlZQr4X3Vg9WTMtQSI0X/A9ULrlR9wOreswbr+MOv OuEGsvSBdkbb6RL7G+BTRScgPkQmmLejSRyfVCTz8pBHoNAsTzqdNd/FYnYHrqQmxEXn Gj97N5z3ayBY9GWh6W3zUpp+e5gEsM2bmW8bve5QKgpRxFkTDtORsIWIMKma00E7zcQo c25w== X-Gm-Message-State: ALQs6tAU2Ac6T7/MvVDU5F/VYROm/8NDQYE8aVGWRAZXLN0HUrIOKlO0 3ZLpSKs60V0MN+yJi/8DT9Ld7w4JdJQLNqQVTcplSg== X-Google-Smtp-Source: AIpwx48X0mWaP6dgiF6OAZFY8ofcLq5OCwbDNSOMUVAC9K2qV1oyY5Ahx7Jl3w9a7h0VuHRujm4Jtub2dxoclgYM+EE= X-Received: by 10.176.96.19 with SMTP id j19mr1623015ual.179.1522505739851; Sat, 31 Mar 2018 07:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.13.199 with HTTP; Sat, 31 Mar 2018 07:15:39 -0700 (PDT) In-Reply-To: <2D841B39-7A79-42C0-AB3C-E6C473CC6977@amazon.com> References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> <2D841B39-7A79-42C0-AB3C-E6C473CC6977@amazon.com> From: Bill Burke Date: Sat, 31 Mar 2018 10:15:39 -0400 Message-ID: To: "Richard Backman, Annabelle" Cc: Mike Jones , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 31 Mar 2018 14:15:43 -0000 On Fri, Mar 30, 2018 at 2:47 PM, Richard Backman, Annabelle wrote: > It sounds like you're asking the OP to provide client-side session management as a service. There may be value in standardizing that, but I think it goes beyond what Backchannel Logout is intended to do. Sure, sort of. Though, we would have never implemented these extensions if back channel logout didn't exist as a concept and requirement. Its all in the sometimes ugly business of supporting application developers who have a variety of deployment requirements and restrictions. Bill From nobody Sat Mar 31 17:33:13 2018 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 3A9B512702E for ; Sat, 31 Mar 2018 17:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 CE5QZ3eCfTTd for ; Sat, 31 Mar 2018 17:33:10 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 82A66126DC2 for ; Sat, 31 Mar 2018 17:33:10 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w310Hbg2190254; Sun, 1 Apr 2018 00:33:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=NjKTVhXQ8mK3M1DUtW+QJI8cWFckyQTkC+dUU+ylXfs=; b=iwmYaHFyqTLwQrK9VW62aW5/iNaLUWlI5Gx4AYpMD4osdkrg1Xdb3nhGA4vw8Te1qr4O s+NgZqOC/nUq7tpBJ9CEvWCXIDRvdAE4lCdOdAkw0mhcCPojxk6rVVwnS1lVUR5CF/fX Hou2wUPxJcdihzf+VGjGzDX3uD4PL0DsuHoIWbf1whYK+iSlfoQfvBPtLIDmDeT5gpbu tRCePs9yZGk3hzG2aiest72aqDauFKnCYoLyFLY/C6de7n4V1hQIVFQfS5k/VkhbbHKv 4TOnbT0UxrJQFVhFlJdfoHPzv38jivbipJH3Pc0jI+bRi16tLocfghZVy+iXgfsCti+6 Tg== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2h2mrc00gr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 01 Apr 2018 00:33:05 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w310X3J2018947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 1 Apr 2018 00:33:03 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 w310X1Ci013889; Sun, 1 Apr 2018 00:33:01 GMT Received: from [192.168.0.93] (/68.145.180.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 31 Mar 2018 17:33:01 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Sat, 31 Mar 2018 18:32:58 -0600 Cc: "Richard Backman, Annabelle" , Roberto Carbone , "oauth@ietf.org" , Nat Sakimura Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> <7B1638A7-ADAD-4AE1-8AF8-6E26853D32C7@amazon.com> <2D841B39-7A79-42C0-AB3C-E6C473CC6977@amazon.com> To: Bill Burke X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8849 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=944 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804010000 Archived-At: Subject: Re: [OAUTH-WG] What Does Logout Mean? 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, 01 Apr 2018 00:33:12 -0000 These kinds of discussions are why i think the signal should just be token r= evoked. It is up to the receiver to infer meaning.=20 As soon as we talk in forma like commands(user is to be logged out), a stand= ardized meaning becomes a problem.=20 Receiver decision on action based on an issuer signal is the primary differe= nce between a security event signal (a SET) and a security assertion (a JWT)= or a command.=20 Phil > On Mar 31, 2018, at 8:15 AM, Bill Burke wrote: >=20 > On Fri, Mar 30, 2018 at 2:47 PM, Richard Backman, Annabelle > wrote: >> It sounds like you're asking the OP to provide client-side session manage= ment as a service. There may be value in standardizing that, but I think it g= oes beyond what Backchannel Logout is intended to do. >=20 > Sure, sort of. Though, we would have never implemented these > extensions if back channel logout didn't exist as a concept and > requirement. Its all in the sometimes ugly business of supporting > application developers who have a variety of deployment requirements > and restrictions. >=20 > Bill >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt Thread-Index: AQHTvu/78FHbTSFVrU6aBnDH4DxpKKPWY/aAgADS8gA= Date: Mon, 19 Mar 2018 08:25:55 +0000 Message-ID: References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> In-Reply-To: <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.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=Louis.LARMIGNAT@wavestone.com; x-originating-ip: [212.99.112.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR03MB1685; 7:N1mm9/s2q+/brcpDp/g38Wld+TyA0HYcfteVgBhLJegggpv3L4PfKrP8L64pWvmgepi0DBMEUXnWLwaegBE9YdAv4xcZJS9Wcb2gGEXtDPClCOmZZp+UQHmT1zGBVaqVyCndDJF8K5Q+VA4aqOPpgVvnql6IimZeu2LIXOM0tOuEiiziToaMd2muOahlYIISDdHcJ5nk2i57V6W78XmfuA0R5V1/XXombdX2WZk5HHvhNHHW2qKP9dWN0ZJeaZyU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cfd3eef7-d6ad-4802-2b53-08d58d730915 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR03MB1685; x-ms-traffictypediagnostic: DB5PR03MB1685: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501244)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB5PR03MB1685; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1685; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(39850400004)(396003)(376002)(366004)(53754006)(189003)(199004)(377424004)(26244003)(3280700002)(478600001)(8676002)(68736007)(8936002)(81156014)(81166006)(10710500007)(1680700002)(2900100001)(966005)(14454004)(5660300001)(74316002)(3660700001)(33656002)(72206003)(66066001)(39060400002)(7736002)(106356001)(25786009)(14971765001)(3846002)(7696005)(316002)(2501003)(2950100002)(53546011)(6506007)(76176011)(2420400007)(102836004)(59450400001)(6116002)(6246003)(606006)(53936002)(2906002)(15650500001)(55016002)(229853002)(105586002)(97736004)(790700001)(26005)(99286004)(5890100001)(5250100002)(186003)(110136005)(9686003)(54896002)(236005)(6306002)(86362001)(6436002)(7110500001)(53386004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1685; H:DB5PR03MB1191.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: wavestone.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ONY5Vv5L7SBmDVSqgmeClfk+KRvL+rH83M0dTz60lFm/UMUK7cc8UOkKnHaat6nmZchR2UTDN47kGbTrMTYJs/Y9wHBfkBAaquJj07cC8B9VqpsVE9PEHOaCYSMb5JqNgWkJ6cvPtE7o/OxqE3jFjeOixwZVAUqNw7bWICK30SSPUWbLm9phtg5oCcpuIh51YexJPuD3YH30ik6Iz8OMLhUgqiolNR54BZKnH9ItL9EbDqG4gROUGpdCb/KqkIfiDAKUkLapHzFJESNGVEgcl9Nxor8ZW092E50Av1n2crrFuKDiNM2kUIdXdBbDzPT0aE6fkByqLN+EPy6duHFsOQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR03MB1191DFA3BACC2806E2C07899F6D40DB5PR03MB1191eurp_" MIME-Version: 1.0 X-OriginatorOrg: wavestone.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfd3eef7-d6ad-4802-2b53-08d58d730915 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 08:25:55.4524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5de96c96-c87c-4dce-aad9-f5c557b52ac1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1685 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 08:26:03 -0000 --_000_DB5PR03MB1191DFA3BACC2806E2C07899F6D40DB5PR03MB1191eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBkcmFmdCBTaWduaW5nIEhUVFAgTWVzc2FnZXMgKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jYXZhZ2UtaHR0cC1zaWduYXR1cmVzLTA5KSBjb3VsZCBub3QgbWVl dCB0aGlzIHJlcXVpcmVtZW50IGluIGEgbW9yZSBnZW5lcmljIHdheSA/DQoNClJlZ2FyZHMsDQpM b3Vpcw0KDQpEZSA6IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBwYXJ0IGRl IEJyb2NrIEFsbGVuDQpFbnZvecOpIDogZGltYW5jaGUgMTggbWFycyAyMDE4IDIwOjQwDQrDgCA6 IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pjsgb2F1dGhAaWV0 Zi5vcmcNCk9iamV0IDogUmU6IFtPQVVUSC1XR10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNl LTAwLnR4dA0KDQpXaHkgaXMgVExTIHRvIHRoZSBpbnRvc3BlY3Rpb24gZW5kcG9pbnQgbm90IHN1 ZmZpY2llbnQ/IEFyZSB5b3UgdGhpbmtpbmcgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSBtdWx0aS10 ZW5hbmN5IHN1cHBvcnQgb2Ygc29tZSBraW5kPw0KDQotQnJvY2sNCg0KDQpPbiAzLzE4LzIwMTgg MzozMzoxNiBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCkkganVz dCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdGhhdCBWbGFkaW1pciBEemh1dmlub3YgYW5kIEkgaGF2 ZSB3cml0dGVuLiBJdCBwcm9wb3NlcyBhIEpXVC1iYXNlZCByZXNwb25zZSB0eXBlIGZvciBUb2tl biBJbnRyb3NwZWN0aW9uLiBUaGUgb2JqZWN0aXZlIGlzIHRvIHByb3ZpZGUgcmVzb3VyY2Ugc2Vy dmVycyB3aXRoIHNpZ25lZCB0b2tlbnMgaW4gY2FzZSB0aGV5IG5lZWQgY3J5cHRvZ3JhcGhpYyBl dmlkZW5jZSB0aGF0IHRoZSBBUyBjcmVhdGVkIHRoZSB0b2tlbiAoZS5nLiBmb3IgbGlhYmlsaXR5 KS4NCg0KSSB3aWxsIHByZXNlbnQgdGhlIG5ldyBkcmFmdCBpbiB0aGUgc2Vzc2lvbiBvbiBXZWRu ZXNkYXkuDQoNCmtpbmQgcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KQW5mYW5nIGRlciB3ZWl0ZXJn ZWxlaXRldGVuIE5hY2hyaWNodDoNCg0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkJldHJlZmY6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVz cG9uc2UtMDAudHh0DQpEYXR1bTogMTguIE3DpHJ6IDIwMTggdW0gMjA6MTk6MzcgTUVaDQpBbjog IlZsYWRpbWlyIER6aHV2aW5vdiIgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFk aW1pckBjb25uZWN0MmlkLmNvbT4+LCAiVG9yc3RlbiBMb2RkZXJzdGVkdCIgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9u LXJlc3BvbnNlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb3Jz dGVuIExvZGRlcnN0ZWR0IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6ICAgICAgICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1y ZXNwb25zZQ0KUmV2aXNpb246IDAwDQpUaXRsZTogICAgICAgICAgSldUIFJlc3BvbnNlIGZvciBP QXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uDQpEb2N1bWVudCBkYXRlOiAgMjAxOC0wMy0xNQ0KR3Jv dXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDUNClVS TDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt bG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9kZGVy c3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UvDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1p bnRyb3NwZWN0aW9uLXJlc3BvbnNlLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9z cGVjdGlvbi1yZXNwb25zZTxodHRwczovL2RhdGF0cmFja2VyLi5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZT4NCg0KDQpB YnN0cmFjdDoNCiAgVGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBhZGRpdGlvbmFsIEpTT04gV2ViIFRv a2VuIChKV1QpIGJhc2VkIHJlc3BvbnNlDQogIGZvciBPQXV0aCAyLjAgVG9rZW4gSW50cm9zcGVj dGlvbi4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9v bHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpUaGUgaW5mb3JtYXRpb24g dHJhbnNtaXR0ZWQgaW4gdGhlIHByZXNlbnQgZW1haWwgaW5jbHVkaW5nIHRoZSBhdHRhY2htZW50 IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHBy aXZpbGVnZWQgbWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0 aW9uIG9yIG90aGVyIHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2Ug dXBvbiB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlz IGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGll cyBvZiB0aGUgbWF0ZXJpYWwuDQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIHF1 aSB5IHNvbnQgw6l2ZW50dWVsbGVtZW50IGpvaW50ZXMgc29udCBjb25maWRlbnRpZWxzIGV0IHRy YW5zbWlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzb24gZGVzdGluYXRhaXJlLiBUb3V0 ZSBtb2RpZmljYXRpb24sIMOpZGl0aW9uLCB1dGlsaXNhdGlvbiBvdSBkaWZmdXNpb24gcGFyIHRv dXRlIHBlcnNvbm5lIG91IGVudGl0w6kgYXV0cmUgcXVlIGxlIGRlc3RpbmF0YWlyZSBlc3QgaW50 ZXJkaXRlLiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBub3VzIHZv dXMgcmVtZXJjaW9ucyBkZSBub3VzIGVuIGluZm9ybWVyIGltbcOpZGlhdGVtZW50IGV0IGRlIGxl IHN1cHByaW1lciBhaW5zaSBxdWUgbGVzIHBpw6hjZXMgcXVpIHkgc29udCDDqXZlbnR1ZWxsZW1l bnQgam9pbnRlcy4NCg== --_000_DB5PR03MB1191DFA3BACC2806E2C07899F6D40DB5PR03MB1191eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNSA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVjaWRhIENv bnNvbGUiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDQgNSA0IDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZHJhZnQNCjxhIG5hbWU9Il9IbGs1MDkyMTQ2NjMi PjxpPlNpZ25pbmcgSFRUUCBNZXNzYWdlczwvaT48L2E+PGk+ICg8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlcy0wOSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25hdHVyZXMtMDk8L2E+ KTwvaT4gY291bGQgbm90IG1lZXQgdGhpcyByZXF1aXJlbWVudCBpbiBhIG1vcmUgZ2VuZXJpYyB3 YXkgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TG91aXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0Ow0K PGI+RGUgbGEgcGFydCBkZTwvYj4gQnJvY2sgQWxsZW48YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gZGltYW5jaGUgMTggbWFycyAyMDE4IDIwOjQwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBUb3Jz dGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs7IG9hdXRoQGll dGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW09BVVRILVdHXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJv c3BlY3Rpb24tcmVzcG9uc2UtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgaWQ9Il9fTWFpbGJpcmRTdHlsZUNvbnRlbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRh IENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPldoeSBpcyBUTFMgdG8gdGhlIGludG9zcGVjdGlv biBlbmRwb2ludCBub3Qgc3VmZmljaWVudD8gQXJlIHlvdSB0aGlua2luZyB0aGVyZSBuZWVkcyB0 byBiZSBzb21lIG11bHRpLXRlbmFuY3kgc3VwcG9ydCBvZiBzb21lIGtpbmQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+LUJyb2NrPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2lu LXRvcDoxNS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDo3 LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6I0FBQUFBQSI+T24gMy8xOC8yMDE4IDM6MzM6MTYgUE0s IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFj ayI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6 YmxhY2siPkkganVzdCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdGhhdCBWbGFkaW1pciBEemh1dmlu b3YgYW5kIEkgaGF2ZSB3cml0dGVuLiBJdCBwcm9wb3NlcyBhIEpXVC1iYXNlZCByZXNwb25zZSB0 eXBlIGZvciBUb2tlbiBJbnRyb3NwZWN0aW9uLiBUaGUgb2JqZWN0aXZlIGlzIHRvIHByb3ZpZGUN CiByZXNvdXJjZSBzZXJ2ZXJzIHdpdGggc2lnbmVkIHRva2VucyBpbiBjYXNlIHRoZXkgbmVlZCBj cnlwdG9ncmFwaGljIGV2aWRlbmNlIHRoYXQgdGhlIEFTIGNyZWF0ZWQgdGhlIHRva2VuIChlLmcu IGZvciBsaWFiaWxpdHkpLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+SSB3aWxsIHByZXNlbnQgdGhlIG5ldyBkcmFmdCBp biB0aGUgc2Vzc2lvbiBvbiBXZWRuZXNkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1 Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj5raW5kIHJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVv dDs7Y29sb3I6YmxhY2siPlRvcnN0ZW4uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+QW5mYW5nIGRlciB3ZWl0ZXJnZWxlaXRldGVuIE5h Y2hyaWNodDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lk YSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlZvbjoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTAw LnR4dDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5EYXR1bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjE4LiBNw6RyeiAyMDE4IHVtIDIwOjE5OjM3IE1FWjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFu Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7VmxhZGlt aXIgRHpodXZpbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp ZC5jb20iPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPiZndDssICZxdW90O1RvcnN0ZW4gTG9k ZGVyc3RlZHQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2Ut MDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb3JzdGVuIExv ZGRlcnN0ZWR0IGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxi cj4NCk5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPmRyYWZ0LWxv ZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlPGJyPg0KUmV2aXNpb246 PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjAwPGJyPg0KVGl0bGU6PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkpXVCBSZXNwb25zZSBmb3IgT0F1dGggVG9rZW4g SW50cm9zcGVjdGlvbjxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsgPC9zcGFuPjIwMTgtMDMtMTU8YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjU8YnI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1v YXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMC50eHQiPmh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVj dGlvbi1yZXNwb25zZS0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1y ZXNwb25zZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvZGRlcnN0 ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLzwvYT48YnI+DQpIdG1saXplZDog Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9u LXJlc3BvbnNlLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3Rl ZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDA8L2E+PGJyPg0KSHRtbGl6ZWQ6 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1p bnRyb3NwZWN0aW9uLXJlc3BvbnNlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlPC9h Pjxicj4NCjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZHJhZnQg cHJvcG9zZXMgYW4gYWRkaXRpb25hbCBKU09OIFdlYiBUb2tlbiAoSldUKSBiYXNlZCByZXNwb25z ZTxicj4NCiZuYnNwOyZuYnNwO2ZvciBPQXV0aCAyLjAgVG9rZW4gSW50cm9zcGVjdGlvbi48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmciPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRo ZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTp0YWhvbWE7 Zm9udC1zaXplOjlweDtjb2xvcjpncmF5OyI+VGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlu IHRoZSBwcmVzZW50IGVtYWlsIGluY2x1ZGluZyB0aGUgYXR0YWNobWVudCBpcyBpbnRlbmRlZCBv bmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJl c3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG1hdGVy aWFsLg0KIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9yIG90aGVy IHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiB0aGlzIGlu Zm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGluIGVycm9yLCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCiBhbGwgY29waWVzIG9mIHRoZSBt YXRlcmlhbC4gPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hjZXMgcXVp IHkgc29udCDDqXZlbnR1ZWxsZW1lbnQgam9pbnRlcyBzb250IGNvbmZpZGVudGllbHMgZXQgdHJh bnNtaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNvbiBkZXN0aW5hdGFpcmUuIFRvdXRl IG1vZGlmaWNhdGlvbiwgw6lkaXRpb24sIHV0aWxpc2F0aW9uIG91IGRpZmZ1c2lvbiBwYXIgdG91 dGUgcGVyc29ubmUgb3UgZW50aXTDqSBhdXRyZSBxdWUgbGUgZGVzdGluYXRhaXJlIGVzdCBpbnRl cmRpdGUuDQogU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbm91cyB2 b3VzIHJlbWVyY2lvbnMgZGUgbm91cyBlbiBpbmZvcm1lciBpbW3DqWRpYXRlbWVudCBldCBkZSBs ZSBzdXBwcmltZXIgYWluc2kgcXVlIGxlcyBwacOoY2VzIHF1aSB5IHNvbnQgw6l2ZW50dWVsbGVt ZW50IGpvaW50ZXMuPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB5PR03MB1191DFA3BACC2806E2C07899F6D40DB5PR03MB1191eurp_-- From nobody Mon Mar 19 01:58:14 2018 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 DEF6E124235 for ; Mon, 19 Mar 2018 01:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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=oracle.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 7r3D4qrSrtvW for ; Mon, 19 Mar 2018 01:58:10 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 7621C1200F1 for ; Mon, 19 Mar 2018 01:58:10 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2J8rgNr009332; Mon, 19 Mar 2018 08:58:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=Obo1698KZ96D6EbCGIzbC+Myvt8cBIcN5/HBKnJxN/k=; b=JYbECDRGDfz255jjaFHe8ogtCwtdLcnWA1Kz1k/w/uv0kaKw3nCDkI2tF0888+Gj6dQz ZPYVtYmIfsD5xXL+UacUXL5x9FqawTrUFgWDcMuM2+o71dOVhxNt4woY0F+X4J3f4VCT bG+7EAJYjMopv2faW10QICZZGBa1sjV/VhoJKw7avxmsDh5sPnw4Uo45KIiosVvhHLP3 9+vlGIfheQX1pY+aikTY+FFH0Ht+CAEVv0GEx6LQ/bpZA1Fyw9GrnEDXTOIL0ZE7lbRL vg+ghz5a7wcZjgqk/dTpc4gyjG36iy+3qi6seqG4Zx/kP8ThuHTF1DMf4Jolpxrsrr4D vw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2gta3m80mw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Mar 2018 08:58:06 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2J8vxkY019360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Mar 2018 08:58:00 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2J8vwuq021133; Mon, 19 Mar 2018 08:57:59 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Mar 2018 01:57:58 -0700 From: Phil Hunt Message-Id: <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DC5F3267-BA29-413C-84C8-453C6D3F559B" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 08:57:55 +0000 In-Reply-To: Cc: Brock Allen , Torsten Lodderstedt , "oauth@ietf.org" To: LARMIGNAT Louis References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8836 signatures=668693 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190007 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 08:58:13 -0000 --Apple-Mail=_DC5F3267-BA29-413C-84C8-453C6D3F559B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This draft has similar issues to = https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 Rather than *try* sign HTTP, a signed JWT object is more reliably = returned. Phil > On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis = wrote: >=20 > Hi, > =20 > The draft Signing HTTP Messages <> = (https://tools.ietf.org/html/draft-cavage-http-signatures-09 = ) could not = meet this requirement in a more generic way ? > =20 > Regards, > Louis > =20 > De : OAuth > De = la part de Brock Allen > Envoy=C3=A9 : dimanche 18 mars 2018 20:40 > =C3=80 : Torsten Lodderstedt >; oauth@ietf.org = > Objet : Re: [OAUTH-WG] Fwd: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > =20 > Why is TLS to the intospection endpoint not sufficient? Are you = thinking there needs to be some multi-tenancy support of some kind? > =20 > -Brock > =20 > On 3/18/2018 3:33:16 PM, Torsten Lodderstedt > wrote: >=20 > Hi all, > =20 > I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 > =20 > I will present the new draft in the session on Wednesday. > =20 > kind regards, > Torsten.=20 >=20 >=20 > Anfang der weitergeleiteten Nachricht: > =20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ > An: "Vladimir Dzhuvinov" >, "Torsten Lodderstedt" = > > =20 >=20 > A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to = the > IETF repository. >=20 > Name: draft-lodderstedt-oauth-jwt-introspection-response > Revision: 00 > Title: JWT Response for OAuth Token Introspection > Document date: 2018-03-15 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ = > Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response = >=20 >=20 > Abstract: > This draft proposes an additional JSON Web Token (JWT) based = response > for OAuth 2.0 Token Introspection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > =20 > The information transmitted in the present email including the = attachment is intended only for the person to whom or entity to which it = is addressed and may contain confidential 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 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 = jointes sont confidentiels et transmis =C3=A0 l'intention exclusive de = son destinataire. Toute modification, =C3=A9dition, utilisation ou = diffusion par toute personne 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 imm=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=_DC5F3267-BA29-413C-84C8-453C6D3F559B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = draft has similar issues to https://tools.ietf.org/html/draft-richer-oauth-signed-http-requ= est-01

Rather = than *try* sign HTTP, a signed JWT object is more reliably returned.

Phil


On Mar 19, 2018, at 8:25 AM, = LARMIGNAT Louis <Louis.LARMIGNAT@wavestone.com> wrote:

Hi,
 
The draft Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-09= ) could not meet = this requirement in a more generic way ?
 
Regards,
Louis
 
De : OAuth <oauth-bounces@ietf.org> De la part = de Brock Allen
Envoy=C3=A9 : dimanche 18 mars 2018 = 20:40
=C3=80 : Torsten Lodderstedt <torsten@lodderstedt.net>; oauth@ietf.org
Objet : Re: [OAUTH-WG] Fwd: New = Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
 
Why is TLS to the intospection endpoint not = sufficient? Are you thinking there needs to be some multi-tenancy = support of some kind?
 
-Brock
 

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi all,
 
I just submitted a = new draft that Vladimir Dzhuvinov and I have written. It proposes a = JWT-based response type for Token Introspection. The objective is to = provide resource servers with signed tokens in case they need = cryptographic evidence that the AS created the token (e.g. for = liability). 
 
I will present the = new draft in the session on Wednesday.
 
kind regards,
Torsten. 


Anfang der weitergeleiteten Nachricht:
 
Von: internet-drafts@ietf.org
Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, = "Torsten Lodderstedt" <torsten@lodderstedt.net>
 


A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name:        &= nbsp;  draft-lodderstedt-oaut= h-jwt-introspection-response
Revision: 00
Title:        &= nbsp; JWT = Response for OAuth Token Introspection
Document date:  2018-03-15
Group:        &= nbsp; Individual = Submission
Pages:        &= nbsp; 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat

 
The information transmitted in the present = email including the attachment is intended only for the person to whom = or entity to which it is addressed and may contain confidential 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 the intended recipient is prohibited. If = you received this in error, please contact the sender and delete all = copies of the material. 

Ce message et toutes les pi=C3=A8ces qui y sont = =C3=A9ventuellement jointes sont confidentiels et transmis =C3=A0 = l'intention exclusive de son destinataire. Toute modification, =C3=A9ditio= n, utilisation ou diffusion par toute personne 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 imm=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=_DC5F3267-BA29-413C-84C8-453C6D3F559B-- From nobody Mon Mar 19 03:15:04 2018 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 38445126DED for ; Mon, 19 Mar 2018 03:15:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 BLQGHWscUSMh for ; Mon, 19 Mar 2018 03:15:00 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 4F810126CE8 for ; Mon, 19 Mar 2018 03:15:00 -0700 (PDT) Received: from [80.187.102.250] (helo=[172.20.10.2]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1exrof-0000XM-5s; Mon, 19 Mar 2018 11:14:57 +0100 From: Torsten Lodderstedt Message-Id: <990FE110-03D1-4B3B-8067-1D619D570E25@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_18DB902B-5262-4A4C-B194-CC216C6338AC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 11:14:55 +0100 In-Reply-To: <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> Cc: oauth@ietf.org To: Brock Allen References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 10:15:03 -0000 --Apple-Mail=_18DB902B-5262-4A4C-B194-CC216C6338AC Content-Type: multipart/alternative; boundary="Apple-Mail=_9548E800-5C7C-4D7F-8BB8-A100508B9484" --Apple-Mail=_9548E800-5C7C-4D7F-8BB8-A100508B9484 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 18.03.2018 um 20:40 schrieb Brock Allen : >=20 > Why is TLS to the intospection endpoint not sufficient? TLS is sufficient, if AS and RS want to ensure the integrity of the = token data (on transit). But there are use cases, where the RS wants = evidence (=3D=3D digital signature over the token) who created the = token. This is for non-repudation/liability. > Are you thinking there needs to be some multi-tenancy support of some = kind? With respect to what party? The draft allows every RS to choose the = response type and if JWT, the algorithms to use.=20 kind regards, Torsten. =20 =20 >=20 > -Brock >=20 >> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt = wrote: >>=20 >> Hi all, >>=20 >> I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 >>=20 >> I will present the new draft in the session on Wednesday. >>=20 >> kind regards, >> Torsten.=20 >>=20 >>> Anfang der weitergeleiteten Nachricht: >>>=20 >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ >>> An: "Vladimir Dzhuvinov" >, "Torsten Lodderstedt" = > >>>=20 >>>=20 >>> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to = the >>> IETF repository. >>>=20 >>> Name: = draft-lodderstedt-oauth-jwt-introspection-response >>> Revision: 00 >>> Title: JWT Response for OAuth Token Introspection >>> Document date: 2018-03-15 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ = >>> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response = >>>=20 >>>=20 >>> Abstract: >>> This draft proposes an additional JSON Web Token (JWT) based = response >>> for OAuth 2.0 Token Introspection. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 --Apple-Mail=_9548E800-5C7C-4D7F-8BB8-A100508B9484 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Am 18.03.2018 um 20:40 schrieb Brock Allen <brockallen@gmail.com>:

=20 =20 =20 =20 =20 Why is TLS to the intospection = endpoint not sufficient?

TLS is sufficient, if AS and RS want to ensure the = integrity of the token data (on transit). But there are use cases, where = the RS wants evidence (=3D=3D digital signature over the token) who = created the token. This is for non-repudation/liability.

Are you thinking there needs to = be some multi-tenancy support of some kind?

With = respect to what party? The draft allows every RS to choose the response = type and if JWT, the algorithms to use. 

kind regards,
Torsten. =   
 

-Brock

On 3/18/2018 3:33:16 PM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

I just submitted a new = draft that Vladimir Dzhuvinov and I have written. It proposes a = JWT-based response type for Token Introspection. The objective is to = provide resource servers with signed tokens in case they need = cryptographic evidence that the AS created the token (e.g. for = liability). 

I will present the new draft in the session on = Wednesday.

kind = regards,
Torsten. 

Anfang der weitergeleiteten Nachricht:

Von: internet-drafts@ietf.org
Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>


A new version = of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name: = = draft-lodderstedt-oauth-jwt-introspection-response
Revision: 00
Title: JWT = Response for OAuth Token Introspection
Document date: = 2018-03-15
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat


=20 =

= --Apple-Mail=_9548E800-5C7C-4D7F-8BB8-A100508B9484-- --Apple-Mail=_18DB902B-5262-4A4C-B194-CC216C6338AC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzE5MTAxNDU2WjAjBgkqhkiG9w0BCQQxFgQUL/CmoT494Ad3 AY8/228B4OnnO8cwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAKd6q9HgMPrg05OnCEoD6MRy1DriTz1ZJIig6k6jBP0hNPC3Wreh hLaD3D+b1DkgmsFv+R46un0EMWU2Ck+NA3PTfbrit90/ssWuqYLiJdI0FcExShLFhk4SagHXV4ei xC0tGSEqC++50dPyjEzMiTuM9JTC5myMj9203WAzHxGulQZJofHCG5fieZEODKGxq2BtIthAGb7R ZNEHvjp+lhL5+AD7PabjR9393N4q9os3nl6fOr3d1FuGI4XGR0REeOyEF0xEthwbuX/7Chn+FmSU /RK3RO+PAE7eL3DdxlVG2kkjlrR+vKYJZOtAapgl8j1Y7mBDzXijDXiNTPhZ16MAAAAAAAA= --Apple-Mail=_18DB902B-5262-4A4C-B194-CC216C6338AC-- From nobody Mon Mar 19 03:17:07 2018 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 C0DC7126CE8 for ; Mon, 19 Mar 2018 03:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 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_L5=3.082, 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 SKgpE5-Pw5NI for ; Mon, 19 Mar 2018 03:17:03 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.107]) (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 30977124BFA for ; Mon, 19 Mar 2018 03:17:03 -0700 (PDT) Received: from [80.187.102.250] (helo=[172.20.10.2]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1exrqp-00050c-Io; Mon, 19 Mar 2018 11:17:11 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FCD637DE-13B8-4F9F-873D-88D002DF4819"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 11:16:58 +0100 In-Reply-To: <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> Cc: LARMIGNAT Louis , Brock Allen , "oauth@ietf.org" To: Phil Hunt References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 10:17:06 -0000 --Apple-Mail=_FCD637DE-13B8-4F9F-873D-88D002DF4819 Content-Type: multipart/alternative; boundary="Apple-Mail=_587A86F3-8925-4C51-85D4-79A20DA4C5C4" --Apple-Mail=_587A86F3-8925-4C51-85D4-79A20DA4C5C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We explicitly want the token (JSON object) to be signed not the HTTP = response. I think using JWS is the most generic way to achieve that = goal. > Am 19.03.2018 um 09:57 schrieb Phil Hunt : >=20 > This draft has similar issues to = https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 = >=20 > Rather than *try* sign HTTP, a signed JWT object is more reliably = returned. >=20 > Phil >=20 >=20 >> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis = > = wrote: >>=20 >> Hi, >> =20 >> The draft Signing HTTP Messages <> = (https://tools.ietf.org/html/draft-cavage-http-signatures-09 = ) could not = meet this requirement in a more generic way ? >> =20 >> Regards, >> Louis >> =20 >> De : OAuth > = De la part de Brock Allen >> Envoy=C3=A9 : dimanche 18 mars 2018 20:40 >> =C3=80 : Torsten Lodderstedt >; oauth@ietf.org = >> Objet : Re: [OAUTH-WG] Fwd: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> =20 >> Why is TLS to the intospection endpoint not sufficient? Are you = thinking there needs to be some multi-tenancy support of some kind? >> =20 >> -Brock >> =20 >> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt > wrote: >>=20 >> Hi all, >> =20 >> I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 >> =20 >> I will present the new draft in the session on Wednesday. >> =20 >> kind regards, >> Torsten.=20 >>=20 >>=20 >> Anfang der weitergeleiteten Nachricht: >> =20 >> Von: internet-drafts@ietf.org >> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ >> An: "Vladimir Dzhuvinov" >, "Torsten Lodderstedt" = > >> =20 >>=20 >> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to = the >> IETF repository. >>=20 >> Name: draft-lodderstedt-oauth-jwt-introspection-response >> Revision: 00 >> Title: JWT Response for OAuth Token Introspection >> Document date: 2018-03-15 >> Group: Individual Submission >> Pages: 5 >> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ = >> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response = >>=20 >>=20 >> Abstract: >> This draft proposes an additional JSON Web Token (JWT) based = response >> for OAuth 2.0 Token Introspection. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >> =20 >> The information transmitted in the present email including the = attachment is intended only for the person to whom or entity to which it = is addressed and may contain confidential 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 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 = jointes sont confidentiels et transmis =C3=A0 l'intention exclusive de = son destinataire. Toute modification, =C3=A9dition, utilisation ou = diffusion par toute personne 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 imm=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 = >=20 --Apple-Mail=_587A86F3-8925-4C51-85D4-79A20DA4C5C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = explicitly want the token (JSON object) to be signed not the HTTP = response. I think using JWS is the most generic way to achieve that = goal.

Am 19.03.2018 um 09:57 schrieb Phil Hunt = <phil.hunt@oracle.com>:

This draft has similar = issues to https://tools.ietf.org/html/draft-richer-oauth-signed-http-requ= est-01

Rather = than *try* sign HTTP, a signed JWT object is more reliably returned.

Phil


On Mar = 19, 2018, at 8:25 AM, LARMIGNAT Louis <Louis.LARMIGNAT@wavestone.com> wrote:

Hi,
 
The draft Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-09= ) could not meet = this requirement in a more generic way ?
 
Regards,
Louis
 
De : OAuth <oauth-bounces@ietf.org> De la part = de Brock Allen
Envoy=C3=A9 : dimanche 18 mars 2018 = 20:40
=C3=80 : Torsten Lodderstedt <torsten@lodderstedt.net>; oauth@ietf.org
Objet : Re: [OAUTH-WG] Fwd: New = Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
 
Why is TLS to the intospection endpoint not = sufficient? Are you thinking there needs to be some multi-tenancy = support of some kind?
 
-Brock
 

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi all,
 
I just submitted a = new draft that Vladimir Dzhuvinov and I have written. It proposes a = JWT-based response type for Token Introspection. The objective is to = provide resource servers with signed tokens in case they need = cryptographic evidence that the AS created the token (e.g. for = liability). 
 
I will present the = new draft in the session on Wednesday.
 
kind regards,
Torsten. 


Anfang der weitergeleiteten Nachricht:
 
Von: internet-drafts@ietf.org
Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, = "Torsten Lodderstedt" <torsten@lodderstedt.net>
 


A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name:        &= nbsp;  draft-lodderstedt-oaut= h-jwt-introspection-response
Revision: 00
Title:        &= nbsp; JWT = Response for OAuth Token Introspection
Document date:  2018-03-15
Group:        &= nbsp; Individual = Submission
Pages:        &= nbsp; 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat

 
The information transmitted in the present = email including the attachment is intended only for the person to whom = or entity to which it is addressed and may contain confidential 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 the intended recipient is prohibited. If = you received this in error, please contact the sender and delete all = copies of the material. 

Ce message et toutes les pi=C3=A8ces qui y sont = =C3=A9ventuellement jointes sont confidentiels et transmis =C3=A0 = l'intention exclusive de son destinataire. Toute modification, =C3=A9ditio= n, utilisation ou diffusion par toute personne 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 imm=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=_587A86F3-8925-4C51-85D4-79A20DA4C5C4-- --Apple-Mail=_FCD637DE-13B8-4F9F-873D-88D002DF4819 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwMzE5MTAxNjU5WjAjBgkqhkiG9w0BCQQxFgQUt/BmyLwk3oQP 7wsfK0MoOvzyhfswgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAGLAzKXnCPBK4pYBZflm+QMui7pzgrvoEu3usmLEZ6IDYczFSq8d BBNOghfCs9YKQgcAeD2AbV5LL59ZFygD96ELM3KbT55t6qwNkpDdUOz3ZFgB7buYzY31IrYLzSVt D9Ccd3iEOb8Wzfe8H4PZ3lVwWJUso/3W6r4NY2qnenzDnJEbLMKd8XWu/+kN0e/I7Wq/MJACgpka coAGJrZq8Y0CBUASCkxywb3pkf/p03lLEtpZauggr44ePelclFCSwYoWYlOxHIkE2W7ltHNdC08R N0OYB8jMB6BRhiUwcVtnoZmqXCMKY4hdvmRHfn/c+nO8BkS9tiQgTVPKtqSXJa8AAAAAAAA= --Apple-Mail=_FCD637DE-13B8-4F9F-873D-88D002DF4819-- From nobody Mon Mar 19 03:23:04 2018 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 83CC0127010 for ; Mon, 19 Mar 2018 03:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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=oracle.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 MAhG4ZhVfTA7 for ; Mon, 19 Mar 2018 03:23:01 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 D21ED126DC2 for ; Mon, 19 Mar 2018 03:23:00 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2JAD8CZ015840; Mon, 19 Mar 2018 10:22:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=/psBluOhZoxf4jdOqj8gTW5ijZ14hVmhNqZSGcel7us=; b=Ky8uEoY3DtaySv6LiymBC2e6w9tKOEYMnmIrhF+/jHrSEufHqxarUC91nlpS/9DnvI02 FY+d3ZSO8eSDOIZHAsSpnFQH55yxAzOOHoj6q3uX4tgD9+/+lEARL86+iqyxXGOUuvSO 9QzHCXGaU9Rf6d/X+61cgL+0bD4oilCttKNEv4U0+aWPWHrL6N/mvk3ViWWELXlqgpkZ hTGmvQBufPN4VnvjbRKF5DQi8WSOrUNiZl4yXN6DBKdPPbTmumzC0hfI8htboX07kXQh vWqzkNv6zINTKClVbUHIVozd8Jq1qFU+PC5HFnrYLxLHH8hS/gHZ1BvkWYp6VF99znsj YQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2gtb8p0148-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Mar 2018 10:22:58 +0000 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 w2JAMvkg004328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Mar 2018 10:22:57 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2JAMvSJ005583; Mon, 19 Mar 2018 10:22:57 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Mar 2018 03:22:56 -0700 From: Phil Hunt Message-Id: <84E8CEAD-98D3-48D2-AC48-0899BAC4419C@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8293F99E-4A45-40CB-9F61-D8CF45ADB775" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 10:22:53 +0000 In-Reply-To: Cc: LARMIGNAT Louis , Brock Allen , "oauth@ietf.org" To: Torsten Lodderstedt References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8836 signatures=668693 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190007 Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 10:23:03 -0000 --Apple-Mail=_8293F99E-4A45-40CB-9F61-D8CF45ADB775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1. This is what I expected. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt = wrote: >=20 > We explicitly want the token (JSON object) to be signed not the HTTP = response. I think using JWS is the most generic way to achieve that = goal. >=20 >> Am 19.03.2018 um 09:57 schrieb Phil Hunt >: >>=20 >> This draft has similar issues to = https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 = >>=20 >> Rather than *try* sign HTTP, a signed JWT object is more reliably = returned. >>=20 >> Phil >>=20 >>=20 >>> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis = > = wrote: >>>=20 >>> Hi, >>> =20 >>> The draft Signing HTTP Messages <> = (https://tools.ietf.org/html/draft-cavage-http-signatures-09 = ) could not = meet this requirement in a more generic way ? >>> =20 >>> Regards, >>> Louis >>> =20 >>> De : OAuth > = De la part de Brock Allen >>> Envoy=C3=A9 : dimanche 18 mars 2018 20:40 >>> =C3=80 : Torsten Lodderstedt >; oauth@ietf.org = >>> Objet : Re: [OAUTH-WG] Fwd: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> =20 >>> Why is TLS to the intospection endpoint not sufficient? Are you = thinking there needs to be some multi-tenancy support of some kind? >>> =20 >>> -Brock >>> =20 >>> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt = > wrote: >>>=20 >>> Hi all, >>> =20 >>> I just submitted a new draft that Vladimir Dzhuvinov and I have = written. It proposes a JWT-based response type for Token Introspection. = The objective is to provide resource servers with signed tokens in case = they need cryptographic evidence that the AS created the token (e.g. for = liability).=20 >>> =20 >>> I will present the new draft in the session on Wednesday. >>> =20 >>> kind regards, >>> Torsten.=20 >>>=20 >>>=20 >>> Anfang der weitergeleiteten Nachricht: >>> =20 >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ >>> An: "Vladimir Dzhuvinov" >, "Torsten Lodderstedt" = > >>> =20 >>>=20 >>> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-lodderstedt-oauth-jwt-introspection-response >>> Revision: 00 >>> Title: JWT Response for OAuth Token Introspection >>> Document date: 2018-03-15 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-00.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ = >>> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-00 = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response = >>>=20 >>>=20 >>> Abstract: >>> This draft proposes an additional JSON Web Token (JWT) based = response >>> for OAuth 2.0 Token Introspection. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>> =20 >>> The information transmitted in the present email including the = attachment is intended only for the person to whom or entity to which it = is addressed and may contain confidential 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 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 = jointes sont confidentiels et transmis =C3=A0 l'intention exclusive de = son destinataire. Toute modification, =C3=A9dition, utilisation ou = diffusion par toute personne 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 imm=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 = >>=20 >=20 --Apple-Mail=_8293F99E-4A45-40CB-9F61-D8CF45ADB775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1. =  This is what I expected.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

We explicitly want the = token (JSON object) to be signed not the HTTP response. I think using = JWS is the most generic way to achieve that goal.

Am 19.03.2018 um 09:57 schrieb Phil Hunt <phil.hunt@oracle.com>:

This draft has similar = issues to https://tools.ietf.org/html/draft-richer-oauth-signed-http-requ= est-01

Rather = than *try* sign HTTP, a signed JWT object is more reliably returned.

Phil


On Mar = 19, 2018, at 8:25 AM, LARMIGNAT Louis <Louis.LARMIGNAT@wavestone.com> wrote:

Hi,
 
The draft Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-09= ) could not meet = this requirement in a more generic way ?
 
Regards,
Louis
 
De : OAuth <oauth-bounces@ietf.org> De la part = de Brock Allen
Envoy=C3=A9 : dimanche 18 mars 2018 = 20:40
=C3=80 : Torsten Lodderstedt <torsten@lodderstedt.net>; oauth@ietf.org
Objet : Re: [OAUTH-WG] Fwd: New = Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
 
Why is TLS to the intospection endpoint not = sufficient? Are you thinking there needs to be some multi-tenancy = support of some kind?
 
-Brock
 

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

Hi all,
 
I just submitted a = new draft that Vladimir Dzhuvinov and I have written. It proposes a = JWT-based response type for Token Introspection. The objective is to = provide resource servers with signed tokens in case they need = cryptographic evidence that the AS created the token (e.g. for = liability). 
 
I will present the = new draft in the session on Wednesday.
 
kind regards,
Torsten. 


Anfang der weitergeleiteten Nachricht:
 
Von: internet-drafts@ietf.org
Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. M=C3=A4rz 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, = "Torsten Lodderstedt" <torsten@lodderstedt.net>
 


A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been successfully submitted by Torsten Lodderstedt and = posted to the
IETF repository.

Name:        &= nbsp;  draft-lodderstedt-oaut= h-jwt-introspection-response
Revision: 00
Title:        &= nbsp; JWT = Response for OAuth Token Introspection
Document date:  2018-03-15
Group:        &= nbsp; Individual = Submission
Pages:        &= nbsp; 5
URL: =            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jw= t-introspection-response-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-in= trospection-response/
Htmlized: =       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introsp= ection-response-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-j= wt-introspection-response


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




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

The IETF Secretariat

 
The information transmitted in the present = email including the attachment is intended only for the person to whom = or entity to which it is addressed and may contain confidential 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 the intended recipient is prohibited. If = you received this in error, please contact the sender and delete all = copies of the material. 

Ce message et toutes les pi=C3=A8ces qui y sont = =C3=A9ventuellement jointes sont confidentiels et transmis =C3=A0 = l'intention exclusive de son destinataire. Toute modification, =C3=A9ditio= n, utilisation ou diffusion par toute personne 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 imm=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=_8293F99E-4A45-40CB-9F61-D8CF45ADB775-- From nobody Mon Mar 19 04:41:12 2018 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 D0E2912E036 for ; Mon, 19 Mar 2018 04:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=erdtman-se.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 GjDbaA4jcAML for ; Mon, 19 Mar 2018 04:41:01 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 43BDB12D870 for ; Mon, 19 Mar 2018 04:41:01 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id g12so6789470pgs.0 for ; Mon, 19 Mar 2018 04:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yt1vn0LNSFp8kgKPJrMfOzwvFlvQvrFpYICGHdYMnv0=; b=mcw5pcemGAik6aduJ0Ae0riqd7HGgvkmoeDgeLecDMrF0d/V9RZ3/Zy3q8ppa49F2U RJwx5csRoe5qKlExXKO/BJAtZpfcpufiC5TWxNnGnthw8Ebzdefmv2rsv1wh+LgeZQkz HdcWBW9gxA7O2hS7RyIbw+J88baffACtsjnbDmpdg4Ow2pjNS4xz+Gnw6UuB4786CKXs pTn/XigRsd0Y3hAIZh8HTSEz9xbgeZfxlvTqEZRFFRhOrb7qHCsGGrk2gjWoiqUtbp6B NFPDOTJ4AYIswsZ+H3+x5d6Q7PMxblskUZ3twy2S5+vNORFVktQo5IhIk6Q4EP/kp7qv revQ== 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=yt1vn0LNSFp8kgKPJrMfOzwvFlvQvrFpYICGHdYMnv0=; b=EGtsQ4Mt+2v1DOmVU1GjB8OTacYKwvfSAu/XfCOHPWHubN3Zm+H/PD8uhyPH3quPrH JERpdq0eRv+fmV/Q4BQluTDrNwgt+EQaXQLBQpJHtumNmA3yt62C4TXwz6haaM/hCggk YDbYxOqPU+o0NfVO3HgHiWL8VW2AEi0sJhnNvd04SbEjFqfZUgI67Wy11RPGSzPisrsi 79xz9T028MUIJI9PQxQZb1dtHPIkJojH3WxXXoZ20sygNbnWQIVEINdESgo5Ny+MjELo LtK4z6FhiZgS24c7muUh63DxMhZM0d3lycDmnuqF8lZ+2uUVzuRYEfgVHZRnGPvVzL1F bj5Q== X-Gm-Message-State: AElRT7Gm4zd32xNupk1hX8pO11HqpDhGKg8EatDFEj36kuNlGeSXcoX6 CUzO7VNiGJ7QoMfgoBthkMcAbpNg5HBsK+o8Wq5yUA== X-Google-Smtp-Source: AG47ELvpfhmhgsLWcVVVkt9IizHCXkxapzKU9Uey03sCfjw7T5AoW2oGjROVOO743QtZ0LDMmMG+zzMH7mKhvfPhRYg= X-Received: by 10.99.155.2 with SMTP id r2mr2931129pgd.450.1521459660668; Mon, 19 Mar 2018 04:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.141.24 with HTTP; Mon, 19 Mar 2018 04:41:00 -0700 (PDT) In-Reply-To: <84E8CEAD-98D3-48D2-AC48-0899BAC4419C@oracle.com> References: <152140077785.15835.11388192447917251931.idtracker@ietfa.amsl.com> <2A1E98B8-973E-44F0-96F0-E319FD6969A8@lodderstedt.net> <308c1c61-a2ba-4e45-9fe6-9d525e554fb7@getmailbird.com> <85274C99-A8AA-452C-B8BC-46E7869642EB@oracle.com> <84E8CEAD-98D3-48D2-AC48-0899BAC4419C@oracle.com> From: Samuel Erdtman Date: Mon, 19 Mar 2018 12:41:00 +0100 Message-ID: To: Phil Hunt Cc: Torsten Lodderstedt , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="f403045e3bd09d59290567c26eaa" Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.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, 19 Mar 2018 11:41:05 -0000 --f403045e3bd09d59290567c26eaa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Adding an additional proposal to the table. Mike Jones, Anders Rundgren and I have created a version of JWS there the signed JSON data does not have to be Base64url encoded (the JSON is signed using ES6 serialization rules). One of the benefits to this approach would be that the introspection data is transferred in cleartext while still fully protected. Since it is transferred in the response body and not in a URL there is no need for the Base64url encoding. The draft can be fond here https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 And the example from your draft would look like this (the signature is not valid, I just copied it from another place) { "sub": "Z5O3upPC88QrAjx00dis", "aud": "https://protected.example.net/resource", "extension_field": "twenty-seven", "scope": "read write dolphin", "iss": "https://server.example.com/", "active": true, "exp": 1419356238, "iat": 1419350238, "client_id": "l238j323ds-23ij4", "username": "jdoe" "__cleartext_signature": { "alg": "ES256", "kid": "example.com:p256", "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHHZjsYdT96JZw" } } On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt wrote: > +1. This is what I expected. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt > wrote: > > We explicitly want the token (JSON object) to be signed not the HTTP > response. I think using JWS is the most generic way to achieve that goal. > > Am 19.03.2018 um 09:57 schrieb Phil Hunt : > > This draft has similar issues to https://tools.ietf.org/ > html/draft-richer-oauth-signed-http-request-01 > > Rather than *try* sign HTTP, a signed JWT object is more reliably returne= d. > > Phil > > > On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis < > Louis.LARMIGNAT@wavestone.com> wrote: > > Hi, > > The draft *Signing HTTP Messages** (https://tools.ietf.org/html/draft-cav= age-http-signatures-09 > )* could not > meet this requirement in a more generic way ? > > Regards, > Louis > > *De :* OAuth *De la part de* Brock Allen > *Envoy=C3=A9 :* dimanche 18 mars 2018 20:40 > *=C3=80 :* Torsten Lodderstedt ; oauth@ietf.org > *Objet :* Re: [OAUTH-WG] Fwd: New Version Notification for > draft-lodderstedt-oauth-jwt-introspection-response-00.txt > > Why is TLS to the intospection endpoint not sufficient? Are you thinking > there needs to be some multi-tenancy support of some kind? > > -Brock > > > On 3/18/2018 3:33:16 PM, Torsten Lodderstedt > wrote: > Hi all, > > I just submitted a new draft that Vladimir Dzhuvinov and I have written. > It proposes a JWT-based response type for Token Introspection. The > objective is to provide resource servers with signed tokens in case they > need cryptographic evidence that the AS created the token (e.g. for > liability). > > I will present the new draft in the session on Wednesday. > > kind regards, > Torsten. > > > Anfang der weitergeleiteten Nachricht: > > *Von: *internet-drafts@ietf.org > *Betreff: New Version Notification for > draft-lodderstedt-oauth-jwt-introspection-response-00.txt* > *Datum: *18. M=C3=A4rz 2018 um 20:19:37 MEZ > *An: *"Vladimir Dzhuvinov" , "Torsten > Lodderstedt" > > > > A new version of I-D, draft-lodderstedt-oauth-jwt- > introspection-response-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-jwt-introspection-response > Revision: 00 > Title: JWT Response for OAuth Token Introspection > Document date: 2018-03-15 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft- > lodderstedt-oauth-jwt-introspection-response-00.txt > Status: https://datatracker.ietf.org/doc/draft- > lodderstedt-oauth-jwt-introspection-response/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth- > jwt-introspection-response-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft- > lodderstedt-oauth-jwt-introspection-response > > > > Abstract: > This draft proposes an additional JSON Web Token (JWT) based response > for OAuth 2.0 Token Introspection. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > The information transmitted in the present email including the attachment > is intended only for the person to whom or entity to which it is addresse= d > and may contain confidential 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 the > intended recipient is prohibited. If you received this in error, please > contact the sender and delete all copies of the material. > > Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement joint= es sont > confidentiels et transmis =C3=A0 l'intention exclusive de son destinatair= e. > Toute modification, =C3=A9dition, utilisation ou diffusion par toute pers= onne 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 imm=C3=A9dia= tement > et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=A9ventuelleme= nt jointes. > _______________________________________________ > 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 > > --f403045e3bd09d59290567c26eaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Adding an additional proposal t= o the table. Mike Jones, Anders Rundgren and I have created a version of JW= S there the signed JSON data does not have to be Base64url encoded (the JSO= N is signed using ES6 serialization rules). One of the benefits to this app= roach would be that the introspection data is transferred in cleartext whil= e still fully protected. Since it is transferred in the response body and n= ot in a URL there is no need for the Base64url encoding.

=
The draft can be fond here

And = the example from your draft would look like this (the signature is not vali= d, I just copied it from another place)
{
=C2=A0 "sub": &qu= ot;Z5O3upPC88QrAjx00dis",
=C2=A0 "aud": "https://protected.example.net/resou= rce",
=C2=A0 "extension_field": "twenty-seven&qu= ot;,
=C2=A0 "scope": "read write dolphin",
=C2=A0= "iss": "https://ser= ver.example.com/",
=C2=A0 "active": true,
=C2=A0 &= quot;exp": 1419356238,
=C2=A0 "iat": 1419350238,
=C2= =A0 "client_id": "l238j323ds-23ij4",
=C2=A0 "us= ername": "jdoe"
=C2=A0 "__cleartext_signature":= {
=C2=A0=C2=A0=C2=A0 "alg": "ES256",
=C2=A0=C2= =A0=C2=A0 "kid": "example.com:p256",
=C2=A0= =C2=A0=C2=A0 "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmA= JktY_hpMsI
=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 AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHH= ZjsYdT96JZw"
=C2=A0 }
}



On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt <phil.hunt@or= acle.com> wrote:
+1.=C2=A0 This is = what I expected.

Phil

Oracle Corporation, Identity Cloud Services Architect
@ind= ependentid
phil.hunt@oracle.com
<= /div>

On Mar 19, 2018, at 10:16 AM, Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:

We explicitly want the token (JSON object) t= o be signed not the HTTP response. I think using JWS is the most generic wa= y to achieve that goal.

Am 19.03= .2018 um 09:57 schrieb Phil Hunt <phil.hunt@oracle.com>:

This draft has similar issues to=C2=A0= https://tools.ietf.org/html/draft-richer-oaut= h-signed-http-request-01

Rather than *try* sign= HTTP, a signed JWT object is more reliably returned.

Phil


On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis <Louis.LARMIGNAT@wavestone.co= m> wrote:

= Hi,
=C2=A0
The draft=C2=A0Signing HTTP Messages=C2=A0(https://tools.ietf.org/ht= ml/draft-cavage-http-signatures-09)=C2=A0could not meet this requireme= nt in a more generic way ?
=C2=A0
= Regards,
Louis<= /u>
=C2=A0<= /span>
De=C2=A0:=C2= =A0OAuth <oauth-bounces@ietf.or= g>=C2=A0= De la part de=C2=A0Brock Allen
Envoy=C3=A9=C2=A0:=C2=A0dimanche 18 = mars 2018 20:40
=C3=80=C2=A0:=C2=A0Torsten Lodderstedt <torsten@lodderstedt.net>;=C2=A0oauth@ietf.org
Objet=C2=A0:=C2=A0Re: [OAUTH-WG] Fwd: New Versi= on Notification for draft-lodderstedt-oauth-jwt-introspection-response= -00.txt
=C2= =A0
Why is TLS to the intospection endpoint not sufficient? Are you t= hinking there needs to be some multi-tenancy support of some kind?
=C2=A0
=C2=A0

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,
=C2= =A0
I just submitted a new draft that Vl= adimir Dzhuvinov and I have written. It proposes a JWT-based response type = for Token Introspection. The objective is to provide resource servers with = signed tokens in case they need cryptographic evidence that the AS created = the token (e.g. for liability).=C2=A0
=
=C2=A0
I will present the ne= w draft in the session on Wednesday.
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
kind regards,
Torsten.=C2=A0
=


Anfang der weitergeleiteten Nachricht:
=C2=A0
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Von:=C2=A0internet-drafts@ietf.org<= span style=3D"font-size:10pt;font-family:"Lucida Console"">
Betreff: New Version Notification for dra= ft-lodderstedt-oauth-jwt-introspection-response-00.txt=
Datum:=C2=A018. M=C3=A4rz 2018 um 20:19:37 MEZ=
An:=C2=A0"Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torst= en Lodderstedt" <torsten@lodde= rstedt.net>
=C2=A0=


A new version of I-D, dra= ft-lodderstedt-oauth-jwt-introspection-response-00.txt
has been suc= cessfully submitted by Torsten Lodderstedt and posted to the
IETF reposi= tory.

Name:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-lo= dderstedt-oauth-jwt-introspection-response
Revision:=C2=A000
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2= =A0JWT Response for OAuth Token Introspection
Document dat= e:=C2=A0=C2=A02018-03-1= 5
Group:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Individual Submission
= Pages:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
URL: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https:= //www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-i= ntrospection-response-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft= -lodderstedt-oauth-jwt-introspection-response/
Htmlized: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/= html/draft-lodderstedt-oauth-jwt-introspection-response-00
Html= ized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datat= racker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introsp= ection-response


Abstract:
=C2=A0=C2=A0This draft proposes= an additional JSON Web Token (JWT) based response
=C2=A0=C2=A0for OAuth= 2.0 Token Introspection.




Please note that it may take a= couple of minutes from the time of submission
until the htmlized versio= n and diff are available at=C2=A0tools.ietf.org.
=
The IETF Secretariat

<= /div>
=C2=A0
<= span style=3D"font-style:normal;font-variant-caps:normal;font-weight:normal= ;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none= ;white-space:normal;word-spacing:0px;font-family:tahoma;font-size:9px;color= :gray">The information transmitted in the present email including the attac= hment is intended only for the person to whom or entity to which it is addr= essed and may contain confidential and/or privileged material. Any review, = retransmission, dissemination or other use of, or taking of any action in r= eliance upon this information by persons or entities other than the intende= d recipient is prohibited. If you received this in error, please contact th= e sender and delete all copies of the material.=C2=A0

Ce message et toutes l= es pi=C3=A8ces qui y sont =C3=A9ventuellement jointes sont confidentiels et= transmis =C3=A0 l'intention exclusive de son destinataire. Toute modif= ication, =C3=A9dition, utilisation ou diffusion par toute personne ou entit= =C3=A9 autre que le destinataire est interdite. Si vous avez re=C3=A7u ce m= essage par erreur, nous vous remercions de nous en informer imm=C3=A9diatem= ent et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=A9ventuelle= ment jointes.=C2=A0____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth