From nobody Thu Aug 1 13:08:14 2019 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 6AA0E1201A1; Thu, 1 Aug 2019 13:08:12 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156469009236.19324.11429306390308195439@ietfa.amsl.com> Date: Thu, 01 Aug 2019 13:08:12 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 20:08:12 -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 : Reciprocal OAuth Author : Dick Hardt Filename : draft-ietf-oauth-reciprocal-04.txt Pages : 8 Date : 2019-08-01 Abstract: There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seamless experience for the user to grant access to a pair of protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-reciprocal-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 1 13:44:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781BA12022B for ; Thu, 1 Aug 2019 13:44:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d50pTmMmpJ7 for ; Thu, 1 Aug 2019 13:44:29 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119E41201BB for ; Thu, 1 Aug 2019 13:44:29 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id f17so64330409wme.2 for ; Thu, 01 Aug 2019 13:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EquOcKkggtw8hcRgdL4cGqqlVKGtIKp2raEh4WtjYQs=; b=RWYp/bg2N11YZ2SmrSsuZUmev9PxXIa2osv1R5HPVD0fNlP2RtZIO3Nh2iiHahmBg0 jI6kRWdFUxPRcvyLdyKoVo4qMxE0Mzm3hULnzWOhskUFXMMoTXZUxX5uslKcTAQpVIns 1AZSp5Vyu3MdszUHy5RZ0wupGODJe/ONRdKWKK8ladP5I64bXzynkDtVa1r5y0vOYx54 1ArWpMq1eFqjfUL411ffbekPLH3LQPxkyY0tvU+RBqsBEMlKbDynFnqlcVWfo86jNbNL WQHIUCjttqQEluxJyNfxnzf/2P2vc/QfBZC+isDHzzY2wp8fJ0JtnSWqwcTSQbCoRve2 JDlA== 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=EquOcKkggtw8hcRgdL4cGqqlVKGtIKp2raEh4WtjYQs=; b=G7qLOOkDhbeGg42VOG3mw/5oVuUrnQBuGTTI5SJX64WBTEdiGGzXyae6tzwl9y7i79 eaXlFGG06giXms1fHPh3OJgm0+J9TnlpUTAE/yrer5fBGa1rKDLuT0mUUIdHOGuQiuEz 4zJ62tZ8S52T0p9SPDOHDgEF9zPZfoQ1zDgxBcjWbGrunMGl8++v+bx8DP4/C083RuhE mB4OQZ2CkdUwds3aaALSPet3QtmSyILWobz3ZtoFekyKGAuat0Rd9l97Bc2nkcgUSTqB rE1imM0JvoTrzD0hbZcC523PIxwJEH0B/SPaoyOp/9Grj9JNm2jSpooHcx9iBDrdM5T1 zo4Q== X-Gm-Message-State: APjAAAVE9srlz8AKFQgt/AChYC/VUOKrUycaiRkNt07g310yLwdBWt4+ dY7ZTE+ia5zNV0jUxqscem12D6J2pDZS4Ig1s2A= X-Google-Smtp-Source: APXvYqx7xeTtERz2wWCZUraeIv4oaqyHuWKdjH9UrKTitZ5ntqqJRhDco8K4LrBbCB1ueHRWKoyUoZegLt8rp7lWbUo= X-Received: by 2002:a05:600c:204c:: with SMTP id p12mr388364wmg.121.1564692267448; Thu, 01 Aug 2019 13:44:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sascha Preibisch Date: Thu, 1 Aug 2019 13:43:37 -0700 Message-ID: To: Daniel Fett Cc: IETF oauth WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 20:44:32 -0000 Hi all! I am reading through the latest draft ( ... dpop-02). When I got to the first example request (bullet 5.) I saw that only 'grant_type, code, redirect_uri' are used. If I am not mistaken the recommendation is to generally use PKCE with an authorization_code flow. Therefore, I wondered if the example should also include a 'code_verifier'. Thanks, Sascha On Mon, 8 Jul 2019 at 06:30, Daniel Fett wrote: > > All, > > In preparation for the meeting in Montreal, I just uploaded a new version of the DPoP draft: > https://tools.ietf.org/html/draft-fett-oauth-dpop-02 > > Please have a look and let me know what you think. We should make this a working group item soon. > > As you might have noticed, there is also a new version of the Security Best Current Practice draft: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > -Daniel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Aug 5 04:02:22 2019 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 BE28D12017E; Mon, 5 Aug 2019 04:02:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shwetha Bhandari via Datatracker To: Cc: draft-ietf-oauth-resource-indicators.all@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Shwetha Bhandari Message-ID: <156500293964.24423.8625379330723423979@ietfa.amsl.com> Date: Mon, 05 Aug 2019 04:02:19 -0700 Archived-At: Subject: [OAUTH-WG] Opsdir last call review of draft-ietf-oauth-resource-indicators-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 11:02:20 -0000 Reviewer: Shwetha Bhandari Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document extends OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server : 1. In Authorization Request: the identity of the protected resource to which it is requesting access and 2. In Access Token Request: where it intends to use the access token it is requesting The document is well written and meets the Operations and Management Review Checklist - https://tools.ietf.org/html/rfc5706#appendix-A. The proposed extension does not have a significant operational impact on the network. From nobody Mon Aug 5 14:23:11 2019 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 B8F8E120091; Mon, 5 Aug 2019 14:22:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-oauth-jwt-introspection-response.all@ietf.org, ietf@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <156504017769.2046.13239300457018910370@ietfa.amsl.com> Date: Mon, 05 Aug 2019 14:22:57 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 21:22:58 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-jwt-introspection-response-05 Reviewer: Linda Dunbar Review Date: 2019-08-05 IETF LC End Date: 2019-08-07 IESG Telechat date: Not scheduled for a telechat Summary: This draft specifies an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection, specify the signed JWT and signed & encrypted JWT response. The document has very thorough analysis from many aspects in the security consideration section. Major issues: None Minor issues: None Nits/editorial comments: From nobody Tue Aug 6 05:19:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49B112013E for ; Tue, 6 Aug 2019 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACRkhluZMehQ for ; Tue, 6 Aug 2019 05:19:55 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6410120137 for ; Tue, 6 Aug 2019 05:19:54 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id v15so82135314eds.9 for ; Tue, 06 Aug 2019 05:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=mA5u0YoV7SmJU5DpIayePHYT2j9AoKtXzkSr6jztC4Q=; b=RuC3BQEfVyZRDN1/bwdG+7Hi1aiSSPKL6y/BxUjzWeozWrVJy6HdnYEnwGM49r+7oE s44/4uVLrbI6DchAjaG2l/Zr0RZdZ7QPyJz0hnc+xIKXGRF7OTClBu27FrWbsreZYArP JufGgOUO7jF/g2Q4+85PI6VnVASGQ6e4NvsT0hi6sMVd1IP25VEM8Tb07EeFQlMW07Du GHwVYaA/CUvNWKQ1XiDwAJu8NaKEMvFmkXHDSYPG23C2U+TmSxv+/O5TCQJKjOjuig3p 2Y/9XsA8Sb2NZRBLCYZpMJK5xdPb/vpp8PVNQD2cURgOWHo/VqjpH8bpbTD0mzCXBNDW h7gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mA5u0YoV7SmJU5DpIayePHYT2j9AoKtXzkSr6jztC4Q=; b=Ea2Y/Xh5jV3rFbF4a9n/Tn6s9NVQhuZCNXe3AeeN5hZQBJvPtb6tzlLoVq9SVxyq9b y8fvFImkmHmqIDjrrMW535VtQv0626cVXBUlnbh4IjLd15ztDtGz3wQ8Soz3SoeWKi57 9d2uUWB74RKyAiUdWbXo6Ass3AlSA/9ee+ia0eGvaieWVyNIbENgm27xRjXry6MCnLxk dDxrR95urZjAFpjrLxH1BIdMkBKHbFpHDvWSanDt9YMywbv2pV64Eka7phvLhwplbdfr /Qg7Ec2/O2cccN9H5HKoATukfjn23hqdam1mGUrO+QQ/H3DQkx6UOmF+m3eATR7MrlsC +2EA== X-Gm-Message-State: APjAAAV3Xphn3V7AG0uLFsmG1A+VjqOqKHtzEPEMYmmkOnbmZ8f1NwXY LMniV4XSQwbLFMDmvtvEkH5MP1av2XU= X-Google-Smtp-Source: APXvYqxJkIbsaG0gX5exM7yY1U7QqO2wdFKeeugnyE1i0Bo+V0MtGklhi8QxbUp+/hBOy3zC9/BZyg== X-Received: by 2002:a17:906:580b:: with SMTP id m11mr2932243ejq.0.1565093992402; Tue, 06 Aug 2019 05:19:52 -0700 (PDT) Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id h10sm20729538ede.93.2019.08.06.05.19.50 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 05:19:51 -0700 (PDT) From: Emond Papegaaij To: oauth@ietf.org Date: Tue, 06 Aug 2019 14:19:50 +0200 Message-ID: <3495798.29O3mTMRrG@papegaaij> In-Reply-To: References: <156401017666.14534.9422325088242867919@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 12:19:57 -0000 Hi all, After my vacation I've finally found time read up on the new BCP draft for browser based apps. First of all, thanks for the great work on this spec. I think this is a very important area to work on, as browser based applications are getting more and more common. Here's my feedback: 6.1. Apps Served from a Common Domain as the Resource Server This section has seen quite some comments, but IMHO one important aspect has not been emphasized enough: using an HTTP-only cookie to secure an API can make it very vulnerable to CSRF attacks. This was already mentioned by David Waite, but has not seen any response. Storing the access token (or session id, or whatever it is called when stored in a cookie) in an HTTP-only cookie will make it hard to steal, but also hard to protect from misuse. Any page can embed links to your API, and the browser will simply send the cookie. 'Traditional', server based, web applications require special protection against these kinds of attacks, but RESTful APIs often don't have such protection. IMHO advising to use a cookie to secure your API is therefore a dangerous advice. 8. Refresh Tokens This section also has seen a lot of comments. Why all this focus on the refresh token? All the attack vectors apply to the access token as well. If tokens cannot be stored securely in a browser based application, the authorization server should not issue any token at all. Leaking a single valid access token is likely to be more than enough for an attacker to get all the information he/she needs, even if it is only valid for a couple of minutes. Also, when an attacker manages to get an access token once, it is likely he/ she will succeed a second time (i.e. via an XSS attack). Placing these restrictions on refresh tokens, without addressing the access token seems senseless to me. I think this section should be about the lifetime of the authorization and detecting potential leaks of tokens. For a browser based application, I see no use at all for offline tokens. Without the browser, there is no application. Therefore the access should be scoped to the browser session, and this is IMHO best checked by the authorization server. At Topicus, we plan to implement this with short lived access tokens and performing re-authentication in a hidden iframe with prompt=none. The disadvantage of this is that is requires OIDC for the prompt parameter. In this setup we do not need refresh tokens, but other solutions may also apply. Shouldn't this BCP give actual recommendations on how to manage this (preferably without full page redirections, because those destroy the state of a SPA), rather than simply forbidding refresh tokens? 9.7. Content-Security Policy A very important measure to secure your browser based application is a strong CSP, but it is also very hard to do correctly. The current advise is a bit broad. I think it should explicitly state the policies that should NOT be allowed (inline scripting, eval). This was already mentioned by Dominick Baier. Also, it could benefit from a few examples (correct and wrong). Best regards, Emond Papegaaij Topicus KeyHub From nobody Wed Aug 7 09:10:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7D412012D for ; Wed, 7 Aug 2019 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He_LaHDOgpLN for ; Wed, 7 Aug 2019 09:10:03 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 0FA72120483 for ; Wed, 7 Aug 2019 09:10:01 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id r9so86002046ljg.5 for ; Wed, 07 Aug 2019 09:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gn2Aj14u/UgMtkNxJkSbN7PGYyiNcfg3sAxTWPnU2y8=; b=ZrSmeNsdaM1cjB3riG+6MvXCENJzfyxSv3n6B69V37dJmQNckF7wux4WKFl8G1ry0R 3M0k7xsX0WBXu6nNEtYmXq93Nrs7b0wn/6oZ2N6VIyQ1nsRNB2+1i6mu1X9myliH/7Mt 6VZoH2mOjYrIRTGLOaghUaCCPRCQGI70QEUuR6g2/dERcDbQTxnI7SsVAZp7CWUQG1z7 3t0KjKPIGHFaKCL4AmEXcQZcYXd+7r3CwPB/+GHB9GC0kfj25CvytibiCuU/1eJ24NIW A7lcdxhWwSgbMmtU9W8GR1BfaK6FsNvtTU7/iGtgSvPzTmKoa8Z9qBzAlChM4BeDc3Oc 2RlQ== 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=gn2Aj14u/UgMtkNxJkSbN7PGYyiNcfg3sAxTWPnU2y8=; b=mvjjhP0sEOXbEyke18tbfwCjnmffXTlfzk8g1ZsXDG479eoJjXiSUXM/OOooG7RH2y SCs3J2zUYwKRr499oaKtSlPGfhCIH2bkSzdJ7lQKuHboiE7OlXJfqGizmsFDO1C0+KDJ HkjiSsH48Y7GFxtYgGgl/xvt8hczNo7prt/6GdqAhdNDbyL5Bgq2PRpZt9CE83fXsdtC O5Fh837iPsug0akEEOhk8QmL8cMnjf+fZu0zWoxPqvTc2mgxhU4PR6V2tXO/6GE8gU2/ VYyT1brFufZnCOjiidzUs/UQFTpGe3vFOIB/UfKu9FcTc4S7TmU0lrcJujfefKbGqwzQ 83Fw== X-Gm-Message-State: APjAAAU5xDifvxexYZye6IGLuWcHMyXtpcqkEkv5AHPbJ3Vdsvuf3cBg RfGniyviX7zur4UIeh5Rf7IXDgtPbkGXdyHT20c= X-Google-Smtp-Source: APXvYqyKhVIAcLpmERIwhSwmlcK1UlYDemadqz4tIJ+tPV+Vh5mixORc+AC5GNx9/ZF4r4RrXU9L9Xp0JWWkJkeMbBY= X-Received: by 2002:a2e:2b9d:: with SMTP id r29mr5336107ljr.181.1565194199090; Wed, 07 Aug 2019 09:09:59 -0700 (PDT) MIME-Version: 1.0 References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> In-Reply-To: From: Dick Hardt Date: Wed, 7 Aug 2019 09:09:47 -0700 Message-ID: To: Dominick Baier Cc: Aaron Parecki , Mike Jones , Daniel Fett , OAuth WG Content-Type: multipart/alternative; boundary="0000000000003dccba058f892c63" Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:10:08 -0000 --0000000000003dccba058f892c63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are we ready to pick a date? On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier wrote: > August will conflict with holiday time for most Europeans=E2=80=A6 > > Just been to Trondheim last week - it was lovely weather. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick > > On 25. July 2019 at 22:14:28, Mike Jones ( > michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote: > > I'm not aware of any conflicts for any of the three sets of dates. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Aaron Parecki > Sent: Thursday, July 25, 2019 4:07 PM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security > Workshop > > We'll be so productive with only 4 hours of darkness every day! > > All of the dates work for me, but I would prefer the July dates since > it'll be easier/cheaper to bundle the two trips into one. (Hopefully we > could get the OAuth meeting dates early in the week at IETF then) > > On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt wrote: > > > > +1 to July / August. Nicer weather in the north then. =3D) > > > > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett > wrote: > >> > >> Hi all, > >> > >> it seems like there is a rough consensus on having the next OAuth > Security Workshop in Trondheim, Norway. We will therefore start with the > planning. > >> > >> After checking various event calendars it seems like the following > dates are suitable: > >> > >> May 7-9 > >> > >> July 22-24 > >> > >> August 3-5 > >> > >> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/Germ= any. The > latter two dates are before/after IETF 108 which is July 25-31, > Madrid/Spain. > >> > >> Unless somebody raises objections because of conflicting > identity/security events we will pick one of these dates in the next two > weeks or so. > >> > >> -Daniel > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w > >> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jo= n > >> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 > >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwG= W > >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jone= s > > %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af > > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRX= y > > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40m= icrosoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd= 011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXc= MD482nhyARt28me4xbE%3D&reserved=3D0 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000003dccba058f892c63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 = PM Dominick Baier <dbaier@l= eastprivilege.com> wrote:
August will conflict with holiday time for most Europeans=E2=80=A6

Just been to Trondheim= last week - it was lovely weather.

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

On 25. July = 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsoft.com@dmar= c.ietf.org) wrote:

I'm not aware of any= conflicts for any of the three sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Work= shop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since i= t'll be easier/cheaper to bundle the two trips into one. (Hopefully we = could get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> w= rote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OA= uth Security Workshop in Trondheim, Norway. We will therefore start with th= e planning.
>>
>> After checking various event calendars it seems like the follo= wing dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Mun= ich/Germany. The latter two dates are before/after IETF 108 which is July 2= 5-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting ident= ity/security events we will pick one of these dates in the next two weeks o= r so.
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf= .org
>> https://nam06.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org%2F= mailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40micr= osoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata= =3DdAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://nam06.safelinks.protection.outl= ook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailm= an%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones
> %40microsoft.= com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAok= WYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichae= l.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141= af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWS= RXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
_______________________________________________
OAuth mailing listOAuth@ietf.org= https://www.ietf.org/mailman/listinfo/oauth
--0000000000003dccba058f892c63-- From prvs=114f83850=remco.schaar@logius.nl Tue Aug 6 07:02:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45B1120172 for ; Tue, 6 Aug 2019 07:02:05 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=logius.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLM5zLizQyfh for ; Tue, 6 Aug 2019 07:02:03 -0700 (PDT) Received: from mail2.ssonet.nl (mail2.ssonet.nl [147.181.98.131]) (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 ECA80120072 for ; Tue, 6 Aug 2019 07:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=logius.nl; i=@logius.nl; q=dns/txt; s=Selector2; t=1565100123; x=1596636123; h=from:to:subject:date:message-id:mime-version; bh=ZbmNhmK0t0jZBdZrs++oIf1dunmKQoz5nKrL5/K3jNc=; b=qY2i96P9o+0UskAuJzBwCBcfbf3mhSlcca47yLcZqvP5ps53N0xIeFy7 PRlkpVUc+rMDRVBgpkG7Q2RoOYVFT6VWJbjFhn928GIcXiufLhgB9NY0v Qp48ltCiR7eZCs3hIFXymxWlCmc0mDw/ROkBFVKsIkOrHiMLSxqRCFEqr 9mD1lHc4HoumjVWDbZ4mfje6Yzr8WOn/+lWj5n52FzvkHkhN8tfjdBweI VfhaaSI+2Xp/e4Ouj/nzJSJBtj8unCY2KrJ9XJQgJLAXsivcKLtL2og15 mSYJv8TE740IwC77bI6wOzqmh0gYz7cTWTmX37GQ1MQEgAJAXdPkxYoJw Q==; IronPort-SDR: cOOCL/pQosT/ime++c8Bf/2s17lM6JLvvu5a+5w1RQEkSgyZwjR1EjZw7UJZ/SjyR7xSNDTo45 qXhWKx7FKFWA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EcAAC+h0ld/8HfK5BmGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVQQBAQELAYEVL1NtchI0mSGPS4YFgXsJAQEBDhMaAgEBhwAjNgc?= =?us-ascii?q?NAQEEAQEBAQMBAQEBBQEBAQJphGVOgjoigyNFGQEVayYBBBuDG4EdbQGtORq?= =?us-ascii?q?KJ4E0AYRxhACEST6PCASMDC2HU5ccBwICghwDhXmGCYgUI41aA4pPjUmVOoJ?= =?us-ascii?q?ggVcDL4FYfIMxkQVBgVqMCgGBIAEB?= X-IPAS-Result: =?us-ascii?q?A2EcAAC+h0ld/8HfK5BmGwEBAQEDAQEBBwMBAQGBVQQBA?= =?us-ascii?q?QELAYEVL1NtchI0mSGPS4YFgXsJAQEBDhMaAgEBhwAjNgcNAQEEAQEBAQMBA?= =?us-ascii?q?QEBBQEBAQJphGVOgjoigyNFGQEVayYBBBuDG4EdbQGtORqKJ4E0AYRxhACES?= =?us-ascii?q?T6PCASMDC2HU5ccBwICghwDhXmGCYgUI41aA4pPjUmVOoJggVcDL4FYfIMxk?= =?us-ascii?q?QVBgVqMCgGBIAEB?= X-IronPort-AV: E=McAfee;i="6000,8403,9340"; a="12024036" X-IronPort-AV: E=Sophos; i="5.64,353,1559512800"; d="scan'208,217"; a="12024036" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False From: "Schaar, R.M. (Remco) - Logius" To: "'oauth@ietf.org'" Thread-Topic: Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AdVMX0zd8VJvxu//SVaPc8ibBp8OiQ== Date: Tue, 6 Aug 2019 14:01:59 +0000 Message-ID: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [144.43.223.38] Content-Type: multipart/alternative; boundary="_000_38503cd44d9e455bad4432d9ba5e82e8SV1601507frdshsdirnl_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 07 Aug 2019 13:09:48 -0700 Subject: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 14:03:22 -0000 --_000_38503cd44d9e455bad4432d9ba5e82e8SV1601507frdshsdirnl_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, I would like to request the OAuth2 working group on a clarification for int= rospection, in particular regarding the semantics of the 'jti' and 'aud' cl= aims. The draft 'JWT Response for OAuth Token Introspection' seems ambiguou= s in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 caus= e this ambiguity. RFC7662 specifies the 'aud' and 'jti' parameters in relation to "for the to= ken". Note that the wording in RFC7662 is somewhat implicit, we assume "the= token" is the (access) token being introspected. RFC7519 specifies the 'aud' and 'jti' parameters in relation to the JWT its= elf. The token in the context of RFC7519 is the JWT containing the paramete= rs. The draft (draft-ietf-oauth-jwt-introspection-response-05) now formulates t= he response to an introspection as a JWT. The content of the JWT "MAY furth= ermore contain all claims defined in RFC7662". Now this raises the question= to the meaning of the 'aud' and 'jti' parameters. In line with RFC7519 the parameters would define a value for the introspect= ion response. On the other hand following RFC7662 for the definition would = define the value of the parameters as those of the introspected token. Now for the 'aud' parameter this will typically only be an issue with multi= ple values for the audience. In the case of a single intended audience the = audience of the introspected (access) token will normally be the same princ= ipal as the audience of the introspection response JWT. Only for some use c= ases the value of 'aud' may end up ambiguous. The 'jti' parameter however will always be ambiguous. As it is an identifie= r, it should differ for the introspected token and the introspection respon= se by definition. Hence the semantics of 'jti' in a JWT introspection respo= nse is unclear. The same can apply to the 'iat', 'nbf' and 'exp' claims in = a JWT introspection response. Can someone clarify the semantics of claims in an introspection response JW= T that are defined in both RFC7662 and RFC7519? Furthermore, the introspection response should use the 'iss' and 'aud' clai= ms to avoid cross-JWT confusion (section 6.1). The 'iss' and 'aud' of an in= trospected token will typically be the same as those of the introspection r= esponse. Hence a JWT access token cannot be distinguished from an introspec= tion response using 'iss' and 'aud' as suggested in the draft. Introspection refers to JWT best-current-practice. The draft BCP recommends= using explicit typing of JWTs, however the draft JWT response for introspe= ction does not apply this recommendation and uses the generic 'application/= jwt' instead... The BCP has other recommendations in section 3.12, but thes= e may be insufficient to distinguish a JWT access token from a JWT introspe= ction response. How would people suggest to best distinguish a JWT (access) token from a JW= T introspection response? Thank you in advance for your response. Kind regards, Remco Schaar Logius Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard oo= k, die verband houdt met risico's verbonden aan het elektronisch verzenden = van berichten. This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. The State accepts n= o liability for damage of any kind resulting from the risks inherent in the= electronic transmission of messages. --_000_38503cd44d9e455bad4432d9ba5e82e8SV1601507frdshsdirnl_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hello,

 

I would like to request the OAuth2 wo= rking group on a clarification for introspection, in particular regarding t= he semantics of the ‘jti’ and ‘aud’ claims. The draft ‘JWT Response for OAuth Token Introspection’ seems ambig= uous in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 c= ause this ambiguity.

 

RFC7662 specifies the ‘aud̵= 7; and ‘jti’ parameters in relation to “for the tokenR= 21;. Note that the wording in RFC7662 is somewhat implicit, we assume ̶= 0;the token” is the (access) token being introspected.

RFC7519 specifies the ‘aud̵= 7; and ‘jti’ parameters in relation to the JWT itself. The toke= n in the context of RFC7519 is the JWT containing the parameters.

 

The draft (draft-ietf-oauth-jwt-intro= spection-response-05) now formulates the response to an introspection as a = JWT. The content of the JWT “MAY furthermore contain all claims defined in RFC7662”. Now this raises the question to the = meaning of the ‘aud’ and ‘jti’ parameters.

 

In line with RFC7519 the parameters w= ould define a value for the introspection response. On the other hand follo= wing RFC7662 for the definition would define the value of the parameters as those of the introspected token.

 

Now for the ‘aud’ paramet= er this will typically only be an issue with multiple values for the audien= ce. In the case of a single intended audience the audience of the introspected (access) token will normally be the same principal as the= audience of the introspection response JWT. Only for some use cases the va= lue of ’aud’ may end up ambiguous.

The ‘jti’ parameter howev= er will always be ambiguous. As it is an identifier, it should differ for t= he introspected token and the introspection response by definition. Hence the semantics of ‘jti’ in a JWT introspection response i= s unclear. The same can apply to the ‘iat’, ‘nbf’ a= nd ‘exp’ claims in a JWT introspection response.

 

Can someone clarify the semantics of = claims in an introspection response JWT that are defined in both RFC7662 an= d RFC7519?

 

Furthermore, the introspection respon= se should use the ‘iss’ and ‘aud’ claims to avoid c= ross-JWT confusion (section 6.1). The ‘iss’ and ‘aud̵= 7; of an introspected token will typically be the same as those of the introspection response. H= ence a JWT access token cannot be distinguished from an introspection respo= nse using ‘iss’ and ‘aud’ as suggested in the draft= .

 

Introspection refers to JWT best-curr= ent-practice. The draft BCP recommends using explicit typing of JWTs, howev= er the draft JWT response for introspection does not apply this recommendation and uses the generic ‘application/jwt&= #8217; instead... The BCP has other recommendations in section 3.12, but th= ese may be insufficient to distinguish a JWT access token from a JWT intros= pection response.

 

How would people suggest to best dist= inguish a JWT (access) token from a JWT introspection response?<= /span>

 

Thank you in advance for your respons= e.

 

Kind regards,

Remco Schaar

Logius


Dit bericht kan informatie bevatte= n die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit be= richt abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzend= er te melden en het bericht te verwijderen. De Staat aanvaardt geen aanspra= kelijkheid voor schade, van welke aard ook, die verband houdt met risico's = verbonden aan het elektronisch verzenden van berichten.
This message may= contain information that is not intended for you. If you are not the addre= ssee or if this message was sent to you by mistake, you are requested to in= form the sender and delete the message. The State accepts no liability for = damage of any kind resulting from the risks inherent in the electronic tran= smission of messages.
--_000_38503cd44d9e455bad4432d9ba5e82e8SV1601507frdshsdirnl_-- From nobody Wed Aug 7 23:48:01 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7D11200F9 for ; Wed, 7 Aug 2019 23:47:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 72nUmqWc8PDt for ; Wed, 7 Aug 2019 23:47:57 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 E09781200DB for ; Wed, 7 Aug 2019 23:47:54 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id s49so54582114edb.1 for ; Wed, 07 Aug 2019 23:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=BYuG6imcEHkrtzi7ZdNl0iVjHQK60cL6WsprzHFjggU=; b=DmIPj17XxfnUgk7ulYhtQMo1DsZAu4VJ21ekJrKB/n3hcfSBmQ8SdVUR1CpDe4tC2d krzoxV9k3MHlf1SU+BH6jtfCLNunP0G/2+dqH0e8oKT/Voyrii8nX4s2WO0tVHXb+rq1 i/+bb+53PP+ZvzPnL6vUP9tOspHqxps8/uraXWuOPxhubVZqBngSnU4KMIeLeftIdoko TOxkfGk/TR2daJMbGPyDyBVpVSU9YHRly2e9uevHEVQdRADAA1wG4YTcdqbgaB+MBf5/ UMvYtMOi70mWhA21WTyQEMPNncvdq4o6dOg/n+/wIZqtLT4RQVIlkQmfaj0un4kI38SC kx7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=BYuG6imcEHkrtzi7ZdNl0iVjHQK60cL6WsprzHFjggU=; b=Z2+yoS9MHp3eE/PdSCERRW87E9F8sacU5/OiVfSMunUMcpStRoT+EOW6NHsjVIKe+9 NpK1wA+8WjeEqbRd6v5KJwUVLZ3LwutdBCjG6LbP2p42+kVKbwpxkS11pVLGHFNQRAjk wVgxwRYvfYO9NLXRKq8FpLYoQS8l2tGPkaKSt3sTHYX6tEOoN/PWdkSpT2XgNyiSara8 XID/IC1+4Z1PTkV2cvD9Cz+mfeO3Do8hRGlQXOVYmuCwuw1ObduiJNh4wAdJga1266bQ E3+QE3SVyE65omL81KsYjAFQjSf1wEUPILp6Ky3hV7QWCZincyTahNokR6AOJT9lYLNC ZsNw== X-Gm-Message-State: APjAAAWhrTlEFKZpnDMlh+w63+hZeRSUCbp6BSU+PQpHdOg8XQOK0jX+ ujSiloFsw8JdxH39iNs/dSlQrGDJUNpuqw== X-Google-Smtp-Source: APXvYqxHQh5iXv18QnDG83g6s0xlKOAsFE3m5I6Zf0VPLSU1q+DIapCI2Dz9xAdfVsbdR9Qzzw5Pig== X-Received: by 2002:a50:d0d6:: with SMTP id g22mr14252096edf.250.1565246873105; Wed, 07 Aug 2019 23:47:53 -0700 (PDT) Received: from ?IPv6:2001:16b8:1caf:3f00:fd09:26ac:9d7f:277f? ([2001:16b8:1caf:3f00:fd09:26ac:9d7f:277f]) by smtp.gmail.com with ESMTPSA id a9sm21816064edc.44.2019.08.07.23.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 23:47:52 -0700 (PDT) To: Dick Hardt , Dominick Baier Cc: Aaron Parecki , Mike Jones , OAuth WG References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> From: Daniel Fett Message-ID: <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> Date: Thu, 8 Aug 2019 08:47:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D975C955CE06FA539CD891A2" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 06:48:00 -0000 This is a multi-part message in MIME format. --------------D975C955CE06FA539CD891A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Not yet, we are talking to potential venues. It's vacation time in Norway right now, so that will take a week or two more. -Daniel Am 07.08.19 um 18:09 schrieb Dick Hardt: > Are we ready to pick a date? > > On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier > > wrote: > > August will conflict with holiday time for most Europeans… > > Just been to Trondheim last week - it was lovely weather. > > ——— > Dominick > > On 25. July 2019 at 22:14:28, Mike Jones > (michael.jones=40microsoft.com@dmarc.ietf.org > ) wrote: > >> I'm not aware of any conflicts for any of the three sets of dates. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth > > On Behalf Of Aaron Parecki >> Sent: Thursday, July 25, 2019 4:07 PM >> To: Dick Hardt > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Location and dates for next OAuth >> Security Workshop >> >> We'll be so productive with only 4 hours of darkness every day! >> >> All of the dates work for me, but I would prefer the July dates >> since it'll be easier/cheaper to bundle the two trips into one. >> (Hopefully we could get the OAuth meeting dates early in the week >> at IETF then) >> >> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt > > wrote: >> > >> > +1 to July / August. Nicer weather in the north then. =) >> > >> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett >> > wrote: >> >> >> >> Hi all, >> >> >> >> it seems like there is a rough consensus on having the next >> OAuth Security Workshop in Trondheim, Norway. We will therefore >> start with the planning. >> >> >> >> After checking various event calendars it seems like the >> following dates are suitable: >> >> >> >> May 7-9 >> >> >> >> July 22-24 >> >> >> >> August 3-5 >> >> >> >> First date is before EIC ‘20 which is May 12-15 in >> Munich/Germany. The latter two dates are before/after IETF 108 >> which is July 25-31, Madrid/Spain. >> >> >> >> Unless somebody raises objections because of conflicting >> identity/security events we will pick one of these dates in the >> next two weeks or so. >> >> >> >> -Daniel >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> >> >> .ietf.org >> %2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon >> >> >> es%40microsoft.com >> %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >> >> >> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW >> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> >> > ietf.org >> %2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones >> >> > %40microsoft.com >> %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af >> >> > >> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy >> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------D975C955CE06FA539CD891A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Not yet, we are talking to potential venues. It's vacation time in Norway right now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
August will conflict with holiday time for most Europeans…

Just been to Trondheim last week - it was lovely weather.

———
Dominick

On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=40microsoft.com@dmarc.ietf.org) wrote:

I'm not aware of any conflicts for any of the three sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll be easier/cheaper to bundle the two trips into one. (Hopefully we could get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Security Workshop in Trondheim, Norway. We will therefore start with the planning.
>>
>> After checking various event calendars it seems like the following dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/security events we will pick one of these dates in the next two weeks or so.
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones
> %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------D975C955CE06FA539CD891A2-- From nobody Thu Aug 8 05:42:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25967120077 for ; Thu, 8 Aug 2019 05:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=unavailable 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 6GOwOS4FQxhb for ; Thu, 8 Aug 2019 05:42:14 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640136.outbound.protection.outlook.com [40.107.64.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAD9120046 for ; Thu, 8 Aug 2019 05:42:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q130gpmBurLdAR+09BzTFn6JHFS1zczbyla1uK55ohUbpUpRrsXdqSCHzPyQb3WZ4jHKsO2lUmfCZXbaLA9/bupkMk6xTsnEUrovnsAd7MfuOSp09fBx0Owd738y4Mw5j0CgQpb0INneJ86fDnoO8Jal1RdJCt0GbYysWOwSIoskv7rHx20CkQFbesxrcoJRNK9dydrzwR4OQH5RliCCH6CCzvN/7xs2lVRlt4pyIHHVPXdf3+/M3dwz5GbcSkBeCSU80wkQEPMWFfDiVpv1VNywKzmcNl4ytnKllIJxskpUdUvfNazSfIhkN/ls77eYbLXgZQK19LrBezBKfw9sFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d+T9h6KmaKhZq8lFYdZZNfX5caSWY/4DmvZP0E0GB2I=; b=R8sqldnwSN6CZH/rLc9D8FAj4U2whH+MI1tPFubLP4LGUA+VllnsSkc2Diud0YC8CUlMEMgdLDIWKb3yNFGExZQTG1Dw+/wd7wzfqp9HYUz17ixy8a1Di4i8lEACApv/z14BfGBFbq5LwlFB4ecTgGJG93lODH8daeRzUEatGQ5KEYIdXj+X5XgDs5JXrEM/cPUX4MOhQ7u1KgTCGe7Vw+Ny31p/+lNabc4Z2Ji31/8MR1R5cyIGMcix9Dhp6k3KC8Pumf1O29YaG9FYBjfrjwhqYhxkj2WJAxV/uDoNy1Xs8j/jGmTOIrVai0tohAqDaVxxtqeWl1KEWPgQiWb6HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d+T9h6KmaKhZq8lFYdZZNfX5caSWY/4DmvZP0E0GB2I=; b=C59oAGTSpj5n1Wf83yUiZ5cxi7Q1PzRSAYnwdGhmR/16jR4ygX6TWGmq86efMNadC1w7q0oCiRnDiWtPYKL3pX0vD5mi8zf99LaZdHTQSySXq5FQgmjwN32ByQ/xkic1Kue0t0URqXVmGGupExV2zj1AF3CkhYu8ooioOUlNunM= Received: from CO2PR00MB0085.namprd00.prod.outlook.com (10.166.215.143) by CO2PR00MB0119.namprd00.prod.outlook.com (10.166.215.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2196.0; Thu, 8 Aug 2019 12:42:10 +0000 Received: from CO2PR00MB0085.namprd00.prod.outlook.com ([fe80::1836:4d7c:61a9:8dc1]) by CO2PR00MB0085.namprd00.prod.outlook.com ([fe80::1836:4d7c:61a9:8dc1%14]) with mapi id 15.20.2195.000; Thu, 8 Aug 2019 12:42:10 +0000 From: Anthony Nadalin To: Daniel Fett , Dick Hardt , "dbaier@leastprivilege.com" CC: Mike Jones , OAuth WG Thread-Topic: [OAUTH-WG] Location and dates for next OAuth Security Workshop Thread-Index: AQHVQxqsq2lN3BMOX0W1/ljKGHD73qbbummAgAAIf4CAAAHogIAArDMAgBN92ICAAPVUgIAAYmKI Date: Thu, 8 Aug 2019 12:42:10 +0000 Message-ID: References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> , <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> 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_SetDate=2019-08-08T12:39:58.3235846Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [107.77.205.210] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbef9fd3-8fdc-48e7-6a49-08d71bfdd4c3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:CO2PR00MB0119; x-ms-traffictypediagnostic: CO2PR00MB0119: x-ms-exchange-purlcount: 4 x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:473; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(189003)(13464003)(199004)(53754006)(256004)(4326008)(71200400001)(486006)(53936002)(14454004)(66066001)(236005)(6246003)(966005)(53386004)(76116006)(5660300002)(64756008)(66446008)(66946007)(66476007)(7110500001)(2906002)(2501003)(478600001)(33656002)(25786009)(99286004)(2420400007)(10290500003)(15650500001)(52536014)(9686003)(81166006)(86362001)(81156014)(26005)(316002)(102836004)(74316002)(22452003)(7696005)(186003)(8676002)(8936002)(110136005)(8990500004)(76176011)(10090500001)(66556008)(53546011)(14444005)(6506007)(7736002)(71190400001)(229853002)(606006)(3846002)(446003)(476003)(11346002)(54896002)(6436002)(6116002)(55016002)(5070765005)(54906003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0119; H:CO2PR00MB0085.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rP45hxl64rEhjRPmUSzMzF10mbVowGCvM7RdoD6ea2m/E1ABYKUtVsNneaGYrd9kcIpET+4AypTd2yUPwyyAtSUlslRjoKOuXaPNWYnr2nnDa8T84PGLyh0jADLGW6T7n10RzsjVF+ss6eLZuKIyhclUHvEML94m1ZJ4FcDfg4DvUrsmLvsxxCBcGN5ta5UH2RPtTbg7PRnXyxZpHr5hE5Qr5FDW1rbU4mFTxdTesZWLHiwLN8LcHeDxGnOHKe66ss4N9dD3BAvC3kA4geu7cV5jEzB4JkNpFkm7zzHAco4/GjssMpdc41I5KflHYzzPVh5pjRCQm/d0pNnE+By8oD09XtqJ39GUlANJrhlC39T7qkoFCe0kN08dh/sUvz0388V3Be/2RRWRrHsro49DyGhXRoCyXlhflnX1bUew1fg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO2PR00MB00856B37BD4BB02B5F42ADDCA6D70CO2PR00MB0085namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dbef9fd3-8fdc-48e7-6a49-08d71bfdd4c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 12:42:10.2908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uH3CqvSvUgludC+vrEcNEzBrzx4UUknlUvfdVV6zKRfaZRoREpIFRevRLK9viUpA8g/CE5avvw5CGOrNCpWfPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0119 Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 12:42:17 -0000 --_000_CO2PR00MB00856B37BD4BB02B5F42ADDCA6D70CO2PR00MB0085namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How about the University in Gjovik ? Get Outlook for Android ________________________________ From: OAuth on behalf of Daniel Fett Sent: Wednesday, August 7, 2019 11:47:51 PM To: Dick Hardt ; dbaier@leastprivilege.com Cc: Mike Jones ; OAuth WG <= oauth@ietf.org> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop Not yet, we are talking to potential venues. It's vacation time in Norway r= ight now, so that will take a week or two more. -Daniel Am 07.08.19 um 18:09 schrieb Dick Hardt: Are we ready to pick a date? On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier > wrote: August will conflict with holiday time for most Europeans=85 Just been to Trondheim last week - it was lovely weather. =97=97=97 Dominick On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsoft.com@d= marc.ietf.org) wrote= : I'm not aware of any conflicts for any of the three sets of dates. -- Mike -----Original Message----- From: OAuth > On Beha= lf Of Aaron Parecki Sent: Thursday, July 25, 2019 4:07 PM To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop We'll be so productive with only 4 hours of darkness every day! All of the dates work for me, but I would prefer the July dates since it'll= be easier/cheaper to bundle the two trips into one. (Hopefully we could ge= t the OAuth meeting dates early in the week at IETF then) On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt > wrote: > > +1 to July / August. Nicer weather in the north then. =3D) > > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett > wrote: >> >> Hi all, >> >> it seems like there is a rough consensus on having the next OAuth Securi= ty Workshop in Trondheim, Norway. We will therefore start with the planning= . >> >> After checking various event calendars it seems like the following dates= are suitable: >> >> May 7-9 >> >> July 22-24 >> >> August 3-5 >> >> First date is before EIC =9120 which is May 12-15 in Munich/Germany. The= latter two dates are before/after IETF 108 which is July 25-31, Madrid/Spa= in. >> >> Unless somebody raises objections because of conflicting identity/securi= ty events we will pick one of these dates in the next two weeks or so. >> >> -Daniel >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww<= https://www> >> .ietf.org%= 2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jon >> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGW >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fma= ilman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones > %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXy > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40mic= rosoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd01= 1db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD= 482nhyARt28me4xbE%3D&reserved=3D0 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CO2PR00MB00856B37BD4BB02B5F42ADDCA6D70CO2PR00MB0085namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How about the University in Gjovik ?

From: OAuth <oauth-bounc= es@ietf.org> on behalf of Daniel Fett <danielf+oauth@yes.com><= br> Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.c= om <dbaier@leastprivilege.com>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>= ;; OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop
 
Not yet, we are talking to potential venues.= It's vacation time in Norway right now, so that will take a week or two mo= re.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Domi= nick Baier <dbaier@leastprivilege.com> wrote:
August will confl= ict with holiday time for most Europeans=85

Just been to Tron= dheim last week - it was lovely weather.

=97=97=97
Dominick

On 25. July 2019 at 22:1= 4:28, Mike Jones (michael.jones=3D40micro= soft.com@dmarc.ietf.org) wrote:

I'm not aware of any conflicts for any of the three sets of dates.
-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron= Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it'll= be easier/cheaper to bundle the two trips into one. (Hopefully we could ge= t the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com= > wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf= 3;oauth@yes.com> wrote:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =9120 which is May 12-15 in Munich/German= y. The latter two dates are before/after IETF 108 which is July 25-31, Madr= id/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/= security events we will pick one of these dates in the next two weeks or so= .
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org= %2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40= microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> htt= ps://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %= 40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.out= look.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&= ;amp;data=3D02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e0= 8d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975= &amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;r= eserved=3D0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th


--_000_CO2PR00MB00856B37BD4BB02B5F42ADDCA6D70CO2PR00MB0085namp_-- From nobody Thu Aug 8 05:49:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7C9120181 for ; Thu, 8 Aug 2019 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.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 apXkd5p-sxzA for ; Thu, 8 Aug 2019 05:49:49 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 EA24D120074 for ; Thu, 8 Aug 2019 05:49:48 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id x21so24737629otq.12 for ; Thu, 08 Aug 2019 05:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4yqpxAoILUHubAmcMfLUGzHeJjCyj6uiCijFOL1SRAc=; b=zpjgOPHQIgEyr8cfmxxt2c5uqbLlBt0YFgz+FnAFT1AMkBHneryCBngQBLQia9toFj vvQGtQ3w3izKT+IMD/4JzvkCl/qpvrJwyxHgUzZtgIhhBYXezUJaG/4/ZpkOQmcQoE4t M+o5qCl6H0Rr0xumHxAoSX/EAeh0ypUQL0rySnGN7QpgKAneJ/nKhFT7KV4ZoNs1cSup nZOGKYDdB5PFe0hRvIJBvs3o7wJjxQ+CUmzXtPkemair/d6u25oA1ODk56Sv70h/RShC CFlwb6a4+pMZAQWcwyG8VgyNTveQcqOrAGmvBGhF1PZcaNS2H5EVZUyYWq2HxaiwIOMG MuUQ== 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=4yqpxAoILUHubAmcMfLUGzHeJjCyj6uiCijFOL1SRAc=; b=qOVElvsGgy+4AhlmWDz5Viwm6YmJkaFlzUOEB3hBICaZD0QZ7ypDsJDGsm8uYCvo/x xwEXH9nXzN95XMOEUZWVWR6RmMpuWNWuR9dDYi7P60xv2VJstD7B33abgNg0wr4s798b ALnK91IyXaWbDBQsfe/20uMkJILuqbgKkP6F5JoSiOJPRZYTF02Lcaq/Pu9mLyWCLK3X 2678dcsnTjxgL4BcGL9Czdb5soTnzEwPcS0OqB33ukz6wUV4+s0f48vfBpcsEFxzRvQL 2m3wsYo4h/GCZn3tHRBMp1RRY+xM3m0DOPWROqKSUlbG7/5Q3XP8E5dz0H+QDgXsJ0Tf +v0w== X-Gm-Message-State: APjAAAV5su+gZsAX9aI3Se2Uy9m+/FSucEA5dOOyqEkzHue5DYskUF3x I0EmHFXPm9mB2xa0gT1x5NSXIT1/BTb/xkhBBJVvUA== X-Google-Smtp-Source: APXvYqyxjb56y9yv45oZ0HcXMLBy05eo2gVSQI0glkG2dVT9529bKhcRFC4Od2vKVbj+ijCTzTxygJudBqhhnm2Pvk0= X-Received: by 2002:a9d:7383:: with SMTP id j3mr586401otk.74.1565268588146; Thu, 08 Aug 2019 05:49:48 -0700 (PDT) MIME-Version: 1.0 References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: From: Steinar Noem Date: Thu, 8 Aug 2019 14:49:37 +0200 Message-ID: To: Anthony Nadalin Cc: Daniel Fett , Dick Hardt , Mike Jones , OAuth WG , "dbaier@leastprivilege.com" Content-Type: multipart/alternative; boundary="0000000000002cc810058f9a7e07" Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 12:49:51 -0000 --0000000000002cc810058f9a7e07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Anthony. Gj=C3=B8vik is part of NTNU, we are waiting for feedback from = them :) I think Trondheim is more accessible (travel time) and has more to offer. tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin : > How about the University in Gjovik ? > > Get Outlook for Android > > ------------------------------ > *From:* OAuth on behalf of Daniel Fett < > danielf+oauth@yes.com> > *Sent:* Wednesday, August 7, 2019 11:47:51 PM > *To:* Dick Hardt ; dbaier@leastprivilege.com < > dbaier@leastprivilege.com> > *Cc:* Mike Jones ; OAuth = WG > > > *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security > Workshop > > Not yet, we are talking to potential venues. It's vacation time in Norway > right now, so that will take a week or two more. > > -Daniel > > Am 07.08.19 um 18:09 schrieb Dick Hardt: > > Are we ready to pick a date? > > On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier > wrote: > > August will conflict with holiday time for most Europeans=E2=80=A6 >> >> Just been to Trondheim last week - it was lovely weather. >> >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick >> >> On 25. July 2019 at 22:14:28, Mike Jones ( >> michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote: >> > I'm not aware of any conflicts for any of the three sets of dates. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth On Behalf Of Aaron Parecki >> Sent: Thursday, July 25, 2019 4:07 PM >> To: Dick Hardt >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security >> Workshop >> >> We'll be so productive with only 4 hours of darkness every day! >> >> All of the dates work for me, but I would prefer the July dates since >> it'll be easier/cheaper to bundle the two trips into one. (Hopefully we >> could get the OAuth meeting dates early in the week at IETF then) >> >> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt wrote: >> > >> > +1 to July / August. Nicer weather in the north then. =3D) >> > >> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett >> wrote: >> >> >> >> Hi all, >> >> >> >> it seems like there is a rough consensus on having the next OAuth >> Security Workshop in Trondheim, Norway. We will therefore start with the >> planning. >> >> >> >> After checking various event calendars it seems like the following >> dates are suitable: >> >> >> >> May 7-9 >> >> >> >> July 22-24 >> >> >> >> August 3-5 >> >> >> >> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/Ger= many. The >> latter two dates are before/after IETF 108 which is July 25-31, >> Madrid/Spain. >> >> >> >> >> Unless somebody raises objections because of conflicting >> identity/security events we will pick one of these dates in the next two >> weeks or so.. >> >> >> >> >> -Daniel >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww >> >> >> .ietf.org >> %2Fmailman= %2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jon >> >> >> es%40microsoft.com >> %7C= 4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >> >> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxw= GW >> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w >> . >> > ietf.org >> %2Fmailman%2= Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones >> >> > %40microsoft.com >> %= 7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af >> >> > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSR= Xy >> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40= microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BWMX= cMD482nhyARt28me4xbE%3D&reserved=3D0 >> >> _______________________________________________ >> 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 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --0000000000002cc810058f9a7e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Anthony. Gj=C3=B8vik is part of NTNU, we are wai= ting for feedback from them :)

I think Trondheim is more accessible (travel time) and has mor= e to offer.

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin <tonyn= ad=3D40microsoft.com@dmar= c.ietf.org>:
How about the University in Gjovik ?

From:= OAuth <oaut= h-bounces@ietf.org> on behalf of Daniel Fett <danielf+oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.com <dbaier@leastprivilege.com<= /a>>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>; = OAuth WG <oauth@ietf= .org>

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop
=C2=A0
Not yet, we are talkin= g to potential venues. It's vacation time in Norway right now, so that = will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 s= chrieb Dick Hardt:
Are we ready to pick a date?

=
On Thu, Jul 25, 2019 at 11:30 PM Domi= nick Baier <dbaier@leastprivilege.com> wrote:
August will confl= ict with holiday time for most Europeans=E2=80=A6

Just been to Tron= dheim last week - it was lovely weather.

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

On= 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsof= t.com@dmarc.ietf.org) wrote:

=
<= span>
=
I'm not aware of an= y conflicts for any of the three sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it= 9;ll be easier/cheaper to bundle the two trips into one. (Hopefully we coul= d get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote= :
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/= Germany. The latter two dates are before/after IETF 108 which is July 25-31= , Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/= security events we will pick one of these dates in the next two weeks or so= ..
<= /div>
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://nam06.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fo= auth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c010= 1bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %40microsoft.com%7C4c0101bc1e= dc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06= .safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailm= an%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones%40microsoft.co= m%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD482nh= yARt28me4xbE%3D&amp;reserved=3D0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
<= div style=3D"color:rgb(80,0,80)">Vennli= g hilsen

Steinar Noem
Partner Udelt AS
Systemutv= ikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@u= delt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.= udelt.no=C2=A0|=C2=A0
--0000000000002cc810058f9a7e07-- From nobody Sat Aug 10 01:52:40 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16561200B3 for ; Sat, 10 Aug 2019 01:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=unavailable 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 0U4ATMlUEgDE for ; Sat, 10 Aug 2019 01:52:35 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 66628120099 for ; Sat, 10 Aug 2019 01:52:35 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id v19so7563571wmj.5 for ; Sat, 10 Aug 2019 01:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rir8ePcWNP/CgtbuYLmfLJezfekUwLva+7rZ+acHK/U=; b=ZGV0qxOmgE4YVRs1LBZvKX6rwz/41PfG7XiwhncoYjyqsWkaeRY7yp4ZjZgJDki4e+ tzqMaqItRmiVuIKWXS34oWq3oi9Vn5i/aoF0d8V8o9qhNZK2+VPM10qLIpJWkbmEoTmm 7uzCpDKzlKUKzY07tzJI2A5FfBv5MA4SwRZp//DgnyDCYUhnbTnxSiUKXaZbsByGkz/1 SYhbcldAttJ+T4qh800D+NgnghujukZQB03pmK23Wu3sBNgNf93hK+h0MoXTGNeTkNeM jslqwAA2CrIOu95uQfbTMwYYTgPktMjCECEOWeIVBDlKTSs6igJzIWb7XQGeFQIozlnA meFA== 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=Rir8ePcWNP/CgtbuYLmfLJezfekUwLva+7rZ+acHK/U=; b=gm8x6F7DTvDTWKbLtuXbS3GP70CA1IXwceQA+r41CWLoWvQm4GHhjUozqkg0xMBRmr CVZvoziHOICnihFHKHhztM4t8IxjbyumXoZO66e72qxnuRx0DdTEs3EoByUye3vke2hP wb0J9csW2943ooSTpGHTD+6BxyfNqi3I4xJ1IFReqyTTaF5M+A+q+HuRjzVh6GWddzsT EA6jrTeXqbLRn3/qU3p/QWkVzW5KHYNDF6ctVROgRl5p/CpbAXGw1gMBowIZi4lECfUi zk+k2dfjQ33dwJdxxvZomsb9Y5VWm14roRpetRyk/co1pV5D/ipmryLfFqL+/6dKqSTl HMJA== X-Gm-Message-State: APjAAAW4YXEk6vDwM8n32O2JTw8WYSvtPffJ4XWhqRN9Sq2LFsS1FUVJ eIykPsE5pajJ0kvNjKI+qZgirvSvjjR3Kvgcd3s= X-Google-Smtp-Source: APXvYqxph8SoZVS8e56DesGHZDXpMm91KdqBB6VvqDP8O1n0L/8quylAK5X7ee8h7ZcVB9tl4JdJkPLT2b3WKLReAbI= X-Received: by 2002:a05:600c:218d:: with SMTP id e13mr15802962wme.29.1565427153380; Sat, 10 Aug 2019 01:52:33 -0700 (PDT) MIME-Version: 1.0 References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: From: Nat Sakimura Date: Sat, 10 Aug 2019 17:52:22 +0900 Message-ID: To: Steinar Noem Cc: Anthony Nadalin , OAuth WG , Mike Jones Content-Type: multipart/alternative; boundary="000000000000662b61058fbf6977" Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 08:52:40 -0000 --000000000000662b61058fbf6977 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Tony was just joking as it was quite a hassle for both of us to get to Gj=C3=B8vik for an ISO meeting. On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem wrote: > Hey Anthony. Gj=C3=B8vik is part of NTNU, we are waiting for feedback fro= m them > :) > > I think Trondheim is more accessible (travel time) and has more to offer. > > tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin 40microsoft.com@dmarc.ietf.org>: > >> How about the University in Gjovik ? >> >> Get Outlook for Android >> >> ------------------------------ >> *From:* OAuth on behalf of Daniel Fett < >> danielf+oauth@yes.com> >> *Sent:* Wednesday, August 7, 2019 11:47:51 PM >> *To:* Dick Hardt ; dbaier@leastprivilege.com < >> dbaier@leastprivilege.com> >> *Cc:* Mike Jones ; OAuth >> WG > >> >> *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security >> Workshop >> >> Not yet, we are talking to potential venues. It's vacation time in Norwa= y >> right now, so that will take a week or two more. >> >> -Daniel >> >> Am 07.08.19 um 18:09 schrieb Dick Hardt: >> >> Are we ready to pick a date? >> >> On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier < >> dbaier@leastprivilege.com> wrote: >> >> August will conflict with holiday time for most Europeans=E2=80=A6 >>> >>> Just been to Trondheim last week - it was lovely weather. >>> >>> =E2=80=94=E2=80=94=E2=80=94 >>> Dominick >>> >>> On 25. July 2019 at 22:14:28, Mike Jones ( >>> michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote: >>> >> I'm not aware of any conflicts for any of the three sets of dates. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: OAuth On Behalf Of Aaron Parecki >>> Sent: Thursday, July 25, 2019 4:07 PM >>> To: Dick Hardt >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security >>> Workshop >>> >>> We'll be so productive with only 4 hours of darkness every day! >>> >>> All of the dates work for me, but I would prefer the July dates since >>> it'll be easier/cheaper to bundle the two trips into one. (Hopefully we >>> could get the OAuth meeting dates early in the week at IETF then) >>> >>> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt >>> wrote: >>> > >>> > +1 to July / August. Nicer weather in the north then. =3D) >>> > >>> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett >>> wrote: >>> >> >>> >> Hi all, >>> >> >>> >> it seems like there is a rough consensus on having the next OAuth >>> Security Workshop in Trondheim, Norway. We will therefore start with th= e >>> planning. >>> >> >>> >> After checking various event calendars it seems like the following >>> dates are suitable: >>> >> >>> >> May 7-9 >>> >> >>> >> July 22-24 >>> >> >>> >> August 3-5 >>> >> >>> >> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/Ge= rmany. >>> The latter two dates are before/after IETF 108 which is July 25-31, >>> Madrid/Spain. >>> >> >>> >>> >> Unless somebody raises objections because of conflicting >>> identity/security events we will pick one of these dates in the next tw= o >>> weeks or so... >>> >>> >> >>> >> -Daniel >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >>> >>> >> .ietf.org >>> %2Fmailma= n%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jon >>> >>> >> es%40microsoft.com >>> %7= C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >>> >>> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYx= wGW >>> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww >>> . >>> > ietf.org >>> %2Fmailman%= 2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones >>> >>> > %40microsoft.com >>> = %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af >>> >>> > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWS= RXy >>> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://nam06..safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%= 40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d= 7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BW= MXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>> >>> _______________________________________________ >>> 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 >> > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000662b61058fbf6977 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Tony was just joking as it was quite a hassle for = both of us to get to Gj=C3=B8vik for an ISO meeting.=C2=A0

On Thu, Aug 8, 20= 19 at 9:50 PM Steinar Noem <steinar@= udelt.no> wrote:
Hey Anthony. Gj=C3=B8vik is part of NTNU, we= are waiting for feedback from them :)

I think Trondheim is more accessible (travel time) and= has more to offer.

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin &= lt;tonynad=3D40microsoft.com@dmarc.ietf.org>:
How about the University in Gjovik ?

From: OAuth <oauth-bounces@ietf.org> on behalf of Daniel F= ett <daniel= f+oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.com <dbaier@leastprivilege.com<= /a>>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>; = OAuth WG <oauth@ietf= ..org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop
=C2=A0
Not yet, we are talking to potential venues. It's vacation time in= Norway right now, so that will take a week or two more.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Domi= nick Baier <dbaier@leastprivilege.com> wrote:
August will confl= ict with holiday time for most Europeans=E2=80=A6

Just been to Tron= dheim last week - it was lovely weather.

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

On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote:

=
=
=
I'm not a= ware of any conflicts for any of the three sets of dates.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it= 9;ll be easier/cheaper to bundle the two trips into one. (Hopefully we coul= d get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote= :
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/= Germany. The latter two dates are before/after IETF 108 which is July 25-31= , Madrid/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/= security events we will pick one of these dates in the next two weeks or so= ...
<= /div>
<= blockquote type=3D"cite" class=3D"gmail-m_5734447317792991337m_-74403732588= 45141650gmail-m_1384038748018219611clean_bq">
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://nam06.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fo= auth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c010= 1bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %40microsoft.com%7C4c0101bc1e= dc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06= ..safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmail= man%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones%40microsoft.c= om%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD482n= hyARt28me4xbE%3D&amp;reserved=3D0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth


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

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--000000000000662b61058fbf6977-- From nobody Sat Aug 10 08:10:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29022120043 for ; Sat, 10 Aug 2019 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] 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 IkeBP6VO155r for ; Sat, 10 Aug 2019 08:10:14 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 573CA12001A for ; Sat, 10 Aug 2019 08:10:13 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id m8so61100053lji.7 for ; Sat, 10 Aug 2019 08:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VyERmQT+KfKxkLZY/bOchh2CtWO2jmf1KO9tX9Wzli8=; b=QswxO7/g6iTml3+cMAU9k8HCfUw2ClObyukwni6HN/c/MPvnDLkR7oS58YgyuAe3Kj PhlIc68ZbvuOjUkjNriWefrVFdp6c6XqagXMMQYz7Xsi+6nHv49Ut32ZJLTTquqhDoGU LPl0HNR1Ul5f6DH6NIxfnPhYEZqMJ7a6gEARnJryKKQ4iMYAfEBXXuJl598x6r+DDcSc OhgDJ2M/89hzSL9WNIvGjNllcMN56T2za1X2gAyd3bFbaEzRHseYl8iP6gixcQChEGSd Gpz9bSoDQu17FsEXf6Eg5R7aa6I0zw2LrqA9c/CIrII6aML/myTgnAiXxIdM4Ogcgr53 Ip9w== 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=VyERmQT+KfKxkLZY/bOchh2CtWO2jmf1KO9tX9Wzli8=; b=Y7+FAK5lHGI37wUU7OIvkUnbWZOGwPow11IYKLwrFxhi8ZY1+yksACIebU0wJ+gunv dzGP9cyvS3Vv5ZCYw9jx/lp3TuPC66MjKQFM9l2tG8pslQNAcQNLWWTAgeh5aA9MJXzv E1ENIB86NbAXwFAVb+fDqZOP9Rp1blVOXPnyvIndqb4pVKtsJpral7HY3ad3nMVZIXG6 t6ybFpF7SBK8GEQ7FsK+ZjJAXf1jWGkYOgFV4TCn4ixTsG85XLi2vBnCt1qmQkeJ00Y/ jv98tMQAVI67DIifr9bRBCEMm6dny6FTWKzCiUdH4OAUqPkvIYr8qqWFj3C/rlqBdi+8 LCwA== X-Gm-Message-State: APjAAAVChEWu36zhrsMbz8ypPmhWB39TPQyHWvRrfhKLMP2gwu3t7i74 usEn5O+heIbC7KAXJmcjQp3RR92tYey9/H544mc= X-Google-Smtp-Source: APXvYqzCF7Yku+Dcg/Y7s4C2SzjWhDEMVG0LmD1ypeG3mQ5odUnB9ShepGWVU5jdOG6J/OdOQQR6caXx2tUsSYinXTg= X-Received: by 2002:a2e:98d7:: with SMTP id s23mr4377847ljj.179.1565449811360; Sat, 10 Aug 2019 08:10:11 -0700 (PDT) MIME-Version: 1.0 References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: From: Dick Hardt Date: Sat, 10 Aug 2019 08:09:59 -0700 Message-ID: To: Nat Sakimura Cc: Anthony Nadalin , Mike Jones , OAuth WG , Steinar Noem Content-Type: multipart/alternative; boundary="000000000000eb7fd4058fc4afec" Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 15:10:17 -0000 --000000000000eb7fd4058fc4afec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps someone can teach Tony about emoticons to communicate his ironic humor? =3D) On Sat, Aug 10, 2019 at 1:52 AM Nat Sakimura wrote: > I think Tony was just joking as it was quite a hassle for both of us to > get to Gj=C3=B8vik for an ISO meeting. > > On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem wrote: > >> Hey Anthony. Gj=C3=B8vik is part of NTNU, we are waiting for feedback fr= om >> them :) >> >> I think Trondheim is more accessible (travel time) and has more to offer= . >> >> tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin > 40microsoft.com@dmarc.ietf.org>: >> >>> How about the University in Gjovik ? >>> >>> Get Outlook for Android >>> >>> ------------------------------ >>> *From:* OAuth on behalf of Daniel Fett < >>> danielf+oauth@yes.com> >>> *Sent:* Wednesday, August 7, 2019 11:47:51 PM >>> *To:* Dick Hardt ; dbaier@leastprivilege.com < >>> dbaier@leastprivilege.com> >>> *Cc:* Mike Jones ; OAut= h >>> WG > >>> >> >>> *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security >>> Workshop >>> >>> Not yet, we are talking to potential venues. It's vacation time in >>> Norway right now, so that will take a week or two more. >>> >>> -Daniel >>> >>> Am 07.08.19 um 18:09 schrieb Dick Hardt: >>> >>> Are we ready to pick a date? >>> >>> On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>> August will conflict with holiday time for most Europeans=E2=80=A6 >>>> >>>> Just been to Trondheim last week - it was lovely weather. >>>> >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> Dominick >>>> >>>> On 25. July 2019 at 22:14:28, Mike Jones ( >>>> michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote: >>>> >>> I'm not aware of any conflicts for any of the three sets of dates. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: OAuth On Behalf Of Aaron Parecki >>>> Sent: Thursday, July 25, 2019 4:07 PM >>>> To: Dick Hardt >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security >>>> Workshop >>>> >>>> We'll be so productive with only 4 hours of darkness every day! >>>> >>>> All of the dates work for me, but I would prefer the July dates since >>>> it'll be easier/cheaper to bundle the two trips into one. (Hopefully w= e >>>> could get the OAuth meeting dates early in the week at IETF then) >>>> >>>> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt >>>> wrote: >>>> > >>>> > +1 to July / August. Nicer weather in the north then. =3D) >>>> > >>>> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett >>>> wrote: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> it seems like there is a rough consensus on having the next OAuth >>>> Security Workshop in Trondheim, Norway. We will therefore start with t= he >>>> planning. >>>> >> >>>> >> After checking various event calendars it seems like the following >>>> dates are suitable: >>>> >> >>>> >> May 7-9 >>>> >> >>>> >> July 22-24 >>>> >> >>>> >> August 3-5 >>>> >> >>>> >> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/G= ermany. >>>> The latter two dates are before/after IETF 108 which is July 25-31, >>>> Madrid/Spain. >>>> >> >>>> >>>> >> Unless somebody raises objections because of conflicting >>>> identity/security events we will pick one of these dates in the next t= wo >>>> weeks or so.... >>>> >>>> >> >>>> >> -Daniel >>>> >> >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> >>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w >>>> >>>> >> .ietf.org >>>> %2Fmailm= an%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jon >>>> >>>> >> es%40microsoft.com >>>> %= 7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >>>> >>>> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWY= xwGW >>>> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >>>> . >>>> > ietf.org >>>> %2Fmailman= %2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones >>>> >>>> > %40microsoft.com >>>> %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af >>>> >>>> > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGW= SRXy >>>> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> >>>> https://nam06...safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jone= s%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab= 2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2= BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000eb7fd4058fc4afec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps someone can teach Tony about emoticons to co= mmunicate his ironic humor? =3D)

On Sat, Aug 10, 2019 at 1:52 AM = Nat Sakimura <sakimura@gmail.com> wrote:

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 8, 2019 at 9:50 PM Steinar= Noem <steinar@ude= lt.no> wrote:
Hey Anthony. Gj=C3=B8vik is part of NTNU, we ar= e waiting for feedback from them :)

=
I think Trondheim is more accessible (travel time) and ha= s more to offer.

tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin <= tonynad=3D40microsoft.com@dmarc.ietf.org>:
How about the University in Gjovik ?

From: OAuth <oauth-bounces@ietf.org>= ; on behalf of Daniel Fett <danielf+oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.com <dbaier@leastprivilege.com<= /a>>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>; = OAuth WG <oauth@ietf= ...org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop
=C2=A0
Not yet, we are talking to potential venues. It&= #39;s vacation time in Norway right now, so that will take a week or two mo= re.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Domi= nick Baier <dbaier@leastprivilege.com> wrote:
August will confl= ict with holiday time for most Europeans=E2=80=A6

Just been to Tron= dheim last week - it was lovely weather.

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

On 25. July 2019 at 22:14:28= , Mike Jones (michael.jones=3D40microsoft.com@dmarc.ietf.org) = wrote:

=
=
=
<= div>
I'm not aware of any conflicts for any of the three sets of da= tes.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it= 9;ll be easier/cheaper to bundle the two trips into one. (Hopefully we coul= d get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote= :
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/= Germany. The latter two dates are before/after IETF 108 which is July 25-31= , Madrid/Spain.
>>
<= div bgcolor=3D"#FFFFFF">
>> Unless somebody raises objections because of conflicting identity/= security events we will pick one of these dates in the next two weeks or so= ....
<= /div>
<= blockquote type=3D"cite" class=3D"m_-8701006442984404282gmail-m_57344473177= 92991337m_-7440373258845141650gmail-m_1384038748018219611clean_bq">
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://nam06.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fo= auth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c010= 1bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %40microsoft.com%7C4c0101bc1e= dc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06= ...safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones%40microsoft.= com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD482= nhyARt28me4xbE%3D&amp;reserved=3D0
<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth


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

Steinar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
<= div style=3D"color:rgb(34,34,34)">|=C2=A0steinar@udelt.no=C2=A0|= =C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|= =C2=A0www.udelt.no=C2=A0|=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimura (=3Dnat)
= Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000eb7fd4058fc4afec-- From nobody Sat Aug 10 11:04:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61AE120122 for ; Sat, 10 Aug 2019 11:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.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 2kY0LS2bcUUg for ; Sat, 10 Aug 2019 11:04:33 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 25DCD1200F6 for ; Sat, 10 Aug 2019 11:04:32 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id m97so11586927otm.12 for ; Sat, 10 Aug 2019 11:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tysz3tbL7XGfBofg357QNZ0NXaTty7Gch5XVsR67+P4=; b=V9SCg62Nyr9bxN1VRulSG7dllvZ6wsmAOQcXfwnIHRfKs3ZFmC3ILNQfFfLkVNZUnl yuz0THGsNvTDLGGBlnp65n/0Cn26iZuw5wTrcdjMRQSXaPG5kUvsCAnAsLLZ3wEkYzQd qHWJr/4dNvoaxNnh2K2hL2f7NG4jygcpFgxXy5rJja/nxVybAyBv+veucfotHoUB7SKe frZ9ovTnTfvBMJKZxiJKbk5rTr+rheMEo/CSkiuhtn2MzkYFtAOoonxVakXqH1rWHk9i VVzbMp9NHr94Jp3TNvepX6h9cEdxJ3i4ZqYB25wq09H2HKYpB36OI36eQ4vMeOj4Vivx dMXA== 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=Tysz3tbL7XGfBofg357QNZ0NXaTty7Gch5XVsR67+P4=; b=lRAkgoROfR6dfTgxCWHr32SA/zgFUL4zNLzYKBrBqbiEy5L30ui8EOGvrZjrV13moj V0XMlXv96lT6ULKux/JFiGINCPjrd5+H929bDy0BbwvL4msHVCJ1n+Azx2t+WJ9+iiXA l324jNrJmuglxTmgjtdaAclRDVspJ43fado3I5pMISMAD/E3VRXtEJ1mn09U37P4BuOy /jxonxXip4AL9iwjb/SnLYkuuOtkBncX5rlzLa17QtXeJDVVupxc5FnKWjOOziBVjjNf 6QtC3RN9wmRkl5gTggmSlhwp0VEM37TqUhMBZXh4Hu0DGeZlYPL3OrEFxPt18SHrDeDK EA4A== X-Gm-Message-State: APjAAAW1q2Nv+pYTKRQIkVFU0X7Uz3iUXX+NXpCJRfIUu5FWe8LpRKj8 iRcfu6SFtJUNYes6qEwALzb8TSP2DRCIJJzSjWKbNw== X-Google-Smtp-Source: APXvYqwZKiiIARD1xjpo/KSvIBrlbtIFjh3GeoRQSyzQrzJ29CVYjM5ruvBqf/+jCoFaOPvW0wJEU6DWc9DxtfALrpM= X-Received: by 2002:aca:dc88:: with SMTP id t130mr5701850oig.98.1565460271843; Sat, 10 Aug 2019 11:04:31 -0700 (PDT) MIME-Version: 1.0 References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> In-Reply-To: From: Steinar Noem Date: Sat, 10 Aug 2019 20:04:20 +0200 Message-ID: To: Nat Sakimura Cc: Anthony Nadalin , Mike Jones , OAuth WG Content-Type: multipart/alternative; boundary="00000000000069e0d8058fc71fd8" Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 18:04:37 -0000 --00000000000069e0d8058fc71fd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That is good to hear, Nat. I tried to be as polite as possible in my response. l=C3=B8r. 10. aug. 2019 kl. 10:52 skrev Nat Sakimura : > I think Tony was just joking as it was quite a hassle for both of us to > get to Gj=C3=B8vik for an ISO meeting. > > On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem wrote: > >> Hey Anthony. Gj=C3=B8vik is part of NTNU, we are waiting for feedback fr= om >> them :) >> >> I think Trondheim is more accessible (travel time) and has more to offer= . >> >> tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin > 40microsoft.com@dmarc.ietf.org>: >> >>> How about the University in Gjovik ? >>> >>> Get Outlook for Android >>> >>> ------------------------------ >>> *From:* OAuth on behalf of Daniel Fett < >>> danielf+oauth@yes.com> >>> *Sent:* Wednesday, August 7, 2019 11:47:51 PM >>> *To:* Dick Hardt ; dbaier@leastprivilege.com < >>> dbaier@leastprivilege.com> >>> *Cc:* Mike Jones ; OAut= h >>> WG > >>> >> >>> *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security >>> Workshop >>> >>> Not yet, we are talking to potential venues. It's vacation time in >>> Norway right now, so that will take a week or two more. >>> >>> -Daniel >>> >>> Am 07.08.19 um 18:09 schrieb Dick Hardt: >>> >>> Are we ready to pick a date? >>> >>> On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>> August will conflict with holiday time for most Europeans=E2=80=A6 >>>> >>>> Just been to Trondheim last week - it was lovely weather. >>>> >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> Dominick >>>> >>>> On 25. July 2019 at 22:14:28, Mike Jones ( >>>> michael.jones=3D40microsoft.com@dmarc.ietf.org) wrote: >>>> >>> I'm not aware of any conflicts for any of the three sets of dates. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: OAuth On Behalf Of Aaron Parecki >>>> Sent: Thursday, July 25, 2019 4:07 PM >>>> To: Dick Hardt >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security >>>> Workshop >>>> >>>> We'll be so productive with only 4 hours of darkness every day! >>>> >>>> All of the dates work for me, but I would prefer the July dates since >>>> it'll be easier/cheaper to bundle the two trips into one. (Hopefully w= e >>>> could get the OAuth meeting dates early in the week at IETF then) >>>> >>>> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt >>>> wrote: >>>> > >>>> > +1 to July / August. Nicer weather in the north then. =3D) >>>> > >>>> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett >>>> wrote: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> it seems like there is a rough consensus on having the next OAuth >>>> Security Workshop in Trondheim, Norway. We will therefore start with t= he >>>> planning. >>>> >> >>>> >> After checking various event calendars it seems like the following >>>> dates are suitable: >>>> >> >>>> >> May 7-9 >>>> >> >>>> >> July 22-24 >>>> >> >>>> >> August 3-5 >>>> >> >>>> >> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/G= ermany. >>>> The latter two dates are before/after IETF 108 which is July 25-31, >>>> Madrid/Spain. >>>> >> >>>> >>>> >> Unless somebody raises objections because of conflicting >>>> identity/security events we will pick one of these dates in the next t= wo >>>> weeks or so... >>>> >>>> >> >>>> >> -Daniel >>>> >> >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> >>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w >>>> >>>> >> .ietf.org >>>> %2Fmailm= an%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jon >>>> >>>> >> es%40microsoft.com >>>> %= 7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14 >>>> >>>> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWY= xwGW >>>> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www >>>> . >>>> > ietf.org >>>> %2Fmailman= %2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones >>>> >>>> > %40microsoft.com >>>> %7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af >>>> >>>> > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGW= SRXy >>>> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> >>>> https://nam06..safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones= %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2B= WMXcMD482nhyARt28me4xbE%3D&reserved=3D0 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --00000000000069e0d8058fc71fd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is good to hear, Nat.
I tried to be as polite as possible in my response.

l=C3=B8r. 10. a= ug. 2019 kl. 10:52 skrev Nat Sakimura <sakimura@gmail.com>:
I think Tony was just joking as it was quite a hassle for bo= th of us to get to Gj=C3=B8vik for an ISO meeting.=C2=A0

On Thu, Aug 8, 2019= at 9:50 PM Steinar Noem <steinar@udelt.no> wrote:
Hey Anthony. Gj=C3=B8vik is = part of NTNU, we are waiting for feedback from them :)

I think Trondheim is more accessible = (travel time) and has more to offer.

tor. 8. aug. 2019 kl. 14:42 skrev = Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org>:
How about the University in Gjovik ?

From: OAuth <oauth-bounces@ietf.org>= ; on behalf of Daniel Fett <danielf+oauth@yes.com>
Sent: Wednesday, August 7, 2019 11:47:51 PM
To: Dick Hardt <dick.hardt@gmail.com>; dbaier@leastprivilege.com <dbaier@leastprivilege.com<= /a>>
Cc: Mike Jones <michael.jones=3D40microsoft.com@dmarc.ietf.org>; = OAuth WG <oauth@ietf= ..org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security W= orkshop
=C2=A0
Not yet, we are talking to potential venues. It&#= 39;s vacation time in Norway right now, so that will take a week or two mor= e.

-Daniel

Am 07.08.19 um 18:09 schrieb Dick Hardt:
Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Domi= nick Baier <dbaier@leastprivilege.com> wrote:
August will confl= ict with holiday time for most Europeans=E2=80=A6

Just been to Tron= dheim last week - it was lovely weather.

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

On 25. July 2019 at 22:14:28,= Mike Jones (michael.jones=3D40microsoft.com@dmarc.ietf.org) w= rote:

=
=
=
I'm not aware of any conflicts for any of the three sets of dat= es.

-- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: OAuth WG <oauth@= ietf.org>
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop=

We'll be so productive with only 4 hours of darkness every day!

All of the dates work for me, but I would prefer the July dates since it= 9;ll be easier/cheaper to bundle the two trips into one. (Hopefully we coul= d get the OAuth meeting dates early in the week at IETF then)

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote= :
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth = Security Workshop in Trondheim, Norway. We will therefore start with the pl= anning.
>>
>> After checking various event calendars it seems like the following= dates are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/= Germany. The latter two dates are before/after IETF 108 which is July 25-31= , Madrid/Spain.
>>
<= div bgcolor=3D"#FFFFFF">
>> Unless somebody raises objections because of conflicting identity/= security events we will pick one of these dates in the next two weeks or so= ...
<= /div>
<= blockquote type=3D"cite" class=3D"m_2022211865354367987gmail-m_573444731779= 2991337m_-7440373258845141650gmail-m_1384038748018219611clean_bq">
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://nam06.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fo= auth&amp;data=3D02%7C01%7CMichael.Jon
>> es%40microsoft.com%7C4c010= 1bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3Dd= AokWYxwGW
>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://nam06.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.= Jones
> %40microsoft.com%7C4c0101bc1e= dc403d7b0e08d7113be77f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxw= GWSRXy
> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06= ..safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmail= man%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones%40microsoft.c= om%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD482n= hyARt28me4xbE%3D&amp;reserved=3D0
<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth


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

Steinar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2= =A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2= =A0www.udelt.no=C2=A0|=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Nat Sakimura (=3Dnat)
C= hairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--
<= div style=3D"color:rgb(80,0,80)">Vennli= g hilsen

Steinar Noem
Partner Udelt AS
Systemutv= ikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@u= delt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.= udelt.no=C2=A0|=C2=A0
--00000000000069e0d8058fc71fd8-- From nobody Mon Aug 12 15:24:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEB7120DE1 for ; Mon, 12 Aug 2019 15:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] 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 YjX2TGlFUz9H for ; Mon, 12 Aug 2019 15:24:42 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640110.outbound.protection.outlook.com [40.107.64.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F35C12100A for ; Mon, 12 Aug 2019 11:08:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e/RzyePF+jTM773K0oQi5NCxvZiHeX/BOjfRkvrK27oZQA+VsrQwsF+gi3thLzEq+WH3UXNlcO+wXb9X1LORA3c8umZZQf6e7cS/GXAoTuLys9iUXdskLY6wei5Wi5KrSr/uvcnnaKnNCOY0PPOM3oHFBwNqX4MbjL2v/kRd9SZJhscAWv1MXagczlwefdl4WBx34+dHGGdrLF4gKqbKCy3s65uYhbNJkMZUjvEg2XgFvCBuD1JhMqgpPzmcTtv60PZpBCOgX7ctMhFuMeBjuF3btk+LjfI+IREdpJ1sbm47jFVzeu9CWlQ+B3oR9Lg4txcJNkjhZy/Ii1kyYJgv4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jS2OgaDvGICDF0mUk6/BY22utB2AFjRIyTlO+q7h9s4=; b=K9+fAfeiJO5HAyqWA9Sqn/zcd+R2ehI9XCVZLYgLCqjmvaL4dRIYV0OQHHIIoV8/XTHOdQpi7mA+5/Vse8b/Cvp10vFPgiYJvwT00LTeU+R2kkpa7g9hWQZsFrthX+FIduOeiklEBfR5s34OvVGUxNWXr26ghM/uE+ErXfnhVpnoKzG3w6F4nV2Lvc6Hrpz8NpULV+Fl9h5TR7XK0bV9EkR1MPD13zNUmzvQ5n/TPNsriOPHoMZlJORDah3WpPlMnGKEIktjt7INApBWk6JtwfD2qAAu5GWOX6OGUupISlB2okAZlvifmrzRt8gcOYCLv9mNjxaD2pPdKY3xrdFrHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jS2OgaDvGICDF0mUk6/BY22utB2AFjRIyTlO+q7h9s4=; b=d3sOSlYSpJSpW639K9GDHQcg34SygfXSxcpPQmIHsjJQvpsPXyvC9FbPu6q4cEu6O9uLAp9z96NTbouVgVLsu0C1LTLoUB88Pp22JNxXeAGZFZIzWPtHkS2fcUYdHu13b8ebKFVPRFLILbss221AicDN6aovDpfimTd+zVfshAE= Received: from CY1PR00MB0091.namprd00.prod.outlook.com (10.167.9.143) by CY1PR00MB0140.namprd00.prod.outlook.com (10.167.9.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2183.0; Mon, 12 Aug 2019 18:08:30 +0000 Received: from CY1PR00MB0091.namprd00.prod.outlook.com ([fe80::a17c:758a:c4dd:ab7c]) by CY1PR00MB0091.namprd00.prod.outlook.com ([fe80::a17c:758a:c4dd:ab7c%11]) with mapi id 15.20.2208.000; Mon, 12 Aug 2019 18:08:30 +0000 From: Anthony Nadalin To: Steinar Noem , Nat Sakimura CC: Mike Jones , OAuth WG Thread-Topic: [OAUTH-WG] Location and dates for next OAuth Security Workshop Thread-Index: AQHVQxqsq2lN3BMOX0W1/ljKGHD73qbbummAgAAIf4CAAAHogIAArDMAgBN92ICAAPVUgIAAYmKIgAACsoCAAuJgAIAAmjgAgAMlv9A= Date: Mon, 12 Aug 2019 18:08:30 +0000 Message-ID: References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> <119995fd-caad-c29d-7a8c-7eafe38054a0@yes.com> 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=tonynad@microsoft.com; x-originating-ip: [131.107.160.237] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18fb7e2f-ad4e-487e-a1f4-08d71f501506 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600158)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:CY1PR00MB0140; x-ms-traffictypediagnostic: CY1PR00MB0140:|CY1PR00MB0140: x-ms-exchange-transport-forked: True x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(366004)(396003)(136003)(39860400002)(53754006)(13464003)(189003)(199004)(2420400007)(71200400001)(15650500001)(71190400001)(52536014)(66574012)(14454004)(22452003)(64756008)(76116006)(66946007)(66556008)(66476007)(66446008)(33656002)(74316002)(7736002)(86362001)(186003)(81166006)(26005)(8676002)(81156014)(5070765005)(5660300002)(8936002)(25786009)(446003)(11346002)(486006)(476003)(7110500001)(14444005)(256004)(606006)(99286004)(7696005)(53546011)(6506007)(102836004)(2906002)(76176011)(4326008)(6436002)(54906003)(110136005)(790700001)(6116002)(316002)(6246003)(55016002)(53936002)(236005)(478600001)(3846002)(10290500003)(10090500001)(8990500004)(229853002)(66066001)(54896002)(9686003)(6306002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0140; H:CY1PR00MB0091.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hdy3LHEsjAHbjFPT07H6J2Zcu59kE5DDlO+5wHnWnrXzwpaL3c0IWWQrXQQhbASBbdNbNn+8ELgmX62qpk4ij8Yu7C8PSdu2QOFzqoqgAiW5tpv6nPojcfwPUtSbiwkKIqGIiL9aZgr2gqOslCYIQNqOcvm1dFqnn6jo1wn2/U27mCooYHp5G5YGrTljNvGHwOiOlDv/wTqSM2IUorAzrugJG7tWYahdeXAUrKifuqP2MIyqU0t84G2Ydg34cW+Ap8PH/DqNxl/AYoh1863og+QAQ3Bp7qNhSmr3t/Bu+cUDrIMhICm2JiI346H87FDWWlnVa8TnHQ9mLgIDl15ZERhbli9FQSEWDqOIzvfzoQ0ZKG04xl7M1SqUrgkKsi+OdTPq+7FJJUdgBwybNhLt6pndIzyMCh0CBLBTDZNsO/E= Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0091A787BC5A3C403097DE4DA6D30CY1PR00MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18fb7e2f-ad4e-487e-a1f4-08d71f501506 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2019 18:08:30.4536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DAMhUO4jC68GRMnCX2kTdLbLTKR5tJOkAr77v6tP6RZh4dVmN23Yeh1sO30KmHngPIDApTxR1X49MD/YvnaeAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0140 Archived-At: Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:24:48 -0000 --_000_CY1PR00MB0091A787BC5A3C403097DE4DA6D30CY1PR00MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IHlvdSB3ZXJlIHRvbyBwb2xpdGUgIQ0KDQpGcm9tOiBTdGVpbmFyIE5vZW0gPHN0ZWlu YXJAdWRlbHQubm8+DQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDEwLCAyMDE5IDExOjA0IEFNDQpU bzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+DQpDYzogQW50aG9ueSBOYWRhbGlu IDx0b255bmFkQG1pY3Jvc29mdC5jb20+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+OyBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBMb2NhdGlvbiBhbmQgZGF0ZXMgZm9yIG5leHQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3AN Cg0KVGhhdCBpcyBnb29kIHRvIGhlYXIsIE5hdC4NCkkgdHJpZWQgdG8gYmUgYXMgcG9saXRlIGFz IHBvc3NpYmxlIGluIG15IHJlc3BvbnNlLg0KDQpsw7hyLiAxMC4gYXVnLiAyMDE5IGtsLiAxMDo1 MiBza3JldiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFA Z21haWwuY29tPj46DQpJIHRoaW5rIFRvbnkgd2FzIGp1c3Qgam9raW5nIGFzIGl0IHdhcyBxdWl0 ZSBhIGhhc3NsZSBmb3IgYm90aCBvZiB1cyB0byBnZXQgdG8gR2rDuHZpayBmb3IgYW4gSVNPIG1l ZXRpbmcuDQoNCk9uIFRodSwgQXVnIDgsIDIwMTkgYXQgOTo1MCBQTSBTdGVpbmFyIE5vZW0gPHN0 ZWluYXJAdWRlbHQubm88bWFpbHRvOnN0ZWluYXJAdWRlbHQubm8+PiB3cm90ZToNCkhleSBBbnRo b255LiBHasO4dmlrIGlzIHBhcnQgb2YgTlROVSwgd2UgYXJlIHdhaXRpbmcgZm9yIGZlZWRiYWNr IGZyb20gdGhlbSA6KQ0KDQpJIHRoaW5rIFRyb25kaGVpbSBpcyBtb3JlIGFjY2Vzc2libGUgKHRy YXZlbCB0aW1lKSBhbmQgaGFzIG1vcmUgdG8gb2ZmZXIuDQoNCnRvci4gOC4gYXVnLiAyMDE5IGts LiAxNDo0MiBza3JldiBBbnRob255IE5hZGFsaW4gPHRvbnluYWQ9NDBtaWNyb3NvZnQuY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PjoNCkhv dyBhYm91dCB0aGUgVW5pdmVyc2l0eSBpbiBHam92aWsgPw0KR2V0IE91dGxvb2sgZm9yIEFuZHJv aWQ8aHR0cHM6Ly9ha2EubXMvZ2hlaTM2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGFuaWVsIEZldHQgPGRhbmllbGYrb2F1dGhA eWVzLmNvbTxtYWlsdG86ZGFuaWVsZiUyQm9hdXRoQHllcy5jb20+Pg0KU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgNywgMjAxOSAxMTo0Nzo1MSBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+OyBkYmFpZXJAbGVhc3Rwcml2 aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPiA8ZGJhaWVyQGxlYXN0 cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+DQpDYzogTWlr ZSBKb25lcyA8bWljaGFlbC5qb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBPQXV0aCBXRyA8b2F1dGhAaWV0 Zi4uLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBMb2NhdGlvbiBhbmQgZGF0ZXMgZm9yIG5leHQgT0F1dGggU2VjdXJpdHkgV29ya3Nob3ANCg0K Tm90IHlldCwgd2UgYXJlIHRhbGtpbmcgdG8gcG90ZW50aWFsIHZlbnVlcy4gSXQncyB2YWNhdGlv biB0aW1lIGluIE5vcndheSByaWdodCBub3csIHNvIHRoYXQgd2lsbCB0YWtlIGEgd2VlayBvciB0 d28gbW9yZS4NCg0KLURhbmllbA0KDQpBbSAwNy4wOC4xOSB1bSAxODowOSBzY2hyaWViIERpY2sg SGFyZHQ6DQpBcmUgd2UgcmVhZHkgdG8gcGljayBhIGRhdGU/DQoNCk9uIFRodSwgSnVsIDI1LCAy MDE5IGF0IDExOjMwIFBNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t PG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpBdWd1c3Qgd2lsbCBj b25mbGljdCB3aXRoIGhvbGlkYXkgdGltZSBmb3IgbW9zdCBFdXJvcGVhbnPigKYNCg0KSnVzdCBi ZWVuIHRvIFRyb25kaGVpbSBsYXN0IHdlZWsgLSBpdCB3YXMgbG92ZWx5IHdlYXRoZXIuDQoNCuKA lOKAlOKAlA0KRG9taW5pY2sNCg0KDQpPbiAyNS4gSnVseSAyMDE5IGF0IDIyOjE0OjI4LCBNaWtl IEpvbmVzIChtaWNoYWVsLmpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86bWljaGFlbC5qb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToN CkknbSBub3QgYXdhcmUgb2YgYW55IGNvbmZsaWN0cyBmb3IgYW55IG9mIHRoZSB0aHJlZSBzZXRz IG9mIGRhdGVzLg0KDQotLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBBYXJvbiBQYXJlY2tpDQpTZW50OiBUaHVyc2RheSwgSnVseSAy NSwgMjAxOSA0OjA3IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIExvY2F0aW9u IGFuZCBkYXRlcyBmb3IgbmV4dCBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcA0KDQpXZSdsbCBiZSBz byBwcm9kdWN0aXZlIHdpdGggb25seSA0IGhvdXJzIG9mIGRhcmtuZXNzIGV2ZXJ5IGRheSENCg0K QWxsIG9mIHRoZSBkYXRlcyB3b3JrIGZvciBtZSwgYnV0IEkgd291bGQgcHJlZmVyIHRoZSBKdWx5 IGRhdGVzIHNpbmNlIGl0J2xsIGJlIGVhc2llci9jaGVhcGVyIHRvIGJ1bmRsZSB0aGUgdHdvIHRy aXBzIGludG8gb25lLiAoSG9wZWZ1bGx5IHdlIGNvdWxkIGdldCB0aGUgT0F1dGggbWVldGluZyBk YXRlcyBlYXJseSBpbiB0aGUgd2VlayBhdCBJRVRGIHRoZW4pDQoNCk9uIFRodSwgSnVsIDI1LCAy MDE5IGF0IDM6MzcgUE0gRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+ICsxIHRvIEp1bHkgLyBBdWd1c3QuIE5p Y2VyIHdlYXRoZXIgaW4gdGhlIG5vcnRoIHRoZW4uID0pDQo+DQo+IE9uIFRodSwgSnVsIDI1LCAy MDE5IGF0IDExOjU2IEFNIERhbmllbCBGZXR0IDxkYW5pZWxmK29hdXRoQHllcy5jb208bWFpbHRv OmRhbmllbGYlMkJvYXV0aEB5ZXMuY29tPj4gd3JvdGU6DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+ IGl0IHNlZW1zIGxpa2UgdGhlcmUgaXMgYSByb3VnaCBjb25zZW5zdXMgb24gaGF2aW5nIHRoZSBu ZXh0IE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIGluIFRyb25kaGVpbSwgTm9yd2F5LiBXZSB3aWxs IHRoZXJlZm9yZSBzdGFydCB3aXRoIHRoZSBwbGFubmluZy4NCj4+DQo+PiBBZnRlciBjaGVja2lu ZyB2YXJpb3VzIGV2ZW50IGNhbGVuZGFycyBpdCBzZWVtcyBsaWtlIHRoZSBmb2xsb3dpbmcgZGF0 ZXMgYXJlIHN1aXRhYmxlOg0KPj4NCj4+IE1heSA3LTkNCj4+DQo+PiBKdWx5IDIyLTI0DQo+Pg0K Pj4gQXVndXN0IDMtNQ0KPj4NCj4+IEZpcnN0IGRhdGUgaXMgYmVmb3JlIEVJQyDigJgyMCB3aGlj aCBpcyBNYXkgMTItMTUgaW4gTXVuaWNoL0dlcm1hbnkuIFRoZSBsYXR0ZXIgdHdvIGRhdGVzIGFy ZSBiZWZvcmUvYWZ0ZXIgSUVURiAxMDggd2hpY2ggaXMgSnVseSAyNS0zMSwgTWFkcmlkL1NwYWlu Lg0KPj4NCj4+IFVubGVzcyBzb21lYm9keSByYWlzZXMgb2JqZWN0aW9ucyBiZWNhdXNlIG9mIGNv bmZsaWN0aW5nIGlkZW50aXR5L3NlY3VyaXR5IGV2ZW50cyB3ZSB3aWxsIHBpY2sgb25lIG9mIHRo ZXNlIGRhdGVzIGluIHRoZSBuZXh0IHR3byB3ZWVrcyBvciBzby4uLi4NCj4+DQo+PiAtRGFuaWVs DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KPj4gaHR0cHM6Ly93d3cNCj4+IC5pZXRmLm9yZzxodHRwczovL25hbTA2LnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmlldGYub3JnJmRh dGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAw ZjgwOGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MDEwNTcwODMxMzMyMDkwJnNkYXRhPURkV1pDb3BwVGpWWlRkdGd0JTJGRVI3TjU5SEht Y0tFc2xVOHpKWXdDQnowUSUzRCZyZXNlcnZlZD0wPiUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9h dXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbg0KPj4gZXMlNDBtaWNyb3NvZnQuY29t PGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGNDBtaWNyb3NvZnQuY29tJmRhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3Nv ZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgwOGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDEwNTcwODMxMzQyMDgzJnNkYXRhPVF3 RG1jZEFnVnpDU0QyaldnTGdiYyUyQnBQTWxkM2RWd29HVXl1azVIbGZUNCUzRCZyZXNlcnZlZD0w PiU3QzRjMDEwMWJjMWVkYzQwM2Q3YjBlMDhkNzExM2JlNzdmJTdDNzJmOTg4YmY4NmYxNA0KPj4g MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTk2ODIxMzA1MjA3OTc1JmFtcDtzZGF0 YT1kQW9rV1l4d0dXDQo+PiBTUlh5cnpzNFYlMkJXTVhjTUQ0ODJuaHlBUnQyOG1lNHhiRSUzRCZh bXA7cmVzZXJ2ZWQ9MA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy4NCj4gaWV0Zi5vcmc8aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZpZXRm Lm9yZyZkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRi MzQ3YTcwMGY4MDhkNzFkYmQzNjYxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNzAxMDU3MDgzMTM0MjA4MyZzZGF0YT1YZkdxSDRxVVdiUm1HVGNTJTJGSGgw ZCUyQmVOa21Rb3VmJTJCTGxYRU5XbUI3dFljJTNEJnJlc2VydmVkPTA+JTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMNCj4gJTQwbWlj cm9zb2Z0LmNvbTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzQSUyRiUyRjQwbWljcm9zb2Z0LmNvbSZkYXRhPTAyJTdDMDElN0N0b255bmFk JTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcwMGY4MDhkNzFkYmQzNjYxJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzAxMDU3MDgzMTM1MjA3 NiZzZGF0YT1jMkxab3hINGhScTZrTEFXQ2tDdDVSZVhuaWRhUW5lQ21DY0NhYkVhdWFvJTNEJnJl c2VydmVkPTA+JTdDNGMwMTAxYmMxZWRjNDAzZDdiMGUwOGQ3MTEzYmU3N2YlN0M3MmY5ODhiZjg2 ZjE0MWFmDQo+IDkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk5NjgyMTMwNTIwNzk3NSZh bXA7c2RhdGE9ZEFva1dZeHdHV1NSWHkNCj4gcnpzNFYlMkJXTVhjTUQ0ODJuaHlBUnQyOG1lNHhi RSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL25hbTA2Li4uc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpvbmVzJTQwbWljcm9zb2Z0 LmNvbSU3QzRjMDEwMWJjMWVkYzQwM2Q3YjBlMDhkNzExM2JlNzdmJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk5NjgyMTMwNTIwNzk3NSZhbXA7c2RhdGE9 ZEFva1dZeHdHV1NSWHlyenM0ViUyQldNWGNNRDQ4Mm5oeUFSdDI4bWU0eGJFJTNEJmFtcDtyZXNl cnZlZD0wPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRo JmRhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdh NzAwZjgwOGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MDEwNTcwODMxMzUyMDc2JnNkYXRhPTJwaGUwUFEySWVuJTJCRlQlMkJqd011ODcl MkJBOWJEQkRYaERONXNIajBpbXZZenMlM0QmcmVzZXJ2ZWQ9MD4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0My NDUwMDU1MGZkYjM0N2E3MDBmODA4ZDcxZGJkMzY2MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwMTA1NzA4MzEzNjIwNzAmc2RhdGE9a0ZLOUFLRmNYV1hT MkZGcElrNFg5VjBxSWlLZVFITjB5Zmc3ZTl4RDJqOCUzRCZyZXNlcnZlZD0wPg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jv c29mdC5jb20lN0MyNDUwMDU1MGZkYjM0N2E3MDBmODA4ZDcxZGJkMzY2MSU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwMTA1NzA4MzEzNjIwNzAmc2RhdGE9 a0ZLOUFLRmNYV1hTMkZGcElrNFg5VjBxSWlLZVFITjB5Zmc3ZTl4RDJqOCUzRCZyZXNlcnZlZD0w Pg0KLS0NClZlbm5saWcgaGlsc2VuDQoNClN0ZWluYXIgTm9lbQ0KUGFydG5lciBVZGVsdCBBUw0K U3lzdGVtdXR2aWtsZXINCg0KfCBzdGVpbmFyQHVkZWx0Lm5vPG1haWx0bzpzdGVpbmFyQHVkZWx0 Lm5vPiB8IGhlaUB1ZGVsdC5ubzxtYWlsdG86aGVpQHVkZWx0Lm5vPiAgfCArNDcgOTU1IDIxIDYy MCB8IHd3dy51ZGVsdC5ubzxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy51ZGVsdC5ubyUyRiZkYXRhPTAyJTdDMDElN0N0 b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcwMGY4MDhkNzFkYmQzNjYx JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzAxMDU3MDgz MTM2MjA3MCZzZGF0YT0lMkJqU1BRVDZpaHBabDhhdGtmalhxRFFzVUo4c2pTSE41dGJsRjYxQTFi SDAlM0QmcmVzZXJ2ZWQ9MD4gfA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZkYXRh PTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcwMGY4 MDhkNzFkYmQzNjYxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzAxMDU3MDgzMTM3MjA2NSZzZGF0YT1iUWxaV1dqNU1HREZsb2dTdUxuWVBwR0JyT0tIVndK dCUyRmw3MmJIM09neGslM0QmcmVzZXJ2ZWQ9MD4NCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0 KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88 aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAl M0ElMkYlMkZuYXQuc2FraW11cmEub3JnJTJGJmRhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgwOGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDEwNTcwODMxMzcyMDY1JnNkYXRh PWZoR3pzM3hwRVA0Y2xYVmhPQWhRdWRtQWpUR3NRZnFTUUluWUQ0b2ZYZ0klM0QmcmVzZXJ2ZWQ9 MD4NCkBfbmF0X2VuDQotLQ0KVmVubmxpZyBoaWxzZW4NCg0KU3RlaW5hciBOb2VtDQpQYXJ0bmVy IFVkZWx0IEFTDQpTeXN0ZW11dHZpa2xlcg0KDQp8IHN0ZWluYXJAdWRlbHQubm88bWFpbHRvOnN0 ZWluYXJAdWRlbHQubm8+IHwgaGVpQHVkZWx0Lm5vPG1haWx0bzpoZWlAdWRlbHQubm8+ICB8ICs0 NyA5NTUgMjEgNjIwIHwgd3d3LnVkZWx0Lm5vPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnVkZWx0Lm5vJTJGJmRhdGE9 MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgw OGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM3MDEwNTcwODMxMzgyMDU3JnNkYXRhPTlkSnUlMkZGQzZnNDA4dTF0RFc2OGFHZFRKbGpuQlpt SVc2SFR0eXFmbHd2TSUzRCZyZXNlcnZlZD0wPiB8DQo= --_000_CY1PR00MB0091A787BC5A3C403097DE4DA6D30CY1PR00MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm0yMDIyMjExODY1MzU0MzY3OTg3Z21haWwtbTU3MzQ0NDczMTc3OTI5OTEzMzdt LTc0NDAzNzMyNTg4NDUxNDE2NTBnbWFpbC1tMTM4NDAzODc0ODAxODIxOTYxMWFpcm1haWxvbiwg bGkubTIwMjIyMTE4NjUzNTQzNjc5ODdnbWFpbC1tNTczNDQ0NzMxNzc5Mjk5MTMzN20tNzQ0MDM3 MzI1ODg0NTE0MTY1MGdtYWlsLW0xMzg0MDM4NzQ4MDE4MjE5NjExYWlybWFpbG9uLCBkaXYubTIw MjIyMTE4NjUzNTQzNjc5ODdnbWFpbC1tNTczNDQ0NzMxNzc5Mjk5MTMzN20tNzQ0MDM3MzI1ODg0 NTE0MTY1MGdtYWlsLW0xMzg0MDM4NzQ4MDE4MjE5NjExYWlybWFpbG9uDQoJe21zby1zdHlsZS1u YW1lOm1fMjAyMjIxMTg2NTM1NDM2Nzk4N2dtYWlsLW1fNTczNDQ0NzMxNzc5Mjk5MTMzN21fLTc0 NDAzNzMyNTg4NDUxNDE2NTBnbWFpbC1tXzEzODQwMzg3NDgwMTgyMTk2MTFhaXJtYWlsX29uOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkga25vdyB5b3Ugd2VyZSB0b28gcG9saXRlICE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IFN0ZWluYXIgTm9lbSAmbHQ7c3RlaW5hckB1ZGVsdC5ubyZndDsgPGJyPg0K PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBdWd1c3QgMTAsIDIwMTkgMTE6MDQgQU08YnI+DQo8Yj5U bzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gQW50aG9ueSBOYWRhbGluICZsdDt0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7OyBNaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBPQXV0aCBXRyAmbHQ7 b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIExv Y2F0aW9uIGFuZCBkYXRlcyBmb3IgbmV4dCBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgZ29vZCB0byBoZWFyLCBOYXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdHJpZWQgdG8gYmUgYXMgcG9saXRlIGFzIHBvc3NpYmxlIGluIG15IHJlc3BvbnNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmzDuHIu IDEwLiBhdWcuIDIwMTkga2wuIDEwOjUyIHNrcmV2IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayBUb255IHdhcyBqdXN0IGpva2luZyBhcyBpdCB3YXMgcXVpdGUgYSBoYXNz bGUgZm9yIGJvdGggb2YgdXMgdG8gZ2V0IHRvIEdqw7h2aWsgZm9yIGFuIElTTyBtZWV0aW5nLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBBdWcgOCwgMjAxOSBhdCA5OjUwIFBNIFN0ZWluYXIgTm9lbSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnN0ZWluYXJAdWRlbHQubm8iIHRhcmdldD0iX2JsYW5rIj5zdGVpbmFyQHVkZWx0Lm5vPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhleSBBbnRob255LiBHasO4dmlrIGlzIHBhcnQgb2Yg TlROVSwgd2UgYXJlIHdhaXRpbmcgZm9yIGZlZWRiYWNrIGZyb20gdGhlbSA6KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgVHJvbmRoZWltIGlzIG1vcmUgYWNjZXNzaWJsZSAodHJhdmVsIHRpbWUpIGFuZCBoYXMgbW9y ZSB0byBvZmZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50b3IuIDguIGF1Zy4gMjAxOSBrbC4gMTQ6NDIgc2tyZXYgQW50aG9ueSBOYWRhbGlu ICZsdDt0b255bmFkPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SG93IGFib3V0IHRoZSBVbml2ZXJzaXR5IGluIEdqb3ZpayA/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5H ZXQNCjxhIGhyZWY9Imh0dHBzOi8vYWthLm1zL2doZWkzNiIgdGFyZ2V0PSJfYmxhbmsiPk91dGxv b2sgZm9yIEFuZHJvaWQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMjAyMjIxMTg2NTM1NDM2Nzk4N2dtYWlsLW1fNTczNDQ0NzMxNzc5 Mjk5MTMzN21fLTc0NDAzNzMyNTg4NDUxNDE2NTBkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IE9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGFuaWVsIEZldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYW5p ZWxmJTJCb2F1dGhAeWVzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhbmllbGYmIzQzO29hdXRoQHll cy5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCA3LCAyMDE5 IDExOjQ3OjUxIFBNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWls LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20i IHRhcmdldD0iX2JsYW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYmFp ZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMg Jmx0O21pY2hhZWwuam9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7OyBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi4uLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXYgaWQ9Im1fMjAyMjIxMTg2NTM1NDM2Nzk4N2dtYWlsLW1fNTczNDQ0 NzMxNzc5Mjk5MTMzN21fLTc0NDAzNzMyNTg4NDUxNDE2NTBkaXZScGx5RndkTXNnIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIExvY2F0aW9uIGFuZCBkYXRlcyBmb3IgbmV4dCBPQXV0aCBT ZWN1cml0eSBXb3Jrc2hvcDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBpZD0ibV8yMDIyMjExODY1MzU0MzY3OTg3Z21haWwtbV81NzM0NDQ3MzE3Nzky OTkxMzM3bV8tNzQ0MDM3MzI1ODg0NTE0MTY1MGRpdlJwbHlGd2RNc2ciPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHlldCwg d2UgYXJlIHRhbGtpbmcgdG8gcG90ZW50aWFsIHZlbnVlcy4gSXQncyB2YWNhdGlvbiB0aW1lIGlu IE5vcndheSByaWdodCBub3csIHNvIHRoYXQgd2lsbCB0YWtlIGEgd2VlayBvciB0d28gbW9yZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURh bmllbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbSAwNy4wOC4xOSB1bSAxODowOSBzY2hyaWViIERpY2sgSGFyZHQ6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFyZSB3ZSByZWFkeSB0byBwaWNrIGEgZGF0ZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjUsIDIwMTkgYXQgMTE6MzAgUE0gRG9t aW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BdWd1c3Qgd2lsbCBjb25m bGljdCB3aXRoIGhvbGlkYXkgdGltZSBmb3IgbW9zdCBFdXJvcGVhbnPigKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkp1c3QgYmVlbiB0byBUcm9uZGhl aW0gbGFzdCB3ZWVrIC0gaXQgd2FzIGxvdmVseSB3ZWF0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCU4oCU4oCUIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0ibTIwMjIyMTE4NjUzNTQzNjc5ODdnbWFpbC1tNTczNDQ0NzMxNzc5Mjk5MTMzN20tNzQ0 MDM3MzI1ODg0NTE0MTY1MGdtYWlsLW0xMzg0MDM4NzQ4MDE4MjE5NjExYWlybWFpbG9uIj4NCk9u IDI1LiBKdWx5IDIwMTkgYXQgMjI6MTQ6MjgsIE1pa2UgSm9uZXMgKDxhIGhyZWY9Im1haWx0bzpt aWNoYWVsLmpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1pY2hhZWwuam9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPikgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBh d2FyZSBvZiBhbnkgY29uZmxpY3RzIGZvciBhbnkgb2YgdGhlIHRocmVlIHNldHMgb2YgZGF0ZXMu DQo8YnI+DQo8YnI+DQotLSBNaWtlIDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tIDxicj4NCkZyb206IE9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBP biBCZWhhbGYgT2YgQWFyb24gUGFyZWNraQ0KPGJyPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMjUs IDIwMTkgNDowNyBQTSA8YnI+DQpUbzogRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208 L2E+Jmd0Ow0KPGJyPg0KQ2M6IE9BdXRoIFdHICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBMb2NhdGlvbiBhbmQgZGF0ZXMgZm9yIG5leHQgT0F1dGggU2Vj dXJpdHkgV29ya3Nob3AgPGJyPg0KPGJyPg0KV2UnbGwgYmUgc28gcHJvZHVjdGl2ZSB3aXRoIG9u bHkgNCBob3VycyBvZiBkYXJrbmVzcyBldmVyeSBkYXkhIDxicj4NCjxicj4NCkFsbCBvZiB0aGUg ZGF0ZXMgd29yayBmb3IgbWUsIGJ1dCBJIHdvdWxkIHByZWZlciB0aGUgSnVseSBkYXRlcyBzaW5j ZSBpdCdsbCBiZSBlYXNpZXIvY2hlYXBlciB0byBidW5kbGUgdGhlIHR3byB0cmlwcyBpbnRvIG9u ZS4gKEhvcGVmdWxseSB3ZSBjb3VsZCBnZXQgdGhlIE9BdXRoIG1lZXRpbmcgZGF0ZXMgZWFybHkg aW4gdGhlIHdlZWsgYXQgSUVURiB0aGVuKQ0KPGJyPg0KPGJyPg0KT24gVGh1LCBKdWwgMjUsIDIw MTkgYXQgMzozNyBQTSBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICYjNDM7MSB0byBKdWx5IC8gQXVndXN0LiBOaWNl ciB3ZWF0aGVyIGluIHRoZSBub3J0aCB0aGVuLiA9KSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24g VGh1LCBKdWwgMjUsIDIwMTkgYXQgMTE6NTYgQU0gRGFuaWVsIEZldHQgJmx0OzxhIGhyZWY9Im1h aWx0bzpkYW5pZWxmJTJCb2F1dGhAeWVzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhbmllbGYmIzQz O29hdXRoQHllcy5jb208L2E+Jmd0OyB3cm90ZToNCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgaXQgc2VlbXMgbGlrZSB0 aGVyZSBpcyBhIHJvdWdoIGNvbnNlbnN1cyBvbiBoYXZpbmcgdGhlIG5leHQgT0F1dGggU2VjdXJp dHkgV29ya3Nob3AgaW4gVHJvbmRoZWltLCBOb3J3YXkuIFdlIHdpbGwgdGhlcmVmb3JlIHN0YXJ0 IHdpdGggdGhlIHBsYW5uaW5nLg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWZ0ZXIg Y2hlY2tpbmcgdmFyaW91cyBldmVudCBjYWxlbmRhcnMgaXQgc2VlbXMgbGlrZSB0aGUgZm9sbG93 aW5nIGRhdGVzIGFyZSBzdWl0YWJsZToNCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE1h eSA3LTkgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSnVseSAyMi0yNCA8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBdWd1c3QgMy01IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IEZpcnN0IGRhdGUgaXMgYmVmb3JlIEVJQyDigJgyMCB3aGljaCBpcyBNYXkgMTItMTUgaW4g TXVuaWNoL0dlcm1hbnkuIFRoZSBsYXR0ZXIgdHdvIGRhdGVzIGFyZSBiZWZvcmUvYWZ0ZXIgSUVU RiAxMDggd2hpY2ggaXMgSnVseSAyNS0zMSwgTWFkcmlkL1NwYWluLg0KPGJyPg0KJmd0OyZndDsg PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyZndDsgVW5sZXNzIHNvbWVib2R5IHJhaXNlcyBvYmplY3Rpb25zIGJlY2F1c2Ug b2YgY29uZmxpY3RpbmcgaWRlbnRpdHkvc2VjdXJpdHkgZXZlbnRzIHdlIHdpbGwgcGljayBvbmUg b2YgdGhlc2UgZGF0ZXMgaW4gdGhlIG5leHQgdHdvIHdlZWtzIG9yIHNvLi4uLg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC1EYW5pZWwgPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gPGJyPg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0IDxicj4NCiZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPiA8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3PC9hPiA8YnI+DQomZ3Q7Jmd0OyAuPGEgaHJlZj0iaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZpZXRm Lm9yZyZhbXA7ZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0MyNDUwMDU1 MGZkYjM0N2E3MDBmODA4ZDcxZGJkMzY2MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzcwMTA1NzA4MzEzMzIwOTAmYW1wO3NkYXRhPURkV1pDb3BwVGpWWlRk dGd0JTJGRVI3TjU5SEhtY0tFc2xVOHpKWXdDQnowUSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPmlldGYub3JnPC9hPiUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDth bXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb24NCjxicj4NCiZndDsmZ3Q7IGVzJTxhIGhyZWY9 Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGNDBtaWNyb3NvZnQuY29tJmFtcDtkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWlj cm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcwMGY4MDhkNzFkYmQzNjYxJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzAxMDU3MDgzMTM0MjA4MyZhbXA7 c2RhdGE9UXdEbWNkQWdWekNTRDJqV2dMZ2JjJTJCcFBNbGQzZFZ3b0dVeXVrNUhsZlQ0JTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tPC9hPiU3QzRjMDEw MWJjMWVkYzQwM2Q3YjBlMDhkNzExM2JlNzdmJTdDNzJmOTg4YmY4NmYxNA0KPGJyPg0KJmd0OyZn dDsgMWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTk2ODIxMzA1MjA3OTc1JmFtcDth bXA7c2RhdGE9ZEFva1dZeHdHVzxicj4NCiZndDsmZ3Q7IFNSWHlyenM0ViUyQldNWGNNRDQ4Mm5o eUFSdDI4bWU0eGJFJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCA8YnI+DQomZ3Q7IDxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyPg0KJmd0 OyBPQXV0aCBtYWlsaW5nIGxpc3QgPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3PC9hPi4gPGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzQSUyRiUyRmlldGYub3JnJmFtcDtkYXRhPTAyJTdDMDElN0N0b255bmFk JTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcwMGY4MDhkNzFkYmQzNjYxJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzAxMDU3MDgzMTM0MjA4 MyZhbXA7c2RhdGE9WGZHcUg0cVVXYlJtR1RjUyUyRkhoMGQlMkJlTmttUW91ZiUyQkxsWEVOV21C N3RZYyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaWV0Zi5vcmc8L2E+JTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVs LkpvbmVzIDxicj4NCiZndDsgJTxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGNDBtaWNyb3NvZnQuY29tJmFtcDtk YXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRiMzQ3YTcw MGY4MDhkNzFkYmQzNjYxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNzAxMDU3MDgzMTM1MjA3NiZhbXA7c2RhdGE9YzJMWm94SDRoUnE2a0xBV0NrQ3Q1UmVY bmlkYVFuZUNtQ2NDYWJFYXVhbyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPjQw bWljcm9zb2Z0LmNvbTwvYT4lN0M0YzAxMDFiYzFlZGM0MDNkN2IwZTA4ZDcxMTNiZTc3ZiU3Qzcy Zjk4OGJmODZmMTQxYWYNCjxicj4NCiZndDsgOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 OTk2ODIxMzA1MjA3OTc1JmFtcDthbXA7c2RhdGE9ZEFva1dZeHdHV1NSWHk8YnI+DQomZ3Q7IHJ6 czRWJTJCV01YY01ENDgybmh5QVJ0MjhtZTR4YkUlM0QmYW1wO2FtcDtyZXNlcnZlZD0wIDxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDxi cj4NCk9BdXRoIG1haWxpbmcgbGlzdCA8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9 MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgw OGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM3MDEwNTcwODMxMzUyMDc2JmFtcDtzZGF0YT0ycGhlMFBRMkllbiUyQkZUJTJCandNdTg3JTJC QTliREJEWGhETjVzSGowaW12WXpzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9uYW0wNi4uLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZhbXA7 YW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNGMwMTAx YmMxZWRjNDAzZDdiMGUwOGQ3MTEzYmU3N2YlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2OTk2ODIxMzA1MjA3OTc1JmFtcDthbXA7c2RhdGE9ZEFva1dZeHdH V1NSWHlyenM0ViUyQldNWGNNRDQ4Mm5oeUFSdDI4bWU0eGJFJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9 MDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2Rh dGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAw ZjgwOGQ3MWRiZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MDEwNTcwODMxMzYyMDcwJmFtcDtzZGF0YT1rRks5QUtGY1hXWFMyRkZwSWs0WDlWMHFJ aUtlUUhOMHlmZzdlOXhEMmo4JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZvYXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0My NDUwMDU1MGZkYjM0N2E3MDBmODA4ZDcxZGJkMzY2MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwMTA1NzA4MzEzNjIwNzAmYW1wO3NkYXRhPWtGSzlBS0Zj WFdYUzJGRnBJazRYOVYwcUlpS2VRSE4weWZnN2U5eEQyajglM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIy MjIyMiI+VmVubmxpZyBoaWxzZW48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMyMjIyMjIiPlN0ZWluYXIgTm9lbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIy Ij5QYXJ0bmVyIFVkZWx0IEFTPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPlN5c3RlbXV0 dmlrbGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMjIyMjIyIj58Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnN0ZWluYXJAdWRlbHQubm8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNG RkZGQ0MiPnN0ZWluYXJAdWRlbHQubm88L3NwYW4+PC9hPiZuYnNwO3wmbmJzcDs8YSBocmVmPSJt YWlsdG86aGVpQHVkZWx0Lm5vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx MTU1Q0MiPmhlaUB1ZGVsdC5ubzwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyYjNDM7NDcN CiA5NTUgMjEgNjIwJm5ic3A7fCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnVkZWx0Lm5vJTJG JmFtcDtkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzI0NTAwNTUwZmRi MzQ3YTcwMGY4MDhkNzFkYmQzNjYxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNzAxMDU3MDgzMTM2MjA3MCZhbXA7c2RhdGE9JTJCalNQUVQ2aWhwWmw4YXRr ZmpYcURRc1VKOHNqU0hONXRibEY2MUExYkgwJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPnd3dy51ZGVsdC5ubzwvc3Bhbj48L2E+ Jm5ic3A7fCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q3RvbnluYWQl NDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgwOGQ3MWRiZDM2NjElN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDEwNTcwODMxMzcyMDY1 JmFtcDtzZGF0YT1iUWxaV1dqNU1HREZsb2dTdUxuWVBwR0JyT0tIVndKdCUyRmw3MmJIM09neGsl M0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwJTNBJTJGJTJGbmF0LnNha2ltdXJhLm9yZyUyRiZhbXA7ZGF0YT0wMiU3QzAx JTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0MyNDUwMDU1MGZkYjM0N2E3MDBmODA4ZDcxZGJk MzY2MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcwMTA1 NzA4MzEzNzIwNjUmYW1wO3NkYXRhPWZoR3pzM3hwRVA0Y2xYVmhPQWhRdWRtQWpUR3NRZnFTUUlu WUQ0b2ZYZ0klM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNh a2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5WZW5ubGlnIGhp bHNlbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM1MDAwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+ U3RlaW5hciBOb2VtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPlBhcnRuZXIgVWRlbHQg QVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3lzdGVtdXR2aWtsZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzIyMjIyMiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIi PnwmbmJzcDs8YSBocmVmPSJtYWlsdG86c3RlaW5hckB1ZGVsdC5ubyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6I0ZGRkZDQyI+c3RlaW5hckB1 ZGVsdC5ubzwvc3Bhbj48L2E+Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Im1haWx0bzpoZWlAdWRlbHQu bm8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+aGVpQHVkZWx0 Lm5vPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDt8Jm5ic3A7JiM0Mzs0Nw0KIDk1NSAyMSA2MjAmbmJz cDt8Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZ3d3cudWRlbHQubm8lMkYmYW1wO2RhdGE9MDIlN0Mw MSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMjQ1MDA1NTBmZGIzNDdhNzAwZjgwOGQ3MWRi ZDM2NjElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDEw NTcwODMxMzgyMDU3JmFtcDtzZGF0YT05ZEp1JTJGRkM2ZzQwOHUxdERXNjhhR2RUSmxqbkJabUlX NkhUdHlxZmx3dk0lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6IzExNTVDQyI+d3d3LnVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDt8Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR00MB0091A787BC5A3C403097DE4DA6D30CY1PR00MB0091namp_-- From nobody Mon Aug 12 20:24:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A336712006A for ; Mon, 12 Aug 2019 20:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.9 X-Spam-Level: X-Spam-Status: No, score=-14.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] 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 N3bXpG95UxBI for ; Mon, 12 Aug 2019 20:24:16 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by ietfa.amsl.com (Postfix) with SMTP id 96F9C12004A for ; Mon, 12 Aug 2019 20:24:16 -0700 (PDT) Received: (qmail 20001 invoked by uid 99); 13 Aug 2019 03:24:15 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Aug 2019 03:24:15 +0000 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 6501F84B4 for ; Tue, 13 Aug 2019 03:24:15 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id k2so20530054wrq.2 for ; Mon, 12 Aug 2019 20:24:15 -0700 (PDT) X-Gm-Message-State: APjAAAXe4fUkTbdcmzhV4hKjNuiVGbdPxBecSAgpAOWmZPt94PpJKtvK gm9YuukmLcBV1EAgWl9eQthUW6zdF3Sc2VXNCaglWA== X-Google-Smtp-Source: APXvYqw2Wq8PaSmeNKVuKrILeEgXi+hBYM0pjPla6WuI9cmjCNd2Ze0QgxrRBuNz1Go9Bp753w7TXFwZ5ZBlqiHIrkc= X-Received: by 2002:adf:fa01:: with SMTP id m1mr14175206wrr.254.1565666654737; Mon, 12 Aug 2019 20:24:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Querna Date: Mon, 12 Aug 2019 20:24:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Daniel Fett Cc: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 03:24:19 -0000 I've updated the dpop in go implementation to -02: https://github.com/pquerna/dpop Compared to implementing -01, because the same proof is used against the token requests and resource server access, it did generally simplify the implementation risk and complexity. Getting the private key fingerprint into the Access Token or introspect response seems like the highest barrier to wide adoption, and not something that a dpop library can directly tackle making easier -- but I don't have any magical ideas to make it better. On Mon, Jul 8, 2019 at 6:30 AM Daniel Fett wrote: > > All, > > In preparation for the meeting in Montreal, I just uploaded a new version of the DPoP draft: > https://tools.ietf.org/html/draft-fett-oauth-dpop-02 > > Please have a look and let me know what you think. We should make this a working group item soon. > > As you might have noticed, there is also a new version of the Security Best Current Practice draft: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > -Daniel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Aug 13 02:04:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA851200D6 for ; Tue, 13 Aug 2019 02:04:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 pWWUJMIT27kT for ; Tue, 13 Aug 2019 02:04:37 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 EE78812008C for ; Tue, 13 Aug 2019 02:04:36 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id o4so633666wmh.2 for ; Tue, 13 Aug 2019 02:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id :references:to:date; bh=OBfm7taRBYTPH4CGNgRCvy/cu3Xg/Pr7mpyuwS7frYs=; b=Bz3MsYg7Ufx5oJQ2oVhmjvvcrLMUHKHpfyVL8sj4lr9Ld9pHDxj0LoNXPBjXJAFCJw p7t4UwoioDAVQYG0iX8DHnrk5wf+xzTIbtqWMBWRkKLUQo7/v+94CpRy8xaU4Dza5z21 9SWGD1uIDM/1MLjFzkfplTRB9cqlqZBcKs+Fk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:references:to:date; bh=OBfm7taRBYTPH4CGNgRCvy/cu3Xg/Pr7mpyuwS7frYs=; b=uEMOmTG88remqY6bqe3/tafI63no4rzmWwu4BjWutZ0J7Pdrf0yzrIxZ5w8/5Gdhvf g9kkcsdwgtMqXsXA6X2GvsoYuu/0d4M6cz8nKPYMD7Vd0C+O+k/QBlX6W9NwA8ECy10n Zc+3k6OqQw/di+3D/zqPK8sTHfa3M2NqZnpmc4vKUa9fv2QH7QXqnq1xTf5OeAxYFsUH TwzFRmkXI4f9CzwCdn7dxEBE4ZWitOpAduqqNBZ5KwGzVzyPloo50LSChesef159Iq5s pt1faaNJuw2vwjDBMFofsOUSY05jKlc5X7pJO74hn1BTVwXgEf/XGNyh7GRYs8PJt+V+ O/ww== X-Gm-Message-State: APjAAAVT58irq7ZyAePOQ9ny9lrKHn00mTystk1HwxWRRY2TmM7a23Xu 5laJSpJRyp0peoPxsBRn9L4587gjYcN+C9/G51P7dukDxy/XfJtuPMZXRfbw6lEI/twXla8EbGi KNz3zTv3ziv4YlJtuKC00nwSNue3WZdEU58qoAROuNMRganojzyHLefq/IPWldA0= X-Google-Smtp-Source: APXvYqyHMXn7WiaRI7XobesXbKQtWHkSXDYtaFkZx6pgBt9WjJjkOCy+5+qwY7SMPm3qMbeDAlxrLA== X-Received: by 2002:a05:600c:d9:: with SMTP id u25mr1967967wmm.26.1565687075027; Tue, 13 Aug 2019 02:04:35 -0700 (PDT) Received: from [192.168.2.116] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id z2sm680371wmi.2.2019.08.13.02.04.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 02:04:34 -0700 (PDT) From: Neil Madden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <156568660565.24107.1708228686719919450.idtracker@ietfa.amsl.com> To: OAuth WG Date: Tue, 13 Aug 2019 10:04:31 +0100 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [OAUTH-WG] Updated version of draft-madden-jose-ecdh-1pu-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 09:04:40 -0000 Hi all, I've created a new version of my I-D on adding public key authenticated = encryption to JOSE to support JWT-based encrypted access tokens. https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 Version -02 removes the discussion of creating a two-way interactive = handshake protocol after discussion with Hannes. That's out of scope for = this WG and distracts from the main benefits of the draft, which are = summed up in these bullet points from the introduction: o The resulting message size is more compact as an additional layer of headers and base64url-encoding is avoided. A 500-byte payload when encrypted and authenticated with ECDH-1PU (with P-256 keys and "A256GCM" Content Encryption Method) results in a 1087-byte JWE in Compact Encoding. An equivalent nested signed-then- encrypted JOSE message using the same keys and encryption method is 1489 bytes (37% larger). o The same primitives are used for both confidentiality and authenticity, providing savings in code size for constrained environments. o The generic composition of signatures and public key encryption involves a number of subtle details that are essential to security [PKAE]. Providing a dedicated algorithm for public key authenticated encryption reduces complexity for users of JOSE libraries. o ECDH-1PU provides only authenticity and not the stronger security properties of non-repudiation or third-party verifiability. This can be an advantage in applications where privacy, anonymity, or plausible deniability are goals. I missed the IETF meeting unfortunately. I can put together a few slides = if anybody wants me to run through it? -- Neil > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-madden-jose-ecdh-1pu-02.txt > Date: 13 August 2019 at 09:56:45 BST > To: "Neil Madden" >=20 >=20 > A new version of I-D, draft-madden-jose-ecdh-1pu-02.txt > has been successfully submitted by Neil Madden and posted to the > IETF repository. >=20 > Name: draft-madden-jose-ecdh-1pu > Revision: 02 > Title: Public Key Authenticated Encryption for JOSE: = ECDH-1PU > Document date: 2019-08-13 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu-02.txt > Status: = https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ > Htmlized: = https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-madden-jose-ecdh-1pu-02 >=20 > Abstract: > This document describes the ECDH-1PU public key authenticated > encryption algorithm for JWE. The algorithm is similar to the > existing ECDH-ES encryption algorithm, but adds an additional ECDH > key agreement between static keys of the sender and recipient. This > additional step allows the recipient to be assured of sender > authenticity without requiring a nested signed-then-encrypted = message > structure. >=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 From nobody Tue Aug 13 03:39:05 2019 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 77D1312006F; Tue, 13 Aug 2019 03:38:55 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156569273540.24230.12383998714668932069@ietfa.amsl.com> Date: Tue, 13 Aug 2019 03:38:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 10:38:56 -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 Mutual TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-16.txt Pages : 31 Date : 2019-08-13 Abstract: This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-16 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 13 11:44:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B712018B for ; Tue, 13 Aug 2019 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up61MmxE-mpC for ; Tue, 13 Aug 2019 11:43:49 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 B4514120288 for ; Tue, 13 Aug 2019 11:43:49 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id c34so36385737otb.7 for ; Tue, 13 Aug 2019 11:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DqJix+N09zDgz9glAHHJYATPncoTVxZlYMLRakx+7JE=; b=Edn+QMnhdu1wOGxf1GSAsWUWUgB0Horr8QowP8biisBzkKgYQv1xGfwEMvEtqnlzgU er8d42yBMqmquPw+Q1o2y9j1pa/T98FlPTI7yKrJq4G6jLEi2MuwlOuQxQXHDXVC3vOE BPWr/bwJsHYI5CMemIEIgzB4o1AoUV76lFP1k= 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=DqJix+N09zDgz9glAHHJYATPncoTVxZlYMLRakx+7JE=; b=CmjFzjp8wE0ypxJFYRQhfen4O0HUNdya8E0q0hN4Wrg0g5LTzYpZ9xolziH6OfzJRP N9yiakQ8PyFapkcmQPR8HAZ3ELR2dXg0wicTyddFA583QSQ7uGSa3SgvnWCeE/Jzftif x7WMWmFlui0y0QUTnsLhSOa14eVueuqqEe6hlGIKYWGlaRyHBLRTnqczag8RvRKVw9XR 0cImGmaQzpIU2IXt/iU5EVaS9tkYmeINeZmNhQQOFojlqTClsjU9X3I9symuoDoBXIZQ JZkncVC0j+zhvqwbWbkXOKiOjiyy+3gUzCjEArOrvs8dgHgOTJ61jButOlRi6Is5kpyU YEng== X-Gm-Message-State: APjAAAWsZLN9dGIsS/YJS6hCsD8NrUZ0lm5cOwsBULWXOmVL2s0LZPAX RY46xzQwS8WMBdRDcxJFSx5QTRuesVhS3Td4x9Vim1samTcMgtG4wgYblS5kaEubmaDfxXFu1Yr r2lDfWIWbRGlmLw== X-Google-Smtp-Source: APXvYqw0NIOimQXeRD0oTGNrPfDYxaarQIAsYzDCMGwzr8evLZ/FdFNkSqSZ+L0T6qvEY9CxvxL32+XWNmY0suhhKR8= X-Received: by 2002:a6b:621a:: with SMTP id f26mr6294505iog.127.1565721828956; Tue, 13 Aug 2019 11:43:48 -0700 (PDT) MIME-Version: 1.0 References: <156450808245.14321.11139106487161414680@ietfa.amsl.com> In-Reply-To: <156450808245.14321.11139106487161414680@ietfa.amsl.com> From: Brian Campbell Date: Tue, 13 Aug 2019 12:43:22 -0600 Message-ID: To: Stewart Bryant Cc: gen-art@ietf.org, draft-ietf-oauth-resource-indicators.all@ietf.org, ietf@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000006eb6650590040530" Archived-At: Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-resource-indicators-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 18:43:54 -0000 --0000000000006eb6650590040530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review Stewart and my apologies for the slow response - I left on a longish summer family vacation the day before the review email hit my inbox. I've fixed the nit by using "JSON Web Token (JWT)" on that first use in the source controlled editor's xml version and it'll show up in the next draft revision. On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker < noreply@ietf.org> wrote: > Reviewer: Stewart Bryant > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-oauth-resource-indicators-05 > Reviewer: Stewart Bryant > Review Date: 2019-07-30 > IETF LC End Date: 2019-08-05 > IESG Telechat date: Not scheduled for a telechat > > Summary: A well written document ready for publication. It has one very > minor > nit that needs to be addressed at some point. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: JWT is not in the well known list and does not > seem > to be expanded on first use, > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006eb6650590040530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Stewart and my apologies for th= e slow response - I left on a longish summer family vacation the day before= the review email hit my inbox.

I've fixed the= nit by using "JSON Web Token (JWT)" on that first use in the sou= rce controlled editor's xml version and it'll show up in the next d= raft revision.
=C2=A0

On Tue, Jul 30, 2019 at 11:35 AM Stewar= t Bryant via Datatracker <noreply@ietf.org> wrote:
Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-oauth-resource-indicators-05
Reviewer: Stewart Bryant
Review Date: 2019-07-30
IETF LC End Date: 2019-08-05
IESG Telechat date: Not scheduled for a telechat

Summary: A well written document ready for publication.=C2=A0 It has one ve= ry minor
nit that needs to be addressed at some point.

Major issues: None

Minor issues: None

Nits/editorial comments:=C2=A0 JWT is not in the well known list and does n= ot seem
to be expanded on first use,



<= 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. --0000000000006eb6650590040530-- From nobody Wed Aug 14 12:24:39 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52963120DF1 for ; Wed, 14 Aug 2019 12:24:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OoPXx7jA73aX for ; Wed, 14 Aug 2019 12:24:36 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7DC120847 for ; Wed, 14 Aug 2019 12:24:36 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id t24so5361743oij.13 for ; Wed, 14 Aug 2019 12:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XE6S+wrsumSV0eD37za41HmbT5kzW0UswVv/pFaa/tU=; b=B0uIrS3blh2mjPIV8GKUYjSknCbuuZuVRCWwZwEDwFMo4jXxZx6ANEyZuWjQ745y+O sLKEBQW89cKK/w+kQtiU2VxmxLuoxEAn5RMq8wYpv5fxOht5oh/eo3iQL0e29v6SoOZU 7G/fX4fyh8J6O7lDd4TGsZRRLGAttC4oHpr04= 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=XE6S+wrsumSV0eD37za41HmbT5kzW0UswVv/pFaa/tU=; b=FUfnsy82trZrMVWEA/6TomqcLvUoc1NVzFZKyvO3ppWXG7SriKlcsInPR/6MdIb0Lb AKV6kxT4vpxe/+qXaeZhek/nmQZ6uTfJCPnmZNMf5rBHQGNlYxNWyomLkF2IAJeXYeFb JTmi5+hglzLZpnkq18AJj/EoxuRpHlogkSWAZDxjd7ImokkTJRvVHxbiQey9yZNyF8i5 UG0cNgj30pZTcCQB4R3/cpvR5sh8eUrjM04MXGxlc0gba/BDqcRSkHYOYKeJKX9/X/Di 7CVofjCLVYyXA+mybVoCewQ4mSR1dcYVTQtsx43koHjiT6h4ieMzFBgf6/uW/Nt8ie3o 1cpg== X-Gm-Message-State: APjAAAVHy+lSmwnu3ZActtcQftHwC/VggcTNU4TZE0zyEzOgUdDBgQ8t Kne5JgG1zPRND6+OBf5TAu2nc1p7vNNHTJeWo7upII2EAvWkPErDqdaxi4A4CxBvx3aUK5Y1dNw AmvSNp7zdzcdZqg== X-Google-Smtp-Source: APXvYqy5S87H6H+RggmEaeX7bRCe0uQe0XHGShL4BqNYYohnbToCH6v4kg0dOAwiAwAYnBkuG0Soa+PSxegDr+vjTgk= X-Received: by 2002:a02:9644:: with SMTP id c62mr938721jai.45.1565810675187; Wed, 14 Aug 2019 12:24:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 14 Aug 2019 13:24:09 -0600 Message-ID: To: Sascha Preibisch Cc: Daniel Fett , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000014a5d6059018b5c6" Archived-At: Subject: Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 19:24:38 -0000 --00000000000014a5d6059018b5c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It can be a bit of a balancing act to have examples that clearly and concisely demonstrate the target functionality of the document but do so in the context of an otherwise complete and valid protocol message that also shows best practices being adhered to. But I think in this case I agree that adding a code_verifier to that example is worthwhile to show one of the generally agreed on best practices being followed and it doesn't add too much bloat to the example. On Thu, Aug 1, 2019 at 2:44 PM Sascha Preibisch wrote: > Hi all! > > I am reading through the latest draft ( ... dpop-02). When I got to > the first example request (bullet 5.) I saw that only 'grant_type, > code, redirect_uri' are used. > > If I am not mistaken the recommendation is to generally use PKCE with > an authorization_code flow. Therefore, I wondered if the example > should also include a 'code_verifier'. > > Thanks, > Sascha > > On Mon, 8 Jul 2019 at 06:30, Daniel Fett wrote: > > > > All, > > > > In preparation for the meeting in Montreal, I just uploaded a new > version of the DPoP draft: > > https://tools.ietf.org/html/draft-fett-oauth-dpop-02 > > > > Please have a look and let me know what you think. We should make this = a > working group item soon. > > > > As you might have noticed, there is also a new version of the Security > Best Current Practice draft: > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > > > -Daniel > > _______________________________________________ > > 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.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000014a5d6059018b5c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It can be a bit of a balancing act to have examples that c= learly and concisely demonstrate the target functionality of the document b= ut do so in the context of an otherwise complete and valid protocol message= that also shows best practices being adhered to. But I think in this case = I agree that adding a code_verifier to that example is worthwhile to show o= ne of the generally agreed on best practices being followed and it doesn= 9;t add too much bloat to the example.
=C2=A0

On Thu, Aug 1, 2019 at 2:44 PM Sascha Preibisch <saschapreibisch@gmail.com> = wrote:
Hi all!
I am reading through the latest draft ( ... dpop-02). When I got to
the first example request (bullet 5.) I saw that only 'grant_type,
code, redirect_uri' are used.

If I am not mistaken the recommendation is to generally use PKCE with
an authorization_code flow. Therefore, I wondered if the example
should also include a 'code_verifier'.

Thanks,
Sascha

On Mon, 8 Jul 2019 at 06:30, Daniel Fett <danielf+oauth@yes.com> wrote:
>
> All,
>
> In preparation for the meeting in Montreal, I just uploaded a new vers= ion of the DPoP draft:
> https://tools.ietf.org/html/draft-fett-oa= uth-dpop-02
>
> Please have a look and let me know what you think. We should make this= a working group item soon.
>
> As you might have noticed, there is also a new version of the Security= Best Current Practice draft:
> https://tools.ietf.org/html/draf= t-ietf-oauth-security-topics-13
>
> -Daniel
> _______________________________________________
> 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. --00000000000014a5d6059018b5c6-- From nobody Fri Aug 16 21:56:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39A21201B7; Fri, 16 Aug 2019 21:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 R7fj_Qjh9-Ew; Fri, 16 Aug 2019 21:55:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5C4120113; Fri, 16 Aug 2019 21:55:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 44AEEB812D8; Fri, 16 Aug 2019 21:55:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190817045547.44AEEB812D8@rfc-editor.org> Date: Fri, 16 Aug 2019 21:55:47 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] =?utf-8?q?RFC_8628_on_OAuth_2=2E0_Device_Authorizatio?= =?utf-8?q?n_Grant?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 04:55:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8628 Title: OAuth 2.0 Device Authorization Grant Author: W. Denniss, J. Bradley, M. Jones, H. Tschofenig Status: Standards Track Stream: IETF Date: August 2019 Mailbox: wdenniss@google.com, ve7jtb@ve7jtb.com, mbj@microsoft.com, Hannes.Tschofenig@gmx.net Pages: 21 Characters: 46718 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-device-flow-15.txt URL: https://www.rfc-editor.org/info/rfc8628 DOI: 10.17487/RFC8628 The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Aug 17 00:03:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D42120025 for ; Sat, 17 Aug 2019 00:03:49 -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, DKIMWL_WL_HIGH=-0.001, 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 Fx-TAh4ytZFV for ; Sat, 17 Aug 2019 00:03:46 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (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 B7D00120020 for ; Sat, 17 Aug 2019 00:03:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntPD53/qcYpN6EGNv3XA7ahjjALT465qCBHBnOS9Sh6nJKMTHU0Ho/zca7goebOJkHpgMF4HiVe4znkK9ytQ5KMSLF6jNjbg6UB0khJIuLvmXKRPI1/of6G1569Lt4+YjS5fG2Wp4LV27bgEwf80tlqdJ5T6Jb6VF1n3UOmw4JKkzgI0fAMpHd+Wy03V2OyMkUC9BWhyzE4MXW2Vu05zEgOssQmmdejF90FvZ74rV7UFvGVwxiJi1TlN+2T5NtlVOEecpq4vnFjFsFm8COHggytkQUJW9GOscyyEcJFXrr6UCQKCwZCxKmSMVkDlx7uthMA0No/A2SlQ9XAzHpKh8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CSHv5X7Cce5iuRViGeMOU5qST5t+l+oh64HjUccSrsQ=; b=P4Xe6KUOreey2NVLLZo97z8MFzRlxYn9v38m1+WSnBSKx+vHE1WgGrEKyvmaKPXCmcuIfLQI2xufrv+VLfSalwFFr4T7gJYP/M1WW+zbmgjSsSAZYQOshxH0BWj1SX8mn9hYzVLSZHSfkGwZKiB4xUI/PhEh/NPK2Ltos+7dAV9uCfxCH0ikrborvV+ZOnamWYWEm4HLHGtyxd2WXpFnP6CZR1wxd/tHyvht8c/lsEMXRmxyA7Xy+mdcw+qwa4Z5RvBKNcZAz90NRkleZ7xObXFAe8atIlRKbsF8UdxN9iBYPq9ExMXZG4vPi2dXwOYILZfY/EsFbI3d85LgAcrECQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CSHv5X7Cce5iuRViGeMOU5qST5t+l+oh64HjUccSrsQ=; b=Idu5KW3zzxmSlGzYUTG0aFFbHTMx/0Y2a6YzhaRbh6P60SaGVAC8rEk0weHlrpGBg/eu/eTgb2ZNW2REyMl7EzDb3mPhzZKT3h+282K7/3LHe9Fl9j/XK550Uk/Pq+7xEw/ePjyGr9fmUPGU1rBvX5CpQwPGxfvxgIwL6vbjgBg= Received: from MN2PR00MB0576.namprd00.prod.outlook.com (20.178.255.149) by MN2PR00MB0575.namprd00.prod.outlook.com (20.178.255.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2225.0; Sat, 17 Aug 2019 07:03:28 +0000 Received: from MN2PR00MB0576.namprd00.prod.outlook.com ([fe80::686f:49df:5f45:9ed3]) by MN2PR00MB0576.namprd00.prod.outlook.com ([fe80::686f:49df:5f45:9ed3%2]) with mapi id 15.20.2225.000; Sat, 17 Aug 2019 07:03:28 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Device Flow is now RFC 8628 Thread-Index: AdVTpmGKPgMfY9cFTzi3WEqP1APMyg== Date: Sat, 17 Aug 2019 07:03:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a2978f6f-1827-493c-99c6-0000c3361fbf; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-08-15T20:15:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 79a20159-d297-43ab-56a1-08d722e10191 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600158)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MN2PR00MB0575; x-ms-traffictypediagnostic: MN2PR00MB0575: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0132C558ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(209900001)(54164003)(199004)(189003)(966005)(10090500001)(6306002)(76116006)(236005)(8990500004)(9686003)(55016002)(54896002)(14454004)(66446008)(64756008)(66556008)(66476007)(6916009)(5640700003)(6436002)(606006)(66946007)(99286004)(7696005)(86362001)(2906002)(14444005)(256004)(22452003)(316002)(33656002)(3846002)(6116002)(790700001)(66066001)(66574012)(5660300002)(52536014)(8936002)(2501003)(6506007)(26005)(81156014)(7736002)(81166006)(186003)(1730700003)(74316002)(8676002)(102836004)(53936002)(53376002)(478600001)(2351001)(25786009)(10290500003)(486006)(476003)(71190400001)(71200400001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0575; H:MN2PR00MB0576.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rfEGNZJ8AS+QcUsj6Bd4VqndhI4aolFlxdXXQOuwV2eTHR1QpV6J/z6vRcXrwikvUBOvhpxcpYwXgCeCPYxI1v1cYAabKVFMdvgDAVo/fyKX4WpDShha/iN14+SwZY3eixd3t6fdOqqBbPaJcQ/0TFmgBaG3EfWG2B8HHmM7zUU5Xq1fKUAKhXqTLHBH/6yYJdxxMGXsvUjc0NLYGu8ZQ5NMvHl1xUeIFQCP+jwnLe6Nk1nFc40/gochS7QBftGoOz7ENwDyOcnZRvEOryNQhgpjBtZxnHfuQ4DwoOnwWnkfH/8osAqTYYiSEWmdDgeG/84Z6Qc2/mh4MygwAeC1Rh9p2GjK8Lj/jWVGvD3DkD6rfL7uafUXH57py1OFSu3BEHto+jWK/0kqyUsbOawqbuKCLz3ncLhUfzZfGr2vgY8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0576F3B1B1DAE617771F8732F5AE0MN2PR00MB0576namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79a20159-d297-43ab-56a1-08d722e10191 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2019 07:03:28.3871 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Lz87dAr0yrct++9G2p7vdXOagKLnB/1O23nPhLyYlpE3eOTAFBCQ/j/y1kJav/CdK1MD6liRqH9TfcXTsIqbrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0575 Archived-At: Subject: [OAUTH-WG] OAuth Device Flow is now RFC 8628 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 07:03:50 -0000 --_000_MN2PR00MB0576F3B1B1DAE617771F8732F5AE0MN2PR00MB0576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Device Flow specification (recently renamed to be the OAuth 2.0 D= evice Authorization Grant specification) is now RFC 8628. The abstract describes the specification as: The OAuth 2.0 device authorization grant is designed for Internet-connected= devices that either lack a browser to perform a user-agent-based authoriza= tion or are input constrained to the extent that requiring the user to inpu= t text in order to authenticate during the authorization flow is impractica= l. It enables OAuth clients on such devices (like smart TVs, media console= s, digital picture frames, and printers) to obtain user authorization to ac= cess protected resources by using a user agent on a separate device. This specification standardizes an already widely-deployed pattern in produ= ction use by Facebook, ForgeRock, Google, Microsoft, Salesforce, and many o= thers. Thanks to all of you who helped make this existing practice an actu= al standard! -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D200= 1 and as @selfissued. --_000_MN2PR00MB0576F3B1B1DAE617771F8732F5AE0MN2PR00MB0576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Device Flow specification (recently rename= d to be the OAuth 2.0 Device Authorization Grant specification) is now RFC 8628.  = The abstract describes the specification as:

 

The OAuth 2.0 device auth= orization grant is designed for Internet-connected devices that either lack= a browser to perform a user-agent-based authorization or are input constra= ined to the extent that requiring the user to input text in order to authenticate during the authorization flow = is impractical.  It enables OAuth clients on such devices (like smart = TVs, media consoles, digital picture frames, and printers) to obtain user a= uthorization to access protected resources by using a user agent on a separate device.

 

This specification standardizes an already widely-de= ployed pattern in production use by Facebook, ForgeRock, Google, Microsoft,= Salesforce, and many others.  Thanks to all of you who helped make th= is existing practice an actual standard!

 

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

 

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

--_000_MN2PR00MB0576F3B1B1DAE617771F8732F5AE0MN2PR00MB0576namp_-- From nobody Sat Aug 17 04:59:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56455120088 for ; Sat, 17 Aug 2019 04:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uulAFIQwJnKz for ; Sat, 17 Aug 2019 04:59:52 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.100]) (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 B37F0120024 for ; Sat, 17 Aug 2019 04:59:52 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hyxN7-0003TA-Bo; Sat, 17 Aug 2019 13:59:49 +0200 From: Torsten Lodderstedt Message-Id: <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_896D9A43-A706-418D-99B2-4CD931B64860"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 17 Aug 2019 13:59:48 +0200 In-Reply-To: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> Cc: "oauth@ietf.org" To: "Schaar, R.M. (Remco) - Logius" References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 11:59:57 -0000 --Apple-Mail=_896D9A43-A706-418D-99B2-4CD931B64860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Remco, > On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius = wrote: >=20 > Hello, > =20 > I would like to request the OAuth2 working group on a clarification = for introspection, in particular regarding the semantics of the = =E2=80=98jti=E2=80=99 and =E2=80=98aud=E2=80=99 claims. The draft =E2=80=98= JWT Response for OAuth Token Introspection=E2=80=99 seems ambiguous in = relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 cause = this ambiguity. > =20 > RFC7662 specifies the =E2=80=98aud=E2=80=99 and =E2=80=98jti=E2=80=99 = parameters in relation to =E2=80=9Cfor the token=E2=80=9D. Note that the = wording in RFC7662 is somewhat implicit, we assume =E2=80=9Cthe token=E2=80= =9D is the (access) token being introspected. > RFC7519 specifies the =E2=80=98aud=E2=80=99 and =E2=80=98jti=E2=80=99 = parameters in relation to the JWT itself. The token in the context of = RFC7519 is the JWT containing the parameters. > =20 > The draft (draft-ietf-oauth-jwt-introspection-response-05) now = formulates the response to an introspection as a JWT. The content of the = JWT =E2=80=9CMAY furthermore contain all claims defined in RFC7662=E2=80=9D= . Now this raises the question to the meaning of the =E2=80=98aud=E2=80=99= and =E2=80=98jti=E2=80=99 parameters. > =20 > In line with RFC7519 the parameters would define a value for the = introspection response. On the other hand following RFC7662 for the = definition would define the value of the parameters as those of the = introspected token. RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different = representations for token data. In RFC 7519 the data is carried in the = token itself (which also means the format of the token is well-defined = and know to the RS) whereas RFC 7662 defines a way to inspect tokens via = an API provided by the AS. The latter is typically used in conjunction = with opaque tokens, i.e. the RS does not have a clue how to parse and = interpret the token. The token might just be a handle to a database = entry at the AS in this case.=20 This also means a JWT (RFC 7662) and the Introspection Response are = conceptually the same from a RSs perspective. > =20 > Now for the =E2=80=98aud=E2=80=99 parameter this will typically only = be an issue with multiple values for the audience. In the case of a = single intended audience the audience of the introspected (access) token = will normally be the same principal as the audience of the introspection = response JWT. Only for some use cases the value of =E2=80=99aud=E2=80=99 = may end up ambiguous. It should not. At most the RS must turn up in the list of the legit = recipient. At best the aud value is always the RS only (see = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.= 8.1.3) .=20 > The =E2=80=98jti=E2=80=99 parameter however will always be ambiguous. = As it is an identifier, it should differ for the introspected token and = the introspection response by definition. Hence the semantics of = =E2=80=98jti=E2=80=99 in a JWT introspection response is unclear. The = same can apply to the =E2=80=98iat=E2=80=99, =E2=80=98nbf=E2=80=99 and = =E2=80=98exp=E2=80=99 claims in a JWT introspection response. I don=E2=80=99t understand the difference you are making. All before = mentioned claims are related to the (abstract) access token. You may = think of the Introspection Response as _the_ JWT representation of the = access token produced by the AS for the RS. > =20 > Can someone clarify the semantics of claims in an introspection = response JWT that are defined in both RFC7662 and RFC7519? > =20 > Furthermore, the introspection response should use the =E2=80=98iss=E2=80= =99 and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion = (section 6.1). The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an = introspected token will typically be the same as those of the = introspection response. Hence a JWT access token cannot be distinguished = from an introspection response using =E2=80=98iss=E2=80=99 and =E2=80=98au= d=E2=80=99 as suggested in the draft.. > =20 > Introspection refers to JWT best-current-practice. The draft BCP = recommends using explicit typing of JWTs, however the draft JWT response = for introspection does not apply this recommendation and uses the = generic =E2=80=98application/jwt=E2=80=99 instead... The BCP has other = recommendations in section 3.12, but these may be insufficient to = distinguish a JWT access token from a JWT introspection response. Good point. The reason why the BCP recommends explicit typing is to = prevent replay in other contexts. In the end typing is a compelling = concept unfortunately not broadly used in the wild. So the JWT Introspection Response draft copes with that attack angle by = making iss and aud mandatory.=20 > =20 > How would people suggest to best distinguish a JWT (access) token from = a JWT introspection response? Why should you? One reason why we extended the Introspection Response = was to eliminate the difference between JWTs directly used as access = tokens and Introspection Responses. best regards, Torsten.=20 > =20 > Thank you in advance for your response. > =20 > Kind regards, > Remco Schaar > Logius >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien = u niet de geadresseerde bent of dit bericht abusievelijk aan u is = toegezonden, wordt u verzocht dat aan de afzender te melden en het = bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor = schade, van welke aard ook, die verband houdt met risico's verbonden aan = het elektronisch verzenden van berichten. > This message may contain information that is not intended for you. If = you are not the addressee or if this message was sent to you by mistake, = you are requested to inform the sender and delete the message. The State = accepts no liability for damage of any kind resulting from the risks = inherent in the electronic transmission of messages.=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_896D9A43-A706-418D-99B2-4CD931B64860 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA4MTcxMTU5NDhaMC8GCSqGSIb3DQEJBDEiBCAuQgb4VsGO7OVFv2Dr98jajvvcRs/HaPdz wRzIYMUjbjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAGLduYwQXWHkry150A4HWQBhso0kGi3jb9+oM/ijohcspO3fffh9vpatUs6t Kt3CxR/tDim1j4SWk4WkvUfZk36bc2C2cXABOvgIhfOwT+//nEBpZLMzoZJEsefQsJQ5MPKUmJm2 3pQY2/c4WPC1sTatLBOfd1x0aSgibRtymP4Rh30c8VHy2iopjz9lkTnRjD65kuFHD8WWaeIEbj4R wGw6D4f0+4qhr4/gcixV/9NUBw8C4zjjiaSZyP6sNTV+W8TjUehrYziaA2/GhDTC91jUW/A04tuL pwtJqgxB3yzF1T3BMDqGaAcTkEonDT3ZHr8DdVdoT8DP4HxlPeYPQLkAAAAAAAA= --Apple-Mail=_896D9A43-A706-418D-99B2-4CD931B64860-- From nobody Sat Aug 17 10:23:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47F120145 for ; Sat, 17 Aug 2019 10:23:40 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 eGSqwWIF4ca6 for ; Sat, 17 Aug 2019 10:23:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 01FEC1200D7 for ; Sat, 17 Aug 2019 10:23:38 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7HHLf6o022891 for ; Sat, 17 Aug 2019 18:23:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=dnkHmDw3ZnLK5N4tEjVxtI/f6vgbM7S1AvRTVsO2TdA=; b=Zgf3u8vIw1Vn6ftIsmlRL3nET4CcQd/tqTHLXN/agyt8damLJkoWbLUbEkbcX7/9RbXy EeDQPwkwIe16W3D4OnotwsustH7Yk09izuWOAJl08YZg1H22iJ8suRD59NAUkNrfGJBj DCxMH1uj3fwk3iVDd6y61KYEt6AMl9FWoIg3tMDBozpSN8Q+Ej54QjjHSzP4cILENWWZ gUwkvyecrA5AJtVtCOauEdBThL5BJboIxSMEylI5YhrBM/e/CbSG63MNZ0RVPj2E02u/ xe7tUEj8aHUv1d4wawnMm1cxGkM4mykZMeCNaulV5dfEv4cp8UupKXr7FTANF180gkDw NA== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ue97tt816-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 17 Aug 2019 18:23:37 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7HHH7Zt000542 for ; Sat, 17 Aug 2019 13:23:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2uecwyd5d8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 17 Aug 2019 13:23:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 17 Aug 2019 13:23:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sat, 17 Aug 2019 13:23:34 -0400 From: "Salz, Rich" To: "oauth@ietf.org" Thread-Topic: Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzg== Date: Sat, 17 Aug 2019 17:23:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.94] Content-Type: multipart/alternative; boundary="_000_D3FB59752448445B8B480A46D43E0A99akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=563 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908170188 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-17_08:2019-08-16,2019-08-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=554 impostorscore=0 mlxscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908170189 Archived-At: Subject: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 17:23:40 -0000 --_000_D3FB59752448445B8B480A46D43E0A99akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdOKAmXMgdGhlIFdHIGNvbnNlbnN1cyAoaGVoKSBvbiB0aGUgYmVzdCBndWlkZSB0byBhZGRp bmcgT0FVVEggc3VwcG9ydCB0byBhbiBleGlzdGluZyBzZXJ2ZXIgc28gdGhhdCBpdCBjYW4gYWN0 IGFzIGFuIGlkZW50aXR5IHByb3ZpZGVyPyAgV2hpY2ggdmVyc2lvbiBvZiBvYXV0aCBpcyBtb3N0 IHdpZGVseSBkZXBsb3llZCBieSByZWx5aW5nIHBhcnRpZXMgdGhlc2UgZGF5cz8NCg0KSSB3YW50 IHRvIGFkZCBPQVVUSCBzdXBwb3J0IHRvIHRoZSBJRVRGIGRhdGF0cmFja2VyLg0KDQpUaGFua3Mg Zm9yIGFueSBwb2ludGVycy4gIFJlcGxpZXMgdG8gbWUgd2lsbCBiZSBzdW1tYXJpemVkIGZvciB0 aGUgbGlzdC4NCg0KICAgICAgICAgICAgICAgIC9yJA0KDQo= --_000_D3FB59752448445B8B480A46D43E0A99akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5XaGF04oCZcyB0aGUgV0cgY29uc2Vuc3VzIChoZWgpIG9uIHRoZSBiZXN0IGd1 aWRlIHRvIGFkZGluZyBPQVVUSCBzdXBwb3J0IHRvIGFuIGV4aXN0aW5nIHNlcnZlciBzbyB0aGF0 IGl0IGNhbiBhY3QgYXMgYW4gaWRlbnRpdHkgcHJvdmlkZXI/Jm5ic3A7IFdoaWNoIHZlcnNpb24g b2Ygb2F1dGggaXMgbW9zdCB3aWRlbHkgZGVwbG95ZWQgYnkgcmVseWluZyBwYXJ0aWVzDQogdGhl c2UgZGF5cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgd2Fu dCB0byBhZGQgT0FVVEggc3VwcG9ydCB0byB0aGUgSUVURiBkYXRhdHJhY2tlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyBmb3IgYW55IHBvaW50ZXJz LiZuYnNwOyBSZXBsaWVzIHRvIG1lIHdpbGwgYmUgc3VtbWFyaXplZCBmb3IgdGhlIGxpc3QuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgL3IkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3FB59752448445B8B480A46D43E0A99akamaicom_-- From nobody Sat Aug 17 11:30:42 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A839C12006D for ; Sat, 17 Aug 2019 11:30:40 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zvgamqBlbDsw for ; Sat, 17 Aug 2019 11:30:38 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 5EEAF120041 for ; Sat, 17 Aug 2019 11:30:38 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 125so7476925qkl.6 for ; Sat, 17 Aug 2019 11:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=f+udEwfrgYuckxhLaunIf3FH7q2tfzsDWHZRoBU1XT0=; b=0Z+FA+ODknGoG7jAWcCDtECNAxE2Uuur55NY3u45qqwRwlc12lhZ8yi67y2hV2ZyY0 PqUlDuiWWIKfkaAsElwsMyTJtqA8HBWfMqPaBbuR2ffEmQQAWoZ1bipbp8REgDeCeY7k w5klkiRqPPkIRI2OlraJtDelcpCNk6TUrj3dljuBFGbPTZUvJ8Zlp/zvcTkdQw0ryT3G 8iDKzlS7MkEK5tuwnBU8M6xBMMeOu2ywSoZP6P8SQYB3/GzEm9ErWwjKqhxyhY86lluf 7UfYqiyl7QxbQt/v1/2e+CdFwRm9vfl8Tnev4Cstqbh4qm0k4A/o1+R7fYDGqg/7QLNC AV/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=f+udEwfrgYuckxhLaunIf3FH7q2tfzsDWHZRoBU1XT0=; b=M3qytzdGD6dEniXuEbopXzr3LqT+vUdtbc+m8jerqFLcYqbOJVPSAVlbfbDUXnDBZA wCHACjJk8SJebv2XDF/phOcWGc1XI5Sk/pARPtTtMz565TQhNQYU4qOQtPPVVORyDqS/ MUI1UiEGd6WoLxe15ekj+VAg/GdmHo6uImk1TZXGo4K1NLfVvx7lJ+PejmFYQHgfEBgg rNKdSmVDJfEJ+4YLBmzjPLIuK5KY0VaPFuuGEI+1JXnNbPN9LNnX7pw1d/qiTDeSnLEs hLRtq/L/Qrf6PiHb5CC3roHrvyfRzJxPpSz1+M4zAqK+sSlUHHkCSjbMs6EkaazQ8H18 N0XQ== X-Gm-Message-State: APjAAAVtzFsp/3sLMsyxMITM/wUBwuIGpWZoTPafBNrhyG+28kyF4sdI h9mkbO/q3lOAl3Fcxg3c2sHd/dSGh/zy70+5 X-Google-Smtp-Source: APXvYqxEqpasMTaK/zrtWg7deVgSALvECZKV9OpiOSCyTq/298VBe7KkrJ1bvMjSys2q2iLWk27Tmw== X-Received: by 2002:a37:6248:: with SMTP id w69mr14248978qkb.225.1566066636679; Sat, 17 Aug 2019 11:30:36 -0700 (PDT) Received: from [192.168.8.103] ([181.203.52.123]) by smtp.gmail.com with ESMTPSA id t124sm4741926qke.31.2019.08.17.11.30.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Aug 2019 11:30:35 -0700 (PDT) To: oauth@ietf.org References: From: John Bradley Message-ID: Date: Sat, 17 Aug 2019 14:30:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2A3F2B903D4D83B50B86A37C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 18:30:41 -0000 This is a multi-part message in MIME format. --------------2A3F2B903D4D83B50B86A37C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit The openID Connect kind of OAuth server. OAuth on its own is not designed to be secure for identity federation. John B. On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What’s the WG consensus (heh) on the best guide to adding OAUTH > support to an existing server so that it can act as an identity > provider?  Which version of oauth is most widely deployed by relying > parties these days? > >   > > I want to add OAUTH support to the IETF datatracker. > >   > > Thanks for any pointers.  Replies to me will be summarized for the list. > >   > >                 /r$ > >   > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2A3F2B903D4D83B50B86A37C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The openID Connect kind of OAuth server.

OAuth on its own is not designed to be secure for identity federation.

John B.

On 8/17/2019 1:23 PM, Salz, Rich wrote:

What’s the WG consensus (heh) on the best guide to adding OAUTH support to an existing server so that it can act as an identity provider?  Which version of oauth is most widely deployed by relying parties these days?

 

I want to add OAUTH support to the IETF datatracker.

 

Thanks for any pointers.  Replies to me will be summarized for the list.

 

                /r$

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------2A3F2B903D4D83B50B86A37C-- From nobody Sat Aug 17 11:34:19 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0110A120041 for ; Sat, 17 Aug 2019 11:34: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx6x6fYHdZdh for ; Sat, 17 Aug 2019 11:34:15 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 8E27E120048 for ; Sat, 17 Aug 2019 11:34:15 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id m2so7448979qki.12 for ; Sat, 17 Aug 2019 11:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfRD5dbWJGSmONY2YMtWRioQgcRIXpAPjmKKAZLMcdc=; b=od+0Zk6yQJlN49VTzmoPmf7aeQgmgmRYlv/6Y0FM3wKyPE8GIAiZZ3iZinDSS1hm21 SlRi93NyeLuJ/lI7/ecRmZ+9yyM69Ek8MMt1XhgcTO6J+VP4qF+zuQejzNyyavEWhg8p RD0BYiDugZMPGg6M+pNsB5K834Tug/YmvmPl/+ShEnXrgmguhjpeAv1kNlcPAdCwpgHo lVgQx29ScmsEurCac3zzTO9Q3qIjrPyJ3r1i8DElWlCHMFbuLhKeaaL2FuDtPY329KMi 5YXoBy+0quzR3e7Uqm/+R3bM7iG57jg3WvRraAsa2aXZkk2zcc8vfOUlgtwSfwR9ft1J 5YUQ== 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=DfRD5dbWJGSmONY2YMtWRioQgcRIXpAPjmKKAZLMcdc=; b=PtN5NFgfLQBs3VgWNNJ3OMzI73p0bGPSQzcnXpI2UpqhTaWsKdELLCGc8jk3sgT5Jz azCn65VsO/r/darwmvBsYKHviUQGNd9DJo5F5AlfFis0QNqlAKIUaC/XN2PeQJX3XIfa vRKs/iRqpRhoWi0VuEWbpwdP0FbWYOCTSwz4zqo56MZ8pMF4UVJ2tzSRu7lUEyYyGcKb IAcX4Svf1yWh5PBECxeusRgG1uNnXbgscjtVPgBix/kMZe1gHq+btLzLjdn6UpjcEq+x 6ebFQjSXIWyG79IYuJkMcEkm3OX98Bzxi8ULRhr2iQmnVollmPzqNkpfk9HgffDMcx21 ARfA== X-Gm-Message-State: APjAAAVwWQZvd9kEfe7gP/aHciHNkg0oD4qTEwsI981HhxGw0RhvLfAC 35gNMC90sEI+fuIwMY3UYH/tH21IcqsEM1yyuEUnixQMGms= X-Google-Smtp-Source: APXvYqyE7xeeC1tE5U6YMRYvch1ievaKfhfVXbRGig9gaBd4uPO7suqXL0UBTgIUIzNvZ3Pdzu/+U0jtXo3oCxrBIUM= X-Received: by 2002:a37:a2d1:: with SMTP id l200mr14461879qke.63.1566066854637; Sat, 17 Aug 2019 11:34:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Sat, 17 Aug 2019 20:34:03 +0200 Message-ID: To: John Bradley Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000090c1ab0590545a93" Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 18:34:18 -0000 --00000000000090c1ab0590545a93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable indeed OAuth !=3D identity see https://oauth.net/articles/authentication/ Hans. On Sat, Aug 17, 2019 at 8:31 PM John Bradley wrote: > The openID Connect kind of OAuth server. > > OAuth on its own is not designed to be secure for identity federation. > > John B. > On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What=E2=80=99s the WG consensus (heh) on the best guide to adding OAUTH s= upport to > an existing server so that it can act as an identity provider? Which > version of oauth is most widely deployed by relying parties these days? > > > > I want to add OAUTH support to the IETF datatracker. > > > > Thanks for any pointers. Replies to me will be summarized for the list. > > > > /r$ > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --00000000000090c1ab0590545a93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
indeed OAuth !=3D identity see=C2=A0https://oauth.net/articles/authentication/=

Hans.

On Sat, Aug 17, 2019 at 8:31 PM John Bra= dley <ve7jtb@ve7jtb.com> wro= te:
=20 =20 =20

The openID Connect kind of OAuth server.

OAuth on its own is not designed to be secure for identity federation.

John B.

On 8/17/2019 = 1:23 PM, Salz, Rich wrote:
=20 =20 =20

What=E2=80=99= s the WG consensus (heh) on the best guide to adding OAUTH support to an existing server so that it can act as an identity provider?=C2=A0 Which version of oauth is most widely deployed = by relying parties these days?

=C2=A0=

I want to add OAUTH support to the IETF datatracker.=

=C2=A0=

Thanks for any pointers.=C2=A0 Replies to me will be summarized for the list.

=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 /r$

=C2=A0=


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


--
--00000000000090c1ab0590545a93-- From nobody Sun Aug 18 12:41:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F21200B8 for ; Sun, 18 Aug 2019 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 X0_XtwUjdImq for ; Sun, 18 Aug 2019 12:41:06 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E5A841201E4 for ; Sun, 18 Aug 2019 12:41:06 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7IJb4Na019161; Sun, 18 Aug 2019 20:41:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=TH2tpcL/214BA0dI7CPvzeXXqtgjugEZ0x/E6BhjbSY=; b=Ypzvrl8tb9chDlyHvkM6tufC8zO/3qBIMDV0/nIjBEoa3I8v472MLvLLSdJQef1IvwxW 9oAjG6SxapuckUqNM//JkPEpXLaTA+HPZvjooe9+UKlPoD7zXJKkJtO5lWDvlTCjO3gO gTcbCe6dUQ/l5zo6jE8e5fzW0oJpqAOz2z2IGf1uxZdlz1OWdPk74RRWQ6QaC+9dfdnl RT7ji7HGZNWw81/axkxRX1YK8NXGBFDf8JdQE79q1U4/hRkX0RVGX6Dpw54z2qxaNRlK eHTQKcwOMeZrtxQ/qjWY9usdhvTZk33g2+ifVwKRdT1Ocr+SayVjrzoGxJ0/6c1jd4/+ XA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2ue8u6x3uc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 20:41:05 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7IJWAGq029222; Sun, 18 Aug 2019 12:41:04 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 2uefj92b3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 12:41:04 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 15:41:03 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sun, 18 Aug 2019 15:41:03 -0400 From: "Salz, Rich" To: Hans Zandbelt , John Bradley CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzqb/7IKAgAAA+4CAAWH9AA== Date: Sun, 18 Aug 2019 19:41:02 +0000 Message-ID: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.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.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: multipart/alternative; boundary="_000_74BEF7B555AC4BD6AEF1D04DEFE9F0EAakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_08:, , signatures=0 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-1906280000 definitions=main-1908180216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_08:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 spamscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180217 Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 19:41:09 -0000 --_000_74BEF7B555AC4BD6AEF1D04DEFE9F0EAakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgbGlua3MsIGZvbGtzLiAgSeKAmW0gYXdhcmUsIGFuZCBzb3JyeSBmb3Ig bXkgc2xvcHB5IHRlcm1pbm9sb2d5Lg0KDQpJbWFnaW5lIGEgc2VydmljZSB3aGVyZSBhbnlvbmUg d2l0aCBhIHZhbGlkIGlkZW50aXR5IGlzIGF1dGhvcml6ZWQuIFRoZXJlIGFyZSBtYW55IG9mIHRo ZXNlIG9uIHRoZSBuZXQuIENvbGxhcHNpbmcgYXV0aGVudGljYXRpb24gdG8gYXV0aG9yaXphdGlv biAo4oCcZXZlcnlvbmUgYXV0aGVudGljYXRlZCBpcyBhdXRob3JpemVk4oCdKSBzZWVtcyBub3Qg dW5yZWFzb25hYmxlLg0KDQpCdXQgSSBkb27igJl0IHdhbnQgdG8gZ2V0IGRpc3RyYWN0ZWQgZnJv bSBteSBtYWluIGdvYWwuICBUaGFua3MuDQoNCkZyb206IEhhbnMgWmFuZGJlbHQgPGhhbnMuemFu ZGJlbHRAem1hcnR6b25lLmV1Pg0KRGF0ZTogU2F0dXJkYXksIEF1Z3VzdCAxNywgMjAxOSBhdCAy OjM0IFBNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4NCkNjOiAib2F1dGhA aWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEluZm8g b24gaG93IHRvIGltcGxlbWVudCBhIHNlcnZlcg0KDQppbmRlZWQgT0F1dGggIT0gaWRlbnRpdHkg c2VlIGh0dHBzOi8vb2F1dGgubmV0L2FydGljbGVzL2F1dGhlbnRpY2F0aW9uLzxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX29hdXRoLm5ldF9hcnRp Y2xlc19hdXRoZW50aWNhdGlvbl8mZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9 NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPVFOTktfTVk5ckZreE9IOGtUWTVMYjlYemFvY256cUhm RTJReTFzMXJLSVEmcz1TM2hOUlpOLUY3M1ZOcjJscy15S040YkpQU3VINHc5MlNtRmMxUEF2aTRN JmU9Pg0KDQpIYW5zLg0KDQpPbiBTYXQsIEF1ZyAxNywgMjAxOSBhdCA4OjMxIFBNIEpvaG4gQnJh ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6 DQoNClRoZSBvcGVuSUQgQ29ubmVjdCBraW5kIG9mIE9BdXRoIHNlcnZlci4NCg0KT0F1dGggb24g aXRzIG93biBpcyBub3QgZGVzaWduZWQgdG8gYmUgc2VjdXJlIGZvciBpZGVudGl0eSBmZWRlcmF0 aW9uLg0KDQpKb2huIEIuDQpPbiA4LzE3LzIwMTkgMToyMyBQTSwgU2FseiwgUmljaCB3cm90ZToN CldoYXTigJlzIHRoZSBXRyBjb25zZW5zdXMgKGhlaCkgb24gdGhlIGJlc3QgZ3VpZGUgdG8gYWRk aW5nIE9BVVRIIHN1cHBvcnQgdG8gYW4gZXhpc3Rpbmcgc2VydmVyIHNvIHRoYXQgaXQgY2FuIGFj dCBhcyBhbiBpZGVudGl0eSBwcm92aWRlcj8gIFdoaWNoIHZlcnNpb24gb2Ygb2F1dGggaXMgbW9z dCB3aWRlbHkgZGVwbG95ZWQgYnkgcmVseWluZyBwYXJ0aWVzIHRoZXNlIGRheXM/DQoNCkkgd2Fu dCB0byBhZGQgT0FVVEggc3VwcG9ydCB0byB0aGUgSUVURiBkYXRhdHJhY2tlci4NCg0KVGhhbmtz IGZvciBhbnkgcG9pbnRlcnMuICBSZXBsaWVzIHRvIG1lIHdpbGwgYmUgc3VtbWFyaXplZCBmb3Ig dGhlIGxpc3QuDQoNCiAgICAgICAgICAgICAgICAvciQNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29h dXRoJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0 c0tJLXcmbT1RTk5LX01ZOXJGa3hPSDhrVFk1TGI5WHphb2NuenFIZkUyUXkxczFyS0lRJnM9bVlH NE12WWozSXBTaWREaWlnWnI0TnRtWGlaNHV6cHhyRkFHZDJXdG9GTSZlPT4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0 aCZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNL SS13Jm09UU5OS19NWTlyRmt4T0g4a1RZNUxiOVh6YW9jbnpxSGZFMlF5MXMxcktJUSZzPW1ZRzRN dllqM0lwU2lkRGlpZ1pyNE50bVhpWjR1enB4ckZBR2QyV3RvRk0mZT0+DQoNCg0KLS0NCmhhbnMu emFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4N ClptYXJ0Wm9uZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuem1hcnR6b25lLmV1JmQ9RHdNRmFRJmM9 OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1RTk5LX01Z OXJGa3hPSDhrVFk1TGI5WHphb2NuenFIZkUyUXkxczFyS0lRJnM9cmRHWm5jWVVxdmx3Y1hJN19H R3JjNU5paWk0NnBEV0hkcFZrbHNiMElqZyZlPT4NCg== --_000_74BEF7B555AC4BD6AEF1D04DEFE9F0EAakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgdGhlIGxpbmtzLCBmb2xrcy4mbmJzcDsgSeKAmW0gYXdhcmUsIGFuZCBz b3JyeSBmb3IgbXkgc2xvcHB5IHRlcm1pbm9sb2d5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J bWFnaW5lIGEgc2VydmljZSB3aGVyZSBhbnlvbmUgd2l0aCBhIHZhbGlkIGlkZW50aXR5IGlzIGF1 dGhvcml6ZWQuIFRoZXJlIGFyZSBtYW55IG9mIHRoZXNlIG9uIHRoZSBuZXQuIENvbGxhcHNpbmcg YXV0aGVudGljYXRpb24gdG8gYXV0aG9yaXphdGlvbiAo4oCcZXZlcnlvbmUgYXV0aGVudGljYXRl ZCBpcyBhdXRob3JpemVk4oCdKSBzZWVtcyBub3QgdW5yZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CdXQgSSBkb27igJl0IHdhbnQgdG8gZ2V0IGRpc3RyYWN0ZWQgZnJvbSBteSBt YWluIGdvYWwuJm5ic3A7IFRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkhhbnMgWmFuZGJlbHQgJmx0O2hhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgQXVndXN0IDE3LCAyMDE5IGF0IDI6MzQgUE08 YnI+DQo8Yj5UbzogPC9iPkpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIEluZm8gb24gaG93IHRv IGltcGxlbWVudCBhIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5kZWVkIE9BdXRoICE9IGlkZW50aXR5IHNlZSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fb2F1dGgubmV0X2FydGljbGVzX2F1dGhlbnRpY2F0aW9uXyZhbXA7ZD1Ed01GYVEmYW1w O2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFt cDttPVFOTktfTVk5ckZreE9IOGtUWTVMYjlYemFvY256cUhmRTJReTFzMXJLSVEmYW1wO3M9UzNo TlJaTi1GNzNWTnIybHMteUtONGJKUFN1SDR3OTJTbUZjMVBBdmk0TSZhbXA7ZT0iPmh0dHBzOi8v b2F1dGgubmV0L2FydGljbGVzL2F1dGhlbnRpY2F0aW9uLzwvYT4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBBdWcgMTcsIDIwMTkgYXQg ODozMSBQTSBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNv bSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cD5UaGUgb3BlbklEIENvbm5lY3Qga2luZCBvZiBPQXV0 aCBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8cD5PQXV0aCBvbiBpdHMgb3duIGlzIG5vdCBkZXNp Z25lZCB0byBiZSBzZWN1cmUgZm9yIGlkZW50aXR5IGZlZGVyYXRpb24uPG86cD48L286cD48L3A+ DQo8cD5Kb2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gOC8xNy8yMDE5IDE6MjMgUE0sIFNhbHosIFJpY2ggd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdOKAmXMgdGhlIFdHIGNv bnNlbnN1cyAoaGVoKSBvbiB0aGUgYmVzdCBndWlkZSB0byBhZGRpbmcgT0FVVEggc3VwcG9ydCB0 byBhbiBleGlzdGluZyBzZXJ2ZXIgc28gdGhhdCBpdCBjYW4gYWN0IGFzIGFuIGlkZW50aXR5IHBy b3ZpZGVyPyZuYnNwOyBXaGljaCB2ZXJzaW9uIG9mIG9hdXRoIGlzIG1vc3Qgd2lkZWx5DQogZGVw bG95ZWQgYnkgcmVseWluZyBwYXJ0aWVzIHRoZXNlIGRheXM/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIHdhbnQgdG8gYWRkIE9BVVRIIHN1cHBvcnQgdG8gdGhlIElFVEYgZGF0YXRyYWNr ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIGFueSBwb2ludGVycy4m bmJzcDsgUmVwbGllcyB0byBtZSB3aWxsIGJlIHN1bW1hcml6ZWQgZm9yIHRoZSBsaXN0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC9yJDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPVFOTktf TVk5ckZreE9IOGtUWTVMYjlYemFvY256cUhmRTJReTFzMXJLSVEmYW1wO3M9bVlHNE12WWozSXBT aWREaWlnWnI0TnRtWGlaNHV6cHhyRkFHZDJXdG9GTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19vYXV0aCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZh bXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPVFOTktfTVk5ckZreE9IOGtUWTVMYjlY emFvY256cUhmRTJReTFzMXJLSVEmYW1wO3M9bVlHNE12WWozSXBTaWREaWlnWnI0TnRtWGlaNHV6 cHhyRkFHZDJXdG9GTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFu ZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpv bmUuZXU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0g LSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9fd3d3LnptYXJ0em9uZS5ldSZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPVFOTktfTVk5ckZreE9I OGtUWTVMYjlYemFvY256cUhmRTJReTFzMXJLSVEmYW1wO3M9cmRHWm5jWVVxdmx3Y1hJN19HR3Jj NU5paWk0NnBEV0hkcFZrbHNiMElqZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCnd3dy56bWFy dHpvbmUuZXU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_74BEF7B555AC4BD6AEF1D04DEFE9F0EAakamaicom_-- From nobody Sun Aug 18 13:47:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1512020A for ; Sun, 18 Aug 2019 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK5kLJsUMcPI for ; Sun, 18 Aug 2019 13:47:30 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 617A81201E3 for ; Sun, 18 Aug 2019 13:47:30 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b17so7456439lff.7 for ; Sun, 18 Aug 2019 13:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wN5JG9lrOje/JfRsoNbW/n+PhyRPJva2w5kdSvUxfrM=; b=YlO6CvQLMJV4wRGJthj7GThrAecB8Pss4FRjf4f646eq71orrh5D7BJybTf5SJjoxf 96CrE8uDDra1IzWjUtqMThj6NTGe0Y2vbZ83Ldnrl7Jl/Sey9Opb+mmvH/ZNqwFVTWvX HIc2h8puH5bmN+J3pyhQUX+4EofhiU7rM71BIW1RAn+8+qHs0Au+lruSHNW67zutN2WM Y/xzqCP70NMt/g6/Yf1K5HYJDLOEEZaEV/Bmzs2OxqXII7ybMI0oVxwJ9kLpYFK44IAW SiLfoPTIjFcbw0nAfYcRAUFytdAdSlrHSfkvOqVtmw5/JiwhuYS6gB7MhpV0uA5TJSYu J4Gw== 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=wN5JG9lrOje/JfRsoNbW/n+PhyRPJva2w5kdSvUxfrM=; b=dgImzZKcq9lnMQCX4OR7RnvnvLHF2i8uwd9SYKj9YM9LTzo9ydCsb774l5HM9jLb3l piG8lRzMuLBu5i+Rd4HqTe9JhgAhdYHKdcX9WL95GSFKtX0cUhBuw3ObWBHWXC/m0Z1b 1UmmYY9cJCp5MFrzctF4EwOLLStAvXicHuk+qQ+V3CmIEQ4kPz/KqFgQOfFIlDvcb5m/ RZJE6XmKyqaSdftkTyXbj8l1PghkMY7bPo4EtHcUp7he1vc185t3WMTCRTYzYEBsX7tX Sv2gzM+rdfPp3XmZoL7Xon9WKLzGSzBtR6VPhtyG+Sgzy3bZKoXShxSzIzrExtFy4h1U Bf5A== X-Gm-Message-State: APjAAAXOLJaQWuwMGOEucVrp7BM1t4BgDN/en4swd2+tH1nBI1ZPUDVL 2HRZ5IYKtzalc4iJXnEGoS0EqF1gl9ydeI2Gr9Q= X-Google-Smtp-Source: APXvYqwDJdvonAUmDmvI+UyJLaOSaBDFBmOqaQz7TcncBhhHVurwdGiKXhYT4PO9LQYu1r2gHvRaFCCO+IZtRDjOMQQ= X-Received: by 2002:a19:8c57:: with SMTP id i23mr10180999lfj.192.1566161248296; Sun, 18 Aug 2019 13:47:28 -0700 (PDT) MIME-Version: 1.0 References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> In-Reply-To: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> From: Dick Hardt Date: Sun, 18 Aug 2019 13:47:15 -0700 Message-ID: To: "Salz, Rich" Cc: Hans Zandbelt , John Bradley , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dda29105906a5479" Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 20:47:33 -0000 --000000000000dda29105906a5479 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is the goal? On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich wrote: > Thanks for the links, folks. I=E2=80=99m aware, and sorry for my sloppy > terminology. > > > > Imagine a service where anyone with a valid identity is authorized. There > are many of these on the net. Collapsing authentication to authorization > (=E2=80=9Ceveryone authenticated is authorized=E2=80=9D) seems not unreas= onable. > > > > But I don=E2=80=99t want to get distracted from my main goal. Thanks. > > > > *From: *Hans Zandbelt > *Date: *Saturday, August 17, 2019 at 2:34 PM > *To: *John Bradley > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Info on how to implement a server > > > > indeed OAuth !=3D identity see https://oauth.net/articles/authentication/ > > > > > Hans. > > > > On Sat, Aug 17, 2019 at 8:31 PM John Bradley wrote: > > The openID Connect kind of OAuth server. > > OAuth on its own is not designed to be secure for identity federation. > > John B. > > On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What=E2=80=99s the WG consensus (heh) on the best guide to adding OAUTH s= upport to > an existing server so that it can act as an identity provider? Which > version of oauth is most widely deployed by relying parties these days? > > > > I want to add OAUTH support to the IETF datatracker. > > > > Thanks for any pointers. Replies to me will be summarized for the list. > > > > /r$ > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > hans.zandbelt@zmartzone.eu > > ZmartZone IAM - www.zmartzone.eu > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000dda29105906a5479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is the goal?

On Sun, Aug 18, 2019 at = 12:41 PM Salz, Rich <rsalz@akamai.co= m> wrote:

Thanks for the links, folks.=C2=A0 I=E2=80=99m aware= , and sorry for my sloppy terminology.

=C2=A0

Imagine a service where anyone with a valid identity= is authorized. There are many of these on the net. Collapsing authenticati= on to authorization (=E2=80=9Ceveryone authenticated is authorized=E2=80=9D= ) seems not unreasonable.

=C2=A0

But I don=E2=80=99t want to get distracted from my m= ain goal.=C2=A0 Thanks.

=C2=A0

From= : Hans Zandbelt <= ;hans.zandb= elt@zmartzone.eu>
Date: Saturday, August 17, 2019 at 2:34 PM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Info on how to implement a server<= /u>

=C2=A0

indeed OAuth !=3D identity see=C2=A0https:= //oauth.net/articles/authentication/

=C2=A0

Hans.

=C2=A0

On Sat, Aug 17, 2019 at 8:31 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

The openID Connect kind of OAuth server.

OAuth on its own is not designed to be secure for identity federation.

John B.

On 8/17/2019 1:23 PM, Salz, Rich wrote:

What=E2=80=99s the WG consensus (heh) on the best gu= ide to adding OAUTH support to an existing server so that it can act as an = identity provider?=C2=A0 Which version of oauth is most widely deployed by relying parties these days?

=C2=A0

I want to add OAUTH support to the IETF datatracker.=

=C2=A0

Thanks for any pointers.=C2=A0 Replies to me will be= summarized for the list.

=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 /r$

=C2=A0



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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


=C2=A0

--

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000dda29105906a5479-- From nobody Sun Aug 18 14:05:18 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3B120047 for ; Sun, 18 Aug 2019 14:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 rVC8snjwlNpg for ; Sun, 18 Aug 2019 14:05:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7463A1200B9 for ; Sun, 18 Aug 2019 14:05:14 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7IL2KsS018771; Sun, 18 Aug 2019 22:05:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hrM7qsmdMB6fpr0NxZwDCdPZjp0AKuX6zmMmd8JAVLw=; b=TpLA+78PO+/Ks4F6EwhQ1blfNZyJwLIJJtwNvyCdGti9LFN6m3fSEZjfIuL2On/rQoGX PPkd/fkSK4rSpaJonT7m9/NG4xOjCPJzoFO04svG8/m1XwJEe0jeHo8hOiqbwmiyo4/q 2LcqJRd2dKi4OeCO+ytcxjKK7pypp345tDdmeYF5UWWw9f8ruaDY0zUmd8TIR4Erk5mx n/tDH8rwoY3T9m1FUUDRMwwu/o/P0H3ebQBmhAk/t1uVpjGMOyjWTCB1UIJVkyqQOthf O4EDsNzNYq7jv2PFiyOHRmH3WWIyCnM/wdMC4AIPEpyXk0Gtw8xb3E3TgHLQy3LUvpom fQ== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ue97txdr2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 22:05:11 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7IL2dd9010694; Sun, 18 Aug 2019 17:05:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uecwvsk8k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 17:05:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 17:05:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sun, 18 Aug 2019 17:05:05 -0400 From: "Salz, Rich" To: Dick Hardt CC: Hans Zandbelt , John Bradley , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzqb/7IKAgAAA+4CAAWH9AIAAVY+A///B7AA= Date: Sun, 18 Aug 2019 21:05:04 +0000 Message-ID: <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.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.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: multipart/alternative; boundary="_000_40AA5F984EB14ECBA9A6AEB2E435F693akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_09:, , signatures=0 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-1906280000 definitions=main-1908180234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_09:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180234 Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:05:17 -0000 --_000_40AA5F984EB14ECBA9A6AEB2E435F693akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBzYWlkIGF0IHRoZSBzdGFydCBvZiB0aGUgdGhyZWFkOiBJIHdhbnQgdG8gYWRkIE9BVVRI IHN1cHBvcnQgdG8gdGhlIGRhdGF0cmFja2VyLg0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhh cmR0QGdtYWlsLmNvbT4NCkRhdGU6IFN1bmRheSwgQXVndXN0IDE4LCAyMDE5IGF0IDQ6NDcgUE0N ClRvOiBSaWNoIFNhbHogPHJzYWx6QGFrYW1haS5jb20+DQpDYzogSGFucyBaYW5kYmVsdCA8aGFu cy56YW5kYmVsdEB6bWFydHpvbmUuZXU+LCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29t PiwgIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBJbmZvIG9uIGhvdyB0byBpbXBsZW1lbnQgYSBzZXJ2ZXINCg0KV2hhdCBpcyB0aGUgZ29h bD8NCg0KT24gU3VuLCBBdWcgMTgsIDIwMTkgYXQgMTI6NDEgUE0gU2FseiwgUmljaCA8cnNhbHpA YWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0 aGUgbGlua3MsIGZvbGtzLiAgSeKAmW0gYXdhcmUsIGFuZCBzb3JyeSBmb3IgbXkgc2xvcHB5IHRl cm1pbm9sb2d5Lg0KDQpJbWFnaW5lIGEgc2VydmljZSB3aGVyZSBhbnlvbmUgd2l0aCBhIHZhbGlk IGlkZW50aXR5IGlzIGF1dGhvcml6ZWQuIFRoZXJlIGFyZSBtYW55IG9mIHRoZXNlIG9uIHRoZSBu ZXQuIENvbGxhcHNpbmcgYXV0aGVudGljYXRpb24gdG8gYXV0aG9yaXphdGlvbiAo4oCcZXZlcnlv bmUgYXV0aGVudGljYXRlZCBpcyBhdXRob3JpemVk4oCdKSBzZWVtcyBub3QgdW5yZWFzb25hYmxl Lg0KDQpCdXQgSSBkb27igJl0IHdhbnQgdG8gZ2V0IGRpc3RyYWN0ZWQgZnJvbSBteSBtYWluIGdv YWwuICBUaGFua3MuDQoNCkZyb206IEhhbnMgWmFuZGJlbHQgPGhhbnMuemFuZGJlbHRAem1hcnR6 b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4+DQpEYXRlOiBTYXR1cmRh eSwgQXVndXN0IDE3LCAyMDE5IGF0IDI6MzQgUE0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2 ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpDYzogIm9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSW5mbyBvbiBob3cgdG8gaW1wbGVtZW50 IGEgc2VydmVyDQoNCmluZGVlZCBPQXV0aCAhPSBpZGVudGl0eSBzZWUgaHR0cHM6Ly9vYXV0aC5u ZXQvYXJ0aWNsZXMvYXV0aGVudGljYXRpb24vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fb2F1dGgubmV0X2FydGljbGVzX2F1dGhlbnRpY2F0aW9u XyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNL SS13Jm09UU5OS19NWTlyRmt4T0g4a1RZNUxiOVh6YW9jbnpxSGZFMlF5MXMxcktJUSZzPVMzaE5S Wk4tRjczVk5yMmxzLXlLTjRiSlBTdUg0dzkyU21GYzFQQXZpNE0mZT0+DQoNCkhhbnMuDQoNCk9u IFNhdCwgQXVnIDE3LCAyMDE5IGF0IDg6MzEgUE0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi LmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KVGhlIG9wZW5JRCBDb25u ZWN0IGtpbmQgb2YgT0F1dGggc2VydmVyLg0KDQpPQXV0aCBvbiBpdHMgb3duIGlzIG5vdCBkZXNp Z25lZCB0byBiZSBzZWN1cmUgZm9yIGlkZW50aXR5IGZlZGVyYXRpb24uDQoNCkpvaG4gQi4NCk9u IDgvMTcvMjAxOSAxOjIzIFBNLCBTYWx6LCBSaWNoIHdyb3RlOg0KV2hhdOKAmXMgdGhlIFdHIGNv bnNlbnN1cyAoaGVoKSBvbiB0aGUgYmVzdCBndWlkZSB0byBhZGRpbmcgT0FVVEggc3VwcG9ydCB0 byBhbiBleGlzdGluZyBzZXJ2ZXIgc28gdGhhdCBpdCBjYW4gYWN0IGFzIGFuIGlkZW50aXR5IHBy b3ZpZGVyPyAgV2hpY2ggdmVyc2lvbiBvZiBvYXV0aCBpcyBtb3N0IHdpZGVseSBkZXBsb3llZCBi eSByZWx5aW5nIHBhcnRpZXMgdGhlc2UgZGF5cz8NCg0KSSB3YW50IHRvIGFkZCBPQVVUSCBzdXBw b3J0IHRvIHRoZSBJRVRGIGRhdGF0cmFja2VyLg0KDQpUaGFua3MgZm9yIGFueSBwb2ludGVycy4g IFJlcGxpZXMgdG8gbWUgd2lsbCBiZSBzdW1tYXJpemVkIGZvciB0aGUgbGlzdC4NCg0KICAgICAg ICAgICAgICAgIC9yJA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmQ9RHdNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1RTk5LX01ZOXJGa3hP SDhrVFk1TGI5WHphb2NuenFIZkUyUXkxczFyS0lRJnM9bVlHNE12WWozSXBTaWREaWlnWnI0TnRt WGlaNHV6cHhyRkFHZDJXdG9GTSZlPT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09UU5OS19NWTlyRmt4T0g4 a1RZNUxiOVh6YW9jbnpxSGZFMlF5MXMxcktJUSZzPW1ZRzRNdllqM0lwU2lkRGlpZ1pyNE50bVhp WjR1enB4ckZBR2QyV3RvRk0mZT0+DQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1 PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJQU0gLSB3d3cu em1hcnR6b25lLmV1PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuem1hcnR6b25lLmV1JmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxa ZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1RTk5LX01ZOXJGa3hPSDhrVFk1TGI5WHphb2Nu enFIZkUyUXkxczFyS0lRJnM9cmRHWm5jWVVxdmx3Y1hJN19HR3JjNU5paWk0NnBEV0hkcFZrbHNi MElqZyZlPT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09VW44dGRHaW5JVnBBcVN0VTRHVGdaV3dRalJMN3RN TFVXRkxmRzVIY2l2OCZzPXJMM0prVTNieUI2cmNaZGdseklkZnpMTUNoV3dnVFJ1YkdVWXdpRGxf azgmZT0+DQo= --_000_40AA5F984EB14ECBA9A6AEB2E435F693akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <258FA548F39ECA4389B31C567362EA99@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzIEkgc2FpZCBhdCB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZDogSSB3YW50IHRvIGFkZCBP QVVUSCBzdXBwb3J0IHRvIHRoZSBkYXRhdHJhY2tlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEF1Z3VzdCAxOCwgMjAxOSBhdCA0OjQ3IFBNPGJy Pg0KPGI+VG86IDwvYj5SaWNoIFNhbHogJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5IYW5zIFphbmRiZWx0ICZsdDtoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSZndDss IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7LCAmcXVvdDtvYXV0aEBpZXRm Lm9yZyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbT0FVVEgtV0ddIEluZm8gb24gaG93IHRvIGltcGxlbWVudCBhIHNlcnZlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoYXQgaXMgdGhlIGdvYWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEF1ZyAxOCwgMjAxOSBhdCAxMjo0MSBQTSBT YWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSI+cnNhbHpAYWth bWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgdGhlIGxp bmtzLCBmb2xrcy4mbmJzcDsgSeKAmW0gYXdhcmUsIGFuZCBzb3JyeSBmb3IgbXkgc2xvcHB5IHRl cm1pbm9sb2d5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW1hZ2luZSBhIHNlcnZpY2Ug d2hlcmUgYW55b25lIHdpdGggYSB2YWxpZCBpZGVudGl0eSBpcyBhdXRob3JpemVkLiBUaGVyZSBh cmUgbWFueSBvZiB0aGVzZSBvbiB0aGUgbmV0LiBDb2xsYXBzaW5nIGF1dGhlbnRpY2F0aW9uIHRv IGF1dGhvcml6YXRpb24gKOKAnGV2ZXJ5b25lIGF1dGhlbnRpY2F0ZWQgaXMgYXV0aG9yaXplZOKA nSkNCiBzZWVtcyBub3QgdW5yZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QnV0IEkgZG9u4oCZdCB3YW50IHRvIGdldCBkaXN0cmFjdGVkIGZyb20gbXkgbWFpbiBnb2FsLiZu YnNwOyBUaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkhhbnMgWmFuZGJlbHQgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhh bnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJk YXksIEF1Z3VzdCAxNywgMjAxOSBhdCAyOjM0IFBNPGJyPg0KPGI+VG86IDwvYj5Kb2huIEJyYWRs ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRI LVdHXSBJbmZvIG9uIGhvdyB0byBpbXBsZW1lbnQgYSBzZXJ2ZXI8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbmRlZWQgT0F1 dGggIT0gaWRlbnRpdHkgc2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19vYXV0aC5uZXRfYXJ0aWNsZXNfYXV0aGVudGlj YXRpb25fJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRM TTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209UU5OS19NWTlyRmt4T0g4a1RZNUxiOVh6YW9jbnpx SGZFMlF5MXMxcktJUSZhbXA7cz1TM2hOUlpOLUY3M1ZOcjJscy15S040YkpQU3VINHc5MlNtRmMx UEF2aTRNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vb2F1dGgubmV0L2FydGljbGVz L2F1dGhlbnRpY2F0aW9uLzwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTYXQsIEF1ZyAxNywgMjAxOSBhdCA4OjMxIFBNIEpv aG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHA+VGhlIG9wZW5JRCBDb25uZWN0IGtpbmQgb2YgT0F1dGggc2VydmVyLjxvOnA+ PC9vOnA+PC9wPg0KPHA+T0F1dGggb24gaXRzIG93biBpcyBub3QgZGVzaWduZWQgdG8gYmUgc2Vj dXJlIGZvciBpZGVudGl0eSBmZWRlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+Sm9obiBCLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gOC8xNy8yMDE5 IDE6MjMgUE0sIFNhbHosIFJpY2ggd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdOKAmXMgdGhlIFdHIGNvbnNlbnN1cyAoaGVo KSBvbiB0aGUgYmVzdCBndWlkZSB0byBhZGRpbmcgT0FVVEggc3VwcG9ydCB0byBhbiBleGlzdGlu ZyBzZXJ2ZXIgc28gdGhhdCBpdCBjYW4gYWN0IGFzIGFuIGlkZW50aXR5IHByb3ZpZGVyPyZuYnNw OyBXaGljaCB2ZXJzaW9uIG9mIG9hdXRoIGlzIG1vc3Qgd2lkZWx5DQogZGVwbG95ZWQgYnkgcmVs eWluZyBwYXJ0aWVzIHRoZXNlIGRheXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdh bnQgdG8gYWRkIE9BVVRIIHN1cHBvcnQgdG8gdGhlIElFVEYgZGF0YXRyYWNrZXIuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIGFueSBwb2ludGVycy4mbmJzcDsgUmVwbGll cyB0byBtZSB3aWxsIGJlIHN1bW1hcml6ZWQgZm9yIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9yJDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX29hdXRoJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDty PTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209UU5OS19NWTlyRmt4T0g4a1RZNUxiOVh6YW9j bnpxSGZFMlF5MXMxcktJUSZhbXA7cz1tWUc0TXZZajNJcFNpZERpaWdacjROdG1YaVo0dXpweHJG QUdkMld0b0ZNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9 RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2 RnRzS0ktdyZhbXA7bT1RTk5LX01ZOXJGa3hPSDhrVFk1TGI5WHphb2NuenFIZkUyUXkxczFyS0lR JmFtcDtzPW1ZRzRNdllqM0lwU2lkRGlpZ1pyNE50bVhpWjR1enB4ckZBR2QyV3RvRk0mYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0 em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLQ0KPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3 dy56bWFydHpvbmUuZXUmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm YW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1RTk5LX01ZOXJGa3hPSDhrVFk1TGI5 WHphb2NuenFIZkUyUXkxczFyS0lRJmFtcDtzPXJkR1puY1lVcXZsd2NYSTdfR0dyYzVOaWlpNDZw RFdIZHBWa2xzYjBJamcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQp3d3cuem1hcnR6b25lLmV1 PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZM WmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1Vbjh0ZEdpbklWcEFxU3RVNEdU Z1pXd1FqUkw3dE1MVVdGTGZHNUhjaXY4JmFtcDtzPXJMM0prVTNieUI2cmNaZGdseklkZnpMTUNo V3dnVFJ1YkdVWXdpRGxfazgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_40AA5F984EB14ECBA9A6AEB2E435F693akamaicom_-- From nobody Sun Aug 18 14:08:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D3120220 for ; Sun, 18 Aug 2019 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HedFvQlqxIMn for ; Sun, 18 Aug 2019 14:08:45 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 5B1381207FE for ; Sun, 18 Aug 2019 14:08:45 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id x18so9702019ljh.1 for ; Sun, 18 Aug 2019 14:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2WY7rkWDd4WwG7MsLItJgiirRNw6pO5jjSgCVY9DkWg=; b=RxLpqeuIozs63m0/5auYH/kr7Dld+ZphVAFKnvP3eMIcKZfhrfwtpt610RlBjVdCAt rFNxc0UNOk4KYFQL42Jepr+OV+Y0/TegfZe2b/NwBnJUpmhGY26wHKZ2NSjPM/+W+BeN DvIQWZRdP9HKVh8YYSe6iIpG93q47YdEW7M36ksqbdUHPxKNdD6yILPJ7qD5cDnfljVH f+Q/v9FGmFKQMQDAVJDP7VNYk8C7lKNt6ACc2RzkgZTxO1wkWZbZ3noE3Q9CtKWFfpUX xBKajDgk65tO8jxI6oxcfp8RYKe/hyNXIzBYLPT2XkDpxQ0kT5Kkn5Fr8xwfgMIDCR2z DLkQ== 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=2WY7rkWDd4WwG7MsLItJgiirRNw6pO5jjSgCVY9DkWg=; b=s7dXSm+WZvF/uc2sIoBlho236z6htfgT+3QtTsbDkGjX+L9ZGnM8xOGVP2JQux5nVD 9rr/jZdLobsME1Y0kNJo8U9rT8wysIT1+2Eu2MKaJELbz0VajJvXAFEuVQBWoo114h/U WyhIlYXMI9l2d3Gyz35etJ0tMZnv2nthPp6N5cTRPmki5j3DMP4eA22zcAyRAUWK+Vcw medu8V4ocoVLyUsnZfJCsuBreXBSwRYqVo2dOhQNEuX7i58+N9Hk3i+bcWC0RD4XLRRI Qfl4immtppUnJFN9YpBuzSLiPhAVvJehKIWckP0nLkK8GSkozgar+GDwyDHZCrkXuR/0 XFtQ== X-Gm-Message-State: APjAAAWBmpi1/Jcsr+lQA1VWGb1b5e4UWAWpkmsX6wB1L7LxArHLOK+f Ia4U9pf0zBd6Ap8l7QwBwDXjBEXzlVcxO6x/jg0= X-Google-Smtp-Source: APXvYqxbV1ri1gMToJD1yxiTj42JMsqt2Xl8yImMImnZ0DmzGpgIusrUx652Pyxsss9nv8yXhURFkRzhHzxbGQzN3iw= X-Received: by 2002:a2e:80da:: with SMTP id r26mr8566646ljg.62.1566162523454; Sun, 18 Aug 2019 14:08:43 -0700 (PDT) MIME-Version: 1.0 References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> In-Reply-To: <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> From: Dick Hardt Date: Sun, 18 Aug 2019 14:08:32 -0700 Message-ID: To: "Salz, Rich" Cc: Hans Zandbelt , John Bradley , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000df04e305906aa01f" Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:08:55 -0000 --000000000000df04e305906aa01f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That sounds like a means to an end. Do you want to enable applications to call datatracker APIs? On Sun, Aug 18, 2019 at 2:05 PM Salz, Rich wrote: > As I said at the start of the thread: I want to add OAUTH support to the > datatracker. > > > > *From: *Dick Hardt > *Date: *Sunday, August 18, 2019 at 4:47 PM > *To: *Rich Salz > *Cc: *Hans Zandbelt , John Bradley < > ve7jtb@ve7jtb.com>, "oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Info on how to implement a server > > > > What is the goal? > > > > On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich wrote: > > Thanks for the links, folks. I=E2=80=99m aware, and sorry for my sloppy > terminology. > > > > Imagine a service where anyone with a valid identity is authorized. There > are many of these on the net. Collapsing authentication to authorization > (=E2=80=9Ceveryone authenticated is authorized=E2=80=9D) seems not unreas= onable. > > > > But I don=E2=80=99t want to get distracted from my main goal. Thanks. > > > > *From: *Hans Zandbelt > *Date: *Saturday, August 17, 2019 at 2:34 PM > *To: *John Bradley > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Info on how to implement a server > > > > indeed OAuth !=3D identity see https://oauth.net/articles/authentication/ > > > > > Hans. > > > > On Sat, Aug 17, 2019 at 8:31 PM John Bradley wrote: > > The openID Connect kind of OAuth server. > > OAuth on its own is not designed to be secure for identity federation. > > John B. > > On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What=E2=80=99s the WG consensus (heh) on the best guide to adding OAUTH s= upport to > an existing server so that it can act as an identity provider? Which > version of oauth is most widely deployed by relying parties these days? > > > > I want to add OAUTH support to the IETF datatracker. > > > > Thanks for any pointers. Replies to me will be summarized for the list. > > > > /r$ > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > hans.zandbelt@zmartzone.eu > > ZmartZone IAM - www.zmartzone.eu > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000df04e305906aa01f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That sounds like a means to an end.=

Do you want to enable applicat= ions to call datatracker APIs?

On Sun, Aug 18, 2019 at 2:05 PM Sa= lz, Rich <rsalz@ak= amai.com> wrote:

As I said at the start of the thread: I want to add = OAUTH support to the datatracker.

=C2=A0

From: = Dick Hardt <dick.hardt@gmail.com>
Date: Sunday, August 18, 2019 at 4:47 PM
To: Rich Salz <rsalz@akamai.com>
Cc: Hans Zandbelt <hans.zandbelt@zmartzone.eu>, John Bradley <ve7jtb@ve7jtb.com>= ;, "oauth@ietf.org= " <oauth@ie= tf.org>
Subject: Re: [OAUTH-WG] Info on how to implement a server<= /u>

=C2=A0

What is the goal?

=C2=A0

On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich <rsalz@akamai.com> = wrote:

Thanks for the links, folks.=C2=A0 I=E2=80=99m aware= , and sorry for my sloppy terminology.

=C2=A0

Imagine a service where anyone with a valid identity= is authorized. There are many of these on the net. Collapsing authenticati= on to authorization (=E2=80=9Ceveryone authenticated is authorized=E2=80=9D= ) seems not unreasonable.

=C2=A0

But I don=E2=80=99t want to get distracted from my m= ain goal.=C2=A0 Thanks.

=C2=A0

From: Hans Zandbelt <hans.zandbelt@= zmartzone.eu>
Date: Saturday, August 17, 2019 at 2:34 PM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Info on how to implement a server<= /u>

=C2=A0

indeed OAuth !=3D identity see=C2=A0https:= //oauth.net/articles/authentication/

=C2=A0

Hans.

=C2=A0

On Sat, Aug 17, 2019 at 8:31 PM John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

The openID Connect kind of OAuth server.

OAuth on its own is not designed to be secure for identity federation.

John B.

On 8/17/2019 1:23 PM, Salz, Rich wrote:

What=E2=80=99s the WG consensus (heh) on the best gu= ide to adding OAUTH support to an existing server so that it can act as an = identity provider?=C2=A0 Which version of oauth is most widely deployed by relying parties these days?

=C2=A0

I want to add OAUTH support to the IETF datatracker.=

=C2=A0

Thanks for any pointers.=C2=A0 Replies to me will be= summarized for the list.

=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 /r$

=C2=A0

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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


=C2=A0

--

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

--000000000000df04e305906aa01f-- From nobody Sun Aug 18 14:10:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040E212013B for ; Sun, 18 Aug 2019 14:10:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.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 kgBoEVN1fflg for ; Sun, 18 Aug 2019 14:10:04 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 B9664120047 for ; Sun, 18 Aug 2019 14:10:04 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id t3so16545567ioj.12 for ; Sun, 18 Aug 2019 14:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sobe46CW3LKzpsPq/BU/zFtfbeAsZFU3EEy96yRNFGk=; b=r0J7usxOi+V2M6frAkj8dBsoR4Rb6AFxOGo46SP88ZQlX9DLgOyl8RumaIcbMGj9zI UETxJ02d5oah04cvdqUhplincc/Oy6DNQI96+W7kX+ck3WpgN8O3NaKd9zRr2Zd+X52U 6tAgGzZJB6zv7Z97YYX8cReAJhzKorSYmnHgapoSy9NOGZHahh64qGP390h/I4WvqFCW Bh4jXIIpl8eTvfv7zCqkM79Iq1CxNiHMV0J3G5GIJz4otna6SgpLGkvIckyA8e1QSvSt WjKVMmE7g/0+JOfdvEV4ODcq9iQG0w4H5L/vBPm2Zt5eBSosY8X7J2VIfSNuI4MJ1g7K BaEA== 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:content-transfer-encoding; bh=sobe46CW3LKzpsPq/BU/zFtfbeAsZFU3EEy96yRNFGk=; b=fgd1VmywhwATbZEo6HkInfxiIcBqsncemLlh1BkEf4KG4MnVCqpChfp8EZXXuqnrlB KRcfEKFyp9WBwWC4AqKrAwuyyM1Zt5jXGUAws6n7p0NEKrXlixabba2bSRKdUfpCezV1 RJXtGLUSMjt1E5sYgrR0Em3o50UE5KwNI12uXKuzfx0WyvG3Gh3IKERwSO7tm/V2BGu4 pyTaMGCkt6s9lhwoGm/YDjzwKqInOO3MIbTK08UzZ9I3QjurMguVOctnUTTw7B3vytD1 Fk+o9sOcDEcPf4wtA264OGuDxbptZYNumdt/uYmUkgsgewxRKw15kELG7Wo7AGds6o7L q26Q== X-Gm-Message-State: APjAAAXBgIon7+yPRxuPF90C3vz/rH5T85blujlcFC0X5OGPyCpoFYBc t9r0s5FNdN8s+iyc05e60LGMIN7NLJU= X-Google-Smtp-Source: APXvYqz1BXr2lZ4auIIigQg16qG5FmDWsOFTYjrxcSh2hnTjF9BF8guQMSkAH4sorqjDa6C3g0GENg== X-Received: by 2002:a6b:915:: with SMTP id t21mr22916984ioi.261.1566162603839; Sun, 18 Aug 2019 14:10:03 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id a21sm15399932ioe.27.2019.08.18.14.10.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Aug 2019 14:10:03 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id s21so16581245ioa.1 for ; Sun, 18 Aug 2019 14:10:03 -0700 (PDT) X-Received: by 2002:a6b:fd13:: with SMTP id c19mr12341514ioi.168.1566162603112; Sun, 18 Aug 2019 14:10:03 -0700 (PDT) MIME-Version: 1.0 References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> In-Reply-To: <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> From: Aaron Parecki Date: Sun, 18 Aug 2019 14:09:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:10:07 -0000 Not to be pedantic, but adding OAuth support is a mechanism in support of a goal. What's the end goal? * Letting third party apps use the datatracker API? * Letting people sign in to other apps with a datatracker account? ---- Aaron Parecki aaronparecki.com On Sun, Aug 18, 2019 at 2:05 PM Salz, Rich wrote: > > As I said at the start of the thread: I want to add OAUTH support to the = datatracker. > > > > From: Dick Hardt > Date: Sunday, August 18, 2019 at 4:47 PM > To: Rich Salz > Cc: Hans Zandbelt , John Bradley , "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Info on how to implement a server > > > > What is the goal? > > > > On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich wrote: > > Thanks for the links, folks. I=E2=80=99m aware, and sorry for my sloppy = terminology. > > > > Imagine a service where anyone with a valid identity is authorized. There= are many of these on the net. Collapsing authentication to authorization (= =E2=80=9Ceveryone authenticated is authorized=E2=80=9D) seems not unreasona= ble. > > > > But I don=E2=80=99t want to get distracted from my main goal. Thanks. > > > > From: Hans Zandbelt > Date: Saturday, August 17, 2019 at 2:34 PM > To: John Bradley > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Info on how to implement a server > > > > indeed OAuth !=3D identity see https://oauth.net/articles/authentication/ > > > > Hans. > > > > On Sat, Aug 17, 2019 at 8:31 PM John Bradley wrote: > > The openID Connect kind of OAuth server. > > OAuth on its own is not designed to be secure for identity federation. > > John B. > > On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What=E2=80=99s the WG consensus (heh) on the best guide to adding OAUTH s= upport to an existing server so that it can act as an identity provider? W= hich version of oauth is most widely deployed by relying parties these days= ? > > > > I want to add OAUTH support to the IETF datatracker. > > > > Thanks for any pointers. Replies to me will be summarized for the list. > > > > /r$ > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > hans.zandbelt@zmartzone.eu > > ZmartZone IAM - www.zmartzone.eu > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Aug 18 14:28:51 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186B0120110 for ; Sun, 18 Aug 2019 14:28:49 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 itzg196a8gXG for ; Sun, 18 Aug 2019 14:28:48 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 EF8431200B9 for ; Sun, 18 Aug 2019 14:28:47 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7ILS8LA019901; Sun, 18 Aug 2019 22:28:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=NFm6hjcx6G7/Opd5wqIXIgHFZkZv81Vod1wtSKuSAfs=; b=NIacbTCFb/ijABRd7azyGrbBgSzgFaqnTlU5IwUdApYmwGcb69sUeUAGDPWppSwlS0DK CivAsHlDr75yASZT7YwJhAU8BZi/S7iP2vpuZa93AswFdML8IjQhYBo02akAPryVeqN5 KB561siqN6KmHirbGfshf/Et8k+D9xvgy29sH+5veJZR+yNwvmgaKysq24FuQ7rsZnlQ 5+TzjKdD71QoEJ78OXA8/Grezf4WtiKHaZKkDrWHtFrL8Jgy8CX9TsfDEFWLWIYElAby ukSt4LMKw13hIkoyL8BcCMZEkC3CpBg1aYZ6kT/8DXWHY7b4X1z9GqeKLgQeJNQXbbwc QA== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2ue8unxr3t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 22:28:46 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7ILHIFh026415; Sun, 18 Aug 2019 17:28:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uecwvspfm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 17:28:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 17:28:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sun, 18 Aug 2019 17:28:44 -0400 From: "Salz, Rich" To: Dick Hardt CC: Hans Zandbelt , John Bradley , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzqb/7IKAgAAA+4CAAWH9AIAAVY+A///B7ACAAEQGAP//wpWA Date: Sun, 18 Aug 2019 21:28:43 +0000 Message-ID: References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.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.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: multipart/alternative; boundary="_000_ED700200997846D39E2EC9DF41F1925Eakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=700 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_10:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 mlxlogscore=690 clxscore=1015 spamscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180236 Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:28:49 -0000 --_000_ED700200997846D39E2EC9DF41F1925Eakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+RG8geW91IHdhbnQgdG8gZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBjYWxsIGRhdGF0cmFja2Vy IEFQSXM/DQoNCk5vdCBtZSwgbm8uICBCdXQgSSBrbm93IG9mIGEgY291cGxlIHRoYXQgd2lsbCBi ZSBhYmxlIHRvIGJlbmVmaXQNCg== --_000_ED700200997846D39E2EC9DF41F1925Eakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDtEbyB5b3Ugd2FudCB0byBlbmFibGUgYXBwbGljYXRpb25zIHRvIGNhbGwgZGF0YXRyYWNrZXIg QVBJcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IG1lLCBuby4mbmJzcDsgQnV0IEkga25v dyBvZiBhIGNvdXBsZSB0aGF0IHdpbGwgYmUgYWJsZSB0byBiZW5lZml0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ED700200997846D39E2EC9DF41F1925Eakamaicom_-- From nobody Sun Aug 18 14:29:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E071200B9 for ; Sun, 18 Aug 2019 14:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 WbHmMBw2In7P for ; Sun, 18 Aug 2019 14:29:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 BD307120047 for ; Sun, 18 Aug 2019 14:29:25 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7ILRLkZ019917; Sun, 18 Aug 2019 22:29:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aVcgcZspjKw3rGQDNAN2n6eeiYySFNtD9Zyi1CetSuM=; b=motMMD5CR066aN9l7W3WhlXECYEvwc0ndM+/NX8jPax+vbZ6uSlSwF9T1fF38KLQk+/V p8YQ90U2MXQkpWA3cUFYgNYosnThqt7sPxzj0uHsvbPhshHFKeyoDF93KVvRTWppE8eO r4ZQvbAwdkXSVOp0Qg9c8tmM2wLRvCkH7e8Vr9PVWhpjAlMMLqfA4pJZouIRg8+S2vhK IURGo5sL1f0bAeuHUDYu66I3aLU98ivUw7az2ZTdAvvAYLmTFgZSpL4Q3pBLjSGJrjtj uOrChGbNnqlQl+nnzjOx8K3f2zVW/ndJdQXTNSvobntrMSoylFcsiHO7FK3lYLuugv8h KQ== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ue6es7067-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 22:29:24 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7ILHHrL003496; Sun, 18 Aug 2019 17:29:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2uecww3mj8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 17:29:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 17:29:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sun, 18 Aug 2019 17:29:22 -0400 From: "Salz, Rich" To: Aaron Parecki CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzqb/7IKAgAAA+4CAAWH9AIAAVY+A///B7ACAAERhAP//wmkA Date: Sun, 18 Aug 2019 21:29:22 +0000 Message-ID: References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.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.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: text/plain; charset="utf-8" Content-ID: <6357E6794CE3A24D8459C1B6C540E67D@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=639 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_10:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 impostorscore=0 clxscore=1011 priorityscore=1501 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 mlxlogscore=632 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180236 Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:29:27 -0000 ICAgIE5vdCB0byBiZSBwZWRhbnRpYywgYnV0IGFkZGluZyBPQXV0aCBzdXBwb3J0IGlzIGEgbWVj aGFuaXNtIGluIHN1cHBvcnQNCiAgICBvZiBhIGdvYWwuIFdoYXQncyB0aGUgZW5kIGdvYWw/DQog ICAgDQogICAgKiBMZXR0aW5nIHRoaXJkIHBhcnR5IGFwcHMgdXNlIHRoZSBkYXRhdHJhY2tlciBB UEk/DQogICAgKiBMZXR0aW5nIHBlb3BsZSBzaWduIGluIHRvIG90aGVyIGFwcHMgd2l0aCBhIGRh dGF0cmFja2VyIGFjY291bnQ/DQoNClRoZSBsYXR0ZXIuDQoNCg== From nobody Sun Aug 18 14:31:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E771200B9 for ; Sun, 18 Aug 2019 14:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq0h4Ia4lsFL for ; Sun, 18 Aug 2019 14:30:59 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD91120047 for ; Sun, 18 Aug 2019 14:30:58 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id z17so9731727ljz.0 for ; Sun, 18 Aug 2019 14:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LmAWXZ7c96mOEgU1YDesBuN0sSJOUMNO//OJOQe18xs=; b=sLyRogtxtCbz8CluTdufhNhUWqlOmMTZFu7wdg2XNNAluJVTmS2t2oMfQFxfa5adJA plxyggOLlOdiJfJJbm1wm7ITKaGDqIxWcOUM2gPRyA80fLUoG9vPVF8VjznbbNue0tvf 1yEmhDFQ+2sIC260ZPvyd80P8LV2CKDPyinD4l6Zjch9onKL8KTrlEoWQcDuu/CvL0AE ilx+kwgp4bUd8ZUgYuxdtF7xgl/PsrYCgfZp0liUpsN2H8uivDd2mOF/F1Gu2Pz6VrwK YOwDBfsq4zEjpfi0vRcMe41+LoePwtYaB90QIPH2wZwX0vwYTgZ9xH6Vk+/TF8edPSOh QutA== 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=LmAWXZ7c96mOEgU1YDesBuN0sSJOUMNO//OJOQe18xs=; b=H7bK4O8xRAUMZv0EPJvM4PXK6QLcIUBMyMNBs/8KeMA1Dvm+mkIzHy/oWG0e0BCMFU YvTlkg202PJK452YPBVaHXATPaoTOQD0YpUndCH/VmC1oYruB3zzKnsI4h6LQc11GYiD IvmElOkuK9qKzNs+y8G50Myh8ttg79Vkpw/w/cpAGaROfos2t3sKaIsJMVi+fWo++lOu T/aTMIOw07jq/K8Qvvv4nGyCSRe0ASo7Qis6mEj19KJJMItknWGI3CGgt9cqMdXUWJD1 gPO0/sebUsIW8NQqtI3i2Ll2vE5Xx8dkwDtSpar5VqmXfHWvRJEXQH+BiLidXa3hSEL6 5iDw== X-Gm-Message-State: APjAAAW0YNuE4TMFuWToUH2hl8EsI8BkrCZpvj+jgxZe22ElmdmNGJmS mRzCZ3DP7P24ZBLPAYHCvbUqXJ41i/DnM9Ew07c= X-Google-Smtp-Source: APXvYqy0D+PuMZWDmOehfdR66mYvhysQccBuXwrCy5g8pQIJWpG2TnUsOfV7o/UspitHjav6DMKu1mQPKQgGXd5w2WU= X-Received: by 2002:a2e:81cb:: with SMTP id s11mr10619305ljg.179.1566163856772; Sun, 18 Aug 2019 14:30:56 -0700 (PDT) MIME-Version: 1.0 References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.com> In-Reply-To: From: Dick Hardt Date: Sun, 18 Aug 2019 14:30:45 -0700 Message-ID: To: "Salz, Rich" Cc: Aaron Parecki , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000057d0f305906af037" Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:31:01 -0000 --00000000000057d0f305906af037 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 18, 2019 at 2:29 PM Salz, Rich wrote: > Not to be pedantic, but adding OAuth support is a mechanism in support > of a goal. What's the end goal? > > * Letting third party apps use the datatracker API? > * Letting people sign in to other apps with a datatracker account? > > The latter. > Then you want OpenID Connect > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000057d0f305906af037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Aug 18, 2019 at 2:29 PM Salz, Ric= h <rsalz@akamai.com> wrote:
=C2=A0 =C2=A0 Not= to be pedantic, but adding OAuth support is a mechanism in support
=C2=A0 =C2=A0 of a goal. What's the end goal?

=C2=A0 =C2=A0 * Letting third party apps use the datatracker API?
=C2=A0 =C2=A0 * Letting people sign in to other apps with a datatracker acc= ount?
The latter.

Then you want OpenID Connec= t
=C2=A0
=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000057d0f305906af037-- From nobody Sun Aug 18 14:56:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC81200B9 for ; Sun, 18 Aug 2019 14:56:20 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 67nQv6QLIOmv for ; Sun, 18 Aug 2019 14:56:18 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 8322C120047 for ; Sun, 18 Aug 2019 14:56:18 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7ILqaOx023206; Sun, 18 Aug 2019 22:56:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=zWrpHnbOeK3lAjdlKG2OZ5Il9CfDJK6Iy+12mrjaOeQ=; b=YLH/T8EoLIp/6UyMDWgrUbOPAo3MniOvz1v3KYttcAMKTID2GV4LMMoRZ5AGbtrOverY mw22SAmFraciWwPNoZ8kGtyrIwTqpLjV4NqvzechOjUmmH7JGtzbqpPUaNuPGEjBIyFo Doc+LDMNwhlMIDPay09XyMCBvLA8T1Wrdj9AuEKMS/6vYKnUvMtaATEjadZcwaGyBmcW EEMdprlOAeinSr/yrmNNQZN/BufN+tfwKQTuQPTQIJPp6cP4h2uzsJ+lpNON9TwdOESW xEUFeUf4LJDn2AU0f8XCxyCNIhOdLuyRKtn2PbYi8vCFbzDHncPZCmMkZZ5RSKM0XCyJ 0Q== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ue9436s0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 22:56:17 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7ILlAKD025321; Sun, 18 Aug 2019 17:56:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uecwvst1k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 17:56:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 18 Aug 2019 17:55:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Sun, 18 Aug 2019 17:55:57 -0400 From: "Salz, Rich" To: Dick Hardt CC: Aaron Parecki , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Info on how to implement a server Thread-Index: AQHVVSB+mqzXXWtHJ0yU+TjhKS0hzqb/7IKAgAAA+4CAAWH9AIAAVY+A///B7ACAAERhAP//wmkAgABDcYD//8P7AA== Date: Sun, 18 Aug 2019 21:55:56 +0000 Message-ID: <47AAB965-5F68-4DE3-A9BD-09F221D92DEE@akamai.com> References: <74BEF7B5-55AC-4BD6-AEF1-D04DEFE9F0EA@akamai.com> <40AA5F98-4EB1-4ECB-A9A6-AEB2E435F693@akamai.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.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: multipart/alternative; boundary="_000_47AAB9655F684DE3A9BD09F221D92DEEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=631 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180240 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_10:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 mlxscore=0 mlxlogscore=628 malwarescore=0 spamscore=0 adultscore=0 impostorscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180241 Archived-At: Subject: Re: [OAUTH-WG] Info on how to implement a server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:56:20 -0000 --_000_47AAB9655F684DE3A9BD09F221D92DEEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZW4geW91IHdhbnQgT3BlbklEIENvbm5lY3QNCg0KZ3JlYXQsIHRoYW5rIHlvdSBmb3IgdGhl IHBvaW50ZXIuDQo= --_000_47AAB9655F684DE3A9BD09F221D92DEEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5UaGVuIHlvdSB3YW50IE9wZW5JRCBDb25uZWN0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PGJyPg0KZ3JlYXQsIHRoYW5rIHlvdSBmb3IgdGhlIHBv aW50ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_47AAB9655F684DE3A9BD09F221D92DEEakamaicom_-- From nobody Mon Aug 19 09:29:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363A5120810 for ; Mon, 19 Aug 2019 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 IUAAKn1a-_la for ; Mon, 19 Aug 2019 09:28:56 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 62A90120043 for ; Mon, 19 Aug 2019 09:28:56 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id h13so2235169edq.10 for ; Mon, 19 Aug 2019 09:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=P2WO2Ld9nAcRLeayq5eEm8ftgaI69avQxc/rEM/dQJE=; b=lmK+O006cL1doXqzqo5r+nyfiBrlgvAplPaTvKAC6BWIQNPjJY2jTFtiiIYLxlyXAU EfudAO3r6rLLFZMchEU5o4gTAwaNBJqAwTxF2ELdBH2d8on87QrSww4x7E9hu620qjA6 XiEDq4Ic7S6Y8Sy9yCc70rgvPNk55pcDwQB4ejHes9BvLynFDn7FIfLXKaQjyNIXQzgq FHERGNB4dFfA/qUfFJ37pHOjewypO4uxRneFXaVUJw/e5fewrJtxHmH6y0oaLdx6iwpu TRcmU/LyywjnGfVciXD2DSgUAvc06EA5RvDOR2zqE3WUo+w+NcNyMwwRPJS5vM1XMTIf 2Y+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=P2WO2Ld9nAcRLeayq5eEm8ftgaI69avQxc/rEM/dQJE=; b=oTxmxPWgKvYZI70UqKZ/LcH3GtR3MaAbLpi4Qeq7d79XCMWSUFN6i2/iYHOdC7M2U0 CkxjA/ikIIekSjGO/vML1kHxgZjhCIMI4Z76Lb534fOot6JArqO6rnLt+QbajB1xCCLZ 5NXvySdXBG/dNMEHiOWPXN4Eupl5oRYazQkistw6RPl3IgIu7Pg2pBuHb//4Ppo3bUpj 5eyTeJCLIN+mjYIKKe126OW2FVAcrKEIvqIG8SWSvxWQnanpjbUuw0HCvO7tSWD2EhhW n7JXu67+NGmz7IlxYDC2tJ/mZUFj4DnZ+U3tiN7Jx+ztw0/099o2MCnLXkzMx0sOudFL IoCA== X-Gm-Message-State: APjAAAWSqikJ+DyHVOoT8H47K1oKRs40U0xiPFgSiTrt+ZfCMvST92yL Dk6Fa3XCCdpV6mwyXl4FYXIw9uo4xoE= X-Google-Smtp-Source: APXvYqzKNdmD/IZiu1vIfBDc7qLzntt/YBzA7SRGIiposcMxVP+DSG+AeFN2DG6pF1U41NJUfmnH2A== X-Received: by 2002:a17:906:cecb:: with SMTP id si11mr22210215ejb.178.1566232134550; Mon, 19 Aug 2019 09:28:54 -0700 (PDT) Received: from ?IPv6:2001:16b8:1c2b:9a00:ade9:2680:b14b:db50? ([2001:16b8:1c2b:9a00:ade9:2680:b14b:db50]) by smtp.gmail.com with ESMTPSA id r11sm2870177edq.10.2019.08.19.09.28.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 09:28:53 -0700 (PDT) To: oauth@ietf.org From: Daniel Fett Message-ID: <0dd8395a-d0ba-7742-535a-f5dadd032ed4@yes.com> Date: Mon, 19 Aug 2019 18:28:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------DDBABC5E0A8D7F6675299AD5" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] Save the Date - OAuth Security Workshop 2020 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 16:28:58 -0000 This is a multi-part message in MIME format. --------------DDBABC5E0A8D7F6675299AD5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit All, The OAuth Security Workshop 2020 will be held July 22-24, 2020 in Trondheim, Norway. I will follow-up here over the next months with details on location, registration, and call for talks. If you are interested in sponsoring the event, or if you know somebody who might be, please drop a mail to Steinar Noem, steinar@udelt.no. -Daniel --------------DDBABC5E0A8D7F6675299AD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

All,

The OAuth Security Workshop 2020 will be held July 22-24, 2020 in Trondheim, Norway.

I will follow-up here over the next months with details on location, registration, and call for talks.

If you are interested in sponsoring the event, or if you know somebody who might be, please drop a mail to Steinar Noem, steinar@udelt.no.

-Daniel

--------------DDBABC5E0A8D7F6675299AD5-- From nobody Mon Aug 19 11:19:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445A5120096 for ; Mon, 19 Aug 2019 11:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 76wMwmUP_Bh0 for ; Mon, 19 Aug 2019 11:19:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED2C120091 for ; Mon, 19 Aug 2019 11:19:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DF156B80C2A; Mon, 19 Aug 2019 11:19:08 -0700 (PDT) To: wdenniss@google.com, ve7jtb@ve7jtb.com, mbj@microsoft.com, Hannes.Tschofenig@gmx.net, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: konstantin.lapine@forgerock.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190819181908.DF156B80C2A@rfc-editor.org> Date: Mon, 19 Aug 2019 11:19:08 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Technical Errata Reported] RFC8628 (5840) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 18:19:18 -0000 The following errata report has been submitted for RFC8628, "OAuth 2.0 Device Authorization Grant". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5840 -------------------------------------- Type: Technical Reported by: Konstantin Lapine Section: 5.2 Original Text ------------- An attacker who guesses the device code would be able to potentially obtain the authorization code once the user completes the flow. Corrected Text -------------- An attacker who guesses the device code would be able to potentially obtain the access token once the user completes the flow. Notes ----- The "authorization code" term is associated with Authorization Code Grant (defined in RFC 6749) and has the meaning of a temporary credential used by an OAuth 2.0 client to obtain the access token. Section 5.2 of RFC 8628 seems to refer to the steps of the device authorization flow during which the device code and the client identifier are exchanged for the access token (and the optional refresh token). Alternative correction: "An attacker who guesses the device code would be able to potentially obtain the access token and the optional refresh token once the user completes the flow." Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8628 (draft-ietf-oauth-device-flow-15) -------------------------------------- Title : OAuth 2.0 Device Authorization Grant Publication Date : August 2019 Author(s) : W. Denniss, J. Bradley, M. Jones, H. Tschofenig Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Aug 19 13:04:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5761207FF for ; Mon, 19 Aug 2019 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebCy2ODWOlit for ; Mon, 19 Aug 2019 13:04:05 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 DF0891202A0 for ; Mon, 19 Aug 2019 13:04:04 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x7JK3qpx028917 for ; Mon, 19 Aug 2019 16:04:00 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 19 Aug 2019 16:03:35 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 19 Aug 2019 16:03:49 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 19 Aug 2019 16:03:49 -0400 From: Justin Richer To: OAuth WG Thread-Topic: Use cases for XYZ Thread-Index: AQHVVsk3ygbNmitz50KIBjZxDVxF0w== Date: Mon, 19 Aug 2019 20:03:49 +0000 Message-ID: <2E8DAF90-2834-4B08-AF1C-2A9928BB6869@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_2E8DAF9028344B08AF1C2A9928BB6869mitedu_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Use cases for XYZ X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 20:04:09 -0000 --_000_2E8DAF9028344B08AF1C2A9928BB6869mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgcHJvbWlzZWQgaW4gTW9udHJlYWwsIEkgaGF2ZSBzdGFydGVkIHRvIHB1bGwgdG9nZXRoZXIg dXNlIGNhc2VzIHRoYXQgZml0IFhZWuKAmXMgbW9kZWwgYmV0dGVyIHRoYW4gdGhleSBmaXQgdHJh ZGl0aW9uYWwgT0F1dGguIFdoaWxlIEnigJl2ZSBiZWVuIGFibGUgdG8gd29yayBvdXQgaG93IFhZ WiB3b3JrcyBmb3IgdGhlIG1vc3QgY29tbW9uIE9BdXRoIGRlcGxveW1lbnRzIGFuZCBleHRlbnNp b25zLCBJIHRoaW5rIHRoZSByZWFsIGludGVyZXN0IGlzIGluIHRoZSBuZXcgc3BhY2VzIHdoZXJl IE9BdXRoIGRvZXNu4oCZdCB3b3JrIG91dCBhcyB3ZWxsLiBUaGUgbGlzdCBoZXJlIGlzIGZhciBm cm9tIGNvbXByZWhlbnNpdmUsIG9mIGNvdXJzZSwgYW5kIEnigJlkIGxpa2UgdG8ga2VlcCBidWls ZGluZyB0aGlzIG91dC4gSSBwbGFuIG9uIHB1dHRpbmcgdGhpbmdzIGludG8gYSBtb3JlIGZvcm1h bCBzdHJ1Y3R1cmUgYW5kIGdldHRpbmcgdGhlbSBvbnRvIHRoZSBodHRwczovL29hdXRoLnh5ei8g d2Vic2l0ZSBpbiB0aGUgbmVhciBmdXR1cmUgYWxvbmdzaWRlIGFueSBvdGhlcnMgdGhhdCBJIGdh dGhlci4NCg0KDQpFcGhlbWVyYWwgQ2xpZW50cy4gVGhlIE9BdXRoIG1vZGVsIHB1dHMgdGhlIG5v dGlvbiBvZiBhIOKAnGNsaWVudOKAnSBhcHBsaWNhdGlvbiBmcm9udCBhbmQgY2VudGVyLCBhbmQg dGhpcyBtYWtlcyBzZW5zZSBmcm9tIE9BdXRo4oCZcyByb290cyBhcyBhIHdheSB0byBjb25uZWN0 IHR3byB3ZWIgc2VydmVycyB0b2dldGhlci4gV2XigJl2ZSBzZWVuIHRoYXQgdGhpcyBicmVha3Mg ZG93biBpbiBkaWZmZXJlbnQgd2F5cyB3aGVuIHdlIGhhdmUgU1BB4oCZcywgbW9iaWxlIGFwcCBp bnN0YW5jZXMsIGV0Yy4gRHluYW1pYyBSZWdpc3RyYXRpb24gaGVscHMsIGJ1dCB3aXRoIHRydWx5 IGVwaGVtZXJhbCBjbGllbnRzIHlvdSBlbmQgdXAgd2l0aCBoYXZpbmcgYSBsb3Qgb2Ygb3JwaGFu ZWQgYXBwbGljYXRpb25zIHJlZ2lzdGVyZWQgaW50byB0aGUgQVMuIEluIHRoZSBsYXN0IGZldyB5 ZWFycywgT0F1dGggaGFzIGJlZW4gdHJlbmRpbmcgYXdheSBmcm9tIHByZS1yZWdpc3RyYXRpb24g b2YgYWxsIHRydXN0IG1hdGVyaWFsIGludG8gZW5hYmxpbmcgbW9yZSBydW50aW1lIGtleXMgYW5k IHNlY3JldHMuIEV4dGVuc2lvbnMgbGlrZSBQS0NFLCBEUG9QLCBPQXV0aC1NVExTLCBhbmQgVG9r ZW4gQmluZGluZyBhcmUgYWxsIGJhc2VkIG9uIHRoaXMgbm90aW9uLiBJbiBYWVosIHRoZSDigJx0 cmFuc2FjdGlvbuKAnSBpcyB0aGUgY29yZSBjb21wb25lbnQgb2YgdGhlIG1vZGVsLCBhbmQgZXZl cnl0aGluZyBoYW5ncyBvZmYgZnJvbSB0aGF0LiBBcyBzdWNoLCBhIGNsaWVudCBhcHBsaWNhdGlv biB0aGF0IGlkZW50aWZpZXMgaXRzZWxmIHRvIGEgbmV3IEFTLCBnZXRzIGEgdG9rZW4sIHRoZW4g ZGlzYXBwZWFycyB3aXRoIGl0cyB0b2tlbnMgaXMgYSByZWFzb25hYmxlIG1vZGVsIHRoYXQgbGVh dmVzIG5vIHRyYWNlIGJlaGluZC4NCg0KRGlzdHJpYnV0ZWQgUlPigJlzLiBJbiBoaWdobHkgZGlz dHJpYnV0ZWQgc3BhY2VzIHdpdGggY29tbW9uIEFQSXMsIHN1Y2ggYXMgYSBkaXN0cmlidXRlZCBz b2NpYWwgbmV0d29yaywgdGhlIFJT4oCZcyBhbGwgbmVlZCB0byByZWNvZ25pemUgbm90IG9ubHkg dGhlIHRva2VuIGJ1dCBhbHNvIHdobyB0aGUgdG9rZW4gcmVwcmVzZW50cy4gT0F1dGggaGFzIHNv bWUgcGllY2VzIHRoYXQgbGV0IHlvdSB0aWUgc29tZXRoaW5nIGxpa2UgdGhpcyB0b2dldGhlciwg c3VjaCBhcyBhIEpXVCB3aXRoIGtleSBkaXNjb3ZlcnkgYmFzZWQgb24gdGhlIGlzc3VlciBvZiB0 aGUgdG9rZW4sIGJ1dCB0aGlzIGRvZXNu4oCZdCBsZW5kIGl0c2VsZiB0byB1c2Ugd2l0aCBlcGhl bWVyYWwgY2xpZW50cyBhbmQgYm91bmQgdG9rZW5zIHdoZXJlIHRoZSBSUyB3b3VsZCBuZWVkIGEg d2F5IHRvIGZpZ3VyZSBvdXQgaG93IHRvIGdldCB0byB0aGUga2V5cy4gVGhpcyBraW5kIG9mIHRo aW5raW5nIGV4dGVuZHMgdG8gQVBJcyBkZXBsb3llZCBhcyBtaWNybyBzZXJ2aWNlcyBiZWhpbmQg Z2F0ZXdheXMsIG9yIGxhbWJkYSBmdW5jdGlvbnMgb24gYW4gZWxhc3RpYyBjbG91ZC4gV2hhdCBz ZXJ2ZXMgYW4g4oCcQVBJ4oCdIGVuZHBvaW50IGlzbuKAmXQgd2hhdCBpdCB1c2VkIHRvIGJlLCBh bmQgSSB0aGluayB3ZeKAmXZlIGdvdCBhIGJldHRlciBzdGFydGluZyBwbGFjZSB3aXRoIFhZWiB0 byBtYWtlIHRoZSBsaXZlcyBvZiBSUyBkZXZlbG9wZXJzIGVhc2llciBieSBoYXZpbmcgY2xlYXJl ciBtZWNoYW5pc21zIHRvIGJpbmQgdG9rZW5zIHRvIGJvdGggdGhlIHJpZ2h0cyB0aGV5IHJlcHJl c2VudCBhbmQgdGhlIHByZXNlbnRhdGlvbiBtZWNoYW5pc21zIHRoZXkgbmVlZC4NCg0KQm91bmQg QWNjZXNzIFRva2Vucy4gRXZlcnl0aGluZyBpcyBiZWFyZXIgdG9rZW5zIGluIE9BdXRoMi4gWWVz LCB3ZeKAmXJlIGdldHRpbmcgYmV0dGVyIGFib3V0IHRoaXMgd2l0aCBEUG9QIGFuZCBPQXV0aC1N VExTLCBhbmQgSSBzdXBwb3J0IHRoaXMgd29yayBleHRlbmRpbmcgT0F1dGggMi4gQnV0IHRoYXTi gJlzIGZhciBmcm9tIGNvbXBsZXRlIG9yIHdpZGVseSB1c2VkLiBBbmQgd2hhdOKAmXMgcmVhbGx5 IHdlaXJkLCB3aGVuIHlvdSBsb29rIGF0IHRoZXNlLCBpcyB0aGF0IHdl4oCZcmUgbm90IGV2ZW4g dXNpbmcgc29tZSBvZiB0aGUgaGFsZi1iYWtlZCBleHRlbnNpb24gcG9pbnRzIHRoYXQgd2UgOmRv OiBoYXZlIGluIE9BdXRoIDIsIHN1Y2ggYXMgdG9rZW4gdHlwZXMuIFdlIHJlYWxseSBzaG91bGRu 4oCZdCBiZSBjYWxsaW5nIHRoaW5ncyDigJxCZWFyZXLigJ0gdG9rZW5zIGFueW1vcmUgd2hlbiB0 aGV5IHJlcXVpcmUgeW91IHRvIGRvIG90aGVyIHRoaW5ncyBvbiB0b3Agb2YgcHJlc2VudGluZyB0 aGUgdG9rZW4sIGxpa2UgdXNpbmcgTVRMUyB3aXRoIGEgc3BlY2lmaWMgY2VydC4gUGx1cyB3ZeKA mXZlIGdvdCBhIGxvdCBvZiBjb25mbGF0aW9uIGJldHdlZW4gcGVvcGxlIHdobyB3YW50IHRvIHBh Y2sga2V5cyBpbnRvIHRoZSB0b2tlbnMgdGhlbXNlbHZlcyB2cy4gaGF2aW5nIHRoZSBrZXlzIHJl ZmVyZW5jZWQgYnkgdGhlIHRva2VuLCB3aGljaCBsZWFkcyB0byBjb25mdXNpb24gYXJvdW5kIHdo YXQgdGhpbmdzIGxpa2UgUkZDNzgwMCBhY3R1YWxseSBwcm92aWRlIGFuZCBkZWZpbmUuIFhZWiBn aXZlcyB1cyBhbiBvcHBvcnR1bml0eSB0byBoYXZlIGEgbXVjaCBjbGVhcmVyIG1vZGVsIGZvciB3 aGF0IGFuIGFjY2VzcyB0b2tlbiBpcywgYW5kIGhvdyBpdCBnZXRzIGJvdW5kIHRvIGEga2V5IGFu ZCBwcmVzZW50YXRpb24gbWVjaGFuaXNtIG9mIHZhcmlvdXMgdHlwZXMuIEJlYXJlciB0b2tlbnMg c3RpbGwgd29yayBoZXJlLCB0b28sIGJ1dCB0aGV5IGJlY29tZSBvbmUgYW1vbmcgbWFueSBjaXRp emVucywgbGlrZSB3ZSBhbHdheXMgaW50ZW5kZWQgT0F1dGgyIHRvIGhhdmUuDQoNCk11bHRpcGxl IFBhcnRpZXMuIE9BdXRoIGFzc3VtZXMgdGhhdCB0aGUgUmVzb3VyY2UgT3duZXIgaXMgdGhlIHBl cnNvbiBvcGVyYXRpbmcgdGhlIGNsaWVudCBhcHBsaWNhdGlvbi4gVU1BIGV4dGVuZHMgdGhpcyB0 byBhbGxvd2luZyB0aGUgUmVxdWVzdGluZyBQYXJ0eSB0byBiZSB0aGUgb25lIHVzaW5nIHRoZSBj bGllbnQsIGJ1dCBpdCBnZW5lcmFsbHkgZG9lc27igJl0IGNvbGxhcHNlIGNsZWFubHkgaW50byB0 aGUgY2FzZXMgd2hlcmUgdGhlIFJPIDppczogdGhlIHBhcnR5IHVzaW5nIHRoZSBjbGllbnQgc2lu Y2UgdGhlIGNsYWltcyBnYXRoZXJpbmcgZW5kcG9pbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50IGFyZW7igJl0IHF1aXRlIHRoZSBzYW1lIGluIGNvbmNlcHQuIFVNQeKAmXMgYWxzbyBh cmd1YWJseSBwcmV0dHkgY29tcGxleCwgYnV0IEkgdGhpbmsgaXQgOmhhZDogdG8gYmUgaW4gb3Jk ZXIgdG8gZml0IGludG8gdGhlIE9BdXRoMiB3b3JsZC4gQW5kIHRoZW4gd2UgaGF2ZSBleHRlbnNp b25zIGluIHRoZSBpZGVudGl0eSBzcGFjZSBsaWtlIENJQkEgd2hpY2ggaGF2ZSBtdWx0aXBsZSBj aGFubmVscyBvZiBpbnRlcmFjdGlvbiB3aXRoIHBvdGVudGlhbGx5IG11bHRpcGxlIHVzZXJzLiBX ZeKAmXZlIGFsc28gZ290IHRoZSBEZXZpY2UgRmxvdyB3aGljaCBhbGxvd3MgbXVsdGlwbGUgY2hh bm5lbHMgY29ubmVjdGVkIGJ5IGEgcmVhbC13b3JsZCBhcnRpZmFjdCAodGhlIHVzZXIgY29kZSks IGFuZCBJIGtub3cgb2YgYXQgbGVhc3Qgb25lIGRlcGxveW1lbnQgd2hlcmUgdGhlIGludGVyYWN0 aXZlIHBhZ2Ugd2hlcmUgdGhlIGNvZGUgaXMgZW50ZXJlZCBpcyB1bmRlciB0aGUgY29udHJvbCBv ZiBzb21lb25lIG90aGVyIHRoYW4gdGhlIHJlc291cmNlIG93bmVyLCBzaW5jZSBpdOKAmXMgYSB0 cmFuc2l0aXZlIHRydXN0IG1vZGVsIGF0IHBsYXkuIFRoaXMgaXMgYW4gb2ZmLWxhYmVsIHVzZSwg d2hpY2ggWFlaIGNhbiBtYWtlIG11Y2ggbW9yZSBleHBsaWNpdGx5IGJ1aWx0LWluLiBCeSBzZXBh cmF0aW5nIHRoZSBub3Rpb24gb2YgdGhlIG5hdHVyZSBvZiB0aGUgc29mdHdhcmUgZnJvbSB0aGUg bmF0dXJlIG9mIHRoZSB1c2Vy4oCZcyBpbnRlcmFjdGlvbiwgd2UgY2FuIGFkZHJlc3MgYSB3aWRl ciBhcnJheSBvZiBtdWx0aS1wYXJ0eSBjb25maWd1cmF0aW9ucyB3aXRob3V0IE9BdXRo4oCZcyBz YW1lIGNvcmUgYXNzdW1wdGlvbnMuIE5hdOKAmXMgYWxyZWFkeSB0YWxrZWQgYWJvdXQgdGhpcyBr aW5kIG9mIHRoaW5nIGhlcmUgb24gdGhlIGxpc3QsIGFuZCBJIHRoaW5rIGZsZXhpYmlsaXR5IGFy b3VuZCB3aG8gZG9lcyB3aGF0IGlzIGdvaW5nIHRvIGJlIGEga2V5IGRpZmZlcmVuY2UuDQoNCktu b3duIFVzZXIuIFdoZW4gdGhlIGNsaWVudCBrbm93cyBzb21ldGhpbmcgYWJvdXQgdGhlIHVzZXIs IGl0IHNob3VsZCBiZSBhYmxlIHRvIGV4cHJlc3MgdGhhdCB0byB0aGUgQVMgYXMgcGFydCBvZiB0 aGUgdHJhbnNhY3Rpb24gcmVxdWVzdC4gT0F1dGggZG9lc27igJl0IGhhdmUgYW55IHBsYWNlIGZv ciB0aGlzIHRvIGhhcHBlbiwgc2luY2UgbW9zdCBpbnRlcmFjdGl2ZSBmbG93cyBzdGFydCBmcm9t IHRoZSBmcm9udCBjaGFubmVsLiBUaGUgb25lIGNvcmUgZmxvdyB0aGF0IGRvZXMgYWxsb3cgdGhp cyBpcyB0aGUgcmVzb3VyY2Utb3duZXIgcGFzc3dvcmQgZ3JhbnQsIHdoaWNoIG9mIGNvdXJzZSBl eHBvc2VzIHRoZSBjbGllbnQgc29mdHdhcmUgdG8gYSB1c2Vy4oCZcyBtZW1vcml6ZWQgc2hhcmVk IHNlY3JldCAodGhlaXIgcGFzc3dvcmQpLiBJdCBjYW7igJl0IGJlIHVzZWQgd2l0aCBhbnkga2lu ZCBvZiBjaGFsbGVuZ2UtcmVzcG9uc2Ugb3IgYXNzZXJ0aW9uLWJhc2VkIHN5c3RlbS4gV2UgZG9u 4oCZdCBoYXZlIGFueSB3YXkgdG8gcGFzcyBhc3NlcnRpb25zIG9yIGNsYWltcyBhYm91dCB0aGUg dXNlciwgdW5sZXNzIHdlIHdhbnRlZCB0byB1c2UgdGhlIHRva2VuIGV4Y2hhbmdlIGdyYW50IOKA lCBhbmQgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoaXMgaXMgYWJ1c2luZyB0aGUgZGVmaW5pdGlvbiBv ZiDigJx0b2tlbuKAnSBpbiB0aGlzIHNwYWNlIGFuZCBnZXR0aW5nIHVzIGludG8gV1MtKiB0ZXJy aXRvcnkuIE9uZSBzdG9wIGdhcCB0aGF0IEkga25vdyBvZiBpbiB0aGUgd2lsZCBpcyB0byB1c2Ug dG9rZW4gZXhjaGFuZ2UgdG8gcHJlc2VudCBhIHVzZXItdG9rZW4gdG8gdGhlIEFTLCBhbmQgdGhl biBicmFuY2ggYmVoYXZpb3I6IGlmIHRoZSBleGNoYW5nZSB3b3JrcywgdXNlIHRoZSByZXN1bHRp bmcgdG9rZW4uIElmIHRoZSBleGNoYW5nZSBmYWlscyAoZHVlIHRvIHRoZSB1c2VyIG5lZWRpbmcg dG8gaW50ZXJhY3Qgb3IgdGhlIHRydXN0IG5vdCBiZWluZyBoaWdoIGVub3VnaCBmb3IgdGhlIHJl cXVlc3QpLCB0aGVuIHlvdSBiYWlsIG91dCBvZiB0aGUgZXhjaGFuZ2UgZ3JhbnQgYW5kIGludG8g b25lIG9mIHRoZSBpbnRlcmFjdGl2ZSBncmFudHMgaW5zdGVhZCB0byBnZXQgdGhlIHVzZXIgdG8g dGhlIGZyb250IGNoYW5uZWwuIFNpbmNlIHlvdSBzdGFydCBpbiB0aGUgYmFjayBjaGFubmVsIGlu IFhZWiwgdGhlIGNsaWVudCBjYW4gc2VuZCBhbG9uZyBhbnkgaW5mb3JtYXRpb24gdGhhdCBpdCBo YXMgYWJvdXQgdGhlIHVzZXIgcmlnaHQgZnJvbSB0aGUgc3RhcnQsIGFuZCB0aGUgQVMgY2FuIGRl dGVybWluZSB3aGF0IGVsc2UgaXQgbmVlZHMgdG8gZG8uIFRoaXMgY291bGQgaW5jbHVkZSBpbnRl cmFjdGluZyB3aXRoIHRoZSB1c2VyIGRpcmVjdGx5LCBvciBldmVuIGJ1aWxkaW5nIHVwIGEgY2hh bGxlbmdlLXJlc3BvbnNlIGZvciBhIHVzZXLigJlzIGNyZWRlbnRpYWwgdG8gYmUgcHJlc2VudGVk IHZpYSB0aGUgY2xpZW50IGFuZCByZXR1cm5lZCB0aHJvdWdoIGEgdHJhbnNhY3Rpb24gY29udGlu dWUgbWVzc2FnZS4gT24gdG9wIG9mIHRoaXMsIHNpbmNlIHdl4oCZcmUgZG9pbmcgSlNPTiBpbiB0 aGUgYmFjayBjaGFubmVsLCB3ZeKAmXZlIGdvdCBhIGxvdCBtb3JlIGV4cHJlc3NpdmVuZXNzIGZv ciB0aGUgZGF0YSB3ZeKAmXJlIHNlbmRpbmcgYmFjayBhbmQgZm9ydGggYmV5b25kIGZvcm0tZW5j b2RlZCBzdHJpbmdzLg0KDQpOb24tYXV0aG9yaXphdGlvbiBJbnRlcmFjdGlvbi4gVGhpcyBpcyBv bmUgdGhhdCBBbm5hYmVsbGUgYnJvdWdodCB1cCBpbiBNb250cmVhbCwgYW5kIEnigJlsbCBhZG1p dCB0aGF0IGl04oCZcyBhIGJpdCBmdXJ0aGVyIG91dCB0aGFuIHRoZSBvdGhlcnMgYmVjYXVzZSBp dOKAmXMgbm90IGV2ZW4gYW4gYXV0aG9yaXphdGlvbiBjYXNlLiBJbiB0aGlzLCBhbiBhcHBsaWNh dGlvbiB0cmllcyB0byBkbyBzb21ldGhpbmcgYXQgYW4gQVBJIGJ1dCBmaW5kcyBvdXQgdGhhdCB0 aGUgdXNlciBuZWVkcyB0byBpbnRlcmFjdCB3aXRoIHRoZSBzZXJ2aWNlLiBUaGlzIG1pZ2h0IGJl IHRvIGNvbnNlbnQsIGxpa2UgaW4gT0F1dGgsIGJ1dCBpdCBhbHNvIG1pZ2h0IGJlIHRvIGVudGVy IGFuIHVwZGF0ZWQgY3JlZGl0IGNhcmQuIEJhc2ljYWxseSwgYSBiYWNrZW5kIHN5c3RlbSBuZWVk cyB0byBzYXkg4oCcT2ggSSB0aG91Z2h0IHRoaW5ncyB3ZXJlIGZpbmUgYnV0IEkgbmVlZCB0byB0 YWxrIHRvIHNvbWVvbmUgd2l0aCBhIHdlYnBhZ2UgcmlnaHQgbm934oCdLCBtdWNoIGxpa2UgdGhl IHRva2VuLWV4Y2hhbmdlLWZhaWx1cmUgbW9kZWwgaW4gdGhlIGxhc3QgcGFyYWdyYXBoLiBUaGlz IGZpdHMgWFla4oCZcyBtb2RlbCBvZiBwaW5naW5nIHRoZSBBUyB0byB0cnkgYW5kIGRvIHNvbWV0 aGluZywgYnV0IGhhdmluZyB0aGUgQVMgb3B0aW9uYWxseSBjb21lIGJhY2sgYW5kIHNheSDigJxo ZXkgZ2V0IHRoZSB1c2VyIHRvIHRoaXMgd2VicGFnZSwgSSBuZWVkIHRvIHRhbGsgdG8gdGhlbeKA nSwgd2l0aCB0aGUgbWFpbiBkaWZmZXJlbmNlIHRoYXQgaXTigJlzIG5vdCBpbnNpZGUgYSB0cmFu c2FjdGlvbiByZXF1ZXN0LCBwZXIgc2UuIEkgdGhpbmsgdGhlcmXigJlzIHNvbWV0aGluZyBpbnRl cmVzdGluZyBoYXBwZW5pbmcgaGVyZSB0aG91Z2ggdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIuDQoN CktleSBEaXN0cmlidXRpb24uIFRoaXMgaXMgYW5vdGhlciBvbmUgdGhhdCBsYW5kcyB1cyBvdXRz aWRlIG9mIHdoYXQgT0F1dGggaXMgdXNlZCBmb3IsIGJ1dCBub3QgdGhhdCBmYXIgZnJvbSBpdHMg aW50ZW50LiBJZiB3ZSBoYXZlIGJvdW5kIGFjY2VzcyB0b2tlbnMsIHRoYXQgbWVhbnMgdGhlIHRv a2VucyB0aGVtc2VsdmVzIGFyZSBib3VuZCB0byBrZXlzLiBXZWxsLCB0aG9zZSBrZXlzIGNvdWxk IGFsc28gYmUgdXNlZCBpbiBvdGhlciBub24tYWNjZXNzLXRva2VuLWJhc2VkIHByZXNlbnRhdGlv biBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMuIE1heWJlIHRoZSBjbGllbnQgbmVlZHMgdG8gc2ln biBhbiBhc3NlcnRpb24gYWJvdXQgaXRzZWxmLCBvciBhIGRvY3VtZW50LCBvciBhIFNFVCBmb3Ig YXVkaXQgcHVycG9zZXMuIEluIGFsbCBvZiB0aGVzZSBjYXNlcywgSSB0aGluayBpdCBjYW4gYmUg YXJndWVkIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiByZXByZXNlbnRzIGhlcmUgd2hhdCB0aGUga2V5 IGNhbiBiZSB1c2VkIGZvciwgd2hpY2ggbWlnaHQgYmUgaW4gYWRkaXRpb24gdG8gaXRzIHByZXNl bnRhdGlvbiBhdCBhbiBBUEkgaXRzZWxmLiBJ4oCZdmUgYmVlbiBpbnZvbHZlZCB3aXRoIHBsZW50 eSBvZiBzeXN0ZW1zIHRoYXQgYm9pbCBkb3duIHRvIGEga2V5IGV4Y2hhbmdlIG9yIGRpc3RyaWJ1 dGlvbiBwcm9ibGVtLCBhbmQgd2hlbiB0aGUgdHJ1c3QgaXMgdXNlci1kcml2ZW4sIGl04oCZcyBu b3QgdGhhdCBkaWZmZXJlbnQgZnJvbSB3aGF0IHdl4oCZcmUgZG9pbmcgd2l0aCB0b2tlbnMgaW4g WFlaLg0KDQpTdHJ1Y3R1cmVkIFJlc291cmNlcy4gT3IgaW4gb3RoZXIgd29yZHMsIOKAnHN0cnVj dHVyZWQgc2NvcGVz4oCdIGxpa2UgVG9yc3RlbiBpcyBwcm9wb3NpbmcuIEFnYWluLCBJIHN1cHBv cnQgdGhpcyB3b3JrIGZvciBleHRlbmRpbmcgT0F1dGgsIGJ1dCBpdOKAmXMgZ290IGEgbG90IG9m IGh1cmRsZXMgdG8gb3ZlcmNvbWUuIEZvciBvbmUsIGVuY29kaW5nIHRoZSBzdHJ1Y3R1cmVzIGFz IGZvcm0gcGFyYW1ldGVycyBpcyBhd2t3YXJkLCBhdCBiZXN0LiBTZWNvbmQsIHRoZSBjb21iaW5h dGlvbiBvZiDigJxwbGFpbuKAnSBzY29wZXMgd2l0aCBzdHJ1Y3R1cmVkIHNjb3BlcyB3b3VsZCBu ZWVkIHRvIGJlIGNhcmVmdWxseSBkZWZpbmVkLCBzaW5jZSBhIOKAnHBsYWlu4oCdIHNjb3BlIGNh biByZXByZXNlbnQgc28gbWFueSBkaWZmZXJlbnQgYXNwZWN0cyBvZiB0aGUgcmVxdWVzdC4gQW5k IGZpbmFsbHksIHdoYXQgZ29lcyBpbnRvIHRoZSBzdHJ1Y3R1cmUgaXMgZ29pbmcgdG8gYmUgYSBi aWcgaXNzdWUgb2YgcG9zc2libGUgY29udGVudGlvbiBzaW5jZSBub3Qgb25seSBhcmUgYWxsIEFQ SXMgdmVyeSBkaWZmZXJlbnQsIHNvIGZhciBBUElzIGhhdmUgdXNlZCDigJxzY29wZeKAnSBpbiB2 ZXJ5IGRpZmZlcmVudCB3YXlzLiBXaXRoIFhZWiwgcmVzb3VyY2UgcmVxdWVzdHMgaGF2ZSBhIG11 Y2ggbW9yZSB3ZWxsLWRlZmluZWQgc2V0dXA6IHRoZXkgZXhpc3QgYXMgb2JqZWN0cyBkZXNjcmli aW5nIHRoZSByZXF1ZXN0LCB0aGV54oCZcmUgY29tYmluZWQgd2l0aCDigJxBTkTigJ0gc2VtYW50 aWNzLCBhbmQgdGhleSBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgc3RyaW5ncyB0aGF0IGRlY29kZSBl eHBsaWNpdGx5IHRvIHRoZSByZXByZXNlbnRhdGlvbmFsIG9iamVjdHMuDQoNCg0KDQpJ4oCZZCBs aWtlIHRvIGhlYXIgZnJvbSBvdGhlcnMgYWJvdXQgd2hhdCBvdGhlciB1c2UgY2FzZXMgeW914oCZ dmUgcnVuIGludG8gYXQgdGhlIGVkZ2VzIG9mIE9BdXRoIChvciByZWxhdGVkIHNwYWNlKSB0aGF0 IGRvbuKAmXQgcXVpdGUgZml0Lg0KDQpJIGhhdmUgcmVhY2hlZCBvdXQgdG8gdGhlIGNoYWlycyBh bmQgdGhlIEFEIHRvIGhlbHAgZGV0ZXJtaW5lIG5leHQgc3RlcHMgZm9yIFhZWiB3aXRoaW4gdGhl IElFVEYuIEkgaG9wZSB0byBiZSBhYmxlIHRvIGF0dGVuZCB0aGUgU2luZ2Fwb3JlIG1lZXRpbmcg YW5kIGNvbnRpbnVlIHRoZSBjb252ZXJzYXRpb24gaW4gcGVyc29uIHRoZXJlIGFzIHdlbGwuDQoN CuKAlCBKdXN0aW4NCg0K --_000_2E8DAF9028344B08AF1C2A9928BB6869mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <12F494543CBF8F41ABC4A1B852AF8D3B@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFzIHByb21pc2VkIGluIE1vbnRyZWFsLCBJIGhh dmUgc3RhcnRlZCB0byBwdWxsIHRvZ2V0aGVyIHVzZSBjYXNlcyB0aGF0IGZpdCBYWVrigJlzIG1v ZGVsIGJldHRlciB0aGFuIHRoZXkgZml0IHRyYWRpdGlvbmFsIE9BdXRoLiBXaGlsZSBJ4oCZdmUg YmVlbiBhYmxlIHRvIHdvcmsgb3V0IGhvdyBYWVogd29ya3MgZm9yIHRoZSBtb3N0IGNvbW1vbiBP QXV0aCBkZXBsb3ltZW50cyBhbmQgZXh0ZW5zaW9ucywgSSB0aGluayB0aGUgcmVhbCBpbnRlcmVz dCBpcw0KIGluIHRoZSBuZXcgc3BhY2VzIHdoZXJlIE9BdXRoIGRvZXNu4oCZdCB3b3JrIG91dCBh cyB3ZWxsLiBUaGUgbGlzdCBoZXJlIGlzIGZhciBmcm9tIGNvbXByZWhlbnNpdmUsIG9mIGNvdXJz ZSwgYW5kIEnigJlkIGxpa2UgdG8ga2VlcCBidWlsZGluZyB0aGlzIG91dC4gSSBwbGFuIG9uIHB1 dHRpbmcgdGhpbmdzIGludG8gYSBtb3JlIGZvcm1hbCBzdHJ1Y3R1cmUgYW5kIGdldHRpbmcgdGhl bSBvbnRvIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly9vYXV0aC54eXovIiBjbGFzcz0iIj5odHRwczov L29hdXRoLnh5ei88L2E+IHdlYnNpdGUgaW4gdGhlIG5lYXIgZnV0dXJlIGFsb25nc2lkZSBhbnkg b3RoZXJzIHRoYXQgSSBnYXRoZXIuDQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkVwaGVtZXJhbCBDbGllbnRzLjwvYj4mbmJzcDtUaGUg T0F1dGggbW9kZWwgcHV0cyB0aGUgbm90aW9uIG9mIGEg4oCcY2xpZW504oCdIGFwcGxpY2F0aW9u IGZyb250IGFuZCBjZW50ZXIsIGFuZCB0aGlzIG1ha2VzIHNlbnNlIGZyb20gT0F1dGjigJlzIHJv b3RzIGFzIGEgd2F5IHRvIGNvbm5lY3QgdHdvIHdlYiBzZXJ2ZXJzIHRvZ2V0aGVyLiBXZeKAmXZl IHNlZW4gdGhhdCB0aGlzIGJyZWFrcyBkb3duIGluIGRpZmZlcmVudA0KIHdheXMgd2hlbiB3ZSBo YXZlIFNQQeKAmXMsIG1vYmlsZSBhcHAgaW5zdGFuY2VzLCBldGMuIER5bmFtaWMgUmVnaXN0cmF0 aW9uIGhlbHBzLCBidXQgd2l0aCB0cnVseSBlcGhlbWVyYWwgY2xpZW50cyB5b3UgZW5kIHVwIHdp dGggaGF2aW5nIGEgbG90IG9mIG9ycGhhbmVkIGFwcGxpY2F0aW9ucyByZWdpc3RlcmVkIGludG8g dGhlIEFTLiBJbiB0aGUgbGFzdCBmZXcgeWVhcnMsIE9BdXRoIGhhcyBiZWVuIHRyZW5kaW5nIGF3 YXkgZnJvbSBwcmUtcmVnaXN0cmF0aW9uDQogb2YgYWxsIHRydXN0IG1hdGVyaWFsIGludG8gZW5h YmxpbmcgbW9yZSBydW50aW1lIGtleXMgYW5kIHNlY3JldHMuIEV4dGVuc2lvbnMgbGlrZSBQS0NF LCBEUG9QLCBPQXV0aC1NVExTLCBhbmQgVG9rZW4gQmluZGluZyBhcmUgYWxsIGJhc2VkIG9uIHRo aXMgbm90aW9uLiBJbiBYWVosIHRoZSDigJx0cmFuc2FjdGlvbuKAnSBpcyB0aGUgY29yZSBjb21w b25lbnQgb2YgdGhlIG1vZGVsLCBhbmQgZXZlcnl0aGluZyBoYW5ncyBvZmYgZnJvbSB0aGF0LiBB cw0KIHN1Y2gsIGEgY2xpZW50IGFwcGxpY2F0aW9uIHRoYXQgaWRlbnRpZmllcyBpdHNlbGYgdG8g YSBuZXcgQVMsIGdldHMgYSB0b2tlbiwgdGhlbiBkaXNhcHBlYXJzIHdpdGggaXRzIHRva2VucyBp cyBhIHJlYXNvbmFibGUgbW9kZWwgdGhhdCBsZWF2ZXMgbm8gdHJhY2UgYmVoaW5kLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xh c3M9IiI+RGlzdHJpYnV0ZWQgUlPigJlzLjwvYj4mbmJzcDtJbiBoaWdobHkgZGlzdHJpYnV0ZWQg c3BhY2VzIHdpdGggY29tbW9uIEFQSXMsIHN1Y2ggYXMgYSBkaXN0cmlidXRlZCBzb2NpYWwgbmV0 d29yaywgdGhlIFJT4oCZcyBhbGwgbmVlZCB0byByZWNvZ25pemUgbm90IG9ubHkgdGhlIHRva2Vu IGJ1dCBhbHNvIHdobyB0aGUgdG9rZW4gcmVwcmVzZW50cy4gT0F1dGggaGFzIHNvbWUgcGllY2Vz IHRoYXQgbGV0IHlvdSB0aWUNCiBzb21ldGhpbmcgbGlrZSB0aGlzIHRvZ2V0aGVyLCBzdWNoIGFz IGEgSldUIHdpdGgga2V5IGRpc2NvdmVyeSBiYXNlZCBvbiB0aGUgaXNzdWVyIG9mIHRoZSB0b2tl biwgYnV0IHRoaXMgZG9lc27igJl0IGxlbmQgaXRzZWxmIHRvIHVzZSB3aXRoIGVwaGVtZXJhbCBj bGllbnRzIGFuZCBib3VuZCB0b2tlbnMgd2hlcmUgdGhlIFJTIHdvdWxkIG5lZWQgYSB3YXkgdG8g ZmlndXJlIG91dCBob3cgdG8gZ2V0IHRvIHRoZSBrZXlzLiBUaGlzIGtpbmQgb2YgdGhpbmtpbmcN CiBleHRlbmRzIHRvIEFQSXMgZGVwbG95ZWQgYXMgbWljcm8gc2VydmljZXMgYmVoaW5kIGdhdGV3 YXlzLCBvciBsYW1iZGEgZnVuY3Rpb25zIG9uIGFuIGVsYXN0aWMgY2xvdWQuIFdoYXQgc2VydmVz IGFuIOKAnEFQSeKAnSBlbmRwb2ludCBpc27igJl0IHdoYXQgaXQgdXNlZCB0byBiZSwgYW5kIEkg dGhpbmsgd2XigJl2ZSBnb3QgYSBiZXR0ZXIgc3RhcnRpbmcgcGxhY2Ugd2l0aCBYWVogdG8gbWFr ZSB0aGUgbGl2ZXMgb2YgUlMgZGV2ZWxvcGVycyBlYXNpZXIgYnkNCiBoYXZpbmcgY2xlYXJlciBt ZWNoYW5pc21zIHRvIGJpbmQgdG9rZW5zIHRvIGJvdGggdGhlIHJpZ2h0cyB0aGV5IHJlcHJlc2Vu dCBhbmQgdGhlIHByZXNlbnRhdGlvbiBtZWNoYW5pc21zIHRoZXkgbmVlZC48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIi PkJvdW5kIEFjY2VzcyBUb2tlbnMuPC9iPiZuYnNwO0V2ZXJ5dGhpbmcgaXMgYmVhcmVyIHRva2Vu cyBpbiBPQXV0aDIuIFllcywgd2XigJlyZSBnZXR0aW5nIGJldHRlciBhYm91dCB0aGlzIHdpdGgg RFBvUCBhbmQgT0F1dGgtTVRMUywgYW5kIEkgc3VwcG9ydCB0aGlzIHdvcmsgZXh0ZW5kaW5nIE9B dXRoIDIuIEJ1dCB0aGF04oCZcyBmYXIgZnJvbSBjb21wbGV0ZSBvciB3aWRlbHkgdXNlZC4gQW5k IHdoYXTigJlzIHJlYWxseQ0KIHdlaXJkLCB3aGVuIHlvdSBsb29rIGF0IHRoZXNlLCBpcyB0aGF0 IHdl4oCZcmUgbm90IGV2ZW4gdXNpbmcgc29tZSBvZiB0aGUgaGFsZi1iYWtlZCBleHRlbnNpb24g cG9pbnRzIHRoYXQgd2UgOmRvOiBoYXZlIGluIE9BdXRoIDIsIHN1Y2ggYXMgdG9rZW4gdHlwZXMu IFdlIHJlYWxseSBzaG91bGRu4oCZdCBiZSBjYWxsaW5nIHRoaW5ncyDigJxCZWFyZXLigJ0gdG9r ZW5zIGFueW1vcmUgd2hlbiB0aGV5IHJlcXVpcmUgeW91IHRvIGRvIG90aGVyIHRoaW5ncyBvbg0K IHRvcCBvZiBwcmVzZW50aW5nIHRoZSB0b2tlbiwgbGlrZSB1c2luZyBNVExTIHdpdGggYSBzcGVj aWZpYyBjZXJ0LiBQbHVzIHdl4oCZdmUgZ290IGEgbG90IG9mIGNvbmZsYXRpb24gYmV0d2VlbiBw ZW9wbGUgd2hvIHdhbnQgdG8gcGFjayBrZXlzIGludG8gdGhlIHRva2VucyB0aGVtc2VsdmVzIHZz LiBoYXZpbmcgdGhlIGtleXMgcmVmZXJlbmNlZCBieSB0aGUgdG9rZW4sIHdoaWNoIGxlYWRzIHRv IGNvbmZ1c2lvbiBhcm91bmQgd2hhdCB0aGluZ3MgbGlrZQ0KIFJGQzc4MDAgYWN0dWFsbHkgcHJv dmlkZSBhbmQgZGVmaW5lLiBYWVogZ2l2ZXMgdXMgYW4gb3Bwb3J0dW5pdHkgdG8gaGF2ZSBhIG11 Y2ggY2xlYXJlciBtb2RlbCBmb3Igd2hhdCBhbiBhY2Nlc3MgdG9rZW4gaXMsIGFuZCBob3cgaXQg Z2V0cyBib3VuZCB0byBhIGtleSBhbmQgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBvZiB2YXJpb3Vz IHR5cGVzLiBCZWFyZXIgdG9rZW5zIHN0aWxsIHdvcmsgaGVyZSwgdG9vLCBidXQgdGhleSBiZWNv bWUgb25lIGFtb25nDQogbWFueSBjaXRpemVucywgbGlrZSB3ZSBhbHdheXMgaW50ZW5kZWQgT0F1 dGgyIHRvIGhhdmUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5NdWx0aXBsZSBQYXJ0aWVzPC9iPi4gT0F1 dGggYXNzdW1lcyB0aGF0IHRoZSBSZXNvdXJjZSBPd25lciBpcyB0aGUgcGVyc29uIG9wZXJhdGlu ZyB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLiBVTUEgZXh0ZW5kcyB0aGlzIHRvIGFsbG93aW5nIHRo ZSBSZXF1ZXN0aW5nIFBhcnR5IHRvIGJlIHRoZSBvbmUgdXNpbmcgdGhlIGNsaWVudCwgYnV0IGl0 IGdlbmVyYWxseSBkb2VzbuKAmXQgY29sbGFwc2UgY2xlYW5seQ0KIGludG8gdGhlIGNhc2VzIHdo ZXJlIHRoZSBSTyA6aXM6IHRoZSBwYXJ0eSB1c2luZyB0aGUgY2xpZW50IHNpbmNlIHRoZSBjbGFp bXMgZ2F0aGVyaW5nIGVuZHBvaW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmVu 4oCZdCBxdWl0ZSB0aGUgc2FtZSBpbiBjb25jZXB0LiBVTUHigJlzIGFsc28gYXJndWFibHkgcHJl dHR5IGNvbXBsZXgsIGJ1dCBJIHRoaW5rIGl0IDpoYWQ6IHRvIGJlIGluIG9yZGVyIHRvIGZpdCBp bnRvIHRoZSBPQXV0aDINCiB3b3JsZC4gQW5kIHRoZW4gd2UgaGF2ZSBleHRlbnNpb25zIGluIHRo ZSBpZGVudGl0eSBzcGFjZSBsaWtlIENJQkEgd2hpY2ggaGF2ZSBtdWx0aXBsZSBjaGFubmVscyBv ZiBpbnRlcmFjdGlvbiB3aXRoIHBvdGVudGlhbGx5IG11bHRpcGxlIHVzZXJzLiBXZeKAmXZlIGFs c28gZ290IHRoZSBEZXZpY2UgRmxvdyB3aGljaCBhbGxvd3MgbXVsdGlwbGUgY2hhbm5lbHMgY29u bmVjdGVkIGJ5IGEgcmVhbC13b3JsZCBhcnRpZmFjdCAodGhlIHVzZXIgY29kZSksDQogYW5kIEkg a25vdyBvZiBhdCBsZWFzdCBvbmUgZGVwbG95bWVudCB3aGVyZSB0aGUgaW50ZXJhY3RpdmUgcGFn ZSB3aGVyZSB0aGUgY29kZSBpcyBlbnRlcmVkIGlzIHVuZGVyIHRoZSBjb250cm9sIG9mIHNvbWVv bmUgb3RoZXIgdGhhbiB0aGUgcmVzb3VyY2Ugb3duZXIsIHNpbmNlIGl04oCZcyBhIHRyYW5zaXRp dmUgdHJ1c3QgbW9kZWwgYXQgcGxheS4gVGhpcyBpcyBhbiBvZmYtbGFiZWwgdXNlLCB3aGljaCBY WVogY2FuIG1ha2UgbXVjaCBtb3JlIGV4cGxpY2l0bHkNCiBidWlsdC1pbi4gQnkgc2VwYXJhdGlu ZyB0aGUgbm90aW9uIG9mIHRoZSBuYXR1cmUgb2YgdGhlIHNvZnR3YXJlIGZyb20gdGhlIG5hdHVy ZSBvZiB0aGUgdXNlcuKAmXMgaW50ZXJhY3Rpb24sIHdlIGNhbiBhZGRyZXNzIGEgd2lkZXIgYXJy YXkgb2YgbXVsdGktcGFydHkgY29uZmlndXJhdGlvbnMgd2l0aG91dCBPQXV0aOKAmXMgc2FtZSBj b3JlIGFzc3VtcHRpb25zLiBOYXTigJlzIGFscmVhZHkgdGFsa2VkIGFib3V0IHRoaXMga2luZCBv ZiB0aGluZyBoZXJlDQogb24gdGhlIGxpc3QsIGFuZCBJIHRoaW5rIGZsZXhpYmlsaXR5IGFyb3Vu ZCB3aG8gZG9lcyB3aGF0IGlzIGdvaW5nIHRvIGJlIGEga2V5IGRpZmZlcmVuY2UuJm5ic3A7PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5Lbm93biBVc2VyPC9iPi4gV2hlbiB0aGUgY2xpZW50IGtub3dzIHNvbWV0aGlu ZyBhYm91dCB0aGUgdXNlciwgaXQgc2hvdWxkIGJlIGFibGUgdG8gZXhwcmVzcyB0aGF0IHRvIHRo ZSBBUyBhcyBwYXJ0IG9mIHRoZSB0cmFuc2FjdGlvbiByZXF1ZXN0LiBPQXV0aCBkb2VzbuKAmXQg aGF2ZSBhbnkgcGxhY2UgZm9yIHRoaXMgdG8gaGFwcGVuLCBzaW5jZSBtb3N0IGludGVyYWN0aXZl IGZsb3dzIHN0YXJ0IGZyb20NCiB0aGUgZnJvbnQgY2hhbm5lbC4gVGhlIG9uZSBjb3JlIGZsb3cg dGhhdCBkb2VzIGFsbG93IHRoaXMgaXMgdGhlIHJlc291cmNlLW93bmVyIHBhc3N3b3JkIGdyYW50 LCB3aGljaCBvZiBjb3Vyc2UgZXhwb3NlcyB0aGUgY2xpZW50IHNvZnR3YXJlIHRvIGEgdXNlcuKA mXMgbWVtb3JpemVkIHNoYXJlZCBzZWNyZXQgKHRoZWlyIHBhc3N3b3JkKS4gSXQgY2Fu4oCZdCBi ZSB1c2VkIHdpdGggYW55IGtpbmQgb2YgY2hhbGxlbmdlLXJlc3BvbnNlIG9yIGFzc2VydGlvbi1i YXNlZA0KIHN5c3RlbS4gV2UgZG9u4oCZdCBoYXZlIGFueSB3YXkgdG8gcGFzcyBhc3NlcnRpb25z IG9yIGNsYWltcyBhYm91dCB0aGUgdXNlciwgdW5sZXNzIHdlIHdhbnRlZCB0byB1c2UgdGhlIHRv a2VuIGV4Y2hhbmdlIGdyYW50IOKAlCBhbmQgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoaXMgaXMgYWJ1 c2luZyB0aGUgZGVmaW5pdGlvbiBvZiDigJx0b2tlbuKAnSBpbiB0aGlzIHNwYWNlIGFuZCBnZXR0 aW5nIHVzIGludG8gV1MtKiB0ZXJyaXRvcnkuIE9uZSBzdG9wIGdhcCB0aGF0DQogSSBrbm93IG9m IGluIHRoZSB3aWxkIGlzIHRvIHVzZSB0b2tlbiBleGNoYW5nZSB0byBwcmVzZW50IGEgdXNlci10 b2tlbiB0byB0aGUgQVMsIGFuZCB0aGVuIGJyYW5jaCBiZWhhdmlvcjogaWYgdGhlIGV4Y2hhbmdl IHdvcmtzLCB1c2UgdGhlIHJlc3VsdGluZyB0b2tlbi4gSWYgdGhlIGV4Y2hhbmdlIGZhaWxzIChk dWUgdG8gdGhlIHVzZXIgbmVlZGluZyB0byBpbnRlcmFjdCBvciB0aGUgdHJ1c3Qgbm90IGJlaW5n IGhpZ2ggZW5vdWdoIGZvciB0aGUNCiByZXF1ZXN0KSwgdGhlbiB5b3UgYmFpbCBvdXQgb2YgdGhl IGV4Y2hhbmdlIGdyYW50IGFuZCBpbnRvIG9uZSBvZiB0aGUgaW50ZXJhY3RpdmUgZ3JhbnRzIGlu c3RlYWQgdG8gZ2V0IHRoZSB1c2VyIHRvIHRoZSBmcm9udCBjaGFubmVsLiBTaW5jZSB5b3Ugc3Rh cnQgaW4gdGhlIGJhY2sgY2hhbm5lbCBpbiBYWVosIHRoZSBjbGllbnQgY2FuIHNlbmQgYWxvbmcg YW55IGluZm9ybWF0aW9uIHRoYXQgaXQgaGFzIGFib3V0IHRoZSB1c2VyIHJpZ2h0IGZyb20NCiB0 aGUgc3RhcnQsIGFuZCB0aGUgQVMgY2FuIGRldGVybWluZSB3aGF0IGVsc2UgaXQgbmVlZHMgdG8g ZG8uIFRoaXMgY291bGQgaW5jbHVkZSBpbnRlcmFjdGluZyB3aXRoIHRoZSB1c2VyIGRpcmVjdGx5 LCBvciBldmVuIGJ1aWxkaW5nIHVwIGEgY2hhbGxlbmdlLXJlc3BvbnNlIGZvciBhIHVzZXLigJlz IGNyZWRlbnRpYWwgdG8gYmUgcHJlc2VudGVkIHZpYSB0aGUgY2xpZW50IGFuZCByZXR1cm5lZCB0 aHJvdWdoIGEgdHJhbnNhY3Rpb24gY29udGludWUNCiBtZXNzYWdlLiBPbiB0b3Agb2YgdGhpcywg c2luY2Ugd2XigJlyZSBkb2luZyBKU09OIGluIHRoZSBiYWNrIGNoYW5uZWwsIHdl4oCZdmUgZ290 IGEgbG90IG1vcmUgZXhwcmVzc2l2ZW5lc3MgZm9yIHRoZSBkYXRhIHdl4oCZcmUgc2VuZGluZyBi YWNrIGFuZCBmb3J0aCBiZXlvbmQgZm9ybS1lbmNvZGVkIHN0cmluZ3MuJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFz cz0iIj5Ob24tYXV0aG9yaXphdGlvbiBJbnRlcmFjdGlvbi48L2I+Jm5ic3A7VGhpcyBpcyBvbmUg dGhhdCBBbm5hYmVsbGUgYnJvdWdodCB1cCBpbiBNb250cmVhbCwgYW5kIEnigJlsbCBhZG1pdCB0 aGF0IGl04oCZcyBhIGJpdCBmdXJ0aGVyIG91dCB0aGFuIHRoZSBvdGhlcnMgYmVjYXVzZSBpdOKA mXMgbm90IGV2ZW4gYW4gYXV0aG9yaXphdGlvbiBjYXNlLiBJbiB0aGlzLCBhbiBhcHBsaWNhdGlv biB0cmllcyB0byBkbyBzb21ldGhpbmcNCiBhdCBhbiBBUEkgYnV0IGZpbmRzIG91dCB0aGF0IHRo ZSB1c2VyIG5lZWRzIHRvIGludGVyYWN0IHdpdGggdGhlIHNlcnZpY2UuIFRoaXMgbWlnaHQgYmUg dG8gY29uc2VudCwgbGlrZSBpbiBPQXV0aCwgYnV0IGl0IGFsc28gbWlnaHQgYmUgdG8gZW50ZXIg YW4gdXBkYXRlZCBjcmVkaXQgY2FyZC4gQmFzaWNhbGx5LCBhIGJhY2tlbmQgc3lzdGVtIG5lZWRz IHRvIHNheSDigJxPaCBJIHRob3VnaHQgdGhpbmdzIHdlcmUgZmluZSBidXQgSSBuZWVkIHRvIHRh bGsNCiB0byBzb21lb25lIHdpdGggYSB3ZWJwYWdlIHJpZ2h0IG5vd+KAnSwgbXVjaCBsaWtlIHRo ZSB0b2tlbi1leGNoYW5nZS1mYWlsdXJlIG1vZGVsIGluIHRoZSBsYXN0IHBhcmFncmFwaC4gVGhp cyBmaXRzIFhZWuKAmXMgbW9kZWwgb2YgcGluZ2luZyB0aGUgQVMgdG8gdHJ5IGFuZCBkbyBzb21l dGhpbmcsIGJ1dCBoYXZpbmcgdGhlIEFTIG9wdGlvbmFsbHkgY29tZSBiYWNrIGFuZCBzYXkg4oCc aGV5IGdldCB0aGUgdXNlciB0byB0aGlzIHdlYnBhZ2UsIEkgbmVlZA0KIHRvIHRhbGsgdG8gdGhl beKAnSwgd2l0aCB0aGUgbWFpbiBkaWZmZXJlbmNlIHRoYXQgaXTigJlzIG5vdCBpbnNpZGUgYSB0 cmFuc2FjdGlvbiByZXF1ZXN0LCBwZXIgc2UuIEkgdGhpbmsgdGhlcmXigJlzIHNvbWV0aGluZyBp bnRlcmVzdGluZyBoYXBwZW5pbmcgaGVyZSB0aG91Z2ggdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YiBjbGFzcz0iIj5LZXkgRGlzdHJpYnV0aW9uLjwvYj4mbmJzcDtUaGlzIGlzIGFub3RoZXIg b25lIHRoYXQgbGFuZHMgdXMgb3V0c2lkZSBvZiB3aGF0IE9BdXRoIGlzIHVzZWQgZm9yLCBidXQg bm90IHRoYXQgZmFyIGZyb20gaXRzIGludGVudC4gSWYgd2UgaGF2ZSBib3VuZCBhY2Nlc3MgdG9r ZW5zLCB0aGF0IG1lYW5zIHRoZSB0b2tlbnMgdGhlbXNlbHZlcyBhcmUgYm91bmQgdG8ga2V5cy4g V2VsbCwgdGhvc2Uga2V5cyBjb3VsZA0KIGFsc28gYmUgdXNlZCBpbiBvdGhlciBub24tYWNjZXNz LXRva2VuLWJhc2VkIHByZXNlbnRhdGlvbiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMuIE1heWJl IHRoZSBjbGllbnQgbmVlZHMgdG8gc2lnbiBhbiBhc3NlcnRpb24gYWJvdXQgaXRzZWxmLCBvciBh IGRvY3VtZW50LCBvciBhIFNFVCBmb3IgYXVkaXQgcHVycG9zZXMuIEluIGFsbCBvZiB0aGVzZSBj YXNlcywgSSB0aGluayBpdCBjYW4gYmUgYXJndWVkIHRoYXQgdGhlIGFjY2VzcyB0b2tlbg0KIHJl cHJlc2VudHMgaGVyZSB3aGF0IHRoZSBrZXkgY2FuIGJlIHVzZWQgZm9yLCB3aGljaCBtaWdodCBi ZSBpbiBhZGRpdGlvbiB0byBpdHMgcHJlc2VudGF0aW9uIGF0IGFuIEFQSSBpdHNlbGYuIEnigJl2 ZSBiZWVuIGludm9sdmVkIHdpdGggcGxlbnR5IG9mIHN5c3RlbXMgdGhhdCBib2lsIGRvd24gdG8g YSBrZXkgZXhjaGFuZ2Ugb3IgZGlzdHJpYnV0aW9uIHByb2JsZW0sIGFuZCB3aGVuIHRoZSB0cnVz dCBpcyB1c2VyLWRyaXZlbiwgaXTigJlzIG5vdCB0aGF0DQogZGlmZmVyZW50IGZyb20gd2hhdCB3 ZeKAmXJlIGRvaW5nIHdpdGggdG9rZW5zIGluIFhZWi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN0cnVjdHVyZWQg UmVzb3VyY2VzLjwvYj4mbmJzcDtPciBpbiBvdGhlciB3b3Jkcywg4oCcc3RydWN0dXJlZCBzY29w ZXPigJ0gbGlrZSBUb3JzdGVuIGlzIHByb3Bvc2luZy4gQWdhaW4sIEkgc3VwcG9ydCB0aGlzIHdv cmsgZm9yIGV4dGVuZGluZyBPQXV0aCwgYnV0IGl04oCZcyBnb3QgYSBsb3Qgb2YgaHVyZGxlcyB0 byBvdmVyY29tZS4gRm9yIG9uZSwgZW5jb2RpbmcgdGhlIHN0cnVjdHVyZXMgYXMgZm9ybSBwYXJh bWV0ZXJzDQogaXMgYXdrd2FyZCwgYXQgYmVzdC4gU2Vjb25kLCB0aGUgY29tYmluYXRpb24gb2Yg 4oCccGxhaW7igJ0gc2NvcGVzIHdpdGggc3RydWN0dXJlZCBzY29wZXMgd291bGQgbmVlZCB0byBi ZSBjYXJlZnVsbHkgZGVmaW5lZCwgc2luY2UgYSDigJxwbGFpbuKAnSBzY29wZSBjYW4gcmVwcmVz ZW50IHNvIG1hbnkgZGlmZmVyZW50IGFzcGVjdHMgb2YgdGhlIHJlcXVlc3QuIEFuZCBmaW5hbGx5 LCB3aGF0IGdvZXMgaW50byB0aGUgc3RydWN0dXJlIGlzIGdvaW5nIHRvIGJlDQogYSBiaWcgaXNz dWUgb2YgcG9zc2libGUgY29udGVudGlvbiBzaW5jZSBub3Qgb25seSBhcmUgYWxsIEFQSXMgdmVy eSBkaWZmZXJlbnQsIHNvIGZhciBBUElzIGhhdmUgdXNlZCDigJxzY29wZeKAnSBpbiB2ZXJ5IGRp ZmZlcmVudCB3YXlzLiBXaXRoIFhZWiwgcmVzb3VyY2UgcmVxdWVzdHMgaGF2ZSBhIG11Y2ggbW9y ZSB3ZWxsLWRlZmluZWQgc2V0dXA6IHRoZXkgZXhpc3QgYXMgb2JqZWN0cyBkZXNjcmliaW5nIHRo ZSByZXF1ZXN0LCB0aGV54oCZcmUgY29tYmluZWQNCiB3aXRoIOKAnEFOROKAnSBzZW1hbnRpY3Ms IGFuZCB0aGV5IGNhbiBiZSByZXByZXNlbnRlZCBieSBzdHJpbmdzIHRoYXQgZGVjb2RlIGV4cGxp Y2l0bHkgdG8gdGhlIHJlcHJlc2VudGF0aW9uYWwgb2JqZWN0cy4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SeKAmWQgbGlrZSB0byBoZWFyIGZyb20gb3RoZXJzIGFib3V0IHdoYXQgb3RoZXIgdXNl IGNhc2VzIHlvdeKAmXZlIHJ1biBpbnRvIGF0IHRoZSBlZGdlcyBvZiBPQXV0aCAob3IgcmVsYXRl ZCBzcGFjZSkgdGhhdCBkb27igJl0IHF1aXRlIGZpdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgaGF2ZSByZWFjaGVkIG91dCB0byB0 aGUgY2hhaXJzIGFuZCB0aGUgQUQgdG8gaGVscCBkZXRlcm1pbmUgbmV4dCBzdGVwcyBmb3IgWFla IHdpdGhpbiB0aGUgSUVURi4gSSBob3BlIHRvIGJlIGFibGUgdG8gYXR0ZW5kIHRoZSBTaW5nYXBv cmUgbWVldGluZyBhbmQgY29udGludWUgdGhlIGNvbnZlcnNhdGlvbiBpbiBwZXJzb24gdGhlcmUg YXMgd2VsbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2E8DAF9028344B08AF1C2A9928BB6869mitedu_-- From nobody Mon Aug 19 15:15:27 2019 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 5162012008C; Mon, 19 Aug 2019 15:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 15:15:19 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 22:15:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-mtls-16: 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-mtls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I think that we need some text that covers how the resource server will know to use mtls (and thus, to send a CertificateRequest to the client during the TLS handshake). The authorization server and client can indicate their capabilities/preference via the RFC 8414 and RFC 7591 discovery and registration procedures, but I didn't see any discussion of how an AS might know a RS's capabilities, or how an RS might develop expectations of the capabilities of the clients accessing it. A naive conclusion might be that any given RS (hostname+port) would have to either always or never use mtls, given the misordering between TLS handshake completion and delivery of TLS application data (i.e., including the oauth token), though there may be refinements available in the form of the unpopular TLS 1.2 renegotiation or TLS 1.3 post-handshake authentication (or exported authenticators). Doing either of those in an environment with TLS Termination per Section 6.5 may entail additional complications. (We may also want some additional text discussing error handling for the client/AS interaction, e.g., if a request shows up from a client-id that should be using mtls but did not provide a certificate in the TLS handshake, but that is only debatably something that rises to Discuss-level; or if a client that advertised an intent to use MTLS used the regular token endpoint and not the mtls endpoint alias (if they differ).) (2) I can't validate the examples in Appendix A. Specifically, my reading of the text would put the "x5t#S256" value as needing 86 characters, but only 43 are provided. The ones there also do not seem to be a prefix of the result that I get from taking the PEM certificate contents and running them through the pipeline: base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64 (Noting, of course, that 'base64' will be producing the non-URL-safe variant, but expecting it to remain "pretty close".) I also had some trouble comparing the "y" coordinate from the JWK to the certificate contents, but that may just be user error. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 nit: in Figure 1, the (C) label is applied to both an arrow and a box (the other two boxes are not labelled). (C) The protected resource validates the access token in order to authorize the request. In some cases, such as when the token is self-contained and cryptographically secured, the validation can be done locally by the protected resource. While other cases require that the protected resource call out to the authorization server to determine the state of the token and obtain meta-information about it. nit: "While" is a conjunction but this last sentence only has one clause. Layering on the abstract flow above, this document standardizes enhanced security options for OAuth 2.0 utilizing client certificate based mutual TLS. Section 2 provides options for authenticating the nit: "client-certificate-based" is hyphenated. request in step (A). While step (C) is supported with semantics to express the binding of the token to the client certificate for both local and remote processing in Section 3.1 and Section 3.2 respectively. This ensures that, as described in Section 3, nit: same thing about "while". protected resource access in step (B) is only possible by the legitimate client bearing the access token and holding the private key corresponding to the certificate. nit: I guess it is only protected resource access "using this tokwn" that is only possible as specified. Section 1.2 We probably want to say something like "in addition to the normal TLS server authentication with a certificate" -- we need both for it to properly be "mutual" :) Section 2.1 The PKI (public key infrastructure) method of mutual TLS OAuth client authentication adheres to the way in which X.509 certificates are traditionally used for authentication. It relies on a validated certificate chain [RFC5280] and a single subject distinguished name (DN) or a single subject alternative name (SAN) to authenticate the client. Only one subject name value of any type is used for each I think we might be able to refer to RFC 6125 and call these the "CN-ID" and "DNS-ID". That might also let us get out of doing quite as much referencing to RFC 4514 and specifying string representations "by hand"... I'm surprised to not see any discussion of trust anchor management or how to indicate (or decide) which CAs are to be trusted for this purpose, even if that's just to acknowledge that it must be done but leave it up to deployments. Section 2.1.2 Similarly the tls_client_auth_san_uri could be a URI-ID. tls_client_auth_san_ip A string representation of an IP address in either dotted decimal notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in [RFC4291] section 2.2) that is expected to be present as an iPAddress SAN entry in the certificate, which the OAuth client will use in mutual TLS authentication. Do we want to note that this string representation differs from the actual iPAddress encoding? I guess by the time you go to actually implement it, it's probably pretty obvious, though... Section 2.2.2 For the Self-Signed Certificate method of binding a certificate with a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to convey the client's certificates via JSON Web Key (JWK) in a JWK Set (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set containing the client's public keys as an array of JWKs while the "jwks_uri" parameter is a URL that references a client's JWK Set. A certificate is represented with the "x5c" parameter of an individual JWK within the set. Note that the members of the JWK representing nit: "containing the client's public keys" is a bit of a juxtaposition with "represented with the "x5c" parameter" (which is certificates). True, the certificate does contain the public key, so it's not exactly wrong, but since we focus elsewhere on the certificate, it may not make sense to focus on the public key here. Section 3 Binding the access token to the client certificate in that fashion has the benefit of decoupling that binding from the client's authentication with the authorization server, which enables mutual TLS during protected resource access to serve purely as a proof-of-possession mechanism. Other methods of associating a I don't think I understand what's meant about "decoupling that binding from the client's authentication with the authorization server" -- it seems like the authorization server shouldn't issue a bound token without some proof of possession, which the client's authentication thereto performs. The protected resource MUST obtain, from its TLS implementation layer, the client certificate used for mutual TLS and MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST How does the resource server know it needs to do this? Is this just configured as part of the ability to do mutual TLS, or indiated by a token type, or something else? Section 3.1 Per BCP 201, we may want to say something about this recommendation changing over time as cryptographic algorithm preferences change. RFC 7525 has a decent note to this effect: Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document. (obviously the "BCP" part doesn't apply to this document, but most of the rest should.) This could of course be coordinated between here and Section 7.2. There's only 43 characters of base64 in the "x5t#S256" example; for SHA-256 output shouldn't there be 86? Section 3.2 (Same comment about the length of base64 in the example, in Figure 3.) Section 3.3 We should probably reference RFC 8414 (at least) the first time we talk about authorizaiton server metadata parameters. Section 3.4 Similarly, we could reference RFC 7591 here. Section 5 Note that the endpoints in "mtls_endpoint_aliases" use a different host than their conventional counterparts, which allows the authorization server (via SNI or actual distinct hosts) to differentiate its TLS behavior as appropriate. nit: Sadly, "SNI" does not appear in https://www.rfc-editor.org/materials/abbrev.expansion.txt as a "well-known" abbreviation, so we probably have to say 'TLS "server_name" extension [RFC 6066]' or similar. Section 6.1 In order to support the Self-Signed Certificate method, the authorization server would configure the TLS stack in such a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate. This statement doesn't quite follow -- *support*ing self-signed certificates only requires that you configure TLS to not require a valid client cert+chain for the handshake to succeed, but it can still try to validate such a chain. This would be useful if, for example, you intended to support both self-signed and CA-signed certificates. We may also want a specific note to implementors to check validation results for certificates intended to be CA-signed, if we're going to include a note about disabling validation for self-signed cert usage. Section 6.2 Would there be any scenario in which "additional security" might be gained from having the RS check that the client-presented cert does chain to a trusted CA? Section 6.3 Isn't this ignoring the elephant in the room about what to do when the refresh token is also bound to the (expiring) client certificate? Section 6.5 There are a couple of active proposals for new, secure, protocols from load balancer to backend server, but probably not anything quite mature enough to be worth referencing from here. (e.g., draft-schwartz-tls-lb and another one that I think was presented in QUIC but I can't find right now) Section 7 We could potentially also talk about how the use of jwks_uri requires a fairly strong level of trust in the service at the target of the URI: the client has to trust it to faithfully provide the certification information, and the RS has to trust it to provide valid data for the client in question, as well as the usual trust in the TLS connection that identifies it, etc. Section 7.1 The OAuth 2.0 Authorization Framework [RFC6749] requires that an authorization server bind refresh tokens to the client to which they were issued and that confidential clients (those having established authentication credentials with the authorization server) authenticate to the AS when presenting a refresh token. As a result, refresh tokens are indirectly certificate-bound when issued to clients utilizing the "tls_client_auth" or "self_signed_tls_client_auth" methods of client authentication. nit(?): is this "indirectly" or "implicitly" bound? Section 7.2 I'm not sure why we mention both (first) preimage and second-preimage resistance, as they're pretty different properties. I suppose there could be some registration scenarios where only the thumbprint is provided and thus an attacker with a DB dump would not have the first preimage in the form of the actual intended certificate, but even if they could reconstruct that "real" preimage from the thumbprint they wouldn't have the corresponding private key. So second-preimage probably covers what we need, and we can assume that the "first" preimage (certificate) is always available to the attacker. Section 7.4 Maybe we should say "agree out of band" on the set of trust anchors. Section 7.5 o handling of null-terminator bytes and non-canonical string representations in subject names; ASN.1 encodings are going to be using counted strings, so any NUL terminators will be in implementation languages. I think we might want to reword this to indicate that ASN.1 strings cannot be directly interpreted as native language strings in languages that use NUL terminators. o handling of wildcard patterns in subject names; Interestingly, RFC 5280 punts on the semantics of wildcard characters in SANs, though I think many applications will insist on only a single wildcard and the leftmost label being just the single wildcard character. Section 8 There's perhaps some additional considerations if a client uses the same certificate across multiple RSes, in that the client certificate provides an additional mechanism for collaborating RSes to correlate a single client, in ways that just the access token would not. This is not a terribly common threat model in a highly centralized deployment where all RSes are fairly well trusted, of course, but there can be some environments where it is relevant, so it probably merits discussion. Section 9.2 This specification requests registration of the following value in nit: "values" plural Section 10.2 I think that RFC 7517 needs to be normative, since we use the jwks containers for conveying certificate information. It also seems like RFCs 7591 and 8414 should probably be normative. Traditionally we keep RFC 8174 as normative, as part of BCP 14 along with RFC 2119. From nobody Mon Aug 19 19:02:40 2019 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 8CC2D120024; Mon, 19 Aug 2019 19:02:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 19:02:39 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 02:02:40 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-mtls-16: 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-mtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that everyone did on this document. I have one suggestion for clarification, followed by a handful of editorial nits. --------------------------------------------------------------------------- §2.1.2: > tls_client_auth_san_ip > A string representation of an IP address in either dotted decimal > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as > defined in [RFC4291] section 2.2) that is expected to be present > as an iPAddress SAN entry in the certificate, which the OAuth > client will use in mutual TLS authentication. This probably needs some text that clarifies expectations around comparison and/or normalization. For example, if the iPAddress value in the cert is "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's), one should presume that this would match both tls_client_auth_san_ip values "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, then this document needs to talk about normalization of address representation. --------------------------------------------------------------------------- §1: > Layering on the abstract flow above, this document standardizes > enhanced security options for OAuth 2.0 utilizing client certificate > based mutual TLS. Nit: "client-certificate-based" > OAuth 2.0 defines a shared secret method of client authentication but Nit: "shared-secret" --------------------------------------------------------------------------- §1: > This document describes an additional > mechanism of client authentication utilizing mutual TLS certificate- > based authentication Nit: "mutual-TLS" > Mutual TLS certificate-bound access tokens ensure that only the party Nit: "Mutual-TLS" > Mutual TLS certificate-bound access tokens and mutual TLS client Nit: "Mutual-TLS... mutual-TLS" > Additional client metadata parameters are introduced by this document > in support of certificate-bound access tokens and mutual TLS client > authentication. Nit: "mutual-TLS" The remainder of the document has several other uses of the phrase "mutual TLS" as an adjective; they should be similarly hyphenated. I will not call them out individually. (Non-adjectival uses should not contain hyphens, so this isn't a simple find-and-replace operation.) --------------------------------------------------------------------------- §5: > Authorization servers supporting both clients using mutual TLS and > conventional clients MAY chose to isolate the server side mutual TLS > behaviour to only clients intending to do mutual TLS, thus avoiding Nit: "behavior" (or adjust other spellings in the document to be consistently British). From nobody Tue Aug 20 12:16:42 2019 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 A23401209EA; Tue, 20 Aug 2019 12:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156632859162.350.2919813913771406915.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 12:16:31 -0700 Archived-At: Subject: [OAUTH-WG] Suresh Krishnan's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:16:32 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-oauth-mtls-16: 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-mtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.1.2. Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in RFC4291 section 2.2. The canonical representation described in RFC5952 makes it easier to compare two IPv6 address strings which is probably something you want to do while doing mutual authentication. From nobody Wed Aug 21 14:21:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63712007C for ; Wed, 21 Aug 2019 14:21:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 om5T6AmQI0ax for ; Wed, 21 Aug 2019 14:21:51 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 C038412001E for ; Wed, 21 Aug 2019 14:21:50 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id p12so7626694iog.5 for ; Wed, 21 Aug 2019 14:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sigWnhqOA/CMDsPHbAZYxxudT6ZkHfS63lJbXzAPBJ0=; b=VgYAKVJBZrer/2cTPANPlMBZWnYm54ilwHcB22uZel/OweJazAh9JUbOyBOApbWl/f Ovuvq/OqKUrTiCbbbLxG3BmRnvMWGS7LtAWz7iVZFiB89EA4346a9vjFftOUpeHsuwkE HyBzgv6gsyQ4A+vpysCDBsJyKkhDGdH5mucxc= 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=sigWnhqOA/CMDsPHbAZYxxudT6ZkHfS63lJbXzAPBJ0=; b=hqSA3dF5Wx2bt+UwTD4NL2hHYPT4T8FLWCQfb8J267hDGhBQ/B6DzZeSp4zBqCDN9R dSd207i1Uoemt655vlWAwt883igGjYsoLh6mfNaSaK5+OU2XhuTquOID5I7Zc2PoQiuV rxAWzHm5Dw66PPPEeSM2UJM+Cn3E67HbjebbCzlpNO/sYhKfx0TbdHXaczhgJKdLfHEI nVE1j50M9tfNyFUgagm0eY01BnRihYmZ6ichUXcYGrieWNP8i4WHKtOEzZGpu2fKi5jY b/E68//VqFV8JDyz7Qe93Me4J224LXgXQl/12TVfO9ru3yoG5k0rjyOO29RgZxMfJpEa tH1A== X-Gm-Message-State: APjAAAWyG7qvCVt9QNMn6a1rjLyAJQuwqqFJFsmqRakBU7AEYHl7BgGs w8/xTSnss3iq/e0GswCHfvHopCm5Dm2U1taZubW4yRWjVS0gLALvCBOVaiOyBkXVgPzw5P3dPCY zUBU5UsCPjw86Ww== X-Google-Smtp-Source: APXvYqzawSTX+KOOnSBiHPANIJOqzGoK9JaTCBTsjZpYxmHmNNDxQz3WOHdHve2MCR9fxnJ3Tv8AEkXxLuJhUcKnnFE= X-Received: by 2002:a02:c00c:: with SMTP id y12mr12396259jai.65.1566422509615; Wed, 21 Aug 2019 14:21:49 -0700 (PDT) MIME-Version: 1.0 References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> In-Reply-To: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 21 Aug 2019 15:21:23 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000041106b0590a72931" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:21:55 -0000 --00000000000041106b0590a72931 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben, I attempt (over the course of many hours) to respond to your comments and discuss your discuss inline below. On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-mtls-16: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) I think that we need some text that covers how the resource server > will know to use mtls (and thus, to send a CertificateRequest to the > client during the TLS handshake). The authorization server and client > can indicate their capabilities/preference via the RFC 8414 and RFC 7591 > discovery and registration procedures, but I didn't see any discussion > of how an AS might know a RS's capabilities, or how an RS might develop > expectations of the capabilities of the clients accessing it. A naive > conclusion might be that any given RS (hostname+port) would have to > either always or never use mtls, given the misordering between TLS > handshake completion and delivery of TLS application data (i.e., > including the oauth token), though there may be refinements available in > the form of the unpopular TLS 1.2 renegotiation or TLS 1.3 > post-handshake authentication (or exported authenticators). Doing > either of those in an environment with TLS Termination per Section 6.5 > may entail additional complications. > Is there some text that you can propose? Whether or not to ask for or require MTLS and how to determine when is going to be a deployment decision of the RS. I don't think what you describe as the naive conclusion is all that naive at all. But maybe that just makes me naive:) In implementations/deployments that I've seen thus far, a particular RS decides (or is dictated by some policy) that its stuff is high value enough that it needs cert-bound access tokens so it always sends a CertificateRequest to the client during the TLS handshake. Such an RS that also wants to allow access via non cert-bound access tokens might just let the TLS connection proceed even if the client doesn't offer a certificate or it might offer its stuff on a different host and/or port that is just regular TLS. I don't want to preclude the use of renegotiation or post-handshake authentication but (other than some past pain with renegotiation) I'm not really qualified to discuss or make recommendations about using them. Note also there is not something like RFC 8414 and RFC 7591 for RSs and (for good reasons I think) the WG has balked at working on something like that. So the requirements/capabilities/preferences of an RS will need to be communicated or configured out-of-band. And that's the case in general for RSs independent of this document. (We may also want some additional text discussing error handling for the > client/AS interaction, e.g., if a request shows up from a client-id that > should be using mtls but did not provide a certificate in the TLS > handshake, but that is only debatably something that rises to > Discuss-level; or if a client that advertised an intent to use MTLS used > the regular token endpoint and not the mtls endpoint alias (if they > differ).) > The end of sec 2 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2 says what to do in the case of a certificate mismatch in client auth: "If the presented certificate doesn't match that which is expected for the given "client_id", the authorization server returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749 [RFC6749] with the "invalid_client" error code to indicate failed client authentication." And my intent and assumption was that a mismatch covered the case where no certificate was presented (i.e. null cert doesn't match expected cert just as different cert doesn't match). But perhaps that particular case should be made more explicit? The second to last paragraph of sec 3 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar guidance for error handing in the case of mismatch during resource access. The case of a so called public client that has tls_client_certificate_bound_access_tokens metadata of true that shows up at the token endpoint without having done MTLS is a bit more nuanced and I think it's untimely a policy decision for the AS at that point as to whether to error or issue an unbound token. > > (2) I can't validate the examples in Appendix A. > > Specifically, my reading of the text would put the "x5t#S256" value as > needing 86 characters, but only 43 are provided. The ones there also do > not seem to be a prefix of the result that I get from taking the PEM > certificate contents and running them through the pipeline: > > base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64 > > (Noting, of course, that 'base64' will be producing the non-URL-safe > variant, but expecting it to remain "pretty close".) > Here's a quick back of the napkin calculation that gives 43 characters: SHA 256 produces a 256 bit output, which is 32 bytes. Base64url encoding 32 bytes gives 43 bytes/characters of output (the ratio of output bytes to input bytes is 4:3 with base64 encoding). I am not *nix skilled enough to troubleshoot that command pipeline but I suspect that the sha256sum output is in hex which represents each byte of the hash output with two charterers and thus double the resultant size. I don't believe this particular example has been validated by other folks but it was produced using code that has produced consistent results with other implementers. Also it's code from an existing JOSE/JWT library ( https://bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing support for the x5t / x5t#S256 parameters in JWS and JWK. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > nit: in Figure 1, the (C) label is applied to both an arrow and a box > (the other two boxes are not labelled). > That was intentional and meant to show that access token validation can happen locally (in the box) or by introspection call-out to the AS (the arrow). Maybe this could be done a bit differently, with I dunno sub items of C1 and C2 or something, that would be more clear? > > (C) The protected resource validates the access token in order to > authorize the request. In some cases, such as when the token is > self-contained and cryptographically secured, the validation can > be done locally by the protected resource. While other cases > require that the protected resource call out to the > authorization server to determine the state of the token and > obtain meta-information about it. > > nit: "While" is a conjunction but this last sentence only has one > clause. > Will remove. > > Layering on the abstract flow above, this document standardizes > enhanced security options for OAuth 2.0 utilizing client certificate > based mutual TLS. Section 2 provides options for authenticating the > > nit: "client-certificate-based" is hyphenated. > ok > > request in step (A). While step (C) is supported with semantics to > express the binding of the token to the client certificate for both > local and remote processing in Section 3.1 and Section 3.2 > respectively. This ensures that, as described in Section 3, > > nit: same thing about "while". > ok > > protected resource access in step (B) is only possible by the > legitimate client bearing the access token and holding the private > key corresponding to the certificate. > > nit: I guess it is only protected resource access "using this tokwn" > that is only possible as specified. > I kinda felt like that was implied at this point. But I can add "using this token" there, if you think it's needed or helpful? > > Section 1.2 > > We probably want to say something like "in addition to the normal TLS > server authentication with a certificate" -- we need both for it to > properly be "mutual" :) > ok > > Section 2.1 > > The PKI (public key infrastructure) method of mutual TLS OAuth client > authentication adheres to the way in which X.509 certificates are > traditionally used for authentication. It relies on a validated > certificate chain [RFC5280] and a single subject distinguished name > (DN) or a single subject alternative name (SAN) to authenticate the > client. Only one subject name value of any type is used for each > > I think we might be able to refer to RFC 6125 and call these the "CN-ID" > and "DNS-ID". That might also let us get out of doing quite as much > referencing to RFC 4514 and specifying string representations "by hand"..= . > RFC 6125 "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)" came up at one point but given that certificate usage in this draft aren't about Domain-Based Application Services I was unable to see the applicable or how using it might help. > > I'm surprised to not see any discussion of trust anchor management or > how to indicate (or decide) which CAs are to be trusted for this > purpose, even if that's just to acknowledge that it must be done but > leave it up to deployments. > It's gotta be done (unless using the self-singed method) and it is definitely up to deployments as I wouldn't even pretend to know where to begin on providing general guidance nor would I think it appropriate. I felt like this was pretty well implied and touched on in security considerations too. But please suggest some specific text, if you think it's needed or would be useful. > Section 2.1.2 > > Similarly the tls_client_auth_san_uri could be a URI-ID. > Similar to the above I'm really not seeing how or why this would be done or useful. > > tls_client_auth_san_ip > A string representation of an IP address in either dotted decimal > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as > defined in [RFC4291] section 2.2) that is expected to be present > as an iPAddress SAN entry in the certificate, which the OAuth > client will use in mutual TLS authentication. > > Do we want to note that this string representation differs from the > actual iPAddress encoding? I guess by the time you go to actually > implement it, it's probably pretty obvious, though... > I don't know, to be honest. The text in question came as a suggestion from someone on the WG list and it seemed good enough to me. I sort of thought it would probably be pretty obvious too. However the other IESG ballot positions have also had similar(ish) comments (see https://mailarchive.ietf.org/arch/msg/oauth/PbpygP8an-e80dDolo97Q5cBdd4 and https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so it seems something more or different is needed with respect to this tls_client_auth_san_ip thing. The suggestion from Suresh around RFC 5952 seems promising but I need to look further into it than just reading the title. Which I'll do. But also trying to be somewhat timely in responding to these reviews. I've also never been able to think of a case where tls_client_auth_san_ip is actually needed so maybe removing it all together is an option as well. > > Section 2.2.2 > > For the Self-Signed Certificate method of binding a certificate with > a client using mutual TLS client authentication, the existing > "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to > convey the client's certificates via JSON Web Key (JWK) in a JWK Set > (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set > containing the client's public keys as an array of JWKs while the > "jwks_uri" parameter is a URL that references a client's JWK Set. A > certificate is represented with the "x5c" parameter of an individual > JWK within the set. Note that the members of the JWK representing > > nit: "containing the client's public keys" is a bit of a juxtaposition > with "represented with the "x5c" parameter" (which is certificates). > True, the certificate does contain the public key, so it's not exactly > wrong, but since we focus elsewhere on the certificate, it may not make > sense to focus on the public key here. > That juxtaposition arises out of the way JWK is primarily about bare public keys and certificates are an optional additional JSON member. > > Section 3 > > Binding the access token to the client certificate in > that fashion has the benefit of decoupling that binding from the > client's authentication with the authorization server, which enables > mutual TLS during protected resource access to serve purely as a > proof-of-possession mechanism. Other methods of associating a > > I don't think I understand what's meant about "decoupling that binding > from the client's authentication with the authorization server" -- it > seems like the authorization server shouldn't issue a bound token > without some proof of possession, which the client's authentication > thereto performs. > What it is trying to say is that the AS does what the AS does in terms of client auth including dealing with trust anchors and what type of subject name or allowing for self singed auth matching against explicitly configured certs. But, because the token is bound to the hash of the cert, the RS need not concern itself with any of that and can treat the client TLS certificate as only a proof-of-possession mechanism for using the access token. Does that help your understanding or just confuse things further? > > The protected resource MUST obtain, from its TLS implementation > layer, the client certificate used for mutual TLS and MUST verify > that the certificate matches the certificate associated with the > access token. If they do not match, the resource access attempt MUST > > How does the resource server know it needs to do this? Is this just > configured as part of the ability to do mutual TLS, or indiated by a > token type, or something else? > Configured and/or based on the presence of the cnf claim with x5t#S256 method in the access token. > > Section 3.1 > > Per BCP 201, we may want to say something about this recommendation > changing over time as cryptographic algorithm preferences change. RFC > 7525 has a decent note to this effect: > > Community knowledge about the strength of various algorithms and > feasible attacks can change quickly, and experience shows that a Best > Current Practice (BCP) document about security is a point-in-time > statement. Readers are advised to seek out any errata or updates > that apply to this document. > > (obviously the "BCP" part doesn't apply to this document, but most of > the rest should.) This could of course be coordinated between here and > Section 7.2. > Makes sense. I'll incorporate some text borrowed from 7525 in 3.1 and/or 7.2. > > There's only 43 characters of base64 in the "x5t#S256" example; for > SHA-256 output shouldn't there be 86? > see previous explanation of why 43 seems right based on my math and code > > Section 3.2 > > (Same comment about the length of base64 in the example, in Figure 3.) > same same > > Section 3.3 > > We should probably reference RFC 8414 (at least) the first time we talk > about authorizaiton server metadata parameters. > Yeah, that's an oversight on my part. Will fix. > > Section 3.4 > > Similarly, we could reference RFC 7591 here. > RFC 7591 has been referenced several times already at this point. > > Section 5 > > Note > that the endpoints in "mtls_endpoint_aliases" use a different host > than their conventional counterparts, which allows the authorization > server (via SNI or actual distinct hosts) to differentiate its TLS > behavior as appropriate. > > nit: Sadly, "SNI" does not appear in > https://www.rfc-editor.org/materials/abbrev.expansion.txt as a > "well-known" abbreviation, so we probably have to say 'TLS "server_name" > extension [RFC 6066]' or similar. > Shoot, okay. Will do. > > Section 6.1 > > In order to support the Self-Signed Certificate method, the > authorization server would configure the TLS stack in such a way that > it does not verify whether the certificate presented by the client > during the handshake is signed by a trusted CA certificate. > > This statement doesn't quite follow -- *support*ing self-signed > certificates only requires that you configure TLS to not require a valid > client cert+chain for the handshake to succeed, but it can still try to > validate such a chain. This would be useful if, for example, you > intended to support both self-signed and CA-signed certificates. > We may also want a specific note to implementors to check validation > results for certificates intended to be CA-signed, if we're going to > include a note about disabling validation for self-signed cert usage. > I take your point but the text (which I did not write FWIW) was meant to be practical guidance based on an understanding of how the most common web servers work (problem in chain validation terminates the handshake) and the options they provide (can turn off cert chain validating) and what they surface about the handshake results (AFAIK not the kind of info that would allow the distinction you mention so the whole process of chain validation would maybe have to be deferred to the application layer). I can try and add or amend some text along the lines of your comment. But I worry I'd do more harm than good in doing so. > Section 6.2 > > Would there be any scenario in which "additional security" might be > gained from having the RS check that the client-presented cert does > chain to a trusted CA? > I'm sure there is some such scenario out there. But this is meant as implementation considerations or guidance for the general or common cases. > > Section 6.3 > > Isn't this ignoring the elephant in the room about what to do when the > refresh token is also bound to the (expiring) client certificate? > The only time a refresh token is bound directly to the client certificate is for public clients ( https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-4 and https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-7.1) and public clients can only use self signed certificates for which the expiration isn't all that meaningful and can be made to be far enough in the future. > > Section 6.5 > > There are a couple of active proposals for new, secure, protocols from > load balancer to backend server, but probably not anything quite mature > enough to be worth referencing from here. > (e.g., draft-schwartz-tls-lb and another one that I think was presented > in QUIC but I can't find right now) > > Section 7 > > We could potentially also talk about how the use of jwks_uri requires > a fairly strong level of trust in the service at the target of the URI: > the client has to trust it to faithfully provide the certification > information, and the RS has to trust it to provide valid data for the > client in question, as well as the usual trust in the TLS connection > that identifies it, etc. > I understand what you are saying but don't know what I would actually write and kinda think that anything along those lines should have been in RFC 7591 anyway because it's applicable there and not just in the context of this narrow document. > > Section 7.1 > > The OAuth 2.0 Authorization Framework [RFC6749] requires that an > authorization server bind refresh tokens to the client to which they > were issued and that confidential clients (those having established > authentication credentials with the authorization server) > authenticate to the AS when presenting a refresh token. As a result, > refresh tokens are indirectly certificate-bound when issued to > clients utilizing the "tls_client_auth" or > "self_signed_tls_client_auth" methods of client authentication. > > nit(?): is this "indirectly" or "implicitly" bound? > I guess it's both? But "indirectly" seemed right to me. The word "implicit" also has some meaning and connotations in the general word of OAuth, which are unrelated but I was trying to avoid it just the same. > > Section 7.2 > > I'm not sure why we mention both (first) preimage and second-preimage > resistance, as they're pretty different properties. I suppose there > could be some registration scenarios where only the thumbprint is > provided and thus an attacker with a DB dump would not have the first > preimage in the form of the actual intended certificate, but even if > they could reconstruct that "real" preimage from the thumbprint they > wouldn't have the corresponding private key. So second-preimage > probably covers what we need, and we can assume that the "first" > preimage (certificate) is always available to the attacker. > > Section 7.4 > > Maybe we should say "agree out of band" on the set of trust anchors. > okay > > Section 7.5 > > o handling of null-terminator bytes and non-canonical string > representations in subject names; > > ASN.1 encodings are going to be using counted strings, so any > NUL terminators will be in implementation languages. I think we might > want to reword this to indicate that ASN.1 strings cannot be directly > interpreted as native language strings in languages that use NUL > terminators. > I am not equipped with the knowledge to do that rewording. Please suggest some specific text, if you'd like to have it reworded. > > o handling of wildcard patterns in subject names; > > Interestingly, RFC 5280 punts on the semantics of wildcard characters in > SANs, though I think many applications will insist on only a single > wildcard and the leftmost label being just the single wildcard > character. > Also there is no allowance anywhere in this draft for using wildcards in subject names for the client certificate. This whole section came as a suggestion doing WGLC that was taken to get through WGLC. But it's not entirely contextually relevant. This bullet in particular. Maybe it'd be better to remove it? > > Section 8 > > There's perhaps some additional considerations if a client uses the same > certificate across multiple RSes, in that the client certificate > provides an additional mechanism for collaborating RSes to correlate a > single client, in ways that just the access token would not. This is > not a terribly common threat model in a highly centralized deployment > where all RSes are fairly well trusted, of course, but there can be some > environments where it is relevant, so it probably merits discussion. > I have balked at adding any such discussion and will continue to do so because there is likely so much correlateble info in an access token already that the client has no control over and might well not even know about. I don't know how to write what you're suggesting in a meaningful way and without giving the impression that using a different certificate provides privacy benefits that are not really there. > > Section 9.2 > > This specification requests registration of the following value in > > nit: "values" plural > Will fix and also found and will fix the same thing in 9.3 > > Section 10.2 > > I think that RFC 7517 needs to be normative, since we use the jwks > containers for conveying certificate information. > okay > > It also seems like RFCs 7591 and 8414 should probably be normative. > I was on the fence with these two as i didn't think they are strictly necessary but am happy to move them to normative. 7519 and 7662 probably too. > > Traditionally we keep RFC 8174 as normative, as part of BCP 14 along > with RFC 2119. > I think I knew that but somehow got it wrong here. Will fix. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000041106b0590a72931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben, I attempt (over the course of many hours)= to respond to your comments and discuss your discuss inline below.

On M= on, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk ha= s entered the following ballot position for
draft-ietf-oauth-mtls-16: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake).=C2=A0 The authorization server and client=
can indicate their capabilities/preference via the RFC 8414 and RFC 7591 discovery and registration procedures, but I didn't see any discussion<= br> of how an AS might know a RS's capabilities, or how an RS might develop=
expectations of the capabilities of the clients accessing it.=C2=A0 A naive=
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators).=C2=A0 Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.

Is= there some text that you can propose?

Whethe= r or not to ask for or require MTLS and how to determine when is going to b= e a deployment decision of the RS. I don't think what you describe as t= he naive conclusion is all that naive at all. But maybe that just makes me = naive:) In implementations/deployments that I've seen thus far, a parti= cular RS decides (or is dictated by some policy) that its stuff is high val= ue enough that it needs cert-bound access tokens so it always sends a Certi= ficateRequest to the client during the TLS handshake. Such an RS that also = wants to allow access via non cert-bound access tokens might just let the T= LS connection proceed even if the client doesn't offer a certificate or= it might offer its stuff on a different host and/or port that is just regu= lar TLS. I don't want to preclude the use of renegotiation or post-hand= shake authentication but (other than some past pain with renegotiation) I&#= 39;m not really qualified to discuss or make recommendations about using th= em.
=C2=A0
Note also there is not something lik= e RFC 8414 and RFC 7591 for RSs and (for good reasons I think) the WG has b= alked at working on something like that. So the requirements/capabilities/p= references of an RS will need to be communicated or configured out-of-band.= And that's the case in general for RSs independent of this document. <= br>

(We may also want some additional text discussing error handling for the client/AS interaction, e.g., if a request shows up from a client-id that should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used the regular token endpoint and not the mtls endpoint alias (if they
differ).)

The end of sec 2 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2
=C2=A0says what to do in the case of a certificate mismatch in clie= nt auth:
=C2=A0=C2=A0 "If the presented certificate doe= sn't match that
=C2=A0 =C2=A0which is expected for the given "c= lient_id", the authorization server
=C2=A0 =C2=A0returns a normal O= Auth 2.0 error response per Section 5.2 of RFC6749
=C2=A0 =C2=A0[RFC6749= ] with the "invalid_client" error code to indicate failed
=C2= =A0 =C2=A0client authentication."

And my inte= nt and assumption was that a mismatch covered the case where no certificate= was presented (i.e. null cert doesn't match expected cert just as diff= erent cert doesn't match). But perhaps that particular case should be m= ade more explicit?=C2=A0 The second to last paragraph of sec 3 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 ha= s similar guidance for error handing in the case of mismatch during resourc= e access.

The case of a so called public clie= nt that has tls_client_certificate_bound_access_tokens metadata of true tha= t shows up at the token endpoint without having done MTLS is a bit more nua= nced and I think it's untimely a policy decision for the AS at that poi= nt as to whether to error or issue an unbound token.

=C2=A0

(2) I can't validate the examples in Appendix A.

Specifically, my reading of the text would put the "x5t#S256" val= ue as
needing 86 characters, but only 43 are provided.=C2=A0 The ones there also = do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:

base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64<= br>
(Noting, of course, that 'base64' will be producing the non-URL-saf= e
variant, but expecting it to remain "pretty close".)

Here's a quick back of the napkin calculation t= hat gives 43 characters: SHA 256 produces a 256 bit output, which is 32 byt= es. Base64url encoding 32 bytes gives 43 bytes/characters of output (the ratio of output bytes to input bytes is 4:3 with ba= se64 encoding).

I am not *nix skilled enough = to troubleshoot that command pipeline but I suspect that the sha256sum outp= ut is in hex which represents each byte of the hash output with two charter= ers and thus double the resultant size.

I don= 't believe this particular example has been validated by other folks bu= t it was produced using code that has produced consistent results with othe= r implementers. Also it's code from an existing JOSE/JWT library (https:/= /bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing sup= port for the x5t / x5t#S256 parameters in JWS and JWK.

<= /div>
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).

That was intentional and meant to show that access token validation can ha= ppen locally (in the box) or by introspection call-out to the AS (the arrow= ). Maybe this could be done a bit differently, with I dunno sub items of C1= and C2 or something, that would be more clear?

=C2=A0

=C2=A0 =C2=A0(C)=C2=A0 The protected resource validates the access token in= order to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorize the request.=C2=A0 In some cases, suc= h as when the token is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 self-contained and cryptographically secured, t= he validation can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be done locally by the protected resource.=C2= =A0 While other cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 require that the protected resource call out to= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization server to determine the state of = the token and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 obtain meta-information about it.

nit: "While" is a conjunction but this last sentence only has one=
clause.

Will remove.
=C2= =A0

=C2=A0 =C2=A0Layering on the abstract flow above, this document standardize= s
=C2=A0 =C2=A0enhanced security options for OAuth 2.0 utilizing client certi= ficate
=C2=A0 =C2=A0based mutual TLS.=C2=A0 Section 2 provides options for authent= icating the

nit: "client-certificate-based" is hyphenated.

ok
=C2=A0

=C2=A0 =C2=A0request in step (A).=C2=A0 While step (C) is supported with se= mantics to
=C2=A0 =C2=A0express the binding of the token to the client certificate for= both
=C2=A0 =C2=A0local and remote processing in Section 3.1 and Section 3.2
=C2=A0 =C2=A0respectively.=C2=A0 This ensures that, as described in Section= 3,

nit: same thing about "while".

ok
=C2=A0

=C2=A0 =C2=A0protected resource access in step (B) is only possible by the<= br> =C2=A0 =C2=A0legitimate client bearing the access token and holding the pri= vate
=C2=A0 =C2=A0key corresponding to the certificate.

nit: I guess it is only protected resource access "using this tokwn&qu= ot;
that is only possible as specified.

I k= inda felt like that was implied at this point. But I can add "using th= is token" there, if you think it's needed or helpful?
=C2=A0

Section 1.2

We probably want to say something like "in addition to the normal TLS<= br> server authentication with a certificate" -- we need both for it to properly be "mutual" :)

ok
=C2=A0

Section 2.1

=C2=A0 =C2=A0The PKI (public key infrastructure) method of mutual TLS OAuth= client
=C2=A0 =C2=A0authentication adheres to the way in which X.509 certificates = are
=C2=A0 =C2=A0traditionally used for authentication.=C2=A0 It relies on a va= lidated
=C2=A0 =C2=A0certificate chain [RFC5280] and a single subject distinguished= name
=C2=A0 =C2=A0(DN) or a single subject alternative name (SAN) to authenticat= e the
=C2=A0 =C2=A0client.=C2=A0 Only one subject name value of any type is used = for each

I think we might be able to refer to RFC 6125 and call these the "CN-I= D"
and "DNS-ID".=C2=A0 That might also let us get out of doing quite= as much
referencing to RFC 4514 and specifying string representations "by hand= "...

=C2=A0RFC 6125 "Represen= tation and Verification of Domain-Based Application Service
=C2=A0Identi= ty within Internet Public Key Infrastructure Using X.509 (PKIX)
=C2=A0 = =C2=A0 =C2=A0Certificates in the Context of Transport Layer Security (TLS)&= quot; came up at one point but given that certificate usage in this draft a= ren't about Domain-Based Application Services I was unable to see the a= pplicable or how using it might help.

=C2=A0

I'm surprised to not see any discussion of trust anchor management or how to indicate (or decide) which CAs are to be trusted for this
purpose, even if that's just to acknowledge that it must be done but leave it up to deployments.

It's go= tta be done (unless using the self-singed method) and it is definitely up t= o deployments as I wouldn't even pretend to know where to begin on prov= iding general guidance nor would I think it appropriate.
I felt like this was pretty well implied and touched on in secu= rity considerations too. But please suggest some specific text, if you thin= k it's needed or would be useful.
=C2=A0
= =C2=A0
Section 2.1.2

Similarly the tls_client_auth_san_uri could be a URI-ID.

Similar to the above I'm really not seeing how or why= this would be done or useful.

=C2=A0

=C2=A0 =C2=A0tls_client_auth_san_ip
=C2=A0 =C2=A0 =C2=A0 A string representation of an IP address in either dot= ted decimal
=C2=A0 =C2=A0 =C2=A0 notation (for IPv4) or colon-delimited hexadecimal (fo= r IPv6, as
=C2=A0 =C2=A0 =C2=A0 defined in [RFC4291] section 2.2) that is expected to = be present
=C2=A0 =C2=A0 =C2=A0 as an iPAddress SAN entry in the certificate, which th= e OAuth
=C2=A0 =C2=A0 =C2=A0 client will use in mutual TLS authentication.

Do we want to note that this string representation differs from the
actual iPAddress encoding?=C2=A0 I guess by the time you go to actually
implement it, it's probably pretty obvious, though...
<= div>
I don't know, to be honest. The text in question cam= e as a suggestion from someone on the WG list and it seemed good enough to = me.=C2=A0 I sort of thought it would probably be pretty obvious too. Howeve= r the other IESG ballot positions have also had similar(ish) comments (see = https://mailarchive.ietf.org/arch/msg/oauth/Pbpy= gP8an-e80dDolo97Q5cBdd4 and https://mailarch= ive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so it seems so= mething more or different is needed with respect to this tls_client_auth_sa= n_ip thing. The suggestion from Suresh around RFC 5952 seems promising but = I need to look further into it than just reading the title. Which I'll = do. But also trying to be somewhat timely in responding to these reviews. <= br>

I've also never been able to think of a ca= se where tls_client_auth_san_ip is actually needed so maybe removing it all= together is an option as well.

=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">
Section 2.2.2

=C2=A0 =C2=A0For the Self-Signed Certificate method of binding a certificat= e with
=C2=A0 =C2=A0a client using mutual TLS client authentication, the existing<= br> =C2=A0 =C2=A0"jwks_uri" or "jwks" metadata parameters f= rom [RFC7591] are used to
=C2=A0 =C2=A0convey the client's certificates via JSON Web Key (JWK) in= a JWK Set
=C2=A0 =C2=A0(JWKS) [RFC7517].=C2=A0 The "jwks" metadata paramete= r is a JWK Set
=C2=A0 =C2=A0containing the client's public keys as an array of JWKs wh= ile the
=C2=A0 =C2=A0"jwks_uri" parameter is a URL that references a clie= nt's JWK Set.=C2=A0 A
=C2=A0 =C2=A0certificate is represented with the "x5c" parameter = of an individual
=C2=A0 =C2=A0JWK within the set.=C2=A0 Note that the members of the JWK rep= resenting

nit: "containing the client's public keys" is a bit of a juxt= aposition
with "represented with the "x5c" parameter" (which is c= ertificates).
True, the certificate does contain the public key, so it's not exactly<= br> wrong, but since we focus elsewhere on the certificate, it may not make
sense to focus on the public key here.

= That juxtaposition arises out of the way JWK is primarily about bare public= keys and certificates are an optional additional JSON member.
=C2=A0

Section 3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Binding the a= ccess token to the client certificate in
=C2=A0 =C2=A0that fashion has the benefit of decoupling that binding from t= he
=C2=A0 =C2=A0client's authentication with the authorization server, whi= ch enables
=C2=A0 =C2=A0mutual TLS during protected resource access to serve purely as= a
=C2=A0 =C2=A0proof-of-possession mechanism.=C2=A0 Other methods of associat= ing a

I don't think I understand what's meant about "decoupling that= binding
from the client's authentication with the authorization server" --= it
seems like the authorization server shouldn't issue a bound token
without some proof of possession, which the client's authentication
thereto performs.

What it is trying to = say is that the AS does what the AS does in terms of client auth including = dealing with trust anchors and what type of subject name or allowing for se= lf singed auth matching against explicitly configured certs. But, because t= he token is bound to the hash of the cert, the RS need not concern itself w= ith any of that and can treat the client TLS certificate as only a proof-of= -possession mechanism for using the access token. Does that help your under= standing or just confuse things further?
=C2=A0

=C2=A0 =C2=A0The protected resource MUST obtain, from its TLS implementatio= n
=C2=A0 =C2=A0layer, the client certificate used for mutual TLS and MUST ver= ify
=C2=A0 =C2=A0that the certificate matches the certificate associated with t= he
=C2=A0 =C2=A0access token.=C2=A0 If they do not match, the resource access = attempt MUST

How does the resource server know it needs to do this?=C2=A0 Is this just configured as part of the ability to do mutual TLS, or indiated by a
token type, or something else?

Configur= ed and/or based on the presence of the cnf claim with x5t#S256 method in th= e access token.

=C2=A0

Section 3.1

Per BCP 201, we may want to say something about this recommendation
changing over time as cryptographic algorithm preferences change.=C2=A0 RFC=
7525 has a decent note to this effect:

=C2=A0 =C2=A0Community knowledge about the strength of various algorithms a= nd
=C2=A0 =C2=A0feasible attacks can change quickly, and experience shows that= a Best
=C2=A0 =C2=A0Current Practice (BCP) document about security is a point-in-t= ime
=C2=A0 =C2=A0statement.=C2=A0 Readers are advised to seek out any errata or= updates
=C2=A0 =C2=A0that apply to this document.

(obviously the "BCP" part doesn't apply to this document, but= most of
the rest should.)=C2=A0 This could of course be coordinated between here an= d
Section 7.2.

Makes sense. I'll inco= rporate some text borrowed from 7525 in 3.1 and/or 7.2.
=C2= =A0

There's only 43 characters of base64 in the "x5t#S256" exampl= e; for
SHA-256 output shouldn't there be 86?

see previous explanation of why 43 seems right based on my math and code=
=C2=A0

Section 3.2

(Same comment about the length of base64 in the example, in Figure 3.)
<= /blockquote>

same same
=C2=A0

Section 3.3

We should probably reference RFC 8414 (at least) the first time we talk
about authorizaiton server metadata parameters.

Yeah, that's an oversight on my part. Will fix.
=C2=A0

Section 3.4

Similarly, we could reference RFC 7591 here.

RFC 7591 has been referenced several times already at this point.

=C2=A0

Section 5

=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=A0Note
=C2=A0 =C2=A0that the endpoints in "mtls_endpoint_aliases" use a = different host
=C2=A0 =C2=A0than their conventional counterparts, which allows the authori= zation
=C2=A0 =C2=A0server (via SNI or actual distinct hosts) to differentiate its= TLS
=C2=A0 =C2=A0behavior as appropriate.

nit: Sadly, "SNI" does not appear in
https://www.rfc-editor.org/materials/abbr= ev.expansion.txt as a
"well-known" abbreviation, so we probably have to say 'TLS &q= uot;server_name"
extension [RFC 6066]' or similar.

S= hoot, okay. Will do.
=C2=A0

Section 6.1

=C2=A0 =C2=A0In order to support the Self-Signed Certificate method, the =C2=A0 =C2=A0authorization server would configure the TLS stack in such a w= ay that
=C2=A0 =C2=A0it does not verify whether the certificate presented by the cl= ient
=C2=A0 =C2=A0during the handshake is signed by a trusted CA certificate.
This statement doesn't quite follow -- *support*ing self-signed
certificates only requires that you configure TLS to not require a valid client cert+chain for the handshake to succeed, but it can still try to
validate such a chain.=C2=A0 This would be useful if, for example, you
intended to support both self-signed and CA-signed certificates.
We may also want a specific note to implementors to check validation
results for certificates intended to be CA-signed, if we're going to include a note about disabling validation for self-signed cert usage.

I take your point but the text (which I did = not write FWIW) was meant to be practical guidance based on an understandin= g of how the most common web servers work (problem in chain validation term= inates the handshake) and the options they provide (can turn off cert chain= validating) and what they surface about the handshake results (AFAIK not t= he kind of info that would allow the distinction you mention so the whole p= rocess of chain validation would maybe have to be deferred to the applicati= on layer). I can try and add or amend some text along the lines of your com= ment. But I worry I'd do more harm than good in doing so.

=C2=A0
Section 6.2

Would there be any scenario in which "additional security" might = be
gained from having the RS check that the client-presented cert does
chain to a trusted CA?

I'm sure the= re is some such scenario out there. But this is meant as implementation con= siderations or guidance for the general or common cases.
=C2= =A0

Section 6.3

Isn't this ignoring the elephant in the room about what to do when the<= br> refresh token is also bound to the (expiring) client certificate?


Section 6.5

There are a couple of active proposals for new, secure, protocols from
load balancer to backend server, but probably not anything quite mature
enough to be worth referencing from here.
(e.g., draft-schwartz-tls-lb and another one that I think was presented
in QUIC but I can't find right now)

Section 7

We could potentially also talk about how the use of jwks_uri requires
a fairly strong level of trust in the service at the target of the URI:
the client has to trust it to faithfully provide the certification
information, and the RS has to trust it to provide valid data for the
client in question, as well as the usual trust in the TLS connection
that identifies it, etc.


Section 7.1

=C2=A0 =C2=A0The OAuth 2.0 Authorization Framework [RFC6749] requires that = an
=C2=A0 =C2=A0authorization server bind refresh tokens to the client to whic= h they
=C2=A0 =C2=A0were issued and that confidential clients (those having establ= ished
=C2=A0 =C2=A0authentication credentials with the authorization server)
=C2=A0 =C2=A0authenticate to the AS when presenting a refresh token.=C2=A0 = As a result,
=C2=A0 =C2=A0refresh tokens are indirectly certificate-bound when issued to=
=C2=A0 =C2=A0clients utilizing the "tls_client_auth" or
=C2=A0 =C2=A0"self_signed_tls_client_auth" methods of client auth= entication.

nit(?): is this "indirectly" or "implicitly" bound?
=


Section 7.2

I'm not sure why we mention both (first) preimage and second-preimage resistance, as they're pretty different properties.=C2=A0 I suppose the= re
could be some registration scenarios where only the thumbprint is
provided and thus an attacker with a DB dump would not have the first
preimage in the form of the actual intended certificate, but even if
they could reconstruct that "real" preimage from the thumbprint t= hey
wouldn't have the corresponding private key.=C2=A0 So second-preimage probably covers what we need, and we can assume that the "first"<= br> preimage (certificate) is always available to the attacker.

Section 7.4

Maybe we should say "agree out of band" on the set of trust ancho= rs.


Section 7.5

=C2=A0 =C2=A0o=C2=A0 handling of null-terminator bytes and non-canonical st= ring
=C2=A0 =C2=A0 =C2=A0 representations in subject names;

ASN.1 encodings are going to be using counted strings, so any
NUL terminators will be in implementation languages.=C2=A0 I think we might=
want to reword this to indicate that ASN.1 strings cannot be directly
interpreted as native language strings in languages that use NUL
terminators.

I am not equipped with the= knowledge to do that rewording. Please suggest some specific text, if you&= #39;d like to have it reworded.=C2=A0
=C2=A0

=C2=A0 =C2=A0o=C2=A0 handling of wildcard patterns in subject names;

Interestingly, RFC 5280 punts on the semantics of wildcard characters in SANs, though I think many applications will insist on only a single
wildcard and the leftmost label being just the single wildcard
character.

Also there is no allowance a= nywhere in this draft for using wildcards in subject names for the client c= ertificate. This whole section came as a suggestion doing WGLC that was tak= en to get through WGLC. But it's not entirely contextually relevant. Th= is bullet in particular. Maybe it'd be better to remove it?
=C2=A0

Section 8

There's perhaps some additional considerations if a client uses the sam= e
certificate across multiple RSes, in that the client certificate
provides an additional mechanism for collaborating RSes to correlate a
single client, in ways that just the access token would not.=C2=A0 This is<= br> not a terribly common threat model in a highly centralized deployment
where all RSes are fairly well trusted, of course, but there can be some environments where it is relevant, so it probably merits discussion.

I have balked at adding any such discussion a= nd will continue to do so because there is likely so much correlateble info= in an access token already that the client has no control over and might w= ell not even know about. I don't know how to write what you're sugg= esting in a meaningful way and without giving the impression that using a d= ifferent certificate provides privacy benefits that are not really there. = =C2=A0
=C2=A0

Section 9.2

=C2=A0 =C2=A0This specification requests registration of the following valu= e in

nit: "values" plural

Will fix= and also found and will fix the same thing in 9.3
=C2=A0

Section 10.2

I think that RFC 7517 needs to be normative, since we use the jwks
containers for conveying certificate information.

=
okay
=C2=A0

It also seems like RFCs 7591 and 8414 should probably be normative.

I was on the fence with these two as i didn= 9;t think they are strictly necessary but am happy to move them to normativ= e. 7519 and 7662 probably too.
=C2=A0

Traditionally we keep RFC 8174 as normative, as part of BCP 14 along
with RFC 2119.

I think I knew that but = somehow got it wrong here. Will fix.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000041106b0590a72931-- From nobody Wed Aug 21 14:52:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50B1200B6 for ; Wed, 21 Aug 2019 14:52:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 yDTn0cW3unAE for ; Wed, 21 Aug 2019 14:52:10 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3B912001E for ; Wed, 21 Aug 2019 14:52:10 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id o9so7786921iom.3 for ; Wed, 21 Aug 2019 14:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DjVN34u4729kf2Ea2mQ7Jw2/OvzhqHalaMKBhWQPzOE=; b=RK8HSi8TFV8KqpTwCgrcFwCim/T/SucZDsJ6gwg6JUzSWmlFXcunX0Gy5u9X/krAVK Ap98LB5Ie2yFgrVam58PkFSlhkK7VtwL+nX3I1X65moukbg8biQ6VYjCrIy5ilxXV7YF ALEdOc/XGRyIXUtpXvl6rtjIy1aY5mqpBVGJU= 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=DjVN34u4729kf2Ea2mQ7Jw2/OvzhqHalaMKBhWQPzOE=; b=XdlXmke3fi1xOjMTDmy59UqtJR4nVDa803y3C8VmP5AZJvTNaAOITwy1Yn8hK8Fi1M OlLHffIznu1NSXGzsaN7tkMOMnLyt8bg4EkDU4YxZJfr5yTfwr04w95wNjtvgABu6Mz0 WxmMuUnfr1UJnLj9wEPElQMCHUGmh3c9vpb8AhonOdDCsUtbTMA0F1ewpyVuMFFz1fLv xkCcsFguMoF7sS2P5yXoBPjve7xWGsPxAybRo84MAEnDOYlnylHOn3cvp7yIDtVcctKb 7b2L4wx7qVqUtXIIQDVXMM3H/MeUsZSzhMvh7THJmxwGVIJLb7YR2eAxVW8UmtiBTcDQ kMRQ== X-Gm-Message-State: APjAAAUs0ZbyRDGFEwWhxkYTnxC/k5YBOtGgIVai1MXe7g+WPOy+b5Q9 T5xnB7bsL0IP9aXWfYOyW0+qK9rZsRMac8JhBV/av21EsGGfP5gtPDXLCi7iLX6TjNbxe8cRXjp m1lu1Wr3/WSDhxQ== X-Google-Smtp-Source: APXvYqwMs5u7QcwRE0hjc6YZD8KR+SVK6ktjTgzCxRik/eNHGUWuOCYp448w0QeJxAu2PHHptXkgyOE/s7Jxp3P1DA0= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr1874539ioc.115.1566424329783; Wed, 21 Aug 2019 14:52:09 -0700 (PDT) MIME-Version: 1.0 References: <156632859162.350.2919813913771406915.idtracker@ietfa.amsl.com> In-Reply-To: <156632859162.350.2919813913771406915.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 21 Aug 2019 15:51:43 -0600 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000be9fdc0590a795d6" Archived-At: Subject: Re: [OAUTH-WG] Suresh Krishnan's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:52:14 -0000 --000000000000be9fdc0590a795d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Suresh, I'll consider using RFC5952 there as I try and work though some other comments on that parameter in that section. On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 2.1.2. > > Suggest using the IPv6 Address Text Representation described in RFC5952 > instead > of using the representations described in RFC4291 section 2.2. The > canonical > representation described in RFC5952 makes it easier to compare two IPv6 > address > strings which is probably something you want to do while doing mutual > authentication. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000be9fdc0590a795d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Suresh, I'll consider using RFC5952 there = as I try and work though some other comments on that parameter in that sect= ion.

On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker &l= t;noreply@ietf.org> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 ins= tead
of using the representations described in RFC4291 section 2.2. The canonica= l
representation described in RFC5952 makes it easier to compare two IPv6 add= ress
strings which is probably something you want to do while doing mutual
authentication.


_______________________________________________
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. --000000000000be9fdc0590a795d6-- From nobody Wed Aug 21 15:08:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB75D120113 for ; Wed, 21 Aug 2019 15:08:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 smbMEg5wfjcv for ; Wed, 21 Aug 2019 15:08:05 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 2BCD012010F for ; Wed, 21 Aug 2019 15:08:05 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id p12so7847268iog.5 for ; Wed, 21 Aug 2019 15:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y4C1D54pGHVMqaazZQxb2P/p9WUu2iLQdqFhSV23Ebg=; b=NZ8LE6LOB6p1HXRGM+33LTAUhrJuTKjCqDclLycJ4/j00BhWJmOyk+2ydz49k0NQH1 zSFdo+FdU92eicHMc3WUAkHOSaKm02nvsEbU4kpIcaG8lZuHpuDYvJ55y/QqyJaewOnd Jn68rx22ghJALJJIcKgAp8E8t2zEHV5/P9KrI= 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=y4C1D54pGHVMqaazZQxb2P/p9WUu2iLQdqFhSV23Ebg=; b=SuL2AbGehtf+0ZenrdR2QdcT4UwJJEs5tyUurnZEeQcC8m0QuZzy0rWsXYVE3a8vif h2iIbId5Irys9cvyeGzTATMd1gajciaS14YGWFVlisjA+IqUH+DCB/ogrLQ8vMu5GVRU b5gMhHUDb/FFZe6CMwOYjfbXZt+f9OFXbU25SqDUZoh31QRsjDirCMt4kwrEhzPMeZ6v eiI0PUnByAexKf/BnMxNHpHoePs8ssvCnibRncrtSdkOaOCJbYKPtkEvz7mVzRldDuRD 1OlW9bGDRasZJt8EHdhXoaDt6zBlr91KytP29r7pmUpR9aPId/+QCOUBSWAcBRt/Yq5e 8M/A== X-Gm-Message-State: APjAAAXAKq9Vg71DJAo+ay6T4eKJ2q3PZrhBsACVoLQSjRqy/0+K+7W8 HDbp2ZtB3VqFGmIkI1mveMQ1SRLxs+lEiQ88vFCUHw6I5QEclP9bUtYCT4IFznQjDWHwb9RUyvs 5m224fPqDtuh4Og== X-Google-Smtp-Source: APXvYqw25mlCI/hk0dbEj5v364wAaDotpPcCsVnccrZ58T0cCItlFkG6q0O+tuZvlux7jgdPIKPE4cRBD+Fc9LhMcbM= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr1950626ioc.115.1566425284339; Wed, 21 Aug 2019 15:08:04 -0700 (PDT) MIME-Version: 1.0 References: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> In-Reply-To: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 21 Aug 2019 16:07:38 -0600 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a3f88c0590a7cef9" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 22:08:08 -0000 --000000000000a3f88c0590a7cef9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adam, I attempt to provide not-too-terrible replies to your comments inline below. On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for the work that everyone did on this document. I have one > suggestion > for clarification, followed by a handful of editorial nits. > > -------------------------------------------------------------------------= -- > > =C2=A72.1.2: > > > tls_client_auth_san_ip > > A string representation of an IP address in either dotted decimal > > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as > > defined in [RFC4291] section 2.2) that is expected to be present > > as an iPAddress SAN entry in the certificate, which the OAuth > > client will use in mutual TLS authentication. > > This probably needs some text that clarifies expectations around comparis= on > and/or normalization. For example, if the iPAddress value in the cert is > "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's)= , > one > should presume that this would match both tls_client_auth_san_ip values > "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, th= en > this document needs to talk about normalization of address representation= . > Can you help me with some text here? I'm a bit out of my realm, to be honest. I naively just want it to say that the tls_client_auth_san_ip value and iPAddress value in the cert need to be the same IP address. But I do realize "same" isn't totally clear as your comment and others have pointed out. But I don't know enough to know how to write it in a way that's suitable for this kind of thing. Alternatively, as I mentioned in my response to Ben (down a ways in https://mailarchive.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ), I've never personally been able to think of a situation where tls_client_auth_san_ip is actually needed. So maybe removing it all together is an option as well? > -------------------------------------------------------------------------= -- > > =C2=A71: > > > Layering on the abstract flow above, this document standardizes > > enhanced security options for OAuth 2.0 utilizing client certificate > > based mutual TLS. > > Nit: "client-certificate-based" > Mr. Kaduk beat you to this one. Will fix. > OAuth 2.0 defines a shared secret method of client authentication but > > Nit: "shared-secret" > Will fix. > > -------------------------------------------------------------------------= -- > =C2=A71: > > > This document describes an additional > > mechanism of client authentication utilizing mutual TLS certificate- > > based authentication > > Nit: "mutual-TLS" > > > Mutual TLS certificate-bound access tokens ensure that only the party > > Nit: "Mutual-TLS" > > > Mutual TLS certificate-bound access tokens and mutual TLS client > > Nit: "Mutual-TLS... mutual-TLS" > > > Additional client metadata parameters are introduced by this document > > in support of certificate-bound access tokens and mutual TLS client > > authentication. > > Nit: "mutual-TLS" > > The remainder of the document has several other uses of the phrase "mutua= l > TLS" as an adjective; they should be similarly hyphenated. I will not cal= l > them out individually. (Non-adjectival uses should not contain hyphens, s= o > this isn't a simple find-and-replace operation.) > Understood. In theory anyway. I'll take a pass thought the whole document and endeavor to find and hyphenate all the places that "mutual TLS" is used as an adjective. > > -------------------------------------------------------------------------= -- > > =C2=A75: > > > Authorization servers supporting both clients using mutual TLS and > > conventional clients MAY chose to isolate the server side mutual TLS > > behaviour to only clients intending to do mutual TLS, thus avoiding > > Nit: "behavior" (or adjust other spellings in the document to be > consistently > British). > Ugh. I'm surprised my jingoistic spellcheck didn't flag that one. Will fix. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a3f88c0590a7cef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam, I attempt to provide not-too-terrible re= plies to your comments inline below.

On Mon, Aug 19, 2019 at 8:02 PM Ad= am Roach via Datatracker <noreply@ietf.org> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for the work that everyone did on this document. I have one suggesti= on
for clarification, followed by a handful of editorial nits.

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

=C2=A72.1.2:

>=C2=A0 tls_client_auth_san_ip
>=C2=A0 =C2=A0 =C2=A0A string representation of an IP address in either = dotted decimal
>=C2=A0 =C2=A0 =C2=A0notation (for IPv4) or colon-delimited hexadecimal = (for IPv6, as
>=C2=A0 =C2=A0 =C2=A0defined in [RFC4291] section 2.2) that is expected = to be present
>=C2=A0 =C2=A0 =C2=A0as an iPAddress SAN entry in the certificate, which= the OAuth
>=C2=A0 =C2=A0 =C2=A0client will use in mutual TLS authentication.

This probably needs some text that clarifies expectations around comparison=
and/or normalization. For example, if the iPAddress value in the cert is "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of = all F's), one
should presume that this would match both tls_client_auth_san_ip values
"2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202"= , right? If no, then
this document needs to talk about normalization of address representation.<= br>

Can you help me with some text here? I&= #39;m a bit out of my realm, to be honest. I naively just want it to say th= at the tls_client_auth_san_ip value and iPAddress value in the cert need to= be the same IP address. But I do realize "same" isn't totall= y clear as your comment and others have pointed out. But I don't know e= nough to know how to write it in a way that's suitable for this kind of= thing.

Alternatively, as I mentioned in my r= esponse to Ben (down a ways in https://mailarchive.ietf.org/arch/m= sg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ), I've never personally been a= ble to think of a situation where tls_client_auth_san_ip is actually needed= .=C2=A0 So maybe removing it all together is an option as well?
<= br>
=C2=A0
---------------------------------------------------------------------------=

=C2=A71:

>=C2=A0 Layering on the abstract flow above, this document standardizes<= br> >=C2=A0 enhanced security options for OAuth 2.0 utilizing client certifi= cate
>=C2=A0 based mutual TLS.

Nit: "client-certificate-based"

Mr. Kaduk beat you to this one. Will fix.
=C2=A0

>=C2=A0 OAuth 2.0 defines a shared secret method of client authenticatio= n but

Nit: "shared-secret"

Will fix= .
=C2=A0

---------------------------------------------------------------------------=
=C2=A71:

>=C2=A0 This document describes an additional
>=C2=A0 mechanism of client authentication utilizing mutual TLS certific= ate-
>=C2=A0 based authentication

Nit: "mutual-TLS"

>=C2=A0 Mutual TLS certificate-bound access tokens ensure that only the = party

Nit: "Mutual-TLS"

>=C2=A0 Mutual TLS certificate-bound access tokens and mutual TLS client=

Nit: "Mutual-TLS... mutual-TLS"

>=C2=A0 Additional client metadata parameters are introduced by this doc= ument
>=C2=A0 in support of certificate-bound access tokens and mutual TLS cli= ent
>=C2=A0 authentication.

Nit: "mutual-TLS"

The remainder of the document has several other uses of the phrase "mu= tual
TLS" as an adjective; they should be similarly hyphenated. I will not = call
them out individually. (Non-adjectival uses should not contain hyphens, so<= br> this isn't a simple find-and-replace operation.)
<= br>
Understood. In theory anyway.=C2=A0 I'll take a pass thou= ght the whole document and endeavor to find and hyphenate all the places th= at "mutual TLS" is used as an adjective.

=C2=A0

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

=C2=A75:

>=C2=A0 Authorization servers supporting both clients using mutual TLS a= nd
>=C2=A0 conventional clients MAY chose to isolate the server side mutual= TLS
>=C2=A0 behaviour to only clients intending to do mutual TLS, thus avoid= ing

Nit: "behavior" (or adjust other spellings in the document to be = consistently
British).

=C2=A0Ugh. I'm surprised = my jingoistic spellcheck didn't flag that one. Will fix.

<= 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. --000000000000a3f88c0590a7cef9-- From nobody Wed Aug 21 20:19:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054F120143 for ; Wed, 21 Aug 2019 20:19: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 v2To3CDSyPz2 for ; Wed, 21 Aug 2019 20:19:02 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 9DEF5120804 for ; Wed, 21 Aug 2019 20:19:02 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id l7so8997915ioj.6 for ; Wed, 21 Aug 2019 20:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vdFUOzybxO/XLsN1LwCKkLMetJpSpAKJTBQ34L9nysk=; b=JmnuYapJ7zHZOmPCc8S2bPlsBHWiYJ8iaVB2ap63uNVfjX0vFtD1alERw7q4hJtr7d YElcDWqRRdji7HYvvr8Z8ZJSIKIN/H1pd/KL7WtMuwQCPuA+4j7w0tfEpD38LQnEpbm5 xkz1kidoLu37Yq8GUboe22okMQus2DaB+6tRs= 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=vdFUOzybxO/XLsN1LwCKkLMetJpSpAKJTBQ34L9nysk=; b=qEbjFkkWmvhYAavDDdikp2fVaH5Y9xhSi283XCBm+ZowLmn7KChS2Uu3Nyuop9WdUv tvMHfeMSBElK3z/t+BOO9Lr3yk5N9Rk7ttOun2Z7nQLZHxjDGwhduOTtUAu9MD5jEtvZ od0Gag0Mv+dczw5ACet+8PyRXdwM6xyh38J6uhPtclSFa1SAdiRulUixYTmbdqxlPxqe VbfnCC39PrMwQ1VoXlNHFCi7VCb1EuMeOUdgUPL2Q+uvA6Tbx7c5Jpdw51YEdrrzSTv1 WMdbt8ibYZyOT0O/p5p00oBGsaLhIn2g8c5MnePp0n/J+8LziODM1E0V6HUIMqk/cDiP QFJQ== X-Gm-Message-State: APjAAAUSs+M1bgIAVaoBrfFzPhFFYNuO4HHrvAoRyqpIs+VES6oIWN7J 41/BK5/ykDGHaslNeSzosgGspxBWOgNcE+aGpGYxqqhaVib1DSM5QHuwGY1wF7sg1dvc0DFn/yv 9ChCBqPRYSYfyyg== X-Google-Smtp-Source: APXvYqzj99JhXCmAhfZJVdgOykgBrZ2uUwbtaG5JdKaJHXiELEornH8FCKDoQI+wD6LEyTs31OUDQlpalHYO2RbWasY= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr3214618ioc.115.1566443941610; Wed, 21 Aug 2019 20:19:01 -0700 (PDT) MIME-Version: 1.0 References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Wed, 21 Aug 2019 21:18:35 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b360f90590ac2663" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 03:19:14 -0000 --000000000000b360f90590ac2663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I missed responding to this one part below about sec 7.2 and yet somehow remembered that I'd missed it. Anyway, I feel like I had some seemingly legitimate reason for mentioning (first) preimage when I wrote that text but I cannot recall what that was and, on reading the text again with the benefit of your comment, I think you are right. Second-preimage resistance is what we care about in this context. I'll drop mention of regular preimage. > Section 7.2 > > I'm not sure why we mention both (first) preimage and second-preimage > resistance, as they're pretty different properties. I suppose there > could be some registration scenarios where only the thumbprint is > provided and thus an attacker with a DB dump would not have the first > preimage in the form of the actual intended certificate, but even if > they could reconstruct that "real" preimage from the thumbprint they > wouldn't have the corresponding private key. So second-preimage > probably covers what we need, and we can assume that the "first" > preimage (certificate) is always available to the attacker. On Wed, Aug 21, 2019 at 3:21 PM Brian Campbell wrote: > Thanks Ben, I attempt (over the course of many hours) to respond to your > comments and discuss your discuss inline below. > > On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-oauth-mtls-16: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (1) I think that we need some text that covers how the resource server >> will know to use mtls (and thus, to send a CertificateRequest to the >> client during the TLS handshake). The authorization server and client >> can indicate their capabilities/preference via the RFC 8414 and RFC 7591 >> discovery and registration procedures, but I didn't see any discussion >> of how an AS might know a RS's capabilities, or how an RS might develop >> expectations of the capabilities of the clients accessing it. A naive >> conclusion might be that any given RS (hostname+port) would have to >> either always or never use mtls, given the misordering between TLS >> handshake completion and delivery of TLS application data (i.e., >> including the oauth token), though there may be refinements available in >> the form of the unpopular TLS 1.2 renegotiation or TLS 1.3 >> post-handshake authentication (or exported authenticators). Doing >> either of those in an environment with TLS Termination per Section 6.5 >> may entail additional complications. >> > > Is there some text that you can propose? > > Whether or not to ask for or require MTLS and how to determine when is > going to be a deployment decision of the RS. I don't think what you > describe as the naive conclusion is all that naive at all. But maybe that > just makes me naive:) In implementations/deployments that I've seen thus > far, a particular RS decides (or is dictated by some policy) that its stu= ff > is high value enough that it needs cert-bound access tokens so it always > sends a CertificateRequest to the client during the TLS handshake. Such a= n > RS that also wants to allow access via non cert-bound access tokens might > just let the TLS connection proceed even if the client doesn't offer a > certificate or it might offer its stuff on a different host and/or port > that is just regular TLS. I don't want to preclude the use of renegotiati= on > or post-handshake authentication but (other than some past pain with > renegotiation) I'm not really qualified to discuss or make recommendation= s > about using them. > > Note also there is not something like RFC 8414 and RFC 7591 for RSs and > (for good reasons I think) the WG has balked at working on something like > that. So the requirements/capabilities/preferences of an RS will need to = be > communicated or configured out-of-band. And that's the case in general fo= r > RSs independent of this document. > > (We may also want some additional text discussing error handling for the >> client/AS interaction, e.g., if a request shows up from a client-id that >> should be using mtls but did not provide a certificate in the TLS >> handshake, but that is only debatably something that rises to >> Discuss-level; or if a client that advertised an intent to use MTLS used >> the regular token endpoint and not the mtls endpoint alias (if they >> differ).) >> > > The end of sec 2 > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2 > says what to do in the case of a certificate mismatch in client auth: > "If the presented certificate doesn't match that > which is expected for the given "client_id", the authorization server > returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749 > [RFC6749] with the "invalid_client" error code to indicate failed > client authentication." > > And my intent and assumption was that a mismatch covered the case where n= o > certificate was presented (i.e. null cert doesn't match expected cert jus= t > as different cert doesn't match). But perhaps that particular case should > be made more explicit? The second to last paragraph of sec 3 > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has > similar guidance for error handing in the case of mismatch during resourc= e > access. > > The case of a so called public client that has > tls_client_certificate_bound_access_tokens metadata of true that shows up > at the token endpoint without having done MTLS is a bit more nuanced and = I > think it's untimely a policy decision for the AS at that point as to > whether to error or issue an unbound token. > > > >> >> (2) I can't validate the examples in Appendix A. >> >> Specifically, my reading of the text would put the "x5t#S256" value as >> needing 86 characters, but only 43 are provided. The ones there also do >> not seem to be a prefix of the result that I get from taking the PEM >> certificate contents and running them through the pipeline: >> >> base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64 >> >> (Noting, of course, that 'base64' will be producing the non-URL-safe >> variant, but expecting it to remain "pretty close".) >> > > Here's a quick back of the napkin calculation that gives 43 characters: > SHA 256 produces a 256 bit output, which is 32 bytes. Base64url encoding = 32 > bytes gives 43 bytes/characters of output (the ratio of output bytes to > input bytes is 4:3 with base64 encoding). > > I am not *nix skilled enough to troubleshoot that command pipeline but I > suspect that the sha256sum output is in hex which represents each byte of > the hash output with two charterers and thus double the resultant size. > > I don't believe this particular example has been validated by other folks > but it was produced using code that has produced consistent results with > other implementers. Also it's code from an existing JOSE/JWT library ( > https://bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing > support for the x5t / x5t#S256 parameters in JWS and JWK. > > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 1 >> >> nit: in Figure 1, the (C) label is applied to both an arrow and a box >> (the other two boxes are not labelled). >> > > That was intentional and meant to show that access token validation can > happen locally (in the box) or by introspection call-out to the AS (the > arrow). Maybe this could be done a bit differently, with I dunno sub item= s > of C1 and C2 or something, that would be more clear? > > > >> >> (C) The protected resource validates the access token in order to >> authorize the request. In some cases, such as when the token is >> self-contained and cryptographically secured, the validation can >> be done locally by the protected resource. While other cases >> require that the protected resource call out to the >> authorization server to determine the state of the token and >> obtain meta-information about it. >> >> nit: "While" is a conjunction but this last sentence only has one >> clause. >> > > Will remove. > > >> >> Layering on the abstract flow above, this document standardizes >> enhanced security options for OAuth 2.0 utilizing client certificate >> based mutual TLS. Section 2 provides options for authenticating the >> >> nit: "client-certificate-based" is hyphenated. >> > > ok > > >> >> request in step (A). While step (C) is supported with semantics to >> express the binding of the token to the client certificate for both >> local and remote processing in Section 3.1 and Section 3.2 >> respectively. This ensures that, as described in Section 3, >> >> nit: same thing about "while". >> > > ok > > >> >> protected resource access in step (B) is only possible by the >> legitimate client bearing the access token and holding the private >> key corresponding to the certificate. >> >> nit: I guess it is only protected resource access "using this tokwn" >> that is only possible as specified. >> > > I kinda felt like that was implied at this point. But I can add "using > this token" there, if you think it's needed or helpful? > > >> >> Section 1.2 >> >> We probably want to say something like "in addition to the normal TLS >> server authentication with a certificate" -- we need both for it to >> properly be "mutual" :) >> > > ok > > >> >> Section 2.1 >> >> The PKI (public key infrastructure) method of mutual TLS OAuth client >> authentication adheres to the way in which X.509 certificates are >> traditionally used for authentication. It relies on a validated >> certificate chain [RFC5280] and a single subject distinguished name >> (DN) or a single subject alternative name (SAN) to authenticate the >> client. Only one subject name value of any type is used for each >> >> I think we might be able to refer to RFC 6125 and call these the "CN-ID" >> and "DNS-ID". That might also let us get out of doing quite as much >> referencing to RFC 4514 and specifying string representations "by hand".= .. >> > > RFC 6125 "Representation and Verification of Domain-Based Application > Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS)" came > up at one point but given that certificate usage in this draft aren't abo= ut > Domain-Based Application Services I was unable to see the applicable or h= ow > using it might help. > > > >> >> I'm surprised to not see any discussion of trust anchor management or >> how to indicate (or decide) which CAs are to be trusted for this >> purpose, even if that's just to acknowledge that it must be done but >> leave it up to deployments. >> > > It's gotta be done (unless using the self-singed method) and it is > definitely up to deployments as I wouldn't even pretend to know where to > begin on providing general guidance nor would I think it appropriate. > > I felt like this was pretty well implied and touched on in security > considerations too. But please suggest some specific text, if you think > it's needed or would be useful. > > > >> Section 2.1.2 >> >> Similarly the tls_client_auth_san_uri could be a URI-ID. >> > > Similar to the above I'm really not seeing how or why this would be done > or useful. > > > >> >> tls_client_auth_san_ip >> A string representation of an IP address in either dotted decimal >> notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as >> defined in [RFC4291] section 2.2) that is expected to be present >> as an iPAddress SAN entry in the certificate, which the OAuth >> client will use in mutual TLS authentication. >> >> Do we want to note that this string representation differs from the >> actual iPAddress encoding? I guess by the time you go to actually >> implement it, it's probably pretty obvious, though... >> > > I don't know, to be honest. The text in question came as a suggestion fro= m > someone on the WG list and it seemed good enough to me. I sort of though= t > it would probably be pretty obvious too. However the other IESG ballot > positions have also had similar(ish) comments (see > https://mailarchive.ietf.org/arch/msg/oauth/PbpygP8an-e80dDolo97Q5cBdd4 > and > https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) > so it seems something more or different is needed with respect to this > tls_client_auth_san_ip thing. The suggestion from Suresh around RFC 5952 > seems promising but I need to look further into it than just reading the > title. Which I'll do. But also trying to be somewhat timely in responding > to these reviews. > > I've also never been able to think of a case where tls_client_auth_san_ip > is actually needed so maybe removing it all together is an option as well= . > > > >> >> Section 2.2.2 >> >> For the Self-Signed Certificate method of binding a certificate with >> a client using mutual TLS client authentication, the existing >> "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to >> convey the client's certificates via JSON Web Key (JWK) in a JWK Set >> (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set >> containing the client's public keys as an array of JWKs while the >> "jwks_uri" parameter is a URL that references a client's JWK Set. A >> certificate is represented with the "x5c" parameter of an individual >> JWK within the set. Note that the members of the JWK representing >> >> nit: "containing the client's public keys" is a bit of a juxtaposition >> with "represented with the "x5c" parameter" (which is certificates). >> True, the certificate does contain the public key, so it's not exactly >> wrong, but since we focus elsewhere on the certificate, it may not make >> sense to focus on the public key here. >> > > That juxtaposition arises out of the way JWK is primarily about bare > public keys and certificates are an optional additional JSON member. > > >> >> Section 3 >> >> Binding the access token to the client certificate in >> that fashion has the benefit of decoupling that binding from the >> client's authentication with the authorization server, which enables >> mutual TLS during protected resource access to serve purely as a >> proof-of-possession mechanism. Other methods of associating a >> >> I don't think I understand what's meant about "decoupling that binding >> from the client's authentication with the authorization server" -- it >> seems like the authorization server shouldn't issue a bound token >> without some proof of possession, which the client's authentication >> thereto performs. >> > > What it is trying to say is that the AS does what the AS does in terms of > client auth including dealing with trust anchors and what type of subject > name or allowing for self singed auth matching against explicitly > configured certs. But, because the token is bound to the hash of the cert= , > the RS need not concern itself with any of that and can treat the client > TLS certificate as only a proof-of-possession mechanism for using the > access token. Does that help your understanding or just confuse things > further? > > >> >> The protected resource MUST obtain, from its TLS implementation >> layer, the client certificate used for mutual TLS and MUST verify >> that the certificate matches the certificate associated with the >> access token. If they do not match, the resource access attempt MUST >> >> How does the resource server know it needs to do this? Is this just >> configured as part of the ability to do mutual TLS, or indiated by a >> token type, or something else? >> > > Configured and/or based on the presence of the cnf claim with x5t#S256 > method in the access token. > > > >> >> Section 3.1 >> >> Per BCP 201, we may want to say something about this recommendation >> changing over time as cryptographic algorithm preferences change. RFC >> 7525 has a decent note to this effect: >> >> Community knowledge about the strength of various algorithms and >> feasible attacks can change quickly, and experience shows that a Best >> Current Practice (BCP) document about security is a point-in-time >> statement. Readers are advised to seek out any errata or updates >> that apply to this document. >> >> (obviously the "BCP" part doesn't apply to this document, but most of >> the rest should.) This could of course be coordinated between here and >> Section 7.2. >> > > Makes sense. I'll incorporate some text borrowed from 7525 in 3.1 and/or > 7.2. > > >> >> There's only 43 characters of base64 in the "x5t#S256" example; for >> SHA-256 output shouldn't there be 86? >> > > see previous explanation of why 43 seems right based on my math and code > > >> >> Section 3.2 >> >> (Same comment about the length of base64 in the example, in Figure 3.) >> > > same same > > >> >> Section 3.3 >> >> We should probably reference RFC 8414 (at least) the first time we talk >> about authorizaiton server metadata parameters. >> > > Yeah, that's an oversight on my part. Will fix. > > >> >> Section 3.4 >> >> Similarly, we could reference RFC 7591 here. >> > > RFC 7591 has been referenced several times already at this point. > > > >> >> Section 5 >> >> Note >> that the endpoints in "mtls_endpoint_aliases" use a different host >> than their conventional counterparts, which allows the authorization >> server (via SNI or actual distinct hosts) to differentiate its TLS >> behavior as appropriate. >> >> nit: Sadly, "SNI" does not appear in >> https://www.rfc-editor.org/materials/abbrev.expansion.txt as a >> "well-known" abbreviation, so we probably have to say 'TLS "server_name" >> extension [RFC 6066]' or similar. >> > > Shoot, okay. Will do. > > >> >> Section 6.1 >> >> In order to support the Self-Signed Certificate method, the >> authorization server would configure the TLS stack in such a way that >> it does not verify whether the certificate presented by the client >> during the handshake is signed by a trusted CA certificate. >> >> This statement doesn't quite follow -- *support*ing self-signed >> certificates only requires that you configure TLS to not require a valid >> client cert+chain for the handshake to succeed, but it can still try to >> validate such a chain. This would be useful if, for example, you >> intended to support both self-signed and CA-signed certificates. >> We may also want a specific note to implementors to check validation >> results for certificates intended to be CA-signed, if we're going to >> include a note about disabling validation for self-signed cert usage. >> > > I take your point but the text (which I did not write FWIW) was meant to > be practical guidance based on an understanding of how the most common we= b > servers work (problem in chain validation terminates the handshake) and t= he > options they provide (can turn off cert chain validating) and what they > surface about the handshake results (AFAIK not the kind of info that woul= d > allow the distinction you mention so the whole process of chain validatio= n > would maybe have to be deferred to the application layer). I can try and > add or amend some text along the lines of your comment. But I worry I'd d= o > more harm than good in doing so. > > > >> Section 6.2 >> >> Would there be any scenario in which "additional security" might be >> gained from having the RS check that the client-presented cert does >> chain to a trusted CA? >> > > I'm sure there is some such scenario out there. But this is meant as > implementation considerations or guidance for the general or common cases= . > > >> >> Section 6.3 >> >> Isn't this ignoring the elephant in the room about what to do when the >> refresh token is also bound to the (expiring) client certificate? >> > > The only time a refresh token is bound directly to the client certificate > is for public clients ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-4 and > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-7.1) and > public clients can only use self signed certificates for which the > expiration isn't all that meaningful and can be made to be far enough in > the future. > > >> >> Section 6.5 >> >> There are a couple of active proposals for new, secure, protocols from >> load balancer to backend server, but probably not anything quite mature >> enough to be worth referencing from here. >> (e.g., draft-schwartz-tls-lb and another one that I think was presented >> in QUIC but I can't find right now) >> >> Section 7 >> >> We could potentially also talk about how the use of jwks_uri requires >> a fairly strong level of trust in the service at the target of the URI: >> the client has to trust it to faithfully provide the certification >> information, and the RS has to trust it to provide valid data for the >> client in question, as well as the usual trust in the TLS connection >> that identifies it, etc. >> > > I understand what you are saying but don't know what I would actually > write and kinda think that anything along those lines should have been in > RFC 7591 anyway because it's applicable there and not just in the context > of this narrow document. > > >> >> Section 7.1 >> >> The OAuth 2.0 Authorization Framework [RFC6749] requires that an >> authorization server bind refresh tokens to the client to which they >> were issued and that confidential clients (those having established >> authentication credentials with the authorization server) >> authenticate to the AS when presenting a refresh token. As a result, >> refresh tokens are indirectly certificate-bound when issued to >> clients utilizing the "tls_client_auth" or >> "self_signed_tls_client_auth" methods of client authentication. >> >> nit(?): is this "indirectly" or "implicitly" bound? >> > > I guess it's both? But "indirectly" seemed right to me. The word > "implicit" also has some meaning and connotations in the general word of > OAuth, which are unrelated but I was trying to avoid it just the same. > > >> >> Section 7.2 >> >> I'm not sure why we mention both (first) preimage and second-preimage >> resistance, as they're pretty different properties. I suppose there >> could be some registration scenarios where only the thumbprint is >> provided and thus an attacker with a DB dump would not have the first >> preimage in the form of the actual intended certificate, but even if >> they could reconstruct that "real" preimage from the thumbprint they >> wouldn't have the corresponding private key. So second-preimage >> probably covers what we need, and we can assume that the "first" >> preimage (certificate) is always available to the attacker. >> >> Section 7.4 >> >> Maybe we should say "agree out of band" on the set of trust anchors. >> > > okay > > >> >> Section 7.5 >> >> o handling of null-terminator bytes and non-canonical string >> representations in subject names; >> >> ASN.1 encodings are going to be using counted strings, so any >> NUL terminators will be in implementation languages. I think we might >> want to reword this to indicate that ASN.1 strings cannot be directly >> interpreted as native language strings in languages that use NUL >> terminators. >> > > I am not equipped with the knowledge to do that rewording. Please suggest > some specific text, if you'd like to have it reworded. > > >> >> o handling of wildcard patterns in subject names; >> >> Interestingly, RFC 5280 punts on the semantics of wildcard characters in >> SANs, though I think many applications will insist on only a single >> wildcard and the leftmost label being just the single wildcard >> character. >> > > Also there is no allowance anywhere in this draft for using wildcards in > subject names for the client certificate. This whole section came as a > suggestion doing WGLC that was taken to get through WGLC. But it's not > entirely contextually relevant. This bullet in particular. Maybe it'd be > better to remove it? > > >> >> Section 8 >> >> There's perhaps some additional considerations if a client uses the same >> certificate across multiple RSes, in that the client certificate >> provides an additional mechanism for collaborating RSes to correlate a >> single client, in ways that just the access token would not. This is >> not a terribly common threat model in a highly centralized deployment >> where all RSes are fairly well trusted, of course, but there can be some >> environments where it is relevant, so it probably merits discussion. >> > > I have balked at adding any such discussion and will continue to do so > because there is likely so much correlateble info in an access token > already that the client has no control over and might well not even know > about. I don't know how to write what you're suggesting in a meaningful w= ay > and without giving the impression that using a different certificate > provides privacy benefits that are not really there. > > >> >> Section 9.2 >> >> This specification requests registration of the following value in >> >> nit: "values" plural >> > > Will fix and also found and will fix the same thing in 9.3 > > >> >> Section 10.2 >> >> I think that RFC 7517 needs to be normative, since we use the jwks >> containers for conveying certificate information. >> > > okay > > >> >> It also seems like RFCs 7591 and 8414 should probably be normative. >> > > I was on the fence with these two as i didn't think they are strictly > necessary but am happy to move them to normative. 7519 and 7662 probably > too. > > >> >> Traditionally we keep RFC 8174 as normative, as part of BCP 14 along >> with RFC 2119. >> > > I think I knew that but somehow got it wrong here. Will fix. > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b360f90590ac2663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I missed responding t= o this one part below about sec 7.2 and yet somehow remembered that I'd= missed it. Anyway, I feel like I had some seemingly legitimate reason for = mentioning (first) preimage when I wrote that text but I cannot recall what= that was and, on reading the text again with the benefit of your comment, = I think you are right. Second-preimage resistance is what we care about in = this context. I'll drop mention of regular preimage.
=C2=A0
Section 7.2

I'm not sure why we mention both (first) preimage and second-preimage resistance, as they're pretty different properties.=C2=A0 I suppose the= re
could be some registration scenarios where only the thumbprint is
provided and thus an attacker with a DB dump would not have the first
preimage in the form of the actual intended certificate, but even if
they could reconstruct that "real" preimage from the thumbprint t= hey
wouldn't have the corresponding private key.=C2=A0 So second-preimage probably covers what we need, and we can assume that the "first"<= br> preimage (certificate) is always available to the attacker.

=C2=A0


On Wed, Aug 21, 2019 at 3= :21 PM Brian Campbell <bca= mpbell@pingidentity.com> wrote:
Thanks Ben, I attempt (over th= e course of many hours) to respond to your comments and discuss your discus= s inline below.

On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datat= racker <noreply@ie= tf.org> wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-mtls-16: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake).=C2=A0 The authorization server and client=
can indicate their capabilities/preference via the RFC 8414 and RFC 7591 discovery and registration procedures, but I didn't see any discussion<= br> of how an AS might know a RS's capabilities, or how an RS might develop=
expectations of the capabilities of the clients accessing it.=C2=A0 A naive=
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators).=C2=A0 Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.

Is= there some text that you can propose?

Whethe= r or not to ask for or require MTLS and how to determine when is going to b= e a deployment decision of the RS. I don't think what you describe as t= he naive conclusion is all that naive at all. But maybe that just makes me = naive:) In implementations/deployments that I've seen thus far, a parti= cular RS decides (or is dictated by some policy) that its stuff is high val= ue enough that it needs cert-bound access tokens so it always sends a Certi= ficateRequest to the client during the TLS handshake. Such an RS that also = wants to allow access via non cert-bound access tokens might just let the T= LS connection proceed even if the client doesn't offer a certificate or= it might offer its stuff on a different host and/or port that is just regu= lar TLS. I don't want to preclude the use of renegotiation or post-hand= shake authentication but (other than some past pain with renegotiation) I&#= 39;m not really qualified to discuss or make recommendations about using th= em.
=C2=A0
Note also there is not something lik= e RFC 8414 and RFC 7591 for RSs and (for good reasons I think) the WG has b= alked at working on something like that. So the requirements/capabilities/p= references of an RS will need to be communicated or configured out-of-band.= And that's the case in general for RSs independent of this document. <= br>

(We may also want some additional text discussing error handling for the client/AS interaction, e.g., if a request shows up from a client-id that should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used the regular token endpoint and not the mtls endpoint alias (if they
differ).)

The end of sec 2 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2
=C2=A0says what to do in the case of a certificate mismatch in clie= nt auth:
=C2=A0=C2=A0 "If the presented certificate doe= sn't match that
=C2=A0 =C2=A0which is expected for the given "c= lient_id", the authorization server
=C2=A0 =C2=A0returns a normal O= Auth 2.0 error response per Section 5.2 of RFC6749
=C2=A0 =C2=A0[RFC6749= ] with the "invalid_client" error code to indicate failed
=C2= =A0 =C2=A0client authentication."

And my inte= nt and assumption was that a mismatch covered the case where no certificate= was presented (i.e. null cert doesn't match expected cert just as diff= erent cert doesn't match). But perhaps that particular case should be m= ade more explicit?=C2=A0 The second to last paragraph of sec 3 https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 ha= s similar guidance for error handing in the case of mismatch during resourc= e access.

The case of a so called public clie= nt that has tls_client_certificate_bound_access_tokens metadata of true tha= t shows up at the token endpoint without having done MTLS is a bit more nua= nced and I think it's untimely a policy decision for the AS at that poi= nt as to whether to error or issue an unbound token.

=C2=A0

(2) I can't validate the examples in Appendix A.

Specifically, my reading of the text would put the "x5t#S256" val= ue as
needing 86 characters, but only 43 are provided.=C2=A0 The ones there also = do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:

base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64<= br>
(Noting, of course, that 'base64' will be producing the non-URL-saf= e
variant, but expecting it to remain "pretty close".)

Here's a quick back of the napkin calculation t= hat gives 43 characters: SHA 256 produces a 256 bit output, which is 32 byt= es. Base64url encoding 32 bytes gives 43 bytes/characters of output (the ratio of output bytes to input bytes is 4:3 with ba= se64 encoding).

I am not *nix skilled enough = to troubleshoot that command pipeline but I suspect that the sha256sum outp= ut is in hex which represents each byte of the hash output with two charter= ers and thus double the resultant size.

I don= 't believe this particular example has been validated by other folks bu= t it was produced using code that has produced consistent results with othe= r implementers. Also it's code from an existing JOSE/JWT library (https:/= /bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing sup= port for the x5t / x5t#S256 parameters in JWS and JWK.

<= /div>
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).

That was intentional and meant to show that access token validation can ha= ppen locally (in the box) or by introspection call-out to the AS (the arrow= ). Maybe this could be done a bit differently, with I dunno sub items of C1= and C2 or something, that would be more clear?

=C2=A0

=C2=A0 =C2=A0(C)=C2=A0 The protected resource validates the access token in= order to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorize the request.=C2=A0 In some cases, suc= h as when the token is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 self-contained and cryptographically secured, t= he validation can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be done locally by the protected resource.=C2= =A0 While other cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 require that the protected resource call out to= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization server to determine the state of = the token and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 obtain meta-information about it.

nit: "While" is a conjunction but this last sentence only has one=
clause.

Will remove.
=C2= =A0

=C2=A0 =C2=A0Layering on the abstract flow above, this document standardize= s
=C2=A0 =C2=A0enhanced security options for OAuth 2.0 utilizing client certi= ficate
=C2=A0 =C2=A0based mutual TLS.=C2=A0 Section 2 provides options for authent= icating the

nit: "client-certificate-based" is hyphenated.

ok
=C2=A0

=C2=A0 =C2=A0request in step (A).=C2=A0 While step (C) is supported with se= mantics to
=C2=A0 =C2=A0express the binding of the token to the client certificate for= both
=C2=A0 =C2=A0local and remote processing in Section 3.1 and Section 3.2
=C2=A0 =C2=A0respectively.=C2=A0 This ensures that, as described in Section= 3,

nit: same thing about "while".

ok
=C2=A0

=C2=A0 =C2=A0protected resource access in step (B) is only possible by the<= br> =C2=A0 =C2=A0legitimate client bearing the access token and holding the pri= vate
=C2=A0 =C2=A0key corresponding to the certificate.

nit: I guess it is only protected resource access "using this tokwn&qu= ot;
that is only possible as specified.

I k= inda felt like that was implied at this point. But I can add "using th= is token" there, if you think it's needed or helpful?
=C2=A0

Section 1.2

We probably want to say something like "in addition to the normal TLS<= br> server authentication with a certificate" -- we need both for it to properly be "mutual" :)

ok
=C2=A0

Section 2.1

=C2=A0 =C2=A0The PKI (public key infrastructure) method of mutual TLS OAuth= client
=C2=A0 =C2=A0authentication adheres to the way in which X.509 certificates = are
=C2=A0 =C2=A0traditionally used for authentication.=C2=A0 It relies on a va= lidated
=C2=A0 =C2=A0certificate chain [RFC5280] and a single subject distinguished= name
=C2=A0 =C2=A0(DN) or a single subject alternative name (SAN) to authenticat= e the
=C2=A0 =C2=A0client.=C2=A0 Only one subject name value of any type is used = for each

I think we might be able to refer to RFC 6125 and call these the "CN-I= D"
and "DNS-ID".=C2=A0 That might also let us get out of doing quite= as much
referencing to RFC 4514 and specifying string representations "by hand= "...

=C2=A0RFC 6125 "Represen= tation and Verification of Domain-Based Application Service
=C2=A0Identi= ty within Internet Public Key Infrastructure Using X.509 (PKIX)
=C2=A0 = =C2=A0 =C2=A0Certificates in the Context of Transport Layer Security (TLS)&= quot; came up at one point but given that certificate usage in this draft a= ren't about Domain-Based Application Services I was unable to see the a= pplicable or how using it might help.

=C2=A0

I'm surprised to not see any discussion of trust anchor management or how to indicate (or decide) which CAs are to be trusted for this
purpose, even if that's just to acknowledge that it must be done but leave it up to deployments.

It's go= tta be done (unless using the self-singed method) and it is definitely up t= o deployments as I wouldn't even pretend to know where to begin on prov= iding general guidance nor would I think it appropriate.
I felt like this was pretty well implied and touched on in secu= rity considerations too. But please suggest some specific text, if you thin= k it's needed or would be useful.
=C2=A0
= =C2=A0
Section 2.1.2

Similarly the tls_client_auth_san_uri could be a URI-ID.

Similar to the above I'm really not seeing how or why= this would be done or useful.

=C2=A0

=C2=A0 =C2=A0tls_client_auth_san_ip
=C2=A0 =C2=A0 =C2=A0 A string representation of an IP address in either dot= ted decimal
=C2=A0 =C2=A0 =C2=A0 notation (for IPv4) or colon-delimited hexadecimal (fo= r IPv6, as
=C2=A0 =C2=A0 =C2=A0 defined in [RFC4291] section 2.2) that is expected to = be present
=C2=A0 =C2=A0 =C2=A0 as an iPAddress SAN entry in the certificate, which th= e OAuth
=C2=A0 =C2=A0 =C2=A0 client will use in mutual TLS authentication.

Do we want to note that this string representation differs from the
actual iPAddress encoding?=C2=A0 I guess by the time you go to actually
implement it, it's probably pretty obvious, though...
<= div>
I don't know, to be honest. The text in question cam= e as a suggestion from someone on the WG list and it seemed good enough to = me.=C2=A0 I sort of thought it would probably be pretty obvious too. Howeve= r the other IESG ballot positions have also had similar(ish) comments (see = https://mailarchive.ietf.org/arch/msg/oauth/Pbpy= gP8an-e80dDolo97Q5cBdd4 and https://mailarch= ive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so it seems so= mething more or different is needed with respect to this tls_client_auth_sa= n_ip thing. The suggestion from Suresh around RFC 5952 seems promising but = I need to look further into it than just reading the title. Which I'll = do. But also trying to be somewhat timely in responding to these reviews. <= br>

I've also never been able to think of a ca= se where tls_client_auth_san_ip is actually needed so maybe removing it all= together is an option as well.

=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">
Section 2.2.2

=C2=A0 =C2=A0For the Self-Signed Certificate method of binding a certificat= e with
=C2=A0 =C2=A0a client using mutual TLS client authentication, the existing<= br> =C2=A0 =C2=A0"jwks_uri" or "jwks" metadata parameters f= rom [RFC7591] are used to
=C2=A0 =C2=A0convey the client's certificates via JSON Web Key (JWK) in= a JWK Set
=C2=A0 =C2=A0(JWKS) [RFC7517].=C2=A0 The "jwks" metadata paramete= r is a JWK Set
=C2=A0 =C2=A0containing the client's public keys as an array of JWKs wh= ile the
=C2=A0 =C2=A0"jwks_uri" parameter is a URL that references a clie= nt's JWK Set.=C2=A0 A
=C2=A0 =C2=A0certificate is represented with the "x5c" parameter = of an individual
=C2=A0 =C2=A0JWK within the set.=C2=A0 Note that the members of the JWK rep= resenting

nit: "containing the client's public keys" is a bit of a juxt= aposition
with "represented with the "x5c" parameter" (which is c= ertificates).
True, the certificate does contain the public key, so it's not exactly<= br> wrong, but since we focus elsewhere on the certificate, it may not make
sense to focus on the public key here.

= That juxtaposition arises out of the way JWK is primarily about bare public= keys and certificates are an optional additional JSON member.
=C2=A0

Section 3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Binding the a= ccess token to the client certificate in
=C2=A0 =C2=A0that fashion has the benefit of decoupling that binding from t= he
=C2=A0 =C2=A0client's authentication with the authorization server, whi= ch enables
=C2=A0 =C2=A0mutual TLS during protected resource access to serve purely as= a
=C2=A0 =C2=A0proof-of-possession mechanism.=C2=A0 Other methods of associat= ing a

I don't think I understand what's meant about "decoupling that= binding
from the client's authentication with the authorization server" --= it
seems like the authorization server shouldn't issue a bound token
without some proof of possession, which the client's authentication
thereto performs.

What it is trying to = say is that the AS does what the AS does in terms of client auth including = dealing with trust anchors and what type of subject name or allowing for se= lf singed auth matching against explicitly configured certs. But, because t= he token is bound to the hash of the cert, the RS need not concern itself w= ith any of that and can treat the client TLS certificate as only a proof-of= -possession mechanism for using the access token. Does that help your under= standing or just confuse things further?
=C2=A0

=C2=A0 =C2=A0The protected resource MUST obtain, from its TLS implementatio= n
=C2=A0 =C2=A0layer, the client certificate used for mutual TLS and MUST ver= ify
=C2=A0 =C2=A0that the certificate matches the certificate associated with t= he
=C2=A0 =C2=A0access token.=C2=A0 If they do not match, the resource access = attempt MUST

How does the resource server know it needs to do this?=C2=A0 Is this just configured as part of the ability to do mutual TLS, or indiated by a
token type, or something else?

Configur= ed and/or based on the presence of the cnf claim with x5t#S256 method in th= e access token.

=C2=A0

Section 3.1

Per BCP 201, we may want to say something about this recommendation
changing over time as cryptographic algorithm preferences change.=C2=A0 RFC=
7525 has a decent note to this effect:

=C2=A0 =C2=A0Community knowledge about the strength of various algorithms a= nd
=C2=A0 =C2=A0feasible attacks can change quickly, and experience shows that= a Best
=C2=A0 =C2=A0Current Practice (BCP) document about security is a point-in-t= ime
=C2=A0 =C2=A0statement.=C2=A0 Readers are advised to seek out any errata or= updates
=C2=A0 =C2=A0that apply to this document.

(obviously the "BCP" part doesn't apply to this document, but= most of
the rest should.)=C2=A0 This could of course be coordinated between here an= d
Section 7.2.

Makes sense. I'll inco= rporate some text borrowed from 7525 in 3.1 and/or 7.2.
=C2= =A0

There's only 43 characters of base64 in the "x5t#S256" exampl= e; for
SHA-256 output shouldn't there be 86?

see previous explanation of why 43 seems right based on my math and code=
=C2=A0

Section 3.2

(Same comment about the length of base64 in the example, in Figure 3.)
<= /blockquote>

same same
=C2=A0

Section 3.3

We should probably reference RFC 8414 (at least) the first time we talk
about authorizaiton server metadata parameters.

Yeah, that's an oversight on my part. Will fix.
=C2=A0

Section 3.4

Similarly, we could reference RFC 7591 here.

RFC 7591 has been referenced several times already at this point.

=C2=A0

Section 5

=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=A0Note
=C2=A0 =C2=A0that the endpoints in "mtls_endpoint_aliases" use a = different host
=C2=A0 =C2=A0than their conventional counterparts, which allows the authori= zation
=C2=A0 =C2=A0server (via SNI or actual distinct hosts) to differentiate its= TLS
=C2=A0 =C2=A0behavior as appropriate.

nit: Sadly, "SNI" does not appear in
https://www.rfc-editor.org/materials/abbr= ev.expansion.txt as a
"well-known" abbreviation, so we probably have to say 'TLS &q= uot;server_name"
extension [RFC 6066]' or similar.

S= hoot, okay. Will do.
=C2=A0

Section 6.1

=C2=A0 =C2=A0In order to support the Self-Signed Certificate method, the =C2=A0 =C2=A0authorization server would configure the TLS stack in such a w= ay that
=C2=A0 =C2=A0it does not verify whether the certificate presented by the cl= ient
=C2=A0 =C2=A0during the handshake is signed by a trusted CA certificate.
This statement doesn't quite follow -- *support*ing self-signed
certificates only requires that you configure TLS to not require a valid client cert+chain for the handshake to succeed, but it can still try to
validate such a chain.=C2=A0 This would be useful if, for example, you
intended to support both self-signed and CA-signed certificates.
We may also want a specific note to implementors to check validation
results for certificates intended to be CA-signed, if we're going to include a note about disabling validation for self-signed cert usage.

I take your point but the text (which I did = not write FWIW) was meant to be practical guidance based on an understandin= g of how the most common web servers work (problem in chain validation term= inates the handshake) and the options they provide (can turn off cert chain= validating) and what they surface about the handshake results (AFAIK not t= he kind of info that would allow the distinction you mention so the whole p= rocess of chain validation would maybe have to be deferred to the applicati= on layer). I can try and add or amend some text along the lines of your com= ment. But I worry I'd do more harm than good in doing so.

=C2=A0
Section 6.2

Would there be any scenario in which "additional security" might = be
gained from having the RS check that the client-presented cert does
chain to a trusted CA?

I'm sure the= re is some such scenario out there. But this is meant as implementation con= siderations or guidance for the general or common cases.
=C2= =A0

Section 6.3

Isn't this ignoring the elephant in the room about what to do when the<= br> refresh token is also bound to the (expiring) client certificate?


Section 6.5

There are a couple of active proposals for new, secure, protocols from
load balancer to backend server, but probably not anything quite mature
enough to be worth referencing from here.
(e.g., draft-schwartz-tls-lb and another one that I think was presented
in QUIC but I can't find right now)

Section 7

We could potentially also talk about how the use of jwks_uri requires
a fairly strong level of trust in the service at the target of the URI:
the client has to trust it to faithfully provide the certification
information, and the RS has to trust it to provide valid data for the
client in question, as well as the usual trust in the TLS connection
that identifies it, etc.


Section 7.1

=C2=A0 =C2=A0The OAuth 2.0 Authorization Framework [RFC6749] requires that = an
=C2=A0 =C2=A0authorization server bind refresh tokens to the client to whic= h they
=C2=A0 =C2=A0were issued and that confidential clients (those having establ= ished
=C2=A0 =C2=A0authentication credentials with the authorization server)
=C2=A0 =C2=A0authenticate to the AS when presenting a refresh token.=C2=A0 = As a result,
=C2=A0 =C2=A0refresh tokens are indirectly certificate-bound when issued to=
=C2=A0 =C2=A0clients utilizing the "tls_client_auth" or
=C2=A0 =C2=A0"self_signed_tls_client_auth" methods of client auth= entication.

nit(?): is this "indirectly" or "implicitly" bound?
=


Section 7.2

I'm not sure why we mention both (first) preimage and second-preimage resistance, as they're pretty different properties.=C2=A0 I suppose the= re
could be some registration scenarios where only the thumbprint is
provided and thus an attacker with a DB dump would not have the first
preimage in the form of the actual intended certificate, but even if
they could reconstruct that "real" preimage from the thumbprint t= hey
wouldn't have the corresponding private key.=C2=A0 So second-preimage probably covers what we need, and we can assume that the "first"<= br> preimage (certificate) is always available to the attacker.

Section 7.4

Maybe we should say "agree out of band" on the set of trust ancho= rs.


Section 7.5

=C2=A0 =C2=A0o=C2=A0 handling of null-terminator bytes and non-canonical st= ring
=C2=A0 =C2=A0 =C2=A0 representations in subject names;

ASN.1 encodings are going to be using counted strings, so any
NUL terminators will be in implementation languages.=C2=A0 I think we might=
want to reword this to indicate that ASN.1 strings cannot be directly
interpreted as native language strings in languages that use NUL
terminators.

I am not equipped with the= knowledge to do that rewording. Please suggest some specific text, if you&= #39;d like to have it reworded.=C2=A0
=C2=A0

=C2=A0 =C2=A0o=C2=A0 handling of wildcard patterns in subject names;

Interestingly, RFC 5280 punts on the semantics of wildcard characters in SANs, though I think many applications will insist on only a single
wildcard and the leftmost label being just the single wildcard
character.

Also there is no allowance a= nywhere in this draft for using wildcards in subject names for the client c= ertificate. This whole section came as a suggestion doing WGLC that was tak= en to get through WGLC. But it's not entirely contextually relevant. Th= is bullet in particular. Maybe it'd be better to remove it?
=C2=A0

Section 8

There's perhaps some additional considerations if a client uses the sam= e
certificate across multiple RSes, in that the client certificate
provides an additional mechanism for collaborating RSes to correlate a
single client, in ways that just the access token would not.=C2=A0 This is<= br> not a terribly common threat model in a highly centralized deployment
where all RSes are fairly well trusted, of course, but there can be some environments where it is relevant, so it probably merits discussion.

I have balked at adding any such discussion a= nd will continue to do so because there is likely so much correlateble info= in an access token already that the client has no control over and might w= ell not even know about. I don't know how to write what you're sugg= esting in a meaningful way and without giving the impression that using a d= ifferent certificate provides privacy benefits that are not really there. = =C2=A0
=C2=A0

Section 9.2

=C2=A0 =C2=A0This specification requests registration of the following valu= e in

nit: "values" plural

Will fix= and also found and will fix the same thing in 9.3
=C2=A0

Section 10.2

I think that RFC 7517 needs to be normative, since we use the jwks
containers for conveying certificate information.

=
okay
=C2=A0

It also seems like RFCs 7591 and 8414 should probably be normative.

I was on the fence with these two as i didn= 9;t think they are strictly necessary but am happy to move them to normativ= e. 7519 and 7662 probably too.
=C2=A0

Traditionally we keep RFC 8174 as normative, as part of BCP 14 along
with RFC 2119.

I think I knew that but = somehow got it wrong here. Will fix.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b360f90590ac2663-- From nobody Thu Aug 22 15:49:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C568120099 for ; Thu, 22 Aug 2019 15:49:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MY9UugJ2iX0K for ; Thu, 22 Aug 2019 15:49:20 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 068A0120091 for ; Thu, 22 Aug 2019 15:49:20 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b10so6526069ioj.2 for ; Thu, 22 Aug 2019 15:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j6VsLE+ywPRjE7dnZ16bKs84pNEmFFRvnAwuj9xJMZs=; b=mkuNoOFeV6ZTN/a9Tp0Q/9tYIGrcRKp0h61c22ba854SZigy1uZDCDA9mKnH5R/eH4 Ar0HRvGn1APPKv93Hu5kBeRRB65ezUrTOsj1fAApKZ5ZdvhzfIylHNFXHv81QITroFPP AbfVIhms/Z3xFtlR+4BrtmsqNyakY4XKerAZ0= 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=j6VsLE+ywPRjE7dnZ16bKs84pNEmFFRvnAwuj9xJMZs=; b=hwcg60F4C+cnlsjpXoBxDqOQdowoVQIunB/NlPE239elM7uEdGKFc7n0wdEDuE5PRV WL8L43zUWlGMemofmo4JIMDRBZ08EG5G+4d16WykLD21KufzYRVGSLEgUECR1ib1Cski 1AwyTCAc/Da+8YBwaqL4E+FhXtyJL7XRQQMJUlhBKJb0rpFJNXa2/qvooNUhDzJdlXpq R8aESanDw0BBulClmipWNqeQak+8eW630Blbi4dyRRu+1JpAaVofbqvv6fnWgQECGpKC 19fduRSC9PWUDK/mjzZooScdr+KE7ssUhubHAc0xAyLqTYS0tNr0Nn8BjhAei6qPfboT sn0w== X-Gm-Message-State: APjAAAVulTdydWSPBKuGuYiK8tF34SVB9VxXvYl9LH4qh9kcAU2X95qY tv1GGSSpNbdPpv0kwenWLsbj4ltGUcGrhu7xkj5z38r/+TjkC/WyU4e67b6D447zZVrsTgP3Zqd W7EXir5bTBPiWGjuUZJk= X-Google-Smtp-Source: APXvYqxs/seAM/XBOIUHVOyJzj8Q51Y3Gd2zKCExChXbWSzoLpbeL/EgKp7eX22mBoU4bEbt6c/Ji0RP0/M5qKH7aRw= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr1535051ioc.115.1566514159226; Thu, 22 Aug 2019 15:49:19 -0700 (PDT) MIME-Version: 1.0 References: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Thu, 22 Aug 2019 16:48:53 -0600 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ff2c360590bc7f40" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 22:49:23 -0000 --000000000000ff2c360590bc7f40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the comment on tls_client_auth_san_ip, some other reviewers have suggested using the using the IPv6 Address Text Representation described in RFC 5952 rather than the one from in RFC 4291. Which I think makes sense to do. Maybe also with a note that the comparison of the addresses should done using binary as suggested in https://tools.ietf.org/html/rfc5952#section-8 What do you think? On Wed, Aug 21, 2019 at 4:07 PM Brian Campbell wrote: > Thanks Adam, I attempt to provide not-too-terrible replies to your > comments inline below. > > On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatracker < > noreply@ietf.org> wrote: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Thanks for the work that everyone did on this document. I have one >> suggestion >> for clarification, followed by a handful of editorial nits. >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A72.1.2: >> >> > tls_client_auth_san_ip >> > A string representation of an IP address in either dotted decimal >> > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as >> > defined in [RFC4291] section 2.2) that is expected to be present >> > as an iPAddress SAN entry in the certificate, which the OAuth >> > client will use in mutual TLS authentication. >> >> This probably needs some text that clarifies expectations around >> comparison >> and/or normalization. For example, if the iPAddress value in the cert is >> "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all >> F's), one >> should presume that this would match both tls_client_auth_san_ip values >> "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, >> then >> this document needs to talk about normalization of address representatio= n. >> > > Can you help me with some text here? I'm a bit out of my realm, to be > honest. I naively just want it to say that the tls_client_auth_san_ip val= ue > and iPAddress value in the cert need to be the same IP address. But I do > realize "same" isn't totally clear as your comment and others have pointe= d > out. But I don't know enough to know how to write it in a way that's > suitable for this kind of thing. > > Alternatively, as I mentioned in my response to Ben (down a ways in > https://mailarchive.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ), > I've never personally been able to think of a situation where > tls_client_auth_san_ip is actually needed. So maybe removing it all > together is an option as well? > > > >> >> ------------------------------------------------------------------------= --- >> >> =C2=A71: >> >> > Layering on the abstract flow above, this document standardizes >> > enhanced security options for OAuth 2.0 utilizing client certificate >> > based mutual TLS. >> >> Nit: "client-certificate-based" >> > > Mr. Kaduk beat you to this one. Will fix. > > > > OAuth 2.0 defines a shared secret method of client authentication but >> >> Nit: "shared-secret" >> > > Will fix. > > >> >> >> ------------------------------------------------------------------------= --- >> =C2=A71: >> >> > This document describes an additional >> > mechanism of client authentication utilizing mutual TLS certificate- >> > based authentication >> >> Nit: "mutual-TLS" >> >> > Mutual TLS certificate-bound access tokens ensure that only the party >> >> Nit: "Mutual-TLS" >> >> > Mutual TLS certificate-bound access tokens and mutual TLS client >> >> Nit: "Mutual-TLS... mutual-TLS" >> >> > Additional client metadata parameters are introduced by this document >> > in support of certificate-bound access tokens and mutual TLS client >> > authentication. >> >> Nit: "mutual-TLS" >> >> The remainder of the document has several other uses of the phrase "mutu= al >> TLS" as an adjective; they should be similarly hyphenated. I will not ca= ll >> them out individually. (Non-adjectival uses should not contain hyphens, = so >> this isn't a simple find-and-replace operation.) >> > > Understood. In theory anyway. I'll take a pass thought the whole documen= t > and endeavor to find and hyphenate all the places that "mutual TLS" is us= ed > as an adjective. > > > >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A75: >> >> > Authorization servers supporting both clients using mutual TLS and >> > conventional clients MAY chose to isolate the server side mutual TLS >> > behaviour to only clients intending to do mutual TLS, thus avoiding >> >> Nit: "behavior" (or adjust other spellings in the document to be >> consistently >> British). >> > > Ugh. I'm surprised my jingoistic spellcheck didn't flag that one. Will > fix. > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ff2c360590bc7f40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
On Wed, Au= g 21, 2019 at 4:07 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
=
Thanks Adam, I attempt to provide not-too-terrible replies to your comme= nts inline below.

On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatr= acker <noreply@iet= f.org> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for the work that everyone did on this document. I have one suggesti= on
for clarification, followed by a handful of editorial nits.

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

=C2=A72.1.2:

>=C2=A0 tls_client_auth_san_ip
>=C2=A0 =C2=A0 =C2=A0A string representation of an IP address in either = dotted decimal
>=C2=A0 =C2=A0 =C2=A0notation (for IPv4) or colon-delimited hexadecimal = (for IPv6, as
>=C2=A0 =C2=A0 =C2=A0defined in [RFC4291] section 2.2) that is expected = to be present
>=C2=A0 =C2=A0 =C2=A0as an iPAddress SAN entry in the certificate, which= the OAuth
>=C2=A0 =C2=A0 =C2=A0client will use in mutual TLS authentication.

This probably needs some text that clarifies expectations around comparison=
and/or normalization. For example, if the iPAddress value in the cert is "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of = all F's), one
should presume that this would match both tls_client_auth_san_ip values
"2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202"= , right? If no, then
this document needs to talk about normalization of address representation.<= br>

Can you help me with some text here? I&= #39;m a bit out of my realm, to be honest. I naively just want it to say th= at the tls_client_auth_san_ip value and iPAddress value in the cert need to= be the same IP address. But I do realize "same" isn't totall= y clear as your comment and others have pointed out. But I don't know e= nough to know how to write it in a way that's suitable for this kind of= thing.

Alternatively, as I mentioned in my r= esponse to Ben (down a ways in https://mailarchi= ve.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ), I've never= personally been able to think of a situation where tls_client_auth_san_ip = is actually needed.=C2=A0 So maybe removing it all together is an option as= well?

=C2=A0
---------------------------------------------------------------------------=

=C2=A71:

>=C2=A0 Layering on the abstract flow above, this document standardizes<= br> >=C2=A0 enhanced security options for OAuth 2.0 utilizing client certifi= cate
>=C2=A0 based mutual TLS.

Nit: "client-certificate-based"

Mr. Kaduk beat you to this one. Will fix.
=C2=A0

>=C2=A0 OAuth 2.0 defines a shared secret method of client authenticatio= n but

Nit: "shared-secret"

Will fix= .
=C2=A0

---------------------------------------------------------------------------=
=C2=A71:

>=C2=A0 This document describes an additional
>=C2=A0 mechanism of client authentication utilizing mutual TLS certific= ate-
>=C2=A0 based authentication

Nit: "mutual-TLS"

>=C2=A0 Mutual TLS certificate-bound access tokens ensure that only the = party

Nit: "Mutual-TLS"

>=C2=A0 Mutual TLS certificate-bound access tokens and mutual TLS client=

Nit: "Mutual-TLS... mutual-TLS"

>=C2=A0 Additional client metadata parameters are introduced by this doc= ument
>=C2=A0 in support of certificate-bound access tokens and mutual TLS cli= ent
>=C2=A0 authentication.

Nit: "mutual-TLS"

The remainder of the document has several other uses of the phrase "mu= tual
TLS" as an adjective; they should be similarly hyphenated. I will not = call
them out individually. (Non-adjectival uses should not contain hyphens, so<= br> this isn't a simple find-and-replace operation.)
<= br>
Understood. In theory anyway.=C2=A0 I'll take a pass thou= ght the whole document and endeavor to find and hyphenate all the places th= at "mutual TLS" is used as an adjective.

=C2=A0

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

=C2=A75:

>=C2=A0 Authorization servers supporting both clients using mutual TLS a= nd
>=C2=A0 conventional clients MAY chose to isolate the server side mutual= TLS
>=C2=A0 behaviour to only clients intending to do mutual TLS, thus avoid= ing

Nit: "behavior" (or adjust other spellings in the document to be = consistently
British).

=C2=A0Ugh. I'm surprised = my jingoistic spellcheck didn't flag that one. Will fix.

<= 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. --000000000000ff2c360590bc7f40-- From nobody Thu Aug 22 16:03:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63C5120091; Thu, 22 Aug 2019 16:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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=nostrum.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 26S3Tk1m1BUD; Thu, 22 Aug 2019 16:02:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 86D88120089; Thu, 22 Aug 2019 16:02:53 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7MN2k2d019642 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Aug 2019 18:02:48 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566514971; bh=6hv0eyQJHWDEMm/43NQRiurmVK4/bBMjbLbzD3aeGvA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=bKvCMnxXiYGHoB10a8ezFQDnOdenewrRwTBt1Qkg88tHBqCG7AlP1CZyeq5XqxhY/ mUrGgh4rgcSkpGUW/F2hZPFhr+lXirzKtGC4pXIzJjZG/WJAPyCYDTzxFVtj24yEz+ EJdtdhcpQRJ4X7vaP3Zr0WfaXx1AfDOwtLlJF42k= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Brian Campbell Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org References: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 22 Aug 2019 18:02:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 23:02:55 -0000 On 8/22/19 5:48 PM, Brian Campbell wrote: > Regarding the comment on tls_client_auth_san_ip, some other reviewers > have suggested using the using the IPv6 Address Text Representation > described in RFC 5952 rather than the one from in RFC 4291. Which I > think makes sense to do. Maybe also with a note that the comparison of > the addresses should done using binary as suggested in > https://tools.ietf.org/html/rfc5952#section-8 > > What do you think? That sounds like a fine approach. Thanks for digging that reference up. :) /a From nobody Thu Aug 22 16:17:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204B7120091; Thu, 22 Aug 2019 16:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT5Jk10o1F_b; Thu, 22 Aug 2019 16:17:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24395120089; Thu, 22 Aug 2019 16:17:00 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7MNGtgZ012462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 19:16:58 -0400 Date: Thu, 22 Aug 2019 18:16:55 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Message-ID: <20190822231654.GS60855@kduck.mit.edu> References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 23:17:05 -0000 On Wed, Aug 21, 2019 at 03:21:23PM -0600, Brian Campbell wrote: > Thanks Ben, I attempt (over the course of many hours) to respond to your > comments and discuss your discuss inline below. > > On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-mtls-16: Discuss > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (1) I think that we need some text that covers how the resource server > > will know to use mtls (and thus, to send a CertificateRequest to the > > client during the TLS handshake). The authorization server and client > > can indicate their capabilities/preference via the RFC 8414 and RFC 7591 > > discovery and registration procedures, but I didn't see any discussion > > of how an AS might know a RS's capabilities, or how an RS might develop > > expectations of the capabilities of the clients accessing it. A naive > > conclusion might be that any given RS (hostname+port) would have to > > either always or never use mtls, given the misordering between TLS > > handshake completion and delivery of TLS application data (i.e., > > including the oauth token), though there may be refinements available in > > the form of the unpopular TLS 1.2 renegotiation or TLS 1.3 > > post-handshake authentication (or exported authenticators). Doing > > either of those in an environment with TLS Termination per Section 6.5 > > may entail additional complications. > > > > Is there some text that you can propose? > > Whether or not to ask for or require MTLS and how to determine when is > going to be a deployment decision of the RS. I don't think what you > describe as the naive conclusion is all that naive at all. But maybe that Well, I think it was naive when I wrote it, because I didn't think very hard. But it's possible to be naive and be correct at the same time... > just makes me naive:) In implementations/deployments that I've seen thus > far, a particular RS decides (or is dictated by some policy) that its stuff > is high value enough that it needs cert-bound access tokens so it always > sends a CertificateRequest to the client during the TLS handshake. Such an > RS that also wants to allow access via non cert-bound access tokens might > just let the TLS connection proceed even if the client doesn't offer a > certificate or it might offer its stuff on a different host and/or port > that is just regular TLS. I don't want to preclude the use of renegotiation > or post-handshake authentication but (other than some past pain with > renegotiation) I'm not really qualified to discuss or make recommendations > about using them. > > Note also there is not something like RFC 8414 and RFC 7591 for RSs and > (for good reasons I think) the WG has balked at working on something like > that. So the requirements/capabilities/preferences of an RS will need to be > communicated or configured out-of-band. And that's the case in general for > RSs independent of this document. Sure, and I don't really see that changing anytime soon. In terms of proposed text, it looks like after the first paragraph of Section 3 would be a reasonable place, perhaps: In order for a resource server to use certificate-bound access tokens, it must have advance knowledge that mtls is to be used for some or all resource accesses. In particular, the client ID or access token itself cannot be used as input to the decision of whether or not to use mtls, since from the TLS perspective those are "Application Data", only exchanged after the TLS handshake has been completed, and the initial CertificateRequest occurs during the handshake, before the Application Data is available. Although subsequent opportunities for a TLS client to present a certificate may be available, e.g., via TLS 1.2 renegotiation [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document makes no provision for their usage. It is expected to be common that a mtls-using resource server will require mtls for all resources hosted thereupon, or will serve mtls-protected and regular resources on separate hostname+port combinations, though other workflows are possible. How resource server policy is synchronized with the AS is out of scope for this document. And then the following paragraph could start "Within the scope of an mtls-protected resource-access flow," > (We may also want some additional text discussing error handling for the > > client/AS interaction, e.g., if a request shows up from a client-id that > > should be using mtls but did not provide a certificate in the TLS > > handshake, but that is only debatably something that rises to > > Discuss-level; or if a client that advertised an intent to use MTLS used > > the regular token endpoint and not the mtls endpoint alias (if they > > differ).) > > > > The end of sec 2 > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2 > says what to do in the case of a certificate mismatch in client auth: > "If the presented certificate doesn't match that > which is expected for the given "client_id", the authorization server > returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749 > [RFC6749] with the "invalid_client" error code to indicate failed > client authentication." > > And my intent and assumption was that a mismatch covered the case where no > certificate was presented (i.e. null cert doesn't match expected cert just > as different cert doesn't match). But perhaps that particular case should > be made more explicit? The second to last paragraph of sec 3 It probably should; "if the presented certificate" as a predicate could fairly be easily read as to ignore the case where no certificate is presented. > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar > guidance for error handing in the case of mismatch during resource access. > > The case of a so called public client that has > tls_client_certificate_bound_access_tokens metadata of true that shows up > at the token endpoint without having done MTLS is a bit more nuanced and I > think it's untimely a policy decision for the AS at that point as to > whether to error or issue an unbound token. Do you have any feelings about whether or not you want to mention that case explicitly as being up to local policy at the AS (vs. leaving it implicit as is presently being done)? > > > > > > (2) I can't validate the examples in Appendix A. > > > > Specifically, my reading of the text would put the "x5t#S256" value as > > needing 86 characters, but only 43 are provided. The ones there also do > > not seem to be a prefix of the result that I get from taking the PEM > > certificate contents and running them through the pipeline: > > > > base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64 > > > > (Noting, of course, that 'base64' will be producing the non-URL-safe > > variant, but expecting it to remain "pretty close".) > > > > Here's a quick back of the napkin calculation that gives 43 characters: SHA > 256 produces a 256 bit output, which is 32 bytes. Base64url encoding 32 > bytes gives 43 bytes/characters of output (the ratio of output bytes to > input bytes is 4:3 with base64 encoding). > > I am not *nix skilled enough to troubleshoot that command pipeline but I > suspect that the sha256sum output is in hex which represents each byte of > the hash output with two charterers and thus double the resultant size. Please excuse me while I wipe the egg off my face. Yes, that sha256sum output is in hex, and I should have counted the bits directly. I hope you did not waste too much time on this (and now I can get the thumbprint to agree). > I don't believe this particular example has been validated by other folks > but it was produced using code that has produced consistent results with > other implementers. Also it's code from an existing JOSE/JWT library ( > https://bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing > support for the x5t / x5t#S256 parameters in JWS and JWK. Thanks for the heads-up about how the example was generated; it's reassuring. > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > nit: in Figure 1, the (C) label is applied to both an arrow and a box > > (the other two boxes are not labelled). > > > > That was intentional and meant to show that access token validation can > happen locally (in the box) or by introspection call-out to the AS (the > arrow). Maybe this could be done a bit differently, with I dunno sub items > of C1 and C2 or something, that would be more clear? Hmm. With the explanation, it makes sense. It's possible that C1/C2 might be more clear, though, but don't feel obligated to do that. > > > > > > (C) The protected resource validates the access token in order to > > authorize the request. In some cases, such as when the token is > > self-contained and cryptographically secured, the validation can > > be done locally by the protected resource. While other cases > > require that the protected resource call out to the > > authorization server to determine the state of the token and > > obtain meta-information about it. > > > > nit: "While" is a conjunction but this last sentence only has one > > clause. > > > > Will remove. > > > > > > Layering on the abstract flow above, this document standardizes > > enhanced security options for OAuth 2.0 utilizing client certificate > > based mutual TLS. Section 2 provides options for authenticating the > > > > nit: "client-certificate-based" is hyphenated. > > > > ok > > > > > > request in step (A). While step (C) is supported with semantics to > > express the binding of the token to the client certificate for both > > local and remote processing in Section 3.1 and Section 3.2 > > respectively. This ensures that, as described in Section 3, > > > > nit: same thing about "while". > > > > ok > > > > > > protected resource access in step (B) is only possible by the > > legitimate client bearing the access token and holding the private > > key corresponding to the certificate. > > > > nit: I guess it is only protected resource access "using this tokwn" > > that is only possible as specified. > > > > I kinda felt like that was implied at this point. But I can add "using this > token" there, if you think it's needed or helpful? Or perhaps "using a certificate-bound token". I think it's just barely worth adding, since this section is largely reiterating the general OAuth flow, and this helps emphasize that the "and holding the private key" is the important/new part. > > > > > Section 1.2 > > > > We probably want to say something like "in addition to the normal TLS > > server authentication with a certificate" -- we need both for it to > > properly be "mutual" :) > > > > ok > > > > > > Section 2.1 > > > > The PKI (public key infrastructure) method of mutual TLS OAuth client > > authentication adheres to the way in which X.509 certificates are > > traditionally used for authentication. It relies on a validated > > certificate chain [RFC5280] and a single subject distinguished name > > (DN) or a single subject alternative name (SAN) to authenticate the > > client. Only one subject name value of any type is used for each > > > > I think we might be able to refer to RFC 6125 and call these the "CN-ID" > > and "DNS-ID". That might also let us get out of doing quite as much > > referencing to RFC 4514 and specifying string representations "by hand"... > > > > RFC 6125 "Representation and Verification of Domain-Based Application > Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS)" came up > at one point but given that certificate usage in this draft aren't about > Domain-Based Application Services I was unable to see the applicable or how > using it might help. Okay, if it was already considered and rejected I don't want to rehash old ground. > > > > > > I'm surprised to not see any discussion of trust anchor management or > > how to indicate (or decide) which CAs are to be trusted for this > > purpose, even if that's just to acknowledge that it must be done but > > leave it up to deployments. > > > > It's gotta be done (unless using the self-singed method) and it is > definitely up to deployments as I wouldn't even pretend to know where to > begin on providing general guidance nor would I think it appropriate. > > I felt like this was pretty well implied and touched on in security > considerations too. But please suggest some specific text, if you think > it's needed or would be useful. Maybe a couple lines at the end of Section 7.3, "TLS certificate validation (for both client and server certificates) requires a local database of trusted certificate authorities (CAs). Decisions about what CAs to trust and how to make such a determination of trust are out of scope for this document, but such policy must be consistent between AS and RS for reliable operation."? > > > > Section 2.1.2 > > > > Similarly the tls_client_auth_san_uri could be a URI-ID. > > > > Similar to the above I'm really not seeing how or why this would be done or > useful. > > > > > > > tls_client_auth_san_ip > > A string representation of an IP address in either dotted decimal > > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as > > defined in [RFC4291] section 2.2) that is expected to be present > > as an iPAddress SAN entry in the certificate, which the OAuth > > client will use in mutual TLS authentication. > > > > Do we want to note that this string representation differs from the > > actual iPAddress encoding? I guess by the time you go to actually > > implement it, it's probably pretty obvious, though... > > > > I don't know, to be honest. The text in question came as a suggestion from > someone on the WG list and it seemed good enough to me. I sort of thought > it would probably be pretty obvious too. However the other IESG ballot > positions have also had similar(ish) comments (see > https://mailarchive.ietf.org/arch/msg/oauth/PbpygP8an-e80dDolo97Q5cBdd4 and > https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so > it seems something more or different is needed with respect to this > tls_client_auth_san_ip thing. The suggestion from Suresh around RFC 5952 > seems promising but I need to look further into it than just reading the > title. Which I'll do. But also trying to be somewhat timely in responding > to these reviews. > > I've also never been able to think of a case where tls_client_auth_san_ip > is actually needed so maybe removing it all together is an option as well. That all sounds reasonable to me; I'm happy to leave this topic to the other ballot threads (or remove the option entirely). > > > > > > Section 2.2.2 > > > > For the Self-Signed Certificate method of binding a certificate with > > a client using mutual TLS client authentication, the existing > > "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to > > convey the client's certificates via JSON Web Key (JWK) in a JWK Set > > (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set > > containing the client's public keys as an array of JWKs while the > > "jwks_uri" parameter is a URL that references a client's JWK Set. A > > certificate is represented with the "x5c" parameter of an individual > > JWK within the set. Note that the members of the JWK representing > > > > nit: "containing the client's public keys" is a bit of a juxtaposition > > with "represented with the "x5c" parameter" (which is certificates). > > True, the certificate does contain the public key, so it's not exactly > > wrong, but since we focus elsewhere on the certificate, it may not make > > sense to focus on the public key here. > > > > That juxtaposition arises out of the way JWK is primarily about bare public > keys and certificates are an optional additional JSON member. > > > > > > Section 3 > > > > Binding the access token to the client certificate in > > that fashion has the benefit of decoupling that binding from the > > client's authentication with the authorization server, which enables > > mutual TLS during protected resource access to serve purely as a > > proof-of-possession mechanism. Other methods of associating a > > > > I don't think I understand what's meant about "decoupling that binding > > from the client's authentication with the authorization server" -- it > > seems like the authorization server shouldn't issue a bound token > > without some proof of possession, which the client's authentication > > thereto performs. > > > > What it is trying to say is that the AS does what the AS does in terms of > client auth including dealing with trust anchors and what type of subject > name or allowing for self singed auth matching against explicitly > configured certs. But, because the token is bound to the hash of the cert, > the RS need not concern itself with any of that and can treat the client > TLS certificate as only a proof-of-possession mechanism for using the > access token. Does that help your understanding or just confuse things > further? I think it helps my understanding, thanks. Perhaps it is the RS's verification of proof-of-possession that is decoupled from the client's authentication to the AS, then? > > > > > The protected resource MUST obtain, from its TLS implementation > > layer, the client certificate used for mutual TLS and MUST verify > > that the certificate matches the certificate associated with the > > access token. If they do not match, the resource access attempt MUST > > > > How does the resource server know it needs to do this? Is this just > > configured as part of the ability to do mutual TLS, or indiated by a > > token type, or something else? > > > > Configured and/or based on the presence of the cnf claim with x5t#S256 > method in the access token. Okay. (I think this may have been the part of my notes that was a precursor to the Discuss point; sorry if it was underdeveloped or unclear.) > > > > > > Section 3.1 > > > > Per BCP 201, we may want to say something about this recommendation > > changing over time as cryptographic algorithm preferences change. RFC > > 7525 has a decent note to this effect: > > > > Community knowledge about the strength of various algorithms and > > feasible attacks can change quickly, and experience shows that a Best > > Current Practice (BCP) document about security is a point-in-time > > statement. Readers are advised to seek out any errata or updates > > that apply to this document. > > > > (obviously the "BCP" part doesn't apply to this document, but most of > > the rest should.) This could of course be coordinated between here and > > Section 7.2. > > > > Makes sense. I'll incorporate some text borrowed from 7525 in 3.1 and/or > 7.2. > > > > > > There's only 43 characters of base64 in the "x5t#S256" example; for > > SHA-256 output shouldn't there be 86? > > > > see previous explanation of why 43 seems right based on my math and code > > > > > > Section 3.2 > > > > (Same comment about the length of base64 in the example, in Figure 3.) > > > > same same > > > > > > Section 3.3 > > > > We should probably reference RFC 8414 (at least) the first time we talk > > about authorizaiton server metadata parameters. > > > > Yeah, that's an oversight on my part. Will fix. > > > > > > Section 3.4 > > > > Similarly, we could reference RFC 7591 here. > > > > RFC 7591 has been referenced several times already at this point. Okay. > > > > Section 5 > > > > Note > > that the endpoints in "mtls_endpoint_aliases" use a different host > > than their conventional counterparts, which allows the authorization > > server (via SNI or actual distinct hosts) to differentiate its TLS > > behavior as appropriate. > > > > nit: Sadly, "SNI" does not appear in > > https://www.rfc-editor.org/materials/abbrev.expansion.txt as a > > "well-known" abbreviation, so we probably have to say 'TLS "server_name" > > extension [RFC 6066]' or similar. > > > > Shoot, okay. Will do. Thanks. Though I do wonder whether "we" should ask to have it added ... I wonder how well-known it is outside the security area. > > > > > Section 6.1 > > > > In order to support the Self-Signed Certificate method, the > > authorization server would configure the TLS stack in such a way that > > it does not verify whether the certificate presented by the client > > during the handshake is signed by a trusted CA certificate. > > > > This statement doesn't quite follow -- *support*ing self-signed > > certificates only requires that you configure TLS to not require a valid > > client cert+chain for the handshake to succeed, but it can still try to > > validate such a chain. This would be useful if, for example, you > > intended to support both self-signed and CA-signed certificates. > > We may also want a specific note to implementors to check validation > > results for certificates intended to be CA-signed, if we're going to > > include a note about disabling validation for self-signed cert usage. > > > > I take your point but the text (which I did not write FWIW) was meant to be > practical guidance based on an understanding of how the most common web > servers work (problem in chain validation terminates the handshake) and the > options they provide (can turn off cert chain validating) and what they > surface about the handshake results (AFAIK not the kind of info that would > allow the distinction you mention so the whole process of chain validation > would maybe have to be deferred to the application layer). I can try and > add or amend some text along the lines of your comment. But I worry I'd do > more harm than good in doing so. I sympathize with your concern; please don't feel obligated to take any action here on this non-blocking comment. > > > > Section 6.2 > > > > Would there be any scenario in which "additional security" might be > > gained from having the RS check that the client-presented cert does > > chain to a trusted CA? > > > > I'm sure there is some such scenario out there. But this is meant as > implementation considerations or guidance for the general or common cases. Okay; we definitely don't have to cover such things in this document. > > > > > Section 6.3 > > > > Isn't this ignoring the elephant in the room about what to do when the > > refresh token is also bound to the (expiring) client certificate? > > > > The only time a refresh token is bound directly to the client certificate > is for public clients ( > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-4 and > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-7.1) and > public clients can only use self signed certificates for which the > expiration isn't all that meaningful and can be made to be far enough in > the future. Oh, I think I was misunderstanding what the "indirectly certificate-bound" meant in 7.1. Okay, this seems less worrisome now. > > > > > Section 6.5 > > > > There are a couple of active proposals for new, secure, protocols from > > load balancer to backend server, but probably not anything quite mature > > enough to be worth referencing from here. > > (e.g., draft-schwartz-tls-lb and another one that I think was presented > > in QUIC but I can't find right now) > > > > Section 7 > > > > We could potentially also talk about how the use of jwks_uri requires > > a fairly strong level of trust in the service at the target of the URI: > > the client has to trust it to faithfully provide the certification > > information, and the RS has to trust it to provide valid data for the > > client in question, as well as the usual trust in the TLS connection > > that identifies it, etc. > > > > I understand what you are saying but don't know what I would actually write > and kinda think that anything along those lines should have been in RFC > 7591 anyway because it's applicable there and not just in the context of > this narrow document. I guess in some sense this is already done in RFC 3986 (Section 7.1), too, which 7591 unfortunately does not cite directly. > > > > > Section 7.1 > > > > The OAuth 2.0 Authorization Framework [RFC6749] requires that an > > authorization server bind refresh tokens to the client to which they > > were issued and that confidential clients (those having established > > authentication credentials with the authorization server) > > authenticate to the AS when presenting a refresh token. As a result, > > refresh tokens are indirectly certificate-bound when issued to > > clients utilizing the "tls_client_auth" or > > "self_signed_tls_client_auth" methods of client authentication. > > > > nit(?): is this "indirectly" or "implicitly" bound? > > > > I guess it's both? But "indirectly" seemed right to me. The word "implicit" > also has some meaning and connotations in the general word of OAuth, which > are unrelated but I was trying to avoid it just the same. Per your clarification above, I think I misunderstood the meaning here. My new suggestion would be "indirectly certificate-bound by way of the clientID and the associated requirement for (certificate-based) authentication to the AS", if that's not too unwieldly. > > > > > Section 7.2 > > > > I'm not sure why we mention both (first) preimage and second-preimage > > resistance, as they're pretty different properties. I suppose there > > could be some registration scenarios where only the thumbprint is > > provided and thus an attacker with a DB dump would not have the first > > preimage in the form of the actual intended certificate, but even if > > they could reconstruct that "real" preimage from the thumbprint they > > wouldn't have the corresponding private key. So second-preimage > > probably covers what we need, and we can assume that the "first" > > preimage (certificate) is always available to the attacker. > > > > Section 7.4 > > > > Maybe we should say "agree out of band" on the set of trust anchors. > > > > okay > > > > > > Section 7.5 > > > > o handling of null-terminator bytes and non-canonical string > > representations in subject names; > > > > ASN.1 encodings are going to be using counted strings, so any > > NUL terminators will be in implementation languages. I think we might > > want to reword this to indicate that ASN.1 strings cannot be directly > > interpreted as native language strings in languages that use NUL > > terminators. > > > > I am not equipped with the knowledge to do that rewording. Please suggest > some specific text, if you'd like to have it reworded. How about: o handling of embedded NUL bytes in ASN.1 counted-length strings, and non-canonical or non-normalized string representations in subject names > > > > > o handling of wildcard patterns in subject names; > > > > Interestingly, RFC 5280 punts on the semantics of wildcard characters in > > SANs, though I think many applications will insist on only a single > > wildcard and the leftmost label being just the single wildcard > > character. > > > > Also there is no allowance anywhere in this draft for using wildcards in > subject names for the client certificate. This whole section came as a > suggestion doing WGLC that was taken to get through WGLC. But it's not > entirely contextually relevant. This bullet in particular. Maybe it'd be > better to remove it? I'd leave it in. I don't think I had any specific change in mind here, and was just making an observation. > > > > > Section 8 > > > > There's perhaps some additional considerations if a client uses the same > > certificate across multiple RSes, in that the client certificate > > provides an additional mechanism for collaborating RSes to correlate a > > single client, in ways that just the access token would not. This is > > not a terribly common threat model in a highly centralized deployment > > where all RSes are fairly well trusted, of course, but there can be some > > environments where it is relevant, so it probably merits discussion. > > > > I have balked at adding any such discussion and will continue to do so > because there is likely so much correlateble info in an access token > already that the client has no control over and might well not even know > about. I don't know how to write what you're suggesting in a meaningful way > and without giving the impression that using a different certificate > provides privacy benefits that are not really there. Okay. You're much closer to what access tokens look like in practice than I am, and this is a fairly theoretical scenario anyway. > > > > > Section 9.2 > > > > This specification requests registration of the following value in > > > > nit: "values" plural > > > > Will fix and also found and will fix the same thing in 9.3 > > > > > > Section 10.2 > > > > I think that RFC 7517 needs to be normative, since we use the jwks > > containers for conveying certificate information. > > > > okay > > > > > > It also seems like RFCs 7591 and 8414 should probably be normative. > > > > I was on the fence with these two as i didn't think they are strictly > necessary but am happy to move them to normative. 7519 and 7662 probably > too. > > > > > > Traditionally we keep RFC 8174 as normative, as part of BCP 14 along > > with RFC 2119. > > > > I think I knew that but somehow got it wrong here. Will fix. Thanks for all the updates! -Ben From nobody Fri Aug 23 14:08:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC0120122 for ; Fri, 23 Aug 2019 14:08:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CRHgr6T_e4RG for ; Fri, 23 Aug 2019 14:08:11 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 8268A120047 for ; Fri, 23 Aug 2019 14:08:11 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id z3so23286814iog.0 for ; Fri, 23 Aug 2019 14:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MtEclJgIQngIhR4Hj5fzZCx86mlL0cwxvdsfEvq5x04=; b=eTdiRApO5o+L7/gzUYgpzIh0T4VHK5cCtsebJsbCXmUwlkrW/cpwq1p8PKKElIsLpQ wuiiMoGpA0QHfOWCKCdgPHDOYDR92Zfh+tzMMsmSyKzfPHLXcG5e10erpoJN/PQGNTJw /+brQz30LbgZDCZMKEHGMWdtwkfgdI0Rt8cXY= 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=MtEclJgIQngIhR4Hj5fzZCx86mlL0cwxvdsfEvq5x04=; b=mXAofprqVLYj9ZIs1Gwku20SUWCyanuqnGVn5kQ1gLf4YSqhzBDh/av6LybwwRN/FG uG0OVWWAe9dS4lCa4HzZ6Wt2coMhaL4eRNPp1tOQtqFROZCPJSQNCQSnCDWkzDBCsWK9 RYeiEZ05nPT91qrgSXIjLvRGdmZi4gb0n+TBXYy02ImPrj6aObhhtpB8K0o6Z3mvK4Id HzLUM+MYCE+nW7Ux7q+237AyemL5B0bWcM5K10xlobxk6GNJmDgA+jOZmJO6dMkXwdCv IQVstvEmEZQuXPXFJDd5b2+qNHaAlJMCjHlRomJZh/0IwpTboz37Sfrb4KLJejgRq0Uc AZjA== X-Gm-Message-State: APjAAAWxNzQDJJSiP4dnpyS7U4VKgrm22hSNgRxtZIWVRelE0JhKCNRe XftLjp7V6v7+SDK/OaBLwhAKzMVYGRyYkQDFgSaD/V6UgXpIBWnhuJ95YiXMifcM9efj40prkeq 0Ymf+/9ps3XBqtA== X-Google-Smtp-Source: APXvYqzbMfN4Momxnv0j/c5ep7bdvKcqnh5sGhDYjyIaTpVKe7czIhvcd3hXJB7uR4ZID/nERvfshrE1vP7N6rEnxl8= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr8190467ioc.115.1566594490541; Fri, 23 Aug 2019 14:08:10 -0700 (PDT) MIME-Version: 1.0 References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> <20190822231654.GS60855@kduck.mit.edu> In-Reply-To: <20190822231654.GS60855@kduck.mit.edu> From: Brian Campbell Date: Fri, 23 Aug 2019 15:07:43 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001dd4810590cf3421" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 21:08:14 -0000 --0000000000001dd4810590cf3421 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the responses Ben. More inline below with stuff that warrants no further discussion snipped out. On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk wrote: > > But it's possible to be naive and be correct at the same time... > I rather like that and suspect I might have to use it in the future :) > In terms of proposed text, it looks like after the first paragraph of > Section 3 would be a reasonable place, perhaps: > > In order for a resource server to use certificate-bound access tokens, it > must have advance knowledge that mtls is to be used for some or all > resource accesses. In particular, the client ID or access token itself > cannot be used as input to the decision of whether or not to use mtls, > since from the TLS perspective those are "Application Data", only exchang= ed > after the TLS handshake has been completed, and the initial > CertificateRequest occurs during the handshake, before the Application Da= ta > is available. Although subsequent opportunities for a TLS client to > present a certificate may be available, e.g., via TLS 1.2 renegotiation > [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this docume= nt > makes no provision for their usage. It is expected to be common that a > mtls-using resource server will require mtls for all resources hosted > thereupon, or will serve mtls-protected and regular resources on separate > hostname+port combinations, though other workflows are possible. How > resource server policy is synchronized with the AS is out of scope for th= is > document. > > And then the following paragraph could start "Within the scope of an > mtls-protected resource-access flow," > Thank you for that. Super helpful. I'll incorporate. > And my intent and assumption was that a mismatch covered the case where n= o > > certificate was presented (i.e. null cert doesn't match expected cert > just > > as different cert doesn't match). But perhaps that particular case shou= ld > > be made more explicit? The second to last paragraph of sec 3 > > It probably should; "if the presented certificate" as a predicate could > fairly be easily read as to ignore the case where no certificate is > presented. > Fair enough. Maybe, "If no certificate is presented or that which is presented doesn't match" would suffice to avoid that reading? > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has simila= r > > guidance for error handing in the case of mismatch during resource > access. > > > > The case of a so called public client that has > > tls_client_certificate_bound_access_tokens metadata of true that shows = up > > at the token endpoint without having done MTLS is a bit more nuanced an= d > I > > think it's untimely a policy decision for the AS at that point as to > > whether to error or issue an unbound token. > > Do you have any feelings about whether or not you want to mention that ca= se > explicitly as being up to local policy at the AS (vs. leaving it implicit > as is presently being done)? > I don't really *want* to add anything but it's probably better to be explicit about it. I'll look for a place to work it in. > > > I am not *nix skilled enough to troubleshoot that command pipeline but = I > > suspect that the sha256sum output is in hex which represents each byte = of > > the hash output with two charterers and thus double the resultant size. > > Please excuse me while I wipe the egg off my face. > Yes, that sha256sum output is in hex, and I should have counted the bits > directly. I hope you did not waste too much time on this (and now I can > get the thumbprint to agree). > No worries. I only spent enough time second guessing everything so as to try and avoid getting egg on my own face. > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > protected resource access in step (B) is only possible by the > > > legitimate client bearing the access token and holding the private > > > key corresponding to the certificate. > > > > > > nit: I guess it is only protected resource access "using this tokwn" > > > that is only possible as specified. > > > > > > > I kinda felt like that was implied at this point. But I can add "using > this > > token" there, if you think it's needed or helpful? > > Or perhaps "using a certificate-bound token". I think it's just barely > worth adding, since this section is largely reiterating the general OAuth > flow, and this helps emphasize that the "and holding the private key" is > the important/new part. > Works for me. > It's gotta be done (unless using the self-singed method) and it is > > definitely up to deployments as I wouldn't even pretend to know where t= o > > begin on providing general guidance nor would I think it appropriate. > > > > I felt like this was pretty well implied and touched on in security > > considerations too. But please suggest some specific text, if you think > > it's needed or would be useful. > > Maybe a couple lines at the end of Section 7.3, "TLS certificate validati= on > (for both client and server certificates) requires a local database of > trusted certificate authorities (CAs). Decisions about what CAs to trust > and how to make such a determination of trust are out of scope for this > document, but such policy must be consistent between AS and RS for reliab= le > operation."? > The very last part isn't exactly true as this document recommends or at least discusses the possibility that an RS run in a "trust em all" mode wrt client certs and use the client cert only for private-key PoP of the bound access tokens. As such, I'm inclined to take your text but end it with "scope for this document." > > > tls_client_auth_san_ip > > That all sounds reasonable to me; I'm happy to leave this topic to the > other ballot threads (or remove the option entirely). > I think the other thread(s) got it to an actionable way forward https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNsvwS9AgFSI I think it helps my understanding, thanks. > Perhaps it is the RS's verification of proof-of-possession that is > decoupled from the client's authentication to the AS, then? > Yeah, I think so. I guess I sometimes conflate the binding in the token and the verification of the binding by the RS. I'll work on the wording a bit. Per your clarification above, I think I misunderstood the meaning here. > My new suggestion would be "indirectly certificate-bound by way of the > clientID and the associated requirement for (certificate-based) > authentication to the AS", if that's not too unwieldly. > It's possible to be unwieldy and be correct at the same time:) I'm inclined to use it. > > > > Section 7.5 > > > > > > o handling of null-terminator bytes and non-canonical string > > > representations in subject names; > > > > > > ASN.1 encodings are going to be using counted strings, so any > > > NUL terminators will be in implementation languages. I think we migh= t > > > want to reword this to indicate that ASN.1 strings cannot be directly > > > interpreted as native language strings in languages that use NUL > > > terminators. > > > > > > > I am not equipped with the knowledge to do that rewording. Please sugge= st > > some specific text, if you'd like to have it reworded. > > How about: > > o handling of embedded NUL bytes in ASN.1 counted-length strings, and > non-canonical or non-normalized string representations in subject names > Sure. > > Thanks for all the updates! > Likewise, thanks for the review. Yours can be long and painful at times but are quite useful. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000001dd4810590cf3421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the responses Ben. More inline below with = stuff that warrants no further discussion snipped out.

On Thu, Aug 22, 2= 019 at 5:17 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

=C2=A0 But it's possible to be naive and be correct at the same time...

I rather like that and suspect I might have t= o use it in the future :)

=C2=A0
In terms of proposed text, it looks like after the first paragraph of
Section 3 would be a reasonable place, perhaps:

In order for a resource server to use certificate-bound access tokens, it must have advance knowledge that mtls is to be used for some or all
resource accesses.=C2=A0 In particular, the client ID or access token itsel= f
cannot be used as input to the decision of whether or not to use mtls,
since from the TLS perspective those are "Application Data", only= exchanged
after the TLS handshake has been completed, and the initial
CertificateRequest occurs during the handshake, before the Application Data=
is available.=C2=A0 Although subsequent opportunities for a TLS client to present a certificate may be available, e.g., via TLS 1.2 renegotiation
[RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document=
makes no provision for their usage.=C2=A0 It is expected to be common that = a
mtls-using resource server will require mtls for all resources hosted
thereupon, or will serve mtls-protected and regular resources on separate hostname+port combinations, though other workflows are possible.=C2=A0 How<= br> resource server policy is synchronized with the AS is out of scope for this=
document.

And then the following paragraph could start "Within the scope of an mtls-protected resource-access flow,"

<= div>Thank you for that. Super helpful. I'll incorporate.
= =C2=A0

> https://tools.ietf.org/html/draft= -ietf-oauth-mtls-16#section-3 has similar
> guidance for error handing in the case of mismatch during resource acc= ess.
>
> The case of a so called public client that has
> tls_client_certificate_bound_access_tokens metadata of true that shows= up
> at the token endpoint without having done MTLS is a bit more nuanced a= nd I
> think it's untimely a policy decision for the AS at that point as = to
> whether to error or issue an unbound token.

Do you have any feelings about whether or not you want to mention that case=
explicitly as being up to local policy at the AS (vs. leaving it implicit as is presently being done)?

I don'= t really *want* to add anything but it's probably better to be explicit= about it. I'll look for a place to work it in.
=C2=A0
=C2=A0

> I am not *nix skilled enough to troubleshoot that command pipeline but= I
> suspect that the sha256sum output is in hex which represents each byte= of
> the hash output with two charterers and thus double the resultant size= .

Please excuse me while I wipe the egg off my face.
Yes, that sha256sum output is in hex, and I should have counted the bits directly.=C2=A0 I hope you did not waste too much time on this (and now I c= an
get the thumbprint to agree).

No worrie= s. I only spent enough time second guessing everything so as to try and avo= id getting egg on my own face.

=C2=A0
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> >=C2=A0 =C2=A0 protected resource access in step (B) is only possib= le by the
> >=C2=A0 =C2=A0 legitimate client bearing the access token and holdi= ng the private
> >=C2=A0 =C2=A0 key corresponding to the certificate.
> >
> > nit: I guess it is only protected resource access "using thi= s tokwn"
> > that is only possible as specified.
> >
>
> I kinda felt like that was implied at this point. But I can add "= using this
> token" there, if you think it's needed or helpful?

Or perhaps "using a certificate-bound token".=C2=A0 I think it= 9;s just barely
worth adding, since this section is largely reiterating the general OAuth flow, and this helps emphasize that the "and holding the private key&q= uot; is
the important/new part.

Works for me.
=C2=A0

> It's gotta be done (unless using the self-singed method) and it is=
> definitely up to deployments as I wouldn't even pretend to know wh= ere to
> begin on providing general guidance nor would I think it appropriate.<= br> >
> I felt like this was pretty well implied and touched on in security > considerations too. But please suggest some specific text, if you thin= k
> it's needed or would be useful.

Maybe a couple lines at the end of Section 7.3, "TLS certificate valid= ation
(for both client and server certificates) requires a local database of
trusted certificate authorities (CAs).=C2=A0 Decisions about what CAs to tr= ust
and how to make such a determination of trust are out of scope for this
document, but such policy must be consistent between AS and RS for reliable=
operation."?

The very last part is= n't exactly true as this document recommends or at least discusses the = possibility that an RS run in a "trust em all" mode wrt client ce= rts and use the client cert only for private-key PoP of the bound access to= kens. As such, I'm inclined to take your text but end it with "sco= pe for this document."

=C2=A0
> >=C2=A0 =C2=A0 tls_client_auth_san_ip

That all sounds reasonable to me; I'm happy to leave this topic to the<= br> other ballot threads (or remove the option entirely).
=
I think the other thread(s) got it to an actionable way forw= ard https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNs= vwS9AgFSI
=C2=A0

I think it helps my understanding, thanks.
Perhaps it is the RS's verification of proof-of-possession that is
decoupled from the client's authentication to the AS, then?

Yeah, I think so. I guess I sometimes conflate the= binding in the token and the verification of the binding by the RS. I'= ll work on the wording a bit.
=C2=A0

Per your clarification above, I think I misunderstood the meaning here.
My new suggestion would be "indirectly certificate-bound by way of the=
clientID and the associated requirement for (certificate-based)
authentication to the AS", if that's not too unwieldly.

It's possible to be unwieldy and be correct a= t the same time:) I'm inclined to use it.
=C2=A0

> > Section 7.5
> >
> >=C2=A0 =C2=A0 o=C2=A0 handling of null-terminator bytes and non-ca= nonical string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0representations in subject names;
> >
> > ASN.1 encodings are going to be using counted strings, so any
> > NUL terminators will be in implementation languages.=C2=A0 I thin= k we might
> > want to reword this to indicate that ASN.1 strings cannot be dire= ctly
> > interpreted as native language strings in languages that use NUL<= br> > > terminators.
> >
>
> I am not equipped with the knowledge to do that rewording. Please sugg= est
> some specific text, if you'd like to have it reworded.

How about:

o handling of embedded NUL bytes in ASN.1 counted-length strings, and
non-canonical or non-normalized string representations in subject names
=

Sure.=C2=A0
=C2=A0

Thanks for all the updates!

Likewise, t= hanks for the review. Yours can be long and painful at times but are quite = useful.

<= 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. --0000000000001dd4810590cf3421-- From nobody Fri Aug 23 15:25:32 2019 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 CEAEA12000F; Fri, 23 Aug 2019 15:25:23 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156659912373.25038.10618687116060609811@ietfa.amsl.com> Date: Fri, 23 Aug 2019 15:25:23 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:25:24 -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 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-17.txt Pages : 32 Date : 2019-08-23 Abstract: This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-17 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 Aug 23 15:33:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4107012002E for ; Fri, 23 Aug 2019 15:33:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 rcwOh7v2hnrY for ; Fri, 23 Aug 2019 15:33:03 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 2372012002F for ; Fri, 23 Aug 2019 15:33:03 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id l7so23676502ioj.6 for ; Fri, 23 Aug 2019 15:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bv/oazToyo1mI3hfqMMxdxccHUDYf6kwTq5bbMS4N5E=; b=Zmauect9idsVXuLW+v4NHFLZqUz4xLsUmr9VlwGtkgfohIa4R78xd/YvH1GIjcOZ4w 6V/F1BjRitKhjGetBT2mhan03xulYjLSj/rN3vhdn18MHKyUgJR4x3GSj+M7MudnIAKX 54m8vx0EjrpSFQhKwSU2cKl9Nt7fxMCrIRmSc= 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=bv/oazToyo1mI3hfqMMxdxccHUDYf6kwTq5bbMS4N5E=; b=Vj+L5V7NLcK70pP1DH+M23kToheNW1LTCigiI0LAgTlWAW+L4Wvfe1NWqUJp2KGE+V /na6x4BMGyQKh3ZZE+8IxZEP/TQbHNw9SqhG8KQuLUKjd4ATycRl4ZI7mhO4uh+OFv/i eykvJqwJ1VQnRnWGNq/ayVrk/fEnm2gQW634msjhSyfeZ/EHBiCvQ6uEYPeuTBzf4LUx uaMjo2Vax6/V4tnOwadS1A+BA1Qzds8v9sEggWykCI5C6anB+uxo6Uzy5XIltuFGu73O EIRflRYe438PlUgvDe+CshevGRhGsKO8uID0zMWh32bJ784AtTjHZTMre2EKYpTSFDxD boHw== X-Gm-Message-State: APjAAAVG2iNv45znjaQnkEzb5jYvwXgyEkra3FysvLj6qvyPQiUeS1yT Ux8Uc+10aixxX8Ho5V6LZ3kwcQWm9YLTj2ufdtTS8VMVoNXsqVkDcc+18fGaeQ3PivxDlWLj/n8 rPs2/Fu9u3mbgpQ== X-Google-Smtp-Source: APXvYqwLEbkMnE0PzvS+tM3gKb/yPCeYu4+Ddk8YeLEY2/ZcYlu43F/nE7pleq3Cfev/CvJVyKN95UuAbuhkYOWpiD0= X-Received: by 2002:a02:9644:: with SMTP id c62mr7204064jai.45.1566599582198; Fri, 23 Aug 2019 15:33:02 -0700 (PDT) MIME-Version: 1.0 References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> <20190822231654.GS60855@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Fri, 23 Aug 2019 16:32:35 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009abd570590d06335" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:33:06 -0000 --0000000000009abd570590d06335 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I went ahead and pushed a -17, which I think addresses everything discussed in this thread. https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 Thanks again for the review and suggestions. On Fri, Aug 23, 2019 at 3:07 PM Brian Campbell wrote: > Thanks for the responses Ben. More inline below with stuff that warrants > no further discussion snipped out. > > On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk wrote: > >> >> But it's possible to be naive and be correct at the same time... >> > > I rather like that and suspect I might have to use it in the future :) > > > >> In terms of proposed text, it looks like after the first paragraph of >> Section 3 would be a reasonable place, perhaps: >> >> In order for a resource server to use certificate-bound access tokens, i= t >> must have advance knowledge that mtls is to be used for some or all >> resource accesses. In particular, the client ID or access token itself >> cannot be used as input to the decision of whether or not to use mtls, >> since from the TLS perspective those are "Application Data", only >> exchanged >> after the TLS handshake has been completed, and the initial >> CertificateRequest occurs during the handshake, before the Application >> Data >> is available. Although subsequent opportunities for a TLS client to >> present a certificate may be available, e.g., via TLS 1.2 renegotiation >> [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this >> document >> makes no provision for their usage. It is expected to be common that a >> mtls-using resource server will require mtls for all resources hosted >> thereupon, or will serve mtls-protected and regular resources on separat= e >> hostname+port combinations, though other workflows are possible. How >> resource server policy is synchronized with the AS is out of scope for >> this >> document. >> >> And then the following paragraph could start "Within the scope of an >> mtls-protected resource-access flow," >> > > Thank you for that. Super helpful. I'll incorporate. > > > > And my intent and assumption was that a mismatch covered the case where >> no >> > certificate was presented (i.e. null cert doesn't match expected cert >> just >> > as different cert doesn't match). But perhaps that particular case >> should >> > be made more explicit? The second to last paragraph of sec 3 >> >> It probably should; "if the presented certificate" as a predicate could >> fairly be easily read as to ignore the case where no certificate is >> presented. >> > > Fair enough. Maybe, "If no certificate is presented or that which is > presented doesn't match" would suffice to avoid that reading? > > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has >> similar >> > guidance for error handing in the case of mismatch during resource >> access. >> > >> > The case of a so called public client that has >> > tls_client_certificate_bound_access_tokens metadata of true that shows >> up >> > at the token endpoint without having done MTLS is a bit more nuanced >> and I >> > think it's untimely a policy decision for the AS at that point as to >> > whether to error or issue an unbound token. >> >> Do you have any feelings about whether or not you want to mention that >> case >> explicitly as being up to local policy at the AS (vs. leaving it implici= t >> as is presently being done)? >> > > I don't really *want* to add anything but it's probably better to be > explicit about it. I'll look for a place to work it in. > > > >> >> > I am not *nix skilled enough to troubleshoot that command pipeline but= I >> > suspect that the sha256sum output is in hex which represents each byte >> of >> > the hash output with two charterers and thus double the resultant size= . >> >> Please excuse me while I wipe the egg off my face. >> Yes, that sha256sum output is in hex, and I should have counted the bits >> directly. I hope you did not waste too much time on this (and now I can >> get the thumbprint to agree). >> > > No worries. I only spent enough time second guessing everything so as to > try and avoid getting egg on my own face. > > > >> > > --------------------------------------------------------------------= -- >> > > COMMENT: >> > > --------------------------------------------------------------------= -- >> > > >> > > protected resource access in step (B) is only possible by the >> > > legitimate client bearing the access token and holding the privat= e >> > > key corresponding to the certificate. >> > > >> > > nit: I guess it is only protected resource access "using this tokwn" >> > > that is only possible as specified. >> > > >> > >> > I kinda felt like that was implied at this point. But I can add "using >> this >> > token" there, if you think it's needed or helpful? >> >> Or perhaps "using a certificate-bound token". I think it's just barely >> worth adding, since this section is largely reiterating the general OAut= h >> flow, and this helps emphasize that the "and holding the private key" is >> the important/new part. >> > > Works for me. > > > > It's gotta be done (unless using the self-singed method) and it is >> > definitely up to deployments as I wouldn't even pretend to know where = to >> > begin on providing general guidance nor would I think it appropriate. >> > >> > I felt like this was pretty well implied and touched on in security >> > considerations too. But please suggest some specific text, if you thin= k >> > it's needed or would be useful. >> >> Maybe a couple lines at the end of Section 7.3, "TLS certificate >> validation >> (for both client and server certificates) requires a local database of >> trusted certificate authorities (CAs). Decisions about what CAs to trus= t >> and how to make such a determination of trust are out of scope for this >> document, but such policy must be consistent between AS and RS for >> reliable >> operation."? >> > > The very last part isn't exactly true as this document recommends or at > least discusses the possibility that an RS run in a "trust em all" mode w= rt > client certs and use the client cert only for private-key PoP of the boun= d > access tokens. As such, I'm inclined to take your text but end it with > "scope for this document." > > > >> > > tls_client_auth_san_ip >> >> That all sounds reasonable to me; I'm happy to leave this topic to the >> other ballot threads (or remove the option entirely). >> > > I think the other thread(s) got it to an actionable way forward > https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNsvwS9AgFSI > > > I think it helps my understanding, thanks. >> Perhaps it is the RS's verification of proof-of-possession that is >> decoupled from the client's authentication to the AS, then? >> > > Yeah, I think so. I guess I sometimes conflate the binding in the token > and the verification of the binding by the RS. I'll work on the wording a > bit. > > > Per your clarification above, I think I misunderstood the meaning here. >> My new suggestion would be "indirectly certificate-bound by way of the >> clientID and the associated requirement for (certificate-based) >> authentication to the AS", if that's not too unwieldly. >> > > It's possible to be unwieldy and be correct at the same time:) I'm > inclined to use it. > > >> >> > > Section 7.5 >> > > >> > > o handling of null-terminator bytes and non-canonical string >> > > representations in subject names; >> > > >> > > ASN.1 encodings are going to be using counted strings, so any >> > > NUL terminators will be in implementation languages. I think we mig= ht >> > > want to reword this to indicate that ASN.1 strings cannot be directl= y >> > > interpreted as native language strings in languages that use NUL >> > > terminators. >> > > >> > >> > I am not equipped with the knowledge to do that rewording. Please >> suggest >> > some specific text, if you'd like to have it reworded. >> >> How about: >> >> o handling of embedded NUL bytes in ASN.1 counted-length strings, and >> non-canonical or non-normalized string representations in subject names >> > > Sure. > > >> >> Thanks for all the updates! >> > > Likewise, thanks for the review. Yours can be long and painful at times > but are quite useful. > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000009abd570590d06335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went ahead and pushed a -17, which I think addresse= s everything discussed in this thread.


Tha= nks again for the review and suggestions.

On Fri, Aug 23, 2019 at= 3:07 PM Brian Campbell <b= campbell@pingidentity.com> wrote:
Thanks for the responses Ben= . More inline below with stuff that warrants no further discussion snipped = out.

On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

=C2=A0 But it's possible to be naive and be correct at the same time...

I rather like that and suspect I might have t= o use it in the future :)

=C2=A0
In terms of proposed text, it looks like after the first paragraph of
Section 3 would be a reasonable place, perhaps:

In order for a resource server to use certificate-bound access tokens, it must have advance knowledge that mtls is to be used for some or all
resource accesses.=C2=A0 In particular, the client ID or access token itsel= f
cannot be used as input to the decision of whether or not to use mtls,
since from the TLS perspective those are "Application Data", only= exchanged
after the TLS handshake has been completed, and the initial
CertificateRequest occurs during the handshake, before the Application Data=
is available.=C2=A0 Although subsequent opportunities for a TLS client to present a certificate may be available, e.g., via TLS 1.2 renegotiation
[RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document=
makes no provision for their usage.=C2=A0 It is expected to be common that = a
mtls-using resource server will require mtls for all resources hosted
thereupon, or will serve mtls-protected and regular resources on separate hostname+port combinations, though other workflows are possible.=C2=A0 How<= br> resource server policy is synchronized with the AS is out of scope for this=
document.

And then the following paragraph could start "Within the scope of an mtls-protected resource-access flow,"

<= div>Thank you for that. Super helpful. I'll incorporate.
= =C2=A0

> https://tools.ietf.org/html/draft= -ietf-oauth-mtls-16#section-3 has similar
> guidance for error handing in the case of mismatch during resource acc= ess.
>
> The case of a so called public client that has
> tls_client_certificate_bound_access_tokens metadata of true that shows= up
> at the token endpoint without having done MTLS is a bit more nuanced a= nd I
> think it's untimely a policy decision for the AS at that point as = to
> whether to error or issue an unbound token.

Do you have any feelings about whether or not you want to mention that case=
explicitly as being up to local policy at the AS (vs. leaving it implicit as is presently being done)?

I don'= t really *want* to add anything but it's probably better to be explicit= about it. I'll look for a place to work it in.
=C2=A0
=C2=A0

> I am not *nix skilled enough to troubleshoot that command pipeline but= I
> suspect that the sha256sum output is in hex which represents each byte= of
> the hash output with two charterers and thus double the resultant size= .

Please excuse me while I wipe the egg off my face.
Yes, that sha256sum output is in hex, and I should have counted the bits directly.=C2=A0 I hope you did not waste too much time on this (and now I c= an
get the thumbprint to agree).

No worrie= s. I only spent enough time second guessing everything so as to try and avo= id getting egg on my own face.

=C2=A0
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> >=C2=A0 =C2=A0 protected resource access in step (B) is only possib= le by the
> >=C2=A0 =C2=A0 legitimate client bearing the access token and holdi= ng the private
> >=C2=A0 =C2=A0 key corresponding to the certificate.
> >
> > nit: I guess it is only protected resource access "using thi= s tokwn"
> > that is only possible as specified.
> >
>
> I kinda felt like that was implied at this point. But I can add "= using this
> token" there, if you think it's needed or helpful?

Or perhaps "using a certificate-bound token".=C2=A0 I think it= 9;s just barely
worth adding, since this section is largely reiterating the general OAuth flow, and this helps emphasize that the "and holding the private key&q= uot; is
the important/new part.

Works for me.
=C2=A0

> It's gotta be done (unless using the self-singed method) and it is=
> definitely up to deployments as I wouldn't even pretend to know wh= ere to
> begin on providing general guidance nor would I think it appropriate.<= br> >
> I felt like this was pretty well implied and touched on in security > considerations too. But please suggest some specific text, if you thin= k
> it's needed or would be useful.

Maybe a couple lines at the end of Section 7.3, "TLS certificate valid= ation
(for both client and server certificates) requires a local database of
trusted certificate authorities (CAs).=C2=A0 Decisions about what CAs to tr= ust
and how to make such a determination of trust are out of scope for this
document, but such policy must be consistent between AS and RS for reliable=
operation."?

The very last part is= n't exactly true as this document recommends or at least discusses the = possibility that an RS run in a "trust em all" mode wrt client ce= rts and use the client cert only for private-key PoP of the bound access to= kens. As such, I'm inclined to take your text but end it with "sco= pe for this document."

=C2=A0
> >=C2=A0 =C2=A0 tls_client_auth_san_ip

That all sounds reasonable to me; I'm happy to leave this topic to the<= br> other ballot threads (or remove the option entirely).
=
I think the other thread(s) got it to an actionable way forw= ard https://mailarchive.ietf.org/arch/msg/oauth/= KUb3G-Rr_7KsAWVCNsvwS9AgFSI
=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"> I think it helps my understanding, thanks.
Perhaps it is the RS's verification of proof-of-possession that is
decoupled from the client's authentication to the AS, then?

Yeah, I think so. I guess I sometimes conflate the= binding in the token and the verification of the binding by the RS. I'= ll work on the wording a bit.
=C2=A0

Per your clarification above, I think I misunderstood the meaning here.
My new suggestion would be "indirectly certificate-bound by way of the=
clientID and the associated requirement for (certificate-based)
authentication to the AS", if that's not too unwieldly.

It's possible to be unwieldy and be correct a= t the same time:) I'm inclined to use it.
=C2=A0

> > Section 7.5
> >
> >=C2=A0 =C2=A0 o=C2=A0 handling of null-terminator bytes and non-ca= nonical string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0representations in subject names;
> >
> > ASN.1 encodings are going to be using counted strings, so any
> > NUL terminators will be in implementation languages.=C2=A0 I thin= k we might
> > want to reword this to indicate that ASN.1 strings cannot be dire= ctly
> > interpreted as native language strings in languages that use NUL<= br> > > terminators.
> >
>
> I am not equipped with the knowledge to do that rewording. Please sugg= est
> some specific text, if you'd like to have it reworded.

How about:

o handling of embedded NUL bytes in ASN.1 counted-length strings, and
non-canonical or non-normalized string representations in subject names
=

Sure.=C2=A0
=C2=A0

Thanks for all the updates!

Likewise, t= hanks for the review. Yours can be long and painful at times but are quite = useful.

<= 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. --0000000000009abd570590d06335-- From nobody Fri Aug 23 15:34:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DCA12002E; Fri, 23 Aug 2019 15:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfzEuTyRfVed; Fri, 23 Aug 2019 15:34:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A30712000F; Fri, 23 Aug 2019 15:34:12 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7NMY8lO024409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 18:34:10 -0400 Date: Fri, 23 Aug 2019 17:34:07 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Message-ID: <20190823223407.GF60855@kduck.mit.edu> References: <156625291928.19849.7735014830227365369.idtracker@ietfa.amsl.com> <20190822231654.GS60855@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:34:16 -0000 On Fri, Aug 23, 2019 at 03:07:43PM -0600, Brian Campbell wrote: > Thanks for the responses Ben. More inline below with stuff that warrants no > further discussion snipped out. > > On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk wrote: > > > > > But it's possible to be naive and be correct at the same time... > > > > I rather like that and suspect I might have to use it in the future :) > > > > > In terms of proposed text, it looks like after the first paragraph of > > Section 3 would be a reasonable place, perhaps: > > > > In order for a resource server to use certificate-bound access tokens, it > > must have advance knowledge that mtls is to be used for some or all > > resource accesses. In particular, the client ID or access token itself > > cannot be used as input to the decision of whether or not to use mtls, > > since from the TLS perspective those are "Application Data", only exchanged > > after the TLS handshake has been completed, and the initial > > CertificateRequest occurs during the handshake, before the Application Data > > is available. Although subsequent opportunities for a TLS client to > > present a certificate may be available, e.g., via TLS 1.2 renegotiation > > [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document > > makes no provision for their usage. It is expected to be common that a > > mtls-using resource server will require mtls for all resources hosted > > thereupon, or will serve mtls-protected and regular resources on separate > > hostname+port combinations, though other workflows are possible. How > > resource server policy is synchronized with the AS is out of scope for this > > document. > > > > And then the following paragraph could start "Within the scope of an > > mtls-protected resource-access flow," > > > > Thank you for that. Super helpful. I'll incorporate. > > > > And my intent and assumption was that a mismatch covered the case where no > > > certificate was presented (i.e. null cert doesn't match expected cert > > just > > > as different cert doesn't match). But perhaps that particular case should > > > be made more explicit? The second to last paragraph of sec 3 > > > > It probably should; "if the presented certificate" as a predicate could > > fairly be easily read as to ignore the case where no certificate is > > presented. > > > > Fair enough. Maybe, "If no certificate is presented or that which is > presented doesn't match" would suffice to avoid that reading? I think so :) > > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar > > > guidance for error handing in the case of mismatch during resource > > access. > > > > > > The case of a so called public client that has > > > tls_client_certificate_bound_access_tokens metadata of true that shows up > > > at the token endpoint without having done MTLS is a bit more nuanced and > > I > > > think it's untimely a policy decision for the AS at that point as to > > > whether to error or issue an unbound token. > > > > Do you have any feelings about whether or not you want to mention that case > > explicitly as being up to local policy at the AS (vs. leaving it implicit > > as is presently being done)? > > > > I don't really *want* to add anything but it's probably better to be > explicit about it. I'll look for a place to work it in. Okay, thanks. > > > > > > > I am not *nix skilled enough to troubleshoot that command pipeline but I > > > suspect that the sha256sum output is in hex which represents each byte of > > > the hash output with two charterers and thus double the resultant size. > > > > Please excuse me while I wipe the egg off my face. > > Yes, that sha256sum output is in hex, and I should have counted the bits > > directly. I hope you did not waste too much time on this (and now I can > > get the thumbprint to agree). > > > > No worries. I only spent enough time second guessing everything so as to > try and avoid getting egg on my own face. > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > protected resource access in step (B) is only possible by the > > > > legitimate client bearing the access token and holding the private > > > > key corresponding to the certificate. > > > > > > > > nit: I guess it is only protected resource access "using this tokwn" > > > > that is only possible as specified. > > > > > > > > > > I kinda felt like that was implied at this point. But I can add "using > > this > > > token" there, if you think it's needed or helpful? > > > > Or perhaps "using a certificate-bound token". I think it's just barely > > worth adding, since this section is largely reiterating the general OAuth > > flow, and this helps emphasize that the "and holding the private key" is > > the important/new part. > > > > Works for me. > > > > It's gotta be done (unless using the self-singed method) and it is > > > definitely up to deployments as I wouldn't even pretend to know where to > > > begin on providing general guidance nor would I think it appropriate. > > > > > > I felt like this was pretty well implied and touched on in security > > > considerations too. But please suggest some specific text, if you think > > > it's needed or would be useful. > > > > Maybe a couple lines at the end of Section 7.3, "TLS certificate validation > > (for both client and server certificates) requires a local database of > > trusted certificate authorities (CAs). Decisions about what CAs to trust > > and how to make such a determination of trust are out of scope for this > > document, but such policy must be consistent between AS and RS for reliable > > operation."? > > > > The very last part isn't exactly true as this document recommends or at > least discusses the possibility that an RS run in a "trust em all" mode wrt > client certs and use the client cert only for private-key PoP of the bound > access tokens. As such, I'm inclined to take your text but end it with > "scope for this document." Good point; works for me. > > > > > > tls_client_auth_san_ip > > > > That all sounds reasonable to me; I'm happy to leave this topic to the > > other ballot threads (or remove the option entirely). > > > > I think the other thread(s) got it to an actionable way forward > https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNsvwS9AgFSI > > > I think it helps my understanding, thanks. > > Perhaps it is the RS's verification of proof-of-possession that is > > decoupled from the client's authentication to the AS, then? > > > > Yeah, I think so. I guess I sometimes conflate the binding in the token and > the verification of the binding by the RS. I'll work on the wording a bit. > > > Per your clarification above, I think I misunderstood the meaning here. > > My new suggestion would be "indirectly certificate-bound by way of the > > clientID and the associated requirement for (certificate-based) > > authentication to the AS", if that's not too unwieldly. > > > > It's possible to be unwieldy and be correct at the same time:) I'm inclined > to use it. :) > > > > > > > Section 7.5 > > > > > > > > o handling of null-terminator bytes and non-canonical string > > > > representations in subject names; > > > > > > > > ASN.1 encodings are going to be using counted strings, so any > > > > NUL terminators will be in implementation languages. I think we might > > > > want to reword this to indicate that ASN.1 strings cannot be directly > > > > interpreted as native language strings in languages that use NUL > > > > terminators. > > > > > > > > > > I am not equipped with the knowledge to do that rewording. Please suggest > > > some specific text, if you'd like to have it reworded. > > > > How about: > > > > o handling of embedded NUL bytes in ASN.1 counted-length strings, and > > non-canonical or non-normalized string representations in subject names > > > > Sure. > > > > > > Thanks for all the updates! > > > > Likewise, thanks for the review. Yours can be long and painful at times but > are quite useful. Let me know when that stops being the case! I mean, just the last part ;) -Ben From nobody Fri Aug 23 15:35:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6721B12006A for ; Fri, 23 Aug 2019 15:35:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2P1Mx_NI-cBt for ; Fri, 23 Aug 2019 15:35:19 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 316FE12002F for ; Fri, 23 Aug 2019 15:35:19 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id t3so23558761ioj.12 for ; Fri, 23 Aug 2019 15:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tTHo76PXbD2xzZhx3ZwjD6VY5AX0qWA5YY/kl6TuQ7w=; b=OmW7nSfHg04Ma5HmRrfio9rGqRBxw5X1+MY1rX9qJ7frtaQ6e31Ot7W1G9SBJ7C7+Z 0gWQIvifOtG9fED3Z4zgtNyhCVHX2hQkjaY+a7fdVyQJreryH1P1XVCYMWw6ckpWHTj3 AsgkzHvpoSDVWM4eClGAT6dOwKE6afnCcp3oA= 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=tTHo76PXbD2xzZhx3ZwjD6VY5AX0qWA5YY/kl6TuQ7w=; b=DiUD67IsD8amxSDH7bYbo9dDFv9Mb4PqaCfS6nxns7Bz5/y4it3YOK47kso/GSyV0t VHJ7s0u5R0NjRXi7xcCTxJHVoAWMd9EpaBpnpA8Ny8TqlygtV01//y0mw3ax7QEpwQEB 5ZRETBKqRkB76Uqujt3C49CMuIpp0sTj72PXn0bcYzLwZjD+QPBt38HFPkYowvmjxyt8 3hEg3NfPo2QCB7SqurVKW5BFUMIdJw9MkYykEVlPDEdpxxztiwogcq7mJaMnroFVDAaR erikzz/zqyPVB9innQfahySWP6YbDy/70EIb4gwEMja9VSd1oWikHIsCUK7e+qLVIH07 mMKQ== X-Gm-Message-State: APjAAAUgBCaRR7aDR/YAz9NXm49qL+Y6GWE3LnMdpVv/vcBAk5s3GVn+ X/Bs74bn0MVtmm6B/r/C+eyIV3iSQ6YVzRgipSx37gNDMyuPnuvgoz6wUFE3nUOnJB/V5d6xz5n KR3yY9b3HuiWGew== X-Google-Smtp-Source: APXvYqxJzm2Nb6Y/7AmynfA6gZ2avk5mEPT2uRo5HwlHPy+PS1A9urfm9p3HVU9HRcnvSvfG9osbqWik9fdrkW2A4Sg= X-Received: by 2002:a6b:ea16:: with SMTP id m22mr8736052ioc.115.1566599718464; Fri, 23 Aug 2019 15:35:18 -0700 (PDT) MIME-Version: 1.0 References: <156626655953.5157.11629807813580977810.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 23 Aug 2019 16:34:52 -0600 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b9941f0590d06b1f" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:35:22 -0000 --000000000000b9941f0590d06b1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again Adam for the review, suggestions, and grammar lesson. I went ahead and pushed a -17, which I think addresses everything discussed herein. https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 On Thu, Aug 22, 2019 at 5:02 PM Adam Roach wrote: > On 8/22/19 5:48 PM, Brian Campbell wrote: > > Regarding the comment on tls_client_auth_san_ip, some other reviewers > > have suggested using the using the IPv6 Address Text Representation > > described in RFC 5952 rather than the one from in RFC 4291. Which I > > think makes sense to do. Maybe also with a note that the comparison of > > the addresses should done using binary as suggested in > > https://tools.ietf.org/html/rfc5952#section-8 > > > > What do you think? > > > That sounds like a fine approach. Thanks for digging that reference up. := ) > > /a > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b9941f0590d06b1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again Adam for the review, suggestions, and gr= ammar lesson. I went ahead and pushed a -17, which I think addresses everyt= hing discussed herein.
=
On Thu= , Aug 22, 2019 at 5:02 PM Adam Roach <adam@nostrum.com> wrote:
On 8/22/19 5:48 PM, Brian Campbell wrot= e:
> Regarding the comment on tls_client_auth_san_ip, some other reviewers =
> have suggested using the using the IPv6 Address Text Representation > described in RFC 5952 rather than the one from in RFC 4291. Which I > think makes sense to do. Maybe also with a note that the comparison of=
> the addresses should done using binary as suggested in
> https://tools.ietf.org/html/rfc5952#section-8<= br> >
> What do you think?


That sounds like a fine approach. Thanks for digging that reference up. :)<= br>
/a


<= 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. --000000000000b9941f0590d06b1f-- From nobody Fri Aug 23 15:38:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1772612006A for ; Fri, 23 Aug 2019 15:38:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gMUD0baB5eZk for ; Fri, 23 Aug 2019 15:38:09 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 3690A12002E for ; Fri, 23 Aug 2019 15:38:09 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q22so23680447iog.4 for ; Fri, 23 Aug 2019 15:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qu4Y+5Ro1r15/MKOr1pCpWea63xbo0HCsOdwuokTzpw=; b=XYdUUu2lDa25u3ANcGu1Z/UJDuIAJNPoPQOm6cQsks+qlHd2te24RkInzFAOt+e0CE 2rD2K0VvVVUfNh1KNDV2jAPGZpTftaykzfTUVu02GcN2MngHjWNw/xLbdgUE8ycie1rl I2lJg2lcs1fzxIrGvBV7E3Ko/coPhV8POIEpY= 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=Qu4Y+5Ro1r15/MKOr1pCpWea63xbo0HCsOdwuokTzpw=; b=bdVn+UuyvbSJYDS1UlyiNvkXo/9nzTqYfU8TstBvEcOCzblT4wbadj35ACtnbJf9gO IMlmOYmwpd0aPrWY0x1VjYRzbY9P7erVBlrpBWiKlXmzYBclNomRhzPtkQofuNTmnTSN EvOd8t4ZG55p4GVVGI9/loS2E9TvxOq3FdS0HlX8itf01ySyySoGl7SMeI585vJMQxci 4Q4yLrmh2swpBHRRiAVVojIf2CYndmHs8K9wNLZFij41mYcEmCblYAlfAyQEOD57X+nO vKnuBfbwzyvvgupMwClRJv1LUXvvdlv61sm19t2R5Kbc5gbjbH7B2h5fwsUxNSf3XlWO X2qw== X-Gm-Message-State: APjAAAUV6HjvuUgqseedDWFpV81YQ36nn8YWqGYh0TQ16730QilNZ+X9 Uu2Xh67LTfhcKx+RbPLLm5YpsvicrcAl16/ML5T0+4iCu9BOyxfdfOlEx0F8IQ0fxyxhVVm79fu zSGc+vK1n1m2BUw== X-Google-Smtp-Source: APXvYqztYCYfraTB4FeiH7aI1eUFvyuz4Xxc7wnXTGd1652pVighWl+2wxiuoZCQ3FUxDYHzvvfy6MJPM2RNTZUYjDA= X-Received: by 2002:a6b:cdcc:: with SMTP id d195mr10611482iog.78.1566599888409; Fri, 23 Aug 2019 15:38:08 -0700 (PDT) MIME-Version: 1.0 References: <156632859162.350.2919813913771406915.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 23 Aug 2019 16:37:42 -0600 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-oauth-mtls@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000dab00e0590d07551" Archived-At: Subject: Re: [OAUTH-WG] Suresh Krishnan's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:38:12 -0000 --000000000000dab00e0590d07551 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again for the suggestion Suresh. The switch to use RFC5952 is now in the document https://tools.ietf.org/html/draft-ietf-oauth-mtls-17 On Wed, Aug 21, 2019 at 3:51 PM Brian Campbell wrote: > Thanks Suresh, I'll consider using RFC5952 there as I try and work though > some other comments on that parameter in that section. > > On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker < > noreply@ietf.org> wrote: > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> * Section 2.1.2. >> >> Suggest using the IPv6 Address Text Representation described in RFC5952 >> instead >> of using the representations described in RFC4291 section 2.2. The >> canonical >> representation described in RFC5952 makes it easier to compare two IPv6 >> address >> strings which is probably something you want to do while doing mutual >> authentication. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000dab00e0590d07551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again for the suggestion Suresh. The switch to= use RFC5952 is now in the document https://tools.ietf.org/html/dra= ft-ietf-oauth-mtls-17


=C2= =A0

On Wed, Aug 21, 2019 at 3:51 PM Brian Campbell <bcampbell@pingidentity.com>= wrote:
Thanks Suresh, I'll consider using RFC5952 there as I try= and work though some other comments on that parameter in that section.

On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker <noreply@ietf.org> wr= ote:

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 2.1.2.

Suggest using the IPv6 Address Text Representation described in RFC5952 ins= tead
of using the representations described in RFC4291 section 2.2. The canonica= l
representation described in RFC5952 makes it easier to compare two IPv6 add= ress
strings which is probably something you want to do while doing mutual
authentication.


_______________________________________________
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. --000000000000dab00e0590d07551-- From nobody Fri Aug 23 15:39:06 2019 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 C58A612000F; Fri, 23 Aug 2019 15:38:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156659993772.24954.17223748128318841872.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2019 15:38:57 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-mtls-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 22:38:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-mtls-17: 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-mtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment!) points! From nobody Mon Aug 26 03:48:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98D4120111 for ; Mon, 26 Aug 2019 00:42:58 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=logius.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nKDhtdDqPal for ; Mon, 26 Aug 2019 00:42:55 -0700 (PDT) Received: from mail2.ssonet.nl (mail2.ssonet.nl [147.181.98.131]) (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 7765312010F for ; Mon, 26 Aug 2019 00:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=logius.nl; i=@logius.nl; q=dns/txt; s=Selector2; t=1566805375; x=1598341375; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=8otYwTngUSOmZD4hilkJjAR66GBWRACLy2b/V2RMQ9M=; b=DKhdIqiDcm0pBdSTybhDi72ls0VPPrzDs0XKt8Pb86pqYh53pDFtdV2p 9+D7aYNTmovHS1nEhdfmC2q02voFo2GBOzS2GEV2zVUCWHX5PsSuGZCha dtf/YbHFOz0ziNaxS98cCKZSSmdbZFqp+at74KrvYwzJtLtyOmhA7zwWT phl7LL4+p0GykGHJZVDf0DBq7vSNquHuIUNh3kW/3xY2Goy6DPRwvQ3q1 g2uWTyX+IzQFTQqOwerdiAeZ7nqYkq1GzQ3GcYQ4J132CVIkEhtXeLx7U o3M+7oxnwdff2F8druQSjmLMoPH88sbZhEUaCk2+5WL8pc4uLKp27SxxT w==; IronPort-SDR: Xol7tYQj8l87HhhW8HMqCM8M7+NJ/ClCrSscPVkq2G6295QgdKkZG9LIWQAHJO3j8mrjk6r0X1 1969LqhVjI3Q== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ERAABFjWNd/8HfK5BkGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgUQpKoFgEioKhBeRE5ktgWQJAQEBDi0?= =?us-ascii?q?CAQGEPwIXglEjNwYNAQIKAQEBAQMBAQEBAQYDAQEBAmmEa06COikBgmcBAQE?= =?us-ascii?q?BAgEjETMSBQsCAQgNCwICJgICAjAVEAIEDgUIhRYPAadCgTIaih2BDCgBhHy?= =?us-ascii?q?EBCiEIj6EIz6ELoMhglgEjBwgE4JKnFEHAgKCHoweiB0jjWoDimKjVoJggWY?= =?us-ascii?q?jRIEUfDoPex2BJimCem8BAY0cQTGBKYxYAYEgAQE?= X-IPAS-Result: =?us-ascii?q?A2ERAABFjWNd/8HfK5BkGQEBAQEBAQEBAQEBAQcBAQEBA?= =?us-ascii?q?QGBVgEBAQEBAQsBgUQpKoFgEioKhBeRE5ktgWQJAQEBDi0CAQGEPwIXglEjN?= =?us-ascii?q?wYNAQIKAQEBAQMBAQEBAQYDAQEBAmmEa06COikBgmcBAQEBAgEjETMSBQsCA?= =?us-ascii?q?QgNCwICJgICAjAVEAIEDgUIhRYPAadCgTIaih2BDCgBhHyEBCiEIj6EIz6EL?= =?us-ascii?q?oMhglgEjBwgE4JKnFEHAgKCHoweiB0jjWoDimKjVoJggWYjRIEUfDoPex2BJ?= =?us-ascii?q?imCem8BAY0cQTGBKYxYAYEgAQE?= X-IronPort-AV: E=McAfee;i="6000,8403,9360"; a="14195008" X-IronPort-AV: E=Sophos;i="5.64,431,1559512800"; d="scan'208";a="14195008" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False From: "Schaar, R.M. (Remco) - Logius" To: 'Torsten Lodderstedt' CC: "'oauth@ietf.org'" Thread-Topic: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AQHVVPNIj99CrYifUEuqB+4o77upAKcHR81A Date: Mon, 26 Aug 2019 07:42:51 +0000 Message-ID: <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> In-Reply-To: <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [144.43.223.38] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: X-Mailman-Approved-At: Mon, 26 Aug 2019 03:48:43 -0700 Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 07:42:59 -0000 SGVsbG8gVGhvcnN0ZW4sDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZS4gSSBoYXZlIGEg ZmV3IG1vcmUgcXVlc3Rpb25zL2NvbW1lbnRzIGFzDQpmb2xsb3ctdXAuLi4NCg0KWW91IHN0YXRl IHRoYXQgUkZDNzUxOSBhbmQgUkZDNzY2MiAianVzdCIgZGVmaW5lIGRpZmZlcmVudCByZXByZXNl bnRhdGlvbnMNCmZvciB0b2tlbiBkYXRhLiBJZiB0aGUgZHJhZnQgUkZDIHdvdWxkIHJlZmVyIHRv IFJGQyA3NTE1IChKV1MpLCBJIHdvdWxkDQphZ3JlZS4gSG93ZXZlciwgUkZDNzUxOSAoSldUKSBl eHBsaWNpdGx5IGFkZHMgc2VtYW50aWNzIHRvIHNvbWUgc3BlY2lmaWMNCnBhcmFtZXRlcnMgKGUu Zy4gYXVkLCBqdGkgYW5kIGlhdCkuIFJGQzc2NjIgaGFzIGRpZmZlcmVudCBzZW1hbnRpY3MgZm9y DQp0aGUgc2V2ZXJhbCBvZiB0aGUgc2FtZSBwYXJhbWV0ZXJzLg0KRm9yIGluc3RhbmNlIHRoZSAn aWF0JywgaXMgdGhlIG1vbWVudCBvZiBpc3N1YW5jZSBvZiB0aGUgSldUIGluIFJGQzc1MTkuIElu DQpSRkM3NjYyIHRoYXQgaXMgdGhlICJ3aGVuIHRoaXMgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNz dWVkIi4gVGhpcyB0aW1lIHdpbGwNCnZhcnkgaW4gdXNlIGNhc2VzIHdpdGhvdXQgaW1tZWRpYXRl IGludHJvc3BlY3Rpb24gb2YgYW4gYWNjZXNzIHRva2VuLg0KDQpGb3IgdGhlIHVzZSBjYXNlIG9m IHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmVseWluZyBvbiB2ZXJpZmlhYmxlIGRhdGEsIGFzDQpkZXNj cmliZWQgaW4gdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZHJhZnQgUkZDLCB0aGUgdGltZSBvZiB0 aGUgaW50cm9zcGVjdGlvbg0KaXMgY3JpdGljYWwuIEluIHBhcnRpY3VsYXIgd2hlbiBjb21iaW5l ZCB3aXRoIHJldm9jYXRpb24sIHRoZSB0aW1lIG9mDQppbnRyb3NwZWN0aW9uIGFuZCB0aGUgJ2Fj dGl2ZScgc3RhdHVzIGNhbiBkaWZmZXIgYmV0d2VlbiB0d28gc3Vic2VxdWVudCBjYWxscw0KZm9y IGludHJvc3BlY3Rpb24uDQoNCklmIHRoZSBkcmFmdCBSRkMganVzdCBwcm9kdWNlcyBhIEpXVCBy ZXByZXNlbnRhdGlvbiBvZiB0aGUgYWNjZXNzIHRva2VuLA0KaW5jbHVkaW5nICdhY3RpdmUnIHdv dWxkIG5vdCBtYWtlIHNlbnNlIGFzIHRoZSBKV1Qgd2lsbCBleHBpcmUgd2l0aG91dA0KdXBkYXRp bmcgaXQgdG8gZmFsc2UuIExlYXZpbmcgJ2FjdGl2ZScgb3V0IHdvdWxkIG1ha2UgaXQgaW5jb21w YXRpYmxlIHdpdGgNClJGQzc2NjIgaW50cm9zcGVjdGlvbiByZXNwb25zZXMuDQpTaW1pbGFyLCBu b3QgaW5jbHVkaW5nIGEgdW5pcXVlICdqdGknIHBlciBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIHdv dWxkIG1ha2UNCnRoZSByZXNvdXJjZSBzZXJ2ZXIgdnVsbmVyYWJsZSB0byByZXBsYXkgYXR0YWNr cy4gT3IgdGhlIHJlc291cmNlIHNlcnZlcg0Kd291bGQgbWlzdGFrZW5seSByZWZlciB0byBub24t dW5pcXVlIHRva2VucywgbWFraW5nIHRoZSByZXNwb25zZXMgdW5zdWl0YWJsZQ0KZm9yIGFjY291 bnRhYmlsaXR5IGFuZCBhdWRpdCBwdXJwb3Nlcy4NCg0KDQpBcyB0byB3aHkgc29tZW9uZSB3b3Vs ZCB3YW50IHRvIGRpc3Rpbmd1aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBmcm9tIGFuDQppbnRyb3Nw ZWN0aW9uIHJlc3BvbnNlOiBzZXZlcmFsIHVzZSBjYXNlcyBjb21lIHRvIG1pbmQuDQoNCkZpcnN0 IG9mIGFsbCwgZXZlbiBpZiBvbmUgaXMgdXNpbmcgc3RhbmRhbG9uZSBpbnRlcnByZXRhYmxlIEpX VCBhY2Nlc3MgdG9rZW5zLA0Kb25lIG1heSB3YW50IHRvIGNvbWJpbmUgdGhhdCB3aXRoIHJldm9j YXRpb24gY2hlY2tpbmcgdXNpbmcgaW50cm9zcGVjdGlvbi4gVGhlDQppbnRlcnByZXRhdGlvbiBh bmQgbWVhbmluZyBvZiB0aGUgSldUIGFuZCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFu IGRvDQpkaWZmZXIgYW5kIG1hdHRlci4NCg0KQW5vdGhlciB1c2UgY2FzZSB3b3VsZCBiZSBhIG1p eGVkIGVjb3N5c3RlbSB3aXRoIHJlc291cmNlIHNlcnZlcnMgcmVseWluZyBvbg0KaW50cm9zcGVj dGlvbiB3aGlsZSBvdGhlcnMgZG8gcGFyc2UgSldUIGFjY2VzcyB0b2tlbnMuIEEgc2luZ2xlLCB1 bmlmb3JtDQppbXBsZW1lbnRhdGlvbiBmb3IgdGhlIEFTIHdvdWxkIHRoYW4gbWl4IGJvdGggYXMg d2VsbC4NCg0KQSBsYXN0IHVzZSBjYXNlIGNvdWxkIGJlIGV4Y2hhbmdpbmcgYWNjZXNzIHRva2Vu cyB3aXRoIGEgc3Vic2V0IG9mIHRoZSBmdWxsDQpzZXQgb2YgYXBwbGljYWJsZSBwYXJhbWV0ZXJz LCB0byByZWR1Y2UgdGhlIHNpemUgb2YgYWNjZXNzIHRva2Vucy4gQWRkaXRpb25hbA0KaW5mb3Jt YXRpb24gY2FuIGJlIGV4Y2hhbmdlZCB2aWEgaW50cm9zcGVjdGlvbiwgcmVzdWx0aW5nIGluIG1p eGVkIEpXVCBhY2Nlc3MNCnRva2VucyBhbmQgaW50cm9zcGVjdGlvbiBhcyB3ZWxsLg0KDQpLaW5k IHJlZ2FyZHMsDQpSZW1jbyBTY2hhYXINCg0KLS0tLS1Pb3JzcHJvbmtlbGlqayBiZXJpY2h0LS0t LS0NClZhbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IA0K VmVyem9uZGVuOiB6YXRlcmRhZyAxNyBhdWd1c3R1cyAyMDE5IDE0OjAwDQpBYW46IFNjaGFhciwg Ui5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hhYXJAbG9naXVzLm5sPg0KQ0M6IG9hdXRo QGlldGYub3JnDQpPbmRlcndlcnA6IFJlOiBbT0FVVEgtV0ddIFF1ZXN0aW9uIHJlZ2FyZGluZyBk cmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA1DQoNCkhpIFJlbWNv LA0KDQo+IE9uIDYuIEF1ZyAyMDE5LCBhdCAxNjowMSwgU2NoYWFyLCBSLk0uIChSZW1jbykgLSBM b2dpdXMgPHJlbWNvLnNjaGFhckBsb2dpdXMubmw+IHdyb3RlOg0KPiANCj4gSGVsbG8sDQoNClsu Li5dDQpSRkMgNzUxOSBhbmQgUkZDIDc2NjIg4oCcanVzdOKAnSBkZWZpbmUgZGlmZmVyZW50IHJl cHJlc2VudGF0aW9ucyBmb3IgdG9rZW4gZGF0YS4gSW4gUkZDIDc1MTkgdGhlIGRhdGEgaXMgY2Fy cmllZCBpbiB0aGUgdG9rZW4gaXRzZWxmICh3aGljaCBhbHNvIG1lYW5zIHRoZSBmb3JtYXQgb2Yg dGhlIHRva2VuIGlzIHdlbGwtZGVmaW5lZCBhbmQga25vdyB0byB0aGUgUlMpIHdoZXJlYXMgUkZD IDc2NjIgZGVmaW5lcyBhIHdheSB0byBpbnNwZWN0IHRva2VucyB2aWEgYW4gQVBJIHByb3ZpZGVk IGJ5IHRoZSBBUy4gVGhlIGxhdHRlciBpcyB0eXBpY2FsbHkgdXNlZCBpbiBjb25qdW5jdGlvbiB3 aXRoIG9wYXF1ZSB0b2tlbnMsIGkuZS4gdGhlIFJTIGRvZXMgbm90IGhhdmUgYSBjbHVlIGhvdyB0 byBwYXJzZSBhbmQgaW50ZXJwcmV0IHRoZSB0b2tlbi4gVGhlIHRva2VuIG1pZ2h0IGp1c3QgYmUg YSBoYW5kbGUgdG8gYSBkYXRhYmFzZSBlbnRyeSBhdCB0aGUgQVMgaW4gdGhpcyBjYXNlLiANCg0K VGhpcyBhbHNvIG1lYW5zIGEgSldUIChSRkMgNzY2MikgYW5kIHRoZSBJbnRyb3NwZWN0aW9uIFJl c3BvbnNlIGFyZSBjb25jZXB0dWFsbHkgdGhlIHNhbWUgZnJvbSBhIFJTcyBwZXJzcGVjdGl2ZS4N Cg0KWy4uLl0NCg0KPiBUaGUg4oCYanRp4oCZIHBhcmFtZXRlciBob3dldmVyIHdpbGwgYWx3YXlz IGJlIGFtYmlndW91cy4gQXMgaXQgaXMgYW4gaWRlbnRpZmllciwgaXQgc2hvdWxkIGRpZmZlciBm b3IgdGhlIGludHJvc3BlY3RlZCB0b2tlbiBhbmQgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ug YnkgZGVmaW5pdGlvbi4gSGVuY2UgdGhlIHNlbWFudGljcyBvZiDigJhqdGnigJkgaW4gYSBKV1Qg aW50cm9zcGVjdGlvbiByZXNwb25zZSBpcyB1bmNsZWFyLiBUaGUgc2FtZSBjYW4gYXBwbHkgdG8g dGhlIOKAmGlhdOKAmSwg4oCYbmJm4oCZIGFuZCDigJhleHDigJkgY2xhaW1zIGluIGEgSldUIGlu dHJvc3BlY3Rpb24gcmVzcG9uc2UuDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJl bmNlIHlvdSBhcmUgbWFraW5nLiBBbGwgYmVmb3JlIG1lbnRpb25lZCBjbGFpbXMgYXJlIHJlbGF0 ZWQgdG8gdGhlIChhYnN0cmFjdCkgYWNjZXNzIHRva2VuLiBZb3UgbWF5IHRoaW5rIG9mIHRoZSBJ bnRyb3NwZWN0aW9uIFJlc3BvbnNlIGFzIF90aGVfIEpXVCByZXByZXNlbnRhdGlvbiBvZiB0aGUg YWNjZXNzIHRva2VuIHByb2R1Y2VkIGJ5IHRoZSBBUyBmb3IgdGhlIFJTLg0KDQo+ICANCj4gQ2Fu IHNvbWVvbmUgY2xhcmlmeSB0aGUgc2VtYW50aWNzIG9mIGNsYWltcyBpbiBhbiBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIEpXVCB0aGF0IGFyZSBkZWZpbmVkIGluIGJvdGggUkZDNzY2MiBhbmQgUkZD NzUxOT8NCj4gIA0KPiBGdXJ0aGVybW9yZSwgdGhlIGludHJvc3BlY3Rpb24gcmVzcG9uc2Ugc2hv dWxkIHVzZSB0aGUg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgY2xhaW1zIHRvIGF2b2lkIGNyb3Nz LUpXVCBjb25mdXNpb24gKHNlY3Rpb24gNi4xKS4gVGhlIOKAmGlzc+KAmSBhbmQg4oCYYXVk4oCZ IG9mIGFuIGludHJvc3BlY3RlZCB0b2tlbiB3aWxsIHR5cGljYWxseSBiZSB0aGUgc2FtZSBhcyB0 aG9zZSBvZiB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZS4gSGVuY2UgYSBKV1QgYWNjZXNzIHRv a2VuIGNhbm5vdCBiZSBkaXN0aW5ndWlzaGVkIGZyb20gYW4gaW50cm9zcGVjdGlvbiByZXNwb25z ZSB1c2luZyDigJhpc3PigJkgYW5kIOKAmGF1ZOKAmSBhcyBzdWdnZXN0ZWQgaW4gdGhlIGRyYWZ0 Li4NCj4gIA0KPiBJbnRyb3NwZWN0aW9uIHJlZmVycyB0byBKV1QgYmVzdC1jdXJyZW50LXByYWN0 aWNlLiBUaGUgZHJhZnQgQkNQIHJlY29tbWVuZHMgdXNpbmcgZXhwbGljaXQgdHlwaW5nIG9mIEpX VHMsIGhvd2V2ZXIgdGhlIGRyYWZ0IEpXVCByZXNwb25zZSBmb3IgaW50cm9zcGVjdGlvbiBkb2Vz IG5vdCBhcHBseSB0aGlzIHJlY29tbWVuZGF0aW9uIGFuZCB1c2VzIHRoZSBnZW5lcmljIOKAmGFw cGxpY2F0aW9uL2p3dOKAmSBpbnN0ZWFkLi4uIFRoZSBCQ1AgaGFzIG90aGVyIHJlY29tbWVuZGF0 aW9ucyBpbiBzZWN0aW9uIDMuMTIsIGJ1dCB0aGVzZSBtYXkgYmUgaW5zdWZmaWNpZW50IHRvIGRp c3Rpbmd1aXNoIGEgSldUIGFjY2VzcyB0b2tlbiBmcm9tIGEgSldUIGludHJvc3BlY3Rpb24gcmVz cG9uc2UuDQoNCkdvb2QgcG9pbnQuIFRoZSByZWFzb24gd2h5IHRoZSBCQ1AgcmVjb21tZW5kcyBl eHBsaWNpdCB0eXBpbmcgaXMgdG8gcHJldmVudCByZXBsYXkgaW4gb3RoZXIgY29udGV4dHMuIElu IHRoZSBlbmQgdHlwaW5nIGlzIGEgY29tcGVsbGluZyBjb25jZXB0IHVuZm9ydHVuYXRlbHkgbm90 IGJyb2FkbHkgdXNlZCBpbiB0aGUgd2lsZC4NCg0KU28gdGhlIEpXVCBJbnRyb3NwZWN0aW9uIFJl c3BvbnNlIGRyYWZ0IGNvcGVzIHdpdGggdGhhdCBhdHRhY2sgYW5nbGUgYnkgbWFraW5nIGlzcyBh bmQgYXVkIG1hbmRhdG9yeS4gDQoNCg0KPiAgDQo+IEhvdyB3b3VsZCBwZW9wbGUgc3VnZ2VzdCB0 byBiZXN0IGRpc3Rpbmd1aXNoIGEgSldUIChhY2Nlc3MpIHRva2VuIGZyb20gYSBKV1QgaW50cm9z cGVjdGlvbiByZXNwb25zZT8NCg0KV2h5IHNob3VsZCB5b3U/IE9uZSByZWFzb24gd2h5IHdlIGV4 dGVuZGVkIHRoZSBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIHdhcyB0byBlbGltaW5hdGUgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBKV1RzIGRpcmVjdGx5IHVzZWQgYXMgYWNjZXNzIHRva2VucyBhbmQg SW50cm9zcGVjdGlvbiBSZXNwb25zZXMuDQoNCmJlc3QgcmVnYXJkcywNClRvcnN0ZW4uIA0KDQoN CkRpdCBiZXJpY2h0IGthbiBpbmZvcm1hdGllIGJldmF0dGVuIGRpZSBuaWV0IHZvb3IgdSBpcyBi ZXN0ZW1kLiBJbmRpZW4gdSBuaWV0IGRlIGdlYWRyZXNzZWVyZGUgYmVudCBvZiBkaXQgYmVyaWNo dCBhYnVzaWV2ZWxpamsgYWFuIHUgaXMgdG9lZ2V6b25kZW4sIHdvcmR0IHUgdmVyem9jaHQgZGF0 IGFhbiBkZSBhZnplbmRlciB0ZSBtZWxkZW4gZW4gaGV0IGJlcmljaHQgdGUgdmVyd2lqZGVyZW4u IERlIFN0YWF0IGFhbnZhYXJkdCBnZWVuIGFhbnNwcmFrZWxpamtoZWlkIHZvb3Igc2NoYWRlLCB2 YW4gd2Vsa2UgYWFyZCBvb2ssIGRpZSB2ZXJiYW5kIGhvdWR0IG1ldCByaXNpY28ncyB2ZXJib25k ZW4gYWFuIGhldCBlbGVrdHJvbmlzY2ggdmVyemVuZGVuIHZhbiBiZXJpY2h0ZW4uDQpUaGlzIG1l c3NhZ2UgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub3QgaW50ZW5kZWQgZm9yIHlv dS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvciBpZiB0aGlzIG1lc3NhZ2Ugd2FzIHNl bnQgdG8geW91IGJ5IG1pc3Rha2UsIHlvdSBhcmUgcmVxdWVzdGVkIHRvIGluZm9ybSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UuIFRoZSBTdGF0ZSBhY2NlcHRzIG5vIGxpYWJpbGl0 eSBmb3IgZGFtYWdlIG9mIGFueSBraW5kIHJlc3VsdGluZyBmcm9tIHRoZSByaXNrcyBpbmhlcmVu dCBpbiB0aGUgZWxlY3Ryb25pYyB0cmFuc21pc3Npb24gb2YgbWVzc2FnZXMuCg== From nobody Mon Aug 26 12:04:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EDE120C9C for ; Mon, 26 Aug 2019 12:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9dxujcCbW4n1 for ; Mon, 26 Aug 2019 12:04:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3381200FF for ; Mon, 26 Aug 2019 12:04:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A7DADB80BB9; Mon, 26 Aug 2019 12:04:27 -0700 (PDT) To: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bayard.bell@twosigma.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190826190427.A7DADB80BB9@rfc-editor.org> Date: Mon, 26 Aug 2019 12:04:27 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 19:04:43 -0000 The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5848 -------------------------------------- Type: Technical Reported by: Bayard Bell Section: Appendix B.1 Original Text ------------- Apps can initiate an authorization request in the browser, without the user leaving the app, through the "SFSafariViewController" class or its successor "SFAuthenticationSession", which implement the in- app browser tab pattern. Safari can be used to handle requests on old versions of iOS without in-app browser tab functionality. Corrected Text -------------- Apps can initiate an authorization request in the browser, without the user leaving the app, through the "ASWebAuthenticationSession" class or its successors "SFAuthenticationSession" and "SFSafariViewController", which implement the in-app browser tab pattern. The first of these allows calls to a handler registered for the AS URL, consistent with Section 7.2. The latter two classes, now deprecated, can use Safari to handle requests on old versions of iOS without in-app browser tab functionality. Notes ----- SFAuthenticationSession documentation reflects deprecated status: https://developer.apple.com/documentation/safariservices/sfauthenticationsession Here's the documentation for ASWebAuthenticationSession: https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Aug 26 13:46:43 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8512011C for ; Mon, 26 Aug 2019 13:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToqS3ebkYSCV for ; Mon, 26 Aug 2019 13:46:38 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::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 A4B4E12004D for ; Mon, 26 Aug 2019 13:46:38 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id y8so13205003oih.10 for ; Mon, 26 Aug 2019 13:46:38 -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=slSseVzVNhhqI2kmi/M10IDs6rOFwfr+LM2V/kbP7to=; b=bWp5LuDJfESDywAYr4/sB0DcBgOxpNeZt+0FmtrfVsfb4E/R9jwPr7At19rw9Do6yW WOPupZu8sM42u/HayYuBs1LUtqCNqypLNY/0ePM4x9tkGPs5WQVy+XEo32r6zSVgikRr 7hMj898QlPuMkz32S5/+XikIuFjBUzVvnMFLlgIR+SGSwyqFOkLXt+rbv7LCmHaC4hwp 33ap4Yo/PBzvE/KVAoivwnqR/8qAXfdr8d5uGQ4+6NCCyypNYeoYnztQDWpSAaS2oLGW KWC3uSRCZLBZ8iBKcau5s7o4iqoJY4Fzi8/VV/Pp5QYn0bDZy9vTdmqyVnUI/GWlf1LD Mf8A== 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=slSseVzVNhhqI2kmi/M10IDs6rOFwfr+LM2V/kbP7to=; b=r39sDuXvjAfaOy8WmfkSmgWokGQQoClcQy476KvHe+ryTXH/TykT8k/ikcWZnuYO7C PLPDuQzTzNJ3VMFyZ4mFJlmazdmgtvJ91JRi1eoFhVV6kMbnCvSTVx1RxJaZldaeAhZc s26QpOA4AzRA382k9gVHAmvruM+dj+ewuOkykA++g+1Ce/GAU++6Kc50bkYfCQiEEC1c UxIYlaImuu8RIxWfGetUyfZEA2wXcEGc9Wxl7OMmi0UVNwFQC6FZH+sRTFnbPYCiPq7F TLHyy6v77Riu7iw08qfV7PlQTrTaTn8/czuCxnSsJqOrEJHl4Wk9qVRPWR7mfntyVQBn x21w== X-Gm-Message-State: APjAAAUU1pV/Aa2c6q0fiBdsSaOTVF3HsZGf6WYq7DuYnFwhQ43c15DG FyqX2JAhxbWLFRdeyPCq87iYmZFvpwx+HpxLwKVfOA== X-Google-Smtp-Source: APXvYqz9Y3IBgdI+yMYF1jFOlttbzv6+chUN+iR9e0ofXTi8evJdVurDDOqkicNWOWfy66BWExEpVBagFX679iFz+RA= X-Received: by 2002:a05:6808:198:: with SMTP id w24mr13644933oic.53.1566852397442; Mon, 26 Aug 2019 13:46:37 -0700 (PDT) MIME-Version: 1.0 References: <20190826190427.A7DADB80BB9@rfc-editor.org> In-Reply-To: <20190826190427.A7DADB80BB9@rfc-editor.org> From: William Denniss Date: Mon, 26 Aug 2019 13:46:25 -0700 Message-ID: To: RFC Errata System Cc: Hannes Tschofenig , bayard.bell@twosigma.com, Benjamin Kaduk , oauth , Roman Danyliw , rfc8252@ve7jtb.com, rfc8252@wdenniss.com, Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary="00000000000091125805910b40b5" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:46:41 -0000 --00000000000091125805910b40b5 Content-Type: text/plain; charset="UTF-8" Process-wise I'm not sure if errata should be used to capture changing implementation details like this. We expected the implementation details that we documented in the appendix to change, and explicitly stated that assumption. "The implementation details herein are considered accurate at the time of publishing but will likely change over time.". If updating those implementation details were in scope, then the proposed text should needs to be revised before being accepted due to some inaccuracies (e.g. SFSafariViewController is not a successor to ASWebAuthenticationSession). Best, William On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5848 > > -------------------------------------- > Type: Technical > Reported by: Bayard Bell > > Section: Appendix B.1 > > Original Text > ------------- > Apps can initiate an authorization request in the browser, without > the user leaving the app, through the "SFSafariViewController" class > or its successor "SFAuthenticationSession", which implement the in- > app browser tab pattern. Safari can be used to handle requests on > old versions of iOS without in-app browser tab functionality. > > Corrected Text > -------------- > Apps can initiate an authorization request in the browser, without > the user leaving the app, through the "ASWebAuthenticationSession" > class or its successors "SFAuthenticationSession" and > "SFSafariViewController", which implement the in-app browser tab > pattern. The first of these allows calls to a handler registered > for the AS URL, consistent with Section 7.2. The latter two classes, > now deprecated, can use Safari to handle requests on old versions of > iOS without in-app browser tab functionality. > > Notes > ----- > SFAuthenticationSession documentation reflects deprecated status: > > > https://developer.apple.com/documentation/safariservices/sfauthenticationsession > > Here's the documentation for ASWebAuthenticationSession: > > > https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000091125805910b40b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Process-wise I'm not sure if errata s= hould be used to capture changing implementation details like this. We expe= cted the implementation details that we documented in the appendix to chang= e, and explicitly stated that assumption. "The implementation details = herein are considered accurate at the time=C2=A0of publishing but will like= ly change over time.".

If updating those implementa= tion details were in scope,=C2=A0then the proposed text should needs to be = revised before being accepted due to some inaccuracies (e.g. SFSafariViewCo= ntroller is not a successor to=20 ASWebAuthenticationSession).

Best,
William

On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System <rfc-editor@rfc-edit= or.org> wrote:
The following errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5848

--------------------------------------
Type: Technical
Reported by: Bayard Bell <bayard.bell@twosigma.com>

Section: Appendix B.1

Original Text
-------------
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" cl= ass
or its successor "SFAuthenticationSession", which implement the i= n-
app browser tab pattern.=C2=A0 Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality.

Corrected Text
--------------
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"= ;
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab<= br> pattern.=C2=A0 The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes
-----
SFAuthenticationSession documentation reflects deprecated status:

https://developer.ap= ple.com/documentation/safariservices/sfauthenticationsession

Here's the documentation for ASWebAuthenticationSession:

https://d= eveloper.apple.com/documentation/authenticationservices/aswebauthentication= session

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8252 (draft-ietf-oauth-native-apps-12)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 for= Native Apps
Publication Date=C2=A0 =C2=A0 : October 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: W. Denniss, J. Bradley<= br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : BEST CURRENT PRACTICE Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authorization = Protocol
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000091125805910b40b5-- From nobody Tue Aug 27 03:52:03 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1121712021C for ; Tue, 27 Aug 2019 03:52:00 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OcdC_9tuZAhw for ; Tue, 27 Aug 2019 03:51:56 -0700 (PDT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 A38D912004A for ; Tue, 27 Aug 2019 03:51:56 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id i63so2500528wmg.4 for ; Tue, 27 Aug 2019 03:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GEbvp8MXAlyqwo36eCQTpPEQxoMnfDCvSDq+TJc+psI=; b=qwr7bqkJdNXoVj0o8pPdqUgzTCZUMS/rWnRrc+OCPSzh5EonUg/8PbSTzxqMilpVDO oHo0IL1MPVafRMsGdBxRysPDbqoMSpDA+/8LcThEllmrMkuCSMcg1xtZnVBaMZTss2is NaTHuz6Qim/1EAXMgcD36xYLIJuAg3aO1Faw4rbZqk0SDw79EF3vY0C+a6QWq82AjOgp OWSO7sVoZreg0mYiEA1HGNl/Zhfb3MbFIjlASUj/vwkhAHfqptTroj5GnUrcUyIf9P/o jflHySsbFelDghLgVWLVKtltyyOze84LM6tDTwqykLssyGT2B7xVCmOLZgUVFqb1mJcs mbDg== 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=GEbvp8MXAlyqwo36eCQTpPEQxoMnfDCvSDq+TJc+psI=; b=GHG0L6V/B0p7Dj5zhto9KNaAIpKOuDFSKOOdGChVExdaUKXFnYrJcU9/qfrNrI6a9A gzY/012s3AjexDqZTpdXcsO5qFaJqVsBnAa20rX5AbxSCB1oAofJSV64/jgEz0OIBoja SIYVjKUmqzk5KDKovR9vnmS9Du3yFKvZoCVdcZUg/vbRXQthdWcnB35++p/DMUIh1yTO 1/b2U+L+nSaLoRN4DcDh2q6UO2RxhuNr+My9TuSot+guzQRbmCnd3zK4fkd6fcMlf6Cd HPuMn3XVtUqLw63c/BHdfignOUCxzK0L67PYyshEy+e7VDBJdJC+UryoHaT72S7LC3Wy 9YAw== X-Gm-Message-State: APjAAAUp1t91eueHl7suPzqYDNbJINEE4GqksgMjX0YBIw2R4ZoW2jzq 15QGeHToUixZ2uydfgcEV712HLAJq7tFOAN1vp622w== X-Google-Smtp-Source: APXvYqzT8ybrCE9gTGb8Gv0LwrHkVzQ6QPZsNZHvDO76Y8QGIdpAdSEZLLmPkeUEPjNitxQ5JTVZJqqZZXv69jNtJqs= X-Received: by 2002:a05:600c:2111:: with SMTP id u17mr28921228wml.64.1566903114687; Tue, 27 Aug 2019 03:51:54 -0700 (PDT) MIME-Version: 1.0 References: <20190826190427.A7DADB80BB9@rfc-editor.org> In-Reply-To: From: John Bradley Date: Tue, 27 Aug 2019 12:51:42 +0200 Message-ID: To: William Denniss Cc: RFC Errata System , Hannes Tschofenig , bayard.bell@twosigma.com, Benjamin Kaduk , oauth , Roman Danyliw , rfc8252@ve7jtb.com, rfc8252@wdenniss.com, Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary="0000000000008c79510591170fea" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 10:52:00 -0000 --0000000000008c79510591170fea Content-Type: text/plain; charset="UTF-8" This is not really an eratta. Asome point we need to update the BCP with a updated RFC. Perhaps the time is now to start a new draft that can capture the changes in iOS, OSX and others. John B. On Mon, Aug 26, 2019, 10:46 PM William Denniss wrote: > Process-wise I'm not sure if errata should be used to capture changing > implementation details like this. We expected the implementation details > that we documented in the appendix to change, and explicitly stated that > assumption. "The implementation details herein are considered accurate at > the time of publishing but will likely change over time.". > > If updating those implementation details were in scope, then the proposed > text should needs to be revised before being accepted due to some > inaccuracies (e.g. SFSafariViewController is not a successor to > ASWebAuthenticationSession). > > Best, > William > > On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8252, >> "OAuth 2.0 for Native Apps". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5848 >> >> -------------------------------------- >> Type: Technical >> Reported by: Bayard Bell >> >> Section: Appendix B.1 >> >> Original Text >> ------------- >> Apps can initiate an authorization request in the browser, without >> the user leaving the app, through the "SFSafariViewController" class >> or its successor "SFAuthenticationSession", which implement the in- >> app browser tab pattern. Safari can be used to handle requests on >> old versions of iOS without in-app browser tab functionality. >> >> Corrected Text >> -------------- >> Apps can initiate an authorization request in the browser, without >> the user leaving the app, through the "ASWebAuthenticationSession" >> class or its successors "SFAuthenticationSession" and >> "SFSafariViewController", which implement the in-app browser tab >> pattern. The first of these allows calls to a handler registered >> for the AS URL, consistent with Section 7.2. The latter two classes, >> now deprecated, can use Safari to handle requests on old versions of >> iOS without in-app browser tab functionality. >> >> Notes >> ----- >> SFAuthenticationSession documentation reflects deprecated status: >> >> >> https://developer.apple.com/documentation/safariservices/sfauthenticationsession >> >> Here's the documentation for ASWebAuthenticationSession: >> >> >> https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8252 (draft-ietf-oauth-native-apps-12) >> -------------------------------------- >> Title : OAuth 2.0 for Native Apps >> Publication Date : October 2017 >> Author(s) : W. Denniss, J. Bradley >> Category : BEST CURRENT PRACTICE >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000008c79510591170fea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is not really an eratta.=C2=A0 Asome point we need t= o update the BCP with a updated RFC.=C2=A0 =C2=A0Perhaps the time is now to= start a new draft that can capture the changes in iOS, OSX and others.=C2= =A0=C2=A0

John B.=C2=A0
<= /div>
O= n Mon, Aug 26, 2019, 10:46 PM William Denniss <wdenniss@google.com> wrote:
Process-wise I'm not su= re if errata should be used to capture changing implementation details like= this. We expected the implementation details that we documented in the app= endix to change, and explicitly stated that assumption. "The implement= ation details herein are considered accurate at the time=C2=A0of publishing= but will likely change over time.".

If updating th= ose implementation details were in scope,=C2=A0then the proposed text shoul= d needs to be revised before being accepted due to some inaccuracies (e.g. = SFSafariViewController is not a successor to=20 ASWebAuthenticationSession).

Best,
William

On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System <= rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for= RFC8252,
"OAuth 2.0 for Native Apps".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5848
--------------------------------------
Type: Technical
Reported by: Bayard Bell <bayard.bell@twosigma.com>

Section: Appendix B.1

Original Text
-------------
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "SFSafariViewController" cl= ass
or its successor "SFAuthenticationSession", which implement the i= n-
app browser tab pattern.=C2=A0 Safari can be used to handle requests on
old versions of iOS without in-app browser tab functionality.

Corrected Text
--------------
Apps can initiate an authorization request in the browser, without
the user leaving the app, through the "ASWebAuthenticationSession"= ;
class or its successors "SFAuthenticationSession" and
"SFSafariViewController", which implement the in-app browser tab<= br> pattern.=C2=A0 The first of these allows calls to a handler registered
for the AS URL, consistent with Section 7.2. The latter two classes,
now deprecated, can use Safari to handle requests on old versions of
iOS without in-app browser tab functionality.

Notes
-----
SFAuthenticationSession documentation reflects deprecated status:

https://d= eveloper.apple.com/documentation/safariservices/sfauthenticationsession=

Here's the documentation for ASWebAuthenticationSession:

https://developer.apple.com/documentation/authenticationservices/aswebaut= henticationsession

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8252 (draft-ietf-oauth-native-apps-12)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 for= Native Apps
Publication Date=C2=A0 =C2=A0 : October 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: W. Denniss, J. Bradley<= br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : BEST CURRENT PRACTICE Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authorization = Protocol
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000008c79510591170fea-- From nobody Tue Aug 27 04:46:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE15A12008F for ; Tue, 27 Aug 2019 04:46:54 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZG4Ggcg7DIS for ; Tue, 27 Aug 2019 04:46:53 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802D0120073 for ; Tue, 27 Aug 2019 04:46:53 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id f17so18379057otq.4 for ; Tue, 27 Aug 2019 04:46:53 -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=bukYtoPmIjjZcMpta0TD+jY33xZDQLT96XmpaTbv7/0=; b=Ns3YYWMLXHXswiqRFaisdw+bwZ+TQac200TNiE32xC7ki0SyXYB3EXwFABL17n7eLW GgDvWEcUZJ+zSofLButJ8I89fpvFquw+8Cflna2vfxUXZrI6JvgwmP6hpA98nw9YBtlb gJw0sKbU0yiRi5xeV7KX54Vmm5S73b2Pv0uCj/DFkcN7xtjkdNbECAtH+tsQe0cV/Bdw SEazbpxUZqpjG9v0HnH7QU+pcADfg8D4yEKSPLtiyGkRIPcLZh8wLPvtRse4RpUJiue+ vtibl/KDQDzXdXlkIH0h5uc5nY2hE1vBmajSfPVdabMKdn4RNAZU853xjzvXvihu+5Wx zNRw== 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=bukYtoPmIjjZcMpta0TD+jY33xZDQLT96XmpaTbv7/0=; b=H5/XYdERMS0DiC8d7HkdTZQ5uCaXwvTWhtrl2d2a/uVG1EnNkQ5XnUzLGGbA4kpmiO Bd50znXvjn8K3HXmwDtLi7D4PHFOgOfKA5mxyd/KuCrnCBHxIKN1Oh2kBkHuJbPjVk5e Y6Q5eutJQ9hv8kaKmDoIQ13de04j4pGDH3BBNX5ly9pZQ8GkDn2F3NGjGQk+T71beGFC OjVLRelnpxSO3o5WoBvF5nCiz1TQzX3cn336JPqjnmTjd2zkZsaw9duM6hgPhKY7USPY L/zhxOy7h8gr44Tmx72o2zSHp1pBdVUh2yh7kQoZzeNZga/5NWqBhRrfUkmndHyLOTSk Qx8g== X-Gm-Message-State: APjAAAUX7/nDckCYxYcGvAHdFOivPsqsSv9e6XNQCFcSgBteCHjMXwX+ o9c6z8oZZhFW3ioD2YIbYm5xSQBwLf8tTQHdrkyxhWgdkQ== X-Google-Smtp-Source: APXvYqxlekqlO/+rTlukodrIH6ShgxhT510Wn70jw5tJR2W+ZdfAq541IgKs1tiCPEkNJDovrQeNM7AyPXrpZwFxRto= X-Received: by 2002:a05:6830:613:: with SMTP id w19mr18709115oti.362.1566906412525; Tue, 27 Aug 2019 04:46:52 -0700 (PDT) MIME-Version: 1.0 From: Filip Skokan Date: Tue, 27 Aug 2019 13:46:41 +0200 Message-ID: To: oauth , Nat Sakimura , John Bradley Content-Type: multipart/alternative; boundary="0000000000001d7d93059117d442" Archived-At: Subject: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 11:46:55 -0000 --0000000000001d7d93059117d442 Content-Type: text/plain; charset="UTF-8" Hello everyone, in an earlier thread I've posed the following question that might have gotten missed, this might have consequences for the existing implementations of Request Objects in OIDC implementations - its making pure JAR requests incompatible with OIDC Core implementations. draft 14 of jwsreq (JAR) introduced this language The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. > > *However, the authorization server supporting thisspecification MUST only > use the parameters included in the requestobject. * Server MUST only use the parameters in the Request Object even if the > same parameter is provided in the query parameter. The Authorization The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. > > *However, the authorization server supporting thisspecification MUST only > use the parameters included in the requestobject. * Nat, John, everyone - *does this mean a JAR compliant AS ignores everything outside of the request object while OIDC Request Object one merges the two with the ones in the request object being used over ones that are sent in clear?* The OIDC language also includes sections which make sure that some required arguments are still passed outside of the request object with the same value to make sure the request is "valid" OAuth 2.0 request (client_id, response_type), something which an example in the JAR spec does not do. Not having this language means that existing authorization request pipelines can't simply be extended with e.g. a middleware, they need to branch their codepaths. Is an AS required to choose which of the two it follows? Thank you for clarifying this in advance. I think if either the behaviour is the same as in OIDC or different this should be called out in the language to avoid confusion, especially since this already exists in OIDC and likely isn't going to be read in isolation, especially because the Request Object is even called out to be already in place in OIDC in the JAR draft. Best, *Filip* --0000000000001d7d93059117d442 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

in an = earlier thread I've posed the following question that might have gotten= missed, this might have consequences for the existing implementations of R= equest Objects in OIDC implementations - its making pure JAR requests incom= patible with OIDC Core implementations.

draft 14 of jwsreq (JAR) introd= uced this language

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

Server MUST only use the parameters in the Request Obje= ct even if the
same parameter is provided in the query parameter.=C2=A0 = The Authorization

T= he client MAY send the parameters included in the request object
duplica= ted in the query parameters as well for the backward
compatibility etc. = =C2=A0However, the authorization server supporting this
specification= MUST only use the parameters included in the request
object.=C2=A0<= /blockquote>

Nat, John= , everyone -=C2=A0does this mean a JAR compliant AS ignores everything o= utside of the request object while OIDC Request Object one merges the two w= ith the ones in the request object being used over ones that are sent in cl= ear?=C2=A0The OIDC language also includes sections which make sure that= some required arguments are still passed outside of the request object wit= h the same value to make sure the request is "valid" OAuth 2.0 re= quest (client_id, response_type), something which an example in the JAR spe= c does not do. Not having this language means that existing authorization r= equest pipelines can't simply be extended with e.g. a middleware, they = need to branch their codepaths.

Is an AS required to choose which of th= e two it follows?

Thank you for clarifying this in advance. I think if = either the behaviour is the same as in OIDC or different this should be cal= led out in the language to avoid confusion, especially since this already e= xists in OIDC and likely isn't going to be read in isolation, especiall= y because the Request Object is even called out to be already in place in O= IDC in the JAR draft.

Best,
Filip
--0000000000001d7d93059117d442-- From nobody Tue Aug 27 14:38:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDCB12012E for ; Tue, 27 Aug 2019 14:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHjbFM-zO0ZY for ; Tue, 27 Aug 2019 14:23:41 -0700 (PDT) Received: from mxo1.nje.dmz.twosigma.com (mxo1.nje.dmz.twosigma.com [208.77.214.160]) (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 DF2A2120113 for ; Tue, 27 Aug 2019 14:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxo1.nje.dmz.twosigma.com (Postfix) with ESMTP id 46J2171wmxz7t9D; Tue, 27 Aug 2019 21:23:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at twosigma.com Received: from mxo1.nje.dmz.twosigma.com ([127.0.0.1]) by localhost (mxo1.nje.dmz.twosigma.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azSzgLlF3HT3; Tue, 27 Aug 2019 21:23:39 +0000 (GMT) Received: from EXMBNJE6.ad.twosigma.com (exmbnje6.ad.twosigma.com [172.20.45.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mxo1.nje.dmz.twosigma.com (Postfix) with ESMTPS id 46J21710KDz3wZ3; Tue, 27 Aug 2019 21:23:39 +0000 (GMT) Received: from EXMBNJE10.ad.twosigma.com (172.20.2.246) by EXMBNJE6.ad.twosigma.com (172.20.45.169) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 27 Aug 2019 21:23:38 +0000 Received: from EXMBNJE11.ad.twosigma.com (172.20.2.181) by EXMBNJE10.ad.twosigma.com (172.20.2.246) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 27 Aug 2019 21:23:38 +0000 Received: from EXMBNJE11.ad.twosigma.com ([fe80::a1d5:365c:d606:f6d1]) by EXMBNJE11.ad.twosigma.com ([fe80::a1d5:365c:d606:f6d1%19]) with mapi id 15.00.1365.000; Tue, 27 Aug 2019 21:23:38 +0000 From: Bayard Bell To: John Bradley , William Denniss CC: RFC Errata System , Hannes Tschofenig , Benjamin Kaduk , oauth , Roman Danyliw , "rfc8252@ve7jtb.com" , "rfc8252@wdenniss.com" , "Rifaat Shekh-Yusef" Thread-Topic: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848) Thread-Index: AQHVXEEnHPgiallIu0ydb6QIPYRKdqcN5iSAgADsLACAAK/8AA== Date: Tue, 27 Aug 2019 21:23:38 +0000 Message-ID: <7a4d4121f5cf4979bee6ad157323c893@EXMBNJE11.ad.twosigma.com> References: <20190826190427.A7DADB80BB9@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.20.187.15] Content-Type: multipart/alternative; boundary="_000_7a4d4121f5cf4979bee6ad157323c893EXMBNJE11adtwosigmacom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 27 Aug 2019 14:38:13 -0700 Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:23:44 -0000 --_000_7a4d4121f5cf4979bee6ad157323c893EXMBNJE11adtwosigmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx0ZXJuYXRpdmVseSBpZiB0aGUgYXBwZW5kaXggd2VyZSBhcyBvZiBhIHBvaW50IGluIHRpbWUg YnV0IHRoZSBnaXRodWIgcmVmZXJlbmNlcyB3ZXJlIG1haW50YWluZWQsIHRoZSB3YXJuaW5nIHRo YXQgdGhlIFJGQyBpcyBhIHBvaW50LWluLXRpbWUgd2hpbGUgdGhlIGdpdGh1YiByZWZlcmVuY2Vz IHdpbGwgcmVtYWluIGN1cnJlbnQgbGV0cyB5b3UgZGVmZXIgYXV0aG9yaW5nIGFuIHVwZGF0ZWQg QkNQIFJGQyB1bnRpbCB0aGVyZSBhcmUgbXVjaCBsYXJnZXIgY2hhbmdlcyBpbiBtZWNoYW5pY3Mu DQoNCkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMjcsIDIwMTkgNjo1MiBBTQ0KVG86IFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NA Z29vZ2xlLmNvbT4NCkNjOiBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZz47IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgQmF5 YXJkIEJlbGwgPEJheWFyZC5CZWxsQHR3b3NpZ21hLmNvbT47IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1Pjsgb2F1dGggPG9hdXRoQGlldGYub3JnPjsgUm9tYW4gRGFueWxpdyA8cmRkQGNl cnQub3JnPjsgcmZjODI1MkB2ZTdqdGIuY29tOyByZmM4MjUyQHdkZW5uaXNzLmNvbTsgUmlmYWF0 IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDODI1MiAoNTg0OCkNCg0KVGhpcyBp cyBub3QgcmVhbGx5IGFuIGVyYXR0YS4gIEFzb21lIHBvaW50IHdlIG5lZWQgdG8gdXBkYXRlIHRo ZSBCQ1Agd2l0aCBhIHVwZGF0ZWQgUkZDLiAgIFBlcmhhcHMgdGhlIHRpbWUgaXMgbm93IHRvIHN0 YXJ0IGEgbmV3IGRyYWZ0IHRoYXQgY2FuIGNhcHR1cmUgdGhlIGNoYW5nZXMgaW4gaU9TLCBPU1gg YW5kIG90aGVycy4NCg0KSm9obiBCLg0KDQpPbiBNb24sIEF1ZyAyNiwgMjAxOSwgMTA6NDYgUE0g V2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29n bGUuY29tPj4gd3JvdGU6DQpQcm9jZXNzLXdpc2UgSSdtIG5vdCBzdXJlIGlmIGVycmF0YSBzaG91 bGQgYmUgdXNlZCB0byBjYXB0dXJlIGNoYW5naW5nIGltcGxlbWVudGF0aW9uIGRldGFpbHMgbGlr ZSB0aGlzLiBXZSBleHBlY3RlZCB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0aGF0IHdlIGRv Y3VtZW50ZWQgaW4gdGhlIGFwcGVuZGl4IHRvIGNoYW5nZSwgYW5kIGV4cGxpY2l0bHkgc3RhdGVk IHRoYXQgYXNzdW1wdGlvbi4gIlRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIGhlcmVpbiBhcmUg Y29uc2lkZXJlZCBhY2N1cmF0ZSBhdCB0aGUgdGltZSBvZiBwdWJsaXNoaW5nIGJ1dCB3aWxsIGxp a2VseSBjaGFuZ2Ugb3ZlciB0aW1lLiIuDQoNCklmIHVwZGF0aW5nIHRob3NlIGltcGxlbWVudGF0 aW9uIGRldGFpbHMgd2VyZSBpbiBzY29wZSwgdGhlbiB0aGUgcHJvcG9zZWQgdGV4dCBzaG91bGQg bmVlZHMgdG8gYmUgcmV2aXNlZCBiZWZvcmUgYmVpbmcgYWNjZXB0ZWQgZHVlIHRvIHNvbWUgaW5h Y2N1cmFjaWVzIChlLmcuIFNGU2FmYXJpVmlld0NvbnRyb2xsZXIgaXMgbm90IGEgc3VjY2Vzc29y IHRvIEFTV2ViQXV0aGVudGljYXRpb25TZXNzaW9uKS4NCg0KQmVzdCwNCldpbGxpYW0NCg0KT24g TW9uLCBBdWcgMjYsIDIwMTkgYXQgMTI6MDQgUE0gUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0 b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+PiB3cm90 ZToNClRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJG QzgyNTIsDQoiT0F1dGggMi4wIGZvciBOYXRpdmUgQXBwcyIuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFu ZCBhdDoNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1ODQ4DQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwNClJlcG9y dGVkIGJ5OiBCYXlhcmQgQmVsbCA8YmF5YXJkLmJlbGxAdHdvc2lnbWEuY29tPG1haWx0bzpiYXlh cmQuYmVsbEB0d29zaWdtYS5jb20+Pg0KDQpTZWN0aW9uOiBBcHBlbmRpeCBCLjENCg0KT3JpZ2lu YWwgVGV4dA0KLS0tLS0tLS0tLS0tLQ0KQXBwcyBjYW4gaW5pdGlhdGUgYW4gYXV0aG9yaXphdGlv biByZXF1ZXN0IGluIHRoZSBicm93c2VyLCB3aXRob3V0DQp0aGUgdXNlciBsZWF2aW5nIHRoZSBh cHAsIHRocm91Z2ggdGhlICJTRlNhZmFyaVZpZXdDb250cm9sbGVyIiBjbGFzcw0Kb3IgaXRzIHN1 Y2Nlc3NvciAiU0ZBdXRoZW50aWNhdGlvblNlc3Npb24iLCB3aGljaCBpbXBsZW1lbnQgdGhlIGlu LQ0KYXBwIGJyb3dzZXIgdGFiIHBhdHRlcm4uICBTYWZhcmkgY2FuIGJlIHVzZWQgdG8gaGFuZGxl IHJlcXVlc3RzIG9uDQpvbGQgdmVyc2lvbnMgb2YgaU9TIHdpdGhvdXQgaW4tYXBwIGJyb3dzZXIg dGFiIGZ1bmN0aW9uYWxpdHkuDQoNCkNvcnJlY3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KQXBw cyBjYW4gaW5pdGlhdGUgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGluIHRoZSBicm93c2VyLCB3 aXRob3V0DQp0aGUgdXNlciBsZWF2aW5nIHRoZSBhcHAsIHRocm91Z2ggdGhlICJBU1dlYkF1dGhl bnRpY2F0aW9uU2Vzc2lvbiINCmNsYXNzIG9yIGl0cyBzdWNjZXNzb3JzICJTRkF1dGhlbnRpY2F0 aW9uU2Vzc2lvbiIgYW5kDQoiU0ZTYWZhcmlWaWV3Q29udHJvbGxlciIsIHdoaWNoIGltcGxlbWVu dCB0aGUgaW4tYXBwIGJyb3dzZXIgdGFiDQpwYXR0ZXJuLiAgVGhlIGZpcnN0IG9mIHRoZXNlIGFs bG93cyBjYWxscyB0byBhIGhhbmRsZXIgcmVnaXN0ZXJlZA0KZm9yIHRoZSBBUyBVUkwsIGNvbnNp c3RlbnQgd2l0aCBTZWN0aW9uIDcuMi4gVGhlIGxhdHRlciB0d28gY2xhc3NlcywNCm5vdyBkZXBy ZWNhdGVkLCBjYW4gdXNlIFNhZmFyaSB0byBoYW5kbGUgcmVxdWVzdHMgb24gb2xkIHZlcnNpb25z IG9mDQppT1Mgd2l0aG91dCBpbi1hcHAgYnJvd3NlciB0YWIgZnVuY3Rpb25hbGl0eS4NCg0KTm90 ZXMNCi0tLS0tDQpTRkF1dGhlbnRpY2F0aW9uU2Vzc2lvbiBkb2N1bWVudGF0aW9uIHJlZmxlY3Rz IGRlcHJlY2F0ZWQgc3RhdHVzOg0KDQpodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1l bnRhdGlvbi9zYWZhcmlzZXJ2aWNlcy9zZmF1dGhlbnRpY2F0aW9uc2Vzc2lvbg0KDQpIZXJlJ3Mg dGhlIGRvY3VtZW50YXRpb24gZm9yIEFTV2ViQXV0aGVudGljYXRpb25TZXNzaW9uOg0KDQpodHRw czovL2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi9hdXRoZW50aWNhdGlvbnNlcnZp Y2VzL2Fzd2ViYXV0aGVudGljYXRpb25zZXNzaW9uDQoNCkluc3RydWN0aW9uczoNCi0tLS0tLS0t LS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElm IG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFj aGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVz IGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzgyNTIgKGRyYWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFw cHMtMTIpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGUgICAg ICAgICAgICAgICA6IE9BdXRoIDIuMCBmb3IgTmF0aXZlIEFwcHMNClB1YmxpY2F0aW9uIERhdGUg ICAgOiBPY3RvYmVyIDIwMTcNCkF1dGhvcihzKSAgICAgICAgICAgOiBXLiBEZW5uaXNzLCBKLiBC cmFkbGV5DQpDYXRlZ29yeSAgICAgICAgICAgIDogQkVTVCBDVVJSRU5UIFBSQUNUSUNFDQpTb3Vy Y2UgICAgICAgICAgICAgIDogV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wNCkFyZWEgICAgICAg ICAgICAgICAgOiBTZWN1cml0eQ0KU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNClZlcmlmeWlu ZyBQYXJ0eSAgICAgOiBJRVNHDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg== --_000_7a4d4121f5cf4979bee6ad157323c893EXMBNJE11adtwosigmacom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWx0ZXJuYXRpdmVseSBpZiB0aGUgYXBw ZW5kaXggd2VyZSBhcyBvZiBhIHBvaW50IGluIHRpbWUgYnV0IHRoZSBnaXRodWIgcmVmZXJlbmNl cyB3ZXJlIG1haW50YWluZWQsIHRoZSB3YXJuaW5nIHRoYXQgdGhlIFJGQyBpcyBhIHBvaW50LWlu LXRpbWUgd2hpbGUgdGhlIGdpdGh1Yg0KIHJlZmVyZW5jZXMgd2lsbCByZW1haW4gY3VycmVudCBs ZXRzIHlvdSBkZWZlciBhdXRob3JpbmcgYW4gdXBkYXRlZCBCQ1AgUkZDIHVudGlsIHRoZXJlIGFy ZSBtdWNoIGxhcmdlciBjaGFuZ2VzIGluIG1lY2hhbmljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJyYWRs ZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEF1Z3VzdCAyNywgMjAxOSA2OjUyIEFNPGJyPg0KPGI+VG86PC9iPiBXaWxsaWFtIERlbm5pc3Mg Jmx0O3dkZW5uaXNzQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSRkMgRXJyYXRhIFN5 c3RlbSAmbHQ7cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyZndDs7IEhhbm5lcyBUc2Nob2Zlbmln ICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0OzsgQmF5YXJkIEJlbGwgJmx0O0JheWFy ZC5CZWxsQHR3b3NpZ21hLmNvbSZndDs7IEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1 Jmd0Ozsgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0OzsgUm9tYW4gRGFueWxpdyAmbHQ7cmRk QGNlcnQub3JnJmd0OzsgcmZjODI1MkB2ZTdqdGIuY29tOyByZmM4MjUyQHdkZW5uaXNzLmNvbTsN CiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRd IFJGQzgyNTIgKDU4NDgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgbm90IHJlYWxseSBhbiBlcmF0dGEuJm5ic3A7IEFzb21lIHBv aW50IHdlIG5lZWQgdG8gdXBkYXRlIHRoZSBCQ1Agd2l0aCBhIHVwZGF0ZWQgUkZDLiZuYnNwOyAm bmJzcDtQZXJoYXBzIHRoZSB0aW1lIGlzIG5vdyB0byBzdGFydCBhIG5ldyBkcmFmdCB0aGF0IGNh biBjYXB0dXJlIHRoZSBjaGFuZ2VzIGluIGlPUywgT1NYIGFuZCBvdGhlcnMuJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgQXVnIDI2LCAyMDE5LCAxMDo0NiBQTSBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhy ZWY9Im1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb2Nlc3Mtd2lzZSBJJ20gbm90IHN1cmUgaWYgZXJy YXRhIHNob3VsZCBiZSB1c2VkIHRvIGNhcHR1cmUgY2hhbmdpbmcgaW1wbGVtZW50YXRpb24gZGV0 YWlscyBsaWtlIHRoaXMuIFdlIGV4cGVjdGVkIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRo YXQgd2UgZG9jdW1lbnRlZCBpbiB0aGUgYXBwZW5kaXggdG8gY2hhbmdlLCBhbmQgZXhwbGljaXRs eSBzdGF0ZWQgdGhhdCBhc3N1bXB0aW9uLiAmcXVvdDtUaGUgaW1wbGVtZW50YXRpb24NCiBkZXRh aWxzIGhlcmVpbiBhcmUgY29uc2lkZXJlZCBhY2N1cmF0ZSBhdCB0aGUgdGltZSZuYnNwO29mIHB1 Ymxpc2hpbmcgYnV0IHdpbGwgbGlrZWx5IGNoYW5nZSBvdmVyIHRpbWUuJnF1b3Q7LjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdXBkYXRpbmcgdGhvc2Ug aW1wbGVtZW50YXRpb24gZGV0YWlscyB3ZXJlIGluIHNjb3BlLCZuYnNwO3RoZW4gdGhlIHByb3Bv c2VkIHRleHQgc2hvdWxkIG5lZWRzIHRvIGJlIHJldmlzZWQgYmVmb3JlIGJlaW5nIGFjY2VwdGVk IGR1ZSB0byBzb21lIGluYWNjdXJhY2llcyAoZS5nLiBTRlNhZmFyaVZpZXdDb250cm9sbGVyIGlz IG5vdCBhIHN1Y2Nlc3NvciB0byBBU1dlYkF1dGhlbnRpY2F0aW9uU2Vzc2lvbikuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz dCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldp bGxpYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEF1ZyAyNiwgMjAxOSBhdCAxMjowNCBQTSBSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciIHRhcmdldD0iX2JsYW5r Ij5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZm9sbG93aW5n IGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM4MjUyLDxicj4NCiZxdW90 O09BdXRoIDIuMCBmb3IgTmF0aXZlIEFwcHMmcXVvdDsuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0 IGJlbG93IGFuZCBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9l cnJhdGEvZWlkNTg0OCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2VycmF0YS9laWQ1ODQ4PC9hPjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KVHlwZTogVGVjaG5pY2FsPGJyPg0KUmVwb3J0ZWQgYnk6IEJheWFy ZCBCZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmF5YXJkLmJlbGxAdHdvc2lnbWEuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YmF5YXJkLmJlbGxAdHdvc2lnbWEuY29tPC9hPiZndDs8YnI+DQo8YnI+DQpT ZWN0aW9uOiBBcHBlbmRpeCBCLjE8YnI+DQo8YnI+DQpPcmlnaW5hbCBUZXh0PGJyPg0KLS0tLS0t LS0tLS0tLTxicj4NCkFwcHMgY2FuIGluaXRpYXRlIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBp biB0aGUgYnJvd3Nlciwgd2l0aG91dDxicj4NCnRoZSB1c2VyIGxlYXZpbmcgdGhlIGFwcCwgdGhy b3VnaCB0aGUgJnF1b3Q7U0ZTYWZhcmlWaWV3Q29udHJvbGxlciZxdW90OyBjbGFzczxicj4NCm9y IGl0cyBzdWNjZXNzb3IgJnF1b3Q7U0ZBdXRoZW50aWNhdGlvblNlc3Npb24mcXVvdDssIHdoaWNo IGltcGxlbWVudCB0aGUgaW4tPGJyPg0KYXBwIGJyb3dzZXIgdGFiIHBhdHRlcm4uJm5ic3A7IFNh ZmFyaSBjYW4gYmUgdXNlZCB0byBoYW5kbGUgcmVxdWVzdHMgb248YnI+DQpvbGQgdmVyc2lvbnMg b2YgaU9TIHdpdGhvdXQgaW4tYXBwIGJyb3dzZXIgdGFiIGZ1bmN0aW9uYWxpdHkuPGJyPg0KPGJy Pg0KQ29ycmVjdGVkIFRleHQ8YnI+DQotLS0tLS0tLS0tLS0tLTxicj4NCkFwcHMgY2FuIGluaXRp YXRlIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpbiB0aGUgYnJvd3Nlciwgd2l0aG91dDxicj4N CnRoZSB1c2VyIGxlYXZpbmcgdGhlIGFwcCwgdGhyb3VnaCB0aGUgJnF1b3Q7QVNXZWJBdXRoZW50 aWNhdGlvblNlc3Npb24mcXVvdDs8YnI+DQpjbGFzcyBvciBpdHMgc3VjY2Vzc29ycyAmcXVvdDtT RkF1dGhlbnRpY2F0aW9uU2Vzc2lvbiZxdW90OyBhbmQ8YnI+DQomcXVvdDtTRlNhZmFyaVZpZXdD b250cm9sbGVyJnF1b3Q7LCB3aGljaCBpbXBsZW1lbnQgdGhlIGluLWFwcCBicm93c2VyIHRhYjxi cj4NCnBhdHRlcm4uJm5ic3A7IFRoZSBmaXJzdCBvZiB0aGVzZSBhbGxvd3MgY2FsbHMgdG8gYSBo YW5kbGVyIHJlZ2lzdGVyZWQ8YnI+DQpmb3IgdGhlIEFTIFVSTCwgY29uc2lzdGVudCB3aXRoIFNl Y3Rpb24gNy4yLiBUaGUgbGF0dGVyIHR3byBjbGFzc2VzLDxicj4NCm5vdyBkZXByZWNhdGVkLCBj YW4gdXNlIFNhZmFyaSB0byBoYW5kbGUgcmVxdWVzdHMgb24gb2xkIHZlcnNpb25zIG9mPGJyPg0K aU9TIHdpdGhvdXQgaW4tYXBwIGJyb3dzZXIgdGFiIGZ1bmN0aW9uYWxpdHkuPGJyPg0KPGJyPg0K Tm90ZXM8YnI+DQotLS0tLTxicj4NClNGQXV0aGVudGljYXRpb25TZXNzaW9uIGRvY3VtZW50YXRp b24gcmVmbGVjdHMgZGVwcmVjYXRlZCBzdGF0dXM6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24vc2FmYXJpc2VydmljZXMvc2ZhdXRo ZW50aWNhdGlvbnNlc3Npb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RldmVsb3Blci5hcHBs ZS5jb20vZG9jdW1lbnRhdGlvbi9zYWZhcmlzZXJ2aWNlcy9zZmF1dGhlbnRpY2F0aW9uc2Vzc2lv bjwvYT48YnI+DQo8YnI+DQpIZXJlJ3MgdGhlIGRvY3VtZW50YXRpb24gZm9yIEFTV2ViQXV0aGVu dGljYXRpb25TZXNzaW9uOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGV2ZWxvcGVyLmFw cGxlLmNvbS9kb2N1bWVudGF0aW9uL2F1dGhlbnRpY2F0aW9uc2VydmljZXMvYXN3ZWJhdXRoZW50 aWNhdGlvbnNlc3Npb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RldmVsb3Blci5hcHBsZS5j b20vZG9jdW1lbnRhdGlvbi9hdXRoZW50aWNhdGlvbnNlcnZpY2VzL2Fzd2ViYXV0aGVudGljYXRp b25zZXNzaW9uPC9hPjxicj4NCjxicj4NCkluc3RydWN0aW9uczo8YnI+DQotLS0tLS0tLS0tLS0t PGJyPg0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQm cXVvdDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyPg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90 OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVqZWN0 ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5Jm5ic3A7 IDxicj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9y dCwgaWYgbmVjZXNzYXJ5LiA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NClJGQzgyNTIgKGRyYWZ0LWlldGYtb2F1dGgtbmF0aXZlLWFwcHMtMTIp PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaXRsZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IE9B dXRoIDIuMCBmb3IgTmF0aXZlIEFwcHM8YnI+DQpQdWJsaWNhdGlvbiBEYXRlJm5ic3A7ICZuYnNw OyA6IE9jdG9iZXIgMjAxNzxicj4NCkF1dGhvcihzKSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiBXLiBEZW5uaXNzLCBKLiBCcmFkbGV5PGJyPg0KQ2F0ZWdvcnkmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEJFU1QgQ1VSUkVOVCBQUkFD VElDRTxicj4NClNvdXJjZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sPGJyPg0KQXJlYSZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBTZWN1cml0eTxi cj4NClN0cmVhbSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA6IElFVEY8YnI+DQpWZXJpZnlpbmcgUGFydHkmbmJzcDsgJm5ic3A7ICZuYnNwOzogSUVTRzxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7a4d4121f5cf4979bee6ad157323c893EXMBNJE11adtwosigmacom_-- From nobody Wed Aug 28 01:40:37 2019 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 76423120024; Wed, 28 Aug 2019 01:40:28 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156698162841.32357.13614826640159073076@ietfa.amsl.com> Date: Wed, 28 Aug 2019 01:40:28 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 08:40:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-06.txt Pages : 17 Date : 2019-08-28 Abstract: This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-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 Wed Aug 28 01:48:31 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04607120072 for ; Wed, 28 Aug 2019 01:48:29 -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, 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 xRGB5ljH7NQm for ; Wed, 28 Aug 2019 01:48:26 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.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 A9E8612002F for ; Wed, 28 Aug 2019 01:48:26 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2tct-0005Kg-Rh; Wed, 28 Aug 2019 10:48:23 +0200 From: Torsten Lodderstedt Message-Id: <674CC181-FE18-4BED-83DC-916EF86E7AA8@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_7627747C-7517-4A1E-904F-955B69BDCA24"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 28 Aug 2019 10:48:23 +0200 In-Reply-To: Cc: oauth , Nat Sakimura , John Bradley To: Filip Skokan References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 08:48:29 -0000 --Apple-Mail=_7627747C-7517-4A1E-904F-955B69BDCA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Filip, In my understanding, duplication of request parameters outside of the = request object was necessary in the OIDC variant in order to retain = OAuth compliance. JAR as an OAuth extension will not require the client = to duplicate OAuth request parameters outside of the request object. =20 There might potentially be reasons for merging (different) URI request = parameters with parameters passed in the request object in cases where = long living request objects are used. =20 kind regards, Torsten.=20 > On 27. Aug 2019, at 13:46, Filip Skokan wrote: >=20 > Hello everyone, >=20 > in an earlier thread I've posed the following question that might have = gotten missed, this might have consequences for the existing = implementations of Request Objects in OIDC implementations - its making = pure JAR requests incompatible with OIDC Core implementations. >=20 > draft 14 of jwsreq (JAR) introduced this language >=20 > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. However, the authorization server supporting this > specification MUST only use the parameters included in the request > object.=20 >=20 > Server MUST only use the parameters in the Request Object even if the > same parameter is provided in the query parameter. The Authorization >=20 > The client MAY send the parameters included in the request object > duplicated in the query parameters as well for the backward > compatibility etc. However, the authorization server supporting this > specification MUST only use the parameters included in the request > object.=20 >=20 > Nat, John, everyone - does this mean a JAR compliant AS ignores = everything outside of the request object while OIDC Request Object one = merges the two with the ones in the request object being used over ones = that are sent in clear? The OIDC language also includes sections which = make sure that some required arguments are still passed outside of the = request object with the same value to make sure the request is "valid" = OAuth 2.0 request (client_id, response_type), something which an example = in the JAR spec does not do. Not having this language means that = existing authorization request pipelines can't simply be extended with = e.g. a middleware, they need to branch their codepaths. >=20 > Is an AS required to choose which of the two it follows? >=20 > Thank you for clarifying this in advance. I think if either the = behaviour is the same as in OIDC or different this should be called out = in the language to avoid confusion, especially since this already exists = in OIDC and likely isn't going to be read in isolation, especially = because the Request Object is even called out to be already in place in = OIDC in the JAR draft. >=20 > Best, > Filip > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7627747C-7517-4A1E-904F-955B69BDCA24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA4MjgwODQ4MjNaMC8GCSqGSIb3DQEJBDEiBCC5JMLrzNX6LVvj2U784NwQa1Rnr+WO7DoG 13qUSchpVzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAAPsTweviswpUh8eWoAmtoAPHpCRyQENhKY+AWxI9v8AjFjqoN/dTkY94962 +DQU+TfDUZ6ioHxeCDEpRXqAMm8Gw+I7Hyvs9BLbzHtYH9MbmySJu7QUUCmVtH3psjqIZMOtr4mT wDep00awRlA/Ajz+IZ3PYcQe4nfOKFKPHxWWQErRlpuQTntii+4v3WiLKEcuEfjAYwbB4BRn3hL0 /TTGMG7Saqv8sjzMKIO7JepCSVwf2V0VisTPZY2U7oLw3Rlg6H2bVqt7D1NSp477gQEg8mJKDNel a13ZqlR0A3nmlN/e/WC2O3LfMZPfQU0KfIXN19Jnon4+pBZO8UYlejMAAAAAAAA= --Apple-Mail=_7627747C-7517-4A1E-904F-955B69BDCA24-- From nobody Wed Aug 28 02:00:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A9A12003E for ; Wed, 28 Aug 2019 02:00:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1JEyAsEOKNM for ; Wed, 28 Aug 2019 02:00:33 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 D21BA120018 for ; Wed, 28 Aug 2019 02:00:32 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id z11so1656274wrt.4 for ; Wed, 28 Aug 2019 02:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o08zIB/CxMNC9z2adp5BgYkmaPiGjs6OpqvfVdRIWAY=; b=djUQ6EEX8TJVNkvFia7BFIiL8zFWpJMXdaeju+xCxILOnhWW1eaqdSTHqHaUcpC7pJ GFsNw78/6i6Bda0+IDBp1APhI1p1u+XICnU/NO93mRFAcLoCLYNDTO4wANoMcPpaOR9p 8DM/VW90gAdUjwLYutmq5CNE+hyyqf1KMUBgZiVgUEHgRq7zOhf6br15qSDpjE3PXPha qFvICnqhcd8i4//iORcTgJ3Walw+E+w1xoBLcikillelruZ+7WjyTeEQq+hbEkF6pf3Z U6d2yToDpNu9XpbjUIh9yKdhur4arJlFWp3j6CeFTr2drlk8IsG0qtGu/pA4Zpy1xwEG V9qA== 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=o08zIB/CxMNC9z2adp5BgYkmaPiGjs6OpqvfVdRIWAY=; b=UbcEJ56iETBXnH38qspm0qUFB0nz84zSebyKo1NspkUR2bK7r6CBj8zkb8WSb0wybQ e+BIGJ7nPnBvHjdkxd2csoOPZHKaa3EgsEY6ZQADJ09aFfrmrvOx7L+Pq83/oJ+MpE6A 77yt9h4NodEvplEpU0qDqwP8TVx4zZx9xBO9mTknMC7faMPhIBK57XpqgwdeZn2uw82c hdZi/32/jJg2GQ4jBrSJIBMD3CRpuQKY9xEUtvALE5YWTsm6l7YTvLbV3WDyjF5T8vaV kZxdaUp0LwcWi8IZl2yvZvKpbuPPVFuSm6AxTCNT3ieK0Byt3aRJRf0/q16LrLdmN0rm 2q5g== X-Gm-Message-State: APjAAAWFLnqx8PqO8SyNBIj3PSapDO3HSrKag/GxDrIm+huQYdVehrQP bhvd2jFax62/YC4/TARhNg== X-Google-Smtp-Source: APXvYqxbRUotVlGk/yotKkiNc8lvfZ8AjmHAP0sYrsKtyXfd5eOxRUCbGQdIOEie+rR089F1OzRV0w== X-Received: by 2002:adf:e30e:: with SMTP id b14mr3262084wrj.168.1566982831242; Wed, 28 Aug 2019 02:00:31 -0700 (PDT) Received: from [100.96.66.97] (ip-37-188-253-244.eurotel.cz. [37.188.253.244]) by smtp.gmail.com with ESMTPSA id 20sm1977743wmk.34.2019.08.28.02.00.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 02:00:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16G77) In-Reply-To: <674CC181-FE18-4BED-83DC-916EF86E7AA8@lodderstedt.net> Date: Wed, 28 Aug 2019 11:00:29 +0200 Cc: oauth , Nat Sakimura , John Bradley Content-Transfer-Encoding: quoted-printable Message-Id: <865F377D-46D7-4420-AB15-FD2B67E37B28@gmail.com> References: <674CC181-FE18-4BED-83DC-916EF86E7AA8@lodderstedt.net> To: Torsten Lodderstedt Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 09:00:36 -0000 I can get by not having to have the minimum oauth request parameters, but th= e current language does not imply that one can use the parameters if they=E2= =80=99re not present in the Request Object.=20 That derails JAR from its OIDC variant.=20 Odesl=C3=A1no z iPhonu 28. 8. 2019 v 10:48, Torsten Lodderstedt : > Hi Filip, >=20 > In my understanding, duplication of request parameters outside of the requ= est object was necessary in the OIDC variant in order to retain OAuth compli= ance. JAR as an OAuth extension will not require the client to duplicate OAu= th request parameters outside of the request object. =20 >=20 > There might potentially be reasons for merging (different) URI request par= ameters with parameters passed in the request object in cases where long liv= ing request objects are used. =20 >=20 > kind regards, > Torsten.=20 >=20 >> On 27. Aug 2019, at 13:46, Filip Skokan wrote: >>=20 >> Hello everyone, >>=20 >> in an earlier thread I've posed the following question that might have go= tten missed, this might have consequences for the existing implementations o= f Request Objects in OIDC implementations - its making pure JAR requests inc= ompatible with OIDC Core implementations. >>=20 >> draft 14 of jwsreq (JAR) introduced this language >>=20 >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. However, the authorization server supporting this >> specification MUST only use the parameters included in the request >> object.=20 >>=20 >> Server MUST only use the parameters in the Request Object even if the >> same parameter is provided in the query parameter. The Authorization >>=20 >> The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. However, the authorization server supporting this >> specification MUST only use the parameters included in the request >> object.=20 >>=20 >> Nat, John, everyone - does this mean a JAR compliant AS ignores everythin= g outside of the request object while OIDC Request Object one merges the two= with the ones in the request object being used over ones that are sent in c= lear? The OIDC language also includes sections which make sure that some req= uired arguments are still passed outside of the request object with the same= value to make sure the request is "valid" OAuth 2.0 request (client_id, res= ponse_type), something which an example in the JAR spec does not do. Not hav= ing this language means that existing authorization request pipelines can't s= imply be extended with e.g. a middleware, they need to branch their codepath= s. >>=20 >> Is an AS required to choose which of the two it follows? >>=20 >> Thank you for clarifying this in advance. I think if either the behaviour= is the same as in OIDC or different this should be called out in the langua= ge to avoid confusion, especially since this already exists in OIDC and like= ly isn't going to be read in isolation, especially because the Request Objec= t is even called out to be already in place in OIDC in the JAR draft. >>=20 >> Best, >> Filip >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Wed Aug 28 02:14:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBA0120046 for ; Wed, 28 Aug 2019 02:14: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, 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 1__nDWtYC-xa for ; Wed, 28 Aug 2019 02:14:03 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.109]) (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 4107E120033 for ; Wed, 28 Aug 2019 02:14:03 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2u1f-0005Po-UE; Wed, 28 Aug 2019 11:13:59 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_72D506DB-FD70-4668-863D-811E89CB1AB6"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 28 Aug 2019 11:13:59 +0200 In-Reply-To: <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> Cc: "oauth@ietf.org" To: "Schaar, R.M. (Remco) - Logius" References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 09:14:06 -0000 --Apple-Mail=_72D506DB-FD70-4668-863D-811E89CB1AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rhemco, > On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius = wrote: >=20 > Hello Thorsten, >=20 > Thank you for your response. I have a few more questions/comments as > follow-up... >=20 > You state that RFC7519 and RFC7662 "just" define different = representations > for token data. If the draft RFC would refer to RFC 7515 (JWS), I = would > agree. However, RFC7519 (JWT) explicitly adds semantics to some = specific > parameters (e.g. aud, jti and iat). RFC7662 has different semantics = for > the several of the same parameters. > For instance the 'iat', is the moment of issuance of the JWT in = RFC7519. In > RFC7662 that is the "when this token was originally issued". This time = will > vary in use cases without immediate introspection of an access token. I read the text differently. In my interpretation =E2=80=9Cwhen the = token was originally issued=E2=80=9D stated from the perspective of the = introspection endpoint refers exactly to the same instant as =E2=80=9Cthe = time at which the JWT was issued=E2=80=9D. >=20 > For the use case of the resource server relying on verifiable data, as > described in the introduction of the draft RFC, the time of the = introspection > is critical. Why is this time critical? > In particular when combined with revocation, the time of > introspection and the 'active' status can differ between two = subsequent calls > for introspection. The status at token introspection request time is indeed critical. RFC = 7662 gives a good indication how this value should be calculated. =E2=80=9C=E2=80=A6 a "true" value return for the "active" property will generally indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g., after its issuance time and before its expiration time)."=20 So it represents the results of the issuer check, the revocation check = and the validity check in one boolean value.=20 >=20 > If the draft RFC just produces a JWT representation of the access = token, > including 'active' would not make sense as the JWT will expire without > updating it to false. Leaving 'active' out would make it incompatible = with > RFC7662 introspection responses. =E2=80=9Cactive=E2=80=9D is not part of the JWT representation I = referred to. The AS needs to determine the active value for every token = introspection request.=20 If the RS would consume JWTs, it would determine the =E2=80=9Cactive=E2=80= =9D value itself by inspecting the iss claim and check against its AS = whitelist, check the signature and the iat & exp values. Determining the = revocation status would require an information exchange with the AS of = some sort.=20 > Similar, not including a unique 'jti' per introspection response would = make > the resource server vulnerable to replay attacks. To the contrary, including a different =E2=80=9Cjit" with every token = introspection response would make the RS vulnerable to replay of one = time access token since it remove the possibility for the RS to identity = a certain access token.=20 > Or the resource server > would mistakenly refer to non-unique tokens, making the responses = unsuitable > for accountability and audit purposes. >=20 >=20 > As to why someone would want to distinguish a JWT access token from an > introspection response: several use cases come to mind. >=20 > First of all, even if one is using standalone interpretable JWT access = tokens, > one may want to combine that with revocation checking using = introspection. The > interpretation and meaning of the JWT and the introspection response = than do > differ and matter. As I described above, I don=E2=80=99t see any difference.=20 >=20 > Another use case would be a mixed ecosystem with resource servers = relying on > introspection while others do parse JWT access tokens. A single, = uniform > implementation for the AS would than mix both as well. See above - I don=E2=80=99t see any issue.=20 >=20 > A last use case could be exchanging access tokens with a subset of the = full > set of applicable parameters, to reduce the size of access tokens. = Additional > information can be exchanged via introspection, resulting in mixed JWT = access > tokens and introspection as well. That=E2=80=99s all possible within the current text.=20 kind regards, Torsten=20 >=20 > Kind regards, > Remco Schaar >=20 > -----Oorspronkelijk bericht----- > Van: Torsten Lodderstedt =20 > Verzonden: zaterdag 17 augustus 2019 14:00 > Aan: Schaar, R.M. (Remco) - Logius > CC: oauth@ietf.org > Onderwerp: Re: [OAUTH-WG] Question regarding = draft-ietf-oauth-jwt-introspection-response-05 >=20 > Hi Remco, >=20 >> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius = wrote: >>=20 >> Hello, >=20 > [...] > RFC 7519 and RFC 7662 =E2=80=9Cjust=E2=80=9D define different = representations for token data. In RFC 7519 the data is carried in the = token itself (which also means the format of the token is well-defined = and know to the RS) whereas RFC 7662 defines a way to inspect tokens via = an API provided by the AS. The latter is typically used in conjunction = with opaque tokens, i.e. the RS does not have a clue how to parse and = interpret the token. The token might just be a handle to a database = entry at the AS in this case.=20 >=20 > This also means a JWT (RFC 7662) and the Introspection Response are = conceptually the same from a RSs perspective. >=20 > [...] >=20 >> The =E2=80=98jti=E2=80=99 parameter however will always be ambiguous. = As it is an identifier, it should differ for the introspected token and = the introspection response by definition. Hence the semantics of = =E2=80=98jti=E2=80=99 in a JWT introspection response is unclear. The = same can apply to the =E2=80=98iat=E2=80=99, =E2=80=98nbf=E2=80=99 and = =E2=80=98exp=E2=80=99 claims in a JWT introspection response. >=20 > I don=E2=80=99t understand the difference you are making. All before = mentioned claims are related to the (abstract) access token. You may = think of the Introspection Response as _the_ JWT representation of the = access token produced by the AS for the RS. >=20 >>=20 >> Can someone clarify the semantics of claims in an introspection = response JWT that are defined in both RFC7662 and RFC7519? >>=20 >> Furthermore, the introspection response should use the =E2=80=98iss=E2=80= =99 and =E2=80=98aud=E2=80=99 claims to avoid cross-JWT confusion = (section 6.1). The =E2=80=98iss=E2=80=99 and =E2=80=98aud=E2=80=99 of an = introspected token will typically be the same as those of the = introspection response. Hence a JWT access token cannot be distinguished = from an introspection response using =E2=80=98iss=E2=80=99 and =E2=80=98au= d=E2=80=99 as suggested in the draft.. >>=20 >> Introspection refers to JWT best-current-practice. The draft BCP = recommends using explicit typing of JWTs, however the draft JWT response = for introspection does not apply this recommendation and uses the = generic =E2=80=98application/jwt=E2=80=99 instead... The BCP has other = recommendations in section 3.12, but these may be insufficient to = distinguish a JWT access token from a JWT introspection response. >=20 > Good point. The reason why the BCP recommends explicit typing is to = prevent replay in other contexts. In the end typing is a compelling = concept unfortunately not broadly used in the wild. >=20 > So the JWT Introspection Response draft copes with that attack angle = by making iss and aud mandatory.=20 >=20 >=20 >>=20 >> How would people suggest to best distinguish a JWT (access) token = from a JWT introspection response? >=20 > Why should you? One reason why we extended the Introspection Response = was to eliminate the difference between JWTs directly used as access = tokens and Introspection Responses. >=20 > best regards, > Torsten.=20 >=20 >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien = u niet de geadresseerde bent of dit bericht abusievelijk aan u is = toegezonden, wordt u verzocht dat aan de afzender te melden en het = bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor = schade, van welke aard ook, die verband houdt met risico's verbonden aan = het elektronisch verzenden van berichten. > This message may contain information that is not intended for you. If = you are not the addressee or if this message was sent to you by mistake, = you are requested to inform the sender and delete the message. The State = accepts no liability for damage of any kind resulting from the risks = inherent in the electronic transmission of messages. --Apple-Mail=_72D506DB-FD70-4668-863D-811E89CB1AB6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA4MjgwOTEzNTlaMC8GCSqGSIb3DQEJBDEiBCCoxfJoklCifRaXdrbHp2rLHeTjK/iITv4c ZpdHI6ImNDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBABZnf50YikWqgUjIf+LwwwiBgYHHqM2XcjavtLom4ngfNrGY4e0pZgaZbafM nuQG9Wneglf++Q+sd6q6aKSsGmcIT80QQ8OSuAxJICtzHtZ0iKxXhF9waId2mnmtmuzYfS3FCUSz FNV1u2xnqr347uvw7wU0P65ypEFHwU2ygPrCarUEtF1NRDCGCbpIGRukBYhTeV1LPUdaPl8zI2Zi 0TCDNf+UFiObT+pAiNRgiHvdoyT+VJ2M4PDwGMar5y2YTMvQByazZjlkqrjSujSm6PmYNx9evQgQ L4dKdeGHD8/VmL2Hc4505DQt9N1+H97Pd7ye8+dQiMxezg2i336qZzQAAAAAAAA= --Apple-Mail=_72D506DB-FD70-4668-863D-811E89CB1AB6-- From nobody Wed Aug 28 04:21:07 2019 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 CBA80120100; Wed, 28 Aug 2019 04:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156699126575.32385.6288194399756449704.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2019 04:21:05 -0700 Archived-At: Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwt-introspection-response-06: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 11:21:06 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-06: 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-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a fine document. I only have one small issue that should be easy to resolve: In 8.3.1: o Name: "locale" o Description: Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. The description doesn’t seem to match the name. From nobody Wed Aug 28 05:56:57 2019 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 57E8A12008D; Wed, 28 Aug 2019 05:56:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156699700827.32429.7834447943968133840.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2019 05:56:48 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 12:56:49 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: 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-resource-indicators/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey that it would be good to mention any privacy implications of providing this additional information to the auth server in the security consideration section; maybe also further advising clients on which resources to request when. From nobody Wed Aug 28 12:32:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193161200CD for ; Wed, 28 Aug 2019 12:32:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Qo8iYrEJJNsR for ; Wed, 28 Aug 2019 12:32:25 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 120681200A3 for ; Wed, 28 Aug 2019 12:32:25 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id t6so1891806ios.7 for ; Wed, 28 Aug 2019 12:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lhu+jzLuK645Vef2rRZniKgaRwqUYAmRmIPMKiRyA74=; b=BkGV/8x6uCywNEqB7v4QISoKYz/sAkEP81I6nuns5VzjkOAuRnUB2qS2L+ENTOP3yv 0BV6YHuERDGgNcKn/Bgkj94gJKcH1ZbG1O+BCsGo+giH0EDi5oK37Hel4GXu2F8bPqTs iudkjnTEGcrEgIR0lHOcd5YijKbm3OmGff3Gg= 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=Lhu+jzLuK645Vef2rRZniKgaRwqUYAmRmIPMKiRyA74=; b=q3G6GBFRgqkdokeCf6I7lBlZB1D+lyzkOeChsO6FQjmxG+BGL80vlhetmpGWkaLPXP XUYfv35ddYVU4oLhLPSDtzDOWscdfw2Z0RREeJhwkHXMsZ+CfETFtjAO1/SAWWhF6JWY BHOrvSFfCwCMCnRuzYpICjZ+ySaLzIyGfUhREyzc4e+BWYDI4ZouHxvoUxXxnSOAMLcb EEVZPyb6Ry7b/F82lG+uk9dVpa+Ur1+Ybah1DMA4e85qbxWtzck7h2QSAhLdcniYz254 NSjP0/61k7f3FjGXApC3oD6bqR8dFc93dWaCtNSCNEcM57phdxbxYMDd6xN3pyVc9YEp D4Aw== X-Gm-Message-State: APjAAAWJaVHndb2iuvV78M6tyhfSZVMg1cgQIYirBeoOwujhdBjePZhn y5gi/rDuDVJmL05YJphcZX+txE/Jf11ngUut2nCBAdYAGRTUeMSIyU+Z98dQS4WrKOpxyVhWJqb N2C6oJb03dwjd0g== X-Google-Smtp-Source: APXvYqxs9UwWpIqXjmB9EILoz5lZf1OMgnTjb76JDyKBe2Qw3hvxmv/QWim9X3gTTz1eMAvuPb+kpqtf9xB+WNBdXxY= X-Received: by 2002:a5d:888a:: with SMTP id d10mr6551707ioo.201.1567020744232; Wed, 28 Aug 2019 12:32:24 -0700 (PDT) MIME-Version: 1.0 References: <156699700827.32429.7834447943968133840.idtracker@ietfa.amsl.com> In-Reply-To: <156699700827.32429.7834447943968133840.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 28 Aug 2019 13:31:58 -0600 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Alexey Melnikov Cc: The IESG , draft-ietf-oauth-resource-indicators@ietf.org, oauth , oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0f3ee0591327200" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 19:32:28 -0000 --000000000000d0f3ee0591327200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and not objectionable ballot, Mirja. I wasn't aware of Alexey's comment until I saw your message here and went to the tracker https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ballo= t/ to find it. I think maybe an email got lost somewhere or didn't send or something? Anyway, in an attempt at bringing some continuity to the discussion I've copied his comment here: "I like this document. Is tracking by authorization server a concern? I suspect on the balance it is less important than restricting token scope (and thus improving security of bearer tokens), but maybe this shoukd be mentioned in the Security Considerations." In all honesty, tracking by authorization server hasn't been a concern in my mind when working on this document because the authorization server is already squarely in the middle of everything and able to track a significant amount even in the absence of what this document describes. And, as you mention, the potential to improve security in an already track-able situation is more important in my mind. With that said, however, I suppose that the resource parameter in this document does, in some circumstances (like when token introspection is not being used), make tracking things at a more granular and specific level possible. And that might warrant a mention in the Security (or Privacy) Considerations. I'm honestly not too sure what exactly that mention would say or how it would say it but I can work on some text. On Wed, Aug 28, 2019 at 6:57 AM Mirja K=C3=BChlewind via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alexey that it would be good to mention any privacy > implications > of providing this additional information to the auth server in the securi= ty > consideration section; maybe also further advising clients on which > resources > to request when. > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000d0f3ee0591327200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for the review= and not objectionable ballot, Mirja.

I wasn&= #39;t aware of Alexey's comment until I saw your message here and went = to the tracker https://datatracker.ietf.org/doc/draft-ietf-o= auth-resource-indicators/ballot/ to find it. I think maybe an email got= lost somewhere or didn't send or something? Anyway, in an attempt at b= ringing some continuity to the discussion I've copied his comment here:=
=09

"I like this document. Is tracking by authorization server a concern? I suspect
on the balance = it is less important than restricting token
scope (and thus improving se= curity of bearer tokens), but
maybe this shoukd be mentioned in the Secu= rity Considerations."
=20 =20 =20 =20

In all honesty, tracking by authorization server hasn't been a co= ncern in my mind when working on this document because the authorization se= rver is already squarely in the middle of everything and able to track a si= gnificant amount even in the absence of what this document describes. And, = as you mention, the potential to improve security in an already track-able = situation is more important in my mind. With that said, however, I suppose = that the resource parameter in this document does, in some circumstances (l= ike when token introspection is not being used), make tracking things at a = more granular and specific level possible. And that might warrant a mention= in the Security (or Privacy) Considerations. I'm honestly not too sure= what exactly that mention would say or how it would say it but I can work = on some text.




On Wed, Aug 28, 2019 at 6:57 AM Mirja K=C3=BChlewi= nd via Datatracker <noreply@ietf.org> wrote:

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alexey that it would be good to mention any privacy implicatio= ns
of providing this additional information to the auth server in the security=
consideration section; maybe also further advising clients on which resourc= es
to request when.

<= 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. --000000000000d0f3ee0591327200-- From nobody Wed Aug 28 14:02:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E5120089 for ; Wed, 28 Aug 2019 14:02:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 28oY7-qycv8B for ; Wed, 28 Aug 2019 14:02:22 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B09012004C for ; Wed, 28 Aug 2019 14:02:22 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id s21so2498599ioa.1 for ; Wed, 28 Aug 2019 14:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Id6KB368tjk5iqlYbJkv2/OrOKSt5gd83pe0A5ibMhM=; b=iTt/MnAn/os/6mMvNw/PQQHLUhUtOfD+LuuRhASXM+HA9vONBlFfLuLs9WU2pRyHxy sQ1dWINcYeF0SE569Yi1bVCebvY3lNnQt6CdBz+UufFZ6uYiEKNJcQFryBbo+MiV+7Rd kdJYnJHrUonOXpodHRQgpqtpRVsZyXl671JtU= 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=Id6KB368tjk5iqlYbJkv2/OrOKSt5gd83pe0A5ibMhM=; b=cjyR+gaICvdm2SsJ2i86iAH0BWJPwCXHKpHUGt+vn3dAZtqsPKiibP1LCF54UM7267 8d6d2RFf003jD3gePXWw8ZbirxT3gXqx7hq+raneqQbntzaGn+gTq5daJ9Cbc5qNHtr/ d8EpOzLfLeDK1+u37Rgt8trU3nesmPmp+OZ45bLxogS3w5l+jL43SshdYDAEbmp8/5o/ +6LeWlzUtrqM4Z8QpIDRpwVwEZ/JY9OkPyGh1tqQg1/3lcG/KWXejEULSMUDie6vfORb wgP9K1Jb5GP0EHna4WvuHIOfHZQmGs/TWWNb4/lHMzEKOvQXgmVokGFtaQTfTorKrn3M WN+g== X-Gm-Message-State: APjAAAWqKIsirGcmQhe6Iz/Nf4NrntX3Q0LlcMhmwiCXbSb6sDOnRdjU mnu/z7bd2yCTJZ3zKwMaRoNBXXfun+enTNF2oaEFr/hU46UZW0UXSmiJSV36QtkFjN6YxcoKa9s x0tbWBvIoHd1dZQ== X-Google-Smtp-Source: APXvYqxTFGlkAvCyitoYOdAhvu1DD3bSA9TtBYaJju8qMwNjDASyr4ODSj+MdgfDTSUcKWff1ZUG0kF0/4GPYVbkRkc= X-Received: by 2002:a5e:9244:: with SMTP id z4mr6633412iop.127.1567026141682; Wed, 28 Aug 2019 14:02:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 28 Aug 2019 15:01:55 -0600 Message-ID: To: Filip Skokan Cc: oauth , Nat Sakimura , John Bradley Content-Type: multipart/alternative; boundary="0000000000008775cd059133b47c" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 21:02:25 -0000 --0000000000008775cd059133b47c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Filip, for better or worse, I believe your assessment of the situation is correct. I know of one AS that didn't choose which of the two to follow but rather implemented a bit of a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the presence and value of the few regular parameters (client_id, response_type) that OIDC mandates. On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote: > Hello everyone, > > in an earlier thread I've posed the following question that might have > gotten missed, this might have consequences for the existing > implementations of Request Objects in OIDC implementations - its making > pure JAR requests incompatible with OIDC Core implementations. > > draft 14 of jwsreq (JAR) introduced this language > > The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. >> >> *However, the authorization server supporting thisspecification MUST onl= y >> use the parameters included in the requestobject. * > > > Server MUST only use the parameters in the Request Object even if the >> same parameter is provided in the query parameter. The Authorization > > > The client MAY send the parameters included in the request object >> duplicated in the query parameters as well for the backward >> compatibility etc. >> >> *However, the authorization server supporting thisspecification MUST onl= y >> use the parameters included in the requestobject. * > > > Nat, John, everyone - *does this mean a JAR compliant AS ignores > everything outside of the request object while OIDC Request Object one > merges the two with the ones in the request object being used over ones > that are sent in clear?* The OIDC language also includes sections which > make sure that some required arguments are still passed outside of the > request object with the same value to make sure the request is "valid" > OAuth 2.0 request (client_id, response_type), something which an example = in > the JAR spec does not do. Not having this language means that existing > authorization request pipelines can't simply be extended with e.g. a > middleware, they need to branch their codepaths. > > Is an AS required to choose which of the two it follows? > > Thank you for clarifying this in advance. I think if either the behaviour > is the same as in OIDC or different this should be called out in the > language to avoid confusion, especially since this already exists in OIDC > and likely isn't going to be read in isolation, especially because the > Request Object is even called out to be already in place in OIDC in the J= AR > draft. > > Best, > *Filip* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008775cd059133b47c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Filip, for better or worse, I believe your assessment of t= he situation is correct. I know of one AS that didn't choose which of t= he two to follow but rather implemented a bit of a hybrid where it basicall= y ignores everything outside of the request object per JAR but also checks = for and enforces the presence and value of the few regular parameters (clie= nt_id, response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 = AM Filip Skokan <panva.ip@gmail.com> wrote:
Hello e= veryone,

in an earlier thread I've posed the following question tha= t might have gotten missed, this might have consequences for the existing i= mplementations of Request Objects in OIDC implementations - its making pure= JAR requests incompatible with OIDC Core implementations.

draft 14 of= jwsreq (JAR) introduced this language

The client MAY send the parameters included in the req= uest object
duplicated in the query parameters as well for the backward<= br>compatibility etc. =C2=A0However, the authorization server supporting= this
specification MUST only use the parameters included in the request=
object.=C2=A0

Server MUST only use the = parameters in the Request Object even if the
same parameter is provided = in the query parameter.=C2=A0 The Authorization

The client MAY send the parameters inc= luded in the request object
duplicated in the query parameters as well f= or the backward
compatibility etc. =C2=A0However, the authorization s= erver supporting this
specification MUST only use the parameters include= d in the request
object.=C2=A0

Nat, John, everyone -=C2=A0does this mean a= JAR compliant AS ignores everything outside of the request object while OI= DC Request Object one merges the two with the ones in the request object be= ing used over ones that are sent in clear?=C2=A0The OIDC language also = includes sections which make sure that some required arguments are still pa= ssed outside of the request object with the same value to make sure the req= uest is "valid" OAuth 2.0 request (client_id, response_type), som= ething which an example in the JAR spec does not do. Not having this langua= ge means that existing authorization request pipelines can't simply be = extended with e.g. a middleware, they need to branch their codepaths.
=

I= s an AS required to choose which of the two it follows?

Thank you for c= larifying this in advance. I think if either the behaviour is the same as i= n OIDC or different this should be called out in the language to avoid conf= usion, especially since this already exists in OIDC and likely isn't go= ing to be read in isolation, especially because the Request Object is even = called out to be already in place in OIDC in the JAR draft.

Best,
Filip
_______________________________________________
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. --0000000000008775cd059133b47c-- From nobody Wed Aug 28 14:23:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AA71200A3 for ; Wed, 28 Aug 2019 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFegjW_E9Alb for ; Wed, 28 Aug 2019 14:23:27 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D8941120059 for ; Wed, 28 Aug 2019 14:23:26 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id p23so1339567oto.0 for ; Wed, 28 Aug 2019 14:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fjm/5bv5z2UQ27WRdQrAENLYuTtey/H0eRSonOACpas=; b=iA2liXCpEPT7AGBbcQr65MSjR55+p1Uca/+KZHKv7tG2+vwte4xJAHFnFOW11w9DTE 2/veLmd70mGU/BYCxbqYiTraremTyY3ggu9ASmWk4CfXswri3qclNMytlRzVtHtimmk4 MFnmv2FpNtzCbwrPIeG0fRpGI5ufjy9KogCjUI6FB6BYZuMHqR9Ih3Y9v46lNNjMkd4N qAAbcAxs5r+5zENBvXs/3+3KNCUL6xyuuKT1amWAobuzoR5Kj2T2U07mzmnrMHNPY/mT ZAva3ERulY9IDzTh+ACM8g9HGCEfHVoHdhe9cVQGOhpHNrfKL5W7Q8fuOlvb0Zq/OBCf 9/GA== 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=Fjm/5bv5z2UQ27WRdQrAENLYuTtey/H0eRSonOACpas=; b=axKESlJj0NP5KNFN1E75lPk6eRChDa8qBaKAB4J4HTufXaA3jdI5XIt/bjiCq+ATAi pFK0O0SqgjACPEMrM2t/vhc1/oyhvBu8stgC10KQ+Jc2CsLyKYNfnouhpld1fKL/alJW McI2hheMJRW6NvP+SKcHfu+vuULTvDcJlGDlhmgKhug4PO0j/qnnuKHYaThum8rVMvQz LNRFUczVUSQf+vOHmvpf1dJAajymZvgIMBSYQvH7UspUq2bP0EG0qMGE8aPmAnkMWP52 Cc/O+EfKL5a4LlfWI5RsICK4IktvP2uz3fcNP5716vfeYSM5MX3EshQ0Df+oX6BTFtZG T0vw== X-Gm-Message-State: APjAAAWuAbXRvwglHYpbRsL1lXUM+3rvKJCZg8XIQ55kaffdlZq988KK KXBzY582/UicHkF6foctkiRYa04FlyPmwYAgvw== X-Google-Smtp-Source: APXvYqyWwTwsLgog0ewuPk7+lLiDJyEcKBWek6JvYqSQlD4vQgFW12EppThgw2RZn1TEenWpEfdxWuAsSHJUU5QTC0k= X-Received: by 2002:a05:6830:1e6e:: with SMTP id m14mr5262383otr.258.1567027405964; Wed, 28 Aug 2019 14:23:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Wed, 28 Aug 2019 23:23:14 +0200 Message-ID: To: Brian Campbell Cc: oauth , Nat Sakimura , John Bradley Content-Type: multipart/alternative; boundary="000000000000e2cadc059133ffcd" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 21:23:31 -0000 --000000000000e2cadc059133ffcd Content-Type: text/plain; charset="UTF-8" Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this was changed. My take on satisfying both worlds looks like this - allow just JAR - no other params when possible. (which btw isn't possible to do with request_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 shows as much) - enforce the "dupe behaviours" defined in OIDC (if response_type or client_id is in request object it must either be missing or the same in regular request). - allows merging request object and regular parameters with request object taking precedence since it is a very useful feature when having pre-signed request object that's not one time use and clients using it wish to vary state/nonce per-request. I wish the group reconsidered making this breaking change from OIDC's take on request objects - allow combination of parameters from the request object with ones from regular parameters (if not present in request object). S pozdravem, *Filip Skokan* On Wed, 28 Aug 2019 at 23:02, Brian Campbell wrote: > Filip, for better or worse, I believe your assessment of the situation is > correct. I know of one AS that didn't choose which of the two to follow but > rather implemented a bit of a hybrid where it basically ignores everything > outside of the request object per JAR but also checks for and enforces the > presence and value of the few regular parameters (client_id, response_type) > that OIDC mandates. > > On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote: > >> Hello everyone, >> >> in an earlier thread I've posed the following question that might have >> gotten missed, this might have consequences for the existing >> implementations of Request Objects in OIDC implementations - its making >> pure JAR requests incompatible with OIDC Core implementations. >> >> draft 14 of jwsreq (JAR) introduced this language >> >> The client MAY send the parameters included in the request object >>> duplicated in the query parameters as well for the backward >>> compatibility etc. >>> >>> *However, the authorization server supporting thisspecification MUST >>> only use the parameters included in the requestobject. * >> >> >> Server MUST only use the parameters in the Request Object even if the >>> same parameter is provided in the query parameter. The Authorization >> >> >> The client MAY send the parameters included in the request object >>> duplicated in the query parameters as well for the backward >>> compatibility etc. >>> >>> *However, the authorization server supporting thisspecification MUST >>> only use the parameters included in the requestobject. * >> >> >> Nat, John, everyone - *does this mean a JAR compliant AS ignores >> everything outside of the request object while OIDC Request Object one >> merges the two with the ones in the request object being used over ones >> that are sent in clear?* The OIDC language also includes sections which >> make sure that some required arguments are still passed outside of the >> request object with the same value to make sure the request is "valid" >> OAuth 2.0 request (client_id, response_type), something which an example in >> the JAR spec does not do. Not having this language means that existing >> authorization request pipelines can't simply be extended with e.g. a >> middleware, they need to branch their codepaths. >> >> Is an AS required to choose which of the two it follows? >> >> Thank you for clarifying this in advance. I think if either the behaviour >> is the same as in OIDC or different this should be called out in the >> language to avoid confusion, especially since this already exists in OIDC >> and likely isn't going to be read in isolation, especially because the >> Request Object is even called out to be already in place in OIDC in the JAR >> draft. >> >> Best, >> *Filip* >> _______________________________________________ >> 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.* --000000000000e2cadc059133ffcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well it kind of blows, doesn't it? I wasn't a= ble to find the "why" anywhere in the mailing list archive around= the time this was changed.

My take on satisfying = both worlds looks like this

- allow just JAR - no = other params when possible.
=C2=A0 =C2=A0 (which btw isn't po= ssible to do with request_uri when enforcing client based uri whitelist and= the jwsreq 5.2.2 shows as much)
- enforce the "dupe behavio= urs" defined in OIDC (if response_type or client_id is in request obje= ct it must either be missing or the same in regular request).
- a= llows merging request object and regular parameters with request object tak= ing=C2=A0precedence since it is a very useful feature when having pre-signe= d request object that's not one time use and clients using it wish to v= ary state/nonce per-request.

I wish the group reco= nsidered making this breaking change from OIDC's take on request object= s - allow combination of parameters from the request object with ones from = regular parameters (if not present in request object).

S pozdravem,
Filip Skokan


On Wed, 28 Au= g 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com> wrote:
Filip, for better or wors= e, I believe your assessment of the situation is correct. I know of one AS = that didn't choose which of the two to follow but rather implemented a = bit of a hybrid where it basically ignores everything outside of the reques= t object per JAR but also checks for and enforces the presence and value of= the few regular parameters (client_id, response_type) that OIDC mandates. =

On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> wrote:
Hello everyone,

in an earlier thread I've= posed the following question that might have gotten missed, this might hav= e consequences for the existing implementations of Request Objects in OIDC = implementations - its making pure JAR requests incompatible with OIDC Core = implementations.

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request objectduplicated in the query parameters as well for the backward
compatibili= ty etc. =C2=A0However, the authorization server supporting this
speci= fication MUST only use the parameters included in the request
object.=C2= =A0

Server MUST only use the parameters in th= e Request Object even if the
same parameter is provided in the query par= ameter.=C2=A0 The Authorization

<= 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">The client MAY send the pa= rameters included in the request object
duplicated in the query paramete= rs as well for the backward
compatibility etc. =C2=A0However, the aut= horization server supporting this
specification MUST only use the parame= ters included in the request
object.=C2=A0

Nat, John, everyone -=C2=A0does= this mean a JAR compliant AS ignores everything outside of the request obj= ect while OIDC Request Object one merges the two with the ones in the reque= st object being used over ones that are sent in clear?=C2=A0The OIDC la= nguage also includes sections which make sure that some required arguments = are still passed outside of the request object with the same value to make = sure the request is "valid" OAuth 2.0 request (client_id, respons= e_type), something which an example in the JAR spec does not do. Not having= this language means that existing authorization request pipelines can'= t simply be extended with e.g. a middleware, they need to branch their code= paths.

Is an AS required to choose which of the two it follows?

Tha= nk you for clarifying this in advance. I think if either the behaviour is t= he same as in OIDC or different this should be called out in the language t= o avoid confusion, especially since this already exists in OIDC and likely = isn't going to be read in isolation, especially because the Request Obj= ect is even called out to be already in place in OIDC in the JAR draft.
Best,
Filip
_______________________________________________
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. --000000000000e2cadc059133ffcd-- From nobody Wed Aug 28 14:38:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF80D120089 for ; Wed, 28 Aug 2019 14:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 5W2HgXPKxQ4j for ; Wed, 28 Aug 2019 14:38:45 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82666120059 for ; Wed, 28 Aug 2019 14:38:45 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id t17so1560932wmi.2 for ; Wed, 28 Aug 2019 14:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JIHp3aYI7erKFH10r77NOQobL7sgUvg1Fpiwhu+sd6c=; b=RWzE1XtSFosQGynE0PPok3rIpd2EXSTk+/SyGqKmioOqkfGn53dqurIhVS8+FqZPXM U7Al1AB7fEHYFT8597ZXSl+MHRILzF83L+SQ1fCQZMaf3aE8Y365pJVHVtpW8Wa2h5fO nJSCv6nqQhrDO60a/c8Fqc2PEBJcXQkOwE+X4ovYP5YlBKs7N6EOy3JCIzrJKwWdIAdg jRPwAbuk3rXWfaBtbnYWUPJi/CXeCqAgVZEu2JLMEp/HGqMAnlVfPQPoYe5RT7FDy/7D gnAzgWYkvSZeZZ2YNgHOXp0h+4M4jCn5QeDMOIzAGOWUdCP9x8OAVshbE6B814xOYvdo dLBQ== 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=JIHp3aYI7erKFH10r77NOQobL7sgUvg1Fpiwhu+sd6c=; b=OiyOKgPepnstdN8FwHLGnwS9vkDNVs4chf9UDlIp83BAn5VZcAbdFU3YEOGl4dgdoQ E7hUy/KB240rfhhG7/5lZCW5M33+5JTg9OyAZIdiDA7rzAxPlilaIS1PHsIj5jmF3l/w /9Khxnj5VlsdsZgClNtKvu2fHkqPselVeuO+T+l61qWFBtS1lAf6eBQEnjEXgQIg1iMK OFPINbBYcYm3acDbzPKe/U1SbBjlBOt9okc+2wSKP+CPmNRpgFKBU9kG9RE12Z6j9Epz 5aUMRJFNZJXv1bDFUHWQcI+oN4nzDM92RPK4nAsh7h8L3T6lpXyZnsON3dYElx1Wytem 2uhg== X-Gm-Message-State: APjAAAUoMN6Q0rE3Tzz9dlsp0phqJN0E8ITGuFrz+WdZuiXsUcrlAauf 49kTnAzYtbex7WR2vAtt4Q== X-Google-Smtp-Source: APXvYqxd6SvmyeNjhRVfIk/9VDrB7JoeCXjDIx7z0Dtb0ZeW5rFZ4ogjDDBefPV+0AC+TqA7duIHAw== X-Received: by 2002:a1c:b6d4:: with SMTP id g203mr7263583wmf.100.1567028323907; Wed, 28 Aug 2019 14:38:43 -0700 (PDT) Received: from [100.96.66.97] (ip-37-188-149-253.eurotel.cz. [37.188.149.253]) by smtp.gmail.com with ESMTPSA id a17sm408609wmm.47.2019.08.28.14.38.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 14:38:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-BA0F4F27-401A-4A37-9AF7-7DE3DC512D63 Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16G77) In-Reply-To: Date: Wed, 28 Aug 2019 23:38:42 +0200 Cc: oauth , Nat Sakimura , John Bradley Content-Transfer-Encoding: 7bit Message-Id: <0265E9D0-E507-4B83-8872-33E64142EE68@gmail.com> References: To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 21:38:50 -0000 --Apple-Mail-BA0F4F27-401A-4A37-9AF7-7DE3DC512D63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It would be fine not allowing that across the board but rather through a lan= guage like so =E2=80=98Authorization Servers MAY allow per-transaction parameters such as =E2= =80=9Cstate=E2=80=9D and =E2=80=9Cnonce=E2=80=9D to be sent outside of the R= equest Object using regular OAuth 2.0 parameter syntax, the specific paramet= ers are at the implementer=E2=80=99s discretion=E2=80=99 Odesl=C3=A1no z iPhonu 28. 8. 2019 v 23:23, Filip Skokan : > Well it kind of blows, doesn't it? I wasn't able to find the "why" anywher= e in the mailing list archive around the time this was changed. >=20 > My take on satisfying both worlds looks like this >=20 > - allow just JAR - no other params when possible. > (which btw isn't possible to do with request_uri when enforcing client= based uri whitelist and the jwsreq 5.2.2 shows as much) > - enforce the "dupe behaviours" defined in OIDC (if response_type or clien= t_id is in request object it must either be missing or the same in regular r= equest). > - allows merging request object and regular parameters with request object= taking precedence since it is a very useful feature when having pre-signed r= equest object that's not one time use and clients using it wish to vary stat= e/nonce per-request. >=20 > I wish the group reconsidered making this breaking change from OIDC's take= on request objects - allow combination of parameters from the request objec= t with ones from regular parameters (if not present in request object). >=20 > S pozdravem, > Filip Skokan >=20 >=20 >> On Wed, 28 Aug 2019 at 23:02, Brian Campbell = wrote: >> Filip, for better or worse, I believe your assessment of the situation is= correct. I know of one AS that didn't choose which of the two to follow but= rather implemented a bit of a hybrid where it basically ignores everything o= utside of the request object per JAR but also checks for and enforces the pr= esence and value of the few regular parameters (client_id, response_type) th= at OIDC mandates.=20 >>=20 >>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote:= >>> Hello everyone, >>>=20 >>> in an earlier thread I've posed the following question that might have g= otten missed, this might have consequences for the existing implementations o= f Request Objects in OIDC implementations - its making pure JAR requests inc= ompatible with OIDC Core implementations. >>>=20 >>> draft 14 of jwsreq (JAR) introduced this language >>>=20 >>>> The client MAY send the parameters included in the request object >>>> duplicated in the query parameters as well for the backward >>>> compatibility etc. However, the authorization server supporting this >>>> specification MUST only use the parameters included in the request >>>> object.=20 >>>=20 >>>> Server MUST only use the parameters in the Request Object even if the >>>> same parameter is provided in the query parameter. The Authorization >>>=20 >>>> The client MAY send the parameters included in the request object >>>> duplicated in the query parameters as well for the backward >>>> compatibility etc. However, the authorization server supporting this >>>> specification MUST only use the parameters included in the request >>>> object.=20 >>>=20 >>> Nat, John, everyone - does this mean a JAR compliant AS ignores everythi= ng outside of the request object while OIDC Request Object one merges the tw= o with the ones in the request object being used over ones that are sent in c= lear? The OIDC language also includes sections which make sure that some req= uired arguments are still passed outside of the request object with the same= value to make sure the request is "valid" OAuth 2.0 request (client_id, res= ponse_type), something which an example in the JAR spec does not do. Not hav= ing this language means that existing authorization request pipelines can't s= imply be extended with e.g. a middleware, they need to branch their codepath= s. >>>=20 >>> Is an AS required to choose which of the two it follows? >>>=20 >>> Thank you for clarifying this in advance. I think if either the behaviou= r is the same as in OIDC or different this should be called out in the langu= age to avoid confusion, especially since this already exists in OIDC and lik= ely isn't going to be read in isolation, especially because the Request Obje= ct is even called out to be already in place in OIDC in the JAR draft. >>>=20 >>> Best, >>> Filip >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution 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. --Apple-Mail-BA0F4F27-401A-4A37-9AF7-7DE3DC512D63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable It would be fine not allowing that across t= he board but rather through a language like so

=E2=80=98A= uthorization Servers MAY allow per-transaction parameters such as =E2=80=9Cs= tate=E2=80=9D and =E2=80=9Cnonce=E2=80=9D to be sent outside of the Request O= bject using regular OAuth 2.0 parameter syntax, the specific parameters are a= t the implementer=E2=80=99s discretion=E2=80=99

Odesl=C3=A1no z iPhonu

28. 8. 2019 v 23:23, Filip Skokan <panva.ip@gmail.com>:

Well it kind of blows, doesn't it?= I wasn't able to find the "why" anywhere in the mailing list archive around= the time this was changed.

My take on satisfying b= oth worlds looks like this

- allow just JAR - no ot= her params when possible.
    (which btw isn't possible t= o do with request_uri when enforcing client based uri whitelist and the jwsr= eq 5.2.2 shows as much)
- enforce the "dupe behaviours" defined in= OIDC (if response_type or client_id is in request object it must either be m= issing or the same in regular request).
- allows merging request o= bject and regular parameters with request object taking precedence sinc= e it is a very useful feature when having pre-signed request object that's n= ot one time use and clients using it wish to vary state/nonce per-request.

I wish the group reconsidered making this breaking c= hange from OIDC's take on request objects - allow combination of parameters f= rom the request object with ones from regular parameters (if not present in r= equest object).

S pozdravem,
Filip Skoka= n


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.com> wr= ote:
Filip, for better or worse, I believe your assessment of the situation is= correct. I know of one AS that didn't choose which of the two to follow but= rather implemented a bit of a hybrid where it basically ignores everything o= utside of the request object per JAR but also checks for and enforces the pr= esence and value of the few regular parameters (client_id, response_type) th= at OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <panva.ip@gmail.com> w= rote:
Hello everyone,

in an earlier thread= I've posed the following question that might have gotten missed, this might= have consequences for the existing implementations of Request Objects in OI= DC implementations - its making pure JAR requests incompatible with OIDC Cor= e implementations.

draft 14 of jwsreq (JAR) introduced this language

Server MUST only use the parameters in the Request Ob= ject even if the
same parameter is provided in the query parameter. = The Authorization

The client MAY send the parameters included i= n the request object
duplicated in the query parameters as well for the b= ackward
compatibility etc.  However, the authorization server sup= porting this
specification MUST only use the parameters included in the r= equest
object. 

Nat, John, everyone - does this mean a JAR complia= nt AS ignores everything outside of the request object while OIDC Request Ob= ject one merges the two with the ones in the request object being used over o= nes that are sent in clear? The OIDC language also includes section= s which make sure that some required arguments are still passed outside of t= he request object with the same value to make sure the request is "valid" OA= uth 2.0 request (client_id, response_type), something which an example in th= e JAR spec does not do. Not having this language means that existing authori= zation request pipelines can't simply be extended with e.g. a middleware, th= ey need to branch their codepaths.

=
Is an AS required to choose which of t= he two it follows?

Thank you for clarifying this in advance. I think if e= ither the behaviour is the same as in OIDC or different this should be calle= d out in the language to avoid confusion, especially since this already exis= ts in OIDC and likely isn't going to be read in isolation, especially becaus= e the Request Object is even called out to be already in place in OIDC in th= e JAR draft.

Best,
Filip
_______________________________________________
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 y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.
= --Apple-Mail-BA0F4F27-401A-4A37-9AF7-7DE3DC512D63-- From nobody Wed Aug 28 14:55:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A45812013D for ; Wed, 28 Aug 2019 14:55:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CEZjlJ-OSdZh for ; Wed, 28 Aug 2019 14:55:52 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 BA57C12011B for ; Wed, 28 Aug 2019 14:55:52 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id t6so2670057ios.7 for ; Wed, 28 Aug 2019 14:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HXjB1f5wpiJsww9nDHbtLjFZHpZm4VpthitZ0j7tvo0=; b=c6gQdv507N3NFIPmRKSvcHbsH/owqfMfIIOAwq+wXKeQP/c7Ig4i0Za3j+Z1jtJLRF n13v93whu6GqfzZmrwFQjiXhDIcG2MI2VQ4p6pqOjuQQW+5yG/zGq/aDtRdmymtlo+II 9guHkJ8NFA8lwQ2bvWu9n2uid3S+Wd5LdkAmM= 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=HXjB1f5wpiJsww9nDHbtLjFZHpZm4VpthitZ0j7tvo0=; b=c2dzPiVxhHxws+J7A2hIfZKShxfHnbByM9sswQ79tlUJnqeLfZ1xvuVEvh3/gOkuu7 WUw9WGmGO1vcegdcN8blstevIq7h64VyjEZLlcOZSE38iQc2ALzZbvDG792LX1z6kNMi jFmH8irT0KvdYuXLTyYxJGgCwb71VZ4pfUwpHWWBe7h6xTMu0c2BW920h/7UZBoS76Oq ggxzqdPvRyFi2EjBH2CaXUBlYcGocLdl/SlEUMgohT7BTJA8sqYshqKzHO2ZR4dUgtPN iTV+xco2dM9oHlXFgBkhWD4mHGDJXveWGoTm6X9oFYtFZSizxpw1JICSC9BSo4pRf5Bn 9uGQ== X-Gm-Message-State: APjAAAUOMdafBFcJUO+G3ix7jWbk4gLTFAXDTFtdUAS8/9G0PR6LdmrF SE7ZQSJvIvYe6VRQc8471T3DFKEoHeZgaK5SJMIAS/f/c91HfeXZLy+Y5rY0CfmhQBsYejbz/3n BWZROi0zn5irXfw== X-Google-Smtp-Source: APXvYqzTUlGk5+RG7rLZevWGvvtYphm+cSgMRMRJ2wZVCw8kq+cJKbTdFf9NZm8+wGE9qzJMn6isK7bQ/YDpInfBOHE= X-Received: by 2002:a02:c00c:: with SMTP id y12mr6861656jai.65.1567029351957; Wed, 28 Aug 2019 14:55:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 28 Aug 2019 15:55:26 -0600 Message-ID: To: Filip Skokan Cc: oauth , Nat Sakimura , John Bradley Content-Type: multipart/alternative; boundary="000000000000e0619805913473b1" Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 21:55:56 -0000 --000000000000e0619805913473b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, as best I can remember the change in question came as I result of directorate/IESG review rather than a WG decision/discussion. Which is likely why you can't find the "why" anywhere in the mailing list archive. On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: > Well it kind of blows, doesn't it? I wasn't able to find the "why" > anywhere in the mailing list archive around the time this was changed. > > My take on satisfying both worlds looks like this > > - allow just JAR - no other params when possible. > (which btw isn't possible to do with request_uri when enforcing clien= t > based uri whitelist and the jwsreq 5.2.2 shows as much) > - enforce the "dupe behaviours" defined in OIDC (if response_type or > client_id is in request object it must either be missing or the same in > regular request). > - allows merging request object and regular parameters with request objec= t > taking precedence since it is a very useful feature when having pre-signe= d > request object that's not one time use and clients using it wish to vary > state/nonce per-request. > > I wish the group reconsidered making this breaking change from OIDC's tak= e > on request objects - allow combination of parameters from the request > object with ones from regular parameters (if not present in request objec= t). > > S pozdravem, > *Filip Skokan* > > > On Wed, 28 Aug 2019 at 23:02, Brian Campbell > wrote: > >> Filip, for better or worse, I believe your assessment of the situation i= s >> correct. I know of one AS that didn't choose which of the two to follow = but >> rather implemented a bit of a hybrid where it basically ignores everythi= ng >> outside of the request object per JAR but also checks for and enforces t= he >> presence and value of the few regular parameters (client_id, response_ty= pe) >> that OIDC mandates. >> >> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan wrote: >> >>> Hello everyone, >>> >>> in an earlier thread I've posed the following question that might have >>> gotten missed, this might have consequences for the existing >>> implementations of Request Objects in OIDC implementations - its making >>> pure JAR requests incompatible with OIDC Core implementations. >>> >>> draft 14 of jwsreq (JAR) introduced this language >>> >>> The client MAY send the parameters included in the request object >>>> duplicated in the query parameters as well for the backward >>>> compatibility etc. >>>> >>>> *However, the authorization server supporting thisspecification MUST >>>> only use the parameters included in the requestobject. * >>> >>> >>> Server MUST only use the parameters in the Request Object even if the >>>> same parameter is provided in the query parameter. The Authorization >>> >>> >>> The client MAY send the parameters included in the request object >>>> duplicated in the query parameters as well for the backward >>>> compatibility etc. >>>> >>>> *However, the authorization server supporting thisspecification MUST >>>> only use the parameters included in the requestobject. * >>> >>> >>> Nat, John, everyone - *does this mean a JAR compliant AS ignores >>> everything outside of the request object while OIDC Request Object one >>> merges the two with the ones in the request object being used over ones >>> that are sent in clear?* The OIDC language also includes sections which >>> make sure that some required arguments are still passed outside of the >>> request object with the same value to make sure the request is "valid" >>> OAuth 2.0 request (client_id, response_type), something which an exampl= e in >>> the JAR spec does not do. Not having this language means that existing >>> authorization request pipelines can't simply be extended with e.g. a >>> middleware, they need to branch their codepaths. >>> >>> Is an AS required to choose which of the two it follows? >>> >>> Thank you for clarifying this in advance. I think if either the >>> behaviour is the same as in OIDC or different this should be called out= in >>> the language to avoid confusion, especially since this already exists i= n >>> OIDC and likely isn't going to be read in isolation, especially because= the >>> Request Object is even called out to be already in place in OIDC in the= JAR >>> draft. >>> >>> Best, >>> *Filip* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e0619805913473b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, as best I can remember the change in question came a= s I result of directorate/IES= G review rather than a WG decision/discussion. Which is likely why you can&= #39;t find the "why" anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <panva.ip@gmail.com> wrote:
= Well it kind of blows, doesn't it? I wasn't able to find the "= why" anywhere in the mailing list archive around the time this was cha= nged.

My take on satisfying both worlds looks like= this

- allow just JAR - no other params when poss= ible.
=C2=A0 =C2=A0 (which btw isn't possible to do with requ= est_uri when enforcing client based uri whitelist and the jwsreq 5.2.2 show= s as much)
- enforce the "dupe behaviours" defined in O= IDC (if response_type or client_id is in request object it must either be m= issing or the same in regular request).
- allows merging request = object and regular parameters with request object taking=C2=A0precedence si= nce it is a very useful feature when having pre-signed request object that&= #39;s not one time use and clients using it wish to vary state/nonce per-re= quest.

I wish the group reconsidered making this b= reaking change from OIDC's take on request objects - allow combination = of parameters from the request object with ones from regular parameters (if= not present in request object).

S pozdravem,
Filip Skokan


On Wed, 28 Aug 2019 at 23:02, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
Filip, for better or worse, I believe your assessment of = the situation is correct. I know of one AS that didn't choose which of = the two to follow but rather implemented a bit of a hybrid where it basical= ly ignores everything outside of the request object per JAR but also checks= for and enforces the presence and value of the few regular parameters (cli= ent_id, response_type) that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47= AM Filip Skokan <panva.ip@gmail.com> wrote:
Hello = everyone,

in an earlier thread I've posed the following question th= at might have gotten missed, this might have consequences for the existing = implementations of Request Objects in OIDC implementations - its making pur= e JAR requests incompatible with OIDC Core implementations.

draft 14 of= jwsreq (JAR) introduced this language

=
The client MAY send= the parameters included in the request object
duplicated in the query p= arameters as well for the backward
compatibility etc. =C2=A0However, = the authorization server supporting this
specification MUST only use the= parameters included in the request
object.=C2=A0
<= br>
Server MUST only use the parameters in the Request Object even if t= he
same parameter is provided in the query parameter.=C2=A0 The Authoriz= ation

The client MAY send the parameters included i= n the request object
duplicated in the query parameters as well for the = backward
compatibility etc. =C2=A0However, the authorization server s= upporting this
specification MUST only use the parameters included in th= e request
object.=C2=A0

Nat, John, everyone -=C2=A0does this mean a JAR co= mpliant AS ignores everything outside of the request object while OIDC Requ= est Object one merges the two with the ones in the request object being use= d over ones that are sent in clear?=C2=A0The OIDC language also include= s sections which make sure that some required arguments are still passed ou= tside of the request object with the same value to make sure the request is= "valid" OAuth 2.0 request (client_id, response_type), something = which an example in the JAR spec does not do. Not having this language mean= s that existing authorization request pipelines can't simply be extende= d with e.g. a middleware, they need to branch their codepaths.

Is an AS= required to choose which of the two it follows?

Thank you for clarifyi= ng this in advance. I think if either the behaviour is the same as in OIDC = or different this should be called out in the language to avoid confusion, = especially since this already exists in OIDC and likely isn't going to = be read in isolation, especially because the Request Object is even called = out to be already in place in OIDC in the JAR draft.

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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e0619805913473b1-- From nobody Thu Aug 29 01:04:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78471207FD for ; Thu, 29 Aug 2019 01:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nIcR6FB-1RM0 for ; Thu, 29 Aug 2019 01:04:13 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) (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 7684C120020 for ; Thu, 29 Aug 2019 01:04:13 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.116]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i3FPd-0003br-Is; Thu, 29 Aug 2019 10:04:09 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-29D920BB-F96A-4A7B-BAE8-1E9093EA6F23; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16G102) In-Reply-To: Date: Thu, 29 Aug 2019 10:04:09 +0200 Cc: Brian Campbell , oauth , Nat Sakimura Content-Transfer-Encoding: 7bit Message-Id: References: To: Filip Skokan X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 08:04:16 -0000 --Apple-Mail-29D920BB-F96A-4A7B-BAE8-1E9093EA6F23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Am 28.08.2019 um 23:23 schrieb Filip Skokan : >=20 > - allows merging request object and regular parameters with request object= taking precedence since it is a very useful feature when having pre-signed r= equest object that's not one time use and clients using it wish to vary stat= e/nonce per-request. +1= --Apple-Mail-29D920BB-F96A-4A7B-BAE8-1E9093EA6F23 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCnQw ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBTowggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0G CSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0x ODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSm v9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+pUy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7 P3GcYleN1waJRH981U81XzH2clCg9+YRnIUpvof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UO VblWAeQvGCvsV2TlPNCOXOtphvG137/0s048LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5 sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btpWfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb 2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCCAekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStx SF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNV HRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCB iwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA67MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZby CyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQkoKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/u U092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0n NI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQb k4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJeQ0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggPJ MIIDxQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0 aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAId3I3cH 21UuPcbaTCkHebYwDQYJYIZIAWUDBAIBBQCgggHtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE5MDgyOTA4MDQwOVowLwYJKoZIhvcNAQkEMSIEINtNOkFrbdareavR xBHe3SgauUNZlU1jJLTz8HlWc+7hMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQAjOMBp70jX+P701k79bV+9IFS3v7D2lz84Yyzs kAhE5qr/mb/1Rdsd8zw8R0dLg4GDoBic9d2n1k8abml9wMHpoicCO2S2NGDLLtoBauvH+jEeSbdr /B5HziumBM+pzIZbW35iC+wkL1DuqWUzUfF0m/h2+NiZwsaTOo25Cpm8AWL9ESJX2SLJRJ9imaEP rPyd0dAKB0BmaUjOjyViPu4DG+BAlEHVvt2bO7WpPvjb03gTKJgYkkzJ1lp7Cv5JcIQVzIaN1l8v 4DL67bQwLX8dxw0Pu9bb5qmcd3CPiez45T4mHepS7wQno09DAyyHmEGeL0QTB4d7KPTFX+S6FwFo AAAAAAAA --Apple-Mail-29D920BB-F96A-4A7B-BAE8-1E9093EA6F23-- From nobody Thu Aug 29 05:51:20 2019 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 B59E412004A; Thu, 29 Aug 2019 05:51:19 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156708307970.21077.13816281614863237542@ietfa.amsl.com> Date: Thu, 29 Aug 2019 05:51:19 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 12:51:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-07.txt Pages : 18 Date : 2019-08-29 Abstract: This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 29 05:53:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C75D120840; Thu, 29 Aug 2019 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AaceoE4OXj0j; Thu, 29 Aug 2019 05:52:43 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E29912082A; Thu, 29 Aug 2019 05:52:40 -0700 (PDT) Received: from [91.13.158.20] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i3Jun-0007Me-6Z; Thu, 29 Aug 2019 14:52:37 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_87E7FF5E-5975-4165-8758-4140C92FD7DC"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 14:52:36 +0200 In-Reply-To: <156699126575.32385.6288194399756449704.idtracker@ietfa.amsl.com> Cc: The IESG , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org To: Alexey Melnikov References: <156699126575.32385.6288194399756449704.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwt-introspection-response-06: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 12:52:59 -0000 --Apple-Mail=_87E7FF5E-5975-4165-8758-4140C92FD7DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alexey,=20 > On 28. Aug 2019, at 13:21, Alexey Melnikov via Datatracker = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a fine document. I only have one small issue that should be = easy to resolve: >=20 > In 8.3.1: >=20 > o Name: "locale" >=20 > o Description: Time the End-User's information was last updated. > Its value is a JSON number representing the number of seconds = from > 1970-01-01T0:0:0Z as measured in UTC until the date/time. >=20 > The description doesn=E2=80=99t seem to match the name. That=E2=80=99s certainly true. I fixed it and published = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-07= Thanks, Torsten.=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_87E7FF5E-5975-4165-8758-4140C92FD7DC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I 91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX 5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB 5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+ SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm 5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy /AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7 T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI 9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA4MjkxMjUyMzZaMC8GCSqGSIb3DQEJBDEiBCC/mapwT/Z6truKFOrfcSyOcZK1bRUsJNZz KW9rWLvKMTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAMzfWMYEYX7YKfthxKBXVdY+9hvXQkpivC9h1k4QZpPX83j05sCcpqjqTvFl 9t70C/3cVHoBxC4w+hgszgQudDcSd+dQlp1glrOxIom2AO82QCQpCFhsulAfMmGJkUNN9lsgAYS4 uRdWXgDRCUyjonwHCsj3GBi8PFDZKner3PqnA0ezrIgw4LMHSqk4piWX7IlOixpy9D+Fn7EBH4aZ Pi0fs1w0U5IrgHvpePEzsRf1Af4GXrUiCgB0bWarjxAfKjMF8aWKuqRBNmWGiN8koKloDlTQ1YDo TCwmbu9HcygPasTt97kxrscvlZX8zoI76NV6l89sdgDJ8wqcgcCni9cAAAAAAAA= --Apple-Mail=_87E7FF5E-5975-4165-8758-4140C92FD7DC-- From nobody Thu Aug 29 06:39:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3012B120105; Thu, 29 Aug 2019 06:39:28 -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, 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=lXYe/2Fy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mAx1FqD0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVnmNOr_CETc; Thu, 29 Aug 2019 06:39:26 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECDF120813; Thu, 29 Aug 2019 06:39:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CF2644FC; Thu, 29 Aug 2019 09:39:25 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 29 Aug 2019 09:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm1; bh=txF76 poe8+EMeP6UrkbWyKY5UZa7fAq7+BRumolnp/Q=; b=lXYe/2FyMSGPr37m7AfTD r930WRA3X8XuanQivTtmJG0LztXwGmKxtteWsWgahQo4rvOdIV8nM9v02bn8Dgy/ JSS0/Hw1KBzCIhbTmA2PhisOEgWDuzZ5rVjbrZn+ey1JtD7s5WcDNx0UOJ3U43bG eDVnJG+xKVZExRriDfMrxf9Fdod6SwhGi+lzy2poA19+3K/3IocZbtuC14qdklUV KXXZW8yC7snS+cCs5yBaGOVgEITNSSBxSbQmW+GFNp7Dh9MD6Wm85WdOtyL1ngRI BOr8DHRd+Ei0ZS5NziutFLN2s0+HG6xdqsKCLWAniCPmb5hYTztUgMigf943zJnQ w== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=txF76poe8+EMeP6UrkbWyKY5UZa7fAq7+BRumolnp /Q=; b=mAx1FqD00BW7qxdClhY4lTQBXCQGH6aljbhWkOHq9EWVYbNR2EQuWLw3K 5n0aNelwn6MCwPtXLMQ+YPl1J1rJ/QVB2zBn5CusybxJF1BpjboG5eCYxT/p+Xaf xMszaPT4mYUxtx/vAmueiNOYNlmQuVRas6I7zfRtURYqDH2dPJoilKgB/9cMjvxj rJN9WazVmr5gh2MGWzMoekLW7WIWVEQTnz6FVUC7KC9+4ftWHyp1Q/6aumpb6MdR GIA8knfhCaeAJEVYyaFg7SWh4zaLV+8pfgaVBsozu6nxGWKHUQzrFGIXXpLBg9PR Xxsr8NqQHI4swG6ao0ba48rM+3Wxg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeivddgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1A36BC200A4; Thu, 29 Aug 2019 09:39:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-154-gfa7592a-fmstable-20190829v1 Mime-Version: 1.0 Message-Id: <7ae29017-63ff-445b-8c22-eb0e605b63da@www.fastmail.com> In-Reply-To: References: <156699126575.32385.6288194399756449704.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 14:38:06 +0100 From: "Alexey Melnikov" To: "Torsten Lodderstedt" Cc: "The IESG" , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-o?= =?utf-8?q?auth-jwt-introspection-response-06=3A_=28with_DISCUSS=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 13:39:39 -0000 On Thu, Aug 29, 2019, at 1:52 PM, Torsten Lodderstedt wrote: > Hi Alexey,=20 >=20 > > On 28. Aug 2019, at 13:21, Alexey Melnikov via Datatracker wrote: > >=20 > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-oauth-jwt-introspection-response-06: Discuss > >=20 > > When responding, please keep the subject line intact and reply to al= l > > email addresses included in the To and CC lines. (Feel free to cut t= his > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= .html > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-= response/ > >=20 > >=20 > >=20 > > --------------------------------------------------------------------= -- > > DISCUSS: > > --------------------------------------------------------------------= -- > >=20 > > This is a fine document. I only have one small issue that should be = easy to resolve: > >=20 > > In 8.3.1: > >=20 > > o Name: "locale" > >=20 > > o Description: Time the End-User's information was last updated. > > Its value is a JSON number representing the number of seconds f= rom > > 1970-01-01T0:0:0Z as measured in UTC until the date/time. > >=20 > > The description doesn=E2=80=99t seem to match the name. >=20 > That=E2=80=99s certainly true. I fixed it and published=20 > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-respons= e-07 Thank you for the quick fix! From nobody Thu Aug 29 21:49:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77652120C9C; Thu, 29 Aug 2019 21:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UTFBZW9j4cB; Thu, 29 Aug 2019 21:49:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4021200D6; Thu, 29 Aug 2019 21:49:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 00525B806C3; Thu, 29 Aug 2019 21:48:52 -0700 (PDT) To: bayard.bell@twosigma.com, rfc8252@wdenniss.com, rfc8252@ve7jtb.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190830044853.00525B806C3@rfc-editor.org> Date: Thu, 29 Aug 2019 21:48:52 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Errata Rejected] RFC8252 (5848) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 04:49:12 -0000 The following errata report has been rejected for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5848 -------------------------------------- Status: Rejected Type: Technical Reported by: Bayard Bell Date Reported: 2019-08-26 Rejected by: Benjamin Kaduk (IESG) Section: Appendix B.1 Original Text ------------- Apps can initiate an authorization request in the browser, without the user leaving the app, through the "SFSafariViewController" class or its successor "SFAuthenticationSession", which implement the in- app browser tab pattern. Safari can be used to handle requests on old versions of iOS without in-app browser tab functionality. Corrected Text -------------- Apps can initiate an authorization request in the browser, without the user leaving the app, through the "ASWebAuthenticationSession" class or its successors "SFAuthenticationSession" and "SFSafariViewController", which implement the in-app browser tab pattern. The first of these allows calls to a handler registered for the AS URL, consistent with Section 7.2. The latter two classes, now deprecated, can use Safari to handle requests on old versions of iOS without in-app browser tab functionality. Notes ----- SFAuthenticationSession documentation reflects deprecated status: https://developer.apple.com/documentation/safariservices/sfauthenticationsession Here's the documentation for ASWebAuthenticationSession: https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession --VERIFIER NOTES-- This sort of change to update for events since the time of publication is not appropriate for an erratum; errata are intended solely to indicate errors in a document that were errors at the time of publication. A revision of the document or a new document with an "Updates:" relationship would be more appropriate ways to indicate that the situation has changed. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Aug 30 05:57:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0127212008D for ; Fri, 30 Aug 2019 05:57:03 -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, HTML_FONT_LOW_CONTRAST=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 (1024-bit key) header.d=wavestone.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 11a3eDM-QtVL for ; Fri, 30 Aug 2019 05:57:00 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130041.outbound.protection.outlook.com [40.107.13.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F6712004E for ; Fri, 30 Aug 2019 05:56:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CNbLpiGDyCssoaWH0oIfDKI63hrvfBkiGIXXtbwnKlzvMF16ysS135XTe/JtQl8HloMWS/aITuR/njQ8mA1mz5FfWV2gJSkglBNzO7CTjaHSW4v1hxXbt/p5Ua7c13NzSC+7Oe9zOb+dn/DCGhLHubt3xdmgompBWTAiAZyOrG3hWkFCTNYOgMZ0a0bPMG9KRkKFiXIp8ovsqc+2YvtGH3tDSlHy1RC5tJRfSU5bNQ9szgR9YqViKcundO4/G/DjIRPiG+3nRlMKfgo36hkjXz7OVcGOWuW3C3nzz7leq0VaqaF6Kkbo2dUhZg5LbZ7He0fLcVQmporHybxowYPvHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9h3mVTKY40zMSXAtVAyDp62Ssv0ymWlmhk1t1Jk8BO0=; b=m4+D1/FVCu6RRM/ytmfNwiYZt0wJbJKDl42QPvgFtUoMo31yKrezpPXiBtltyDpvkBJlH2VcHWw026plSjzeJB5XFSG1okDZokB9kPjwh6/YRaoJ3Yh0JWhgDdXZlvoVkecP4f/YSWjkMWDqZm/IQe0NPgKViqFxT2h1zT0efi1JIo98lzcJafTgvde9AgGumKXHNmFYpLCPQNeGG7S+oS7udK+AFjG8HJdsKRhrCRHUZzClZGoKWeheZShDOBFTseIEh461Nw3CLlPIabI66UQsA0GgeauAusavkAkXmXwu/5xSUFJgAukW9NBfT3SXLfKTBE/OuUhGDkVOWkT5oQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wavestone.com; dmarc=pass action=none header.from=wavestone.com; dkim=pass header.d=wavestone.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wavestone.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9h3mVTKY40zMSXAtVAyDp62Ssv0ymWlmhk1t1Jk8BO0=; b=FewPZ7EbWjTYdXxg5P3U4dsIXvlvifjV3OvDmVuuuZ/9peNXUK4wiq2OVkDAUxHXTeHVWbpYOJ5bGP2sfb+jyV6Z3LSTRw8rClR4hyGeQvji2mFuZWYYKND3E1PlxiqIifyGq1wGlzfSvAfMgeyUdrA2bhfipTrJCnLRmoqfUxE= Received: from DB8PR03MB6092.eurprd03.prod.outlook.com (10.255.17.82) by DB8PR03MB6106.eurprd03.prod.outlook.com (10.255.17.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 12:56:55 +0000 Received: from DB8PR03MB6092.eurprd03.prod.outlook.com ([fe80::3848:b35f:ccb4:8b54]) by DB8PR03MB6092.eurprd03.prod.outlook.com ([fe80::3848:b35f:ccb4:8b54%4]) with mapi id 15.20.2199.021; Fri, 30 Aug 2019 12:56:55 +0000 From: CARLIER Bertrand To: Lee McGovern , "oauth@ietf.org" Thread-Topic: OBO Flow Thread-Index: AdU1ZjJ6jhtWavl2ShC7aP4dgKcQaApy93TQ Date: Fri, 30 Aug 2019 12:56:55 +0000 Message-ID: References: <3a0d6d1dd94240b9ad1e1f53dd7fe417@CHRP5009.corp.gwpnet.com> In-Reply-To: <3a0d6d1dd94240b9ad1e1f53dd7fe417@CHRP5009.corp.gwpnet.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2019-07-08T08:24:36.0988705Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bertrand.CARLIER@wavestone.com; x-originating-ip: [165.225.77.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bdbad9c-c5e2-41c0-0c96-08d72d49897f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB8PR03MB6106; x-ms-traffictypediagnostic: DB8PR03MB6106: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(376002)(136003)(396003)(26244003)(189003)(199004)(8936002)(52536014)(476003)(486006)(81166006)(446003)(11346002)(81156014)(186003)(478600001)(5660300002)(7116003)(66066001)(66574012)(45080400002)(316002)(3480700005)(7696005)(26005)(71200400001)(66476007)(66556008)(64756008)(66446008)(76176011)(76116006)(221733001)(66946007)(53546011)(71190400001)(6506007)(55236004)(86362001)(606006)(110136005)(7736002)(74316002)(5024004)(256004)(102836004)(229853002)(99286004)(2906002)(14444005)(790700001)(14454004)(33656002)(8676002)(3846002)(9686003)(54896002)(53936002)(6116002)(236005)(6306002)(25786009)(55016002)(6436002)(6246003)(2501003)(53946003)(79990200002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR03MB6106; H:DB8PR03MB6092.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: wavestone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 35JRDKth0YkJI1tCCu4WGwSobqhARfVHKAN0WKNLHifrQKXy5VfoQR9D5PBfn9vlhG/sTF34LYMsbcaX3x4wPQgSHqQLnZGYxuqp9fAJ8pTbTuugfY+jHznAgWV7cp881jfmJrLAQT9KDmhaz3WWcsvhOV/2gcCMrGcMA78tt5UjVzVUavotz1emqEEXN6xM9yVpensKWMiI/JyzMlChGTzdGmRK2bwaHhJe2ApHMhrkprQQyGWyoGItWRafbia5xbkgSW1G5sdt/Q6WKLPncmSDTBpuwTQWT1Pe20jmegHrJaCC8zeZV9KDayEYgDS3JgmTYXV1Xw3YGgY8Vc6PNnWbXOtF3NRZRgU7Ld241exEiFuwi9acr9aaLapAvKTviXayItRwKNyze8+4bPnRxvt7peW8vgMJTXPPe9dBrWf/D+oTburDeKMka1NXtA41Q0bvrSq/QkW8Iy7VC+rnXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB8PR03MB609275BEAD0C2DC39F50986887BD0DB8PR03MB6092eurp_" MIME-Version: 1.0 X-OriginatorOrg: wavestone.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bdbad9c-c5e2-41c0-0c96-08d72d49897f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 12:56:55.6313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5de96c96-c87c-4dce-aad9-f5c557b52ac1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZezX1/stcbPMGwHnYlPhKOQCejrt9P6k51gd9ZI9KyVU/j1DJGzhYVB04WJK9HjRCLMO8Hl5f5i0JPYYa3Xkz/r6rOk+7IvwJvq4bepSPIM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6106 Archived-At: Subject: Re: [OAUTH-WG] OBO Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 12:57:03 -0000 --_000_DB8PR03MB609275BEAD0C2DC39F50986887BD0DB8PR03MB6092eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'm actually very curious as well about this and the reasons for the differ= ences between the implementation and the current draft (grant_type value, p= arameters, etc.). Was this discussed somewhere already? Regards,-- Bertrand CARLIER From: OAuth On Behalf Of Lee McGovern Sent: lundi 8 juillet 2019 10:25 To: oauth@ietf.org Subject: [OAUTH-WG] OBO Flow Does it appear strange that Microsoft have called their token exchange flow= implementation (https://docs.microsoft.com/en-us/azure/active-directory/de= velop/v2-oauth2-on-behalf-of-flow) On-Behalf-Of flow? I was under the impre= ssion that delegation was the core use case for oauth development i.e. when= Yelp wants access to your Google contacts a scope is defined and consent i= s granted for that client to act on your behalf... Best, Lee McGovern | IAM Architect | Lee_McGovern@swissre.com This e-mail, including attachments, is intended for the person(s) or compan= y named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful= and is prohibited. If you are not the intended recipient, please delete th= is message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electr= onic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re= , we strongly advise you not to use the Swiss Re e-mail account for any pri= vate, non-business related communications. The information transmitted in the present email including the attachment i= s intended only for the person to whom or entity to which it is addressed a= nd may contain confidential and/or privileged material. Any review, retrans= mission, dissemination or other use of, or taking of any action in reliance= upon this information by persons or entities other than the intended recip= ient is prohibited. If you received this in error, please contact the sende= r and delete all copies of the material. Ce message et toutes les pi?ces qui y sont ?ventuellement jointes sont conf= identiels et transmis ? l'intention exclusive de son destinataire. Toute mo= dification, ?dition, utilisation ou diffusion par toute personne ou entit? = autre que le destinataire est interdite. Si vous avez re?u ce message par e= rreur, nous vous remercions de nous en informer imm?diatement et de le supp= rimer ainsi que les pi?ces qui y sont ?ventuellement jointes. --_000_DB8PR03MB609275BEAD0C2DC39F50986887BD0DB8PR03MB6092eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’m actually very curious as well a= bout this and the reasons for the differences between the implementation an= d the current draft (grant_type value, parameters, etc.).=

 

Was this discussed somewhere already?

 

Regards,--
Bertrand CARL= IER

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Lee McGovern
Sent: lundi 8 juillet 2019 10:25
To: oauth@ietf.org
Subject: [OAUTH-WG] OBO Flow

 

Does it appear strange that Mic= rosoft have called their token exchange flow implementation (https://docs.microsoft.com/en-us/azure/active-directory/deve= lop/v2-oauth2-on-behalf-of-flow) On-Behalf-Of flow? I was under the impression that delegation was the core= use case for oauth development i.e. when Yelp wants access to your Google = contacts a scope is defined and consent is granted for that client to act o= n your behalf…

 

Best,

 

Lee McGovern | IAM Architect | <= a href=3D"mailto:Lee_McGovern@swissre.com">Lee_McGovern@swissre.com


This e-mail, including attachments, is intended for the person(s) or compan= y named and may contain confidential and/or legally privileged information.=
Unauthorized disclosure, copying or use of this information may be unlawful= and is prohibited. If you are not the intended recipient, please delete th= is message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electr= onic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re= , we strongly advise you not to use the Swiss Re e-mail account for any pri= vate, non-business related communications.

The informatio= n transmitted in the present email including the attachment is intended onl= y 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 an= y action in reliance upon this information by persons or entities other tha= n the intended recipient is prohibited. If you received this in error, plea= se contact the sender and delete all copies of the material.

Ce message et toutes les pièces qui y sont éventuellement joi= ntes sont confidentiels et transmis à l'intention exclusive de son d= estinataire. Toute modification, édition, utilisation ou diffusion p= ar toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de no= us en informer immédiatement et de le supprimer ainsi que les pi&egr= ave;ces qui y sont éventuellement jointes. --_000_DB8PR03MB609275BEAD0C2DC39F50986887BD0DB8PR03MB6092eurp_-- From nobody Sat Aug 31 12:27:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6296E1200CC for ; Sat, 31 Aug 2019 12:27:44 -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, 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=logius.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynz6HAzuhM9k for ; Sat, 31 Aug 2019 12:27:41 -0700 (PDT) Received: from mail.ssonet.nl (mail.ssonet.nl [144.43.249.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920531200B3 for ; Sat, 31 Aug 2019 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=logius.nl; i=@logius.nl; q=dns/txt; s=Selector2; t=1567279660; x=1598815660; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y3TCJp+C0K4w6UWw7H7zxrfdRskR1b+4bd2npmE8cNQ=; b=LhanrPnD6+GfkffFtMZ5g9S8zeyrD9IA72QjYoPi2Vbr4Y/wD+lnsmAv tZBwilXv0xOnfAs26UcBbnViMOqIokY7FxCNpLBYkeb92HKvZDPnCNKOX +yCjQfWBl8ChSQNyDe8ryZ4ekSjpfUkMNe04doSIAyP4NCo9gH26zTtbZ J2rfUMLz9r2i/zBtqMVPdneKhhhPtvUHTK9ogELi1WXqsfDDTiDFpctvo maYUWcl0XHcuFxsW2k6ymEERlFqZe1DgM4YfbHXsmou98udybQenCmC+r rLKx8LMpremFAxZ8Q2UHldbjQcFLZRcHocon0LVJ6m42zMwpqobLEfLs0 Q==; IronPort-SDR: w/ITirtMRu57eJ9EwUmuTKfc7gVwGhIqJy1YSwgLGG0VeUWAa8kD0ybQOFB1QFmEByJKs7rRaw y7Vw6xG34gCQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EDAAB0yWpd/8HfK5BdCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYFEJAUqgXIqCoQXiByIf5kaF4FkCQE?= =?us-ascii?q?BAQ4tAgEBhD8CF4JKIzQJDQECAwgBAQEBAwEBAQEBBgMBAQECaYRrT4I6KQG?= =?us-ascii?q?CZwEBAQECASMRMxIFCwIBBgINCwICJgICAjAVEAIEDgUIhRYPAZBNm2+BMhq?= =?us-ascii?q?KMIEMKAGEf4QHKIQiPoQjPoQaFIMhglgEjCggE4JNnARtBwOCH4g7g3SIJCO?= =?us-ascii?q?CM4tAAxCKYKQHgmCBUDlEgRR8Og97HYEmKYJ6bwEBjRxCMYEpjAEogQkBgSI?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A2EDAAB0yWpd/8HfK5BdCRkBAQEBAQEBAQEBAQEHAQEBA?= =?us-ascii?q?QEBgVMEAQEBAQELAYFEJAUqgXIqCoQXiByIf5kaF4FkCQEBAQ4tAgEBhD8CF?= =?us-ascii?q?4JKIzQJDQECAwgBAQEBAwEBAQEBBgMBAQECaYRrT4I6KQGCZwEBAQECASMRM?= =?us-ascii?q?xIFCwIBBgINCwICJgICAjAVEAIEDgUIhRYPAZBNm2+BMhqKMIEMKAGEf4QHK?= =?us-ascii?q?IQiPoQjPoQaFIMhglgEjCggE4JNnARtBwOCH4g7g3SIJCOCM4tAAxCKYKQHg?= =?us-ascii?q?mCBUDlEgRR8Og97HYEmKYJ6bwEBjRxCMYEpjAEogQkBgSIBAQ?= X-IronPort-AV: E=McAfee;i="6000,8403,9366"; a="37505052" X-IronPort-AV: E=Sophos;i="5.64,451,1559512800"; d="scan'208";a="37505052" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False From: "Schaar, R.M. (Remco) - Logius" To: 'Torsten Lodderstedt' CC: "'oauth@ietf.org'" Thread-Topic: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Thread-Index: AQHVVPNIj99CrYifUEuqB+4o77upAKcQWBzEgAVhIfA= Date: Sat, 31 Aug 2019 19:27:35 +0000 Message-ID: <040dcf9971fd4c618e94b957461d14f2@SV1601507.frd.shsdir.nl> References: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl> <308A4847-6390-4D17-BE52-B604E2428391@lodderstedt.net> <10f13f75c100454aa8092961673541b2@SV1601499.frd.shsdir.nl> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [144.43.223.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 19:27:44 -0000 SGVsbG8gVG9yc3RlbiwNCg0KKG15IGFwb2xvZ2llcyBmb3IgbWFraW5nIGEgdHlwbyBwcmV2aW91 c2x5KQ0KDQpUaW1lIG9mIGludHJvc3BlY3Rpb24gaXMgY3JpdGljYWwgaWYgeW91IHdhbnQgdG8g dXNlIHRoZSBzaWduZWQgaW50cm9zcGVjdGlvbg0KcmVzcG9uc2UgZm9yIGxhdGVyIGFjY291bnRh YmlsaXR5IG9yIGF1ZGl0IHB1cnBvc2VzLiBGb3IgZXhhbXBsZSwgYSBDbGllbnQNCm9idGFpbnMg YW4gYWNjZXNzIHRva2VuIEEgYXQgdGltZSB0LiBOb3cgYSByZXNvdXJjZSBzZXJ2ZXIgcmVjZWl2 ZXMgQSBhdCB0aW1lDQp0KzEsIGNhbGxzIGludHJvc3BlY3Rpb24gYW5kIHJlY2VpdmVzIGEgcmVz cG9uc2UgY29udGFpbmluZyBhY3RpdmU9dHJ1ZS4gQXQNCnQrMiB0aGUgYWNjY2VzcyB0b2tlbiBp cyByZXZva2VkLiBBdCB0aW1lIHQrMyB0aGUgcmVzb3VyY2Ugc2VydmVyIG1ha2VzIGEgbmV3DQpp bnRyb3NwZWN0aW9uIHJlcXVlc3QsIG5vdyByZWNlaXZlcyBhIHJlc3BvbnNlIGNvbnRhaW5pbmcg YWN0aXZlPWZhbHNlLiBUaGUNCm9ubHkgZGlmZmVyZW5jZSB3b3VsZCBiZSB0aGUgdmFsdWUgb2Yg dGhlIGFjdGl2ZSBwYXJhbWV0ZXIuIFdpdGhvdXQgdGhlIHRpbWUNCm9mIGludHJvc3BlY3Rpb24g bm9yIGEgdW5pcXVlIGlkIGNvdmVyZWQgYnkgdGhlIHNpZ25hdHVyZSwgb25lIGNhbm5vdCBtYWtl IGENCmNvbmNsdXNpdmUgZGlzdGluY3Rpb24gYmV0d2VlbiBzdWJzZXF1ZW50IHJlc3BvbnNlcyBp ZiByZXZvY2F0aW9uIG1heSBiZSBpbg0KcGxheS4NCg0KVGhlIGRyYWZ0IHNwZWNpZmllcyANCiAg ICAgICBbLi4uXSB0byByZXR1cm4gcmVzcG9uc2VzIGFzIEpXVHMuDQpUaGlzIGNvdWxkIGVpdGhl ciBtZWFuICJ0aGUgcmVzcG9uc2UgaXMgcmV0dXJuZWQgaW4gSldUIGZvcm1hdCIgb3IgInRoZQ0K cmVzcG9uc2UgY29udGFpbnMgYSBKV1QgcmVwcmVzZW50YXRpb24gb2YgdGhlIGluc3BlY3RlZCB0 b2tlbiIuIE5vdCBoYXZpbmcNCmNsZWFyLCBzZXBhcmF0ZSBwYXJhbWV0ZXJzIHRvIGRpc3Rpbmd1 aXNoIGJldHdlZW4gdGhlIHRpbWUgYW5kIGlkIG9mIHRoZQ0KdG9rZW4gYW5kIHRoZSB0aW1lIGFu ZCBpZCBvZiB0aGUgcmVzcG9uc2UgcmVzdWx0cyBpbiBkb3VibGUgbWVhbmluZy4gQXMgYQ0KY29u c2VxdWVuY2UsIGl0IGlzIGVpdGhlciBoYXZpbmcgdGhlIHJpc2sgb2YgcmVwbGF5IG9mIGFuIGFj Y2VzcyB0b2tlbiBvcg0KcmVwbGF5IG9mIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaW5zdGVh ZCBvZiBuZWl0aGVyLg0KDQpLaW5kIHJlZ2FyZHMsDQpSZW1jbyBzY2hhYXINCg0KLS0tLS1Pb3Jz cHJvbmtlbGlqayBiZXJpY2h0LS0tLS0NClZhbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQ+IA0KVmVyem9uZGVuOiB3b2Vuc2RhZyAyOCBhdWd1c3R1cyAyMDE5 IDExOjE0DQpBYW46IFNjaGFhciwgUi5NLiAoUmVtY28pIC0gTG9naXVzIDxyZW1jby5zY2hhYXJA bG9naXVzLm5sPg0KQ0M6IG9hdXRoQGlldGYub3JnDQpPbmRlcndlcnA6IFJlOiBbT0FVVEgtV0dd IFF1ZXN0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJl c3BvbnNlLTA1DQoNCkhpIFJoZW1jbywNCg0KPiBPbiAyNi4gQXVnIDIwMTksIGF0IDA5OjQyLCBT Y2hhYXIsIFIuTS4gKFJlbWNvKSAtIExvZ2l1cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4gd3Jv dGU6DQo+IA0KPiBIZWxsbyBUaG9yc3RlbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXNw b25zZS4gSSBoYXZlIGEgZmV3IG1vcmUgcXVlc3Rpb25zL2NvbW1lbnRzIGFzDQo+IGZvbGxvdy11 cC4uLg0KPiANCj4gWW91IHN0YXRlIHRoYXQgUkZDNzUxOSBhbmQgUkZDNzY2MiAianVzdCIgZGVm aW5lIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMNCj4gZm9yIHRva2VuIGRhdGEuIElmIHRoZSBk cmFmdCBSRkMgd291bGQgcmVmZXIgdG8gUkZDIDc1MTUgKEpXUyksIEkgd291bGQNCj4gYWdyZWUu IEhvd2V2ZXIsIFJGQzc1MTkgKEpXVCkgZXhwbGljaXRseSBhZGRzIHNlbWFudGljcyB0byBzb21l IHNwZWNpZmljDQo+IHBhcmFtZXRlcnMgKGUuZy4gYXVkLCBqdGkgYW5kIGlhdCkuIFJGQzc2NjIg aGFzIGRpZmZlcmVudCBzZW1hbnRpY3MgZm9yDQo+IHRoZSBzZXZlcmFsIG9mIHRoZSBzYW1lIHBh cmFtZXRlcnMuDQo+IEZvciBpbnN0YW5jZSB0aGUgJ2lhdCcsIGlzIHRoZSBtb21lbnQgb2YgaXNz dWFuY2Ugb2YgdGhlIEpXVCBpbiBSRkM3NTE5LiBJbg0KPiBSRkM3NjYyIHRoYXQgaXMgdGhlICJ3 aGVuIHRoaXMgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVkIi4gVGhpcyB0aW1lIHdpbGwNCj4g dmFyeSBpbiB1c2UgY2FzZXMgd2l0aG91dCBpbW1lZGlhdGUgaW50cm9zcGVjdGlvbiBvZiBhbiBh Y2Nlc3MgdG9rZW4uDQoNCkkgcmVhZCB0aGUgdGV4dCBkaWZmZXJlbnRseS4gSW4gbXkgaW50ZXJw cmV0YXRpb24g4oCcd2hlbiB0aGUgdG9rZW4gd2FzIG9yaWdpbmFsbHkgaXNzdWVk4oCdIHN0YXRl ZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCByZWZl cnMgZXhhY3RseSB0byB0aGUgc2FtZSBpbnN0YW50IGFzIOKAnHRoZSB0aW1lIGF0IHdoaWNoIHRo ZSBKV1Qgd2FzDQogICBpc3N1ZWTigJ0uDQoNCj4gDQo+IEZvciB0aGUgdXNlIGNhc2Ugb2YgdGhl IHJlc291cmNlIHNlcnZlciByZWx5aW5nIG9uIHZlcmlmaWFibGUgZGF0YSwgYXMNCj4gZGVzY3Jp YmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRyYWZ0IFJGQywgdGhlIHRpbWUgb2YgdGhl IGludHJvc3BlY3Rpb24NCj4gaXMgY3JpdGljYWwuDQoNCldoeSBpcyB0aGlzIHRpbWUgY3JpdGlj YWw/DQoNCj4gSW4gcGFydGljdWxhciB3aGVuIGNvbWJpbmVkIHdpdGggcmV2b2NhdGlvbiwgdGhl IHRpbWUgb2YNCj4gaW50cm9zcGVjdGlvbiBhbmQgdGhlICdhY3RpdmUnIHN0YXR1cyBjYW4gZGlm ZmVyIGJldHdlZW4gdHdvIHN1YnNlcXVlbnQgY2FsbHMNCj4gZm9yIGludHJvc3BlY3Rpb24uDQoN ClRoZSBzdGF0dXMgYXQgdG9rZW4gaW50cm9zcGVjdGlvbiByZXF1ZXN0IHRpbWUgaXMgaW5kZWVk IGNyaXRpY2FsLiBSRkMgNzY2MiBnaXZlcyBhIGdvb2QgaW5kaWNhdGlvbiBob3cgdGhpcyB2YWx1 ZSBzaG91bGQgYmUgY2FsY3VsYXRlZC4NCg0K4oCc4oCmIGEgInRydWUiDQogICAgICB2YWx1ZSBy ZXR1cm4gZm9yIHRoZSAiYWN0aXZlIiBwcm9wZXJ0eSB3aWxsIGdlbmVyYWxseSBpbmRpY2F0ZQ0K ICAgICAgdGhhdCBhIGdpdmVuIHRva2VuIGhhcyBiZWVuIGlzc3VlZCBieSB0aGlzIGF1dGhvcml6 YXRpb24gc2VydmVyLA0KICAgICAgaGFzIG5vdCBiZWVuIHJldm9rZWQgYnkgdGhlIHJlc291cmNl IG93bmVyLCBhbmQgaXMgd2l0aGluIGl0cw0KICAgICAgZ2l2ZW4gdGltZSB3aW5kb3cgb2YgdmFs aWRpdHkgKGUuZy4sIGFmdGVyIGl0cyBpc3N1YW5jZSB0aW1lIGFuZA0KICAgICAgYmVmb3JlIGl0 cyBleHBpcmF0aW9uIHRpbWUpLiIgDQoNClNvIGl0IHJlcHJlc2VudHMgdGhlIHJlc3VsdHMgb2Yg dGhlIGlzc3VlciBjaGVjaywgdGhlIHJldm9jYXRpb24gY2hlY2sgYW5kIHRoZSB2YWxpZGl0eSBj aGVjayBpbiBvbmUgYm9vbGVhbiB2YWx1ZS4gDQoNCj4gDQo+IElmIHRoZSBkcmFmdCBSRkMganVz dCBwcm9kdWNlcyBhIEpXVCByZXByZXNlbnRhdGlvbiBvZiB0aGUgYWNjZXNzIHRva2VuLA0KPiBp bmNsdWRpbmcgJ2FjdGl2ZScgd291bGQgbm90IG1ha2Ugc2Vuc2UgYXMgdGhlIEpXVCB3aWxsIGV4 cGlyZSB3aXRob3V0DQo+IHVwZGF0aW5nIGl0IHRvIGZhbHNlLiBMZWF2aW5nICdhY3RpdmUnIG91 dCB3b3VsZCBtYWtlIGl0IGluY29tcGF0aWJsZSB3aXRoDQo+IFJGQzc2NjIgaW50cm9zcGVjdGlv biByZXNwb25zZXMuDQoNCuKAnGFjdGl2ZeKAnSBpcyBub3QgcGFydCBvZiB0aGUgSldUIHJlcHJl c2VudGF0aW9uIEkgcmVmZXJyZWQgdG8uIFRoZSBBUyBuZWVkcyB0byBkZXRlcm1pbmUgdGhlIGFj dGl2ZSB2YWx1ZSBmb3IgZXZlcnkgdG9rZW4gaW50cm9zcGVjdGlvbiByZXF1ZXN0LiANCg0KSWYg dGhlIFJTIHdvdWxkIGNvbnN1bWUgSldUcywgaXQgd291bGQgZGV0ZXJtaW5lIHRoZSDigJxhY3Rp dmXigJ0gdmFsdWUgaXRzZWxmIGJ5IGluc3BlY3RpbmcgdGhlIGlzcyBjbGFpbSBhbmQgY2hlY2sg YWdhaW5zdCBpdHMgQVMgd2hpdGVsaXN0LCBjaGVjayB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgaWF0 ICYgZXhwIHZhbHVlcy4gRGV0ZXJtaW5pbmcgdGhlIHJldm9jYXRpb24gc3RhdHVzIHdvdWxkIHJl cXVpcmUgYW4gaW5mb3JtYXRpb24gZXhjaGFuZ2Ugd2l0aCB0aGUgQVMgb2Ygc29tZSBzb3J0LiAN Cg0KPiBTaW1pbGFyLCBub3QgaW5jbHVkaW5nIGEgdW5pcXVlICdqdGknIHBlciBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIHdvdWxkIG1ha2UNCj4gdGhlIHJlc291cmNlIHNlcnZlciB2dWxuZXJhYmxl IHRvIHJlcGxheSBhdHRhY2tzLg0KDQpUbyB0aGUgY29udHJhcnksIGluY2x1ZGluZyBhIGRpZmZl cmVudCDigJxqaXQiIHdpdGggZXZlcnkgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSB3b3Vs ZCBtYWtlIHRoZSBSUyB2dWxuZXJhYmxlIHRvIHJlcGxheSBvZiBvbmUgdGltZSBhY2Nlc3MgdG9r ZW4gc2luY2UgaXQgcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBmb3IgdGhlIFJTIHRvIGlkZW50aXR5 IGEgY2VydGFpbiBhY2Nlc3MgdG9rZW4uIA0KDQo+IE9yIHRoZSByZXNvdXJjZSBzZXJ2ZXINCj4g d291bGQgbWlzdGFrZW5seSByZWZlciB0byBub24tdW5pcXVlIHRva2VucywgbWFraW5nIHRoZSBy ZXNwb25zZXMgdW5zdWl0YWJsZQ0KPiBmb3IgYWNjb3VudGFiaWxpdHkgYW5kIGF1ZGl0IHB1cnBv c2VzLg0KPiANCj4gDQo+IEFzIHRvIHdoeSBzb21lb25lIHdvdWxkIHdhbnQgdG8gZGlzdGluZ3Vp c2ggYSBKV1QgYWNjZXNzIHRva2VuIGZyb20gYW4NCj4gaW50cm9zcGVjdGlvbiByZXNwb25zZTog c2V2ZXJhbCB1c2UgY2FzZXMgY29tZSB0byBtaW5kLg0KPiANCj4gRmlyc3Qgb2YgYWxsLCBldmVu IGlmIG9uZSBpcyB1c2luZyBzdGFuZGFsb25lIGludGVycHJldGFibGUgSldUIGFjY2VzcyB0b2tl bnMsDQo+IG9uZSBtYXkgd2FudCB0byBjb21iaW5lIHRoYXQgd2l0aCByZXZvY2F0aW9uIGNoZWNr aW5nIHVzaW5nIGludHJvc3BlY3Rpb24uIFRoZQ0KPiBpbnRlcnByZXRhdGlvbiBhbmQgbWVhbmlu ZyBvZiB0aGUgSldUIGFuZCB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZSB0aGFuIGRvDQo+IGRp ZmZlciBhbmQgbWF0dGVyLg0KDQpBcyBJIGRlc2NyaWJlZCBhYm92ZSwgSSBkb27igJl0IHNlZSBh bnkgZGlmZmVyZW5jZS4gDQoNCj4gDQo+IEFub3RoZXIgdXNlIGNhc2Ugd291bGQgYmUgYSBtaXhl ZCBlY29zeXN0ZW0gd2l0aCByZXNvdXJjZSBzZXJ2ZXJzIHJlbHlpbmcgb24NCj4gaW50cm9zcGVj dGlvbiB3aGlsZSBvdGhlcnMgZG8gcGFyc2UgSldUIGFjY2VzcyB0b2tlbnMuIEEgc2luZ2xlLCB1 bmlmb3JtDQo+IGltcGxlbWVudGF0aW9uIGZvciB0aGUgQVMgd291bGQgdGhhbiBtaXggYm90aCBh cyB3ZWxsLg0KDQpTZWUgYWJvdmUgLSBJIGRvbuKAmXQgc2VlIGFueSBpc3N1ZS4gDQoNCj4gDQo+ IEEgbGFzdCB1c2UgY2FzZSBjb3VsZCBiZSBleGNoYW5naW5nIGFjY2VzcyB0b2tlbnMgd2l0aCBh IHN1YnNldCBvZiB0aGUgZnVsbA0KPiBzZXQgb2YgYXBwbGljYWJsZSBwYXJhbWV0ZXJzLCB0byBy ZWR1Y2UgdGhlIHNpemUgb2YgYWNjZXNzIHRva2Vucy4gQWRkaXRpb25hbA0KPiBpbmZvcm1hdGlv biBjYW4gYmUgZXhjaGFuZ2VkIHZpYSBpbnRyb3NwZWN0aW9uLCByZXN1bHRpbmcgaW4gbWl4ZWQg SldUIGFjY2Vzcw0KPiB0b2tlbnMgYW5kIGludHJvc3BlY3Rpb24gYXMgd2VsbC4NCg0KVGhhdOKA mXMgYWxsIHBvc3NpYmxlIHdpdGhpbiB0aGUgY3VycmVudCB0ZXh0LiANCg0Ka2luZCByZWdhcmRz LA0KVG9yc3RlbiANCg0KPiANCj4gS2luZCByZWdhcmRzLA0KPiBSZW1jbyBTY2hhYXINCj4gDQo+ IC0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQo+IFZhbjogVG9yc3RlbiBMb2RkZXJz dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IA0KPiBWZXJ6b25kZW46IHphdGVyZGFnIDE3 IGF1Z3VzdHVzIDIwMTkgMTQ6MDANCj4gQWFuOiBTY2hhYXIsIFIuTS4gKFJlbWNvKSAtIExvZ2l1 cyA8cmVtY28uc2NoYWFyQGxvZ2l1cy5ubD4NCj4gQ0M6IG9hdXRoQGlldGYub3JnDQo+IE9uZGVy d2VycDogUmU6IFtPQVVUSC1XR10gUXVlc3Rpb24gcmVnYXJkaW5nIGRyYWZ0LWlldGYtb2F1dGgt and0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDUNCj4gDQo+IEhpIFJlbWNvLA0KPiANCj4+IE9u IDYuIEF1ZyAyMDE5LCBhdCAxNjowMSwgU2NoYWFyLCBSLk0uIChSZW1jbykgLSBMb2dpdXMgPHJl bWNvLnNjaGFhckBsb2dpdXMubmw+IHdyb3RlOg0KPj4gDQo+PiBIZWxsbywNCj4gDQo+IFsuLi5d DQo+IFJGQyA3NTE5IGFuZCBSRkMgNzY2MiDigJxqdXN04oCdIGRlZmluZSBkaWZmZXJlbnQgcmVw cmVzZW50YXRpb25zIGZvciB0b2tlbiBkYXRhLiBJbiBSRkMgNzUxOSB0aGUgZGF0YSBpcyBjYXJy aWVkIGluIHRoZSB0b2tlbiBpdHNlbGYgKHdoaWNoIGFsc28gbWVhbnMgdGhlIGZvcm1hdCBvZiB0 aGUgdG9rZW4gaXMgd2VsbC1kZWZpbmVkIGFuZCBrbm93IHRvIHRoZSBSUykgd2hlcmVhcyBSRkMg NzY2MiBkZWZpbmVzIGEgd2F5IHRvIGluc3BlY3QgdG9rZW5zIHZpYSBhbiBBUEkgcHJvdmlkZWQg YnkgdGhlIEFTLiBUaGUgbGF0dGVyIGlzIHR5cGljYWxseSB1c2VkIGluIGNvbmp1bmN0aW9uIHdp dGggb3BhcXVlIHRva2VucywgaS5lLiB0aGUgUlMgZG9lcyBub3QgaGF2ZSBhIGNsdWUgaG93IHRv IHBhcnNlIGFuZCBpbnRlcnByZXQgdGhlIHRva2VuLiBUaGUgdG9rZW4gbWlnaHQganVzdCBiZSBh IGhhbmRsZSB0byBhIGRhdGFiYXNlIGVudHJ5IGF0IHRoZSBBUyBpbiB0aGlzIGNhc2UuIA0KPiAN Cj4gVGhpcyBhbHNvIG1lYW5zIGEgSldUIChSRkMgNzY2MikgYW5kIHRoZSBJbnRyb3NwZWN0aW9u IFJlc3BvbnNlIGFyZSBjb25jZXB0dWFsbHkgdGhlIHNhbWUgZnJvbSBhIFJTcyBwZXJzcGVjdGl2 ZS4NCj4gDQo+IFsuLi5dDQo+IA0KPj4gVGhlIOKAmGp0aeKAmSBwYXJhbWV0ZXIgaG93ZXZlciB3 aWxsIGFsd2F5cyBiZSBhbWJpZ3VvdXMuIEFzIGl0IGlzIGFuIGlkZW50aWZpZXIsIGl0IHNob3Vs ZCBkaWZmZXIgZm9yIHRoZSBpbnRyb3NwZWN0ZWQgdG9rZW4gYW5kIHRoZSBpbnRyb3NwZWN0aW9u IHJlc3BvbnNlIGJ5IGRlZmluaXRpb24uIEhlbmNlIHRoZSBzZW1hbnRpY3Mgb2Yg4oCYanRp4oCZ IGluIGEgSldUIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaXMgdW5jbGVhci4gVGhlIHNhbWUgY2Fu IGFwcGx5IHRvIHRoZSDigJhpYXTigJksIOKAmG5iZuKAmSBhbmQg4oCYZXhw4oCZIGNsYWltcyBp biBhIEpXVCBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLg0KPiANCj4gSSBkb27igJl0IHVuZGVyc3Rh bmQgdGhlIGRpZmZlcmVuY2UgeW91IGFyZSBtYWtpbmcuIEFsbCBiZWZvcmUgbWVudGlvbmVkIGNs YWltcyBhcmUgcmVsYXRlZCB0byB0aGUgKGFic3RyYWN0KSBhY2Nlc3MgdG9rZW4uIFlvdSBtYXkg dGhpbmsgb2YgdGhlIEludHJvc3BlY3Rpb24gUmVzcG9uc2UgYXMgX3RoZV8gSldUIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBhY2Nlc3MgdG9rZW4gcHJvZHVjZWQgYnkgdGhlIEFTIGZvciB0aGUgUlMu DQo+IA0KPj4gDQo+PiBDYW4gc29tZW9uZSBjbGFyaWZ5IHRoZSBzZW1hbnRpY3Mgb2YgY2xhaW1z IGluIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgSldUIHRoYXQgYXJlIGRlZmluZWQgaW4gYm90 aCBSRkM3NjYyIGFuZCBSRkM3NTE5Pw0KPj4gDQo+PiBGdXJ0aGVybW9yZSwgdGhlIGludHJvc3Bl Y3Rpb24gcmVzcG9uc2Ugc2hvdWxkIHVzZSB0aGUg4oCYaXNz4oCZIGFuZCDigJhhdWTigJkgY2xh aW1zIHRvIGF2b2lkIGNyb3NzLUpXVCBjb25mdXNpb24gKHNlY3Rpb24gNi4xKS4gVGhlIOKAmGlz c+KAmSBhbmQg4oCYYXVk4oCZIG9mIGFuIGludHJvc3BlY3RlZCB0b2tlbiB3aWxsIHR5cGljYWxs eSBiZSB0aGUgc2FtZSBhcyB0aG9zZSBvZiB0aGUgaW50cm9zcGVjdGlvbiByZXNwb25zZS4gSGVu Y2UgYSBKV1QgYWNjZXNzIHRva2VuIGNhbm5vdCBiZSBkaXN0aW5ndWlzaGVkIGZyb20gYW4gaW50 cm9zcGVjdGlvbiByZXNwb25zZSB1c2luZyDigJhpc3PigJkgYW5kIOKAmGF1ZOKAmSBhcyBzdWdn ZXN0ZWQgaW4gdGhlIGRyYWZ0Li4NCj4+IA0KPj4gSW50cm9zcGVjdGlvbiByZWZlcnMgdG8gSldU IGJlc3QtY3VycmVudC1wcmFjdGljZS4gVGhlIGRyYWZ0IEJDUCByZWNvbW1lbmRzIHVzaW5nIGV4 cGxpY2l0IHR5cGluZyBvZiBKV1RzLCBob3dldmVyIHRoZSBkcmFmdCBKV1QgcmVzcG9uc2UgZm9y IGludHJvc3BlY3Rpb24gZG9lcyBub3QgYXBwbHkgdGhpcyByZWNvbW1lbmRhdGlvbiBhbmQgdXNl cyB0aGUgZ2VuZXJpYyDigJhhcHBsaWNhdGlvbi9qd3TigJkgaW5zdGVhZC4uLiBUaGUgQkNQIGhh cyBvdGhlciByZWNvbW1lbmRhdGlvbnMgaW4gc2VjdGlvbiAzLjEyLCBidXQgdGhlc2UgbWF5IGJl IGluc3VmZmljaWVudCB0byBkaXN0aW5ndWlzaCBhIEpXVCBhY2Nlc3MgdG9rZW4gZnJvbSBhIEpX VCBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLg0KPiANCj4gR29vZCBwb2ludC4gVGhlIHJlYXNvbiB3 aHkgdGhlIEJDUCByZWNvbW1lbmRzIGV4cGxpY2l0IHR5cGluZyBpcyB0byBwcmV2ZW50IHJlcGxh eSBpbiBvdGhlciBjb250ZXh0cy4gSW4gdGhlIGVuZCB0eXBpbmcgaXMgYSBjb21wZWxsaW5nIGNv bmNlcHQgdW5mb3J0dW5hdGVseSBub3QgYnJvYWRseSB1c2VkIGluIHRoZSB3aWxkLg0KPiANCj4g U28gdGhlIEpXVCBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIGRyYWZ0IGNvcGVzIHdpdGggdGhhdCBh dHRhY2sgYW5nbGUgYnkgbWFraW5nIGlzcyBhbmQgYXVkIG1hbmRhdG9yeS4gDQo+IA0KPiANCj4+ IA0KPj4gSG93IHdvdWxkIHBlb3BsZSBzdWdnZXN0IHRvIGJlc3QgZGlzdGluZ3Vpc2ggYSBKV1Qg KGFjY2VzcykgdG9rZW4gZnJvbSBhIEpXVCBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlPw0KPiANCj4g V2h5IHNob3VsZCB5b3U/IE9uZSByZWFzb24gd2h5IHdlIGV4dGVuZGVkIHRoZSBJbnRyb3NwZWN0 aW9uIFJlc3BvbnNlIHdhcyB0byBlbGltaW5hdGUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBKV1Rz IGRpcmVjdGx5IHVzZWQgYXMgYWNjZXNzIHRva2VucyBhbmQgSW50cm9zcGVjdGlvbiBSZXNwb25z ZXMuDQo+IA0KPiBiZXN0IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uIA0KPiANCj4gDQo+IERpdCBiZXJp Y2h0IGthbiBpbmZvcm1hdGllIGJldmF0dGVuIGRpZSBuaWV0IHZvb3IgdSBpcyBiZXN0ZW1kLiBJ bmRpZW4gdSBuaWV0IGRlIGdlYWRyZXNzZWVyZGUgYmVudCBvZiBkaXQgYmVyaWNodCBhYnVzaWV2 ZWxpamsgYWFuIHUgaXMgdG9lZ2V6b25kZW4sIHdvcmR0IHUgdmVyem9jaHQgZGF0IGFhbiBkZSBh ZnplbmRlciB0ZSBtZWxkZW4gZW4gaGV0IGJlcmljaHQgdGUgdmVyd2lqZGVyZW4uIERlIFN0YWF0 IGFhbnZhYXJkdCBnZWVuIGFhbnNwcmFrZWxpamtoZWlkIHZvb3Igc2NoYWRlLCB2YW4gd2Vsa2Ug YWFyZCBvb2ssIGRpZSB2ZXJiYW5kIGhvdWR0IG1ldCByaXNpY28ncyB2ZXJib25kZW4gYWFuIGhl dCBlbGVrdHJvbmlzY2ggdmVyemVuZGVuIHZhbiBiZXJpY2h0ZW4uDQo+IFRoaXMgbWVzc2FnZSBt YXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJZiB5 b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0byB5 b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGUgbWVzc2FnZS4gVGhlIFN0YXRlIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBk YW1hZ2Ugb2YgYW55IGtpbmQgcmVzdWx0aW5nIGZyb20gdGhlIHJpc2tzIGluaGVyZW50IGluIHRo ZSBlbGVjdHJvbmljIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdlcy4NCg0K