From nobody Wed May 1 23:33: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 90BFA120052 for ; Wed, 1 May 2019 23:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Tm7x71NlQN3g for ; Wed, 1 May 2019 23:32:59 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by ietfa.amsl.com (Postfix) with SMTP id BCAD4120006 for ; Wed, 1 May 2019 23:32:58 -0700 (PDT) Received: (qmail 46924 invoked by uid 99); 2 May 2019 06:32:57 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 May 2019 06:32:57 +0000 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 39BC01A06 for ; Thu, 2 May 2019 06:32:52 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id d15so1110288ljc.7 for ; Wed, 01 May 2019 23:32:52 -0700 (PDT) X-Gm-Message-State: APjAAAX2AD26iDmD597IkCAgZcmQa3GU/5VXG3WmGgniJj4gWOeDhH1q cZbvETEJPti2M1WOtvBf5E3oVFswyGHYgBQZ0AWVGA== X-Google-Smtp-Source: APXvYqxVFl14PcuksS+ImTKePycy11Ae+qXQvHvge4Rqe5NtnREdsaSiEkJvyuxTDfwopmsB05jZMRxtKcg9xQexiSs= X-Received: by 2002:a2e:456:: with SMTP id 83mr819176lje.77.1556778771581; Wed, 01 May 2019 23:32:51 -0700 (PDT) MIME-Version: 1.0 From: Paul Querna Date: Wed, 1 May 2019 23:32:40 -0700 X-Gmail-Original-Message-ID: Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback 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, 02 May 2019 06:33:01 -0000 Hi all, I recently built a prototype of DPoP using Go, and wanted to provide some feedback as I went about the implementation. The implementation is open source: https://github.com/pquerna/dpop Overall the spec felt functional, though I think the biggest gaps for a deployment are with the Access Token interactions, but this makes sense since that seems to be addressed in the future by Jumping into specific items: cnf in DPoP-Proof > o "cnf": Confirmation claim as per [RFC7800] containing a member > "dpop+jwk", representing the public key chosen by the client in > JWK format (REQUIRED for DPoP Binding JWTs, OPTIONAL for DPoP > Proof JWTs). Is there a use case for this being present in the DPoP-Proof JWT? As I've implemented DPoP, I didn't see how it was helpful to be sent as a `cnf` claim of the Proof? Request Headers vs Parameters > 5. Token Request (Binding Tokens to a Public Key) Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is different than most other OAuth extensions that I am familiar with. It is easy in the Go OAuth2 library to add URL / /body params to the `/token` endpoint, but it is impossible to add an HTTP Header. Is there a reason that the binding can't be sent as an OAuth Parameter in the token request body? HTTP Request Signing > o "http_method": The HTTP method for the request to which the JWT is > attached, in upper case ASCII characters, as defined in [RFC7231] > (REQUIRED). > > o "http_uri": The HTTP URI used for the request, without query and > fragment parts (REQUIRED). HTTP Request signing may be a quagmire that this spec wishes to avoid, but it seems very hard to avoid "fixing" it for at-scale adoption. With the Okta-hat on, I think this is one area we would like to see some iteration on. I think it would be ideal to not require multiple client sign() and server validate() PKI operations per request, so this is where combining DPoP-Proof and a Request Signature start making sense to me. Keeping it simple, there are two approaches for DPoP for adding attesting about the HTTP Request: a) Adding parts of the HTTP Request as claims b) Adding a hash of an HTTP Request as a claim For option (b), it seems like part of this could live in a separate spec: 1) request canonicalization 2) request hashing does cover request canonicalization, but the hashing is part of the specific signature scheme. From an implementors POV, layering draft-cavage-http-signatures-11 in addition to DPoP is annoying since it would take two sign or verify key operations per request. I'm not sure where the spec-author team wants to take this area, but am interested in providing feedback. JWT as AT > 7. IANA Considerations > > [[TODO: MIME type registration for at+jwt ]] Assume this will eventually be done via Thank you for the work so far, and I'm happy to provide further feedback as the spec evolves. Paul From nobody Thu May 2 11:41: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 4435D120125 for ; Thu, 2 May 2019 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEd1VAzC4HCH for ; Thu, 2 May 2019 11:41:24 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7213C1200F8 for ; Thu, 2 May 2019 11:41:24 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x42IOTKa111783 for ; Thu, 2 May 2019 18:41:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2018-07-02; bh=CvVKSG0i0/A6u9ZKXljpiYWfPa2XloJfHJ90FHtqMjc=; b=2cao/rZDtzm31lWYHB8kTU+D5kjMescmDGlbYR+/PPCj78sZJxqAMovRlo8uF/FtpVJI SxsBuZ6OAsCemu/MEloHsNl0Yb31vq35L0ZoplxLEQMt9kDbpILZ+mRvA6g+5MWtEcua Pwo90la46b4HZnoZbV9zqxh+aneFiQInbXeVCOSyi5woQj0M+dOFObwx9u6gWSSzxvZb fxYv0qNnqaCwKBQziJWk1k65IpKeAFqJgUawDLI0XkbKoL9Gp0DY/slpQvmL4iWUJmHw Bade71ejHR2gvClJkrf8aBRd0UiS8zqjoB+MGP6F/oU82NHYVvGuqWC5pq+bgS1Uv7va ww== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2s6xhytnvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 02 May 2019 18:41:23 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x42Iel8t095932 for ; Thu, 2 May 2019 18:41:22 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2s7rtbvxrg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 02 May 2019 18:41:22 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x42IfLaH024019 for ; Thu, 2 May 2019 18:41:21 GMT Received: from [10.0.1.16] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 May 2019 11:41:21 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_5797F36E-482E-4BD7-89C1-6255850CF6A0" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> Date: Thu, 2 May 2019 11:41:19 -0700 To: oauth X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 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-1810050000 definitions=main-1905020118 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905020118 Archived-At: Subject: [OAUTH-WG] MTLS and Native apps Best practices 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, 02 May 2019 18:41:27 -0000 --Apple-Mail=_5797F36E-482E-4BD7-89C1-6255850CF6A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was wondering if anyone had any recommended MTLS best practices for = mobile apps and native browsers. Considering Section 6 of RFC8252=E2=80=A6 After constructing the authorization request URI, the app uses platform-specific APIs to open the URI in an external user-agent. Typically, the external user-agent used is the default browser, that is, the application configured for handling "http" and "https" scheme URIs on the system; however, different browser selection criteria and other categories of external user-agents MAY be used. What choices do developers have to ensure the authorization (and = subsequent user authentication) occur over MTLS? Can the app provide its = own key for MTLS or can it ask that an embedded X.509 cert be used = (assuming one is available)? Are there any platform issues or best practices? Phil Hunt | Cloud Security and Identity Architect Oracle Corporation, Oracle Cloud Infrastructure @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_5797F36E-482E-4BD7-89C1-6255850CF6A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = was wondering if anyone had any recommended MTLS best practices for = mobile apps and native browsers.

Considering Section 6 of RFC8252=E2=80=A6
   After constructing the authorization request URI, the app uses
   platform-specific APIs to open the URI in an external user-agent.
   Typically, the external user-agent used is the default browser, that
   is, the application configured for handling "http" and "https" scheme
   URIs on the system; however, different browser selection criteria and
   other categories of external user-agents MAY be used.

What choices do = developers have to ensure the authorization (and subsequent user = authentication) occur over MTLS? Can the app provide its own key for = MTLS or can it ask that an embedded X.509 cert be used (assuming one is = available)?

Are = there any platform issues or best practices?

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid






= --Apple-Mail=_5797F36E-482E-4BD7-89C1-6255850CF6A0-- From nobody Thu May 2 12:26: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 3C1AA120112 for ; Thu, 2 May 2019 12:26:30 -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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwAhYETGx5BP for ; Thu, 2 May 2019 12:26:28 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 49FD9120075 for ; Thu, 2 May 2019 12:26:28 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x42JQRJu022492 for ; Thu, 2 May 2019 15:26:27 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x42JQRJu022492 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556825187; bh=zpXL18LRPxUCi2mTnOdcZ+TlFFJ9g1u3DjizARrQNu0=; h=From:To:Subject:Date:From; b=ooHOCPmW7wZYCuJ+UyHP+JWJsPx7KXA0Stm9Rgp5mteC0ZeHFGMbUeFxFecKa40nR 1LI+ny4h99bXt9fwoMjczi2v9x+y0/BhqICN0zsyLNv+3VtlsxlwMA9kig9YVEYs3M wKhjmuEB5YzSrAr/nfZrA660j6IVdVO2bDAibNW8= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x42JQOYp024234 for ; Thu, 2 May 2019 15:26:24 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Thu, 2 May 2019 15:26:23 -0400 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: AD follow-up on draft-ietf-oauth-jwsreq-17 Thread-Index: AdUBGsF5M8JVe3eoSDOFph8jEMKQHA== Date: Thu, 2 May 2019 19:26:23 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3353323@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] AD follow-up on draft-ietf-oauth-jwsreq-17 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, 02 May 2019 19:26:30 -0000 Hi! Draft-ietf-oauth-jwsreq-17 is currently in "Approved-announcement to be sen= t::Revised I-D Needed". I reviewed the Feb-2017 ballot and see that everyt= hing appears to have been addressed but: ** Mirja: "Should this document maybe update rfc6749?" -- I saw no response= on this item. What is the thinking? As I inherited this draft, I also conducted a review and have no substantiv= e comments. I'd ask that the authors do a minor rev to address the followi= ng editorial nits so that I can advance the draft. (1) Section 5.2 s/RFC 7230 [RFC7230] ./ RFC 7230 [RFC7230]./ (2) Section 5.2.1 s/Requiest/Request/ (3) Section 7. s/OAuth 2.0 [RFC6749] ./OAuth 2.0 [RFC6749]./ (4) Section 10.3 s/sited/cited/ Thanks for you work on the draft. Roman From nobody Thu May 2 13:46:30 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 449F31205E2 for ; Thu, 2 May 2019 13:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wtMeXnHIIY5 for ; Thu, 2 May 2019 13:46:27 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 C774B1204E0 for ; Thu, 2 May 2019 13:46:27 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id v143so5822268itc.1 for ; Thu, 02 May 2019 13:46:27 -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=kFFCtYB5jEizOnJI9l/ikcfoNmbRELCejxycZ7vRNUw=; b=RZ9QdmvGreN4y0T2S1RRih3jniBj9ZU2xo8H1E9V/AQi9ZuYS5A6p7JehhBP4dS08D hVQAjaDIH/FW0U7j9ee7kU+ZWnsbbz9cw5V3ycs+n3hvjCFaLn8jO08z6xGvi28IRN6a jt323SGnii06yzGgwTG6HCv/IqmFqYFO49JUl8f3uSs5YlxY+8LpaTUpu1qoogJkILRp DpBX22IbC8aV4JWJtFxwvVINUk84edJtlMhqu8Dw/G9paPrqUgd2TxAm5rqez34EzyYB lvm9DSTmX25tWlFVVpBESBBoNbUKCLSP2HtKLk4LZndBOYqkPtNHmkxc4A5aFos+ldHQ 4ZQg== 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=kFFCtYB5jEizOnJI9l/ikcfoNmbRELCejxycZ7vRNUw=; b=FfR977izcD8LpSn7E7xRLmBNKp2aoJGwgOEqo4EOYOxupYbeQr+FIxMZZTLK/HDKui +gJtN/GVIgCd+MZs18eDF5QNA9mezSlerTL4SFKkKvc3wh5DEkJJ6pQ9XUDvfe4NFCL5 fVM3T7/Pg9i+Lpyt4TTGSTrYc1fzNcubMIWVnZaXOyNdSGfjDilrWhOAnaG5XRW9pxNu mW00oDhxrrZ10FzFRh/fIpY/1IQDLsjVJkki6Nn76GkqNz9fTzJBPaaJrAb3107cZx0Y JBnqQ/hFtBHuQ1M2EiTKtCrjqtcCQP94qvZg7LEXyfeGj1HWounK7wvhy4Y5sa5tGUbX CazA== X-Gm-Message-State: APjAAAXzDtlvd+WdEJ3W6WN9fCaeCtz+pCnbmcLm8PqwTj0QxXJXZNHZ vpiHJUbq6xH60CvkSSjRhwPRuG9bdEeQ19Nun0TgrpecIHg= X-Google-Smtp-Source: APXvYqzcefVfomuyqJ6phCA5TfnR4xdcHa7U7I+9v+w+1GIhSV2WFPALbEABB9SjYVVVeYeCfGg4G4ce59OpVOcS9zI= X-Received: by 2002:a24:3201:: with SMTP id j1mr4435553ita.107.1556829986727; Thu, 02 May 2019 13:46:26 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 2 May 2019 16:46:15 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000055ac490587edba7f" Archived-At: Subject: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations 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, 02 May 2019 20:46:29 -0000 --00000000000055ac490587edba7f Content-Type: text/plain; charset="UTF-8" All, As part of the shepherd write-up for the *JWT Response for OAuth Token Introspection* draft, we are looking for information about implementations for this document: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ Are you aware of any implementations? Regards, Rifaat --00000000000055ac490587edba7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

= As part of the shepherd write-up for the JWT Response for OAuth Token In= trospection draft, we are looking for information about implementations= for this document:

Are you aware of any implementations?

Regard= s,
=C2=A0Rifaat


--00000000000055ac490587edba7f-- From nobody Thu May 2 18:13: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 10B4F12011C for ; Thu, 2 May 2019 18:13:05 -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 lT_SSbB3qX8y for ; Thu, 2 May 2019 18:13:03 -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 2220E12004D for ; Thu, 2 May 2019 18:13:02 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x431CwaM024029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 21:13:00 -0400 Date: Thu, 2 May 2019 20:12:58 -0500 From: Benjamin Kaduk To: Torsten Lodderstedt Cc: Sascha Preibisch , oauth Message-ID: <20190503011258.GM59871@kduck.mit.edu> References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net> <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <20190428040821.GF60332@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth 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, 03 May 2019 01:13:05 -0000 On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote: > > > > Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk : > > > >> On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote: > >> Hi Sascha, > >> > >> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. > >> > >> In my last example, the scope is defined as > >> > >> "structured_scope":{ > >> "sign":{ > >> "credentialID":"qes_eidas", > >> "documentDigests":[ > >> { > >> "hash": > >> "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=", > >> "label":"Mobile Subscription Contract" > >> } > >> ], > >> "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1" > >> }, > >> "payment":{ > >> "type":"sepa-credit-transfer", > >> "instructedAmount":{ > >> "currency":"EUR", > >> "amount":"123.50" > >> }, > >> "debtorAccount":{ > >> "iban":"DE40100100103307118608" > >> }, > >> "creditorName":"Merchant123", > >> "creditorAccount":{ > >> "iban":"DE02100100109307118603" > >> }, > >> "remittanceInformationUnstructured":"new Smartphone" > >> } > >> > >> This means “sign" and “payment" would determine the scheme of the respective object. > >> > >> What do you think? > > > > I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the > > "typ" header, and all the reasoning we have to do about different types of > > tokens (not) being replayable at a different endpoint and being interpreted > > wrongly. > > While I agree with the need to use the typ header, I don’t see a direct relationship to my proposal as it is about specifying the intended scope of tokens but not the token format itself. Can you explain your thoughts in more detail? I'll try; my thoughts do not seem entirely well formed, though, so perhaps it will not work very well. It seems like we're opening up for the structured_scope to be an arbitrary JSON object. But the recipient needs to know what context to interpret that object in -- e.g., this "payment" subobject has a clear intent to transfer money in the indicated currency from the one account to the other. But someone else might put a different subobject under "payment", perhaps one where users "pay" each other in virtual kittens for good behavior, which is a different context but the same JSON element. Receivers will of course have some expectation of what they should be getting, and can in effect enforce that what they receive matches a schema, but those are implicit ways of indicating what context an object is to be interpreted in, and we may want to consider explicitly stating an indicator of the context in which an object is intended to be considered. Maybe there's already something in the containing message that will fill that role (see also: "not entirely well formed"), in which case this concern evaporates. Thanks, Ben From nobody Thu May 2 20:41: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 46C661201D5 for ; Thu, 2 May 2019 20:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=bwvZWSC9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AuKgEVHk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ics4qHhviYbD for ; Thu, 2 May 2019 20:41:53 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AD71201D0 for ; Thu, 2 May 2019 20:41:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4CFD521FED for ; Thu, 2 May 2019 23:41:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 02 May 2019 23:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=8z9AY0y1PrLuN+pKo0XJZN3 6FOPVNeemOjm93Begn3A=; b=bwvZWSC9aN2s4qwe9vhwS3TSH/bk5+H64CXUPCl 0vrKRhcRgzeW9IG7KFj2DozOfClE+3F7faxKvEL4oTfAvoW13siQw6Z5tdlYGTif CgxFoC4BirnOAWPVqag9pzstTN120sRCHDD3PGJLWD7xWP+YsQo7i2YgbuQpgpS3 PUHw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8z9AY0 y1PrLuN+pKo0XJZN36FOPVNeemOjm93Begn3A=; b=AuKgEVHkcCAT+fmnkMv2z9 tFh7N72d8n6GB3StQjuIcM7PZoTTZQeHLf/GjQRsHroJ7OZGvKJuEUfPF781+iXm NIEuVbH4hL7+WSYV0v8Pf+bt7B97F25pYCOF50EOHur4lPzY0H4twWYXmDyancYY JCqrX7r0+HwiqtEU6o+D9U1HadPHY/On1f8RvUJF2IjjI/ozja4afY9HMdy5HauF jZOi8I1ofMxweHarBailDUNh5synRIWf3bxn3YO3pEKCOqAkpX8AFqg5ut9wVyRn bbGKGyTukiKmMMBaAo4wtC+VfV1GefHpw8gx0E8TqhVoCyBKSnUpkZ6Bj2ZNA7nw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepvffhuffkffgfgggtgfesthhqredttd efjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgtohhm qeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedukeegrddugeekrdehvddrvd dvleenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsegvvhgvrhhtphhothdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.2.10] (toroon0954w-lp140-02-184-148-52-229.dsl.bell.ca [184.148.52.229]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D85C103CA for ; Thu, 2 May 2019 23:41:51 -0400 (EDT) To: oauth@ietf.org From: Evert Pot Openpgp: preference=signencrypt Autocrypt: addr=me@evertpot.com; keydata= mQINBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAlQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFbkCDQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAYkCPAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA Message-ID: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> Date: Thu, 2 May 2019 23:41:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [OAUTH-WG] Link relations for authenticating 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, 03 May 2019 03:41:55 -0000 Hi everyone! I've been running into a number of situations where it would have been beneficial to have a few protocol/media-type agnositic link relation types for user authentication purposes. https://tools.ietf.org/html/draft-pot-authentication-link Nothing here is coupled to OAuth, but the link relations could potentially be used with OAuth2 servers. I don't exactly know the IETF process, but I thought it would be a good idea to ask for feedback here. My understanding is that either I should find an appropriate WG that's willing to adopt it, or I could do an individual submission. I'm not entirely sure yet which would be the most appropriate WG to ask, so I thought I'd start here. Evert From nobody Thu May 2 23:22:55 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 3539012006B for ; Thu, 2 May 2019 23:22:54 -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 7A7u2YIKrylo for ; Thu, 2 May 2019 23:22:51 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E26120059 for ; Thu, 2 May 2019 23:22:50 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.116]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hMRap-00022X-RO; Fri, 03 May 2019 08:22:47 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-DABF5737-53D2-4C4E-8520-747C6CB20868; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16E227) In-Reply-To: <20190503011258.GM59871@kduck.mit.edu> Date: Fri, 3 May 2019 08:22:47 +0200 Cc: Sascha Preibisch , oauth Content-Transfer-Encoding: 7bit Message-Id: <041703BF-3ACC-4B0A-A30E-B7D23F81F1A8@lodderstedt.net> References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net> <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <20190428040821.GF60332@kduck.mit.edu> <20190503011258.GM59871@kduck.mit.edu> To: Benjamin Kaduk X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth 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, 03 May 2019 06:22:54 -0000 --Apple-Mail-DABF5737-53D2-4C4E-8520-747C6CB20868 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, understood! It seems some scheme identifier would be helpful. thanks, Torsten. > Am 03.05.2019 um 03:12 schrieb Benjamin Kaduk : >=20 >> On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote: >>=20 >>=20 >>>> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk : >>>>=20 >>>> On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote: >>>> Hi Sascha, >>>>=20 >>>> I see. I assume every element within the structured scope element to be= an independent scope (value) object and intended to use the name of that ob= ject as kind of content type definition.=20 >>>>=20 >>>> In my last example, the scope is defined as=20 >>>>=20 >>>> "structured_scope":{ =20 >>>> "sign":{ =20 >>>> "credentialID":"qes_eidas", >>>> "documentDigests":[ =20 >>>> { =20 >>>> "hash": >>>> "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D", >>>> "label":"Mobile Subscription Contract" >>>> } >>>> ], >>>> "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1" >>>> }, >>>> "payment":{ =20 >>>> "type":"sepa-credit-transfer", >>>> "instructedAmount":{ =20 >>>> "currency":"EUR", >>>> "amount":"123.50" >>>> }, >>>> "debtorAccount":{ =20 >>>> "iban":"DE40100100103307118608" >>>> }, >>>> "creditorName":"Merchant123", >>>> "creditorAccount":{ =20 >>>> "iban":"DE02100100109307118603" >>>> }, >>>> "remittanceInformationUnstructured":"new Smartphone" >>>> } >>>>=20 >>>> This means =E2=80=9Csign" and =E2=80=9Cpayment" would determine the sch= eme of the respective object.=20 >>>>=20 >>>> What do you think? >>>=20 >>> I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using t= he >>> "typ" header, and all the reasoning we have to do about different types o= f >>> tokens (not) being replayable at a different endpoint and being interpre= ted >>> wrongly. >>=20 >> While I agree with the need to use the typ header, I don=E2=80=99t see a d= irect relationship to my proposal as it is about specifying the intended sco= pe of tokens but not the token format itself. Can you explain your thoughts i= n more detail? >=20 > I'll try; my thoughts do not seem entirely well formed, though, so perhaps= > it will not work very well. >=20 > It seems like we're opening up for the structured_scope to be an arbitrary= > JSON object. But the recipient needs to know what context to interpret > that object in -- e.g., this "payment" subobject has a clear intent to > transfer money in the indicated currency from the one account to the other= . > But someone else might put a different subobject under "payment", perhaps > one where users "pay" each other in virtual kittens for good behavior, > which is a different context but the same JSON element. >=20 > Receivers will of course have some expectation of what they should be > getting, and can in effect enforce that what they receive matches a schema= , > but those are implicit ways of indicating what context an object is to be > interpreted in, and we may want to consider explicitly stating an indicato= r > of the context in which an object is intended to be considered. Maybe > there's already something in the containing message that will fill that > role (see also: "not entirely well formed"), in which case this concern > evaporates. >=20 > Thanks, >=20 > Ben --Apple-Mail-DABF5737-53D2-4C4E-8520-747C6CB20868 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 HAYJKoZIhvcNAQkFMQ8XDTE5MDUwMzA2MjI0N1owLwYJKoZIhvcNAQkEMSIEICUudKCYasdKHEDR FqTl86Jaem4XznPeOUYpncenMREnMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBePu8GTAewg3ygtgelcTGOW1u/gQ+Mwi/715Cb hHUaKjCkmT98HMpML1m4mPkRnBoMRl+Tnw8BW9l/JUUK5+bqF+7jpZM6nYOnD8WGBboApKyRO9oZ UvqI5yIwdcS+N2k9fPem6yUfYbKSYCTZI5wFKpsWstvSNEQ1u7v2p56goRa7hwFBT3PgcVmS0GsR 5uCTO+EcNz/VdinoJcz5TlOuqvs8NbR1mjA9O/uvw5DotEEknVQ5tbnfPpKaCBckRSh0OR7prp8C wRpcI0eGFfxeJy2vkjNeQtcWnBAvdYmj5IiHBxf0ru8sHBlJ/75sPel2X3oa9B1HbnDvz8f+/81L AAAAAAAA --Apple-Mail-DABF5737-53D2-4C4E-8520-747C6CB20868-- From nobody Thu May 2 23:27:48 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 2EC9812006B for ; Thu, 2 May 2019 23:27:46 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es-L9RgBWdDJ for ; Thu, 2 May 2019 23:27:43 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 55C7B120059 for ; Thu, 2 May 2019 23:27:43 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.116]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hMRfX-0003mL-MP; Fri, 03 May 2019 08:27:39 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-7DC8D6E2-246F-492F-B6F1-FA40363B04F6; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16E227) In-Reply-To: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> Date: Fri, 3 May 2019 08:27:39 +0200 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> To: Phil Hunt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 03 May 2019 06:27:46 -0000 --Apple-Mail-7DC8D6E2-246F-492F-B6F1-FA40363B04F6 Content-Type: multipart/alternative; boundary=Apple-Mail-FA1D5CFC-9089-42B1-97F0-097893857A69 Content-Transfer-Encoding: 7bit --Apple-Mail-FA1D5CFC-9089-42B1-97F0-097893857A69 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phil, since mTLS is used at the tokens endpoint, native apps can definitely use th= eir own key pair. I would asunder such an app to act as public client, but m= TLS would allow such an app to bind its key pair with the token request to t= he issued tokens. Apps running in the browser is a separate topic. There are potential issues w= ith using the certs in the browser. That=E2=80=99s why work towards an appli= cation level PoP mechanism has been started - DPoP. best regards, Torsten. > Am 02.05.2019 um 20:41 schrieb Phil Hunt : >=20 > I was wondering if anyone had any recommended MTLS best practices for mobi= le apps and native browsers. >=20 > Considering Section 6 of RFC8252=E2=80=A6 > After constructing the authorization request URI, the app uses > platform-specific APIs to open the URI in an external user-agent. > Typically, the external user-agent used is the default browser, that > is, the application configured for handling "http" and "https" scheme > URIs on the system; however, different browser selection criteria and > other categories of external user-agents MAY be used. >=20 > What choices do developers have to ensure the authorization (and subsequen= t user authentication) occur over MTLS? Can the app provide its own key for M= TLS or can it ask that an embedded X.509 cert be used (assuming one is avail= able)? >=20 > Are there any platform issues or best practices? >=20 > Phil Hunt | Cloud Security and Identity Architect > Oracle Corporation, Oracle Cloud Infrastructure > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FA1D5CFC-9089-42B1-97F0-097893857A69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi P= hil,

since mTLS is used at t= he tokens endpoint, native apps can definitely use their own key  pair.= I would asunder such an app to act as public client, but mTLS would allow s= uch an app to bind its key pair with the token request to the issued tokens.=

Apps running in the browse= r is a separate topic. There are potential issues with using the certs in th= e browser. That=E2=80=99s why work towards an application level PoP mechanis= m has been started - DPoP.

= best regards,
Torsten.

Am 02= .05.2019 um 20:41 schrieb Phil Hunt <phil.hunt@oracle.com>:

I was wondering if anyone had any recommended MTLS best practices= for mobile apps and native browsers.

Considering Section 6 of RFC8252=E2=80=A6
   After constructing the au=
thorization request URI, the app uses
   platform-specific APIs to open the URI in an external user-agent.
   Typically, the external user-agent used is the default browser, that
   is, the application configured for handling "http" and "https" scheme
   URIs on the system; however, different browser selection criteria and
   other categories of external user-agents MAY be used.

What choices do developers have to en= sure the authorization (and subsequent user authentication) occur over MTLS?= Can the app provide its own key for MTLS or can it ask that an embedded X.5= 09 cert be used (assuming one is available)?

Are there any platform issues or best practices?

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Inf= rastructure
@independenti= d






_______________________________________________OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-FA1D5CFC-9089-42B1-97F0-097893857A69-- --Apple-Mail-7DC8D6E2-246F-492F-B6F1-FA40363B04F6 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 HAYJKoZIhvcNAQkFMQ8XDTE5MDUwMzA2MjczOVowLwYJKoZIhvcNAQkEMSIEIM4jdjT5l1rldFFM V2JQM8UpAXSxZzoPGu13D7sujfMNMIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQCjYsp+l+G5zlfvKA5yInjK30sti2kT4gdcyw8v 8488OFwUxYiLAwIYd24VNhdY2PrwA8Q9QBshxSnZvyEzBf1hXHDo9gimAJDcvl+48sn0/44Zq6z8 Yvr2So499sPQwgDaiqe3t0PnF28zvpV0NecZhbxcayQlv3LWOJsCWbez5rzk10Dn2ITOVGnWIaer bxi/rxR1tvC5snTY/EhmZhIfgE5N+HKr8VPbt4UplrsHcVftRyw71IrKZVlwcck8emymBdnwjNjU 998nFSI1SLVE4TH7ULVWO3smXXEwOQ9iocE779vUcduhM6FZs0uxDLZ6bBVScF/2cuQvcRUv58KI AAAAAAAA --Apple-Mail-7DC8D6E2-246F-492F-B6F1-FA40363B04F6-- From nobody Fri May 3 00:07: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 98A53120090 for ; Fri, 3 May 2019 00:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3AGs22atKji for ; Fri, 3 May 2019 00:07:27 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C16412006D for ; Fri, 3 May 2019 00:07:27 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4374CSX052414; Fri, 3 May 2019 07:07:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=bMhKzJAqvq7dtYCC8qk+Uso4k+yvgiTIZQv0rBN+zEI=; b=ewu0Tg9U5EuvYpEbh0qk3HbVQ52mrE3UQIcMWu9nQn0A/sMdpPRAAvYbddT/3rcOTcug wIY3Pw/dc9+G9eYKHdCSuvnb53SPYORpydfGI5DURumlzEFX31qIW+XpzgQ2U0Nxyf6i 9dt03L9TniVoVpC38HVuRamNE6Vzx6rVnT/vDsocGgHgKibbH+b9ilouyyFC6i2amhcm AYhIfOd9l4mrGkZrP8j2uYLWzbprLPrkLm2JvKX4FB0wH8SAi50IWCcNYp962GfGJpv2 uaINtNnMjcLS8kGq2bX/3/1+RbdIv1Aso9YAhMI85J3vUlSNcKoKpVOy5Knd/u1Z+axI 4A== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2s6xhyvxm2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 07:07:25 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4376pfi024419; Fri, 3 May 2019 07:07:25 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2s6xhh7n60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 07:07:25 +0000 Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4377L1C004771; Fri, 3 May 2019 07:07:24 GMT Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 May 2019 00:07:21 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-950AA235-AE70-4C83-ABAE-C6B14BD73809 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Fri, 3 May 2019 00:07:20 -0700 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <4354F4CA-5FC2-4A9A-BBC9-E492F32A43D3@oracle.com> References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> To: Torsten Lodderstedt X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 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-1810050000 definitions=main-1905030045 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030045 Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 03 May 2019 07:07:30 -0000 --Apple-Mail-950AA235-AE70-4C83-ABAE-C6B14BD73809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. I was more wondering if the app can invoke the system embedded view usi= ng its own key pair to ensure protected authen.=20 Eg. If the authorization endpoint is set to require mutual tls, can the syst= em view use the app=E2=80=99s keys since the app is invoking it? Or, would there have to be a user x.509 cert embedded in the browser store? = =20 I agree browser based apps is another matter.=20 Phil > On May 2, 2019, at 11:27 PM, Torsten Lodderstedt = wrote: >=20 > Hi Phil, >=20 > since mTLS is used at the tokens endpoint, native apps can definitely use t= heir own key pair. I would asunder such an app to act as public client, but= mTLS would allow such an app to bind its key pair with the token request to= the issued tokens. >=20 > Apps running in the browser is a separate topic. There are potential issue= s with using the certs in the browser. That=E2=80=99s why work towards an ap= plication level PoP mechanism has been started - DPoP. >=20 > best regards, > Torsten. >=20 >> Am 02.05.2019 um 20:41 schrieb Phil Hunt : >>=20 >> I was wondering if anyone had any recommended MTLS best practices for mob= ile apps and native browsers. >>=20 >> Considering Section 6 of RFC8252=E2=80=A6 >> After constructing the authorization request URI, the app uses >> platform-specific APIs to open the URI in an external user-agent. >> Typically, the external user-agent used is the default browser, that >> is, the application configured for handling "http" and "https" scheme >> URIs on the system; however, different browser selection criteria and >> other categories of external user-agents MAY be used. >>=20 >> What choices do developers have to ensure the authorization (and subseque= nt user authentication) occur over MTLS? Can the app provide its own key for= MTLS or can it ask that an embedded X.509 cert be used (assuming one is ava= ilable)? >>=20 >> Are there any platform issues or best practices? >>=20 >> Phil Hunt | Cloud Security and Identity Architect >> Oracle Corporation, Oracle Cloud Infrastructure >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-950AA235-AE70-4C83-ABAE-C6B14BD73809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. I was more wondering if the app can in= voke the system embedded view using its own key pair to ensure protected aut= hen. 

Eg. If the authorization endpoint is set to re= quire mutual tls, can the system view use the app=E2=80=99s keys since the a= pp is invoking it?

Or, would there have to be a user x= .509 cert embedded in the browser store?  

I a= gree browser based apps is another matter. 

Phil

On May 2, 2019,= at 11:27 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Phil,
<= div dir=3D"ltr">
since mTLS is used at the tokens e= ndpoint, native apps can definitely use their own key  pair. I would as= under such an app to act as public client, but mTLS would allow such an app t= o bind its key pair with the token request to the issued tokens.

Apps running in the browser is a separ= ate topic. There are potential issues with using the certs in the browser. T= hat=E2=80=99s why work towards an application level PoP mechanism has been s= tarted - DPoP.

best regards= ,
Torsten.

Am 02.05.2019 um 2= 0:41 schrieb Phil Hunt <phil.hunt= @oracle.com>:

I w= as wondering if anyone had any recommended MTLS best practices for mobile ap= ps and native browsers.

= Considering Section 6 of RFC8252=E2=80=A6
   After constructing the authorization re=
quest URI, the app uses
   platform-specific APIs to open the URI in an external user-agent.
   Typically, the external user-agent used is the default browser, that
   is, the application configured for handling "http" and "https" scheme
   URIs on the system; however, different browser selection criteria and
   other categories of external user-agents MAY be used.

What choices do developers have to en= sure the authorization (and subsequent user authentication) occur over MTLS?= Can the app provide its own key for MTLS or can it ask that an embedded X.5= 09 cert be used (assuming one is available)?

Are there any platform issues or best practices?

Phil Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Inf= rastructure
@independenti= d






_______________________________________________OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-950AA235-AE70-4C83-ABAE-C6B14BD73809-- From nobody Fri May 3 00:13: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 5DB0012006D for ; Fri, 3 May 2019 00:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 LwtoPwiutS74 for ; Fri, 3 May 2019 00:13:04 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 345C8120044 for ; Fri, 3 May 2019 00:13:04 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id e92so2274571plb.6 for ; Fri, 03 May 2019 00:13:04 -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=+MsViEBgiCpxSdTLEGV4P4kecO+WaSsgORb/BfpMorE=; b=U0pTaDYqKDgdwN0Qzb6jHVebTtstg7aZOL7FeI3lz9t6ztZoq2ZLhjHgyx1rpeBG12 Cki/em2S6qPbM6OwuRgP8/qsxEQ86XkLlqFACZf1CjzO7paNuUWINfH8cWoh7WvsQev+ dlDEe+WXH5ra54xymFtJcqCA+nJ1vMJASZiAw= 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=+MsViEBgiCpxSdTLEGV4P4kecO+WaSsgORb/BfpMorE=; b=KMikQqtc1uCKNZHPTEtJwAWGN0U9e0Y/2IkEy1Vor7PjUBdSK2qM1xz+SG/qT6SVZy UnJ+sfcnQAm1AD9Lh/G4HSXdUP5Oyct7bZ2J2SJFu0WOS3gVcP2a3/Wp1pOqNFBOtPSA y7NCGiI6A8cByyINZUxjRMItVdHT6sR8jl9bTSMO/t7r9eyJPp+YAft+hYLyy0NjXI6o dGm9WdlrZ+NxI0hfF6Xkq7gUNrxw+U723d4/FJEI1F7OOGUDiZnsWwmTNme3fMiV01oB B5hV6jxxgZ/VlprOUXSgpYOr/sY85Rq7/V5OQGqGBn+Y2x5su5B4KMAbzjDYt6gK7aQv awWg== X-Gm-Message-State: APjAAAWYopqvLxRJbARL5HJneFVNMoSK/TKjiL1pa1aT0rVy/ObowOhJ tksqES1tPHe99ZrLrg9yMHAIgdmtqIb4L2qLtau31TJMhgvQC/+41aX8cZJCJHC/u6LHu+q9957 Yjr/rW5xJpao+2g== X-Google-Smtp-Source: APXvYqzD6s7r1xpI0afrDEyih3BoWq1aUkCh5HDY1dRq+gx9K2v76nVqPBVe3DeQZmbMg1wsIb3qe2NQZEZ+hO5cwHk= X-Received: by 2002:a17:902:1024:: with SMTP id b33mr8198030pla.46.1556867583569; Fri, 03 May 2019 00:13:03 -0700 (PDT) MIME-Version: 1.0 References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> <4354F4CA-5FC2-4A9A-BBC9-E492F32A43D3@oracle.com> In-Reply-To: <4354F4CA-5FC2-4A9A-BBC9-E492F32A43D3@oracle.com> From: Rob Otto Date: Fri, 3 May 2019 08:12:52 +0100 Message-ID: To: Phil Hunt Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000480a200587f67bbd" Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 03 May 2019 07:13:07 -0000 --000000000000480a200587f67bbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you hoping to use the key to authenticate the user, or the OAuth client? If it's the latter, then you don't need to use MTLS to the authorisation endpoint. If it's the former, I'd argue that you would certainly need to include your public key in an X509 cert and *somehow* make it available to the system browser. On Fri, 3 May 2019 at 08:07, Phil Hunt wrote: > Yes. I was more wondering if the app can invoke the system embedded view > using its own key pair to ensure protected authen. > > Eg. If the authorization endpoint is set to require mutual tls, can the > system view use the app=E2=80=99s keys since the app is invoking it? > > Or, would there have to be a user x..509 cert embedded in the browser > store? > > I agree browser based apps is another matter. > > Phil > > On May 2, 2019, at 11:27 PM, Torsten Lodderstedt > wrote: > > Hi Phil, > > since mTLS is used at the tokens endpoint, native apps can definitely use > their own key pair. I would asunder such an app to act as public client, > but mTLS would allow such an app to bind its key pair with the token > request to the issued tokens. > > Apps running in the browser is a separate topic. There are potential > issues with using the certs in the browser. That=E2=80=99s why work towar= ds an > application level PoP mechanism has been started - DPoP. > > best regards, > Torsten. > > Am 02.05.2019 um 20:41 schrieb Phil Hunt : > > I was wondering if anyone had any recommended MTLS best practices for > mobile apps and native browsers. > > Considering Section 6 of RFC8252=E2=80=A6 > > After constructing the authorization request URI, the app uses > platform-specific APIs to open the URI in an external user-agent. > Typically, the external user-agent used is the default browser, that > is, the application configured for handling "http" and "https" scheme > URIs on the system; however, different browser selection criteria and > other categories of external user-agents MAY be used. > > > What choices do developers have to ensure the authorization (and > subsequent user authentication) occur over MTLS? Can the app provide its > own key for MTLS or can it ask that an embedded X.509 cert be used > (assuming one is available)? > > Are there any platform issues or best practices? > > Phil Hunt | Cloud Security and Identity Architect > Oracle Corporation, Oracle Cloud Infrastructure > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 [image: Ping Identity] Rob Otto EMEA Field CTO/Solutions Architect robotto@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] --=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._ --000000000000480a200587f67bbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are you hoping to use the key to authenticate the = user, or the OAuth client? If it's the latter, then you don't need = to use MTLS to the authorisation endpoint. If it's the former, I'd = argue that you would certainly need to include your public key in an X509 c= ert and *somehow* make it available to the system browser.=C2=A0

On Fr= i, 3 May 2019 at 08:07, Phil Hunt <phil.hunt@oracle.com> wrote:
Yes. I was more wondering if the a= pp can invoke the system embedded view using its own key pair to ensure pro= tected authen.=C2=A0

Eg. If the authorization endpoint i= s set to require mutual tls, can the system view use the app=E2=80=99s keys= since the app is invoking it?

Or, would there have = to be a user x..509 cert embedded in the browser store? =C2=A0
I agree browser based apps is another matter.=C2=A0
=
= Phil

On May 2, 2019, at 11:27 PM, Torsten Lodders= tedt <torst= en@lodderstedt.net> wrote:

Hi Phil,

since mTLS is used at the tokens endp= oint, native apps can definitely use their own key =C2=A0pair. I would asun= der such an app to act as public client, but mTLS would allow such an app t= o bind its key pair with the token request to the issued tokens.

Apps running in the browser is a sep= arate topic. There are potential issues with using the certs in the browser= . That=E2=80=99s why work towards an application level PoP mechanism has be= en started - DPoP.

best re= gards,
Torsten.

Am 02.05.20= 19 um 20:41 schrieb Phil Hunt <phil.hunt@oracle.com>:

I was wondering if anyone had any recommended M= TLS best practices for mobile apps and native browsers.

= Considering Section 6 of RFC8252=E2=80=A6
   After constructing the authorization r=
equest URI, the app uses
   platform-specific APIs to open the URI in an external user-agent.
   Typically, the external user-agent used is the default browser, that
   is, the application configured for handling "http" and "h=
ttps" scheme
   URIs on the system; however, different browser selection criteria and
   other categories of external user-agents MAY be used.

What choices do developers have to ensure the authorization (and sub= sequent user authentication) occur over MTLS? Can the app provide its own k= ey for MTLS or can it ask that an embedded X.509 cert be used (assuming one= is available)?

Are there any platform issues or b= est practices?

Phi= l Hunt | Cloud Security and Identity Architect
Oracle Corporation, Oracle Cloud Infrastructure
@independentid






_______________________________________________
OA= uth 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


--
=
3D"Ping = =
Rob Otto
EMEA Field CTO/S= olutions Architect
robotto@p= ingidentity.com

= = c: +44 (0) 777 135 6092
Connect with us: 3D"Glas= 3D"LinkedIn <= a href=3D"https://twitter.com/pingidentity" style=3D"text-decoration:none;m= argin-right:16px" title=3D"Ping on Twitter" target=3D"_blank">3D"twitter = 3D"= 3D"youtube 3D"Google+<= /a> 3D"Blog
=

<= 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. --000000000000480a200587f67bbd-- From nobody Fri May 3 00:32:25 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 2F5EF1200A0 for ; Fri, 3 May 2019 00:32: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JXkeE26m2M7 for ; Fri, 3 May 2019 00:32:21 -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 DCE8812006B for ; Fri, 3 May 2019 00:32:20 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id b67so8209631wmg.1 for ; Fri, 03 May 2019 00:32:20 -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=VlOPwnmc0t2lJYfxAMQNY2LgdvBBxU75QZf3z5/+vmY=; b=A9id08us4+waWa71oMC4gE/PhPnyj1IrJE+168Ewn9DICB3bjn458QhYAg6/DoD05q R+mmSXDKsIiCaiOGaT4aqSlbd1OL/pyFOBef/04gRcZq+ZSgkaiePkrmWTjuLwJQauNV FDgPeASSx8caj0N4HvPs2nae8uMT/R7+N+PDEWFQDGp7VpprXB1UYc7bWXIVfwrKup3U EP2KpWvu48R9z5/OWxrJSLniXHaLaoQ/6fe+EXpZTHEHyBWwHKoDcqZzB4zdxmXoCbEt R8c824hp/YVRMIQy3CAh65rajxqNdR2po8WObpHyqyIcR3AqKT4pAzKVAuHiHsvh/mzV tSUA== 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=VlOPwnmc0t2lJYfxAMQNY2LgdvBBxU75QZf3z5/+vmY=; b=tPddfIOzndDALZzTIxXrEaqAIpXHNe9iPlKS6qD1TVAFMcMcOV+2eaDve3wfeHG6+S aX62pnU5mRLsfvzw3bEVnoLHIIyO1Ny4NaMiIC3ojL0t6x2t1YVxDZl3JVirUwH4Hi6k O/Rlgj9hQJQe6UwGBEvOOg6ktpQtSfvXmNsHQiatE4JAWayOMu5FR2iUlfdFbs0f+qn5 Q1AwA+EHeAsKpxGd4GlzZavFIibYH3NN33hcS9jcMStWzHz7fH7sjZ0PNDztoJpnR2MJ 4Xv62ki5TcIkAwvYzOjf6EKp4f1rgOJUE94fpWrtX5q3xVRBbvjwLStNc0jSecgxt4Q7 p7uQ== X-Gm-Message-State: APjAAAW8wfA8oRG1rnIoO3PJCZtysHXRWRVgvNM4XvsciULBkWn+s/eH HlZ9kKaBGAsZjFXk3PiKj+BziEDrsSqS X-Google-Smtp-Source: APXvYqxxVzbi4iqpoeZVkKCKnfoy/v52fTD6Y5J164UJmhFqx5G69yPT4PdpeDxusWQqGNHEhrCAsg== X-Received: by 2002:a1c:c287:: with SMTP id s129mr5211854wmf.63.1556868739010; Fri, 03 May 2019 00:32:19 -0700 (PDT) Received: from [10.0.0.11] (194-118-63-99.hdsl.highway.telekom.at. [194.118.63.99]) by smtp.gmail.com with ESMTPSA id a12sm1556383wrh.46.2019.05.03.00.32.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 00:32:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9A0A6876-DA85-4666-A483-BB012AD3697E Mime-Version: 1.0 (1.0) From: Filip Skokan X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Fri, 3 May 2019 09:32:16 +0200 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Rifaat Shekh-Yusef Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations 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, 03 May 2019 07:32:23 -0000 --Apple-Mail-9A0A6876-DA85-4666-A483-BB012AD3697E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rifaat, node.js OSS oidc-provider implements the document in full behind an optional= feature toggle - https://github.com/panva/node-oidc-provider/blob/master/do= cs/README.md#featuresjwtintrospection Best, Filip Odesl=C3=A1no z iPhonu 2. 5. 2019 v 22:46, Rifaat Shekh-Yusef : > All, >=20 > As part of the shepherd write-up for the JWT Response for OAuth Token Intr= ospection draft, we are looking for information about implementations for th= is document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 > Are you aware of any implementations? >=20 > Regards, > Rifaat >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9A0A6876-DA85-4666-A483-BB012AD3697E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rifaat,

node.js OSS o= idc-provider implements the document in full behind an optional feature togg= le - https://github.com/panva/node-oidc= -provider/blob/master/docs/README.md#featuresjwtintrospection
=
Best,
Filip

Odesl=C3=A1no z iPhonu

2. 5. 2019 v=  22:46, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

All,

<= /div>
As part of the shepherd write-up for the JWT Response for OAuth= Token Introspection draft, we are looking for information about impleme= ntations for this document:

=
Are you aware of any implementations?

Re= gards,
 Rifaat


________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-9A0A6876-DA85-4666-A483-BB012AD3697E-- From nobody Fri May 3 08:38: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 764421200B8 for ; Fri, 3 May 2019 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FxKlRwmMvld for ; Fri, 3 May 2019 08:38:54 -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 E045112004B for ; Fri, 3 May 2019 08:38:53 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id g57so6475177edc.12 for ; Fri, 03 May 2019 08:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=K2XFSZorFwzS8yYwwVkjAI1R3du43tYZWkpH32jSITg=; b=mnDZ22CWkzWCkfsGVVA383bg8JsJdRa5IfTjAHzgGAxMJyH9q8eV4WkxpzELw/ruRN B/WY/oPxo4vgelFfdsLnm0f5qhuCB8HuhvwJvp0XbTNHSc3u+R1XReYOSNdRmMiDJ8DM 8W6TqqMxpk/AWXBk+1UC0IkL3WxIsXf8+VqSaFL1Kh4tnOM+dY9bjFW7/RGf6vzIHTlE yfkrA8z1rlqCCC2TIpRMSNEb411ZFaYcwKwqp7iXkZmkV22DEqcvfisoj5BEWaB4ReFM u298hS2XuBn+BgrF405KK4T6rmK4wnMCYE61WqbaDSrRB01pPmK7FwpZcnBZcuUu4kj2 bmhw== 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:mime-version :content-transfer-encoding; bh=K2XFSZorFwzS8yYwwVkjAI1R3du43tYZWkpH32jSITg=; b=JabbLw6x0pPIaipqsPHfI28K0Au58wuJ95o6BHseSJgYOQld+TKsU1UWb3X3+KqFsP OlF10zenilOG7rS8wbZime9th4DhjpFHEn8HoE+yfjT96qwbBqhf5H0irpIYaxStw3yG IJc1Et8yw9yldguCR63xsI1n2CYT0r0tW0xvXKNzdyvfM+ZcEcERMCXNPmJF00fiPWTV DjlvopS9oqLggESBobGXVihGAtsRwy9AMXfYeSYa1Sbxjio4+xF4TwqTA7v58nOwndse ylaTunVJten/E7EEVUrMHMG1oifdzNoE6WK/+1DQQXRoiatkzdOUGLinkmtPu2LnSqYC WUBA== X-Gm-Message-State: APjAAAX+46rFUSj0sHW+eYa/03P14wKkEgvuC9XeIlTlLTUbO2BWHHdx tw9VIHI9SpX+VY2tghEYWxuhc/oz1+o= X-Google-Smtp-Source: APXvYqyLlIBi2y4U9kDZgSwCTmGJn5Vsbc0/X6XkFF318ptaV0vckmG0IF4zdCYSEVCo0tBfPoWeUQ== X-Received: by 2002:a50:8dcd:: with SMTP id s13mr8887563edh.247.1556897932064; Fri, 03 May 2019 08:38:52 -0700 (PDT) Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id d6sm635999edq.65.2019.05.03.08.38.50 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 May 2019 08:38:51 -0700 (PDT) From: Emond Papegaaij To: oauth Date: Fri, 03 May 2019 17:38:35 +0200 Message-ID: <4223569.5sG2vptK2V@papegaaij> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [OAUTH-WG] Token Exchange status and Resource Indicators 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, 03 May 2019 15:38:56 -0000 Hi all, For the application I work on, Topicus KeyHub, we are investigating 'OAuth 2.0 Token Exchange'. We want to use this protocol to exchange an access token for a SAML assertion for signing in to AWS (see below). However, I noticed that draft 16 has expired on April 22, 2019. Is this specification still active? While looking at the specification I noticed a partial overlap with 'Resource Indicators for OAuth 2.0'. Both specify the 'resource' parameter on the token endpoint. However, Token Exchange adds to this the 'audience' parameter. In my opinion it would make sense to align these specs and add the 'audience' parameter to 'Resource Indicators'. 'Token Exchange' could then continue to build on the 'Resource Indicators' spec rather than redefining these parameters. The specific use case I have in mind is acquiring a SAML assertion for AWS on the command line, using the following steps: Our CLI starts with the device authorization grant. In the device+ authorization request, it passes 'audience=urn:amazon:webservices', which is the entity ID for AWS. I could use 'resource' here, but I think 'audience' is more appropriate. Next, the user will continue the authentication and will be prompted for consent with signing a token for AWS. The resulting access token will be audience restricted to AWS. Finally, the CLI will exchange this token for a SAML assertion for AWS. I can again pass the desired audience, but as it is already encoded in the token, this is optional. This assertion can then be passed to AWS to complete the sign-in. To summarize, I have to following questions: - Is the 'OAuth 2.0 Token Exchange' specification still active? - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource Indicators for OAuth 2.0' rather than redefining the same parameters? Best regards, Emond Papegaaij Topicus KeyHub From nobody Fri May 3 11:47: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 A45621202D5 for ; Fri, 3 May 2019 11:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKFTjl4iwkMj for ; Fri, 3 May 2019 11:47:40 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72DA1202D8 for ; Fri, 3 May 2019 11:47:37 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id p26so7146858edr.2 for ; Fri, 03 May 2019 11:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HYCoNw7w7O+riu4WsiR0borJ8aftOq5FE0zHsSrAhM=; b=nPTApeYZyURVu/KUVGU4QfXeSTWEfVWmiPkaN+jmeG3RuSi08kcrbxAeHXBrQS/2J3 Y2EFmdHakq9p4ASBNO7xA/RIo4LwMKUVzMfPqWCgtMt6m6a0C/D/pzSWE4V9yQs0/xbH zaAp4DqVCjOAdih+CnlUZoAdXq+Ym+jFPQf/j/jzGnyWi4GFBpeos+6GPkq+4T9OBjsl 2W64M/RgqPasR5/FESJLhaikHZ5x/P84G/kcoL62PteZ6j6jZ6iYj58Nl10tupzGArlH Tp0vK+D7zvhiIh+m3B5WnaYqhLVZkqsfLMYztnBpANM9VYEGLiazijNrt5SH17/jWqkI PnfQ== 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=0HYCoNw7w7O+riu4WsiR0borJ8aftOq5FE0zHsSrAhM=; b=Mdy8FFTmZ0hXamXaHSqvSqrzFK7zc+t7NJgFFz4U0BcS5EJZ8SDBS5R4/6Utf0Kfvu JfMnAoZeYRbIA31LqwjV5AE7HFNnS4AvC5qx9Bs7Yk5RAiVUtGJJ+C7r545wt9hJGnus 6cC0ZEepuwH0yHp+q/FMWEnrxBSAPp0NjVaTwz7zSSjWC6156+HvSZlAZevsVUrniOGi CU0GZD5uLUC4mXD1C5UFVjgYkTRarwEHvd5wbtVTJt9zGGXWHcwveFgpLNSd6Y6Rd5cN 3o/X8B3CcuLTl2ef1eq58QYM8Z0rXgUUjcTJcqfet0TVEfxu3R+2nztktZ5dLG9qjmD9 qFVA== X-Gm-Message-State: APjAAAVDk6QgkcOf2Ge6jkUokNrJjmEpma7/yaJA54V1FYRFMGPSZ5M3 EmTUfnXVm8HoBXN8qkr0VnEWsnDOoal+fAaRy20nURU7N88= X-Google-Smtp-Source: APXvYqzYQWzbMeJP+3QT+DP9GetFDi6WDZzoN/92hL4RtcvYuG7zV9NvVf2ePSosf9S8vXHkU/b3ir3SQtkAaaoNgOg= X-Received: by 2002:a17:906:ad82:: with SMTP id la2mr899937ejb.128.1556909256333; Fri, 03 May 2019 11:47:36 -0700 (PDT) MIME-Version: 1.0 References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <0D21D79B-58A2-4193-B022-C77B739962C2@lodderstedt.net> In-Reply-To: <0D21D79B-58A2-4193-B022-C77B739962C2@lodderstedt.net> From: Takahiko Kawasaki Date: Sat, 4 May 2019 03:47:25 +0900 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002bf3d20588002fbc" Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth 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, 03 May 2019 18:47:43 -0000 --0000000000002bf3d20588002fbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Torsten, To the point. (^_^; It is "request object". Sorry. Best, Taka 2019=E5=B9=B44=E6=9C=8830=E6=97=A5(=E7=81=AB) 19:24 Torsten Lodderstedt : > Dear Taka, > > thanks for your feedback. > > How would this more generic mechanism differ from the JSON-based request > object? I personally would advocate to use both, structured scope & pushe= d > request object, to together. > > best regards, > Torsten. > > Am 26.04.2019 um 09:47 schrieb Takahiko Kawasaki : > > Dear Torsten, > > I was impressed with your article. It describes considerations points ver= y > well that implementers of leading-edge authorization servers will > eventually face or have already faced. > > It seems to me that the mechanism of "structured_scope" can be positioned > as a more generic mechanism whose usage doesn't necessarily have to be > limited to scopes. I mean that the mechanism can be used to include any > arbitrary dynamic structured data in an authorization request. So, if the= re > were something I might be able to propose additionally, I would suggest > renaming "structured_scope" to a more generic name. > > Best Regards, > Takahiko Kawasaki > Representative director, Authlete, Inc. > > 2019=E5=B9=B44=E6=9C=8821=E6=97=A5(=E6=97=A5) 3:21 Torsten Lodderstedt : > >> Hi all, >> >> I just published an article about the subject at: >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-r= e-think-oauth-scopes-2326e2038948 >> >> >> I look forward to getting your feedback. >> >> kind regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000002bf3d20588002fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Torsten,

To the point. (^_^; It is= "request object". Sorry.

Best,
Taka


2019=E5=B9=B44=E6=9C=8830=E6=97=A5(=E7=81=AB) 19= :24 Torsten Lodderstedt <tors= ten@lodderstedt.net>:
Dear= Taka,

thanks for your fee= dback.

How would this more= generic mechanism differ from the JSON-based request object? I personally = would advocate to use both, structured scope & pushed request object, t= o together.

best regards,<= /div>
Torsten.

Am 26.04.2019 um 0= 9:47 schrieb Takahiko Kawasaki <taka@authlete.com>:

<= div>Dear Torsten,

I was impressed with your articl= e. It describes considerations points very well that implementers of leadin= g-edge authorization servers will eventually face or have already faced.

It seems to me that the mechanism of "structure= d_scope" can be positioned as a more generic mechanism whose usage doe= sn't necessarily have to be limited to scopes. I mean that the mechanis= m can be used to include any arbitrary dynamic structured data in an author= ization request. So, if there were something I might be able to propose add= itionally, I would suggest renaming "structured_scope" to a more = generic name.

Best Regards,
Takahiko Kaw= asaki
Representative director, Authlete, Inc.
2019=E5= =B9=B44=E6=9C=8821=E6=97=A5(=E6=97=A5) 3:21 Torsten Lodderstedt <torsten@lodderstedt.n= et>:
Hi a= ll,

I just published an article about the subject at: https://medium.com/o= auth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23= 26e2038948=C2=A0

I look forward to getting your feedback.

kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002bf3d20588002fbc-- From nobody Fri May 3 16:32:24 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 2DDC4120048; Fri, 3 May 2019 16:32:14 -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.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155692633407.7225.8208319971849722426@ietfa.amsl.com> Date: Fri, 03 May 2019 16:32:14 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-02.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, 03 May 2019 23:32:14 -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 Incremental Authorization Author : William Denniss Filename : draft-ietf-oauth-incremental-authz-02.txt Pages : 9 Date : 2019-05-03 Abstract: OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub- optimal end-user consent experience. This specification enhances the OAuth 2.0 authorization protocol by adding incremental authorization, the ability to request specific authorization scopes as needed, when they're needed, removing the requirement to request every possible scope that might be needed upfront. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-incremental-authz-02 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 Sat May 4 10:50:49 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 A2B32120193 for ; Sat, 4 May 2019 10:50:47 -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 nubVlSDr3FOl for ; Sat, 4 May 2019 10:50:45 -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 D340112019F for ; Sat, 4 May 2019 10:50:44 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x44HoYUM020047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 4 May 2019 13:50:36 -0400 Date: Sat, 4 May 2019 12:50:34 -0500 From: Benjamin Kaduk To: Paul Querna Cc: oauth@ietf.org Message-ID: <20190504175034.GV59871@kduck.mit.edu> References: 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] draft-fett-oauth-dpop-01 implementation feedback 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, 04 May 2019 17:50:48 -0000 On Wed, May 01, 2019 at 11:32:40PM -0700, Paul Querna wrote: > Hi all, > HTTP Request Signing > > o "http_method": The HTTP method for the request to which the JWT is > > attached, in upper case ASCII characters, as defined in [RFC7231] > > (REQUIRED). > > > > o "http_uri": The HTTP URI used for the request, without query and > > fragment parts (REQUIRED). > > HTTP Request signing may be a quagmire that this spec wishes to avoid, > but it seems very hard to avoid "fixing" it for at-scale adoption. > With the Okta-hat on, I think this is one area we would like to see > some iteration on. I think it would be ideal to not require multiple > client sign() and server validate() PKI operations per request, so > this is where combining DPoP-Proof and a Request Signature start > making sense to me. > > Keeping it simple, there are two approaches for DPoP for adding > attesting about the HTTP Request: > > a) Adding parts of the HTTP Request as claims > b) Adding a hash of an HTTP Request as a claim > > For option (b), it seems like part of this could live in a separate spec: > 1) request canonicalization > 2) request hashing > > does > cover request canonicalization, but the hashing is part of the > specific signature scheme. From an implementors POV, layering > draft-cavage-http-signatures-11 in addition to DPoP is annoying since > it would take two sign or verify key operations per request. I haven't had a chance to read the linked draft, but we've also seen some activity recently around https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05 and linked/related drafts, which are also working in a similar space. -Ben From nobody Sat May 4 12:37: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 290741202AF for ; Sat, 4 May 2019 12:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLXLeAeJUbhs for ; Sat, 4 May 2019 12:37:22 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id A3ADA120243 for ; Sat, 4 May 2019 12:37:22 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:d54:39a7:6ba1:58a5] (unknown [IPv6:2601:282:202:b210:d54:39a7:6ba1:58a5]) by alkaline-solutions.com (Postfix) with ESMTPSA id D18BC31794; Sat, 4 May 2019 19:37:21 +0000 (UTC) From: David Waite Message-Id: <781D6C2A-289E-4790-BC28-2654B931FD76@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_66C45235-DDB6-43CA-856F-B6E48400AF49" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 4 May 2019 13:37:21 -0600 In-Reply-To: Cc: oauth@ietf.org To: Paul Querna References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback 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, 04 May 2019 19:37:25 -0000 --Apple-Mail=_66C45235-DDB6-43CA-856F-B6E48400AF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2019, at 12:32 AM, Paul Querna wrote: > Jumping into specific items: >=20 > cnf in DPoP-Proof >> o "cnf": Confirmation claim as per [RFC7800] containing a member >> "dpop+jwk", representing the public key chosen by the client in >> JWK format (REQUIRED for DPoP Binding JWTs, OPTIONAL for DPoP >> Proof JWTs). >=20 > Is there a use case for this being present in the DPoP-Proof JWT? As > I've implemented DPoP, I didn't see how it was helpful to be sent as a > `cnf` claim of the Proof? Discussions with some of the authors makes me think the next draft will = change this so that there is no longer a distinction between binding and = proof, instead having the key sent outside the DPoP-Proof JWT while = binding (possibly as another header). This also allows for more = potential flexibility for where the client public key comes from. Ignoring that, cnf in a proof JWT would allow for debugging/errors to = indicate a key mismatch. I think the current language may be a bit = ambiguous as to whether a JWK set is allowed as =E2=80=9Ccnf=E2=80=9D as = it merely says =E2=80=9CJWK format"; if sets are allowed then cnf in the = proof would be used for key selection. > Request Headers vs Parameters >> 5. Token Request (Binding Tokens to a Public Key) >=20 > Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is > different than most other OAuth extensions that I am familiar with. > It is easy in the Go OAuth2 library to add URL / /body params to the > `/token` endpoint, but it is impossible to add an HTTP Header. Is > there a reason that the binding can't be sent as an OAuth Parameter in > the token request body? My understanding is that the goal is to have the proof be applied the = same for accessing the token endpoint as when accessing the resources.=20= RFC 6750 describes sending the access token as a query parameter or = application/x-www-form-urlencoded form parameter, with recommendations = of only legacy/last resort use and resources having this as MAY to = support. I believe the default position (without strong evidence) is to = not carry these forward by defining additional alternatives for DPoP as = a query/form parameter. >=20 > HTTP Request Signing >> o "http_method": The HTTP method for the request to which the JWT = is >> attached, in upper case ASCII characters, as defined in [RFC7231] >> (REQUIRED). >>=20 >> o "http_uri": The HTTP URI used for the request, without query and >> fragment parts (REQUIRED). >=20 > HTTP Request signing may be a quagmire that this spec wishes to avoid, > but it seems very hard to avoid "fixing" it for at-scale adoption. > With the Okta-hat on, I think this is one area we would like to see > some iteration on. I think it would be ideal to not require multiple > client sign() and server validate() PKI operations per request, so > this is where combining DPoP-Proof and a Request Signature start > making sense to me. >=20 > Keeping it simple, there are two approaches for DPoP for adding > attesting about the HTTP Request: >=20 > a) Adding parts of the HTTP Request as claims > b) Adding a hash of an HTTP Request as a claim >=20 > For option (b), it seems like part of this could live in a separate = spec: > 1) request canonicalization > 2) request hashing >=20 > does > cover request canonicalization, but the hashing is part of the > specific signature scheme. =46rom an implementors POV, layering > draft-cavage-http-signatures-11 in addition to DPoP is annoying since > it would take two sign or verify key operations per request. I believe the position at the moment is to keep this close to the bare = minimum necessary for operation as proof of possession - the method, = origin and path which may be used for routing, to allow for a resource = server enforce track one-time-use. The intersection of HTTP components that intermediaries should or must = leave unmodified per spec, and that are useful for http request signing = is basically empty. Even method and origin/path are often modified by = gateways - in such environments, either the intermediary should be = responsible for verifying DPoP or the resource will need knowledge on = how to verify the supplied method, origin and path (such as via static = knowledge or a header added by the intermediary) The proof can be extended with additional parameters, which the AS and = resource servers in an environment can require. In this manner, DPoP can = be extended to meet HTTP request signing use cases. HTTP request signing = will always be environment-specific however, and is a big additional ask = for a proof of possession specification. Cavage request verification, for example, could be mapped into a DPoP = extension by exposing requirements as extensions against the Bearer = authorization request, and embedding the cavage headers and a hash (not = digest or signature) of the output into the proof token. Or perhaps the = requirements are exposed as AS metadata to cover all resources. -DW= --Apple-Mail=_66C45235-DDB6-43CA-856F-B6E48400AF49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 2, 2019, at 12:32 AM, Paul Querna <pquerna@apache.org> = wrote:
Jumping into specific = items:

cnf in DPoP-Proof
 o  "cnf": = Confirmation claim as per [RFC7800] containing a member
=     "dpop+jwk", representing the public key chosen = by the client in
    JWK format = (REQUIRED for DPoP Binding JWTs, OPTIONAL for DPoP
=     Proof JWTs).

Is there a use case for this being present in the DPoP-Proof = JWT?  As
I've implemented DPoP, I didn't see how it = was helpful to be sent as a
`cnf` claim of the Proof?

Discussions with some of the authors makes me = think the next draft will change this so that there is no longer a = distinction between binding and proof, instead having the key sent = outside the DPoP-Proof JWT while binding (possibly as another header). = This also allows for more potential flexibility for where the client = public key comes from.

Ignoring = that, cnf in a proof JWT would allow for debugging/errors to indicate a = key mismatch. I think the current language may be a bit ambiguous as to = whether a JWK set is allowed as =E2=80=9Ccnf=E2=80=9D as it merely says = =E2=80=9CJWK format"; if sets are allowed then cnf in the proof would be = used for key selection.

Request Headers = vs Parameters
5. =  Token Request (Binding Tokens to a Public Key)

Placing the DPoP Binding JWT in = the HTTP Header `DPoP-Binding` is
different than most = other OAuth extensions that I am familiar with.
It is easy = in the Go OAuth2 library to add URL / /body params to the
`/token` endpoint, but it is impossible to add an HTTP = Header.  Is
there a reason that the binding can't be = sent as an OAuth Parameter in
the token request = body?

My understanding = is that the goal is to have the proof be applied the same for accessing = the token endpoint as when accessing the resources. 

RFC 6750 describes sending the access token as a = query parameter or application/x-www-form-urlencoded form parameter, with = recommendations of only legacy/last resort use and resources having this = as MAY to support. I believe the default position (without strong = evidence) is to not carry these forward by defining additional = alternatives for DPoP as a query/form parameter.


HTTP Request = Signing
 o =  "http_method": The HTTP method for the request to which the JWT = is
    attached, in upper case ASCII = characters, as defined in [RFC7231]
=     (REQUIRED).

=  o  "http_uri": The HTTP URI used for the request, without = query and
    fragment parts = (REQUIRED).

HTTP Request = signing may be a quagmire that this spec wishes to avoid,
but it seems very hard to avoid "fixing" it for at-scale = adoption.
With the Okta-hat on, I think this is one area = we would like to see
some iteration on.  I think it = would be ideal to not require multiple
client sign() and = server validate() PKI operations per request, so
this is = where combining DPoP-Proof and a Request Signature start
making sense to me.


Keeping it simple, there are = two approaches for DPoP for adding
attesting about the = HTTP Request:

 a) Adding parts of the = HTTP Request as claims
 b) Adding a hash of an HTTP = Request as a claim

For option (b), it seems = like part of this could live in a separate spec:
1) = request canonicalization
2) request = hashing

<https://tools.ietf.org/html/draft-cavage-http-signatures-11= > does
cover request canonicalization, but the hashing = is part of the
specific signature scheme.  =46rom an = implementors POV, layering
draft-cavage-http-signatures-11 = in addition to DPoP is annoying since
it would take two = sign or verify key operations per request.


I believe the position at the moment is to keep = this close to the bare minimum necessary for operation as proof of = possession - the method, origin and path which may be used for routing, = to allow for a resource server enforce track one-time-use.

The intersection of HTTP components that = intermediaries should or must leave unmodified per spec, and that are = useful for http request signing is basically empty. Even method and = origin/path are often modified by gateways - in such environments, = either the intermediary should be responsible for verifying DPoP or the = resource will need knowledge on how to verify the supplied method, = origin and path (such as via static knowledge or a header added by the = intermediary)

The proof can be = extended with additional parameters, which the AS and resource servers = in an environment can require. In this manner, DPoP can be extended to = meet HTTP request signing use cases. HTTP request signing will always be = environment-specific however, and is a big additional ask for a proof of = possession specification.

Cavage request verification, for example, could be mapped = into a DPoP extension by exposing requirements as extensions against the = Bearer authorization request, and embedding the cavage headers and a = hash (not digest or signature) of the output into the proof token. Or = perhaps the requirements are exposed as AS metadata to cover all = resources.

-DW
= --Apple-Mail=_66C45235-DDB6-43CA-856F-B6E48400AF49-- From nobody Sun May 5 05:56: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 08DBA12014D for ; Sun, 5 May 2019 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ire1gY8wLs for ; Sun, 5 May 2019 05:56:09 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0979412014C for ; Sun, 5 May 2019 05:56:09 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id m9so8937449iok.7 for ; Sun, 05 May 2019 05:56:08 -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=CXjHTs4qQuv6qOYdU7QGjJvSUO0BhruYSRx4vJqGD64=; b=pY6LaQkvG9VtbBnUPUuHYQoLtvq1MKigCgi/I/ZyXoZqL0Y7OeVzqlHNp9Sw57NspV yzem0DhJOsLRTZhdQQeHxruNJ9nritRlzsIQBumD5aUc7oxN3ZP0Ems75rlmQq9nwKRn 0svCPi1w3AQENieHey7HqaGyptBW54+5lkZlk= 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=CXjHTs4qQuv6qOYdU7QGjJvSUO0BhruYSRx4vJqGD64=; b=LObHD44uQZW4zSzuQ5URzylHwlKChP41Ae/p5RsrEnphHmaMaDdG1nVd4Dgwc8n5Sb WfINb3HUqUQsQzo5x7Jilxg21Wi0JK7QxvHzelJwiG1uD4iu2n4wjbc3/rx4ab2s0j7o xaolvXcd6c5OMCh/Q/me+nzkmifDaWl+f0VIHY7/sEmB/80ITgEmTAV7nt5V9L8bW1+B d7WyKkOnMwAhmCVDnpln3OLI4sfayi3bLL+CvTpRw4rhhR6CFNPKjzN3+Sn6XA+MfSyA Fj51YBSlnh9h5PzYnSRAzoYflZuPiA2tLp8ASaIRhMi1qvN9YuFNdRYqJ6UX2pSX+cWX UmrA== X-Gm-Message-State: APjAAAVE4B2Yb3RJKD8aUckmnbcF5b9hWgOtoN/0oAZnfiPUjDYDh/eX J/4gfHuBm0z/IQUfNJIXpmZECpE4hSIGJOvTp/b9EKglAf1sljbdzV5HAEGjI9b+SsVGCbB89bY YXzSL8spu2GCaUw== X-Google-Smtp-Source: APXvYqxgy793e72X/Kyb3h1rKwuoNfqr01mfbuZGXfIrL0Lm749J1N359po+qBce9osyUlcaLK9JwGviVrc5RM2BqaI= X-Received: by 2002:a5d:948d:: with SMTP id v13mr14108262ioj.59.1557060968159; Sun, 05 May 2019 05:56:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Sun, 5 May 2019 06:55:41 -0600 Message-ID: To: Paul Querna Cc: oauth Content-Type: multipart/alternative; boundary="000000000000e6b5e10588238160" Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback 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, 05 May 2019 12:56:13 -0000 --000000000000e6b5e10588238160 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2019 at 12:33 AM Paul Querna wrote: > Overall the spec felt functional, though I think the biggest gaps for > a deployment are with the Access Token interactions, but this makes > sense since that seems to be addressed in the future by > > This DPoP document should aspire to provide sufficient info on access token interactions so as not to have any dependency on draft-ietf-oauth-access-token-jwt. And I sorta doubt that PoP style tokens will be in scope for draft-ietf-oauth-access-token-jwt at all. Sections 6[a] and 8[b] of DPoP aim to define access token usage. Is there specific content that you feel is missing in the draft? [a] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6 [b] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-8 > Is there a use case for this being present in the DPoP-Proof JWT? As > I've implemented DPoP, I didn't see how it was helpful to be sent as a > `cnf` claim of the Proof? > As David alluded to in his reply yesterday, this is an area that is likely to see some changes in the next revision of the draft - like doing away with the distinction between binding and proof, moving the proof key out of the JWT and less inappropriate use of the `cnf` claim. But in the -01 draft the key is included with the access token via the `cnf` claim and you're right that it's not particularly helpful to have it also sent with the Proof. > Request Headers vs Parameters > > 5. Token Request (Binding Tokens to a Public Key) > > Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is > different than most other OAuth extensions that I am familiar with. > It is easy in the Go OAuth2 library to add URL / /body params to the > `/token` endpoint, but it is impossible to add an HTTP Header. Is > there a reason that the binding can't be sent as an OAuth Parameter in > the token request body? > Also as David alluded to in his reply yesterday, there's a goal to have the proof mechanism be the same for accessing the token endpoint as when accessing resources. And using application/x-www-form-urlencoded parameters for resource access is problematic for a litany of reasons. HTTP Request signing may be a quagmire that this spec wishes to avoid, > Very much so, yes. [snip] I'm not sure where the spec-author team wants to take this area, but > am interested in providing feedback. > Somehow cleanly allowing for it by extension would be nice from the perspective of this document. But full treatment of HTTP signing is explicitly a non-goal of the DPoP draft with the intent that it have only a minimal set of stuff that's signed so as to facilitate the proof-of-possession. JWT as AT > > 7. IANA Considerations > > > > [[TODO: MIME type registration for at+jwt ]] > > Assume this will eventually be done via > > That's already where it is, no? Thank you for the work so far, and I'm happy to provide further > feedback as the spec evolves. > Thanks Paul, it's just a -01 version of an individual draft at this point (with all the authority thereby bestowed on it ) but your participation would certainly be appreciated as the spec evolves and if it's something the working group decides to pick up as a working group item. --=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._ --000000000000e6b5e10588238160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 2, 2019 at 12:33 AM Paul Querna <pquerna@apache.org> wr= ote:
Overall the spec felt functional, though I think the biggest gaps for
a deployment are with the Access Token interactions, but this makes
sense since that seems to be addressed in the future by
<https://tools.ietf.org/html/draf= t-ietf-oauth-access-token-jwt-00>

This DPoP document should aspire to provide sufficient info on access tok= en interactions so as not to have any dependency on draft-ietf-oauth-access= -token-jwt. And I sorta doubt that PoP style tokens will be in scope for dr= aft-ietf-oauth-access-token-jwt at all.

Secti= ons 6[a] and 8[b] of DPoP aim to define access token usage. Is there specif= ic content that you feel is missing in the draft?

<= div>[a] https://tools.ietf.org/html/draft-fett-oauth-dpop= -01#section-6

=C2=A0
Is there a use case for this being present in the DPoP-Proof JWT?=C2=A0 As<= br> I've implemented DPoP, I didn't see how it was helpful to be sent a= s a
`cnf` claim of the Proof?

As David allu= ded to in his reply yesterday, this is an area that is likely to see some c= hanges in the next revision of the draft - like doing away with the distinc= tion between binding and proof, moving the proof key out of the JWT and les= s inappropriate use of the `cnf` claim.

But i= n the -01 draft the key is included with the access token via the `cnf` cla= im and you're right that it's not particularly helpful to have it a= lso sent with the Proof.

=C2=A0
Request Headers vs Parameters
> 5.=C2=A0 Token Request (Binding Tokens to a Public Key)

Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is
different than most other OAuth extensions that I am familiar with.
It is easy in the Go OAuth2 library to add URL / /body params to the
`/token` endpoint, but it is impossible to add an HTTP Header.=C2=A0 Is
there a reason that the binding can't be sent as an OAuth Parameter in<= br> the token request body?

Also as David a= lluded to in his reply yesterday, there's a goal to have the proof mech= anism be the same=20 for accessing the token endpoint as when accessing resources. And using app= lication/x-www-form-urlencoded parameters for resource access is problemati= c for a litany of reasons.

=C2=A0
HTTP Request signing may be a quagmire that this spec wishes to avoid,
<= /blockquote>

Very much so, yes.


[snip] I'm not sure where the spec-author team wants to take this area,= but
am interested in providing feedback.

So= mehow cleanly allowing for it by extension would be nice from the perspecti= ve of this document. But full treatment of HTTP signing is explicitly a non= -goal of the DPoP draft with the intent that it have only a minimal set of = stuff that's signed so as to facilitate the proof-of-possession.
=C2=A0

JWT as AT
>=C2=A0 7.=C2=A0 IANA Considerations
>
>=C2=A0 =C2=A0 [[TODO: MIME type registration for at+jwt ]]

Assume this will eventually be done via
<https://tools.ietf.org/html/draf= t-ietf-oauth-access-token-jwt-00>

That's already where it is, no?
=C2=A0


Thank you for the work so far, and I'm happy to provide further
feedback as the spec evolves.

Thanks Pa= ul, it's just a -01 version of an individual draft at this point (with = all the authority thereby bestowed on it) but your participat= ion would certainly be appreciated as the spec evolves and if it's some= thing the working group decides to pick up as a working group item.

=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. --000000000000e6b5e10588238160-- From nobody Sun May 5 06:55: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 D1FDD120074 for ; Sun, 5 May 2019 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5EGYRqy2qIL for ; Sun, 5 May 2019 06:55:16 -0700 (PDT) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 DA868120019 for ; Sun, 5 May 2019 06:55:15 -0700 (PDT) Received: by mail-it1-x143.google.com with SMTP id r85so16171714itc.2 for ; Sun, 05 May 2019 06:55:15 -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=pMBKLQwdaQej7wGj/hYv4TjQz5GBgapIt4MTgcstWSs=; b=b1YcdfdIc0OCc8y6yR0rA75t/Jq6r0HwTHIJS7gpwBdcsvI8dMkYgGRnMzFpTQpbp+ xo3ymk1afTf6zZo/qb7zO5oCfa8K+BF+w0W2QRI5vdwbzr1yw6IGmgUTksSQo6G5P866 XL8PN0EsMnSms7TVbyNB+k/lMJYOHci5J9NXk= 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=pMBKLQwdaQej7wGj/hYv4TjQz5GBgapIt4MTgcstWSs=; b=M16UYsnNQy2LrcSKmlJpdiQ8nCmtACCKHRZlPT+4fzCos7D6g5szvEMHc/PzOgAWAm XzYncGbxuF0UUv4Bi+pG8k6xTJtvVghsezvwUpdXV7V/VJaIk0iGnSffJ2upR6mbnYC9 4GyvsNlXGc3hVKMy0eAWOux3QwonH3q3eZocpCABKOro7MVnOyR03lxSFcCsznKTFiA6 yROCze251fCVqqEoJxyZ6MemgHEXIoh/5Opj+lLtnUJQKgF9LG756PetcVln1mes62tz o67iofztjd8ntgJcFNKFQVVOi4Mp0o1YgueoxA+67iDqaSgMy+u3S20zqB+zUw18dvUN 7vNg== X-Gm-Message-State: APjAAAW5aBZRk82MzDPGfFGtIJ1Ms0bGMdQ8EBWPYDlaLtiLhMR8mnxE ESdjuNKRWuaJscoeBlK0zGs3LQy/pi+Xe3Ty6/rX2WGR6JVoHg8l/UIVKArKv6Oy9kNgpBUY8QZ /J/v01m6EKnqkIw== X-Google-Smtp-Source: APXvYqx/s+WHgeg229eGKDiP+Agj4bTfwxpGfQKo4xJkjFvRobR2NEeCHmrPdCkMeQ2UikjMcfjQ/28WkdYvgspu5RY= X-Received: by 2002:a02:6411:: with SMTP id t17mr15251555jac.90.1557064515026; Sun, 05 May 2019 06:55:15 -0700 (PDT) MIME-Version: 1.0 References: <4223569.5sG2vptK2V@papegaaij> In-Reply-To: <4223569.5sG2vptK2V@papegaaij> From: Brian Campbell Date: Sun, 5 May 2019 07:54:48 -0600 Message-ID: To: Emond Papegaaij Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004fa95c05882455c3" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange status and Resource Indicators 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, 05 May 2019 13:55:18 -0000 --0000000000004fa95c05882455c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij wrote: > [...] we are investigating 'OAuth 2.0 > Token Exchange'. [...] However, I noticed that > draft 16 has expired on April 22, 2019. Is this specification still activ= e? > Yeah, it is. A nontrivial amount of stuff came up in IESG balloting on the document https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/ and I have not been able to find the time to make all the necessary changes. Also, resulting from that IESG balloting there was the need to request early IANA registrations of some things, which is a whole ordeal unto itself with timelines I cannot seem to affect much even when I have the time to try. So it's active but just hung up for a moment at the moment. > > To summarize, I have to following questions: > - Is the 'OAuth 2.0 Token Exchange' specification still active? > Yes with the caveats mentioned above. I will say that although there's a lot of work required for the document, none of it is likely to result in functional changes so I don't anticipate anything breaking at this point. - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? > No, that's beyond it's current scope. And it is well past last call in the WG. But note that a logical identifier can be used as the value of the resource parameter. - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource > Indicators > for OAuth 2.0' rather than redefining the same parameters? > Not really as a matter of timing and process. But the resource parameter will ultimately be consistent across the two. --=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._ --0000000000004fa95c05882455c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 3, 2019 at 9:39= AM Emond Papegaaij <emond.= papegaaij@gmail.com> wrote:
[...] we are investigating 'OAuth 2.0
Token Exchange'. [...] However, I noticed that
draft 16 has expired on April 22, 2019. Is this specification still active?=

Yeah, it is. A nontrivial amount of st= uff came up in IESG balloting on the document https://datatracker= .ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/ and I have not be= en able to find the time to make all the necessary changes. Also, resulting= from that IESG balloting there was the need to request early IANA registra= tions of some things, which is a whole ordeal unto itself with timelines I = cannot seem to affect much even when I have the time to try. So it's ac= tive but just hung up for a=C2=A0moment at the moment.
=C2= =A0

To summarize, I have to following questions:
=C2=A0- Is the 'OAuth 2.0 Token Exchange' specification still activ= e?

Yes with the caveats mentioned above= . I will say that although there's a lot of work required for the docum= ent, none of it is likely to result in functional changes so I don't an= ticipate anything breaking at this point.
=C2=A0
<= br>
=C2=A0- Can 'audience' be added to 'Resource Indicators for OAu= th 2.0'?

No, that's beyond it&#= 39;s current scope. And it is well past last call in the WG. But note that = a logical identifier can be used as the value of the resource parameter.
=C2=A0

=C2=A0- Can 'OAuth 2.0 Token Exchange' be updated to build on '= Resource Indicators
for OAuth 2.0' rather than redefining the same parameters?

Not really as a matter of timing and process. But t= he resource parameter will ultimately be consistent across the two.=C2=A0 <= br>

=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. --0000000000004fa95c05882455c3-- From nobody Mon May 6 10:32: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 997BC1201CC for ; Mon, 6 May 2019 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_Vr2pz_UvTp for ; Mon, 6 May 2019 10:32:45 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8FB120049 for ; Mon, 6 May 2019 10:32:44 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id y10so5296145lji.9 for ; Mon, 06 May 2019 10:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=slXO2ou7bdLy3kvNoNQBsDDNEs/R4V5DKntY+6EXPlg=; b=RiqMFiKN6PKOLymn2WBri8gUOAPsKmTqM2uUe5N0xfKfaIqXZSG6PyM4cdNgvAyPRp ls9Vi6jtIADBflzaDubhJ0XP/kM5RMi2fvm1+PSyxOhqh07o+BSaGzl7/Wra/nj/23hB jcfxCcqTd/My14fPGGP6N/3c1KYWjgMYIRpZcSDh2vaxQCIKMkYbGDPJD+ozR2n6powy D14/LknPS48e/91jlfhXKIJnS7QeExPwWCW/TUqqrR+vsh60vpKPo3EFJrOwS49MDDnp 4ZUhXRS1GQS5QC9JkbQMJARuKOYpRGhhhhN2lpTudSHYk7boAILCH16vryzG0KbFs1ud ngRw== 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=slXO2ou7bdLy3kvNoNQBsDDNEs/R4V5DKntY+6EXPlg=; b=jrca4OTjW2DzCkvsX4vb1SLsEkm/ZlFKNsfBMmUcvfmgwJEB/PXJmxTptpd3/cEynw 3lkJyVLk8agWXYsizCK/JBtsSqFX6dORMRtWHiKLr8g03NiLJOVm6EMwLZWZNwrn+sz1 +PqHRDkoBEEjMKJaN9JTwEm8Pkp95ka+A73KOnwe4C18zh7qbRA3qaEVDuqqfuyT/zMp 3IayUdDhAklkx9HBxHsKrbuzRyAccg/5+3aOVopw/YnEg2fX8n20v5AfVguC9zYtUCJO S24//OV5oZbQtGiDUz3nGIBdnObb+H+4Sl+abZvOCu2/tkimsv0Qg1VA6Q8hsDfjDqEn P2lw== X-Gm-Message-State: APjAAAWDq3qr4hhTZARw/e9MH12MFDVkF2HAnLZGHhoB8IxSafjKU5oV uSLjlJMl3jqIJ6/Tq/pw1Vv0dRpDuiR4oiw2HjZ1lQ== X-Google-Smtp-Source: APXvYqzz6tPHqDUX6uzNP7iq23dvwVq0y1oYWEN9hSAWZlcjg+zUP4L8wbmEYKg+l61aDZGoSNQeWsGY65BrAREIE0Q= X-Received: by 2002:a2e:8794:: with SMTP id n20mr15144423lji.76.1557163962751; Mon, 06 May 2019 10:32:42 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 6 May 2019 10:32:31 -0700 Message-ID: To: Hans Zandbelt , Karl McGuinness , John Bradley Cc: Mike Jones , George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000db735305883b7c98" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 17:32:50 -0000 --000000000000db735305883b7c98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, thanks for your patience during this month long hiatus, and thanks for the comments. Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended). - It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that. - That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, *Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect*. I find the proposal very clever, and the people at IIW thought so as well. What you think? Note, *John Bradley* observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence. On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt wrote: > I also meant to say that (of course) the JWT standard doesn't say that th= e > JWT is supposed to be about the client or about the resource owner, hence > both are valid > > Hans. > > On Thu, Apr 4, 2019 at 10:09 PM Mike Jones > wrote: > >> I get that existing practice is likely to be all over the map, but if >> we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reason= able to require >> that the claims usage comply with the JWT standards. >> >> >> >> -- Mike >> >> >> >> *From:* Hans Zandbelt >> *Sent:* Thursday, April 4, 2019 12:59 PM >> *To:* Mike Jones >> *Cc:* George Fletcher > <40aol.com@dmarc..ietf.org>>; Vittorio Bertocci > 40auth0.com@dmarc.ietf.org>; IETF oauth WG >> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >> >> >> >> the definition of RFC 7519 is actually "petitio principii" and a lot of >> deployments put claims about the Resource Owner in the access token (as = a >> Resource Server implementer I've suffered a lot from this) >> >> >> >> Hans. >> >> >> >> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones >> wrote: >> >> I agree with George that the subject of a token must be the principal of >> that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. Inde= ed, the first >> sentence of the =E2=80=9Csub=E2=80=9D definition at >> https://tools.ietf.org/html/rfc7519#section-4.1.2 is: >> >> The "sub" (subject) claim identifies the principal that is the subject o= f >> the JWT. >> >> >> >> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply wit= h the definition >> from RFC 7519. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *George Fletcher >> *Sent:* Thursday, April 4, 2019 8:51 AM >> *To:* Hans Zandbelt >> *Cc:* Vittorio Bertocci ; IETF >> oauth WG >> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >> >> >> >> The more I think about this the more I land in the "No" camp. >> >> The subject of a token should be the principal of that token. It >> shouldn't matter whether that is a machine, a user, or a device. Trying = to >> separate out "humans" as a special class will just make things more >> complicated. If we need a claim to identify the subject is a "human" the= n >> why not just add that. This doesn't break anything and makes it easy for >> people to detect this case in those use cases where it's required. >> >> Thanks, >> George >> >> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >> >> I will argue that in a way such deployments are already broken e.g. in >> the typical use case of onboarding client accounts in the same >> directory/OU/namespace as user accounts and we don't need to cater for >> that. >> >> >> >> Hans. >> >> >> >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher wrote= : >> >> I agree that this will break a lot of existing flows... especially those >> using any form of the client_credentials flow. In that sense I'm not >> completely on board yet :) >> >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >> >> great summary! this will hurt quite a few existing m2m deployments but I >> do like the rigidness of it all: it is very explicit, cannot misinterpre= ted >> and thus prevents failure (which is really what Dominick is after); I'm = on >> board >> >> >> >> Hans. >> >> >> >> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote: >> >> thank you Steinar and everyone else for the comments on this! >> >> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >> Bertrand recommend using sub only for users. Martin would like to have t= he >> sub for app only flows as well. Hans is neutral. >> >> That does sound like the sub as user has more consensus, tho before >> changing it I'd wait for the people currently at IETF104 to have more ti= me >> to comment as well. >> >> Clarification. If the goal is to be able to apply the logic "if there's = a >> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the us= e >> of sub when that's not the case. Are all OK with it? >> >> >> >> Dave, the suggestion of having explicit typing for app only vs user only >> is interesting! For the purpose of putting together an interoperable >> profile, tho, I would suggest we table it for v1 in the interest of gett= ing >> to something easy to adopt (hence with small delta vs existing >> implementations) faster. >> >> >> >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: >> >> Hi Vittorio, we (the national federation-gateway for the health service= s >> in norway - "HelseID") think his is a really valuable initiative! >> >> We also agree with Dominick concerning definition of the "sub" claim. >> >> >> >> Steinar >> >> >> >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >> dbaier@leastprivilege.com>: >> >> From an access token consumer (aka API) developer point of view, I prefe= r >> this logic >> >> >> >> "If sub is present - client acts on behalf of a user, if not - not." >> >> >> >> Anything more complicated has a potential of going wrong. >> >> >> >> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> >> >> Yeah, I=E2=80=99m concerning user & client ids collision. >> >> I haven=E2=80=99t seen such implementations, but user-select username as= sub, or >> incremental integer as sub & client_id will be easily collide. >> >> >> >> If you can enforce collision resistant IDs between user & client >> instances, it=E2=80=99ll works fine. I feel its overkill though. >> >> >> >> Sent from my iPhone >> >> >> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >> >> Hey Nov, Dominick, Hans- >> >> thanks for the comments. That was an area I was expecting to cause more >> discussion, and I am glad we are having this opportunity to clarify. >> >> The current language in the draft traces the etymology of sub to OpenID >> Connect core, hence Dominick observation is on point. However in the >> description I express something in line with 7519, which was in fact my >> intent. >> >> >> >> The idea was to provide an identifier of the calling subject that is >> guaranteed to be present in all cases- this would allow an SDK developer= to >> use the same code for things like lookups and membership checks regardle= ss >> of the nature of the caller (user in a delegated case, app in app-only >> grants). The information to discriminate between user and app callers is >> always available in the token (say, the caller is a user if sub!=3Dclien= t_id, >> where client_id is always guaranteed to be present as well) hence there'= s >> no loss in expressive power, should that difference be relevant for the >> resource server. >> >> >> >> Dominick, Hans- I probably missed the security issue you guys are >> thinking of in this case. Of course, if this would introduce a risk I >> completely agree it should be changed- I'd just like to understand bette= r >> the problem. Could you expand it in a scenario/use case to clarify the r= isk? >> >> Nov- playing this back: is the concern that a user and a client might >> have the same identifier within an IDP? When using collision resistant I= Ds, >> as it is usually the case, that seems to be a remote possibility- did yo= u >> stumble in such scenario in production? >> >> >> >> Thanks >> >> V. >> >> >> >> >> >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt >> wrote: >> >> I believe there are plenty of OAuth 2.0 only use cases out there... but >> nevertheless I agree with the potential confusion and thus security >> problems arising from that (though one may argue the semantics are the >> same). >> >> >> >> Hans. >> >> >> >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier >> wrote: >> >> Yes I know - and I think in hindsight it was a mistake to use the same >> claim type for multiple semantics. >> >> >> >> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making th= ings more >> complicated than they need to be - in my experience almost no-one (that = I >> know) does OIDC only - nor OAuth only. They always combine it. >> >> >> >> In reality this leads to potential security problems - this spec has the >> potential to rectify the situation. >> >> >> >> Dominick >> >> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu= ) >> wrote: >> >> Without agreeing or disagreeing: OIDC does not apply here since it is no= t >> OAuth and an access token is not an id_token. >> >> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >> >> >> >> "The "sub" (subject) claim identifies the principal that is the >> >> subject of the JWT. The claims in a JWT are normally statements >> >> about the subject. The subject value MUST either be scoped to be >> >> locally unique in the context of the issuer or be globally unique. >> >> The processing of this claim is generally application specific" >> >> >> >> which kind of spells "client" in case of the client credentials grant bu= t >> I also do worry about Resource Servers thinking/acting only in terms of >> users >> >> >> >> Hans. >> >> >> >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier >> wrote: >> >> IMHO the sub claim should always refer to the user - and nothing else. >> >> >> >> OIDC says: >> >> >> >> "Subject - Identifier for the End-User at the Issuer." >> >> >> >> client_id should be used to identify clients. >> >> >> >> cheers >> >> Dominick >> >> >> >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> >> >> Thanks for the good starting point of standardizing JWT-ized AT. >> >> >> >> One feedback. >> >> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-u= ser and client, >> in this spec. >> >> It requires those 2 types of identifiers to be unique each other in the >> IdP context. >> >> >> >> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so th= at no such >> constraint needed. >> >> >> >> thanks >> >> >> >> nov >> >> >> >> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >> >> >> >> Dear all, >> >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions! >> ). >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> >> V. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> >> hans.zandbelt@zmartzone.eu >> >> ZmartZone IAM - www.zmartzone.eu >> >> >> >> >> -- >> >> hans.zandbelt@zmartzone.eu >> >> ZmartZone IAM - www.zmartzone.eu >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> >> hans.zandbelt@zmartzone.eu >> >> ZmartZone IAM - www.zmartzone.eu >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> -- >> >> hans.zandbelt@zmartzone.eu >> >> ZmartZone IAM - www.zmartzone.eu >> >> >> >> >> >> >> -- >> >> hans.zandbelt@zmartzone.eu >> >> ZmartZone IAM - www.zmartzone.eu >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --000000000000db735305883b7c98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
thanks for your patience during this month lon= g hiatus, and thanks for the comments.
Last week at IIW I had the= opportunity to discuss this with many of the people on the list. Here'= s a summary of where the discussion landaed on the subject of the sub (pun = intended).

- It seems that RFC 7519 has pretty cle= ar language on the use of sub- I didn't check it back when we started t= he discussion. I do agree with the people saying that we shouldn't viol= ate existing specifications, hence it looks like we do need to have sub als= o in the case in which we have app-only tokens carrying claims about the ap= p itself. I understand this will cause some implementation to break, but un= fortunately that's intrinsic in the process of coming up with a common = approach and standards compliance is probably one of the strongest reasons = to tolerate that.
- That said, I am strongly committed to preserv= e existing functionality. One of the main reasons that was brought up for i= ncluding sub only for user based ATs was to use it as heuristic for telling= those tokens apart from app-only ones. To that end, Karl MCGuinness<= /b> suggested that we include grant_type as a return claim, which the RS co= uld use to the same effect. I find the proposal very clever, and the pe= ople at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous results if an ex= tension grant is used (say an assertion profile) but that seems like a rela= tively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt= <hans.zandbelt@zmartzone.= eu> wrote:
I also meant to say that (of course) the JWT standard do= esn't say that the JWT is supposed to be about the client or about the = resource owner, hence both are valid

Hans.
On Thu, = Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
=

I get that existi= ng practice is likely to be all over the map, but if we=E2=80=99re to creat= e a JWT access token standard, it=E2=80=99s reasonable to require that the = claims usage comply with the JWT standards.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= /u>

=C2=A0<= /u>

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu&g= t;
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Be= rtocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

the definition of RFC 7519 is actually "petitio= principii" and a lot of deployments put claims about the Resource Own= er in the access token (as a Resource Server implementer I've suffered = a lot from this)

=C2=A0

Hans.

=C2=A0

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

I agree with Geor= ge that the subject of a token must be the principal of that token.=C2=A0 T= hat what the JWT =E2=80=9Csub=E2=80=9D claim is for.=C2=A0 Indeed, the firs= t sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:<= /u>

The "sub" (= subject) claim identifies the principal that is the subject of the JWT.

=C2=A0<= /u>

If an access toke= n uses =E2=80=9Csub=E2=80=9D, its usage must comply with the definition fro= m RFC 7519.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF o= auth WG <oauth@ietf.= org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

The more I think about this the more I land in th= e "No" camp.

The subject of a token should be the principal of that token. It shouldn= 9;t matter whether that is a machine, a user, or a device. Trying to separa= te out "humans" as a special class will just make things more com= plicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break = anything and makes it easy for people to detect this case in those use case= s where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:

I will argue that in a way such deployments are alre= ady broken e.g. in the typical use case of onboarding client accounts in th= e same directory/OU/namespace as user accounts and we don't need to cater for that.

=C2=A0

Hans.

=C2=A0

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <= gffletch@aol.com&= gt; wrote:

I agree that this will break a lot of existing fl= ows... especially those using any form of the client_credentials flow. In t= hat sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:<= /u>

great summary! this will hurt quite a few existing m= 2m deployments but I do like the rigidness of it all: it is very explicit, = cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

=C2=A0

Hans.

=C2=A0

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci &l= t;Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone else for the comments= on this!

To summarize the situation so far: Dominick, Steinar= , Rob, David, Nov, Bertrand recommend using sub only for users. Martin woul= d like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more consen= sus, tho before changing it I'd wait for the people currently at IETF10= 4 to have more time to comment as well.

Clarification. If the goal is to be able to apply th= e logic "if there's a sub, it's a user flow", we have to = explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

=C2=A0

Dave, the suggestion of having explicit typing for a= pp only vs user only is interesting! For the purpose of putting together an= interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence wit= h small delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0

=C2=A0

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no>= wrote:

Hi Vittorio, we=C2=A0 (the national federation-gatew= ay for the health services in norway - "HelseID")=C2=A0 think his= is a really valuable initiative!

We also agree with Dominick concerning definition of= the "sub" claim.

=C2=A0

<mvh>Steinar</mvh>

=C2=A0

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier &l= t;dbaier@lea= stprivilege.com>:

From an access token consumer (aka API) developer point of view= , I prefer this logic

=C2=A0

"If sub is present - client acts on behalf of a user, if n= ot - not."

=C2=A0

Anything more complicated has a potential of going wrong.

=C2=A0

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Yeah, I=E2=80=99m concerning user & client ids c= ollision.

I haven=E2=80=99t seen such implementations, but use= r-select username as sub, or incremental integer as sub & client_id wil= l be easily collide.

=C2=A0

If you can enforce collision resistant IDs between u= ser & client instances, it=E2=80=99ll works fine. I feel its overkill t= hough.

=C2=A0

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was expe= cting to cause more discussion, and I am glad we are having this opportunit= y to clarify.

The current language in the draft traces the etymolo= gy of sub to OpenID Connect core, hence Dominick observation is on point. H= owever in the description I express something in line with 7519, which was in fact my intent.

=C2=A0

The idea was to provide an identifier of the calling= subject that is guaranteed to be present in all cases- this would allow an= SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user= in a delegated case, app in app-only grants). The information to discrimin= ate between user and app callers is always available in the token (say, the= caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there= 9;s no loss in expressive power, should that difference be relevant for the= resource server.

=C2=A0

Dominick, Hans- I probably missed the security issue= you guys are thinking of in this case. Of course, if this would introduce = a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scena= rio/use case to clarify the risk?

Nov- playing this back: is the concern that a user a= nd a client might have the same identifier within an IDP? When using collis= ion resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in prod= uction?

=C2=A0

Thanks

V.=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt= @zmartzone.eu> wrote:

I believe there are plenty of OAuth 2.0 only use cas= es out there... but nevertheless I agree with the potential confusion and t= hus security problems arising from that (though one may argue the semantics are the same).

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <<= a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp= rivilege.com> wrote:

Yes I know - and I think in hindsight it was a mistake to use t= he same claim type for multiple semantics.

=C2=A0

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are = making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always c= ombine it.

=C2=A0

In reality this leads to potential security problems - this spe= c has the potential to rectify the situation.

=C2=A0

Dominick<= /p>

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not apply= here since it is not OAuth and an access token is not an id_token.<= u>

=C2=A0

"The "sub" (subject) claim identifies= the principal that is the

=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in= a JWT are normally statements

=C2=A0 =C2=A0about the subject.=C2=A0 The subject va= lue MUST either be scoped to be

=C2=A0 =C2=A0locally unique in the context of the is= suer or be globally unique.

=C2=A0 =C2=A0The processing of this claim is general= ly application specific"

=C2=A0

which kind of spells "client" in case of t= he client credentials grant but I also do worry about Resource Servers thin= king/acting only in terms of users

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <<= a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp= rivilege.com> wrote:

IMHO the sub claim should always refer to the user - and nothin= g else.

=C2=A0

OIDC says:

=C2=A0

"Subject - Identifier for the End-User at the Issuer."

=C2=A0

client_id should be used to identify clients.=

=C2=A0

cheers

Dominick

=C2=A0

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Thanks for the good starting point of standardizing = JWT-ized AT.

=C2=A0

One feedback.

The =E2=80=9Csub=E2=80=9D claim can include 2 types = of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be uniqu= e each other in the IdP context.

=C2=A0

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-l= egged context, so that no such constraint needed.

=C2=A0

thanks

=C2=A0

nov

=C2=A0

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

=C2=A0

Dear all,

I just submitted a draft describing a JWT profile fo= r OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/<= /a>.

I have a slot to discuss this tomorrow at IETF 104 (= I'll be presenting remotely). I look forward for your comments!<= u>

=C2=A0

Here's just a bit of backstory, in case you are = interested in how this doc came to be. The trajectory it followed is somewh= at unusual.

I was blown away by the availability, involvement an= d willingness to invest time to get things right that everyone demonstrated= in the process. This is an amazing community.=C2=A0

V.

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

=C2=A0

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

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


=C2=A0

--

ZmartZone IAM - www.zmartzone.eu<= /span>


=C2=A0

--

ZmartZone IAM - www.zmartzone.eu<= /span>

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


=C2=A0

--

Vennlig hilsen

=C2=A0<= /u>

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=A0= www.udelt.no=C2=A0|=C2=A0

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


=C2=A0

--

ZmartZone IAM - www.zmartzone.eu<= /span>

=C2=A0 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


=C2=A0

--

ZmartZone IAM - www.zmartzone.eu<= /span>

=C2=A0


=C2=A0

--



--
--000000000000db735305883b7c98-- From nobody Mon May 6 10:38:46 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 34080120047 for ; Mon, 6 May 2019 10:38:45 -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 4cZACQHoJGvn for ; Mon, 6 May 2019 10:38:43 -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 D9C46120111 for ; Mon, 6 May 2019 10:38:42 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x46Hcaxp005290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 13:38:38 -0400 Date: Mon, 6 May 2019 12:38:36 -0500 From: Benjamin Kaduk To: Evert Pot Cc: oauth@ietf.org Message-ID: <20190506173836.GM19509@kduck.mit.edu> References: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Link relations for authenticating 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, 06 May 2019 17:38:45 -0000 Hi Evert, On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote: > Hi everyone! > > I've been running into a number of situations where it would have been > beneficial to have a few protocol/media-type agnositic link relation > types for user authentication purposes. > > https://tools.ietf.org/html/draft-pot-authentication-link > > Nothing here is coupled to OAuth, but the link relations could > potentially be used with OAuth2 servers. > > I don't exactly know the IETF process, but I thought it would be a good > idea to ask for feedback here. My understanding is that either I should > find an appropriate WG that's willing to adopt it, or I could do an > individual submission. I'm not entirely sure yet which would be the most > appropriate WG to ask, so I thought I'd start here. You may want to ask for feedback on art@ietf.org (https://www.ietf.org/mailman/listinfo/art) as well -- there are several folks there that have deep expertise in link relations and could advise on what these proposals might (or might not) be suitable for. There are a few other security-area WGs (than OAuth) that work in authentication (though maybe not as directly in the HTTP world), so once you get some ART feedback it may be worth raising the issue on the secdispatch mailing list as well (https://datatracker.ietf.org/wg/secdispatch/about/). Thanks, Ben From nobody Mon May 6 11:23: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 37B4612004E for ; Mon, 6 May 2019 11:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=ZDpvOYKH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DKG/RzW5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trLASybkzv_x for ; Mon, 6 May 2019 11:22:58 -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 B028F120047 for ; Mon, 6 May 2019 11:22:58 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2658A422; Mon, 6 May 2019 14:22:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 06 May 2019 14:22:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=zr7eNHJVGsQmlLUfGjdNK4uIOYWNacZCAKNE8eO0rl4=; b=ZDpvOYKHxWez /fz9l25e+sG7eSBps3JUsWj5ivtYhKyl/ovDu/CODvCjoG6A8TOWQGplhevS1KVd IMmKBU6RwIeXF/pwWIJa6XN7JU4NPMn/xWMS4XirTvmAquayW7ZHNHhPzh4PcatO QCE2H1NS5vgZLRqZJgzciHmSKOxMj6A= 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=fm2; bh=zr7eNHJVGsQmlLUfGjdNK4uIOYWNacZCAKNE8eO0r l4=; b=DKG/RzW5H8FdrpnbQZst2W4r0w0wIzliaofBsHHFq07RsEL8lvf+nzDSs xdyO7XsrYlh9T0KRUMzXj9UtpPJtnCyLBjZ2+wVoMn4lnyxZgLjYe5oSJixeHQpk NrD89Svg5h0vSY59D6QK6qfZQSoFAE1BxggW/jF5TvSdbD6F/urDjYTWkNpU4QCV c+62rLpBFtS0U4SDM64Qu9aihTe9q1T49VD+dynpsSdOU0GT3bOwCgTysBr7kDft y5gPGL4q9zJiWw8R3PzyztQUGpIXERA5PX7sMj+LdQ56/1FjkuAP3j/fT7ivC7da Jyu5okYzZi75gOik14tN7jSJ72SPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeekgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefgvhgvrhht ucfrohhtuceomhgvsegvvhgvrhhtphhothdrtghomheqnecuffhomhgrihhnpehivghtfh drohhrghenucfkphepudeiiedrudejvddrieefrddvgeelnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.43.31] (mobile-166-172-63-249.mycingular.net [166.172.63.249]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D3FFE4625; Mon, 6 May 2019 14:22:51 -0400 (EDT) To: Benjamin Kaduk Cc: oauth@ietf.org References: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> <20190506173836.GM19509@kduck.mit.edu> From: Evert Pot Openpgp: preference=signencrypt Autocrypt: addr=me@evertpot.com; keydata= mQINBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAlQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFbkCDQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAYkCPAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA Message-ID: <02c511d5-732b-89d1-c142-acca22dbd4a3@evertpot.com> Date: Mon, 6 May 2019 14:22:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190506173836.GM19509@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Link relations for authenticating 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, 06 May 2019 18:23:00 -0000 Hi Benjamin, Thanks for the hint. Will give that a shot! Evert On 2019-05-06 1:38 p.m., Benjamin Kaduk wrote: > Hi Evert, > > On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote: >> Hi everyone! >> >> I've been running into a number of situations where it would have been >> beneficial to have a few protocol/media-type agnositic link relation >> types for user authentication purposes. >> >> https://tools.ietf.org/html/draft-pot-authentication-link >> >> Nothing here is coupled to OAuth, but the link relations could >> potentially be used with OAuth2 servers. >> >> I don't exactly know the IETF process, but I thought it would be a good >> idea to ask for feedback here. My understanding is that either I should >> find an appropriate WG that's willing to adopt it, or I could do an >> individual submission. I'm not entirely sure yet which would be the most >> appropriate WG to ask, so I thought I'd start here. > You may want to ask for feedback on art@ietf.org > (https://www.ietf.org/mailman/listinfo/art) as well -- there are several > folks there that have deep expertise in link relations and could advise on > what these proposals might (or might not) be suitable for. > > There are a few other security-area WGs (than OAuth) that work in > authentication (though maybe not as directly in the HTTP world), so once > you get some ART feedback it may be worth raising the issue on the > secdispatch mailing list as well > (https://datatracker.ietf.org/wg/secdispatch/about/). > > Thanks, > > Ben From nobody Mon May 6 11:36: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 F0611120236 for ; Mon, 6 May 2019 11:35:56 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cxPx4m9hMsX for ; Mon, 6 May 2019 11:35:54 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 35B5A120148 for ; Mon, 6 May 2019 11:35:54 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id a12so8480352wrn.4 for ; Mon, 06 May 2019 11:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jHNCgzaF4dyShTTVdT/2ROINaiyIKb5u3sCr2UFbjqo=; b=L3exN89DUvHjZbh31wnt+A4jV4rOwcPiHajluZ83BShBXXdZqsU99yg+A0+PoG7Qhl nUtLo2cX/SkJRyvoyC9uw5D6oMD7vrRdiLpZxbNdUy//D5BU0XO+XcVQ/kjdKUhUDxbJ kvoTVcQX/4viQ08ALJwBcVVdZSR9/wz7bDEO4= 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=jHNCgzaF4dyShTTVdT/2ROINaiyIKb5u3sCr2UFbjqo=; b=k5/zbdEXZ5w6qhZ/z+Uv2GvsIA2wAZo7kWxaugtDzOiyAdFZCpLNnyDccar6NYBsmH eoZItyleI7x7LXGjVojun/NUjNDQJrAdNNHfaLfd37lgRRZ8aKSQjm5ghaekeNxwAVku cmsdbVT7pXBxwzxC11TVN01pqNSPm6VNPvXPKN1nhRVk/cvztAdqJwcbI1ZV1g8YXuX4 BbiOT9m6UudCKHhlfpeNbktrREQ9vVJV20n6tuTlfE0GxqPNDp6qCZuH08oHUQA/9rsb qRODi4bsAhYRoS/wi4IcOF3VcGx1HnvScNI76a4ScGX4l/AN2rSZVJ9v8zWDjx45zEN+ 8aLQ== X-Gm-Message-State: APjAAAVfjFPiphg4+i+iUw5X4q+FFIlsbXHicKrqhPpwQ2a0VT2Fhy7p HoakKEn8Mt4pAGK6SqLWKFIEVrDioUk= X-Google-Smtp-Source: APXvYqzGHWXxOH4uqTvU7eis4KYoK7bw6VnBUB0eLw9SVzELeOM+aSRb28a9L8rTkxNkOwkDb6t9rw== X-Received: by 2002:adf:f68c:: with SMTP id v12mr19771120wrp.40.1557167752488; Mon, 06 May 2019 11:35:52 -0700 (PDT) Received: from ?IPv6:2a01:4c8:3d:ccfc:a860:1d60:e44f:ad9f? ([2a01:4c8:3d:ccfc:a860:1d60:e44f:ad9f]) by smtp.gmail.com with ESMTPSA id z5sm27026319wre.70.2019.05.06.11.35.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 11:35:51 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D74A6D07-6F48-4EA6-928A-CE29761297DB Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16E227) In-Reply-To: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> Date: Mon, 6 May 2019 19:35:50 +0100 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> To: Evert Pot Archived-At: Subject: Re: [OAUTH-WG] Link relations for authenticating 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, 06 May 2019 18:36:07 -0000 --Apple-Mail-D74A6D07-6F48-4EA6-928A-CE29761297DB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t know the relative merits of Link headers vs .well-known, but= there is at least one other draft standard I know of that is going down the= .well-known route for this kind of thing (password changes in this case): https://github.com/WICG/change-password-url/blob/gh-pages/explainer.md =E2=80=94 Neil > On 3 May 2019, at 04:41, Evert Pot wrote: >=20 > Hi everyone! >=20 > I've been running into a number of situations where it would have been > beneficial to have a few protocol/media-type agnositic link relation > types for user authentication purposes. >=20 > https://tools.ietf.org/html/draft-pot-authentication-link >=20 > Nothing here is coupled to OAuth, but the link relations could > potentially be used with OAuth2 servers. >=20 > I don't exactly know the IETF process, but I thought it would be a good > idea to ask for feedback here. My understanding is that either I should > find an appropriate WG that's willing to adopt it, or I could do an > individual submission. I'm not entirely sure yet which would be the most > appropriate WG to ask, so I thought I'd start here. >=20 > Evert >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-D74A6D07-6F48-4EA6-928A-CE29761297DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I d= on=E2=80=99t know the relative merits of Link headers vs .well-known, but th= ere is at least one other draft standard I know of that is going down the .w= ell-known route for this kind of thing (password changes in this case):

=E2=80=94 Neil

On 3 May 20= 19, at 04:41, Evert Pot <me@evertpot.c= om> wrote:

Hi everyone!

I've been running into a n= umber of situations where it would have been
beneficial to h= ave a few protocol/media-type agnositic link relation
types f= or user authentication purposes.

https://tools.ie= tf.org/html/draft-pot-authentication-link

Nothing here is coupled to OAuth, but the link relations could
= potentially be used with OAuth2 servers.

I don't exactly know the IETF process, but I thought it would be a good<= /span>
idea to ask for feedback here. My understanding is that eith= er I should
find an appropriate WG that's willing to adopt i= t, or I could do an
individual submission. I'm not entirely s= ure yet which would be the most
appropriate WG to ask, so I t= hought I'd start here.

Evert


________________________________________= _______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>
= --Apple-Mail-D74A6D07-6F48-4EA6-928A-CE29761297DB-- From nobody Mon May 6 11:39:54 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 78B85120111 for ; Mon, 6 May 2019 11:39:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SprfnzUZf2Po for ; Mon, 6 May 2019 11:39:50 -0700 (PDT) Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) (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 B1470120100 for ; Mon, 6 May 2019 11:39:50 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id NiWghIJX2gKPCNiWihnznQ; Mon, 06 May 2019 11:39:49 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <3801ae30-0de4-8a82-f283-fd7b3fdb2ac5@connect2id.com> Date: Mon, 6 May 2019 21:39:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfEL9tFgi0BpOdtHSAd6aX8+/Mrf7Dgx6MVXTx0OqylBCHk3+l4c8hfNp7mhwRfKAene5Ei9YeHT4U/6uz9A1heJtd9VoW7BWYtD/Ju5txrGuEQnAF9x5 RYWRWpVDhAqrO/H8u6cff8zBrzAPwoIxV65prGjlxJUoEXVNDt5kCJCZ Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations 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, 06 May 2019 18:39:53 -0000 Hi Rifaat, On 02/05/2019 23:46, Rifaat Shekh-Yusef wrote: > All, > > As part of the shepherd write-up for the *JWT Response for OAuth Token > Introspection* draft, we are looking for information about implementations > for this document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > Are you aware of any implementations? Here is a production implementation of the JWT introspection response: https://connect2id.com/products/server/docs/api/token-introspection Vladimir -- Vladimir Dzhuvinov From nobody Mon May 6 12:16:49 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 D5218120111 for ; Mon, 6 May 2019 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 AQ4t6VZL2D2q for ; Mon, 6 May 2019 12:16:45 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 334B21200E6 for ; Mon, 6 May 2019 12:16:45 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id Nj6OhgTGweWtlNj6Rh9dDn; Mon, 06 May 2019 12:16:43 -0700 To: oauth@ietf.org References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> Date: Mon, 6 May 2019 22:16:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-CMAE-Envelope: MS4wfDS3vv5a7LdU/J6jKD30ZLHUCS8/KGiSzfZJd2/idTIuegpjbfUdZb9iSao7W+UDrqsvvh3TXQ44q9NNsY8AbnsiKvn45ap/mIDk8TZc0CzcGjJYdEhN 7cvf1fHK3QjCbBajWqtRhyiyJydLzyy0r9gWagFbTBN/lVa8lZsMUVgS Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:16:48 -0000 On 06/05/2019 20:32, Vittorio Bertocci wrote: > To that end, *Karl MCGuinness suggested that we include > grant_type as a return claim, which the RS could use to the same effect= *. I > find the proposal very clever, and the people at IIW thought so as well= =2E > What you think? The grant type is not something that the RS is really concerned with, or should be. Introducing this parameter in the access token will create an additional logical dependency, plus complexity - in the system of client, AS and RS as a whole, as well as for RS developers. The grant type, as a concept, is a matter between the client and AS, and IMO should stay that way. Clear language in the spec should suffice. For instance: "If the sub value matches the client_id value, then the subject is the client application". Vladimir --=20 Vladimir Dzhuvinov From nobody Mon May 6 12:21: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 5F4AC1200F5 for ; Mon, 6 May 2019 12:21:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6lnZ4-o5LVlw for ; Mon, 6 May 2019 12:21:14 -0700 (PDT) Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (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 32E331200E6 for ; Mon, 6 May 2019 12:21:14 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id NjAjhAVEdtZvUNjAlhhPXo; Mon, 06 May 2019 12:21:12 -0700 To: oauth@ietf.org References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> Date: Mon, 6 May 2019 22:21:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfPAcYAiCuurXWWyGBr04Lh0w5RC6kHocB/vy3xu4IH5A+Dyt6p70VB9cnfQmF+9/bGUNoWG5ePy7aLjhCH8l2cK+yDjl9R4F/ReNaCcVob8vtzf3uSgA KFl6NmmAMjvETAtZWuWMipFi571FFDdSdhUzg9HzNkuxMLbN9cXJ8h8C Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:21:16 -0000 https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2 In OpenID Connect the access token is consumed by the UserInfo endpoint. Were there any suggestions to also spec parameter(s) for the claims names (with optional locales) for release at the UserInfo endpoint? Vladimir From nobody Mon May 6 12:22: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 92A6D1200F5 for ; Mon, 6 May 2019 12:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33qxeLW-kniG for ; Mon, 6 May 2019 12:22:34 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D221200E6 for ; Mon, 6 May 2019 12:22:33 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id j11so10002839lfm.0 for ; Mon, 06 May 2019 12:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Cb9Rav1uYwKKiRwmu+WAaqOWa32L21GsCzn34yCrhA=; b=nVuVu8OGlMbNY+GcWcRRfrp4cQunOQwqhudkwz2qbotn9EEy1d8DtcvQVNQ09CVJA4 HUOzUAhMzuYgwErOYxMErfKwHQqmq2hIicuAe/QkRGn5wQ0XEIihHFvB5PJKmVRaqwU4 SWTn063TtmfcqU3qKUU749E+5seI6F9/5Oh4A+rOMwZnMUpbZNjT/Eo5dmlO7LplQ1fW JIknXcpbWdD0hWzqMjeVzHL7cPLCX22Fv41AiA2Dv+cGDCMtFjzUhUDSq7qaTBQYKhNV dpVCK+mNLaj4BJYGEIEROGpxxSgvA9NnhZlwNnoFnZRfDjSIGSjbW3vx7Qr9Ei4HqhIK pO9w== 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=3Cb9Rav1uYwKKiRwmu+WAaqOWa32L21GsCzn34yCrhA=; b=iP9soIgNOAt2opN1tA4g/tX1zP7ZS6DJvp6tdKbxq1Rq7q5BiSPDqtuYawbwk4VM/k O5cUvJ2wa57aUOaQrz9bX9njry6LKG9GyLoJLxRHMDQJD/br/i/ldmgD3DxDqJBra5MU 4DOmRJGMehb+ZHCsaO51J1LbpbM6hObD/VwVFpI0SG5KC9OCmJ6bsR6VywmFis9cAk05 uLn1PTkYpNkwvPpnpDYeG2T8/KXMmo0F6ho1Sz/zm06UH5k+0owP90pP79jfzuX9kQ2t +dGDr5OUxbANdEMtqaKL8Z7CoSocw41pUzZB8JgAKCYITlO8a+n2he3QMdk9Sns9YXeG eQUg== X-Gm-Message-State: APjAAAViVxr6nOGQMVqKY9T8FjxGvVsBYwl+3V6L34HsqzW1wl5NHf5z Hqf4ByrBwpjRQSHkkrRH0AJHGlcqq7hkI7idZ9021Fefn3k= X-Google-Smtp-Source: APXvYqy08z6q17ugbMNNylwQjbw/+KJQV+afHl7NwQ+Wwpia+UDBXaJvKKfp1f5p47W7oPCfmZiH3/9qs1Qclx10Ewg= X-Received: by 2002:a19:d115:: with SMTP id i21mr831110lfg.60.1557170551704; Mon, 06 May 2019 12:22:31 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> In-Reply-To: <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> From: Vittorio Bertocci Date: Mon, 6 May 2019 12:22:23 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000096f24105883d05a4" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:22:37 -0000 --00000000000096f24105883d05a4 Content-Type: text/plain; charset="UTF-8" It is true that the grant_type is a client side consideration. I did think about the "client_id==sub" heuristic, but that's not always applicable: many systems have their own rules for generating sub, and in case they want to prevent tracking across RSes the sub might be generated ad-hoc for that particular RS. Would you prefer to have a dedicated claim that distinguish between user and app tokens rather than reusing grant_type? On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov wrote: > On 06/05/2019 20:32, Vittorio Bertocci wrote: > > To that end, *Karl MCGuinness suggested that we include > > grant_type as a return claim, which the RS could use to the same > effect*. I > > find the proposal very clever, and the people at IIW thought so as well. > > What you think? > > The grant type is not something that the RS is really concerned with, or > should be. Introducing this parameter in the access token will create an > additional logical dependency, plus complexity - in the system of > client, AS and RS as a whole, as well as for RS developers. The grant > type, as a concept, is a matter between the client and AS, and IMO > should stay that way. > > Clear language in the spec should suffice. For instance: "If the sub > value matches the client_id value, then the subject is the client > application". > > Vladimir > > -- > Vladimir Dzhuvinov > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000096f24105883d05a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is true that the grant_type is a client side considerat= ion. I did think about the "client_id=3D=3Dsub" heuristic, but th= at's not always applicable: many systems have their own rules for gener= ating sub, and in case they want to prevent tracking across RSes the sub mi= ght be generated ad-hoc for that particular RS.
Would you prefer to hav= e a dedicated claim that distinguish between user and app tokens rather tha= n reusing grant_type?

On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvin= ov <vladimir@connect2id.com> wrote:
On= 06/05/2019 20:32, Vittorio Bertocci wrote:
> To that end, *Karl MCGuinness suggested that we include
> grant_type as a return claim, which the RS could use to the same effec= t*. I
> find the proposal very clever, and the people at IIW thought so as wel= l.
> What you think?

The grant type is not something that the RS is really concerned with, or should be. Introducing this parameter in the access token will create an additional logical dependency, plus complexity - in the system of
client, AS and RS as a whole, as well as for RS developers. The grant
type, as a concept, is a matter between the client and AS, and IMO
should stay that way.

Clear language in the spec should suffice. For instance: "If the sub value matches the client_id value, then the subject is the client
application".

Vladimir

--
Vladimir Dzhuvinov


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000096f24105883d05a4-- From nobody Mon May 6 12:26: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 81A4E120126 for ; Mon, 6 May 2019 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvZf7IXwYNVG for ; Mon, 6 May 2019 12:26:22 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458651200E6 for ; Mon, 6 May 2019 12:26:22 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id d15so12117039ljc.7 for ; Mon, 06 May 2019 12:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FSHC3kZhwAULSHeFvAfGn3wCJO96NCP4vkr0yik7lYo=; b=QPq02zd8XRbFxbTldomok+heyhLg5S1XQbYtxlx4qwu8SrSiZH9iwYKtkcVEV0vjBs 9T0Sqc12VGSpjDQgqK4PgkOXidklxdljy8kjt1SKnC9M2beJceGBcWnQ6wVl7gg9U+LI lnkn9bWG01FkL8sAflSELeFqm8BuTLabedUVkrVg1hehGkRKmlEEdsn9mS3bP6SC/Q9m kZTcrAHAhyd/9wXnRbnu3tIhs+TBZc835Pd3sSv2GuvXZN8p8tn31/rwoBWAbo95EMxk qUeTgIWk/FviArmHPRLlghEgnSjN6+mI/fV8wjhpoDvYOZ1G8+9SxLNRmuk5OHVZ5EPS a3LA== 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=FSHC3kZhwAULSHeFvAfGn3wCJO96NCP4vkr0yik7lYo=; b=H/q8DmKP7ALEJZDsbBhvD3cD6OS1PrdHRScgS1y11iVM767OC/xzkRZBPcYvn6VY0s bBnkOKF+OFnk0f74kqndNSobGbMWQZRdrP8/OZg/jIF5D5/1UET5N3xDQW71cxmiYZAC JruElj1PKbX8xqXDn1HICTkCEDuMrwC/0hFgpzQg79jENpN3zBvKOz4fbtPosWgFI1wo WD1js6KUT43CLX4SsnYzABSAsAkya1Afds0n9vP8JAgR/K04cyQoAHbW1BUMH+taqMyP MWbKud2G6K7LaAhBd6cxDHardoYyRz/LTzpXAMyp6vzDDIfteF7emeGjK4p5NaQQCbQT lqbw== X-Gm-Message-State: APjAAAV3i5yZh6HHA4UorxxaR4LVLL5obFFp+wsOs/MMQj2+6S6ng8el u83mn16MnCwwft6vOMdHk4ihTYfphg7ApfaSL6cxvA== X-Google-Smtp-Source: APXvYqzTtc7Kyw0tRV+IaliHNbG6GKGfEZEfVOWLULXOYHSB7nvpLOQ0gy6fIuj9xz1k1bVd1heEMJk/+wRrm1P5U3c= X-Received: by 2002:a2e:84ca:: with SMTP id q10mr1171984ljh.117.1557170780202; Mon, 06 May 2019 12:26:20 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> In-Reply-To: <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> From: Vittorio Bertocci Date: Mon, 6 May 2019 12:26:12 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000357c9505883d139e" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:26:25 -0000 --000000000000357c9505883d139e Content-Type: text/plain; charset="UTF-8" I am not following, Vladimir. What do you mean? Can you make some examples to clarify? The userinfo is always colocated with the AS, hence I would expect most vendors not to use JWT for the ATs issued for userinfo access On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov wrote: > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2 > > In OpenID Connect the access token is consumed by the UserInfo endpoint. > > Were there any suggestions to also spec parameter(s) for the claims > names (with optional locales) for release at the UserInfo endpoint? > > Vladimir > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000357c9505883d139e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not following, Vladimir. What do you mean? Can you ma= ke some examples to clarify?
The userinfo is always colocated with = the AS, hence I would expect most vendors not to use JWT for the ATs issued= for userinfo access

On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvino= v <vladimir@connect2id.com> wrote:
https://tools.ietf.org/ht= ml/draft-ietf-oauth-access-token-jwt-00#section-2.2.2

In OpenID Connect the access token is consumed by the UserInfo endpoint.
Were there any suggestions to also spec parameter(s) for the claims
names (with optional locales) for release at the UserInfo endpoint?

Vladimir

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000357c9505883d139e-- From nobody Mon May 6 12:35: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 8B65C1200E6 for ; Mon, 6 May 2019 12:35:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 I_K7qRYz5wM7 for ; Mon, 6 May 2019 12:35:09 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 F2DBB12013E for ; Mon, 6 May 2019 12:35:08 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id NjOChEmqqWiaANjOFhLGY0; Mon, 06 May 2019 12:35:07 -0700 To: Vittorio Bertocci Cc: IETF oauth WG References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> Date: Mon, 6 May 2019 22:35:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-CMAE-Envelope: MS4wfPi2pWpEUEraKDLxhskmoJV0n2/s3aLbV6M5XRpaCRehmz/tB+GOIkRm3niHAkuyBQaQ2D43uyjni8hAHCkHf/tz6x5+1WEw6HQM5yIION2+CHM8bRrw GEZNQpCjgSTDDvLNnD9UkuW6LdnrXXDMfV8f6arMcxtzk2t1wehp+ySIlsWwTngV9qhnOJkApRhIxr4CAJXxU/gxFpf1koQwq3M= Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:35:12 -0000 Hi Vittorio, On 06/05/2019 22:22, Vittorio Bertocci wrote: > It is true that the grant_type is a client side consideration. I did th= ink > about the "client_id=3D=3Dsub" heuristic, but that's not always applica= ble: > many systems have their own rules for generating sub, and in case they = want > to prevent tracking across RSes the sub might be generated ad-hoc for t= hat > particular RS. > Would you prefer to have a dedicated claim that distinguish between use= r > and app tokens rather than reusing grant_type? A dedicated claim to flag client_id effectively =3D=3D sub would be preferable, and much easier for RS developers to process. The AS is the authority and has all the knowledge to set / indicate this.= I want to keep RS developers away from having to deal with grant types and having to make decisions whether client_id effectively =3D=3D sub. Vladimir > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov > wrote: > >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>> To that end, *Karl MCGuinness suggested that we include >>> grant_type as a return claim, which the RS could use to the same >> effect*. I >>> find the proposal very clever, and the people at IIW thought so as we= ll. >>> What you think? >> The grant type is not something that the RS is really concerned with, = or >> should be. Introducing this parameter in the access token will create = an >> additional logical dependency, plus complexity - in the system of >> client, AS and RS as a whole, as well as for RS developers. The grant >> type, as a concept, is a matter between the client and AS, and IMO >> should stay that way. >> >> Clear language in the spec should suffice. For instance: "If the sub >> value matches the client_id value, then the subject is the client >> application". >> >> Vladimir >> >> -- >> Vladimir Dzhuvinov >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> --=20 Vladimir Dzhuvinov From nobody Mon May 6 12:42: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 9D097120139 for ; Mon, 6 May 2019 12:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKoML6YXoLwJ for ; Mon, 6 May 2019 12:42:29 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952D91200F9 for ; Mon, 6 May 2019 12:42:28 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id f23so12184826ljc.0 for ; Mon, 06 May 2019 12:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oBAHtMRaqZcC1uxevOEdDDu57f6QNpcmqBVzkXBQFFA=; b=AIZ9cBU0KxkVDl7KGq6rXtr84S0kQGtn5mubm8QYCejRlnnibDZBYKAkwfR6N/0AO1 f8EepUmAATzZrvIxgB4pBoQcawnOjcx19IcM7iuVhJ06hFA547jKrxCTYHG0AekQ47NB cqyggX4sSnBQbY2uDJyoot7KLADquSDFj6KPlSYT66Y0ppdfqT30bqH8E9GskhifScyN eJrOhQgWpqct5lgsXjcq/r1YwGpxo5pDrBveW2EPMJH70lu3UTgooaFNKAu/V7I4CKpF C6b2znODpHikb9YydOdG2b3VJjpH20D9EItmR76B1mXTdRsXZqzsbOkAsGw+XgbweNKp bHJQ== 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=oBAHtMRaqZcC1uxevOEdDDu57f6QNpcmqBVzkXBQFFA=; b=eEZQGJnXzg8Q9NJAIm9gBW/f2u+fwmw3AupG0EVyawYlhwJprj21A+muKzfXgfuuCX cEyOAg9KVPeFTLm4u16Xf+3Og9dmNW052F3qxh2GZf++1n6bwJbSEsuosDIpLI7Mc7bF uhlhwyZiwwfz/Iz8zwaqDdDTHcwjlfLKaJDsaIHFe+xCZlPFUMlB5/mSOFA+MZYcJ53I QgViHrSK5PJyxeefo8ik1l0d5iPH0126byqJcKRUHxZyoh995DgLKUOGTEWWJBdzXr1a RtaOnkcvoi3dOK+gpskiirY2hiYUVhxRX5kNc/cQwYTBHROYLmjF6YXdTn5/NJGU+VQS ZLeQ== X-Gm-Message-State: APjAAAUMZ+aabxUw281Y0+14hDEDAJ2nflr65XKv6t/Pj+DEM42ZA546 0vYaatT/raDWAwhL1vR4TtcAZ9lmuoUnTyd1PAXWcg== X-Google-Smtp-Source: APXvYqwzDQw+R/KCxH7v7oJ0YSxvDvuRD+g/NjxHQ1QSYdsIcx2TWD54n8hQm6NvUa8n8VkUya8Qr3lFmHsALg9JcVo= X-Received: by 2002:a2e:a0c9:: with SMTP id f9mr14514089ljm.62.1557171746557; Mon, 06 May 2019 12:42:26 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> In-Reply-To: <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> From: Vittorio Bertocci Date: Mon, 6 May 2019 12:42:18 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000cee4b505883d4c81" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:42:32 -0000 --000000000000cee4b505883d4c81 Content-Type: text/plain; charset="UTF-8" Fair enough! What others think about it? Exploring the approach: would we want a bool claim or an enumeration, e.g. sub_type = [ resource_owner | client ] ? On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov wrote: > Hi Vittorio, > > On 06/05/2019 22:22, Vittorio Bertocci wrote: > > It is true that the grant_type is a client side consideration. I did > think > > about the "client_id==sub" heuristic, but that's not always applicable: > > many systems have their own rules for generating sub, and in case they > want > > to prevent tracking across RSes the sub might be generated ad-hoc for > that > > particular RS. > > Would you prefer to have a dedicated claim that distinguish between user > > and app tokens rather than reusing grant_type? > > A dedicated claim to flag client_id effectively == sub would be > preferable, and much easier for RS developers to process. > > The AS is the authority and has all the knowledge to set / indicate this. > > I want to keep RS developers away from having to deal with grant types > and having to make decisions whether client_id effectively == sub. > > Vladimir > > > > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < > vladimir@connect2id.com> > > wrote: > > > >> On 06/05/2019 20:32, Vittorio Bertocci wrote: > >>> To that end, *Karl MCGuinness suggested that we include > >>> grant_type as a return claim, which the RS could use to the same > >> effect*. I > >>> find the proposal very clever, and the people at IIW thought so as > well. > >>> What you think? > >> The grant type is not something that the RS is really concerned with, or > >> should be. Introducing this parameter in the access token will create an > >> additional logical dependency, plus complexity - in the system of > >> client, AS and RS as a whole, as well as for RS developers. The grant > >> type, as a concept, is a matter between the client and AS, and IMO > >> should stay that way. > >> > >> Clear language in the spec should suffice. For instance: "If the sub > >> value matches the client_id value, then the subject is the client > >> application". > >> > >> Vladimir > >> > >> -- > >> Vladimir Dzhuvinov > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > -- > Vladimir Dzhuvinov > > > --000000000000cee4b505883d4c81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fair enough! What others think about it?
Exploring the= approach: would we want a bool claim or an enumeration, e.g. sub_type =3D = [ resource_owner | client ] ?


On Mon, May 6, 2019 = at 12:35 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
--
Vladimir Dzhuvinov


--000000000000cee4b505883d4c81-- From nobody Mon May 6 12:42: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 606431200F9 for ; Mon, 6 May 2019 12:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwpl3mO6uhN9 for ; Mon, 6 May 2019 12:42:30 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 5295712012F for ; Mon, 6 May 2019 12:42:30 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id w11so16476374edl.5 for ; Mon, 06 May 2019 12:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=h8x8KfvUeqcZH61XByI2f0qAvGPIiTteczjvilxhZRg=; b=OZHPXH+VXDA8uPzWKxhZu/HvbAasjvj93dnW5h47qvfHqnQ2b+Xg9t4DLeLQshgEFq xKU4+GVQWTk5bAdopNwrJvog8+yhZkGUKU3DsbRo8FpdN34zBu6UA6Kjk4SFWOKu27Fi woSiD7Pv7h2xJbQQ5jqujh0BhCy86nz9tfpJrBGFF1wcXbgiObWQIR4zpN04EgvT5AUr cxZftt0aPEub7kNhW2VL5MP9RXOLpp4mPHpGYTEQQVG2nFv0XMEVqAOivKF9GTXyp0mS Qw6GoXCI+U9Q4xQsJ2RCIxMKJgV3cd8CPPNSH79MqFT8PczmVi7mnl43euC2I96jHkA/ 3rLw== 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:mime-version :content-transfer-encoding; bh=h8x8KfvUeqcZH61XByI2f0qAvGPIiTteczjvilxhZRg=; b=HqfxZEJVsjMBsTYSbQ3jw81DqSVQCLPo3qbpqySu0/3iQqEb+M6krYd7VBlq2B3KE9 t1zzGZ6dKLnMSjbM6U7XgjffThNZQ802wFD0yVHhIjLsSO9lvItlJ0b/WS69I1OXFDkf P89f8Go8Yn97TYx0z9VuyqTdaDjLWa1iwjdabO0RIZoBgoFcmItWlqNEVPofW4c5pLWQ Q396zw6xAnlo5wn6xxxNaZ/LM+SWhG3Q7MSNX7Jx9ONflc4QkNJWrgq5Uu5X61vdszUk wfx+Uf06BwVno46gnuCJBs1WLMvQRt5/sd2dIwNX5ZbjnIb3rdXuDpRunAQvvTOb/qkF 9TUw== X-Gm-Message-State: APjAAAXeXExYekkqBUuOOVfLjuxajdTIKmQXQj0TlJbokLBZOSsQv+d0 JduliVvgspCu93GUvZLSZF1bP9YtF+Y= X-Google-Smtp-Source: APXvYqxsvnqI3Pr/s+sa6kCJQrsgD7uQYBMCXO/xxKbIDnL46b36Ldv0g72wdqcG0x4edaYZ5tlOKA== X-Received: by 2002:a50:f5d4:: with SMTP id x20mr27791096edm.88.1557171748125; Mon, 06 May 2019 12:42:28 -0700 (PDT) Received: from papegaaij.localnet (2001-1c06-0105-0e00-d550-1b4b-99df-63aa.cable.dynamic.v6.ziggo.nl. [2001:1c06:105:e00:d550:1b4b:99df:63aa]) by smtp.gmail.com with ESMTPSA id 65sm3321437edm.60.2019.05.06.12.42.27 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 May 2019 12:42:27 -0700 (PDT) From: Emond Papegaaij To: oauth@ietf.org Date: Mon, 06 May 2019 21:42:17 +0200 Message-ID: <11125817.AKI43N3Yza@papegaaij> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps 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, 06 May 2019 19:42:33 -0000 Hi all, For a browser-based app, we try to follow the recommendations set in draft- ietf-oauth-browser-based-apps-01. This does allow us to create a secure OAuth 2.0 browser-based application, but at the moment it comes at a cost wrt. user experience when the access token expires. Our current solution forces us to redirect the user to the authorization server for a new authorization code. This will destroy most state the browser-based app has, causing the user to loose data. We are looking for a way to get a new access token in a secure way without disrupting the user. As a refresh token is not issued to the app (as it should be), the application is forced to do a front-channel re-authentication for an authorization code. We are thinking of letting this front-channel communication happen in a hidden iframe. Naturally, this can only be done if no user interaction is required, hence we want to use the OIDC prompt=none. Is this a viable way of doing this re-authentication? Can it hurt to open up our authorization server for non- interactive authorization requests inside an iframe? At the moment we do not allow iframes at all. Maybe anybody knows a different way of achieving this? As I cannot believe we are the only ones facing this issue, maybe a recommendation can be put in the spec? Best regards, Emond Papegaaij From nobody Mon May 6 12:43: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 78A8F120086 for ; Mon, 6 May 2019 12:43:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3ZoGO3OqOs6 for ; Mon, 6 May 2019 12:43:53 -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 017F2120049 for ; Mon, 6 May 2019 12:43:52 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x46JhPG7015135 for ; Mon, 6 May 2019 15:43:44 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 6 May 2019 15:42:36 -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, 6 May 2019 15:43:30 -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, 6 May 2019 15:43:30 -0400 From: Justin Richer To: oauth Thread-Topic: XYZ and Transactional OAuth Thread-Index: AQHVBEP7Im7G7leYVU+SN4wbA8uD4g== Date: Mon, 6 May 2019 19:43:30 +0000 Message-ID: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@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_5C245C9EDB464D4C8788821F5C11C8FDmitedu_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] XYZ and Transactional OAuth 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, 06 May 2019 19:43:56 -0000 --_000_5C245C9EDB464D4C8788821F5C11C8FDmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gYSB2ZWluIHJlbGF0ZWQgdG8gVG9yc3RlbuKAmXMgcmVjZW50IHRocmVhZCBhbmQgYmxvZyBw b3N0LCBJ4oCZdmUgYWxzbyBiZWVuIHdvcmtpbmcgb24gYSBwcm9wb3NhbCBhcm91bmQgVHJhbnNh Y3Rpb25hbCBPQXV0aC4gQXMgbWFueSBvZiB5b3Uga25vdywgSSB3cm90ZSBhIGJsb2cgcG9zdCBh Ym91dCB0aGUgYmFzaWMgaWRlYSBsYXN0IGZhbGwsIGFuZCBub3cgSeKAmXZlIGdvdCBzb21ldGhp bmcgYSBiaXQgbW9yZSBjb25jcmV0ZSBvbmxpbmUgdGhhdCBwZW9wbGUgY2FuIHBva2UgYXJvdW5k IHdpdGguIEnigJltIGNhbGxpbmcgaXQg4oCcWFla4oCdIGp1c3QgdG8gZ2l2ZSBpdCBhIG5hbWUs IGFuZCBpdOKAmXMgb25saW5lIGhlcmU6DQoNCmh0dHBzOi8vb2F1dGgueHl6Lw0KDQpJIG5lZWQg dG8gYmUgdmVyeSBjbGVhcjogVGhpcyBpcyBub3Qgd2lyZS1jb21wYXRpYmxlIHdpdGggT0F1dGgy LCBidXQgaXMgaW5zdGVhZCBhIHRyYW5zYWN0aW9uYWwgKGludGVudC1wYXR0ZXJuKSBwcm90b2Nv bCB0aGF0IGltcGxlbWVudHMgYSBsb3Qgb2YgdGhlIGNvcmUgY29uY2VwdHMgYW5kIGEgZmV3IG5l dyBvbmVzIGluIGEgZGlmZmVyZW50IGZyYW1ld29yay4gVGhlcmUgaGF2ZSBiZWVuIGEgbG90IG9m IGF0dGVtcHRzIHRvIGV4dGVuZCBhbmQgYWRhcHQgT0F1dGggaW4gdGhlIGxhc3QgZmV3IHllYXJz LCBhbmQgaW4gbXkgb3BpbmlvbiB0aGF04oCZcyBnb3R0ZW4gdXMgcGFpbnRlZCBpbnRvIGEgYml0 IG9mIGEgY29ybmVyIGFzIHdlIGtlZXAgdHJ5aW5nIHRvIHNvbHZlIG5ldyBwcm9ibGVtcy4gQnkg YnJlYWtpbmcgYXdheSBmcm9tIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCBJIGZvdW5kIHRoYXQg d2FzIGFibGUgdG8gYm90aCBzaW1wbGlmeSBhIGxvdCBvZiB0aGUgY29uY2VwdHMsIG1ha2UgZGlm ZmVyZW50IGFjdGlvbnMgbW9yZSBjb25zaXN0ZW50LCBhbmQgbWFrZSBpdCBtb3JlIHdpZGVseSBm bGV4aWJsZS4NCg0KQWxzbyB0byBub3RlLCBJ4oCZdmUgcmVhZCB0aHJvdWdoIFRvcnN0ZW7igJlz IGRyYWZ0LCBhbmQgSSB0aGluayB0aGF0IGhpcyBpZGVhcyBvZiB3aGF04oCZcyBpbiBhIOKAnFN0 cnVjdHVyZWQgU2NvcGXigJ0gY291bGQgYmUgYSByZXBsYWNlbWVudCBmb3IgdGhlIGhhbmQtd2F2 aW5nIGlkZWEgSSBoYXZlIGluIHRoZSDigJxyZXNvdXJjZXPigJ0gc2VjdGlvbiBvZiBYWVouIEni gJltIGNvbnRpbnVpbmcgZGV2ZWxvcG1lbnQgb2YgdGhpcyBwcm90b2NvbCwgaW5jbHVkaW5nIGEg Y291cGxlIHRveSBpbXBsZW1lbnRhdGlvbnMsIGFsbCBvZiB0aGVtIG9wZW4gc291cmNlLiBJIGhh dmUgc3RhcnRlZCBhIHdyaXRldXAgaW4gc3BlYy1sYW5ndWFnZSwgYW5kIEkgcGxhbiB0byBoYXZl IGl0IGNsZWFuZWQgdXAgYW5kIHN1Ym1pdHRlZCBwcmlvciB0byBNb250cmVhbCDigJQgd2hlcmUg SeKAmWxsIGJlIGF0dGVuZGluZyBpbiBwZXJzb24gYW5kIGhvcGUgdG8gZGlzY3VzcyB0aGlzIGFz IGEgcG90ZW50aWFsIFdHIGl0ZW0uDQoNCuKAlCBKdXN0aW4NCg0K --_000_5C245C9EDB464D4C8788821F5C11C8FDmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkluIGEgdmVpbiByZWxhdGVkIHRvIFRvcnN0ZW7i gJlzIHJlY2VudCB0aHJlYWQgYW5kIGJsb2cgcG9zdCwgSeKAmXZlIGFsc28gYmVlbiB3b3JraW5n IG9uIGEgcHJvcG9zYWwgYXJvdW5kIFRyYW5zYWN0aW9uYWwgT0F1dGguIEFzIG1hbnkgb2YgeW91 IGtub3csIEkgd3JvdGUgYSBibG9nIHBvc3QgYWJvdXQgdGhlIGJhc2ljIGlkZWEgbGFzdCBmYWxs LCBhbmQgbm93IEnigJl2ZSBnb3Qgc29tZXRoaW5nIGEgYml0IG1vcmUgY29uY3JldGUgb25saW5l IHRoYXQNCiBwZW9wbGUgY2FuIHBva2UgYXJvdW5kIHdpdGguIEnigJltIGNhbGxpbmcgaXQg4oCc WFla4oCdIGp1c3QgdG8gZ2l2ZSBpdCBhIG5hbWUsIGFuZCBpdOKAmXMgb25saW5lIGhlcmU6DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL29hdXRoLnh5ei8iIGNsYXNzPSIiPmh0dHBzOi8vb2F1dGgueHl6LzwvYT48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkg bmVlZCB0byBiZSB2ZXJ5IGNsZWFyOiBUaGlzIGlzIG5vdCB3aXJlLWNvbXBhdGlibGUgd2l0aCBP QXV0aDIsIGJ1dCBpcyBpbnN0ZWFkIGEgdHJhbnNhY3Rpb25hbCAoaW50ZW50LXBhdHRlcm4pIHBy b3RvY29sIHRoYXQgaW1wbGVtZW50cyBhIGxvdCBvZiB0aGUgY29yZSBjb25jZXB0cyBhbmQgYSBm ZXcgbmV3IG9uZXMgaW4gYSBkaWZmZXJlbnQgZnJhbWV3b3JrLiBUaGVyZSBoYXZlIGJlZW4gYSBs b3Qgb2YgYXR0ZW1wdHMNCiB0byBleHRlbmQgYW5kIGFkYXB0IE9BdXRoIGluIHRoZSBsYXN0IGZl dyB5ZWFycywgYW5kIGluIG15IG9waW5pb24gdGhhdOKAmXMgZ290dGVuIHVzIHBhaW50ZWQgaW50 byBhIGJpdCBvZiBhIGNvcm5lciBhcyB3ZSBrZWVwIHRyeWluZyB0byBzb2x2ZSBuZXcgcHJvYmxl bXMuIEJ5IGJyZWFraW5nIGF3YXkgZnJvbSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgSSBmb3Vu ZCB0aGF0IHdhcyBhYmxlIHRvIGJvdGggc2ltcGxpZnkgYSBsb3Qgb2YgdGhlIGNvbmNlcHRzLA0K IG1ha2UgZGlmZmVyZW50IGFjdGlvbnMgbW9yZSBjb25zaXN0ZW50LCBhbmQgbWFrZSBpdCBtb3Jl IHdpZGVseSBmbGV4aWJsZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFsc28gdG8gbm90ZSwgSeKAmXZlIHJlYWQgdGhyb3Vn aCBUb3JzdGVu4oCZcyBkcmFmdCwgYW5kIEkgdGhpbmsgdGhhdCBoaXMgaWRlYXMgb2Ygd2hhdOKA mXMgaW4gYSDigJxTdHJ1Y3R1cmVkIFNjb3Bl4oCdIGNvdWxkIGJlIGEgcmVwbGFjZW1lbnQgZm9y IHRoZSBoYW5kLXdhdmluZyBpZGVhIEkgaGF2ZSBpbiB0aGUg4oCccmVzb3VyY2Vz4oCdIHNlY3Rp b24gb2YgWFlaLiBJ4oCZbSBjb250aW51aW5nIGRldmVsb3BtZW50IG9mIHRoaXMgcHJvdG9jb2ws DQogaW5jbHVkaW5nIGEgY291cGxlIHRveSBpbXBsZW1lbnRhdGlvbnMsIGFsbCBvZiB0aGVtIG9w ZW4gc291cmNlLiBJIGhhdmUgc3RhcnRlZCBhIHdyaXRldXAgaW4gc3BlYy1sYW5ndWFnZSwgYW5k IEkgcGxhbiB0byBoYXZlIGl0IGNsZWFuZWQgdXAgYW5kIHN1Ym1pdHRlZCBwcmlvciB0byBNb250 cmVhbCDigJQgd2hlcmUgSeKAmWxsIGJlIGF0dGVuZGluZyBpbiBwZXJzb24gYW5kIGhvcGUgdG8g ZGlzY3VzcyB0aGlzIGFzIGEgcG90ZW50aWFsIFdHIGl0ZW0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5C245C9EDB464D4C8788821F5C11C8FDmitedu_-- From nobody Mon May 6 12:47:36 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 CC373120049 for ; Mon, 6 May 2019 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZTdcqITz56G for ; Mon, 6 May 2019 12:47:33 -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 B5E00120086 for ; Mon, 6 May 2019 12:47:32 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id w37so16475320edw.4 for ; Mon, 06 May 2019 12:47:32 -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=zsDFHKB2Wr5T1PnmdTxRb4vH/3NSQR7ow5MwxAETrdE=; b=YUcidMs076C5J54SrHE2mCGL4mn7FmM99AmKGZo7pV8HEOkm/xrcm4DB5wp30uW1lB a7ldqw3XD1qtUltXSOEs7aqMM/j4Tekteex1qeE+vzSbo+O61pRYSgJSs1w9Dcf4JkH5 Yk3bOphYMw/1fWVasg2Bg7Rl7kobffUgv5sx6zlAv9wae66KBepEl6uoQbu5tBsil8g4 t2Eh1ZFr+hADVRtArnfLEJw0j4ra2qOKengYJzVKAqmz1TpaUjOPdXNE47dc+qbMlAJz SmBQUmha7i5QRWEwTTqj8/0cBBeMEnO6ZqyuC1N3lqV09OjIu9yH9f8CorjWaStWRl6B eofA== 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=zsDFHKB2Wr5T1PnmdTxRb4vH/3NSQR7ow5MwxAETrdE=; b=Lbq5s9A3Ehjq41ewxEp4nmowHy/SL0EVD09Xn1voc9fLcIngy9++7yBHoQ8VbBIV7k SvybVQe+oLD4el6yL9zwBXhk96UogyjZQaE33oZYPXogOMNaQmR3ayGEr+fJdIy+hXBQ NMGLJaoJOO3qz1n8LxYCJCvDYN9SsvAzusF8E3sl2+FYIVieZ7STfmXr02wpfUABqkan TxZrSCtvk4d/nJNzRnzrtLpY4W/63B/VNP8Nj0s4Zdbqre1BPqYwxVG4gbTc2hJr1U+L BorP6vs+2ZSQkMUH8RXCm+EHscII3LhIS56tyJ7XZTuMook9BEGpWz9nBjAQAISW0gOO 6Elw== X-Gm-Message-State: APjAAAXDAgbSwz3qX3DHwAlx0TKvXxFRGy24cOkhDafCx8g3KYAZ6FXS TQxsbH5fUGzNJ+dZd+nDZr0C0ZVT4ic= X-Google-Smtp-Source: APXvYqyeBEuSgf50Cozig5RtYNftBATZ0AjUur1VpVNg0CLUIIju/QKfIVufqGfSkgNyROzQ9aFhOw== X-Received: by 2002:a50:9007:: with SMTP id b7mr27138267eda.194.1557172050840; Mon, 06 May 2019 12:47:30 -0700 (PDT) Received: from papegaaij.localnet (2001-1c06-0105-0e00-d550-1b4b-99df-63aa.cable.dynamic.v6.ziggo.nl. [2001:1c06:105:e00:d550:1b4b:99df:63aa]) by smtp.gmail.com with ESMTPSA id e4sm1705131ejm.50.2019.05.06.12.47.30 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 May 2019 12:47:30 -0700 (PDT) From: Emond Papegaaij To: oauth@ietf.org Date: Mon, 06 May 2019 21:47:29 +0200 Message-ID: <1750829.ebW1fUBprn@papegaaij> In-Reply-To: References: <4223569.5sG2vptK2V@papegaaij> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange status and Resource Indicators 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, 06 May 2019 19:47:35 -0000 On zondag 5 mei 2019 15:54:48 CEST you wrote: > On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij > > To summarize, I have to following questions: > > - Is the 'OAuth 2.0 Token Exchange' specification still active? > > Yes with the caveats mentioned above. I will say that although there's a > lot of work required for the document, none of it is likely to result in > functional changes so I don't anticipate anything breaking at this point. Good to hear, because IMHO it really adds value to OAuth 2.0. > > - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? > > No, that's beyond it's current scope. And it is well past last call in the > WG. But note that a logical identifier can be used as the value of the > resource parameter. Would you recommend to put the AWS entity id in the resource parameter on the authorize request then? I need a way to inform the authorization server that the client wants a token for a different service to allow the authorization server to prompt the user for correct consent. I like the 'audience' parameter defined by the token exchange specification, because it really fits the purpose I'm looking for. However, I also like to keep the authorization request and token request similar. It looks wrong to ask for authorization for 'resource' X and later on request a token for 'audience' X. Best regards, Emond Papegaaij From nobody Mon May 6 12:49:25 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 49150120240 for ; Mon, 6 May 2019 12:49:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 CYG6JPk6VCVv for ; Mon, 6 May 2019 12:49:09 -0700 (PDT) Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) (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 EABE1120170 for ; Mon, 6 May 2019 12:49:08 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id NjbkhIVXzKb9rNjbnhrJiz; Mon, 06 May 2019 12:49:07 -0700 To: Vittorio Bertocci Cc: IETF oauth WG References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: <88c03aa7-ba61-d0fe-97a1-b43f55d11b2d@connect2id.com> Date: Mon, 6 May 2019 22:49:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-CMAE-Envelope: MS4wfAlHXesxpVQooStLAuhaToCnTlvZyysaIPfB/bdSS6TnUz+4HQajbNr52JZJvDCBdcc9Cn0gIF8pNNLLNgZh6nXVAVTiEERhLm8qFIuyIfQyPiJUtUWq DXyuqeVn7unvptyGYOijrACpDjue17SKftFVgxQi4noPum+Q4bAxXf9h3+z0e7cftrr/iWSMrhsG8oRnQb1d4NtdxIxTbtQoufo= Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:49:24 -0000 On 06/05/2019 22:26, Vittorio Bertocci wrote: > I am not following, Vladimir. What do you mean? Can you make some examp= les > to clarify? > The userinfo is always colocated with the AS, hence I would expect most= > vendors not to use JWT for the ATs issued for userinfo access That's what I was curious about, if there are any deployments with the UserInfo not being co-located. OpenID Connect also has this exotic use case, called distributed claims: https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample If co-location is the common case, then there's really no need to spec a JWT claim for that. Vladimir > On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov > wrote: > >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#secti= on-2.2.2 >> >> In OpenID Connect the access token is consumed by the UserInfo endpoin= t. >> >> Were there any suggestions to also spec parameter(s) for the claims >> names (with optional locales) for release at the UserInfo endpoint? >> >> Vladimir >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From nobody Mon May 6 12:57:54 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 68523120115 for ; Mon, 6 May 2019 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=okta.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 ON9tPGQxuPQm for ; Mon, 6 May 2019 12:57:48 -0700 (PDT) Received: from us-smtp-delivery-163.mimecast.com (us-smtp-delivery-163.mimecast.com [63.128.21.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEDC1200E6 for ; Mon, 6 May 2019 12:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=mimecast20140813; t=1557172666; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FKunJx6rWHGADkw8iB4q2Q97n4syu8ZWSm+ZCohniJo=; b=iKGZoRe6Xu/K5y1ZScMvfdOhgEvzppTi2iHU3P5C4VuldGD0psgs37DY2JsrznKPIJFcoD NEN7I9XmdYiQcSGEATkmmTfkK93+hpe34XoLTKfB0Lo9pBE8iUM3JoFzvaPrEx77hzSznW M84aRSyfeCBto8IKEl/y7Il5cRD0HK0= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2056.outbound.protection.outlook.com [104.47.32.56]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-290-e-ISAKRjNGWIzNyNA0DiRQ-1; Mon, 06 May 2019 15:57:43 -0400 Received: from DM6PR05MB4137.namprd05.prod.outlook.com (20.176.72.22) by DM6PR05MB4156.namprd05.prod.outlook.com (20.176.72.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.11; Mon, 6 May 2019 19:57:36 +0000 Received: from DM6PR05MB4137.namprd05.prod.outlook.com ([fe80::ec6f:9ef8:4de8:41ec]) by DM6PR05MB4137.namprd05.prod.outlook.com ([fe80::ec6f:9ef8:4de8:41ec%6]) with mapi id 15.20.1878.019; Mon, 6 May 2019 19:57:36 +0000 From: Karl McGuinness To: Vittorio Bertocci CC: Vladimir Dzhuvinov , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHVBDG8PhxmatP/sk61BqZNupXK46Zef3cqgAAEC4A= Date: Mon, 6 May 2019 19:57:36 +0000 Message-ID: <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.162.34.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f5b3edc7-eb79-4147-3329-08d6d25d160a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR05MB4156; x-ms-traffictypediagnostic: DM6PR05MB4156: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(136003)(366004)(189003)(199004)(6116002)(3846002)(6506007)(53546011)(478600001)(99286004)(81156014)(102836004)(76176011)(316002)(91956017)(66446008)(76116006)(5660300002)(66946007)(73956011)(33656002)(26005)(229853002)(66556008)(64756008)(66476007)(186003)(6306002)(71200400001)(14444005)(256004)(54896002)(83716004)(6512007)(6486002)(6436002)(14454004)(966005)(71190400001)(236005)(606006)(7736002)(68736007)(11346002)(54906003)(486006)(2906002)(8936002)(66066001)(8676002)(81166006)(476003)(2616005)(446003)(82746002)(86362001)(36756003)(561944003)(25786009)(4326008)(6246003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4156; H:DM6PR05MB4137.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kP4HFMe3Sy4QYCa/YAH2OJNTsqEc9VlQwzFTtG8vc2PGORAW+naXdvCtY+Xktb8QMKL/XydRERxbdREkQFE3NPPdERLk2vZID6qTB7WQlTa5uDmCrGm+PZHUS/3l1LloLvGKS5tcIL6jRvu6Rk6aXZhM0ICwkbEVt5tgfJvm+uOyQSY7cVzZvLVW24N+rqxcf1fQNzlxVAQGBExbUbNJybDtb0zyKUp/+2twKSyKjGeEGJT9ESv0cxwPTCP92UvVcIcnrfHwMxP49ESxZ3H/7X0SvXlMG8wNiYkPzMFYfp6j2Pu4cxDvIQX3Lw7H2LZDskilfq8U37ejfY/omxwlZtPUoAuWHVxlQ+JrBkRrxZtrvR2CA8ANkxAFYEeXsr9TX0arJCyxE9h4PlJS42wPrKexJByLU1sYDjLk5mSbI00= MIME-Version: 1.0 X-OriginatorOrg: okta.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5b3edc7-eb79-4147-3329-08d6d25d160a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2019 19:57:36.1533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f1f9fcc4-c616-4261-8a82-855dc9cb8486 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4156 X-MC-Unique: e-ISAKRjNGWIzNyNA0DiRQ-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_2C153797C5AD410DA52EB87DBA19DF99oktacom_" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:57:53 -0000 --_000_2C153797C5AD410DA52EB87DBA19DF99oktacom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TWFrZXMgc2Vuc2UgdGhhdCB3ZSBkb27igJl0IHdhbnQgdG8gZnVydGhlciBjb3VwbGUgQVMgYW5k IFJTIHdpdGggZ3JhbnQgdHlwZXMuICBJ4oCZbSBPSyBpZiB3ZSB3YW50IGEgZGVkaWNhdGVkIGNs YWltIHRvIGVzdGFibGlzaCB3aGV0aGVyIHRoZSB0b2tlbiBpcyByZXNvdXJjZSBvd25lciBkZWxl Z2F0ZWQgIHZzIGNsaWVudCBhY3RpbmcgYXMgaXRzZWxmLg0KDQpTdWJqZWN0IFR5cGUgaXMgYWxy ZWFkeSBhIGNvbmNlcHQgaW4gUklTQy4gIEp1c3QgbWFraW5nIGZvbGtzIGFyZSBhd2FyZSBvZiBw cmlvciBhcnQuDQoNCmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC1ldmVudC10eXBlcy0x XzAtMDEuaHRtbCNyZmMuc2VjdGlvbi4yLjINCmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVu aWQtcmlzYy1wcm9maWxlLTFfMC5odG1sI3JmYy5zZWN0aW9uLjIuMQ0KDQotS2FybA0KDQpPbiBN YXkgNiwgMjAxOSwgYXQgMTI6NDIgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZWQgb3V0c2lkZSB5b3Vy IG9yZ2FuaXphdGlvbi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGYWlyIGVu b3VnaCEgV2hhdCBvdGhlcnMgdGhpbmsgYWJvdXQgaXQ/DQpFeHBsb3JpbmcgdGhlIGFwcHJvYWNo OiB3b3VsZCB3ZSB3YW50IGEgYm9vbCBjbGFpbSBvciBhbiBlbnVtZXJhdGlvbiwgZS5nLiBzdWJf dHlwZSA9IFsgcmVzb3VyY2Vfb3duZXIgfCBjbGllbnQgXSA/DQoNCg0KT24gTW9uLCBNYXkgNiwg MjAxOSBhdCAxMjozNSBQTSBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQu Y29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KSGkgVml0dG9yaW8s DQoNCk9uIDA2LzA1LzIwMTkgMjI6MjIsIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOg0KPiBJdCBp cyB0cnVlIHRoYXQgdGhlIGdyYW50X3R5cGUgaXMgYSBjbGllbnQgc2lkZSBjb25zaWRlcmF0aW9u LiBJIGRpZCB0aGluaw0KPiBhYm91dCB0aGUgImNsaWVudF9pZD09c3ViIiBoZXVyaXN0aWMsIGJ1 dCB0aGF0J3Mgbm90IGFsd2F5cyBhcHBsaWNhYmxlOg0KPiBtYW55IHN5c3RlbXMgaGF2ZSB0aGVp ciBvd24gcnVsZXMgZm9yIGdlbmVyYXRpbmcgc3ViLCBhbmQgaW4gY2FzZSB0aGV5IHdhbnQNCj4g dG8gcHJldmVudCB0cmFja2luZyBhY3Jvc3MgUlNlcyB0aGUgc3ViIG1pZ2h0IGJlIGdlbmVyYXRl ZCBhZC1ob2MgZm9yIHRoYXQNCj4gcGFydGljdWxhciBSUy4NCj4gV291bGQgeW91IHByZWZlciB0 byBoYXZlIGEgZGVkaWNhdGVkIGNsYWltIHRoYXQgZGlzdGluZ3Vpc2ggYmV0d2VlbiB1c2VyDQo+ IGFuZCBhcHAgdG9rZW5zIHJhdGhlciB0aGFuIHJldXNpbmcgZ3JhbnRfdHlwZT8NCg0KQSBkZWRp Y2F0ZWQgY2xhaW0gdG8gZmxhZyBjbGllbnRfaWQgZWZmZWN0aXZlbHkgPT0gc3ViIHdvdWxkIGJl DQpwcmVmZXJhYmxlLCBhbmQgbXVjaCBlYXNpZXIgZm9yIFJTIGRldmVsb3BlcnMgdG8gcHJvY2Vz cy4NCg0KVGhlIEFTIGlzIHRoZSBhdXRob3JpdHkgYW5kIGhhcyBhbGwgdGhlIGtub3dsZWRnZSB0 byBzZXQgLyBpbmRpY2F0ZSB0aGlzLg0KDQpJIHdhbnQgdG8ga2VlcCBSUyBkZXZlbG9wZXJzIGF3 YXkgZnJvbSBoYXZpbmcgdG8gZGVhbCB3aXRoIGdyYW50IHR5cGVzDQphbmQgaGF2aW5nIHRvIG1h a2UgZGVjaXNpb25zIHdoZXRoZXIgY2xpZW50X2lkIGVmZmVjdGl2ZWx5ID09IHN1Yi4NCg0KVmxh ZGltaXINCg0KDQo+IE9uIE1vbiwgTWF5IDYsIDIwMTkgYXQgMTI6MTYgUE0gVmxhZGltaXIgRHpo dXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp ZC5jb20+Pg0KPiB3cm90ZToNCj4NCj4+IE9uIDA2LzA1LzIwMTkgMjA6MzIsIFZpdHRvcmlvIEJl cnRvY2NpIHdyb3RlOg0KPj4+IFRvIHRoYXQgZW5kLCAqS2FybCBNQ0d1aW5uZXNzIHN1Z2dlc3Rl ZCB0aGF0IHdlIGluY2x1ZGUNCj4+PiBncmFudF90eXBlIGFzIGEgcmV0dXJuIGNsYWltLCB3aGlj aCB0aGUgUlMgY291bGQgdXNlIHRvIHRoZSBzYW1lDQo+PiBlZmZlY3QqLiBJDQo+Pj4gZmluZCB0 aGUgcHJvcG9zYWwgdmVyeSBjbGV2ZXIsIGFuZCB0aGUgcGVvcGxlIGF0IElJVyB0aG91Z2h0IHNv IGFzIHdlbGwuDQo+Pj4gV2hhdCB5b3UgdGhpbms/DQo+PiBUaGUgZ3JhbnQgdHlwZSBpcyBub3Qg c29tZXRoaW5nIHRoYXQgdGhlIFJTIGlzIHJlYWxseSBjb25jZXJuZWQgd2l0aCwgb3INCj4+IHNo b3VsZCBiZS4gSW50cm9kdWNpbmcgdGhpcyBwYXJhbWV0ZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiB3 aWxsIGNyZWF0ZSBhbg0KPj4gYWRkaXRpb25hbCBsb2dpY2FsIGRlcGVuZGVuY3ksIHBsdXMgY29t cGxleGl0eSAtIGluIHRoZSBzeXN0ZW0gb2YNCj4+IGNsaWVudCwgQVMgYW5kIFJTIGFzIGEgd2hv bGUsIGFzIHdlbGwgYXMgZm9yIFJTIGRldmVsb3BlcnMuIFRoZSBncmFudA0KPj4gdHlwZSwgYXMg YSBjb25jZXB0LCBpcyBhIG1hdHRlciBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIEFTLCBhbmQgSU1P DQo+PiBzaG91bGQgc3RheSB0aGF0IHdheS4NCj4+DQo+PiBDbGVhciBsYW5ndWFnZSBpbiB0aGUg c3BlYyBzaG91bGQgc3VmZmljZS4gRm9yIGluc3RhbmNlOiAiSWYgdGhlIHN1Yg0KPj4gdmFsdWUg bWF0Y2hlcyB0aGUgY2xpZW50X2lkIHZhbHVlLCB0aGVuIHRoZSBzdWJqZWN0IGlzIHRoZSBjbGll bnQNCj4+IGFwcGxpY2F0aW9uIi4NCj4+DQo+PiBWbGFkaW1pcg0KPj4NCj4+IC0tDQo+PiBWbGFk aW1pciBEemh1dmlub3YNCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPg0KPj4NCi0tDQpWbGFkaW1pciBEemh1dmlub3YNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_2C153797C5AD410DA52EB87DBA19DF99oktacom_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWFrZXMgc2Vuc2UgdGhh dCB3ZSBkb27igJl0IHdhbnQgdG8gZnVydGhlciBjb3VwbGUgQVMgYW5kIFJTIHdpdGggZ3JhbnQg dHlwZXMuICZuYnNwO0nigJltIE9LIGlmIHdlIHdhbnQgYSBkZWRpY2F0ZWQgY2xhaW0gdG8gZXN0 YWJsaXNoIHdoZXRoZXIgdGhlIHRva2VuIGlzIHJlc291cmNlIG93bmVyIGRlbGVnYXRlZCAmbmJz cDt2cyBjbGllbnQgYWN0aW5nIGFzIGl0c2VsZi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQpTdWJqZWN0IFR5cGUgaXMgYWxyZWFkeSBhIGNvbmNlcHQgaW4gUklT Qy4gJm5ic3A7SnVzdCBtYWtpbmcgZm9sa3MgYXJlIGF3YXJlIG9mIHByaW9yIGFydC4gJm5ic3A7 DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBo cmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtZXZlbnQtdHlwZXMtMV8wLTAxLmh0 bWwjcmZjLnNlY3Rpb24uMi4yIiBjbGFzcz0iIj5odHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb2F1 dGgtZXZlbnQtdHlwZXMtMV8wLTAxLmh0bWwjcmZjLnNlY3Rpb24uMi4yPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLXJpc2Mt cHJvZmlsZS0xXzAuaHRtbCNyZmMuc2VjdGlvbi4yLjEiIGNsYXNzPSIiPmh0dHBzOi8vb3Blbmlk Lm5ldC9zcGVjcy9vcGVuaWQtcmlzYy1wcm9maWxlLTFfMC5odG1sI3JmYy5zZWN0aW9uLjIuMTwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPi1LYXJsPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWF5IDYsIDIwMTksIGF0IDEy OjQyIFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlZpdHRvcmlvPTQw YXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiBjbGFzcz0iIj5WaXR0b3Jpbz00MGF1dGgwLmNvbUBk bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtYy1pcC1oaWRl Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgdGV4dC1hbGlnbjogbGVmdDsgZm9udC1m YW1pbHk6IEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzdHJvbmcg Y2xhc3M9IiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZWQgb3V0c2lkZSB5b3VyIG9yZ2FuaXphdGlv bi48L3N0cm9uZz48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxociBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+RmFpciBlbm91Z2ghIFdoYXQgb3RoZXJzIHRoaW5rIGFi b3V0IGl0Pw0KPGRpdiBjbGFzcz0iIj5FeHBsb3JpbmcgdGhlIGFwcHJvYWNoOiB3b3VsZCB3ZSB3 YW50IGEgYm9vbCBjbGFpbSBvciBhbiBlbnVtZXJhdGlvbiwgZS5nLiBzdWJfdHlwZSA9IFsgcmVz b3VyY2Vfb3duZXIgfCBjbGllbnQgXSA/PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24g TW9uLCBNYXkgNiwgMjAxOSBhdCAxMjozNSBQTSBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhy ZWY9Im1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSIgY2xhc3M9IiI+dmxhZGltaXJAY29u bmVjdDJpZC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4N CkhpIFZpdHRvcmlvLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDA2LzA1LzIwMTkg MjI6MjIsIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgSXQgaXMg dHJ1ZSB0aGF0IHRoZSBncmFudF90eXBlIGlzIGEgY2xpZW50IHNpZGUgY29uc2lkZXJhdGlvbi4g SSBkaWQgdGhpbms8YnIgY2xhc3M9IiI+DQomZ3Q7IGFib3V0IHRoZSAmcXVvdDtjbGllbnRfaWQ9 PXN1YiZxdW90OyBoZXVyaXN0aWMsIGJ1dCB0aGF0J3Mgbm90IGFsd2F5cyBhcHBsaWNhYmxlOjxi ciBjbGFzcz0iIj4NCiZndDsgbWFueSBzeXN0ZW1zIGhhdmUgdGhlaXIgb3duIHJ1bGVzIGZvciBn ZW5lcmF0aW5nIHN1YiwgYW5kIGluIGNhc2UgdGhleSB3YW50PGJyIGNsYXNzPSIiPg0KJmd0OyB0 byBwcmV2ZW50IHRyYWNraW5nIGFjcm9zcyBSU2VzIHRoZSBzdWIgbWlnaHQgYmUgZ2VuZXJhdGVk IGFkLWhvYyBmb3IgdGhhdDxiciBjbGFzcz0iIj4NCiZndDsgcGFydGljdWxhciBSUy48YnIgY2xh c3M9IiI+DQomZ3Q7IFdvdWxkIHlvdSBwcmVmZXIgdG8gaGF2ZSBhIGRlZGljYXRlZCBjbGFpbSB0 aGF0IGRpc3Rpbmd1aXNoIGJldHdlZW4gdXNlcjxiciBjbGFzcz0iIj4NCiZndDsgYW5kIGFwcCB0 b2tlbnMgcmF0aGVyIHRoYW4gcmV1c2luZyBncmFudF90eXBlPzxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkEgZGVkaWNhdGVkIGNsYWltIHRvIGZsYWcgY2xpZW50X2lkIGVmZmVjdGl2ZWx5 ID09IHN1YiB3b3VsZCBiZTxiciBjbGFzcz0iIj4NCnByZWZlcmFibGUsIGFuZCBtdWNoIGVhc2ll ciBmb3IgUlMgZGV2ZWxvcGVycyB0byBwcm9jZXNzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NClRoZSBBUyBpcyB0aGUgYXV0aG9yaXR5IGFuZCBoYXMgYWxsIHRoZSBrbm93bGVkZ2UgdG8g c2V0IC8gaW5kaWNhdGUgdGhpcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdhbnQg dG8ga2VlcCBSUyBkZXZlbG9wZXJzIGF3YXkgZnJvbSBoYXZpbmcgdG8gZGVhbCB3aXRoIGdyYW50 IHR5cGVzPGJyIGNsYXNzPSIiPg0KYW5kIGhhdmluZyB0byBtYWtlIGRlY2lzaW9ucyB3aGV0aGVy IGNsaWVudF9pZCBlZmZlY3RpdmVseSA9PSBzdWIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KVmxhZGltaXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQom Z3Q7IE9uIE1vbiwgTWF5IDYsIDIwMTkgYXQgMTI6MTYgUE0gVmxhZGltaXIgRHpodXZpbm92ICZs dDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgT24g MDYvMDUvMjAxOSAyMDozMiwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmZ3Q7IFRvIHRoYXQgZW5kLCAqS2FybCBNQ0d1aW5uZXNzIHN1Z2dlc3RlZCB0aGF0 IHdlIGluY2x1ZGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgZ3JhbnRfdHlwZSBhcyBhIHJl dHVybiBjbGFpbSwgd2hpY2ggdGhlIFJTIGNvdWxkIHVzZSB0byB0aGUgc2FtZTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IGVmZmVjdCouIEk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgZmluZCB0 aGUgcHJvcG9zYWwgdmVyeSBjbGV2ZXIsIGFuZCB0aGUgcGVvcGxlIGF0IElJVyB0aG91Z2h0IHNv IGFzIHdlbGwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IFdoYXQgeW91IHRoaW5rPzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IFRoZSBncmFudCB0eXBlIGlzIG5vdCBzb21ldGhpbmcgdGhhdCB0 aGUgUlMgaXMgcmVhbGx5IGNvbmNlcm5lZCB3aXRoLCBvcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IHNob3VsZCBiZS4gSW50cm9kdWNpbmcgdGhpcyBwYXJhbWV0ZXIgaW4gdGhlIGFjY2VzcyB0b2tl biB3aWxsIGNyZWF0ZSBhbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGFkZGl0aW9uYWwgbG9naWNh bCBkZXBlbmRlbmN5LCBwbHVzIGNvbXBsZXhpdHkgLSBpbiB0aGUgc3lzdGVtIG9mPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgY2xpZW50LCBBUyBhbmQgUlMgYXMgYSB3aG9sZSwgYXMgd2VsbCBhcyBm b3IgUlMgZGV2ZWxvcGVycy4gVGhlIGdyYW50PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgdHlwZSwg YXMgYSBjb25jZXB0LCBpcyBhIG1hdHRlciBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIEFTLCBhbmQg SU1PPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgc2hvdWxkIHN0YXkgdGhhdCB3YXkuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBDbGVhciBsYW5ndWFnZSBpbiB0 aGUgc3BlYyBzaG91bGQgc3VmZmljZS4gRm9yIGluc3RhbmNlOiAmcXVvdDtJZiB0aGUgc3ViPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgdmFsdWUgbWF0Y2hlcyB0aGUgY2xpZW50X2lkIHZhbHVlLCB0 aGVuIHRoZSBzdWJqZWN0IGlzIHRoZSBjbGllbnQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBhcHBs aWNhdGlvbiZxdW90Oy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IFZsYWRpbWlyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAtLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFZsYWRpbWlyIER6aHV2aW5vdjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCi0t IDxiciBjbGFzcz0iIj4NClZsYWRpbWlyIER6aHV2aW5vdjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_2C153797C5AD410DA52EB87DBA19DF99oktacom_-- From nobody Mon May 6 13: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 3D2D81201D7 for ; Mon, 6 May 2019 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dc-DEHOHpHBZ for ; Mon, 6 May 2019 13:42:12 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id C5915120175 for ; Mon, 6 May 2019 13:42:11 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:d54:39a7:6ba1:58a5] (unknown [IPv6:2601:282:202:b210:d54:39a7:6ba1:58a5]) by alkaline-solutions.com (Postfix) with ESMTPSA id 5A814316B2; Mon, 6 May 2019 20:42:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: David Waite In-Reply-To: <11125817.AKI43N3Yza@papegaaij> Date: Mon, 6 May 2019 14:42:09 -0600 Cc: oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <11125817.AKI43N3Yza@papegaaij> To: Emond Papegaaij X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps 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, 06 May 2019 20:42:14 -0000 On May 6, 2019, at 1:42 PM, Emond Papegaaij = wrote: >=20 > Hi all, >=20 > For a browser-based app, we try to follow the recommendations set in = draft- > ietf-oauth-browser-based-apps-01. This does allow us to create a = secure OAuth=20 > 2.0 browser-based application, but at the moment it comes at a cost = wrt. user=20 > experience when the access token expires. Our current solution forces = us to=20 > redirect the user to the authorization server for a new authorization = code.=20 > This will destroy most state the browser-based app has, causing the = user to=20 > loose data. We are looking for a way to get a new access token in a = secure way=20 > without disrupting the user. > As a refresh token is not issued to the app (as it should be), the = application=20 > is forced to do a front-channel re-authentication for an authorization = code.=20 > We are thinking of letting this front-channel communication happen in = a hidden=20 > iframe. Naturally, this can only be done if no user interaction is = required,=20 > hence we want to use the OIDC prompt=3Dnone. Is this a viable way of = doing this=20 > re-authentication? Can it hurt to open up our authorization server for = non- > interactive authorization requests inside an iframe? At the moment we = do not=20 > allow iframes at all. Some AS implementations will block authentication in an iframe, but will = allow you to use the OIDC prompt=3Dnone. This is already used quite = often today by implicit apps. It is possible that AS implementations may = allow iframes in the future, by detecting the frame is not covered with = any buttons, and having the authentication be based on = phishing-resistant authentication methods like W3C Web Authentication. You could also trigger re-authorization with a user click, thus allowing = opening the AS in a new window or tab. Once back on the site via = callback, the temporary/pop-up window can do things like exchange the = code for an access token, persist it, postMessage the original window, = do window.close, etc. The iframe and pop-up methods together can be used in lieu of persisting = state across a redirect to the ISP. Many apps after reaching a = sufficient level of complexity just wind up persisting the page state in = some combination of local and remote storage, however. Javascript state = is very brittle and will be broken by things as simple as a page = refresh. Native apps which opened the system browser had at least the capability = of this problem as well - the application could be unloaded from = memory/quit between when authentication started and ended. On the other hand, refresh tokens IMHO are given quite a bit more fear = in browser apps than warranted. It really depends on the AS - whether it = can tie refresh tokens to the user=E2=80=99s authentication, or if they = are tied to a long-term / persisted / "offline=E2=80=9D authorization = independent of an active user authentication. Currently, the latter is = more common in implementations, and doesn=E2=80=99t make sense for = browser applications. This doesn=E2=80=99t mean refresh tokens are = automatically discounted for all environments. Given the choice between an 8 hour access token, or a 10 minute access = token and a refresh token that will expire at a maximum of 8 hours, the = second provides quite a few more options to be more secure. (eg. = checking backing user session and revocation, checking for updates to = client blacklist, the rotation of the access token, rotating refresh = tokens to prevent use by more than one client, expiring access on = inactivity based on lag in refreshing, and so on). If the refresh token is tied to the AS concept of user session, then it = mostly replaces the =E2=80=98hidden iframe=E2=80=99 use above - you=E2=80=99= ll only have your refresh token expire when the AS is asking for user = presence on the front channel, presumably for interaction. Although, I = suppose in some environments there could be a non-interactive = reauthentication/factor as well (such as kerberos, MTLS, or re-verifying = user location via geoip) where a hidden iframe might still provide UX = benefit. Browser based apps are significantly more vulnerable to code injection = attacks than native apps (although don=E2=80=99t believe native apps are = immune), so it may make sense for an AS to have a stricter default = policy for browser-based applications than they would have for a native = app. It also could make sense to allow for more scopes or longer-lived = tokens for an audited, first-party browser-based application. = Restrictions may be opened up even more for applications/browsers which = also use PoP methods to prevent key exfiltration. OAuth is nice in that the AS consolidates those responsibilities, = however the flip side of that is that a client developer is really = dependent on an AS to provide a combination of features juggling good = security and user experience. > Maybe anybody knows a different way of achieving this? As I cannot = believe we=20 > are the only ones facing this issue, maybe a recommendation can be put = in the=20 > spec? I think so far it has been an omission since this isn=E2=80=99t a = =E2=80=9Cnew=E2=80=9D problem - implicit has the same issues and a = subset of techniques (the difference bineg the capability to use refresh = tokens now). However, it makes sense to document current practices in a = BCP document :-) WRT refresh tokens: I=E2=80=99m at the start of an independent blog post = on considering token policies and lifetimes, but I expect it to take = some time to polish and to get through reviewer feedback before = publishing. -DW= From nobody Mon May 6 13:43:15 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 757E1120073 for ; Mon, 6 May 2019 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vzxb_5228AHk for ; Mon, 6 May 2019 13:43:10 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 876F5120175 for ; Mon, 6 May 2019 13:43:10 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id o7so4539036qtp.4 for ; Mon, 06 May 2019 13:43:10 -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=taxABgpNumEryPEP1BnotoiTqXavd5Vo83zOINb6YwU=; b=AC8ri97gTjNpADyE39RFWIQHF61ZsQjpAcwOctNBrNh0MQ38Vqc4yBmi/dnhDWvzML fA4TX4j3cbG81KXFF6JvcKa79rh2R4ma4KVm4/MwErLE4Ex1OAmQU/ERKfryaRDxLJDr 6g1/LKCIkTyeVTX2MHQgluo5d79amYxpGpSLS1grPLGfSeCm2dY3RuUO4DepuUDIlRRK kbUJS7yyTLERO8M9TE1jLE5xVVQFvDKdUDpGl5Uv2Lc3+5yn2iA3hnvDKLm5Ba4b3x5r sKmnuedcQVPUheDTWkgCFqhdQxYSfTPmi2hv5hcEbXW6K/gH9l5n4dDui0Mbznafwqn1 EmXw== 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=taxABgpNumEryPEP1BnotoiTqXavd5Vo83zOINb6YwU=; b=LLgzjoEHi6MOyQdMxGp/vteEfcn8hxv9Uy5L7imhWGkt3c6geuEz0iP4qPj2QTbZ+y fGpwyCO30fNVk/dGt4J9GndkwDl9MPHJh0ihzGcigrCy1kLktrtMH6zwxpJf4cjhdoqN UKLJSGAcvcy0CNnF0UW7AToHPVUueCMKINQeJiYf+c9Vh7MOvMt7X5RbC3gFLNUty8Qq UBrlSF+U5ZBra0xLKEhcb7A+Pn5OftICcXRBZqe/KjZrKUFkqgR0Bv3AMlrPqGPjwh+0 gEo6NjrOntDAVNFfbPGaPd1MWXhTZFA+XI7RrZvicEI/484ZdfvwYd8WrJxOyrANII+Y 9ywA== X-Gm-Message-State: APjAAAW1/KnKrO5E4q0w46BNc6JDQPImRmvN/jW1amt+jQnO3UocBOAM wcOlhjTQGcFw6UcNycszFZTweoupLHPz9PSjT5A0mg== X-Google-Smtp-Source: APXvYqxdDt+nhbezzbXcTHNr9eNdMXFlcCSugbgCCoweH4rQ7cC2SEsBdzyM9NfXgiPcCXiJ0yXsLR2FjFvkACeTaqk= X-Received: by 2002:ac8:851:: with SMTP id x17mr23571338qth.373.1557175389414; Mon, 06 May 2019 13:43:09 -0700 (PDT) MIME-Version: 1.0 References: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@mit.edu> In-Reply-To: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@mit.edu> From: Hans Zandbelt Date: Mon, 6 May 2019 21:42:58 +0100 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f07cc105883e25cd" Archived-At: Subject: Re: [OAUTH-WG] XYZ and Transactional OAuth 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, 06 May 2019 20:43:14 -0000 --000000000000f07cc105883e25cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OAuth 2.0 has its merits and will be around for the next 20 years or so; yet we're bumping into its limitations every day if not only for its complexity and the incomprehensibility for regular IT peeps that don't have the full historical background; support for transactions is obviously missing today; I'm in for simplifying things, collapsing request parameters, use cases, PCKE, POP etc. in a non-backwards compatible protocol and suggest to adopt something similar to what you propose to become OAuth 3.0 (there, I said it ;-)) Hans. On Mon, May 6, 2019 at 8:44 PM Justin Richer wrote: > In a vein related to Torsten=E2=80=99s recent thread and blog post, I=E2= =80=99ve also been > working on a proposal around Transactional OAuth. As many of you know, I > wrote a blog post about the basic idea last fall, and now I=E2=80=99ve go= t > something a bit more concrete online that people can poke around with. I= =E2=80=99m > calling it =E2=80=9CXYZ=E2=80=9D just to give it a name, and it=E2=80=99s= online here: > > https://oauth.xyz/ > > I need to be very clear: This is not wire-compatible with OAuth2, but is > instead a transactional (intent-pattern) protocol that implements a lot o= f > the core concepts and a few new ones in a different framework. There have > been a lot of attempts to extend and adapt OAuth in the last few years, a= nd > in my opinion that=E2=80=99s gotten us painted into a bit of a corner as = we keep > trying to solve new problems. By breaking away from backwards > compatibility, I found that was able to both simplify a lot of the > concepts, make different actions more consistent, and make it more widely > flexible. > > Also to note, I=E2=80=99ve read through Torsten=E2=80=99s draft, and I th= ink that his > ideas of what=E2=80=99s in a =E2=80=9CStructured Scope=E2=80=9D could be = a replacement for the > hand-waving idea I have in the =E2=80=9Cresources=E2=80=9D section of XYZ= . I=E2=80=99m continuing > development of this protocol, including a couple toy implementations, all > of them open source. I have started a writeup in spec-language, and I pla= n > to have it cleaned up and submitted prior to Montreal =E2=80=94 where I= =E2=80=99ll be > attending in person and hope to discuss this as a potential WG item. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000f07cc105883e25cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OAuth 2.0 has its merits and will be arou= nd for the next 20 years or so; yet we're bumping into its limitations = every day if not only for its complexity and the incomprehensibility=C2=A0f= or regular IT peeps that don't have the full historical background; sup= port for transactions is obviously missing today; I'm in for simplifyin= g things, collapsing request parameters, use cases, PCKE, POP etc. in a non= -backwards compatible protocol and suggest to adopt something similar to wh= at you propose to become OAuth 3.0 (there, I said it ;-))

Hans.

On Mon, May 6, 2019 at 8:44 PM Justin Richer <jricher@mit.edu> wrote:
In a vein related to Torsten=E2=80=99s recent thread and blog post, I=E2=80= =99ve also been working on a proposal around Transactional OAuth. As many o= f you know, I wrote a blog post about the basic idea last fall, and now I= =E2=80=99ve got something a bit more concrete online that people can poke around with. I=E2=80=99m calling it =E2=80=9CXYZ=E2=80=9D = just to give it a name, and it=E2=80=99s online here:


I need to be very clear: This is not wire-compatible with OAuth2, but = is instead a transactional (intent-pattern) protocol that implements a lot = of the core concepts and a few new ones in a different framework. There hav= e been a lot of attempts to extend and adapt OAuth in the last few years, and in my opinion that=E2= =80=99s gotten us painted into a bit of a corner as we keep trying to solve= new problems. By breaking away from backwards compatibility, I found that = was able to both simplify a lot of the concepts, make different actions more consistent, and make it more widely flexible.= =C2=A0

Also to note, I=E2=80=99ve read through Torsten=E2=80=99s draft, and I= think that his ideas of what=E2=80=99s in a =E2=80=9CStructured Scope=E2= =80=9D could be a replacement for the hand-waving idea I have in the =E2=80= =9Cresources=E2=80=9D section of XYZ. I=E2=80=99m continuing development of= this protocol, including a couple toy implementations, all of them open source. I have st= arted a writeup in spec-language, and I plan to have it cleaned up and subm= itted prior to Montreal =E2=80=94 where I=E2=80=99ll be attending in person= and hope to discuss this as a potential WG item.

=E2=80=94 Justin

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


--
--000000000000f07cc105883e25cd-- From nobody Mon May 6 13:48: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 4F225120073 for ; Mon, 6 May 2019 13:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 8zfBS-1g7ySz for ; Mon, 6 May 2019 13:48:06 -0700 (PDT) Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 D4B461200EA for ; Mon, 6 May 2019 13:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557175684; bh=zvwyTCN/lagHlD9K/mXLuu8cGIR+DTjpXe2aO6A0CIw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=reVzHaXBso97Abuhyuh1UBBzrkG+HCDpIOqMkpYCPi5oN66nhVF/WXCygFMaOqaX6XDQuyMygjI58UgAnvlowWPSsp42idi7D+sEh801/r1Byx6etTR3OqxHf3gL25/1bsx2o5Gm/BEXmgnnS8EOUefPljVHn6fYzbzaA9iXtP8X9p3Cs04ODY4IhWdjO8H2GJS/StQMeNPp8dudH6FGwvowmKbiNb1B53sjM5Nf20fM12VboJNVJzkE0P64jDp+NJrVtkGfajPWLucBe/zassZ/ii4axKLEifInFrj8q5PabvRnzFFyE0aQoDwQeJjMMBkipFvqGqqIqYZwvGnJXA== X-YMail-OSG: OOS4R08VM1nUbOs4kuZ_4GU.hBsHyHuCIMXcrYvxG5pVCHVqlRU3l6bc4.YXpgX RiiYce4hP4Dw.44r3RSVs.pfDowsAfh1l_QX1H4u9BpBM_CognfnI8HkqO5Fqj5VNEI8WOMGMYUu MrGW6FXdPIIRBh3R2yrNrKr4QaJHmCMGTbXPBlxA6z6xi0hhGtikBoc.SBKCA8CaGyIp5zNruGBf B_lkbIdKrD4d__bTCtmh0UH8A06UAgcJtB0Cerb8WP2z.JX1beB9zNfvwiDnAsayh.QjVW2f9Up6 78m0y1fIWjTJ2x2APrebx9A40jo3A2DpSmambnNhV2AzrDfXuN0h7SzhgghPcR_oVWoiPGvrUUYn d_2d3FbCvLX_aUGgz68MBz8UjYf3pwrwnlph4GG8rdnLMnzRoBmZc1fGGIRiUvH32YXgPb1aU9v. ovhbJJf6YngXrC8c8_JijWrHinGyGYqxpLwa3lQWfQtJi4lStPM_hqb.4tAkGYyTOk9oXApANsl1 GqynRNMj7M2mx188EY5Es6FBIb.w.qzpYFgmCtNz29MCfe9EVOK9vQyIvlFW8ONbghfqIVHj2IEF jDCNFLH5WMDdPbCjGb5.lfqnlK7IKQNC_QDCTNbg_INWmBmGgRRZ7ZRmkhnWFvqW6hkAswJp31Ji rrShEwNc94TljJHIaDDWV1WfpPBstJzERHmTtVWM.VRat4Z4RQPpn3zwIp8GMENP_9hfoBrs95nd wXnCa2HWhzvBm3vERuuJUcRjpW8JHcfLR_bpi_iFjRVXB3uOFQHWQgbLn7jKdFxCWfDcRAWQDXVv VdUS59wiW6_5M0gqQ6iin2884NEBzF7Le4Ov2nSTzqBf_dF78maijnInpcdjHqWw2bieIf7UyGLI uLdboUJHf_BJiE_ubwVpIb1XFMw25CqzH78sFYY.4wYcldzTZzvILdgltrdfhnkajcd09BZriOMu lou5YEbJrcX.kmWjrkD_M6NNQ0SYy4cJZ.FL55t286mxdfUITTDB5TldlJ1oR8po0IeqRW6uhjcB C9PH5f1bS5SNrGJS2rUP7EjZgYFNuJH.hgXEtINB9ajwS3FoYLrlTi0jSb9F5izLAbqPgrN5qKah zcEtYK4NTjlZYIDZrpejoTcqRrj7Bm4p6obVKuVlKPmhAcrnILkEDpurw87NFOWKGa8bz1FdEfMI - Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 6 May 2019 20:48:04 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9fb7e5a1fbce34104e0d4f6648536fac; Mon, 06 May 2019 20:48:01 +0000 (UTC) To: Vladimir Dzhuvinov , Vittorio Bertocci Cc: IETF oauth WG References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> <88c03aa7-ba61-d0fe-97a1-b43f55d11b2d@connect2id.com> From: George Fletcher Organization: AOL LLC Message-ID: <0eac74d2-1f0c-a567-c7ff-ce64a4c1c232@aol.com> Date: Mon, 6 May 2019 16:48:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <88c03aa7-ba61-d0fe-97a1-b43f55d11b2d@connect2id.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 20:48:09 -0000 In OpenID Connect, aggregated and distributed claims are ways for the OpenID Provider to reference claims issued by other entities (e.g. attribute provider or "Issuer" in the SSI sense). There is no requirement from a spec perspective that the /userinfo endpoint be co-located with the AS. It seems to me that whether a /userinfo endpoint uses opaque or structured tokens is orthogonal to the need for access token claim definition. It may be useful reference the claims specifications in OpenID Connect as a reference for user claim values in addition to the claims defined in the JWT spec. Thanks, George On 5/6/19 3:49 PM, Vladimir Dzhuvinov wrote: > On 06/05/2019 22:26, Vittorio Bertocci wrote: >> I am not following, Vladimir. What do you mean? Can you make some examples >> to clarify? >> The userinfo is always colocated with the AS, hence I would expect most >> vendors not to use JWT for the ATs issued for userinfo access > That's what I was curious about, if there are any deployments with the > UserInfo not being co-located. > > OpenID Connect also has this exotic use case, called distributed claims: > > https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample > > If co-location is the common case, then there's really no need to spec a > JWT claim for that. > > Vladimir > > >> On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov >> wrote: >> >>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2 >>> >>> In OpenID Connect the access token is consumed by the UserInfo endpoint. >>> >>> Were there any suggestions to also spec parameter(s) for the claims >>> names (with optional locales) for release at the UserInfo endpoint? >>> >>> Vladimir >>> >>> _______________________________________________ >>> 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 Mon May 6 13:48: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 F3B42120073 for ; Mon, 6 May 2019 13:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Voe_0lxSBa_c for ; Mon, 6 May 2019 13:48:49 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 BBAC01201E3 for ; Mon, 6 May 2019 13:48:48 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id f24so6098420qtk.11 for ; Mon, 06 May 2019 13:48:48 -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=0hEFR11CgLChPFOz5KfNNKut7pgSr48ZLnR4YgrJ8HI=; b=aqTE/8wy1VGpPYCJSmViXssq4AmbmGF1lo2xzydzjpfSYBMBSaU9s6d/dnTEg7U6MO wVGDh8buEY2m6fN4n+ZmlEvV7+/W6fnfuHbL/txX/0ZyOmY2YHTtqYTclY3JWmtuRS4q wG3Z3Lxe5LkqjffWJGcjKUd/sX9FU5rX8I8hUOgERLw5VchaS4yJ4/4dwLXKp4zVrrIi x/mp8HNzhUdFjAnu9OIqihD6Pziiza3Lrvi2l1DqsyqX9pBl8RczIYTNq1dtZTJw2mGN UsE1mxZCSj1q10tMfrW9KcnFpktPvPGBLZShYhFl6UufB9u2Lg1iDcpDv201eJhUXXAC XZsQ== 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=0hEFR11CgLChPFOz5KfNNKut7pgSr48ZLnR4YgrJ8HI=; b=jAykuRdpJQLH6giKSIQigo7G/veoKQ1X8gIpK5//PASCiT7nXHFt9eydvtlBkAqRVJ pYqO2ZSwyk+ZM0o8+l3L7/8+0bth82LTn2tLShTMNDaXZ+LPw8eWHEHiqVii4YcSnFHl AMo469+zvNYpU4VChta0NDQEwHWLS60p/xScBgNbVd/2lvIuIGW6eTy8dgjk+QFsqMf6 jNTMtL2Y/s7OQ0Uzolv6oFfvPiVAHAKmu3MFVhyfEw/FG/nNKpeC1ckbZoxrhPRomThu /ZKOGyOKG4Bvuij/JevHrsmJ3ydDeA0VtSDn8dpHtoffNwOYuEujcAtradZfEqqTquFq pVFg== X-Gm-Message-State: APjAAAVBTq2MbdK0Kzx+PJP8v0IweF8bkuj5rsc8FCe4FOh/fP1Z/XOD bVybId9BJ0cgav6Aw29hfFmPZZMT41PjiOBQlRv5Xg== X-Google-Smtp-Source: APXvYqxaJ89otnkglgknckpitJRAvUXOAzH3f9LnqU3NubfQW9wRTTPpQZlbOQSubzfx/88qd184SFTIwoX2RGb0NJk= X-Received: by 2002:ac8:1bec:: with SMTP id m41mr21737519qtk.272.1557175727835; Mon, 06 May 2019 13:48:47 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> From: Hans Zandbelt Date: Mon, 6 May 2019 21:48:36 +0100 Message-ID: To: Karl McGuinness Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000001c623905883e3a5c" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 20:48:52 -0000 --0000000000001c623905883e3a5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I may be missing something but I'd argue that by requiring and comparing both "sub" and "client_id" we achieve the same semantics without a new/additional claim (barring name spacing) Hans. On Mon, May 6, 2019 at 8:58 PM Karl McGuinness wrote: > Makes sense that we don=E2=80=99t want to further couple AS and RS with g= rant > types. I=E2=80=99m OK if we want a dedicated claim to establish whether = the token > is resource owner delegated vs client acting as itself. > > Subject Type is already a concept in RISC. Just making folks are aware o= f > prior art. > > https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 > https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 > > -Karl > > On May 6, 2019, at 12:42 PM, Vittorio Bertocci < > Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: > > *This message originated outside your organization.* > ------------------------------ > Fair enough! What others think about it? > Exploring the approach: would we want a bool claim or an enumeration, e.g= . > sub_type =3D [ resource_owner | client ] ? > > > On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> Hi Vittorio, >> >> On 06/05/2019 22:22, Vittorio Bertocci wrote: >> > It is true that the grant_type is a client side consideration. I did >> think >> > about the "client_id=3D=3Dsub" heuristic, but that's not always applic= able: >> > many systems have their own rules for generating sub, and in case they >> want >> > to prevent tracking across RSes the sub might be generated ad-hoc for >> that >> > particular RS. >> > Would you prefer to have a dedicated claim that distinguish between us= er >> > and app tokens rather than reusing grant_type? >> >> A dedicated claim to flag client_id effectively =3D=3D sub would be >> preferable, and much easier for RS developers to process. >> >> The AS is the authority and has all the knowledge to set / indicate this= . >> >> I want to keep RS developers away from having to deal with grant types >> and having to make decisions whether client_id effectively =3D=3D sub. >> >> Vladimir >> >> >> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >> vladimir@connect2id.com> >> > wrote: >> > >> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >> >>> To that end, *Karl MCGuinness suggested that we include >> >>> grant_type as a return claim, which the RS could use to the same >> >> effect*. I >> >>> find the proposal very clever, and the people at IIW thought so as >> well. >> >>> What you think? >> >> The grant type is not something that the RS is really concerned with, >> or >> >> should be. Introducing this parameter in the access token will create >> an >> >> additional logical dependency, plus complexity - in the system of >> >> client, AS and RS as a whole, as well as for RS developers. The grant >> >> type, as a concept, is a matter between the client and AS, and IMO >> >> should stay that way. >> >> >> >> Clear language in the spec should suffice. For instance: "If the sub >> >> value matches the client_id value, then the subject is the client >> >> application". >> >> >> >> Vladimir >> >> >> >> -- >> >> Vladimir Dzhuvinov >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> Vladimir Dzhuvinov >> >> >> _______________________________________________ > 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 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000001c623905883e3a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I may be missing something but I'd ar= gue that by requiring and comparing both "sub" and "client_i= d" we achieve the same semantics without a new/additional claim (barri= ng name spacing)

Hans.

On Mon, May 6, 2= 019 at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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


--
--0000000000001c623905883e3a5c-- From nobody Mon May 6 14:49: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 8218712004D for ; Mon, 6 May 2019 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tku5o8_yGSFa for ; Mon, 6 May 2019 14:49:29 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADBC12002F for ; Mon, 6 May 2019 14:49:29 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id u27so9987106lfg.10 for ; Mon, 06 May 2019 14:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5B6FLB64S/vOdGSp96IvTocxea/ApiG0mk1AkK6Wwq8=; b=DlW71Ifs6LU6sODWu1ly0uYdlLKc9OjfPmV7QJtfW6yp/5R91Qll7rhS1FvJdTjRvz s6dIJZXvXdqTcW7YOpLozda6Fc14bj2Vic7DgLBpZWdKHu0eDQqHqarp09OknxFj8OpW Gzf6nrEcicg0VuVHshXzfUbwVXgp28XpFFqNrJ5OfAkXDg4t4TlPPQfrWVhwPyiZb6qC PYPXb7paT4iXXGAfLy45e0IAsnFaSW9EGIzt8CVAoKIk4UXCGimXC7HoW2fTucUNK0Jn 01A9iQHDUd7hywpGOTyV/jX6Z/DrBpUnNr3OxaQbeyh7mNETLUlD0nx/JLV84ZiLnrwi ssMA== 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=5B6FLB64S/vOdGSp96IvTocxea/ApiG0mk1AkK6Wwq8=; b=QHdhfr+P6/4Qku79nPPhfKofMFs72zqChbRt9jSPQ22/H9kUjJLU3PGiFMovZwVfO6 nXnqTCtihg/0Ie/6Foo9oPhlvKzk0siMvfk5STs39WEqP8zRcxwtmMu5r1zLyS84JOu0 7QK70cP6puzBj5HQ/O607sFoTGtUjFi0THKzO7NCtuSTNatrJjQ0EbVB3wTrXVOpacyc YzEaaCljN2SETkvDqqYFROXjdVEQZ1IDDloXJMBL8Xu5iR3PKUWztRi9TrF3C3M+3kQx 1zOtdb+ECJmdaZfPm3CbeQdSoxdmxd1kNg9msf+snVQ+RlqFuLGxoT1k3XTy4QHRvoOs G1qw== X-Gm-Message-State: APjAAAUqBV+1+QxCKQgfGZuWCjWxId0ZhKZ7ZsqqCdYD3ezLVHSvxb1B +ddfuDUp4qF95aO5cEFKaTnfsF/HU22E2ERbBRDpeQ== X-Google-Smtp-Source: APXvYqwMT5kbE5SOyAZveZq4JpHgaPzrqHSn3j12kyjEUj8zoyvjAvV8c80t+mX+u2TrFVh7/m7CjDqxi9jUIV6MlpQ= X-Received: by 2002:ac2:51a1:: with SMTP id f1mr13017102lfk.129.1557179367461; Mon, 06 May 2019 14:49:27 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 6 May 2019 14:49:16 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000000cb1c305883f13a2" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:49:32 -0000 --0000000000000cb1c305883f13a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See below, Hans- the sub doesn=E2=80=99t have to be global, it could be som= ething generated just for this particular RS. Or the AS might have its own recipe for generating sub values that different from the recipe used to generate client_ids. It would be much easier for an AS to emit a claim making this explicit statement than to change sub and client_id assignment logic. On Mon, May 6, 2019 at 13:49 Hans Zandbelt wrote: > I may be missing something but I'd argue that by requiring and comparing > both "sub" and "client_id" we achieve the same semantics without a > new/additional claim (barring name spacing) > > Hans. > > On Mon, May 6, 2019 at 8:58 PM Karl McGuinness 40okta.com@dmarc.ietf.org> wrote: > >> Makes sense that we don=E2=80=99t want to further couple AS and RS with = grant >> types. I=E2=80=99m OK if we want a dedicated claim to establish whether= the token >> is resource owner delegated vs client acting as itself. >> >> Subject Type is already a concept in RISC. Just making folks are aware >> of prior art. >> >> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 >> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >> >> -Karl >> >> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >> >> *This message originated outside your organization.* >> ------------------------------ >> Fair enough! What others think about it? >> Exploring the approach: would we want a bool claim or an enumeration, >> e.g. sub_type =3D [ resource_owner | client ] ? >> >> >> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >> vladimir@connect2id.com> wrote: >> >>> Hi Vittorio, >>> >>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>> > It is true that the grant_type is a client side consideration. I did >>> think >>> > about the "client_id=3D=3Dsub" heuristic, but that's not always appli= cable: >>> > many systems have their own rules for generating sub, and in case the= y >>> want >>> > to prevent tracking across RSes the sub might be generated ad-hoc for >>> that >>> > particular RS. >>> > Would you prefer to have a dedicated claim that distinguish between >>> user >>> > and app tokens rather than reusing grant_type? >>> >>> A dedicated claim to flag client_id effectively =3D=3D sub would be >>> preferable, and much easier for RS developers to process. >>> >>> The AS is the authority and has all the knowledge to set / indicate thi= s. >>> >>> I want to keep RS developers away from having to deal with grant types >>> and having to make decisions whether client_id effectively =3D=3D sub. >>> >>> Vladimir >>> >>> >>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>> vladimir@connect2id.com> >>> > wrote: >>> > >>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>> >>> To that end, *Karl MCGuinness suggested that we include >>> >>> grant_type as a return claim, which the RS could use to the same >>> >> effect*. I >>> >>> find the proposal very clever, and the people at IIW thought so as >>> well. >>> >>> What you think? >>> >> The grant type is not something that the RS is really concerned with= , >>> or >>> >> should be. Introducing this parameter in the access token will creat= e >>> an >>> >> additional logical dependency, plus complexity - in the system of >>> >> client, AS and RS as a whole, as well as for RS developers. The gran= t >>> >> type, as a concept, is a matter between the client and AS, and IMO >>> >> should stay that way. >>> >> >>> >> Clear language in the spec should suffice. For instance: "If the sub >>> >> value matches the client_id value, then the subject is the client >>> >> application". >>> >> >>> >> Vladimir >>> >> >>> >> -- >>> >> Vladimir Dzhuvinov >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >> >>> -- >>> Vladimir Dzhuvinov >>> >>> >>> _______________________________________________ >> 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 > --0000000000000cb1c305883f13a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
See below, Hans- the sub doesn=E2=80=99t have to be = global, it could be something generated just for this particular RS. Or the= AS might have its own recipe for generating sub values that different from= the recipe used to generate client_ids. It would be much easier for an AS = to emit a claim making this explicit statement than to change sub and clien= t_id assignment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt= <hans.zandbelt@zmartzone.= eu> wrote:
=
I may be missing something but I'd argue that by requi= ring and comparing both "sub" and "client_id" we achiev= e the same semantics without a new/additional claim (barring name spacing)<= /div>

Hans.

On Mon, May 6, 2019 at 8:58 PM Ka= rl McGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000000cb1c305883f13a2-- From nobody Mon May 6 14:54:15 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 BB8EA12006E for ; Mon, 6 May 2019 14:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8fJnVMHIOOhU for ; Mon, 6 May 2019 14:54:09 -0700 (PDT) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 091CE12001E for ; Mon, 6 May 2019 14:54:08 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id p19so5272281qkm.10 for ; Mon, 06 May 2019 14:54:08 -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=dclRodGj5e2x+jbm50yjlOPag8yfH85oQ/GSrnLowxM=; b=Voc6NzWzJFp3S9zqBSLKtJ1okYsxTOkbk2F2PjL1WZWTLWoOU/pCmqYwN+QBq61+hJ v98Sz/g8HM7tqIV2UnaMPfD+m6qvldXG6Vr5fxqkZuZj5YP+b3N++/HIBCIH9QfOEwPr KsNArQqr16QYeW4KaXW6hDY9dfsGzDFRpggjEJkvXkSdgwNpMegYBxSKo7KYZCo5y/ux LDEStZVfp4wlhuydYWlmVnASsrrCNxxikosYmAO9GGDIpmiB97LO19Uygp8aN+Eol1lH DRR/JUvzi8Ki4SS5AjJ/TTIB4rGx9dCm8qnMsnW1xx1o4Wi6BPwksM6ysdbVHvzDDusX c2ZQ== 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=dclRodGj5e2x+jbm50yjlOPag8yfH85oQ/GSrnLowxM=; b=cMtGBWdS8ou357NL+7wVD/I0yx51vPr+7HeaHaU4OejjcOti19kAHJhzKi6alNqeOG PqSqhhLQ8+lx+TYFtClW+7S18Px2dsP29xaqngcmGHH6+JFG4dUtKzwvZYG1NPf5Jh/x K5Z9qz5HWdiGCPkk/y9lRyEDkJu/Dp8YzqTTlnK6LJV41+3eWuH0RIWGK+VO4ApesgCD 0u++khup8q9Hfyd9CQ6sIKW0YcczACoPPV3PshvODlf1gw9nKF5B1EQbINSeQBjcj81E 4kRSxscXkubElzueZZiuBUj+Bc+RzD+74jcydyYby8p1MgYtt3CpOm7+cmI/FoCLXL76 1yAA== X-Gm-Message-State: APjAAAVKaf0DuTTi04FFxj3jDNqHnVACsOlTxW+p2H/TNenkinpr/Y8I itlj3I5nAI324rolSr6TMs2B9VNuxNncDdVVla7Si4XzMF8= X-Google-Smtp-Source: APXvYqyBjabP6uQswyiRwJKUJuD3RhpvUMcvaCSZztW7c2/p85OVxeEMo4piDRotXtYk2Po1TQBc4GNeLG6lbzeiy2g= X-Received: by 2002:a37:495:: with SMTP id 143mr9970845qke.106.1557179647850; Mon, 06 May 2019 14:54:07 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Hans Zandbelt Date: Mon, 6 May 2019 22:53:56 +0100 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000c3145505883f23a7" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:54:13 -0000 --000000000000c3145505883f23a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable the scope and way of generating sub/client_id is orthogonal to the semantics IMHO but if I'm the only one who thinks so, I'll rest my case Hans. On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci wrote: > See below, Hans- the sub doesn=E2=80=99t have to be global, it could be s= omething > generated just for this particular RS. Or the AS might have its own recip= e > for generating sub values that different from the recipe used to generate > client_ids. It would be much easier for an AS to emit a claim making this > explicit statement than to change sub and client_id assignment logic. > > On Mon, May 6, 2019 at 13:49 Hans Zandbelt > wrote: > >> I may be missing something but I'd argue that by requiring and comparing >> both "sub" and "client_id" we achieve the same semantics without a >> new/additional claim (barring name spacing) >> >> Hans. >> >> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness > 40okta.com@dmarc.ietf.org> wrote: >> >>> Makes sense that we don=E2=80=99t want to further couple AS and RS with= grant >>> types. I=E2=80=99m OK if we want a dedicated claim to establish whethe= r the token >>> is resource owner delegated vs client acting as itself. >>> >>> Subject Type is already a concept in RISC. Just making folks are aware >>> of prior art. >>> >>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 >>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >>> >>> -Karl >>> >>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>> >>> *This message originated outside your organization.* >>> ------------------------------ >>> Fair enough! What others think about it? >>> Exploring the approach: would we want a bool claim or an enumeration, >>> e.g. sub_type =3D [ resource_owner | client ] ? >>> >>> >>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>> >>>> Hi Vittorio, >>>> >>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>> > It is true that the grant_type is a client side consideration. I did >>>> think >>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>> applicable: >>>> > many systems have their own rules for generating sub, and in case >>>> they want >>>> > to prevent tracking across RSes the sub might be generated ad-hoc fo= r >>>> that >>>> > particular RS. >>>> > Would you prefer to have a dedicated claim that distinguish between >>>> user >>>> > and app tokens rather than reusing grant_type? >>>> >>>> A dedicated claim to flag client_id effectively =3D=3D sub would be >>>> preferable, and much easier for RS developers to process. >>>> >>>> The AS is the authority and has all the knowledge to set / indicate >>>> this. >>>> >>>> I want to keep RS developers away from having to deal with grant types >>>> and having to make decisions whether client_id effectively =3D=3D sub. >>>> >>>> Vladimir >>>> >>>> >>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>> vladimir@connect2id.com> >>>> > wrote: >>>> > >>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>> >>> To that end, *Karl MCGuinness suggested that we include >>>> >>> grant_type as a return claim, which the RS could use to the same >>>> >> effect*. I >>>> >>> find the proposal very clever, and the people at IIW thought so as >>>> well. >>>> >>> What you think? >>>> >> The grant type is not something that the RS is really concerned >>>> with, or >>>> >> should be. Introducing this parameter in the access token will >>>> create an >>>> >> additional logical dependency, plus complexity - in the system of >>>> >> client, AS and RS as a whole, as well as for RS developers. The gra= nt >>>> >> type, as a concept, is a matter between the client and AS, and IMO >>>> >> should stay that way. >>>> >> >>>> >> Clear language in the spec should suffice. For instance: "If the su= b >>>> >> value matches the client_id value, then the subject is the client >>>> >> application". >>>> >> >>>> >> Vladimir >>>> >> >>>> >> -- >>>> >> Vladimir Dzhuvinov >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>> >> >>>> -- >>>> Vladimir Dzhuvinov >>>> >>>> >>>> _______________________________________________ >>> 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 >> > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000c3145505883f23a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the scope and way of generating sub/client_id is orthogona= l to the semantics IMHO but if I'm the only one who thinks so, I'll= rest my case

Hans.

On Mon, May 6, 2019 at 10:49 PM= Vittorio Bertocci <Vittorio@auth0= .com> wrote:
See below, Hans- the sub doesn=E2=80=99t have to= be global, it could be something generated just for this particular RS. Or= the AS might have its own recipe for generating sub values that different = from the recipe used to generate client_ids. It would be much easier for an= AS to emit a claim making this explicit statement than to change sub and c= lient_id assignment logic.

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 6, 2019 at 13:49 Hans Zand= belt <ha= ns.zandbelt@zmartzone.eu> wrote:
I may be missing = something but I'd argue that by requiring and comparing both "sub&= quot; and "client_id" we achieve the same semantics without a new= /additional claim (barring name spacing)

Hans.

On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dma= rc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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


--
--000000000000c3145505883f23a7-- From nobody Mon May 6 15:06: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 E68681201D2 for ; Mon, 6 May 2019 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcmubtz46Nts for ; Mon, 6 May 2019 15:06:30 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D551201FA for ; Mon, 6 May 2019 15:06:29 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id y19so2712693lfy.5 for ; Mon, 06 May 2019 15:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mjuabSVgvQATDuvn4ZjOwSzMxXjqV/2qQSyFCohQixI=; b=YIiZFN4q9jzcH4ZGiOSG9a6jyVmHa+cPJT104ZHS9ioz7GZ+ceF9b+Ku/4ng2OsW8L 5xlOC3fYFKhrpnXcyUFu3t/hFtGz0KKSt33fYxBN7FoXXnuqHPxRCS2JsD5/TJ/oqZw9 +SpML7ElUB+QcjgnnyPbtWvw5JBdMtx01RvQZ6feTOZCKDdVeWZr5y6Q6pWMr83Avzcy 0H6ok69KHTMwfeGqPdG/AxZ42Fx3NzdfiWb+SSh8WAPajOf8wdqGmWKoiiwVXzUaSU1p AR7b0xokBly4UEn0ewp64V+voSucmSR7cUOnB1dt1oRPaRcRjEv9In7U1tkDSUzPdxeR UWkA== 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=mjuabSVgvQATDuvn4ZjOwSzMxXjqV/2qQSyFCohQixI=; b=MzVSwXFRYDGSV42R2Cu2DqpBFsr4yl1OkRytl4Ri+eUb0o2S+vxNrNBiI4+agG6WTw 0QsnsGn4GWPRmnY/cwKMUw1tGQ14LkMZln7j6OIVqPqq4tadJH9i5Ebd7gyaIi/cXPed MIVMADIeDKcDV6lMW3ik+we9p1nDPdzksE7fTmH21RoJ+eWuempxQlUiYSO25y195Vsj Kzzrkp2rfy64nXLQHWvHiBWCodg6apigqapG9rnu9WnWXkSVRujCDEPkTqIp12CXtZ2K sJR2KGIHytfxpAYsGVJGcsyQt++TvbhEX+62qgJKmJQa/wpxnyXvPtPmhSolXjCYPeNa 19NA== X-Gm-Message-State: APjAAAUqOjkuSmKBtR2NWJ1yo2rcOIcCab+wQItQ/FlcwKBvfYItl0XN fOBWwenUDLFXOaFXcJMcqcPPV7ZYOVRUKoYW9iaT0A== X-Google-Smtp-Source: APXvYqxAhMeQE8rB2UkmC3P7KfMlcCQd/wdFfYwhHH1MCAk1jaOUUbdL6EbtHtdFgeKP8DbTi7iElascp5cSNnJlBSg= X-Received: by 2002:ac2:51a1:: with SMTP id f1mr13050091lfk.129.1557180387142; Mon, 06 May 2019 15:06:27 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 6 May 2019 15:06:15 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000d3b91105883f4fa9" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 22:06:43 -0000 --000000000000d3b91105883f4fa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not following. We want this to be adopted, right? :) if we provide guidance that is sound but hard to implement we are going to fail. Considerations on whether the guidance requires a big effort to be applied are very much in scope for me. On Mon, May 6, 2019 at 14:54 Hans Zandbelt wrote: > the scope and way of generating sub/client_id is orthogonal to the > semantics IMHO but if I'm the only one who thinks so, I'll rest my case > > Hans. > > On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci > wrote: > >> See below, Hans- the sub doesn=E2=80=99t have to be global, it could be = something >> generated just for this particular RS. Or the AS might have its own reci= pe >> for generating sub values that different from the recipe used to generat= e >> client_ids. It would be much easier for an AS to emit a claim making thi= s >> explicit statement than to change sub and client_id assignment logic. >> >> On Mon, May 6, 2019 at 13:49 Hans Zandbelt >> wrote: >> >>> I may be missing something but I'd argue that by requiring and comparin= g >>> both "sub" and "client_id" we achieve the same semantics without a >>> new/additional claim (barring name spacing) >>> >>> Hans. >>> >>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >> 40okta.com@dmarc.ietf.org> wrote: >>> >>>> Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant >>>> types. I=E2=80=99m OK if we want a dedicated claim to establish wheth= er the token >>>> is resource owner delegated vs client acting as itself. >>>> >>>> Subject Type is already a concept in RISC. Just making folks are awar= e >>>> of prior art. >>>> >>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 >>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >>>> >>>> -Karl >>>> >>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> *This message originated outside your organization.* >>>> ------------------------------ >>>> Fair enough! What others think about it? >>>> Exploring the approach: would we want a bool claim or an enumeration, >>>> e.g. sub_type =3D [ resource_owner | client ] ? >>>> >>>> >>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>> vladimir@connect2id.com> wrote: >>>> >>>>> Hi Vittorio, >>>>> >>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>> > It is true that the grant_type is a client side consideration. I di= d >>>>> think >>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>>> applicable: >>>>> > many systems have their own rules for generating sub, and in case >>>>> they want >>>>> > to prevent tracking across RSes the sub might be generated ad-hoc >>>>> for that >>>>> > particular RS. >>>>> > Would you prefer to have a dedicated claim that distinguish between >>>>> user >>>>> > and app tokens rather than reusing grant_type? >>>>> >>>>> A dedicated claim to flag client_id effectively =3D=3D sub would be >>>>> preferable, and much easier for RS developers to process. >>>>> >>>>> The AS is the authority and has all the knowledge to set / indicate >>>>> this. >>>>> >>>>> I want to keep RS developers away from having to deal with grant type= s >>>>> and having to make decisions whether client_id effectively =3D=3D sub= . >>>>> >>>>> Vladimir >>>>> >>>>> >>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>> vladimir@connect2id.com> >>>>> > wrote: >>>>> > >>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>> >>> grant_type as a return claim, which the RS could use to the same >>>>> >> effect*. I >>>>> >>> find the proposal very clever, and the people at IIW thought so a= s >>>>> well. >>>>> >>> What you think? >>>>> >> The grant type is not something that the RS is really concerned >>>>> with, or >>>>> >> should be. Introducing this parameter in the access token will >>>>> create an >>>>> >> additional logical dependency, plus complexity - in the system of >>>>> >> client, AS and RS as a whole, as well as for RS developers. The >>>>> grant >>>>> >> type, as a concept, is a matter between the client and AS, and IMO >>>>> >> should stay that way. >>>>> >> >>>>> >> Clear language in the spec should suffice. For instance: "If the s= ub >>>>> >> value matches the client_id value, then the subject is the client >>>>> >> application". >>>>> >> >>>>> >> Vladimir >>>>> >> >>>>> >> -- >>>>> >> Vladimir Dzhuvinov >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>> >> >>>>> -- >>>>> Vladimir Dzhuvinov >>>>> >>>>> >>>>> _______________________________________________ >>>> 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 >>> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --000000000000d3b91105883f4fa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not following. We want this to be adopted, righ= t? :) if we provide guidance that is sound but hard to implement we are goi= ng to fail. Considerations on whether the guidance requires a big effort to= be applied are very much in scope for me.=C2=A0

On Mon, May 6, 2= 019 at 14:54 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
the scope and way of generating sub/client_id is = orthogonal to the semantics IMHO but if I'm the only one who thinks so,= I'll rest my case

Hans.

On Mon, May 6, 2019 = at 10:49 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
See below, Hans- th= e sub doesn=E2=80=99t have to be global, it could be something generated ju= st for this particular RS. Or the AS might have its own recipe for generati= ng sub values that different from the recipe used to generate client_ids. I= t would be much easier for an AS to emit a claim making this explicit state= ment than to change sub and client_id assignment logic.
On Mon, M= ay 6, 2019 at 13:49 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I may be missing something but I'd argue that by requiring = and comparing both "sub" and "client_id" we achieve the= same semantics without a new/additional claim (barring name spacing)
=

Hans.

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 6, 2019 at 8:58 PM Karl Mc= Guinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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



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


--
--000000000000d3b91105883f4fa9-- From nobody Mon May 6 15:12:12 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 996391201C7 for ; Mon, 6 May 2019 15:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dOjyrbb-thP3 for ; Mon, 6 May 2019 15:12:02 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 D542A120045 for ; Mon, 6 May 2019 15:11:59 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id o7so4808291qtp.4 for ; Mon, 06 May 2019 15:11:59 -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=MO0YeGg1DIeOgyrDKKz9fBfPriTdtKLsJqLQhu4aeI0=; b=jvKp9VmbNt3lQxyWGL9IDmW7tfYi++KrAPXzAJDNpIy6lgP6kJn7KTE6Pg7FqsqG53 FVGiZe1lAiOBi8htHyjyaaPeu1fvYKlomNFafRCZ+u1dYK8vP2dQuBaf+zlWcwHWA0es OMBY/XyhXeLiTel1+RzIdCVZ+yyyuVBdg5/ZuP25Lp1aWHpL48Nug3anqdiPf9LllkV0 h2ipW9irdSbwudIxzUGTE2V7GFgMtYK2LilWJNZ56zq9dPofBYoy1UVe6BbjBbWxp+HE 5NNgEze0LddY6pLzL5fgt/TPufvDNlfNMgOPDzFvbljjcn1tMgSo1qStopQylkRPQr/s Cv5w== 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=MO0YeGg1DIeOgyrDKKz9fBfPriTdtKLsJqLQhu4aeI0=; b=MnfonCfjn44r50Do3WNKlDiV1uWO7zo8Evj+DVbOZ7U+LxvNJavvk1ZE5vcRSiIN65 Cdo+JknI006RvJr2ThsthE67K74XXlXTWDSXEs8JeT57BJbbc9d3RcvwpSW1elqpfA0o tlpmzBehceTA4Z82UlE7/pGk/3mQliZfNCPG3zFlifOcd2C4fwm+kGKAjgYRu/S1MlUH zudVw+7HBFDAZ6lBYvx1efeN7KpjGhE9cMrVTJTVTA1q9K/GH2Vcjv5su2T358x05cRK 8DvnlwE5TTOUez/9zVrE3G24ks7zXJ5e5c7AKDiRmhyvWJDhtRKAj3AVTAzdUkJP8idR BiRg== X-Gm-Message-State: APjAAAVvJ4zxrpinjoV09THJ87TZiHm3CWHiAKrzQKDlaxKoZaBDg9TT rilZRciM1nKOabKgjV+SIVI+5dK0QnY68Fzs80f7wA== X-Google-Smtp-Source: APXvYqx2kUE1gZrwSESjIIvCuhyoVyprrhDMlw7Qs2+WO0fuGUlawS74BHu0gQO1rH58KeTM94VMLqZk/5xAiB/SNxM= X-Received: by 2002:ac8:851:: with SMTP id x17mr23919972qth.373.1557180718821; Mon, 06 May 2019 15:11:58 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Hans Zandbelt Date: Mon, 6 May 2019 23:11:47 +0100 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="00000000000098cf6405883f63d9" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 22:12:11 -0000 --00000000000098cf6405883f63d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm suggesting that whichever "sub" and "client_id" the RS is receiving and however it was generated, it must mean something to it in alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; moreover, if the "sub" has the same value as "client_id" it must be a client talking to the RS on behalf of its own and the claims are associated with the client; if the "sub" has a different value than the "client_id" it must be a scenario where the client presents a token delegated by a Resource Owner and the claims are about the Resource Owner. Problem solved? Hans. On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci wrote: > I am not following. We want this to be adopted, right? :) if we provide > guidance that is sound but hard to implement we are going to fail. > Considerations on whether the guidance requires a big effort to be applie= d > are very much in scope for me. > > On Mon, May 6, 2019 at 14:54 Hans Zandbelt > wrote: > >> the scope and way of generating sub/client_id is orthogonal to the >> semantics IMHO but if I'm the only one who thinks so, I'll rest my case >> >> Hans. >> >> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci >> wrote: >> >>> See below, Hans- the sub doesn=E2=80=99t have to be global, it could be >>> something generated just for this particular RS. Or the AS might have i= ts >>> own recipe for generating sub values that different from the recipe use= d to >>> generate client_ids. It would be much easier for an AS to emit a claim >>> making this explicit statement than to change sub and client_id assignm= ent >>> logic. >>> >>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt >>> wrote: >>> >>>> I may be missing something but I'd argue that by requiring and >>>> comparing both "sub" and "client_id" we achieve the same semantics wit= hout >>>> a new/additional claim (barring name spacing) >>>> >>>> Hans. >>>> >>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>> 40okta.com@dmarc.ietf.org> wrote: >>>> >>>>> Makes sense that we don=E2=80=99t want to further couple AS and RS wi= th grant >>>>> types. I=E2=80=99m OK if we want a dedicated claim to establish whet= her the token >>>>> is resource owner delegated vs client acting as itself. >>>>> >>>>> Subject Type is already a concept in RISC. Just making folks are >>>>> aware of prior art. >>>>> >>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.= 2 >>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >>>>> >>>>> -Karl >>>>> >>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>> >>>>> *This message originated outside your organization.* >>>>> ------------------------------ >>>>> Fair enough! What others think about it? >>>>> Exploring the approach: would we want a bool claim or an enumeration, >>>>> e.g. sub_type =3D [ resource_owner | client ] ? >>>>> >>>>> >>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>> vladimir@connect2id.com> wrote: >>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>> > It is true that the grant_type is a client side consideration. I >>>>>> did think >>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>>>> applicable: >>>>>> > many systems have their own rules for generating sub, and in case >>>>>> they want >>>>>> > to prevent tracking across RSes the sub might be generated ad-hoc >>>>>> for that >>>>>> > particular RS. >>>>>> > Would you prefer to have a dedicated claim that distinguish betwee= n >>>>>> user >>>>>> > and app tokens rather than reusing grant_type? >>>>>> >>>>>> A dedicated claim to flag client_id effectively =3D=3D sub would be >>>>>> preferable, and much easier for RS developers to process. >>>>>> >>>>>> The AS is the authority and has all the knowledge to set / indicate >>>>>> this. >>>>>> >>>>>> I want to keep RS developers away from having to deal with grant typ= es >>>>>> and having to make decisions whether client_id effectively =3D=3D su= b. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> >>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>> vladimir@connect2id.com> >>>>>> > wrote: >>>>>> > >>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>> >>> grant_type as a return claim, which the RS could use to the same >>>>>> >> effect*. I >>>>>> >>> find the proposal very clever, and the people at IIW thought so >>>>>> as well. >>>>>> >>> What you think? >>>>>> >> The grant type is not something that the RS is really concerned >>>>>> with, or >>>>>> >> should be. Introducing this parameter in the access token will >>>>>> create an >>>>>> >> additional logical dependency, plus complexity - in the system of >>>>>> >> client, AS and RS as a whole, as well as for RS developers. The >>>>>> grant >>>>>> >> type, as a concept, is a matter between the client and AS, and IM= O >>>>>> >> should stay that way. >>>>>> >> >>>>>> >> Clear language in the spec should suffice. For instance: "If the >>>>>> sub >>>>>> >> value matches the client_id value, then the subject is the client >>>>>> >> application". >>>>>> >> >>>>>> >> Vladimir >>>>>> >> >>>>>> >> -- >>>>>> >> Vladimir Dzhuvinov >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> OAuth mailing list >>>>>> >> OAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >> >>>>>> -- >>>>>> Vladimir Dzhuvinov >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --00000000000098cf6405883f63d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm suggesting that whichever "sub" and &quo= t;client_id" the RS is receiving and however it was generated, it must= mean something to it in alignment with the JWT/OAuth2/OIDC specs, otherwis= e it wouldn't be there at all; moreover, if the "sub" has the= same value as "client_id" it must be a client talking to the RS = on behalf of its own and the claims are associated with the client; if the = "sub" has a different value than the "client_id" it mus= t be a scenario where the client presents a token delegated by a Resource O= wner and the claims are about the Resource Owner. Problem solved?

<= /div>
Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <= Vittorio@auth0.com> wrote:
=
I am not following. We want this to be adopted, right? :) if we provide= guidance that is sound but hard to implement we are going to fail. Conside= rations on whether the guidance requires a big effort to be applied are ver= y much in scope for me.=C2=A0

On Mon, May 6, 2019 at 14:54 Hans Z= andbelt <hans.zandbelt@zmartzone.eu> wrote:
the scope and way of generating= sub/client_id is orthogonal to the semantics IMHO but if I'm the only = one who thinks so, I'll rest my case

Hans.

On M= on, May 6, 2019 at 10:49 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
<= 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">
See= below, Hans- the sub doesn=E2=80=99t have to be global, it could be someth= ing generated just for this particular RS. Or the AS might have its own rec= ipe for generating sub values that different from the recipe used to genera= te client_ids. It would be much easier for an AS to emit a claim making thi= s explicit statement than to change sub and client_id assignment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt <hans.zandbelt@zmartzone.eu&g= t; wrote:
I may be missing something but I'd argue th= at by requiring and comparing both "sub" and "client_id"= ; we achieve the same semantics without a new/additional claim (barring nam= e spacing)

Hans.

On Mon, May 6, 2019 = at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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



--
<= div dir=3D"ltr">
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--


--
--00000000000098cf6405883f63d9-- From nobody Mon May 6 15:22: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 4BB85120045 for ; Mon, 6 May 2019 15:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8deFluh9zLMS for ; Mon, 6 May 2019 15:22:15 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765D5120098 for ; Mon, 6 May 2019 15:22:13 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id h126so10298128lfh.4 for ; Mon, 06 May 2019 15:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5h8WUt3At7MmAWBTeQjRPd9RVvEXe7NTnV3K1Obw0tk=; b=eDU3SsJ8qH/asX5V6fWwk9/EQZRCLonf7NPS68MkywDX/JAR4Ct+m2CQSfFSDmExDe qvEc+fgG7Gr+UnaNd5rf22aQZ/00Fog7c1R4OHmMdMdpSmtYty51KmxcjvwklL7GrWzS 7/Ly/hMLz962mBVsMQ+xAcDaNKo6DiMC+aCTM+qyLMTjI8QKfcMMKkZgNxFBEGT0rhth wFT188vHpE+hxbDYBpGybuck+IQBhjxBBw+/mbtV1TI3blt67FQNW4Y8wR6vITjStl8z rTvN6Lz8QebAJCTGIm3VVknr0l3mP83pJvTQN9VSrAFh+tB8BPxJNO7Y5inYb1Q9JaG1 7AmQ== 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=5h8WUt3At7MmAWBTeQjRPd9RVvEXe7NTnV3K1Obw0tk=; b=p6Unhs2+9OcD5d1qakTpFcJZEU5Baoj/I3ElnUe3n5mhMLW1fTv2Xs6vjT9NfvZjyq B4ZX646+D54ngEY+aFTTJAvWCt5wIAiDRbWxIHofQG+0UsFphrJ73KMVrFSVki/WZE4F +OYlY5vKPWPrdNJ81T+yQR2W6eZVRc2dj44C+8cGsl7mNhf1RNK8C+l8vX5ivG6Qs7Nw SzNamAcc+PFs2qGtqrDtlMrD0PeQDUJNwywr9hjdfnk5+IKbium7d4YhVLqioxRquKcN xD9lDwI1vUw/SSCcGl7zCjriqAHS6wWmVJbLGmxa1EGrGDErdI9vLt0EKZn4oviUAV1T O03w== X-Gm-Message-State: APjAAAUORLMipL4oTGEkP0bSC0/ltWsmnZgLjYGWUUA52lTer0QC/Z6v 0VmIWur34lSi+c1YIMhlUNMtelQK4seNHobXMtConA== X-Google-Smtp-Source: APXvYqxrWAfQk9Pk5ASFti+GUk0swDuuuIraecv/9SG0JLKabsF40wzjQsVanBEipp2wz/6I3bVC684u4NRUH1u1i8k= X-Received: by 2002:ac2:4192:: with SMTP id z18mr14260085lfh.96.1557181331484; Mon, 06 May 2019 15:22:11 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Vittorio Bertocci Date: Mon, 6 May 2019 15:22:00 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000001d47bc05883f8865" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 22:22:19 -0000 --0000000000001d47bc05883f8865 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me try a different angle. An AS might generate sub claims and client_id identifiers using a different format/template. That means that there might be a client with client_id X that gets assigned a sub value Y, despite the client being the same, hence the check =E2=80=9Csub=3D=3Dclient_id=E2=80=9D= would fail. The logic producing this might be hard for an AS to change as there has never been any requirement on client_id or sub formats hence everyone was free until now to use whatever logic they chose, including name spacing one but not the other and any other variation, and changes might have ripple effects downstream on systems that have nothing to do w this spec (eg sharing of where clients are stored might depend on the internal structure of the client_id). So in other words, an AS might have to touch pretty fundamental stuff in its logic and potentially impact scenarios that have no direct bearing with the JWT AT profile just for making that condition true. On the other plate of the scale, there=E2=80=99s adding a new claim- = which I can literally already do in various commercial ASes via extensibility points, without changing their code. On Mon, May 6, 2019 at 15:11 Hans Zandbelt wrote: > I'm suggesting that whichever "sub" and "client_id" the RS is receiving > and however it was generated, it must mean something to it in alignment > with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; > moreover, if the "sub" has the same value as "client_id" it must be a > client talking to the RS on behalf of its own and the claims are associat= ed > with the client; if the "sub" has a different value than the "client_id" = it > must be a scenario where the client presents a token delegated by a > Resource Owner and the claims are about the Resource Owner. Problem solve= d? > > Hans. > > On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci > wrote: > >> I am not following. We want this to be adopted, right? :) if we provide >> guidance that is sound but hard to implement we are going to fail. >> Considerations on whether the guidance requires a big effort to be appli= ed >> are very much in scope for me. >> >> On Mon, May 6, 2019 at 14:54 Hans Zandbelt >> wrote: >> >>> the scope and way of generating sub/client_id is orthogonal to the >>> semantics IMHO but if I'm the only one who thinks so, I'll rest my case >>> >>> Hans. >>> >>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci >>> wrote: >>> >>>> See below, Hans- the sub doesn=E2=80=99t have to be global, it could b= e >>>> something generated just for this particular RS. Or the AS might have = its >>>> own recipe for generating sub values that different from the recipe us= ed to >>>> generate client_ids. It would be much easier for an AS to emit a claim >>>> making this explicit statement than to change sub and client_id assign= ment >>>> logic. >>>> >>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt >>>> wrote: >>>> >>>>> I may be missing something but I'd argue that by requiring and >>>>> comparing both "sub" and "client_id" we achieve the same semantics wi= thout >>>>> a new/additional claim (barring name spacing) >>>>> >>>>> Hans. >>>>> >>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>>> 40okta.com@dmarc.ietf.org> wrote: >>>>> >>>>>> Makes sense that we don=E2=80=99t want to further couple AS and RS w= ith grant >>>>>> types. I=E2=80=99m OK if we want a dedicated claim to establish whe= ther the token >>>>>> is resource owner delegated vs client acting as itself. >>>>>> >>>>>> Subject Type is already a concept in RISC. Just making folks are >>>>>> aware of prior art. >>>>>> >>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2= .2 >>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.= 1 >>>>>> >>>>>> -Karl >>>>>> >>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> *This message originated outside your organization.* >>>>>> ------------------------------ >>>>>> Fair enough! What others think about it? >>>>>> Exploring the approach: would we want a bool claim or an enumeration= , >>>>>> e.g. sub_type =3D [ resource_owner | client ] ? >>>>>> >>>>>> >>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>> vladimir@connect2id.com> wrote: >>>>>> >>>>>>> Hi Vittorio, >>>>>>> >>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>> > It is true that the grant_type is a client side consideration. I >>>>>>> did think >>>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>>>>> applicable: >>>>>>> > many systems have their own rules for generating sub, and in case >>>>>>> they want >>>>>>> > to prevent tracking across RSes the sub might be generated ad-hoc >>>>>>> for that >>>>>>> > particular RS. >>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>> between user >>>>>>> > and app tokens rather than reusing grant_type? >>>>>>> >>>>>>> A dedicated claim to flag client_id effectively =3D=3D sub would be >>>>>>> preferable, and much easier for RS developers to process. >>>>>>> >>>>>>> The AS is the authority and has all the knowledge to set / indicate >>>>>>> this. >>>>>>> >>>>>>> I want to keep RS developers away from having to deal with grant >>>>>>> types >>>>>>> and having to make decisions whether client_id effectively =3D=3D s= ub. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>> vladimir@connect2id.com> >>>>>>> > wrote: >>>>>>> > >>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>> >>> grant_type as a return claim, which the RS could use to the sam= e >>>>>>> >> effect*. I >>>>>>> >>> find the proposal very clever, and the people at IIW thought so >>>>>>> as well. >>>>>>> >>> What you think? >>>>>>> >> The grant type is not something that the RS is really concerned >>>>>>> with, or >>>>>>> >> should be. Introducing this parameter in the access token will >>>>>>> create an >>>>>>> >> additional logical dependency, plus complexity - in the system o= f >>>>>>> >> client, AS and RS as a whole, as well as for RS developers. The >>>>>>> grant >>>>>>> >> type, as a concept, is a matter between the client and AS, and I= MO >>>>>>> >> should stay that way. >>>>>>> >> >>>>>>> >> Clear language in the spec should suffice. For instance: "If the >>>>>>> sub >>>>>>> >> value matches the client_id value, then the subject is the clien= t >>>>>>> >> application". >>>>>>> >> >>>>>>> >> Vladimir >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Vladimir Dzhuvinov >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> OAuth mailing list >>>>>>> >> OAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >> >>>>>>> -- >>>>>>> Vladimir Dzhuvinov >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --0000000000001d47bc05883f8865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let me try a different angle. An AS might generate s= ub claims and client_id identifiers using a different format/template. That= means that there might be a client with client_id X that gets assigned a s= ub value Y, despite the client being the same, hence the check =E2=80=9Csub= =3D=3Dclient_id=E2=80=9D would fail.
The logic produ= cing this might be hard for an AS to change as there has never been any req= uirement on client_id or sub formats hence everyone was free until now to u= se whatever logic they chose, including name spacing one but not the other = and any other variation, and changes might have ripple effects downstream o= n systems that have nothing to do w this spec (eg sharing of where clients = are stored might depend on the internal structure of the client_id). So in = other words, an AS might have to touch pretty fundamental stuff in its logi= c and potentially impact scenarios that have no direct bearing with the JWT= AT profile just for making that condition true. On the other plate of the = scale, there=E2=80=99s adding a new claim- which I can literally already do= in various commercial ASes via extensibility points, without changing thei= r code.


On Mon, May 6, 2019 at 15:11 = Hans Zandbelt <hans.zandbe= lt@zmartzone.eu> wrote:
I'm suggesting that whichever "sub" and "cl= ient_id" the RS is receiving and however it was generated, it must mea= n something to it in alignment with the JWT/OAuth2/OIDC specs, otherwise it= wouldn't be there at all; moreover, if the "sub" has the sam= e value as "client_id" it must be a client talking to the RS on b= ehalf of its own and the claims are associated with the client; if the &quo= t;sub" has a different value than the "client_id" it must be= a scenario where the client presents a token delegated by a Resource Owner= and the claims are about the Resource Owner. Problem solved?

Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <Vittorio@auth0.com&= gt; wrote:
=
I am not following. We want this to be adopted, right? :)= if we provide guidance that is sound but hard to implement we are going to= fail. Considerations on whether the guidance requires a big effort to be a= pplied are very much in scope for me.=C2=A0

On Mon, May 6, 2019 = at 14:54 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
the scope and wa= y of generating sub/client_id is orthogonal to the semantics IMHO but if I&= #39;m the only one who thinks so, I'll rest my case

= Hans.

On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci <Vittorio@auth0.com> wr= ote:
See below, Hans- the sub doesn=E2=80=99t have to be global, it = could be something generated just for this particular RS. Or the AS might h= ave its own recipe for generating sub values that different from the recipe= used to generate client_ids. It would be much easier for an AS to emit a c= laim making this explicit statement than to change sub and client_id assign= ment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt <hans.zandbelt@zma= rtzone.eu> wrote:
I may be missing something but= I'd argue that by requiring and comparing both "sub" and &qu= ot;client_id" we achieve the same semantics without a new/additional c= laim (barring name spacing)

Hans.
On Mo= n, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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



--
<= div dir=3D"ltr">
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=


--
--0000000000001d47bc05883f8865-- From nobody Mon May 6 23:57: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 D21A5120072 for ; Mon, 6 May 2019 23:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7Yb47l9DaBw for ; Mon, 6 May 2019 23:57:53 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 B41D0120020 for ; Mon, 6 May 2019 23:57:52 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id b8so17622644edm.11 for ; Mon, 06 May 2019 23:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mQ1hEBIEKE7B8mlJ2QVlSkLBZDCa85re+F3hCWl8u3E=; b=YCErd86FjueEc4HXCJOijz8lK+jlpfxueYTfkGmW8JobklS4fKm16ZdLFXoQ4ZQ7fY nCVeDY69HjfpWtgxzxSO6mC8WqSyLYg/wSo8lDN6+EaFl2nXpw+ENnr32YpQrfzQ+3wy pqBnO5fPS3G2LlSfq73zNkOepCCEeKau53LF4BUFTOixdATDXjn2MZqe91VgzQwTKz91 MaiKxpNOuwzqZqqyJNJrb1MOfjucF4shRGAJ18sczvNesqw92AdwAe4Radip6iBD1s+B 1by/weO9HIbBTKvWCoOWPE6TBorh/gUkG+DFNEvtBf57khJtsmV0mFCsID51qcARMeJq 1IsQ== 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=mQ1hEBIEKE7B8mlJ2QVlSkLBZDCa85re+F3hCWl8u3E=; b=lyD6Csbu5cIcsJY7vkLl17fBJIE17xeGKESFQRr0IdJlpDEP6yCnThHGldRWtRvz52 mVa3elNYM0e5Pqjhlem/11iI6TCn9c/pCtpRzBsnGbpEeNId7nTolyKKH2EvI4RbfNED 0j18IVaFA+DiLVojgTQzaIAJ9BXWQIFFFWsG+LRbWIgb9+uGiZolDCPuLVPwHwUY3CkN V8Ywp/lGjKE4VLS2J7MNlhqrSHpzAA66lQOKmjCkWoAO3tJQo2HhBVX3/MtYulhFQygw uJuEace40dDhWBIk0ZcsI7Pl+xlt2L6YIu4u9M7ae8w90tjifV7/8XTw31jX2VjE1gb8 aehg== X-Gm-Message-State: APjAAAW5gL88Ezgtw5ch50LwLrOf//LztVPSIiUXHDDjpy/7OCMt5m/8 xKgpsLw43YMvQlQTFfkxY+CboVtjn5Ci8wPLnjKyTfE2v0Wlhw== X-Google-Smtp-Source: APXvYqx1fOI0DSHgWcaAbGGLTBjwk9b+ZekX9R0w74xtN3sjkt2ETlK3YlsM/HCJc4OaD/V5GhukFmc7ePvLHiqfRs0= X-Received: by 2002:a17:906:5613:: with SMTP id f19mr6307185ejq.128.1557212270717; Mon, 06 May 2019 23:57:50 -0700 (PDT) MIME-Version: 1.0 From: Takahiko Kawasaki Date: Tue, 7 May 2019 15:57:39 +0900 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000003c88f5058846bc6b" Archived-At: Subject: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection 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, 07 May 2019 06:57:55 -0000 --0000000000003c88f5058846bc6b Content-Type: text/plain; charset="UTF-8" Hello, I have a question regarding "JWT Response for OAuth Token Introspection" (draft-02). https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/?include_text=1 How to determine the value of "aud" in the response JWT? The example payload uses "https://protected.example.net/resource" as the value of "aud". The example value implies that it represents the identifier of the target resource or the resource server, but how does an authorization server implementation know the identifier? I'm sorry if this has already been discussed. To be honest, I fear that some inconsistencies might occur in future by treating resource servers as clients. If I had to write the specification, I would start from defining "resource server metadata" (e.g. expired draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/) and devising a way to register resource servers into an authorization server and issue resource server credentials (e.g. rs_id and rs_secret, RS JWK Set, etc.) in order to treat resource servers and clients as different entities explicitly. I hope that discussion for distinguishing "resource server authentication" from "client authentication" will be initiated sometime in future. Best Regards, Takahiko Kawasaki Authlete, Inc. --0000000000003c88f5058846bc6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I have a question regarding "JWT Response for OAuth Token= Introspection" (draft-02).


How to dete= rmine the value of "aud" in the response JWT?

The example payload uses "https://protected.example.net/resource" as the value = of "aud". The example value implies that it represents the identi= fier of the target resource or the resource server, but how does an authori= zation server implementation know the identifier? I'm sorry if this has= already been discussed.

To be honest, I fear that= some inconsistencies might occur in future by treating resource servers as= clients. If I had to write the specification, I would start from defining = "resource server metadata" (e.g. expired draft:=C2=A0https= ://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/) and d= evising a way to register resource servers into an authorization server and= issue resource server credentials (e.g. rs_id and rs_secret, RS JWK Set, e= tc.) in order to treat resource servers and clients as different entities e= xplicitly. I hope that discussion for distinguishing "resource server = authentication" from "client authentication" will be initiat= ed sometime in future.

Best Regards,
Tak= ahiko Kawasaki
Authlete, Inc.

--0000000000003c88f5058846bc6b-- From nobody Tue May 7 00: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 021D81201E2 for ; Tue, 7 May 2019 00:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 N9ony4kwzJUl for ; Tue, 7 May 2019 00:07:53 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 DF0C81200E5 for ; Tue, 7 May 2019 00:07:52 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id j6so17865743qtq.1 for ; Tue, 07 May 2019 00:07:52 -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=BcGMFgaDfXX45oXAycmBLRKcUSKB1w0EGPivk9IEwb4=; b=hJ89YdycOPFFl/3+X417/kAw5jf3P5GgxbALgpx2ZB2GZoPi9J5zjQqNE302c6I31f Ec/x1haKvUYR0gAsNkVl1iT6G6Jt5nbkIYsvFIV/rIq/IEOosQwec8VmuZUSQ+8mnVs0 /p7tFUg8tniXMcoYDFELnGfxokTNHlX7DRLIZNu1TT1t+diR4sV0KmT1NqASx7aJ71Rw +bY9odnU7cEdbal+3nS1Yndms5CBbByXqyfDg4nJkiEPy5icmxa1xT3gDJdEOX4HA1/B dNOvV9kZmPsYikEZTbmCyd1stRhBRJ2yc0ZojYb6LGYslTHNM3b0HRt+TfVjAhsG9xGV mokg== 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=BcGMFgaDfXX45oXAycmBLRKcUSKB1w0EGPivk9IEwb4=; b=CcZUzZGyxVqY4LCPAKSDMQqWQCUVjyZiQ+wg7pFpL78ITx5uOq7DjZf6eUCRPSa+hh Y6JUR2+T2i8pPplvVw8mQl9UCI+5YWlKrVfWt+1MZ1yuYhEkybrG5q+3MP5kW1iqawa1 egZNe21rQMRoOdptLRutEQjIVvni87wbPJlCvP5OU3Lh1fPUPwZU17LdpxMrpfLJhP2I ETXWx2ql92jDH1jfKvuwVilRGeKxJf4c/ysFagowaCt+VYXbbyKMT53WiD1HTpDZZAH8 dTvSPWpW8ManiUutSVPAt9Q2Ml1hxs0UNWzDrzee+BtP/+gt98Pl8DX6Su8/Gnn6ii82 anSA== X-Gm-Message-State: APjAAAUafAhJOKwZMiBPh0Bx/QG2JCFY3jQipr1n2e3qaby2qZcf2nY8 1E/WA0pfIffHbZhtJIzdp4vh9Fxc1hD4rkbfMoIW2g== X-Google-Smtp-Source: APXvYqxRj4HwgkcammdQgPtgQ3jDLI37C9GOVfbOEL8BePA433M+zw767V3Ac7BJVy5CY1JOWqPZu3Ywj+aSzkM7q1A= X-Received: by 2002:a0c:8b4a:: with SMTP id d10mr24375813qvc.29.1557212871794; Tue, 07 May 2019 00:07:51 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Hans Zandbelt Date: Tue, 7 May 2019 08:07:40 +0100 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000001038a0058846e025" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 07:08:06 -0000 --0000000000001038a0058846e025 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand your legacy-breaking point (and do see a name spacing hurdle) but: a. I feel we're now painting ourselves into a corner ("soft doctors make stinking wounds"). b. putting the client_id into the sub value would be something that any product should be able to do, just like putting an extra claim in; I don't think that is fundamental stuff Hans. On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci wrote: > Let me try a different angle. An AS might generate sub claims and > client_id identifiers using a different format/template. That means that > there might be a client with client_id X that gets assigned a sub value Y= , > despite the client being the same, hence the check =E2=80=9Csub=3D=3Dclie= nt_id=E2=80=9D would > fail. > The logic producing this might be hard for an AS to change as there has > never been any requirement on client_id or sub formats hence everyone was > free until now to use whatever logic they chose, including name spacing o= ne > but not the other and any other variation, and changes might have ripple > effects downstream on systems that have nothing to do w this spec (eg > sharing of where clients are stored might depend on the internal structur= e > of the client_id). So in other words, an AS might have to touch pretty > fundamental stuff in its logic and potentially impact scenarios that have > no direct bearing with the JWT AT profile just for making that condition > true. On the other plate of the scale, there=E2=80=99s adding a new claim= - which I > can literally already do in various commercial ASes via extensibility > points, without changing their code. > > > On Mon, May 6, 2019 at 15:11 Hans Zandbelt > wrote: > >> I'm suggesting that whichever "sub" and "client_id" the RS is receiving >> and however it was generated, it must mean something to it in alignment >> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; >> moreover, if the "sub" has the same value as "client_id" it must be a >> client talking to the RS on behalf of its own and the claims are associa= ted >> with the client; if the "sub" has a different value than the "client_id"= it >> must be a scenario where the client presents a token delegated by a >> Resource Owner and the claims are about the Resource Owner. Problem solv= ed? >> >> Hans. >> >> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci >> wrote: >> >>> I am not following. We want this to be adopted, right? :) if we provide >>> guidance that is sound but hard to implement we are going to fail. >>> Considerations on whether the guidance requires a big effort to be appl= ied >>> are very much in scope for me. >>> >>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt >>> wrote: >>> >>>> the scope and way of generating sub/client_id is orthogonal to the >>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my cas= e >>>> >>>> Hans. >>>> >>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci >>>> wrote: >>>> >>>>> See below, Hans- the sub doesn=E2=80=99t have to be global, it could = be >>>>> something generated just for this particular RS. Or the AS might have= its >>>>> own recipe for generating sub values that different from the recipe u= sed to >>>>> generate client_ids. It would be much easier for an AS to emit a clai= m >>>>> making this explicit statement than to change sub and client_id assig= nment >>>>> logic. >>>>> >>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt >>>>> wrote: >>>>> >>>>>> I may be missing something but I'd argue that by requiring and >>>>>> comparing both "sub" and "client_id" we achieve the same semantics w= ithout >>>>>> a new/additional claim (barring name spacing) >>>>>> >>>>>> Hans. >>>>>> >>>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>>>> 40okta.com@dmarc.ietf.org> wrote: >>>>>> >>>>>>> Makes sense that we don=E2=80=99t want to further couple AS and RS = with >>>>>>> grant types. I=E2=80=99m OK if we want a dedicated claim to establ= ish whether the >>>>>>> token is resource owner delegated vs client acting as itself. >>>>>>> >>>>>>> Subject Type is already a concept in RISC. Just making folks are >>>>>>> aware of prior art. >>>>>>> >>>>>>> >>>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.= 2.2 >>>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2= .1 >>>>>>> >>>>>>> -Karl >>>>>>> >>>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> *This message originated outside your organization.* >>>>>>> ------------------------------ >>>>>>> Fair enough! What others think about it? >>>>>>> Exploring the approach: would we want a bool claim or an >>>>>>> enumeration, e.g. sub_type =3D [ resource_owner | client ] ? >>>>>>> >>>>>>> >>>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>>> vladimir@connect2id.com> wrote: >>>>>>> >>>>>>>> Hi Vittorio, >>>>>>>> >>>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>>> > It is true that the grant_type is a client side consideration. I >>>>>>>> did think >>>>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>>>>>> applicable: >>>>>>>> > many systems have their own rules for generating sub, and in cas= e >>>>>>>> they want >>>>>>>> > to prevent tracking across RSes the sub might be generated ad-ho= c >>>>>>>> for that >>>>>>>> > particular RS. >>>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>>> between user >>>>>>>> > and app tokens rather than reusing grant_type? >>>>>>>> >>>>>>>> A dedicated claim to flag client_id effectively =3D=3D sub would b= e >>>>>>>> preferable, and much easier for RS developers to process. >>>>>>>> >>>>>>>> The AS is the authority and has all the knowledge to set / indicat= e >>>>>>>> this. >>>>>>>> >>>>>>>> I want to keep RS developers away from having to deal with grant >>>>>>>> types >>>>>>>> and having to make decisions whether client_id effectively =3D=3D = sub. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> >>>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>>> vladimir@connect2id.com> >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>>> >>> grant_type as a return claim, which the RS could use to the sa= me >>>>>>>> >> effect*. I >>>>>>>> >>> find the proposal very clever, and the people at IIW thought s= o >>>>>>>> as well. >>>>>>>> >>> What you think? >>>>>>>> >> The grant type is not something that the RS is really concerned >>>>>>>> with, or >>>>>>>> >> should be. Introducing this parameter in the access token will >>>>>>>> create an >>>>>>>> >> additional logical dependency, plus complexity - in the system = of >>>>>>>> >> client, AS and RS as a whole, as well as for RS developers. The >>>>>>>> grant >>>>>>>> >> type, as a concept, is a matter between the client and AS, and >>>>>>>> IMO >>>>>>>> >> should stay that way. >>>>>>>> >> >>>>>>>> >> Clear language in the spec should suffice. For instance: "If th= e >>>>>>>> sub >>>>>>>> >> value matches the client_id value, then the subject is the clie= nt >>>>>>>> >> application". >>>>>>>> >> >>>>>>>> >> Vladimir >>>>>>>> >> >>>>>>>> >> -- >>>>>>>> >> Vladimir Dzhuvinov >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> _______________________________________________ >>>>>>>> >> OAuth mailing list >>>>>>>> >> OAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >> >>>>>>>> -- >>>>>>>> Vladimir Dzhuvinov >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000001038a0058846e025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand your legacy-breaking point (= and do see a name spacing hurdle) but:
a. I feel we&#= 39;re now painting ourselves into a corner ("soft doctors make stinkin= g wounds").
b. putting the client_id into the su= b value would be something that any product should be able to do, just like= putting an extra claim in; I don't think that is fundamental stuff
Hans.

On Mon, May 6, 2019 at 11:22 PM Vittorio B= ertocci <Vittorio@auth0.com>= ; wrote:
Let me try a different angle. An AS might generate sub clai= ms and client_id identifiers using a different format/template. That means = that there might be a client with client_id X that gets assigned a sub valu= e Y, despite the client being the same, hence the check =E2=80=9Csub=3D=3Dc= lient_id=E2=80=9D would fail.
The logic producing th= is might be hard for an AS to change as there has never been any requiremen= t on client_id or sub formats hence everyone was free until now to use what= ever logic they chose, including name spacing one but not the other and any= other variation, and changes might have ripple effects downstream on syste= ms that have nothing to do w this spec (eg sharing of where clients are sto= red might depend on the internal structure of the client_id). So in other w= ords, an AS might have to touch pretty fundamental stuff in its logic and p= otentially impact scenarios that have no direct bearing with the JWT AT pro= file just for making that condition true. On the other plate of the scale, = there=E2=80=99s adding a new claim- which I can literally already do in var= ious commercial ASes via extensibility points, without changing their code.=


On Mon, May 6, 2019 at 15:11 Hans Za= ndbelt <= hans.zandbelt@zmartzone.eu> wrote:
I'm suggesting that whicheve= r "sub" and "client_id" the RS is receiving and however= it was generated, it must mean something to it in alignment with the JWT/O= Auth2/OIDC specs, otherwise it wouldn't be there at all; moreover, if t= he "sub" has the same value as "client_id" it must be a= client talking to the RS on behalf of its own and the claims are associate= d with the client; if the "sub" has a different value than the &q= uot;client_id" it must be a scenario where the client presents a token= delegated by a Resource Owner and the claims are about the Resource Owner.= Problem solved?

Hans.

On Mon, May 6, 2019 at 11:06= PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
I am not following. We want= this to be adopted, right? :) if we provide guidance that is sound but har= d to implement we are going to fail. Considerations on whether the guidance= requires a big effort to be applied are very much in scope for me.=C2=A0

On Mon, May 6, 2019 at 14:54 Hans Zandbelt <hans.zandbelt@zmartzone.eu= > wrote:
the scope and way of generating sub/client_id is orthogonal to= the semantics IMHO but if I'm the only one who thinks so, I'll res= t my case

Hans.

On Mon, May 6, 2019 at 10:49 PM Vit= torio Bertocci <= Vittorio@auth0.com> wrote:
See below, Hans- the sub doesn=E2= =80=99t have to be global, it could be something generated just for this pa= rticular RS. Or the AS might have its own recipe for generating sub values = that different from the recipe used to generate client_ids. It would be muc= h easier for an AS to emit a claim making this explicit statement than to c= hange sub and client_id assignment logic.

On Mon, May 6, 2019 at = 13:49 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I = may be missing something but I'd argue that by requiring and comparing = both "sub" and "client_id" we achieve the same semantic= s without a new/additional claim (barring name spacing)

Hans.

On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <k= mcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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



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

=


--


--
--0000000000001038a0058846e025-- From nobody Tue May 7 00:26: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 6F50212001E for ; Tue, 7 May 2019 00:25: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_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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovunPAow2y7r for ; Tue, 7 May 2019 00:25:55 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 882001200B4 for ; Tue, 7 May 2019 00:25:51 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id n22so3486189lfe.12 for ; Tue, 07 May 2019 00:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kbuwG7O6a0Tu3m97g/1/tCyy5wlgHEBgje6AIie4BsY=; b=Wuoguysbc14rKrRaqrtvC92VK05kD7LBoAT/EGwL/1Ktr16HlQTgBDAXJAGOamxGlH PsLgL4+fS+zbTl3QoE5/HEirkSY7uM9KpL3dopqc4wr1VMeP2zO1Cyb1GeEyMuSkXq3Q K8SuGz/kNzkx74GnPKZuceMf+dJaLyEXJ+Q93KhImo1gFmtHeQV39JjjH+r137Wcyp5E o3alh3v0UXKAmpmRihFL9f0tNdh5ZOzjyfzuqUbvWFjis877awXwERvIt7SNJmgq7koo EhGc0KBBAMnCHXBjHG8xIxA4ijQjKwG1mJIxgbW3+laIulud6cL9Nesi9H2kXh3NG9PY WMVg== 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=kbuwG7O6a0Tu3m97g/1/tCyy5wlgHEBgje6AIie4BsY=; b=Yjc2VOnX5tvYKYXqwd4hCrdPXU6Bbcjwt8Wh3qKcUSDMu+3tBpbtStqh+qkwMqOgB5 dt6Q6ND/sBlThxLem6oD36ZP5Zi3XLqOVG2M3lJ09uzPJ0PeOpTcC+jkWzK8wECdTPr8 6rvt+Bhk9VhLXNNIBsAsoVPp+etlzX+0DboMjlMCXM0+qzPAxow6V/gbX/i+2+iiFB+Z vIh/1B6FtQgqAhTkmTiICHz06FbZk0VybdbgfCa1iNTiwZkmtVGcmasNdiYv3w6F19jq L6lMQ1FY3J3vEqVXgw18ItDoVL8TMoLIDeS2N1TfwUS5Pqu+Fsuu8agJGeHkzkl6oEkL kBqw== X-Gm-Message-State: APjAAAWX6goYXrFRraf837lzmsjOXGYKuWHUXnxMppBclVKiAx27HmPr o0YiTtOU2d9c8TtLA7AWfnmxpJ/bLlNd7D9zpaqUXA== X-Google-Smtp-Source: APXvYqwNw8m9YuOX26+UPbweSVOmb94HrxVueu0RuAftQaXRu0Rvg+m0wv4siGYycYqMUxdSzHpN4lQ5WaPwT8FlRas= X-Received: by 2002:ac2:4a86:: with SMTP id l6mr15188061lfp.51.1557213949490; Tue, 07 May 2019 00:25:49 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Vittorio Bertocci Date: Tue, 7 May 2019 00:25:41 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000004c90d20588472023" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 07:25:59 -0000 --0000000000004c90d20588472023 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For many of the products I have been and I am working on, sub and client_id can't be arbitrarily changed - the examples I provided aren't hypothetical: in my research *all *the providers adding sub in their app only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and in the claim they used to indicate the client identifier. For at least Auth0 and AAD you can't use arbitrary client_ids/formats, you get them assigned by the system= . That's not really legacy, it's current practice - with no counter indications, really. It's not that we are being soft, handling sub and client_id differently isn't some kind of bad practice nor has any security implications. It's an internal implementation detail. I am not sure I see how having a specialized claim would paint us in a corner more than imposing the constraint you are suggesting. That seems to do the exact opposite: it helps ASes to provide the desired functionality without imposing changes that will ripple across their codebase well beyond this particular use case. On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt wrote: > I understand your legacy-breaking point (and do see a name spacing hurdle= ) > but: > a. I feel we're now painting ourselves into a corner ("soft doctors make > stinking wounds"). > b. putting the client_id into the sub value would be something that any > product should be able to do, just like putting an extra claim in; I don'= t > think that is fundamental stuff > > Hans. > > On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci > wrote: > >> Let me try a different angle. An AS might generate sub claims and >> client_id identifiers using a different format/template. That means that >> there might be a client with client_id X that gets assigned a sub value = Y, >> despite the client being the same, hence the check =E2=80=9Csub=3D=3Dcli= ent_id=E2=80=9D would >> fail. >> The logic producing this might be hard for an AS to change as there has >> never been any requirement on client_id or sub formats hence everyone wa= s >> free until now to use whatever logic they chose, including name spacing = one >> but not the other and any other variation, and changes might have ripple >> effects downstream on systems that have nothing to do w this spec (eg >> sharing of where clients are stored might depend on the internal structu= re >> of the client_id). So in other words, an AS might have to touch pretty >> fundamental stuff in its logic and potentially impact scenarios that hav= e >> no direct bearing with the JWT AT profile just for making that condition >> true. On the other plate of the scale, there=E2=80=99s adding a new clai= m- which I >> can literally already do in various commercial ASes via extensibility >> points, without changing their code. >> >> >> On Mon, May 6, 2019 at 15:11 Hans Zandbelt >> wrote: >> >>> I'm suggesting that whichever "sub" and "client_id" the RS is receiving >>> and however it was generated, it must mean something to it in alignment >>> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; >>> moreover, if the "sub" has the same value as "client_id" it must be a >>> client talking to the RS on behalf of its own and the claims are associ= ated >>> with the client; if the "sub" has a different value than the "client_id= " it >>> must be a scenario where the client presents a token delegated by a >>> Resource Owner and the claims are about the Resource Owner. Problem sol= ved? >>> >>> Hans. >>> >>> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci >>> wrote: >>> >>>> I am not following. We want this to be adopted, right? :) if we provid= e >>>> guidance that is sound but hard to implement we are going to fail. >>>> Considerations on whether the guidance requires a big effort to be app= lied >>>> are very much in scope for me. >>>> >>>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt >>>> wrote: >>>> >>>>> the scope and way of generating sub/client_id is orthogonal to the >>>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my ca= se >>>>> >>>>> Hans. >>>>> >>>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci >>>>> wrote: >>>>> >>>>>> See below, Hans- the sub doesn=E2=80=99t have to be global, it could= be >>>>>> something generated just for this particular RS. Or the AS might hav= e its >>>>>> own recipe for generating sub values that different from the recipe = used to >>>>>> generate client_ids. It would be much easier for an AS to emit a cla= im >>>>>> making this explicit statement than to change sub and client_id assi= gnment >>>>>> logic. >>>>>> >>>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt < >>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>> >>>>>>> I may be missing something but I'd argue that by requiring and >>>>>>> comparing both "sub" and "client_id" we achieve the same semantics = without >>>>>>> a new/additional claim (barring name spacing) >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>>>>> 40okta.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> Makes sense that we don=E2=80=99t want to further couple AS and RS= with >>>>>>>> grant types. I=E2=80=99m OK if we want a dedicated claim to estab= lish whether the >>>>>>>> token is resource owner delegated vs client acting as itself. >>>>>>>> >>>>>>>> Subject Type is already a concept in RISC. Just making folks are >>>>>>>> aware of prior art. >>>>>>>> >>>>>>>> >>>>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section= .2.2 >>>>>>>> >>>>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.= 2.1 >>>>>>>> >>>>>>>> -Karl >>>>>>>> >>>>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>> *This message originated outside your organization.* >>>>>>>> ------------------------------ >>>>>>>> Fair enough! What others think about it? >>>>>>>> Exploring the approach: would we want a bool claim or an >>>>>>>> enumeration, e.g. sub_type =3D [ resource_owner | client ] ? >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>>>> vladimir@connect2id.com> wrote: >>>>>>>> >>>>>>>>> Hi Vittorio, >>>>>>>>> >>>>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>>>> > It is true that the grant_type is a client side consideration. = I >>>>>>>>> did think >>>>>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not always >>>>>>>>> applicable: >>>>>>>>> > many systems have their own rules for generating sub, and in >>>>>>>>> case they want >>>>>>>>> > to prevent tracking across RSes the sub might be generated >>>>>>>>> ad-hoc for that >>>>>>>>> > particular RS. >>>>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>>>> between user >>>>>>>>> > and app tokens rather than reusing grant_type? >>>>>>>>> >>>>>>>>> A dedicated claim to flag client_id effectively =3D=3D sub would = be >>>>>>>>> preferable, and much easier for RS developers to process. >>>>>>>>> >>>>>>>>> The AS is the authority and has all the knowledge to set / >>>>>>>>> indicate this. >>>>>>>>> >>>>>>>>> I want to keep RS developers away from having to deal with grant >>>>>>>>> types >>>>>>>>> and having to make decisions whether client_id effectively =3D=3D= sub. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> >>>>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>>>> vladimir@connect2id.com> >>>>>>>>> > wrote: >>>>>>>>> > >>>>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>>>> >>> grant_type as a return claim, which the RS could use to the >>>>>>>>> same >>>>>>>>> >> effect*. I >>>>>>>>> >>> find the proposal very clever, and the people at IIW thought >>>>>>>>> so as well. >>>>>>>>> >>> What you think? >>>>>>>>> >> The grant type is not something that the RS is really concerne= d >>>>>>>>> with, or >>>>>>>>> >> should be. Introducing this parameter in the access token will >>>>>>>>> create an >>>>>>>>> >> additional logical dependency, plus complexity - in the system >>>>>>>>> of >>>>>>>>> >> client, AS and RS as a whole, as well as for RS developers. Th= e >>>>>>>>> grant >>>>>>>>> >> type, as a concept, is a matter between the client and AS, and >>>>>>>>> IMO >>>>>>>>> >> should stay that way. >>>>>>>>> >> >>>>>>>>> >> Clear language in the spec should suffice. For instance: "If >>>>>>>>> the sub >>>>>>>>> >> value matches the client_id value, then the subject is the >>>>>>>>> client >>>>>>>>> >> application". >>>>>>>>> >> >>>>>>>>> >> Vladimir >>>>>>>>> >> >>>>>>>>> >> -- >>>>>>>>> >> Vladimir Dzhuvinov >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> OAuth mailing list >>>>>>>>> >> OAuth@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >> >>>>>>>>> -- >>>>>>>>> Vladimir Dzhuvinov >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --0000000000004c90d20588472023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For many of the products I have been and I am working on, = sub and client_id can't be arbitrarily changed - the examples I provide= d aren't hypothetical: in my research all the providers adding s= ub in their app only ATs (Azure AD, Auth0, Ping Identity) had different val= ues in sub and in the claim they used to indicate the client identifier. Fo= r at least Auth0 and AAD you can't use arbitrary client_ids/formats, yo= u get them assigned by the system.
That's not really legacy, it'= s current practice - with no counter indications, really. It's not that= we are being soft, handling sub and client_id differently isn't some k= ind of bad practice nor has any security implications. It's an internal= implementation detail.

I am not sure I see how having a speci= alized claim would paint us in a corner more than imposing the constraint y= ou are suggesting. That seems to do the exact opposite: it helps ASes to pr= ovide the desired functionality without imposing changes that will ripple a= cross their codebase well beyond this particular use case.

On Tu= e, May 7, 2019 at 12:07 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I understand your legacy-breaking point (and do see a name spacing hurdle)= but:
a. I feel we're now painting ourselves into= a corner ("soft doctors make stinking wounds").
b. putting the client_id into the sub value would be something that a= ny product should be able to do, just like putting an extra claim in; I don= 't think that is fundamental stuff

Hans.
=

= On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
Let me try a different angle. An AS might generate sub claims and client_i= d identifiers using a different format/template. That means that there migh= t be a client with client_id X that gets assigned a sub value Y, despite th= e client being the same, hence the check =E2=80=9Csub=3D=3Dclient_id=E2=80= =9D would fail.
The logic producing this might be ha= rd for an AS to change as there has never been any requirement on client_id= or sub formats hence everyone was free until now to use whatever logic the= y chose, including name spacing one but not the other and any other variati= on, and changes might have ripple effects downstream on systems that have n= othing to do w this spec (eg sharing of where clients are stored might depe= nd on the internal structure of the client_id). So in other words, an AS mi= ght have to touch pretty fundamental stuff in its logic and potentially imp= act scenarios that have no direct bearing with the JWT AT profile just for = making that condition true. On the other plate of the scale, there=E2=80=99= s adding a new claim- which I can literally already do in various commercia= l ASes via extensibility points, without changing their code.


On Mon, May 6, 2019 at 15:11 Hans Zandbelt <hans.zandbelt@= zmartzone.eu> wrote:
I'm suggesting that whichever "sub&qu= ot; and "client_id" the RS is receiving and however it was genera= ted, it must mean something to it in alignment with the JWT/OAuth2/OIDC spe= cs, otherwise it wouldn't be there at all; moreover, if the "sub&q= uot; has the same value as "client_id" it must be a client talkin= g to the RS on behalf of its own and the claims are associated with the cli= ent; if the "sub" has a different value than the "client_id&= quot; it must be a scenario where the client presents a token delegated by = a Resource Owner and the claims are about the Resource Owner. Problem solve= d?

Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio B= ertocci <Vittori= o@auth0.com> wrote:
I am not following. We want this to be ad= opted, right? :) if we provide guidance that is sound but hard to implement= we are going to fail. Considerations on whether the guidance requires a bi= g effort to be applied are very much in scope for me.=C2=A0

On Mo= n, May 6, 2019 at 14:54 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
t= he scope and way of generating sub/client_id is orthogonal to the semantics= IMHO but if I'm the only one who thinks so, I'll rest my case
=
Hans.

On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci= <Vittorio@auth0= .com> wrote:
See below, Hans- the sub doesn=E2=80=99t have to= be global, it could be something generated just for this particular RS. Or= the AS might have its own recipe for generating sub values that different = from the recipe used to generate client_ids. It would be much easier for an= AS to emit a claim making this explicit statement than to change sub and c= lient_id assignment logic.

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 6, 2019 at 13:49 Hans Zand= belt <ha= ns.zandbelt@zmartzone.eu> wrote:
I may be missing = something but I'd argue that by requiring and comparing both "sub&= quot; and "client_id" we achieve the same semantics without a new= /additional claim (barring name spacing)

Hans.

On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dma= rc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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



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

=


--


--
--0000000000004c90d20588472023-- From nobody Tue May 7 00:30: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 0AA1212001E for ; Tue, 7 May 2019 00:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 XE4fL6y5qZ6t for ; Tue, 7 May 2019 00:30:25 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 BC38B1200B4 for ; Tue, 7 May 2019 00:30:20 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id d13so954447qth.5 for ; Tue, 07 May 2019 00:30:20 -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=dDCN9gdH1sgKPvaKDmGu8vS38u40GQaxZVtNHHsL1qo=; b=Z1rgnk8lbJISC42/lOkZV/4LNhXVrm1fTJnLlbruwMmwqThQOZpwyM0lKEmJQ42gj4 DZIxlG6NI+xuT8TYde2meEBxAf5eh3eltUBjE+8crj8NXsxwsqcEs+5BVseA94JLxy3h l4tTBF/HwfQL4Fjf2AxkDvbZ8qStC9fR1dReLeBWXQhv1YaG0GWVIKHOILZgJfEPaRgA dcrXjQ27zdLDqXz4qdWTA5cwytifObl4Ovy7xcJMFW4yVfYIWbVdzkOJsLf1AuOR9QxO dcxr1K4SjsFF0/zL2/AblrJ2gF8C69zusGyvyo4IdztyW/9xOT+Mc2HTbnKTNrkeGl8x GIRA== 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=dDCN9gdH1sgKPvaKDmGu8vS38u40GQaxZVtNHHsL1qo=; b=ll6KnMKtVw728j9JzpBUiB7MXYe4y+6I1QFpmKt9wpj0blGhDZQ/2vswtVRgZSiwAc HyyuBxzKB61KtnpLCWIwy2fp45D63y0GOvbLmE9q/kj8AMyq1wfputfoYDpjc13oJqz6 Y86NJJAcNiW+PTgZ4/RLMNTo0w4PMjOw5WfPX0RYMeZlrd4zgIIswPplZbZdf41a99Qb NbvLZO9Z2aijL+8ozwR2P6605XDOENfY3WnVWVtwGFQIBQKS7Crlpo4XFhw4x+uH5Atm tt8cwCOfGoGZ6FKkOlQdyEtaCZsPZjpM2muASanB7rOqe7t38pKpkg9zwcMJM7KIo8SK LCaA== X-Gm-Message-State: APjAAAXmnsNngozFNjF+xkjTBJ7Ju8csultXbSDgjmzMKJjbrxO4N81z P7Rmy4YnDdy7aXdhyxYMlTau2YDJjuHmxjZGu/3sKA== X-Google-Smtp-Source: APXvYqwaryCXRniwX4bV866gJNMG4bF1tbTh7PfivcI+MhBOHueegerH0Qjn7nmOckxfFFMeGZNGKlb+XvowcoSni6U= X-Received: by 2002:ac8:2a0c:: with SMTP id k12mr25597377qtk.197.1557214219627; Tue, 07 May 2019 00:30:19 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Hans Zandbelt Date: Tue, 7 May 2019 08:30:07 +0100 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="00000000000066851205884730a2" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 07:30:29 -0000 --00000000000066851205884730a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable using 2 existing + 1 new (=3D3) claims to say the token is about the client to me suggests something went sideways in the past and were unable to fix it in a clean way Hans. On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci wrote= : > For many of the products I have been and I am working on, sub and > client_id can't be arbitrarily changed - the examples I provided aren't > hypothetical: in my research *all *the providers adding sub in their app > only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and > in the claim they used to indicate the client identifier. For at least > Auth0 and AAD you can't use arbitrary client_ids/formats, you get them > assigned by the system. > That's not really legacy, it's current practice - with no counter > indications, really. It's not that we are being soft, handling sub and > client_id differently isn't some kind of bad practice nor has any securit= y > implications. It's an internal implementation detail. > > I am not sure I see how having a specialized claim would paint us in a > corner more than imposing the constraint you are suggesting. That seems t= o > do the exact opposite: it helps ASes to provide the desired functionality > without imposing changes that will ripple across their codebase well beyo= nd > this particular use case. > > On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt > wrote: > >> I understand your legacy-breaking point (and do see a name spacing >> hurdle) but: >> a. I feel we're now painting ourselves into a corner ("soft doctors make >> stinking wounds"). >> b. putting the client_id into the sub value would be something that any >> product should be able to do, just like putting an extra claim in; I don= 't >> think that is fundamental stuff >> >> Hans. >> >> On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci >> wrote: >> >>> Let me try a different angle. An AS might generate sub claims and >>> client_id identifiers using a different format/template. That means tha= t >>> there might be a client with client_id X that gets assigned a sub value= Y, >>> despite the client being the same, hence the check =E2=80=9Csub=3D=3Dcl= ient_id=E2=80=9D would >>> fail. >>> The logic producing this might be hard for an AS to change as there has >>> never been any requirement on client_id or sub formats hence everyone w= as >>> free until now to use whatever logic they chose, including name spacing= one >>> but not the other and any other variation, and changes might have rippl= e >>> effects downstream on systems that have nothing to do w this spec (eg >>> sharing of where clients are stored might depend on the internal struct= ure >>> of the client_id). So in other words, an AS might have to touch pretty >>> fundamental stuff in its logic and potentially impact scenarios that ha= ve >>> no direct bearing with the JWT AT profile just for making that conditio= n >>> true. On the other plate of the scale, there=E2=80=99s adding a new cla= im- which I >>> can literally already do in various commercial ASes via extensibility >>> points, without changing their code. >>> >>> >>> On Mon, May 6, 2019 at 15:11 Hans Zandbelt >>> wrote: >>> >>>> I'm suggesting that whichever "sub" and "client_id" the RS is receivin= g >>>> and however it was generated, it must mean something to it in alignmen= t >>>> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all; >>>> moreover, if the "sub" has the same value as "client_id" it must be a >>>> client talking to the RS on behalf of its own and the claims are assoc= iated >>>> with the client; if the "sub" has a different value than the "client_i= d" it >>>> must be a scenario where the client presents a token delegated by a >>>> Resource Owner and the claims are about the Resource Owner. Problem so= lved? >>>> >>>> Hans. >>>> >>>> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci >>>> wrote: >>>> >>>>> I am not following. We want this to be adopted, right? :) if we >>>>> provide guidance that is sound but hard to implement we are going to = fail. >>>>> Considerations on whether the guidance requires a big effort to be ap= plied >>>>> are very much in scope for me. >>>>> >>>>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt >>>>> wrote: >>>>> >>>>>> the scope and way of generating sub/client_id is orthogonal to the >>>>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my c= ase >>>>>> >>>>>> Hans. >>>>>> >>>>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci >>>>>> wrote: >>>>>> >>>>>>> See below, Hans- the sub doesn=E2=80=99t have to be global, it coul= d be >>>>>>> something generated just for this particular RS. Or the AS might ha= ve its >>>>>>> own recipe for generating sub values that different from the recipe= used to >>>>>>> generate client_ids. It would be much easier for an AS to emit a cl= aim >>>>>>> making this explicit statement than to change sub and client_id ass= ignment >>>>>>> logic. >>>>>>> >>>>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt < >>>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>>> >>>>>>>> I may be missing something but I'd argue that by requiring and >>>>>>>> comparing both "sub" and "client_id" we achieve the same semantics= without >>>>>>>> a new/additional claim (barring name spacing) >>>>>>>> >>>>>>>> Hans. >>>>>>>> >>>>>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>>>>>> 40okta.com@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> Makes sense that we don=E2=80=99t want to further couple AS and R= S with >>>>>>>>> grant types. I=E2=80=99m OK if we want a dedicated claim to esta= blish whether the >>>>>>>>> token is resource owner delegated vs client acting as itself. >>>>>>>>> >>>>>>>>> Subject Type is already a concept in RISC. Just making folks are >>>>>>>>> aware of prior art. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.sectio= n.2.2 >>>>>>>>> >>>>>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section= .2.1 >>>>>>>>> >>>>>>>>> -Karl >>>>>>>>> >>>>>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>> *This message originated outside your organization.* >>>>>>>>> ------------------------------ >>>>>>>>> Fair enough! What others think about it? >>>>>>>>> Exploring the approach: would we want a bool claim or an >>>>>>>>> enumeration, e.g. sub_type =3D [ resource_owner | client ] ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>>>>> vladimir@connect2id.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Vittorio, >>>>>>>>>> >>>>>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>>>>> > It is true that the grant_type is a client side consideration. >>>>>>>>>> I did think >>>>>>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not alway= s >>>>>>>>>> applicable: >>>>>>>>>> > many systems have their own rules for generating sub, and in >>>>>>>>>> case they want >>>>>>>>>> > to prevent tracking across RSes the sub might be generated >>>>>>>>>> ad-hoc for that >>>>>>>>>> > particular RS. >>>>>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>>>>> between user >>>>>>>>>> > and app tokens rather than reusing grant_type? >>>>>>>>>> >>>>>>>>>> A dedicated claim to flag client_id effectively =3D=3D sub would= be >>>>>>>>>> preferable, and much easier for RS developers to process. >>>>>>>>>> >>>>>>>>>> The AS is the authority and has all the knowledge to set / >>>>>>>>>> indicate this. >>>>>>>>>> >>>>>>>>>> I want to keep RS developers away from having to deal with grant >>>>>>>>>> types >>>>>>>>>> and having to make decisions whether client_id effectively =3D= =3D sub. >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>>>>> vladimir@connect2id.com> >>>>>>>>>> > wrote: >>>>>>>>>> > >>>>>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>>>>> >>> grant_type as a return claim, which the RS could use to the >>>>>>>>>> same >>>>>>>>>> >> effect*. I >>>>>>>>>> >>> find the proposal very clever, and the people at IIW thought >>>>>>>>>> so as well. >>>>>>>>>> >>> What you think? >>>>>>>>>> >> The grant type is not something that the RS is really >>>>>>>>>> concerned with, or >>>>>>>>>> >> should be. Introducing this parameter in the access token wil= l >>>>>>>>>> create an >>>>>>>>>> >> additional logical dependency, plus complexity - in the syste= m >>>>>>>>>> of >>>>>>>>>> >> client, AS and RS as a whole, as well as for RS developers. >>>>>>>>>> The grant >>>>>>>>>> >> type, as a concept, is a matter between the client and AS, an= d >>>>>>>>>> IMO >>>>>>>>>> >> should stay that way. >>>>>>>>>> >> >>>>>>>>>> >> Clear language in the spec should suffice. For instance: "If >>>>>>>>>> the sub >>>>>>>>>> >> value matches the client_id value, then the subject is the >>>>>>>>>> client >>>>>>>>>> >> application". >>>>>>>>>> >> >>>>>>>>>> >> Vladimir >>>>>>>>>> >> >>>>>>>>>> >> -- >>>>>>>>>> >> Vladimir Dzhuvinov >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> _______________________________________________ >>>>>>>>>> >> OAuth mailing list >>>>>>>>>> >> OAuth@ietf.org >>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >> >>>>>>>>>> -- >>>>>>>>>> Vladimir Dzhuvinov >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> hans.zandbelt@zmartzone.eu >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>> >>>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --00000000000066851205884730a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
using 2 existing=C2=A0+ 1 new (=3D3) claims to say the tok= en is about the client to me suggests something went sideways in the past a= nd were unable to fix it in a clean way

Hans.

On Tu= e, May 7, 2019 at 8:25 AM Vittorio Bertocci <Vittorio@auth0.com> wrote:
For many of the products I ha= ve been and I am working on, sub and client_id can't be arbitrarily cha= nged - the examples I provided aren't hypothetical: in my research a= ll the providers adding sub in their app only ATs (Azure AD, Auth0, Pin= g Identity) had different values in sub and in the claim they used to indic= ate the client identifier. For at least Auth0 and AAD you can't use arb= itrary client_ids/formats, you get them assigned by the system.
That'= ;s not really legacy, it's current practice - with no counter indicatio= ns, really. It's not that we are being soft, handling sub and client_id= differently isn't some kind of bad practice nor has any security impli= cations. It's an internal implementation detail.

I am not = sure I see how having a specialized claim would paint us in a corner more t= han imposing the constraint you are suggesting. That seems to do the exact = opposite: it helps ASes to provide the desired functionality without imposi= ng changes that will ripple across their codebase well beyond this particul= ar use case.

On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt <<= a href=3D"mailto:hans.zandbelt@zmartzone.eu" target=3D"_blank">hans.zandbel= t@zmartzone.eu> wrote:
I understand your legacy-br= eaking point (and do see a name spacing hurdle) but:
= a. I feel we're now painting ourselves into a corner ("soft doctor= s make stinking wounds").
b. putting the client_= id into the sub value would be something that any product should be able to= do, just like putting an extra claim in; I don't think that is fundame= ntal stuff

Hans.

On Mon, May 6, 2019 at 11:22= PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
Let me try a different angl= e. An AS might generate sub claims and client_id identifiers using a differ= ent format/template. That means that there might be a client with client_id= X that gets assigned a sub value Y, despite the client being the same, hen= ce the check =E2=80=9Csub=3D=3Dclient_id=E2=80=9D would fail.
The logic producing this might be hard for an AS to change as the= re has never been any requirement on client_id or sub formats hence everyon= e was free until now to use whatever logic they chose, including name spaci= ng one but not the other and any other variation, and changes might have ri= pple effects downstream on systems that have nothing to do w this spec (eg = sharing of where clients are stored might depend on the internal structure = of the client_id). So in other words, an AS might have to touch pretty fund= amental stuff in its logic and potentially impact scenarios that have no di= rect bearing with the JWT AT profile just for making that condition true. O= n the other plate of the scale, there=E2=80=99s adding a new claim- which I= can literally already do in various commercial ASes via extensibility poin= ts, without changing their code.


On M= on, May 6, 2019 at 15:11 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
= I'm suggesting that whichever "sub" and "client_id"= the RS is receiving and however it was generated, it must mean something t= o it in alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't= be there at all; moreover, if the "sub" has the same value as &q= uot;client_id" it must be a client talking to the RS on behalf of its = own and the claims are associated with the client; if the "sub" h= as a different value than the "client_id" it must be a scenario w= here the client presents a token delegated by a Resource Owner and the clai= ms are about the Resource Owner. Problem solved?

Hans.

On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
I am not following. We want this to be adopted, right? :) if we provid= e guidance that is sound but hard to implement we are going to fail. Consid= erations on whether the guidance requires a big effort to be applied are ve= ry much in scope for me.=C2=A0

On Mon, May 6, 2019 at 14:54 Hans = Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
the scope and way of generatin= g sub/client_id is orthogonal to the semantics IMHO but if I'm the only= one who thinks so, I'll rest my case

Hans.

On = Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
=
Se= e below, Hans- the sub doesn=E2=80=99t have to be global, it could be somet= hing generated just for this particular RS. Or the AS might have its own re= cipe for generating sub values that different from the recipe used to gener= ate client_ids. It would be much easier for an AS to emit a claim making th= is explicit statement than to change sub and client_id assignment logic.

On Mon, May 6, 2019 at 13:49 Hans Zandbelt <hans.zandbelt@zmartzone.eu&= gt; wrote:
I may be missing something but I'd argue t= hat by requiring and comparing both "sub" and "client_id&quo= t; we achieve the same semantics without a new/additional claim (barring na= me spacing)

Hans.

On Mon, May 6, 2019 = at 8:58 PM Karl McGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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


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

=


--


--


--
--00000000000066851205884730a2-- From nobody Tue May 7 00:50:48 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 697861200A2 for ; Tue, 7 May 2019 00:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhKVuXEFfnBC for ; Tue, 7 May 2019 00:50:41 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 04D6912001E for ; Tue, 7 May 2019 00:50:41 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id d8so11061049lfb.8 for ; Tue, 07 May 2019 00:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6jYx1uFs9dpf9rj/ehIbusxbTLIcZC4/6hjDXAQDoaw=; b=UYGfXLPfWT8GVbetPWltHQe2Z1FzewdgMqNQwC+F43DuiRmoJRs9VtL9Hd/DfyZxfw /+JYnLEQR+6YROI/wlkjphhUL+Pzo6BZAUENuScSga5e9MCH3nPm9XXnuGNahAT/WUYh t02+s3cQeg0Zq7xMIZkZ1zPcI42uR4nIiHZmYiNmDcxY+CnNnPRzG8dLA3UlreOo3JUh 3Rt151PaB57e/fFGiks1Z5KYVkPCmp7tkiPdRjWf1R+aSctf1wLxPOiZiOJtu1th3eCF wUzVtAuWZDKjnMyqxoncgRNxGjBAdm2gtRpsdzzrBd+5iIaY9qXfSE8ZDMFBzr/MbZdy nPdg== 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=6jYx1uFs9dpf9rj/ehIbusxbTLIcZC4/6hjDXAQDoaw=; b=m9oVTt8RMKWJjCvModCyueu+pLZzaHtoKzqBWHGvYW5iya+ZbmWRj5wfwNxoBL/4rX K+dFf2bSG2qVNmMh4PtTPQjQOoEQ5GgVoumNa4tTCs6mdfKj04Wzx1fAI1PL1l0JXUCN icCu7RMT6ObBEgzwomdIQwmWI9saVtEnRXXFYpXqd/MrRx0u9/ifTrYgUrDJoLVLYAl5 AxcgYRZG7Sr76G5UqfIeG7gY6WTM4j0fKva1xVeuIWUR1uPRCUw0U5b+AKXbN72o75dd cPJ1WO/jfAPz2dApI4UWJnM1zKvePVd4H3PwsTITi7j6+aMqYmQmu6G0RD5BqMHoWV16 Um5w== X-Gm-Message-State: APjAAAWjglxUqRXgylHABhBo15w25/vUuL1Gp8FH7AQzvW4v3qlQhAhf vRGgKTjcmXuozgQv9AeVlQADJucDcSbxOTkkEKs2DA== X-Google-Smtp-Source: APXvYqyvkK2NC8Xu5Y5BwGCeFxpJfaVJZuVV+u28sUJXAfZz4aT3QSpdAqNQy9UJkiHzigc+lfyzFth0GlYloobrWM0= X-Received: by 2002:ac2:51a1:: with SMTP id f1mr14259429lfk.129.1557215439044; Tue, 07 May 2019 00:50:39 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> In-Reply-To: From: Vittorio Bertocci Date: Tue, 7 May 2019 00:50:30 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Karl McGuinness , Vittorio Bertocci Content-Type: multipart/alternative; boundary="000000000000155a7105884779a9" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 07:50:46 -0000 --000000000000155a7105884779a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It looks like we'll have to agree to disagree on this one :) to me we aren't using 3 claims to say that the token is about the client. Sub and client_id have their independent reasons to be in the token. Expressing the fact that a token is about an app should not have the side effect of forbidding a sub to be RS-specific, for example. On Tue, May 7, 2019 at 12:30 AM Hans Zandbelt wrote: > using 2 existing + 1 new (=3D3) claims to say the token is about the clie= nt > to me suggests something went sideways in the past and were unable to fix > it in a clean way > > Hans. > > On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci > wrote: > >> For many of the products I have been and I am working on, sub and >> client_id can't be arbitrarily changed - the examples I provided aren't >> hypothetical: in my research *all *the providers adding sub in their app >> only ATs (Azure AD, Auth0, Ping Identity) had different values in sub an= d >> in the claim they used to indicate the client identifier. For at least >> Auth0 and AAD you can't use arbitrary client_ids/formats, you get them >> assigned by the system. >> That's not really legacy, it's current practice - with no counter >> indications, really. It's not that we are being soft, handling sub and >> client_id differently isn't some kind of bad practice nor has any securi= ty >> implications. It's an internal implementation detail. >> >> I am not sure I see how having a specialized claim would paint us in a >> corner more than imposing the constraint you are suggesting. That seems = to >> do the exact opposite: it helps ASes to provide the desired functionalit= y >> without imposing changes that will ripple across their codebase well bey= ond >> this particular use case. >> >> On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt >> wrote: >> >>> I understand your legacy-breaking point (and do see a name spacing >>> hurdle) but: >>> a. I feel we're now painting ourselves into a corner ("soft doctors mak= e >>> stinking wounds"). >>> b. putting the client_id into the sub value would be something that any >>> product should be able to do, just like putting an extra claim in; I do= n't >>> think that is fundamental stuff >>> >>> Hans. >>> >>> On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci >>> wrote: >>> >>>> Let me try a different angle. An AS might generate sub claims and >>>> client_id identifiers using a different format/template. That means th= at >>>> there might be a client with client_id X that gets assigned a sub valu= e Y, >>>> despite the client being the same, hence the check =E2=80=9Csub=3D=3Dc= lient_id=E2=80=9D would >>>> fail. >>>> The logic producing this might be hard for an AS to change as there ha= s >>>> never been any requirement on client_id or sub formats hence everyone = was >>>> free until now to use whatever logic they chose, including name spacin= g one >>>> but not the other and any other variation, and changes might have ripp= le >>>> effects downstream on systems that have nothing to do w this spec (eg >>>> sharing of where clients are stored might depend on the internal struc= ture >>>> of the client_id). So in other words, an AS might have to touch pretty >>>> fundamental stuff in its logic and potentially impact scenarios that h= ave >>>> no direct bearing with the JWT AT profile just for making that conditi= on >>>> true. On the other plate of the scale, there=E2=80=99s adding a new cl= aim- which I >>>> can literally already do in various commercial ASes via extensibility >>>> points, without changing their code. >>>> >>>> >>>> On Mon, May 6, 2019 at 15:11 Hans Zandbelt >>>> wrote: >>>> >>>>> I'm suggesting that whichever "sub" and "client_id" the RS is >>>>> receiving and however it was generated, it must mean something to it = in >>>>> alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be th= ere at >>>>> all; moreover, if the "sub" has the same value as "client_id" it must= be a >>>>> client talking to the RS on behalf of its own and the claims are asso= ciated >>>>> with the client; if the "sub" has a different value than the "client_= id" it >>>>> must be a scenario where the client presents a token delegated by a >>>>> Resource Owner and the claims are about the Resource Owner. Problem s= olved? >>>>> >>>>> Hans. >>>>> >>>>> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci >>>>> wrote: >>>>> >>>>>> I am not following. We want this to be adopted, right? :) if we >>>>>> provide guidance that is sound but hard to implement we are going to= fail. >>>>>> Considerations on whether the guidance requires a big effort to be a= pplied >>>>>> are very much in scope for me. >>>>>> >>>>>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt < >>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>> >>>>>>> the scope and way of generating sub/client_id is orthogonal to the >>>>>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my = case >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci < >>>>>>> Vittorio@auth0.com> wrote: >>>>>>> >>>>>>>> See below, Hans- the sub doesn=E2=80=99t have to be global, it cou= ld be >>>>>>>> something generated just for this particular RS. Or the AS might h= ave its >>>>>>>> own recipe for generating sub values that different from the recip= e used to >>>>>>>> generate client_ids. It would be much easier for an AS to emit a c= laim >>>>>>>> making this explicit statement than to change sub and client_id as= signment >>>>>>>> logic. >>>>>>>> >>>>>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt < >>>>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>>>> >>>>>>>>> I may be missing something but I'd argue that by requiring and >>>>>>>>> comparing both "sub" and "client_id" we achieve the same semantic= s without >>>>>>>>> a new/additional claim (barring name spacing) >>>>>>>>> >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness >>>>>>>> 40okta.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> Makes sense that we don=E2=80=99t want to further couple AS and = RS with >>>>>>>>>> grant types. I=E2=80=99m OK if we want a dedicated claim to est= ablish whether the >>>>>>>>>> token is resource owner delegated vs client acting as itself. >>>>>>>>>> >>>>>>>>>> Subject Type is already a concept in RISC. Just making folks ar= e >>>>>>>>>> aware of prior art. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.secti= on.2.2 >>>>>>>>>> >>>>>>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.sectio= n.2.1 >>>>>>>>>> >>>>>>>>>> -Karl >>>>>>>>>> >>>>>>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>>>>> >>>>>>>>>> *This message originated outside your organization.* >>>>>>>>>> ------------------------------ >>>>>>>>>> Fair enough! What others think about it? >>>>>>>>>> Exploring the approach: would we want a bool claim or an >>>>>>>>>> enumeration, e.g. sub_type =3D [ resource_owner | client ] ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>>>>>> vladimir@connect2id.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Vittorio, >>>>>>>>>>> >>>>>>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>>>>>> > It is true that the grant_type is a client side consideration= . >>>>>>>>>>> I did think >>>>>>>>>>> > about the "client_id=3D=3Dsub" heuristic, but that's not alwa= ys >>>>>>>>>>> applicable: >>>>>>>>>>> > many systems have their own rules for generating sub, and in >>>>>>>>>>> case they want >>>>>>>>>>> > to prevent tracking across RSes the sub might be generated >>>>>>>>>>> ad-hoc for that >>>>>>>>>>> > particular RS. >>>>>>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>>>>>> between user >>>>>>>>>>> > and app tokens rather than reusing grant_type? >>>>>>>>>>> >>>>>>>>>>> A dedicated claim to flag client_id effectively =3D=3D sub woul= d be >>>>>>>>>>> preferable, and much easier for RS developers to process. >>>>>>>>>>> >>>>>>>>>>> The AS is the authority and has all the knowledge to set / >>>>>>>>>>> indicate this. >>>>>>>>>>> >>>>>>>>>>> I want to keep RS developers away from having to deal with gran= t >>>>>>>>>>> types >>>>>>>>>>> and having to make decisions whether client_id effectively =3D= =3D >>>>>>>>>>> sub. >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>>>>>> vladimir@connect2id.com> >>>>>>>>>>> > wrote: >>>>>>>>>>> > >>>>>>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>>>>>> >>> grant_type as a return claim, which the RS could use to the >>>>>>>>>>> same >>>>>>>>>>> >> effect*. I >>>>>>>>>>> >>> find the proposal very clever, and the people at IIW though= t >>>>>>>>>>> so as well. >>>>>>>>>>> >>> What you think? >>>>>>>>>>> >> The grant type is not something that the RS is really >>>>>>>>>>> concerned with, or >>>>>>>>>>> >> should be. Introducing this parameter in the access token >>>>>>>>>>> will create an >>>>>>>>>>> >> additional logical dependency, plus complexity - in the >>>>>>>>>>> system of >>>>>>>>>>> >> client, AS and RS as a whole, as well as for RS developers. >>>>>>>>>>> The grant >>>>>>>>>>> >> type, as a concept, is a matter between the client and AS, >>>>>>>>>>> and IMO >>>>>>>>>>> >> should stay that way. >>>>>>>>>>> >> >>>>>>>>>>> >> Clear language in the spec should suffice. For instance: "If >>>>>>>>>>> the sub >>>>>>>>>>> >> value matches the client_id value, then the subject is the >>>>>>>>>>> client >>>>>>>>>>> >> application". >>>>>>>>>>> >> >>>>>>>>>>> >> Vladimir >>>>>>>>>>> >> >>>>>>>>>>> >> -- >>>>>>>>>>> >> Vladimir Dzhuvinov >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> >> OAuth mailing list >>>>>>>>>>> >> OAuth@ietf.org >>>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >> >>>>>>>>>>> -- >>>>>>>>>>> Vladimir Dzhuvinov >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> hans.zandbelt@zmartzone.eu >>>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --000000000000155a7105884779a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It looks like we'll have to agree to disagree on this = one :) to me we aren't using 3 claims to say that the token is about th= e client. Sub and client_id have their independent reasons to be in the tok= en. Expressing the fact that a token is about an app should not have the si= de effect of forbidding a sub to be RS-specific, for example.=C2=A0
On Tue, = May 7, 2019 at 12:30 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
using 2 existing=C2= =A0+ 1 new (=3D3) claims to say the token is about the client to me suggest= s something went sideways in the past and were unable to fix it in a clean = way

Hans.

On Tue, May 7, 2019 at 8:25 AM Vittorio B= ertocci <Vittori= o@auth0.com> wrote:
For many of the products I have been and I am w= orking on, sub and client_id can't be arbitrarily changed - the example= s I provided aren't hypothetical: in my research all the provide= rs adding sub in their app only ATs (Azure AD, Auth0, Ping Identity) had di= fferent values in sub and in the claim they used to indicate the client ide= ntifier. For at least Auth0 and AAD you can't use arbitrary client_ids/= formats, you get them assigned by the system.
That's not really lega= cy, it's current practice - with no counter indications, really. It'= ;s not that we are being soft, handling sub and client_id differently isn&#= 39;t some kind of bad practice nor has any security implications. It's = an internal implementation detail.

I am not sure I see how hav= ing a specialized claim would paint us in a corner more than imposing the c= onstraint you are suggesting. That seems to do the exact opposite: it helps= ASes to provide the desired functionality without imposing changes that wi= ll ripple across their codebase well beyond this particular use case.
=

On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu= > wrote:
I understand your legacy-breaking point (and = do see a name spacing hurdle) but:
a. I feel we'r= e now painting ourselves into a corner ("soft doctors make stinking wo= unds").
b. putting the client_id into the sub va= lue would be something that any product should be able to do, just like put= ting an extra claim in; I don't think that is fundamental stuff
Hans.

On Mon, May 6, 2019 at 11:22 PM Vittorio Bert= occi <Vittorio@a= uth0.com> wrote:
Let me try a different angle. An AS might ge= nerate sub claims and client_id identifiers using a different format/templa= te. That means that there might be a client with client_id X that gets assi= gned a sub value Y, despite the client being the same, hence the check =E2= =80=9Csub=3D=3Dclient_id=E2=80=9D would fail.
The lo= gic producing this might be hard for an AS to change as there has never bee= n any requirement on client_id or sub formats hence everyone was free until= now to use whatever logic they chose, including name spacing one but not t= he other and any other variation, and changes might have ripple effects dow= nstream on systems that have nothing to do w this spec (eg sharing of where= clients are stored might depend on the internal structure of the client_id= ). So in other words, an AS might have to touch pretty fundamental stuff in= its logic and potentially impact scenarios that have no direct bearing wit= h the JWT AT profile just for making that condition true. On the other plat= e of the scale, there=E2=80=99s adding a new claim- which I can literally a= lready do in various commercial ASes via extensibility points, without chan= ging their code.


On Mon, May 6, 2019 = at 15:11 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I'm suggesti= ng that whichever "sub" and "client_id" the RS is recei= ving and however it was generated, it must mean something to it in alignmen= t with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all= ; moreover, if the "sub" has the same value as "client_id&qu= ot; it must be a client talking to the RS on behalf of its own and the clai= ms are associated with the client; if the "sub" has a different v= alue than the "client_id" it must be a scenario where the client = presents a token delegated by a Resource Owner and the claims are about the= Resource Owner. Problem solved?

Hans.

On Mon, May = 6, 2019 at 11:06 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
I am not fo= llowing. We want this to be adopted, right? :) if we provide guidance that = is sound but hard to implement we are going to fail. Considerations on whet= her the guidance requires a big effort to be applied are very much in scope= for me.=C2=A0

On Mon, May 6, 2019 at 14:54 Hans Zandbelt <hans.zandbelt@= zmartzone.eu> wrote:
the scope and way of generating sub/client_id = is orthogonal to the semantics IMHO but if I'm the only one who thinks = so, I'll rest my case

Hans.

On Mon, May 6, 2019= at 10:49 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
See below, Hans- t= he sub doesn=E2=80=99t have to be global, it could be something generated j= ust for this particular RS. Or the AS might have its own recipe for generat= ing sub values that different from the recipe used to generate client_ids. = It would be much easier for an AS to emit a claim making this explicit stat= ement than to change sub and client_id assignment logic.
On Mon, = May 6, 2019 at 13:49 Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I may be missing something but I'd argue that by requiring= and comparing both "sub" and "client_id" we achieve th= e same semantics without a new/additional claim (barring name spacing)

Hans.

=
On Mon, May 6, 2019 at 8:58 PM Karl M= cGuinness <kmcguinness=3D40okta.com@dmarc.ietf.org> wrote:
Makes sense that we don=E2=80=99t want to further couple AS and RS wit= h grant types.=C2=A0 I=E2=80=99m OK if we want a dedicated claim to establi= sh whether the token is resource owner delegated =C2=A0vs client acting as = itself.

Subject Type is already a concept in RISC.=C2=A0 Just making folks are awar= e of prior art. =C2=A0


-Karl

On May 6, 2019, at 12:42 PM, Vittorio Bertocci <Vittorio=3D40auth0.= com@dmarc.ietf.org> wrote:

This message originated outside your organization.
Fair enough! What others think about it?
Exploring the approach: would we want a bool claim or an enumeration, = e.g. sub_type =3D [ resource_owner | client ] ?


On Mon, May 6, 2019 at 12:35 PM Vladi= mir Dzhuvinov <vladimir@connect2id.com> wrote:
Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did t= hink
> about the "client_id=3D=3Dsub" heuristic, but that's not= always applicable:
> many systems have their own rules for generating sub, and in case they= want
> to prevent tracking across RSes the sub might be generated ad-hoc for = that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between us= er
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively =3D=3D sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.
I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively =3D=3D sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <vladimir@connect2id.com&g= t;
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the sa= me
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought s= o as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned wi= th, or
>> should be. Introducing this parameter in the access token will cre= ate an
>> additional logical dependency, plus complexity - in the system of<= br> >> client, AS and RS as a whole, as well as for RS developers. The gr= ant
>> type, as a concept, is a matter between the client and AS, and IMO=
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If = the sub
>> value matches the client_id value, then the subject is the client<= br> >> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--
Vladimir Dzhuvinov


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

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


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

=

--
<= div dir=3D"ltr">ZmartZone IAM - www.zmartzone.eu


--


--


--
--000000000000155a7105884779a9-- From nobody Tue May 7 01:25: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 620C712009E for ; Tue, 7 May 2019 01:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meQSpY0fHFK2 for ; Tue, 7 May 2019 01:25:37 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10072.outbound.protection.outlook.com [40.107.1.72]) (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 DFF8812001E for ; Tue, 7 May 2019 01:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=32hJJBCdZNHsuNWkZJKOKm5aH6Qy1ljzWVyN4YTMnP0=; b=jf7eJJKlXyKFwXvIRzeyd/NCtRgdFqk8oRXbbMNDH7F6fae6y1dPcgGdgwespn4G0Om9WWMO843jCVjYPirP0QyXvjhE66DXr/EXJWv33rOgU3PgwiYjATY9tyBg0CAlQGqd21zEJnbLksYcZOeF061BRpnOoyTYi/vA5/waVxk= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4728.eurprd08.prod.outlook.com (10.255.79.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 7 May 2019 08:25:34 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 08:25:34 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: MTLS vs. DPOP Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQ== Date: Tue, 7 May 2019 08:25:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 763b84da-368d-402d-cda2-08d6d2c59379 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4728; x-ms-traffictypediagnostic: DBBPR08MB4728: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(396003)(376002)(366004)(199004)(189003)(53754006)(40434004)(66446008)(66556008)(66476007)(66946007)(76116006)(73956011)(7736002)(74316002)(2906002)(52536014)(6436002)(71200400001)(316002)(86362001)(71190400001)(478600001)(25786009)(66066001)(72206003)(486006)(476003)(55016002)(186003)(81166006)(81156014)(1730700003)(9686003)(64756008)(54896002)(6306002)(53936002)(5640700003)(99286004)(33656002)(3846002)(14454004)(6506007)(6116002)(790700001)(7696005)(4744005)(8676002)(68736007)(8936002)(2351001)(5660300002)(5024004)(14444005)(6916009)(256004)(26005)(2501003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4728; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: F/OAU8KhD7DB+rZR01Q/StcPD3YmBvmiL5sqK0/v2EgpwA/YPxVUVdkQFOj0Zuw7X5Uyyxb1ZkmKLYl+rqWRnsQKR5L73D74UL2PR/2iPpMiCs6VGZoD4N4gkbiZ+AS5ukwRHmzkRz7baiERyeLC2AmJKLG2zmFbsKU3UWy4yXSgkyin/MvVOPegYFHm7sO7MGDVuFBKy69oCQTxLgzjV4WokIONrm/EOkac5ZsIReU2/3NaRlrbrPWkHx1n6/9jtMD8BRwLX5HX/UJ18V/tcnG7NdUIRVEWpoiHxd7dph3aBast6p4Bcgst9lOZIoAPUme4BwrD1u7QNZIvAMRekoVq2ah/sV/2IGCIZybAcrQdsu0M4/pHyVfliErnJisTlNK16r4/lBtnBK0KU0IaQlIKp7ucO+bYikcyHwrXWb4= Content-Type: multipart/alternative; boundary="_000_DBBPR08MB4539BA4621AC8029AEF4F8C8FA310DBBPR08MB4539eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 763b84da-368d-402d-cda2-08d6d2c59379 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 08:25:34.2576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4728 Archived-At: Subject: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 08:25:39 -0000 --_000_DBBPR08MB4539BA4621AC8029AEF4F8C8FA310DBBPR08MB4539eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In the OAuth conference call today Vittorio mentioned that some folks are w= ondering whether DPOP is essentially a superset of MTLS and whether it make= s sense to only proceed with one solution rather potentially two. I was wondering whether others in the group have a few about this aspect? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB4539BA4621AC8029AEF4F8C8FA310DBBPR08MB4539eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In the OAuth conference call to= day Vittorio mentioned that some folks are wondering whether DPOP is essent= ially a superset of MTLS and whether it makes sense to only proceed with on= e solution rather potentially two.

 

I was wondering whether others = in the group have a few about this aspect?

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB4539BA4621AC8029AEF4F8C8FA310DBBPR08MB4539eurp_-- From nobody Tue May 7 01:30: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 2916F12001B for ; Tue, 7 May 2019 01:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duYFSuy9pWyN for ; Tue, 7 May 2019 01:30:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150070.outbound.protection.outlook.com [40.107.15.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596FA1200A2 for ; Tue, 7 May 2019 01:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=seGlP4JZ94oKIgDVl29KzzPzbxIs3YxrKj467NVKoLQ=; b=Uyq+oamoJmwslbqQWw//jnqCAqPq16TPMj5bhVc5BYX6++NxJJgpTQ5lFOK3pXEmmJ9Ka/t+xRPXDSAFAIVZ6RQ5QggmuPHJ4w+2/UENLnEP9oIAB6qWGPRK1WuLq5q+NeRfCHsaKYNr80McDS7LX2TZaAx+DUwVq/zO3CrVmyI= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4378.eurprd08.prod.outlook.com (20.179.42.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Tue, 7 May 2019 08:30:37 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 08:30:37 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Luca Arnaboldi CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution Thread-Index: AQHU/BpqKPkcnHWaK0OaLJqnsHk3QKZQ9M4AgA5v8mA= Date: Tue, 7 May 2019 08:30:37 +0000 Message-ID: References: <20190428035731.GE60332@kduck.mit.edu> In-Reply-To: <20190428035731.GE60332@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5492282-7415-4f3f-c1d4-08d6d2c6482c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4378; x-ms-traffictypediagnostic: DBBPR08MB4378: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(136003)(78124002)(189003)(199004)(13464003)(40434004)(11346002)(476003)(4326008)(72206003)(3846002)(6116002)(478600001)(8936002)(446003)(186003)(33656002)(8676002)(26005)(6246003)(2171002)(6636002)(25786009)(81166006)(66066001)(486006)(2906002)(5660300002)(14454004)(73956011)(102836004)(6506007)(86362001)(256004)(55016002)(966005)(53546011)(5024004)(14444005)(110136005)(81156014)(64756008)(66446008)(76176011)(66556008)(316002)(76116006)(66476007)(7696005)(53936002)(229853002)(68736007)(71200400001)(71190400001)(6436002)(66946007)(6306002)(74316002)(9686003)(99286004)(52536014)(305945005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4378; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: b81uBH9Fdwwob3np19c9B6qBQw1fIkA1mZ13KNWM/JohSvIxAmM/G37s2YDWUDRxSWUnuN/4piCi4311RsfABAHjop86aTpa2jQJGyxCBYJCdNeZFB23hJIOXPRSB83oSbpr/Bxq4OGxuV6hOoSifKZEZXOwW123lna4rtmWcPTUjsjRRxS8+22sG3afLXV9mEpyKJeXmGgGn14KJpfVK14DrramEp3GJ2rihAygWTh18xaQU/rths6ZkR4XnK528CWYTaM08SHutdFfPNp2LNSrC5z8xlFoUpsUDMBWZV3drrJi70cLlxOfOXSuBa1BPROwBDIJc0J0oUs+c/jpcdJVu50awfqEjsRyKOJbfeTFPgCKPFpMkae/ch2NxFsWFtytSoP7WSPMTi+GZQsXrTtpNhDK/jPLdjzG9Gp8C7I= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5492282-7415-4f3f-c1d4-08d6d2c6482c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 08:30:37.4533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4378 Archived-At: Subject: Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution 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, 07 May 2019 08:30:43 -0000 Hi Ben, currently we don't seem to have an indication that there is an attack possi= ble. It would be interesting to see whether we could still construct one. M= aybe you can dig out other protocols that have tried to accomplish similar = goals (and failed). Ciao Hannes -----Original Message----- From: OAuth On Behalf Of Benjamin Kaduk Sent: Sonntag, 28. April 2019 05:58 To: Luca Arnaboldi Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distrib= ution On Fri, Apr 26, 2019 at 10:51:53AM +0000, Luca Arnaboldi wrote: > * I spoke with Hannes after the IETF meeting in Prague and he expressed t= he need to enhance our formal analysis (as presented at the OAuth Security = Workshop) to verify whether it is necessary to demonstrate possession of th= e private key by the client to the authorization server. > > > * The analysis checked whether it was necessary for a proof of possession= to be performed between the client and AS to ensure security. The result w= as that even without verification by the AS the client would not be able to= access the resource from the RS without possessing the secret key associat= ed to the token (assuming the check is done correctly by the RS). My apologies for not checking the model directly (I'm on a plane), but I'll= note that we have seen similar PoP scenarios in other protocols where a mi= sbehaving client will deliberately try to bind the (valid) key from another= party to a token it authorizes, which can sometimes result in the other pa= rty taking actions different from the ones they intended. So I'd suggest b= eing careful about what scope of attacks are considered. Thanks, Ben _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue May 7 01:33: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 368EE12001B for ; Tue, 7 May 2019 01:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLQU6MWKDbQv for ; Tue, 7 May 2019 01:33:21 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20061.outbound.protection.outlook.com [40.107.2.61]) (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 0157A1200A2 for ; Tue, 7 May 2019 01:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0YvF1zdIM3i1ogH3T5r83PZmX7OrSF7QNB9iK0xcyHo=; b=Wyf8q6QWQ8KPPmyvXvkWb53U8TqbIXIaf06Y1JJZRE6EahWKykQbPq0m0aZRgoNLUxM2uKlDohHYjU/wEK2RHmGiwf9FZk5GyTvQfV3+gKu1OvmNpFn9UI4+7SDXBkBVL6Dy6E1a+/2lZd0zLaPijQuj20JjkXtIsshPwWFExzI= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4870.eurprd08.prod.outlook.com (20.179.46.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 7 May 2019 08:33:17 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 08:33:17 +0000 From: Hannes Tschofenig To: Phil Hunt , oauth , William Denniss , John Bradley Thread-Topic: [OAUTH-WG] MTLS and Native apps Best practices Thread-Index: AQHVARasP2SF+LiiN02odMgRv1+Lj6ZfXDXQ Date: Tue, 7 May 2019 08:33:17 +0000 Message-ID: References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> In-Reply-To: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64a38daa-f0d2-4650-ad58-08d6d2c6a7be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4870; x-ms-traffictypediagnostic: DBBPR08MB4870: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(136003)(165144002)(199004)(189003)(40434004)(66556008)(478600001)(64756008)(229853002)(6436002)(102836004)(26005)(6116002)(486006)(99286004)(33656002)(476003)(7696005)(446003)(66066001)(11346002)(52536014)(316002)(3846002)(76176011)(53546011)(110136005)(790700001)(236005)(68736007)(5660300002)(186003)(14454004)(66446008)(81156014)(9686003)(66574012)(72206003)(25786009)(6506007)(66476007)(54896002)(6306002)(55016002)(8676002)(81166006)(53936002)(8936002)(7736002)(76116006)(53386004)(66946007)(74316002)(6246003)(73956011)(71190400001)(71200400001)(14444005)(2906002)(606006)(256004)(86362001)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4870; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4PVky9YosVb4vZ2Q6DMCJm9GfgcAJjAKsw7fRJH1SJpkfbPp7x5VcxXLGCehlb3LEojeGFy0BNPDSLOaK0CNQdg6ZwN0xG+M5ngkLKsdvG+4OS0YDVCskUV+ZMCAEO06C7zbHnrCKf4GLaHSn1OCIO54pYZhOG1MCTRv9WqdW/jDXa2VBw4NK+wpmtA7/5CWA2FExN5HjsDXrgSAWb2YfKgPDHoTAMp6ZmuofAPL7xrfrEdVLE9S8HFTn6+YRXTs6ASTSLHKTOBBUGrDfTMxDJwIWUS5M5Nwt4ZLP/lbQyrEk7fkevZjjc16kD6Fyfq6wNrwZAkerwtgoZKsfEWBKWDqfwqa/RG7hI75R1szs7CHeSth/dmKFpxfjIvtw5Dd1aMGI+UaJ8RxX9I1mFSRYpUFgDuzad7p8YupU4j4Dww= Content-Type: multipart/alternative; boundary="_000_DBBPR08MB4539A9D5B918B54B062E2471FA310DBBPR08MB4539eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64a38daa-f0d2-4650-ad58-08d6d2c6a7be X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 08:33:17.7851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4870 Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 07 May 2019 08:33:24 -0000 --_000_DBBPR08MB4539A9D5B918B54B062E2471FA310DBBPR08MB4539eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbA0KDQpJIGJlbGlldmUgdGhpcyBpcyBhIHF1ZXN0aW9uIHRoYXQgV2lsbGlhbSBhbmQg Sm9obiBtYXkgYmUgYWJsZSB0byBhbnN3ZXIuDQoNClNob3VsZCBNVExTIGJlIGFkZGVkIHRvIGEg ZnV0dXJlIHZlcnNpb24gb2YgdGhlIE5hdGl2ZSBBcHBzIEJDUD8gSWYgdGhlIGFuc3dlciBpcyDi gJxub+KAnSwgd2h5IG5vdD8NCg0KQ2lhbw0KSGFubmVzDQoNCg0KRnJvbTogT0F1dGggPG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IERvbm5lcnN0 YWcsIDIuIE1haSAyMDE5IDIwOjQxDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogW09BVVRILVdHXSBNVExTIGFuZCBOYXRpdmUgYXBwcyBCZXN0IHByYWN0aWNlcw0KDQpJIHdh cyB3b25kZXJpbmcgaWYgYW55b25lIGhhZCBhbnkgcmVjb21tZW5kZWQgTVRMUyBiZXN0IHByYWN0 aWNlcyBmb3IgbW9iaWxlIGFwcHMgYW5kIG5hdGl2ZSBicm93c2Vycy4NCg0KQ29uc2lkZXJpbmcg U2VjdGlvbiA2IG9mIFJGQzgyNTLigKYNCg0KICAgQWZ0ZXIgY29uc3RydWN0aW5nIHRoZSBhdXRo b3JpemF0aW9uIHJlcXVlc3QgVVJJLCB0aGUgYXBwIHVzZXMNCg0KICAgcGxhdGZvcm0tc3BlY2lm aWMgQVBJcyB0byBvcGVuIHRoZSBVUkkgaW4gYW4gZXh0ZXJuYWwgdXNlci1hZ2VudC4NCg0KICAg VHlwaWNhbGx5LCB0aGUgZXh0ZXJuYWwgdXNlci1hZ2VudCB1c2VkIGlzIHRoZSBkZWZhdWx0IGJy b3dzZXIsIHRoYXQNCg0KICAgaXMsIHRoZSBhcHBsaWNhdGlvbiBjb25maWd1cmVkIGZvciBoYW5k bGluZyAiaHR0cCIgYW5kICJodHRwcyIgc2NoZW1lDQoNCiAgIFVSSXMgb24gdGhlIHN5c3RlbTsg aG93ZXZlciwgZGlmZmVyZW50IGJyb3dzZXIgc2VsZWN0aW9uIGNyaXRlcmlhIGFuZA0KDQogICBv dGhlciBjYXRlZ29yaWVzIG9mIGV4dGVybmFsIHVzZXItYWdlbnRzIE1BWSBiZSB1c2VkLg0KDQpX aGF0IGNob2ljZXMgZG8gZGV2ZWxvcGVycyBoYXZlIHRvIGVuc3VyZSB0aGUgYXV0aG9yaXphdGlv biAoYW5kIHN1YnNlcXVlbnQgdXNlciBhdXRoZW50aWNhdGlvbikgb2NjdXIgb3ZlciBNVExTPyBD YW4gdGhlIGFwcCBwcm92aWRlIGl0cyBvd24ga2V5IGZvciBNVExTIG9yIGNhbiBpdCBhc2sgdGhh dCBhbiBlbWJlZGRlZCBYLjUwOSBjZXJ0IGJlIHVzZWQgKGFzc3VtaW5nIG9uZSBpcyBhdmFpbGFi bGUpPw0KDQpBcmUgdGhlcmUgYW55IHBsYXRmb3JtIGlzc3VlcyBvciBiZXN0IHByYWN0aWNlcz8N Cg0KUGhpbCBIdW50IHwgQ2xvdWQgU2VjdXJpdHkgYW5kIElkZW50aXR5IEFyY2hpdGVjdA0KT3Jh Y2xlIENvcnBvcmF0aW9uLCBPcmFjbGUgQ2xvdWQgSW5mcmFzdHJ1Y3R1cmUNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoN Cg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_DBBPR08MB4539A9D5B918B54B062E2471FA310DBBPR08MB4539eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBQaGlsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYmVsaWV2ZSB0aGlzIGlzIGEgcXVlc3Rpb24gdGhhdCBXaWxsaWFtIGFuZCBKb2huIG1h eSBiZSBhYmxlIHRvIGFuc3dlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgTVRM UyBiZSBhZGRlZCB0byBhIGZ1dHVyZSB2ZXJzaW9uIG9mIHRoZSBOYXRpdmUgQXBwcyBCQ1A/IElm IHRoZSBhbnN3ZXIgaXMg4oCcbm/igJ0sIHdoeSBub3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gT0F1dGggJmx0O29hdXRoLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxi PlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAyLiBNYWkgMjAxOSAyMDo0MTxicj4NCjxiPlRvOjwvYj4g b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgt V0ddIE1UTFMgYW5kIE5hdGl2ZSBhcHBzIEJlc3QgcHJhY3RpY2VzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgd29uZGVyaW5nIGlmIGFueW9uZSBo YWQgYW55IHJlY29tbWVuZGVkIE1UTFMgYmVzdCBwcmFjdGljZXMgZm9yIG1vYmlsZSBhcHBzIGFu ZCBuYXRpdmUgYnJvd3NlcnMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Db25zaWRlcmluZyBTZWN0aW9uIDYgb2YgUkZDODI1MuKApjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj4mbmJzcDsm bmJzcDsgQWZ0ZXIgY29uc3RydWN0aW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgVVJJLCB0 aGUgYXBwIHVzZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcGxhdGZvcm0t c3BlY2lmaWMgQVBJcyB0byBvcGVuIHRoZSBVUkkgaW4gYW4gZXh0ZXJuYWwgdXNlci1hZ2VudC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVHlwaWNhbGx5LCB0aGUgZXh0ZXJu YWwgdXNlci1hZ2VudCB1c2VkIGlzIHRoZSBkZWZhdWx0IGJyb3dzZXIsIHRoYXQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXMsIHRoZSBhcHBsaWNhdGlvbiBjb25maWd1cmVk IGZvciBoYW5kbGluZyAmcXVvdDtodHRwJnF1b3Q7IGFuZCAmcXVvdDtodHRwcyZxdW90OyBzY2hl bWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVVJJcyBvbiB0aGUgc3lzdGVt OyBob3dldmVyLCBkaWZmZXJlbnQgYnJvd3NlciBzZWxlY3Rpb24gY3JpdGVyaWEgYW5kPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG90aGVyIGNhdGVnb3JpZXMgb2YgZXh0ZXJu YWwgdXNlci1hZ2VudHMgTUFZIGJlIHVzZWQuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgY2hvaWNlcyBkbyBkZXZlbG9wZXJzIGhhdmUgdG8gZW5z dXJlIHRoZSBhdXRob3JpemF0aW9uIChhbmQgc3Vic2VxdWVudCB1c2VyIGF1dGhlbnRpY2F0aW9u KSBvY2N1ciBvdmVyIE1UTFM/IENhbiB0aGUgYXBwIHByb3ZpZGUgaXRzIG93biBrZXkgZm9yIE1U TFMgb3IgY2FuIGl0IGFzayB0aGF0IGFuIGVtYmVkZGVkIFguNTA5IGNlcnQgYmUgdXNlZCAoYXNz dW1pbmcgb25lIGlzIGF2YWlsYWJsZSk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB0aGVyZSBhbnkgcGxhdGZvcm0gaXNzdWVzIG9yIGJl c3QgcHJhY3RpY2VzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlBoaWwgSHVudCB8IENsb3VkIFNlY3VyaXR5IGFuZCBJZGVudGl0eSBBcmNoaXRlY3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PcmFjbGUgQ29ycG9yYXRpb24sIE9yYWNsZSBD bG91ZCBJbmZyYXN0cnVjdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkBpbmRl cGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBBPR08MB4539A9D5B918B54B062E2471FA310DBBPR08MB4539eurp_-- From nobody Tue May 7 01:37: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 70DD41200D8 for ; Tue, 7 May 2019 01:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ESAmXgeOjC-E for ; Tue, 7 May 2019 01:37:37 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED201200A2 for ; Tue, 7 May 2019 01:37:36 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id s15so21015805wra.12 for ; Tue, 07 May 2019 01:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5CcD3CcvaHU7dalqNw3bhF3G1TG8JRPGjz1fMESSqLU=; b=XKAXOEnOvD/CD77fGBX20mKQVi5dQ735NW+5Y9c7uXshY6X2Nn04jubIgchMZQgGyM izriRKQwS396bvEFmzyG3fiHenbaJXVM103nK0DK7Jgu0cQojMQY1sHowFZ0q/AarLIw lfWwhLfunaNM1BDsG90WCi/uRTsmNjFAo9v8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5CcD3CcvaHU7dalqNw3bhF3G1TG8JRPGjz1fMESSqLU=; b=Zl8RVyx7Uq8gC9MsYNqsNfWEaZHKqasam8LE84a959sb+OZxAhRuAsLctkk6JIepTk 4qbFIVa19rvrfoPEkPhAR1CYNxPdaXdJalWhcMc4m6dugBaeD0vnvEtOlzOU7NEnVA9h TPr0spSS6c1Pyy7NDkxXJgrhup2+dDd3EpuMGZTWvQJJdDhA/NrMBxFC78M6Bh+Hr+ta 7/QjAdWubEs0r8kdu+h6uDj9aLxcXu1WqEu30QEjU5C+VcITQgCDfl0/rdeU8lu1aCBD X9vnx2XtT4NLXaMgD70BMif68Y6Zl38S6YghRHrINO3s+AJF6VDA9rNFz4XPs0RIJa6p F9aA== X-Gm-Message-State: APjAAAUor7PB0ZqDE3jgxU+dCBQO1SmsIHMlqO6S6HIv4g8h5nQltYMO bnzE2cV/wGmN7dBYq5NcaOzF8Q== X-Google-Smtp-Source: APXvYqzKBO/yr5iLYdTeUeVBFfonBiCGs1yFI2/TbhMUIhsPxqkgHda+oRg886h92vh2l80igT+nWA== X-Received: by 2002:adf:fb4a:: with SMTP id c10mr21175681wrs.309.1557218255051; Tue, 07 May 2019 01:37:35 -0700 (PDT) Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id n2sm25361767wra.89.2019.05.07.01.37.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 01:37:34 -0700 (PDT) From: Neil Madden Message-Id: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_91C12F08-FDAD-45D8-9C62-288707C481CE" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 09:37:29 +0100 In-Reply-To: Cc: Hans Zandbelt , Karl McGuinness , John Bradley , IETF oauth WG To: Vittorio Bertocci References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 08:37:43 -0000 --Apple-Mail=_91C12F08-FDAD-45D8-9C62-288707C481CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wasn=E2=80=99t at IIW so I may be missing some context. There is a potential security issue if the client_id is used as the = =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the = client can register itself with a self-chosen client_id then it may = deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged actions. Is this the context of the discussion? Given that there are a lot of RSes in existence, many of which are = probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I think the onus is on the AS to ensure that no such = ambiguity can arise in the first place by ensuring that the space of = =E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the = space for genuine users or by disallowing the client_credentials grant = altogether. This issue already arises in token introspection though, so maybe ought = to be mentioned in the OAuth security topics draft rather than specific = to the JWT AT draft? =E2=80=94 Neil > On 6 May 2019, at 18:32, Vittorio Bertocci = wrote: >=20 > Hi all, > thanks for your patience during this month long hiatus, and thanks for = the comments. > Last week at IIW I had the opportunity to discuss this with many of = the people on the list. Here's a summary of where the discussion landaed = on the subject of the sub (pun intended). >=20 > - It seems that RFC 7519 has pretty clear language on the use of sub- = I didn't check it back when we started the discussion. I do agree with = the people saying that we shouldn't violate existing specifications, = hence it looks like we do need to have sub also in the case in which we = have app-only tokens carrying claims about the app itself. I understand = this will cause some implementation to break, but unfortunately that's = intrinsic in the process of coming up with a common approach and = standards compliance is probably one of the strongest reasons to = tolerate that. > - That said, I am strongly committed to preserve existing = functionality. One of the main reasons that was brought up for including = sub only for user based ATs was to use it as heuristic for telling those = tokens apart from app-only ones. To that end, Karl MCGuinness suggested = that we include grant_type as a return claim, which the RS could use to = the same effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think? > Note, John Bradley observed that in some cases this might lead to = ambiguous results if an extension grant is used (say an assertion = profile) but that seems like a relatively fringe occurrence. >=20 > On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt = > wrote: > I also meant to say that (of course) the JWT standard doesn't say that = the JWT is supposed to be about the client or about the resource owner, = hence both are valid >=20 > Hans. >=20 > On Thu, Apr 4, 2019 at 10:09 PM Mike Jones = > = wrote: > I get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards. >=20 > =20 >=20 > -- = Mike >=20 > =20 >=20 > From: Hans Zandbelt >=20 > Sent: Thursday, April 4, 2019 12:59 PM > To: Mike Jones > > Cc: George Fletcher >; Vittorio Bertocci = >; IETF oauth WG > > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >=20 > =20 >=20 > the definition of RFC 7519 is actually "petitio principii" and a lot = of deployments put claims about the Resource Owner in the access token = (as a Resource Server implementer I've suffered a lot from this) >=20 > =20 >=20 > Hans. >=20 > =20 >=20 > On Thu, Apr 4, 2019 at 9:48 PM Mike Jones > wrote: >=20 > I agree with George that the subject of a token must be the principal = of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. = Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at = https://tools.ietf.org/html/rfc7519#section-4.1.2 = is: >=20 > The "sub" (subject) claim identifies the principal that is the subject = of the JWT. >=20 > =20 >=20 > If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply = with the definition from RFC 7519. >=20 > =20 >=20 > -- = Mike >=20 > =20 >=20 > From: OAuth > = On Behalf Of George Fletcher > Sent: Thursday, April 4, 2019 8:51 AM > To: Hans Zandbelt > > Cc: Vittorio Bertocci >; IETF oauth WG > > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >=20 > =20 >=20 > The more I think about this the more I land in the "No" camp. >=20 > The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >=20 > Thanks, > George >=20 > On 4/3/19 4:56 PM, Hans Zandbelt wrote: >=20 > I will argue that in a way such deployments are already broken e.g. in = the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. >=20 > =20 >=20 > Hans. >=20 > =20 >=20 > On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: >=20 > I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >=20 > On 3/26/19 12:56 PM, Hans Zandbelt wrote: >=20 > great summary! this will hurt quite a few existing m2m deployments but = I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board >=20 > =20 >=20 > Hans. >=20 > =20 >=20 > On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = > wrote: >=20 > thank you Steinar and everyone else for the comments on this! >=20 > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, = Bertrand recommend using sub only for users. Martin would like to have = the sub for app only flows as well. Hans is neutral. >=20 > That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. >=20 > Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >=20 > =20 >=20 > Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. =20 >=20 > =20 >=20 > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: >=20 > Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! >=20 > We also agree with Dominick concerning definition of the "sub" claim. >=20 > =20 >=20 > Steinar >=20 > =20 >=20 > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = >: >=20 > =46rom an access token consumer (aka API) developer point of view, I = prefer this logic >=20 > =20 >=20 > "If sub is present - client acts on behalf of a user, if not - not." >=20 > =20 >=20 > Anything more complicated has a potential of going wrong. >=20 > =20 >=20 > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com = ) wrote: >=20 > Hi Vittorio, >=20 > =20 >=20 > Yeah, I=E2=80=99m concerning user & client ids collision. >=20 > I haven=E2=80=99t seen such implementations, but user-select username = as sub, or incremental integer as sub & client_id will be easily = collide. >=20 > =20 >=20 > If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >=20 > =20 >=20 > Sent from my iPhone >=20 >=20 > On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >=20 > Hey Nov, Dominick, Hans- >=20 > thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >=20 > The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >=20 > =20 >=20 > The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server. >=20 > =20 >=20 > Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >=20 > Nov- playing this back: is the concern that a user and a client might = have the same identifier within an IDP? When using collision resistant = IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production? >=20 > =20 >=20 > Thanks >=20 > V.=20 >=20 > =20 >=20 > =20 >=20 > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = > wrote: >=20 > I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >=20 > =20 >=20 > Hans. >=20 > =20 >=20 > On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = > wrote: >=20 > Yes I know - and I think in hindsight it was a mistake to use the same = claim type for multiple semantics. >=20 > =20 >=20 > All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >=20 > =20 >=20 > In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >=20 > =20 >=20 > Dominick >=20 > On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu ) wrote: >=20 > Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. >=20 > The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2 = : >=20 > =20 >=20 > "The "sub" (subject) claim identifies the principal that is the >=20 > subject of the JWT. The claims in a JWT are normally statements >=20 > about the subject. The subject value MUST either be scoped to be >=20 > locally unique in the context of the issuer or be globally unique. >=20 > The processing of this claim is generally application specific" >=20 > =20 >=20 > which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users >=20 > =20 >=20 > Hans. >=20 > =20 >=20 > On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: >=20 > IMHO the sub claim should always refer to the user - and nothing else. >=20 > =20 >=20 > OIDC says: >=20 > =20 >=20 > "Subject - Identifier for the End-User at the Issuer." >=20 > =20 >=20 > client_id should be used to identify clients. >=20 > =20 >=20 > cheers >=20 > Dominick >=20 > =20 >=20 > On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: >=20 > Hi Vittorio, >=20 > =20 >=20 > Thanks for the good starting point of standardizing JWT-ized AT. >=20 > =20 >=20 > One feedback. >=20 > The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >=20 > It requires those 2 types of identifiers to be unique each other in = the IdP context. >=20 > =20 >=20 > I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. >=20 > =20 >=20 > thanks >=20 > =20 >=20 > nov >=20 > =20 >=20 > On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: >=20 > =20 >=20 > Dear all, >=20 > I just submitted a draft describing a JWT profile for OAuth 2.0 access = tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= >=20 > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting = remotely). I look forward for your comments! >=20 > =20 >=20 > Here's just a bit of backstory, in case you are interested in how this = doc came to be. The trajectory it followed is somewhat unusual. >=20 > Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. > I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities = and differences.=20 > I put together a presentation summarizing my findings and suggesting a = rough interoperable profile = (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci= _-_a_jwt_profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! > The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. > On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. > I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 >=20 > V. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 >=20 > -- >=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu >=20 > =20 >=20 > -- >=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 >=20 > -- >=20 > Vennlig hilsen >=20 > =20 >=20 > Steinar Noem >=20 > Partner Udelt AS >=20 > Systemutvikler >=20 > =20 >=20 > | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 | www.udelt.no = |=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 >=20 > -- >=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 >=20 >=20 > =20 >=20 > -- >=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > =20 >=20 >=20 >=20 > =20 >=20 > -- >=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu >=20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_91C12F08-FDAD-45D8-9C62-288707C481CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wasn=E2=80=99t at IIW so I may be missing some context.
There is a potential security issue if = the client_id is used as the =E2=80=9Csub=E2=80=9D for an AT obtained = via client_credentials. If the client can register itself with a = self-chosen client_id then it may deliberately chose a client_id that = matches the user name of a privileged user. An RS that just blindly = looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let the = client perform privileged actions.

Is this the context of the = discussion?

Given that there are a lot of RSes in existence, many of = which are probably just looking at the =E2=80=9Csub=E2=80=9D claim to = identify the resource owner, I think the onus is on the AS to ensure = that no such ambiguity can arise in the first place by ensuring that the = space of =E2=80=9Csub=E2=80=9D values for client credentials is disjoint = with the space for genuine users or by disallowing the = client_credentials grant altogether.

This issue already arises in token = introspection though, so maybe ought to be mentioned in the OAuth = security topics draft rather than specific to the JWT AT = draft?

=E2=80=94= Neil

On 6 May 2019, at 18:32, Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this = month long hiatus, and thanks for the comments.
Last = week at IIW I had the opportunity to discuss this with many of the = people on the list. Here's a summary of where the discussion landaed on = the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty = clear language on the use of sub- I didn't check it back when we started = the discussion. I do agree with the people saying that we shouldn't = violate existing specifications, hence it looks like we do need to have = sub also in the case in which we have app-only tokens carrying claims = about the app itself. I understand this will cause some implementation = to break, but unfortunately that's intrinsic in the process of coming up = with a common approach and standards compliance is probably one of the = strongest reasons to tolerate that.
- That said, I = am strongly committed to preserve existing functionality. One of the = main reasons that was brought up for including sub only for user based = ATs was to use it as heuristic for telling those tokens apart from = app-only ones. To that end, Karl = MCGuinness suggested that we include grant_type as a return claim, = which the RS could use to the same effect. I find the proposal very = clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some = cases this might lead to ambiguous results if an extension grant is used = (say an assertion profile) but that seems like a relatively fringe = occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans = Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I also = meant to say that (of course) the JWT standard doesn't say that the JWT = is supposed to be about the client or about the resource owner, hence = both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike = Jones <Michael.Jones@microsoft.com> wrote:

I= get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards.

 

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

 

From: = Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF = oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is = actually "petitio principii" and a lot of deployments put claims about = the Resource Owner in the access token (as a Resource Server implementer = I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM = Mike Jones <Michael.Jones@microsoft.com> = wrote:

I agree with George that the subject of a token must be the = principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D = claim is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:

The = "sub" (subject) claim identifies the principal that is the subject of = the JWT.

 

If an = access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with the = definition from RFC 7519.

 

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

The more I think = about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything = and makes it easy for people to detect this case in those use cases = where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt = wrote:

I will argue that in a way such = deployments are already broken e.g. in the typical use case of = onboarding client accounts in the same directory/OU/namespace as user = accounts and we don't need to cater for that.

=

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM = George Fletcher <gffletch@aol.com> wrote:

I agree that this = will break a lot of existing flows... especially those using any form of = the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans = Zandbelt wrote:

great summary! this will hurt = quite a few existing m2m deployments but I do like the rigidness of it = all: it is very explicit, cannot misinterpreted and thus prevents = failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone = else for the comments on this!

To summarize the situation so = far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub = only for users. Martin would like to have the sub for app only flows as = well. Hans is neutral.

That does sound like the sub as = user has more consensus, tho before changing it I'd wait for the people = currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to = be able to apply the logic "if there's a sub, it's a user flow", we have = to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

 

Dave, the suggestion of having = explicit typing for app only vs user only is interesting! For the = purpose of putting together an interoperable profile, tho, I would = suggest we table it for v1 in the interest of getting to something easy to adopt (hence = with small delta vs existing implementations) faster.    =  

 

On Tue, Mar 26, 2019 at 1:40 AM = Steinar Noem <steinar@udelt.no> wrote:

Hi Vittorio, we  (the = national federation-gateway for the health services in norway - = "HelseID")  think his is a really valuable initiative!

We also agree with Dominick = concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 = skrev Dominick Baier <dbaier@leastprivilege.com>:

=46ro= m an access token consumer (aka API) developer point of view, I prefer = this logic

 

"If = sub is present - client acts on behalf of a user, if not - = not."

 

Anything more complicated has a potential of going = wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Yeah, I=E2=80=99m concerning user = & client ids collision.

I haven=E2=80=99t seen such = implementations, but user-select username as sub, or incremental integer = as sub & client_id will be easily collide.

 

If you can enforce collision = resistant IDs between user & client instances, it=E2=80=99ll works = fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was = an area I was expecting to cause more discussion, and I am glad we are = having this opportunity to clarify.

The current language in the draft = traces the etymology of sub to OpenID Connect core, hence Dominick = observation is on point. However in the description I express something = in line with 7519, which was in fact my intent.

 

The idea was to provide an = identifier of the calling subject that is guaranteed to be present in = all cases- this would allow an SDK developer to use the same code for = things like lookups and membership checks regardless of the nature of the caller = (user in a delegated case, app in app-only grants). The information to = discriminate between user and app callers is always available in the = token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence = there's no loss in expressive power, should that difference be relevant = for the resource server.

 

Dominick, Hans- I probably missed = the security issue you guys are thinking of in this case. Of course, if = this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a = scenario/use case to clarify the risk?

Nov- playing this back: is the = concern that a user and a client might have the same identifier within = an IDP? When using collision resistant IDs, as it is usually the case, = that seems to be a remote possibility- did you stumble in such scenario in = production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM = Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

I believe there are plenty of = OAuth 2.0 only use cases out there... but nevertheless I agree with the = potential confusion and thus security problems arising from that (though = one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes = I know - and I think in hindsight it was a mistake to use the same claim = type for multiple semantics.

 

All = the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things = more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They = always combine it.

 

In = reality this leads to potential security problems - this spec has the = potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: = OIDC does not apply here since it is not OAuth and an access token is = not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

 

"The "sub" (subject) claim = identifies the principal that is the

   subject of the = JWT.  The claims in a JWT are normally statements

   about the = subject.  The subject value MUST either be scoped to be

   locally unique in = the context of the issuer or be globally unique.

   The processing of = this claim is generally application specific"

 

which kind of spells "client" in = case of the client credentials grant but I also do worry about Resource = Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO = the sub claim should always refer to the user - and nothing = else.

 

OIDC = says:

 

"Subject= - Identifier for the End-User at the Issuer."

 

client_id should be used to = identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Thanks for the good starting = point of standardizing JWT-ized AT.

 

One feedback.

The =E2=80=9Csub=E2=80=9D claim = can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of = identifiers to be unique each other in the IdP context.

 

I prefer omitting =E2=80=9Csub=E2=80= =9D claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

 

Dear all,

I just submitted a draft = describing a JWT profile for OAuth 2.0 access tokens. You can find it = in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.

I have a slot to discuss this = tomorrow at IETF 104 (I'll be presenting remotely). I look forward for = your comments!

 

Here's just a bit of backstory, = in case you are interested in how this doc came to be. The trajectory it = followed is somewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough = to prevent developers from reusing code and skills when moving from = product to product.
  • I asked several individuals from key products and services to share with = me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), = Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities = and differences. 
  • I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on = it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't = get credited in the draft, my apologies: please send me a note and I'll = make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process.

I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 

V.

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

 

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

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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

_______________________________________________
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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 

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

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu



--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_91C12F08-FDAD-45D8-9C62-288707C481CE-- From nobody Tue May 7 01:48:48 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 93D84120043 for ; Tue, 7 May 2019 01:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvZMkiq0IhKT for ; Tue, 7 May 2019 01:48:42 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 D9F3412001B for ; Tue, 7 May 2019 01:48:41 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id h126so52600lfh.4 for ; Tue, 07 May 2019 01:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RQtqgaKub05fsyqnq/GIzUxmxA4cxBsSDZ9WlJhe/5M=; b=pseN69YtU7hsiJX8IsL+F2rBZQmNFs/a+JuZqyquaMV9ha8ckLuhkrNQL8TytO+g0n suu4AvGGFrg9rIQTrfuLeLl2Duaf1Oe4BKpQwFhlBTPKfGZn7goSEa+rlmJcNrqHx2Cj /9c0jkoAr+fOan6ysyMuUm5Gfrk6K08tMVIivMA3J633vXZefzdQQ076eiBWrF+0VGuQ BAzPU5kAEo3x/uMLElyb4B6ePubIKrgsmqZGUhtRoTuofl8kC18GxVNfNg3cN+jQ47Ca q2KgrV8uvInVf6WqdU2QfxS5w793sOZp2hhbT3BFe5MGZzgJY7RWCZIuNNVDy7kp/wkv KUHg== 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=RQtqgaKub05fsyqnq/GIzUxmxA4cxBsSDZ9WlJhe/5M=; b=GaDGr6NWawm/Cnezj00yFhEF/S69NsQeNSD1SZeQss+s5t0QPsqslvruFAS+XQvuEe s2dON4W7QKEj+rs50yNbxTkcvCUhKx8nSwJEzhFPslepVwvipkDRM9Tw5+tYFmEJvA3Q 0ScFapeYyZ++EXRpay9IH9tBmu3jhpSB3DFIgQcGKIjj2V+uUaWfo7opFJ4J3afaCEXN rzSKNm/wlNGZVfp3/PPtnaNJHRB7qmB8pQUEyGQisWL8QKyskQnrK/5xc9LWKS2Vp1XH cMQOsZgPSs8UJB0LOlNkcuPrLCyodhvvOaO1KRsew0PwQfm/TZFg2rW8VsI2zx5moZSV a9cQ== X-Gm-Message-State: APjAAAU304M5ZC6kMytOQxo5+hwFcIapGLUchipzgbU9237iWKYJARaU 8Hm7k01qrbFvN/thbSBOnQ9rO7CdTkQRxCdWvGc6AA== X-Google-Smtp-Source: APXvYqy0EwMF3LgmOfxaIiCnfFT5oqEE1mE72bJFlkPzGdsRfmB362cwecXMJBrEw/wWgCDQxwNHPZm30Ito6tUoyK4= X-Received: by 2002:ac2:53b2:: with SMTP id j18mr16343418lfh.78.1557218919511; Tue, 07 May 2019 01:48:39 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> In-Reply-To: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> From: Vittorio Bertocci Date: Tue, 7 May 2019 01:48:31 -0700 Message-ID: To: Neil Madden Cc: Hans Zandbelt , Karl McGuinness , John Bradley , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000890ec30588484841" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 08:48:47 -0000 --000000000000890ec30588484841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Neil, one more reason to avoid that. TL;DR, The context is the discussion we had pre-IIW about whether sub should be included always or only for tokens issued to ROs. Some exiting implementations rely on that heuristic. Turns out that 7519 has language suggesting sub should be there for both tokens issued for the RO and for apps (via client creds, etc). We don't want to contradict 7519 but we also want to preserve the ability for a RS to tell whether an AT was issued via RO auth or app auth, hence the discussion. Suggestions ranged from adding a grant_type claim (Vlad made a convincing argument against it), to relying to the client_id=3D=3Dsu= b heuristic (which i pushed back on) to the introduction of a new claim (name TBD given that sub_type is taken already) that can explicitly declare whether the token has been issued authenticating th RO or via app credentials. On Tue, May 7, 2019 at 1:37 AM Neil Madden wrote: > I wasn=E2=80=99t at IIW so I may be missing some context. > > There is a potential security issue if the client_id is used as the =E2= =80=9Csub=E2=80=9D > for an AT obtained via client_credentials. If the client can register > itself with a self-chosen client_id then it may deliberately chose a > client_id that matches the user name of a privileged user. An RS that jus= t > blindly looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let= the client > perform privileged actions. > > Is this the context of the discussion? > > Given that there are a lot of RSes in existence, many of which are > probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I > think the onus is on the AS to ensure that no such ambiguity can arise in > the first place by ensuring that the space of =E2=80=9Csub=E2=80=9D value= s for client > credentials is disjoint with the space for genuine users or by disallowin= g > the client_credentials grant altogether. > > This issue already arises in token introspection though, so maybe ought t= o > be mentioned in the OAuth security topics draft rather than specific to t= he > JWT AT draft? > > =E2=80=94 Neil > > On 6 May 2019, at 18:32, Vittorio Bertocci < > Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: > > Hi all, > thanks for your patience during this month long hiatus, and thanks for th= e > comments. > Last week at IIW I had the opportunity to discuss this with many of the > people on the list. Here's a summary of where the discussion landaed on t= he > subject of the sub (pun intended). > > - It seems that RFC 7519 has pretty clear language on the use of sub- I > didn't check it back when we started the discussion. I do agree with the > people saying that we shouldn't violate existing specifications, hence it > looks like we do need to have sub also in the case in which we have > app-only tokens carrying claims about the app itself. I understand this > will cause some implementation to break, but unfortunately that's intrins= ic > in the process of coming up with a common approach and standards complian= ce > is probably one of the strongest reasons to tolerate that. > - That said, I am strongly committed to preserve existing functionality. > One of the main reasons that was brought up for including sub only for us= er > based ATs was to use it as heuristic for telling those tokens apart from > app-only ones. To that end, *Karl MCGuinness suggested that we include > grant_type as a return claim, which the RS could use to the same effect*. > I find the proposal very clever, and the people at IIW thought so as well= . > What you think? > Note, *John Bradley* observed that in some cases this might lead to > ambiguous results if an extension grant is used (say an assertion profile= ) > but that seems like a relatively fringe occurrence. > > On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt > wrote: > >> I also meant to say that (of course) the JWT standard doesn't say that >> the JWT is supposed to be about the client or about the resource owner, >> hence both are valid >> >> Hans. >> >> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones >> wrote: >> >>> I get that existing practice is likely to be all over the map, but if >>> we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reaso= nable to require >>> that the claims usage comply with the JWT standards. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Hans Zandbelt >>> *Sent:* Thursday, April 4, 2019 12:59 PM >>> *To:* Mike Jones >>> *Cc:* George Fletcher >> <40aol.com@dmarc...ietf.org>>; Vittorio Bertocci >> 40auth0.com@dmarc.ietf.org>; IETF oauth WG >>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>> >>> >>> >>> the definition of RFC 7519 is actually "petitio principii" and a lot of >>> deployments put claims about the Resource Owner in the access token (as= a >>> Resource Server implementer I've suffered a lot from this) >>> >>> >>> >>> Hans. >>> >>> >>> >>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones >>> wrote: >>> >>> I agree with George that the subject of a token must be the principal o= f >>> that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. Ind= eed, the first >>> sentence of the =E2=80=9Csub=E2=80=9D definition at >>> https://tools.ietf.org/html/rfc7519#section-4.1.2 is: >>> >>> The "sub" (subject) claim identifies the principal that is the subject >>> of the JWT. >>> >>> >>> >>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply wi= th the definition >>> from RFC 7519. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth *On Behalf Of *George Fletcher >>> *Sent:* Thursday, April 4, 2019 8:51 AM >>> *To:* Hans Zandbelt >>> *Cc:* Vittorio Bertocci ; IETF >>> oauth WG >>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>> >>> >>> >>> The more I think about this the more I land in the "No" camp. >>> >>> The subject of a token should be the principal of that token. It >>> shouldn't matter whether that is a machine, a user, or a device. Trying= to >>> separate out "humans" as a special class will just make things more >>> complicated. If we need a claim to identify the subject is a "human" th= en >>> why not just add that. This doesn't break anything and makes it easy fo= r >>> people to detect this case in those use cases where it's required. >>> >>> Thanks, >>> George >>> >>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>> >>> I will argue that in a way such deployments are already broken e.g. in >>> the typical use case of onboarding client accounts in the same >>> directory/OU/namespace as user accounts and we don't need to cater for >>> that. >>> >>> >>> >>> Hans. >>> >>> >>> >>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher >>> wrote: >>> >>> I agree that this will break a lot of existing flows... especially thos= e >>> using any form of the client_credentials flow. In that sense I'm not >>> completely on board yet :) >>> >>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>> >>> great summary! this will hurt quite a few existing m2m deployments but = I >>> do like the rigidness of it all: it is very explicit, cannot misinterpr= eted >>> and thus prevents failure (which is really what Dominick is after); I'm= on >>> board >>> >>> >>> >>> Hans. >>> >>> >>> >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci >> 40auth0.com@dmarc.ietf.org> wrote: >>> >>> thank you Steinar and everyone else for the comments on this! >>> >>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >>> Bertrand recommend using sub only for users. Martin would like to have = the >>> sub for app only flows as well. Hans is neutral. >>> >>> That does sound like the sub as user has more consensus, tho before >>> changing it I'd wait for the people currently at IETF104 to have more t= ime >>> to comment as well. >>> >>> Clarification. If the goal is to be able to apply the logic "if there's >>> a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the= use >>> of sub when that's not the case. Are all OK with it? >>> >>> >>> >>> Dave, the suggestion of having explicit typing for app only vs user onl= y >>> is interesting! For the purpose of putting together an interoperable >>> profile, tho, I would suggest we table it for v1 in the interest of get= ting >>> to something easy to adopt (hence with small delta vs existing >>> implementations) faster. >>> >>> >>> >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: >>> >>> Hi Vittorio, we (the national federation-gateway for the health >>> services in norway - "HelseID") think his is a really valuable initiat= ive! >>> >>> We also agree with Dominick concerning definition of the "sub" claim. >>> >>> >>> >>> Steinar >>> >>> >>> >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >>> dbaier@leastprivilege.com>: >>> >>> From an access token consumer (aka API) developer point of view, I >>> prefer this logic >>> >>> >>> >>> "If sub is present - client acts on behalf of a user, if not - not." >>> >>> >>> >>> Anything more complicated has a potential of going wrong. >>> >>> >>> >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> >>> >>> Yeah, I=E2=80=99m concerning user & client ids collision. >>> >>> I haven=E2=80=99t seen such implementations, but user-select username a= s sub, or >>> incremental integer as sub & client_id will be easily collide. >>> >>> >>> >>> If you can enforce collision resistant IDs between user & client >>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >>> >>> Hey Nov, Dominick, Hans- >>> >>> thanks for the comments. That was an area I was expecting to cause more >>> discussion, and I am glad we are having this opportunity to clarify. >>> >>> The current language in the draft traces the etymology of sub to OpenID >>> Connect core, hence Dominick observation is on point. However in the >>> description I express something in line with 7519, which was in fact my >>> intent. >>> >>> >>> >>> The idea was to provide an identifier of the calling subject that is >>> guaranteed to be present in all cases- this would allow an SDK develope= r to >>> use the same code for things like lookups and membership checks regardl= ess >>> of the nature of the caller (user in a delegated case, app in app-only >>> grants). The information to discriminate between user and app callers i= s >>> always available in the token (say, the caller is a user if sub!=3Dclie= nt_id, >>> where client_id is always guaranteed to be present as well) hence there= 's >>> no loss in expressive power, should that difference be relevant for the >>> resource server. >>> >>> >>> >>> Dominick, Hans- I probably missed the security issue you guys are >>> thinking of in this case. Of course, if this would introduce a risk I >>> completely agree it should be changed- I'd just like to understand bett= er >>> the problem. Could you expand it in a scenario/use case to clarify the = risk? >>> >>> Nov- playing this back: is the concern that a user and a client might >>> have the same identifier within an IDP? When using collision resistant = IDs, >>> as it is usually the case, that seems to be a remote possibility- did y= ou >>> stumble in such scenario in production? >>> >>> >>> >>> Thanks >>> >>> V. >>> >>> >>> >>> >>> >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>> hans.zandbelt@zmartzone.eu> wrote: >>> >>> I believe there are plenty of OAuth 2.0 only use cases out there... but >>> nevertheless I agree with the potential confusion and thus security >>> problems arising from that (though one may argue the semantics are the >>> same). >>> >>> >>> >>> Hans. >>> >>> >>> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>> Yes I know - and I think in hindsight it was a mistake to use the same >>> claim type for multiple semantics. >>> >>> >>> >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making t= hings more >>> complicated than they need to be - in my experience almost no-one (that= I >>> know) does OIDC only - nor OAuth only. They always combine it. >>> >>> >>> >>> In reality this leads to potential security problems - this spec has th= e >>> potential to rectify the situation. >>> >>> >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.e= u) >>> wrote: >>> >>> Without agreeing or disagreeing: OIDC does not apply here since it is >>> not OAuth and an access token is not an id_token. >>> >>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >>> >>> >>> >>> "The "sub" (subject) claim identifies the principal that is the >>> >>> subject of the JWT. The claims in a JWT are normally statements >>> >>> about the subject. The subject value MUST either be scoped to be >>> >>> locally unique in the context of the issuer or be globally unique. >>> >>> The processing of this claim is generally application specific" >>> >>> >>> >>> which kind of spells "client" in case of the client credentials grant >>> but I also do worry about Resource Servers thinking/acting only in term= s of >>> users >>> >>> >>> >>> Hans. >>> >>> >>> >>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>> IMHO the sub claim should always refer to the user - and nothing else. >>> >>> >>> >>> OIDC says: >>> >>> >>> >>> "Subject - Identifier for the End-User at the Issuer." >>> >>> >>> >>> client_id should be used to identify clients. >>> >>> >>> >>> cheers >>> >>> Dominick >>> >>> >>> >>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> >>> >>> Thanks for the good starting point of standardizing JWT-ized AT. >>> >>> >>> >>> One feedback. >>> >>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-= user and client, >>> in this spec. >>> >>> It requires those 2 types of identifiers to be unique each other in the >>> IdP context. >>> >>> >>> >>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so t= hat no such >>> constraint needed. >>> >>> >>> >>> thanks >>> >>> >>> >>> nov >>> >>> >>> >>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>> >>> >>> >>> Dear all, >>> >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= . >>> >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT= for >>> their access token. The intent and scenarios addressed by those solu= tions >>> are mostly the same across vendors, but the syntax and interpretatio= ns in >>> the implementations are different enough to prevent developers from = reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YO= U >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-= _a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback= and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvin= ov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a not= e and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Ri= faat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the proce= ss. >>> This is an amazing community. >>> >>> V. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >>> >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >>> >>> >>> >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000890ec30588484841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Neil, one more reason to avoid that.
TL;DR,=C2= =A0
The context is the discussion we had pre-IIW about whether su= b should be included always or only for tokens issued to ROs. Some exiting = implementations rely on that heuristic.
Turns out that 7519 has l= anguage suggesting sub should be there for both tokens issued for the RO an= d for apps (via client creds, etc).
We don't want to contradict 7519= but we also want to preserve the ability for a RS to tell whether an AT wa= s issued via RO auth or app auth, hence the discussion. Suggestions ranged = from adding a grant_type claim (Vlad made a convincing argument against it)= , to relying to the client_id=3D=3Dsub heuristic (which i pushed back on) t= o the introduction of a new claim (name TBD given that sub_type is taken al= ready) that can explicitly declare whether the token has been issued authen= ticating th RO or via app credentials.

On Tue, May 7, 2019 at 1:37 AM = Neil Madden <neil.madden@fo= rgerock.com> wrote:
I wasn=E2=80=99t at II= W so I may be missing some context.

There is a potential= security issue if the client_id is used as the =E2=80=9Csub=E2=80=9D for a= n AT obtained via client_credentials. If the client can register itself wit= h a self-chosen client_id then it may deliberately chose a client_id that m= atches the user name of a privileged user. An RS that just blindly looks at= the =E2=80=9Csub=E2=80=9D claim may then erroneously let the client perfor= m privileged actions.

Is this the context of the d= iscussion?

Given that there are a lot of RSes in e= xistence, many of which are probably just looking at the =E2=80=9Csub=E2=80= =9D claim to identify the resource owner, I think the onus is on the AS to = ensure that no such ambiguity can arise in the first place by ensuring that= the space of =E2=80=9Csub=E2=80=9D values for client credentials is disjoi= nt with the space for genuine users or by disallowing the client_credential= s grant altogether.

This issue already arises in t= oken introspection though, so maybe ought to be mentioned in the OAuth secu= rity topics draft rather than specific to the JWT AT draft?

<= /div>
=E2=80=94 Neil

On 6 Ma= y 2019, at 18:32, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.o= rg> wrote:

Hi all,
thanks for your patience = during this month long hiatus, and thanks for the comments.
Last = week at IIW I had the opportunity to discuss this with many of the people o= n the list. Here's a summary of where the discussion landaed on the sub= ject of the sub (pun intended).

- It seems that RF= C 7519 has pretty clear language on the use of sub- I didn't check it b= ack when we started the discussion. I do agree with the people saying that = we shouldn't violate existing specifications, hence it looks like we do= need to have sub also in the case in which we have app-only tokens carryin= g claims about the app itself. I understand this will cause some implementa= tion to break, but unfortunately that's intrinsic in the process of com= ing up with a common approach and standards compliance is probably one of t= he strongest reasons to tolerate that.
- That said, I am strongly= committed to preserve existing functionality. One of the main reasons that= was brought up for including sub only for user based ATs was to use it as = heuristic for telling those tokens apart from app-only ones. To that end, <= i>Karl MCGuinness suggested that we include grant_type as a return c= laim, which the RS could use to the same effect. I find the proposal ve= ry clever, and the people at IIW thought so as well. What you think?
Not= e, John Bradley observed that in some cases this might lead to ambig= uous results if an extension grant is used (say an assertion profile) but t= hat seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at = 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I also meant to s= ay that (of course) the JWT standard doesn't say that the JWT is suppos= ed to be about the client or about the resource owner, hence both are valid=

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones &= lt;Michael= .Jones@microsoft.com> wrote:

I get that existing practice is likely to be all over th= e map, but if we=E2=80=99re to create a JWT access token standard, it=E2=80= =99s reasonable to require that the claims usage comply with the JWT standa= rds.

=C2=A0

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

=C2=A0

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu= >
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio B= ertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

the definition of RFC 7519 is actually "pe= titio principii" and a lot of deployments put claims about the Resourc= e Owner in the access token (as a Resource Server implementer I've suff= ered a lot from this)

=C2=A0

Hans.

=C2=A0

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com> wrote:

I agree with= George that the subject of a token must be the principal of that token.=C2= =A0 That what the JWT =E2=80=9Csub=E2=80=9D claim is for.=C2=A0 Indeed, the= first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:<= /u>

The "sub" (= subject) claim identifies the principal that is the subject of the JWT.

=C2=A0

If an access token uses =E2=80=9Csub=E2=80=9D, its usage = must comply with the definition from RFC 7519.

=C2=A0<= u>

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

=C2=A0

= From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF o= auth WG <oauth@ietf.= org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

The more I think about this the more I land in the "No" camp.=

The subject of a token should be the principal of that token. It shouldn= 9;t matter whether that is a machine, a user, or a device. Trying to separa= te out "humans" as a special class will just make things more com= plicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break = anything and makes it easy for people to detect this case in those use case= s where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:<= u>

I will argue that in a way such deployments are= already broken e.g. in the typical use case of onboarding client accounts = in the same directory/OU/namespace as user accounts and we don't need to cater for that.

=C2=A0

Hans.

=C2=A0

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher= <gffletch@aol.com= > wrote:

I agree that this will break a lot of existi= ng flows... especially those using any form of the client_credentials flow.= In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few exist= ing m2m deployments but I do like the rigidness of it all: it is very expli= cit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

=C2=A0

Hans.

=C2=A0

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertoc= ci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone else for the com= ments on this!

To summarize the situation so far: Dominick, St= einar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin= would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more c= onsensus, tho before changing it I'd wait for the people currently at I= ETF104 to have more time to comment as well.

Clarification. If the goal is to be able to app= ly the logic "if there's a sub, it's a user flow", we hav= e to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

=C2=A0

Dave, the suggestion of having explicit typing = for app only vs user only is interesting! For the purpose of putting togeth= er an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence wit= h small delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0

=C2=A0

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem &l= t;steinar@udelt.no> wrote:

Hi Vittorio, we=C2=A0 (the national federation-= gateway for the health services in norway - "HelseID")=C2=A0 thin= k his is a really valuable initiative!

We also agree with Dominick concerning definiti= on of the "sub" claim.

=C2=A0

<mvh>Steinar</mvh>

=C2=A0

From an access token consumer (aka API) developer point of= view, I prefer this logic

=C2=A0

"If sub is present - client acts on behalf of a user,= if not - not."

=C2=A0

Anything more complicated has a potential of going wrong.<= /span>

=C2=A0<= /u>

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Yeah, I=E2=80=99m concerning user & client = ids collision.

I haven=E2=80=99t seen such implementations, bu= t user-select username as sub, or incremental integer as sub & client_i= d will be easily collide.

=C2=A0

If you can enforce collision resistant IDs betw= een user & client instances, it=E2=80=99ll works fine. I feel its overk= ill though.

=C2=A0

Sent from my iPhone=


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was= expecting to cause more discussion, and I am glad we are having this oppor= tunity to clarify.

The current language in the draft traces the et= ymology of sub to OpenID Connect core, hence Dominick observation is on poi= nt. However in the description I express something in line with 7519, which was in fact my intent.

=C2=A0

The idea was to provide an identifier of the ca= lling subject that is guaranteed to be present in all cases- this would all= ow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user= in a delegated case, app in app-only grants). The information to discrimin= ate between user and app callers is always available in the token (say, the= caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there= 9;s no loss in expressive power, should that difference be relevant for the= resource server.

=C2=A0

Dominick, Hans- I probably missed the security = issue you guys are thinking of in this case. Of course, if this would intro= duce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scena= rio/use case to clarify the risk?

Nov- playing this back: is the concern that a u= ser and a client might have the same identifier within an IDP? When using c= ollision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in prod= uction?

=C2=A0

Thanks

V.=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt &= lt;hans.zan= dbelt@zmartzone.eu> wrote:

I believe there are plenty of OAuth 2.0 only us= e cases out there... but nevertheless I agree with the potential confusion = and thus security problems arising from that (though one may argue the semantics are the same).

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = <dbaier@l= eastprivilege.com> wrote:

Yes I know - and I think in hindsight it was a mistake to = use the same claim type for multiple semantics.

=C2=A0

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments= are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always c= ombine it.

=C2=A0

In reality this leads to potential security problems - thi= s spec has the potential to rectify the situation.

=C2=A0

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not = apply here since it is not OAuth and an access token is not an id_token.=

=C2=A0

"The "sub" (subject) claim ident= ifies the principal that is the

=C2=A0 =C2=A0subject of the JWT.=C2=A0 The clai= ms in a JWT are normally statements

=C2=A0 =C2=A0about the subject.=C2=A0 The subje= ct value MUST either be scoped to be

=C2=A0 =C2=A0locally unique in the context of t= he issuer or be globally unique.

=C2=A0 =C2=A0The processing of this claim is ge= nerally application specific"

=C2=A0

which kind of spells "client" in case= of the client credentials grant but I also do worry about Resource Servers= thinking/acting only in terms of users

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = <dbaier@l= eastprivilege.com> wrote:

IMHO the sub claim should always refer to the user - and n= othing else.

=C2=A0

OIDC says:

=C2=A0

"Subject - Identifier for the End-User at the Issuer."

=C2=A0

client_id should be used to identify clients.

=C2=A0

cheers

Dominick

=C2=A0

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Thanks for the good starting point of standardi= zing JWT-ized AT.

=C2=A0

One feedback.

The =E2=80=9Csub=E2=80=9D claim can include 2 t= ypes of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be = unique each other in the IdP context.

=C2=A0

I prefer omitting =E2=80=9Csub=E2=80=9D claim i= n 2-legged context, so that no such constraint needed.

=C2=A0

thanks

=C2=A0

nov

=C2=A0

On Mar 25, 2019, at 8:29, Vittorio Bertocci <= ;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

=C2=A0

Dear all,

I just submitted a draft describing a JWT profi= le for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-= jwt/.

I have a slot to discuss this tomorrow at IETF = 104 (I'll be presenting remotely). I look forward for your comments!=

=C2=A0

Here's just a bit of backstory, in case you= are interested in how this doc came to be. The trajectory it followed is s= omewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the years= I have come across multiple proprietary solution using JWT for their acces= s token. The intent and scenarios addressed by those solutions are mostly t= he same across vendors, but the syntax and interpretations in the implementations are different enough to = prevent developers from reusing code and skills when moving from product to= product.
  • I asked several individuals from key products and services to share with me= concrete examples of their JWT access tokens (THANK YOU Dominick Baier (Id= entityServer),=C2=A0Brian Campbell (PingIden= tity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and d= ifferences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a roug= h interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_= profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Th= x Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, w= hich was incredibly valuable to get tight-loop feedback and incorporate new= ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Loddersted= t,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed gen= erously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't= get credited in the draft, my apologies: please send me a note and I'l= l make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback i= n a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and = above all Brian were all super helpful in negotiating the mysterious syntax= of the RFC format and submission process.

I was blown away by the availability, involveme= nt and willingness to invest time to get things right that everyone demonst= rated in the process. This is an amazing community.=C2=A0

V.

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

=C2=A0

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

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


=C2=A0

--


=C2=A0

--

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


=C2=A0

--

Vennlig hil= sen

=C2=A0

Steinar Noe= m

Partner Ude= lt AS

Systemutvik= ler

=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=A0= www.udelt.no=C2=A0|=C2=A0

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


=C2=A0

--

=C2=A0<= /u>

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


=C2=A0

--

=C2=A0


=C2=A0

--



--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--000000000000890ec30588484841-- From nobody Tue May 7 02:16: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 3D682120043 for ; Tue, 7 May 2019 02:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDAXLCGkvW1L for ; Tue, 7 May 2019 02:16:50 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 1FA77120033 for ; Tue, 7 May 2019 02:16:50 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id c5so21207920wrs.11 for ; Tue, 07 May 2019 02:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0B3e3Ci22/OMLL/eVnv2HP64pwg0SPdo1fE1sA3e1Dc=; b=Hk9ee1S34Eoxkd9Ciw/ItulHj2NqPFYsCGAQIeSdv9xZA7wV6ddc8RUCCiomXSypC3 2rVSdd9O/kYmtH7gt9nL6V2/zmLHvTPxgvcBWmpW2MuL9tl7EcET0Fw7wktGNzBGkFYl w/v0+flCi4i1vQR/xmcNOh23937C2eUeDJFoQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0B3e3Ci22/OMLL/eVnv2HP64pwg0SPdo1fE1sA3e1Dc=; b=SGIpqd+ohXWVD52ketu+uT0H/1VL2GFL4iZ+KV1tZ4+fPe7E6rcdycuB4LNKuHKEB3 8sfMEtKVaF+FDDlv9IJyMsDGXUBtkUBQhPf8sECql1tBNam+/5Jgch20LPRTI0tEYW25 MhHmh5CmB4hc7l4GdtYe0mttAZPRp+Yun3fqG+82/tb5FrfREi3fzTjBCeFQ13eIP2gW FujPOoFwT/f1n/9fWRFfxUq5LvadiYGRFhDJlwWKk3icW1qZ08CRooaENX3m0yGOZw2h CFePGXScUtkHbVYUW48omq1rGx6aTl/vsfLexxu6M7npImMEcn+5C0jotlYcvDoXYF9r eMuw== X-Gm-Message-State: APjAAAWCZD9DoojM3sJ7jLvrtkJldBd3/ZXCbsjJfHYzvQvmNIj8xzF5 WITBT6GH8PmujQ70WBk5H2fMGw== X-Google-Smtp-Source: APXvYqzz58t5dKqNo+TAey5LzcvmgTv8WOHmiv8p4y+26uDsO9c5EoaBz5bzJk/3KdR5TJJbVV02gg== X-Received: by 2002:a5d:6a46:: with SMTP id t6mr10804065wrw.210.1557220608193; Tue, 07 May 2019 02:16:48 -0700 (PDT) Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id 15sm664784wmg.36.2019.05.07.02.16.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 02:16:47 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A94E66EB-C010-4BE4-B24D-FD4B7CEF912E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 10:16:43 +0100 In-Reply-To: Cc: Hans Zandbelt , Karl McGuinness , John Bradley , IETF oauth WG To: Vittorio Bertocci References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 09:16:54 -0000 --Apple-Mail=_A94E66EB-C010-4BE4-B24D-FD4B7CEF912E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ah, that makes sense. Well, we already add a grant_type claim to our = JWT-based access tokens, so I=E2=80=99m in favour of that solution :-) > On 7 May 2019, at 09:48, Vittorio Bertocci wrote: >=20 > Thanks Neil, one more reason to avoid that. > TL;DR,=20 > The context is the discussion we had pre-IIW about whether sub should = be included always or only for tokens issued to ROs. Some exiting = implementations rely on that heuristic. > Turns out that 7519 has language suggesting sub should be there for = both tokens issued for the RO and for apps (via client creds, etc). > We don't want to contradict 7519 but we also want to preserve the = ability for a RS to tell whether an AT was issued via RO auth or app = auth, hence the discussion. Suggestions ranged from adding a grant_type = claim (Vlad made a convincing argument against it), to relying to the = client_id=3D=3Dsub heuristic (which i pushed back on) to the = introduction of a new claim (name TBD given that sub_type is taken = already) that can explicitly declare whether the token has been issued = authenticating th RO or via app credentials. >=20 > On Tue, May 7, 2019 at 1:37 AM Neil Madden > wrote: > I wasn=E2=80=99t at IIW so I may be missing some context. >=20 > There is a potential security issue if the client_id is used as the = =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the = client can register itself with a self-chosen client_id then it may = deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged actions. >=20 > Is this the context of the discussion? >=20 > Given that there are a lot of RSes in existence, many of which are = probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I think the onus is on the AS to ensure that no such = ambiguity can arise in the first place by ensuring that the space of = =E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the = space for genuine users or by disallowing the client_credentials grant = altogether. >=20 > This issue already arises in token introspection though, so maybe = ought to be mentioned in the OAuth security topics draft rather than = specific to the JWT AT draft? >=20 > =E2=80=94 Neil >=20 >> On 6 May 2019, at 18:32, Vittorio Bertocci = > wrote: >>=20 >> Hi all, >> thanks for your patience during this month long hiatus, and thanks = for the comments. >> Last week at IIW I had the opportunity to discuss this with many of = the people on the list. Here's a summary of where the discussion landaed = on the subject of the sub (pun intended). >>=20 >> - It seems that RFC 7519 has pretty clear language on the use of sub- = I didn't check it back when we started the discussion. I do agree with = the people saying that we shouldn't violate existing specifications, = hence it looks like we do need to have sub also in the case in which we = have app-only tokens carrying claims about the app itself. I understand = this will cause some implementation to break, but unfortunately that's = intrinsic in the process of coming up with a common approach and = standards compliance is probably one of the strongest reasons to = tolerate that. >> - That said, I am strongly committed to preserve existing = functionality. One of the main reasons that was brought up for including = sub only for user based ATs was to use it as heuristic for telling those = tokens apart from app-only ones. To that end, Karl MCGuinness suggested = that we include grant_type as a return claim, which the RS could use to = the same effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think? >> Note, John Bradley observed that in some cases this might lead to = ambiguous results if an extension grant is used (say an assertion = profile) but that seems like a relatively fringe occurrence. >>=20 >> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt = > wrote: >> I also meant to say that (of course) the JWT standard doesn't say = that the JWT is supposed to be about the client or about the resource = owner, hence both are valid >>=20 >> Hans. >>=20 >> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones = > = wrote: >> I get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards. >>=20 >> =20 >>=20 >> -- = Mike >>=20 >> =20 >>=20 >> From: Hans Zandbelt >=20 >> Sent: Thursday, April 4, 2019 12:59 PM >> To: Mike Jones > >> Cc: George Fletcher >; Vittorio Bertocci = >; IETF oauth WG > >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>=20 >> =20 >>=20 >> the definition of RFC 7519 is actually "petitio principii" and a lot = of deployments put claims about the Resource Owner in the access token = (as a Resource Server implementer I've suffered a lot from this) >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones = > = wrote: >>=20 >> I agree with George that the subject of a token must be the principal = of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. = Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at = https://tools.ietf.org/html/rfc7519#section-4.1.2 = is: >>=20 >> The "sub" (subject) claim identifies the principal that is the = subject of the JWT. >>=20 >> =20 >>=20 >> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply = with the definition from RFC 7519. >>=20 >> =20 >>=20 >> -- = Mike >>=20 >> =20 >>=20 >> From: OAuth > = On Behalf Of George Fletcher >> Sent: Thursday, April 4, 2019 8:51 AM >> To: Hans Zandbelt > >> Cc: Vittorio Bertocci >; IETF oauth WG > >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>=20 >> =20 >>=20 >> The more I think about this the more I land in the "No" camp. >>=20 >> The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >>=20 >> Thanks, >> George >>=20 >> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>=20 >> I will argue that in a way such deployments are already broken e.g. = in the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: >>=20 >> I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >>=20 >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>=20 >> great summary! this will hurt quite a few existing m2m deployments = but I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = > wrote: >>=20 >> thank you Steinar and everyone else for the comments on this! >>=20 >> To summarize the situation so far: Dominick, Steinar, Rob, David, = Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral. >>=20 >> That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. >>=20 >> Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >>=20 >> =20 >>=20 >> Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. =20 >>=20 >> =20 >>=20 >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: >>=20 >> Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! >>=20 >> We also agree with Dominick concerning definition of the "sub" claim. >>=20 >> =20 >>=20 >> Steinar >>=20 >> =20 >>=20 >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = >: >>=20 >> =46rom an access token consumer (aka API) developer point of view, I = prefer this logic >>=20 >> =20 >>=20 >> "If sub is present - client acts on behalf of a user, if not - not." >>=20 >> =20 >>=20 >> Anything more complicated has a potential of going wrong. >>=20 >> =20 >>=20 >> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com = ) wrote: >>=20 >> Hi Vittorio, >>=20 >> =20 >>=20 >> Yeah, I=E2=80=99m concerning user & client ids collision. >>=20 >> I haven=E2=80=99t seen such implementations, but user-select username = as sub, or incremental integer as sub & client_id will be easily = collide. >>=20 >> =20 >>=20 >> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >>=20 >> =20 >>=20 >> Sent from my iPhone >>=20 >>=20 >> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >>=20 >> Hey Nov, Dominick, Hans- >>=20 >> thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >>=20 >> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >>=20 >> =20 >>=20 >> The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server. >>=20 >> =20 >>=20 >> Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >>=20 >> Nov- playing this back: is the concern that a user and a client might = have the same identifier within an IDP? When using collision resistant = IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production? >>=20 >> =20 >>=20 >> Thanks >>=20 >> V.=20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = > wrote: >>=20 >> I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = > wrote: >>=20 >> Yes I know - and I think in hindsight it was a mistake to use the = same claim type for multiple semantics. >>=20 >> =20 >>=20 >> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >>=20 >> =20 >>=20 >> In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >>=20 >> =20 >>=20 >> Dominick >>=20 >> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu ) wrote: >>=20 >> Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. >>=20 >> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2 = : >>=20 >> =20 >>=20 >> "The "sub" (subject) claim identifies the principal that is the >>=20 >> subject of the JWT. The claims in a JWT are normally statements >>=20 >> about the subject. The subject value MUST either be scoped to be >>=20 >> locally unique in the context of the issuer or be globally unique. >>=20 >> The processing of this claim is generally application specific" >>=20 >> =20 >>=20 >> which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: >>=20 >> IMHO the sub claim should always refer to the user - and nothing = else. >>=20 >> =20 >>=20 >> OIDC says: >>=20 >> =20 >>=20 >> "Subject - Identifier for the End-User at the Issuer." >>=20 >> =20 >>=20 >> client_id should be used to identify clients. >>=20 >> =20 >>=20 >> cheers >>=20 >> Dominick >>=20 >> =20 >>=20 >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: >>=20 >> Hi Vittorio, >>=20 >> =20 >>=20 >> Thanks for the good starting point of standardizing JWT-ized AT. >>=20 >> =20 >>=20 >> One feedback. >>=20 >> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >>=20 >> It requires those 2 types of identifiers to be unique each other in = the IdP context. >>=20 >> =20 >>=20 >> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. >>=20 >> =20 >>=20 >> thanks >>=20 >> =20 >>=20 >> nov >>=20 >> =20 >>=20 >> On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: >>=20 >> =20 >>=20 >> Dear all, >>=20 >> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= >>=20 >> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>=20 >> =20 >>=20 >> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>=20 >> Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >> I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). >> I studied and compared all those instances, identifying commonalities = and differences.=20 >> I put together a presentation summarizing my findings and suggesting = a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! >> The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >> On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. >> I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 >>=20 >> V. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> Vennlig hilsen >>=20 >> =20 >>=20 >> Steinar Noem >>=20 >> Partner Udelt AS >>=20 >> Systemutvikler >>=20 >> =20 >>=20 >> | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 | www.udelt.no = |=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >>=20 >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> =20 >>=20 >>=20 >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >>=20 >> --=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_A94E66EB-C010-4BE4-B24D-FD4B7CEF912E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ah, = that makes sense. Well, we already add a grant_type claim to our = JWT-based access tokens, so I=E2=80=99m in favour of that solution = :-)


On 7 May = 2019, at 09:48, Vittorio Bertocci <Vittorio@auth0.com> = wrote:

Thanks Neil, one more reason to avoid that.
TL;DR, 
The context is the = discussion we had pre-IIW about whether sub should be included always or = only for tokens issued to ROs. Some exiting implementations rely on that = heuristic.
Turns out that 7519 has language = suggesting sub should be there for both tokens issued for the RO and for = apps (via client creds, etc).
We don't want to contradict = 7519 but we also want to preserve the ability for a RS to tell whether = an AT was issued via RO auth or app auth, hence the discussion. = Suggestions ranged from adding a grant_type claim (Vlad made a = convincing argument against it), to relying to the client_id=3D=3Dsub = heuristic (which i pushed back on) to the introduction of a new claim = (name TBD given that sub_type is taken already) that can explicitly = declare whether the token has been issued authenticating th RO or via = app credentials.

On Tue, May 7, 2019 at 1:37 AM Neil = Madden <neil.madden@forgerock.com> wrote:
I wasn=E2=80=99t at IIW so I may be missing some = context.

There is a = potential security issue if the client_id is used as the =E2=80=9Csub=E2=80= =9D for an AT obtained via client_credentials. If the client can = register itself with a self-chosen client_id then it may deliberately = chose a client_id that matches the user name of a privileged user. An RS = that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may then = erroneously let the client perform privileged actions.

Is this the context of = the discussion?

Given that there are a lot of RSes in existence, many of = which are probably just looking at the =E2=80=9Csub=E2=80=9D claim to = identify the resource owner, I think the onus is on the AS to ensure = that no such ambiguity can arise in the first place by ensuring that the = space of =E2=80=9Csub=E2=80=9D values for client credentials is disjoint = with the space for genuine users or by disallowing the = client_credentials grant altogether.

This issue already arises in token = introspection though, so maybe ought to be mentioned in the OAuth = security topics draft rather than specific to the JWT AT = draft?

=E2=80=94= Neil

On 6 May 2019, at 18:32, = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for = your patience during this month long hiatus, and thanks for the = comments.
Last week at IIW I had the opportunity to = discuss this with many of the people on the list. Here's a summary of = where the discussion landaed on the subject of the sub (pun = intended).

- = It seems that RFC 7519 has pretty clear language on the use of sub- I = didn't check it back when we started the discussion. I do agree with the = people saying that we shouldn't violate existing specifications, hence = it looks like we do need to have sub also in the case in which we have = app-only tokens carrying claims about the app itself. I understand this = will cause some implementation to break, but unfortunately that's = intrinsic in the process of coming up with a common approach and = standards compliance is probably one of the strongest reasons to = tolerate that.
- That said, I am strongly committed = to preserve existing functionality. One of the main reasons that was = brought up for including sub only for user based ATs was to use it as = heuristic for telling those tokens apart from app-only ones. To that = end, Karl MCGuinness suggested that we = include grant_type as a return claim, which the RS could use to the same = effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think?
Note, John= Bradley observed that in some cases this might lead to ambiguous = results if an extension grant is used (say an assertion profile) but = that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I also = meant to say that (of course) the JWT standard doesn't say that the JWT = is supposed to be about the client or about the resource owner, hence = both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike = Jones <Michael.Jones@microsoft.com> wrote:

I get that existing practice is = likely to be all over the map, but if we=E2=80=99re to create a JWT = access token standard, it=E2=80=99s reasonable to require that the = claims usage comply with the JWT standards.

 

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

 

From: = Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF = oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is = actually "petitio principii" and a lot of deployments put claims about = the Resource Owner in the access token (as a Resource Server implementer = I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM = Mike Jones <Michael.Jones@microsoft.com> = wrote:

I agree with George that the subject of a token must be the = principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D = claim is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:

The = "sub" (subject) claim identifies the principal that is the subject of = the JWT.

 

If an = access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with the = definition from RFC 7519.

 

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

The more I think = about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything = and makes it easy for people to detect this case in those use cases = where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt = wrote:

I will argue that in a way such = deployments are already broken e.g. in the typical use case of = onboarding client accounts in the same directory/OU/namespace as user = accounts and we don't need to cater for that.

=

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM = George Fletcher <gffletch@aol.com> wrote:

I agree that this = will break a lot of existing flows... especially those using any form of = the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans = Zandbelt wrote:

great summary! this will hurt = quite a few existing m2m deployments but I do like the rigidness of it = all: it is very explicit, cannot misinterpreted and thus prevents = failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone = else for the comments on this!

To summarize the situation so = far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub = only for users. Martin would like to have the sub for app only flows as = well. Hans is neutral.

That does sound like the sub as = user has more consensus, tho before changing it I'd wait for the people = currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to = be able to apply the logic "if there's a sub, it's a user flow", we have = to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

 

Dave, the suggestion of having = explicit typing for app only vs user only is interesting! For the = purpose of putting together an interoperable profile, tho, I would = suggest we table it for v1 in the interest of getting to something easy to adopt (hence = with small delta vs existing implementations) faster.    =  

 

On Tue, Mar 26, 2019 at 1:40 AM = Steinar Noem <steinar@udelt.no> wrote:

Hi Vittorio, we  (the = national federation-gateway for the health services in norway - = "HelseID")  think his is a really valuable initiative!

We also agree with Dominick = concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 = skrev Dominick Baier <dbaier@leastprivilege.com>:

=46ro= m an access token consumer (aka API) developer point of view, I prefer = this logic

 

"If = sub is present - client acts on behalf of a user, if not - = not."

 

Anything more complicated has a potential of going = wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Yeah, I=E2=80=99m concerning user = & client ids collision.

I haven=E2=80=99t seen such = implementations, but user-select username as sub, or incremental integer = as sub & client_id will be easily collide.

 

If you can enforce collision = resistant IDs between user & client instances, it=E2=80=99ll works = fine. I feel its overkill though.

 

Sent from my = iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was = an area I was expecting to cause more discussion, and I am glad we are = having this opportunity to clarify.

The current language in the draft = traces the etymology of sub to OpenID Connect core, hence Dominick = observation is on point. However in the description I express something = in line with 7519, which was in fact my intent.

 

The idea was to provide an = identifier of the calling subject that is guaranteed to be present in = all cases- this would allow an SDK developer to use the same code for = things like lookups and membership checks regardless of the nature of the caller = (user in a delegated case, app in app-only grants). The information to = discriminate between user and app callers is always available in the = token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence = there's no loss in expressive power, should that difference be relevant = for the resource server.

 

Dominick, Hans- I probably missed = the security issue you guys are thinking of in this case. Of course, if = this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a = scenario/use case to clarify the risk?

Nov- playing this back: is the = concern that a user and a client might have the same identifier within = an IDP? When using collision resistant IDs, as it is usually the case, = that seems to be a remote possibility- did you stumble in such scenario in = production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM = Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

I believe there are plenty of = OAuth 2.0 only use cases out there... but nevertheless I agree with the = potential confusion and thus security problems arising from that (though = one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes = I know - and I think in hindsight it was a mistake to use the same claim = type for multiple semantics.

 

All = the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things = more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They = always combine it.

 

In = reality this leads to potential security problems - this spec has the = potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: = OIDC does not apply here since it is not OAuth and an access token is = not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

 

"The "sub" (subject) claim = identifies the principal that is the

   subject of the = JWT.  The claims in a JWT are normally statements

   about the = subject.  The subject value MUST either be scoped to be

   locally unique in = the context of the issuer or be globally unique.

   The processing of = this claim is generally application specific"

 

which kind of spells "client" in = case of the client credentials grant but I also do worry about Resource = Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO = the sub claim should always refer to the user - and nothing = else.

 

OIDC = says:

 

"Subject= - Identifier for the End-User at the Issuer."

 

client_id should be used to = identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Thanks for the good starting = point of standardizing JWT-ized AT.

 

One feedback.

The =E2=80=9Csub=E2=80=9D claim = can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of = identifiers to be unique each other in the IdP context.

 

I prefer omitting =E2=80=9Csub=E2=80= =9D claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

 

Dear all,

I just submitted a draft = describing a JWT profile for OAuth 2.0 access tokens. You can find it = in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.

I have a slot to discuss this = tomorrow at IETF 104 (I'll be presenting remotely). I look forward for = your comments!

 

Here's just a bit of backstory, = in case you are interested in how this doc came to be. The trajectory it = followed is somewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough = to prevent developers from reusing code and skills when moving from = product to product.
  • I asked several individuals from key products and services to share with = me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), = Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities = and differences. 
  • I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on = it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't = get credited in the draft, my apologies: please send me a note and I'll = make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process.

I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 

V.

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

 

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

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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

_______________________________________________
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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 

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

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu



--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_A94E66EB-C010-4BE4-B24D-FD4B7CEF912E-- From nobody Tue May 7 02:18:29 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 DBE3D1200A2 for ; Tue, 7 May 2019 02:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwjJer2DhRPR for ; Tue, 7 May 2019 02:18:24 -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 66285120043 for ; Tue, 7 May 2019 02:18:23 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id m20so7314517wmg.1 for ; Tue, 07 May 2019 02:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:references:cc:to:message-id; bh=wjYhsrpg5dG6c2aWSDIqjUKQrPcS6dHMURLRZ6EHkSk=; b=g78DVT/CIT6L8xcpSo6wf+fqySKrgjrlrAFKug3diYeUBgsTV5oLjJXbKwf8EUHycb RREEiBdD5kLnsaw0NDLNbhnAVJ/BTeP0YaY1i/rhyLqofq93j/uAKa6sHm7jJnQRbiY3 4T0GNJJgKUcIYybC4NvIjH/afb9zyxpEeDeEk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=wjYhsrpg5dG6c2aWSDIqjUKQrPcS6dHMURLRZ6EHkSk=; b=NH0AE0hvYtdFB27s02Pf0oNoyq9KVf1NEV8uhdWzht71dwaRKyIbBBY1lGxwjlTLvd bbpqOAgsQVYgON9TBVoghyvdaCC3BXrz1F/6gHvBvx6klLJFfZLjbDDItsvjVcdqDraE pCXPF2Dso//i/Ald8kx1HQ7dGnWUGOe7fX8Mr7cnPUAF1x1GeGSDK4xCt9S4U4u3sXl6 ljjFhmaMSQyfRXLnGKQ5TwYkf0U1ZlhbkvRahQJEmoIEbNWip7TDwR9qZl2Vd+zAdGI3 1YtSiJsm5agIcC5Z2cCUE+0/lyVlkXkJzTUVB2VsA+LU7UCvu4V900xWJuBV4vYglYkN iibA== X-Gm-Message-State: APjAAAU4xW2YP7tJoT67uNsqvueG1YW7IznoorYohjjbn1JPw6DFk4Vy QRLAqLvXjbhxqnqA/eFoswk1yebM5qCYyfAQs0o1NHN5e+D/3/EGQfqVC+VkHFMxQaPJ47AEpCM 5o6KEAaQbDo46WW4wym2pFSr5tpuzDUEEpqnpguKPjoXJUMQTT5dfpDWK+X6dths= X-Google-Smtp-Source: APXvYqyvLZcRXwJSsfPJBSlmGp2/IS11gXYh9kcQToqrGvJH3qm/ZNaaFAxr4UbRv/FjEs22bTNR2w== X-Received: by 2002:a1c:2c89:: with SMTP id s131mr8480484wms.142.1557220701141; Tue, 07 May 2019 02:18:21 -0700 (PDT) Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id z7sm17347535wme.26.2019.05.07.02.18.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 02:18:20 -0700 (PDT) From: Neil Madden Content-Type: multipart/alternative; boundary="Apple-Mail=_017F60D6-E67F-48EF-86C6-0D31BDE46AAB" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 10:18:14 +0100 References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> To: IETF oauth WG Message-Id: <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [OAUTH-WG] OAuth security topics 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, 07 May 2019 09:18:28 -0000 --Apple-Mail=_017F60D6-E67F-48EF-86C6-0D31BDE46AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is it too late to add the observation below to the OAuth security topics = BCP draft? > Begin forwarded message: >=20 > From: Neil Madden > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > Date: 7 May 2019 at 09:37:29 BST > To: Vittorio Bertocci > Cc: Hans Zandbelt , Karl McGuinness = , John Bradley , IETF oauth WG = >=20 > I wasn=E2=80=99t at IIW so I may be missing some context. >=20 > There is a potential security issue if the client_id is used as the = =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the = client can register itself with a self-chosen client_id then it may = deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged actions. >=20 > Is this the context of the discussion? >=20 > Given that there are a lot of RSes in existence, many of which are = probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I think the onus is on the AS to ensure that no such = ambiguity can arise in the first place by ensuring that the space of = =E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the = space for genuine users or by disallowing the client_credentials grant = altogether. >=20 > This issue already arises in token introspection though, so maybe = ought to be mentioned in the OAuth security topics draft rather than = specific to the JWT AT draft? >=20 > =E2=80=94 Neil >=20 >> On 6 May 2019, at 18:32, Vittorio Bertocci = > wrote: >>=20 >> Hi all, >> thanks for your patience during this month long hiatus, and thanks = for the comments. >> Last week at IIW I had the opportunity to discuss this with many of = the people on the list. Here's a summary of where the discussion landaed = on the subject of the sub (pun intended). >>=20 >> - It seems that RFC 7519 has pretty clear language on the use of sub- = I didn't check it back when we started the discussion. I do agree with = the people saying that we shouldn't violate existing specifications, = hence it looks like we do need to have sub also in the case in which we = have app-only tokens carrying claims about the app itself. I understand = this will cause some implementation to break, but unfortunately that's = intrinsic in the process of coming up with a common approach and = standards compliance is probably one of the strongest reasons to = tolerate that. >> - That said, I am strongly committed to preserve existing = functionality. One of the main reasons that was brought up for including = sub only for user based ATs was to use it as heuristic for telling those = tokens apart from app-only ones. To that end, Karl MCGuinness suggested = that we include grant_type as a return claim, which the RS could use to = the same effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think? >> Note, John Bradley observed that in some cases this might lead to = ambiguous results if an extension grant is used (say an assertion = profile) but that seems like a relatively fringe occurrence. >>=20 >> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt = > wrote: >> I also meant to say that (of course) the JWT standard doesn't say = that the JWT is supposed to be about the client or about the resource = owner, hence both are valid >>=20 >> Hans. >>=20 >> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones = > = wrote: >> I get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards. >>=20 >> =20 >>=20 >> -- = Mike >>=20 >> =20 >>=20 >> From: Hans Zandbelt >=20 >> Sent: Thursday, April 4, 2019 12:59 PM >> To: Mike Jones > >> Cc: George Fletcher >; Vittorio Bertocci = >; IETF oauth WG > >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>=20 >> =20 >>=20 >> the definition of RFC 7519 is actually "petitio principii" and a lot = of deployments put claims about the Resource Owner in the access token = (as a Resource Server implementer I've suffered a lot from this) >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones = > = wrote: >>=20 >> I agree with George that the subject of a token must be the principal = of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. = Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at = https://tools.ietf.org/html/rfc7519#section-4.1.2 = is: >>=20 >> The "sub" (subject) claim identifies the principal that is the = subject of the JWT. >>=20 >> =20 >>=20 >> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply = with the definition from RFC 7519. >>=20 >> =20 >>=20 >> -- = Mike >>=20 >> =20 >>=20 >> From: OAuth > = On Behalf Of George Fletcher >> Sent: Thursday, April 4, 2019 8:51 AM >> To: Hans Zandbelt > >> Cc: Vittorio Bertocci >; IETF oauth WG > >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>=20 >> =20 >>=20 >> The more I think about this the more I land in the "No" camp. >>=20 >> The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >>=20 >> Thanks, >> George >>=20 >> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>=20 >> I will argue that in a way such deployments are already broken e.g. = in the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: >>=20 >> I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >>=20 >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>=20 >> great summary! this will hurt quite a few existing m2m deployments = but I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = > wrote: >>=20 >> thank you Steinar and everyone else for the comments on this! >>=20 >> To summarize the situation so far: Dominick, Steinar, Rob, David, = Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral. >>=20 >> That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. >>=20 >> Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >>=20 >> =20 >>=20 >> Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. =20 >>=20 >> =20 >>=20 >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: >>=20 >> Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! >>=20 >> We also agree with Dominick concerning definition of the "sub" claim. >>=20 >> =20 >>=20 >> Steinar >>=20 >> =20 >>=20 >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = >: >>=20 >> =46rom an access token consumer (aka API) developer point of view, I = prefer this logic >>=20 >> =20 >>=20 >> "If sub is present - client acts on behalf of a user, if not - not." >>=20 >> =20 >>=20 >> Anything more complicated has a potential of going wrong. >>=20 >> =20 >>=20 >> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com = ) wrote: >>=20 >> Hi Vittorio, >>=20 >> =20 >>=20 >> Yeah, I=E2=80=99m concerning user & client ids collision. >>=20 >> I haven=E2=80=99t seen such implementations, but user-select username = as sub, or incremental integer as sub & client_id will be easily = collide. >>=20 >> =20 >>=20 >> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >>=20 >> =20 >>=20 >> Sent from my iPhone >>=20 >>=20 >> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >>=20 >> Hey Nov, Dominick, Hans- >>=20 >> thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >>=20 >> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >>=20 >> =20 >>=20 >> The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server. >>=20 >> =20 >>=20 >> Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >>=20 >> Nov- playing this back: is the concern that a user and a client might = have the same identifier within an IDP? When using collision resistant = IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production? >>=20 >> =20 >>=20 >> Thanks >>=20 >> V.=20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = > wrote: >>=20 >> I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = > wrote: >>=20 >> Yes I know - and I think in hindsight it was a mistake to use the = same claim type for multiple semantics. >>=20 >> =20 >>=20 >> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >>=20 >> =20 >>=20 >> In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >>=20 >> =20 >>=20 >> Dominick >>=20 >> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu ) wrote: >>=20 >> Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. >>=20 >> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2 = : >>=20 >> =20 >>=20 >> "The "sub" (subject) claim identifies the principal that is the >>=20 >> subject of the JWT. The claims in a JWT are normally statements >>=20 >> about the subject. The subject value MUST either be scoped to be >>=20 >> locally unique in the context of the issuer or be globally unique. >>=20 >> The processing of this claim is generally application specific" >>=20 >> =20 >>=20 >> which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users >>=20 >> =20 >>=20 >> Hans. >>=20 >> =20 >>=20 >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: >>=20 >> IMHO the sub claim should always refer to the user - and nothing = else. >>=20 >> =20 >>=20 >> OIDC says: >>=20 >> =20 >>=20 >> "Subject - Identifier for the End-User at the Issuer." >>=20 >> =20 >>=20 >> client_id should be used to identify clients. >>=20 >> =20 >>=20 >> cheers >>=20 >> Dominick >>=20 >> =20 >>=20 >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: >>=20 >> Hi Vittorio, >>=20 >> =20 >>=20 >> Thanks for the good starting point of standardizing JWT-ized AT. >>=20 >> =20 >>=20 >> One feedback. >>=20 >> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >>=20 >> It requires those 2 types of identifiers to be unique each other in = the IdP context. >>=20 >> =20 >>=20 >> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. >>=20 >> =20 >>=20 >> thanks >>=20 >> =20 >>=20 >> nov >>=20 >> =20 >>=20 >> On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: >>=20 >> =20 >>=20 >> Dear all, >>=20 >> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= >>=20 >> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>=20 >> =20 >>=20 >> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>=20 >> Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >> I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). >> I studied and compared all those instances, identifying commonalities = and differences.=20 >> I put together a presentation summarizing my findings and suggesting = a rough interoperable profile = (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci= _-_a_jwt_profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! >> The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >> On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. >> I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 >>=20 >> V. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> Vennlig hilsen >>=20 >> =20 >>=20 >> Steinar Noem >>=20 >> Partner Udelt AS >>=20 >> Systemutvikler >>=20 >> =20 >>=20 >> | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 | www.udelt.no = |=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >>=20 >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> =20 >>=20 >>=20 >>=20 >> =20 >>=20 >> -- >>=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >>=20 >> --=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_017F60D6-E67F-48EF-86C6-0D31BDE46AAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Is it too late to add the observation below to the OAuth = security topics BCP draft?


Begin = forwarded message:

From: = Neil Madden <neil.madden@forgerock.com>
Subject: = Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00
Date: = 7 May 2019 at 09:37:29 BST
To: = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Cc: = Hans Zandbelt <hans.zandbelt@zmartzone.eu>, Karl McGuinness <kmcguinness@okta.com>, John Bradley <ve7jtb@ve7jtb.com>, = IETF oauth WG <oauth@ietf.org>

I wasn=E2=80=99t at IIW so I may be missing some context.

There is a potential = security issue if the client_id is used as the =E2=80=9Csub=E2=80=9D for = an AT obtained via client_credentials. If the client can register itself = with a self-chosen client_id then it may deliberately chose a client_id = that matches the user name of a privileged user. An RS that just blindly = looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let the = client perform privileged actions.

Is this the context of the = discussion?

Given that there are a lot of RSes in existence, many of = which are probably just looking at the =E2=80=9Csub=E2=80=9D claim to = identify the resource owner, I think the onus is on the AS to ensure = that no such ambiguity can arise in the first place by ensuring that the = space of =E2=80=9Csub=E2=80=9D values for client credentials is disjoint = with the space for genuine users or by disallowing the = client_credentials grant altogether.

This issue already arises in token = introspection though, so maybe ought to be mentioned in the OAuth = security topics draft rather than specific to the JWT AT = draft?

=E2=80=94= Neil

On 6 May 2019, at 18:32, = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this = month long hiatus, and thanks for the comments.
Last = week at IIW I had the opportunity to discuss this with many of the = people on the list. Here's a summary of where the discussion landaed on = the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty = clear language on the use of sub- I didn't check it back when we started = the discussion. I do agree with the people saying that we shouldn't = violate existing specifications, hence it looks like we do need to have = sub also in the case in which we have app-only tokens carrying claims = about the app itself. I understand this will cause some implementation = to break, but unfortunately that's intrinsic in the process of coming up = with a common approach and standards compliance is probably one of the = strongest reasons to tolerate that.
- That said, I = am strongly committed to preserve existing functionality. One of the = main reasons that was brought up for including sub only for user based = ATs was to use it as heuristic for telling those tokens apart from = app-only ones. To that end, Karl = MCGuinness suggested that we include grant_type as a return claim, = which the RS could use to the same effect. I find the proposal very = clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some = cases this might lead to ambiguous results if an extension grant is used = (say an assertion profile) but that seems like a relatively fringe = occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans = Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I also = meant to say that (of course) the JWT standard doesn't say that the JWT = is supposed to be about the client or about the resource owner, hence = both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike = Jones <Michael.Jones@microsoft.com> wrote:

I= get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards.

 

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

 

From: = Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF = oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is = actually "petitio principii" and a lot of deployments put claims about = the Resource Owner in the access token (as a Resource Server implementer = I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM = Mike Jones <Michael.Jones@microsoft.com> = wrote:

I agree with George that the subject of a token must be the = principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D = claim is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:

The = "sub" (subject) claim identifies the principal that is the subject of = the JWT.

 

If an = access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with the = definition from RFC 7519.

 

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

The more I think = about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything = and makes it easy for people to detect this case in those use cases = where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt = wrote:

I will argue that in a way such = deployments are already broken e.g. in the typical use case of = onboarding client accounts in the same directory/OU/namespace as user = accounts and we don't need to cater for that.

=

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM = George Fletcher <gffletch@aol.com> wrote:

I agree that this = will break a lot of existing flows... especially those using any form of = the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans = Zandbelt wrote:

great summary! this will hurt = quite a few existing m2m deployments but I do like the rigidness of it = all: it is very explicit, cannot misinterpreted and thus prevents = failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone = else for the comments on this!

To summarize the situation so = far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub = only for users. Martin would like to have the sub for app only flows as = well. Hans is neutral.

That does sound like the sub as = user has more consensus, tho before changing it I'd wait for the people = currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to = be able to apply the logic "if there's a sub, it's a user flow", we have = to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

 

Dave, the suggestion of having = explicit typing for app only vs user only is interesting! For the = purpose of putting together an interoperable profile, tho, I would = suggest we table it for v1 in the interest of getting to something easy to adopt (hence = with small delta vs existing implementations) faster.    =  

 

On Tue, Mar 26, 2019 at 1:40 AM = Steinar Noem <steinar@udelt.no> wrote:

Hi Vittorio, we  (the = national federation-gateway for the health services in norway - = "HelseID")  think his is a really valuable initiative!

We also agree with Dominick = concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 = skrev Dominick Baier <dbaier@leastprivilege.com>:

=46ro= m an access token consumer (aka API) developer point of view, I prefer = this logic

 

"If = sub is present - client acts on behalf of a user, if not - = not."

 

Anything more complicated has a potential of going = wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Yeah, I=E2=80=99m concerning user = & client ids collision.

I haven=E2=80=99t seen such = implementations, but user-select username as sub, or incremental integer = as sub & client_id will be easily collide.

 

If you can enforce collision = resistant IDs between user & client instances, it=E2=80=99ll works = fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was = an area I was expecting to cause more discussion, and I am glad we are = having this opportunity to clarify.

The current language in the draft = traces the etymology of sub to OpenID Connect core, hence Dominick = observation is on point. However in the description I express something = in line with 7519, which was in fact my intent.

 

The idea was to provide an = identifier of the calling subject that is guaranteed to be present in = all cases- this would allow an SDK developer to use the same code for = things like lookups and membership checks regardless of the nature of the caller = (user in a delegated case, app in app-only grants). The information to = discriminate between user and app callers is always available in the = token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence = there's no loss in expressive power, should that difference be relevant = for the resource server.

 

Dominick, Hans- I probably missed = the security issue you guys are thinking of in this case. Of course, if = this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a = scenario/use case to clarify the risk?

Nov- playing this back: is the = concern that a user and a client might have the same identifier within = an IDP? When using collision resistant IDs, as it is usually the case, = that seems to be a remote possibility- did you stumble in such scenario in = production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM = Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

I believe there are plenty of = OAuth 2.0 only use cases out there... but nevertheless I agree with the = potential confusion and thus security problems arising from that (though = one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes = I know - and I think in hindsight it was a mistake to use the same claim = type for multiple semantics.

 

All = the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things = more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They = always combine it.

 

In = reality this leads to potential security problems - this spec has the = potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: = OIDC does not apply here since it is not OAuth and an access token is = not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

 

"The "sub" (subject) claim = identifies the principal that is the

   subject of the = JWT.  The claims in a JWT are normally statements

   about the = subject.  The subject value MUST either be scoped to be

   locally unique in = the context of the issuer or be globally unique.

   The processing of = this claim is generally application specific"

 

which kind of spells "client" in = case of the client credentials grant but I also do worry about Resource = Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO = the sub claim should always refer to the user - and nothing = else.

 

OIDC = says:

 

"Subject= - Identifier for the End-User at the Issuer."

 

client_id should be used to = identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Thanks for the good starting = point of standardizing JWT-ized AT.

 

One feedback.

The =E2=80=9Csub=E2=80=9D claim = can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of = identifiers to be unique each other in the IdP context.

 

I prefer omitting =E2=80=9Csub=E2=80= =9D claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

 

Dear all,

I just submitted a draft = describing a JWT profile for OAuth 2.0 access tokens. You can find it = in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.

I have a slot to discuss this = tomorrow at IETF 104 (I'll be presenting remotely). I look forward for = your comments!

 

Here's just a bit of backstory, = in case you are interested in how this doc came to be. The trajectory it = followed is somewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough = to prevent developers from reusing code and skills when moving from = product to product.
  • I asked several individuals from key products and services to share with = me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), = Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities = and differences. 
  • I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on = it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't = get credited in the draft, my apologies: please send me a note and I'll = make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process.

I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 

V.

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

 

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

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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

_______________________________________________
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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 

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

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu



--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_017F60D6-E67F-48EF-86C6-0D31BDE46AAB-- From nobody Tue May 7 02:25: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 1D2CA120033 for ; Tue, 7 May 2019 02:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY7CASk7D07t for ; Tue, 7 May 2019 02:25:31 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20063.outbound.protection.outlook.com [40.107.2.63]) (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 4FC4412000E for ; Tue, 7 May 2019 02:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AAwHsbC7DP9K/zRHrouBcGBayWznaX3y472r7aShbtg=; b=Wraxg0E+/W/zdzJRKS1gC7X/ctm8Qv61DGWcOVFP3iqlzYTZG2sZGg0Of0jb/ECMdXf+sVC+ipCXI+lVE7vfDxF95ETitDgRK1w4DYQRlfUWu2Kt5/uSWz4HQaNhfl8VROc1zAgy9DZU5LapP8kXlbLlZaHGnMzsVNhjs7AyTOQ= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4870.eurprd08.prod.outlook.com (20.179.46.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 7 May 2019 09:25:27 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 09:25:27 +0000 From: Hannes Tschofenig To: Neil Madden , IETF oauth WG Thread-Topic: [OAUTH-WG] OAuth security topics Thread-Index: AQHVBLXciYgEKRkfwEavY5dnAZVnpKZfY/Wg Date: Tue, 7 May 2019 09:25:27 +0000 Message-ID: References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> In-Reply-To: <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a29718e-0ff3-426e-aa0c-08d6d2cdf0ef x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4870; x-ms-traffictypediagnostic: DBBPR08MB4870: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(396003)(366004)(376002)(51914003)(53754006)(199004)(189003)(40434004)(72206003)(9686003)(66446008)(6306002)(54896002)(81166006)(81156014)(8676002)(55016002)(66476007)(561944003)(25786009)(6506007)(68736007)(15974865002)(236005)(186003)(14454004)(5660300002)(440504004)(2906002)(71190400001)(14444005)(71200400001)(5024004)(5070765005)(606006)(45080400002)(86362001)(256004)(517774005)(53946003)(8936002)(76116006)(7736002)(53936002)(73956011)(66946007)(6246003)(74316002)(6436002)(7110500001)(15650500001)(966005)(26005)(102836004)(229853002)(30864003)(64756008)(478600001)(66556008)(52536014)(11346002)(446003)(66066001)(790700001)(3846002)(316002)(110136005)(76176011)(53546011)(99286004)(486006)(476003)(33656002)(2420400007)(6116002)(7696005)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4870; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Uh9PdOqAFAHS8evjdglr9MZmH59QWiduVLyWWpSDiBrCUgLCQsSIQkfYVFuCGbpsGX4W3ljj2l7jXpAQmD0iVim+gNu6jNY3tzDDr4o6yxSM1jlGxV1cVLRMKjJ0r2fGRzIA+gdUDWePaQiPAC3yEwTlJzrZ9u2kEPcVE6vjuvxwpdLEaRwsEewXhPZ77hcANSl9uzzKMIOgg+35yXh4G7I2d5s3Mum/FbWjVkg+cnohDVL8nhkAiIcUVlj/jeJD3gYNnqbZ785x/gClMvEdn6hiI5KeBPDZqjzT5BrO/gMkMeA/T22o+BCrhWUHRw6yqV9NUV8aGo/3SODaX6denaquV/pDHw2azMFM2bvOWfRDLVloBpxbQ/cbbFH0fysATZ6Ej8WpEh2LfD84CUNvxX17XrFjT1DIVzYzS17AZyU= Content-Type: multipart/alternative; boundary="_000_DBBPR08MB4539FD7B2C7D27BFBF248E5EFA310DBBPR08MB4539eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a29718e-0ff3-426e-aa0c-08d6d2cdf0ef X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 09:25:27.1260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4870 Archived-At: Subject: Re: [OAUTH-WG] OAuth security topics 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, 07 May 2019 09:25:36 -0000 --_000_DBBPR08MB4539FD7B2C7D27BFBF248E5EFA310DBBPR08MB4539eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIGl0IGlzIGRlZmluaXRlbHkgbm90IHRvbyBsYXRlIGZvciB5b3VyIGNvbW1lbnQNCg0KRnJv bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBOZWlsIE1hZGRl bg0KU2VudDogRGllbnN0YWcsIDcuIE1haSAyMDE5IDExOjE4DQpUbzogSUVURiBvYXV0aCBXRyA8 b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIHNlY3VyaXR5IHRvcGlj cw0KDQpJcyBpdCB0b28gbGF0ZSB0byBhZGQgdGhlIG9ic2VydmF0aW9uIGJlbG93IHRvIHRoZSBP QXV0aCBzZWN1cml0eSB0b3BpY3MgQkNQIGRyYWZ0Pw0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1l c3NhZ2U6DQoNCkZyb206IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1h aWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDANCkRhdGU6IDcgTWF5IDIw MTkgYXQgMDk6Mzc6MjkgQlNUDQpUbzogVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0 aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5p ZXRmLm9yZz4+DQpDYzogSGFucyBaYW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8 bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pj4sIEthcmwgTWNHdWlubmVzcyA8a21j Z3Vpbm5lc3NAb2t0YS5jb208bWFpbHRvOmttY2d1aW5uZXNzQG9rdGEuY29tPj4sIEpvaG4gQnJh ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4sIElFVEYg b2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQoNCkkgd2Fz buKAmXQgYXQgSUlXIHNvIEkgbWF5IGJlIG1pc3Npbmcgc29tZSBjb250ZXh0Lg0KDQpUaGVyZSBp cyBhIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpZiB0aGUgY2xpZW50X2lkIGlzIHVzZWQgYXMg dGhlIOKAnHN1YuKAnSBmb3IgYW4gQVQgb2J0YWluZWQgdmlhIGNsaWVudF9jcmVkZW50aWFscy4g SWYgdGhlIGNsaWVudCBjYW4gcmVnaXN0ZXIgaXRzZWxmIHdpdGggYSBzZWxmLWNob3NlbiBjbGll bnRfaWQgdGhlbiBpdCBtYXkgZGVsaWJlcmF0ZWx5IGNob3NlIGEgY2xpZW50X2lkIHRoYXQgbWF0 Y2hlcyB0aGUgdXNlciBuYW1lIG9mIGEgcHJpdmlsZWdlZCB1c2VyLiBBbiBSUyB0aGF0IGp1c3Qg YmxpbmRseSBsb29rcyBhdCB0aGUg4oCcc3Vi4oCdIGNsYWltIG1heSB0aGVuIGVycm9uZW91c2x5 IGxldCB0aGUgY2xpZW50IHBlcmZvcm0gcHJpdmlsZWdlZCBhY3Rpb25zLg0KDQpJcyB0aGlzIHRo ZSBjb250ZXh0IG9mIHRoZSBkaXNjdXNzaW9uPw0KDQpHaXZlbiB0aGF0IHRoZXJlIGFyZSBhIGxv dCBvZiBSU2VzIGluIGV4aXN0ZW5jZSwgbWFueSBvZiB3aGljaCBhcmUgcHJvYmFibHkganVzdCBs b29raW5nIGF0IHRoZSDigJxzdWLigJ0gY2xhaW0gdG8gaWRlbnRpZnkgdGhlIHJlc291cmNlIG93 bmVyLCBJIHRoaW5rIHRoZSBvbnVzIGlzIG9uIHRoZSBBUyB0byBlbnN1cmUgdGhhdCBubyBzdWNo IGFtYmlndWl0eSBjYW4gYXJpc2UgaW4gdGhlIGZpcnN0IHBsYWNlIGJ5IGVuc3VyaW5nIHRoYXQg dGhlIHNwYWNlIG9mIOKAnHN1YuKAnSB2YWx1ZXMgZm9yIGNsaWVudCBjcmVkZW50aWFscyBpcyBk aXNqb2ludCB3aXRoIHRoZSBzcGFjZSBmb3IgZ2VudWluZSB1c2VycyBvciBieSBkaXNhbGxvd2lu ZyB0aGUgY2xpZW50X2NyZWRlbnRpYWxzIGdyYW50IGFsdG9nZXRoZXIuDQoNClRoaXMgaXNzdWUg YWxyZWFkeSBhcmlzZXMgaW4gdG9rZW4gaW50cm9zcGVjdGlvbiB0aG91Z2gsIHNvIG1heWJlIG91 Z2h0IHRvIGJlIG1lbnRpb25lZCBpbiB0aGUgT0F1dGggc2VjdXJpdHkgdG9waWNzIGRyYWZ0IHJh dGhlciB0aGFuIHNwZWNpZmljIHRvIHRoZSBKV1QgQVQgZHJhZnQ/DQoNCuKAlCBOZWlsDQoNCg0K T24gNiBNYXkgMjAxOSwgYXQgMTg6MzIsIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCg0KSGkgYWxsLA0KdGhhbmtzIGZvciB5b3VyIHBhdGllbmNlIGR1 cmluZyB0aGlzIG1vbnRoIGxvbmcgaGlhdHVzLCBhbmQgdGhhbmtzIGZvciB0aGUgY29tbWVudHMu DQpMYXN0IHdlZWsgYXQgSUlXIEkgaGFkIHRoZSBvcHBvcnR1bml0eSB0byBkaXNjdXNzIHRoaXMg d2l0aCBtYW55IG9mIHRoZSBwZW9wbGUgb24gdGhlIGxpc3QuIEhlcmUncyBhIHN1bW1hcnkgb2Yg d2hlcmUgdGhlIGRpc2N1c3Npb24gbGFuZGFlZCBvbiB0aGUgc3ViamVjdCBvZiB0aGUgc3ViIChw dW4gaW50ZW5kZWQpLg0KDQotIEl0IHNlZW1zIHRoYXQgUkZDIDc1MTkgaGFzIHByZXR0eSBjbGVh ciBsYW5ndWFnZSBvbiB0aGUgdXNlIG9mIHN1Yi0gSSBkaWRuJ3QgY2hlY2sgaXQgYmFjayB3aGVu IHdlIHN0YXJ0ZWQgdGhlIGRpc2N1c3Npb24uIEkgZG8gYWdyZWUgd2l0aCB0aGUgcGVvcGxlIHNh eWluZyB0aGF0IHdlIHNob3VsZG4ndCB2aW9sYXRlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zLCBo ZW5jZSBpdCBsb29rcyBsaWtlIHdlIGRvIG5lZWQgdG8gaGF2ZSBzdWIgYWxzbyBpbiB0aGUgY2Fz ZSBpbiB3aGljaCB3ZSBoYXZlIGFwcC1vbmx5IHRva2VucyBjYXJyeWluZyBjbGFpbXMgYWJvdXQg dGhlIGFwcCBpdHNlbGYuIEkgdW5kZXJzdGFuZCB0aGlzIHdpbGwgY2F1c2Ugc29tZSBpbXBsZW1l bnRhdGlvbiB0byBicmVhaywgYnV0IHVuZm9ydHVuYXRlbHkgdGhhdCdzIGludHJpbnNpYyBpbiB0 aGUgcHJvY2VzcyBvZiBjb21pbmcgdXAgd2l0aCBhIGNvbW1vbiBhcHByb2FjaCBhbmQgc3RhbmRh cmRzIGNvbXBsaWFuY2UgaXMgcHJvYmFibHkgb25lIG9mIHRoZSBzdHJvbmdlc3QgcmVhc29ucyB0 byB0b2xlcmF0ZSB0aGF0Lg0KLSBUaGF0IHNhaWQsIEkgYW0gc3Ryb25nbHkgY29tbWl0dGVkIHRv IHByZXNlcnZlIGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHkuIE9uZSBvZiB0aGUgbWFpbiByZWFzb25z IHRoYXQgd2FzIGJyb3VnaHQgdXAgZm9yIGluY2x1ZGluZyBzdWIgb25seSBmb3IgdXNlciBiYXNl ZCBBVHMgd2FzIHRvIHVzZSBpdCBhcyBoZXVyaXN0aWMgZm9yIHRlbGxpbmcgdGhvc2UgdG9rZW5z IGFwYXJ0IGZyb20gYXBwLW9ubHkgb25lcy4gVG8gdGhhdCBlbmQsIEthcmwgTUNHdWlubmVzcyBz dWdnZXN0ZWQgdGhhdCB3ZSBpbmNsdWRlIGdyYW50X3R5cGUgYXMgYSByZXR1cm4gY2xhaW0sIHdo aWNoIHRoZSBSUyBjb3VsZCB1c2UgdG8gdGhlIHNhbWUgZWZmZWN0LiBJIGZpbmQgdGhlIHByb3Bv c2FsIHZlcnkgY2xldmVyLCBhbmQgdGhlIHBlb3BsZSBhdCBJSVcgdGhvdWdodCBzbyBhcyB3ZWxs LiBXaGF0IHlvdSB0aGluaz8NCk5vdGUsIEpvaG4gQnJhZGxleSBvYnNlcnZlZCB0aGF0IGluIHNv bWUgY2FzZXMgdGhpcyBtaWdodCBsZWFkIHRvIGFtYmlndW91cyByZXN1bHRzIGlmIGFuIGV4dGVu c2lvbiBncmFudCBpcyB1c2VkIChzYXkgYW4gYXNzZXJ0aW9uIHByb2ZpbGUpIGJ1dCB0aGF0IHNl ZW1zIGxpa2UgYSByZWxhdGl2ZWx5IGZyaW5nZSBvY2N1cnJlbmNlLg0KDQpPbiBUaHUsIEFwciA0 LCAyMDE5IGF0IDE6MTEgUE0gSGFucyBaYW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpvbmUu ZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pj4gd3JvdGU6DQpJIGFsc28gbWVh bnQgdG8gc2F5IHRoYXQgKG9mIGNvdXJzZSkgdGhlIEpXVCBzdGFuZGFyZCBkb2Vzbid0IHNheSB0 aGF0IHRoZSBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgYWJvdXQgdGhlIGNsaWVudCBvciBhYm91dCB0 aGUgcmVzb3VyY2Ugb3duZXIsIGhlbmNlIGJvdGggYXJlIHZhbGlkDQoNCkhhbnMuDQoNCk9uIFRo dSwgQXByIDQsIDIwMTkgYXQgMTA6MDkgUE0gTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkg Z2V0IHRoYXQgZXhpc3RpbmcgcHJhY3RpY2UgaXMgbGlrZWx5IHRvIGJlIGFsbCBvdmVyIHRoZSBt YXAsIGJ1dCBpZiB3ZeKAmXJlIHRvIGNyZWF0ZSBhIEpXVCBhY2Nlc3MgdG9rZW4gc3RhbmRhcmQs IGl04oCZcyByZWFzb25hYmxlIHRvIHJlcXVpcmUgdGhhdCB0aGUgY2xhaW1zIHVzYWdlIGNvbXBs eSB3aXRoIHRoZSBKV1Qgc3RhbmRhcmRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBIYW5z IFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVs dEB6bWFydHpvbmUuZXU+Pg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDQsIDIwMTkgMTI6NTkgUE0N ClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00 MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYW9sLmNvbUBkbWFyYy4uLmlldGYub3Jn Pj47IFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9y ZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgSUVURiBvYXV0aCBXRyA8b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDANCg0KdGhlIGRlZmlu aXRpb24gb2YgUkZDIDc1MTkgaXMgYWN0dWFsbHkgInBldGl0aW8gcHJpbmNpcGlpIiBhbmQgYSBs b3Qgb2YgZGVwbG95bWVudHMgcHV0IGNsYWltcyBhYm91dCB0aGUgUmVzb3VyY2UgT3duZXIgaW4g dGhlIGFjY2VzcyB0b2tlbiAoYXMgYSBSZXNvdXJjZSBTZXJ2ZXIgaW1wbGVtZW50ZXIgSSd2ZSBz dWZmZXJlZCBhIGxvdCBmcm9tIHRoaXMpDQoNCkhhbnMuDQoNCk9uIFRodSwgQXByIDQsIDIwMTkg YXQgOTo0OCBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB3aXRoIEdlb3Jn ZSB0aGF0IHRoZSBzdWJqZWN0IG9mIGEgdG9rZW4gbXVzdCBiZSB0aGUgcHJpbmNpcGFsIG9mIHRo YXQgdG9rZW4uICBUaGF0IHdoYXQgdGhlIEpXVCDigJxzdWLigJ0gY2xhaW0gaXMgZm9yLiAgSW5k ZWVkLCB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIOKAnHN1YuKAnSBkZWZpbml0aW9uIGF0IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNC4xLjIgaXM6DQpUaGUg InN1YiIgKHN1YmplY3QpIGNsYWltIGlkZW50aWZpZXMgdGhlIHByaW5jaXBhbCB0aGF0IGlzIHRo ZSBzdWJqZWN0IG9mIHRoZSBKV1QuDQoNCklmIGFuIGFjY2VzcyB0b2tlbiB1c2VzIOKAnHN1YuKA nSwgaXRzIHVzYWdlIG11c3QgY29tcGx5IHdpdGggdGhlIGRlZmluaXRpb24gZnJvbSBSRkMgNzUx OS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgR2VvcmdlIEZs ZXRjaGVyDQpTZW50OiBUaHVyc2RheSwgQXByaWwgNCwgMjAxOSA4OjUxIEFNDQpUbzogSGFucyBa YW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRA em1hcnR6b25lLmV1Pj4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRoMC5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj47IElF VEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0 LTAwDQoNClRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgdGhpcyB0aGUgbW9yZSBJIGxhbmQgaW4gdGhl ICJObyIgY2FtcC4NCg0KVGhlIHN1YmplY3Qgb2YgYSB0b2tlbiBzaG91bGQgYmUgdGhlIHByaW5j aXBhbCBvZiB0aGF0IHRva2VuLiBJdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIgdGhhdCBpcyBh IG1hY2hpbmUsIGEgdXNlciwgb3IgYSBkZXZpY2UuIFRyeWluZyB0byBzZXBhcmF0ZSBvdXQgImh1 bWFucyIgYXMgYSBzcGVjaWFsIGNsYXNzIHdpbGwganVzdCBtYWtlIHRoaW5ncyBtb3JlIGNvbXBs aWNhdGVkLiBJZiB3ZSBuZWVkIGEgY2xhaW0gdG8gaWRlbnRpZnkgdGhlIHN1YmplY3QgaXMgYSAi aHVtYW4iIHRoZW4gd2h5IG5vdCBqdXN0IGFkZCB0aGF0LiBUaGlzIGRvZXNuJ3QgYnJlYWsgYW55 dGhpbmcgYW5kIG1ha2VzIGl0IGVhc3kgZm9yIHBlb3BsZSB0byBkZXRlY3QgdGhpcyBjYXNlIGlu IHRob3NlIHVzZSBjYXNlcyB3aGVyZSBpdCdzIHJlcXVpcmVkLg0KDQpUaGFua3MsDQpHZW9yZ2UN Ck9uIDQvMy8xOSA0OjU2IFBNLCBIYW5zIFphbmRiZWx0IHdyb3RlOg0KSSB3aWxsIGFyZ3VlIHRo YXQgaW4gYSB3YXkgc3VjaCBkZXBsb3ltZW50cyBhcmUgYWxyZWFkeSBicm9rZW4gZS5nLiBpbiB0 aGUgdHlwaWNhbCB1c2UgY2FzZSBvZiBvbmJvYXJkaW5nIGNsaWVudCBhY2NvdW50cyBpbiB0aGUg c2FtZSBkaXJlY3RvcnkvT1UvbmFtZXNwYWNlIGFzIHVzZXIgYWNjb3VudHMgYW5kIHdlIGRvbid0 IG5lZWQgdG8gY2F0ZXIgZm9yIHRoYXQuDQoNCkhhbnMuDQoNCk9uIFdlZCwgQXByIDMsIDIwMTkg YXQgMTA6NDggUE0gR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpnZmZs ZXRjaEBhb2wuY29tPj4gd3JvdGU6DQpJIGFncmVlIHRoYXQgdGhpcyB3aWxsIGJyZWFrIGEgbG90 IG9mIGV4aXN0aW5nIGZsb3dzLi4uIGVzcGVjaWFsbHkgdGhvc2UgdXNpbmcgYW55IGZvcm0gb2Yg dGhlIGNsaWVudF9jcmVkZW50aWFscyBmbG93LiBJbiB0aGF0IHNlbnNlIEknbSBub3QgY29tcGxl dGVseSBvbiBib2FyZCB5ZXQgOikNCk9uIDMvMjYvMTkgMTI6NTYgUE0sIEhhbnMgWmFuZGJlbHQg d3JvdGU6DQpncmVhdCBzdW1tYXJ5ISB0aGlzIHdpbGwgaHVydCBxdWl0ZSBhIGZldyBleGlzdGlu ZyBtMm0gZGVwbG95bWVudHMgYnV0IEkgZG8gbGlrZSB0aGUgcmlnaWRuZXNzIG9mIGl0IGFsbDog aXQgaXMgdmVyeSBleHBsaWNpdCwgY2Fubm90IG1pc2ludGVycHJldGVkIGFuZCB0aHVzIHByZXZl bnRzIGZhaWx1cmUgKHdoaWNoIGlzIHJlYWxseSB3aGF0IERvbWluaWNrIGlzIGFmdGVyKTsgSSdt IG9uIGJvYXJkDQoNCkhhbnMuDQoNCk9uIFR1ZSwgTWFyIDI2LCAyMDE5IGF0IDU6NDkgUE0gVml0 dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KdGhhbmsgeW91IFN0ZWluYXIg YW5kIGV2ZXJ5b25lIGVsc2UgZm9yIHRoZSBjb21tZW50cyBvbiB0aGlzIQ0KVG8gc3VtbWFyaXpl IHRoZSBzaXR1YXRpb24gc28gZmFyOiBEb21pbmljaywgU3RlaW5hciwgUm9iLCBEYXZpZCwgTm92 LCBCZXJ0cmFuZCByZWNvbW1lbmQgdXNpbmcgc3ViIG9ubHkgZm9yIHVzZXJzLiBNYXJ0aW4gd291 bGQgbGlrZSB0byBoYXZlIHRoZSBzdWIgZm9yIGFwcCBvbmx5IGZsb3dzIGFzIHdlbGwuIEhhbnMg aXMgbmV1dHJhbC4NClRoYXQgZG9lcyBzb3VuZCBsaWtlIHRoZSBzdWIgYXMgdXNlciBoYXMgbW9y ZSBjb25zZW5zdXMsIHRobyBiZWZvcmUgY2hhbmdpbmcgaXQgSSdkIHdhaXQgZm9yIHRoZSBwZW9w bGUgY3VycmVudGx5IGF0IElFVEYxMDQgdG8gaGF2ZSBtb3JlIHRpbWUgdG8gY29tbWVudCBhcyB3 ZWxsLg0KQ2xhcmlmaWNhdGlvbi4gSWYgdGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0byBhcHBseSB0 aGUgbG9naWMgImlmIHRoZXJlJ3MgYSBzdWIsIGl0J3MgYSB1c2VyIGZsb3ciLCB3ZSBoYXZlIHRv IGV4cGxpY2l0bHkgZGlzYWxsb3cgKE1VU1QgTk9UKSB0aGUgdXNlIG9mIHN1YiB3aGVuIHRoYXQn cyBub3QgdGhlIGNhc2UuIEFyZSBhbGwgT0sgd2l0aCBpdD8NCg0KRGF2ZSwgdGhlIHN1Z2dlc3Rp b24gb2YgaGF2aW5nIGV4cGxpY2l0IHR5cGluZyBmb3IgYXBwIG9ubHkgdnMgdXNlciBvbmx5IGlz IGludGVyZXN0aW5nISBGb3IgdGhlIHB1cnBvc2Ugb2YgcHV0dGluZyB0b2dldGhlciBhbiBpbnRl cm9wZXJhYmxlIHByb2ZpbGUsIHRobywgSSB3b3VsZCBzdWdnZXN0IHdlIHRhYmxlIGl0IGZvciB2 MSBpbiB0aGUgaW50ZXJlc3Qgb2YgZ2V0dGluZyB0byBzb21ldGhpbmcgZWFzeSB0byBhZG9wdCAo aGVuY2Ugd2l0aCBzbWFsbCBkZWx0YSB2cyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMpIGZhc3Rl ci4NCg0KT24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgMTo0MCBBTSBTdGVpbmFyIE5vZW0gPHN0ZWlu YXJAdWRlbHQubm88bWFpbHRvOnN0ZWluYXJAdWRlbHQubm8+PiB3cm90ZToNCkhpIFZpdHRvcmlv LCB3ZSAgKHRoZSBuYXRpb25hbCBmZWRlcmF0aW9uLWdhdGV3YXkgZm9yIHRoZSBoZWFsdGggc2Vy dmljZXMgaW4gbm9yd2F5IC0gIkhlbHNlSUQiKSAgdGhpbmsgaGlzIGlzIGEgcmVhbGx5IHZhbHVh YmxlIGluaXRpYXRpdmUhDQpXZSBhbHNvIGFncmVlIHdpdGggRG9taW5pY2sgY29uY2VybmluZyBk ZWZpbml0aW9uIG9mIHRoZSAic3ViIiBjbGFpbS4NCg0KPG12aD5TdGVpbmFyPC9tdmg+DQoNCnRp ci4gMjYuIG1hci4gMjAxOSBrbC4gMDc6MjUgc2tyZXYgRG9taW5pY2sgQmFpZXIgPGRiYWllckBs ZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PjoNCkZy b20gYW4gYWNjZXNzIHRva2VuIGNvbnN1bWVyIChha2EgQVBJKSBkZXZlbG9wZXIgcG9pbnQgb2Yg dmlldywgSSBwcmVmZXIgdGhpcyBsb2dpYw0KDQoiSWYgc3ViIGlzIHByZXNlbnQgLSBjbGllbnQg YWN0cyBvbiBiZWhhbGYgb2YgYSB1c2VyLCBpZiBub3QgLSBub3QuIg0KDQpBbnl0aGluZyBtb3Jl IGNvbXBsaWNhdGVkIGhhcyBhIHBvdGVudGlhbCBvZiBnb2luZyB3cm9uZy4NCg0KDQpPbiAyNi4g TWFyY2ggMjAxOSBhdCAwMTozNDo1MywgTm92IE1hdGFrZSAobWF0YWtlQGdtYWlsLmNvbTxtYWls dG86bWF0YWtlQGdtYWlsLmNvbT4pIHdyb3RlOg0KSGkgVml0dG9yaW8sDQoNClllYWgsIEnigJlt IGNvbmNlcm5pbmcgdXNlciAmIGNsaWVudCBpZHMgY29sbGlzaW9uLg0KSSBoYXZlbuKAmXQgc2Vl biBzdWNoIGltcGxlbWVudGF0aW9ucywgYnV0IHVzZXItc2VsZWN0IHVzZXJuYW1lIGFzIHN1Yiwg b3IgaW5jcmVtZW50YWwgaW50ZWdlciBhcyBzdWIgJiBjbGllbnRfaWQgd2lsbCBiZSBlYXNpbHkg Y29sbGlkZS4NCg0KSWYgeW91IGNhbiBlbmZvcmNlIGNvbGxpc2lvbiByZXNpc3RhbnQgSURzIGJl dHdlZW4gdXNlciAmIGNsaWVudCBpbnN0YW5jZXMsIGl04oCZbGwgd29ya3MgZmluZS4gSSBmZWVs IGl0cyBvdmVya2lsbCB0aG91Z2guDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWFyIDI2 LCAyMDE5LCBhdCA4OjUxLCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPG1h aWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCkhleSBOb3YsIERvbWluaWNrLCBIYW5z LQ0KdGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoYXQgd2FzIGFuIGFyZWEgSSB3YXMgZXhwZWN0 aW5nIHRvIGNhdXNlIG1vcmUgZGlzY3Vzc2lvbiwgYW5kIEkgYW0gZ2xhZCB3ZSBhcmUgaGF2aW5n IHRoaXMgb3Bwb3J0dW5pdHkgdG8gY2xhcmlmeS4NClRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRo ZSBkcmFmdCB0cmFjZXMgdGhlIGV0eW1vbG9neSBvZiBzdWIgdG8gT3BlbklEIENvbm5lY3QgY29y ZSwgaGVuY2UgRG9taW5pY2sgb2JzZXJ2YXRpb24gaXMgb24gcG9pbnQuIEhvd2V2ZXIgaW4gdGhl IGRlc2NyaXB0aW9uIEkgZXhwcmVzcyBzb21ldGhpbmcgaW4gbGluZSB3aXRoIDc1MTksIHdoaWNo IHdhcyBpbiBmYWN0IG15IGludGVudC4NCg0KVGhlIGlkZWEgd2FzIHRvIHByb3ZpZGUgYW4gaWRl bnRpZmllciBvZiB0aGUgY2FsbGluZyBzdWJqZWN0IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBiZSBw cmVzZW50IGluIGFsbCBjYXNlcy0gdGhpcyB3b3VsZCBhbGxvdyBhbiBTREsgZGV2ZWxvcGVyIHRv IHVzZSB0aGUgc2FtZSBjb2RlIGZvciB0aGluZ3MgbGlrZSBsb29rdXBzIGFuZCBtZW1iZXJzaGlw IGNoZWNrcyByZWdhcmRsZXNzIG9mIHRoZSBuYXR1cmUgb2YgdGhlIGNhbGxlciAodXNlciBpbiBh IGRlbGVnYXRlZCBjYXNlLCBhcHAgaW4gYXBwLW9ubHkgZ3JhbnRzKS4gVGhlIGluZm9ybWF0aW9u IHRvIGRpc2NyaW1pbmF0ZSBiZXR3ZWVuIHVzZXIgYW5kIGFwcCBjYWxsZXJzIGlzIGFsd2F5cyBh dmFpbGFibGUgaW4gdGhlIHRva2VuIChzYXksIHRoZSBjYWxsZXIgaXMgYSB1c2VyIGlmIHN1YiE9 Y2xpZW50X2lkLCB3aGVyZSBjbGllbnRfaWQgaXMgYWx3YXlzIGd1YXJhbnRlZWQgdG8gYmUgcHJl c2VudCBhcyB3ZWxsKSBoZW5jZSB0aGVyZSdzIG5vIGxvc3MgaW4gZXhwcmVzc2l2ZSBwb3dlciwg c2hvdWxkIHRoYXQgZGlmZmVyZW5jZSBiZSByZWxldmFudCBmb3IgdGhlIHJlc291cmNlIHNlcnZl ci4NCg0KRG9taW5pY2ssIEhhbnMtIEkgcHJvYmFibHkgbWlzc2VkIHRoZSBzZWN1cml0eSBpc3N1 ZSB5b3UgZ3V5cyBhcmUgdGhpbmtpbmcgb2YgaW4gdGhpcyBjYXNlLiBPZiBjb3Vyc2UsIGlmIHRo aXMgd291bGQgaW50cm9kdWNlIGEgcmlzayBJIGNvbXBsZXRlbHkgYWdyZWUgaXQgc2hvdWxkIGJl IGNoYW5nZWQtIEknZCBqdXN0IGxpa2UgdG8gdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIHByb2JsZW0u IENvdWxkIHlvdSBleHBhbmQgaXQgaW4gYSBzY2VuYXJpby91c2UgY2FzZSB0byBjbGFyaWZ5IHRo ZSByaXNrPw0KTm92LSBwbGF5aW5nIHRoaXMgYmFjazogaXMgdGhlIGNvbmNlcm4gdGhhdCBhIHVz ZXIgYW5kIGEgY2xpZW50IG1pZ2h0IGhhdmUgdGhlIHNhbWUgaWRlbnRpZmllciB3aXRoaW4gYW4g SURQPyBXaGVuIHVzaW5nIGNvbGxpc2lvbiByZXNpc3RhbnQgSURzLCBhcyBpdCBpcyB1c3VhbGx5 IHRoZSBjYXNlLCB0aGF0IHNlZW1zIHRvIGJlIGEgcmVtb3RlIHBvc3NpYmlsaXR5LSBkaWQgeW91 IHN0dW1ibGUgaW4gc3VjaCBzY2VuYXJpbyBpbiBwcm9kdWN0aW9uPw0KDQpUaGFua3MNClYuDQoN Cg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgNzo0NCBBTSBIYW5zIFphbmRiZWx0IDxoYW5zLnph bmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+PiB3 cm90ZToNCkkgYmVsaWV2ZSB0aGVyZSBhcmUgcGxlbnR5IG9mIE9BdXRoIDIuMCBvbmx5IHVzZSBj YXNlcyBvdXQgdGhlcmUuLi4gYnV0IG5ldmVydGhlbGVzcyBJIGFncmVlIHdpdGggdGhlIHBvdGVu dGlhbCBjb25mdXNpb24gYW5kIHRodXMgc2VjdXJpdHkgcHJvYmxlbXMgYXJpc2luZyBmcm9tIHRo YXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRoZSBzYW1lKS4NCg0K SGFucy4NCg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMzozOSBQTSBEb21pbmljayBCYWllciA8 ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNv bT4+IHdyb3RlOg0KWWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGluIGhpbmRzaWdodCBpdCB3YXMg YSBtaXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZvciBtdWx0aXBsZSBzZW1hbnRp Y3MuDQoNCkFsbCB0aGUg4oCcdGhpcyBpcyBPSURDIG5vdCBPQXV0aOKAnSBhcmd1bWVudHMgYXJl IG1ha2luZyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoZXkgbmVlZCB0byBiZSAtIGlu IG15IGV4cGVyaWVuY2UgYWxtb3N0IG5vLW9uZSAodGhhdCBJIGtub3cpIGRvZXMgT0lEQyBvbmx5 IC0gbm9yIE9BdXRoIG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUgaXQuDQoNCkluIHJlYWxpdHkg dGhpcyBsZWFkcyB0byBwb3RlbnRpYWwgc2VjdXJpdHkgcHJvYmxlbXMgLSB0aGlzIHNwZWMgaGFz IHRoZSBwb3RlbnRpYWwgdG8gcmVjdGlmeSB0aGUgc2l0dWF0aW9uLg0KDQpEb21pbmljaw0KDQpP biAyNS4gTWFyY2ggMjAxOSBhdCAxNDo1ODo1NiwgSGFucyBaYW5kYmVsdCAoaGFucy56YW5kYmVs dEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pikgd3JvdGU6 DQpXaXRob3V0IGFncmVlaW5nIG9yIGRpc2FncmVlaW5nOiBPSURDIGRvZXMgbm90IGFwcGx5IGhl cmUgc2luY2UgaXQgaXMgbm90IE9BdXRoIGFuZCBhbiBhY2Nlc3MgdG9rZW4gaXMgbm90IGFuIGlk X3Rva2VuLg0KVGhlIEpXVCBzcGVjIHNheXMgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTkjc2VjdGlvbi00LjEuMjoNCg0KIlRoZSAic3ViIiAoc3ViamVjdCkgY2xhaW0gaWRl bnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQgaXMgdGhlDQogICBzdWJqZWN0IG9mIHRoZSBKV1Qu ICBUaGUgY2xhaW1zIGluIGEgSldUIGFyZSBub3JtYWxseSBzdGF0ZW1lbnRzDQogICBhYm91dCB0 aGUgc3ViamVjdC4gIFRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0aGVyIGJlIHNjb3BlZCB0byBi ZQ0KICAgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBiZSBn bG9iYWxseSB1bmlxdWUuDQogICBUaGUgcHJvY2Vzc2luZyBvZiB0aGlzIGNsYWltIGlzIGdlbmVy YWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYyINCg0Kd2hpY2gga2luZCBvZiBzcGVsbHMgImNsaWVu dCIgaW4gY2FzZSBvZiB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IGJ1dCBJIGFsc28gZG8g d29ycnkgYWJvdXQgUmVzb3VyY2UgU2VydmVycyB0aGlua2luZy9hY3Rpbmcgb25seSBpbiB0ZXJt cyBvZiB1c2Vycw0KDQpIYW5zLg0KDQpPbiBNb24sIE1hciAyNSwgMjAxOSBhdCAyOjQxIFBNIERv bWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVh c3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoZSBzdWIgY2xhaW0gc2hvdWxkIGFsd2F5 cyByZWZlciB0byB0aGUgdXNlciAtIGFuZCBub3RoaW5nIGVsc2UuDQoNCk9JREMgc2F5czoNCg0K IlN1YmplY3QgLSBJZGVudGlmaWVyIGZvciB0aGUgRW5kLVVzZXIgYXQgdGhlIElzc3Vlci4iDQoN CmNsaWVudF9pZCBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSBjbGllbnRzLg0KDQpjaGVlcnMN CkRvbWluaWNrDQoNCg0KT24gMjUuLiBNYXJjaCAyMDE5IGF0IDA1OjEzOjAzLCBOb3YgTWF0YWtl IChtYXRha2VAZ21haWwuY29tPG1haWx0bzptYXRha2VAZ21haWwuY29tPikgd3JvdGU6DQpIaSBW aXR0b3JpbywNCg0KVGhhbmtzIGZvciB0aGUgZ29vZCBzdGFydGluZyBwb2ludCBvZiBzdGFuZGFy ZGl6aW5nIEpXVC1pemVkIEFULg0KDQpPbmUgZmVlZGJhY2suDQpUaGUg4oCcc3Vi4oCdIGNsYWlt IGNhbiBpbmNsdWRlIDIgdHlwZXMgb2YgaWRlbnRpZmllciwgZW5kLXVzZXIgYW5kIGNsaWVudCwg aW4gdGhpcyBzcGVjLg0KSXQgcmVxdWlyZXMgdGhvc2UgMiB0eXBlcyBvZiBpZGVudGlmaWVycyB0 byBiZSB1bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQIGNvbnRleHQuDQoNCkkgcHJlZmVyIG9t aXR0aW5nIOKAnHN1YuKAnSBjbGFpbSBpbiAyLWxlZ2dlZCBjb250ZXh0LCBzbyB0aGF0IG5vIHN1 Y2ggY29uc3RyYWludCBuZWVkZWQuDQoNCnRoYW5rcw0KDQpub3YNCg0KT24gTWFyIDI1LCAyMDE5 LCBhdCA4OjI5LCBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5j b21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkRlYXIgYWxsLA0KSSBqdXN0IHN1Ym1pdHRlZCBhIGRy YWZ0IGRlc2NyaWJpbmcgYSBKV1QgcHJvZmlsZSBmb3IgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMu IFlvdSBjYW4gZmluZCBpdCBpbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0Ly4NCkkgaGF2ZSBhIHNsb3QgdG8gZGlz Y3VzcyB0aGlzIHRvbW9ycm93IGF0IElFVEYgMTA0IChJJ2xsIGJlIHByZXNlbnRpbmcgcmVtb3Rl bHkpLiBJIGxvb2sgZm9yd2FyZCBmb3IgeW91ciBjb21tZW50cyENCg0KSGVyZSdzIGp1c3QgYSBi aXQgb2YgYmFja3N0b3J5LCBpbiBjYXNlIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBob3cgdGhpcyBk b2MgY2FtZSB0byBiZS4gVGhlIHRyYWplY3RvcnkgaXQgZm9sbG93ZWQgaXMgc29tZXdoYXQgdW51 c3VhbC4NCg0KICAqICAgRGVzcGl0ZSBPQXV0aDIgbm90IHJlcXVpcmluZyBhbnkgc3BlY2lmaWMg Zm9ybWF0IGZvciBBVHMsIHRocm91Z2ggdGhlIHllYXJzIEkgaGF2ZSBjb21lIGFjcm9zcyBtdWx0 aXBsZSBwcm9wcmlldGFyeSBzb2x1dGlvbiB1c2luZyBKV1QgZm9yIHRoZWlyIGFjY2VzcyB0b2tl bi4gVGhlIGludGVudCBhbmQgc2NlbmFyaW9zIGFkZHJlc3NlZCBieSB0aG9zZSBzb2x1dGlvbnMg YXJlIG1vc3RseSB0aGUgc2FtZSBhY3Jvc3MgdmVuZG9ycywgYnV0IHRoZSBzeW50YXggYW5kIGlu dGVycHJldGF0aW9ucyBpbiB0aGUgaW1wbGVtZW50YXRpb25zIGFyZSBkaWZmZXJlbnQgZW5vdWdo IHRvIHByZXZlbnQgZGV2ZWxvcGVycyBmcm9tIHJldXNpbmcgY29kZSBhbmQgc2tpbGxzIHdoZW4g bW92aW5nIGZyb20gcHJvZHVjdCB0byBwcm9kdWN0Lg0KICAqICAgSSBhc2tlZCBzZXZlcmFsIGlu ZGl2aWR1YWxzIGZyb20ga2V5IHByb2R1Y3RzIGFuZCBzZXJ2aWNlcyB0byBzaGFyZSB3aXRoIG1l IGNvbmNyZXRlIGV4YW1wbGVzIG9mIHRoZWlyIEpXVCBhY2Nlc3MgdG9rZW5zIChUSEFOSyBZT1Ug RG9taW5pY2sgQmFpZXIgKElkZW50aXR5U2VydmVyKSwgQnJpYW4gQ2FtcGJlbGwgKFBpbmdJZGVu dGl0eSksIERhbmllbCBEb2JhbGlhbiAoTWljcm9zb2Z0KSwgS2FybCBHdWlubmVzcyAoT2t0YSkg Zm9yIHRoZSB0b2tlbnMgYW5kIGV4cGxhbmF0aW9ucyEpLg0KSSBzdHVkaWVkIGFuZCBjb21wYXJl ZCBhbGwgdGhvc2UgaW5zdGFuY2VzLCBpZGVudGlmeWluZyBjb21tb25hbGl0aWVzIGFuZCBkaWZm ZXJlbmNlcy4NCiAgKiAgIEkgcHV0IHRvZ2V0aGVyIGEgcHJlc2VudGF0aW9uIHN1bW1hcml6aW5n IG15IGZpbmRpbmdzIGFuZCBzdWdnZXN0aW5nIGEgcm91Z2ggaW50ZXJvcGVyYWJsZSBwcm9maWxl IChzbGlkZXM6IGh0dHBzOi8vc2VjLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9vc3cy MDE5L3NsaWRlcy9iZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4PGh0dHBzOi8v c2VjLi51bmktc3R1dHRnYXJ0LmRlL19tZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9j Y2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMucHB0eD4gKSAtIGdvdCBlYXJseSBmZWVkYmFjayBm cm9tIEZpbGlwIFNrb2thbiBvbiBpdC4gVGh4IEZpbGlwIQ0KICAqICAgVGhlIHByZXNlbnRhdGlv biB3YXMgZm9sbG93ZWQgdXAgYnkgMS41IGhvdXJzIG9mIHVuY29uZmVyZW5jZSBkaXNjdXNzaW9u LCB3aGljaCB3YXMgaW5jcmVkaWJseSB2YWx1YWJsZSB0byBnZXQgdGlnaHQtbG9vcCBmZWVkYmFj ayBhbmQgaW5jb3Jwb3JhdGUgbmV3IGlkZWFzLiBKb2huIEJyYWRsZXksIEJyaWFuIENhbXBiZWxs IFZsYWRpbWlyIER6aHV2aW5vdiwgVG9yc3RlbiBMb2RkZXJzdGVkdCwgTmF0IFNha2ltdXJhLCBI YW5uZXMgVHNjaG9mZW5pZyB3ZXJlIGFsbCB0aGVyZSBhbmQgY29udHJpYnV0ZWQgZ2VuZXJvdXNs eSB0byB0aGUgZGlzY3Vzc2lvbi4gVGhhbmsgeW91ISEhDQpOb3RlOiBpZiB5b3Ugd2VyZSBhdCBP U1cyMDE5LCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb24gYW5kIGRpZG4ndCBnZXQgY3Jl ZGl0ZWQgaW4gdGhlIGRyYWZ0LCBteSBhcG9sb2dpZXM6IHBsZWFzZSBzZW5kIG1lIGEgbm90ZSBh bmQgSSdsbCBtYWtlIHRoaW5ncyByaWdodCBhdCB0aGUgbmV4dCB1cGRhdGUuDQogICogICBPbiBt eSBmbGlnaHQgYmFjayBJIGRpZCBteSBiZXN0IHRvIGluY29ycG9yYXRlIGFsbCB0aGUgaWRlYXMg YW5kIGZlZWRiYWNrIGluIGEgZHJhZnQsIHdoaWNoIHdpbGwgYmUgZGlzY3Vzc2VkIGF0IElFVEYx MDQgdG9tb3Jyb3cuIFJpZmFhdCwgSGFubmVzIGFuZCBhYm92ZSBhbGwgQnJpYW4gd2VyZSBhbGwg c3VwZXIgaGVscGZ1bCBpbiBuZWdvdGlhdGluZyB0aGUgbXlzdGVyaW91cyBzeW50YXggb2YgdGhl IFJGQyBmb3JtYXQgYW5kIHN1Ym1pc3Npb24gcHJvY2Vzcy4NCkkgd2FzIGJsb3duIGF3YXkgYnkg dGhlIGF2YWlsYWJpbGl0eSwgaW52b2x2ZW1lbnQgYW5kIHdpbGxpbmduZXNzIHRvIGludmVzdCB0 aW1lIHRvIGdldCB0aGluZ3MgcmlnaHQgdGhhdCBldmVyeW9uZSBkZW1vbnN0cmF0ZWQgaW4gdGhl IHByb2Nlc3MuIFRoaXMgaXMgYW4gYW1hemluZyBjb21tdW5pdHkuDQpWLg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KLS0N CmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9u ZS5ldT4NClptYXJ0Wm9uZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93d3cuem1hcnR6 b25lLmV1Lz4NCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMu emFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUuZXU8 aHR0cDovL3d3dy56bWFydHpvbmUuZXUvPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQoNCi0tDQpWZW5ubGlnIGhpbHNlbg0KDQpTdGVpbmFyIE5vZW0NClBhcnRuZXIg VWRlbHQgQVMNClN5c3RlbXV0dmlrbGVyDQoNCnwgc3RlaW5hckB1ZGVsdC5ubzxtYWlsdG86c3Rl aW5hckB1ZGVsdC4ubm8+IHwgaGVpQHVkZWx0Lm5vPG1haWx0bzpoZWlAdWRlbHQubm8+ICB8ICs0 NyA5NTUgMjEgNjIwIHwgd3d3LnVkZWx0Lm5vPGh0dHA6Ly93d3cudWRlbHQubm8vPiB8DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KLS0NCmhhbnMuemFuZGJlbHRA em1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9u ZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93d3cuem1hcnR6b25lLmV1Lz4NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBt YWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KaGFu cy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1 Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUu ZXUvPg0KDQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnph bmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1PGh0 dHA6Ly93d3cuem1hcnR6b25lLmV1Lz4NCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUu ZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3 dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXUvPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== --_000_DBBPR08MB4539FD7B2C7D27BFBF248E5EFA310DBBPR08MB4539eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAx MSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNh IE5ldWUiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMzQyNzU1NjIwMjUxMjUxMTUz MmdtYWlsLW0tNzIxMzk2MjMxNjEzNjk3MzE2MWdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21h aWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1t NTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2Fpcm1haWxvbiwg bGkuZ21haWwtbTM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tLTcyMTM5NjIzMTYxMzY5NzMxNjFn bWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdtYWls LW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4 NjE0OTI5NzYwOTgyNTM4NDNhaXJtYWlsb24sIGRpdi5nbWFpbC1tMzQyNzU1NjIwMjUxMjUxMTUz MmdtYWlsLW0tNzIxMzk2MjMxNjEzNjk3MzE2MWdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21h aWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1t NTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2Fpcm1haWxvbg0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tXy03MjEz OTYyMzE2MTM2OTczMTYxZ21haWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5 NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2 MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzYWlybWFpbG9uOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMzQyNzU1NjIwMjUxMjUxMTUzMmdt YWlsLW0tNzIxMzk2MjMxNjEzNjk3MzE2MWdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwt bS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5 ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYw MTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdhaXJtYWlsb24sIGxpLmdtYWls LW0zNDI3NTU2MjAyNTEyNTExNTMyZ21haWwtbS03MjEzOTYyMzE2MTM2OTczMTYxZ21haWwtbTQ2 MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3 OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2 MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEw NjgxN2Fpcm1haWxvbiwgZGl2LmdtYWlsLW0zNDI3NTU2MjAyNTEyNTExNTMyZ21haWwtbS03MjEz OTYyMzE2MTM2OTczMTYxZ21haWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5 NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2 MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4NzcxNjY5 NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2Fpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTpn bWFpbC1tXzM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tXy03MjEzOTYyMzE2MTM2OTczMTYxZ21h aWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1t LTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYx NDkyOTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2 OTUxNTEwNjgxN2Fpcm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAuZ21haWwtbTM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tLTcyMTM5NjIzMTYxMzY5NzMx NjFnbWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdt YWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1t LTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgw NzE3OTY5NTE1MTA2ODE3Z21haWwtbTg0NzU3MjgsIGxpLmdtYWlsLW0zNDI3NTU2MjAyNTEyNTEx NTMyZ21haWwtbS03MjEzOTYyMzE2MTM2OTczMTYxZ21haWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRn bWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWls LW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgy MDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04NDc1NzI4 LCBkaXYuZ21haWwtbTM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tLTcyMTM5NjIzMTYxMzY5NzMx NjFnbWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdt YWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1t LTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgw NzE3OTY5NTE1MTA2ODE3Z21haWwtbTg0NzU3MjgNCgl7bXNvLXN0eWxlLW5hbWU6ImdtYWlsLW1f MzQyNzU1NjIwMjUxMjUxMTUzMmdtYWlsLW1fLTcyMTM5NjIzMTYxMzY5NzMxNjFnbWFpbC1tNDYw ODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW0tMTcwNzc5 OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4NjE0OTI5NzYw OTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2 ODE3Z21haWwtbTg0NzU3MjgiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTAzNTczNTUxODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzM3NDU2NjA0O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Tm8sIGl0IGlzIGRlZmluaXRlbHkgbm90IHRvbyBsYXRlIGZvciB5 b3VyIGNvbW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9u IEJlaGFsZiBPZiA8L2I+TmVpbCBNYWRkZW48YnI+DQo8Yj5TZW50OjwvYj4gRGllbnN0YWcsIDcu IE1haSAyMDE5IDExOjE4PGJyPg0KPGI+VG86PC9iPiBJRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBPQXV0aCBzZWN1cml0 eSB0b3BpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXMgaXQgdG9vIGxhdGUgdG8gYWRkIHRoZSBvYnNlcnZhdGlvbiBiZWxvdyB0byB0aGUg T0F1dGggc2VjdXJpdHkgdG9waWNzIEJDUCBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+TmVpbCBNYWRkZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIj5uZWlsLm1hZGRlbkBmb3JnZXJv Y2suY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDsiPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9h dXRoLWFjY2Vzcy10b2tlbi1qd3QtMDA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EYXRlOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+NyBNYXkgMjAxOSBhdCAw OTozNzoyOSBCU1Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDsiPlRvOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Vml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1h aWx0bzpWaXR0b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyI+Vml0dG9yaW89NDBhdXRo MC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5IYW5zIFphbmRiZWx0ICZs dDs8YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUiPmhhbnMuemFuZGJl bHRAem1hcnR6b25lLmV1PC9hPiZndDssIEthcmwgTWNHdWlubmVzcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmttY2d1aW5uZXNzQG9rdGEuY29tIj5rbWNndWlubmVzc0Bva3RhLmNvbTwvYT4mZ3Q7LA0K IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdq dGJAdmU3anRiLmNvbTwvYT4mZ3Q7LCBJRVRGIG9hdXRoIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhc27igJl0IGF0IElJVyBzbyBJ IG1heSBiZSBtaXNzaW5nIHNvbWUgY29udGV4dC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGEgcG90ZW50aWFsIHNlY3VyaXR5IGlzc3VlIGlm IHRoZSBjbGllbnRfaWQgaXMgdXNlZCBhcyB0aGUg4oCcc3Vi4oCdIGZvciBhbiBBVCBvYnRhaW5l ZCB2aWEgY2xpZW50X2NyZWRlbnRpYWxzLiBJZiB0aGUgY2xpZW50IGNhbiByZWdpc3RlciBpdHNl bGYgd2l0aCBhIHNlbGYtY2hvc2VuIGNsaWVudF9pZCB0aGVuIGl0IG1heSBkZWxpYmVyYXRlbHkg Y2hvc2UgYSBjbGllbnRfaWQgdGhhdCBtYXRjaGVzDQogdGhlIHVzZXIgbmFtZSBvZiBhIHByaXZp bGVnZWQgdXNlci4gQW4gUlMgdGhhdCBqdXN0IGJsaW5kbHkgbG9va3MgYXQgdGhlIOKAnHN1YuKA nSBjbGFpbSBtYXkgdGhlbiBlcnJvbmVvdXNseSBsZXQgdGhlIGNsaWVudCBwZXJmb3JtIHByaXZp bGVnZWQgYWN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXMgdGhpcyB0aGUgY29udGV4dCBvZiB0aGUgZGlzY3Vzc2lvbj88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gdGhh dCB0aGVyZSBhcmUgYSBsb3Qgb2YgUlNlcyBpbiBleGlzdGVuY2UsIG1hbnkgb2Ygd2hpY2ggYXJl IHByb2JhYmx5IGp1c3QgbG9va2luZyBhdCB0aGUg4oCcc3Vi4oCdIGNsYWltIHRvIGlkZW50aWZ5 IHRoZSByZXNvdXJjZSBvd25lciwgSSB0aGluayB0aGUgb251cyBpcyBvbiB0aGUgQVMgdG8gZW5z dXJlIHRoYXQgbm8gc3VjaCBhbWJpZ3VpdHkgY2FuIGFyaXNlIGluIHRoZSBmaXJzdCBwbGFjZSBi eSBlbnN1cmluZw0KIHRoYXQgdGhlIHNwYWNlIG9mIOKAnHN1YuKAnSB2YWx1ZXMgZm9yIGNsaWVu dCBjcmVkZW50aWFscyBpcyBkaXNqb2ludCB3aXRoIHRoZSBzcGFjZSBmb3IgZ2VudWluZSB1c2Vy cyBvciBieSBkaXNhbGxvd2luZyB0aGUgY2xpZW50X2NyZWRlbnRpYWxzIGdyYW50IGFsdG9nZXRo ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgaXNzdWUgYWxyZWFkeSBhcmlzZXMgaW4gdG9rZW4gaW50cm9zcGVjdGlvbiB0aG91Z2gs IHNvIG1heWJlIG91Z2h0IHRvIGJlIG1lbnRpb25lZCBpbiB0aGUgT0F1dGggc2VjdXJpdHkgdG9w aWNzIGRyYWZ0IHJhdGhlciB0aGFuIHNwZWNpZmljIHRvIHRoZSBKV1QgQVQgZHJhZnQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBOZWls PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA2IE1heSAy MDE5LCBhdCAxODozMiwgVml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpWaXR0 b3Jpbz00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyI+Vml0dG9yaW89NDBhdXRoMC5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGFua3MgZm9yIHlvdXIgcGF0aWVuY2UgZHVyaW5nIHRoaXMgbW9udGggbG9u ZyBoaWF0dXMsIGFuZCB0aGFua3MgZm9yIHRoZSBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhc3Qgd2VlayBhdCBJSVcgSSBoYWQg dGhlIG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MgdGhpcyB3aXRoIG1hbnkgb2YgdGhlIHBlb3BsZSBv biB0aGUgbGlzdC4gSGVyZSdzIGEgc3VtbWFyeSBvZiB3aGVyZSB0aGUgZGlzY3Vzc2lvbiBsYW5k YWVkIG9uIHRoZSBzdWJqZWN0IG9mIHRoZSBzdWIgKHB1biBpbnRlbmRlZCkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSXQgc2VlbXMgdGhh dCBSRkMgNzUxOSBoYXMgcHJldHR5IGNsZWFyIGxhbmd1YWdlIG9uIHRoZSB1c2Ugb2Ygc3ViLSBJ IGRpZG4ndCBjaGVjayBpdCBiYWNrIHdoZW4gd2Ugc3RhcnRlZCB0aGUgZGlzY3Vzc2lvbi4gSSBk byBhZ3JlZSB3aXRoIHRoZSBwZW9wbGUgc2F5aW5nIHRoYXQgd2Ugc2hvdWxkbid0IHZpb2xhdGUg ZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMsIGhlbmNlIGl0IGxvb2tzIGxpa2Ugd2UgZG8NCiBuZWVk IHRvIGhhdmUgc3ViIGFsc28gaW4gdGhlIGNhc2UgaW4gd2hpY2ggd2UgaGF2ZSBhcHAtb25seSB0 b2tlbnMgY2FycnlpbmcgY2xhaW1zIGFib3V0IHRoZSBhcHAgaXRzZWxmLiBJIHVuZGVyc3RhbmQg dGhpcyB3aWxsIGNhdXNlIHNvbWUgaW1wbGVtZW50YXRpb24gdG8gYnJlYWssIGJ1dCB1bmZvcnR1 bmF0ZWx5IHRoYXQncyBpbnRyaW5zaWMgaW4gdGhlIHByb2Nlc3Mgb2YgY29taW5nIHVwIHdpdGgg YSBjb21tb24gYXBwcm9hY2ggYW5kIHN0YW5kYXJkcw0KIGNvbXBsaWFuY2UgaXMgcHJvYmFibHkg b25lIG9mIHRoZSBzdHJvbmdlc3QgcmVhc29ucyB0byB0b2xlcmF0ZSB0aGF0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaGF0IHNhaWQsIEkg YW0gc3Ryb25nbHkgY29tbWl0dGVkIHRvIHByZXNlcnZlIGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHku IE9uZSBvZiB0aGUgbWFpbiByZWFzb25zIHRoYXQgd2FzIGJyb3VnaHQgdXAgZm9yIGluY2x1ZGlu ZyBzdWIgb25seSBmb3IgdXNlciBiYXNlZCBBVHMgd2FzIHRvIHVzZSBpdCBhcyBoZXVyaXN0aWMg Zm9yIHRlbGxpbmcgdGhvc2UgdG9rZW5zIGFwYXJ0IGZyb20gYXBwLW9ubHkgb25lcy4NCiBUbyB0 aGF0IGVuZCwgPGI+PGk+S2FybCBNQ0d1aW5uZXNzPC9pPjwvYj48aT4gc3VnZ2VzdGVkIHRoYXQg d2UgaW5jbHVkZSBncmFudF90eXBlIGFzIGEgcmV0dXJuIGNsYWltLCB3aGljaCB0aGUgUlMgY291 bGQgdXNlIHRvIHRoZSBzYW1lIGVmZmVjdDwvaT4uIEkgZmluZCB0aGUgcHJvcG9zYWwgdmVyeSBj bGV2ZXIsIGFuZCB0aGUgcGVvcGxlIGF0IElJVyB0aG91Z2h0IHNvIGFzIHdlbGwuIFdoYXQgeW91 IHRoaW5rPzxicj4NCk5vdGUsIDxiPkpvaG4gQnJhZGxleTwvYj4gb2JzZXJ2ZWQgdGhhdCBpbiBz b21lIGNhc2VzIHRoaXMgbWlnaHQgbGVhZCB0byBhbWJpZ3VvdXMgcmVzdWx0cyBpZiBhbiBleHRl bnNpb24gZ3JhbnQgaXMgdXNlZCAoc2F5IGFuIGFzc2VydGlvbiBwcm9maWxlKSBidXQgdGhhdCBz ZWVtcyBsaWtlIGEgcmVsYXRpdmVseSBmcmluZ2Ugb2NjdXJyZW5jZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgNCwgMjAx OSBhdCAxOjExIFBNIEhhbnMgWmFuZGJlbHQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRi ZWx0QHptYXJ0em9uZS5ldSI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGFsc28gbWVhbnQgdG8gc2F5IHRoYXQgKG9mIGNvdXJzZSkgdGhlIEpXVCBz dGFuZGFyZCBkb2Vzbid0IHNheSB0aGF0IHRoZSBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgYWJvdXQg dGhlIGNsaWVudCBvciBhYm91dCB0aGUgcmVzb3VyY2Ugb3duZXIsIGhlbmNlIGJvdGggYXJlIHZh bGlkPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYW5zLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEFwciA0LCAyMDE5IGF0IDEwOjA5IFBNIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgZ2V0IHRoYXQgZXhpc3RpbmcgcHJh Y3RpY2UgaXMgbGlrZWx5IHRvIGJlIGFsbCBvdmVyIHRoZSBtYXAsIGJ1dCBpZiB3ZeKAmXJlIHRv IGNyZWF0ZSBhIEpXVCBhY2Nlc3MgdG9rZW4gc3RhbmRhcmQsIGl04oCZcyByZWFzb25hYmxlIHRv IHJlcXVpcmUNCiB0aGF0IHRoZSBjbGFpbXMgdXNhZ2UgY29tcGx5IHdpdGggdGhlIEpXVCBzdGFu ZGFyZHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+IEhhbnMgWmFuZGJlbHQgJmx0OzxhIGhyZWY9Im1haWx0bzpo YW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRA em1hcnR6b25lLmV1PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwg NCwgMjAxOSAxMjo1OSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBHZW9yZ2UgRmxl dGNoZXIgJmx0O2dmZmxldGNoPTxhIGhyZWY9Im1haWx0bzo0MGFvbC5jb21AZG1hcmMuLi5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OyBW aXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29t QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OzsgSUVURiBvYXV0aA0KIFdHICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tl bi1qd3QtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUg ZGVmaW5pdGlvbiBvZiBSRkMgNzUxOSBpcyBhY3R1YWxseSAmcXVvdDtwZXRpdGlvIHByaW5jaXBp aSZxdW90OyBhbmQgYSBsb3Qgb2YgZGVwbG95bWVudHMgcHV0IGNsYWltcyBhYm91dCB0aGUgUmVz b3VyY2UgT3duZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiAoYXMgYSBSZXNvdXJjZSBTZXJ2ZXINCiBp bXBsZW1lbnRlciBJJ3ZlIHN1ZmZlcmVkIGEgbG90IGZyb20gdGhpcyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IYW5zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgQXByIDQsIDIw MTkgYXQgOTo0OCBQTSBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPkkgYWdyZWUgd2l0aCBHZW9yZ2UgdGhhdCB0aGUgc3ViamVjdCBvZiBh IHRva2VuIG11c3QgYmUgdGhlIHByaW5jaXBhbCBvZiB0aGF0IHRva2VuLiZuYnNwOyBUaGF0IHdo YXQgdGhlIEpXVCDigJxzdWLigJ0gY2xhaW0gaXMgZm9yLiZuYnNwOyBJbmRlZWQsIHRoZQ0KIGZp cnN0IHNlbnRlbmNlIG9mIHRoZSDigJxzdWLigJ0gZGVmaW5pdGlvbiBhdCA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4y PC9hPiBpczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztiYWNrZ3JvdW5kOndoaXRlIj5UaGUg JnF1b3Q7c3ViJnF1b3Q7IChzdWJqZWN0KSBjbGFpbSBpZGVudGlmaWVzIHRoZSBwcmluY2lwYWwg dGhhdCBpcyB0aGUgc3ViamVjdCBvZiB0aGUgSldULjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDIwNjAiPklmIGFuIGFjY2VzcyB0b2tlbiB1 c2VzIOKAnHN1YuKAnSwgaXRzIHVzYWdlIG11c3QgY29tcGx5IHdpdGggdGhlIGRlZmluaXRpb24g ZnJvbSBSRkMgNzUxOS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IE9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVo YWxmIE9mIDwvYj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFw cmlsIDQsIDIwMTkgODo1MSBBTTxicj4NCjxiPlRvOjwvYj4gSGFucyBaYW5kYmVsdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+ aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVml0dG9y aW8gQmVydG9jY2kgJmx0O1ZpdHRvcmlvPTxhIGhyZWY9Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDs7IElFVEYgb2F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0w MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgdGhp cyB0aGUgbW9yZSBJIGxhbmQgaW4gdGhlICZxdW90O05vJnF1b3Q7IGNhbXAuPGJyPg0KPGJyPg0K VGhlIHN1YmplY3Qgb2YgYSB0b2tlbiBzaG91bGQgYmUgdGhlIHByaW5jaXBhbCBvZiB0aGF0IHRv a2VuLiBJdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIgdGhhdCBpcyBhIG1hY2hpbmUsIGEgdXNl ciwgb3IgYSBkZXZpY2UuIFRyeWluZyB0byBzZXBhcmF0ZSBvdXQgJnF1b3Q7aHVtYW5zJnF1b3Q7 IGFzIGEgc3BlY2lhbCBjbGFzcyB3aWxsIGp1c3QgbWFrZSB0aGluZ3MgbW9yZSBjb21wbGljYXRl ZC4gSWYgd2UgbmVlZCBhIGNsYWltIHRvIGlkZW50aWZ5IHRoZSBzdWJqZWN0DQogaXMgYSAmcXVv dDtodW1hbiZxdW90OyB0aGVuIHdoeSBub3QganVzdCBhZGQgdGhhdC4gVGhpcyBkb2Vzbid0IGJy ZWFrIGFueXRoaW5nIGFuZCBtYWtlcyBpdCBlYXN5IGZvciBwZW9wbGUgdG8gZGV0ZWN0IHRoaXMg Y2FzZSBpbiB0aG9zZSB1c2UgY2FzZXMgd2hlcmUgaXQncyByZXF1aXJlZC48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KR2VvcmdlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+T24gNC8zLzE5IDQ6NTYgUE0sIEhhbnMgWmFuZGJlbHQgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5JIHdpbGwgYXJndWUgdGhhdCBpbiBhIHdheSBzdWNoIGRlcGxveW1lbnRzIGFy ZSBhbHJlYWR5IGJyb2tlbiBlLmcuIGluIHRoZSB0eXBpY2FsIHVzZSBjYXNlIG9mIG9uYm9hcmRp bmcgY2xpZW50IGFjY291bnRzIGluIHRoZSBzYW1lIGRpcmVjdG9yeS9PVS9uYW1lc3BhY2UgYXMN CiB1c2VyIGFjY291bnRzIGFuZCB3ZSBkb24ndCBuZWVkIHRvIGNhdGVyIGZvciB0aGF0LiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGFucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEFwciAz LCAyMDE5IGF0IDEwOjQ4IFBNIEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdm ZmxldGNoQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nZmZsZXRjaEBhb2wuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgYWdyZWUgdGhhdCB0aGlzIHdpbGwgYnJlYWsgYSBsb3Qgb2YgZXhpc3Rp bmcgZmxvd3MuLi4gZXNwZWNpYWxseSB0aG9zZSB1c2luZyBhbnkgZm9ybSBvZiB0aGUgY2xpZW50 X2NyZWRlbnRpYWxzIGZsb3cuIEluDQogdGhhdCBzZW5zZSBJJ20gbm90IGNvbXBsZXRlbHkgb24g Ym9hcmQgeWV0IDopPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g My8yNi8xOSAxMjo1NiBQTSwgSGFucyBaYW5kYmVsdCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5ncmVhdCBzdW1tYXJ5ISB0aGlzIHdpbGwgaHVydCBxdWl0ZSBhIGZldyBl eGlzdGluZyBtMm0gZGVwbG95bWVudHMgYnV0IEkgZG8gbGlrZSB0aGUgcmlnaWRuZXNzIG9mIGl0 IGFsbDogaXQgaXMgdmVyeSBleHBsaWNpdCwgY2Fubm90IG1pc2ludGVycHJldGVkIGFuZCB0aHVz DQogcHJldmVudHMgZmFpbHVyZSAod2hpY2ggaXMgcmVhbGx5IHdoYXQgRG9taW5pY2sgaXMgYWZ0 ZXIpOyBJJ20gb24gYm9hcmQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkhhbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgNTo0OSBQTSBWaXR0b3JpbyBCZXJ0b2Nj aSAmbHQ7Vml0dG9yaW89PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW5rIHlvdSBTdGVpbmFyIGFuZCBldmVyeW9uZSBlbHNlIGZv ciB0aGUgY29tbWVudHMgb24gdGhpcyENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UbyBzdW1tYXJpemUgdGhl IHNpdHVhdGlvbiBzbyBmYXI6IERvbWluaWNrLCBTdGVpbmFyLCBSb2IsIERhdmlkLCBOb3YsIEJl cnRyYW5kIHJlY29tbWVuZCB1c2luZyBzdWIgb25seSBmb3IgdXNlcnMuIE1hcnRpbiB3b3VsZCBs aWtlIHRvIGhhdmUgdGhlIHN1YiBmb3IgYXBwDQogb25seSBmbG93cyBhcyB3ZWxsLiBIYW5zIGlz IG5ldXRyYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhdCBkb2VzIHNvdW5kIGxpa2UgdGhl IHN1YiBhcyB1c2VyIGhhcyBtb3JlIGNvbnNlbnN1cywgdGhvIGJlZm9yZSBjaGFuZ2luZyBpdCBJ J2Qgd2FpdCBmb3IgdGhlIHBlb3BsZSBjdXJyZW50bHkgYXQgSUVURjEwNCB0byBoYXZlIG1vcmUg dGltZSB0byBjb21tZW50IGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2xhcmlmaWNh dGlvbi4gSWYgdGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0byBhcHBseSB0aGUgbG9naWMgJnF1b3Q7 aWYgdGhlcmUncyBhIHN1YiwgaXQncyBhIHVzZXIgZmxvdyZxdW90Oywgd2UgaGF2ZSB0byBleHBs aWNpdGx5IGRpc2FsbG93IChNVVNUIE5PVCkgdGhlIHVzZSBvZiBzdWIgd2hlbg0KIHRoYXQncyBu b3QgdGhlIGNhc2UuIEFyZSBhbGwgT0sgd2l0aCBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5EYXZlLCB0aGUgc3VnZ2VzdGlvbiBvZiBoYXZp bmcgZXhwbGljaXQgdHlwaW5nIGZvciBhcHAgb25seSB2cyB1c2VyIG9ubHkgaXMgaW50ZXJlc3Rp bmchIEZvciB0aGUgcHVycG9zZSBvZiBwdXR0aW5nIHRvZ2V0aGVyIGFuIGludGVyb3BlcmFibGUg cHJvZmlsZSwgdGhvLCBJDQogd291bGQgc3VnZ2VzdCB3ZSB0YWJsZSBpdCBmb3IgdjEgaW4gdGhl IGludGVyZXN0IG9mIGdldHRpbmcgdG8gc29tZXRoaW5nIGVhc3kgdG8gYWRvcHQgKGhlbmNlIHdp dGggc21hbGwgZGVsdGEgdnMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zKSBmYXN0ZXIuJm5ic3A7 ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAxOjQwIEFNIFN0ZWluYXIgTm9lbSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWluYXJAdWRlbHQubm8iIHRhcmdldD0iX2JsYW5rIj5zdGVp bmFyQHVkZWx0Lm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBWaXR0b3Jpbywg d2UmbmJzcDsgKHRoZSBuYXRpb25hbCBmZWRlcmF0aW9uLWdhdGV3YXkgZm9yIHRoZSBoZWFsdGgg c2VydmljZXMgaW4gbm9yd2F5IC0gJnF1b3Q7SGVsc2VJRCZxdW90OykmbmJzcDsgdGhpbmsgaGlz IGlzIGEgcmVhbGx5IHZhbHVhYmxlIGluaXRpYXRpdmUhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgYWxz byBhZ3JlZSB3aXRoIERvbWluaWNrIGNvbmNlcm5pbmcgZGVmaW5pdGlvbiBvZiB0aGUgJnF1b3Q7 c3ViJnF1b3Q7IGNsYWltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZsdDttdmgmZ3Q7U3RlaW5hciZsdDsvbXZoJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPnRpci4gMjYuIG1hci4gMjAx OSBrbC4gMDc6MjUgc2tyZXYgRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFp ZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmls ZWdlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t IGFuIGFjY2VzcyB0b2tlbiBjb25zdW1lciAoYWthIEFQSSkgZGV2ZWxvcGVyIHBvaW50IG9mIHZp ZXcsIEkgcHJlZmVyIHRoaXMgbG9naWM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtJZiBzdWIgaXMg cHJlc2VudCAtIGNsaWVudCBhY3RzIG9uIGJlaGFsZiBvZiBhIHVzZXIsIGlmIG5vdCAtIG5vdC4m cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbnl0aGluZyBtb3JlIGNvbXBsaWNhdGVkIGhhcyBhIHBv dGVudGlhbCBvZiBnb2luZyB3cm9uZy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0zNDI3NTU2 MjAyNTEyNTExNTMyZ21haWwtbS03MjEzOTYyMzE2MTM2OTczMTYxZ21haWwtbTQ2MDg5NjIzNjk4 Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1 Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQz YWlybWFpbG9uIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAyNi4gTWFyY2ggMjAxOSBhdCAwMToz NDo1MywgTm92IE1hdGFrZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYXRha2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgVml0dG9yaW8sPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+WWVhaCwgSeKAmW0gY29uY2VybmluZyB1c2Vy ICZhbXA7IGNsaWVudCBpZHMgY29sbGlzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2 ZW7igJl0IHNlZW4gc3VjaCBpbXBsZW1lbnRhdGlvbnMsIGJ1dCB1c2VyLXNlbGVjdCB1c2VybmFt ZSBhcyBzdWIsIG9yIGluY3JlbWVudGFsIGludGVnZXIgYXMgc3ViICZhbXA7IGNsaWVudF9pZCB3 aWxsIGJlIGVhc2lseSBjb2xsaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdSBjYW4gZW5mb3JjZSBjb2xsaXNpb24gcmVzaXN0YW50 IElEcyBiZXR3ZWVuIHVzZXIgJmFtcDsgY2xpZW50IGluc3RhbmNlcywgaXTigJlsbCB3b3JrcyBm aW5lLiBJIGZlZWwgaXRzIG92ZXJraWxsIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0iZ21haWwtbV8zNDI3 NTU2MjAyNTEyNTExNTMyZ21haWwtbV8tNzIxMzk2MjMxNjEzNjk3MzE2MWdtYWlsLW1fNDYwODk2 MjM2OTg3Nzk2NzIwNGdtYWlsLW1fLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tXy0xNzA3Nzk5 MzMyODgwNTc3NjJnbWFpbC1tXzUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tXy0xODYxNDkyOTc2 MDk4MjUzODQzQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpPbiBNYXIgMjYsIDIwMTksIGF0IDg6NTEsIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVm PSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW9AYXV0 aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGV5 IE5vdiwgRG9taW5pY2ssIEhhbnMtDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhhbmtzIGZvciB0aGUgY29t bWVudHMuIFRoYXQgd2FzIGFuIGFyZWEgSSB3YXMgZXhwZWN0aW5nIHRvIGNhdXNlIG1vcmUgZGlz Y3Vzc2lvbiwgYW5kIEkgYW0gZ2xhZCB3ZSBhcmUgaGF2aW5nIHRoaXMgb3Bwb3J0dW5pdHkgdG8g Y2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgY3VycmVudCBsYW5ndWFnZSBpbiB0 aGUgZHJhZnQgdHJhY2VzIHRoZSBldHltb2xvZ3kgb2Ygc3ViIHRvIE9wZW5JRCBDb25uZWN0IGNv cmUsIGhlbmNlIERvbWluaWNrIG9ic2VydmF0aW9uIGlzIG9uIHBvaW50LiBIb3dldmVyIGluIHRo ZSBkZXNjcmlwdGlvbiBJIGV4cHJlc3MNCiBzb21ldGhpbmcgaW4gbGluZSB3aXRoIDc1MTksIHdo aWNoIHdhcyBpbiBmYWN0IG15IGludGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgaWRlYSB3YXMgdG8gcHJvdmlkZSBhbiBpZGVudGlm aWVyIG9mIHRoZSBjYWxsaW5nIHN1YmplY3QgdGhhdCBpcyBndWFyYW50ZWVkIHRvIGJlIHByZXNl bnQgaW4gYWxsIGNhc2VzLSB0aGlzIHdvdWxkIGFsbG93IGFuIFNESyBkZXZlbG9wZXIgdG8gdXNl IHRoZSBzYW1lDQogY29kZSBmb3IgdGhpbmdzIGxpa2UgbG9va3VwcyBhbmQgbWVtYmVyc2hpcCBj aGVja3MgcmVnYXJkbGVzcyBvZiB0aGUgbmF0dXJlIG9mIHRoZSBjYWxsZXIgKHVzZXIgaW4gYSBk ZWxlZ2F0ZWQgY2FzZSwgYXBwIGluIGFwcC1vbmx5IGdyYW50cykuIFRoZSBpbmZvcm1hdGlvbiB0 byBkaXNjcmltaW5hdGUgYmV0d2VlbiB1c2VyIGFuZCBhcHAgY2FsbGVycyBpcyBhbHdheXMgYXZh aWxhYmxlIGluIHRoZSB0b2tlbiAoc2F5LCB0aGUgY2FsbGVyIGlzDQogYSB1c2VyIGlmIHN1YiE9 Y2xpZW50X2lkLCB3aGVyZSBjbGllbnRfaWQgaXMgYWx3YXlzIGd1YXJhbnRlZWQgdG8gYmUgcHJl c2VudCBhcyB3ZWxsKSBoZW5jZSB0aGVyZSdzIG5vIGxvc3MgaW4gZXhwcmVzc2l2ZSBwb3dlciwg c2hvdWxkIHRoYXQgZGlmZmVyZW5jZSBiZSByZWxldmFudCBmb3IgdGhlIHJlc291cmNlIHNlcnZl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5E b21pbmljaywgSGFucy0gSSBwcm9iYWJseSBtaXNzZWQgdGhlIHNlY3VyaXR5IGlzc3VlIHlvdSBn dXlzIGFyZSB0aGlua2luZyBvZiBpbiB0aGlzIGNhc2UuIE9mIGNvdXJzZSwgaWYgdGhpcyB3b3Vs ZCBpbnRyb2R1Y2UgYSByaXNrIEkgY29tcGxldGVseSBhZ3JlZSBpdCBzaG91bGQNCiBiZSBjaGFu Z2VkLSBJJ2QganVzdCBsaWtlIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBwcm9ibGVtLiBDb3Vs ZCB5b3UgZXhwYW5kIGl0IGluIGEgc2NlbmFyaW8vdXNlIGNhc2UgdG8gY2xhcmlmeSB0aGUgcmlz az88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3YtIHBsYXlpbmcgdGhpcyBiYWNrOiBpcyB0aGUg Y29uY2VybiB0aGF0IGEgdXNlciBhbmQgYSBjbGllbnQgbWlnaHQgaGF2ZSB0aGUgc2FtZSBpZGVu dGlmaWVyIHdpdGhpbiBhbiBJRFA/IFdoZW4gdXNpbmcgY29sbGlzaW9uIHJlc2lzdGFudCBJRHMs IGFzIGl0IGlzIHVzdWFsbHkNCiB0aGUgY2FzZSwgdGhhdCBzZWVtcyB0byBiZSBhIHJlbW90ZSBw b3NzaWJpbGl0eS0gZGlkIHlvdSBzdHVtYmxlIGluIHN1Y2ggc2NlbmFyaW8gaW4gcHJvZHVjdGlv bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5WLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDc6NDQgQU0gSGFucyBaYW5kYmVsdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFu ayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGJlbGlldmUgdGhlcmUgYXJlIHBsZW50eSBvZiBPQXV0aCAyLjAgb25seSB1 c2UgY2FzZXMgb3V0IHRoZXJlLi4uIGJ1dCBuZXZlcnRoZWxlc3MgSSBhZ3JlZSB3aXRoIHRoZSBw b3RlbnRpYWwgY29uZnVzaW9uIGFuZCB0aHVzIHNlY3VyaXR5IHByb2JsZW1zIGFyaXNpbmcgZnJv bQ0KIHRoYXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRoZSBzYW1l KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGFucy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24s IE1hciAyNSwgMjAxOSBhdCAzOjM5IFBNIERvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWls dG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBsZWFz dHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+WWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGluIGhpbmRzaWdodCBpdCB3YXMgYSBt aXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZvciBtdWx0aXBsZSBzZW1hbnRpY3Mu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QWxsIHRoZSDigJx0aGlzIGlzIE9JREMgbm90IE9BdXRo4oCdIGFy Z3VtZW50cyBhcmUgbWFraW5nIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhleSBuZWVk IHRvIGJlDQogLSBpbiBteSBleHBlcmllbmNlIGFsbW9zdCBuby1vbmUgKHRoYXQgSSBrbm93KSBk b2VzIE9JREMgb25seSAtIG5vciBPQXV0aCBvbmx5LiBUaGV5IGFsd2F5cyBjb21iaW5lIGl0Ljwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkluIHJlYWxpdHkgdGhpcyBsZWFkcyB0byBwb3RlbnRpYWwgc2VjdXJp dHkgcHJvYmxlbXMgLSB0aGlzIHNwZWMgaGFzIHRoZSBwb3RlbnRpYWwgdG8gcmVjdGlmeSB0aGUN CiBzaXR1YXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRvbWluaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0zNDI3NTU2MjAyNTEyNTExNTMyZ21haWwtbS03MjEzOTYyMzE2MTM2OTcz MTYxZ21haWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTln bWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwt bS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4 MDcxNzk2OTUxNTEwNjgxN2Fpcm1haWxvbiI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+T24gMjUuIE1h cmNoIDIwMTkgYXQgMTQ6NTg6NTYsIEhhbnMgWmFuZGJlbHQgKDxhIGhyZWY9Im1haWx0bzpoYW5z LnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1h cnR6b25lLmV1PC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5XaXRob3V0IGFncmVlaW5nIG9yIGRpc2FncmVlaW5nOiBPSURDIGRv ZXMgbm90IGFwcGx5IGhlcmUgc2luY2UgaXQgaXMgbm90IE9BdXRoIGFuZCBhbiBhY2Nlc3MgdG9r ZW4gaXMgbm90IGFuIGlkX3Rva2VuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBKV1Qgc3Bl YyBzYXlzIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNz ZWN0aW9uLTQuMS4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTkjc2VjdGlvbi00LjEuMjwvYT46PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZxdW90O1RoZSAmcXVvdDtzdWImcXVvdDsgKHN1YmplY3QpIGNsYWlt IGlkZW50aWZpZXMgdGhlIHByaW5jaXBhbCB0aGF0IGlzIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDtzdWJqZWN0IG9mIHRoZSBKV1QuJm5ic3A7IFRoZSBjbGFpbXMgaW4g YSBKV1QgYXJlIG5vcm1hbGx5IHN0YXRlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7YWJvdXQgdGhlIHN1YmplY3QuJm5ic3A7IFRoZSBzdWJqZWN0IHZhbHVlIE1VU1Qg ZWl0aGVyIGJlIHNjb3BlZCB0byBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJz cDtsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyIG9yIGJlIGdsb2Jh bGx5IHVuaXF1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7VGhlIHByb2Nl c3Npbmcgb2YgdGhpcyBjbGFpbSBpcyBnZW5lcmFsbHkgYXBwbGljYXRpb24gc3BlY2lmaWMmcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj53 aGljaCBraW5kIG9mIHNwZWxscyAmcXVvdDtjbGllbnQmcXVvdDsgaW4gY2FzZSBvZiB0aGUgY2xp ZW50IGNyZWRlbnRpYWxzIGdyYW50IGJ1dCBJIGFsc28gZG8gd29ycnkgYWJvdXQgUmVzb3VyY2Ug U2VydmVycyB0aGlua2luZy9hY3Rpbmcgb25seSBpbiB0ZXJtcyBvZiB1c2VyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDI6NDEgUE0gRG9taW5pY2sgQmFpZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5JTUhPIHRoZSBzdWIgY2xhaW0gc2hvdWxkIGFsd2F5cyByZWZl ciB0byB0aGUgdXNlciAtIGFuZCBub3RoaW5nIGVsc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0lEQyBz YXlzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj5TdWJqZWN0IC0gSWRlbnRpZmllcg0KIGZvciB0aGUgRW5kLVVzZXIgYXQgdGhlIElz c3Vlci4mcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPmNsaWVudF9pZCBzaG91bGQgYmUgdXNl ZCB0byBpZGVudGlmeSBjbGllbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPmNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkRvbWluaWNr PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i Z21haWwtbTM0Mjc1NTYyMDI1MTI1MTE1MzJnbWFpbC1tLTcyMTM5NjIzMTYxMzY5NzMxNjFnbWFp bC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW0t MTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4NjE0 OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5 NTE1MTA2ODE3Z21haWwtbTg0NzU3MjgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPk9uIDI1Li4gTWFy Y2ggMjAxOSBhdCAwNToxMzowMywgTm92IE1hdGFrZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXRha2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIFZpdHRvcmlvLA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBmb3IgdGhlIGdvb2Qgc3RhcnRpbmcgcG9p bnQgb2Ygc3RhbmRhcmRpemluZyBKV1QtaXplZCBBVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgZmVlZGJhY2suPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhlIOKAnHN1YuKAnSBjbGFpbSBjYW4gaW5jbHVkZSAyIHR5cGVzIG9mIGlkZW50 aWZpZXIsIGVuZC11c2VyIGFuZCBjbGllbnQsIGluIHRoaXMgc3BlYy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5JdCByZXF1aXJlcyB0aG9zZSAyIHR5cGVzIG9mIGlkZW50aWZpZXJzIHRvIGJlIHVu aXF1ZSBlYWNoIG90aGVyIGluIHRoZSBJZFAgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHByZWZlciBvbWl0dGluZyDigJxzdWLi gJ0gY2xhaW0gaW4gMi1sZWdnZWQgY29udGV4dCwgc28gdGhhdCBubyBzdWNoIGNvbnN0cmFpbnQg bmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPnRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPm5vdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5PbiBNYXIgMjUsIDIwMTksIGF0IDg6MjksIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVm PSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj52aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBqdXN0IHN1 Ym1pdHRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgYSBKV1QgcHJvZmlsZSBmb3IgT0F1dGggMi4wIGFj Y2VzcyB0b2tlbnMuIFlvdSBjYW4gZmluZCBpdCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1q d3QvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC88L2E+LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgaGF2ZSBhIHNsb3QgdG8gZGlzY3VzcyB0aGlzIHRvbW9ycm93IGF0IElFVEYgMTA0 IChJJ2xsIGJlIHByZXNlbnRpbmcgcmVtb3RlbHkpLiBJIGxvb2sgZm9yd2FyZCBmb3IgeW91ciBj b21tZW50cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5IZXJlJ3MganVzdCBhIGJpdCBvZiBiYWNrc3RvcnksIGluIGNhc2UgeW91IGFyZSBpbnRl cmVzdGVkIGluIGhvdyB0aGlzIGRvYyBjYW1lIHRvIGJlLiBUaGUgdHJhamVjdG9yeSBpdCBmb2xs b3dlZCBpcyBzb21ld2hhdCB1bnVzdWFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkRlc3BpdGUgT0F1dGgyIG5vdCBy ZXF1aXJpbmcgYW55IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0aHJvdWdoIHRoZSB5ZWFycyBJ IGhhdmUgY29tZSBhY3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkgc29sdXRpb24gdXNpbmcgSldU IGZvciB0aGVpciBhY2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5kIHNjZW5hcmlvcyBhZGRyZXNz ZWQgYnkgdGhvc2Ugc29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNhbWUgYWNyb3NzDQogdmVuZG9y cywgYnV0IHRoZSBzeW50YXggYW5kIGludGVycHJldGF0aW9ucyBpbiB0aGUgaW1wbGVtZW50YXRp b25zIGFyZSBkaWZmZXJlbnQgZW5vdWdoIHRvIHByZXZlbnQgZGV2ZWxvcGVycyBmcm9tIHJldXNp bmcgY29kZSBhbmQgc2tpbGxzIHdoZW4gbW92aW5nIGZyb20gcHJvZHVjdCB0byBwcm9kdWN0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSBhc2tlZCBzZXZlcmFsIGluZGl2aWR1 YWxzIGZyb20ga2V5IHByb2R1Y3RzIGFuZCBzZXJ2aWNlcyB0byBzaGFyZSB3aXRoIG1lIGNvbmNy ZXRlIGV4YW1wbGVzIG9mIHRoZWlyIEpXVCBhY2Nlc3MgdG9rZW5zIChUSEFOSyBZT1UgRG9taW5p Y2sgQmFpZXIgKElkZW50aXR5U2VydmVyKSwmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5CcmlhbiBDYW1wYmVsbCAoUGluZ0lkZW50aXR5KSwN CiBEYW5pZWwgRG9iYWxpYW4gKE1pY3Jvc29mdCksIEthcmwgR3Vpbm5lc3MgKE9rdGEpIGZvciB0 aGUgdG9rZW5zIGFuZCBleHBsYW5hdGlvbnMhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4pLjxi cj4NCkkgc3R1ZGllZCBhbmQgY29tcGFyZWQgYWxsIHRob3NlIGluc3RhbmNlcywgaWRlbnRpZnlp bmcgY29tbW9uYWxpdGllcyBhbmQgZGlmZmVyZW5jZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIGxhbmc9IkVOLVVTIj5JIHB1dCB0b2dldGhlciBhIHByZXNlbnRhdGlvbiBzdW1tYXJpemlu ZyBteSBmaW5kaW5ncyBhbmQgc3VnZ2VzdGluZyBhIHJvdWdoIGludGVyb3BlcmFibGUgcHJvZmls ZSAoc2xpZGVzOg0KPGEgaHJlZj0iaHR0cHM6Ly9zZWMuLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlh L2V2ZW50cy9vc3cyMDE5L3NsaWRlcy9iZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5w cHR4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3NlYy51bmktc3R1dHRnYXJ0LmRlL19tZWRp YS9ldmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMu cHB0eDwvYT4gKSAtIGdvdCBlYXJseSBmZWVkYmFjayBmcm9tIEZpbGlwIFNrb2thbiBvbiBpdC4g VGh4IEZpbGlwITxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHByZXNlbnRh dGlvbiB3YXMgZm9sbG93ZWQgdXAgYnkgMS41IGhvdXJzIG9mIHVuY29uZmVyZW5jZSBkaXNjdXNz aW9uLCB3aGljaCB3YXMgaW5jcmVkaWJseSB2YWx1YWJsZSB0byBnZXQgdGlnaHQtbG9vcCBmZWVk YmFjayBhbmQgaW5jb3Jwb3JhdGUgbmV3IGlkZWFzLiBKb2huIEJyYWRsZXksIEJyaWFuIENhbXBi ZWxsIFZsYWRpbWlyIER6aHV2aW5vdiwgVG9yc3RlbiBMb2RkZXJzdGVkdCw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDtOYXQNCiBTYWtpbXVy YSwgSGFubmVzIFRzY2hvZmVuaWc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwO3dlcmUg YWxsIHRoZXJlIGFuZCBjb250cmlidXRlZCBnZW5lcm91c2x5IHRvIHRoZSBkaXNjdXNzaW9uLiBU aGFuayB5b3UhISE8YnI+DQpOb3RlOiBpZiB5b3Ugd2VyZSBhdCBPU1cyMDE5LCBwYXJ0aWNpcGF0 ZWQgaW4gdGhlIGRpc2N1c3Npb24gYW5kIGRpZG4ndCBnZXQgY3JlZGl0ZWQgaW4gdGhlIGRyYWZ0 LCBteSBhcG9sb2dpZXM6IHBsZWFzZSBzZW5kIG1lIGEgbm90ZSBhbmQgSSdsbCBtYWtlIHRoaW5n cyByaWdodCBhdCB0aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBteSBmbGlnaHQgYmFjayBJIGRpZCBteSBiZXN0IHRvIGluY29ycG9yYXRlIGFsbCB0 aGUgaWRlYXMgYW5kIGZlZWRiYWNrIGluIGEgZHJhZnQsIHdoaWNoIHdpbGwgYmUgZGlzY3Vzc2Vk IGF0IElFVEYxMDQgdG9tb3Jyb3cuIFJpZmFhdCwgSGFubmVzIGFuZCBhYm92ZSBhbGwgQnJpYW4g d2VyZSBhbGwgc3VwZXIgaGVscGZ1bCBpbiBuZWdvdGlhdGluZyB0aGUgbXlzdGVyaW91cyBzeW50 YXggb2YgdGhlIFJGQyBmb3JtYXQNCiBhbmQgc3VibWlzc2lvbiBwcm9jZXNzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5JIHdhcyBibG93biBhd2F5IGJ5IHRoZSBhdmFpbGFiaWxpdHksIGludm9sdmVt ZW50IGFuZCB3aWxsaW5nbmVzcyB0byBpbnZlc3QgdGltZSB0byBnZXQgdGhpbmdzIHJpZ2h0IHRo YXQgZXZlcnlvbmUgZGVtb25zdHJhdGVkIGluIHRoZSBwcm9jZXNzLiBUaGlzIGlzIGFuIGFtYXpp bmcNCiBjb21tdW5pdHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5WLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJtYWlsdG86aGFucy56YW5k YmVsdEB6bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9u ZS5ldTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5abWFydFpvbmUgSUFNIC0NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuem1hcnR6b25lLmV1LyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy56bWFydHpvbmUuZXU8L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9i bGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1h cnRab25lIElBTSAtDQo8YSBocmVmPSJodHRwOi8vd3d3LnptYXJ0em9uZS5ldS8iIHRhcmdldD0i X2JsYW5rIj53d3cuem1hcnR6b25lLmV1PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5WZW5ubGlnIGhpbHNlbjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5TdGVpbmFyIE5vZW08L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5QYXJ0 bmVyIFVkZWx0IEFTPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3lzdGVtdXR2aWtsZXI8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMjIyMjIyIj58Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnN0ZWluYXJAdWRlbHQu Lm5vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjI7YmFja2dyb3Vu ZDojRkZGRkNDIj5zdGVpbmFyQHVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDt8Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOmhlaUB1ZGVsdC5ubyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMTE1NUNDIj5oZWlAdWRlbHQubm88L3NwYW4+PC9hPiZuYnNwOyZuYnNwO3wmbmJzcDsmIzQz OzQ3DQogOTU1IDIxIDYyMCZuYnNwO3wmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LnVkZWx0Lm5v LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDIj53d3cudWRlbHQu bm88L3NwYW4+PC9hPiZuYnNwO3wmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEg aHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+ aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1hcnRab25l IElBTSAtDQo8YSBocmVmPSJodHRwOi8vd3d3LnptYXJ0em9uZS5ldS8iIHRhcmdldD0iX2JsYW5r Ij53d3cuem1hcnR6b25lLmV1PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRA em1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1hcnRab25lIElBTSAtDQo8YSBocmVmPSJodHRwOi8vd3d3 LnptYXJ0em9uZS5ldS8iIHRhcmdldD0iX2JsYW5rIj53d3cuem1hcnR6b25lLmV1PC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5r Ij5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5abWFydFpv bmUgSUFNIC0NCjxhIGhyZWY9Imh0dHA6Ly93d3cuem1hcnR6b25lLmV1LyIgdGFyZ2V0PSJfYmxh bmsiPnd3dy56bWFydHpvbmUuZXU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpv bmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1hcnRab25lIElBTSAtIDxhIGhyZWY9Imh0 dHA6Ly93d3cuem1hcnR6b25lLmV1LyIgdGFyZ2V0PSJfYmxhbmsiPg0Kd3d3LnptYXJ0em9uZS5l dTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DBBPR08MB4539FD7B2C7D27BFBF248E5EFA310DBBPR08MB4539eurp_-- From nobody Tue May 7 02: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 6B7AF1200A2 for ; Tue, 7 May 2019 02:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fPNCo1sIkM0 for ; Tue, 7 May 2019 02:46:50 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 2AFB912000E for ; Tue, 7 May 2019 02:46:49 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id a12so11256798wrn.4 for ; Tue, 07 May 2019 02:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=774TTDUfxv+4yLQhpUSsqV9bullGYe+1wOXStbrYeI0=; b=fF6AMm+YHJbeSg0UBIg6RIDnZGRBLx/aZwK0gw9580TS6bhIlJkifk9+mltRRFSy3K bpCY2tUkDnyExdNrXjYgU6wYtuAA1jvIy2s/d+zmb8VajHVCg9A4rgApJNYkTFSRTE4S TsxGZiD15dUl8eo9wT703gpetGD3vhVGxwY1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=774TTDUfxv+4yLQhpUSsqV9bullGYe+1wOXStbrYeI0=; b=AMlrP8bd+ePjZGFWImHazu0WGJzmZF0gu2cYWasVAI0/3ZzszK4weIoYqGnT09p9JN MAv378pw6+FZ88MdoTRH1KeUfY8Brex90ODJMgR6hzov20sr5LqMfbeNCcO4H+k8Vstw XUm+cEmQB3HDAigbl7DM25yAbHEDOQzURDy0HcgqsccHllEq4qEGtDQozKap3BqmuYsA dV0gW64LiCKZ4a7O6woavEo1d21jVRJ9Ucrt2uBzohNrXRYsMuurkIq/yQSZWyOApiTf 5OXH0tleIe/ZxMGhm8mvxXiEAG1b0+hBKR+VezsKlKIm89cbrK5JUJDTBCuAh1YrJinO rPNQ== X-Gm-Message-State: APjAAAWS2PZmRv/DsvyuHlSbdQiRMLccZsV2o576JzQXxgHVM1j6VSOo D2za3R/8H6nzqpPZEEZyX3iIO/SZuaZM/tZ4HHKT5G7zAmb+1pvMHqojKw49MItx65lS0YzlOXh rTKt5VIR5QIujmMsZVFQeSWNdVJpNRPlpIQu/8lkQGdRMrbt+zsUNhSkd7JSCamo= X-Google-Smtp-Source: APXvYqxDv4Qj36qedDWCmIARzTTxH5lEjGOC6344v3nCTz/1b4K4HBfKM3kZZh4Woe2Xtj0aWccuPQ== X-Received: by 2002:adf:b646:: with SMTP id i6mr2645867wre.12.1557222406833; Tue, 07 May 2019 02:46:46 -0700 (PDT) Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id d16sm9351188wrs.68.2019.05.07.02.46.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 02:46:46 -0700 (PDT) From: Neil Madden Content-Type: multipart/alternative; boundary="Apple-Mail=_D84076C4-1D1F-42F1-B423-C494AC3BF45E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 10:46:43 +0100 References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> To: IETF oauth WG In-Reply-To: Message-Id: <771DAF49-BF74-4A78-A65F-78B5E94FE081@forgerock.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [OAUTH-WG] Off Topic: oauth-bounces 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, 07 May 2019 09:46:56 -0000 --Apple-Mail=_D84076C4-1D1F-42F1-B423-C494AC3BF45E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I notice that a few of my emails to the OAuth WG list have come through = with the =46rom field from =E2=80=9Coauth-bounces=E2=80=9D: From: OAuth On Behalf Of Neil Madden Is this normal? I checked my subscription status on mailman and I=E2=80=99= m posting from the same email address that I subscribed from. Cheers, Neil > On 7 May 2019, at 10:25, Hannes Tschofenig = wrote: >=20 > No, it is definitely not too late for your comment > =20 > From: OAuth On Behalf Of Neil Madden > Sent: Dienstag, 7. Mai 2019 11:18 > To: IETF oauth WG > Subject: [OAUTH-WG] OAuth security topics > =20 > Is it too late to add the observation below to the OAuth security = topics BCP draft? > =20 >=20 >=20 > Begin forwarded message: > =20 > From: Neil Madden > > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > Date: 7 May 2019 at 09:37:29 BST > To: Vittorio Bertocci > > Cc: Hans Zandbelt >, Karl McGuinness = >, John Bradley = >, IETF oauth WG = > > =20 > I wasn=E2=80=99t at IIW so I may be missing some context. > =20 > There is a potential security issue if the client_id is used as the = =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the = client can register itself with a self-chosen client_id then it may = deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged actions. > =20 > Is this the context of the discussion? > =20 > Given that there are a lot of RSes in existence, many of which are = probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I think the onus is on the AS to ensure that no such = ambiguity can arise in the first place by ensuring that the space of = =E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the = space for genuine users or by disallowing the client_credentials grant = altogether. > =20 > This issue already arises in token introspection though, so maybe = ought to be mentioned in the OAuth security topics draft rather than = specific to the JWT AT draft? > =20 > =E2=80=94 Neil >=20 >=20 > On 6 May 2019, at 18:32, Vittorio Bertocci = > wrote: > =20 > Hi all, > thanks for your patience during this month long hiatus, and thanks for = the comments. > Last week at IIW I had the opportunity to discuss this with many of = the people on the list. Here's a summary of where the discussion landaed = on the subject of the sub (pun intended). > =20 > - It seems that RFC 7519 has pretty clear language on the use of sub- = I didn't check it back when we started the discussion. I do agree with = the people saying that we shouldn't violate existing specifications, = hence it looks like we do need to have sub also in the case in which we = have app-only tokens carrying claims about the app itself. I understand = this will cause some implementation to break, but unfortunately that's = intrinsic in the process of coming up with a common approach and = standards compliance is probably one of the strongest reasons to = tolerate that. > - That said, I am strongly committed to preserve existing = functionality. One of the main reasons that was brought up for including = sub only for user based ATs was to use it as heuristic for telling those = tokens apart from app-only ones. To that end, Karl MCGuinness suggested = that we include grant_type as a return claim, which the RS could use to = the same effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think? > Note, John Bradley observed that in some cases this might lead to = ambiguous results if an extension grant is used (say an assertion = profile) but that seems like a relatively fringe occurrence. > =20 > On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt = > wrote: > I also meant to say that (of course) the JWT standard doesn't say that = the JWT is supposed to be about the client or about the resource owner, = hence both are valid > =20 > Hans. > =20 > On Thu, Apr 4, 2019 at 10:09 PM Mike Jones = > = wrote: > I get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards. > =20 > -- = Mike > =20 > From: Hans Zandbelt >=20 > Sent: Thursday, April 4, 2019 12:59 PM > To: Mike Jones > > Cc: George Fletcher >; Vittorio Bertocci = >; IETF oauth WG > > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > =20 > the definition of RFC 7519 is actually "petitio principii" and a lot = of deployments put claims about the Resource Owner in the access token = (as a Resource Server implementer I've suffered a lot from this) > =20 > Hans. > =20 > On Thu, Apr 4, 2019 at 9:48 PM Mike Jones > wrote: > I agree with George that the subject of a token must be the principal = of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. = Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at = https://tools.ietf.org/html/rfc7519#section-4.1.2 = is: > The "sub" (subject) claim identifies the principal that is the subject = of the JWT. > =20 > If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply = with the definition from RFC 7519. > =20 > -- = Mike > =20 > From: OAuth > = On Behalf Of George Fletcher > Sent: Thursday, April 4, 2019 8:51 AM > To: Hans Zandbelt > > Cc: Vittorio Bertocci >; IETF oauth WG > > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > =20 > The more I think about this the more I land in the "No" camp. >=20 > The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >=20 > Thanks, > George >=20 > On 4/3/19 4:56 PM, Hans Zandbelt wrote: > I will argue that in a way such deployments are already broken e.g. in = the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that.=20 > =20 > Hans. > =20 > On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: > I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >=20 > On 3/26/19 12:56 PM, Hans Zandbelt wrote: > great summary! this will hurt quite a few existing m2m deployments but = I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board=20 > =20 > Hans. > =20 > On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = > wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, = Bertrand recommend using sub only for users. Martin would like to have = the sub for app only flows as well. Hans is neutral. > That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. > Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? > =20 > Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. =20 > =20 > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: > Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! > We also agree with Dominick concerning definition of the "sub" claim. > =20 > Steinar > =20 > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = >: > =46rom an access token consumer (aka API) developer point of view, I = prefer this logic > =20 > "If sub is present - client acts on behalf of a user, if not - not." > =20 > Anything more complicated has a potential of going wrong. > =20 >=20 > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com = ) wrote: >=20 > Hi Vittorio, > =20 > Yeah, I=E2=80=99m concerning user & client ids collision. > I haven=E2=80=99t seen such implementations, but user-select username = as sub, or incremental integer as sub & client_id will be easily = collide. > =20 > If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. > =20 > Sent from my iPhone >=20 > On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >=20 > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. > The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. > =20 > The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server. > =20 > Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? > Nov- playing this back: is the concern that a user and a client might = have the same identifier within an IDP? When using collision resistant = IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production? > =20 > Thanks > V.=20 > =20 > =20 > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = > wrote: > I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). > =20 > Hans. > =20 > On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = > wrote: > Yes I know - and I think in hindsight it was a mistake to use the same = claim type for multiple semantics. > =20 > All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. > =20 > In reality this leads to potential security problems - this spec has = the potential to rectify the situation. > =20 > Dominick >=20 > On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu ) wrote: >=20 > Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. > The JWT spec says inhttps://tools.ietf.org/html/rfc7519#section-4.1.2 = : > =20 > "The "sub" (subject) claim identifies the principal that is the > subject of the JWT. The claims in a JWT are normally statements > about the subject. The subject value MUST either be scoped to be > locally unique in the context of the issuer or be globally unique. > The processing of this claim is generally application specific" > =20 > which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users > =20 > Hans. > =20 > On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: > IMHO the sub claim should always refer to the user - and nothing else. > =20 > OIDC says: > =20 > "Subject - Identifier for the End-User at the Issuer." > =20 > client_id should be used to identify clients. > =20 > cheers > Dominick > =20 > On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: >=20 > Hi Vittorio, > =20 > Thanks for the good starting point of standardizing JWT-ized AT. > =20 > One feedback. > The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. > It requires those 2 types of identifiers to be unique each other in = the IdP context. > =20 > I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. > =20 > thanks > =20 > nov > =20 >=20 > On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: > =20 > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access = tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting = remotely). I look forward for your comments! > =20 > Here's just a bit of backstory, in case you are interested in how this = doc came to be. The trajectory it followed is somewhat unusual. > Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. > I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities = and differences.=20 > I put together a presentation summarizing my findings and suggesting a = rough interoperable profile = (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci= _-_a_jwt_profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! > The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. > On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. > I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 > V. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM -www.zmartzone.eu >=20 > =20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 > -- > Vennlig hilsen > =20 > Steinar Noem > Partner Udelt AS > Systemutvikler > =20 > | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 | www.udelt.no = |=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > =20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > =20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > =20 >=20 > =20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu >=20 > =20 > --=20 > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. --Apple-Mail=_D84076C4-1D1F-42F1-B423-C494AC3BF45E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I notice that a few of my emails to the OAuth WG list have = come through with the =46rom field from =E2=80=9Coauth-bounces=E2=80=9D:

From: OAuth = <oauth-bounces@ietf.org> On Behalf = Of Neil Madden

Is this normal? I checked my subscription status on mailman and = I=E2=80=99m posting from the same email address that I subscribed = from.

Cheers,

Neil

On 7 May 2019, at 10:25, Hannes = Tschofenig <Hannes.Tschofenig@arm.com> wrote:

No, it is = definitely not too late for your comment
 
From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Neil Madden
Sent: Dienstag, 7. Mai 2019 = 11:18
To: IETF oauth WG <oauth@ietf.org>
Subject: [OAUTH-WG] OAuth security = topics
 
Is it too late to add the observation = below to the OAuth security topics BCP draft?
 


Begin forwarded message:
 
From: Neil = Madden <neil.madden@forgerock.com>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00
Date: 7 May 2019 = at 09:37:29 BST
To: Vittorio = Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Cc: Hans = Zandbelt <hans.zandbelt@zmartzone.eu>, Karl McGuinness <kmcguinness@okta.com>, = John Bradley <ve7jtb@ve7jtb.com>,= IETF oauth WG <oauth@ietf.org>
 
I wasn=E2=80=99t at IIW so I may be = missing some context.
 
There is a potential security issue if the client_id is used = as the =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. = If the client can register itself with a self-chosen client_id then it = may deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged = actions.
 
Is this the context of the discussion?
 
Given that there are a lot of RSes in = existence, many of which are probably just looking at the =E2=80=9Csub=E2=80= =9D claim to identify the resource owner, I think the onus is on the AS = to ensure that no such ambiguity can arise in the first place by = ensuring that the space of =E2=80=9Csub=E2=80=9D values for client = credentials is disjoint with the space for genuine users or by = disallowing the client_credentials grant altogether.
 
This issue already arises in token = introspection though, so maybe ought to be mentioned in the OAuth = security topics draft rather than specific to the JWT AT draft?
 
=E2=80=94 Neil


On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
 
Hi all,
thanks for your patience = during this month long hiatus, and thanks for the comments.
Last week at IIW I had the opportunity to discuss this with = many of the people on the list. Here's a summary of where the discussion = landaed on the subject of the sub (pun intended).
 
- It seems that RFC 7519 has pretty = clear language on the use of sub- I didn't check it back when we started = the discussion. I do agree with the people saying that we shouldn't = violate existing specifications, hence it looks like we do need to have = sub also in the case in which we have app-only tokens carrying claims = about the app itself. I understand this will cause some implementation = to break, but unfortunately that's intrinsic in the process of coming up = with a common approach and standards compliance is probably one of the = strongest reasons to tolerate that.
- That said, I am strongly = committed to preserve existing functionality. One of the main reasons = that was brought up for including sub only for user based ATs was to use = it as heuristic for telling those tokens apart from app-only ones. To = that end, Karl MCGuinness suggested that we include = grant_type as a return claim, which the RS could use to the same = effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think?
Note, John = Bradley observed = that in some cases this might lead to ambiguous results if an extension = grant is used (say an assertion profile) but that seems like a = relatively fringe occurrence.
 
On Thu, = Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu>= wrote:
I also meant to say that (of course) = the JWT standard doesn't say that the JWT is supposed to be about the = client or about the resource owner, hence both are valid
 
Hans.
 
On Thu, Apr 4, 2019 at = 10:09 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
I get that existing practice is likely to be all over the = map, but if we=E2=80=99re to create a JWT access token standard, it=E2=80=99= s reasonable to require that the claims usage comply with the JWT = standards.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu> 
Sent: Thursday, April 4, 2019 = 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher = <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00
 
the definition of RFC 7519 is = actually "petitio principii" and a lot of deployments put claims about = the Resource Owner in the access token (as a Resource Server implementer = I've suffered a lot from this)
 
Hans.
 
On Thu, = Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
I agree with George that the subject of a = token must be the principal of that token.  That what the JWT = =E2=80=9Csub=E2=80=9D claim is for.  Indeed, the first sentence of = the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal = that is the subject of the JWT.
 
If an access = token uses =E2=80=9Csub=E2=80=9D, its usage must comply with the = definition from RFC 7519.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth <oauth-bounces@ietf.org> On Behalf = Of George = Fletcher
Sent: Thursday, April 4, 2019 = 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00
 

The more I think about this the more I land in the "No" = camp.

The subject of a token should be the = principal of that token. It shouldn't matter whether that is a machine, = a user, or a device. Trying to separate out "humans" as a special class = will just make things more complicated. If we need a claim to identify = the subject is a "human" then why not just add that. This doesn't break = anything and makes it easy for people to detect this case in those use = cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans = Zandbelt wrote:
I will argue that in a way such deployments are already = broken e.g. in the typical use case of onboarding client accounts in the = same directory/OU/namespace as user accounts and we don't need to cater = for that. 
 
Hans.
 
On Wed, = Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com> = wrote:

I agree that this will break a lot of existing = flows... especially those using any form of the client_credentials flow. = In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great = summary! this will hurt quite a few existing m2m deployments but I do = like the rigidness of it all: it is very explicit, cannot misinterpreted = and thus prevents failure (which is really what Dominick is after); I'm = on board 
 
Hans.
 
On Tue, = Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
thank you Steinar and = everyone else for the comments on this!
To summarize the situation so = far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub = only for users. Martin would like to have the sub for app only flows as = well. Hans is neutral.
That does sound like the sub as user has more consensus, tho = before changing it I'd wait for the people currently at IETF104 to have = more time to comment as well.
Clarification. If the goal is to be able to apply the logic = "if there's a sub, it's a user flow", we have to explicitly disallow = (MUST NOT) the use of sub when that's not the case. Are all OK with = it?
 
Dave, the suggestion of having explicit typing for app only = vs user only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster.     
 
On Tue, = Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> = wrote:
Hi Vittorio, we  (the = national federation-gateway for the health services in norway - = "HelseID")  think his is a really valuable initiative!
We also agree with Dominick = concerning definition of the "sub" claim.
 
<mvh>Steinar</mvh>
 
tir. = 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
=46rom an access token consumer (aka = API) developer point of view, I prefer this logic
 
"If sub is present - client acts on = behalf of a user, if not - not."
 
Anything more complicated has a potential of going = wrong.

 

On = 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) = wrote:

Hi Vittorio,
 
Yeah, I=E2=80=99m concerning = user & client ids collision.
I haven=E2=80=99t seen such = implementations, but user-select username as sub, or incremental integer = as sub & client_id will be easily collide.
 
If you can enforce collision = resistant IDs between user & client instances, it=E2=80=99ll works = fine. I feel its overkill though.
 
Sent from my iPhone


On Mar 26, = 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey = Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to = cause more discussion, and I am glad we are having this opportunity to = clarify.
The = current language in the draft traces the etymology of sub to OpenID = Connect core, hence Dominick observation is on point. However in the = description I express something in line with 7519, which was in fact my = intent.
 
The idea was to provide an identifier of the calling subject = that is guaranteed to be present in all cases- this would allow an SDK = developer to use the same code for things like lookups and membership = checks regardless of the nature of the caller (user in a delegated case, = app in app-only grants). The information to discriminate between user = and app callers is always available in the token (say, the caller is a = user if sub!=3Dclient_id, where client_id is always guaranteed to be = present as well) hence there's no loss in expressive power, should that = difference be relevant for the resource server.
 
Dominick, Hans- I probably = missed the security issue you guys are thinking of in this case. Of = course, if this would introduce a risk I completely agree it should be = changed- I'd just like to understand better the problem. Could you = expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is = the concern that a user and a client might have the same identifier = within an IDP? When using collision resistant IDs, as it is usually the = case, that seems to be a remote possibility- did you stumble in such = scenario in production?
 
Thanks
V. 
 
 
On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I believe there are plenty of = OAuth 2.0 only use cases out there... but nevertheless I agree with the = potential confusion and thus security problems arising from that (though = one may argue the semantics are the same).
 
Hans.
 
On Mon, = Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Yes I know - and I think in hindsight = it was a mistake to use the same claim type for multiple = semantics.
 
All the =E2=80=9Cthi= s is OIDC not OAuth=E2=80=9D arguments are making things more = complicated than they need to be - in my experience almost no-one (that = I know) does OIDC only - nor OAuth only. They always combine = it.
 
In reality this = leads to potential security problems - this spec has the potential to = rectify the situation.
 

Dominick

On 25. March 2019 at = 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without = agreeing or disagreeing: OIDC does not apply here since it is not OAuth = and an access token is not an id_token.
 
"The "sub" (subject) claim = identifies the principal that is the
   subject of the = JWT.  The claims in a JWT are normally statements
   about the = subject.  The subject value MUST either be scoped to be
   locally unique = in the context of the issuer or be globally unique.
   The processing = of this claim is generally application specific"
 
which kind of spells "client" = in case of the client credentials grant but I also do worry about = Resource Servers thinking/acting only in terms of users
 
Hans.
 
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO the sub claim should always = refer to the user - and nothing else.
 
OIDC says:
 
"Subject - Identifier for the End-User at the = Issuer."
 
client_id should be used to = identify clients.
 
cheers
Dominick
 

On 25.. March 2019 at = 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi = Vittorio,
 
Thanks for the good starting point of standardizing JWT-ized = AT.
 
One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of = identifier, end-user and client, in this spec.
It requires those 2 types of = identifiers to be unique each other in the IdP context.
 
I prefer omitting =E2=80=9Csub=E2= =80=9D claim in 2-legged context, so that no such constraint needed.
 
thanks
 
nov

 

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:
 
Dear all,
I just submitted a draft describing a JWT profile for OAuth = 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.
I have = a slot to discuss this tomorrow at IETF 104 (I'll be presenting = remotely). I look forward for your comments!
 
Here's just a bit of = backstory, in case you are interested in how this doc came to be. The = trajectory it followed is somewhat unusual.
  • Despite OAuth2 not = requiring any specific format for ATs, through the years I have come = across multiple proprietary solution using JWT for their access token. = The intent and scenarios addressed by those solutions are mostly the = same across vendors, but the syntax and interpretations in the = implementations are different enough to prevent developers from reusing = code and skills when moving from product to product.
  • I asked several individuals = from key products and services to share with me concrete examples of = their JWT access tokens (THANK YOU Dominick Baier = (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and = explanations!).
    I = studied and compared all those instances, identifying commonalities and = differences. 
  • I put = together a presentation summarizing my findings and suggesting a rough = interoperable profile (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/berto= cci_-_a_jwt_profile_for_ats.pptx) - got early feedback from Filip = Skokan on it. Thx Filip!
  • The = presentation was followed up by 1.5 hours of unconference discussion, = which was incredibly valuable to get tight-loop feedback and incorporate = new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten = Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you = were at OSW2019, participated in the discussion and didn't get credited = in the draft, my apologies: please send me a note and I'll make things = right at the next update.
  • On my = flight back I did my best to incorporate all the ideas and feedback in a = draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and = above all Brian were all super helpful in negotiating the mysterious = syntax of the RFC format and submission process.
I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 
--
hans.zandbelt@zmartzone.eu
ZmartZone IAM -www.zmartzone.eu

 
--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
_______________________________________________
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

 
--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
 

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

 
--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
 

 
--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

 
-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM = - www.zmartzone.eu
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank = you.
= --Apple-Mail=_D84076C4-1D1F-42F1-B423-C494AC3BF45E-- From nobody Tue May 7 04:21:25 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 DE8BA12011B for ; Tue, 7 May 2019 04:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZEsyR_qQhVF for ; Tue, 7 May 2019 04:21:17 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 1290B120116 for ; Tue, 7 May 2019 04:21:16 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hNy9n-00079L-RV; Tue, 07 May 2019 13:21:12 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-48EC71B5-2605-408F-A5C4-8D70E9C914AF; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (16E227) In-Reply-To: <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> Date: Tue, 7 May 2019 13:21:10 +0200 Cc: IETF oauth WG , Daniel Fett Content-Transfer-Encoding: 7bit Message-Id: <1BEB5CBA-6AD0-4EB0-88F5-A2FCEF53A48C@lodderstedt.net> References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> To: Neil Madden X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth security topics 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, 07 May 2019 11:21:24 -0000 --Apple-Mail-48EC71B5-2605-408F-A5C4-8D70E9C914AF Content-Type: multipart/alternative; boundary=Apple-Mail-64218248-B7AE-488B-A875-0F3CE9DE3FB9 Content-Transfer-Encoding: 7bit --Apple-Mail-64218248-B7AE-488B-A875-0F3CE9DE3FB9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Neil, you raised a very important issue but the Security BCP does not talk about J= WT content like the Access Token JWT BCP. I therefore think the security advise should go into the security considerat= ions section of the Access Token JWT BCP. best regards, Torsten. > Am 07.05.2019 um 11:18 schrieb Neil Madden : >=20 > Is it too late to add the observation below to the OAuth security topics B= CP draft? >=20 >=20 >> Begin forwarded message: >>=20 >> From: Neil Madden >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >> Date: 7 May 2019 at 09:37:29 BST >> To: Vittorio Bertocci >> Cc: Hans Zandbelt , Karl McGuinness , John Bradley , IETF oauth WG >>=20 >> I wasn=E2=80=99t at IIW so I may be missing some context. >>=20 >> There is a potential security issue if the client_id is used as the =E2=80= =9Csub=E2=80=9D for an AT obtained via client_credentials. If the client can= register itself with a self-chosen client_id then it may deliberately chose= a client_id that matches the user name of a privileged user. An RS that jus= t blindly looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let t= he client perform privileged actions. >>=20 >> Is this the context of the discussion? >>=20 >> Given that there are a lot of RSes in existence, many of which are probab= ly just looking at the =E2=80=9Csub=E2=80=9D claim to identify the resource o= wner, I think the onus is on the AS to ensure that no such ambiguity can ari= se in the first place by ensuring that the space of =E2=80=9Csub=E2=80=9D va= lues for client credentials is disjoint with the space for genuine users or b= y disallowing the client_credentials grant altogether. >>=20 >> This issue already arises in token introspection though, so maybe ought t= o be mentioned in the OAuth security topics draft rather than specific to th= e JWT AT draft? >>=20 >> =E2=80=94 Neil >>=20 >>> On 6 May 2019, at 18:32, Vittorio Bertocci wrote: >>>=20 >>> Hi all, >>> thanks for your patience during this month long hiatus, and thanks for t= he comments. >>> Last week at IIW I had the opportunity to discuss this with many of the p= eople on the list. Here's a summary of where the discussion landaed on the s= ubject of the sub (pun intended). >>>=20 >>> - It seems that RFC 7519 has pretty clear language on the use of sub- I d= idn't check it back when we started the discussion. I do agree with the peop= le saying that we shouldn't violate existing specifications, hence it looks l= ike we do need to have sub also in the case in which we have app-only tokens= carrying claims about the app itself. I understand this will cause some imp= lementation to break, but unfortunately that's intrinsic in the process of c= oming up with a common approach and standards compliance is probably one of t= he strongest reasons to tolerate that. >>> - That said, I am strongly committed to preserve existing functionality.= One of the main reasons that was brought up for including sub only for user= based ATs was to use it as heuristic for telling those tokens apart from ap= p-only ones. To that end, Karl MCGuinness suggested that we include grant_ty= pe as a return claim, which the RS could use to the same effect. I find the p= roposal very clever, and the people at IIW thought so as well. What you thin= k? >>> Note, John Bradley observed that in some cases this might lead to ambigu= ous results if an extension grant is used (say an assertion profile) but tha= t seems like a relatively fringe occurrence. >>>=20 >>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt wrote: >>>> I also meant to say that (of course) the JWT standard doesn't say that t= he JWT is supposed to be about the client or about the resource owner, hence= both are valid >>>>=20 >>>> Hans. >>>>=20 >>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones wrote: >>>>> I get that existing practice is likely to be all over the map, but if w= e=E2=80=99re to create a JWT access token standard, it=E2=80=99s reasonable t= o require that the claims usage comply with the JWT standards. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mik= e >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Hans Zandbelt =20 >>>>> Sent: Thursday, April 4, 2019 12:59 PM >>>>> To: Mike Jones >>>>> Cc: George Fletcher ; Vittorio Be= rtocci ; IETF oauth WG >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> the definition of RFC 7519 is actually "petitio principii" and a lot o= f deployments put claims about the Resource Owner in the access token (as a R= esource Server implementer I've suffered a lot from this) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones wrote: >>>>>=20 >>>>> I agree with George that the subject of a token must be the principal o= f that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. Indeed= , the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tool= s.ietf.org/html/rfc7519#section-4.1.2 is: >>>>>=20 >>>>> The "sub" (subject) claim identifies the principal that is the subject= of the JWT. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply w= ith the definition from RFC 7519. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- Mik= e >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: OAuth On Behalf Of George Fletcher >>>>> Sent: Thursday, April 4, 2019 8:51 AM >>>>> To: Hans Zandbelt >>>>> Cc: Vittorio Bertocci ; IETF oa= uth WG >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The more I think about this the more I land in the "No" camp. >>>>>=20 >>>>> The subject of a token should be the principal of that token. It shoul= dn't matter whether that is a machine, a user, or a device. Trying to separa= te out "humans" as a special class will just make things more complicated. I= f we need a claim to identify the subject is a "human" then why not just add= that. This doesn't break anything and makes it easy for people to detect th= is case in those use cases where it's required. >>>>>=20 >>>>> Thanks, >>>>> George >>>>>=20 >>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>>>>=20 >>>>> I will argue that in a way such deployments are already broken e.g. in= the typical use case of onboarding client accounts in the same directory/OU= /namespace as user accounts and we don't need to cater for that. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher wro= te: >>>>>=20 >>>>> I agree that this will break a lot of existing flows... especially tho= se using any form of the client_credentials flow. In that sense I'm not comp= letely on board yet :) >>>>>=20 >>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>>>>=20 >>>>> great summary! this will hurt quite a few existing m2m deployments but= I do like the rigidness of it all: it is very explicit, cannot misinterpret= ed and thus prevents failure (which is really what Dominick is after); I'm o= n board >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci wrote: >>>>>=20 >>>>> thank you Steinar and everyone else for the comments on this! >>>>>=20 >>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,= Bertrand recommend using sub only for users. Martin would like to have the s= ub for app only flows as well. Hans is neutral. >>>>>=20 >>>>> That does sound like the sub as user has more consensus, tho before ch= anging it I'd wait for the people currently at IETF104 to have more time to c= omment as well. >>>>>=20 >>>>> Clarification. If the goal is to be able to apply the logic "if there'= s a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the us= e of sub when that's not the case. Are all OK with it? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Dave, the suggestion of having explicit typing for app only vs user on= ly is interesting! For the purpose of putting together an interoperable prof= ile, tho, I would suggest we table it for v1 in the interest of getting to s= omething easy to adopt (hence with small delta vs existing implementations) f= aster. =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote:= >>>>>=20 >>>>> Hi Vittorio, we (the national federation-gateway for the health servi= ces in norway - "HelseID") think his is a really valuable initiative!=20 >>>>>=20 >>>>> We also agree with Dominick concerning definition of the "sub" claim. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Steinar >>>>>=20 >>>>> =20 >>>>>=20 >>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier : >>>>>=20 >>>>> =46rom an access token consumer (aka API) developer point of view, I p= refer this logic >>>>>=20 >>>>> =20 >>>>>=20 >>>>> "If sub is present - client acts on behalf of a user, if not - not." >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Anything more complicated has a potential of going wrong. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>>>>=20 >>>>> Hi Vittorio, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>>>=20 >>>>> I haven=E2=80=99t seen such implementations, but user-select username a= s sub, or incremental integer as sub & client_id will be easily collide. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If you can enforce collision resistant IDs between user & client insta= nces, it=E2=80=99ll works fine. I feel its overkill though. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>=20 >>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote= : >>>>>=20 >>>>> Hey Nov, Dominick, Hans- >>>>>=20 >>>>> thanks for the comments. That was an area I was expecting to cause mor= e discussion, and I am glad we are having this opportunity to clarify. >>>>>=20 >>>>> The current language in the draft traces the etymology of sub to OpenI= D Connect core, hence Dominick observation is on point. However in the descr= iption I express something in line with 7519, which was in fact my intent. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The idea was to provide an identifier of the calling subject that is g= uaranteed to be present in all cases- this would allow an SDK developer to u= se the same code for things like lookups and membership checks regardless of= the nature of the caller (user in a delegated case, app in app-only grants)= . The information to discriminate between user and app callers is always ava= ilable in the token (say, the caller is a user if sub!=3Dclient_id, where cl= ient_id is always guaranteed to be present as well) hence there's no loss in= expressive power, should that difference be relevant for the resource serve= r. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Dominick, Hans- I probably missed the security issue you guys are thin= king of in this case. Of course, if this would introduce a risk I completely= agree it should be changed- I'd just like to understand better the problem.= Could you expand it in a scenario/use case to clarify the risk? >>>>>=20 >>>>> Nov- playing this back: is the concern that a user and a client might h= ave the same identifier within an IDP? When using collision resistant IDs, a= s it is usually the case, that seems to be a remote possibility- did you stu= mble in such scenario in production? >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> V.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt wrote: >>>>>=20 >>>>> I believe there are plenty of OAuth 2.0 only use cases out there... bu= t nevertheless I agree with the potential confusion and thus security proble= ms arising from that (though one may argue the semantics are the same). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier wrote: >>>>>=20 >>>>> Yes I know - and I think in hindsight it was a mistake to use the same= claim type for multiple semantics. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making t= hings more complicated than they need to be - in my experience almost no-one= (that I know) does OIDC only - nor OAuth only. They always combine it. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In reality this leads to potential security problems - this spec has t= he potential to rectify the situation. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Dominick >>>>>=20 >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.= eu) wrote: >>>>>=20 >>>>> Without agreeing or disagreeing: OIDC does not apply here since it is n= ot OAuth and an access token is not an id_token. >>>>>=20 >>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2= : >>>>>=20 >>>>> =20 >>>>>=20 >>>>> "The "sub" (subject) claim identifies the principal that is the >>>>>=20 >>>>> subject of the JWT. The claims in a JWT are normally statements >>>>>=20 >>>>> about the subject. The subject value MUST either be scoped to be >>>>>=20 >>>>> locally unique in the context of the issuer or be globally unique. >>>>>=20 >>>>> The processing of this claim is generally application specific" >>>>>=20 >>>>> =20 >>>>>=20 >>>>> which kind of spells "client" in case of the client credentials grant b= ut I also do worry about Resource Servers thinking/acting only in terms of u= sers >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier wrote: >>>>>=20 >>>>> IMHO the sub claim should always refer to the user - and nothing else.= >>>>>=20 >>>>> =20 >>>>>=20 >>>>> OIDC says: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>=20 >>>>> =20 >>>>>=20 >>>>> client_id should be used to identify clients. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> cheers >>>>>=20 >>>>> Dominick >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>>=20 >>>>> Hi Vittorio, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> One feedback. >>>>>=20 >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end= -user and client, in this spec. >>>>>=20 >>>>> It requires those 2 types of identifiers to be unique each other in th= e IdP context. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so t= hat no such constraint needed. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> thanks >>>>>=20 >>>>> =20 >>>>>=20 >>>>> nov >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci wrote: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access= tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-= oauth-access-token-jwt/. >>>>>=20 >>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting= remotely). I look forward for your comments! >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Here's just a bit of backstory, in case you are interested in how this= doc came to be. The trajectory it followed is somewhat unusual. >>>>>=20 >>>>> Despite OAuth2 not requiring any specific format for ATs, through the y= ears I have come across multiple proprietary solution using JWT for their ac= cess token. The intent and scenarios addressed by those solutions are mostly= the same across vendors, but the syntax and interpretations in the implemen= tations are different enough to prevent developers from reusing code and ski= lls when moving from product to product. >>>>> I asked several individuals from key products and services to share wi= th me concrete examples of their JWT access tokens (THANK YOU Dominick Baier= (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft= ), Karl Guinness (Okta) for the tokens and explanations!). >>>>> I studied and compared all those instances, identifying commonalities a= nd differences.=20 >>>>> I put together a presentation summarizing my findings and suggesting a= rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/ev= ents/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feed= back from Filip Skokan on it. Thx Filip! >>>>> The presentation was followed up by 1.5 hours of unconference discussi= on, which was incredibly valuable to get tight-loop feedback and incorporate= new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodders= tedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generou= sly to the discussion. Thank you!!! >>>>> Note: if you were at OSW2019, participated in the discussion and didn'= t get credited in the draft, my apologies: please send me a note and I'll ma= ke things right at the next update. >>>>> On my flight back I did my best to incorporate all the ideas and feedb= ack in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes a= nd above all Brian were all super helpful in negotiating the mysterious synt= ax of the RFC format and submission process. >>>>> I was blown away by the availability, involvement and willingness to i= nvest time to get things right that everyone demonstrated in the process. Th= is is an amazing community.=20 >>>>>=20 >>>>> V. >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> hans.zandbelt@zmartzone.eu >>>>>=20 >>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> hans.zandbelt@zmartzone.eu >>>>>=20 >>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Vennlig hilsen >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Steinar Noem >>>>>=20 >>>>> Partner Udelt AS >>>>>=20 >>>>> Systemutvikler >>>>>=20 >>>>> =20 >>>>>=20 >>>>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no |=20= >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> hans.zandbelt@zmartzone.eu >>>>>=20 >>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> hans.zandbelt@zmartzone.eu >>>>>=20 >>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> hans.zandbelt@zmartzone.eu >>>>>=20 >>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail-64218248-B7AE-488B-A875-0F3CE9DE3FB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi N= eil,

you raised a very impo= rtant issue but the Security BCP does not talk about JWT content like the Access Token JWT BCP= .

I therefore think t= he security advise should go into the security considerations section of the= Access Token JWT BCP.

best= regards,
Torsten.

Am 07.05.= 2019 um 11:18 schrieb Neil Madden <neil.madden@forgerock.com>:

Is it too late to add the observation bel= ow to the OAuth security topics BCP draft?


Begin forwarded m= essage:

From: <= /span>Neil Madden <neil.madden@forgerock.com>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Date: 7 May 201= 9 at 09:37:29 BST
To: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org&g= t;
Cc: Hans Zandbelt <hans.zandbelt@zmartzone.eu>, Karl McGuinness <kmcguinness@okta.com>, John Bradley &= lt;ve7jtb@ve7jtb.com>= , IETF oauth WG <oauth@ietf.= org>

I wasn=E2=80=99t at IIW so I may be missing so= me context.

There is a p= otential security issue if the client_id is used as the =E2=80=9Csub=E2=80=9D= for an AT obtained via client_credentials. If the client can register itsel= f with a self-chosen client_id then it may deliberately chose a client_id th= at matches the user name of a privileged user. An RS that just blindly looks= at the =E2=80=9Csub=E2=80=9D claim may then erroneously let the client perf= orm privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, ma= ny of which are probably just looking at the =E2=80=9Csub=E2=80=9D claim to i= dentify the resource owner, I think the onus is on the AS to ensure that no s= uch ambiguity can arise in the first place by ensuring that the space of =E2= =80=9Csub=E2=80=9D values for client credentials is disjoint with the space f= or genuine users or by disallowing the client_credentials grant altogether.<= /div>

This issue already= arises in token introspection though, so maybe ought to be mentioned in the= OAuth security topics draft rather than specific to the JWT AT draft?
=

=E2=80=94 Neil

On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=3D40auth0.com@= dmarc.ietf.org> wrote:

<= div class=3D"">
Hi all,
thanks for= your patience during this month long hiatus, and thanks for the comments.
Last week at IIW I had the opportunity to discuss this w= ith many of the people on the list. Here's a summary of where the discussion= landaed on the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear la= nguage on the use of sub- I didn't check it back when we started the discuss= ion. I do agree with the people saying that we shouldn't violate existing sp= ecifications, hence it looks like we do need to have sub also in the case in= which we have app-only tokens carrying claims about the app itself. I under= stand this will cause some implementation to break, but unfortunately that's= intrinsic in the process of coming up with a common approach and standards c= ompliance is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing func= tionality. One of the main reasons that was brought up for including sub onl= y for user based ATs was to use it as heuristic for telling those tokens apa= rt from app-only ones. To that end, Karl MCGuinn= ess suggested that we include grant_type as a return claim, which the RS= could use to the same effect. I find the proposal very clever, and the p= eople at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambig= uous results if an extension grant is used (say an assertion profile) but th= at seems like a relatively fringe occurrence.

On Thu, Apr 4, 2= 019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
=
I also meant to say that (of course) the JWT standard doesn't say that the J= WT is supposed to be about the client or about the resource owner, hence bot= h are valid

Hans.
<= /div>
On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@micros= oft.com> wrote:

= I get that existing practice is likely to be all over the map, but if we=E2=80= =99re to create a JWT access token standard, it=E2=80=99s reasonable to requ= ire that the claims usage comply with the JWT standards.

 

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

 

From: Hans Zandbelt <= ;= hans.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org= >; Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>= ; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-= jwt-00

 

the definition of RFC 7519 is actuall= y "petitio principii" and a lot of deployments put claims about the Resource= Owner in the access token (as a Resource Server implementer I've suffered a= lot from this)

 

Hans.=

 

On Thu, Apr 4, 2019 at 9:48 PM Mike J= ones <Michael.Jones@microsoft.com> wrote:

I agree with George that the subject of a token must be the princip= al of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for= .  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:

The "sub" (= subject) claim identifies the principal that is the subject of the JWT.

 

If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with= the definition from RFC 7519.

 =

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu> Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf= .org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-= jwt-00

 

<= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">The more I think about this the more I la= nd in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't m= atter whether that is a machine, a user, or a device. Trying to separate out= "humans" as a special class will just make things more complicated. If we n= eed a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and ma= kes it easy for people to detect this case in those use cases where it's req= uired.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrot= e:

I will argue that in a way such deplo= yments are already broken e.g. in the typical use case of onboarding client a= ccounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.

 

Hans.=

 

On Wed, Apr 3, 2019 at 10:48 PM Georg= e Fletcher <gffletch@aol.com> wrote:

I agree that this will b= reak a lot of existing flows... especially those using any form of the clien= t_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wr= ote:

great summary! this will hurt quite a= few existing m2m deployments but I do like the rigidness of it all: it is v= ery explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

 

Hans.=

 

On Tue, Mar 26, 2019 at 5:49 PM Vitto= rio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone else f= or the comments on this!

To summarize the situation so far: Do= minick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for user= s. Martin would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user h= as more consensus, tho before changing it I'd wait for the people currently a= t IETF104 to have more time to comment as well.

Clarification. If the goal is to be a= ble to apply the logic "if there's a sub, it's a user flow", we have to expl= icitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

 

Dave, the suggestion of having explic= it typing for app only vs user only is interesting! For the purpose of putti= ng together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with= small delta vs existing implementations) faster.     

 

On Tue, Mar 26, 2019 at 1:40 AM Stein= ar Noem <steinar@udelt.no> wrote:

Hi Vittorio, we  (the national f= ederation-gateway for the health services in norway - "HelseID")  think= his is a really valuable initiative!

We also agree with Dominick concernin= g definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 skrev Do= minick Baier <dbaier@leastprivilege.com>:

=46rom an access token consumer (aka A= PI) developer point of view, I prefer this logic

 

"If sub is present - client acts on be= half of a user, if not - not."

 

Anything more complicated has a potent= ial of going wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Yeah, I=E2=80=99m concerning user &am= p; client ids collision.

I haven=E2=80=99t seen such implement= ations, but user-select username as sub, or incremental integer as sub &= client_id will be easily collide.

 

If you can enforce collision resistan= t IDs between user & client instances, it=E2=80=99ll works fine. I feel i= ts overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an a= rea I was expecting to cause more discussion, and I am glad we are having th= is opportunity to clarify.

The current language in the draft tra= ces the etymology of sub to OpenID Connect core, hence Dominick observation i= s on point. However in the description I express something in line with 7519, which was in fact my intent.=

 

The idea was to provide an identifier= of the calling subject that is guaranteed to be present in all cases- this w= ould allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user i= n a delegated case, app in app-only grants). The information to discriminate= between user and app callers is always available in the token (say, the cal= ler is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's n= o loss in expressive power, should that difference be relevant for the resou= rce server.

 

Dominick, Hans- I probably missed the= security issue you guys are thinking of in this case. Of course, if this wo= uld introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenar= io/use case to clarify the risk?

Nov- playing this back: is the concer= n that a user and a client might have the same identifier within an IDP? Whe= n using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in produ= ction?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM Hans Z= andbelt <hans.zandbelt@zmartzone.eu> wrote:

I believe there are plenty of OAuth 2= .0 only use cases out there... but nevertheless I agree with the potential c= onfusion and thus security problems arising from that (though one may argue the semantics are the same).<= /p>

 

Hans.=

 

On Mon, Mar 25, 2019 at 3:39 PM Domin= ick Baier <dbaier@leastprivilege.com> wrote:

Yes I know - and I think in hindsight i= t was a mistake to use the same claim type for multiple semantics.

 

All the =E2=80=9Cthis is OIDC not OAut= h=E2=80=9D arguments are making things more complicated than they need to be= - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always co= mbine it.

 

In reality this leads to potential sec= urity problems - this spec has the potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu)= wrote:

Without agreeing or disagreeing: OIDC= does not apply here since it is not OAuth and an access token is not an id_= token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

 

"The "sub" (subject) claim identifies= the principal that is the

   subject of the JWT. = ; The claims in a JWT are normally statements

   about the subject. = The subject value MUST either be scoped to be

   locally unique in the co= ntext of the issuer or be globally unique.

   The processing of this c= laim is generally application specific"<= /p>

 

which kind of spells "client" in case= of the client credentials grant but I also do worry about Resource Servers t= hinking/acting only in terms of users

 

Hans.=

 

On Mon, Mar 25, 2019 at 2:41 PM Domin= ick Baier <dbaier@leastprivilege.com> wrote:

IMHO the sub claim should always refer= to the user - and nothing else.<= /p>

 

OIDC says:

 

"Subject - Identifier for the End-= User at the Issuer."

 

client_id should be used to identify c= lients.

 

cheers

Dominick

 

<= p class=3D"gmail-m_3427556202512511532gmail-m_-7213962316136973161gmail-m460= 8962369877967204gmail-m-7045545945873532059gmail-m-170779933288057762gmail-m= 5198006064186021407gmail-m-1861492976098253843gmail-m8203060113877166976gmai= l-m1280717969515106817gmail-m8475728656245492495airmailon"> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:<= /u>

Hi Vittorio,

 

Thanks for the good starting point of= standardizing JWT-ized AT.

 

One feedback.

The =E2=80=9Csub=E2=80=9D claim can i= nclude 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of identifi= ers to be unique each other in the IdP context.

 

I prefer omitting =E2=80=9Csub=E2=80=9D= claim in 2-legged context, so that no such constraint needed.=

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, Vittorio Be= rtocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org= > wrote:

 

Dear all,

I just submitted a draft describing a= JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-o= auth-access-token-jwt/.

I have a slot to discuss this tomorro= w at IETF 104 (I'll be presenting remotely). I look forward for your comment= s!

 

Here's just a bit of backstory, in ca= se you are interested in how this doc came to be. The trajectory it followed= is somewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the years I= have come across multiple proprietary solution using JWT for their access t= oken. The intent and scenarios addressed by those solutions are mostly the s= ame across vendors, but the syntax and interpretations in the implementations are different enough to p= revent developers from reusing code and skills when moving from product to p= roduct.
  • I asked several individuals from key products and services to share with me c= oncrete examples of their JWT access tokens (THANK YOU Dominick Baier (Ident= ityServer), Brian Campbell (P= ingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and di= fferences. 
  • I put together a presentation summarizing my findings and suggesting a rough= interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_p= rofile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx = Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, wh= ich was incredibly valuable to get tight-loop feedback and incorporate new i= deas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,<= span style=3D"font-size:10pt" class=3D""> Nat Sakimura, Hannes Tschofenig were all there and contributed gene= rously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get c= redited in the draft, my apologies: please send me a note and I'll make thin= gs right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in= a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and ab= ove all Brian were all super helpful in negotiating the mysterious syntax of= the RFC format and submission process.

I was blown away by the availability,= involvement and willingness to invest time to get things right that everyon= e demonstrated in the process. This is an amazing community. 

V.

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

 

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

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


 

--

hans.zandbelt@zmartzone.eu<= /p>

ZmartZone IAM - www.zmartz= one.eu


 

--

hans.zandbelt@zmartzone.eu<= /p>

ZmartZone IAM - www.zmartz= one.eu

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


 

--

hans.zandbelt@zmartzone.eu<= /p>

ZmartZone IAM - www.zmartz= one.eu

=  

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

 


 

--

hans.zandbelt@zmartzone.eu<= /p>

ZmartZone IAM - www.zmartz= one.eu

 


 

--

hans.zandbelt@zmartzone.eu<= /p>

ZmartZone IAM - www.zmartzone.eu



--
ZmartZone IAM - www.zmartzone.eu
<= /div>
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-64218248-B7AE-488B-A875-0F3CE9DE3FB9-- --Apple-Mail-48EC71B5-2605-408F-A5C4-8D70E9C914AF Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w 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 jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9 SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy 4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4 ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8 BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTA3MTEyMTEwWjAvBgkqhkiG9w0BCQQxIgQg L32U1nNWhTqeJF1eX+axIgG9kVUZyjurjMJKwSixX6cwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0 MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAGncm9wFvqh9byN0 nY4vzkSxWSUGyYfTEZgjogUBut+l2JS67DYS1Rui3iSPOgadJluIQkXwSF8HIwA831LoBiBok85T VYm32gNnwtaU6KqEMJp0z/ixn9EdwHyFfUvzRgEp08zBZ99Zv/E5EsPeqE6gWAVcsadjBKgK8XBh SUEsx4PUjMLY6BUHPEpoP9EX0+DB3r8WSXSEKdfHUj6jfbP9mzsHCBeTanF0UdKPSPwKZyOE4MUk OWWExfygIyDC7Voh2Cn6HXdyQXC2ML23W0SwqAStMUMLwahSlmxvieh+QHnP2UW3IyBw+4eJe76f x0vaxIgNN9yV+WvUV6DwVXAAAAAAAAA= --Apple-Mail-48EC71B5-2605-408F-A5C4-8D70E9C914AF-- From nobody Tue May 7 04:23:24 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 D521B120112 for ; Tue, 7 May 2019 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcpE90kaC5xK for ; Tue, 7 May 2019 04:23:17 -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 173AC12010C for ; Tue, 7 May 2019 04:23:17 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id m20so7561438wmg.1 for ; Tue, 07 May 2019 04:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OkUJsMSS6Dix4i/LFD4aj1CfR4JiOPz8Nd1eZYqU8sM=; b=fTrd7PWD0XoAJPRhVs587Socg483gDMXWzAR2oz1OcKrv/zH45WI2tDb/tez6e7w99 EQ23xW65kH4rnW9cbSNClvzulNG5n1rqf74DqdXQjm6IGvBPRXJXoCnX+mmmn4jZLMMt sZBHcPpluq6wEAqw6qCqJz991L1uz6upI2Nm0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OkUJsMSS6Dix4i/LFD4aj1CfR4JiOPz8Nd1eZYqU8sM=; b=ozFghEVqOXf3/je7zoiKIe79L2vfaDgTdJC+hf3HWCz19NLqTiQkdhBqqQ8WJ/cinM kNcIna+sknYTk+EymG+yDa2huaJWvUxxfDwQXN4nJOI0nw8asQSnzzM2mM8XYdTABbIr ELgNGSRNoCXSBAr4Oj+uA4hA1I+hD6zNc47+rrqugvpoH5b9kmWM17BnjgSOPG4pOkqp t4YoaIOTsX30MVSYyVBaxSzby268ix70ozDELEml9VksrnLa22vRh3jdk2AkgWyLDrx3 HB8NS0GnW92/wbkE+34lxN5kGl1Fn9VlT+RdsTSM5I6IUOsjluz2sya95zwcSCjunqDf Z8Zw== X-Gm-Message-State: APjAAAWb3Wcd/DTVk166W4BEwf4ub3EQ9YA4ynEgC6K3mEktIND1AKSB jXtipTgrZJly+mwOIEypWPWSSg== X-Google-Smtp-Source: APXvYqyAHp2FYHl4RKMOp+ckMO/NpRZ/OxUKE/4gX6p2CB9+LvIM89EQQzlpeK7u2p9L/+F3s/72iA== X-Received: by 2002:a05:600c:d1:: with SMTP id u17mr13003523wmm.2.1557228195213; Tue, 07 May 2019 04:23:15 -0700 (PDT) Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id k67sm19551995wmb.34.2019.05.07.04.23.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 04:23:14 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4277B358-6782-43A5-81BA-A5F43F252C2C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 7 May 2019 12:23:11 +0100 In-Reply-To: <1BEB5CBA-6AD0-4EB0-88F5-A2FCEF53A48C@lodderstedt.net> Cc: IETF oauth WG , Daniel Fett To: Torsten Lodderstedt References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> <1BEB5CBA-6AD0-4EB0-88F5-A2FCEF53A48C@lodderstedt.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] OAuth security topics 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, 07 May 2019 11:23:23 -0000 --Apple-Mail=_4277B358-6782-43A5-81BA-A5F43F252C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The same issue applies to token introspection responses though. > On 7 May 2019, at 12:21, Torsten Lodderstedt = wrote: >=20 > Hi Neil, >=20 > you raised a very important issue but the Security BCP does not talk = about JWT content like the Access Token JWT BCP. >=20 > I therefore think the security advise should go into the security = considerations section of the Access Token JWT BCP. >=20 > best regards, > Torsten. >=20 > Am 07.05.2019 um 11:18 schrieb Neil Madden >: >=20 >> Is it too late to add the observation below to the OAuth security = topics BCP draft? >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: Neil Madden > >>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>> Date: 7 May 2019 at 09:37:29 BST >>> To: Vittorio Bertocci > >>> Cc: Hans Zandbelt >, Karl McGuinness = >, John Bradley = >, IETF oauth WG = > >>>=20 >>> I wasn=E2=80=99t at IIW so I may be missing some context. >>>=20 >>> There is a potential security issue if the client_id is used as the = =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the = client can register itself with a self-chosen client_id then it may = deliberately chose a client_id that matches the user name of a = privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D= claim may then erroneously let the client perform privileged actions. >>>=20 >>> Is this the context of the discussion? >>>=20 >>> Given that there are a lot of RSes in existence, many of which are = probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the = resource owner, I think the onus is on the AS to ensure that no such = ambiguity can arise in the first place by ensuring that the space of = =E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the = space for genuine users or by disallowing the client_credentials grant = altogether. >>>=20 >>> This issue already arises in token introspection though, so maybe = ought to be mentioned in the OAuth security topics draft rather than = specific to the JWT AT draft? >>>=20 >>> =E2=80=94 Neil >>>=20 >>>> On 6 May 2019, at 18:32, Vittorio Bertocci = > wrote: >>>>=20 >>>> Hi all, >>>> thanks for your patience during this month long hiatus, and thanks = for the comments. >>>> Last week at IIW I had the opportunity to discuss this with many of = the people on the list. Here's a summary of where the discussion landaed = on the subject of the sub (pun intended). >>>>=20 >>>> - It seems that RFC 7519 has pretty clear language on the use of = sub- I didn't check it back when we started the discussion. I do agree = with the people saying that we shouldn't violate existing = specifications, hence it looks like we do need to have sub also in the = case in which we have app-only tokens carrying claims about the app = itself. I understand this will cause some implementation to break, but = unfortunately that's intrinsic in the process of coming up with a common = approach and standards compliance is probably one of the strongest = reasons to tolerate that. >>>> - That said, I am strongly committed to preserve existing = functionality. One of the main reasons that was brought up for including = sub only for user based ATs was to use it as heuristic for telling those = tokens apart from app-only ones. To that end, Karl MCGuinness suggested = that we include grant_type as a return claim, which the RS could use to = the same effect. I find the proposal very clever, and the people at IIW = thought so as well. What you think? >>>> Note, John Bradley observed that in some cases this might lead to = ambiguous results if an extension grant is used (say an assertion = profile) but that seems like a relatively fringe occurrence. >>>>=20 >>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt = > wrote: >>>> I also meant to say that (of course) the JWT standard doesn't say = that the JWT is supposed to be about the client or about the resource = owner, hence both are valid >>>>=20 >>>> Hans. >>>>=20 >>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones = > = wrote: >>>> I get that existing practice is likely to be all over the map, but = if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards. >>>>=20 >>>> =20 >>>>=20 >>>> -- = Mike >>>>=20 >>>> =20 >>>>=20 >>>> From: Hans Zandbelt >=20 >>>> Sent: Thursday, April 4, 2019 12:59 PM >>>> To: Mike Jones > >>>> Cc: George Fletcher >; Vittorio Bertocci = >; IETF oauth WG > >>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>=20 >>>> =20 >>>>=20 >>>> the definition of RFC 7519 is actually "petitio principii" and a = lot of deployments put claims about the Resource Owner in the access = token (as a Resource Server implementer I've suffered a lot from this) >>>>=20 >>>> =20 >>>>=20 >>>> Hans. >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones = > = wrote: >>>>=20 >>>> I agree with George that the subject of a token must be the = principal of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim = is for. Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D = definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 = is: >>>>=20 >>>> The "sub" (subject) claim identifies the principal that is the = subject of the JWT. >>>>=20 >>>> =20 >>>>=20 >>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must = comply with the definition from RFC 7519. >>>>=20 >>>> =20 >>>>=20 >>>> -- = Mike >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth > On Behalf Of George Fletcher >>>> Sent: Thursday, April 4, 2019 8:51 AM >>>> To: Hans Zandbelt > >>>> Cc: Vittorio Bertocci >; IETF oauth WG > >>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>=20 >>>> =20 >>>>=20 >>>> The more I think about this the more I land in the "No" camp. >>>>=20 >>>> The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >>>>=20 >>>> Thanks, >>>> George >>>>=20 >>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>>>=20 >>>> I will argue that in a way such deployments are already broken e.g. = in the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. >>>>=20 >>>> =20 >>>>=20 >>>> Hans. >>>>=20 >>>> =20 >>>>=20 >>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: >>>>=20 >>>> I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >>>>=20 >>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>>>=20 >>>> great summary! this will hurt quite a few existing m2m deployments = but I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board >>>>=20 >>>> =20 >>>>=20 >>>> Hans. >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = > wrote: >>>>=20 >>>> thank you Steinar and everyone else for the comments on this! >>>>=20 >>>> To summarize the situation so far: Dominick, Steinar, Rob, David, = Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral. >>>>=20 >>>> That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. >>>>=20 >>>> Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >>>>=20 >>>> =20 >>>>=20 >>>> Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: >>>>=20 >>>> Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! >>>>=20 >>>> We also agree with Dominick concerning definition of the "sub" = claim. >>>>=20 >>>> =20 >>>>=20 >>>> Steinar >>>>=20 >>>> =20 >>>>=20 >>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = >: >>>>=20 >>>> =46rom an access token consumer (aka API) developer point of view, = I prefer this logic >>>>=20 >>>> =20 >>>>=20 >>>> "If sub is present - client acts on behalf of a user, if not - = not." >>>>=20 >>>> =20 >>>>=20 >>>> Anything more complicated has a potential of going wrong. >>>>=20 >>>> =20 >>>>=20 >>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com = ) wrote: >>>>=20 >>>> Hi Vittorio, >>>>=20 >>>> =20 >>>>=20 >>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>>=20 >>>> I haven=E2=80=99t seen such implementations, but user-select = username as sub, or incremental integer as sub & client_id will be = easily collide. >>>>=20 >>>> =20 >>>>=20 >>>> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >>>>=20 >>>> =20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>=20 >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >>>>=20 >>>> Hey Nov, Dominick, Hans- >>>>=20 >>>> thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >>>>=20 >>>> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >>>>=20 >>>> =20 >>>>=20 >>>> The idea was to provide an identifier of the calling subject that = is guaranteed to be present in all cases- this would allow an SDK = developer to use the same code for things like lookups and membership = checks regardless of the nature of the caller (user in a delegated case, = app in app-only grants). The information to discriminate between user = and app callers is always available in the token (say, the caller is a = user if sub!=3Dclient_id, where client_id is always guaranteed to be = present as well) hence there's no loss in expressive power, should that = difference be relevant for the resource server. >>>>=20 >>>> =20 >>>>=20 >>>> Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >>>>=20 >>>> Nov- playing this back: is the concern that a user and a client = might have the same identifier within an IDP? When using collision = resistant IDs, as it is usually the case, that seems to be a remote = possibility- did you stumble in such scenario in production? >>>>=20 >>>> =20 >>>>=20 >>>> Thanks >>>>=20 >>>> V.=20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = > wrote: >>>>=20 >>>> I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >>>>=20 >>>> =20 >>>>=20 >>>> Hans. >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = > wrote: >>>>=20 >>>> Yes I know - and I think in hindsight it was a mistake to use the = same claim type for multiple semantics. >>>>=20 >>>> =20 >>>>=20 >>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are = making things more complicated than they need to be - in my experience = almost no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >>>>=20 >>>> =20 >>>>=20 >>>> In reality this leads to potential security problems - this spec = has the potential to rectify the situation. >>>>=20 >>>> =20 >>>>=20 >>>> Dominick >>>>=20 >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu ) wrote: >>>>=20 >>>> Without agreeing or disagreeing: OIDC does not apply here since it = is not OAuth and an access token is not an id_token. >>>>=20 >>>> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2 = : >>>>=20 >>>> =20 >>>>=20 >>>> "The "sub" (subject) claim identifies the principal that is the >>>>=20 >>>> subject of the JWT. The claims in a JWT are normally statements >>>>=20 >>>> about the subject. The subject value MUST either be scoped to = be >>>>=20 >>>> locally unique in the context of the issuer or be globally = unique. >>>>=20 >>>> The processing of this claim is generally application specific" >>>>=20 >>>> =20 >>>>=20 >>>> which kind of spells "client" in case of the client credentials = grant but I also do worry about Resource Servers thinking/acting only in = terms of users >>>>=20 >>>> =20 >>>>=20 >>>> Hans. >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: >>>>=20 >>>> IMHO the sub claim should always refer to the user - and nothing = else. >>>>=20 >>>> =20 >>>>=20 >>>> OIDC says: >>>>=20 >>>> =20 >>>>=20 >>>> "Subject - Identifier for the End-User at the Issuer." >>>>=20 >>>> =20 >>>>=20 >>>> client_id should be used to identify clients. >>>>=20 >>>> =20 >>>>=20 >>>> cheers >>>>=20 >>>> Dominick >>>>=20 >>>> =20 >>>>=20 >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: >>>>=20 >>>> Hi Vittorio, >>>>=20 >>>> =20 >>>>=20 >>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>=20 >>>> =20 >>>>=20 >>>> One feedback. >>>>=20 >>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >>>>=20 >>>> It requires those 2 types of identifiers to be unique each other in = the IdP context. >>>>=20 >>>> =20 >>>>=20 >>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such constraint needed. >>>>=20 >>>> =20 >>>>=20 >>>> thanks >>>>=20 >>>> =20 >>>>=20 >>>> nov >>>>=20 >>>> =20 >>>>=20 >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: >>>>=20 >>>> =20 >>>>=20 >>>> Dear all, >>>>=20 >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= >>>>=20 >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>>>=20 >>>> =20 >>>>=20 >>>> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>>>=20 >>>> Despite OAuth2 not requiring any specific format for ATs, through = the years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >>>> I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). >>>> I studied and compared all those instances, identifying = commonalities and differences.=20 >>>> I put together a presentation summarizing my findings and = suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! >>>> The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >>>> On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. >>>> I was blown away by the availability, involvement and willingness = to invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 >>>>=20 >>>> V. >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> Vennlig hilsen >>>>=20 >>>> =20 >>>>=20 >>>> Steinar Noem >>>>=20 >>>> Partner Udelt AS >>>>=20 >>>> Systemutvikler >>>>=20 >>>> =20 >>>>=20 >>>> | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 | www.udelt.no = |=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>>=20 >>>> --=20 >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>=20 --Apple-Mail=_4277B358-6782-43A5-81BA-A5F43F252C2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = same issue applies to token introspection responses though.

On 7 May 2019, at 12:21, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Neil,

you raised a very important issue but the Security BCP does = not talk about JWT content like the Access Token JWT = BCP.

I therefore think the security advise should go = into the security considerations section of the Access Token JWT = BCP.

best regards,
Torsten.

Am = 07.05.2019 um 11:18 schrieb Neil Madden <neil.madden@forgerock.com>:

Is it too late to add the = observation below to the OAuth security topics BCP draft?


Begin forwarded message:

From: Neil Madden <neil.madden@forgerock.com>
Subject: = Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00
Date: 7 May 2019 at 09:37:29 BST
To: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>
Cc: Hans Zandbelt <hans.zandbelt@zmartzone.eu>, Karl McGuinness <kmcguinness@okta.com>, John Bradley <ve7jtb@ve7jtb.com>, = IETF oauth WG <oauth@ietf.org>

I wasn=E2=80=99t at IIW so I may be missing some context.

There is a potential = security issue if the client_id is used as the =E2=80=9Csub=E2=80=9D for = an AT obtained via client_credentials. If the client can register itself = with a self-chosen client_id then it may deliberately chose a client_id = that matches the user name of a privileged user. An RS that just blindly = looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let the = client perform privileged actions.

Is this the context of the = discussion?

Given that there are a lot of RSes in existence, many of = which are probably just looking at the =E2=80=9Csub=E2=80=9D claim to = identify the resource owner, I think the onus is on the AS to ensure = that no such ambiguity can arise in the first place by ensuring that the = space of =E2=80=9Csub=E2=80=9D values for client credentials is disjoint = with the space for genuine users or by disallowing the = client_credentials grant altogether.

This issue already arises in token = introspection though, so maybe ought to be mentioned in the OAuth = security topics draft rather than specific to the JWT AT = draft?

=E2=80=94= Neil

On 6 May 2019, at 18:32, = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this = month long hiatus, and thanks for the comments.
Last = week at IIW I had the opportunity to discuss this with many of the = people on the list. Here's a summary of where the discussion landaed on = the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty = clear language on the use of sub- I didn't check it back when we started = the discussion. I do agree with the people saying that we shouldn't = violate existing specifications, hence it looks like we do need to have = sub also in the case in which we have app-only tokens carrying claims = about the app itself. I understand this will cause some implementation = to break, but unfortunately that's intrinsic in the process of coming up = with a common approach and standards compliance is probably one of the = strongest reasons to tolerate that.
- That said, I = am strongly committed to preserve existing functionality. One of the = main reasons that was brought up for including sub only for user based = ATs was to use it as heuristic for telling those tokens apart from = app-only ones. To that end, Karl = MCGuinness suggested that we include grant_type as a return claim, = which the RS could use to the same effect. I find the proposal very = clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some = cases this might lead to ambiguous results if an extension grant is used = (say an assertion profile) but that seems like a relatively fringe = occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans = Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I also = meant to say that (of course) the JWT standard doesn't say that the JWT = is supposed to be about the client or about the resource owner, hence = both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike = Jones <Michael.Jones@microsoft.com> wrote:

I= get that existing practice is likely to be all over the map, but if = we=E2=80=99re to create a JWT access token standard, it=E2=80=99s = reasonable to require that the claims usage comply with the JWT = standards.

 

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

 

From: = Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Bertocci = <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF = oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is = actually "petitio principii" and a lot of deployments put claims about = the Resource Owner in the access token (as a Resource Server implementer = I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM = Mike Jones <Michael.Jones@microsoft.com> = wrote:

I agree with George that the subject of a token must be the = principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D = claim is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:

The = "sub" (subject) claim identifies the principal that is the subject of = the JWT.

 

If an = access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with the = definition from RFC 7519.

 

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

The more I think = about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything = and makes it easy for people to detect this case in those use cases = where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt = wrote:

I will argue that in a way such = deployments are already broken e.g. in the typical use case of = onboarding client accounts in the same directory/OU/namespace as user = accounts and we don't need to cater for that.

=

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM = George Fletcher <gffletch@aol.com> wrote:

I agree that this = will break a lot of existing flows... especially those using any form of = the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans = Zandbelt wrote:

great summary! this will hurt = quite a few existing m2m deployments but I do like the rigidness of it = all: it is very explicit, cannot misinterpreted and thus prevents = failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone = else for the comments on this!

To summarize the situation so = far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub = only for users. Martin would like to have the sub for app only flows as = well. Hans is neutral.

That does sound like the sub as = user has more consensus, tho before changing it I'd wait for the people = currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to = be able to apply the logic "if there's a sub, it's a user flow", we have = to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

 

Dave, the suggestion of having = explicit typing for app only vs user only is interesting! For the = purpose of putting together an interoperable profile, tho, I would = suggest we table it for v1 in the interest of getting to something easy to adopt (hence = with small delta vs existing implementations) faster.    =  

 

On Tue, Mar 26, 2019 at 1:40 AM = Steinar Noem <steinar@udelt.no> wrote:

Hi Vittorio, we  (the = national federation-gateway for the health services in norway - = "HelseID")  think his is a really valuable initiative!

We also agree with Dominick = concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 = skrev Dominick Baier <dbaier@leastprivilege.com>:

=46ro= m an access token consumer (aka API) developer point of view, I prefer = this logic

 

"If = sub is present - client acts on behalf of a user, if not - = not."

 

Anything more complicated has a potential of going = wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Yeah, I=E2=80=99m concerning user = & client ids collision.

I haven=E2=80=99t seen such = implementations, but user-select username as sub, or incremental integer = as sub & client_id will be easily collide.

 

If you can enforce collision = resistant IDs between user & client instances, it=E2=80=99ll works = fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was = an area I was expecting to cause more discussion, and I am glad we are = having this opportunity to clarify.

The current language in the draft = traces the etymology of sub to OpenID Connect core, hence Dominick = observation is on point. However in the description I express something = in line with 7519, which was in fact my intent.

 

The idea was to provide an = identifier of the calling subject that is guaranteed to be present in = all cases- this would allow an SDK developer to use the same code for = things like lookups and membership checks regardless of the nature of the caller = (user in a delegated case, app in app-only grants). The information to = discriminate between user and app callers is always available in the = token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence = there's no loss in expressive power, should that difference be relevant = for the resource server.

 

Dominick, Hans- I probably missed = the security issue you guys are thinking of in this case. Of course, if = this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a = scenario/use case to clarify the risk?

Nov- playing this back: is the = concern that a user and a client might have the same identifier within = an IDP? When using collision resistant IDs, as it is usually the case, = that seems to be a remote possibility- did you stumble in such scenario in = production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM = Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:

I believe there are plenty of = OAuth 2.0 only use cases out there... but nevertheless I agree with the = potential confusion and thus security problems arising from that (though = one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes = I know - and I think in hindsight it was a mistake to use the same claim = type for multiple semantics.

 

All = the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things = more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They = always combine it.

 

In = reality this leads to potential security problems - this spec has the = potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: = OIDC does not apply here since it is not OAuth and an access token is = not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

 

"The "sub" (subject) claim = identifies the principal that is the

   subject of the = JWT.  The claims in a JWT are normally statements

   about the = subject.  The subject value MUST either be scoped to be

   locally unique in = the context of the issuer or be globally unique.

   The processing of = this claim is generally application specific"

 

which kind of spells "client" in = case of the client credentials grant but I also do worry about Resource = Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM = Dominick Baier <dbaier@leastprivilege.com> wrote:

IMHO = the sub claim should always refer to the user - and nothing = else.

 

OIDC = says:

 

"Subject= - Identifier for the End-User at the Issuer."

 

client_id should be used to = identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

 

Thanks for the good starting = point of standardizing JWT-ized AT.

 

One feedback.

The =E2=80=9Csub=E2=80=9D claim = can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of = identifiers to be unique each other in the IdP context.

 

I prefer omitting =E2=80=9Csub=E2=80= =9D claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

 

Dear all,

I just submitted a draft = describing a JWT profile for OAuth 2.0 access tokens. You can find it = in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.

I have a slot to discuss this = tomorrow at IETF 104 (I'll be presenting remotely). I look forward for = your comments!

 

Here's just a bit of backstory, = in case you are interested in how this doc came to be. The trajectory it = followed is somewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough = to prevent developers from reusing code and skills when moving from = product to product.
  • I asked several individuals from key products and services to share with = me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), = Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities = and differences. 
  • I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on = it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't = get credited in the draft, my apologies: please send me a note and I'll = make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process.

I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 

V.

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

 

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

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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

_______________________________________________
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


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 

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

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu

 


 

--

hans.zandbelt@zmartzone.eu

ZmartZone IAM - www.zmartzone.eu



--
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_4277B358-6782-43A5-81BA-A5F43F252C2C-- From nobody Tue May 7 05:55: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 4E0E5120130 for ; Tue, 7 May 2019 05:55:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm4PqNRJ5g0C for ; Tue, 7 May 2019 05:55:28 -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 BCDB612012D for ; Tue, 7 May 2019 05:55:27 -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 x47CtIXc014711; Tue, 7 May 2019 08:55:18 -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; Tue, 7 May 2019 08:54:53 -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; Tue, 7 May 2019 08:55:24 -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; Tue, 7 May 2019 08:55:24 -0400 From: Justin Richer To: Hans Zandbelt CC: oauth Thread-Topic: [OAUTH-WG] XYZ and Transactional OAuth Thread-Index: AQHVBEP7W/TPKVA82ke/Vd+HgyQ+VKZe0xkAgAEPsgA= Date: Tue, 7 May 2019 12:55:24 +0000 Message-ID: References: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@mit.edu> In-Reply-To: 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_A19D943C82AB48758103A5C123DF620Cmitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] XYZ and Transactional OAuth 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, 07 May 2019 12:55:30 -0000 --_000_A19D943C82AB48758103A5C123DF620Cmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0F1dGggMiBpcyBkZWZpbml0ZWx5IG5vdCBnb2luZyBhbnl3aGVyZSBhbnkgdGltZSBzb29uLiBJ dCBzb2x2ZXMgYSBzdWl0ZSBvZiBwcm9ibGVtcyByZWFsbHkgd2VsbCwgaW4gYSB3YXkgdGhhdCBk ZXZlbG9wZXJzIGNhbiBnZXQgcmlnaHQgbW9yZSBvZnRlbiB0aGFuIG5vdC4gRXZlbiBzbywgSSB0 aGluayBpdOKAmXMgdGltZSB0byBzdGFydCBsb29raW5nIHRvd2FyZCB3aGF04oCZcyBuZXh0LiBJ dOKAmXMgbm90IHVwIHRvIG1lIHdoZXRoZXIgdGhpcyBkZXNlcnZlcyB0aGUgT0F1dGggYnJhbmRp bmcgb3Igbm90LCBidXQgSSB3YW50ZWQgcGVvcGxlIHRvIGJvdGggYmUgYXdhcmUgb2YgdGhlIHdv cmsgYW5kIHRvIHN0YXJ0IHRoZSBjb252ZXJzYXRpb24gb24gaXQuIEkgdGhpbmsgdGhlcmXigJlz IHNvbWUgZ29vZCB3b3JrIHRoYXQgd2UgY2FuIGRvIGhlcmUuDQoNCuKAlCBKdXN0aW4NCg0KT24g TWF5IDYsIDIwMTksIGF0IDQ6NDIgUE0sIEhhbnMgWmFuZGJlbHQgPGhhbnMuemFuZGJlbHRAem1h cnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4+IHdyb3RlOg0KDQpP QXV0aCAyLjAgaGFzIGl0cyBtZXJpdHMgYW5kIHdpbGwgYmUgYXJvdW5kIGZvciB0aGUgbmV4dCAy MCB5ZWFycyBvciBzbzsgeWV0IHdlJ3JlIGJ1bXBpbmcgaW50byBpdHMgbGltaXRhdGlvbnMgZXZl cnkgZGF5IGlmIG5vdCBvbmx5IGZvciBpdHMgY29tcGxleGl0eSBhbmQgdGhlIGluY29tcHJlaGVu c2liaWxpdHkgZm9yIHJlZ3VsYXIgSVQgcGVlcHMgdGhhdCBkb24ndCBoYXZlIHRoZSBmdWxsIGhp c3RvcmljYWwgYmFja2dyb3VuZDsgc3VwcG9ydCBmb3IgdHJhbnNhY3Rpb25zIGlzIG9idmlvdXNs eSBtaXNzaW5nIHRvZGF5OyBJJ20gaW4gZm9yIHNpbXBsaWZ5aW5nIHRoaW5ncywgY29sbGFwc2lu ZyByZXF1ZXN0IHBhcmFtZXRlcnMsIHVzZSBjYXNlcywgUENLRSwgUE9QIGV0Yy4gaW4gYSBub24t YmFja3dhcmRzIGNvbXBhdGlibGUgcHJvdG9jb2wgYW5kIHN1Z2dlc3QgdG8gYWRvcHQgc29tZXRo aW5nIHNpbWlsYXIgdG8gd2hhdCB5b3UgcHJvcG9zZSB0byBiZWNvbWUgT0F1dGggMy4wICh0aGVy ZSwgSSBzYWlkIGl0IDstKSkNCg0KSGFucy4NCg0KT24gTW9uLCBNYXkgNiwgMjAxOSBhdCA4OjQ0 IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1 Pj4gd3JvdGU6DQpJbiBhIHZlaW4gcmVsYXRlZCB0byBUb3JzdGVu4oCZcyByZWNlbnQgdGhyZWFk IGFuZCBibG9nIHBvc3QsIEnigJl2ZSBhbHNvIGJlZW4gd29ya2luZyBvbiBhIHByb3Bvc2FsIGFy b3VuZCBUcmFuc2FjdGlvbmFsIE9BdXRoLiBBcyBtYW55IG9mIHlvdSBrbm93LCBJIHdyb3RlIGEg YmxvZyBwb3N0IGFib3V0IHRoZSBiYXNpYyBpZGVhIGxhc3QgZmFsbCwgYW5kIG5vdyBJ4oCZdmUg Z290IHNvbWV0aGluZyBhIGJpdCBtb3JlIGNvbmNyZXRlIG9ubGluZSB0aGF0IHBlb3BsZSBjYW4g cG9rZSBhcm91bmQgd2l0aC4gSeKAmW0gY2FsbGluZyBpdCDigJxYWVrigJ0ganVzdCB0byBnaXZl IGl0IGEgbmFtZSwgYW5kIGl04oCZcyBvbmxpbmUgaGVyZToNCg0KaHR0cHM6Ly9vYXV0aC54eXov DQoNCkkgbmVlZCB0byBiZSB2ZXJ5IGNsZWFyOiBUaGlzIGlzIG5vdCB3aXJlLWNvbXBhdGlibGUg d2l0aCBPQXV0aDIsIGJ1dCBpcyBpbnN0ZWFkIGEgdHJhbnNhY3Rpb25hbCAoaW50ZW50LXBhdHRl cm4pIHByb3RvY29sIHRoYXQgaW1wbGVtZW50cyBhIGxvdCBvZiB0aGUgY29yZSBjb25jZXB0cyBh bmQgYSBmZXcgbmV3IG9uZXMgaW4gYSBkaWZmZXJlbnQgZnJhbWV3b3JrLiBUaGVyZSBoYXZlIGJl ZW4gYSBsb3Qgb2YgYXR0ZW1wdHMgdG8gZXh0ZW5kIGFuZCBhZGFwdCBPQXV0aCBpbiB0aGUgbGFz dCBmZXcgeWVhcnMsIGFuZCBpbiBteSBvcGluaW9uIHRoYXTigJlzIGdvdHRlbiB1cyBwYWludGVk IGludG8gYSBiaXQgb2YgYSBjb3JuZXIgYXMgd2Uga2VlcCB0cnlpbmcgdG8gc29sdmUgbmV3IHBy b2JsZW1zLiBCeSBicmVha2luZyBhd2F5IGZyb20gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIEkg Zm91bmQgdGhhdCB3YXMgYWJsZSB0byBib3RoIHNpbXBsaWZ5IGEgbG90IG9mIHRoZSBjb25jZXB0 cywgbWFrZSBkaWZmZXJlbnQgYWN0aW9ucyBtb3JlIGNvbnNpc3RlbnQsIGFuZCBtYWtlIGl0IG1v cmUgd2lkZWx5IGZsZXhpYmxlLg0KDQpBbHNvIHRvIG5vdGUsIEnigJl2ZSByZWFkIHRocm91Z2gg VG9yc3RlbuKAmXMgZHJhZnQsIGFuZCBJIHRoaW5rIHRoYXQgaGlzIGlkZWFzIG9mIHdoYXTigJlz IGluIGEg4oCcU3RydWN0dXJlZCBTY29wZeKAnSBjb3VsZCBiZSBhIHJlcGxhY2VtZW50IGZvciB0 aGUgaGFuZC13YXZpbmcgaWRlYSBJIGhhdmUgaW4gdGhlIOKAnHJlc291cmNlc+KAnSBzZWN0aW9u IG9mIFhZWi4gSeKAmW0gY29udGludWluZyBkZXZlbG9wbWVudCBvZiB0aGlzIHByb3RvY29sLCBp bmNsdWRpbmcgYSBjb3VwbGUgdG95IGltcGxlbWVudGF0aW9ucywgYWxsIG9mIHRoZW0gb3BlbiBz b3VyY2UuIEkgaGF2ZSBzdGFydGVkIGEgd3JpdGV1cCBpbiBzcGVjLWxhbmd1YWdlLCBhbmQgSSBw bGFuIHRvIGhhdmUgaXQgY2xlYW5lZCB1cCBhbmQgc3VibWl0dGVkIHByaW9yIHRvIE1vbnRyZWFs IOKAlCB3aGVyZSBJ4oCZbGwgYmUgYXR0ZW5kaW5nIGluIHBlcnNvbiBhbmQgaG9wZSB0byBkaXNj dXNzIHRoaXMgYXMgYSBwb3RlbnRpYWwgV0cgaXRlbS4NCg0K4oCUIEp1c3Rpbg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1h cnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJ QU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93d3cuem1hcnR6b25lLmV1Lz4NCg0K --_000_A19D943C82AB48758103A5C123DF620Cmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9BdXRoIDIgaXMgZGVmaW5pdGVseSBub3QgZ29p bmcgYW55d2hlcmUgYW55IHRpbWUgc29vbi4gSXQgc29sdmVzIGEgc3VpdGUgb2YgcHJvYmxlbXMg cmVhbGx5IHdlbGwsIGluIGEgd2F5IHRoYXQgZGV2ZWxvcGVycyBjYW4gZ2V0IHJpZ2h0IG1vcmUg b2Z0ZW4gdGhhbiBub3QuIEV2ZW4gc28sIEkgdGhpbmsgaXTigJlzIHRpbWUgdG8gc3RhcnQgbG9v a2luZyB0b3dhcmQgd2hhdOKAmXMgbmV4dC4gSXTigJlzIG5vdCB1cCB0byBtZSB3aGV0aGVyIHRo aXMgZGVzZXJ2ZXMNCiB0aGUgT0F1dGggYnJhbmRpbmcgb3Igbm90LCBidXQgSSB3YW50ZWQgcGVv cGxlIHRvIGJvdGggYmUgYXdhcmUgb2YgdGhlIHdvcmsgYW5kIHRvIHN0YXJ0IHRoZSBjb252ZXJz YXRpb24gb24gaXQuIEkgdGhpbmsgdGhlcmXigJlzIHNvbWUgZ29vZCB3b3JrIHRoYXQgd2UgY2Fu IGRvIGhlcmUuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA2 LCAyMDE5LCBhdCA0OjQyIFBNLCBIYW5zIFphbmRiZWx0ICZsdDs8YSBocmVmPSJtYWlsdG86aGFu cy56YW5kYmVsdEB6bWFydHpvbmUuZXUiIGNsYXNzPSIiPmhhbnMuemFuZGJlbHRAem1hcnR6b25l LmV1PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+T0F1dGggMi4wIGhhcyBpdHMgbWVyaXRzIGFuZCB3aWxsIGJlIGFy b3VuZCBmb3IgdGhlIG5leHQgMjAgeWVhcnMgb3Igc287IHlldCB3ZSdyZSBidW1waW5nIGludG8g aXRzIGxpbWl0YXRpb25zIGV2ZXJ5IGRheSBpZiBub3Qgb25seSBmb3IgaXRzIGNvbXBsZXhpdHkg YW5kIHRoZSBpbmNvbXByZWhlbnNpYmlsaXR5Jm5ic3A7Zm9yIHJlZ3VsYXIgSVQgcGVlcHMgdGhh dCBkb24ndCBoYXZlIHRoZSBmdWxsIGhpc3RvcmljYWwNCiBiYWNrZ3JvdW5kOyBzdXBwb3J0IGZv ciB0cmFuc2FjdGlvbnMgaXMgb2J2aW91c2x5IG1pc3NpbmcgdG9kYXk7IEknbSBpbiBmb3Igc2lt cGxpZnlpbmcgdGhpbmdzLCBjb2xsYXBzaW5nIHJlcXVlc3QgcGFyYW1ldGVycywgdXNlIGNhc2Vz LCBQQ0tFLCBQT1AgZXRjLiBpbiBhIG5vbi1iYWNrd2FyZHMgY29tcGF0aWJsZSBwcm90b2NvbCBh bmQgc3VnZ2VzdCB0byBhZG9wdCBzb21ldGhpbmcgc2ltaWxhciB0byB3aGF0IHlvdSBwcm9wb3Nl IHRvIGJlY29tZQ0KIE9BdXRoIDMuMCAodGhlcmUsIEkgc2FpZCBpdCA7LSkpDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IYW5zLjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIE1heSA2LCAyMDE5IGF0IDg6 NDQgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIg Y2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBw eCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyIgY2xh c3M9IiI+SW4gYSB2ZWluIHJlbGF0ZWQgdG8gVG9yc3RlbuKAmXMgcmVjZW50IHRocmVhZCBhbmQg YmxvZyBwb3N0LCBJ4oCZdmUgYWxzbyBiZWVuIHdvcmtpbmcgb24gYSBwcm9wb3NhbCBhcm91bmQg VHJhbnNhY3Rpb25hbCBPQXV0aC4gQXMgbWFueSBvZiB5b3Uga25vdywgSSB3cm90ZSBhIGJsb2cg cG9zdCBhYm91dCB0aGUgYmFzaWMgaWRlYSBsYXN0IGZhbGwsIGFuZCBub3cgSeKAmXZlDQogZ290 IHNvbWV0aGluZyBhIGJpdCBtb3JlIGNvbmNyZXRlIG9ubGluZSB0aGF0IHBlb3BsZSBjYW4gcG9r ZSBhcm91bmQgd2l0aC4gSeKAmW0gY2FsbGluZyBpdCDigJxYWVrigJ0ganVzdCB0byBnaXZlIGl0 IGEgbmFtZSwgYW5kIGl04oCZcyBvbmxpbmUgaGVyZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vb2F1dGgueHl6LyIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vb2F1dGgueHl6LzwvYT48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgbmVlZCB0 byBiZSB2ZXJ5IGNsZWFyOiBUaGlzIGlzIG5vdCB3aXJlLWNvbXBhdGlibGUgd2l0aCBPQXV0aDIs IGJ1dCBpcyBpbnN0ZWFkIGEgdHJhbnNhY3Rpb25hbCAoaW50ZW50LXBhdHRlcm4pIHByb3RvY29s IHRoYXQgaW1wbGVtZW50cyBhIGxvdCBvZiB0aGUgY29yZSBjb25jZXB0cyBhbmQgYSBmZXcgbmV3 IG9uZXMgaW4gYSBkaWZmZXJlbnQgZnJhbWV3b3JrLiBUaGVyZSBoYXZlIGJlZW4gYSBsb3Qgb2Yg YXR0ZW1wdHMNCiB0byBleHRlbmQgYW5kIGFkYXB0IE9BdXRoIGluIHRoZSBsYXN0IGZldyB5ZWFy cywgYW5kIGluIG15IG9waW5pb24gdGhhdOKAmXMgZ290dGVuIHVzIHBhaW50ZWQgaW50byBhIGJp dCBvZiBhIGNvcm5lciBhcyB3ZSBrZWVwIHRyeWluZyB0byBzb2x2ZSBuZXcgcHJvYmxlbXMuIEJ5 IGJyZWFraW5nIGF3YXkgZnJvbSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgSSBmb3VuZCB0aGF0 IHdhcyBhYmxlIHRvIGJvdGggc2ltcGxpZnkgYSBsb3Qgb2YgdGhlIGNvbmNlcHRzLA0KIG1ha2Ug ZGlmZmVyZW50IGFjdGlvbnMgbW9yZSBjb25zaXN0ZW50LCBhbmQgbWFrZSBpdCBtb3JlIHdpZGVs eSBmbGV4aWJsZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkFsc28gdG8gbm90ZSwgSeKAmXZlIHJlYWQgdGhyb3VnaCBUb3Jz dGVu4oCZcyBkcmFmdCwgYW5kIEkgdGhpbmsgdGhhdCBoaXMgaWRlYXMgb2Ygd2hhdOKAmXMgaW4g YSDigJxTdHJ1Y3R1cmVkIFNjb3Bl4oCdIGNvdWxkIGJlIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBo YW5kLXdhdmluZyBpZGVhIEkgaGF2ZSBpbiB0aGUg4oCccmVzb3VyY2Vz4oCdIHNlY3Rpb24gb2Yg WFlaLiBJ4oCZbSBjb250aW51aW5nIGRldmVsb3BtZW50IG9mIHRoaXMgcHJvdG9jb2wsDQogaW5j bHVkaW5nIGEgY291cGxlIHRveSBpbXBsZW1lbnRhdGlvbnMsIGFsbCBvZiB0aGVtIG9wZW4gc291 cmNlLiBJIGhhdmUgc3RhcnRlZCBhIHdyaXRldXAgaW4gc3BlYy1sYW5ndWFnZSwgYW5kIEkgcGxh biB0byBoYXZlIGl0IGNsZWFuZWQgdXAgYW5kIHN1Ym1pdHRlZCBwcmlvciB0byBNb250cmVhbCDi gJQgd2hlcmUgSeKAmWxsIGJlIGF0dGVuZGluZyBpbiBwZXJzb24gYW5kIGhvcGUgdG8gZGlzY3Vz cyB0aGlzIGFzIGEgcG90ZW50aWFsIFdHIGl0ZW0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4N CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xlYXI9ImFs bCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KLS0gPGJy IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOnNt YWxsIiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTpzbWFsbCIgY2xhc3M9IiI+Wm1hcnRab25lIElB TSAtIDxhIGhyZWY9Imh0dHA6Ly93d3cuem1hcnR6b25lLmV1LyIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPg0Kd3d3LnptYXJ0em9uZS5ldTwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A19D943C82AB48758103A5C123DF620Cmitedu_-- From nobody Tue May 7 05:57: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 3CFEB12012D for ; Tue, 7 May 2019 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ER-J2Rx2vuxN for ; Tue, 7 May 2019 05:57:49 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 BBB6412012C for ; Tue, 7 May 2019 05:57:48 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id z128so7422575qkb.6 for ; Tue, 07 May 2019 05:57:48 -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=G3YLN9CpHuzGOH5hSraNzEvtZDn/AJkZNLOHoyGoQ6c=; b=gzVk8x4k8EftzdM7D6VGAB4WL+wzBFyVMR7b1FimPrJW9js09sB0+w5hIIZ758f67b hcwtd/IAZCdjUaQ8opamHxGPjH0Oed4YEQUS4/aHkLeOqiUMDtZQeAFeSXmkxWlHeeX4 cxUC7Rt+l7xH4w7eCDqNvfvQQCaOVubYQQfJeZF1r8uSK+j5Gaia3O6ZVZqGwM5v116I ftTo7bR5QeFH1qj4l/vFRzJXj1y5SScjz+dM2VIRmT1Ktol5cIWB9jDgOvfrj0oPphns K6gO8Q3PaNYMkL2vxTrU+zewpxEo1KBLRAeYLlEckNgtLWwTfFekf9sZ/IGAejB3yi1v efHA== 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=G3YLN9CpHuzGOH5hSraNzEvtZDn/AJkZNLOHoyGoQ6c=; b=A+LlAPZU7JftJMaefjIv8K555WlE75ptxoHxGSUWfGY6VTpUmrXtBLAmU8NqdNxsdW B9Wq1fsBTLah6KqNxQJAA+BiiTIneTlA1fUOAMXE1A9RbYZPMRt/aN543oVZfRmFbhrt BaJ9X2atPRsrQEOvvlJDL3gnmo7BTJGX4mkNqowSQo7+WQh6vggT239bvpyv7IRcRcpt D5oc58UYwxuBiM+Fjp6h1ZnbvRX8uYpR2eqRqWWvl16XODKGmUM1c6K6g3kAok42hHGD HAY2x1SpTrGBqj7k43pxdCeQEjBX8BL+UmF1QaSTc5qQSVjln05yiEKfkwfHaq55zwkQ jqZw== X-Gm-Message-State: APjAAAXDd1+Fjtq6bF1rrhX67ctIwXbQOdcAltFKNk5d9arzyJjwf3AI suieGIbQ8WBYtWlTQvW9Sg+9O7On9BNCoNANFFrXAQ== X-Google-Smtp-Source: APXvYqyskNj+IFOjkteNneWGXuYjVUNUaxIj+0VCyIs672MbW5g5QZVBMj3tEUWI64sKsPk0dMiC0+nzepKUwz1jQsg= X-Received: by 2002:a37:a24b:: with SMTP id l72mr9829459qke.166.1557233867195; Tue, 07 May 2019 05:57:47 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> In-Reply-To: From: Hans Zandbelt Date: Tue, 7 May 2019 13:57:35 +0100 Message-ID: To: Neil Madden Cc: Vittorio Bertocci , Karl McGuinness , John Bradley , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000007c97c905884bc3a9" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 12:57:55 -0000 --0000000000007c97c905884bc3a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Vladimir: we don't want the RS to know about grant types since these are extensible and there may be more than one grant type that has client credentials like semantics [1] Hans. [1] I can think of a new "referred_client_credentials" grant type that doesn't return its tokens directly from the token endpoint but refers to a remote endpoint and hands out creds for the call to that endpoint On Tue, May 7, 2019 at 10:16 AM Neil Madden wrote: > Ah, that makes sense. Well, we already add a grant_type claim to our > JWT-based access tokens, so I=E2=80=99m in favour of that solution :-) > > > On 7 May 2019, at 09:48, Vittorio Bertocci wrote: > > Thanks Neil, one more reason to avoid that. > TL;DR, > The context is the discussion we had pre-IIW about whether sub should be > included always or only for tokens issued to ROs. Some exiting > implementations rely on that heuristic. > Turns out that 7519 has language suggesting sub should be there for both > tokens issued for the RO and for apps (via client creds, etc). > We don't want to contradict 7519 but we also want to preserve the ability > for a RS to tell whether an AT was issued via RO auth or app auth, hence > the discussion. Suggestions ranged from adding a grant_type claim (Vlad > made a convincing argument against it), to relying to the client_id=3D=3D= sub > heuristic (which i pushed back on) to the introduction of a new claim (na= me > TBD given that sub_type is taken already) that can explicitly declare > whether the token has been issued authenticating th RO or via app > credentials. > > On Tue, May 7, 2019 at 1:37 AM Neil Madden > wrote: > >> I wasn=E2=80=99t at IIW so I may be missing some context. >> >> There is a potential security issue if the client_id is used as the =E2= =80=9Csub=E2=80=9D >> for an AT obtained via client_credentials. If the client can register >> itself with a self-chosen client_id then it may deliberately chose a >> client_id that matches the user name of a privileged user. An RS that ju= st >> blindly looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously le= t the client >> perform privileged actions. >> >> Is this the context of the discussion? >> >> Given that there are a lot of RSes in existence, many of which are >> probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the= resource owner, I >> think the onus is on the AS to ensure that no such ambiguity can arise i= n >> the first place by ensuring that the space of =E2=80=9Csub=E2=80=9D valu= es for client >> credentials is disjoint with the space for genuine users or by disallowi= ng >> the client_credentials grant altogether. >> >> This issue already arises in token introspection though, so maybe ought >> to be mentioned in the OAuth security topics draft rather than specific = to >> the JWT AT draft? >> >> =E2=80=94 Neil >> >> On 6 May 2019, at 18:32, Vittorio Bertocci < >> Vittorio=3D40auth0.com@dmarc.ietf.org> wrote: >> >> Hi all, >> thanks for your patience during this month long hiatus, and thanks for >> the comments. >> Last week at IIW I had the opportunity to discuss this with many of the >> people on the list. Here's a summary of where the discussion landaed on = the >> subject of the sub (pun intended). >> >> - It seems that RFC 7519 has pretty clear language on the use of sub- I >> didn't check it back when we started the discussion. I do agree with the >> people saying that we shouldn't violate existing specifications, hence i= t >> looks like we do need to have sub also in the case in which we have >> app-only tokens carrying claims about the app itself. I understand this >> will cause some implementation to break, but unfortunately that's intrin= sic >> in the process of coming up with a common approach and standards complia= nce >> is probably one of the strongest reasons to tolerate that. >> - That said, I am strongly committed to preserve existing functionality. >> One of the main reasons that was brought up for including sub only for u= ser >> based ATs was to use it as heuristic for telling those tokens apart from >> app-only ones. To that end, *Karl MCGuinness suggested that we include >> grant_type as a return claim, which the RS could use to the same effect*= . >> I find the proposal very clever, and the people at IIW thought so as wel= l. >> What you think? >> Note, *John Bradley* observed that in some cases this might lead to >> ambiguous results if an extension grant is used (say an assertion profil= e) >> but that seems like a relatively fringe occurrence. >> >> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt >> wrote: >> >>> I also meant to say that (of course) the JWT standard doesn't say that >>> the JWT is supposed to be about the client or about the resource owner, >>> hence both are valid >>> >>> Hans. >>> >>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones >>> wrote: >>> >>>> I get that existing practice is likely to be all over the map, but if >>>> we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reas= onable to require >>>> that the claims usage comply with the JWT standards. >>>> >>>> >>>> >>>> -- Mik= e >>>> >>>> >>>> >>>> *From:* Hans Zandbelt >>>> *Sent:* Thursday, April 4, 2019 12:59 PM >>>> *To:* Mike Jones >>>> *Cc:* George Fletcher >>> <40aol.com@dmarc...ietf.org>>; Vittorio Bertocci >>> 40auth0.com@dmarc.ietf.org>; IETF oauth WG >>>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>> >>>> >>>> >>>> the definition of RFC 7519 is actually "petitio principii" and a lot o= f >>>> deployments put claims about the Resource Owner in the access token (a= s a >>>> Resource Server implementer I've suffered a lot from this) >>>> >>>> >>>> >>>> Hans. >>>> >>>> >>>> >>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones >>>> wrote: >>>> >>>> I agree with George that the subject of a token must be the principal >>>> of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. = Indeed, the first >>>> sentence of the =E2=80=9Csub=E2=80=9D definition at >>>> https://tools.ietf.org/html/rfc7519#section-4.1.2 is: >>>> >>>> The "sub" (subject) claim identifies the principal that is the subject >>>> of the JWT. >>>> >>>> >>>> >>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply w= ith the >>>> definition from RFC 7519. >>>> >>>> >>>> >>>> -- Mik= e >>>> >>>> >>>> >>>> *From:* OAuth *On Behalf Of *George Fletcher >>>> *Sent:* Thursday, April 4, 2019 8:51 AM >>>> *To:* Hans Zandbelt >>>> *Cc:* Vittorio Bertocci ; IETF >>>> oauth WG >>>> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>> >>>> >>>> >>>> The more I think about this the more I land in the "No" camp. >>>> >>>> The subject of a token should be the principal of that token. It >>>> shouldn't matter whether that is a machine, a user, or a device. Tryin= g to >>>> separate out "humans" as a special class will just make things more >>>> complicated. If we need a claim to identify the subject is a "human" t= hen >>>> why not just add that. This doesn't break anything and makes it easy f= or >>>> people to detect this case in those use cases where it's required. >>>> >>>> Thanks, >>>> George >>>> >>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>>> >>>> I will argue that in a way such deployments are already broken e.g. in >>>> the typical use case of onboarding client accounts in the same >>>> directory/OU/namespace as user accounts and we don't need to cater for >>>> that. >>>> >>>> >>>> >>>> Hans. >>>> >>>> >>>> >>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher >>>> wrote: >>>> >>>> I agree that this will break a lot of existing flows... especially >>>> those using any form of the client_credentials flow. In that sense I'm= not >>>> completely on board yet :) >>>> >>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>>> >>>> great summary! this will hurt quite a few existing m2m deployments but >>>> I do like the rigidness of it all: it is very explicit, cannot >>>> misinterpreted and thus prevents failure (which is really what Dominic= k is >>>> after); I'm on board >>>> >>>> >>>> >>>> Hans. >>>> >>>> >>>> >>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci >>> 40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> thank you Steinar and everyone else for the comments on this! >>>> >>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >>>> Bertrand recommend using sub only for users. Martin would like to have= the >>>> sub for app only flows as well. Hans is neutral. >>>> >>>> That does sound like the sub as user has more consensus, tho before >>>> changing it I'd wait for the people currently at IETF104 to have more = time >>>> to comment as well. >>>> >>>> Clarification. If the goal is to be able to apply the logic "if there'= s >>>> a sub, it's a user flow", we have to explicitly disallow (MUST NOT) th= e use >>>> of sub when that's not the case. Are all OK with it? >>>> >>>> >>>> >>>> Dave, the suggestion of having explicit typing for app only vs user >>>> only is interesting! For the purpose of putting together an interopera= ble >>>> profile, tho, I would suggest we table it for v1 in the interest of ge= tting >>>> to something easy to adopt (hence with small delta vs existing >>>> implementations) faster. >>>> >>>> >>>> >>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: >>>> >>>> Hi Vittorio, we (the national federation-gateway for the health >>>> services in norway - "HelseID") think his is a really valuable initia= tive! >>>> >>>> We also agree with Dominick concerning definition of the "sub" claim. >>>> >>>> >>>> >>>> Steinar >>>> >>>> >>>> >>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >>>> dbaier@leastprivilege.com>: >>>> >>>> From an access token consumer (aka API) developer point of view, I >>>> prefer this logic >>>> >>>> >>>> >>>> "If sub is present - client acts on behalf of a user, if not - not." >>>> >>>> >>>> >>>> Anything more complicated has a potential of going wrong. >>>> >>>> >>>> >>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> >>>> >>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>> >>>> I haven=E2=80=99t seen such implementations, but user-select username = as sub, >>>> or incremental integer as sub & client_id will be easily collide. >>>> >>>> >>>> >>>> If you can enforce collision resistant IDs between user & client >>>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>> >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote= : >>>> >>>> Hey Nov, Dominick, Hans- >>>> >>>> thanks for the comments. That was an area I was expecting to cause mor= e >>>> discussion, and I am glad we are having this opportunity to clarify. >>>> >>>> The current language in the draft traces the etymology of sub to OpenI= D >>>> Connect core, hence Dominick observation is on point. However in the >>>> description I express something in line with 7519, which was in fact m= y >>>> intent. >>>> >>>> >>>> >>>> The idea was to provide an identifier of the calling subject that is >>>> guaranteed to be present in all cases- this would allow an SDK develop= er to >>>> use the same code for things like lookups and membership checks regard= less >>>> of the nature of the caller (user in a delegated case, app in app-only >>>> grants). The information to discriminate between user and app callers = is >>>> always available in the token (say, the caller is a user if sub!=3Dcli= ent_id, >>>> where client_id is always guaranteed to be present as well) hence ther= e's >>>> no loss in expressive power, should that difference be relevant for th= e >>>> resource server. >>>> >>>> >>>> >>>> Dominick, Hans- I probably missed the security issue you guys are >>>> thinking of in this case. Of course, if this would introduce a risk I >>>> completely agree it should be changed- I'd just like to understand bet= ter >>>> the problem. Could you expand it in a scenario/use case to clarify the= risk? >>>> >>>> Nov- playing this back: is the concern that a user and a client might >>>> have the same identifier within an IDP? When using collision resistant= IDs, >>>> as it is usually the case, that seems to be a remote possibility- did = you >>>> stumble in such scenario in production? >>>> >>>> >>>> >>>> Thanks >>>> >>>> V. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>>> hans.zandbelt@zmartzone.eu> wrote: >>>> >>>> I believe there are plenty of OAuth 2.0 only use cases out there... bu= t >>>> nevertheless I agree with the potential confusion and thus security >>>> problems arising from that (though one may argue the semantics are the >>>> same). >>>> >>>> >>>> >>>> Hans. >>>> >>>> >>>> >>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>> Yes I know - and I think in hindsight it was a mistake to use the same >>>> claim type for multiple semantics. >>>> >>>> >>>> >>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more >>>> complicated than they need to be - in my experience almost no-one (tha= t I >>>> know) does OIDC only - nor OAuth only. They always combine it. >>>> >>>> >>>> >>>> In reality this leads to potential security problems - this spec has >>>> the potential to rectify the situation. >>>> >>>> >>>> >>>> Dominick >>>> >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>> hans.zandbelt@zmartzone.eu) wrote: >>>> >>>> Without agreeing or disagreeing: OIDC does not apply here since it is >>>> not OAuth and an access token is not an id_token. >>>> >>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2= : >>>> >>>> >>>> >>>> "The "sub" (subject) claim identifies the principal that is the >>>> >>>> subject of the JWT. The claims in a JWT are normally statements >>>> >>>> about the subject. The subject value MUST either be scoped to be >>>> >>>> locally unique in the context of the issuer or be globally unique. >>>> >>>> The processing of this claim is generally application specific" >>>> >>>> >>>> >>>> which kind of spells "client" in case of the client credentials grant >>>> but I also do worry about Resource Servers thinking/acting only in ter= ms of >>>> users >>>> >>>> >>>> >>>> Hans. >>>> >>>> >>>> >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>> IMHO the sub claim should always refer to the user - and nothing else. >>>> >>>> >>>> >>>> OIDC says: >>>> >>>> >>>> >>>> "Subject - Identifier for the End-User at the Issuer." >>>> >>>> >>>> >>>> client_id should be used to identify clients. >>>> >>>> >>>> >>>> cheers >>>> >>>> Dominick >>>> >>>> >>>> >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> >>>> >>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>> >>>> >>>> >>>> One feedback. >>>> >>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end= -user and client, >>>> in this spec. >>>> >>>> It requires those 2 types of identifiers to be unique each other in th= e >>>> IdP context. >>>> >>>> >>>> >>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such >>>> constraint needed. >>>> >>>> >>>> >>>> thanks >>>> >>>> >>>> >>>> nov >>>> >>>> >>>> >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> >>>> >>>> Dear all, >>>> >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt= / >>>> . >>>> >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JW= T for >>>> their access token. The intent and scenarios addressed by those sol= utions >>>> are mostly the same across vendors, but the syntax and interpretati= ons in >>>> the implementations are different enough to prevent developers from= reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK Y= OU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens an= d >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_= -_a_jwt_profile_for_ats.pptx >>>> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedbac= k and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvi= nov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a no= te and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. R= ifaat, >>>> Hannes and above all Brian were all super helpful in negotiating th= e >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the proc= ess. >>>> This is an amazing community. >>>> >>>> V. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000007c97c905884bc3a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Vladimir: we don't want = the RS to know about grant types since these are extensible and there may b= e more than one grant type that has client credentials like semantics [1]

Hans.

[1] I can think of a new "referred_client_credent= ials" grant type that doesn't return its tokens directly from the = token endpoint but refers to a remote endpoint and hands out creds for the = call to that endpoint


On= Tue, May 7, 2019 at 10:16 AM Neil Madden <neil.madden@forgerock.com> wrote:
Ah, that makes sense. Well, we already add a grant_type claim to ou= r JWT-based access tokens, so I=E2=80=99m in favour of that solution :-)

On 7 May 2019, at = 09:48, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Nei= l, one more reason to avoid that.
TL;DR,=C2=A0
The context is= the discussion we had pre-IIW about whether sub should be included always = or only for tokens issued to ROs. Some exiting implementations rely on that= heuristic.
Turns out that 7519 has language suggesting sub shoul= d be there for both tokens issued for the RO and for apps (via client creds= , etc).
We don't want to contradict 7519 but we also want to preserv= e the ability for a RS to tell whether an AT was issued via RO auth or app = auth, hence the discussion. Suggestions ranged from adding a grant_type cla= im (Vlad made a convincing argument against it), to relying to the client_i= d=3D=3Dsub heuristic (which i pushed back on) to the introduction of a new = claim (name TBD given that sub_type is taken already) that can explicitly d= eclare whether the token has been issued authenticating th RO or via app cr= edentials.

On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.madden@forgerock.co= m> wrote:
I wasn=E2=80=99t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the= =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the cl= ient can register itself with a self-chosen client_id then it may deliberat= ely chose a client_id that matches the user name of a privileged user. An R= S that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may then erron= eously let the client perform privileged actions.

= Is this the context of the discussion?

Given that = there are a lot of RSes in existence, many of which are probably just looki= ng at the =E2=80=9Csub=E2=80=9D claim to identify the resource owner, I thi= nk the onus is on the AS to ensure that no such ambiguity can arise in the = first place by ensuring that the space of =E2=80=9Csub=E2=80=9D values for = client credentials is disjoint with the space for genuine users or by disal= lowing the client_credentials grant altogether.

Th= is issue already arises in token introspection though, so maybe ought to be= mentioned in the OAuth security topics draft rather than specific to the J= WT AT draft?

=E2=80=94 Neil

On 6 May 2019, at 18:32, Vittorio Bertocci <Vittori= o=3D40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this month lo= ng hiatus, and thanks for the comments.
Last week at IIW I had th= e opportunity to discuss this with many of the people on the list. Here'= ;s a summary of where the discussion landaed on the subject of the sub (pun= intended).

- It seems that RFC 7519 has pretty cl= ear language on the use of sub- I didn't check it back when we started = the discussion. I do agree with the people saying that we shouldn't vio= late existing specifications, hence it looks like we do need to have sub al= so in the case in which we have app-only tokens carrying claims about the a= pp itself. I understand this will cause some implementation to break, but u= nfortunately that's intrinsic in the process of coming up with a common= approach and standards compliance is probably one of the strongest reasons= to tolerate that.
- That said, I am strongly committed to preser= ve existing functionality. One of the main reasons that was brought up for = including sub only for user based ATs was to use it as heuristic for tellin= g those tokens apart from app-only ones. To that end, Karl MCGuinness= suggested that we include grant_type as a return claim, which the RS c= ould use to the same effect. I find the proposal very clever, and the p= eople at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous results if an e= xtension grant is used (say an assertion profile) but that seems like a rel= atively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbel= t <hans.= zandbelt@zmartzone.eu> wrote:
I also meant to say that (of course) = the JWT standard doesn't say that the JWT is supposed to be about the c= lient or about the resource owner, hence both are valid

= Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com= > wrote:

I get that existing practice = is likely to be all over the map, but if we=E2=80=99re to create a JWT acce= ss token standard, it=E2=80=99s reasonable to require that the claims usage= comply with the JWT standards.

=C2=A0

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

=C2=A0

From: Hans Zandb= elt <han= s.zandbelt@zmartzone.eu>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio B= ertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

the definition of RFC 7519 is actually "pe= titio principii" and a lot of deployments put claims about the Resourc= e Owner in the access token (as a Resource Server implementer I've suff= ered a lot from this)

=C2=A0

Hans.

=C2=A0

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com> wrote:

I agree with= George that the subject of a token must be the principal of that token.=C2= =A0 That what the JWT =E2=80=9Csub=E2=80=9D claim is for.=C2=A0 Indeed, the= first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:<= /u>

The "sub" (= subject) claim identifies the principal that is the subject of the JWT.

=C2=A0

If an access token uses =E2=80=9Csub=E2=80=9D, its usage = must comply with the definition from RFC 7519.

=C2=A0<= u>

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

=C2=A0

= From: OAuth <oauth-bounces@ietf.org> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF o= auth WG <oauth@ietf.= org>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<= /u>

=C2=A0

The more I think about this the more I land in the "No" camp.=

The subject of a token should be the principal of that token. It shouldn= 9;t matter whether that is a machine, a user, or a device. Trying to separa= te out "humans" as a special class will just make things more com= plicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break = anything and makes it easy for people to detect this case in those use case= s where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:<= u>

I will argue that in a way such deployments are= already broken e.g. in the typical use case of onboarding client accounts = in the same directory/OU/namespace as user accounts and we don't need to cater for that.

=C2=A0

Hans.

=C2=A0

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher= <gffletch@aol.com= > wrote:

I agree that this will break a lot of existi= ng flows... especially those using any form of the client_credentials flow.= In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few exist= ing m2m deployments but I do like the rigidness of it all: it is very expli= cit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

=C2=A0

Hans.

=C2=A0

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertoc= ci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:

thank you Steinar and everyone else for the com= ments on this!

To summarize the situation so far: Dominick, St= einar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin= would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more c= onsensus, tho before changing it I'd wait for the people currently at I= ETF104 to have more time to comment as well.

Clarification. If the goal is to be able to app= ly the logic "if there's a sub, it's a user flow", we hav= e to explicitly disallow (MUST NOT) the use of sub when that's not the = case. Are all OK with it?

=C2=A0

Dave, the suggestion of having explicit typing = for app only vs user only is interesting! For the purpose of putting togeth= er an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence wit= h small delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0

=C2=A0

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem &l= t;steinar@udelt.no> wrote:

Hi Vittorio, we=C2=A0 (the national federation-= gateway for the health services in norway - "HelseID")=C2=A0 thin= k his is a really valuable initiative!

We also agree with Dominick concerning definiti= on of the "sub" claim.

=C2=A0

<mvh>Steinar</mvh>

=C2=A0

From an access token consumer (aka API) developer point of= view, I prefer this logic

=C2=A0

"If sub is present - client acts on behalf of a user,= if not - not."

=C2=A0

Anything more complicated has a potential of going wrong.<= /span>

=C2=A0<= /u>

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Yeah, I=E2=80=99m concerning user & client = ids collision.

I haven=E2=80=99t seen such implementations, bu= t user-select username as sub, or incremental integer as sub & client_i= d will be easily collide.

=C2=A0

If you can enforce collision resistant IDs betw= een user & client instances, it=E2=80=99ll works fine. I feel its overk= ill though.

=C2=A0

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was= expecting to cause more discussion, and I am glad we are having this oppor= tunity to clarify.

The current language in the draft traces the et= ymology of sub to OpenID Connect core, hence Dominick observation is on poi= nt. However in the description I express something in line with 7519, which was in fact my intent.

=C2=A0

The idea was to provide an identifier of the ca= lling subject that is guaranteed to be present in all cases- this would all= ow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user= in a delegated case, app in app-only grants). The information to discrimin= ate between user and app callers is always available in the token (say, the= caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there= 9;s no loss in expressive power, should that difference be relevant for the= resource server.

=C2=A0

Dominick, Hans- I probably missed the security = issue you guys are thinking of in this case. Of course, if this would intro= duce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scena= rio/use case to clarify the risk?

Nov- playing this back: is the concern that a u= ser and a client might have the same identifier within an IDP? When using c= ollision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in prod= uction?

=C2=A0

Thanks

V.=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt &= lt;hans.zan= dbelt@zmartzone.eu> wrote:

I believe there are plenty of OAuth 2.0 only us= e cases out there... but nevertheless I agree with the potential confusion = and thus security problems arising from that (though one may argue the semantics are the same).

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = <dbaier@l= eastprivilege.com> wrote:

Yes I know - and I think in hindsight it was a mistake to = use the same claim type for multiple semantics.

=C2=A0

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments= are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always c= ombine it.

=C2=A0

In reality this leads to potential security problems - thi= s spec has the potential to rectify the situation.

=C2=A0

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not = apply here since it is not OAuth and an access token is not an id_token.=

=C2=A0

"The "sub" (subject) claim ident= ifies the principal that is the

=C2=A0 =C2=A0subject of the JWT.=C2=A0 The clai= ms in a JWT are normally statements

=C2=A0 =C2=A0about the subject.=C2=A0 The subje= ct value MUST either be scoped to be

=C2=A0 =C2=A0locally unique in the context of t= he issuer or be globally unique.

=C2=A0 =C2=A0The processing of this claim is ge= nerally application specific"

=C2=A0

which kind of spells "client" in case= of the client credentials grant but I also do worry about Resource Servers= thinking/acting only in terms of users

=C2=A0

Hans.

=C2=A0

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = <dbaier@l= eastprivilege.com> wrote:

IMHO the sub claim should always refer to the user - and n= othing else.

=C2=A0

OIDC says:

=C2=A0

"Subject - Identifier for the End-User at the Issuer."

=C2=A0

client_id should be used to identify clients.

=C2=A0

cheers

Dominick

=C2=A0

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

=C2=A0

Thanks for the good starting point of standardi= zing JWT-ized AT.

=C2=A0

One feedback.

The =E2=80=9Csub=E2=80=9D claim can include 2 t= ypes of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be = unique each other in the IdP context.

=C2=A0

I prefer omitting =E2=80=9Csub=E2=80=9D claim i= n 2-legged context, so that no such constraint needed.

=C2=A0

thanks

=C2=A0

nov

=C2=A0

On Mar 25, 2019, at 8:29, Vittorio Bertocci <= ;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

=C2=A0

Dear all,

I just submitted a draft describing a JWT profi= le for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-= jwt/.

I have a slot to discuss this tomorrow at IETF = 104 (I'll be presenting remotely). I look forward for your comments!=

=C2=A0

Here's just a bit of backstory, in case you= are interested in how this doc came to be. The trajectory it followed is s= omewhat unusual.

  • Despite OAuth2 not requiring any specific format for ATs, through the years= I have come across multiple proprietary solution using JWT for their acces= s token. The intent and scenarios addressed by those solutions are mostly t= he same across vendors, but the syntax and interpretations in the implementations are different enough to = prevent developers from reusing code and skills when moving from product to= product.
  • I asked several individuals from key products and services to share with me= concrete examples of their JWT access tokens (THANK YOU Dominick Baier (Id= entityServer),=C2=A0Brian Campbell (PingIden= tity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and d= ifferences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a roug= h interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_= profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Th= x Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, w= hich was incredibly valuable to get tight-loop feedback and incorporate new= ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Loddersted= t,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed gen= erously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't= get credited in the draft, my apologies: please send me a note and I'l= l make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback i= n a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and = above all Brian were all super helpful in negotiating the mysterious syntax= of the RFC format and submission process.

I was blown away by the availability, involveme= nt and willingness to invest time to get things right that everyone demonst= rated in the process. This is an amazing community.=C2=A0

V.

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

=C2=A0

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

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


=C2=A0

--


=C2=A0

--

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


=C2=A0

--

Vennlig hil= sen

=C2=A0

Steinar Noe= m

Partner Ude= lt AS

Systemutvik= ler

=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=A0= www.udelt.no=C2=A0|=C2=A0

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


=C2=A0

--

=C2=A0<= /u>

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


=C2=A0

--

=C2=A0


=C2=A0

--



--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth



--
--0000000000007c97c905884bc3a9-- From nobody Tue May 7 06:03: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 0673D120136 for ; Tue, 7 May 2019 06:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5ICnPHzs9j2 for ; Tue, 7 May 2019 06:03:04 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140053.outbound.protection.outlook.com [40.107.14.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D0212012C for ; Tue, 7 May 2019 06:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BhlCnCzNPlncbmhjhLa38IYi49Hzf+ECr7FYJyGHbjo=; b=W3qkI/LioJx+dBthFBHIbw+5jFOUD7/UVbHDkYNEJky4p2n9N8MgpmPi1Dc/LD+qGKT0P+GYY9nND3XIL9Gzw+dpD+dT18NR6+9KlSvKW6fUCp5dzoLmLvXpfcBoi4sO81aPBZtLOPwj0fU3e3l4mpXOyZxUFRmfJf1xn77n1yE= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4508.eurprd08.prod.outlook.com (20.179.44.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Tue, 7 May 2019 13:03:00 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 13:03:00 +0000 From: Hannes Tschofenig To: Emond Papegaaij , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Exchange status and Resource Indicators Thread-Index: AQHVAcZYNVw6J+P5IESl2t8a8wJK6qZckKcAgAH034CAAR+xoA== Date: Tue, 7 May 2019 13:03:00 +0000 Message-ID: References: <4223569.5sG2vptK2V@papegaaij> <1750829.ebW1fUBprn@papegaaij> In-Reply-To: <1750829.ebW1fUBprn@papegaaij> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7115f77-94a2-40c6-63b6-08d6d2ec552d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4508; x-ms-traffictypediagnostic: DBBPR08MB4508: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(136003)(346002)(199004)(40434004)(189003)(11346002)(64756008)(66446008)(66556008)(74316002)(446003)(66476007)(8936002)(2501003)(66066001)(2906002)(55016002)(486006)(9686003)(6116002)(3846002)(476003)(52536014)(5660300002)(76116006)(305945005)(73956011)(186003)(26005)(66946007)(7736002)(229853002)(81156014)(81166006)(72206003)(110136005)(8676002)(53936002)(71190400001)(86362001)(102836004)(71200400001)(6246003)(6506007)(6436002)(5024004)(33656002)(99286004)(7696005)(316002)(76176011)(256004)(14444005)(25786009)(68736007)(14454004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4508; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eE8qt8Gc7Z1YInDW7Rn7z3HOGBpKHwEgvUvvaEsY7T2IFye3HY89siOzY2SQXksaW5K+rVxLm4jxClk9jspbj6FiZyNnu2TL/N4ASXjL5Rz6344G7lKtItXj0Z/TcRlls7x2ab4wwS2IT1N+gzEoS0y3KRpX07sEIC7FCJMOOPTd7UjzXs3rZc4UeojqGvO+Ssrs7hEMy/XF988bS7lCgNLO16+h6pGCBn5eLkTzYo0wzUujEBickziNXIzCPMrDm4k4RV0T8y5v2qKcqtF4VXkqQOq3Y7VykzoP2EGangei1Q2NETAedhAycmn4tJov/fqPjq3Yklwbn87lZqCCUSbwDWnpOwSy/7NUeN9UrmFqvWQ6qzurgP2x9UCEKjtqIGxzG/Ya08aHU3n+XnRtXmSbSJJxud8hWyD9Tg2Wy3o= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7115f77-94a2-40c6-63b6-08d6d2ec552d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 13:03:00.2006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4508 Archived-At: Subject: Re: [OAUTH-WG] Token Exchange status and Resource Indicators 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, 07 May 2019 13:03:09 -0000 > > - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'? > > No, that's beyond it's current scope. And it is well past last call in > the WG. But note that a logical identifier can be used as the value of > the resource parameter. The group can define what is in scope of a document and what isn't. I personally think that we should at least talking about the audience param= eter in the resource indicator draft and pointing to the token exchange dra= ft makes a lot of sense because there is a strong relationship between the = two. Deployments are likely to use a mixture of resource and audience depending = on whether they want to express the target service as an absolute URI or a = logical name. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue May 7 06:22: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 A4E1312012C for ; Tue, 7 May 2019 06:22:09 -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 7LMDy-NF59WN for ; Tue, 7 May 2019 06:22:08 -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 E343B12010C for ; Tue, 7 May 2019 06:22:07 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x47DM3iu022387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 May 2019 09:22:05 -0400 Date: Tue, 7 May 2019 08:22:03 -0500 From: Benjamin Kaduk To: Neil Madden Cc: IETF oauth WG Message-ID: <20190507132202.GB19509@kduck.mit.edu> References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> <771DAF49-BF74-4A78-A65F-78B5E94FE081@forgerock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <771DAF49-BF74-4A78-A65F-78B5E94FE081@forgerock.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Off Topic: oauth-bounces 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, 07 May 2019 13:22:10 -0000 On Tue, May 07, 2019 at 10:46:43AM +0100, Neil Madden wrote: > I notice that a few of my emails to the OAuth WG list have come through with the From field from “oauth-bounces”: > > From: OAuth On Behalf Of Neil Madden > > Is this normal? I checked my subscription status on mailman and I’m posting from the same email address that I subscribed from. It's the latest iteration of trying to maintain DMARC compliance when mailing list software redistributes your message. The IETF (well, AMS, LLC) mail servers are presumably not listed as authorized senders for your actual domain, so they rewrite to a From: address they are authorized to send from. -Ben From nobody Tue May 7 07:02: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 4A8E2120157 for ; Tue, 7 May 2019 07:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDUCjZdButIh for ; Tue, 7 May 2019 07:02:16 -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 5B506120141 for ; Tue, 7 May 2019 07:02:16 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id b10so20684901wmj.4 for ; Tue, 07 May 2019 07:02:16 -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=JUru3Ltj4W7oi/2yhyU+Edyt2ejpST2CS7mJOzK6Bhs=; b=JzDna4BclKzN49MNuJzavQtC4+KiI06jPKucUPs3iZgvSwFogd+E4C6+kdDN+wPBQn yzZYQ3gm0CsRo3zT+Kwh9gEx7bRGfxBS25ht6NsGfcORQBbCAvKvF6V80clyPCc9urpS 0dBb/gJ/iK7eoN9/1uQ9jgcc+oACFtaxRRv8BuTUQnJn0jKHNjyKoNuYU+mZD+XuFEAF uIRumZUnJSbW7/wQPbv1VeK3EVJZ7MU1kS5JODaWrwxoEdczNFXV2k17yTpyx/QViBij fKU+qxYnZnMuUYuMbesk2eGT1WFd0iE3RZN4benpGX1n2GGi/nPu0ZD+wyOsU1HPG/EV IYOA== 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=JUru3Ltj4W7oi/2yhyU+Edyt2ejpST2CS7mJOzK6Bhs=; b=dIS4TP/JvWKzXqL8YzUsy8se95TxixNdzcPZnaAwlu4Eq3EPLuTlwR5r4MX7VvBN8a csNxVNXi5LqL6mf9n4mwrVSvt2FkjuUG1Mo55Pv1+x2gOvJnq5zTvsU9mm9QKm77iz9l wDhQ0auvyajK1bY3n2BzxFA2c3MxK3lGmC7w/Oc//uVff/DlCQf35A0MyISPz1D6Ojwk Ot4CFKCdANkbuOKJqYLPOgMPF6gx++20eNDi3r2jrYMVJ+1bHpOZI1RBt5u52RZkWOEu s0bnkitP4EAkJOMQxmtArdgev1BK2mO5M7woXpm5k+FtHxmuteaW4LZaUZ5Rb0oCPI7b 18pA== X-Gm-Message-State: APjAAAUuhKlQ5LdJbeLqKCjAJ9Sbwo9g4XUsl6kZ3x7aBxB+NyP+ZJZM DlK4ddX5uRuXDUr6t6RBQ5ngGV/CaGc6H7zZ5c8SvQ== X-Google-Smtp-Source: APXvYqyVTSWT4xyZSUYSrBUcuS/aA761J9KbmCs+cGs9GXqu8RwJ8acu1u22w7wnifqF4mMUQd9ZttDtCd2iwybYOIo= X-Received: by 2002:a1c:80d7:: with SMTP id b206mr2238430wmd.48.1557237734262; Tue, 07 May 2019 07:02:14 -0700 (PDT) MIME-Version: 1.0 References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> In-Reply-To: From: John Bradley Date: Tue, 7 May 2019 10:02:01 -0400 Message-ID: To: Hannes Tschofenig Cc: Phil Hunt , IETF oauth WG , William Denniss Content-Type: multipart/alternative; boundary="000000000000fb62c705884ca993" Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 07 May 2019 14:02:21 -0000 --000000000000fb62c705884ca993 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The mtls spec doesn't cover the authorization endpoint. Mtls via the browser is a whole world of pain. I believe that for a native app to use mtls via a chrome custom tab or Safari view controller you need to provision a certificate and private key to the system keystore. It is not something that can happen dynamically from the app. That in practice is generally done by proprietary EMM (Enterprise Mobility Management) systems like mobile Iron etc. I think there are also some issues with the app using the same key, it may need to be separately provisioned to the app as well. Each OS and browser has its own twists. It is probably better to explain how to do WebAuthn based authentication via the browser and app. I think there is likely more value in having a WebAuthn based authentication of the app that also attests to the identity of the app than trying to document all the implimented issues with MTLS via the browser. It depends on what the working group thinks is important. John B. On Tue, May 7, 2019, 4:33 AM Hannes Tschofenig wrote: > Hi Phil > > > > I believe this is a question that William and John may be able to answer. > > > > Should MTLS be added to a future version of the Native Apps BCP? If the > answer is =E2=80=9Cno=E2=80=9D, why not? > > > > Ciao > > Hannes > > > > > > *From:* OAuth *On Behalf Of *Phil Hunt > *Sent:* Donnerstag, 2. Mai 2019 20:41 > *To:* oauth > *Subject:* [OAUTH-WG] MTLS and Native apps Best practices > > > > I was wondering if anyone had any recommended MTLS best practices for > mobile apps and native browsers. > > > > Considering Section 6 of RFC8252=E2=80=A6 > > After constructing the authorization request URI, the app uses > > platform-specific APIs to open the URI in an external user-agent. > > Typically, the external user-agent used is the default browser, that > > is, the application configured for handling "http" and "https" scheme > > URIs on the system; however, different browser selection criteria and > > other categories of external user-agents MAY be used. > > > > What choices do developers have to ensure the authorization (and > subsequent user authentication) occur over MTLS? Can the app provide its > own key for MTLS or can it ask that an embedded X.509 cert be used > (assuming one is available)? > > > > Are there any platform issues or best practices? > > > > Phil Hunt | Cloud Security and Identity Architect > > Oracle Corporation, Oracle Cloud Infrastructure > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --000000000000fb62c705884ca993 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The mtls spec doesn't cover the authorization endpoin= t.=C2=A0=C2=A0

Mtls via the br= owser is a whole world of pain.=C2=A0=C2=A0

I believe that for a native app to use mtls via a chrom= e custom tab or Safari view controller you need to provision a certificate = and private key to the system keystore.=C2=A0 It is not something that can = happen dynamically from the app.

That in practice is generally done by proprietary EMM (Enterprise= Mobility Management) systems like mobile Iron etc.=C2=A0

I think there are also some issues with t= he app using the same key, it may need to be separately provisioned to the = app as well.=C2=A0=C2=A0

Each OS and browser has its own twists.=C2=A0=C2=A0

It is probably better to explain how to do Web= Authn based authentication via the browser and app.=C2=A0=C2=A0

I think there is likely more value = in having a WebAuthn based authentication of the app that also attests to t= he identity of the app than trying to document all the implimented issues w= ith MTLS via the browser.

It depends on what the working group thinks is important.=C2=A0

John B.=C2=A0

On Tue, May 7,= 2019, 4:33 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Phil

=C2=A0

I believe this is a question that William and John m= ay be able to answer.

=C2=A0

Should MTLS be added to a future version of the Nati= ve Apps BCP? If the answer is =E2=80=9Cno=E2=80=9D, why not?<= /p>

=C2=A0

Ciao

Hannes

=C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Donnerstag, 2. Mai 2019 20:41
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] MTLS and Native apps Best practices

=C2=A0

I was wondering if anyone had any recommended MTLS b= est practices for mobile apps and native browsers.

=C2=A0

Considering Section 6 of RFC8252=E2=80=A6<= /u>

=C2=A0=C2=A0 After constructing the author=
ization request URI, the app uses
=C2=A0=C2=A0 platform-specific APIs to open the URI in an external use=
r-agent.
=C2=A0=C2=A0 Typically, the external user-agent used is the default br=
owser, that
=C2=A0=C2=A0 is, the application configured for handling "http&qu=
ot; and "https" scheme
=C2=A0=C2=A0 URIs on the system; however, different browser selection =
criteria and
=C2=A0=C2=A0 other categories of external user-agents MAY be used.<=
/u>

=C2=A0

What choices do developers have to ensure the author= ization (and subsequent user authentication) occur over MTLS? Can the app p= rovide its own key for MTLS or can it ask that an embedded X.509 cert be us= ed (assuming one is available)?

=C2=A0

Are there any platform issues or best practices?<= /u>

=C2=A0

Phil Hunt | Cloud Security and Identit= y Architect

Oracle Corporation, Oracle Cloud Infra= structure

@independentid

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--000000000000fb62c705884ca993-- From nobody Tue May 7 07:13:06 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 871CC12013C for ; Tue, 7 May 2019 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=aol.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 giMrc9G0WZ8M for ; Tue, 7 May 2019 07:13:00 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 054AC12006B for ; Tue, 7 May 2019 07:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557238379; bh=GW943BDWVs9GdntlGR8dSGh+u8ir/RL67nD1yRazESA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=OmE/jgJmKCHeck/n3Pz3UVKD2BUuUzMrkRE7/sEb5S7oMaaE9Nun4x+ylB4r8D2ZojFrrb83jm10XDufJ/j6P1JnSBO3Z9la/pPs8XsMZKi7Y3rFjR04VyUw2vP+b2ILepZiZu7q4ScjJrvIyC/C4r1FriOhAQGBagr/wrYLODC4IvJt0G3aYIoZ8E61dsO7L4Aa/DtyF/IkIFFubSkzgOsjDmyVtBkN2oNm8ESJeXwnoQykRxj1RcKqLjMWJsEQOuLAe5ZDaaeBvMyWV6baxvEWoTA6GXqSQLU8w3p1+F+luPGjRPGhwHQEt48NIHKvxQLZ3XM/tbydAoSC6pFqQA== X-YMail-OSG: Lkir5X8VM1m22FsBV3sF5QU3gDs1YpjLKY.KSTOJsxcCJwNkysLY8JTeTU.ZHOy PlQlgqr4oZuGYFH4u.JiLuJp5sykppEg3LvG79_GI8XYTkklqwj2TWJtKeb8Amp8AVb2OW3ZijgS wN6khW1EiE9Hkho_RXblLm0onLyTjDKhV8s5srpfT3fCrwppZGjtMwgxaJPTQvIa9qACR14qnF.4 U1o2jDHOeofM0j_a1.q00U6H3VhrpFTTxDQoGUShnI0mi5BVNad3YhThl4FFG01KLg46M8vELCNa fiurq72BXKV1eED9g4B45G3HOz2XkwqGMw_7ov0oBfCoqinhDdsLwbqBx0Q_rVCEehQ76M8jf27t h95zklcpgaSdYp26Z4SRq9dzOPETxB9VhkZKPECuk5dG0NSbHdq59ZIe8WaVti0CkXkSwblJj38J TG57cy4JeifwF1NGUyNR4OT5givcQImSJ6ZjY44Vd42lJC_xNPiW4UKLscVw8ZY0Eopmj_SZM6af gPB59CtiNnQzRHgv9IA3BpW_5ViR5708ya361grAbb_Yc6Yo8mGOzftuR3p8UENgnrl2HN02_BQ9 E08iXePevDIQsfPNI_XpJiBdQ42__0UQGOJsunVSroyTBWFkb2BBrvtE2aPv143lJX56ayCOe3xH uuB5J_a4djMyeto3RfmQhHj6LG8KUCu1znxezs_AxaxSpEFMBUtSl0YlSE4helQ_3BRYxZx2gUiO 0nUUtp6vYJIGonTJ6sI8OYbkQoM54B4Eeo3B19yjcCpLvy7mXGLsHcWGLtH0wAc8Qe5hY6_Df0Sp X_M7LKepZxvuLi2u4OLtfnOqmUIqycX_H1C3s3qF6eLt0oSB4c0KwLflLHdfgXJmb04_yPNxbFpO A0wfyc4fIWim2hZ5UrU9JOD8gJYujgESe5uIJkGoHpNQZ6pDMyKqUfqBSEcYxkmgHKmgE6strbAZ 79ib.M_.OxYNP3fii_7rqQb1ZsbqHtVAx7SCPJBSPp7uRTGQqVPCu7WmQo1SQ8L8E.DHNy4xVQ5h TZA2vb8yLdIplSjv9ucr.NRk4fHjJM2fn_ZWrpZ.3ImYftyCxLEU8wX8hAmKbu5rvhyglLvj4Hst L5QyeyCpe5MgPbLex.YtkbB4L48ZFwLVmS.DMe1gtwYDuxxutcgkcdIay_QpLEfgq3H.x Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 7 May 2019 14:12:59 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e4f7d0beb6657acd613188b99856fa31; Tue, 07 May 2019 14:12:55 +0000 (UTC) To: Hannes Tschofenig , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> Date: Tue, 7 May 2019 10:12:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9808E3953C04FEFB8E388298" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 14:13:05 -0000 This is a multi-part message in MIME format. --------------9808E3953C04FEFB8E388298 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client. To compromise an MTLS bound token the attacker has to compromise the private key. To compromise a DPOP bound token, depending on what HTTP request elements are signed, and whether the DPOP is managed as one-time-use etc, there are additional attacks. (Ducks head and waits for all the real security experts to prove me wrong:) The deployment models are also different. With MTLS bound tokens the clients don't really have to know about the binding because it is established at the AS and the deployment of the service manages the cert used for the MTLS connection. This is simpler for client development (provided the environment is already set up for MTLS everywhere). I'd strong encourage us to continue supporting both methods. On 5/7/19 4:25 AM, Hannes Tschofenig wrote: > > Hi all, > > In the OAuth conference call today Vittorio mentioned that some folks > are wondering whether DPOP is essentially a superset of MTLS and > whether it makes sense to only proceed with one solution rather > potentially two. > > I was wondering whether others in the group have a few about this aspect? > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------9808E3953C04FEFB8E388298 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client.

To compromise an MTLS bound token the attacker has to compromise the private key. To compromise a DPOP bound token, depending on what HTTP request elements are signed, and whether the DPOP is managed as one-time-use etc, there are additional attacks. (Ducks head and waits for all the real security experts to prove me wrong:)

The deployment models are also different. With MTLS bound tokens the clients don't really have to know about the binding because it is established at the AS and the deployment of the service manages the cert used for the MTLS connection. This is simpler for client development (provided the environment is already set up for MTLS everywhere).

I'd strong encourage us to continue supporting both methods.

On 5/7/19 4:25 AM, Hannes Tschofenig wrote:

Hi all,

?

In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.

?

I was wondering whether others in the group have a few about this aspect?

?

Ciao

Hannes

?

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------9808E3953C04FEFB8E388298-- From nobody Tue May 7 07:50: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 6A44E120161 for ; Tue, 7 May 2019 07:50: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3gaBwW_2213c for ; Tue, 7 May 2019 07:50:37 -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 49615120158 for ; Tue, 7 May 2019 07:50:36 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id p21so20832913wmc.0 for ; Tue, 07 May 2019 07:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=VvyxpulNFyRFBpJTNBgkEi+OT+yuw2SbbYsCwd0fnTY=; b=v3h+RXWHZK+3IhclHCr3jx8f27Z0itL06YhVtDVpjBCUBhDjCxYnKMWAC67GEL5xxO Fb7R9DLGoc0FY1ZOU0E0gNRTkCqU6isol5WelCeZ6owbFsnlFn4WeHo0/d/RdyuSSC6q E2yYa3JmOqd85x24aZCs+fql0zQseQPFh/klYgpegIU/hzgH8wkY13OwtNJhUhMeVPt9 406wcDBl1Z3PEimsSGzuhQrtV/S0vwqMf+SQq+S5AvPj/3dW/pnelQwn00S/A5huY5SH E8LjG4cqy+MDDGVMqQGLfK9VeWBlBisyR1CBpNlsqD0xRSSRukZ5ExaJQOIq74VcuY1+ ME1A== 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=VvyxpulNFyRFBpJTNBgkEi+OT+yuw2SbbYsCwd0fnTY=; b=G2cbIYaVSBYwtdoQtU4h/WoqUSRNJzJKr1aD0kfymgEil69xvdSg34o9ChqFsGKpgd aKGLtvQfAlPvi4uRtKr1+svVQUB+fEoq8xUmVGaJH43w2jk6ZoLPGmKGwXWlJ3MroO/i 0KBDaKehEez2kXGHSVjCWkehhzMHdE+vP7NMLgSCzY8qh6er6zVlVqOItyqdj+qR9uf+ +yCJA5FyPMmOrD3GZ7gXzSwZqiDqWtK1mMhJs/daNA3ZxjpSd9zMxYM/E6IuFVerP5sD I9H+5zYDN/DFhyazcwVy74wB/5XR+WnonS7KFze8LarifNtAIDTJ/RVwKuIFMowN/moi RPPg== X-Gm-Message-State: APjAAAWnyUIvi1qtMNZbmp8cEqYpCGfYzpFVwd3KkcMmwBkzC4njOsLU ZFOzmVXEwirN7nNol0/vklboE8GszQM= X-Google-Smtp-Source: APXvYqxMC3cjhzlxWLMeSjSlXb1bdTwdcRKXspIZj0BV3/ri6XMp65BnFVTblwXOxMdaHIxdjZi4Tg== X-Received: by 2002:a1c:99d5:: with SMTP id b204mr20572753wme.141.1557240634345; Tue, 07 May 2019 07:50:34 -0700 (PDT) Received: from [10.3.12.228] (gate.haus-staade.de. [80.155.34.3]) by smtp.gmail.com with ESMTPSA id s8sm3721687wrm.26.2019.05.07.07.50.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 07:50:33 -0700 (PDT) To: oauth@ietf.org References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> From: Daniel Fett Message-ID: <8ead12b0-2098-e032-fc6c-27fb8bf1205a@yes.com> Date: Tue, 7 May 2019 16:50:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> Content-Type: multipart/alternative; boundary="------------CE8955A35177A8774418B775" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 14:50:39 -0000 This is a multi-part message in MIME format. --------------CE8955A35177A8774418B775 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Am 07.05.19 um 16:12 schrieb George Fletcher: > I don't see them the same at all. With MTLS, the token is bound to the > transport layer (and the key used to establish that encrypted > connection). With DPOP, the token is bound to the private key known to > the client. They are certainly not the same, and as you wrote further below, MTLS is more secure. I also wouldn't call one of them the superset of the other one. That said, they are similar in their functionality. One could, in theory, use MTLS on the token endpoint and DPoP for the resource access and vice-versa. We could specify both, MTLS and DPoP in a single document. But I am not sure what the added value of that would be. Pending good arguments for a merge I would propose to continue the work on both, MTLS and DPoP. They both have their merits. - Daniel --------------CE8955A35177A8774418B775 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Am 07.05.19 um 16:12 schrieb George Fletcher:
I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client.

They are certainly not the same, and as you wrote further below, MTLS is more secure. I also wouldn't call one of them the superset of the other one.

That said, they are similar in their functionality. One could, in theory, use MTLS on the token endpoint and DPoP for the resource access and vice-versa.

We could specify both, MTLS and DPoP in a single document. But I am not sure what the added value of that would be.

Pending good arguments for a merge I would propose to continue the work on both, MTLS and DPoP. They both have their merits.

- Daniel


--------------CE8955A35177A8774418B775-- From nobody Tue May 7 08:44:54 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 865E0120144 for ; Tue, 7 May 2019 08:44: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_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=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0vu5rmyU76X for ; Tue, 7 May 2019 08:44:50 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 E444A12011D for ; Tue, 7 May 2019 08:44:49 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id n134so10393049lfn.11 for ; Tue, 07 May 2019 08:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rO7BdrcqMDIHL5pbPZmbZeTD16MXt4j5wqL0QSZZB6k=; b=Tpa6ep30i0OmXLX5MA5Ks7vt3kLtBBU2sujHdgC0MYeJho3Y5QxIynszPlweuMwR9C XujOEEtb4ZkgctCdIf/s5G5WXVoHxwXkip33CGTP6EReZk4IsHS21/FcqvivjOAMT1dZ HOhdXBVB1tIIjHeM2Q8D929Cui5DgUasoeCH6Fe7ElA4GZ2P+ElY3WUr7xRIsoyC60id 9DEjIrsIwuTCX1+vGM9F+3A34GcaNV+97ur+1YjKJra/5Eeju5S7QKiCfD1QkjqH2HdQ 3mPCSiPi6g+o7gWFBI9yD8daBV2dEsThlcg8MQfeRMFLtIIz56jk7DP0jCuO+Bqiia22 uayA== 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=rO7BdrcqMDIHL5pbPZmbZeTD16MXt4j5wqL0QSZZB6k=; b=Ty4jNJkzxdWO/TAgPTBtW/K+nyiN2I14BIJOuXkC1WEBZ5MqviKzKnoNE8NaxqljaX ZqDsB1c4W3No+9AexVM+D8fSzCY8YyFee4GsI7w5gdnACJkIx0rXg7EHVtrpPcWNGWA6 y3Jipe+fdcZnSNy1QaP6/Q+3H88ASWrx3meO3Vq9rc2KgtLbIYazPDM89w7gAMcHyiyL BbpkjoseGgFE9wWJyH7ZBzZaJ5DhjGe8E39gReMBq4OV0PJA67Gl8O1BTp5rbw8ZRXnN kwnox6g/x7UztOXabHWC+MUjbM4gUtnihVU86E7ro7jY5Bd5GCAQ+tpX91kMuC86vlOo Lf3Q== X-Gm-Message-State: APjAAAWYTK8X9tDpeo21qSuLllE+fITNWj8R9CnQ3e46kLe9vQCBQQwn bQX3orJ+gcBOvpXjfNaEnuzgfDq17nReLKnwl5LvnQ== X-Google-Smtp-Source: APXvYqxELKX4NwAqCQsBii2Y9QBNaNWlUsc96NZO65N0L9X2sgMnAN7k0mIYaOrpRd8sqqTjXFl4A8urtLo1ImwEmYs= X-Received: by 2002:ac2:51a1:: with SMTP id f1mr15580188lfk.129.1557243887782; Tue, 07 May 2019 08:44:47 -0700 (PDT) MIME-Version: 1.0 References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> In-Reply-To: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> From: Vittorio Bertocci Date: Tue, 7 May 2019 08:44:36 -0700 Message-ID: To: George Fletcher Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c2a61105884e188c" Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:44:54 -0000 --000000000000c2a61105884e188c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify, I wasn=E2=80=99t suggesting we drop one or the other. Both have= their merit and use cases, and both should be developed all the way to standard IMO. But from some preliminary exploration, it seems unlikely that services will adopt both at the same time. From the =E2=80=9Cpr=E2=80=9D perspective= , having a clear _default_ answer to the question =E2=80=9Chow do I add sender constraint capabilities to my service?=E2=80=9D would greatly enhance the chances of g= etting something out in the real world quickly, make it possible to interop and iron out wrinkles, etc etc- For the general developer populace, at this point =E2=80=9Csender constrain= t=E2=80=9D remains something vaguely exotic and often decisions made on that (like the ones on the implicit deprecation) are poorly received. Even the ones who had exposure had been somewhat =E2=80=9Cburned=E2=80=9D by how token bindin= g is going, and we are in need for something easy to grok and actionable to rekindle interest IMO. The sooner we can get the concept mainstream the better. On Tue, May 7, 2019 at 07:13 George Fletcher wrote: > I don't see them the same at all. With MTLS, the token is bound to the > transport layer (and the key used to establish that encrypted connection)= . > With DPOP, the token is bound to the private key known to the client. > > To compromise an MTLS bound token the attacker has to compromise the > private key. To compromise a DPOP bound token, depending on what HTTP > request elements are signed, and whether the DPOP is managed as > one-time-use etc, there are additional attacks. (Ducks head and waits for > all the real security experts to prove me wrong:) > > The deployment models are also different. With MTLS bound tokens the > clients don't really have to know about the binding because it is > established at the AS and the deployment of the service manages the cert > used for the MTLS connection. This is simpler for client development > (provided the environment is already set up for MTLS everywhere). > > I'd strong encourage us to continue supporting both methods. > > On 5/7/19 4:25 AM, Hannes Tschofenig wrote: > > Hi all, > > ? > > In the OAuth conference call today Vittorio mentioned that some folks are > wondering whether DPOP is essentially a superset of MTLS and whether it > makes sense to only proceed with one solution rather potentially two. > > ? > > I was wondering whether others in the group have a few about this aspect? > > ? > > Ciao > > Hannes > > ? > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > 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 > --000000000000c2a61105884e188c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To clarify, I wasn=E2=80=99t suggesting we drop one = or the other. Both have their merit and use cases, and both should be devel= oped all the way to standard IMO. But from some preliminary exploration, it= seems unlikely that services will adopt both at the same time. From the = =E2=80=9Cpr=E2=80=9D perspective, having a clear _default_ answer to the qu= estion =E2=80=9Chow do I add sender constraint capabilities to my service?= =E2=80=9D would greatly enhance the chances of getting something out in the= real world quickly, make it possible to interop and iron out wrinkles, etc= etc-=C2=A0
For the general developer populace= , at this point =E2=80=9Csender constraint=E2=80=9D remains something vague= ly exotic and often decisions made on that (like the ones on the implicit d= eprecation) are poorly received. Even the ones who had exposure had been so= mewhat =E2=80=9Cburned=E2=80=9D by how token binding is going, and we are i= n need for something easy to grok and actionable to rekindle interest IMO. = The sooner we can get the concept mainstream the better.

On Tue, May 7, 2019 at 07:13 George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wro= te:
=20 =20 =20
I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client.

To compromise an MTLS bound token the attacker has to compromise the private key. To compromise a DPOP bound token, depending on what HTTP request elements are signed, and whether the DPOP is managed as one-time-use etc, there are additional attacks. (Ducks head and waits for all the real security experts to prove me wrong:)

The deployment models are also different. With MTLS bound tokens the clients don't really have to know about the binding because it is established at the AS and the deployment of the service manages the cert used for the MTLS connection. This is simpler for client development (provided the environment is already set up for MTLS everywhere).

I'd strong encourage us to continue supporting both methods.

On 5/7/19 4:25 AM, = Hannes Tschofenig wrote:
=20 =20 =20

Hi all,

?<= /p>

In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.

?<= /p>

I was wondering whether others in the group have a few about this aspect?

?<= /p>

Ciao

Hannes

?<= /p>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c2a61105884e188c-- From nobody Tue May 7 09:00: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 36FD7120181 for ; Tue, 7 May 2019 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVAy3sxfFapG for ; Tue, 7 May 2019 09:00:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80053.outbound.protection.outlook.com [40.107.8.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E7A120189 for ; Tue, 7 May 2019 09:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YysbVOTqfxzAlA5XWETQJGMJpOLqghvs6id11NPlC0Q=; b=YhdnEnsDcZzCttoD5LHcHkQlg9gwRiFqWiueGLvrOVhU2xSj5HPCik5dspP3wD4fYvS4I35QgxvQIUu5aCuJBzp1D3cCvWdN96fBAlKKQm6mQmKHWuljkkF23hcAFfJ4VivWAmOM3emoRl2BkClYK0NvSkwhu4SgnEmDmeU5lf8= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4837.eurprd08.prod.outlook.com (20.179.46.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Tue, 7 May 2019 16:00:27 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 16:00:26 +0000 From: Hannes Tschofenig To: Vittorio Bertocci , George Fletcher CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] MTLS vs. DPOP Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQAMeI0AAAMz3AAAAHu2AA== Date: Tue, 7 May 2019 16:00:26 +0000 Message-ID: References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.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=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f5b3ee0-2756-4371-a516-08d6d3051f18 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4837; x-ms-traffictypediagnostic: DBBPR08MB4837: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(396003)(346002)(199004)(189003)(40434004)(7736002)(99286004)(8936002)(81166006)(6436002)(8676002)(81156014)(66066001)(6116002)(102836004)(86362001)(256004)(64756008)(186003)(26005)(3846002)(305945005)(25786009)(76176011)(476003)(68736007)(7696005)(6506007)(2906002)(74316002)(4326008)(14444005)(55016002)(9686003)(71190400001)(71200400001)(66556008)(76116006)(11346002)(229853002)(66446008)(73956011)(66476007)(66946007)(5024004)(486006)(52536014)(33656002)(5660300002)(4744005)(446003)(478600001)(316002)(6246003)(14454004)(53936002)(72206003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4837; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GPwmCPjwPQfxbfH7i8Gy2gKO0BI75iGHe/Xz2KeYaQZlsPf89Dnz4PjJWiSCAfLAzb8YbWiEAO+7W9CuhbSJ5djFJ9ySMJfUfO8PjRPisXwRYSWucLzj/7f3gDnIrNe/tTRWjleL5l4ZuTM8vgcF5/d0szAldXAjqx+evpeJg5UWZqkHGBQIqiw7ih5d9IE4X+iqQbgMeHBQmEH2xsuVkJBA2yGV0lh5lRQQlv7xrydPFDedONQiOIaUCj1FPuZ7ZJi+yE4bm3Fht3ybsaotGSsN5NQWlhhQ75XcDDdgUWhdSsNEsi7UUetTQL7XKdkRlopfq/Kc9UgHRmGOwG7yrnmhRsSMCyni/TbB01UfM/7bLdI506mtDIPduKCIuzDhEN5gzbQRg11C+X/JYOYxQ0DVYrU8qzmF02gW3MZ5eZ0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f5b3ee0-2756-4371-a516-08d6d3051f18 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 16:00:26.8829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4837 Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:00:38 -0000 R2VvcmdlLA0KDQo+IEkgZG9uJ3Qgc2VlIHRoZW0gdGhlIHNhbWUgYXQgYWxsLiBXaXRoIE1UTFMs IHRoZSB0b2tlbiBpcyBib3VuZCB0byB0aGUgdHJhbnNwb3J0IGxheWVyIChhbmQgdGhlIGtleSB1 c2VkIHRvIGVzdGFibGlzaCB0aGF0IGVuY3J5cHRlZCBjb25uZWN0aW9uKS4gV2l0aCBEUE9QLCB0 aGUgdG9rZW4gaXMgYm91bmQgdG8gdGhlIHByaXZhdGUga2V5IGtub3duIHRvIHRoZSBjbGllbnQu DQoNClN0cmljdGx5IHNwZWFraW5nIGJvdGggc29sdXRpb25zIHRpZSB0aGUgdG9rZW4gdG8gdGhl IHB1YmxpYyBrZXkgYW5kIHRoZSBjbGllbnQgbmVlZHMgdG8gZGVtb25zdHJhdGUgcG9zc2Vzc2lv biBvZiB0aGUgcHJpdmF0ZSBrZXkgdGhyb3VnaCBzb21lIHNlY3VyaXR5IHByb3RvY29sLg0KDQpD aWFvDQpIYW5uZXMNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Tue May 7 10:16:06 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 1063C1200F1 for ; Tue, 7 May 2019 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYMWWSEo9HAX for ; Tue, 7 May 2019 10:16:01 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209EC1200B9 for ; Tue, 7 May 2019 10:16:01 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id q132so12500938itc.5 for ; Tue, 07 May 2019 10:16:00 -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=EbCCwiY23fD9qZPBB/nHOYE+mdPvEXuIVHJh3rTEab8=; b=HADP3GKOhC73w/kFjerh74QVRcHdTsKch7cKIPZXdbmlY8iTW9Yk0d0VaUeEUYKhTi +09eZT1VnP+CWVaclgwETidanyCsM8vHkJ7egPRkLetfjYzN5AJekHxVfenHcudWTb2h W0uFEKoCNJjwdbawv0ZHjjL1FxgYydmbMPM/U= 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=EbCCwiY23fD9qZPBB/nHOYE+mdPvEXuIVHJh3rTEab8=; b=Nu+w685GNLYbJubCv1Yc8OW6J0mZ3LIjmENEcKmOFz+/OKrf7g5ACjsn3wIUUgHicv chZsb1MTnDx5Nnr61cLjsavW16Fb9sK/i4wPJ/fo0YiY3yHMmhbaLRAWevQsH62XXHMu YVO5Xy3CZLcea7WqvwPepcEcslKAZ6HvpEB8r5MXYsFqGZL3A2oOUwvwpCJiC52iIES3 V280WFVFd8EjUYy0RRi+x7Kk8UmXa7UDInPbV532GheMfEL7mMhEUIPi0tAw2ZICY2Jc shpxuc5TUGIqYyjuv1XIGYFh/SLvts9isp2At9V8PL57wLMa5aysu/eVxlOVyBnaepaE /N6A== X-Gm-Message-State: APjAAAUPcs8pzfJEftygDF5FLmwhdgg1WZAAU9INd8x54ZlHw7PINtGI DNbIxD1VFkkeIzTRjYNZkszmjmxXma3Ch2P/LDo+cvjz/XnQ9Ovd5BccGmHBSjqtGX6scGe+rx6 aPxkrT+MU/fha+g== X-Google-Smtp-Source: APXvYqx8aAy/p67hVcsaQjnf7VEZspI980SyzX9PzqHK348yfhcjBV1T1GGApINH3xYfTsI91Fhai5H1I8sfoiZWljM= X-Received: by 2002:a24:9289:: with SMTP id l131mr1965915itd.45.1557249360263; Tue, 07 May 2019 10:16:00 -0700 (PDT) MIME-Version: 1.0 References: <4223569.5sG2vptK2V@papegaaij> <1750829.ebW1fUBprn@papegaaij> In-Reply-To: From: Brian Campbell Date: Tue, 7 May 2019 11:15:34 -0600 Message-ID: To: Hannes Tschofenig Cc: Emond Papegaaij , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f21fec05884f5e24" Archived-At: Subject: Re: [OAUTH-WG] Token Exchange status and Resource Indicators 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, 07 May 2019 17:16:03 -0000 --000000000000f21fec05884f5e24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 7, 2019 at 7:03 AM Hannes Tschofenig wrote: > > The group can define what is in scope of a document and what isn't. > Which is what's been done with the document during the course of it's development and WGLC and subsequent submission to the IESG for publication. --=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._ --000000000000f21fec05884f5e24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 7, 2019 = at 7:03 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

The group can define what is in scope of a document and what isn't.
=

Which is what's been done with the doc= ument during the course of it's development and WGLC and subsequent sub= mission to the IESG for publication.
=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. --000000000000f21fec05884f5e24-- From nobody Tue May 7 10:19: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 F1A961202D2 for ; Tue, 7 May 2019 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev22BsRBXCAd for ; Tue, 7 May 2019 10:18:50 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 527871202D9 for ; Tue, 7 May 2019 10:18:48 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id l140so27021439itb.0 for ; Tue, 07 May 2019 10:18:48 -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=DExUIVhLdiArxwxJ0NmQk4sZz21SX2YmVeGp5M7H3E4=; b=Qqkf1xzCfAO62wEy4+47ehZZfNgN3ep+Mgif5tN9k4K6MQzASs0K5Y8FJ6glbnzVTs 15T4AcDY1Pf7/CCjyEumcqhZHgZ6AMJ8AG9MXLJ7qgRPYV/YMWAVTGRFkzPOlypFxIV4 8FlxyxVe4Sjs4C8pQZTYe8XCFTu4A9bjN8U48= 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=DExUIVhLdiArxwxJ0NmQk4sZz21SX2YmVeGp5M7H3E4=; b=F8dfafWsQ8IUZdNcKmlmJQUrKRECKuHP1SMajP+csnz33qBo2qHhGSImvepNUmt0Cv 91sWKZqzRDu+NQWGd+EDVF41HtpljhPOS85U+uq2f/pZd2Ccp26184yyORbyL2kzN/gL y//Qxc0ZYzbMZMa5H2nUPAKhA97tmHqngnLxuo7N4qeBdBAH+kbp4fJNx431shgSdZgz RieU1xXc7VP2N1QIy23TTQmw3O0FipEFXDIs4TBzdQbED8QVxx+RQDJ/GEUYIxqDcShK CkIw3cqbwnpuMTyB7bp69WtF/51v6YPkxITeb+ujU0iV6r1w/l9D30zM3MYD8N3sCK10 oo4Q== X-Gm-Message-State: APjAAAXqqWGeYKTwN8X3dzbt/4sw5vhPPm+IexMihyHiMxB7hp2zigin 99saiuwmWfm6SBp0HExkEgTVVEPxbIFzgpLhpeXDMPtiJwbXkIApojt2PYEV9EHvhvRMR8/RFeN lsT5ZgDtKHmb2KmMr X-Google-Smtp-Source: APXvYqx9HsDvW6a1KRTc1QQ8nNU5ukpNFfzehRxe2tbkq+lrkHDqNoMQbbELF3826nVsADx4CKbQgPnnLDhOxGA9jus= X-Received: by 2002:a02:62ce:: with SMTP id d197mr23922642jac.91.1557249527436; Tue, 07 May 2019 10:18:47 -0700 (PDT) MIME-Version: 1.0 References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> In-Reply-To: From: Brian Campbell Date: Tue, 7 May 2019 11:18:21 -0600 Message-ID: To: Vittorio Bertocci Cc: George Fletcher , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e9025705884f680b" Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:19:00 -0000 --000000000000e9025705884f680b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Practically speaking there's the MTLS draft, which has been sent to the IESG for publication, has commercial and opensource implementations as well as production deployments, and is referenced by other prospective standards and profiles. It's not uncommon to receive off list inquires about the document status from people involved in those things asking when it will be "finished". Which is to say that there's a good amount of interest from the community at large in seeing the MTLS document go to RFC. And it's relatively close to doing so (as these things go anyway). The DPoP document, on the other hand, is currently an individual draft submission. And while it has generated some good interest and discussion, it is only an individual draft submission and carries the same authority as any other individual draft submission (see https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I believe that the MTLS draft should continue on the it's course. And am interested in seeing where we can take the DPoP work and if the WG wants to take it on. Your point about the "PR" perspective is taken. And I probably shouldn't even bring these up but that whole situation is exacerbated by the expired/dormant WG documents like draft-ietf-oauth-token-binding and draft-ietf-oauth-signed-http-request. Some organizations out there touting their support for RFC 7800 as a complete solution in the pop/sender-constrained space aren't helping matters either. So while I think I hear what you are saying, I don't personally see much of anything reasonable or actionable that can done about it. On Tue, May 7, 2019 at 9:45 AM Vittorio Bertocci wrote: > To clarify, I wasn=E2=80=99t suggesting we drop one or the other. Both ha= ve their > merit and use cases, and both should be developed all the way to standard > IMO. But from some preliminary exploration, it seems unlikely that servic= es > will adopt both at the same time. From the =E2=80=9Cpr=E2=80=9D perspecti= ve, having a clear > _default_ answer to the question =E2=80=9Chow do I add sender constraint > capabilities to my service?=E2=80=9D would greatly enhance the chances of= getting > something out in the real world quickly, make it possible to interop and > iron out wrinkles, etc etc- > For the general developer populace, at this point =E2=80=9Csender constra= int=E2=80=9D > remains something vaguely exotic and often decisions made on that (like t= he > ones on the implicit deprecation) are poorly received. Even the ones who > had exposure had been somewhat =E2=80=9Cburned=E2=80=9D by how token bind= ing is going, and > we are in need for something easy to grok and actionable to rekindle > interest IMO. The sooner we can get the concept mainstream the better. > > On Tue, May 7, 2019 at 07:13 George Fletcher 40aol.com@dmarc.ietf.org> wrote: > >> I don't see them the same at all. With MTLS, the token is bound to the >> transport layer (and the key used to establish that encrypted connection= ). >> With DPOP, the token is bound to the private key known to the client. >> >> To compromise an MTLS bound token the attacker has to compromise the >> private key. To compromise a DPOP bound token, depending on what HTTP >> request elements are signed, and whether the DPOP is managed as >> one-time-use etc, there are additional attacks. (Ducks head and waits fo= r >> all the real security experts to prove me wrong:) >> >> The deployment models are also different. With MTLS bound tokens the >> clients don't really have to know about the binding because it is >> established at the AS and the deployment of the service manages the cert >> used for the MTLS connection. This is simpler for client development >> (provided the environment is already set up for MTLS everywhere). >> >> I'd strong encourage us to continue supporting both methods. >> >> On 5/7/19 4:25 AM, Hannes Tschofenig wrote: >> >> Hi all, >> >> ? >> >> In the OAuth conference call today Vittorio mentioned that some folks ar= e >> wondering whether DPOP is essentially a superset of MTLS and whether it >> makes sense to only proceed with one solution rather potentially two. >> >> ? >> >> I was wondering whether others in the group have a few about this aspect= ? >> >> ? >> >> Ciao >> >> Hannes >> >> ? >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > 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._ --000000000000e9025705884f680b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Practically speaking there's the MTLS d= raft, which has been sent to the=20 IESG for publication, has commercial and opensource implementations as=20 well as production deployments, and is referenced by other prospective stan= dards and profiles. It's not uncommon to receive off list inquires abou= t the document status from people involved in those things asking when it w= ill be "finished". Which is to say that there's a good amount= of interest from the community at large in seeing the MTLS document go to = RFC. And it's relatively close to doing so (as these things go anyway).= The DPoP document, on the other hand, is currently an individual draft sub= mission. And while it has generated some good interest and discussion, it i= s only an individual draft submission and carries the same authority as any= other individual draft submission (see https://tools.ietf.org/h= tml/draft-abr-twitter-reply-00 for example). I believe that the MTLS dr= aft should continue on the it's course. And am interested in seeing whe= re we can take the DPoP work and if the WG wants to take it on.
<= div>
Your point about the "PR" perspective is taken= . And I probably shouldn't even bring these up but that whole situation= is exacerbated by the expired/dormant WG documents like draft-ietf-oauth-t= oken-binding and draft-ietf-oauth-signed-http-request. Some organizations o= ut there touting their support for RFC 7800 as a complete solution in the p= op/sender-constrained space aren't helping matters either. So while I t= hink I hear what you are saying, I don't personally see much of anythin= g reasonable or actionable that can done about it.

=
=C2=A0


On Tue, May 7, 2019 at 9:45 AM V= ittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
To cl= arify, I wasn=E2=80=99t suggesting we drop one or the other. Both have thei= r merit and use cases, and both should be developed all the way to standard= IMO. But from some preliminary exploration, it seems unlikely that service= s will adopt both at the same time. From the =E2=80=9Cpr=E2=80=9D perspecti= ve, having a clear _default_ answer to the question =E2=80=9Chow do I add s= ender constraint capabilities to my service?=E2=80=9D would greatly enhance= the chances of getting something out in the real world quickly, make it po= ssible to interop and iron out wrinkles, etc etc-=C2=A0
For the general developer populace, at this point =E2=80=9Csender= constraint=E2=80=9D remains something vaguely exotic and often decisions m= ade on that (like the ones on the implicit deprecation) are poorly received= . Even the ones who had exposure had been somewhat =E2=80=9Cburned=E2=80=9D= by how token binding is going, and we are in need for something easy to gr= ok and actionable to rekindle interest IMO. The sooner we can get the conce= pt mainstream the better.

On Tue, May 7, 2019 = at 07:13 George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
I don't see them the same at all. With MTLS, the token is bound to the transport layer (and the key used to establish that encrypted connection). With DPOP, the token is bound to the private key known to the client.

To compromise an MTLS bound token the attacker has to compromise the private key. To compromise a DPOP bound token, depending on what HTTP request elements are signed, and whether the DPOP is managed as one-time-use etc, there are additional attacks. (Ducks head and waits for all the real security experts to prove me wrong:)

The deployment models are also different. With MTLS bound tokens the clients don't really have to know about the binding because it is established at the AS and the deployment of the service manages the cert used for the MTLS connection. This is simpler for client development (provided the environment is already set up for MTLS everywhere).

I'd strong encourage us to continue supporting both methods.

On 5/7/19 4:25 AM, Hannes Tschofenig wrote:
=20 =20 =20

Hi all,

?<= /p>

In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.

?<= /p>

I was wondering whether others in the group have a few about this aspect?

?<= /p>

Ciao

Hannes

?<= /p>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 
____________________________________________=
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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. --000000000000e9025705884f680b-- From nobody Tue May 7 10:43:47 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 EC785120153 for ; Tue, 7 May 2019 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6YVcDZ0vEeGm for ; Tue, 7 May 2019 10:43:41 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 A8A4F1200B1 for ; Tue, 7 May 2019 10:43:41 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hO47u-00009o-Fa; Tue, 07 May 2019 19:43:38 +0200 From: Torsten Lodderstedt Message-Id: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_7BAE4960-3077-403C-B8A2-29C561550BA4"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 7 May 2019 19:43:37 +0200 In-Reply-To: Cc: "oauth@ietf.org" To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3445.104.8) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 17:43:46 -0000 --Apple-Mail=_7BAE4960-3077-403C-B8A2-29C561550BA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 mTLS is dead simple to use, secure, is used and can be used on a broad = basis (in contrast to the token binding stuff). I also like the fact it = provides both client authentication and sender-constraining. We started the work on DPoP for the simple reason that SPAs don=E2=80=99t = work well with mTLS and we want to provide a solution with somehow = limited capabilities, e.g. regarding replay protection (see DPoP = introduction).=20 If someone asks me for the default solution, it=E2=80=99s simple: use = mTLS. And if you build a SPA and want to do really security sensitive = things, implement your OAuth stuff and the RS interactions in the = backend of your application.=20 DPoP is in a really early stage, let=E2=80=99s see where it will go. best regards, Torsten.=20 > On 7. May 2019, at 10:25, Hannes Tschofenig = wrote: >=20 > Hi all, > =20 > In the OAuth conference call today Vittorio mentioned that some folks = are wondering whether DPOP is essentially a superset of MTLS and whether = it makes sense to only proceed with one solution rather potentially two. > =20 > I was wondering whether others in the group have a few about this = aspect? > =20 > Ciao > Hannes > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. = _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7BAE4960-3077-403C-B8A2-29C561550BA4 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 Fw0xOTA1MDcxNzQzMzdaMC8GCSqGSIb3DQEJBDEiBCDx9Y/368R/71nA0fIBZlJ7T87t0Yc/UXZK Wb72waUA9TCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAMc7QxPn01wLK4Mzgs9GNVryN6Rx3Nirkta3E/v/1kQgvy4DgTH9FKBwABTF qIqEDxWwEI81iIDPkhd933Y2L8vC+WrPgfhzr3VMAHWirhrsUw7HztpPQaR2FrHKTye5dDA6Y98G TQJFoGr0+WcqR0yp/fvM9RmrbedbJurl5/A6NevJOYee2E8gbod3/DdOEduF9ieR8eujsm77kp// vHfMyqYvTYe1QhTiOf5ciMDNoIEG/QaAwI+7KZSVZKDbdoqH9uKHdrmeNqzzb5O4fQC7haXaMjg+ /o0gI8MkI0s/rX4tYJve+tfRTZbjveO+m3FoOZFFe1gGhsCL56ZYVMUAAAAAAAA= --Apple-Mail=_7BAE4960-3077-403C-B8A2-29C561550BA4-- From nobody Tue May 7 11:00: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 4D8021201A8 for ; Tue, 7 May 2019 11:00:05 -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=unavailable 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 ChVJWCtrPkIi for ; Tue, 7 May 2019 11:00:03 -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 F34681201BB for ; Tue, 7 May 2019 11:00:01 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x47HxtAB016484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 May 2019 13:59:57 -0400 Date: Tue, 7 May 2019 12:59:55 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: Vittorio Bertocci , George Fletcher , "oauth@ietf.org" Message-ID: <20190507175954.GM19509@kduck.mit.edu> References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.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] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 18:00:05 -0000 On Tue, May 07, 2019 at 11:18:21AM -0600, Brian Campbell wrote: > Practically speaking there's the MTLS draft, which has been sent to the > IESG for publication, has commercial and opensource implementations as well > as production deployments, and is referenced by other prospective standards > and profiles. It's not uncommon to receive off list inquires about the > document status from people involved in those things asking when it will be > "finished". Which is to say that there's a good amount of interest from the > community at large in seeing the MTLS document go to RFC. And it's > relatively close to doing so (as these things go anyway). The DPoP > document, on the other hand, is currently an individual draft submission. > And while it has generated some good interest and discussion, it is only an > individual draft submission and carries the same authority as any other > individual draft submission (see > https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I > believe that the MTLS draft should continue on the it's course. And am > interested in seeing where we can take the DPoP work and if the WG wants to > take it on. > > Your point about the "PR" perspective is taken. And I probably shouldn't > even bring these up but that whole situation is exacerbated by the > expired/dormant WG documents like draft-ietf-oauth-token-binding and > draft-ietf-oauth-signed-http-request. Some organizations out there touting I've forgotten the details of those two documents, but in the general case, if there's a WG document that is no longer actively being worked on (or is now believed to be a bad idea), the chairs can pretty easily get a new rev posted that has a "tombstone" notice, like "this document is no longer being worked on" or similar, which may help clarify the situation to external parties without much investment on time or tooling. -Ben > their support for RFC 7800 as a complete solution in the > pop/sender-constrained space aren't helping matters either. So while I > think I hear what you are saying, I don't personally see much of anything > reasonable or actionable that can done about it. From nobody Tue May 7 11:10: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 44E1E1201C9 for ; Tue, 7 May 2019 11:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=okta.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 QyeFJlw-VLZl for ; Tue, 7 May 2019 11:10:03 -0700 (PDT) Received: from us-smtp-delivery-163.mimecast.com (us-smtp-delivery-163.mimecast.com [63.128.21.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9E31201B0 for ; Tue, 7 May 2019 11:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=mimecast20140813; t=1557252601; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpKo4RmAx6/jQKoRpD/UAJtuiJQCMYbpaF3AzC3MZ5s=; b=Fs/Qef748Z1jj6ejPP5Zd3plMjYTI3RZy4pCFslCswOYvAtKDZ86Mem+r77cs5ZL9TKSME 8ISDr0y0TDzKQhsQupW9Yl9AcLXZFNxG6gCl93+Zss+smQDiMkGD8mn6kdy9fCOanjruIo ci51JXrfC9K7JqMnSOntuOgjwbdSQ2g= Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp2055.outbound.protection.outlook.com [104.47.48.55]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-214-lu1f6HBnOGysVoFBfnd36w-1; Tue, 07 May 2019 14:10:00 -0400 Received: from BYAPR05MB4133.namprd05.prod.outlook.com (52.135.199.154) by BYAPR05MB5493.namprd05.prod.outlook.com (20.177.186.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.19; Tue, 7 May 2019 18:09:57 +0000 Received: from BYAPR05MB4133.namprd05.prod.outlook.com ([fe80::1fa:75b8:92d7:93b4]) by BYAPR05MB4133.namprd05.prod.outlook.com ([fe80::1fa:75b8:92d7:93b4%4]) with mapi id 15.20.1878.019; Tue, 7 May 2019 18:09:57 +0000 From: Karl McGuinness To: Torsten Lodderstedt CC: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] MTLS vs. DPOP Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQAT1IGAAADrJIA= Date: Tue, 7 May 2019 18:09:57 +0000 Message-ID: References: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> In-Reply-To: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.24.59.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba55f133-7515-45ec-6907-08d6d31736a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR05MB5493; x-ms-traffictypediagnostic: BYAPR05MB5493: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(346002)(396003)(40434004)(53754006)(189003)(199004)(3846002)(6486002)(71190400001)(6116002)(33656002)(71200400001)(6306002)(25786009)(68736007)(6436002)(5660300002)(6512007)(305945005)(8936002)(82746002)(54906003)(99286004)(2906002)(83716004)(53546011)(6506007)(36756003)(229853002)(7736002)(8676002)(2616005)(81156014)(81166006)(76176011)(316002)(6916009)(5024004)(14444005)(966005)(476003)(256004)(86362001)(102836004)(478600001)(14454004)(486006)(186003)(4326008)(66066001)(53936002)(26005)(66556008)(64756008)(66476007)(66446008)(11346002)(66946007)(76116006)(6246003)(446003)(73956011); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5493; H:BYAPR05MB4133.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: j1Nc3UfG0Up2fGnCgP64QSZiAZTtFW/Ubp7O2ZuXLGjpm00SETWJAfZt2UhqMIUnZkkBXG8VqnYPrKUr4UtV3RdeVdEhE10AWg2CMikHeGd/IujDMO9gGVkM+4radQllR2VhH+m9gdQPIS+ZQZxj2qzucZAhykRE6MJZmk57kR6ixs0G25fSrJ0gqL/5JhxuAnQFLpAdhoQJGaBGVhGb+LMN9RR/nkiW0+nTeV2aQYOaatunFWaNqQ4MzUi3ZEq2tEX/F3mK8SMkwmXCbiE/T2DHXvmjhVQdrYBPn07SK5TdjNzXe2hSEjSHDvTuEsSjjhP3MULWvvcpnZ5st7fQFtnL3WA75smqBWc5qFXwmL8B2dJYS18EnQZ72xhHHqbh/pmyLG7zIPHZkZLZB+GzQyNC/vyPedscdh70wRBM3Ts= Content-ID: <1C56112CD45D5244A32A728828CB4298@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: okta.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba55f133-7515-45ec-6907-08d6d31736a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 18:09:57.3129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f1f9fcc4-c616-4261-8a82-855dc9cb8486 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5493 X-MC-Unique: lu1f6HBnOGysVoFBfnd36w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 18:10:07 -0000 bVRMUyBoYXMgc2lnbmlmaWNhbnQgY2hhbGxlbmdlcyBhdCBzY2FsZSBpbiBhIG11bHRpLXRlbmFu dCBTYWFTIGRlcGxveW1lbnQgb24gcHVibGljIGNsb3VkcyB1c2luZyBtb2Rlcm4gZWRnZSB0ZWNo bm9sb2dpZXMvc2VydmljZXMuICBBcHBsaWNhdGlvbnMgYXJlIGluY3JlYXNpbmdseSBiZWluZyBi dWlsdCB1c2luZyBGdW5jdGlvbi1hcy1hLVNlcnZpY2UvZXBoZW1lcmFsIHdvcmtsb2FkcyBhcyB3 ZWxsLiAgQWRkaXRpb25hbCBjb21wbGV4aXR5IGluY3JlYXNlcyBpZiB5b3UgYWxzbyB3YW50IHRv IHN1cHBvcnQgImJyaW5nIHlvdXIgb3duIENB4oCdLg0KDQpEUG9QIGVuYWJsZXMgYXBwbGljYXRp b24gbGV2ZWwgZGVwbG95bWVudCBtb2RlbCBpbmRlcGVuZGVudCBvZiBob3cgb25l4oCZcyBlZGdl IG9yIHJ1bnRpbWUgaXMgZGVwbG95ZWQvbWFuYWdlZC4gIFRoaXMgaXMgdmVyeSB2YWx1YWJsZSBm b3IgU2FhUyBwcm92aWRlcnMuICBXZSBleHBlY3QgdG8gZXZlbnR1YWxseSBkZXBsb3kgYSBEUG9Q IGxpa2Ugc29sdXRpb24gZm9yIGFsbCBjbGllbnQgbW9kZWxzIGFuZCBub3QganVzdCBTUEEuIA0K DQotS2FybA0KDQo+IE9uIE1heSA3LCAyMDE5LCBhdCAxMDo0MyBBTSwgVG9yc3RlbiBMb2RkZXJz dGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KPiANCj4gSGksIA0KPiANCj4g bVRMUyBpcyBkZWFkIHNpbXBsZSB0byB1c2UsIHNlY3VyZSwgaXMgdXNlZCBhbmQgY2FuIGJlIHVz ZWQgb24gYSBicm9hZCBiYXNpcyAoaW4gY29udHJhc3QgdG8gdGhlIHRva2VuIGJpbmRpbmcgc3R1 ZmYpLiBJIGFsc28gbGlrZSB0aGUgZmFjdCBpdCBwcm92aWRlcyBib3RoIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhbmQgc2VuZGVyLWNvbnN0cmFpbmluZy4NCj4gDQo+IFdlIHN0YXJ0ZWQgdGhlIHdv cmsgb24gRFBvUCBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCBTUEFzIGRvbuKAmXQgd29yayB3 ZWxsIHdpdGggbVRMUyBhbmQgd2Ugd2FudCB0byBwcm92aWRlIGEgc29sdXRpb24gd2l0aCBzb21l aG93IGxpbWl0ZWQgY2FwYWJpbGl0aWVzLCBlLmcuIHJlZ2FyZGluZyByZXBsYXkgcHJvdGVjdGlv biAoc2VlIERQb1AgaW50cm9kdWN0aW9uKS4gDQo+IA0KPiBJZiBzb21lb25lIGFza3MgbWUgZm9y IHRoZSBkZWZhdWx0IHNvbHV0aW9uLCBpdOKAmXMgc2ltcGxlOiB1c2UgbVRMUy4gQW5kIGlmIHlv dSBidWlsZCBhIFNQQSBhbmQgd2FudCB0byBkbyByZWFsbHkgc2VjdXJpdHkgc2Vuc2l0aXZlIHRo aW5ncywgaW1wbGVtZW50IHlvdXIgT0F1dGggc3R1ZmYgYW5kIHRoZSBSUyBpbnRlcmFjdGlvbnMg aW4gdGhlIGJhY2tlbmQgb2YgeW91ciBhcHBsaWNhdGlvbi4gDQo+IA0KPiBEUG9QIGlzIGluIGEg cmVhbGx5IGVhcmx5IHN0YWdlLCBsZXTigJlzIHNlZSB3aGVyZSBpdCB3aWxsIGdvLg0KPiANCj4g YmVzdCByZWdhcmRzLA0KPiBUb3JzdGVuLiANCj4gDQo+PiBPbiA3LiBNYXkgMjAxOSwgYXQgMTA6 MjUsIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToN Cj4+IA0KPj4gSGkgYWxsLA0KPj4gDQo+PiBJbiB0aGUgT0F1dGggY29uZmVyZW5jZSBjYWxsIHRv ZGF5IFZpdHRvcmlvIG1lbnRpb25lZCB0aGF0IHNvbWUgZm9sa3MgYXJlIHdvbmRlcmluZyB3aGV0 aGVyIERQT1AgaXMgZXNzZW50aWFsbHkgYSBzdXBlcnNldCBvZiBNVExTIGFuZCB3aGV0aGVyIGl0 IG1ha2VzIHNlbnNlIHRvIG9ubHkgcHJvY2VlZCB3aXRoIG9uZSBzb2x1dGlvbiByYXRoZXIgcG90 ZW50aWFsbHkgdHdvLg0KPj4gDQo+PiBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBvdGhlcnMgaW4g dGhlIGdyb3VwIGhhdmUgYSBmZXcgYWJvdXQgdGhpcyBhc3BlY3Q/DQo+PiANCj4+IENpYW8NCj4+ IEhhbm5lcw0KPj4gDQo+PiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBt YWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= From nobody Tue May 7 11:17: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 9DA08120203 for ; Tue, 7 May 2019 11:17:31 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NylEz24MCWtW for ; Tue, 7 May 2019 11:17:29 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D831201C9 for ; Tue, 7 May 2019 11:17:29 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.116]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hO4ec-0003SU-EB; Tue, 07 May 2019 20:17:26 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-2A5A0743-8103-4BA7-B9D2-6172A64ADD6F; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (16E227) In-Reply-To: Date: Tue, 7 May 2019 20:17:25 +0200 Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <132A5A1F-FF8C-4EBE-BF53-66564FB7C7A7@lodderstedt.net> References: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> To: Karl McGuinness X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 18:17:32 -0000 --Apple-Mail-2A5A0743-8103-4BA7-B9D2-6172A64ADD6F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 07.05.2019 um 20:09 schrieb Karl McGuinness : >=20 > mTLS has significant challenges at scale in a multi-tenant SaaS deployment= on public clouds using modern edge technologies/services. Applications are= increasingly being built using Function-as-a-Service/ephemeral workloads as= well. Additional complexity increases if you also want to support "bring y= our own CA=E2=80=9D. Can you please share the details of those challenges with us? >=20 > DPoP enables application level deployment model independent of how one=E2=80= =99s edge or runtime is deployed/managed. This is very valuable for SaaS pr= oviders. We expect to eventually deploy a DPoP like solution for all client= models and not just SPA.=20 >=20 > -Karl >=20 >> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt wrote: >>=20 >> Hi,=20 >>=20 >> mTLS is dead simple to use, secure, is used and can be used on a broad ba= sis (in contrast to the token binding stuff). I also like the fact it provid= es both client authentication and sender-constraining. >>=20 >> We started the work on DPoP for the simple reason that SPAs don=E2=80=99t= work well with mTLS and we want to provide a solution with somehow limited c= apabilities, e.g. regarding replay protection (see DPoP introduction).=20 >>=20 >> If someone asks me for the default solution, it=E2=80=99s simple: use mTL= S. And if you build a SPA and want to do really security sensitive things, i= mplement your OAuth stuff and the RS interactions in the backend of your app= lication.=20 >>=20 >> DPoP is in a really early stage, let=E2=80=99s see where it will go. >>=20 >> best regards, >> Torsten.=20 >>=20 >>> On 7. May 2019, at 10:25, Hannes Tschofenig w= rote: >>>=20 >>> Hi all, >>>=20 >>> In the OAuth conference call today Vittorio mentioned that some folks ar= e wondering whether DPOP is essentially a superset of MTLS and whether it ma= kes sense to only proceed with one solution rather potentially two. >>>=20 >>> I was wondering whether others in the group have a few about this aspect= ? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to an= y other person, use it for any purpose, or store or copy the information in a= ny medium. Thank you. _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-2A5A0743-8103-4BA7-B9D2-6172A64ADD6F 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 HAYJKoZIhvcNAQkFMQ8XDTE5MDUwNzE4MTcyNVowLwYJKoZIhvcNAQkEMSIEIDZ5IGQYxMM0HGW8 aVS3OYfEiNgjMmAOVuaFaeQEQ12/MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTCBwAYLKoZIhvcNAQkQ AgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuY La5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQDUrz2Jhi8MsR6Z7iOnUXJ0FPJ7zkqXRmezMjwl nCjL0wEXeZYp3Fce/l9NCAltgI0mQcRuz8+ILfyxVW+9C+Z8p4PmsedF/0E4VbJC9U2Bdv2t1nCB /H2SQiLMrvkwXMZ5tceArD9HhPDuqBUYUc+GfTSCSsstdgArhrI+ozhtsDHESFV40gom6bhHkHLB Lp3TKmchqmGYLxeR8DWQSDS3m8VOAE8q3zrpIft0MnTP/PFnQeT/lTS3LmIVKTNhGLqTtBwslS7z uhIA3WjXuVpTbW0rrrVutiJ9C89JyeDelnbXPy845z3uxlSYNNP2JiG6/DLpCseix/+SJc/34whj AAAAAAAA --Apple-Mail-2A5A0743-8103-4BA7-B9D2-6172A64ADD6F-- From nobody Tue May 7 11:26: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 990D912021D for ; Tue, 7 May 2019 11:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQTiqvRTCOZS for ; Tue, 7 May 2019 11:26:06 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A562120228 for ; Tue, 7 May 2019 11:26:06 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x47IIohN071757; Tue, 7 May 2019 18:25:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=BDPxP22ASVNkq08Nkc6oDRoMoREZgjK/1BWJJIfIRfM=; b=3GsiwmVIPbCHS5VX+7ez9gfmC3p6wEEYzP4VuEojfcvhcNHd6wNmX9Extk5/IVH4TCto soNTQNzKZufn1qomRY3IjwI+5KMfur4YztIDiKE2GcLO5UipJROhQ3B/YYAWulHeSDGK YqNS2I6l1vF50jGPBDuGKyem0+GotmxmS/mqGhY/OQkhpds3jm2ZiBPkwkxYbOUSbAGD PvAV4QLtbM6PPwfgaCkzawnXx4sYhoGpO0HkuPFZVIJxTGk/qjF5sm8wJ5XYmfVICbzU VZkgSvikHCRSQCS7d7GBXLBBagZJKSDsUKJD66V3Cnja69O7T+F1ixolqOMz9PQQs3/R QA== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2s94b0q92v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 May 2019 18:25:59 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x47IPs1B028234; Tue, 7 May 2019 18:25:59 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2sagyu3nkb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 May 2019 18:25:59 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x47IPvk7010693; Tue, 7 May 2019 18:25:58 GMT Received: from [IPv6:2605:8d80:440:beaf:8149:8cb0:349c:3e2a] (/72.143.237.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 May 2019 11:25:57 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-F0560F78-2AB7-4B18-B2E5-9B4859673C84 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Tue, 7 May 2019 11:25:53 -0700 Cc: Hannes Tschofenig , IETF oauth WG , William Denniss Content-Transfer-Encoding: 7bit Message-Id: References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com> To: John Bradley X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9250 signatures=668686 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-1810050000 definitions=main-1905070118 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9250 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905070118 Archived-At: Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices 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, 07 May 2019 18:26:10 -0000 --Apple-Mail-F0560F78-2AB7-4B18-B2E5-9B4859673C84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks John. This is what I suspected but wanted to confirm.=20 Phil > On May 7, 2019, at 7:02 AM, John Bradley wrote: >=20 > The mtls spec doesn't cover the authorization endpoint. =20 >=20 > Mtls via the browser is a whole world of pain. =20 >=20 > I believe that for a native app to use mtls via a chrome custom tab or Saf= ari view controller you need to provision a certificate and private key to t= he system keystore. It is not something that can happen dynamically from th= e app. >=20 > That in practice is generally done by proprietary EMM (Enterprise Mobility= Management) systems like mobile Iron etc.=20 >=20 > I think there are also some issues with the app using the same key, it may= need to be separately provisioned to the app as well. =20 >=20 > Each OS and browser has its own twists. =20 >=20 > It is probably better to explain how to do WebAuthn based authentication v= ia the browser and app. =20 >=20 > I think there is likely more value in having a WebAuthn based authenticati= on of the app that also attests to the identity of the app than trying to do= cument all the implimented issues with MTLS via the browser. >=20 > It depends on what the working group thinks is important.=20 >=20 > John B.=20 >=20 >> On Tue, May 7, 2019, 4:33 AM Hannes Tschofenig wrote: >> Hi Phil >>=20 >> =20 >>=20 >> I believe this is a question that William and John may be able to answer.= >>=20 >> =20 >>=20 >> Should MTLS be added to a future version of the Native Apps BCP? If the a= nswer is =E2=80=9Cno=E2=80=9D, why not? >>=20 >> =20 >>=20 >> Ciao >>=20 >> Hannes >>=20 >> =20 >>=20 >> =20 >>=20 >> From: OAuth On Behalf Of Phil Hunt >> Sent: Donnerstag, 2. Mai 2019 20:41 >> To: oauth >> Subject: [OAUTH-WG] MTLS and Native apps Best practices >>=20 >> =20 >>=20 >> I was wondering if anyone had any recommended MTLS best practices for mob= ile apps and native browsers. >>=20 >> =20 >>=20 >> Considering Section 6 of RFC8252=E2=80=A6 >>=20 >> After constructing the authorization request URI, the app uses >> platform-specific APIs to open the URI in an external user-agent. >> Typically, the external user-agent used is the default browser, that >> is, the application configured for handling "http" and "https" scheme >> URIs on the system; however, different browser selection criteria and >> other categories of external user-agents MAY be used. >> =20 >>=20 >> What choices do developers have to ensure the authorization (and subseque= nt user authentication) occur over MTLS? Can the app provide its own key for= MTLS or can it ask that an embedded X.509 cert be used (assuming one is ava= ilable)? >>=20 >> =20 >>=20 >> Are there any platform issues or best practices? >>=20 >> =20 >>=20 >> Phil Hunt | Cloud Security and Identity Architect >>=20 >> Oracle Corporation, Oracle Cloud Infrastructure >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. --Apple-Mail-F0560F78-2AB7-4B18-B2E5-9B4859673C84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks John. This is what I suspected but w= anted to confirm. 

P= hil

On May 7, 2019, at 7:02 AM, John Bradley <<= a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com> wrote:

=
The mtls s= pec doesn't cover the authorization endpoint.  
<= br>
Mtls via the browser is a whole world of pain.&nb= sp; 

I believe that f= or a native app to use mtls via a chrome custom tab or Safari view controlle= r you need to provision a certificate and private key to the system keystore= .  It is not something that can happen dynamically from the app.
<= div dir=3D"auto">
That in practice is generally d= one by proprietary EMM (Enterprise Mobility Management) systems like mobile I= ron etc. 

I think th= ere are also some issues with the app using the same key, it may need to be s= eparately provisioned to the app as well.  

Each OS and browser has its own twists. &n= bsp;

It is probably bette= r to explain how to do WebAuthn based authentication via the browser and app= .  

I think the= re is likely more value in having a WebAuthn based authentication of the app= that also attests to the identity of the app than trying to document all th= e implimented issues with MTLS via the browser.

<= /div>
It depends on what the working group thinks is import= ant. 

John B. <= /div>

On Tue, May 7, 2019, 4:33 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Phil

 

I believe this is a question that William and John ma= y be able to answer.

 

Should MTLS be added to a future version of the Nativ= e Apps BCP? If the answer is =E2=80=9Cno=E2=80=9D, why not?

 

Ciao

Hannes

 

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Donnerstag, 2. Mai 2019 20:41
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] MTLS and Native apps Best practices=

 

I was wondering if anyone had any recommended MTLS be= st practices for mobile apps and native browsers.

 

Considering Section 6 of RFC8252=E2=80=A6

   After constructing the authori=
zation request URI, the app uses
   platform-specific APIs to open the URI in an external user=
-agent.
   Typically, the external user-agent used is the default bro=
wser, that
   is, the application configured for handling "http" and "ht=
tps" scheme
   URIs on the system; however, different browser selection c=
riteria and
   other categories of external user-agents MAY be used.

 

What choices do developers have to ensure the authori= zation (and subsequent user authentication) occur over MTLS? Can the app pro= vide its own key for MTLS or can it ask that an embedded X.509 cert be used (= assuming one is available)?

 

Are there any platform issues or best practices?

 

Phil Hunt | Cloud Security and Identity A= rchitect

Oracle Corporation, Oracle Cloud Infrast= ructure

@independentid

 

 

 

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confide= ntial and may also be privileged. If you are not the intended recipient, ple= ase notify the sender immediately and do not disclose the contents to any ot= her person, use it for any purpose, or store or copy the information in any medium. Thank you.
= --Apple-Mail-F0560F78-2AB7-4B18-B2E5-9B4859673C84-- From nobody Tue May 7 13:42:29 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 728E5120235 for ; Tue, 7 May 2019 13:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=okta.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 S3SUlZkzCpSn for ; Tue, 7 May 2019 13:42:24 -0700 (PDT) Received: from us-smtp-delivery-163.mimecast.com (us-smtp-delivery-163.mimecast.com [63.128.21.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CF3120226 for ; Tue, 7 May 2019 13:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=okta.com; s=mimecast20140813; t=1557261742; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JWy4xjvtOmfk8LZBWog+0Ak9xiLo4Dgh1dF1zt/0aXg=; b=FrjmmjrdcB7huCxfei9LmMPw9i6v9Sq0zA1f5YW1eoYl6/bCN/K8K0Q+94LksdfxHOeOmP JbV8KVyNeemBF1/xwxtgbxehLN0G38p3X5jOT+05ZSuOIuEkiT8HeL0sVFQlgip+8fOHcN ibW0lO4WoZp2OD6/uXeaQetCa3MBeeE= Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2050.outbound.protection.outlook.com [104.47.46.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-126-kHe_qomiNfa0AqFEg_Y2iA-1; Tue, 07 May 2019 16:42:21 -0400 Received: from BYAPR05MB4133.namprd05.prod.outlook.com (52.135.199.154) by BYAPR05MB6198.namprd05.prod.outlook.com (20.178.55.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.11; Tue, 7 May 2019 20:42:19 +0000 Received: from BYAPR05MB4133.namprd05.prod.outlook.com ([fe80::1fa:75b8:92d7:93b4]) by BYAPR05MB4133.namprd05.prod.outlook.com ([fe80::1fa:75b8:92d7:93b4%4]) with mapi id 15.20.1878.019; Tue, 7 May 2019 20:42:19 +0000 From: Karl McGuinness To: Torsten Lodderstedt CC: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] MTLS vs. DPOP Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQAT1IGAAADrJIAAAEMOgAAFD4KA Date: Tue, 7 May 2019 20:42:19 +0000 Message-ID: <93AEC302-1D48-47C5-AA2F-5F21EE8935F9@okta.com> References: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> <132A5A1F-FF8C-4EBE-BF53-66564FB7C7A7@lodderstedt.net> In-Reply-To: <132A5A1F-FF8C-4EBE-BF53-66564FB7C7A7@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.24.59.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ded476e-27f7-4225-68bf-08d6d32c7ff6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR05MB6198; x-ms-traffictypediagnostic: BYAPR05MB6198: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(136003)(396003)(39860400002)(346002)(189003)(199004)(53754006)(40434004)(8936002)(68736007)(478600001)(71190400001)(83716004)(66946007)(71200400001)(81156014)(8676002)(81166006)(26005)(606006)(73956011)(76116006)(82746002)(316002)(66446008)(66556008)(66476007)(64756008)(966005)(5024004)(14444005)(14454004)(256004)(6916009)(33656002)(76176011)(7736002)(66066001)(486006)(11346002)(446003)(2616005)(476003)(229853002)(53936002)(4326008)(186003)(25786009)(6246003)(54906003)(99286004)(86362001)(36756003)(53546011)(6506007)(2906002)(5660300002)(236005)(3846002)(6116002)(6486002)(6512007)(102836004)(6306002)(54896002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6198; H:BYAPR05MB4133.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ep+2pEIT45YbOgGnwVfhkdyx+Sj77lhRzf16dtgrwF8BIPoPCthGEbf2tOFMSinXLk9YiuA6QXHM7QJ9TViI118U1TPoQc+YZAx40v4TEA+4ZgqF9JevPmzO8Pb7u785RvY16FbidWk39K3SXhbB9VVGuxv0krCdcMISMunSl26gO9rK7dTdUdHLwnMSah4MbZwmhlrs/SRiQleE92oqI0hzO4e9IYiHLzNl+kwY0Od0fdj6Fmgrko2m8+3UtF3BsO3XiuOUuRW1OWrtlDaOF/LrUchjL5vXMxUSYz9CHjnMjppevE+S2ZtlD1w7QzqtVAHgMwsoQYCX8nAZhjbbQiYG1r4attLhiS4XJbTGaNkLX4bGenOX3/tzzDRZQA90vn0WZ5YNF0eJOhOw1yYWcEW/LIp+0PBvLTn5WuPrQjU= MIME-Version: 1.0 X-OriginatorOrg: okta.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ded476e-27f7-4225-68bf-08d6d32c7ff6 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 20:42:19.7411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f1f9fcc4-c616-4261-8a82-855dc9cb8486 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6198 X-MC-Unique: kHe_qomiNfa0AqFEg_Y2iA-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_93AEC3021D4847C5AA2F5F21EE8935F9oktacom_" Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 20:42:28 -0000 --_000_93AEC3021D4847C5AA2F5F21EE8935F9oktacom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 MSkgWW91IG9mdGVuIG5lZWQgdG8gZGVwbG95IHlvdXIgY2xvdWQgZWRnZSBsb2FkIGJhbGFuY2Vy IGluIFRDUCBtb2RlIGFuZCBoYW5kbGUgeW91ciBvd24gVExTIHRlcm1pbmF0aW9uIGlmIHlvdSB3 YW50IGNsaWVudCBhdXRoZW50aWNhdGlvbi4NCjIpIFRoZXJlIGFyZSBvZnRlbiBtYW55IGludGVy bWVkaWF0ZXMgYmV0d2VlbiB5b3VyIGVkZ2Ugd2hlcmUgY2xpZW50IFRMUyBpcyB0ZXJtaW5hdGVk IGFuZCB5b3VyIGFjdHVhbCBzZXJ2aWNlLiAgWW91IG5lZWQgdG8gZm9yd2FyZCBjZXJ0IGNvbnRl eHQgZnJvbSB0aGUgZWRnZSBhcyBwcm90ZWN0ZWQgaGVhZGVycyB0byB5b3VyIEFTLg0KMykgSXQn cyBub3QgZWFzeSB0byB1c2UgZGlmZmVyZW50IHRydXN0IHJvb3RzIHBlciB0ZW5hbnQgZm9yIGNs aWVudCBhdXRoZW50aWNhdGlvbi4gIFNOSSBpcyBub3Qgc3VwcG9ydGVkIGFzIGEgc2VsZWN0b3Ig dmlhIG9mZiB0aGUgc2hlbGYgc29sdXRpb25zIGFuZCByZXF1aXJlcyBhIHNvZnR3YXJlIGRlZmlu ZWQgbmV0d29yayAoU0ROKSBzb2x1dGlvbi4NCg0KT24gdGhlIEZhYVMgc2lkZSBjbGllbnQgY29t cGxleGl0eSBpcyB0aGVyZSBlc3BlY2lhbGx5IHdpdGggT3BlblNTTCBiaW5kaW5ncw0KDQoxKSBo dHRwczovL21lZGl1bS5jb20vQHZhbmVlay91c2luZy1tdXR1YWwtdGxzLWF1dGhlbnRpY2F0aW9u LWluLWEtc2VydmVybGVzcy13b3JsZC0zYWZkMTlhNmZlNzANCg0KLUthcmwNCg0KT24gTWF5IDcs IDIwMTksIGF0IDExOjE3IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCg0KDQoNCkFt IDA3LjA1LjIwMTkgdW0gMjA6MDkgc2NocmllYiBLYXJsIE1jR3Vpbm5lc3MgPGttY2d1aW5uZXNz QG9rdGEuY29tPG1haWx0bzprbWNndWlubmVzc0Bva3RhLmNvbT4+Og0KDQptVExTIGhhcyBzaWdu aWZpY2FudCBjaGFsbGVuZ2VzIGF0IHNjYWxlIGluIGEgbXVsdGktdGVuYW50IFNhYVMgZGVwbG95 bWVudCBvbiBwdWJsaWMgY2xvdWRzIHVzaW5nIG1vZGVybiBlZGdlIHRlY2hub2xvZ2llcy9zZXJ2 aWNlcy4gIEFwcGxpY2F0aW9ucyBhcmUgaW5jcmVhc2luZ2x5IGJlaW5nIGJ1aWx0IHVzaW5nIEZ1 bmN0aW9uLWFzLWEtU2VydmljZS9lcGhlbWVyYWwgd29ya2xvYWRzIGFzIHdlbGwuICBBZGRpdGlv bmFsIGNvbXBsZXhpdHkgaW5jcmVhc2VzIGlmIHlvdSBhbHNvIHdhbnQgdG8gc3VwcG9ydCAiYnJp bmcgeW91ciBvd24gQ0HigJ0uDQoNCkNhbiB5b3UgcGxlYXNlIHNoYXJlIHRoZSBkZXRhaWxzIG9m IHRob3NlIGNoYWxsZW5nZXMgd2l0aCB1cz8NCg0KDQpEUG9QIGVuYWJsZXMgYXBwbGljYXRpb24g bGV2ZWwgZGVwbG95bWVudCBtb2RlbCBpbmRlcGVuZGVudCBvZiBob3cgb25l4oCZcyBlZGdlIG9y IHJ1bnRpbWUgaXMgZGVwbG95ZWQvbWFuYWdlZC4gIFRoaXMgaXMgdmVyeSB2YWx1YWJsZSBmb3Ig U2FhUyBwcm92aWRlcnMuICBXZSBleHBlY3QgdG8gZXZlbnR1YWxseSBkZXBsb3kgYSBEUG9QIGxp a2Ugc29sdXRpb24gZm9yIGFsbCBjbGllbnQgbW9kZWxzIGFuZCBub3QganVzdCBTUEEuDQoNCi1L YXJsDQoNCk9uIE1heSA3LCAyMDE5LCBhdCAxMDo0MyBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4g d3JvdGU6DQoNCkhpLA0KDQptVExTIGlzIGRlYWQgc2ltcGxlIHRvIHVzZSwgc2VjdXJlLCBpcyB1 c2VkIGFuZCBjYW4gYmUgdXNlZCBvbiBhIGJyb2FkIGJhc2lzIChpbiBjb250cmFzdCB0byB0aGUg dG9rZW4gYmluZGluZyBzdHVmZikuIEkgYWxzbyBsaWtlIHRoZSBmYWN0IGl0IHByb3ZpZGVzIGJv dGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBzZW5kZXItY29uc3RyYWluaW5nLg0KDQpXZSBz dGFydGVkIHRoZSB3b3JrIG9uIERQb1AgZm9yIHRoZSBzaW1wbGUgcmVhc29uIHRoYXQgU1BBcyBk b27igJl0IHdvcmsgd2VsbCB3aXRoIG1UTFMgYW5kIHdlIHdhbnQgdG8gcHJvdmlkZSBhIHNvbHV0 aW9uIHdpdGggc29tZWhvdyBsaW1pdGVkIGNhcGFiaWxpdGllcywgZS5nLiByZWdhcmRpbmcgcmVw bGF5IHByb3RlY3Rpb24gKHNlZSBEUG9QIGludHJvZHVjdGlvbikuDQoNCklmIHNvbWVvbmUgYXNr cyBtZSBmb3IgdGhlIGRlZmF1bHQgc29sdXRpb24sIGl04oCZcyBzaW1wbGU6IHVzZSBtVExTLiBB bmQgaWYgeW91IGJ1aWxkIGEgU1BBIGFuZCB3YW50IHRvIGRvIHJlYWxseSBzZWN1cml0eSBzZW5z aXRpdmUgdGhpbmdzLCBpbXBsZW1lbnQgeW91ciBPQXV0aCBzdHVmZiBhbmQgdGhlIFJTIGludGVy YWN0aW9ucyBpbiB0aGUgYmFja2VuZCBvZiB5b3VyIGFwcGxpY2F0aW9uLg0KDQpEUG9QIGlzIGlu IGEgcmVhbGx5IGVhcmx5IHN0YWdlLCBsZXTigJlzIHNlZSB3aGVyZSBpdCB3aWxsIGdvLg0KDQpi ZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpPbiA3LiBNYXkgMjAxOSwgYXQgMTA6MjUsIEhhbm5l cyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNj aG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KSW4gdGhlIE9BdXRoIGNvbmZl cmVuY2UgY2FsbCB0b2RheSBWaXR0b3JpbyBtZW50aW9uZWQgdGhhdCBzb21lIGZvbGtzIGFyZSB3 b25kZXJpbmcgd2hldGhlciBEUE9QIGlzIGVzc2VudGlhbGx5IGEgc3VwZXJzZXQgb2YgTVRMUyBh bmQgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBvbmx5IHByb2NlZWQgd2l0aCBvbmUgc29sdXRp b24gcmF0aGVyIHBvdGVudGlhbGx5IHR3by4NCg0KSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgb3Ro ZXJzIGluIHRoZSBncm91cCBoYXZlIGEgZmV3IGFib3V0IHRoaXMgYXNwZWN0Pw0KDQpDaWFvDQpI YW5uZXMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91LiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KDQo= --_000_93AEC3021D4847C5AA2F5F21EE8935F9oktacom_ Content-Type: text/html; charset=UTF-8 Content-ID: <338956D994C1474EBFF861EA3CB58CAC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjEpIFlvdSBvZnRlbiBuZWVkIHRvIGRlcGxveSB5 b3VyIGNsb3VkIGVkZ2UgbG9hZCBiYWxhbmNlciBpbiBUQ1AgbW9kZSBhbmQgaGFuZGxlIHlvdXIg b3duIFRMUyB0ZXJtaW5hdGlvbiBpZiB5b3Ugd2FudCBjbGllbnQgYXV0aGVudGljYXRpb24uJm5i c3A7DQo8ZGl2IGNsYXNzPSIiPjIpIFRoZXJlIGFyZSBvZnRlbiBtYW55IGludGVybWVkaWF0ZXMg YmV0d2VlbiB5b3VyIGVkZ2Ugd2hlcmUgY2xpZW50IFRMUyBpcyB0ZXJtaW5hdGVkIGFuZCB5b3Vy IGFjdHVhbCBzZXJ2aWNlLiAmbmJzcDtZb3UgbmVlZCB0byBmb3J3YXJkIGNlcnQgY29udGV4dCBm cm9tIHRoZSBlZGdlIGFzIHByb3RlY3RlZCBoZWFkZXJzIHRvIHlvdXIgQVMuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjMpIEl0J3Mgbm90IGVhc3kgdG8gdXNlIGRpZmZlcmVudCB0cnVzdCByb290cyBw ZXIgdGVuYW50IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uICZuYnNwO1NOSSBpcyBub3Qgc3Vw cG9ydGVkIGFzIGEgc2VsZWN0b3IgdmlhIG9mZiB0aGUgc2hlbGYgc29sdXRpb25zIGFuZCByZXF1 aXJlcyBhIHNvZnR3YXJlIGRlZmluZWQgbmV0d29yayAoU0ROKSBzb2x1dGlvbi48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9uIHRoZSBG YWFTIHNpZGUgY2xpZW50IGNvbXBsZXhpdHkgaXMgdGhlcmUgZXNwZWNpYWxseSB3aXRoIE9wZW5T U0wgYmluZGluZ3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjEpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tZWRpdW0uY29tL0B2YW5lZWsv dXNpbmctbXV0dWFsLXRscy1hdXRoZW50aWNhdGlvbi1pbi1hLXNlcnZlcmxlc3Mtd29ybGQtM2Fm ZDE5YTZmZTcwIiBjbGFzcz0iIj5odHRwczovL21lZGl1bS5jb20vQHZhbmVlay91c2luZy1tdXR1 YWwtdGxzLWF1dGhlbnRpY2F0aW9uLWluLWEtc2VydmVybGVzcy13b3JsZC0zYWZkMTlhNmZlNzA8 L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tS2FybDxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBN YXkgNywgMjAxOSwgYXQgMTE6MTcgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9 Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgY2xhc3M9IiI+dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BbSAwNy4w NS4yMDE5IHVtIDIwOjA5IHNjaHJpZWIgS2FybCBNY0d1aW5uZXNzICZsdDs8YSBocmVmPSJtYWls dG86a21jZ3Vpbm5lc3NAb2t0YS5jb20iIGNsYXNzPSIiPmttY2d1aW5uZXNzQG9rdGEuY29tPC9h PiZndDs6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KbVRMUyBoYXMgc2lnbmlmaWNhbnQg Y2hhbGxlbmdlcyBhdCBzY2FsZSBpbiBhIG11bHRpLXRlbmFudCBTYWFTIGRlcGxveW1lbnQgb24g cHVibGljIGNsb3VkcyB1c2luZyBtb2Rlcm4gZWRnZSB0ZWNobm9sb2dpZXMvc2VydmljZXMuICZu YnNwO0FwcGxpY2F0aW9ucyBhcmUgaW5jcmVhc2luZ2x5IGJlaW5nIGJ1aWx0IHVzaW5nIEZ1bmN0 aW9uLWFzLWEtU2VydmljZS9lcGhlbWVyYWwgd29ya2xvYWRzIGFzIHdlbGwuICZuYnNwO0FkZGl0 aW9uYWwgY29tcGxleGl0eSBpbmNyZWFzZXMNCiBpZiB5b3UgYWxzbyB3YW50IHRvIHN1cHBvcnQg JnF1b3Q7YnJpbmcgeW91ciBvd24gQ0HigJ0uPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KQ2FuIHlvdSBwbGVhc2Ugc2hhcmUgdGhlIGRldGFpbHMgb2YgdGhvc2Ug Y2hhbGxlbmdlcyB3aXRoIHVzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkRQb1AgZW5hYmxlcyBhcHBs aWNhdGlvbiBsZXZlbCBkZXBsb3ltZW50IG1vZGVsIGluZGVwZW5kZW50IG9mIGhvdyBvbmXigJlz IGVkZ2Ugb3IgcnVudGltZSBpcyBkZXBsb3llZC9tYW5hZ2VkLiAmbmJzcDtUaGlzIGlzIHZlcnkg dmFsdWFibGUgZm9yIFNhYVMgcHJvdmlkZXJzLiAmbmJzcDtXZSBleHBlY3QgdG8gZXZlbnR1YWxs eSBkZXBsb3kgYSBEUG9QIGxpa2Ugc29sdXRpb24gZm9yIGFsbCBjbGllbnQgbW9kZWxzIGFuZCBu b3QganVzdCBTUEEuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotS2FybDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9u IE1heSA3LCAyMDE5LCBhdCAxMDo0MyBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiBjbGFzcz0iIj50b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhp LCA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQptVExTIGlzIGRlYWQgc2ltcGxlIHRvIHVz ZSwgc2VjdXJlLCBpcyB1c2VkIGFuZCBjYW4gYmUgdXNlZCBvbiBhIGJyb2FkIGJhc2lzIChpbiBj b250cmFzdCB0byB0aGUgdG9rZW4gYmluZGluZyBzdHVmZikuIEkgYWxzbyBsaWtlIHRoZSBmYWN0 IGl0IHByb3ZpZGVzIGJvdGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBzZW5kZXItY29uc3Ry YWluaW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldlIHN0YXJ0ZWQgdGhlIHdvcmsg b24gRFBvUCBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCBTUEFzIGRvbuKAmXQgd29yayB3ZWxs IHdpdGggbVRMUyBhbmQgd2Ugd2FudCB0byBwcm92aWRlIGEgc29sdXRpb24gd2l0aCBzb21laG93 IGxpbWl0ZWQgY2FwYWJpbGl0aWVzLCBlLmcuIHJlZ2FyZGluZyByZXBsYXkgcHJvdGVjdGlvbiAo c2VlIERQb1AgaW50cm9kdWN0aW9uKS4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklm IHNvbWVvbmUgYXNrcyBtZSBmb3IgdGhlIGRlZmF1bHQgc29sdXRpb24sIGl04oCZcyBzaW1wbGU6 IHVzZSBtVExTLiBBbmQgaWYgeW91IGJ1aWxkIGEgU1BBIGFuZCB3YW50IHRvIGRvIHJlYWxseSBz ZWN1cml0eSBzZW5zaXRpdmUgdGhpbmdzLCBpbXBsZW1lbnQgeW91ciBPQXV0aCBzdHVmZiBhbmQg dGhlIFJTIGludGVyYWN0aW9ucyBpbiB0aGUgYmFja2VuZCBvZiB5b3VyIGFwcGxpY2F0aW9uLg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRFBvUCBpcyBpbiBhIHJlYWxseSBlYXJseSBz dGFnZSwgbGV04oCZcyBzZWUgd2hlcmUgaXQgd2lsbCBnby48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpiZXN0IHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KVG9yc3Rlbi4gPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gNy4g TWF5IDIwMTksIGF0IDEwOjI1LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRv Okhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIGNsYXNzPSIiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBhbGws PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gdGhlIE9BdXRoIGNvbmZlcmVuY2UgY2Fs bCB0b2RheSBWaXR0b3JpbyBtZW50aW9uZWQgdGhhdCBzb21lIGZvbGtzIGFyZSB3b25kZXJpbmcg d2hldGhlciBEUE9QIGlzIGVzc2VudGlhbGx5IGEgc3VwZXJzZXQgb2YgTVRMUyBhbmQgd2hldGhl ciBpdCBtYWtlcyBzZW5zZSB0byBvbmx5IHByb2NlZWQgd2l0aCBvbmUgc29sdXRpb24gcmF0aGVy IHBvdGVudGlhbGx5IHR3by48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdhcyB3b25k ZXJpbmcgd2hldGhlciBvdGhlcnMgaW4gdGhlIGdyb3VwIGhhdmUgYSBmZXcgYWJvdXQgdGhpcyBh c3BlY3Q/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2lhbzxiciBjbGFzcz0iIj4NCkhh bm5lczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_93AEC3021D4847C5AA2F5F21EE8935F9oktacom_-- From nobody Tue May 7 22:56: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 0C8D7120134 for ; Tue, 7 May 2019 22:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7mAj8nkO6cy for ; Tue, 7 May 2019 22:55:56 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id D10E912008C for ; Tue, 7 May 2019 22:55:56 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:1c11:55a1:19fa:b678] (unknown [IPv6:2601:282:202:b210:1c11:55a1:19fa:b678]) by alkaline-solutions.com (Postfix) with ESMTPSA id 2936E31794; Wed, 8 May 2019 05:55:55 +0000 (UTC) From: David Waite Message-Id: <964BEC93-473E-4D4D-96F0-AB25CCFB2AC5@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_37C68E3C-0509-4A91-B329-D5CC425C977D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 May 2019 23:55:54 -0600 In-Reply-To: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> Cc: Hannes Tschofenig , "oauth@ietf.org" To: George Fletcher References: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 05:55:58 -0000 --Apple-Mail=_37C68E3C-0509-4A91-B329-D5CC425C977D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 7, 2019, at 8:12 AM, George Fletcher = wrote: >=20 > To compromise an MTLS bound token the attacker has to compromise the = private key. To compromise a DPOP bound token, depending on what HTTP = request elements are signed, and whether the DPOP is managed as = one-time-use etc, there are additional attacks. (Ducks head and waits = for all the real security experts to prove me wrong:) Both should wind up supporting either longer-term, issued keys or = ephemeral keys - and either exportable or not. Off the top of my head, if your application is compromised I can=E2=80=99t= think of a difference in the kinds of abuse that could be performed = with equivalent policies and key protections. -DW= --Apple-Mail=_37C68E3C-0509-4A91-B329-D5CC425C977D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 7, 2019, at 8:12 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

To compromise an MTLS bound token the attacker has to = compromise the private key. To compromise a DPOP bound token, depending = on what HTTP request elements are signed, and whether the DPOP is = managed as one-time-use etc, there are additional attacks. (Ducks head = and waits for all the real security experts to prove me = wrong:)

Both= should wind up supporting either longer-term, issued keys or ephemeral = keys - and either exportable or not.

Off the top of my head, if your = application is compromised I can=E2=80=99t think of a difference in the = kinds of abuse that could be performed with equivalent policies and key = protections.

-DW
= --Apple-Mail=_37C68E3C-0509-4A91-B329-D5CC425C977D-- From nobody Wed May 8 00:32: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 6565E120041 for ; Wed, 8 May 2019 00:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lndKlzL_6T6J for ; Wed, 8 May 2019 00:32:53 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A1312002F for ; Wed, 8 May 2019 00:32:53 -0700 (PDT) Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hOH4J-0003Vt-I0; Wed, 08 May 2019 09:32:47 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_83F680DF-72D5-4259-99EB-14C1877DA8C3"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 8 May 2019 09:32:46 +0200 In-Reply-To: <93AEC302-1D48-47C5-AA2F-5F21EE8935F9@okta.com> Cc: Hannes Tschofenig , "oauth@ietf.org" To: Karl McGuinness References: <6A97A589-FB03-4EE3-8403-43D12E82071C@lodderstedt.net> <132A5A1F-FF8C-4EBE-BF53-66564FB7C7A7@lodderstedt.net> <93AEC302-1D48-47C5-AA2F-5F21EE8935F9@okta.com> X-Mailer: Apple Mail (2.3445.104.8) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS vs. DPOP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 07:32:56 -0000 --Apple-Mail=_83F680DF-72D5-4259-99EB-14C1877DA8C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Karl, > On 7. May 2019, at 22:42, Karl McGuinness = wrote: >=20 > 1) You often need to deploy your cloud edge load balancer in TCP mode = and handle your own TLS termination if you want client authentication.=20= I like that option since it gives end2end transport security for your = application. Unfortunately, that=E2=80=99s not supported by all cloud = platforms.=20 > 2) There are often many intermediates between your edge where client = TLS is terminated and your actual service. You need to forward cert = context from the edge as protected headers to your AS. That=E2=80=99s certainly true. The mTLS implementations I know all = support passing the certificate from the TLS handshake via header = parameter. Brian Campbell wrote a draft about this topic for token = binding (https://tools.ietf.org/html/draft-ietf-tokbind-ttrp), but = conceptually the same holds true for mTLS.=20 Clearly, authenticity and integrity of the request between proxy and = consuming service must be ensured, TLS in conjunction with shared = secrets or TLS Client authentication could be used for that purpose or = even network mechanisms.=20 > 3) It's not easy to use different trust roots per tenant for client = authentication. =20 That=E2=80=99s required if you use the PKI mode. I would recommend to = use the self-signed mode (in combination with the optional_no_ca setting = at your TLS terminating proxy), which does not require any trust root. = Given you consider using DPoP, which uses raw keys, self-signed should = be fine for you as well. =20 > SNI is not supported as a selector via off the shelf solutions and = requires a software defined network (SDN) solution. >=20 > On the FaaS side client complexity is there especially with OpenSSL = bindings >=20 > 1) = https://medium.com/@vaneek/using-mutual-tls-authentication-in-a-serverless= -world-3afd19a6fe70 As far as I understand this article, it=E2=80=99s mainly about PKI. So = again, use mTLS in conjunction with self-signed certs and = optional_no_ca. kind regards, Torsten. =20 >=20 > -Karl >=20 >> On May 7, 2019, at 11:17 AM, Torsten Lodderstedt = wrote: >>=20 >>=20 >>=20 >>> Am 07.05.2019 um 20:09 schrieb Karl McGuinness = : >>>=20 >>> mTLS has significant challenges at scale in a multi-tenant SaaS = deployment on public clouds using modern edge technologies/services. = Applications are increasingly being built using = Function-as-a-Service/ephemeral workloads as well. Additional = complexity increases if you also want to support "bring your own CA=E2=80=9D= . >>=20 >> Can you please share the details of those challenges with us? >>=20 >>>=20 >>> DPoP enables application level deployment model independent of how = one=E2=80=99s edge or runtime is deployed/managed. This is very = valuable for SaaS providers. We expect to eventually deploy a DPoP like = solution for all client models and not just SPA.=20 >>>=20 >>> -Karl >>>=20 >>>> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt = wrote: >>>>=20 >>>> Hi,=20 >>>>=20 >>>> mTLS is dead simple to use, secure, is used and can be used on a = broad basis (in contrast to the token binding stuff). I also like the = fact it provides both client authentication and sender-constraining. >>>>=20 >>>> We started the work on DPoP for the simple reason that SPAs don=E2=80= =99t work well with mTLS and we want to provide a solution with somehow = limited capabilities, e.g. regarding replay protection (see DPoP = introduction).=20 >>>>=20 >>>> If someone asks me for the default solution, it=E2=80=99s simple: = use mTLS. And if you build a SPA and want to do really security = sensitive things, implement your OAuth stuff and the RS interactions in = the backend of your application.=20 >>>>=20 >>>> DPoP is in a really early stage, let=E2=80=99s see where it will = go. >>>>=20 >>>> best regards, >>>> Torsten.=20 >>>>=20 >>>>> On 7. May 2019, at 10:25, Hannes Tschofenig = wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> In the OAuth conference call today Vittorio mentioned that some = folks are wondering whether DPOP is essentially a superset of MTLS and = whether it makes sense to only proceed with one solution rather = potentially two. >>>>>=20 >>>>> I was wondering whether others in the group have a few about this = aspect? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> IMPORTANT NOTICE: The contents of this email and any attachments = are confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. = _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 --Apple-Mail=_83F680DF-72D5-4259-99EB-14C1877DA8C3 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 Fw0xOTA1MDgwNzMyNDZaMC8GCSqGSIb3DQEJBDEiBCBWwT0L7kubNvYjPfiY8qnR81iPey3iYsjj AcTusSMegjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBACc6Pme4bfXGlaJFNjC0gr9o0DIEODrxAN/MXjLH+wL6Wwxjdiy5QOeumn3U OCX5D3T4z27m5UruNn1b80zLVkTTU76o6PLwhJ3ptkyL3RBIQk4Z7r146RmwOzMw5x4Nq4sCBh0n G1drKRfqJgpRtiJNaSB3a//20bFuqfxCUjmbClg8LWUCskNcJSR38q1X77hoemnil3nNR8Y29zBi txGB0H17ceH9cJPA/ToKLT2lMl3GmbnbU5rqc5hPckPw/g9/y81wiH9QDwYuQ74YAgcBUs512cG4 RxGHEDuZ3zmBXgOhhneDt083E/EW/0fTv3sgNSTXYVu/MZStmpu8FN4AAAAAAAA= --Apple-Mail=_83F680DF-72D5-4259-99EB-14C1877DA8C3-- From nobody Wed May 8 00:38: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 B46E912008B for ; Wed, 8 May 2019 00:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak1p-BepClla for ; Wed, 8 May 2019 00:38:06 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849F312002F for ; Wed, 8 May 2019 00:38:06 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id e56so21112113ede.7 for ; Wed, 08 May 2019 00:38:06 -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=iGAXywihdZzc0vXYOyg28Wv6y1u3QQEhQYv2FP4EaAs=; b=XnuPlI1ElYrY+Hhu+OeiY8YF798Bm596d5LF77/XeSpFBscgpXeHbz6kQNA2HyzIlE +5/4AV0p+hbMhMQSJC43gSA5/vGRlWADXJqyXqvQ+4IBD/5EmYm4+br/yfLbiyFEoBMf h8kGXKErBWAkKswQiGoBiPGZULsz7v4uE1trXeyVocl4vTZpN/gAEkoIPMi+E6ybYdco ibEdsBQaSQVDbSKrvri77VhLLQWOHgDp1Gjj7+D4BeB3UzuhPYs+hHP/4c0MAm8/ZbP4 AlERjXhE+LxfzZRepGd66oY0e1T/7tMqjAPkhQIFKpVkh+y1nQLTAgTCQa3+koTfhMKm 9dsQ== 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=iGAXywihdZzc0vXYOyg28Wv6y1u3QQEhQYv2FP4EaAs=; b=XWlqq3K2g3Z1JPgRNK7+oimqnAkU2Bq3KyatjKUbn1MiGMnN8qec2ES6JIjrIEdHwK yv6z3M5Tu1LivOoia9lbRAH5VxzxDEg9QUKfmfg5c2iKdUyPKihsfL6rG365IPbSlW2C pWLbb4Ozuv5HaLqVFE3N3D1SadUbDicQKG41vzuPyPjxicyzgTBxlkZQacmCrXRxan95 9oYbrer5mm7CZ5xZ3758v52K35ggderAWAylYjqS5hZwTKzG4GNH8B+v4xjfaShpBzOt ECn6Ky1kaa5R5Ba7qiiJn59mIyCsPUG/hu2UYx04z4ijFpfQnxzmtIT1mkpHWjT5ep4q tKSw== X-Gm-Message-State: APjAAAUHT08ySdztF2a6swmV6YIbsfmYBpVT6zIbjL2OeZcd5ISjCpzR FnKg5aOjc5VMWI5hTLaD4hAttxMtxb4= X-Google-Smtp-Source: APXvYqz8owo+IYcVy2EO6sYM8b9LMnnHrKdgQpphw5Qyok7O7+iNc6mKtZC5ZfIrflVBEelHjaMKtg== X-Received: by 2002:a17:906:6410:: with SMTP id d16mr28322349ejm.75.1557301084578; Wed, 08 May 2019 00:38:04 -0700 (PDT) Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id o15sm4913645edj.44.2019.05.08.00.38.03 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 May 2019 00:38:03 -0700 (PDT) From: Emond Papegaaij To: oauth@ietf.org Date: Wed, 08 May 2019 09:37:56 +0200 Message-ID: <2125064.3GpWMRz4CO@papegaaij> In-Reply-To: References: <11125817.AKI43N3Yza@papegaaij> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps 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, 08 May 2019 07:38:09 -0000 Hi, Thanks for your detailed reply. I've replied inline. On maandag 6 mei 2019 22:42:09 CEST David Waite wrote: > On May 6, 2019, at 1:42 PM, Emond Papegaaij =20 wrote: > > For a browser-based app, we try to follow the recommendations set in > > draft- > > ietf-oauth-browser-based-apps-01. This does allow us to create a secure > > OAuth 2.0 browser-based application, but at the moment it comes at a co= st > > wrt. user experience when the access token expires. Our current solution > > forces us to redirect the user to the authorization server for a new > > authorization code. This will destroy most state the browser-based app > > has, causing the user to loose data. We are looking for a way to get a > > new access token in a secure way without disrupting the user. > > As a refresh token is not issued to the app (as it should be), the > > application is forced to do a front-channel re-authentication for an > > authorization code. We are thinking of letting this front-channel > > communication happen in a hidden iframe. Naturally, this can only be do= ne > > if no user interaction is required, hence we want to use the OIDC > > prompt=3Dnone. Is this a viable way of doing this re-authentication? Ca= n it > > hurt to open up our authorization server for non- interactive > > authorization requests inside an iframe? At the moment we do not allow > > iframes at all. >=20 > Some AS implementations will block authentication in an iframe, but will > allow you to use the OIDC prompt=3Dnone. This is already used quite often > today by implicit apps. It is possible that AS implementations may allow > iframes in the future, by detecting the frame is not covered with any > buttons, and having the authentication be based on phishing-resistant > authentication methods like W3C Web Authentication. =46ortunately for us, we build the AS as well, so we are in control here. I= t is=20 a bit unfortunate that this does depend on OIDC. Doing user interaction in = an=20 iframe seems like a snake pit I'd rather not go into. I think it's also bad= =20 wrt the user interaction. We do not want user to enter their credentials on= =20 any site that looks like our AS. Users should only enter their credentials= =20 when the URL matches or AS. > You could also trigger re-authorization with a user click, thus allowing > opening the AS in a new window or tab. Once back on the site via callback, > the temporary/pop-up window can do things like exchange the code for an > access token, persist it, postMessage the original window, do window.clos= e, > etc. This would work, but would really be a nuisance to the user. Especially wit= h a=20 token timeout of just one hour. Also, most of the times there would be no=20 interaction, the user would just have to click a button. As a user I wouldn= 't=20 understand why I have to do that all the time. > On the other hand, refresh tokens IMHO are given quite a bit more fear in > browser apps than warranted. It really depends on the AS - whether it can > tie refresh tokens to the user=E2=80=99s authentication, or if they are t= ied to a > long-term / persisted / "offline=E2=80=9D authorization independent of an= active > user authentication. Currently, the latter is more common in > implementations, and doesn=E2=80=99t make sense for browser applications.= This > doesn=E2=80=99t mean refresh tokens are automatically discounted for all > environments. How would you tie a refresh token to a user session on the AS? This would=20 depend on the user visiting the AS on a regular basis and using a logout=20 button when done. Most people simply close their browser when they're done,= =20 leaving the session open. Also, when making a call to the token endpoint to= =20 refresh the access token, there is no way of knowing that this call is=20 actually initiated by the user, because it's done on a back channel. Perhap= s=20 this can be solved with DPOP with a keypair per browser, but this would rea= lly=20 complicate the whole solution. > Given the choice between an 8 hour access token, or a 10 minute access to= ken > and a refresh token that will expire at a maximum of 8 hours, the second > provides quite a few more options to be more secure. (eg. checking backing > user session and revocation, checking for updates to client blacklist, the > rotation of the access token, rotating refresh tokens to prevent use by > more than one client, expiring access on inactivity based on lag in > refreshing, and so on). I agree with you on this, but the spec currently states clearly that the AS= =20 should not issue refresh tokens to an SPA. Do you think this should be chan= ged=20 to something like: Authorization servers SHOULD NOT issue *offline* refresh= =20 tokens to browser-based applications. A refresh token should be tied to a u= ser=20 session on the AS. > If the refresh token is tied to the AS concept of user session, then it > mostly replaces the =E2=80=98hidden iframe=E2=80=99 use above - you=E2=80= =99ll only have your > refresh token expire when the AS is asking for user presence on the front > channel, presumably for interaction. Although, I suppose in some > environments there could be a non-interactive reauthentication/factor as > well (such as kerberos, MTLS, or re-verifying user location via geoip) > where a hidden iframe might still provide UX benefit. In our case or AS might have to federate the authentication to some other A= S,=20 that would only work in an iframe. Therefore, I think we will go for the OI= DC=20 prompt=3Dnone in a hidden iframe. I'm not sure what to do if the AS reports= that=20 interaction is required, but at least the majority of the cases will be=20 covered. Best regards, Emond Papegaaij From nobody Wed May 8 00:51:27 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 31FAB12002F for ; Wed, 8 May 2019 00:51:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 a_WGQ95U3erb for ; Wed, 8 May 2019 00:51:19 -0700 (PDT) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B485D120020 for ; Wed, 8 May 2019 00:51:19 -0700 (PDT) Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id OHMChIhiCZ0SbOHMDh5QAn; Wed, 08 May 2019 00:51:18 -0700 To: oauth@ietf.org References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> From: Vladimir Dzhuvinov Openpgp: preference=signencrypt Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ== Organization: Connect2id Ltd. Message-ID: Date: Wed, 8 May 2019 10:51:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4951DFA39B4AB493E3459F55" Content-Language: en-US X-CMAE-Envelope: MS4wfLuLo/WeczN02Ch9fBeyByZtkaF1wz7fbnxPxYABFX+ZTFz5ATqHnV1H14le8QeAPk5ySfRqvn9NqdSPLoRi6tFr5jkcNbSUpgHsu+FzLZyBFI5kP4ft GXijN/My7Nnt21ytw5Ya6lvPNxqZPumdyq27il9onrpPXLp4pbfCDB2U Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 07:51:25 -0000 This is a multi-part message in MIME format. --------------4951DFA39B4AB493E3459F55 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable grant_type would be horrible for RS developers to deal with, just to find out whether "sub" effectively =3D=3D "client_id". Why? * RS developers will need to learn more OAuth stuff - there are better ways to motivate people than that :) * The OAuth grant types are unbounded. If at some point a new grant gets devised / implemented, RS developers will need to update the code that maps grant_types to ("sub" effectively =3D=3D "client_id") * We have at least one grant - JWT assertion - where checking the grant type is not sufficient to determine if "sub" effectively =3D=3D= "client_id" I believe we should aim for a spec where RS developers shouldn't be required to know more than how to process JWTs. The AS has all the necessary information to indicate whether "sub" effectively =3D=3D "client_id". We don't need to push that logic to the R= S. Vladimir On 07/05/2019 12:16, Neil Madden wrote: > Ah, that makes sense. Well, we already add a grant_type claim to our JW= T-based access tokens, so I=E2=80=99m in favour of that solution :-) > > >> On 7 May 2019, at 09:48, Vittorio Bertocci wrote:= >> >> Thanks Neil, one more reason to avoid that. >> TL;DR,=20 >> The context is the discussion we had pre-IIW about whether sub should = be included always or only for tokens issued to ROs. Some exiting impleme= ntations rely on that heuristic. >> Turns out that 7519 has language suggesting sub should be there for bo= th tokens issued for the RO and for apps (via client creds, etc). >> We don't want to contradict 7519 but we also want to preserve the abil= ity for a RS to tell whether an AT was issued via RO auth or app auth, he= nce the discussion. Suggestions ranged from adding a grant_type claim (Vl= ad made a convincing argument against it), to relying to the client_id=3D= =3Dsub heuristic (which i pushed back on) to the introduction of a new cl= aim (name TBD given that sub_type is taken already) that can explicitly d= eclare whether the token has been issued authenticating th RO or via app = credentials. >> >> On Tue, May 7, 2019 at 1:37 AM Neil Madden > wrote: >> I wasn=E2=80=99t at IIW so I may be missing some context. >> >> There is a potential security issue if the client_id is used as the =E2= =80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the clie= nt can register itself with a self-chosen client_id then it may deliberat= ely chose a client_id that matches the user name of a privileged user. An= RS that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may then e= rroneously let the client perform privileged actions. >> >> Is this the context of the discussion? >> >> Given that there are a lot of RSes in existence, many of which are pro= bably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the res= ource owner, I think the onus is on the AS to ensure that no such ambigui= ty can arise in the first place by ensuring that the space of =E2=80=9Csu= b=E2=80=9D values for client credentials is disjoint with the space for g= enuine users or by disallowing the client_credentials grant altogether. >> >> This issue already arises in token introspection though, so maybe ough= t to be mentioned in the OAuth security topics draft rather than specific= to the JWT AT draft? >> >> =E2=80=94 Neil >> >>> On 6 May 2019, at 18:32, Vittorio Bertocci > wrote: >>> >>> Hi all, >>> thanks for your patience during this month long hiatus, and thanks fo= r the comments. >>> Last week at IIW I had the opportunity to discuss this with many of t= he people on the list. Here's a summary of where the discussion landaed o= n the subject of the sub (pun intended). >>> >>> - It seems that RFC 7519 has pretty clear language on the use of sub-= I didn't check it back when we started the discussion. I do agree with t= he people saying that we shouldn't violate existing specifications, hence= it looks like we do need to have sub also in the case in which we have a= pp-only tokens carrying claims about the app itself. I understand this wi= ll cause some implementation to break, but unfortunately that's intrinsic= in the process of coming up with a common approach and standards complia= nce is probably one of the strongest reasons to tolerate that. >>> - That said, I am strongly committed to preserve existing functionali= ty. One of the main reasons that was brought up for including sub only fo= r user based ATs was to use it as heuristic for telling those tokens apar= t from app-only ones. To that end, Karl MCGuinness suggested that we incl= ude grant_type as a return claim, which the RS could use to the same effe= ct. I find the proposal very clever, and the people at IIW thought so as = well. What you think? >>> Note, John Bradley observed that in some cases this might lead to amb= iguous results if an extension grant is used (say an assertion profile) b= ut that seems like a relatively fringe occurrence. >>> >>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt > wrote: >>> I also meant to say that (of course) the JWT standard doesn't say tha= t the JWT is supposed to be about the client or about the resource owner,= hence both are valid >>> >>> Hans. >>> >>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones > wrote: >>> I get that existing practice is likely to be all over the map, but if= we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reason= able to require that the claims usage comply with the JWT standards. >>> >>> =20 >>> >>> -- Mi= ke >>> >>> =20 >>> >>> From: Hans Zandbelt >=20 >>> Sent: Thursday, April 4, 2019 12:59 PM >>> To: Mike Jones > >>> Cc: George Fletcher >; Vittorio Bertocci >; IETF oauth WG > >>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>> >>> =20 >>> >>> the definition of RFC 7519 is actually "petitio principii" and a lot = of deployments put claims about the Resource Owner in the access token (a= s a Resource Server implementer I've suffered a lot from this) >>> >>> =20 >>> >>> Hans. >>> >>> =20 >>> >>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones > wrote: >>> >>> I agree with George that the subject of a token must be the principal= of that token. That what the JWT =E2=80=9Csub=E2=80=9D claim is for. I= ndeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at http= s://tools.ietf.org/html/rfc7519#section-4.1.2 is: >>> >>> The "sub" (subject) claim identifies the principal that is the subjec= t of the JWT. >>> >>> =20 >>> >>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply = with the definition from RFC 7519. >>> >>> =20 >>> >>> -- Mi= ke >>> >>> =20 >>> >>> From: OAuth > = On Behalf Of George Fletcher >>> Sent: Thursday, April 4, 2019 8:51 AM >>> To: Hans Zandbelt > >>> Cc: Vittorio Bertocci >; IETF oauth WG > >>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>> >>> =20 >>> >>> The more I think about this the more I land in the "No" camp. >>> >>> The subject of a token should be the principal of that token. It shou= ldn't matter whether that is a machine, a user, or a device. Trying to se= parate out "humans" as a special class will just make things more complic= ated. If we need a claim to identify the subject is a "human" then why no= t just add that. This doesn't break anything and makes it easy for people= to detect this case in those use cases where it's required. >>> >>> Thanks, >>> George >>> >>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>> >>> I will argue that in a way such deployments are already broken e.g. i= n the typical use case of onboarding client accounts in the same director= y/OU/namespace as user accounts and we don't need to cater for that. >>> >>> =20 >>> >>> Hans. >>> >>> =20 >>> >>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: >>> >>> I agree that this will break a lot of existing flows... especially th= ose using any form of the client_credentials flow. In that sense I'm not = completely on board yet :) >>> >>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>> >>> great summary! this will hurt quite a few existing m2m deployments bu= t I do like the rigidness of it all: it is very explicit, cannot misinter= preted and thus prevents failure (which is really what Dominick is after)= ; I'm on board >>> >>> =20 >>> >>> Hans. >>> >>> =20 >>> >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci > wrote: >>> >>> thank you Steinar and everyone else for the comments on this! >>> >>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov= , Bertrand recommend using sub only for users. Martin would like to have = the sub for app only flows as well. Hans is neutral. >>> >>> That does sound like the sub as user has more consensus, tho before c= hanging it I'd wait for the people currently at IETF104 to have more time= to comment as well. >>> >>> Clarification. If the goal is to be able to apply the logic "if there= 's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) th= e use of sub when that's not the case. Are all OK with it? >>> >>> =20 >>> >>> Dave, the suggestion of having explicit typing for app only vs user o= nly is interesting! For the purpose of putting together an interoperable = profile, tho, I would suggest we table it for v1 in the interest of getti= ng to something easy to adopt (hence with small delta vs existing impleme= ntations) faster. =20 >>> >>> =20 >>> >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: >>> >>> Hi Vittorio, we (the national federation-gateway for the health serv= ices in norway - "HelseID") think his is a really valuable initiative! >>> >>> We also agree with Dominick concerning definition of the "sub" claim.= >>> >>> =20 >>> >>> Steinar >>> >>> =20 >>> >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier >: >>> >>> From an access token consumer (aka API) developer point of view, I pr= efer this logic >>> >>> =20 >>> >>> "If sub is present - client acts on behalf of a user, if not - not." >>> >>> =20 >>> >>> Anything more complicated has a potential of going wrong. >>> >>> =20 >>> >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com ) wrote: >>> >>> Hi Vittorio, >>> >>> =20 >>> >>> Yeah, I=E2=80=99m concerning user & client ids collision. >>> >>> I haven=E2=80=99t seen such implementations, but user-select username= as sub, or incremental integer as sub & client_id will be easily collide= =2E >>> >>> =20 >>> >>> If you can enforce collision resistant IDs between user & client inst= ances, it=E2=80=99ll works fine. I feel its overkill though. >>> >>> =20 >>> >>> Sent from my iPhone >>> >>> >>> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: >>> >>> Hey Nov, Dominick, Hans- >>> >>> thanks for the comments. That was an area I was expecting to cause mo= re discussion, and I am glad we are having this opportunity to clarify. >>> >>> The current language in the draft traces the etymology of sub to Open= ID Connect core, hence Dominick observation is on point. However in the d= escription I express something in line with 7519, which was in fact my in= tent. >>> >>> =20 >>> >>> The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks regard= less of the nature of the caller (user in a delegated case, app in app-on= ly grants). The information to discriminate between user and app callers = is always available in the token (say, the caller is a user if sub!=3Dcli= ent_id, where client_id is always guaranteed to be present as well) hence= there's no loss in expressive power, should that difference be relevant = for the resource server. >>> >>> =20 >>> >>> Dominick, Hans- I probably missed the security issue you guys are thi= nking of in this case. Of course, if this would introduce a risk I comple= tely agree it should be changed- I'd just like to understand better the p= roblem. Could you expand it in a scenario/use case to clarify the risk? >>> >>> Nov- playing this back: is the concern that a user and a client might= have the same identifier within an IDP? When using collision resistant I= Ds, as it is usually the case, that seems to be a remote possibility- did= you stumble in such scenario in production? >>> >>> =20 >>> >>> Thanks >>> >>> V.=20 >>> >>> =20 >>> >>> =20 >>> >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt > wrote: >>> >>> I believe there are plenty of OAuth 2.0 only use cases out there... b= ut nevertheless I agree with the potential confusion and thus security pr= oblems arising from that (though one may argue the semantics are the same= ). >>> >>> =20 >>> >>> Hans. >>> >>> =20 >>> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier > wrote: >>> >>> Yes I know - and I think in hindsight it was a mistake to use the sam= e claim type for multiple semantics. >>> >>> =20 >>> >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making= things more complicated than they need to be - in my experience almost n= o-one (that I know) does OIDC only - nor OAuth only. They always combine = it. >>> >>> =20 >>> >>> In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >>> >>> =20 >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone= =2Eeu ) wrote: >>> >>> Without agreeing or disagreeing: OIDC does not apply here since it is= not OAuth and an access token is not an id_token. >>> >>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.= 2 : >>> >>> =20 >>> >>> "The "sub" (subject) claim identifies the principal that is the >>> >>> subject of the JWT. The claims in a JWT are normally statements >>> >>> about the subject. The subject value MUST either be scoped to be >>> >>> locally unique in the context of the issuer or be globally unique.= >>> >>> The processing of this claim is generally application specific" >>> >>> =20 >>> >>> which kind of spells "client" in case of the client credentials grant= but I also do worry about Resource Servers thinking/acting only in terms= of users >>> >>> =20 >>> >>> Hans. >>> >>> =20 >>> >>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote: >>> >>> IMHO the sub claim should always refer to the user - and nothing else= =2E >>> >>> =20 >>> >>> OIDC says: >>> >>> =20 >>> >>> "Subject - Identifier for the End-User at the Issuer." >>> >>> =20 >>> >>> client_id should be used to identify clients. >>> >>> =20 >>> >>> cheers >>> >>> Dominick >>> >>> =20 >>> >>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com ) wrote: >>> >>> Hi Vittorio, >>> >>> =20 >>> >>> Thanks for the good starting point of standardizing JWT-ized AT. >>> >>> =20 >>> >>> One feedback. >>> >>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, en= d-user and client, in this spec. >>> >>> It requires those 2 types of identifiers to be unique each other in t= he IdP context. >>> >>> =20 >>> >>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so= that no such constraint needed. >>> >>> =20 >>> >>> thanks >>> >>> =20 >>> >>> nov >>> >>> =20 >>> >>> On Mar 25, 2019, at 8:29, Vittorio Bertocci > wrote: >>> >>> =20 >>> >>> Dear all, >>> >>> I just submitted a draft describing a JWT profile for OAuth 2.0 acces= s tokens. You can find it in https://datatracker.ietf.org/doc/draft-berto= cci-oauth-access-token-jwt/ . >>> >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presentin= g remotely). I look forward for your comments! >>> >>> =20 >>> >>> Here's just a bit of backstory, in case you are interested in how thi= s doc came to be. The trajectory it followed is somewhat unusual. >>> >>> Despite OAuth2 not requiring any specific format for ATs, through the= years I have come across multiple proprietary solution using JWT for the= ir access token. The intent and scenarios addressed by those solutions ar= e mostly the same across vendors, but the syntax and interpretations in t= he implementations are different enough to prevent developers from reusin= g code and skills when moving from product to product. >>> I asked several individuals from key products and services to share w= ith me concrete examples of their JWT access tokens (THANK YOU Dominick B= aier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Mi= crosoft), Karl Guinness (Okta) for the tokens and explanations!). >>> I studied and compared all those instances, identifying commonalities= and differences.=20 >>> I put together a presentation summarizing my findings and suggesting = a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_medi= a/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!= >>> The presentation was followed up by 1.5 hours of unconference discuss= ion, which was incredibly valuable to get tight-loop feedback and incorpo= rate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten = Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contribut= ed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and didn= 't get credited in the draft, my apologies: please send me a note and I'l= l make things right at the next update. >>> On my flight back I did my best to incorporate all the ideas and feed= back in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Han= nes and above all Brian were all super helpful in negotiating the mysteri= ous syntax of the RFC format and submission process. >>> I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the process= =2E This is an amazing community.=20 >>> >>> V. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> =20 >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >>> =20 >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> =20 >>> >>> -- >>> >>> Vennlig hilsen >>> >>> =20 >>> >>> Steinar Noem >>> >>> Partner Udelt AS >>> >>> Systemutvikler >>> >>> =20 >>> >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no |=20 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> =20 >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> =20 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> >>> >>> >>> =20 >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> =20 >>> >>> >>> >>> =20 >>> >>> -- >>> >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >>> --=20 >>> 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 --------------4951DFA39B4AB493E3459F55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

grant_type would be horrible for RS developers to deal with, just to find out whether "sub" effectively == "client_id".

Why?
  • RS developers will need to learn more OAuth stuff - there are better ways to motivate people than that :)
  • The OAuth grant types are unbounded. If at some point a new grant gets devised / implemented, RS developers will need to update the code that maps grant_types to ("sub" effectively == "client_id")
  • We have at least one grant - JWT assertion - where checking the grant type is not sufficient to determine if "sub" effectively == "client_id"

I believe we should aim for a spec where RS developers shouldn't be required to know more than how to process JWTs.

The AS has all the necessary information to indicate whether "sub" effectively == "client_id". We don't need to push that logic to the RS.

Vladimir

On 07/05/2019 12:16, Neil Madden wrote:
Ah, that makes sense. Well, we already add a grant_type claim to our JWT-based access tokens, so I’m in favour of that solution :-)



On 7 May 2019, at 09:48, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Neil, one more reason to avoid that.
TL;DR, 
The context is the discussion we had pre-IIW about whether sub should be included always or only for tokens issued to ROs. Some exiting implementations rely on that heuristic.
Turns out that 7519 has language suggesting sub should be there for both tokens issued for the RO and for apps (via client creds, etc).
We don't want to contradict 7519 but we also want to preserve the ability for a RS to tell whether an AT was issued via RO auth or app auth, hence the discussion. Suggestions ranged from adding a grant_type claim (Vlad made a convincing argument against it), to relying to the client_id==sub heuristic (which i pushed back on) to the introduction of a new claim (name TBD given that sub_type is taken already) that can explicitly declare whether the token has been issued authenticating th RO or via app credentials.

On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
I wasn’t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the “sub” for an AT obtained via client_credentials. If the client can register itself with a self-chosen client_id then it may deliberately chose a client_id that matches the user name of a privileged user. An RS that just blindly looks at the “sub” claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are probably just looking at the “sub” claim to identify the resource owner, I think the onus is on the AS to ensure that no such ambiguity can arise in the first place by ensuring that the space of “sub” values for client credentials is disjoint with the space for genuine users or by disallowing the client_credentials grant altogether.

This issue already arises in token introspection though, so maybe ought to be mentioned in the OAuth security topics draft rather than specific to the JWT AT draft?

— Neil


On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:Vittorio=40auth0.com@dmarc.ietf.org>> wrote:

Hi all,
thanks for your patience during this month long hiatus, and thanks for the comments.
Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect. I find the proposal very clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
I get that existing practice is likely to be all over the map, but if we’re to create a JWT access token standard, it’s reasonable to require that the claims usage comply with the JWT standards.

 

                                                                -- Mike

 

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> 
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>
Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Owner in the access token (as a Resource Server implementer I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:

I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2> is:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.

 

If an access token uses “sub”, its usage must comply with the definition from RFC 7519.

 

                                                                -- Mike

 

From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:

I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>> wrote:

thank you Steinar and everyone else for the comments on this!

To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

 

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.     

 

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no <mailto:steinar@udelt.no>> wrote:

Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!

We also agree with Dominick concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>>:

>From an access token consumer (aka API) developer point of view, I prefer this logic

 

"If sub is present - client acts on behalf of a user, if not - not."

 

Anything more complicated has a potential of going wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Yeah, I’m concerning user & client ids collision.

I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

 

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com <mailto:Vittorio@auth0.com>> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.

The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

 

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

 

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?

Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:

I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

 

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

 

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2>:

 

"The "sub" (subject) claim identifies the principal that is the

   subject of the JWT.  The claims in a JWT are normally statements

   about the subject.  The subject value MUST either be scoped to be

   locally unique in the context of the issuer or be globally unique.

   The processing of this claim is generally application specific"

 

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

IMHO the sub claim should always refer to the user - and nothing else.

 

OIDC says:

 

"Subject - Identifier for the End-User at the Issuer."

 

client_id should be used to identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Thanks for the good starting point of standardizing JWT-ized AT.

 

One feedback.

The “sub” claim can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be unique each other in the IdP context.

 

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org <mailto:vittorio.bertocci=40auth0.com@dmarc.ietf.org>> wrote:

 

Dear all,

I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.

I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

 

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.

Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and differences. 
I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early feedback from Filip Skokan on it. Thx Filip!
The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 

V.

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

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

 

--

Vennlig hilsen

 

Steinar Noem

Partner Udelt AS

Systemutvikler

 

| steinar@udelt.no <mailto:steinar@udelt..no> | hei@udelt.no <mailto:hei@udelt.no>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> | 

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 

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



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

-- 
hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>


      

      



      

      

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

    

    

  


--------------4951DFA39B4AB493E3459F55--


From nobody Wed May  8 00:56: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 4B747120041 for ; Wed,  8 May 2019 00:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Jaubs_GBLbxy for ; Wed,  8 May 2019 00:56:00 -0700 (PDT)
Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (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 5EF9B12002F for ; Wed,  8 May 2019 00:56:00 -0700 (PDT)
Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id OHQkhvquf5frXOHQkhZLkT; Wed, 08 May 2019 00:55:59 -0700
To: oauth@ietf.org
References:       <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> 
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <19527766-710d-ad3b-ca5d-40c3857362ce@connect2id.com>
Date: Wed, 8 May 2019 10:55:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-CMAE-Envelope: MS4wfLRXLrnyvQiBb1MjN8dGZs3796eGuOfAE225VG0Yu8/hn196dVfi8duievPFQC5QUILiUb75TgkHpv+rWFZMNhvI3tQ3IoQCGnOKOoe6ZfhESSg1Y/W3 1UBLwrDjhH2EUhpwpwTCIMlk6wLwDGJYZ7h6pEn7dZXkcjcXuMxDO4Tn
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 07:56:02 -0000

On 07/05/2019 11:48, Vittorio Bertocci wrote:
> name
> TBD given that sub_type is taken already

Meaning that it cannot be used in a AT as JWT?

What spec is that?

Thanks,

Vladimir

-- 
Vladimir Dzhuvinov


From nobody Wed May  8 01:06: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 7080712008B for ; Wed,  8 May 2019 01:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzBnOHcuJNtL for ; Wed,  8 May 2019 01:06:45 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 091B5120100 for ; Wed,  8 May 2019 01:06:45 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:1c11:55a1:19fa:b678] (unknown [IPv6:2601:282:202:b210:1c11:55a1:19fa:b678]) by alkaline-solutions.com (Postfix) with ESMTPSA id 76A8731764; Wed,  8 May 2019 08:06:44 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: David Waite 
In-Reply-To: 
Date: Wed, 8 May 2019 02:06:43 -0600
Cc: Hannes Tschofenig , IETF oauth WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CC45D37-982F-4116-AECF-3C1C0F245B05@alkaline-solutions.com>
References: <9483DDB2-B495-42F2-BE29-38D15E1EEAE2@oracle.com>  
To: John Bradley 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and Native apps Best practices
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, 08 May 2019 08:06:50 -0000

> On May 7, 2019, at 8:02 AM, John Bradley  wrote:
>=20

> I believe that for a native app to use mtls via a chrome custom tab or =
Safari view controller you need to provision a certificate and private =
key to the system keystore.  It is not something that can happen =
dynamically from the app.
>=20
> That in practice is generally done by proprietary EMM (Enterprise =
Mobility Management) systems like mobile Iron etc.=20

On iOS you can load a PKCS12 file or use SCEP. You can do so with static =
policies, but nobody does it that way - they use an EMM system. This =
really limits things to enterprise usage or value-added features for =
small businesses that use EMM management integrated into other products =
like GSuite.

> I think there are also some issues with the app using the same key, it =
may need to be separately provisioned to the app as well. =20

On iOS, such certificates will be used by the system browser, but will =
not be used by an embedded web view or otherwise made available to =
applications. So, code flow and resource access MTLS using a client =
certificate at the system level is right out, unless some app-specific =
mechanism to negotiate a client key pair is used. Mobile apps on iOS =
will need to use ephemeral keys.

The client certificate may be used by the system browser to identify the =
device, so that the user authentication process can also verify that =
they are accessing from a device that meets corporate policy. So =
there=E2=80=99s precedent for a MTLS negotiation with the front channel =
being used for a different, non-PoP purpose. Not to say that enterprises =
wouldn=E2=80=99t prefer access be tied to a certificate they know was =
installed on the device and was requested to be non-exportable - there =
is just no standard way to do that today. Well, I suppose Kerberos.

-DW=


From nobody Wed May  8 01:15: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 5D0D5120090 for ; Wed,  8 May 2019 01:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1H1PMSdK8NF for ; Wed,  8 May 2019 01:15:52 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::631]) (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 0910C12002F for ; Wed,  8 May 2019 01:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQM4HcChqINj+9g3p+Wdhe45vPDQ5hySIQFp1tP99eM=; b=FvR28l1+3gMZxss08+BKq7w+0h/lzz2KsUP8DkcNIzAPjh8ekNgTAr7V9YMjfcqFmj/6d61L734aJPyNMMcdzYxRxKGf3ZECHW6TzTKAPGptVYtNH7JHwJkS4Lm/BxXSRdElENGyYWf20NLjqwNuNYEj3O7V9GwTYvGGgz+VaUw=
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4267.eurprd08.prod.outlook.com (20.179.40.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Wed, 8 May 2019 08:15:49 +0000
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Wed, 8 May 2019 08:15:49 +0000
From: Hannes Tschofenig 
To: Benjamin Kaduk , Brian Campbell 
CC: Vittorio Bertocci , George Fletcher , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] MTLS vs. DPOP
Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQAMeI0AAAMz3AAAA0YxgAABc6OAAB054iA=
Date: Wed, 8 May 2019 08:15:49 +0000
Message-ID: 
References:  <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com>   <20190507175954.GM19509@kduck.mit.edu>
In-Reply-To: <20190507175954.GM19509@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.123.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ceb962b6-086d-48f3-6b4d-08d6d38d6112
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4267; 
x-ms-traffictypediagnostic: DBBPR08MB4267:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39860400002)(346002)(366004)(40434004)(189003)(199004)(72206003)(81156014)(3846002)(53936002)(478600001)(76116006)(6116002)(446003)(5024004)(2171002)(14454004)(14444005)(8676002)(6246003)(7696005)(68736007)(966005)(25786009)(256004)(99286004)(33656002)(66446008)(5660300002)(186003)(26005)(6506007)(66476007)(66556008)(316002)(66066001)(110136005)(54906003)(73956011)(66946007)(4326008)(102836004)(52536014)(6436002)(2906002)(11346002)(7736002)(229853002)(74316002)(86362001)(305945005)(8936002)(486006)(64756008)(71190400001)(71200400001)(76176011)(476003)(6306002)(9686003)(55016002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4267; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6tyEIzY2lFRTEaWr+0bXQeul1GRvOcCX7tewTtbDs1QsE1bYe2NnnEPdsZ1ql1y9/czSVk3ZJUn9BdYugfBcNjmoD4ttrhogQX0F08Z0XdDtP9FOHRPSHOZAT4ZrhVLVbDGAw+xpUgSGpWq2Pt2LzcfdxgW+2hy/UtiKgyEaFyGzmUfK8plAtoQzHY6g2f2pFF6HTTFaxnUBXuSfNpioEs+MlPFCOk+RfJwCLfExwY807d4G+vhjGAmiv/uQzz7nYygARJsIVClsk3hqcvXSJjlqtrvDPhucuxgMUWtHBZWIOp64RV/aJUd25CAKCtEGuMWFkUZIHBOlFks0cU8JfYls9Tipg9/xxHoCE/vNaO7ebrrt5pfCBcH+O+4iixegPwweMVKQ1dyQ2KAL3sTxSdobEn0fEuNOTlIXvGB0njA=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ceb962b6-086d-48f3-6b4d-08d6d38d6112
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 08:15:49.1289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4267
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS vs. DPOP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 08:15:56 -0000

Hi Ben,

> I've forgotten the details of those two documents, but in the general cas=
e, if there's a WG document that is no longer actively being worked on (or =
is now believed to be a bad idea), the chairs can pretty easily get a new r=
ev posted that has a "tombstone" notice, like "this document is no longer b=
eing worked on" or similar, which may help clarify the situation to externa=
l parties without much investment on time or tooling.

When we started the work on the PoP tokens we were ahead of the OAuth deplo=
yment because many developers didn't see the need to switch from the bearer=
 tokens to the proof-of-possession tokens. Hence, the work progressed very =
slowly.

Now, the situation has changed with OAuth being used in use cases where the=
re are higher security concerns, for example in the financial sector.

There are, however, also technical challenges with the PoP token approach a=
nd we ran into one of them with the HTTP signing and also deployment challe=
nges (see token binding). I believe many people want such a PoP solution bu=
t there are just cases where it does not work. For HTTP signing we have at =
least two solutions in the IETF right now, namely  https://tools.ietf.org/h=
tml/draft-ietf-oauth-signed-http-request-03 and https://tools.ietf.org/html=
/draft-cavage-http-signatures-11

DPoP does not address the issue of how the request from the Client to the R=
S is actually protected. It only hints to it. If you want to get this to wo=
rk you have to use one of the above documents or come up with yet another m=
ethod.

Additionally, DPoP overlaps an already existing working group item, which w=
e had planned to sent to the IESG soon: https://tools.ietf.org/html/draft-i=
etf-oauth-pop-key-distribution-07
One of the differences between DPoP and PoP key distribution is the questio=
n whether the client always needs to demonstrate possession of the private =
to the AS. As you remember I took the action item to work on a formal analy=
sis, which I posted to the list.

Why the extra DPoP functionality has not been incorporated into the already=
 chartered working group item is not entirely clear to me.

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


From nobody Wed May  8 01:22:30 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 A3BC4120088 for ; Wed,  8 May 2019 01:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JFr4fdqhsLmB for ; Wed,  8 May 2019 01:22:22 -0700 (PDT)
Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (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 5580612002F for ; Wed,  8 May 2019 01:22:22 -0700 (PDT)
Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id OHqEhcpkFDKU9OHqFhSo6X; Wed, 08 May 2019 01:22:20 -0700
To: oauth@ietf.org
References:         <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <73400ae2-aa92-a532-551d-613300229bf5@connect2id.com>
Date: Wed, 8 May 2019 11:22:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>
Content-Type: multipart/alternative; boundary="------------BF2870311CB521E4E006CF24"
Content-Language: en-US
X-CMAE-Envelope: MS4wfKtdATU1/HnPPmx/aOEc7QTZzCpKcMVg7W2KikGHm3U4dH5ANT+SPiSGYjgQPLcCvdMntr42eO7hQjWfYw5viOj3KMGbp6T2UUd9ai7hb+HvTGRxaIUu aNEsqibjrt9NAss2OPmaII/tV+jC976rlWWJ4Tj+/p+fCYq6gF1cMgif
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 08:22:28 -0000

This is a multi-part message in MIME format.
--------------BF2870311CB521E4E006CF24
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

This is an excellent security point.

I also imagine that in "federated" cases an RS could have its own
subject scheme / namespace, distinct from the one at the AS, including
for clients acting on their own behalf.

Vladimir

On 07/05/2019 11:37, Neil Madden wrote:
> I wasn=E2=80=99t at IIW so I may be missing some context.
>
> There is a potential security issue if the client_id is used as the =E2=
=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the clie=
nt can register itself with a self-chosen client_id then it may deliberat=
ely chose a client_id that matches the user name of a privileged user. An=
 RS that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may then e=
rroneously let the client perform privileged actions.
>
> Is this the context of the discussion?
>
> Given that there are a lot of RSes in existence, many of which are prob=
ably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the reso=
urce owner, I think the onus is on the AS to ensure that no such ambiguit=
y can arise in the first place by ensuring that the space of =E2=80=9Csub=
=E2=80=9D values for client credentials is disjoint with the space for ge=
nuine users or by disallowing the client_credentials grant altogether.
>
> This issue already arises in token introspection though, so maybe ought=
 to be mentioned in the OAuth security topics draft rather than specific =
to the JWT AT draft?
>
> =E2=80=94 Neil
>
>> On 6 May 2019, at 18:32, Vittorio Bertocci  wrote:
>>
>> Hi all,
>> thanks for your patience during this month long hiatus, and thanks for=
 the comments.
>> Last week at IIW I had the opportunity to discuss this with many of th=
e people on the list. Here's a summary of where the discussion landaed on=
 the subject of the sub (pun intended).
>>
>> - It seems that RFC 7519 has pretty clear language on the use of sub- =
I didn't check it back when we started the discussion. I do agree with th=
e people saying that we shouldn't violate existing specifications, hence =
it looks like we do need to have sub also in the case in which we have ap=
p-only tokens carrying claims about the app itself. I understand this wil=
l cause some implementation to break, but unfortunately that's intrinsic =
in the process of coming up with a common approach and standards complian=
ce is probably one of the strongest reasons to tolerate that.
>> - That said, I am strongly committed to preserve existing functionalit=
y. One of the main reasons that was brought up for including sub only for=
 user based ATs was to use it as heuristic for telling those tokens apart=
 from app-only ones. To that end, Karl MCGuinness suggested that we inclu=
de grant_type as a return claim, which the RS could use to the same effec=
t. I find the proposal very clever, and the people at IIW thought so as w=
ell. What you think?
>> Note, John Bradley observed that in some cases this might lead to ambi=
guous results if an extension grant is used (say an assertion profile) bu=
t that seems like a relatively fringe occurrence.
>>
>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt > wrote:
>> I also meant to say that (of course) the JWT standard doesn't say that=
 the JWT is supposed to be about the client or about the resource owner, =
hence both are valid
>>
>> Hans.
>>
>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones > wrote:
>> I get that existing practice is likely to be all over the map, but if =
we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reasona=
ble to require that the claims usage comply with the JWT standards.
>>
>> =20
>>
>>                                                                 -- Mik=
e
>>
>> =20
>>
>> From: Hans Zandbelt >=20
>> Sent: Thursday, April 4, 2019 12:59 PM
>> To: Mike Jones >
>> Cc: George Fletcher >; Vittorio Bertocci >; IETF oauth WG >
>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>
>> =20
>>
>> the definition of RFC 7519 is actually "petitio principii" and a lot o=
f deployments put claims about the Resource Owner in the access token (as=
 a Resource Server implementer I've suffered a lot from this)
>>
>> =20
>>
>> Hans.
>>
>> =20
>>
>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones > wrote:
>>
>> I agree with George that the subject of a token must be the principal =
of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for.  In=
deed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https=
://tools.ietf.org/html/rfc7519#section-4.1.2  is:
>>
>> The "sub" (subject) claim identifies the principal that is the subject=
 of the JWT.
>>
>> =20
>>
>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply w=
ith the definition from RFC 7519.
>>
>> =20
>>
>>                                                                 -- Mik=
e
>>
>> =20
>>
>> From: OAuth > O=
n Behalf Of George Fletcher
>> Sent: Thursday, April 4, 2019 8:51 AM
>> To: Hans Zandbelt >
>> Cc: Vittorio Bertocci >; IETF oauth WG >
>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>
>> =20
>>
>> The more I think about this the more I land in the "No" camp.
>>
>> The subject of a token should be the principal of that token. It shoul=
dn't matter whether that is a machine, a user, or a device. Trying to sep=
arate out "humans" as a special class will just make things more complica=
ted. If we need a claim to identify the subject is a "human" then why not=
 just add that. This doesn't break anything and makes it easy for people =
to detect this case in those use cases where it's required.
>>
>> Thanks,
>> George
>>
>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>
>> I will argue that in a way such deployments are already broken e.g. in=
 the typical use case of onboarding client accounts in the same directory=
/OU/namespace as user accounts and we don't need to cater for that.
>>
>> =20
>>
>> Hans.
>>
>> =20
>>
>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote:
>>
>> I agree that this will break a lot of existing flows... especially tho=
se using any form of the client_credentials flow. In that sense I'm not c=
ompletely on board yet :)
>>
>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>
>> great summary! this will hurt quite a few existing m2m deployments but=
 I do like the rigidness of it all: it is very explicit, cannot misinterp=
reted and thus prevents failure (which is really what Dominick is after);=
 I'm on board
>>
>> =20
>>
>> Hans.
>>
>> =20
>>
>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci > wrote:
>>
>> thank you Steinar and everyone else for the comments on this!
>>
>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,=
 Bertrand recommend using sub only for users. Martin would like to have t=
he sub for app only flows as well. Hans is neutral.
>>
>> That does sound like the sub as user has more consensus, tho before ch=
anging it I'd wait for the people currently at IETF104 to have more time =
to comment as well.
>>
>> Clarification. If the goal is to be able to apply the logic "if there'=
s a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the=
 use of sub when that's not the case. Are all OK with it?
>>
>> =20
>>
>> Dave, the suggestion of having explicit typing for app only vs user on=
ly is interesting! For the purpose of putting together an interoperable p=
rofile, tho, I would suggest we table it for v1 in the interest of gettin=
g to something easy to adopt (hence with small delta vs existing implemen=
tations) faster.    =20
>>
>> =20
>>
>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote:
>>
>> Hi Vittorio, we  (the national federation-gateway for the health servi=
ces in norway - "HelseID")  think his is a really valuable initiative!
>>
>> We also agree with Dominick concerning definition of the "sub" claim.
>>
>> =20
>>
>> Steinar
>>
>> =20
>>
>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier >:
>>
>> From an access token consumer (aka API) developer point of view, I pre=
fer this logic
>>
>> =20
>>
>> "If sub is present - client acts on behalf of a user, if not - not."
>>
>> =20
>>
>> Anything more complicated has a potential of going wrong.
>>
>> =20
>>
>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com ) wrote:
>>
>> Hi Vittorio,
>>
>> =20
>>
>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>
>> I haven=E2=80=99t seen such implementations, but user-select username =
as sub, or incremental integer as sub & client_id will be easily collide.=

>>
>> =20
>>
>> If you can enforce collision resistant IDs between user & client insta=
nces, it=E2=80=99ll works fine. I feel its overkill though.
>>
>> =20
>>
>> Sent from my iPhone
>>
>>
>> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote:
>>
>> Hey Nov, Dominick, Hans-
>>
>> thanks for the comments. That was an area I was expecting to cause mor=
e discussion, and I am glad we are having this opportunity to clarify.
>>
>> The current language in the draft traces the etymology of sub to OpenI=
D Connect core, hence Dominick observation is on point. However in the de=
scription I express something in line with 7519, which was in fact my int=
ent.
>>
>> =20
>>
>> The idea was to provide an identifier of the calling subject that is g=
uaranteed to be present in all cases- this would allow an SDK developer t=
o use the same code for things like lookups and membership checks regardl=
ess of the nature of the caller (user in a delegated case, app in app-onl=
y grants). The information to discriminate between user and app callers i=
s always available in the token (say, the caller is a user if sub!=3Dclie=
nt_id, where client_id is always guaranteed to be present as well) hence =
there's no loss in expressive power, should that difference be relevant f=
or the resource server.
>>
>> =20
>>
>> Dominick, Hans- I probably missed the security issue you guys are thin=
king of in this case. Of course, if this would introduce a risk I complet=
ely agree it should be changed- I'd just like to understand better the pr=
oblem. Could you expand it in a scenario/use case to clarify the risk?
>>
>> Nov- playing this back: is the concern that a user and a client might =
have the same identifier within an IDP? When using collision resistant ID=
s, as it is usually the case, that seems to be a remote possibility- did =
you stumble in such scenario in production?
>>
>> =20
>>
>> Thanks
>>
>> V.=20
>>
>> =20
>>
>> =20
>>
>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt > wrote:
>>
>> I believe there are plenty of OAuth 2.0 only use cases out there... bu=
t nevertheless I agree with the potential confusion and thus security pro=
blems arising from that (though one may argue the semantics are the same)=
=2E
>>
>> =20
>>
>> Hans.
>>
>> =20
>>
>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier > wrote:
>>
>> Yes I know - and I think in hindsight it was a mistake to use the same=
 claim type for multiple semantics.
>>
>> =20
>>
>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making =
things more complicated than they need to be - in my experience almost no=
-one (that I know) does OIDC only - nor OAuth only. They always combine i=
t.
>>
>> =20
>>
>> In reality this leads to potential security problems - this spec has t=
he potential to rectify the situation.
>>
>> =20
>>
>> Dominick
>>
>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.=
eu ) wrote:
>>
>> Without agreeing or disagreeing: OIDC does not apply here since it is =
not OAuth and an access token is not an id_token.
>>
>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2=
 :
>>
>> =20
>>
>> "The "sub" (subject) claim identifies the principal that is the
>>
>>    subject of the JWT.  The claims in a JWT are normally statements
>>
>>    about the subject.  The subject value MUST either be scoped to be
>>
>>    locally unique in the context of the issuer or be globally unique.
>>
>>    The processing of this claim is generally application specific"
>>
>> =20
>>
>> which kind of spells "client" in case of the client credentials grant =
but I also do worry about Resource Servers thinking/acting only in terms =
of users
>>
>> =20
>>
>> Hans.
>>
>> =20
>>
>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote:
>>
>> IMHO the sub claim should always refer to the user - and nothing else.=

>>
>> =20
>>
>> OIDC says:
>>
>> =20
>>
>> "Subject - Identifier for the End-User at the Issuer."
>>
>> =20
>>
>> client_id should be used to identify clients.
>>
>> =20
>>
>> cheers
>>
>> Dominick
>>
>> =20
>>
>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com ) wrote:
>>
>> Hi Vittorio,
>>
>> =20
>>
>> Thanks for the good starting point of standardizing JWT-ized AT.
>>
>> =20
>>
>> One feedback.
>>
>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end=
-user and client, in this spec.
>>
>> It requires those 2 types of identifiers to be unique each other in th=
e IdP context.
>>
>> =20
>>
>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so =
that no such constraint needed.
>>
>> =20
>>
>> thanks
>>
>> =20
>>
>> nov
>>
>> =20
>>
>> On Mar 25, 2019, at 8:29, Vittorio Bertocci > wrote:
>>
>> =20
>>
>> Dear all,
>>
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access=
 tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertoc=
ci-oauth-access-token-jwt/ .
>>
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting=
 remotely). I look forward for your comments!
>>
>> =20
>>
>> Here's just a bit of backstory, in case you are interested in how this=
 doc came to be. The trajectory it followed is somewhat unusual.
>>
>> Despite OAuth2 not requiring any specific format for ATs, through the =
years I have come across multiple proprietary solution using JWT for thei=
r access token. The intent and scenarios addressed by those solutions are=
 mostly the same across vendors, but the syntax and interpretations in th=
e implementations are different enough to prevent developers from reusing=
 code and skills when moving from product to product.
>> I asked several individuals from key products and services to share wi=
th me concrete examples of their JWT access tokens (THANK YOU Dominick Ba=
ier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Mic=
rosoft), Karl Guinness (Okta) for the tokens and explanations!).
>> I studied and compared all those instances, identifying commonalities =
and differences.=20
>> I put together a presentation summarizing my findings and suggesting a=
 rough interoperable profile (slides:https://sec.uni-stuttgart.de/_media/=
events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx  ) - got early feedback from Filip Skokan on it. Thx Filip!=

>> The presentation was followed up by 1.5 hours of unconference discussi=
on, which was incredibly valuable to get tight-loop feedback and incorpor=
ate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten L=
odderstedt, Nat Sakimura, Hannes Tschofenig were all there and contribute=
d generously to the discussion. Thank you!!!
>> Note: if you were at OSW2019, participated in the discussion and didn'=
t get credited in the draft, my apologies: please send me a note and I'll=
 make things right at the next update.
>> On my flight back I did my best to incorporate all the ideas and feedb=
ack in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hann=
es and above all Brian were all super helpful in negotiating the mysterio=
us syntax of the RFC format and submission process.
>> I was blown away by the availability, involvement and willingness to i=
nvest time to get things right that everyone demonstrated in the process.=
 This is an amazing community.=20
>>
>> V.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> =20
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>> =20
>>
>> --
>>
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>>
>> =20
>>
>> --
>>
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>> =20
>>
>> --
>>
>> Vennlig hilsen
>>
>> =20
>>
>> Steinar Noem
>>
>> Partner Udelt AS
>>
>> Systemutvikler
>>
>> =20
>>
>> | steinar@udelt.no  | hei@udelt.no   | +47 955 21 620 | www.udelt.no  |=20
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>> =20
>>
>> --
>>
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>> =20
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> =20
>>
>>
>>
>> =20
>>
>> --
>>
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>> =20
>>
>>
>>
>> =20
>>
>> --
>>
>> hans.zandbelt@zmartzone.eu 
>> ZmartZone IAM - www.zmartzone.eu 
>>
>> --=20
>> 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


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


  
    
  
  
    
This is an excellent security point.

    
I also imagine that in "federated" cases an RS could have its own
      subject scheme / namespace, distinct from the one at the AS,
      including for clients acting on their own behalf.

    
Vladimir

    

    
On 07/05/2019 11:37, Neil Madden wrote:

    

    

      
I wasn’t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the “sub” for an AT obtained via client_credentials. If the client can register itself with a self-chosen client_id then it may deliberately chose a client_id that matches the user name of a privileged user. An RS that just blindly looks at the “sub” claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are probably just looking at the “sub” claim to identify the resource owner, I think the onus is on the AS to ensure that no such ambiguity can arise in the first place by ensuring that the space of “sub” values for client credentials is disjoint with the space for genuine users or by disallowing the client_credentials grant altogether.

This issue already arises in token introspection though, so maybe ought to be mentioned in the OAuth security topics draft rather than specific to the JWT AT draft?

— Neil



      

        
On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this month long hiatus, and thanks for the comments.
Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect. I find the proposal very clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
I get that existing practice is likely to be all over the map, but if we’re to create a JWT access token standard, it’s reasonable to require that the claims usage comply with the JWT standards.

 

                                                                -- Mike

 

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> 
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>
Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Owner in the access token (as a Resource Server implementer I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:

I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2> is:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.

 

If an access token uses “sub”, its usage must comply with the definition from RFC 7519.

 

                                                                -- Mike

 

From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:

I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>> wrote:

thank you Steinar and everyone else for the comments on this!

To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

 

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.     

 

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no <mailto:steinar@udelt.no>> wrote:

Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!

We also agree with Dominick concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>>:

>From an access token consumer (aka API) developer point of view, I prefer this logic

 

"If sub is present - client acts on behalf of a user, if not - not."

 

Anything more complicated has a potential of going wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Yeah, I’m concerning user & client ids collision.

I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

 

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com <mailto:Vittorio@auth0.com>> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.

The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

 

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

 

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?

Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:

I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

 

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

 

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2>:

 

"The "sub" (subject) claim identifies the principal that is the

   subject of the JWT.  The claims in a JWT are normally statements

   about the subject.  The subject value MUST either be scoped to be

   locally unique in the context of the issuer or be globally unique.

   The processing of this claim is generally application specific"

 

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

IMHO the sub claim should always refer to the user - and nothing else.

 

OIDC says:

 

"Subject - Identifier for the End-User at the Issuer."

 

client_id should be used to identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Thanks for the good starting point of standardizing JWT-ized AT.

 

One feedback.

The “sub” claim can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be unique each other in the IdP context.

 

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org <mailto:vittorio.bertocci=40auth0.com@dmarc.ietf.org>> wrote:

 

Dear all,

I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.

I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

 

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.

Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and differences. 
I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early feedback from Filip Skokan on it. Thx Filip!
The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 

V.

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

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

 

--

Vennlig hilsen

 

Steinar Noem

Partner Udelt AS

Systemutvikler

 

| steinar@udelt.no <mailto:steinar@udelt..no> | hei@udelt.no <mailto:hei@udelt.no>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> | 

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 

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



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

-- 
hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://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


    

    

  


--------------BF2870311CB521E4E006CF24--


From nobody Wed May  8 01:57: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 03F2B1201E3 for ; Wed,  8 May 2019 01:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 O0gvYuLKD9oz for ; Wed,  8 May 2019 01:57:24 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 A92DA1201D8 for ; Wed,  8 May 2019 01:57:23 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id o25so2201228wmf.2 for ; Wed, 08 May 2019 01:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yu+/h7Qs1Ru6pcewhAjoSZTy5udIVSb4i9h//PlZJJ0=; b=YWymLdeFVZEB0vrSNR/OJ1N5/0SgrgNxmY7fIRv16rR/p1qtejQGk8JzZBY9U2kDcG n9TNbJY4aNRsTUp6hEqFMSd2U9YZOX2jmwdiAa6VXOr0RBWgSGghnEELh5EPbSXxxqt+ tq2tM5GMWmP3La3YXgbw4jGhZwzAeSfUsVQQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yu+/h7Qs1Ru6pcewhAjoSZTy5udIVSb4i9h//PlZJJ0=; b=nNW44YY51FWndg+tuumqzLkV2Lp6WdOVVQ4gBbMroqEQ71XsuoS4WwnImga3hpP2fS UpzF0bp5y/qfSZllw0n2GMbKXW9uLUg5xhUj6HNDnAJiXvGxEqpUWS8ePZrylv1ipwtY 1oir2UkULSNsjDst7KqKrmvILEeR4Ws6NABJOyVOdrOM23tP054US2oq4A8cyAnAMFzs digTxEdyVVvAAnbSsobvbQgeCzOA8yi5LCREshwQkXORpRYR4l1iFH+vx5f5l0FoY9LS ekU+YmvZc5hu2BmOqFtW8zRcXELs0DDUl61GmvRei0diUScY0wczAXe/8Ov93yar4syx nbRQ==
X-Gm-Message-State: APjAAAVGth+XH81mOUx3e7cdqmh1mKapCaJlJBRN0AyQf0L5BcawNDSM m/A7DTe3/YJ65mItWcNlKmPfAEIGRs0=
X-Google-Smtp-Source: APXvYqyNYEmpop4u02z6a3xujcAz4cmbutppIc/owXuJC0pUt4Pi+bkreGEbrfI2PRmTVbxgU0mIHA==
X-Received: by 2002:a7b:ce83:: with SMTP id q3mr2075801wmj.32.1557305841449; Wed, 08 May 2019 01:57:21 -0700 (PDT)
Received: from [192.168.2.130] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id k2sm17759592wrg.22.2019.05.08.01.57.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2019 01:57:20 -0700 (PDT)
From: Neil Madden 
Message-Id: <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_433D967C-3536-4879-9456-4AE8708B0C9A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 8 May 2019 09:57:18 +0100
In-Reply-To: 
Cc: IETF oauth WG 
To: Vladimir Dzhuvinov 
References:       <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>   
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 08:57:31 -0000

--Apple-Mail=_433D967C-3536-4879-9456-4AE8708B0C9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Why does the RS need to know if the subject is a client vs a user? I =
suspect the answers to that question are about as problematic as the RS =
needing to know about the grant type.

I=E2=80=99m not a fan of the client_credentials grant, better off using =
a real service account in most cases. Hopefully no new grants will be =
added that repeat that mistake.

Not sure I understand the point about JWT assertion grant type. If you =
use a JWT assertion for client authentication then that=E2=80=99s just =
the client_credentials grant again with a different token auth method, =
right?

=E2=80=94 Neil

> On 8 May 2019, at 08:51, Vladimir Dzhuvinov  =
wrote:
>=20
> grant_type would be horrible for RS developers to deal with, just to =
find out whether "sub" effectively =3D=3D "client_id".
>=20
> Why?
> RS developers will need to learn more OAuth stuff - there are better =
ways to motivate people than that :)
> The OAuth grant types are unbounded. If at some point a new grant gets =
devised / implemented, RS developers will need to update the code that =
maps grant_types to ("sub" effectively =3D=3D "client_id")
> We have at least one grant - JWT assertion - where checking the grant =
type is not sufficient to determine if "sub" effectively =3D=3D =
"client_id"
> I believe we should aim for a spec where RS developers shouldn't be =
required to know more than how to process JWTs.
>=20
> The AS has all the necessary information to indicate whether "sub" =
effectively =3D=3D "client_id". We don't need to push that logic to the =
RS.
> Vladimir
>=20
> On 07/05/2019 12:16, Neil Madden wrote:
>> Ah, that makes sense. Well, we already add a grant_type claim to our =
JWT-based access tokens, so I=E2=80=99m in favour of that solution :-)
>>=20
>>=20
>>> On 7 May 2019, at 09:48, Vittorio Bertocci  =
 wrote:
>>>=20
>>> Thanks Neil, one more reason to avoid that.
>>> TL;DR,=20
>>> The context is the discussion we had pre-IIW about whether sub =
should be included always or only for tokens issued to ROs. Some exiting =
implementations rely on that heuristic.
>>> Turns out that 7519 has language suggesting sub should be there for =
both tokens issued for the RO and for apps (via client creds, etc).
>>> We don't want to contradict 7519 but we also want to preserve the =
ability for a RS to tell whether an AT was issued via RO auth or app =
auth, hence the discussion. Suggestions ranged from adding a grant_type =
claim (Vlad made a convincing argument against it), to relying to the =
client_id=3D=3Dsub heuristic (which i pushed back on) to the =
introduction of a new claim (name TBD given that sub_type is taken =
already) that can explicitly declare whether the token has been issued =
authenticating th RO or via app credentials.
>>>=20
>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden =
 =
 > =
wrote:
>>> I wasn=E2=80=99t at IIW so I may be missing some context.
>>>=20
>>> There is a potential security issue if the client_id is used as the =
=E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the =
client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a =
privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D=
 claim may then erroneously let the client perform privileged actions.
>>>=20
>>> Is this the context of the discussion?
>>>=20
>>> Given that there are a lot of RSes in existence, many of which are =
probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I think the onus is on the AS to ensure that no such =
ambiguity can arise in the first place by ensuring that the space of =
=E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the =
space for genuine users or by disallowing the client_credentials grant =
altogether.
>>>=20
>>> This issue already arises in token introspection though, so maybe =
ought to be mentioned in the OAuth security topics draft rather than =
specific to the JWT AT draft?
>>>=20
>>> =E2=80=94 Neil
>>>=20
>>>> On 6 May 2019, at 18:32, Vittorio Bertocci =
 =
 =
> wrote:
>>>>=20
>>>> Hi all,
>>>> thanks for your patience during this month long hiatus, and thanks =
for the comments.
>>>> Last week at IIW I had the opportunity to discuss this with many of =
the people on the list. Here's a summary of where the discussion landaed =
on the subject of the sub (pun intended).
>>>>=20
>>>> - It seems that RFC 7519 has pretty clear language on the use of =
sub- I didn't check it back when we started the discussion. I do agree =
with the people saying that we shouldn't violate existing =
specifications, hence it looks like we do need to have sub also in the =
case in which we have app-only tokens carrying claims about the app =
itself. I understand this will cause some implementation to break, but =
unfortunately that's intrinsic in the process of coming up with a common =
approach and standards compliance is probably one of the strongest =
reasons to tolerate that.
>>>> - That said, I am strongly committed to preserve existing =
functionality. One of the main reasons that was brought up for including =
sub only for user based ATs was to use it as heuristic for telling those =
tokens apart from app-only ones. To that end, Karl MCGuinness suggested =
that we include grant_type as a return claim, which the RS could use to =
the same effect. I find the proposal very clever, and the people at IIW =
thought so as well. What you think?
>>>> Note, John Bradley observed that in some cases this might lead to =
ambiguous results if an extension grant is used (say an assertion =
profile) but that seems like a relatively fringe occurrence.
>>>>=20
>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt =
 =
 > =
wrote:
>>>> I also meant to say that (of course) the JWT standard doesn't say =
that the JWT is supposed to be about the client or about the resource =
owner, hence both are valid
>>>>=20
>>>> Hans.
>>>>=20
>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones =
 =
 =
> wrote:
>>>> I get that existing practice is likely to be all over the map, but =
if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s =
reasonable to require that the claims usage comply with the JWT =
standards.
>>>>=20
>>>> =20
>>>>=20
>>>>                                                                 -- =
Mike
>>>>=20
>>>> =20
>>>>=20
>>>> From: Hans Zandbelt   =
>=20
>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>> To: Mike Jones  =
 =
>
>>>> Cc: George Fletcher  =
 =
>; Vittorio Bertocci =
 =
 =
>; IETF oauth WG   >
>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>=20
>>>> =20
>>>>=20
>>>> the definition of RFC 7519 is actually "petitio principii" and a =
lot of deployments put claims about the Resource Owner in the access =
token (as a Resource Server implementer I've suffered a lot from this)
>>>>=20
>>>> =20
>>>>=20
>>>> Hans.
>>>>=20
>>>> =20
>>>>=20
>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones =
 =
 =
> wrote:
>>>>=20
>>>> I agree with George that the subject of a token must be the =
principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim =
is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D =
definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 =
 =
 =
 is:
>>>>=20
>>>> The "sub" (subject) claim identifies the principal that is the =
subject of the JWT.
>>>>=20
>>>> =20
>>>>=20
>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must =
comply with the definition from RFC 7519.
>>>>=20
>>>> =20
>>>>=20
>>>>                                                                 -- =
Mike
>>>>=20
>>>> =20
>>>>=20
>>>> From: OAuth  =
 > On =
Behalf Of George Fletcher
>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>> To: Hans Zandbelt   =
>
>>>> Cc: Vittorio Bertocci  =
 =
>; IETF oauth WG   >
>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>=20
>>>> =20
>>>>=20
>>>> The more I think about this the more I land in the "No" camp.
>>>>=20
>>>> The subject of a token should be the principal of that token. It =
shouldn't matter whether that is a machine, a user, or a device. Trying =
to separate out "humans" as a special class will just make things more =
complicated. If we need a claim to identify the subject is a "human" =
then why not just add that. This doesn't break anything and makes it =
easy for people to detect this case in those use cases where it's =
required.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>>=20
>>>> I will argue that in a way such deployments are already broken e.g. =
in the typical use case of onboarding client accounts in the same =
directory/OU/namespace as user accounts and we don't need to cater for =
that.
>>>>=20
>>>> =20
>>>>=20
>>>> Hans.
>>>>=20
>>>> =20
>>>>=20
>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher   =
> wrote:
>>>>=20
>>>> I agree that this will break a lot of existing flows... especially =
those using any form of the client_credentials flow. In that sense I'm =
not completely on board yet :)
>>>>=20
>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>>=20
>>>> great summary! this will hurt quite a few existing m2m deployments =
but I do like the rigidness of it all: it is very explicit, cannot =
misinterpreted and thus prevents failure (which is really what Dominick =
is after); I'm on board
>>>>=20
>>>> =20
>>>>=20
>>>> Hans.
>>>>=20
>>>> =20
>>>>=20
>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci =
 =
 > =
wrote:
>>>>=20
>>>> thank you Steinar and everyone else for the comments on this!
>>>>=20
>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, =
Nov, Bertrand recommend using sub only for users. Martin would like to =
have the sub for app only flows as well. Hans is neutral.
>>>>=20
>>>> That does sound like the sub as user has more consensus, tho before =
changing it I'd wait for the people currently at IETF104 to have more =
time to comment as well.
>>>>=20
>>>> Clarification. If the goal is to be able to apply the logic "if =
there's a sub, it's a user flow", we have to explicitly disallow (MUST =
NOT) the use of sub when that's not the case. Are all OK with it?
>>>>=20
>>>> =20
>>>>=20
>>>> Dave, the suggestion of having explicit typing for app only vs user =
only is interesting! For the purpose of putting together an =
interoperable profile, tho, I would suggest we table it for v1 in the =
interest of getting to something easy to adopt (hence with small delta =
vs existing implementations) faster.    =20
>>>>=20
>>>> =20
>>>>=20
>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem   =
> wrote:
>>>>=20
>>>> Hi Vittorio, we  (the national federation-gateway for the health =
services in norway - "HelseID")  think his is a really valuable =
initiative!
>>>>=20
>>>> We also agree with Dominick concerning definition of the "sub" =
claim.
>>>>=20
>>>> =20
>>>>=20
>>>> Steinar
>>>>=20
>>>> =20
>>>>=20
>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier =
 =
 >:
>>>>=20
>>>> >=46rom an access token consumer (aka API) developer point of view, =
I prefer this logic
>>>>=20
>>>> =20
>>>>=20
>>>> "If sub is present - client acts on behalf of a user, if not - =
not."
>>>>=20
>>>> =20
>>>>=20
>>>> Anything more complicated has a potential of going wrong.
>>>>=20
>>>> =20
>>>>=20
>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com =
  =
) wrote:
>>>>=20
>>>> Hi Vittorio,
>>>>=20
>>>> =20
>>>>=20
>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>>>=20
>>>> I haven=E2=80=99t seen such implementations, but user-select =
username as sub, or incremental integer as sub & client_id will be =
easily collide.
>>>>=20
>>>> =20
>>>>=20
>>>> If you can enforce collision resistant IDs between user & client =
instances, it=E2=80=99ll works fine. I feel its overkill though.
>>>>=20
>>>> =20
>>>>=20
>>>> Sent from my iPhone
>>>>=20
>>>>=20
>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci   =
> wrote:
>>>>=20
>>>> Hey Nov, Dominick, Hans-
>>>>=20
>>>> thanks for the comments. That was an area I was expecting to cause =
more discussion, and I am glad we are having this opportunity to =
clarify.
>>>>=20
>>>> The current language in the draft traces the etymology of sub to =
OpenID Connect core, hence Dominick observation is on point. However in =
the description I express something in line with 7519, which was in fact =
my intent.
>>>>=20
>>>> =20
>>>>=20
>>>> The idea was to provide an identifier of the calling subject that =
is guaranteed to be present in all cases- this would allow an SDK =
developer to use the same code for things like lookups and membership =
checks regardless of the nature of the caller (user in a delegated case, =
app in app-only grants). The information to discriminate between user =
and app callers is always available in the token (say, the caller is a =
user if sub!=3Dclient_id, where client_id is always guaranteed to be =
present as well) hence there's no loss in expressive power, should that =
difference be relevant for the resource server.
>>>>=20
>>>> =20
>>>>=20
>>>> Dominick, Hans- I probably missed the security issue you guys are =
thinking of in this case. Of course, if this would introduce a risk I =
completely agree it should be changed- I'd just like to understand =
better the problem. Could you expand it in a scenario/use case to =
clarify the risk?
>>>>=20
>>>> Nov- playing this back: is the concern that a user and a client =
might have the same identifier within an IDP? When using collision =
resistant IDs, as it is usually the case, that seems to be a remote =
possibility- did you stumble in such scenario in production?
>>>>=20
>>>> =20
>>>>=20
>>>> Thanks
>>>>=20
>>>> V.=20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt =
 =
 > =
wrote:
>>>>=20
>>>> I believe there are plenty of OAuth 2.0 only use cases out there... =
but nevertheless I agree with the potential confusion and thus security =
problems arising from that (though one may argue the semantics are the =
same).
>>>>=20
>>>> =20
>>>>=20
>>>> Hans.
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier =
 =
 > =
wrote:
>>>>=20
>>>> Yes I know - and I think in hindsight it was a mistake to use the =
same claim type for multiple semantics.
>>>>=20
>>>> =20
>>>>=20
>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience =
almost no-one (that I know) does OIDC only - nor OAuth only. They always =
combine it.
>>>>=20
>>>> =20
>>>>=20
>>>> In reality this leads to potential security problems - this spec =
has the potential to rectify the situation.
>>>>=20
>>>> =20
>>>>=20
>>>> Dominick
>>>>=20
>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt =
(hans.zandbelt@zmartzone.eu  =
 ) =
wrote:
>>>>=20
>>>> Without agreeing or disagreeing: OIDC does not apply here since it =
is not OAuth and an access token is not an id_token.
>>>>=20
>>>> The JWT spec says in =
https://tools.ietf.org/html/rfc7519#section-4.1.2 =
 =
 =
:
>>>>=20
>>>> =20
>>>>=20
>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>=20
>>>>    subject of the JWT.  The claims in a JWT are normally statements
>>>>=20
>>>>    about the subject.  The subject value MUST either be scoped to =
be
>>>>=20
>>>>    locally unique in the context of the issuer or be globally =
unique.
>>>>=20
>>>>    The processing of this claim is generally application specific"
>>>>=20
>>>> =20
>>>>=20
>>>> which kind of spells "client" in case of the client credentials =
grant but I also do worry about Resource Servers thinking/acting only in =
terms of users
>>>>=20
>>>> =20
>>>>=20
>>>> Hans.
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier =
 =
 > =
wrote:
>>>>=20
>>>> IMHO the sub claim should always refer to the user - and nothing =
else.
>>>>=20
>>>> =20
>>>>=20
>>>> OIDC says:
>>>>=20
>>>> =20
>>>>=20
>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>=20
>>>> =20
>>>>=20
>>>> client_id should be used to identify clients.
>>>>=20
>>>> =20
>>>>=20
>>>> cheers
>>>>=20
>>>> Dominick
>>>>=20
>>>> =20
>>>>=20
>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com =
  =
) wrote:
>>>>=20
>>>> Hi Vittorio,
>>>>=20
>>>> =20
>>>>=20
>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>=20
>>>> =20
>>>>=20
>>>> One feedback.
>>>>=20
>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and client, in this spec.
>>>>=20
>>>> It requires those 2 types of identifiers to be unique each other in =
the IdP context.
>>>>=20
>>>> =20
>>>>=20
>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, =
so that no such constraint needed.
>>>>=20
>>>> =20
>>>>=20
>>>> thanks
>>>>=20
>>>> =20
>>>>=20
>>>> nov
>>>>=20
>>>> =20
>>>>=20
>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci =
 =
 =
> wrote:
>>>>=20
>>>> =20
>>>>=20
>>>> Dear all,
>>>>=20
>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 =
access tokens. You can find it in =
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ =
 =
 =
.=

>>>>=20
>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be =
presenting remotely). I look forward for your comments!
>>>>=20
>>>> =20
>>>>=20
>>>> Here's just a bit of backstory, in case you are interested in how =
this doc came to be. The trajectory it followed is somewhat unusual.
>>>>=20
>>>> Despite OAuth2 not requiring any specific format for ATs, through =
the years I have come across multiple proprietary solution using JWT for =
their access token. The intent and scenarios addressed by those =
solutions are mostly the same across vendors, but the syntax and =
interpretations in the implementations are different enough to prevent =
developers from reusing code and skills when moving from product to =
product.
>>>> I asked several individuals from key products and services to share =
with me concrete examples of their JWT access tokens (THANK YOU Dominick =
Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian =
(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>>>> I studied and compared all those instances, identifying =
commonalities and differences.=20
>>>> I put together a presentation summarizing my findings and =
suggesting a rough interoperable profile (slides: =
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt=
_profile_for_ats.pptx =
 =
 =
 ) - got early feedback from Filip Skokan on it. =
Thx Filip!
>>>> The presentation was followed up by 1.5 hours of unconference =
discussion, which was incredibly valuable to get tight-loop feedback and =
incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, =
Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and =
contributed generously to the discussion. Thank you!!!
>>>> Note: if you were at OSW2019, participated in the discussion and =
didn't get credited in the draft, my apologies: please send me a note =
and I'll make things right at the next update.
>>>> On my flight back I did my best to incorporate all the ideas and =
feedback in a draft, which will be discussed at IETF104 tomorrow. =
Rifaat, Hannes and above all Brian were all super helpful in negotiating =
the mysterious syntax of the RFC format and submission process.
>>>> I was blown away by the availability, involvement and willingness =
to invest time to get things right that everyone demonstrated in the =
process. This is an amazing community.=20
>>>>=20
>>>> V.
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>> =20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> Vennlig hilsen
>>>>=20
>>>> =20
>>>>=20
>>>> Steinar Noem
>>>>=20
>>>> Partner Udelt AS
>>>>=20
>>>> Systemutvikler
>>>>=20
>>>> =20
>>>>=20
>>>> | steinar@udelt.no  =
  | hei@udelt.no =
    | +47 =
955 21 620 | www.udelt.no   =
 |=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>> =20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

>>>> =20
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>> =20
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>>=20
>>>> --
>>>>=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>>=20
>>>> --=20
>>>> hans.zandbelt@zmartzone.eu  =
 
>>>> ZmartZone IAM - www.zmartzone.eu  =
 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org   =

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

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


--Apple-Mail=_433D967C-3536-4879-9456-4AE8708B0C9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Why =
does the RS need to know if the subject is a client vs a user? I suspect =
the answers to that question are about as problematic as the RS needing =
to know about the grant type.

I=E2=80=99m not a fan of the client_credentials grant, better =
off using a real service account in most cases. Hopefully no new grants =
will be added that repeat that mistake.

Not sure I understand the point about =
JWT assertion grant type. If you use a JWT assertion for client =
authentication then that=E2=80=99s just the client_credentials grant =
again with a different token auth method, right?

=E2=80=94 Neil

On 8 May =
2019, at 08:51, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
grant_type would be horrible for RS developers to deal with, =
just
      to find out whether "sub" effectively =3D=3D "client_id".

    Why?

    
    
      
  • RS developers will need to learn more OAuth stuff - =
there are
        better ways to motivate people than that :)
    
      
    • 
      
  • The OAuth grant types are unbounded. If at some =
point a new
        grant gets devised / implemented, RS developers will need to
        update the code that maps grant_types to ("sub" effectively =3D=3D=

        "client_id")
    • 
      
  • We have at least one grant - JWT assertion - where =
checking
        the grant type is not sufficient to determine if "sub"
        effectively =3D=3D "client_id"
    • 
    
I believe we should aim for a spec where RS =
developers shouldn't
      be required to know more than how to process JWTs.

    

    The AS has all the necessary information to indicate whether "sub"
    effectively =3D=3D "client_id". We don't need to push that logic to =
the
    RS.
    
Vladimir

    

    
On 07/05/2019 12:16, Neil Madden =
wrote:

    

    

      
Ah, that makes sense. Well, =
we already add a grant_type claim to our JWT-based access tokens, so =
I=E2=80=99m in favour of that solution :-)




      

        
On 7 May 2019, at 09:48, =
Vittorio Bertocci <Vittorio@auth0.com> wrote:

Thanks Neil, one more reason to avoid that.
TL;DR,=20
The context is the discussion we had pre-IIW about whether sub should be =
included always or only for tokens issued to ROs. Some exiting =
implementations rely on that heuristic.
Turns out that 7519 has language suggesting sub should be there for both =
tokens issued for the RO and for apps (via client creds, etc).
We don't want to contradict 7519 but we also want to preserve the =
ability for a RS to tell whether an AT was issued via RO auth or app =
auth, hence the discussion. Suggestions ranged from adding a grant_type =
claim (Vlad made a convincing argument against it), to relying to the =
client_id=3D=3Dsub heuristic (which i pushed back on) to the =
introduction of a new claim (name TBD given that sub_type is taken =
already) that can explicitly declare whether the token has been issued =
authenticating th RO or via app credentials.

On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.madden@forgerock.com =
<mailto:neil.madden@forgerock=
.com>> wrote:
I wasn=E2=80=99t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the =
=E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the =
client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a =
privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D=
 claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are =
probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I think the onus is on the AS to ensure that no such =
ambiguity can arise in the first place by ensuring that the space of =
=E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the =
space for genuine users or by disallowing the client_credentials grant =
altogether.

This issue already arises in token introspection though, so maybe ought =
to be mentioned in the OAuth security topics draft rather than specific =
to the JWT AT draft?

=E2=80=94 Neil



        

          
On 6 May 2019, at =
18:32, Vittorio Bertocci <Vittorio=3D40auth0.c=
om@dmarc.ietf.org <mailto:Vittorio=3D=
40auth0.com@dmarc.ietf.org>> wrote:

Hi all,
thanks for your patience during this month long hiatus, and thanks for =
the comments.
Last week at IIW I had the opportunity to discuss this with many of the =
people on the list. Here's a summary of where the discussion landaed on =
the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I =
didn't check it back when we started the discussion. I do agree with the =
people saying that we shouldn't violate existing specifications, hence =
it looks like we do need to have sub also in the case in which we have =
app-only tokens carrying claims about the app itself. I understand this =
will cause some implementation to break, but unfortunately that's =
intrinsic in the process of coming up with a common approach and =
standards compliance is probably one of the strongest reasons to =
tolerate that.
- That said, I am strongly committed to preserve existing functionality. =
One of the main reasons that was brought up for including sub only for =
user based ATs was to use it as heuristic for telling those tokens apart =
from app-only ones. To that end, Karl MCGuinness suggested that we =
include grant_type as a return claim, which the RS could use to the same =
effect. I find the proposal very clever, and the people at IIW thought =
so as well. What you think?
Note, John Bradley observed that in some cases this might lead to =
ambiguous results if an extension grant is used (say an assertion =
profile) but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that =
the JWT is supposed to be about the client or about the resource owner, =
hence both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@micro=
soft.com>> wrote:
I get that existing practice is likely to be all over the map, but if =
we=E2=80=99re to create a JWT access token standard, it=E2=80=99s =
reasonable to require that the claims usage comply with the JWT =
standards.

=20

                                                                -- Mike

=20

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>>=20
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@micro=
soft.com>>
Cc: George Fletcher <gffletch=3D40aol.com@d=
marc.ietf.org <mailto:40aol.com@dmarc...ie=
tf.org>>; Vittorio Bertocci <Vittorio=3D40auth0.c=
om@dmarc.ietf.org <mailto:40auth0.com@dmarc.ie=
tf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

=20

the definition of RFC 7519 is actually "petitio principii" and a lot of =
deployments put claims about the Resource Owner in the access token (as =
a Resource Server implementer I've suffered a lot from this)

=20

Hans.

=20

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@micro=
soft.com>> wrote:

I agree with George that the subject of a token must be the principal of =
that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for.  =
Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at https://tools.i=
etf.org/html/rfc7519#section-4.1.2 <https://too=
ls.ietf.org/html/rfc7519#section-4.1.2> is:

The "sub" (subject) claim identifies the principal that is the subject =
of the JWT.

=20

If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply =
with the definition from RFC 7519.

=20

                                                                -- Mike

=20

From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org&g=
t;> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>>
Cc: Vittorio Bertocci <Vittorio=3D40auth0.c=
om@dmarc.ietf.org <mailto:40auth0.com@dmarc.ie=
tf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

=20

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It =
shouldn't matter whether that is a machine, a user, or a device. Trying =
to separate out "humans" as a special class will just make things more =
complicated. If we need a claim to identify the subject is a "human" =
then why not just add that. This doesn't break anything and makes it =
easy for people to detect this case in those use cases where it's =
required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:

I will argue that in a way such deployments are already broken e.g. in =
the typical use case of onboarding client accounts in the same =
directory/OU/namespace as user accounts and we don't need to cater for =
that.

=20

Hans.

=20

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> =
wrote:

I agree that this will break a lot of existing flows... especially those =
using any form of the client_credentials flow. In that sense I'm not =
completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m deployments but I =
do like the rigidness of it all: it is very explicit, cannot =
misinterpreted and thus prevents failure (which is really what Dominick =
is after); I'm on board

=20

Hans.

=20

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=3D40auth0.c=
om@dmarc.ietf.org <mailto:40auth0.com@dmarc.ie=
tf.org>> wrote:

thank you Steinar and everyone else for the comments on this!

To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, =
Bertrand recommend using sub only for users. Martin would like to have =
the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more consensus, tho before =
changing it I'd wait for the people currently at IETF104 to have more =
time to comment as well.

Clarification. If the goal is to be able to apply the logic "if there's =
a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the =
use of sub when that's not the case. Are all OK with it?

=20

Dave, the suggestion of having explicit typing for app only vs user only =
is interesting! For the purpose of putting together an interoperable =
profile, tho, I would suggest we table it for v1 in the interest of =
getting to something easy to adopt (hence with small delta vs existing =
implementations) faster.    =20

=20

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no <mailto:steinar@udelt.no>> =
wrote:

Hi Vittorio, we  (the national federation-gateway for the health =
services in norway - "HelseID")  think his is a really valuable =
initiative!

We also agree with Dominick concerning definition of the "sub" claim.

=20

<mvh>Steinar</mvh>

=20

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com =
<mailto:dbaier@leastprivilege=
.com>>:

>=46rom an access token consumer (aka API) developer point of view, I =
prefer this logic

=20

"If sub is present - client acts on behalf of a user, if not - not."

=20

Anything more complicated has a potential of going wrong.

=20

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) =
wrote:

Hi Vittorio,

=20

Yeah, I=E2=80=99m concerning user & client ids collision.

I haven=E2=80=99t seen such implementations, but user-select username as =
sub, or incremental integer as sub & client_id will be easily =
collide.

=20

If you can enforce collision resistant IDs between user & client =
instances, it=E2=80=99ll works fine. I feel its overkill though.

=20

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com <mailto:Vittorio@auth0.com>&g=
t; wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was expecting to cause more =
discussion, and I am glad we are having this opportunity to clarify.

The current language in the draft traces the etymology of sub to OpenID =
Connect core, hence Dominick observation is on point. However in the =
description I express something in line with 7519, which was in fact my =
intent.

=20

The idea was to provide an identifier of the calling subject that is =
guaranteed to be present in all cases- this would allow an SDK developer =
to use the same code for things like lookups and membership checks =
regardless of the nature of the caller (user in a delegated case, app in =
app-only grants). The information to discriminate between user and app =
callers is always available in the token (say, the caller is a user if =
sub!=3Dclient_id, where client_id is always guaranteed to be present as =
well) hence there's no loss in expressive power, should that difference =
be relevant for the resource server.

=20

Dominick, Hans- I probably missed the security issue you guys are =
thinking of in this case. Of course, if this would introduce a risk I =
completely agree it should be changed- I'd just like to understand =
better the problem. Could you expand it in a scenario/use case to =
clarify the risk?

Nov- playing this back: is the concern that a user and a client might =
have the same identifier within an IDP? When using collision resistant =
IDs, as it is usually the case, that seems to be a remote possibility- =
did you stumble in such scenario in production?

=20

Thanks

V.=20

=20

=20

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>> wrote:

I believe there are plenty of OAuth 2.0 only use cases out there... but =
nevertheless I agree with the potential confusion and thus security =
problems arising from that (though one may argue the semantics are the =
same).

=20

Hans.

=20

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com =
<mailto:dbaier@leastprivilege=
.com>> wrote:

Yes I know - and I think in hindsight it was a mistake to use the same =
claim type for multiple semantics.

=20

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making =
things more complicated than they need to be - in my experience almost =
no-one (that I know) does OIDC only - nor OAuth only. They always =
combine it.

=20

In reality this leads to potential security problems - this spec has the =
potential to rectify the situation.

=20

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is =
not OAuth and an access token is not an id_token.

The JWT spec says in https://tools.i=
etf.org/html/rfc7519#section-4.1.2 <https://too=
ls.ietf.org/html/rfc7519#section-4.1.2>:

=20

"The "sub" (subject) claim identifies the principal that is the

   subject of the JWT.  The claims in a JWT are normally statements

   about the subject.  The subject value MUST either be scoped to be

   locally unique in the context of the issuer or be globally unique.

   The processing of this claim is generally application specific"

=20

which kind of spells "client" in case of the client credentials grant =
but I also do worry about Resource Servers thinking/acting only in terms =
of users

=20

Hans.

=20

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com =
<mailto:dbaier@leastprivilege=
.com>> wrote:

IMHO the sub claim should always refer to the user - and nothing else.

=20

OIDC says:

=20

"Subject - Identifier for the End-User at the Issuer."

=20

client_id should be used to identify clients.

=20

cheers

Dominick

=20

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) =
wrote:

Hi Vittorio,

=20

Thanks for the good starting point of standardizing JWT-ized AT.

=20

One feedback.

The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and client, in this spec.

It requires those 2 types of identifiers to be unique each other in the =
IdP context.

=20

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so =
that no such constraint needed.

=20

thanks

=20

nov

=20

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.be=
rtocci=3D40auth0.com@dmarc.ietf.org <mailto:=
vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>> wrote:

=20

Dear all,

I just submitted a draft describing a JWT profile for OAuth 2.0 access =
tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-=
jwt/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to=
ken-jwt/>.

I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting =
remotely). I look forward for your comments!

=20

Here's just a bit of backstory, in case you are interested in how this =
doc came to be. The trajectory it followed is somewhat unusual.

Despite OAuth2 not requiring any specific format for ATs, through the =
years I have come across multiple proprietary solution using JWT for =
their access token. The intent and scenarios addressed by those =
solutions are mostly the same across vendors, but the syntax and =
interpretations in the implementations are different enough to prevent =
developers from reusing code and skills when moving from product to =
product.
I asked several individuals from key products and services to share with =
me concrete examples of their JWT access tokens (THANK YOU Dominick =
Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian =
(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities =
and differences.=20
I put together a presentation summarizing my findings and suggesting a =
rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/=
osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/e=
vents/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - =
got early feedback from Filip Skokan on it. Thx Filip!
The presentation was followed up by 1.5 hours of unconference =
discussion, which was incredibly valuable to get tight-loop feedback and =
incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, =
Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and =
contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't =
get credited in the draft, my apologies: please send me a note and I'll =
make things right at the next update.
On my flight back I did my best to incorporate all the ideas and =
feedback in a draft, which will be discussed at IETF104 tomorrow. =
Rifaat, Hannes and above all Brian were all super helpful in negotiating =
the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to =
invest time to get things right that everyone demonstrated in the =
process. This is an amazing community.=20

V.

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

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

=20

--

hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

=20

--

hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/=
mailman/listinfo/oauth <https://www.ietf.=
org/mailman/listinfo/oauth>

=20

--

Vennlig hilsen

=20

Steinar Noem

Partner Udelt AS

Systemutvikler

=20

| steinar@udelt.no <mailto:steinar@udelt..no> | =
hei@udelt.no <mailto:hei@udelt.no>  | +47 955 =
21 620 | www.udelt.no <http://www.udelt.no/> |=20

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

=20

--

hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
=20

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



=20

--

hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
=20



=20

--

hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

--=20
hans.zandbelt@zmartzone.eu =
<mailto:hans.zandbelt@zmartz=
one.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/=
mailman/listinfo/oauth <https://www.ietf.=
org/mailman/listinfo/oauth>


        

        

      

      

      

      

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

    

    

  


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

=

--Apple-Mail=_433D967C-3536-4879-9456-4AE8708B0C9A--


From nobody Wed May  8 02:35:30 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 493CF1200B4 for ; Wed,  8 May 2019 02:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv6PEQoFzt_g for ; Wed,  8 May 2019 02:35:27 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7075A120021 for ; Wed,  8 May 2019 02:35:27 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id g8so17722379otl.8 for ; Wed, 08 May 2019 02:35:27 -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=OquHtgQmL+rxmi9C8pB2GN/NwCHfP0Pi0/QqGdEsCdk=; b=Z3mJcpcIG+SYpd9pHl7oowTAbd8rntbd/AwINIJJukKzevjLsBtRxL2qmcsAJKy2Rv PP0aEK5HYbOXNSUNqthlySxa7zJOaUTSR/z/TBp1CIHpXJVFgFBUkTwq8lnsgie+0Jy0 MnRi70LynwO3Wzs9d44D315y43WfEYH8TiXu2M9IIGrg/zrGaR8HaJjPrHHvuCMZ5tDj D9h3pnzm1RfwVyB/4TESZ60QEQ74fJrnuYcRCxdM5nSv9j5U8LAzmdUSzYb+Mx6NBXW+ g2SaFkRyqh1aXK1eluIdgG8P8ko1HnbwLZmrqYgUXeZrtRzoA4ycvdYyYQRrA988uTA6 F1Bw==
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=OquHtgQmL+rxmi9C8pB2GN/NwCHfP0Pi0/QqGdEsCdk=; b=ecvY0vxcXqoKCef3E1nV4zuvwiGGf3co0WiwyPp/h+iQZ1CHDOBuPO+nX8oGQU/mMT eGSOY4HTI9uqowvI65aRnhSIrLri7DgczkOCvLlrjYoSRCZR8EcKvgQ+XgCHd7kU+Fm3 XqpzHBxn/tve48W5lmiqb6fhHGsvsCwMaZFJwSRsNURcGi6UyuuKfe58q5COY9F3PS4X u9eBkBlgyaP7V7pSM140Pgr2P9jYGOw0qH3OOFOAXo6UsGp2otZ8iJU9OqaB5gm3VPbL 4khw6UGvkTkqu/ZHNlFenWRZHo6Ve2dEx23Qltr8HjjuqmYhndAOh4L8ZfXmdlXuZbFU yKBg==
X-Gm-Message-State: APjAAAXts4YvkQpZ9s+dvZBIFFg1VQCzQLDDJk+Y+mRE+FjyEEc78Mnq 0iK096gACiOTlQjENrC0WFkwQ87oSob2AFDTT9U=
X-Google-Smtp-Source: APXvYqwJeXZ/xficrf4eOeWJymxgE0HT3YteBMY8kpwBMDOZnwhRl+7fyFm+XZ+R5jEOrtNo99y8+ghwwP7bsIWheDs=
X-Received: by 2002:a9d:7d95:: with SMTP id j21mr4542477otn.141.1557308126724;  Wed, 08 May 2019 02:35:26 -0700 (PDT)
MIME-Version: 1.0
References: <11125817.AKI43N3Yza@papegaaij>  <2125064.3GpWMRz4CO@papegaaij>
In-Reply-To: <2125064.3GpWMRz4CO@papegaaij>
From: Thomas Broyer 
Date: Wed, 8 May 2019 11:35:14 +0200
Message-ID: 
To: Emond Papegaaij 
Cc: "" 
Content-Type: multipart/alternative; boundary="000000000000b30e9605885d0dc8"
Archived-At: 
Subject: Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
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, 08 May 2019 09:35:29 -0000

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

On Wed, May 8, 2019 at 9:38 AM Emond Papegaaij 
wrote:

> In our case or AS might have to federate the authentication to some other
> AS,
> that would only work in an iframe. Therefore, I think we will go for the
> OIDC
> prompt=none in a hidden iframe. I'm not sure what to do if the AS reports
> that
> interaction is required, but at least the majority of the cases will be
> covered.
>

I've implemented OpenID Connect Session Management in two AS and one app
(not a SPA though); Session Management uses prompt=none in a hidden iframe.
When the AS redirects back with an error (login_required,
interaction_required, etc.) the hidden iframe can communicate the error to
the app (parent window), which then can display a message with a
button/link to reauthenticate in a popup.
prompt=none in a hidden iframe, plus interactions in a popup, look to me
like the way to go (my use-case has always been authentication though,
never authorizations alone, so maybe things would be different in your
case).

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




=

On Wed, May 8, 2019 at 9:38 AM Emond =
Papegaaij <emond.papegaaij@=
gmail.com> wrote:
In our case or AS might have to federate the authentication to s=
ome other AS, 

that would only work in an iframe. Therefore, I think we will go for the OI=
DC 

prompt=3Dnone in a hidden iframe. I'm not sure what to do if the AS rep=
orts that 

interaction is required, but at least the majority of the cases will be 
covered.

I've implemented OpenID Co=
nnect Session Management in two AS and one app (not a SPA though); Session =
Management uses prompt=3Dnone in a hidden iframe. When the AS redirects bac=
k with an error (login_required, interaction_required, etc.) the hidden ifr=
ame can communicate the error to the app (parent window), which then can di=
splay a message with a button/link to reauthenticate in a popup.
=
prompt=3Dnone in a hidden iframe, plus interactions in a popup, look to me =
like the way to go (my use-case has always been authentication though, neve=
r authorizations alone, so maybe things would be different in your case).


--000000000000b30e9605885d0dc8--


From nobody Wed May  8 05:14: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 F0D6412004C for ; Wed,  8 May 2019 05:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1fxdWm1PDZi for ; Wed,  8 May 2019 05:14:14 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E4C12003F for ; Wed,  8 May 2019 05:14:14 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hOLSb-0006tC-FX; Wed, 08 May 2019 14:14:09 +0200
From: Torsten Lodderstedt 
Message-Id: <51C6447A-6536-4E1E-ABC6-45FFB5ED2CE0@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_905200A1-757C-4946-9C2E-F20881A2F9B2"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 8 May 2019 14:14:08 +0200
In-Reply-To: <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com>
Cc: Vladimir Dzhuvinov , IETF oauth WG 
To: Neil Madden 
References:       <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>    <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 12:14:20 -0000

--Apple-Mail=_905200A1-757C-4946-9C2E-F20881A2F9B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

An AS (and also an OP) MUST ensure uniqueness of any id that may end up =
in a =E2=80=9Csub". OpenID Connect even states that explicitly. That way =
the recipient of the data (token, assertion, introspection response, =
=E2=80=A6) does not need to know anything about account types.=20

Having the same sub value for a user and a client (service account) =
violates that requirement.


> On 8. May 2019, at 10:57, Neil Madden  =
wrote:
>=20
> Why does the RS need to know if the subject is a client vs a user? I =
suspect the answers to that question are about as problematic as the RS =
needing to know about the grant type.
>=20
> I=E2=80=99m not a fan of the client_credentials grant, better off =
using a real service account in most cases. Hopefully no new grants will =
be added that repeat that mistake.
>=20
> Not sure I understand the point about JWT assertion grant type. If you =
use a JWT assertion for client authentication then that=E2=80=99s just =
the client_credentials grant again with a different token auth method, =
right?
>=20
> =E2=80=94 Neil
>=20
>> On 8 May 2019, at 08:51, Vladimir Dzhuvinov  =
wrote:
>>=20
>> grant_type would be horrible for RS developers to deal with, just to =
find out whether "sub" effectively =3D=3D "client_id".
>>=20
>> Why?
>> 	=E2=80=A2 RS developers will need to learn more OAuth stuff - =
there are better ways to motivate people than that :)
>> 	=E2=80=A2 The OAuth grant types are unbounded. If at some point =
a new grant gets devised / implemented, RS developers will need to =
update the code that maps grant_types to ("sub" effectively =3D=3D =
"client_id")
>> 	=E2=80=A2 We have at least one grant - JWT assertion - where =
checking the grant type is not sufficient to determine if "sub" =
effectively =3D=3D "client_id"
>> I believe we should aim for a spec where RS developers shouldn't be =
required to know more than how to process JWTs.
>>=20
>> The AS has all the necessary information to indicate whether "sub" =
effectively =3D=3D "client_id". We don't need to push that logic to the =
RS.
>> Vladimir
>>=20
>> On 07/05/2019 12:16, Neil Madden wrote:
>>> Ah, that makes sense. Well, we already add a grant_type claim to our =
JWT-based access tokens, so I=E2=80=99m in favour of that solution :-)
>>>=20
>>>=20
>>>=20
>>>> On 7 May 2019, at 09:48, Vittorio Bertocci 
>>>>  wrote:
>>>>=20
>>>> Thanks Neil, one more reason to avoid that.
>>>> TL;DR,=20
>>>> The context is the discussion we had pre-IIW about whether sub =
should be included always or only for tokens issued to ROs. Some exiting =
implementations rely on that heuristic.
>>>> Turns out that 7519 has language suggesting sub should be there for =
both tokens issued for the RO and for apps (via client creds, etc).
>>>> We don't want to contradict 7519 but we also want to preserve the =
ability for a RS to tell whether an AT was issued via RO auth or app =
auth, hence the discussion. Suggestions ranged from adding a grant_type =
claim (Vlad made a convincing argument against it), to relying to the =
client_id=3D=3Dsub heuristic (which i pushed back on) to the =
introduction of a new claim (name TBD given that sub_type is taken =
already) that can explicitly declare whether the token has been issued =
authenticating th RO or via app credentials.
>>>>=20
>>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <
>>>> neil.madden@forgerock.com 
>>>> > wrote:
>>>> I wasn=E2=80=99t at IIW so I may be missing some context.
>>>>=20
>>>> There is a potential security issue if the client_id is used as the =
=E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the =
client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a =
privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D=
 claim may then erroneously let the client perform privileged actions.
>>>>=20
>>>> Is this the context of the discussion?
>>>>=20
>>>> Given that there are a lot of RSes in existence, many of which are =
probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I think the onus is on the AS to ensure that no such =
ambiguity can arise in the first place by ensuring that the space of =
=E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the =
space for genuine users or by disallowing the client_credentials grant =
altogether.
>>>>=20
>>>> This issue already arises in token introspection though, so maybe =
ought to be mentioned in the OAuth security topics draft rather than =
specific to the JWT AT draft?
>>>>=20
>>>> =E2=80=94 Neil
>>>>=20
>>>>=20
>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci =

>>>>> > wrote:
>>>>>=20
>>>>> Hi all,
>>>>> thanks for your patience during this month long hiatus, and thanks =
for the comments.
>>>>> Last week at IIW I had the opportunity to discuss this with many =
of the people on the list. Here's a summary of where the discussion =
landaed on the subject of the sub (pun intended).
>>>>>=20
>>>>> - It seems that RFC 7519 has pretty clear language on the use of =
sub- I didn't check it back when we started the discussion. I do agree =
with the people saying that we shouldn't violate existing =
specifications, hence it looks like we do need to have sub also in the =
case in which we have app-only tokens carrying claims about the app =
itself. I understand this will cause some implementation to break, but =
unfortunately that's intrinsic in the process of coming up with a common =
approach and standards compliance is probably one of the strongest =
reasons to tolerate that.
>>>>> - That said, I am strongly committed to preserve existing =
functionality. One of the main reasons that was brought up for including =
sub only for user based ATs was to use it as heuristic for telling those =
tokens apart from app-only ones. To that end, Karl MCGuinness suggested =
that we include grant_type as a return claim, which the RS could use to =
the same effect. I find the proposal very clever, and the people at IIW =
thought so as well. What you think?
>>>>> Note, John Bradley observed that in some cases this might lead to =
ambiguous results if an extension grant is used (say an assertion =
profile) but that seems like a relatively fringe occurrence.
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <
>>>>> hans.zandbelt@zmartzone.eu 
>>>>> > wrote:
>>>>> I also meant to say that (of course) the JWT standard doesn't say =
that the JWT is supposed to be about the client or about the resource =
owner, hence both are valid
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <
>>>>> Michael.Jones@microsoft.com 
>>>>> > wrote:
>>>>> I get that existing practice is likely to be all over the map, but =
if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s =
reasonable to require that the claims usage comply with the JWT =
standards.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                                 -- =
Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: Hans Zandbelt <
>>>>> hans.zandbelt@zmartzone.eu 
>>>>> >=20
>>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>>> To: Mike Jones <
>>>>> Michael.Jones@microsoft.com 
>>>>> >
>>>>> Cc: George Fletcher <
>>>>> gffletch=3D40aol.com@dmarc.ietf.org =
>; Vittorio Bertocci =
>; IETF oauth WG 
>>>>> >
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> the definition of RFC 7519 is actually "petitio principii" and a =
lot of deployments put claims about the Resource Owner in the access =
token (as a Resource Server implementer I've suffered a lot from this)
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <
>>>>> Michael.Jones@microsoft.com 
>>>>> > wrote:
>>>>>=20
>>>>> I agree with George that the subject of a token must be the =
principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim =
is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D =
definition at=20
>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2 =

>>>>>  is:
>>>>>=20
>>>>> The "sub" (subject) claim identifies the principal that is the =
subject of the JWT.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must =
comply with the definition from RFC 7519.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                                 -- =
Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: OAuth <
>>>>> oauth-bounces@ietf.org 
>>>>> > On Behalf Of George Fletcher
>>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>>> To: Hans Zandbelt <
>>>>> hans.zandbelt@zmartzone.eu 
>>>>> >
>>>>> Cc: Vittorio Bertocci <
>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org =
>; IETF oauth WG 
>>>>> >
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The more I think about this the more I land in the "No" camp.
>>>>>=20
>>>>> The subject of a token should be the principal of that token. It =
shouldn't matter whether that is a machine, a user, or a device. Trying =
to separate out "humans" as a special class will just make things more =
complicated. If we need a claim to identify the subject is a "human" =
then why not just add that. This doesn't break anything and makes it =
easy for people to detect this case in those use cases where it's =
required.
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>>=20
>>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>>>=20
>>>>> I will argue that in a way such deployments are already broken =
e.g. in the typical use case of onboarding client accounts in the same =
directory/OU/namespace as user accounts and we don't need to cater for =
that.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <
>>>>> gffletch@aol.com 
>>>>> > wrote:
>>>>>=20
>>>>> I agree that this will break a lot of existing flows... especially =
those using any form of the client_credentials flow. In that sense I'm =
not completely on board yet :)
>>>>>=20
>>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>>>=20
>>>>> great summary! this will hurt quite a few existing m2m deployments =
but I do like the rigidness of it all: it is very explicit, cannot =
misinterpreted and thus prevents failure (which is really what Dominick =
is after); I'm on board
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <
>>>>> Vittorio=3D40auth0.com@dmarc.ietf.org =

>>>>> > wrote:
>>>>>=20
>>>>> thank you Steinar and everyone else for the comments on this!
>>>>>=20
>>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, =
Nov, Bertrand recommend using sub only for users. Martin would like to =
have the sub for app only flows as well. Hans is neutral.
>>>>>=20
>>>>> That does sound like the sub as user has more consensus, tho =
before changing it I'd wait for the people currently at IETF104 to have =
more time to comment as well.
>>>>>=20
>>>>> Clarification. If the goal is to be able to apply the logic "if =
there's a sub, it's a user flow", we have to explicitly disallow (MUST =
NOT) the use of sub when that's not the case. Are all OK with it?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dave, the suggestion of having explicit typing for app only vs =
user only is interesting! For the purpose of putting together an =
interoperable profile, tho, I would suggest we table it for v1 in the =
interest of getting to something easy to adopt (hence with small delta =
vs existing implementations) faster.    =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <
>>>>> steinar@udelt.no 
>>>>> > wrote:
>>>>>=20
>>>>> Hi Vittorio, we  (the national federation-gateway for the health =
services in norway - "HelseID")  think his is a really valuable =
initiative!
>>>>>=20
>>>>> We also agree with Dominick concerning definition of the "sub" =
claim.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Steinar
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
>>>>> dbaier@leastprivilege.com 
>>>>> >:
>>>>>=20
>>>>> >=46rom an access token consumer (aka API) developer point of =
view, I prefer this logic
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "If sub is present - client acts on behalf of a user, if not - =
not."
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Anything more complicated has a potential of going wrong.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On 26. March 2019 at 01:34:53, Nov Matake (
>>>>> matake@gmail.com 
>>>>> ) wrote:
>>>>>=20
>>>>> Hi Vittorio,
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>>>>=20
>>>>> I haven=E2=80=99t seen such implementations, but user-select =
username as sub, or incremental integer as sub & client_id will be =
easily collide.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> If you can enforce collision resistant IDs between user & client =
instances, it=E2=80=99ll works fine. I feel its overkill though.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>>=20
>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <
>>>>> Vittorio@auth0.com 
>>>>> > wrote:
>>>>>=20
>>>>> Hey Nov, Dominick, Hans-
>>>>>=20
>>>>> thanks for the comments. That was an area I was expecting to cause =
more discussion, and I am glad we are having this opportunity to =
clarify.
>>>>>=20
>>>>> The current language in the draft traces the etymology of sub to =
OpenID Connect core, hence Dominick observation is on point. However in =
the description I express something in line with 7519, which was in fact =
my intent.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The idea was to provide an identifier of the calling subject that =
is guaranteed to be present in all cases- this would allow an SDK =
developer to use the same code for things like lookups and membership =
checks regardless of the nature of the caller (user in a delegated case, =
app in app-only grants). The information to discriminate between user =
and app callers is always available in the token (say, the caller is a =
user if sub!=3Dclient_id, where client_id is always guaranteed to be =
present as well) hence there's no loss in expressive power, should that =
difference be relevant for the resource server.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dominick, Hans- I probably missed the security issue you guys are =
thinking of in this case. Of course, if this would introduce a risk I =
completely agree it should be changed- I'd just like to understand =
better the problem. Could you expand it in a scenario/use case to =
clarify the risk?
>>>>>=20
>>>>> Nov- playing this back: is the concern that a user and a client =
might have the same identifier within an IDP? When using collision =
resistant IDs, as it is usually the case, that seems to be a remote =
possibility- did you stumble in such scenario in production?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> V.=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
>>>>> hans.zandbelt@zmartzone.eu 
>>>>> > wrote:
>>>>>=20
>>>>> I believe there are plenty of OAuth 2.0 only use cases out =
there... but nevertheless I agree with the potential confusion and thus =
security problems arising from that (though one may argue the semantics =
are the same).
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <
>>>>> dbaier@leastprivilege.com 
>>>>> > wrote:
>>>>>=20
>>>>> Yes I know - and I think in hindsight it was a mistake to use the =
same claim type for multiple semantics.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience =
almost no-one (that I know) does OIDC only - nor OAuth only. They always =
combine it.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> In reality this leads to potential security problems - this spec =
has the potential to rectify the situation.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dominick
>>>>>=20
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (
>>>>> hans.zandbelt@zmartzone.eu 
>>>>> ) wrote:
>>>>>=20
>>>>> Without agreeing or disagreeing: OIDC does not apply here since it =
is not OAuth and an access token is not an id_token.
>>>>>=20
>>>>> The JWT spec says in=20
>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2 =

>>>>> :
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>>=20
>>>>>    subject of the JWT.  The claims in a JWT are normally =
statements
>>>>>=20
>>>>>    about the subject.  The subject value MUST either be scoped to =
be
>>>>>=20
>>>>>    locally unique in the context of the issuer or be globally =
unique.
>>>>>=20
>>>>>    The processing of this claim is generally application specific"
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> which kind of spells "client" in case of the client credentials =
grant but I also do worry about Resource Servers thinking/acting only in =
terms of users
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <
>>>>> dbaier@leastprivilege.com 
>>>>> > wrote:
>>>>>=20
>>>>> IMHO the sub claim should always refer to the user - and nothing =
else.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> OIDC says:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> client_id should be used to identify clients.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> cheers
>>>>>=20
>>>>> Dominick
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (
>>>>> matake@gmail.com 
>>>>> ) wrote:
>>>>>=20
>>>>> Hi Vittorio,
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> One feedback.
>>>>>=20
>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and client, in this spec.
>>>>>=20
>>>>> It requires those 2 types of identifiers to be unique each other =
in the IdP context.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, =
so that no such constraint needed.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> thanks
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> nov
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
>>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org =

>>>>> > wrote:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 =
access tokens. You can find it in=20
>>>>> =
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ =

>>>>> .
>>>>>=20
>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be =
presenting remotely). I look forward for your comments!
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Here's just a bit of backstory, in case you are interested in how =
this doc came to be. The trajectory it followed is somewhat unusual.
>>>>>=20
>>>>> Despite OAuth2 not requiring any specific format for ATs, through =
the years I have come across multiple proprietary solution using JWT for =
their access token. The intent and scenarios addressed by those =
solutions are mostly the same across vendors, but the syntax and =
interpretations in the implementations are different enough to prevent =
developers from reusing code and skills when moving from product to =
product.
>>>>> I asked several individuals from key products and services to =
share with me concrete examples of their JWT access tokens (THANK YOU =
Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel =
Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and =
explanations!).
>>>>> I studied and compared all those instances, identifying =
commonalities and differences.=20
>>>>> I put together a presentation summarizing my findings and =
suggesting a rough interoperable profile (slides:=20
>>>>> =
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt=
_profile_for_ats.pptx =

>>>>>  ) - got early feedback from Filip Skokan on it. Thx Filip!
>>>>> The presentation was followed up by 1.5 hours of unconference =
discussion, which was incredibly valuable to get tight-loop feedback and =
incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, =
Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and =
contributed generously to the discussion. Thank you!!!
>>>>> Note: if you were at OSW2019, participated in the discussion and =
didn't get credited in the draft, my apologies: please send me a note =
and I'll make things right at the next update.
>>>>> On my flight back I did my best to incorporate all the ideas and =
feedback in a draft, which will be discussed at IETF104 tomorrow. =
Rifaat, Hannes and above all Brian were all super helpful in negotiating =
the mysterious syntax of the RFC format and submission process.
>>>>> I was blown away by the availability, involvement and willingness =
to invest time to get things right that everyone demonstrated in the =
process. This is an amazing community.=20
>>>>>=20
>>>>> V.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> Vennlig hilsen
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Steinar Noem
>>>>>=20
>>>>> Partner Udelt AS
>>>>>=20
>>>>> Systemutvikler
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> |=20
>>>>> steinar@udelt.no  | hei@udelt.no =
  | +47 955 21 620 | www.udelt.no =

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

>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

>>>>>=20
>>>>> =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>>=20
>>>>> --=20
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu 
>>>>>=20
>>>>> ZmartZone IAM -=20
>>>>> www.zmartzone.eu 
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_905200A1-757C-4946-9C2E-F20881A2F9B2
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
Fw0xOTA1MDgxMjE0MDhaMC8GCSqGSIb3DQEJBDEiBCC99BPgZPTW/JNOR3AP+oZs7H3PT+yHC5JP
PDv//r0uWzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBABI8iqGIdrpeJXQ/Mkgs44KX8KgAN/53/gA69kziGWW/y/xSHhg+nhZzf0Ds
aeg7FifX34FkROYuUCd9eLqmIiiyXVUDHigsH2yimze9f0wNzoXerNEvfB+S7XjGJVVFoeNtXN0V
JIr/Rd2tUYVEzOmmMOBGs5bn6T/07/7DnIV0VH1SQPRbMiJu751LhgB6ImSIjCG5yv+wsPD8Bby0
fvFBAjT1vXemwvIsnAI9uvvem+2QaYTCkqqINRzI+D2p6IZltHbNEda0KqLifV8dIsZQGY7i405W
xClsfx0PKnan9OdNIEcMNIWccx+UJ8yaiETbu8jG1XDidfWfTFFJ1YoAAAAAAAA=
--Apple-Mail=_905200A1-757C-4946-9C2E-F20881A2F9B2--


From nobody Wed May  8 05:15:30 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 1822012006A for ; Wed,  8 May 2019 05:15: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 tO-BclxhGVVg for ; Wed,  8 May 2019 05:15:25 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 D56DA12004C for ; Wed,  8 May 2019 05:15:24 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hOLTl-0000wR-F1; Wed, 08 May 2019 14:15:21 +0200
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_D0DA92FB-A364-4ADC-9D7F-0ED8B87BD90A"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 8 May 2019 14:15:20 +0200
In-Reply-To: 
Cc: IETF oauth WG , Daniel Fett 
To: Neil Madden 
References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> <1BEB5CBA-6AD0-4EB0-88F5-A2FCEF53A48C@lodderstedt.net> 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth security topics
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, 08 May 2019 12:15:29 -0000

--Apple-Mail=_D0DA92FB-A364-4ADC-9D7F-0ED8B87BD90A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

You are right. May I ask you to propose text (threat description, =
advice, ...) to be included in the BCP?=20

> On 7. May 2019, at 13:23, Neil Madden  =
wrote:
>=20
> The same issue applies to token introspection responses though.
>=20
>> On 7 May 2019, at 12:21, Torsten Lodderstedt =
 wrote:
>>=20
>> Hi Neil,
>>=20
>> you raised a very important issue but the Security BCP does not talk =
about JWT content like the Access Token JWT BCP.
>>=20
>> I therefore think the security advise should go into the security =
considerations section of the Access Token JWT BCP.
>>=20
>> best regards,
>> Torsten.
>>=20
>> Am 07.05.2019 um 11:18 schrieb Neil Madden =
:
>>=20
>>> Is it too late to add the observation below to the OAuth security =
topics BCP draft?
>>>=20
>>>=20
>>>> Begin forwarded message:
>>>>=20
>>>> From: Neil Madden 
>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>> Date: 7 May 2019 at 09:37:29 BST
>>>> To: Vittorio Bertocci 
>>>> Cc: Hans Zandbelt , Karl McGuinness =
, John Bradley , IETF oauth WG =

>>>>=20
>>>> I wasn=E2=80=99t at IIW so I may be missing some context.
>>>>=20
>>>> There is a potential security issue if the client_id is used as the =
=E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the =
client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a =
privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D=
 claim may then erroneously let the client perform privileged actions.
>>>>=20
>>>> Is this the context of the discussion?
>>>>=20
>>>> Given that there are a lot of RSes in existence, many of which are =
probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I think the onus is on the AS to ensure that no such =
ambiguity can arise in the first place by ensuring that the space of =
=E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the =
space for genuine users or by disallowing the client_credentials grant =
altogether.
>>>>=20
>>>> This issue already arises in token introspection though, so maybe =
ought to be mentioned in the OAuth security topics draft rather than =
specific to the JWT AT draft?
>>>>=20
>>>> =E2=80=94 Neil
>>>>=20
>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci =
 wrote:
>>>>>=20
>>>>> Hi all,
>>>>> thanks for your patience during this month long hiatus, and thanks =
for the comments.
>>>>> Last week at IIW I had the opportunity to discuss this with many =
of the people on the list. Here's a summary of where the discussion =
landaed on the subject of the sub (pun intended).
>>>>>=20
>>>>> - It seems that RFC 7519 has pretty clear language on the use of =
sub- I didn't check it back when we started the discussion. I do agree =
with the people saying that we shouldn't violate existing =
specifications, hence it looks like we do need to have sub also in the =
case in which we have app-only tokens carrying claims about the app =
itself. I understand this will cause some implementation to break, but =
unfortunately that's intrinsic in the process of coming up with a common =
approach and standards compliance is probably one of the strongest =
reasons to tolerate that.
>>>>> - That said, I am strongly committed to preserve existing =
functionality. One of the main reasons that was brought up for including =
sub only for user based ATs was to use it as heuristic for telling those =
tokens apart from app-only ones. To that end, Karl MCGuinness suggested =
that we include grant_type as a return claim, which the RS could use to =
the same effect. I find the proposal very clever, and the people at IIW =
thought so as well. What you think?
>>>>> Note, John Bradley observed that in some cases this might lead to =
ambiguous results if an extension grant is used (say an assertion =
profile) but that seems like a relatively fringe occurrence.
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt =
 wrote:
>>>>> I also meant to say that (of course) the JWT standard doesn't say =
that the JWT is supposed to be about the client or about the resource =
owner, hence both are valid
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones =
 wrote:
>>>>> I get that existing practice is likely to be all over the map, but =
if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s =
reasonable to require that the claims usage comply with the JWT =
standards.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                                 -- =
Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: Hans Zandbelt =20
>>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>>> To: Mike Jones 
>>>>> Cc: George Fletcher ; =
Vittorio Bertocci ; IETF oauth WG =

>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> the definition of RFC 7519 is actually "petitio principii" and a =
lot of deployments put claims about the Resource Owner in the access =
token (as a Resource Server implementer I've suffered a lot from this)
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones =
 wrote:
>>>>>=20
>>>>> I agree with George that the subject of a token must be the =
principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim =
is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D =
definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>>>>>=20
>>>>> The "sub" (subject) claim identifies the principal that is the =
subject of the JWT.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must =
comply with the definition from RFC 7519.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>                                                                 -- =
Mike
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> From: OAuth  On Behalf Of George Fletcher
>>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>>> To: Hans Zandbelt 
>>>>> Cc: Vittorio Bertocci ; =
IETF oauth WG 
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The more I think about this the more I land in the "No" camp.
>>>>>=20
>>>>> The subject of a token should be the principal of that token. It =
shouldn't matter whether that is a machine, a user, or a device. Trying =
to separate out "humans" as a special class will just make things more =
complicated. If we need a claim to identify the subject is a "human" =
then why not just add that. This doesn't break anything and makes it =
easy for people to detect this case in those use cases where it's =
required.
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>>=20
>>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>>>=20
>>>>> I will argue that in a way such deployments are already broken =
e.g. in the typical use case of onboarding client accounts in the same =
directory/OU/namespace as user accounts and we don't need to cater for =
that.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  =
wrote:
>>>>>=20
>>>>> I agree that this will break a lot of existing flows... especially =
those using any form of the client_credentials flow. In that sense I'm =
not completely on board yet :)
>>>>>=20
>>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>>>=20
>>>>> great summary! this will hurt quite a few existing m2m deployments =
but I do like the rigidness of it all: it is very explicit, cannot =
misinterpreted and thus prevents failure (which is really what Dominick =
is after); I'm on board
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci =
 wrote:
>>>>>=20
>>>>> thank you Steinar and everyone else for the comments on this!
>>>>>=20
>>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, =
Nov, Bertrand recommend using sub only for users. Martin would like to =
have the sub for app only flows as well. Hans is neutral.
>>>>>=20
>>>>> That does sound like the sub as user has more consensus, tho =
before changing it I'd wait for the people currently at IETF104 to have =
more time to comment as well.
>>>>>=20
>>>>> Clarification. If the goal is to be able to apply the logic "if =
there's a sub, it's a user flow", we have to explicitly disallow (MUST =
NOT) the use of sub when that's not the case. Are all OK with it?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dave, the suggestion of having explicit typing for app only vs =
user only is interesting! For the purpose of putting together an =
interoperable profile, tho, I would suggest we table it for v1 in the =
interest of getting to something easy to adopt (hence with small delta =
vs existing implementations) faster.    =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  =
wrote:
>>>>>=20
>>>>> Hi Vittorio, we  (the national federation-gateway for the health =
services in norway - "HelseID")  think his is a really valuable =
initiative!
>>>>>=20
>>>>> We also agree with Dominick concerning definition of the "sub" =
claim.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Steinar
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier =
:
>>>>>=20
>>>>> =46rom an access token consumer (aka API) developer point of view, =
I prefer this logic
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "If sub is present - client acts on behalf of a user, if not - =
not."
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Anything more complicated has a potential of going wrong.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) =
wrote:
>>>>>=20
>>>>> Hi Vittorio,
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>>>>=20
>>>>> I haven=E2=80=99t seen such implementations, but user-select =
username as sub, or incremental integer as sub & client_id will be =
easily collide.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> If you can enforce collision resistant IDs between user & client =
instances, it=E2=80=99ll works fine. I feel its overkill though.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>>=20
>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci  =
wrote:
>>>>>=20
>>>>> Hey Nov, Dominick, Hans-
>>>>>=20
>>>>> thanks for the comments. That was an area I was expecting to cause =
more discussion, and I am glad we are having this opportunity to =
clarify.
>>>>>=20
>>>>> The current language in the draft traces the etymology of sub to =
OpenID Connect core, hence Dominick observation is on point. However in =
the description I express something in line with 7519, which was in fact =
my intent.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> The idea was to provide an identifier of the calling subject that =
is guaranteed to be present in all cases- this would allow an SDK =
developer to use the same code for things like lookups and membership =
checks regardless of the nature of the caller (user in a delegated case, =
app in app-only grants). The information to discriminate between user =
and app callers is always available in the token (say, the caller is a =
user if sub!=3Dclient_id, where client_id is always guaranteed to be =
present as well) hence there's no loss in expressive power, should that =
difference be relevant for the resource server.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dominick, Hans- I probably missed the security issue you guys are =
thinking of in this case. Of course, if this would introduce a risk I =
completely agree it should be changed- I'd just like to understand =
better the problem. Could you expand it in a scenario/use case to =
clarify the risk?
>>>>>=20
>>>>> Nov- playing this back: is the concern that a user and a client =
might have the same identifier within an IDP? When using collision =
resistant IDs, as it is usually the case, that seems to be a remote =
possibility- did you stumble in such scenario in production?
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> V.=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt =
 wrote:
>>>>>=20
>>>>> I believe there are plenty of OAuth 2.0 only use cases out =
there... but nevertheless I agree with the potential confusion and thus =
security problems arising from that (though one may argue the semantics =
are the same).
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier =
 wrote:
>>>>>=20
>>>>> Yes I know - and I think in hindsight it was a mistake to use the =
same claim type for multiple semantics.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience =
almost no-one (that I know) does OIDC only - nor OAuth only. They always =
combine it.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> In reality this leads to potential security problems - this spec =
has the potential to rectify the situation.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dominick
>>>>>=20
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt =
(hans.zandbelt@zmartzone.eu) wrote:
>>>>>=20
>>>>> Without agreeing or disagreeing: OIDC does not apply here since it =
is not OAuth and an access token is not an id_token.
>>>>>=20
>>>>> The JWT spec says in =
https://tools.ietf.org/html/rfc7519#section-4.1.2:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>>=20
>>>>>    subject of the JWT.  The claims in a JWT are normally =
statements
>>>>>=20
>>>>>    about the subject.  The subject value MUST either be scoped to =
be
>>>>>=20
>>>>>    locally unique in the context of the issuer or be globally =
unique.
>>>>>=20
>>>>>    The processing of this claim is generally application specific"
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> which kind of spells "client" in case of the client credentials =
grant but I also do worry about Resource Servers thinking/acting only in =
terms of users
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier =
 wrote:
>>>>>=20
>>>>> IMHO the sub claim should always refer to the user - and nothing =
else.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> OIDC says:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> client_id should be used to identify clients.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> cheers
>>>>>=20
>>>>> Dominick
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) =
wrote:
>>>>>=20
>>>>> Hi Vittorio,
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> One feedback.
>>>>>=20
>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and client, in this spec.
>>>>>=20
>>>>> It requires those 2 types of identifiers to be unique each other =
in the IdP context.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, =
so that no such constraint needed.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> thanks
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> nov
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci =
 wrote:
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 =
access tokens. You can find it in =
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>>>>>=20
>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be =
presenting remotely). I look forward for your comments!
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Here's just a bit of backstory, in case you are interested in how =
this doc came to be. The trajectory it followed is somewhat unusual.
>>>>>=20
>>>>> 	=E2=80=A2 Despite OAuth2 not requiring any specific format for =
ATs, through the years I have come across multiple proprietary solution =
using JWT for their access token. The intent and scenarios addressed by =
those solutions are mostly the same across vendors, but the syntax and =
interpretations in the implementations are different enough to prevent =
developers from reusing code and skills when moving from product to =
product.
>>>>> 	=E2=80=A2 I asked several individuals from key products and =
services to share with me concrete examples of their JWT access tokens =
(THANK YOU Dominick Baier (IdentityServer), Brian Campbell =
(PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for =
the tokens and explanations!).
>>>>> I studied and compared all those instances, identifying =
commonalities and differences.=20
>>>>> 	=E2=80=A2 I put together a presentation summarizing my findings =
and suggesting a rough interoperable profile (slides: =
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt=
_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. =
Thx Filip!
>>>>> 	=E2=80=A2 The presentation was followed up by 1.5 hours of =
unconference discussion, which was incredibly valuable to get tight-loop =
feedback and incorporate new ideas. John Bradley, Brian Campbell =
Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig =
were all there and contributed generously to the discussion. Thank =
you!!!
>>>>> Note: if you were at OSW2019, participated in the discussion and =
didn't get credited in the draft, my apologies: please send me a note =
and I'll make things right at the next update.
>>>>> 	=E2=80=A2 On my flight back I did my best to incorporate all the =
ideas and feedback in a draft, which will be discussed at IETF104 =
tomorrow. Rifaat, Hannes and above all Brian were all super helpful in =
negotiating the mysterious syntax of the RFC format and submission =
process.
>>>>> I was blown away by the availability, involvement and willingness =
to invest time to get things right that everyone demonstrated in the =
process. This is an amazing community.=20
>>>>>=20
>>>>> V.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>>=20
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>>=20
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> Vennlig hilsen
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Steinar Noem
>>>>>=20
>>>>> Partner Udelt AS
>>>>>=20
>>>>> Systemutvikler
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no =
|=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>>=20
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>>=20
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>>=20
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --=20
>>>>> hans.zandbelt@zmartzone.eu
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>=20


--Apple-Mail=_D0DA92FB-A364-4ADC-9D7F-0ED8B87BD90A
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
Fw0xOTA1MDgxMjE1MjBaMC8GCSqGSIb3DQEJBDEiBCBDaaDGfocy10udomn9S7BAeaO07+BfJf6w
r4lFXZiJrTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAJmyT+TBD6lKXi8H6++ag3dmGVH1t2zknikdGLTmqy/qutz2m85oHjN3yU45
tOEGHxdsi//rCzhxZ0nfDQhmpvvAV7zh+GufV+fBDVfnn5ZeA8uImSFsJco0fFuhtmsFbrOof+OV
GMnF1sCgndMdOaoBZGFsUffcqcT3cIjPM5yPa8OY8ySubn/hPlR+dU8CSDbBhmDsLMUjHRtA7UQV
ohe4ug7dNaNa0gnNz+0SZY84+e8M4OtSAXSfbCytimPCF/64vKsvn7PKCSc8g+raXLhV0//f4vvo
IuAG0ljl/ZFT6YPXPjYoZELSSboE8UJvFPzFHKq7lrlmUMJIa0i1fE0AAAAAAAA=
--Apple-Mail=_D0DA92FB-A364-4ADC-9D7F-0ED8B87BD90A--


From nobody Wed May  8 07:44: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 693BE12011C for ; Wed,  8 May 2019 07:43: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 Ujd7zR_Ubfyr for ; Wed,  8 May 2019 07:43:49 -0700 (PDT)
Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (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 2F07112010C for ; Wed,  8 May 2019 07:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557326627; bh=7YHkCbB8UH4U/BiI+9BFsXLBKjFWrqQzpCLybdw6DEM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ZFq9kCU3FEizsBLEL8k15twH8wz/9ovMlprM0DpO+QGXvqDaR6/Bk7e20p9kGUJZykyKPygXg18q89E4x17CH1DH0Uk6kbZN7m9C98Ax/66clHT/eEXV+9B2sLH27wAbePCNI7yLCCvkgatTSuySCrRenZOhYpsjAXwnSy8j8G5mV2DHrHShATRM7N+KvcAZGtLxUTkYzVbhLHuLocDSGGBpEzxDfAUI7eomxdOhnTOST1JowCQ9viilQRm8ppl0axWIFvyB2Z2JpH72fVFJjssvJC8sE1zxWvjvs6hqw6P9s3lWPqrwY8x5vlkYBlVRgErPU85/ROYf4NN4Y23Zkw==
X-YMail-OSG: YGeN4RsVM1k2Gluf0Msew9N1QTxouyBi4PZ56XGIsUt9O5l_FtozygESAoIxCEI pQs4O42YVJMCmM0x5AtEEQUh0KWDSVxWH0DnUtNDjqQhWi2Xg990h0gk11Gkoq8IjrSH2h6KSS6n .b3SszKzZiy0feS3FuhtAIYuuD3LpzBYeTIz9hgj1XNhgVP0pzbt2yV1Qi7t3RaXk5U.2DtVGkps dTWu.2bBbVuNombP8MEkv282ggM2OXzG9qMgh5YMRaL2qiVmIXcV47xNnVqUEwsF5UMMVess9Tw7 eSgJekvfpUT9vdK6CWL_mHfcd5aDPAfoETRvqueEDXftDEeatNWaz7toZDaMlQDyXRADpEwZkZn0 4grIPM0G9qYl6Im0LtAkczBlzRb28jF_y0xvZygbZVSJZPKLa7Y0NnzUgMEZ32cMGEOhHTPJiyq0 Ckayqh5xhEglFGJUbtdTZ.3KLV6mQTQuuCSsirI0zDkwjQOy_uc2oDOZ6SY_64BmLg5O5vfqTtDo B7Sal4nAg8KSkghy7H46dD2XdEMhz.OpQsOOff5Sdxq0kh6vyqXLwNXAW3lPPyP99bmq9sFmrw2p DGhXSOIsrC2WanO0m4N.qhOCvNCQgsnF6rVjPLSa5xnqDOcv0PUW46z.yVySLWBJ3uRoVPE6oESZ _KGWsVVdOJwTKfet9AGLOhkw0b5Rz8ryw3BIuVM352XO2mRcQlfHAkMRNXKO5KAy4jfqsJIWoAFd rgou94HUwCGt1x5vxgNIwu7sH330cH2Kqa1h8xfcjdUFu59iz6qNq0OVZ647qvb1uzC9Q9cG7DQq TW6XPMQ2Zf._O5HKk0Kfj8rzgZ9z6nCwcWzqffr97VAar627lCSXM1mQZ916mZFg2J5TbTJMsqie jiicfheYhQBBOsmV.lgpvX7qi7x9j9mrvvNlnu5hM0W4YfkHTgkPx8BKHFEuGXekmW0LGIxcf7Gk N6gN9ndZzRfgVBfTihDTcUHFSWWdFhzEMMueMutRWyvFgG7E9jP6vmtt3G9LWBK2.alOF8TEwTx4 MNfqi4Fl8wyvzkQYsPF.M5GGC5NnxL8bkHntx0O3ueX2K77bw0hBkRmSLJbYuojZ5BMcL0q._Hg9 0iLrrHM_eOJKXWhh7qX_HiyrhziHi3dwYWrBYZJ0mUoVYiLWJ78CZFAyTco4j2BPo8pyjeynKJc7 Oym.RaGFzlSL0YOg-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 8 May 2019 14:43:47 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2ab2ba8950ddb4134b1b99a9603f86f5;  Wed, 08 May 2019 14:43:44 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: Sascha Preibisch , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com>
Date: Wed, 8 May 2019 10:43:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------A8784BD710690087DFAAD650"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
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, 08 May 2019 14:43:55 -0000

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

>     George::
>
>     Again, I would want the transaction requirements to be part of the
>     API not part of the scope. In my mind, the authorization token
>     should convey the client is authorized to perform a set of actions
>     (capabilities) and then the API parameters define the exact
>     details of that particular transaction.
>
>
> Torsten:: I understand your sentiments. How would you envision to ask 
> a user for consent about those details if this consent is required by law?

So it seems we are looking for two key aspects as it relates to the 
transaction(s) and consent...

1. Require explicit user consent regarding the details of the transaction
2. Specify the details of the transaction

It seems the mapping of this to the term "scope" is because at the 
authorization endpoint it's the "scopes" the user has to consent to. 
However, we don't have to try and map this transactional functionality 
into the existing more capability model of OAuth2.

Assuming that something like a "consent receipt" will be issued to the 
user once they have consented... what about using a term more consistent 
with consent? "transaction_consent" ? I'd even be fine with 
"transaction_details" and then have the spec require that the user 
consent to all information in the "transaction_details" object. Though I 
suspect there are use cases where there are more details in the 
transaction than for which the user needs to give consent. So that might 
not be the best name.

At this point I'm probably splitting hairs:) Naming things is hard:)

On 4/30/19 6:39 AM, Torsten Lodderstedt wrote:
>
>
> Am 26.04.2019 um 16:17 schrieb George Fletcher  >:
>
>>
>>
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>>
>>>
>>> Am 25.04.2019 um 17:03 schrieb George Fletcher >> >:
>>>
>>>> A couple of thoughts...
>>>>
>>>> 1. It doesn't feel like these are scopes (at least not as scope is 
>>>> defined by RFC 6749). It feels like they are more transaction 
>>>> requirements.
>>>
>>> What???s the difference? In my opinion, if you authorize a 
>>> transaction it???s the same. Moreover, in other use cases (account 
>>> information) it a complex requirement for a potentially long lasting 
>>> grant.
>>>
>>> In both cases, they describe the request power of the token == 
>>> it???s scope.
>> I guess I look at scope as "authorized to transfer" maybe something 
>> like "authorized to transfer up to 10K". However the details of which 
>> account to take the money from and the account of where to put the 
>> money are not aspects of the scope but rather restrictions on the 
>> transaction.
>>
>> It may be fine to have a model where the client tells the AS what 
>> transaction it wants to perform for the purpose of getting consent 
>> from the user to perform that transaction... but I don't think the 
>> details of the transaction should be considered scope(s).
>>
>> For me.. scope is a capability the client is authorized to perform... 
>> "send an Instant message", or "read a buddy list".
>>>
>>>>
>>>> 2. The schemas are going to be very ecosystem specific, correct?
>>>
>>> API (e.g. all psd2 standards), ecosystem, single deployment - just 
>>> like ???traditional??? scope values
>> Again, I would want the transaction requirements to be part of the 
>> API not part of the scope. In my mind, the authorization token should 
>> convey the client is authorized to perform a set of actions 
>> (capabilities) and then the API parameters define the exact details 
>> of that particular transaction.
>
> I understand your sentiments. How would you envision to ask a user for 
> consent about those details if this consent is required by law?
>
>>>
>>>>
>>>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>>>> Hi Sascha,
>>>>>
>>>>> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition.
>>>>>
>>>>> In my last example, the scope is defined as
>>>>>
>>>>>     "structured_scope":{
>>>>>        "sign":{
>>>>>           "credentialID":"qes_eidas",
>>>>>           "documentDigests":[
>>>>>              {
>>>>>                 "hash":
>>>>>                   "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>>>>>                 "label":"Mobile Subscription Contract"
>>>>>              }
>>>>>           ],
>>>>>           "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>>>        },
>>>>>        "payment":{
>>>>>           "type":"sepa-credit-transfer",
>>>>>           "instructedAmount":{
>>>>>              "currency":"EUR",
>>>>>              "amount":"123.50"
>>>>>           },
>>>>>           "debtorAccount":{
>>>>>              "iban":"DE40100100103307118608"
>>>>>           },
>>>>>           "creditorName":"Merchant123",
>>>>>           "creditorAccount":{
>>>>>              "iban":"DE02100100109307118603"
>>>>>           },
>>>>>           "remittanceInformationUnstructured":"new Smartphone"
>>>>>        }
>>>>>
>>>>> This means ???sign" and ???payment" would determine the scheme of the respective object.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> best regards,
>>>>> Torsten.
>>>>>
>>>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:
>>>>>>
>>>>>> Hi Torsten!
>>>>>>
>>>>>> If 'structured_scope' would become a generic field for application
>>>>>> specific content, I believe an indicator for the type of content would
>>>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>>>> this helps!
>>>>>>
>>>>>> Thank you,
>>>>>> Sascha
>>>>>>
>>>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>>>> :
>>>>>>> Hi Sascha,
>>>>>>>
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:
>>>>>>>>
>>>>>>>> Thank you for the article, Torsten!
>>>>>>> my pleasure :-)
>>>>>>>
>>>>>>>> I like that 'scope' is out of the game for these kinds of authorizations.
>>>>>>>>
>>>>>>>> What I can see for the general use case is a required identifier
>>>>>>>> within the 'structures_scope' document that identifies the profile it
>>>>>>>> should be used for.
>>>>>>> What does profile mean in this context?
>>>>>>>
>>>>>>> best regards,
>>>>>>> Torsten.
>>>>>>>> Thank you,
>>>>>>>> Sascha
>>>>>>>>
>>>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>>>> :
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I just published an article about the subject at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>>>>>
>>>>>>>>> I look forward to getting your feedback.
>>>>>>>>>
>>>>>>>>> kind regards,
>>>>>>>>> Torsten.
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>
>>


--------------A8784BD710690087DFAAD650
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
George::

    

    

      
Again, I would want the transaction requirements to be
        part of the API not part of the scope. In my mind, the
        authorization token should convey the client is authorized to
        perform a set of actions (capabilities) and then the API
        parameters define the exact details of that particular
        transaction.

      

      


      

      Torsten:: I understand your sentiments. How would you envision to
      ask a user for consent about those details if this consent is
      required by law?

    

    So it seems we are looking for two key aspects as it relates to the
    transaction(s) and consent...

    

    1. Require explicit user consent regarding the details of the
    transaction

    2. Specify the details of the transaction

    

    It seems the mapping of this to the term "scope" is because at the
    authorization endpoint it's the "scopes" the user has to consent to.
    However, we don't have to try and map this transactional
    functionality into the existing more capability model of OAuth2.

    

    Assuming that something like a "consent receipt" will be issued to
    the user once they have consented... what about using a term more
    consistent with consent? "transaction_consent" ? I'd even be fine
    with "transaction_details" and then have the spec require that the
    user consent to all information in the "transaction_details" object.
    Though I suspect there are use cases where there are more details in
    the transaction than for which the user needs to give consent. So
    that might not be the best name.

    

    At this point I'm probably splitting hairs:) Naming things is hard:)

    

    
On 4/30/19 6:39 AM, Torsten Lodderstedt
      wrote:

    

    

      
      


      

      


        Am 26.04.2019 um 16:17 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          

          

          
On 4/25/19 1:54 PM, Torsten
            Lodderstedt wrote:

          

          

            
            


            

            


              Am 25.04.2019 um 17:03 schrieb George Fletcher <gffletch@aol.com>:

              

            

            

              

                
                A couple of
                  thoughts...

                  

                  1. It doesn't feel like these are scopes (at least not
                  as scope is defined by RFC 6749). It feels like they
                  are more transaction requirements.

                

            

            


            

            What???s the difference? In my opinion, if you authorize a
            transaction it???s the same. Moreover, in other use cases
            (account information) it a complex requirement for a
            potentially long lasting grant.
            


            

            
In both cases, they describe the request power of the
              token == it???s scope.

            

          

          I guess I look at scope as "authorized to transfer" maybe
          something like "authorized to transfer up to 10K". However the
          details of which account to take the money from and the
          account of where to put the money are not aspects of the scope
          but rather restrictions on the transaction. 

          

          It may be fine to have a model where the client tells the AS
          what transaction it wants to perform for the purpose of
          getting consent from the user to perform that transaction...
          but I don't think the details of the transaction should be
          considered scope(s).

          

          For me.. scope is a capability the client is authorized to
          perform... "send an Instant message", or "read a buddy list".

          

            

              


                

                  
 

                      2. The schemas are going to be very ecosystem
                      specific, correct?

                    

                

                


                

                
API (e.g. all psd2 standards), ecosystem, single
                  deployment - just like ???traditional??? scope values

              

            

          

          Again, I would want the transaction requirements to be part of
          the API not part of the scope. In my mind, the authorization
          token should convey the client is authorized to perform a set
          of actions (capabilities) and then the API parameters define
          the exact details of that particular transaction.

        

      

      


      

      I understand your sentiments. How would you envision to ask a user
      for consent about those details if this consent is required by
      law?
      

        


          

            

              

                

                  


                    

                      
 

                        
On 4/24/19 1:08 PM,
                          Torsten Lodderstedt wrote:

                        

                        

                          
Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 



                          

                            
On 23. Apr 2019, at 17:14, Sascha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                            

                              
Hi Sascha,



                              

                                
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


                              

                              
my pleasure :-)



                              

                                
I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


                              

                              
What does profile mean in this context?

best regards,
Torsten.


                              

                                
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                                

                                  
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.
_______________________________________________
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


                        

                        

                      

                    

                  

                

              

              

            

          

        

      

    

    

  


--------------A8784BD710690087DFAAD650--


From nobody Wed May  8 07:53:59 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 1FCD812011C for ; Wed,  8 May 2019 07:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 aweo3lmnJ5q7 for ; Wed,  8 May 2019 07:53:51 -0700 (PDT)
Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 210701201E6 for ; Wed,  8 May 2019 07:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557327217; bh=jFyLvCqJWDUBMIYhlBavZ87sWP8j1stVRm90WZDZr8c=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=rUAgpalAmHPn2tgrOEeuC9oD5LcsdneFNcn1/qxh0B0g1ECjegpsnZ7reDkkw9H+6gLhEBo/7dnB/WojvnUekhgsTqyn6+fzQSkX7NWJION756rhs4IcRlWTg3SvUK7Y5COc5i1roLelu+XxMt+bYDHgoppu+zTBso3GQ0uAoWpamOy3bF2Wc7iJ9jxnP3ubtyvooO7VSvjIDBceRbGT3Jdg7CgEMtnv3UgN8m7ZD7Ww2NiKdl0pGx/lU6NWmV3vD2HFexuJ3jdlrznMI9srs2jaIKIZOP79v8ocI+tyzrB6lZ6TB7kdzmjCLGyXkwvElS5cLFHG552hF6XexLcLhQ==
X-YMail-OSG: 4Kb8UqMVM1mN5qsdezH.GtlnG6dC4Hg1AjjiYeY3ENvoXGLCgWfpBaZ9C83KKXC zZBOFpOp8IvAEAZ7jAbTUHrS1JKLsf_SNFcBcIo6JOh5_iDHfyGlIAWn30L8TxnXtFsgZnyvTi0E skDvKojumvfQvKI.n3XvT1zkkA3LVyE23YOlIrl7gRvAwvnrCfLLqMlu71Ao4wwIqRtlXcSnAmUO YH_IkG98j7ZIkYMuyvjOA_T.pQq5gcTSJeU5H1px.DKhbkCKVqowkvmFup8AeDQpCGgcBfpT.OX0 e_vn1wU148wwyV.ECy0ibK02azA4.BDt_6nHRcJhw_IdV8Vv1Yp_tcnpcSKVENMSzbvrH_1TAPwR tmGdsFtuKfwvpPqhbRhozzS6LQJN1YR6HK_vRElevEl8pY5ijx5LOgrZBeVoajTnc6AwPMp_ZdgR a41_qEhg.OSV7bQNEXgiNVyFK6FasAYYsCYy0Hyv9CMbfXx2izgFj3d0zekV7I954gxsIHLKzMBU lpBpAYx3NUmHq5.HLRjPsPhP.kPG5irsak1nsy21QyGR4gezgGLDTyouUwNN.bZU4UR2Dj1YHlnh _ZrhXPlgBumKh8_8WCB5fnOOhN7BOe5BWgp6vA0YfqakDMdZBfPaFCfT2yCkqc4c4raJF6PaFJnC BOsrAloHlEH3BTRTioFGnLv9Je.GNE3QMqSESQp.._AETjQIkyNLrSgzCT6CkN_aaJekMpiYCWz7 zkvqdCNJRqcwpiq5D2RToAKn.QsPHx3l5qpHd5JO5XiB.QufOeKvU5zkAVLQHf160sEAMqew7jBn kyCpBxK6owITNtKVtxq2yV3X3rfzKbY.HoxOJVvQ2a4fPenqYcBht4PyUxtJ9SZhphCgbPCMxnWa B9fehG1a82qFdx_61z8xUIONnNZBibWTnswzpeE4cacfKAjWVdMS_ZhtGjPK68N7uJ1Gxh.cSyeE TiGUfXwyptj9iSeNkpIt9Xyc8IbLuld95FeHg.jLI8YuEe70PogSXIe_nGz9dXRxqvrif7cDIq0B rVVLLB3f16_6BCrehzWkAJjqhYV6sDyQI7HewtLoGD35D1D_JgtjRsw0oGgwQeht3wTx7dUymHLR eZZABf.UB8p8tNRwQW4P3unEQA1nCZmwf7cryZe77Ygv9W1uKRYTMbqYrmJVB0mE2pj3uIhW3sAl Tnjs-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 8 May 2019 14:53:37 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4cae3bc137c309e71b068b5683fa2a3d;  Wed, 08 May 2019 14:53:32 +0000 (UTC)
To: Vladimir Dzhuvinov , oauth@ietf.org
References:        <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <73400ae2-aa92-a532-551d-613300229bf5@connect2id.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <72478670-61e5-bb8a-e454-0753dc83a80b@aol.com>
Date: Wed, 8 May 2019 10:53:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <73400ae2-aa92-a532-551d-613300229bf5@connect2id.com>
Content-Type: multipart/alternative; boundary="------------BD0DE98D34489C3E8CFC4DAA"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 14:53:56 -0000

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

Maybe this is a dumb question, but why would an AS allow a client to 
register it's own client_id rather than issuing the client a client_id 
within the namespace of the AS?

Also, a client_id or sub should NEVER be treated as unique without the 
context of the issuer. In that regard, the AS (as Torsten pointed out) 
MUST ensure uniqueness within it's "issuer" context.

On 5/8/19 4:22 AM, Vladimir Dzhuvinov wrote:
>
> This is an excellent security point.
>
> I also imagine that in "federated" cases an RS could have its own 
> subject scheme / namespace, distinct from the one at the AS, including 
> for clients acting on their own behalf.
>
> Vladimir
>
> On 07/05/2019 11:37, Neil Madden wrote:
>> I wasn’t at IIW so I may be missing some context.
>>
>> There is a potential security issue if the client_id is used as the “sub” for an AT obtained via client_credentials. If the client can register itself with a self-chosen client_id then it may deliberately chose a client_id that matches the user name of a privileged user. An RS that just blindly looks at the “sub” claim may then erroneously let the client perform privileged actions.
>>
>> Is this the context of the discussion?
>>
>> Given that there are a lot of RSes in existence, many of which are probably just looking at the “sub” claim to identify the resource owner, I think the onus is on the AS to ensure that no such ambiguity can arise in the first place by ensuring that the space of “sub” values for client credentials is disjoint with the space for genuine users or by disallowing the client_credentials grant altogether.
>>
>> This issue already arises in token introspection though, so maybe ought to be mentioned in the OAuth security topics draft rather than specific to the JWT AT draft?
>>
>> — Neil
>>
>>> On 6 May 2019, at 18:32, Vittorio Bertocci  wrote:
>>>
>>> Hi all,
>>> thanks for your patience during this month long hiatus, and thanks for the comments.
>>> Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended).
>>>
>>> - It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that.
>>> - That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect. I find the proposal very clever, and the people at IIW thought so as well. What you think?
>>> Note, John Bradley observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence.
>>>
>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt > wrote:
>>> I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid
>>>
>>> Hans.
>>>
>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones > wrote:
>>> I get that existing practice is likely to be all over the map, but if we’re to create a JWT access token standard, it’s reasonable to require that the claims usage comply with the JWT standards.
>>>
>>>   
>>>
>>>                                                                  -- Mike
>>>
>>>   
>>>
>>> From: Hans Zandbelt > 
>>> Sent: Thursday, April 4, 2019 12:59 PM
>>> To: Mike Jones >
>>> Cc: George Fletcher >; Vittorio Bertocci >; IETF oauth WG >
>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>
>>>   
>>>
>>> the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Owner in the access token (as a Resource Server implementer I've suffered a lot from this)
>>>
>>>   
>>>
>>> Hans.
>>>
>>>   
>>>
>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones > wrote:
>>>
>>> I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition athttps://tools.ietf.org/html/rfc7519#section-4.1.2    is:
>>>
>>> The "sub" (subject) claim identifies the principal that is the subject of the JWT.
>>>
>>>   
>>>
>>> If an access token uses “sub”, its usage must comply with the definition from RFC 7519.
>>>
>>>   
>>>
>>>                                                                  -- Mike
>>>
>>>   
>>>
>>> From: OAuth > On Behalf Of George Fletcher
>>> Sent: Thursday, April 4, 2019 8:51 AM
>>> To: Hans Zandbelt >
>>> Cc: Vittorio Bertocci >; IETF oauth WG >
>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>
>>>   
>>>
>>> The more I think about this the more I land in the "No" camp.
>>>
>>> The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.
>>>
>>> Thanks,
>>> George
>>>
>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>
>>> I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.
>>>
>>>   
>>>
>>> Hans.
>>>
>>>   
>>>
>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote:
>>>
>>> I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)
>>>
>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>
>>> great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board
>>>
>>>   
>>>
>>> Hans.
>>>
>>>   
>>>
>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci > wrote:
>>>
>>> thank you Steinar and everyone else for the comments on this!
>>>
>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.
>>>
>>> That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.
>>>
>>> Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?
>>>
>>>   
>>>
>>> Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.
>>>
>>>   
>>>
>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote:
>>>
>>> Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!
>>>
>>> We also agree with Dominick concerning definition of the "sub" claim.
>>>
>>>   
>>>
>>> Steinar
>>>
>>>   
>>>
>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier >:
>>>
>>> >From an access token consumer (aka API) developer point of view, I prefer this logic
>>>
>>>   
>>>
>>> "If sub is present - client acts on behalf of a user, if not - not."
>>>
>>>   
>>>
>>> Anything more complicated has a potential of going wrong.
>>>
>>>   
>>>
>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com  ) wrote:
>>>
>>> Hi Vittorio,
>>>
>>>   
>>>
>>> Yeah, I’m concerning user & client ids collision.
>>>
>>> I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.
>>>
>>>   
>>>
>>> If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.
>>>
>>>   
>>>
>>> Sent from my iPhone
>>>
>>>
>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote:
>>>
>>> Hey Nov, Dominick, Hans-
>>>
>>> thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
>>>
>>> The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.
>>>
>>>   
>>>
>>> The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.
>>>
>>>   
>>>
>>> Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
>>>
>>> Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?
>>>
>>>   
>>>
>>> Thanks
>>>
>>> V.
>>>
>>>   
>>>
>>>   
>>>
>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt > wrote:
>>>
>>> I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).
>>>
>>>   
>>>
>>> Hans.
>>>
>>>   
>>>
>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier > wrote:
>>>
>>> Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.
>>>
>>>   
>>>
>>> All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.
>>>
>>>   
>>>
>>> In reality this leads to potential security problems - this spec has the potential to rectify the situation.
>>>
>>>   
>>>
>>> Dominick
>>>
>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu  ) wrote:
>>>
>>> Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
>>>
>>> The JWT spec says inhttps://tools.ietf.org/html/rfc7519#section-4.1.2  :
>>>
>>>   
>>>
>>> "The "sub" (subject) claim identifies the principal that is the
>>>
>>>     subject of the JWT.  The claims in a JWT are normally statements
>>>
>>>     about the subject.  The subject value MUST either be scoped to be
>>>
>>>     locally unique in the context of the issuer or be globally unique.
>>>
>>>     The processing of this claim is generally application specific"
>>>
>>>   
>>>
>>> which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users
>>>
>>>   
>>>
>>> Hans.
>>>
>>>   
>>>
>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote:
>>>
>>> IMHO the sub claim should always refer to the user - and nothing else.
>>>
>>>   
>>>
>>> OIDC says:
>>>
>>>   
>>>
>>> "Subject - Identifier for the End-User at the Issuer."
>>>
>>>   
>>>
>>> client_id should be used to identify clients.
>>>
>>>   
>>>
>>> cheers
>>>
>>> Dominick
>>>
>>>   
>>>
>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com  ) wrote:
>>>
>>> Hi Vittorio,
>>>
>>>   
>>>
>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>
>>>   
>>>
>>> One feedback.
>>>
>>> The “sub” claim can include 2 types of identifier, end-user and client, in this spec.
>>>
>>> It requires those 2 types of identifiers to be unique each other in the IdP context.
>>>
>>>   
>>>
>>> I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.
>>>
>>>   
>>>
>>> thanks
>>>
>>>   
>>>
>>> nov
>>>
>>>   
>>>
>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci > wrote:
>>>
>>>   
>>>
>>> Dear all,
>>>
>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it inhttps://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/  .
>>>
>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!
>>>
>>>   
>>>
>>> Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
>>>
>>> Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
>>> I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>>> I studied and compared all those instances, identifying commonalities and differences.
>>> I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx    ) - got early feedback from Filip Skokan on it. Thx Filip!
>>> The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
>>> Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
>>> On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
>>> I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.
>>>
>>> V.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/oauth  
>>>   
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/oauth  
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/oauth  
>>>
>>>   
>>>
>>> --
>>>
>>> hans.zandbelt@zmartzone.eu  
>>> ZmartZone IAM -www.zmartzone.eu  
>>>
>>>   
>>>
>>> --
>>>
>>> hans.zandbelt@zmartzone.eu  
>>> ZmartZone IAM -www.zmartzone.eu  
>>> _______________________________________________
>>> 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  
>>>
>>>   
>>>
>>> --
>>>
>>> hans.zandbelt@zmartzone.eu  
>>> ZmartZone IAM -www.zmartzone.eu  
>>>   
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/oauth  
>>>   
>>>
>>>
>>>
>>>   
>>>
>>> --
>>>
>>> hans.zandbelt@zmartzone.eu  
>>> ZmartZone IAM -www.zmartzone.eu  
>>>   
>>>
>>>
>>>
>>>   
>>>
>>> --
>>>
>>> hans.zandbelt@zmartzone.eu  
>>> ZmartZone IAM -www.zmartzone.eu  
>>>
>>> -- 
>>> 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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Maybe this is a dumb question, but why would an AS allow a client to
    register it's own client_id rather than issuing the client a
    client_id within the namespace of the AS? 

    

    Also, a client_id or sub should NEVER be treated as unique without
    the context of the issuer. In that regard, the AS (as Torsten
    pointed out) MUST ensure uniqueness within it's "issuer" context.

    

    
On 5/8/19 4:22 AM, Vladimir Dzhuvinov
      wrote:

    

    

      
      
This is an excellent security point.

      
I also imagine that in "federated" cases an RS could have its
        own subject scheme / namespace, distinct from the one at the AS,
        including for clients acting on their own behalf.

      
Vladimir

      

      
On 07/05/2019 11:37, Neil Madden
        wrote:

      

      

        
I wasn’t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the “sub” for an AT obtained via client_credentials. If the client can register itself with a self-chosen client_id then it may deliberately chose a client_id that matches the user name of a privileged user. An RS that just blindly looks at the “sub” claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are probably just looking at the “sub” claim to identify the resource owner, I think the onus is on the AS to ensure that no such ambiguity can arise in the first place by ensuring that the space of “sub” values for client credentials is disjoint with the space for genuine users or by disallowing the client_credentials grant altogether.

This issue already arises in token introspection though, so maybe ought to be mentioned in the OAuth security topics draft rather than specific to the JWT AT draft?

— Neil



        

          
On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org> wrote:

Hi all,
thanks for your patience during this month long hiatus, and thanks for the comments.
Last week at IIW I had the opportunity to discuss this with many of the people on the list. Here's a summary of where the discussion landaed on the subject of the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I didn't check it back when we started the discussion. I do agree with the people saying that we shouldn't violate existing specifications, hence it looks like we do need to have sub also in the case in which we have app-only tokens carrying claims about the app itself. I understand this will cause some implementation to break, but unfortunately that's intrinsic in the process of coming up with a common approach and standards compliance is probably one of the strongest reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality. One of the main reasons that was brought up for including sub only for user based ATs was to use it as heuristic for telling those tokens apart from app-only ones. To that end, Karl MCGuinness suggested that we include grant_type as a return claim, which the RS could use to the same effect. I find the proposal very clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous results if an extension grant is used (say an assertion profile) but that seems like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that the JWT is supposed to be about the client or about the resource owner, hence both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
I get that existing practice is likely to be all over the map, but if we’re to create a JWT access token standard, it’s reasonable to require that the claims usage comply with the JWT standards.

 

                                                                -- Mike

 

From: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> 
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>
Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Owner in the access token (as a Resource Server implementer I've suffered a lot from this)

 

Hans.

 

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:

I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2> is:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.

 

If an access token uses “sub”, its usage must comply with the definition from RFC 7519.

 

                                                                -- Mike

 

From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

 

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:

I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.

 

Hans.

 

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

 

Hans.

 

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>> wrote:

thank you Steinar and everyone else for the comments on this!

To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.

That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.

Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

 

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.     

 

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no <mailto:steinar@udelt.no>> wrote:

Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!

We also agree with Dominick concerning definition of the "sub" claim.

 

<mvh>Steinar</mvh>

 

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>>:

>From an access token consumer (aka API) developer point of view, I prefer this logic

 

"If sub is present - client acts on behalf of a user, if not - not."

 

Anything more complicated has a potential of going wrong.

 

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Yeah, I’m concerning user & client ids collision.

I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

 

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

 

Sent from my iPhone


On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com <mailto:Vittorio@auth0.com>> wrote:

Hey Nov, Dominick, Hans-

thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.

The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

 

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

 

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?

Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

 

Thanks

V. 

 

 

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>> wrote:

I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

 

Hans.

 

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

 

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

 

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

 

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2 <https://tools.ietf.org/html/rfc7519#section-4.1.2>:

 

"The "sub" (subject) claim identifies the principal that is the

   subject of the JWT.  The claims in a JWT are normally statements

   about the subject.  The subject value MUST either be scoped to be

   locally unique in the context of the issuer or be globally unique.

   The processing of this claim is generally application specific"

 

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

 

Hans.

 

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com>> wrote:

IMHO the sub claim should always refer to the user - and nothing else.

 

OIDC says:

 

"Subject - Identifier for the End-User at the Issuer."

 

client_id should be used to identify clients.

 

cheers

Dominick

 

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com <mailto:matake@gmail.com>) wrote:

Hi Vittorio,

 

Thanks for the good starting point of standardizing JWT-ized AT.

 

One feedback.

The “sub” claim can include 2 types of identifier, end-user and client, in this spec.

It requires those 2 types of identifiers to be unique each other in the IdP context.

 

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

 

thanks

 

nov

 

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org <mailto:vittorio.bertocci=40auth0.com@dmarc.ietf.org>> wrote:

 

Dear all,

I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.

I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

 

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.

Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and differences. 
I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides:https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early feedback from Filip Skokan on it. Thx Filip!
The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 

V.

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

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

 

--

Vennlig hilsen

 

Steinar Noem

Partner Udelt AS

Systemutvikler

 

| steinar@udelt.no <mailto:steinar@udelt..no> | hei@udelt.no <mailto:hei@udelt.no>  | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> | 

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

 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 

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



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>
 



 

--

hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

-- 
hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
ZmartZone IAM - www.zmartzone.eu <http://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


      

      

      

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


    

    

  


--------------BD0DE98D34489C3E8CFC4DAA--


From nobody Wed May  8 08:06: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 E3BEA12012B for ; Wed,  8 May 2019 08:06:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eaTLzApSwvKf for ; Wed,  8 May 2019 08:06:00 -0700 (PDT)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 EED38120258 for ; Wed,  8 May 2019 08:05:38 -0700 (PDT)
Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id OO8WhUT8j3EbKOO8XhrSz5; Wed, 08 May 2019 08:05:38 -0700
To: Neil Madden 
Cc: IETF oauth WG 
References:     <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>    <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com>
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <77d825e3-1fe8-87a6-90e4-52018f9e8c59@connect2id.com>
Date: Wed, 8 May 2019 18:05:35 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-CMAE-Envelope: MS4wfNV9SS0Ga0/XKNBcPW0PHugpQ8KMbbpFVeN2HS7tQnpHNVFJq3If0+s63l6qNceqryXqo0kx15CCLpUujItYtjVWa0xk+s+qHFtvPqZBHQsBKv5tYLhN lqrGKUyhlTWUqy2w5yFCBu+PVgm2L1KAvBDyEGoH8XcV0FiSgSj4h5bdVzhDrOtoLuBMCmuDa7K54C/5qcUgdjC5llivda0hjI8=
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 15:06:06 -0000

On 08/05/2019 11:57, Neil Madden wrote:
> Why does the RS need to know if the subject is a client vs a user? I su=
spect the answers to that question are about as problematic as the RS nee=
ding to know about the grant type.

I have the exact same question.

Could someone comment on that?

I cannot think of a good reason, unless perhaps for logging / audit.

> I=E2=80=99m not a fan of the client_credentials grant, better off using=
 a real service account in most cases. Hopefully no new grants will be ad=
ded that repeat that mistake.

What do you mean by service account in this context?

> Not sure I understand the point about JWT assertion grant type. If you =
use a JWT assertion for client authentication then that=E2=80=99s just th=
e client_credentials grant again with a different token auth method, righ=
t?

That was my point, that the JWT assertion grant as the client
credentials grant can be used by a client acting on its own behalf.

> =E2=80=94 Neil
>
>> On 8 May 2019, at 08:51, Vladimir Dzhuvinov  =
wrote:
>>
>> grant_type would be horrible for RS developers to deal with, just to f=
ind out whether "sub" effectively =3D=3D "client_id".
>>
>> Why?
>> RS developers will need to learn more OAuth stuff - there are better w=
ays to motivate people than that :)
>> The OAuth grant types are unbounded. If at some point a new grant gets=
 devised / implemented, RS developers will need to update the code that m=
aps grant_types to ("sub" effectively =3D=3D "client_id")
>> We have at least one grant - JWT assertion - where checking the grant =
type is not sufficient to determine if "sub" effectively =3D=3D "client_i=
d"
>> I believe we should aim for a spec where RS developers shouldn't be re=
quired to know more than how to process JWTs.
>>
>> The AS has all the necessary information to indicate whether "sub" eff=
ectively =3D=3D "client_id". We don't need to push that logic to the RS.
>> Vladimir
>>
>> On 07/05/2019 12:16, Neil Madden wrote:
>>> Ah, that makes sense. Well, we already add a grant_type claim to our =
JWT-based access tokens, so I=E2=80=99m in favour of that solution :-)
>>>
>>>
>>>> On 7 May 2019, at 09:48, Vittorio Bertocci   wrote:
>>>>
>>>> Thanks Neil, one more reason to avoid that.
>>>> TL;DR,=20
>>>> The context is the discussion we had pre-IIW about whether sub shoul=
d be included always or only for tokens issued to ROs. Some exiting imple=
mentations rely on that heuristic.
>>>> Turns out that 7519 has language suggesting sub should be there for =
both tokens issued for the RO and for apps (via client creds, etc).
>>>> We don't want to contradict 7519 but we also want to preserve the ab=
ility for a RS to tell whether an AT was issued via RO auth or app auth, =
hence the discussion. Suggestions ranged from adding a grant_type claim (=
Vlad made a convincing argument against it), to relying to the client_id=3D=
=3Dsub heuristic (which i pushed back on) to the introduction of a new cl=
aim (name TBD given that sub_type is taken already) that can explicitly d=
eclare whether the token has been issued authenticating th RO or via app =
credentials.
>>>>
>>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden   <=
mailto:neil.madden@forgerock.com>> wrote:
>>>> I wasn=E2=80=99t at IIW so I may be missing some context.
>>>>
>>>> There is a potential security issue if the client_id is used as the =
=E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the c=
lient can register itself with a self-chosen client_id then it may delibe=
rately chose a client_id that matches the user name of a privileged user.=
 An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may the=
n erroneously let the client perform privileged actions.
>>>>
>>>> Is this the context of the discussion?
>>>>
>>>> Given that there are a lot of RSes in existence, many of which are p=
robably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the r=
esource owner, I think the onus is on the AS to ensure that no such ambig=
uity can arise in the first place by ensuring that the space of =E2=80=9C=
sub=E2=80=9D values for client credentials is disjoint with the space for=
 genuine users or by disallowing the client_credentials grant altogether.=

>>>>
>>>> This issue already arises in token introspection though, so maybe ou=
ght to be mentioned in the OAuth security topics draft rather than specif=
ic to the JWT AT draft?
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci   > wrote:
>>>>>
>>>>> Hi all,
>>>>> thanks for your patience during this month long hiatus, and thanks =
for the comments.
>>>>> Last week at IIW I had the opportunity to discuss this with many of=
 the people on the list. Here's a summary of where the discussion landaed=
 on the subject of the sub (pun intended).
>>>>>
>>>>> - It seems that RFC 7519 has pretty clear language on the use of su=
b- I didn't check it back when we started the discussion. I do agree with=
 the people saying that we shouldn't violate existing specifications, hen=
ce it looks like we do need to have sub also in the case in which we have=
 app-only tokens carrying claims about the app itself. I understand this =
will cause some implementation to break, but unfortunately that's intrins=
ic in the process of coming up with a common approach and standards compl=
iance is probably one of the strongest reasons to tolerate that.
>>>>> - That said, I am strongly committed to preserve existing functiona=
lity. One of the main reasons that was brought up for including sub only =
for user based ATs was to use it as heuristic for telling those tokens ap=
art from app-only ones. To that end, Karl MCGuinness suggested that we in=
clude grant_type as a return claim, which the RS could use to the same ef=
fect. I find the proposal very clever, and the people at IIW thought so a=
s well. What you think?
>>>>> Note, John Bradley observed that in some cases this might lead to a=
mbiguous results if an extension grant is used (say an assertion profile)=
 but that seems like a relatively fringe occurrence.
>>>>>
>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt   > wrote:
>>>>> I also meant to say that (of course) the JWT standard doesn't say t=
hat the JWT is supposed to be about the client or about the resource owne=
r, hence both are valid
>>>>>
>>>>> Hans.
>>>>>
>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones   > wrote:
>>>>> I get that existing practice is likely to be all over the map, but =
if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reas=
onable to require that the claims usage comply with the JWT standards.
>>>>>
>>>>> =20
>>>>>
>>>>>                                                                 -- =
Mike
>>>>>
>>>>> =20
>>>>>
>>>>> From: Hans Zandbelt   >=20
>>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>>> To: Mike Jones   >
>>>>> Cc: George Fletcher   >; Vittorio Bertocci   >; IET=
F oauth WG   >
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>
>>>>> =20
>>>>>
>>>>> the definition of RFC 7519 is actually "petitio principii" and a lo=
t of deployments put claims about the Resource Owner in the access token =
(as a Resource Server implementer I've suffered a lot from this)
>>>>>
>>>>> =20
>>>>>
>>>>> Hans.
>>>>>
>>>>> =20
>>>>>
>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones   > wrote:
>>>>>
>>>>> I agree with George that the subject of a token must be the princip=
al of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for. =
 Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D definition at ht=
tps://tools.ietf.org/html/rfc7519#section-4.1.2    is:
>>>>>
>>>>> The "sub" (subject) claim identifies the principal that is the subj=
ect of the JWT.
>>>>>
>>>>> =20
>>>>>
>>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must compl=
y with the definition from RFC 7519.
>>>>>
>>>>> =20
>>>>>
>>>>>                                                                 -- =
Mike
>>>>>
>>>>> =20
>>>>>
>>>>> From: OAuth =
  > On Beha=
lf Of George Fletcher
>>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>>> To: Hans Zandbelt   >
>>>>> Cc: Vittorio Bertocci   >; IETF oauth WG   >
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>
>>>>> =20
>>>>>
>>>>> The more I think about this the more I land in the "No" camp.
>>>>>
>>>>> The subject of a token should be the principal of that token. It sh=
ouldn't matter whether that is a machine, a user, or a device. Trying to =
separate out "humans" as a special class will just make things more compl=
icated. If we need a claim to identify the subject is a "human" then why =
not just add that. This doesn't break anything and makes it easy for peop=
le to detect this case in those use cases where it's required.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>>>
>>>>> I will argue that in a way such deployments are already broken e.g.=
 in the typical use case of onboarding client accounts in the same direct=
ory/OU/namespace as user accounts and we don't need to cater for that.
>>>>>
>>>>> =20
>>>>>
>>>>> Hans.
>>>>>
>>>>> =20
>>>>>
>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher   > wrote:
>>>>>
>>>>> I agree that this will break a lot of existing flows... especially =
those using any form of the client_credentials flow. In that sense I'm no=
t completely on board yet :)
>>>>>
>>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>>>
>>>>> great summary! this will hurt quite a few existing m2m deployments =
but I do like the rigidness of it all: it is very explicit, cannot misint=
erpreted and thus prevents failure (which is really what Dominick is afte=
r); I'm on board
>>>>>
>>>>> =20
>>>>>
>>>>> Hans.
>>>>>
>>>>> =20
>>>>>
>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci   > wrot=
e:
>>>>>
>>>>> thank you Steinar and everyone else for the comments on this!
>>>>>
>>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, N=
ov, Bertrand recommend using sub only for users. Martin would like to hav=
e the sub for app only flows as well. Hans is neutral.
>>>>>
>>>>> That does sound like the sub as user has more consensus, tho before=
 changing it I'd wait for the people currently at IETF104 to have more ti=
me to comment as well.
>>>>>
>>>>> Clarification. If the goal is to be able to apply the logic "if the=
re's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) =
the use of sub when that's not the case. Are all OK with it?
>>>>>
>>>>> =20
>>>>>
>>>>> Dave, the suggestion of having explicit typing for app only vs user=
 only is interesting! For the purpose of putting together an interoperabl=
e profile, tho, I would suggest we table it for v1 in the interest of get=
ting to something easy to adopt (hence with small delta vs existing imple=
mentations) faster.    =20
>>>>>
>>>>> =20
>>>>>
>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem   =
> wrote:
>>>>>
>>>>> Hi Vittorio, we  (the national federation-gateway for the health se=
rvices in norway - "HelseID")  think his is a really valuable initiative!=

>>>>>
>>>>> We also agree with Dominick concerning definition of the "sub" clai=
m.
>>>>>
>>>>> =20
>>>>>
>>>>> Steinar
>>>>>
>>>>> =20
>>>>>
>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier   >:
>>>>>
>>>>> >From an access token consumer (aka API) developer point of view, I=
 prefer this logic
>>>>>
>>>>> =20
>>>>>
>>>>> "If sub is present - client acts on behalf of a user, if not - not.=
"
>>>>>
>>>>> =20
>>>>>
>>>>> Anything more complicated has a potential of going wrong.
>>>>>
>>>>> =20
>>>>>
>>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com   ) w=
rote:
>>>>>
>>>>> Hi Vittorio,
>>>>>
>>>>> =20
>>>>>
>>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>>>>
>>>>> I haven=E2=80=99t seen such implementations, but user-select userna=
me as sub, or incremental integer as sub & client_id will be easily colli=
de.
>>>>>
>>>>> =20
>>>>>
>>>>> If you can enforce collision resistant IDs between user & client in=
stances, it=E2=80=99ll works fine. I feel its overkill though.
>>>>>
>>>>> =20
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci   > wrote:
>>>>>
>>>>> Hey Nov, Dominick, Hans-
>>>>>
>>>>> thanks for the comments. That was an area I was expecting to cause =
more discussion, and I am glad we are having this opportunity to clarify.=

>>>>>
>>>>> The current language in the draft traces the etymology of sub to Op=
enID Connect core, hence Dominick observation is on point. However in the=
 description I express something in line with 7519, which was in fact my =
intent.
>>>>>
>>>>> =20
>>>>>
>>>>> The idea was to provide an identifier of the calling subject that i=
s guaranteed to be present in all cases- this would allow an SDK develope=
r to use the same code for things like lookups and membership checks rega=
rdless of the nature of the caller (user in a delegated case, app in app-=
only grants). The information to discriminate between user and app caller=
s is always available in the token (say, the caller is a user if sub!=3Dc=
lient_id, where client_id is always guaranteed to be present as well) hen=
ce there's no loss in expressive power, should that difference be relevan=
t for the resource server.
>>>>>
>>>>> =20
>>>>>
>>>>> Dominick, Hans- I probably missed the security issue you guys are t=
hinking of in this case. Of course, if this would introduce a risk I comp=
letely agree it should be changed- I'd just like to understand better the=
 problem. Could you expand it in a scenario/use case to clarify the risk?=

>>>>>
>>>>> Nov- playing this back: is the concern that a user and a client mig=
ht have the same identifier within an IDP? When using collision resistant=
 IDs, as it is usually the case, that seems to be a remote possibility- d=
id you stumble in such scenario in production?
>>>>>
>>>>> =20
>>>>>
>>>>> Thanks
>>>>>
>>>>> V.=20
>>>>>
>>>>> =20
>>>>>
>>>>> =20
>>>>>
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt   > wrote:
>>>>>
>>>>> I believe there are plenty of OAuth 2.0 only use cases out there...=
 but nevertheless I agree with the potential confusion and thus security =
problems arising from that (though one may argue the semantics are the sa=
me).
>>>>>
>>>>> =20
>>>>>
>>>>> Hans.
>>>>>
>>>>> =20
>>>>>
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier   > wrote:
>>>>>
>>>>> Yes I know - and I think in hindsight it was a mistake to use the s=
ame claim type for multiple semantics.
>>>>>
>>>>> =20
>>>>>
>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are maki=
ng things more complicated than they need to be - in my experience almost=
 no-one (that I know) does OIDC only - nor OAuth only. They always combin=
e it.
>>>>>
>>>>> =20
>>>>>
>>>>> In reality this leads to potential security problems - this spec ha=
s the potential to rectify the situation.
>>>>>
>>>>> =20
>>>>>
>>>>> Dominick
>>>>>
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzo=
ne.eu   ) wrote:
>>>>>
>>>>> Without agreeing or disagreeing: OIDC does not apply here since it =
is not OAuth and an access token is not an id_token.
>>>>>
>>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.=
1.2   :
>>>>>
>>>>> =20
>>>>>
>>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>>
>>>>>    subject of the JWT.  The claims in a JWT are normally statements=

>>>>>
>>>>>    about the subject.  The subject value MUST either be scoped to b=
e
>>>>>
>>>>>    locally unique in the context of the issuer or be globally uniqu=
e.
>>>>>
>>>>>    The processing of this claim is generally application specific"
>>>>>
>>>>> =20
>>>>>
>>>>> which kind of spells "client" in case of the client credentials gra=
nt but I also do worry about Resource Servers thinking/acting only in ter=
ms of users
>>>>>
>>>>> =20
>>>>>
>>>>> Hans.
>>>>>
>>>>> =20
>>>>>
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier   > wrote:
>>>>>
>>>>> IMHO the sub claim should always refer to the user - and nothing el=
se.
>>>>>
>>>>> =20
>>>>>
>>>>> OIDC says:
>>>>>
>>>>> =20
>>>>>
>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>
>>>>> =20
>>>>>
>>>>> client_id should be used to identify clients.
>>>>>
>>>>> =20
>>>>>
>>>>> cheers
>>>>>
>>>>> Dominick
>>>>>
>>>>> =20
>>>>>
>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com   ) =
wrote:
>>>>>
>>>>> Hi Vittorio,
>>>>>
>>>>> =20
>>>>>
>>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>>
>>>>> =20
>>>>>
>>>>> One feedback.
>>>>>
>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and client, in this spec.
>>>>>
>>>>> It requires those 2 types of identifiers to be unique each other in=
 the IdP context.
>>>>>
>>>>> =20
>>>>>
>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, =
so that no such constraint needed.
>>>>>
>>>>> =20
>>>>>
>>>>> thanks
>>>>>
>>>>> =20
>>>>>
>>>>> nov
>>>>>
>>>>> =20
>>>>>
>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci   > wrote:
>>>>>
>>>>> =20
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 acc=
ess tokens. You can find it in https://datatracker.ietf.org/doc/draft-ber=
tocci-oauth-access-token-jwt/   .
>>>>>
>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be present=
ing remotely). I look forward for your comments!
>>>>>
>>>>> =20
>>>>>
>>>>> Here's just a bit of backstory, in case you are interested in how t=
his doc came to be. The trajectory it followed is somewhat unusual.
>>>>>
>>>>> Despite OAuth2 not requiring any specific format for ATs, through t=
he years I have come across multiple proprietary solution using JWT for t=
heir access token. The intent and scenarios addressed by those solutions =
are mostly the same across vendors, but the syntax and interpretations in=
 the implementations are different enough to prevent developers from reus=
ing code and skills when moving from product to product.
>>>>> I asked several individuals from key products and services to share=
 with me concrete examples of their JWT access tokens (THANK YOU Dominick=
 Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (=
Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>>>>> I studied and compared all those instances, identifying commonaliti=
es and differences.=20
>>>>> I put together a presentation summarizing my findings and suggestin=
g a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_me=
dia/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx    ) - g=
ot early feedback from Filip Skokan on it. Thx Filip!
>>>>> The presentation was followed up by 1.5 hours of unconference discu=
ssion, which was incredibly valuable to get tight-loop feedback and incor=
porate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torste=
n Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contrib=
uted generously to the discussion. Thank you!!!
>>>>> Note: if you were at OSW2019, participated in the discussion and di=
dn't get credited in the draft, my apologies: please send me a note and I=
'll make things right at the next update.
>>>>> On my flight back I did my best to incorporate all the ideas and fe=
edback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, H=
annes and above all Brian were all super helpful in negotiating the myste=
rious syntax of the RFC format and submission process.
>>>>> I was blown away by the availability, involvement and willingness t=
o invest time to get things right that everyone demonstrated in the proce=
ss. This is an amazing community.=20
>>>>>
>>>>> V.
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>> =20
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandbelt@zmartzone.eu   
>>>>> ZmartZone IAM - www.zmartzone.eu   
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandbelt@zmartzone.eu   
>>>>> ZmartZone IAM - www.zmartzone.eu   
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> Vennlig hilsen
>>>>>
>>>>> =20
>>>>>
>>>>> Steinar Noem
>>>>>
>>>>> Partner Udelt AS
>>>>>
>>>>> Systemutvikler
>>>>>
>>>>> =20
>>>>>
>>>>> | steinar@udelt.no    | hei@udelt.no     | +47 955 21 620 | www.udelt.n=
o    | =

>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandbelt@zmartzone.eu   
>>>>> ZmartZone IAM - www.zmartzone.eu   
>>>>> =20
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org   
>>>>> https://www.ietf.org/mailman/listinfo/oauth   
>>>>> =20
>>>>>
>>>>>
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandbelt@zmartzone.eu   
>>>>> ZmartZone IAM - www.zmartzone.eu   
>>>>> =20
>>>>>
>>>>>
>>>>>
>>>>> =20
>>>>>
>>>>> --
>>>>>
>>>>> hans.zandbelt@zmartzone.eu   
>>>>> ZmartZone IAM - www.zmartzone.eu   
>>>>>
>>>>> --=20
>>>>> 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 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
Vladimir Dzhuvinov



From nobody Wed May  8 13:55:54 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 2D2CC1200F8 for ; Wed,  8 May 2019 13:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkiYLIucWaSc for ; Wed,  8 May 2019 13:55:50 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id E6E0B1200EC for ; Wed,  8 May 2019 13:55:49 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:68de:4106:d669:7824] (unknown [IPv6:2601:282:202:b210:68de:4106:d669:7824]) by alkaline-solutions.com (Postfix) with ESMTPSA id 1F02531764; Wed,  8 May 2019 20:55:48 +0000 (UTC)
From: David Waite 
Message-Id: <28AF8EF5-9CCF-44EB-B028-1FCFA892ECEB@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_196CF112-771E-4FE3-8398-7674474B01A1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 8 May 2019 14:55:47 -0600
In-Reply-To: <2125064.3GpWMRz4CO@papegaaij>
Cc: oauth@ietf.org
To: Emond Papegaaij 
References: <11125817.AKI43N3Yza@papegaaij>  <2125064.3GpWMRz4CO@papegaaij>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
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, 08 May 2019 20:55:52 -0000

--Apple-Mail=_196CF112-771E-4FE3-8398-7674474B01A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 8, 2019, at 1:37 AM, Emond Papegaaij =
 wrote:
>=20
> On maandag 6 mei 2019 22:42:09 CEST David Waite wrote:
>> On May 6, 2019, at 1:42 PM, Emond Papegaaij =
=20
>=20
>> You could also trigger re-authorization with a user click, thus =
allowing
>> opening the AS in a new window or tab. Once back on the site via =
callback,
>> the temporary/pop-up window can do things like exchange the code for =
an
>> access token, persist it, postMessage the original window, do =
window.close,
>> etc.
>=20
> This would work, but would really be a nuisance to the user. =
Especially with a=20
> token timeout of just one hour. Also, most of the times there would be =
no=20
> interaction, the user would just have to click a button. As a user I =
wouldn't=20
> understand why I have to do that all the time.

You do have this for native apps as well, however: =
app-auth-sso-ios-11-blog.png =


>=20
>> On the other hand, refresh tokens IMHO are given quite a bit more =
fear in
>> browser apps than warranted. It really depends on the AS - whether it =
can
>> tie refresh tokens to the user=E2=80=99s authentication, or if they =
are tied to a
>> long-term / persisted / "offline=E2=80=9D authorization independent =
of an active
>> user authentication. Currently, the latter is more common in
>> implementations, and doesn=E2=80=99t make sense for browser =
applications. This
>> doesn=E2=80=99t mean refresh tokens are automatically discounted for =
all
>> environments.
>=20
> How would you tie a refresh token to a user session on the AS? This =
would=20
> depend on the user visiting the AS on a regular basis and using a =
logout=20
> button when done. Most people simply close their browser when they're =
done,=20
> leaving the session open. Also, when making a call to the token =
endpoint to=20
> refresh the access token, there is no way of knowing that this call is=20=

> actually initiated by the user, because it's done on a back channel. =
Perhaps=20
> this can be solved with DPOP with a keypair per browser, but this =
would really=20
> complicate the whole solution.

Yes, there are still no standard solutions for session keep-alive. =
There=E2=80=99s also not AFAIK a clear solution by the browsers on how =
to do an implicit logout on browser closed, now that browsers may =
persist sessions cookies.

I did pitch something about session keep-alive two years ago around this =
as part of DTVA (see =
https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402d=
d6e8c47/distributed-token-validity-api.txt =
 ), which unfortunately =
didn=E2=80=99t go anyplace. For pure API apps participating in a session =
keep-alive system, a separate =E2=80=9Cuser activity present=E2=80=9D =
API to periodically poke is probably the best way to go. For managed =
devices running enterprise applications, you can just have a screen lock =
rather than tracking session activity at all.

For handling browsers in shared user environments which lack =
non-persistent cookies, you typically have to rely on session =
keep-alive/inactivity timeout and logout (which in OAuth would map to a =
token revocation)
=20
>> Given the choice between an 8 hour access token, or a 10 minute =
access token
>> and a refresh token that will expire at a maximum of 8 hours, the =
second
>> provides quite a few more options to be more secure. (eg. checking =
backing
>> user session and revocation, checking for updates to client =
blacklist, the
>> rotation of the access token, rotating refresh tokens to prevent use =
by
>> more than one client, expiring access on inactivity based on lag in
>> refreshing, and so on).
>=20
> I agree with you on this, but the spec currently states clearly that =
the AS=20
> should not issue refresh tokens to an SPA. Do you think this should be =
changed=20
> to something like: Authorization servers SHOULD NOT issue *offline* =
refresh=20
> tokens to browser-based applications. A refresh token should be tied =
to a user=20
> session on the AS.

I would like this language changed as well. It is complex due to so =
little existing token lifetime/policy guidance to reference. Previous =
conversations went a bit circular IMHO because of a lack of ground =
rules.

-DW=

--Apple-Mail=_196CF112-771E-4FE3-8398-7674474B01A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 8, 2019, at 1:37 AM, Emond Papegaaij <emond.papegaaij@gmail.com> wrote:

On maandag 6 mei 2019 22:42:09 =
CEST David Waite wrote:
On May 6, 2019, at 1:42 PM, Emond Papegaaij <emond.papegaaij@gmail.com> 

You could also trigger re-authorization with a user click, =
thus allowing
opening the AS in a new window or tab. Once =
back on the site via callback,
the temporary/pop-up window =
can do things like exchange the code for an
access token, =
persist it, postMessage the original window, do window.close,
etc.

This would =
work, but would really be a nuisance to the user. Especially with a 
token timeout of just one hour. Also, most of the times there =
would be no 
interaction, the user would just have to =
click a button. As a user I wouldn't 
understand why I =
have to do that all the time.

You =
do have this for native apps as well, however: app-auth-sso-ios-11-blog.png


On the =
other hand, refresh tokens IMHO are given quite a bit more fear in
browser apps than warranted. It really depends on the AS - =
whether it can
tie refresh tokens to the user=E2=80=99s =
authentication, or if they are tied to a
long-term / =
persisted / "offline=E2=80=9D authorization independent of an active
user authentication. Currently, the latter is more common =
in
implementations, and doesn=E2=80=99t make sense for =
browser applications. This
doesn=E2=80=99t mean refresh =
tokens are automatically discounted for all
environments.

How would you tie a refresh =
token to a user session on the AS? This would 
depend on =
the user visiting the AS on a regular basis and using a logout 
button when done. Most people simply close their browser when =
they're done, 
leaving the session open. Also, when making =
a call to the token endpoint to 
refresh the access token, =
there is no way of knowing that this call is 
actually =
initiated by the user, because it's done on a back channel. Perhaps 
this can be solved with DPOP with a keypair per browser, but =
this would really 
complicate the whole solution.

Yes, there =
are still no standard solutions for session keep-alive. There=E2=80=99s =
also not AFAIK a clear solution by the browsers on how to do an implicit =
logout on browser closed, now that browsers may persist sessions =
cookies.

I did pitch something about =
session keep-alive two years ago around this as part of DTVA =
(see https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995=
c32dc7a402dd6e8c47/distributed-token-validity-api.txt ), which =
unfortunately didn=E2=80=99t go anyplace. For pure API apps =
participating in a session keep-alive system, a separate =E2=80=9Cuser =
activity present=E2=80=9D API to periodically poke is probably the best =
way to go. For managed devices running enterprise applications, you can =
just have a screen lock rather than tracking session activity at =
all.

For handling browsers in shared =
user environments which lack non-persistent cookies, you typically have =
to rely on session keep-alive/inactivity timeout and logout (which in =
OAuth would map to a token =
revocation)
 
Given the choice between an 8 hour access token, or a 10 =
minute access token
and a refresh token that will expire =
at a maximum of 8 hours, the second
provides quite a few =
more options to be more secure. (eg. checking backing
user =
session and revocation, checking for updates to client blacklist, the
rotation of the access token, rotating refresh tokens to =
prevent use by
more than one client, expiring access on =
inactivity based on lag in
refreshing, and so on).

I agree with you on this, but the =
spec currently states clearly that the AS 
should not =
issue refresh tokens to an SPA. Do you think this should be changed 
to something like: Authorization servers SHOULD NOT issue =
*offline* refresh 
tokens to browser-based applications. A =
refresh token should be tied to a user 
session on the =
AS.

I would like this language changed as well. It is =
complex due to so little existing token lifetime/policy guidance to =
reference. Previous conversations went a bit circular IMHO because of a =
lack of ground rules.

-DW
=

--Apple-Mail=_196CF112-771E-4FE3-8398-7674474B01A1--


From nobody Wed May  8 13:57: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 D0C2E12022D for ; Wed,  8 May 2019 13:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1lI5hSXU7jC for ; Wed,  8 May 2019 13:57:11 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 E45121200EC for ; Wed,  8 May 2019 13:57:10 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id r76so88140lja.12 for ; Wed, 08 May 2019 13:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i2pcK6FGMbFw1Myr3NgPJaqC9OTGQh4q39gFNoAJruY=; b=VwDjL0SNlE+m02sCYAweXtH/Hy6ufOxD8eQ57/CGDNaD+Oizs/nXdeP5WfSg1UbLkT xc6uaOY3Ieu6Oa+Ew9DZCEdlhGFHv+MSamcLyiSnQiGr8me9G6PvSVb31vvmxm7tDMbw P89yQdjWuOO6aqVyWPKL6zItSUetCm4TruQmmTaLitB06oBV7YpjmgOeuF+X/XWCkVRT ZtkHc9DQjeZStMR31FYqONvT0WgcUuDBDN+brdgS/3n0T4ezxxv5WC9gxRGZMqq8il0c 7jz3LAd/pFWVPPQR7sZ8JDh2ifXbvXcjQdqhNLsipGvMHbL4fC7zm9DFniMGhhwHvcoo AL3w==
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=i2pcK6FGMbFw1Myr3NgPJaqC9OTGQh4q39gFNoAJruY=; b=XbsRXs9yJw+TZXg+i6R7xvIr2KSEBIPxX8OtUhszUCrwVHixyPlW5DJHKiLlZlpPnq /REWOvKX+NmyVhoVRUgiEEgvz4SxKSsATVmPTteXyJyA41zrt/aCV3wDlzIEGSs7s610 IOgoVIngzt9+7i71JtfTOs6k6Q1b4924mV1NDNoI34lqWu7dy5+iYuY8tHzTmxz6eU92 JuUwutMYqwzCZFwirVOGapTYOeRANbg6vK+x0aFjWPj2Tle37otaXpp3hLEZnwf7zhKd /6njRkYGYzY+OZDxMLrNhS2OFkGsHJfTxKm2GhANc/dgY/Sc0+lr5NLFO14ImukdHYN5 VX7g==
X-Gm-Message-State: APjAAAVFsheIJ62u+nXEmW/voykN+mK0CNNhYeduxdYJWevB7iRU7d56 Lmtx6xui7jtdRvt6x9sjjkoh4v3mcleXWeBIcZQYCw==
X-Google-Smtp-Source: APXvYqwgmsHlFc8HtI0UJFYpBu5fFTS84Ymy/CpIAIf6wFL84jWRYgTVXsRSqxqxr7xj34/xFW5LXqhjwcMvQkp+XRA=
X-Received: by 2002:a2e:9a0a:: with SMTP id o10mr12264237lji.67.1557349028117;  Wed, 08 May 2019 13:57:08 -0700 (PDT)
MIME-Version: 1.0
References:     <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>      <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com>    <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com> <77d825e3-1fe8-87a6-90e4-52018f9e8c59@connect2id.com>
In-Reply-To: <77d825e3-1fe8-87a6-90e4-52018f9e8c59@connect2id.com>
From: Vittorio Bertocci 
Date: Wed, 8 May 2019 13:56:56 -0700
Message-ID: 
To: Dominick Baier , Vladimir Dzhuvinov 
Cc: IETF oauth WG , Neil Madden 
Content-Type: multipart/alternative; boundary="0000000000009cd226058866932a"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 20:57:32 -0000

--0000000000009cd226058866932a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One case I have seen back in the AAD days was when a RS wants to authorize
calls from specific clients. In there a client can act both as confidential
and as public client, and in the case of public client the client_id can be
reused by any app really - hence just looking at the client_id in the
incoming token doesn=E2=80=99t prove anything (even assuming that the RS kn=
ows
about the specific client_id, which might not always be the case). AAD had
a special claim saying whether the token was obtained from an authenticated
client, which would solve this particular scenario, but when I suggested
introducing such a claim in the initial proposal discussion that was
strongly discouraged hence I dropped it (tho I think I did add some
comments in the draft).
Having a sub_type (or whatever we=E2=80=99ll name it) would solve this for =
the most
obvious cases (client_crednetials, assertions representing clients).

Dominick mentioned that he uses the absence of sub in app token scenarios
to recognize the incoming tokens as such, hence he might have more
scenarios where the RS needs to be able to tell the difference.

On Wed, May 8, 2019 at 08:06 Vladimir Dzhuvinov 
wrote:

> On 08/05/2019 11:57, Neil Madden wrote:
> > Why does the RS need to know if the subject is a client vs a user? I
> suspect the answers to that question are about as problematic as the RS
> needing to know about the grant type.
>
> I have the exact same question.
>
> Could someone comment on that?
>
> I cannot think of a good reason, unless perhaps for logging / audit.
>
> > I=E2=80=99m not a fan of the client_credentials grant, better off using=
 a real
> service account in most cases. Hopefully no new grants will be added that
> repeat that mistake.
>
> What do you mean by service account in this context?
>
> > Not sure I understand the point about JWT assertion grant type. If you
> use a JWT assertion for client authentication then that=E2=80=99s just th=
e
> client_credentials grant again with a different token auth method, right?
>
> That was my point, that the JWT assertion grant as the client
> credentials grant can be used by a client acting on its own behalf.
>
> > =E2=80=94 Neil
> >
> >> On 8 May 2019, at 08:51, Vladimir Dzhuvinov 
> wrote:
> >>
> >> grant_type would be horrible for RS developers to deal with, just to
> find out whether "sub" effectively =3D=3D "client_id".
> >>
> >> Why?
> >> RS developers will need to learn more OAuth stuff - there are better
> ways to motivate people than that :)
> >> The OAuth grant types are unbounded. If at some point a new grant gets
> devised / implemented, RS developers will need to update the code that ma=
ps
> grant_types to ("sub" effectively =3D=3D "client_id")
> >> We have at least one grant - JWT assertion - where checking the grant
> type is not sufficient to determine if "sub" effectively =3D=3D "client_i=
d"
> >> I believe we should aim for a spec where RS developers shouldn't be
> required to know more than how to process JWTs.
> >>
> >> The AS has all the necessary information to indicate whether "sub"
> effectively =3D=3D "client_id". We don't need to push that logic to the R=
S.
> >> Vladimir
> >>
> >> On 07/05/2019 12:16, Neil Madden wrote:
> >>> Ah, that makes sense. Well, we already add a grant_type claim to our
> JWT-based access tokens, so I=E2=80=99m in favour of that solution :-)
> >>>
> >>>
> >>>> On 7 May 2019, at 09:48, Vittorio Bertocci 
>  wrote:
> >>>>
> >>>> Thanks Neil, one more reason to avoid that.
> >>>> TL;DR,
> >>>> The context is the discussion we had pre-IIW about whether sub shoul=
d
> be included always or only for tokens issued to ROs. Some exiting
> implementations rely on that heuristic.
> >>>> Turns out that 7519 has language suggesting sub should be there for
> both tokens issued for the RO and for apps (via client creds, etc).
> >>>> We don't want to contradict 7519 but we also want to preserve the
> ability for a RS to tell whether an AT was issued via RO auth or app auth=
,
> hence the discussion. Suggestions ranged from adding a grant_type claim
> (Vlad made a convincing argument against it), to relying to the
> client_id=3D=3Dsub heuristic (which i pushed back on) to the introduction=
 of a
> new claim (name TBD given that sub_type is taken already) that can
> explicitly declare whether the token has been issued authenticating th RO
> or via app credentials.
> >>>>
> >>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden   
> > wrote:
> >>>> I wasn=E2=80=99t at IIW so I may be missing some context.
> >>>>
> >>>> There is a potential security issue if the client_id is used as the
> =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If the c=
lient can register
> itself with a self-chosen client_id then it may deliberately chose a
> client_id that matches the user name of a privileged user. An RS that jus=
t
> blindly looks at the =E2=80=9Csub=E2=80=9D claim may then erroneously let=
 the client
> perform privileged actions.
> >>>>
> >>>> Is this the context of the discussion?
> >>>>
> >>>> Given that there are a lot of RSes in existence, many of which are
> probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I
> think the onus is on the AS to ensure that no such ambiguity can arise in
> the first place by ensuring that the space of =E2=80=9Csub=E2=80=9D value=
s for client
> credentials is disjoint with the space for genuine users or by disallowin=
g
> the client_credentials grant altogether.
> >>>>
> >>>> This issue already arises in token introspection though, so maybe
> ought to be mentioned in the OAuth security topics draft rather than
> specific to the JWT AT draft?
> >>>>
> >>>> =E2=80=94 Neil
> >>>>
> >>>>> On 6 May 2019, at 18:32, Vittorio Bertocci  40auth0.com@dmarc.ietf.org 
>   40auth0.com@dmarc.ietf.org>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> thanks for your patience during this month long hiatus, and thanks
> for the comments.
> >>>>> Last week at IIW I had the opportunity to discuss this with many of
> the people on the list. Here's a summary of where the discussion landaed =
on
> the subject of the sub (pun intended).
> >>>>>
> >>>>> - It seems that RFC 7519 has pretty clear language on the use of
> sub- I didn't check it back when we started the discussion. I do agree wi=
th
> the people saying that we shouldn't violate existing specifications, henc=
e
> it looks like we do need to have sub also in the case in which we have
> app-only tokens carrying claims about the app itself. I understand this
> will cause some implementation to break, but unfortunately that's intrins=
ic
> in the process of coming up with a common approach and standards complian=
ce
> is probably one of the strongest reasons to tolerate that.
> >>>>> - That said, I am strongly committed to preserve existing
> functionality. One of the main reasons that was brought up for including
> sub only for user based ATs was to use it as heuristic for telling those
> tokens apart from app-only ones. To that end, Karl MCGuinness suggested
> that we include grant_type as a return claim, which the RS could use to t=
he
> same effect. I find the proposal very clever, and the people at IIW thoug=
ht
> so as well. What you think?
> >>>>> Note, John Bradley observed that in some cases this might lead to
> ambiguous results if an extension grant is used (say an assertion profile=
)
> but that seems like a relatively fringe occurrence.
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <
> hans.zandbelt@zmartzone.eu   hans.zandbelt@zmartzone.eu> > wrote:
> >>>>> I also meant to say that (of course) the JWT standard doesn't say
> that the JWT is supposed to be about the client or about the resource
> owner, hence both are valid
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <
> Michael.Jones@microsoft.com   Michael.Jones@microsoft.com> > wrote:
> >>>>> I get that existing practice is likely to be all over the map, but
> if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reas=
onable to require
> that the claims usage comply with the JWT standards.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                                 --
> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Hans Zandbelt  hans.zandbelt@zmartzone.eu>   hans.zandbelt@zmartzone.eu>>
> >>>>> Sent: Thursday, April 4, 2019 12:59 PM
> >>>>> To: Mike Jones  Michael.Jones@microsoft.com>   Michael.Jones@microsoft.com>>
> >>>>> Cc: George Fletcher  gffletch=3D40aol.com@dmarc.ietf.org> 
> >; Vittorio Bertocci  40auth0.com@dmarc.ietf.org 
>  >;
> IETF oauth WG   oauth@ietf.org> >
> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
> >>>>>
> >>>>>
> >>>>>
> >>>>> the definition of RFC 7519 is actually "petitio principii" and a lo=
t
> of deployments put claims about the Resource Owner in the access token (a=
s
> a Resource Server implementer I've suffered a lot from this)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <
> Michael.Jones@microsoft.com   Michael.Jones@microsoft.com> > wrote:
> >>>>>
> >>>>> I agree with George that the subject of a token must be the
> principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim i=
s for.  Indeed,
> the first sentence of the =E2=80=9Csub=E2=80=9D definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> is:
> >>>>>
> >>>>> The "sub" (subject) claim identifies the principal that is the
> subject of the JWT.
> >>>>>
> >>>>>
> >>>>>
> >>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must compl=
y with the
> definition from RFC 7519.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                                 --
> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: OAuth 
>  > On
> Behalf Of George Fletcher
> >>>>> Sent: Thursday, April 4, 2019 8:51 AM
> >>>>> To: Hans Zandbelt  hans.zandbelt@zmartzone.eu>   hans.zandbelt@zmartzone.eu>>
> >>>>> Cc: Vittorio Bertocci  Vittorio=3D40auth0.com@dmarc.ietf.org> 
> >; IETF oauth WG    >
> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
> >>>>>
> >>>>>
> >>>>>
> >>>>> The more I think about this the more I land in the "No" camp.
> >>>>>
> >>>>> The subject of a token should be the principal of that token. It
> shouldn't matter whether that is a machine, a user, or a device. Trying t=
o
> separate out "humans" as a special class will just make things more
> complicated. If we need a claim to identify the subject is a "human" then
> why not just add that. This doesn't break anything and makes it easy for
> people to detect this case in those use cases where it's required.
> >>>>>
> >>>>> Thanks,
> >>>>> George
> >>>>>
> >>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
> >>>>>
> >>>>> I will argue that in a way such deployments are already broken e.g.
> in the typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for th=
at.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher     gffletch@aol.com>> wrote:
> >>>>>
> >>>>> I agree that this will break a lot of existing flows... especially
> those using any form of the client_credentials flow. In that sense I'm no=
t
> completely on board yet :)
> >>>>>
> >>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
> >>>>>
> >>>>> great summary! this will hurt quite a few existing m2m deployments
> but I do like the rigidness of it all: it is very explicit, cannot
> misinterpreted and thus prevents failure (which is really what Dominick i=
s
> after); I'm on board
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0.com@dmarc.ietf.org 
>  >
> wrote:
> >>>>>
> >>>>> thank you Steinar and everyone else for the comments on this!
> >>>>>
> >>>>> To summarize the situation so far: Dominick, Steinar, Rob, David,
> Nov, Bertrand recommend using sub only for users. Martin would like to ha=
ve
> the sub for app only flows as well. Hans is neutral.
> >>>>>
> >>>>> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more tim=
e
> to comment as well.
> >>>>>
> >>>>> Clarification. If the goal is to be able to apply the logic "if
> there's a sub, it's a user flow", we have to explicitly disallow (MUST NO=
T)
> the use of sub when that's not the case. Are all OK with it?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dave, the suggestion of having explicit typing for app only vs user
> only is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getti=
ng
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem     steinar@udelt.no>> wrote:
> >>>>>
> >>>>> Hi Vittorio, we  (the national federation-gateway for the health
> services in norway - "HelseID")  think his is a really valuable initiativ=
e!
> >>>>>
> >>>>> We also agree with Dominick concerning definition of the "sub" clai=
m.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Steinar
> >>>>>
> >>>>>
> >>>>>
> >>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dbaier@leastprivilege.com   dbaier@leastprivilege.com> >:
> >>>>>
> >>>>> >From an access token consumer (aka API) developer point of view, I
> prefer this logic
> >>>>>
> >>>>>
> >>>>>
> >>>>> "If sub is present - client acts on behalf of a user, if not - not.=
"
> >>>>>
> >>>>>
> >>>>>
> >>>>> Anything more complicated has a potential of going wrong.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com  matake@gmail.com>  )
> wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
> >>>>>
> >>>>> I haven=E2=80=99t seen such implementations, but user-select userna=
me as
> sub, or incremental integer as sub & client_id will be easily collide.
> >>>>>
> >>>>>
> >>>>>
> >>>>> If you can enforce collision resistant IDs between user & client
> instances, it=E2=80=99ll works fine. I feel its overkill though.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>
> >>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci     Vittorio@auth0.com>> wrote:
> >>>>>
> >>>>> Hey Nov, Dominick, Hans-
> >>>>>
> >>>>> thanks for the comments. That was an area I was expecting to cause
> more discussion, and I am glad we are having this opportunity to clarify.
> >>>>>
> >>>>> The current language in the draft traces the etymology of sub to
> OpenID Connect core, hence Dominick observation is on point. However in t=
he
> description I express something in line with 7519, which was in fact my
> intent.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The idea was to provide an identifier of the calling subject that i=
s
> guaranteed to be present in all cases- this would allow an SDK developer =
to
> use the same code for things like lookups and membership checks regardles=
s
> of the nature of the caller (user in a delegated case, app in app-only
> grants). The information to discriminate between user and app callers is
> always available in the token (say, the caller is a user if sub!=3Dclient=
_id,
> where client_id is always guaranteed to be present as well) hence there's
> no loss in expressive power, should that difference be relevant for the
> resource server.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dominick, Hans- I probably missed the security issue you guys are
> thinking of in this case. Of course, if this would introduce a risk I
> completely agree it should be changed- I'd just like to understand better
> the problem. Could you expand it in a scenario/use case to clarify the ri=
sk?
> >>>>>
> >>>>> Nov- playing this back: is the concern that a user and a client
> might have the same identifier within an IDP? When using collision
> resistant IDs, as it is usually the case, that seems to be a remote
> possibility- did you stumble in such scenario in production?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> V.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
> hans.zandbelt@zmartzone.eu   hans.zandbelt@zmartzone.eu> > wrote:
> >>>>>
> >>>>> I believe there are plenty of OAuth 2.0 only use cases out there...
> but nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <
> dbaier@leastprivilege.com   dbaier@leastprivilege.com> > wrote:
> >>>>>
> >>>>> Yes I know - and I think in hindsight it was a mistake to use the
> same claim type for multiple semantics.
> >>>>>
> >>>>>
> >>>>>
> >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are maki=
ng things more
> complicated than they need to be - in my experience almost no-one (that I
> know) does OIDC only - nor OAuth only. They always combine it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> In reality this leads to potential security problems - this spec ha=
s
> the potential to rectify the situation.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dominick
> >>>>>
> >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (
> hans.zandbelt@zmartzone.eu   hans.zandbelt@zmartzone.eu> ) wrote:
> >>>>>
> >>>>> Without agreeing or disagreeing: OIDC does not apply here since it
> is not OAuth and an access token is not an id_token.
> >>>>>
> >>>>> The JWT spec says in
> https://tools.ietf.org/html/rfc7519#section-4.1.2 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2>:
> >>>>>
> >>>>>
> >>>>>
> >>>>> "The "sub" (subject) claim identifies the principal that is the
> >>>>>
> >>>>>    subject of the JWT.  The claims in a JWT are normally statements
> >>>>>
> >>>>>    about the subject.  The subject value MUST either be scoped to b=
e
> >>>>>
> >>>>>    locally unique in the context of the issuer or be globally uniqu=
e.
> >>>>>
> >>>>>    The processing of this claim is generally application specific"
> >>>>>
> >>>>>
> >>>>>
> >>>>> which kind of spells "client" in case of the client credentials
> grant but I also do worry about Resource Servers thinking/acting only in
> terms of users
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <
> dbaier@leastprivilege.com   dbaier@leastprivilege.com> > wrote:
> >>>>>
> >>>>> IMHO the sub claim should always refer to the user - and nothing
> else.
> >>>>>
> >>>>>
> >>>>>
> >>>>> OIDC says:
> >>>>>
> >>>>>
> >>>>>
> >>>>> "Subject - Identifier for the End-User at the Issuer."
> >>>>>
> >>>>>
> >>>>>
> >>>>> client_id should be used to identify clients.
> >>>>>
> >>>>>
> >>>>>
> >>>>> cheers
> >>>>>
> >>>>> Dominick
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com
>    matake@gmail.com>) wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks for the good starting point of standardizing JWT-ized AT.
> >>>>>
> >>>>>
> >>>>>
> >>>>> One feedback.
> >>>>>
> >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, =
end-user and
> client, in this spec.
> >>>>>
> >>>>> It requires those 2 types of identifiers to be unique each other in
> the IdP context.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, =
so that no such
> constraint needed.
> >>>>>
> >>>>>
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>>
> >>>>>
> >>>>> nov
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci  40auth0.com@dmarc.ietf.org  40auth0.com@dmarc.ietf.org>  40auth0.com@dmarc.ietf.org>  40auth0.com@dmarc.ietf.org>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dear all,
> >>>>>
> >>>>> I just submitted a draft describing a JWT profile for OAuth 2.0
> access tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> =
<
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> =
<
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
> >>>>>
> >>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be
> presenting remotely). I look forward for your comments!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Here's just a bit of backstory, in case you are interested in how
> this doc came to be. The trajectory it followed is somewhat unusual.
> >>>>>
> >>>>> Despite OAuth2 not requiring any specific format for ATs, through
> the years I have come across multiple proprietary solution using JWT for
> their access token. The intent and scenarios addressed by those solutions
> are mostly the same across vendors, but the syntax and interpretations in
> the implementations are different enough to prevent developers from reusi=
ng
> code and skills when moving from product to product.
> >>>>> I asked several individuals from key products and services to share
> with me concrete examples of their JWT access tokens (THANK YOU Dominick
> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
> (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
> >>>>> I studied and compared all those instances, identifying
> commonalities and differences.
> >>>>> I put together a presentation summarizing my findings and suggestin=
g
> a rough interoperable profile (slides:
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw=
t_profile_for_ats.pptx
> <
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw=
t_profile_for_ats.pptx>
>  uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_fo=
r_ats.pptx>
>  uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_fo=
r_ats.pptx>
> ) - got early feedback from Filip Skokan on it. Thx Filip!
> >>>>> The presentation was followed up by 1.5 hours of unconference
> discussion, which was incredibly valuable to get tight-loop feedback and
> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
> contributed generously to the discussion. Thank you!!!
> >>>>> Note: if you were at OSW2019, participated in the discussion and
> didn't get credited in the draft, my apologies: please send me a note and
> I'll make things right at the next update.
> >>>>> On my flight back I did my best to incorporate all the ideas and
> feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
> Hannes and above all Brian were all super helpful in negotiating the
> mysterious syntax of the RFC format and submission process.
> >>>>> I was blown away by the availability, involvement and willingness t=
o
> invest time to get things right that everyone demonstrated in the process=
.
> This is an amazing community.
> >>>>>
> >>>>> V.
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Vennlig hilsen
> >>>>>
> >>>>>
> >>>>>
> >>>>> Steinar Noem
> >>>>>
> >>>>> Partner Udelt AS
> >>>>>
> >>>>> Systemutvikler
> >>>>>
> >>>>>
> >>>>>
> >>>>> | steinar@udelt.no  
>  | hei@udelt.no   hei@udelt.no>   | +47 955 21 620 | www.udelt.no <
> http://www.udelt.no/>   |
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>>
> >>>>> --
> >>>>> hans.zandbelt@zmartzone.eu 
>  
> >>>>> ZmartZone IAM - www.zmartzone.eu  <
> http://www.zmartzone.eu/> 
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org  
> 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org 
> >>> https://www.ietf 
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


One case I have seen back in the AAD days was when a=
 RS wants to authorize calls from specific clients. In there a client can a=
ct both as confidential and as public client, and in the case of public cli=
ent the client_id can be reused by any app really - hence just looking at t=
he client_id in the incoming token doesn=E2=80=99t prove anything (even ass=
uming that the RS knows about the specific client_id, which might not alway=
s be the case). AAD had a special claim saying whether the token was obtain=
ed from an authenticated client, which would solve this particular scenario=
, but when I suggested introducing such a claim in the initial proposal dis=
cussion that was strongly discouraged hence I dropped it (tho I think I did=
 add some comments in the draft).
Having a sub=
_type (or whatever we=E2=80=99ll name it) would solve this for the most obv=
ious cases (client_crednetials, assertions representing clients).

Dominick mentioned that he uses t=
he absence of sub in app token scenarios to recognize the incoming tokens a=
s such, hence he might have more scenarios where the RS needs to be able to=
 tell the difference.

On Wed, May 8, 2019 at 08:06 Vladimir Dzhuvi=
nov <vladim=
ir@connect2id.com> wrote:
On=
 08/05/2019 11:57, Neil Madden wrote:

> Why does the RS need to know if the subject is a client vs a user? I s=
uspect the answers to that question are about as problematic as the RS need=
ing to know about the grant type.



I have the exact same question.



Could someone comment on that?



I cannot think of a good reason, unless perhaps for logging / audit.



> I=E2=80=99m not a fan of the client_credentials grant, better off usin=
g a real service account in most cases. Hopefully no new grants will be add=
ed that repeat that mistake.



What do you mean by service account in this context?



> Not sure I understand the point about JWT assertion grant type. If you=
 use a JWT assertion for client authentication then that=E2=80=99s just the=
 client_credentials grant again with a different token auth method, right?<=
br>


That was my point, that the JWT assertion grant as the client

credentials grant can be used by a client acting on its own behalf.



> =E2=80=94 Neil

>

>> On 8 May 2019, at 08:51, Vladimir Dzhuvinov <vladimir@connect2id.com> =
wrote:

>>

>> grant_type would be horrible for RS developers to deal with, just =
to find out whether "sub" effectively =3D=3D "client_id"=
;.

>>

>> Why?

>> RS developers will need to learn more OAuth stuff - there are bett=
er ways to motivate people than that :)

>> The OAuth grant types are unbounded. If at some point a new grant =
gets devised / implemented, RS developers will need to update the code that=
 maps grant_types to ("sub" effectively =3D=3D "client_id&qu=
ot;)

>> We have at least one grant - JWT assertion - where checking the gr=
ant type is not sufficient to determine if "sub" effectively =3D=
=3D "client_id"

>> I believe we should aim for a spec where RS developers shouldn'=
;t be required to know more than how to process JWTs.

>>

>> The AS has all the necessary information to indicate whether "=
;sub" effectively =3D=3D "client_id". We don't need to p=
ush that logic to the RS.

>> Vladimir

>>

>> On 07/05/2019 12:16, Neil Madden wrote:

>>> Ah, that makes sense. Well, we already add a grant_type claim =
to our JWT-based access tokens, so I=E2=80=99m in favour of that solution :=
-)

>>>

>>>

>>>> On 7 May 2019, at 09:48, Vittorio Bertocci <Vittorio@auth0.com> <=
;mailto:Vittorio@au=
th0.com> wrote:

>>>>

>>>> Thanks Neil, one more reason to avoid that.

>>>> TL;DR, 

>>>> The context is the discussion we had pre-IIW about whether=
 sub should be included always or only for tokens issued to ROs. Some exiti=
ng implementations rely on that heuristic.

>>>> Turns out that 7519 has language suggesting sub should be =
there for both tokens issued for the RO and for apps (via client creds, etc=
).

>>>> We don't want to contradict 7519 but we also want to p=
reserve the ability for a RS to tell whether an AT was issued via RO auth o=
r app auth, hence the discussion. Suggestions ranged from adding a grant_ty=
pe claim (Vlad made a convincing argument against it), to relying to the cl=
ient_id=3D=3Dsub heuristic (which i pushed back on) to the introduction of =
a new claim (name TBD given that sub_type is taken already) that can explic=
itly declare whether the token has been issued authenticating th RO or via =
app credentials.

>>>>

>>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.madden@forgerock.c=
om <mailto:neil.madden@forgerock.com> <mailto:neil.madden@forgerock.com> &l=
t;mailto:nei=
l.madden@forgerock.com>> wrote:

>>>> I wasn=E2=80=99t at IIW so I may be missing some context.<=
br>
>>>>

>>>> There is a potential security issue if the client_id is us=
ed as the =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. =
If the client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a privileged u=
ser. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D claim may t=
hen erroneously let the client perform privileged actions.

>>>>

>>>> Is this the context of the discussion?

>>>>

>>>> Given that there are a lot of RSes in existence, many of w=
hich are probably just looking at the =E2=80=9Csub=E2=80=9D claim to identi=
fy the resource owner, I think the onus is on the AS to ensure that no such=
 ambiguity can arise in the first place by ensuring that the space of =E2=
=80=9Csub=E2=80=9D values for client credentials is disjoint with the space=
 for genuine users or by disallowing the client_credentials grant altogethe=
r.

>>>>

>>>> This issue already arises in token introspection though, s=
o maybe ought to be mentioned in the OAuth security topics draft rather tha=
n specific to the JWT AT draft?

>>>>

>>>> =E2=80=94 Neil

>>>>

>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittori=
o=3D40auth0=
.com@dmarc.ietf.org <mailto:Vittorio=3D40auth0.com@dmarc.ietf.org> <mailto:Vittorio=3D40auth0.com@dmarc.ietf.org> <mai=
lto:Vittorio=3D40auth0.com@dmarc.iet=
f.org>> wrote:

>>>>>

>>>>> Hi all,

>>>>> thanks for your patience during this month long hiatus=
, and thanks for the comments.

>>>>> Last week at IIW I had the opportunity to discuss this=
 with many of the people on the list. Here's a summary of where the dis=
cussion landaed on the subject of the sub (pun intended).

>>>>>

>>>>> - It seems that RFC 7519 has pretty clear language on =
the use of sub- I didn't check it back when we started the discussion. =
I do agree with the people saying that we shouldn't violate existing sp=
ecifications, hence it looks like we do need to have sub also in the case i=
n which we have app-only tokens carrying claims about the app itself. I und=
erstand this will cause some implementation to break, but unfortunately tha=
t's intrinsic in the process of coming up with a common approach and st=
andards compliance is probably one of the strongest reasons to tolerate tha=
t.

>>>>> - That said, I am strongly committed to preserve exist=
ing functionality. One of the main reasons that was brought up for includin=
g sub only for user based ATs was to use it as heuristic for telling those =
tokens apart from app-only ones. To that end, Karl MCGuinness suggested tha=
t we include grant_type as a return claim, which the RS could use to the sa=
me effect. I find the proposal very clever, and the people at IIW thought s=
o as well. What you think?

>>>>> Note, John Bradley observed that in some cases this mi=
ght lead to ambiguous results if an extension grant is used (say an asserti=
on profile) but that seems like a relatively fringe occurrence.

>>>>>

>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandbelt@zm=
artzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.e=
u> <mailto:hans.zandbelt@zmartzone.eu>> wrote:

>>>>> I also meant to say that (of course) the JWT standard =
doesn't say that the JWT is supposed to be about the client or about th=
e resource owner, hence both are valid

>>>>>

>>>>> Hans.

>>>>>

>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@mic=
rosoft.com <mailto:Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsof=
t.com> <mailto:Michael.Jones@microsoft.com>> wrote:

>>>>> I get that existing practice is likely to be all over =
the map, but if we=E2=80=99re to create a JWT access token standard, it=E2=
=80=99s reasonable to require that the claims usage comply with the JWT sta=
ndards.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> From: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto=
:hans.zandb=
elt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@z=
martzone.eu>> 

>>>>> Sent: Thursday, April 4, 2019 12:59 PM

>>>>> To: Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jone=
s@microsoft.com> <mailto:Michael.Jones@microsoft.com> <mailto:Michael.Jones=
@microsoft.com>>

>>>>> Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org <=
;mailto:gffletch=3D40aol.com@dmarc.iet=
f.org> <mailto:40aol.com@dmarc...ietf.org> <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci =
<Vittorio=3D40auth0.com@dmarc.ietf.org <mailto:Vittorio=3D40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.=
ietf.org> <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <=
oauth@ietf.org <=
mailto:oauth@ietf.org> <mailto:oauth=
@ietf.org> <mailto:oauth@ietf.org>>

>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-to=
ken-jwt-00

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> the definition of RFC 7519 is actually "petitio p=
rincipii" and a lot of deployments put claims about the Resource Owner=
 in the access token (as a Resource Server implementer I've suffered a =
lot from this)

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Hans.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@mic=
rosoft.com <mailto:Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsof=
t.com> <mailto:Michael.Jones@microsoft.com>> wrote:

>>>>>

>>>>> I agree with George that the subject of a token must b=
e the principal of that token.=C2=A0 That what the JWT =E2=80=9Csub=E2=80=
=9D claim is for.=C2=A0 Indeed, the first sentence of the =E2=80=9Csub=E2=
=80=9D definition at https://tools.ietf.org/html/rf=
c7519#section-4.1.2 <https://tools.ietf.org/=
html/rfc7519#section-4.1.2> <https://tool=
s.ietf.org/html/rfc7519#section-4.1.2> <h=
ttps://tools.ietf.org/html/rfc7519#section-4.1.2> is:

>>>>>

>>>>> The "sub" (subject) claim identifies the pri=
ncipal that is the subject of the JWT.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usa=
ge must comply with the definition from RFC 7519.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>=
 <mailto:oau=
th-bounces@ietf.org> <mailto:oauth-bounces@ietf.org>> On Behalf Of Geo=
rge Fletcher

>>>>> Sent: Thursday, April 4, 2019 8:51 AM

>>>>> To: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:<=
a href=3D"mailto:hans.zandbelt@zmartzone.eu" target=3D"_blank">hans.zandbel=
t@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zma=
rtzone.eu>>

>>>>> Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org <mailto:Vittorio=3D=
40auth0.com=
@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmar=
c.ietf.org>>; IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>><=
br>
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-to=
ken-jwt-00

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> The more I think about this the more I land in the &qu=
ot;No" camp.

>>>>>

>>>>> The subject of a token should be the principal of that=
 token. It shouldn't matter whether that is a machine, a user, or a dev=
ice. Trying to separate out "humans" as a special class will just=
 make things more complicated. If we need a claim to identify the subject i=
s a "human" then why not just add that. This doesn't break an=
ything and makes it easy for people to detect this case in those use cases =
where it's required.

>>>>>

>>>>> Thanks,

>>>>> George

>>>>>

>>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:

>>>>>

>>>>> I will argue that in a way such deployments are alread=
y broken e.g. in the typical use case of onboarding client accounts in the =
same directory/OU/namespace as user accounts and we don't need to cater=
 for that.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Hans.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com &l=
t;mailto:gffletch@aol=
.com> <mailto:gffletch@aol.com> <mailto:gffletch@aol.com>> wrote:

>>>>>

>>>>> I agree that this will break a lot of existing flows..=
. especially those using any form of the client_credentials flow. In that s=
ense I'm not completely on board yet :)

>>>>>

>>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:

>>>>>

>>>>> great summary! this will hurt quite a few existing m2m=
 deployments but I do like the rigidness of it all: it is very explicit, ca=
nnot misinterpreted and thus prevents failure (which is really what Dominic=
k is after); I'm on board

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Hans.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <=
Vittorio=3D=
40auth0.com@dmarc.ietf.org <mailto:Vittorio=3D40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.=
org> <mailto:40auth0.com@dmarc.ietf.org>> wrote:

>>>>>

>>>>> thank you Steinar and everyone else for the comments o=
n this!

>>>>>

>>>>> To summarize the situation so far: Dominick, Steinar, =
Rob, David, Nov, Bertrand recommend using sub only for users. Martin would =
like to have the sub for app only flows as well. Hans is neutral.

>>>>>

>>>>> That does sound like the sub as user has more consensu=
s, tho before changing it I'd wait for the people currently at IETF104 =
to have more time to comment as well.

>>>>>

>>>>> Clarification. If the goal is to be able to apply the =
logic "if there's a sub, it's a user flow", we have to ex=
plicitly disallow (MUST NOT) the use of sub when that's not the case. A=
re all OK with it?

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Dave, the suggestion of having explicit typing for app=
 only vs user only is interesting! For the purpose of putting together an i=
nteroperable profile, tho, I would suggest we table it for v1 in the intere=
st of getting to something easy to adopt (hence with small delta vs existin=
g implementations) faster.=C2=A0 =C2=A0 =C2=A0

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no <m=
ailto:steinar@udelt.n=
o> <mailto:=
steinar@udelt.no> <mailto:steinar@udelt.no>> wrote:

>>>>>

>>>>> Hi Vittorio, we=C2=A0 (the national federation-gateway=
 for the health services in norway - "HelseID")=C2=A0 think his i=
s a really valuable initiative!

>>>>>

>>>>> We also agree with Dominick concerning definition of t=
he "sub" claim.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> <mvh>Steinar</mvh>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <=
dbaier@least=
privilege.com <mailto:dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com=
> <mailto:dbaier@leastprivilege.com>>:

>>>>>

>>>>> >From an access token consumer (aka API) developer =
point of view, I prefer this logic

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> "If sub is present - client acts on behalf of a u=
ser, if not - not."

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Anything more complicated has a potential of going wro=
ng.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:=
matake@gmail.com&=
gt; <mailto:matake=
@gmail.com> <mailto:matake@gmail.com>) wrote:

>>>>>

>>>>> Hi Vittorio,

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Yeah, I=E2=80=99m concerning user & client ids col=
lision.

>>>>>

>>>>> I haven=E2=80=99t seen such implementations, but user-=
select username as sub, or incremental integer as sub & client_id will =
be easily collide.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> If you can enforce collision resistant IDs between use=
r & client instances, it=E2=80=99ll works fine. I feel its overkill tho=
ugh.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Sent from my iPhone

>>>>>

>>>>>

>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com &l=
t;mailto:Vittorio@a=
uth0.com> <mailto:Vittorio@auth0.com> <mailto:Vittorio@auth0.com>> wrote:

>>>>>

>>>>> Hey Nov, Dominick, Hans-

>>>>>

>>>>> thanks for the comments. That was an area I was expect=
ing to cause more discussion, and I am glad we are having this opportunity =
to clarify.

>>>>>

>>>>> The current language in the draft traces the etymology=
 of sub to OpenID Connect core, hence Dominick observation is on point. How=
ever in the description I express something in line with 7519, which was in=
 fact my intent.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> The idea was to provide an identifier of the calling s=
ubject that is guaranteed to be present in all cases- this would allow an S=
DK developer to use the same code for things like lookups and membership ch=
ecks regardless of the nature of the caller (user in a delegated case, app =
in app-only grants). The information to discriminate between user and app c=
allers is always available in the token (say, the caller is a user if sub!=
=3Dclient_id, where client_id is always guaranteed to be present as well) h=
ence there's no loss in expressive power, should that difference be rel=
evant for the resource server.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Dominick, Hans- I probably missed the security issue y=
ou guys are thinking of in this case. Of course, if this would introduce a =
risk I completely agree it should be changed- I'd just like to understa=
nd better the problem. Could you expand it in a scenario/use case to clarif=
y the risk?

>>>>>

>>>>> Nov- playing this back: is the concern that a user and=
 a client might have the same identifier within an IDP? When using collisio=
n resistant IDs, as it is usually the case, that seems to be a remote possi=
bility- did you stumble in such scenario in production?

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Thanks

>>>>>

>>>>> V. 

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@z=
martzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.=
eu> <mailto:hans.zandbelt@zmartzone.eu>> wrote:

>>>>>

>>>>> I believe there are plenty of OAuth 2.0 only use cases=
 out there... but nevertheless I agree with the potential confusion and thu=
s security problems arising from that (though one may argue the semantics a=
re the same).

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Hans.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastpri=
vilege.com <mailto:dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com>> wrote:

>>>>>

>>>>> Yes I know - and I think in hindsight it was a mistake=
 to use the same claim type for multiple semantics.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D argum=
ents are making things more complicated than they need to be - in my experi=
ence almost no-one (that I know) does OIDC only - nor OAuth only. They alwa=
ys combine it.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> In reality this leads to potential security problems -=
 this spec has the potential to rectify the situation.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Dominick

>>>>>

>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmar=
tzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu<=
/a>> <mailto:hans.zandbelt@zmartzone.eu>) wrote:

>>>>>

>>>>> Without agreeing or disagreeing: OIDC does not apply h=
ere since it is not OAuth and an access token is not an id_token.

>>>>>

>>>>> The JWT spec says in https://t=
ools.ietf.org/html/rfc7519#section-4.1.2 <ht=
tps://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2> <https://tools.ietf.org/html/rfc7519#section-4.1.2&g=
t;:

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> "The "sub" (subject) claim identifies t=
he principal that is the

>>>>>

>>>>>=C2=A0 =C2=A0 subject of the JWT.=C2=A0 The claims in a=
 JWT are normally statements

>>>>>

>>>>>=C2=A0 =C2=A0 about the subject.=C2=A0 The subject valu=
e MUST either be scoped to be

>>>>>

>>>>>=C2=A0 =C2=A0 locally unique in the context of the issu=
er or be globally unique.

>>>>>

>>>>>=C2=A0 =C2=A0 The processing of this claim is generally=
 application specific"

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> which kind of spells "client" in case of the=
 client credentials grant but I also do worry about Resource Servers thinki=
ng/acting only in terms of users

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Hans.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastpri=
vilege.com <mailto:dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com>> wrote:

>>>>>

>>>>> IMHO the sub claim should always refer to the user - a=
nd nothing else.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> OIDC says:

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> "Subject - Identifier for the End-User at the Iss=
uer."

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> client_id should be used to identify clients.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> cheers

>>>>>

>>>>> Dominick

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com <mailto=
:matake@gmail.com=
> <mailto:matak=
e@gmail.com> <mailto:matake@gmail.com>) wrote:

>>>>>

>>>>> Hi Vittorio,

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Thanks for the good starting point of standardizing JW=
T-ized AT.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> One feedback.

>>>>>

>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of=
 identifier, end-user and client, in this spec.

>>>>>

>>>>> It requires those 2 types of identifiers to be unique =
each other in the IdP context.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-leg=
ged context, so that no such constraint needed.

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> thanks

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> nov

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittor=
io.bertocci=3D40auth0.com@dmarc.ietf.org <mailto:vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> &l=
t;mailto:vittorio.be=
rtocci=3D40auth0.com@dmarc.ietf.org> <mailto:vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>=
> wrote:

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Dear all,

>>>>>

>>>>> I just submitted a draft describing a JWT profile for =
OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access=
-token-jwt/ <https://d=
atatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <=
https://datatracker.ietf.org/=
doc/draft-bertocci-oauth-access-token-jwt/> <https://datatracker.ietf.org/doc/draft-bertocci-o=
auth-access-token-jwt/>.

>>>>>

>>>>> I have a slot to discuss this tomorrow at IETF 104 (I&=
#39;ll be presenting remotely). I look forward for your comments!

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Here's just a bit of backstory, in case you are in=
terested in how this doc came to be. The trajectory it followed is somewhat=
 unusual.

>>>>>

>>>>> Despite OAuth2 not requiring any specific format for A=
Ts, through the years I have come across multiple proprietary solution usin=
g JWT for their access token. The intent and scenarios addressed by those s=
olutions are mostly the same across vendors, but the syntax and interpretat=
ions in the implementations are different enough to prevent developers from=
 reusing code and skills when moving from product to product.

>>>>> I asked several individuals from key products and serv=
ices to share with me concrete examples of their JWT access tokens (THANK Y=
OU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel D=
obalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!)=
.

>>>>> I studied and compared all those instances, identifyin=
g commonalities and differences. 

>>>>> I put together a presentation summarizing my findings =
and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.=
de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx &=
lt;ht=
tps://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_pr=
ofile_for_ats.pptx> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bert=
occi_-_a_jwt_profile_for_ats.pptx> <https://sec..uni-stuttgart.de/_media/events/osw=
2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early fee=
dback from Filip Skokan on it. Thx Filip!

>>>>> The presentation was followed up by 1.5 hours of uncon=
ference discussion, which was incredibly valuable to get tight-loop feedbac=
k and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino=
v, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and =
contributed generously to the discussion. Thank you!!!

>>>>> Note: if you were at OSW2019, participated in the disc=
ussion and didn't get credited in the draft, my apologies: please send =
me a note and I'll make things right at the next update.

>>>>> On my flight back I did my best to incorporate all the=
 ideas and feedback in a draft, which will be discussed at IETF104 tomorrow=
. Rifaat, Hannes and above all Brian were all super helpful in negotiating =
the mysterious syntax of the RFC format and submission process.

>>>>> I was blown away by the availability, involvement and =
willingness to invest time to get things right that everyone demonstrated i=
n the process. This is an amazing community. 

>>>>>

>>>>> V.

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>>=C2=A0 

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> Vennlig hilsen

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> Steinar Noem

>>>>>

>>>>> Partner Udelt AS

>>>>>

>>>>> Systemutvikler

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> | steinar@udelt.no <mailto:steinar@udelt.no> <mailto:steinar@udelt..no> <mailto:steinar@udelt..no> | hei@udelt.no <mailto:hei@udelt.no> <mail=
to:hei@udelt.no> &=
lt;mailto:hei@udelt.no>=C2=A0 | +47 955 21 620 | www.udelt.no <http://www.udelt.no/> <<=
a href=3D"http://www.udelt.no/" rel=3D"noreferrer" target=3D"_blank">http:/=
/www.udelt.no/> <http://www.udelt.no/> | 

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>>=C2=A0 

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>>>=C2=A0 

>>>>>

>>>>>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>>=C2=A0 

>>>>>

>>>>>

>>>>>

>>>>>=C2=A0 

>>>>>

>>>>> --

>>>>>

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>>

>>>>> -- 

>>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu&g=
t; <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
>>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmart=
zone.eu/> <http://www.zmartzone.eu/> <http://www.zmartzon=
e.eu/>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th> <https://www.ietf.org/mailman/listinfo/oau=
th>

>>>

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org <mailto:OAu=
th@ietf.org>

>>> https://www.ietf <https://www.ietf/>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org=


>> https://www.ietf.org/mailman/listinfo/oauth<=
br>
>

-- 

Vladimir Dzhuvinov





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






--0000000000009cd226058866932a--


From nobody Thu May  9 01:04: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 31E531200A4 for ; Thu,  9 May 2019 01:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSHubsqGhfvm for ; Thu,  9 May 2019 01:04:00 -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 0D67A120006 for ; Thu,  9 May 2019 01:04:00 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id m4so1176780edd.8 for ; Thu, 09 May 2019 01:03:59 -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=imnk9B6dzPe/FEk/vgfKJ4oqDVkmhh6fwDdi2s/EdDw=; b=PIFQrbnPF0vYAZ+nz8NeJ3HKku/Xh8zW6kkDHjslCR88fXWaq+143e3wuwzOH9v8tO iN6OMczDTDZjaINg6xJ6D1BEdmaDikGqqh0wO1cWPZllKgqNz9w/yZ1m6a5B9bqdcF80 92MEA4fNxMWReb3kYBTItSiry1YlNtQ7XEtpgI7DsyrOscRalso8UgP1DXKvcAYGV1/2 97lLPENZ2ciSyr/GngR8EyNY2X1uQdBCCcH2+y8+jtiTkLfMb0HDU98fK9IKrbeVxkpn wiqfV4OhJyzsY2SNv5IargKiVVT6Ml9e22HgrXTQT+0M9vL/ZhhGKLRKq8fjeifKAIv4 MmjA==
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=imnk9B6dzPe/FEk/vgfKJ4oqDVkmhh6fwDdi2s/EdDw=; b=rqO7t6UZ+jusdUbl6j2z0heQEBc2I63YfaTZk6KBZW2pqT/vkMGPHxm6cR2g+KHnY9 Ryn9KVb7+HqjTvulA1IvXhSjQxRq6wx2OARdAR94lGLAJhivYkE3TA/bdThXY7+/5yoi S66tsL3z5SZBW7qIyq+idMJ7b94ZzbC07EBOLHwWcZZaE7ywR4OvZMZHORAnwyVCpp24 XZWZBA7CS1Rfh9HLy5kAH+1r4RSdIQCn8fIUpl1jSrHjLUsAuZiMjIC272RZCfUvgWJX 3ey1tXqtS/2z3S+8S5BJ6HTLhJGPKwnbRuDtaT0LTEEnRloNuq48MXHQ1e9k8Vb1LgvN UbZw==
X-Gm-Message-State: APjAAAVMONYec/EWUxz6MbXXrD7mZx/qtSTbh4TE4SwBkoisnhbbIdVt 72ZVLfQR6C7SoTxGajRQPaDkUXw8v7U=
X-Google-Smtp-Source: APXvYqwOF1PKMpp9sQXxK+/ywRZHECLXJlUYLUbM4m2Bi7qEeAFxT+mOp77HBwEyq3MIzpLYPJlLDA==
X-Received: by 2002:a17:906:314b:: with SMTP id e11mr1956934eje.259.1557389038161;  Thu, 09 May 2019 01:03:58 -0700 (PDT)
Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id o47sm385722edc.37.2019.05.09.01.03.56 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 May 2019 01:03:57 -0700 (PDT)
From: Emond Papegaaij 
To: oauth@ietf.org
Date: Thu, 09 May 2019 10:03:52 +0200
Message-ID: <8031200.pNvfooFNdc@papegaaij>
In-Reply-To: <1750829.ebW1fUBprn@papegaaij>
References: <4223569.5sG2vptK2V@papegaaij>  <1750829.ebW1fUBprn@papegaaij>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [OAUTH-WG] Token Exchange status and Resource Indicators
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, 09 May 2019 08:04:02 -0000

(reposting this to the list, due to an error on my part the mail got sent 
privately)
> > > > - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'?
> > > 
> > > No, that's beyond it's current scope. And it is well past last call in
> > > the WG. But note that a logical identifier can be used as the value
> > > of the resource parameter.
> > 
> > Would you recommend to put the AWS entity id in the resource parameter
> > on the authorize request then?
> 
> Yeah, that seems reasonable.

The more I think about this solution, the more I get convinced it is not going 
to work in the general case. The main problem in this is that the resource 
parameter has a strict format: it MUST be an absolute URI. This works for SAML 
entity id's and OIDC issuers, but it will not work in the general form of a 
client identifier. Many of the client identifiers we use are UUIDs. There is no 
way to put this in the resource parameter on the authorize request. The 
library we use to implement our OAuth2 endpoints is very strict in this.

Best regards,
Emond Papegaaij



From nobody Thu May  9 01:19:48 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 CE66712011F for ; Thu,  9 May 2019 01:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRXu6_iy4FTd for ; Thu,  9 May 2019 01:19:44 -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 BF5341202E5 for ; Thu,  9 May 2019 01:19:42 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id j12so478125eds.7 for ; Thu, 09 May 2019 01:19:42 -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=9fFlpHHhxRxius/jK2vFnUHEZdMeUhM92cI0YPtJP2Q=; b=DoFlEHojoqKKLIHjmRXrUc9eQbLvVwjeCl2kGt3et00QY9DGyNy+L8tQ5e5VGOU2+H kOTzVtPYyX34AFg0KG9tpXqet/nsnIyRkFK0sw2BadUbxS6jHjn2ULAy7pvIvpuWGPCA +zWs5iVLM/INiAGdc3ebZ91pq/byHFO/smXWu7yf84xweFXHlGNbDo5r+9REE9VsKGCt VQppu1roLhuajdTkjpshHGV/N6rKQn/p05Kc/OAd96AxmJfMA0GfnCm7h+FqCvjoG2VX QdTv9erI1YNorPPqeVGuJJeOjkxvhPvIGHFfUIEcR1w0LWZUjpFV2Tqb5zMBt1wO8oRi fEkA==
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=9fFlpHHhxRxius/jK2vFnUHEZdMeUhM92cI0YPtJP2Q=; b=Z/NjuOFI9HeDNSMEArNEVlPuNV1+c2eZvVYt8nCr33SjyOUuqx1kEAKHqZy86PDQAx vyascB+o/GpSEV9/zLQtfBxVaBRZlu0YnLxfhngU7fBlM/DObNF8nGNyrRtJqmw+Zue1 d/uLN+zok1kUofHesbpxWl/kFQqDm5NNQ3uWMLGz2cVaushAbu+aXMjR4MngwbqYITlE nhUaISqYK2SYmLg9KiaYITuQ8wPPDurXZslY9AE94vcwhkXapsgqCidGrDPQPIhuFUH/ qULj6u5qUpsTvHUHbEzedaJqLJlCAFXDRtYvn0kA8kwOlaXNsCUmHex71BOFsW++2ZLn rlfQ==
X-Gm-Message-State: APjAAAX4oE656JR/eDWMIGzLmtZStscHzN6P2bbMAgbKeaNn/86X5GFf kP1qcHuC1/t7bYZU/32Iodnq3whqjpU=
X-Google-Smtp-Source: APXvYqzIAZSVNIejfxzeP9WSbDqXkr/wG1Ib8wVC+C3dSHTVVl4Pn9X51tZW3WrWVb7g0bphfLZ+vg==
X-Received: by 2002:a17:906:3ed1:: with SMTP id d17mr2075661ejj.221.1557389980423;  Thu, 09 May 2019 01:19:40 -0700 (PDT)
Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id dc1sm216862ejb.14.2019.05.09.01.19.39 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 May 2019 01:19:39 -0700 (PDT)
From: Emond Papegaaij 
To: oauth@ietf.org
Date: Thu, 09 May 2019 10:19:38 +0200
Message-ID: <1957487.Czm0dUuOv6@papegaaij>
In-Reply-To: <28AF8EF5-9CCF-44EB-B028-1FCFA892ECEB@alkaline-solutions.com>
References: <11125817.AKI43N3Yza@papegaaij> <2125064.3GpWMRz4CO@papegaaij> <28AF8EF5-9CCF-44EB-B028-1FCFA892ECEB@alkaline-solutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps
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, 09 May 2019 08:19:47 -0000

On woensdag 8 mei 2019 22:55:47 CEST David Waite wrote:
> > How would you tie a refresh token to a user session on the AS? This wou=
ld
> > depend on the user visiting the AS on a regular basis and using a logout
> > button when done. Most people simply close their browser when they're
> > done,
> > leaving the session open. Also, when making a call to the token endpoint
> > to
> > refresh the access token, there is no way of knowing that this call is
> > actually initiated by the user, because it's done on a back channel.
> > Perhaps this can be solved with DPOP with a keypair per browser, but th=
is
> > would really complicate the whole solution.
>=20
> Yes, there are still no standard solutions for session keep-alive. There=
=E2=80=99s
> also not AFAIK a clear solution by the browsers on how to do an implicit
> logout on browser closed, now that browsers may persist sessions cookies.
>=20
> I did pitch something about session keep-alive two years ago around this =
as
> part of DTVA (see
> https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402=
dd
> 6e8c47/distributed-token-validity-api.txt
>  d6e8c47/distributed-token-validity-api.txt> ), which unfortunately didn=
=E2=80=99t go
> anyplace. For pure API apps participating in a session keep-alive system,=
 a
> separate =E2=80=9Cuser activity present=E2=80=9D API to periodically poke=
 is probably the
> best way to go. For managed devices running enterprise applications, you
> can just have a screen lock rather than tracking session activity at all.

This spec seems to make it possible to keep an active session. However, it =
is=20
bound to OIDC, which will not work in our case. Many of the application we =
are=20
IdP for use SAML. The spec relies on all parties communicating session=20
activity. For now, OIDC session management seems to be the best way to go.

> >> Given the choice between an 8 hour access token, or a 10 minute access
> >> token and a refresh token that will expire at a maximum of 8 hours, the
> >> second provides quite a few more options to be more secure. (eg.
> >> checking backing user session and revocation, checking for updates to
> >> client blacklist, the rotation of the access token, rotating refresh
> >> tokens to prevent use by more than one client, expiring access on
> >> inactivity based on lag in refreshing, and so on).
> >=20
> > I agree with you on this, but the spec currently states clearly that the
> > AS
> > should not issue refresh tokens to an SPA. Do you think this should be
> > changed to something like: Authorization servers SHOULD NOT issue
> > *offline* refresh tokens to browser-based applications. A refresh token
> > should be tied to a user session on the AS.
>=20
> I would like this language changed as well. It is complex due to so little
> existing token lifetime/policy guidance to reference. Previous
> conversations went a bit circular IMHO because of a lack of ground rules.

I can understand. This also highly depend on your use case. Something that=
=20
might work for one application might be totally inappropriate for another.

Best regards,
Emond Papegaaij




From nobody Thu May  9 09:15:24 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 B653612006B for ; Thu,  9 May 2019 09:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbwrnvME_yr5 for ; Thu,  9 May 2019 09:15:18 -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 1EEB612000E for ; Thu,  9 May 2019 09:15:18 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id w12so3899747wrp.2 for ; Thu, 09 May 2019 09:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tfCdKJopZDtQAJmBv8vy4YiPuS9tUSuFapC9Rj5f+0M=; b=BSRdYXhJEetawxrvDHhMi8RoK6LufZtSF9b2asDbAvzuRu4kxUVDfIm+Sxie8GodHr CXpfTt4EOuwVy061Lv1ciOWVmT/HRQjIiHK5lgGqO57DL61fcIfy3jeKfGaZt1v7Z9lC rkSpdvLrygV9q5+66VSUB+adp6+F+MBG7b7/U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tfCdKJopZDtQAJmBv8vy4YiPuS9tUSuFapC9Rj5f+0M=; b=W8VyOknVpDPP1tzrkKMZXYaPX+MI2N8jZYN/ozeT1ff6lnyv2FMZzawGG4jR3UPUct nKCUgRQ9xqmfnUT9U5U1EGmaxIicovujybJdGu+KxxplWa62ij3XV8t11PzhArdta546 5h0HTZEVhKQmWdNoGP/gBVboLIpsUxeHHY8rpWOGxxKyiAQHdmSh9jXWax6RVGpAYka9 MOsV32tgT1hwXF3vBh0gEtK5yFScfxQBzA6f6su0T1jLBq+nDp1o/9pBnQRY2V0oGVWO d+z3Q31W1ExSaSOqSs8jnP40aNJGAPKnvLZiXY8DEiX20E5kG217eRrb2REPdrWlskwE FIEA==
X-Gm-Message-State: APjAAAWC8GjQ0gHHqqKMHQWFAm7HGibv4BX2AIiaMQpXDbH0ZUu0lUEy Lj7thCKGLdg5Mj3hlHaOzbdyxw==
X-Google-Smtp-Source: APXvYqz9bH/jaouo2dLUSCW8ZSD3Q3GO9aAgk6hAFODAEi6yMEluSB8XJdwVL3iNgxjVcOSwGxouzw==
X-Received: by 2002:adf:c503:: with SMTP id q3mr3995249wrf.263.1557418516449;  Thu, 09 May 2019 09:15:16 -0700 (PDT)
Received: from [192.168.1.64] (29.87.75.194.dyn.plus.net. [194.75.87.29]) by smtp.gmail.com with ESMTPSA id b2sm1648833wma.41.2019.05.09.09.15.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2019 09:15:15 -0700 (PDT)
From: Neil Madden 
Message-Id: <6F0B4144-C0E9-48E4-8BE0-0B305FC32B32@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B360F635-F8B3-48D5-AE8B-1459DE246438"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 9 May 2019 17:15:14 +0100
In-Reply-To: <3B27C5F4-3D67-4F37-9522-0883F0D18B85@forgerock.com>
Cc: IETF oauth WG 
To: Vittorio Bertocci 
References:   <3B27C5F4-3D67-4F37-9522-0883F0D18B85@forgerock.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: [OAUTH-WG] Public key authenticated encryption for JWTs [Was Re: JWT ATs and authenticated encryption]
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, 09 May 2019 16:15:22 -0000

--Apple-Mail=_B360F635-F8B3-48D5-AE8B-1459DE246438
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

OK, I have put together a (very) rough first draft here - =
https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ =


I have an implementation so I will try to find some time to generate =
some test vectors, but essentially you do exactly the same as for =
ECDH-ES but you derive a second shared secret between the sender=E2=80=99s=
 static private key and the recipient=E2=80=99s static private key, then =
concatenate them together and run it through Concat-KDF as before.

I also have a GitHub for the draft =
https://github.com/NeilMadden/jose-ecdh-1pu =
 that has a README with =
some more informal discussion.

I think this is potentially a very useful mode for JWT access tokens in =
particular where you want to encrypt and authenticate the AT to pass =
through the client to the RS without the overhead of nested =
signed+encrypted JWTs or the security risks of shared secrets.

Cheers,

Neil

> On 27 Mar 2019, at 13:51, Neil Madden  =
wrote:
>=20
> Yes - a separate doc. Given that it is potentially useful in the =
context of OAuth, it might be something that the OAuth WG could =
consider, given that the JOSE WG is disbanded. I=E2=80=99ll see if I can =
find some time to put a draft together. (In markdown now that my mind =
has been blown that I don=E2=80=99t have to do everything in XML!)
>=20
>> On 26 Mar 2019, at 16:50, Vittorio Bertocci  =
wrote:
>>=20
>> Hi Neil,
>> thanks! This does sound very interesting. Just to clarify, you would =
document this in a separate doc extending JOSE?
>> We could then mention it from the JWT AT profile, whihc would remain =
lightweight and implementation independent.
>> thanks
>> V.
>>=20
>> On Tue, Mar 26, 2019 at 3:11 AM Neil Madden =
 wrote:
>> There was a brief discussion at OSW about signing vs encryption for =
JWT-based access tokens. I think it was Brian Campbell that pointed out =
that you often want authenticated encryption rather than signing, and I =
agree with this.
>>=20
>> Currently JOSE only supports authenticated encryption for symmetric =
cryptography, which means that the AS and RS must agree a shared secret =
key beforehand. (Or else the RS uses the token introspection endpoint =
and doesn=E2=80=99t decrypt the token itself). Symmetric cryptography is =
less than ideal when the AS and RS are in separate trust boundaries =
(e.g., different companies).
>>=20
>> There are actually ways to do *public key* authenticated encryption, =
but JOSE doesn=E2=80=99t support them yet. I wrote a 3-part blog series =
about this recently [1], but I=E2=80=99ll summarise the tl;dr version =
here. I think for JWT-based access tokens that contain identity =
assertions, this is probably what you want in most cases as it provides =
both confidentiality and authenticity without needing a bulky nested =
signed-then-encrypted JWT. Is this something people would be interested =
in, if I propose a draft?
>>=20
>> Details:
>>=20
>> The basic idea is to introduce one or more variants on ECDH-ES that =
provide sender authentication. The most straightforward is to use =
ECDH-SS =E2=80=94 i.e., Diffie-Hellman between two static key pairs, one =
for the sender and one for the recipient, with no ephemeral keys. This =
provides authenticated encryption so long as the content encryption =
method is authenticated (which they all are in JOSE). But it has a =
number of security downsides, which I describe in more detail in the =
blog. (It might be useful in some IoT scenarios though).
>>=20
>> The better variant is to instead do ECDH-ESSS. That is, we generate a =
random ephemeral key pair and do an agreement with the recipient=E2=80=99s=
 static public key, just like in ECDH-ES, but then we do another key =
agreement between the sender=E2=80=99s static private key and the =
recipient=E2=80=99s static private key. We then concatenate the two =
shared secrets and feed them into ConcatKDF just like you would for =
ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass =
unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is =
also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the =
Noise protocol framework [3].
>>=20
>> To spell it out, the process for encrypting a JWE with this new =
scheme is as follows:
>>=20
>> Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk (ssk =
=3D sender secret key, etc)
>> Recipient has long-term static key pair: rsk, rpk
>>=20
>> 1. Sender generates a random ephemeral key pair: esk, epk
>> 2. Calculate Ze :=3D ecdh(esk, rpk)  =E2=80=94 just like in ECDH-ES
>> 3. Calculate Zs :=3D ecdh(ssk, rpk)
>> 4. Let Z =3D Ze || Zs where || is concatenation
>> 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in =
ECDH-ES
>> 6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D =
encryption method using the key derived in step 5.
>>=20
>> On its own ECDH-ESSS has some decent security properties (including =
authenticated encryption), but it is especially good when you want to =
exchange lots of messages with the recipient. If the recipient replies =
to your initial message using ECDH-ESSS but using the ephemeral public =
key you sent in the first message as if it was your static public key, =
then what you get is an interactive handshake very similar to the Noise =
KK pattern [4] (squinting quite hard at this point). Both parties can =
then use the derived key from step 5 of the second message as a shared =
session key and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each =
other from that point on. This provides very strong security properties =
listed later in the Noise spec, including forward secrecy and both =
sender and recipient authentication with resistance to key compromise =
impersonation. So beyond its usefulness for Access Token JWTs, this =
scheme is a really versatile building block that you can use for lots of =
advanced use-cases (e.g., PoP schemes).
>>=20
>> There are even nice formal models of the Noise handshake patterns in =
ProVerif [5], but I think they are only valid for the specific details =
of how Noise performs key derivation and transcript hashing so they =
wouldn=E2=80=99t directly apply to a JOSE version.
>>=20
>> [1] =
https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and=
-why-you-want-it-part-i/
>> [2] =
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd=
f
>> [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns=20=

>> [4] =
https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundam=
ental=20
>> [5] https://noiseexplorer.com
>>=20
>> Cheers,
>>=20
>> Neil
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_B360F635-F8B3-48D5-AE8B-1459DE246438
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

OK, =
I have put together a (very) rough first draft here - https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/

I have an =
implementation so I will try to find some time to generate some test =
vectors, but essentially you do exactly the same as for ECDH-ES but you =
derive a second shared secret between the sender=E2=80=99s static =
private key and the recipient=E2=80=99s static private key, then =
concatenate them together and run it through Concat-KDF as =
before.

I also =
have a GitHub for the draft https://github.com/NeilMadden/jose-ecdh-1pu that has =
a README with some more informal discussion.

I think this is potentially a very =
useful mode for JWT access tokens in particular where you want to =
encrypt and authenticate the AT to pass through the client to the RS =
without the overhead of nested signed+encrypted JWTs or the security =
risks of shared secrets.

Cheers,

Neil

On 27 Mar 2019, at 13:51, Neil =
Madden <neil.madden@forgerock.com> wrote:

Yes =
- a separate doc. Given that it is potentially useful in the context of =
OAuth, it might be something that the OAuth WG could consider, given =
that the JOSE WG is disbanded. I=E2=80=99ll see if I can find some time =
to put a draft together. (In markdown now that my mind has been blown =
that I don=E2=80=99t have to do everything in XML!)

On 26 Mar 2019, at =
16:50, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Neil,
thanks! This does sound very =
interesting. Just to clarify, you would document this in a separate doc =
extending JOSE?
We could then mention it from the JWT AT =
profile, whihc would remain lightweight and implementation =
independent.
thanks
V.

On Tue, Mar 26, 2019 at 3:11 AM Neil Madden <neil.madden@forgerock.com> wrote:
There =
was a brief discussion at OSW about signing vs encryption for JWT-based =
access tokens. I think it was Brian Campbell that pointed out that you =
often want authenticated encryption rather than signing, and I agree =
with this.

Currently JOSE only supports =
authenticated encryption for symmetric cryptography, which means that =
the AS and RS must agree a shared secret key beforehand. (Or else the RS =
uses the token introspection endpoint and doesn=E2=80=99t decrypt the =
token itself). Symmetric cryptography is less than ideal when the AS and =
RS are in separate trust boundaries (e.g., different companies).

There are actually ways to do *public key* =
authenticated encryption, but JOSE doesn=E2=80=99t support them yet. I =
wrote a 3-part blog series about this recently [1], but I=E2=80=99ll =
summarise the tl;dr version here. I think for JWT-based access tokens =
that contain identity assertions, this is probably what you want in most =
cases as it provides both confidentiality and authenticity without =
needing a bulky nested signed-then-encrypted JWT. Is this something =
people would be interested in, if I propose a draft?

Details:

The basic idea is to =
introduce one or more variants on ECDH-ES that provide sender =
authentication. The most straightforward is to use ECDH-SS =E2=80=94 =
i.e., Diffie-Hellman between two static key pairs, one for the sender =
and one for the recipient, with no ephemeral keys. This provides =
authenticated encryption so long as the content encryption method is =
authenticated (which they all are in JOSE). But it has a number of =
security downsides, which I describe in more detail in the blog. (It =
might be useful in some IoT scenarios though).

The better variant is to instead do ECDH-ESSS. That is, we =
generate a random ephemeral key pair and do an agreement with the =
recipient=E2=80=99s static public key, just like in ECDH-ES, but then we =
do another key agreement between the sender=E2=80=99s static private key =
and the recipient=E2=80=99s static private key. We then concatenate the =
two shared secrets and feed them into ConcatKDF just like you would for =
ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass =
unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is =
also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the =
Noise protocol framework [3].

To spell it =
out, the process for encrypting a JWE with this new scheme is as =
follows:

Sender has long-term =E2=80=9Cstatic=
=E2=80=9D key pair: ssk,_spk (ssk =3D sender secret key, etc)
Recipient has long-term static key pair: rsk, rpk

1. Sender generates a random ephemeral key =
pair: esk, epk
2. Calculate Ze :=3D ecdh(esk, rpk) =
 =E2=80=94 just like in ECDH-ES
3. Calculate Zs :=3D =
ecdh(ssk, rpk)
4. Let Z =3D Ze || Zs where || is =
concatenation
5. Run Z through ConcatKDF with =
PartyUInfo/PartyVInfo just as in ECDH-ES
6. Encrypt the =
message using the chosen =E2=80=9Cenc=E2=80=9D encryption method using =
the key derived in step 5.

On its own =
ECDH-ESSS has some decent security properties (including authenticated =
encryption), but it is especially good when you want to exchange lots of =
messages with the recipient. If the recipient replies to your initial =
message using ECDH-ESSS but using the ephemeral public key you sent in =
the first message as if it was your static public key, then what you get =
is an interactive handshake very similar to the Noise KK pattern [4] =
(squinting quite hard at this point). Both parties can then use the =
derived key from step 5 of the second message as a shared session key =
and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each other from that =
point on. This provides very strong security properties listed later in =
the Noise spec, including forward secrecy and both sender and recipient =
authentication with resistance to key compromise impersonation. So =
beyond its usefulness for Access Token JWTs, this scheme is a really =
versatile building block that you can use for lots of advanced use-cases =
(e.g., PoP schemes).

There are even nice =
formal models of the Noise handshake patterns in ProVerif [5], but I =
think they are only valid for the specific details of how Noise performs =
key derivation and transcript hashing so they wouldn=E2=80=99t directly =
apply to a JOSE version.

[1] https://neilmadden.blog/2018/11/14/public-key-authenticated-enc=
ryption-and-why-you-want-it-part-i/
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8=
00-56Ar3.pdf
[3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns=
 
[4] https://noiseprotocol.org/noise.html#interactive-handshake-patt=
erns-fundamental 
[5] https://noiseexplorer.com

Cheers,

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


=

--Apple-Mail=_B360F635-F8B3-48D5-AE8B-1459DE246438--


From nobody Thu May  9 12:46: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 DBD2C120143 for ; Thu,  9 May 2019 12:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQwgx3zxnqll for ; Thu,  9 May 2019 12:46:10 -0700 (PDT)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD9D12013D for ; Thu,  9 May 2019 12:46:09 -0700 (PDT)
Received: by mail-it1-x131.google.com with SMTP id q65so5614613itg.2 for ; Thu, 09 May 2019 12:46:09 -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=1UxVA8wYRnHI/POACUIHF/9ax852RBY7hGZiN8tMr3c=; b=qqEWATgI07XrVeu4fs+zQ4OkQSOkPi2d5yoLcCS+F6ss5iw69teUwIAyW1tgYoWLYY qWA/FkJkC2t/RCVKqDNZNrt2QB1Fx3F5GqMKBF+qYg1GA02WVsT81iadwsgpn/gCZ4mK XHQCyV2PZNF/seoLOnpFLm2ReIy/1aWqEdpgUJAOXGaJ4rLRAMfb04RQxhrJZEJLwHp/ RZuNedR1aB2gleRSDDWYye5EMa4fdlBcGJGoVooXujenDyThggpiubjlfbItvSuYpt84 G0JtD3HhdLaylzvNF0oShzT+6VYvQkb2mkq+uyzBOqpyCPt1bft0kVHIHWDNlmVXlLUQ XAXg==
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=1UxVA8wYRnHI/POACUIHF/9ax852RBY7hGZiN8tMr3c=; b=eyY2uvxbEo8sDwN7K5OH000jIfSzEJ7p8MTlXpdENULaCgUujUfjsgZOpyRvhpgOMk O07Q6QTTfTkUOye7EhJMaO/+tORVaoOCd/Wb+BImfO3wjr6vkESDnRPYlrCMUmom/oXk Wgze4bxFu8uW+Wpcl7sQRrb+XjnqU48LvUJWQ0nvlTOpX62XjnYJBdKkxbD+PO19dW2w +1rUMiNcsdlatRrKMW+AiZ+/WgdYnHwKl1tHxGZ7LMheJahfdAzL/GaEjX/Lqm+LBKVl 1Z2ycrxMqApdMINmcUplCEBA2V6liEqXgfqQL3GlTGjrDV47lIZfSLcDboCHAqnNwSU8 aEEg==
X-Gm-Message-State: APjAAAVYtZG9CA2qw9F44EnMCYevYC4celwKWrY3vqhd22fzozn/YXWp xeIp1Lb5Y26KO6hfRL/HPhEsBdXwmGCYttbGprs=
X-Google-Smtp-Source: APXvYqy8NtDtOJ9Jf8aqJU7+73UM+1L6J54VGkbDsHAkBxRF9j42KKhHa88EAutJlZB9BSsrpRyRIu3xRDmt5TtPD8Q=
X-Received: by 2002:a02:7122:: with SMTP id n34mr4803298jac.73.1557431168974;  Thu, 09 May 2019 12:46:08 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Thu, 9 May 2019 15:45:57 -0400
Message-ID: 
To: Filip Skokan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000096c494058879b319"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations
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, 09 May 2019 19:46:12 -0000

--00000000000096c494058879b319
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Filip!

On Fri, May 3, 2019 at 3:32 AM Filip Skokan  wrote:

> Hi Rifaat,
>
> node.js OSS oidc-provider implements the document in full behind an
> optional feature toggle -
> https://github.com/panva/node-oidc-provider/blob/master/docs/README.md#fe=
aturesjwtintrospection
>
> Best,
> Filip
>
> Odesl=C3=A1no z iPhonu
>
> 2. 5. 2019 v 22:46, Rifaat Shekh-Yusef :
>
> All,
>
> As part of the shepherd write-up for the *JWT Response for OAuth Token
> Introspection* draft, we are looking for information about
> implementations for this document:
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respo=
nse/
>
> Are you aware of any implementations?
>
> Regards,
>  Rifaat
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Thanks Filip!

On Fri, May 3, 2019 at 3:32 AM Filip Skokan &=
lt;panva.ip@gmail.com> wrote:<=
br>
Hi Rifaat,

node.js OSS oidc-provider implements the do=
cument in full behind an optional feature toggle -=C2=A0https://github.com/panva/node-oidc-provider=
/blob/master/docs/README.md#featuresjwtintrospection

Best,
Filip

Odesl=C3=A1no z=C2=A0iPhonu

2. 5. 2019 v=C2=A022:46, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:=


<=
div dir=3D"ltr">
All,

As part of the she=
pherd write-up for the JWT Response for OAuth Token Introspection dr=
aft, we are looking for information about implementations for this document=
:

Are you aware of any implementations?

Regard=
s,
=C2=A0Rifaat




_______=
________________________________________
OAuth mailing list=

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



--00000000000096c494058879b319--


From nobody Thu May  9 12:46:29 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 47D50120168 for ; Thu,  9 May 2019 12:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2aKpQYVsClV for ; Thu,  9 May 2019 12:46:19 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24AD120186 for ; Thu,  9 May 2019 12:46:19 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id o190so5374631itc.1 for ; Thu, 09 May 2019 12:46:19 -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=8Koy97LTMKXoxhTy94vHRhdcAtPY3V53aYF9Kn+3AGg=; b=hE6NV2wzk7+k+YFHqdnof2ouTSp6OecTqXCRtAZT2wtQRFUaendKpHNVCbA4LNVYw7 hrEhx7tzTDiKS2tq4d5bsuM+vX5qvvbi6Q2ufxGOblAiFgICU0uUmoD3dc271ZLY/FJf nD6mhq93ZSLXmLvd4omFOsnv8N58VvFq626jlmhmdlNGgi6K65J1K7mEUP7R7icjcCCL CE/IA5D1HUQ2nYy5CuM/JdzaTJ4/PyfOnN3UVCzBKZwOZbgtnwQcmTZm89VYokq7SlW0 12ky+NDfGMkve1p6mZQNCmJceruDUlYb7/Tmk7NC2L3QrDvb7+sQB/8KRaOl1McNuGLw BdFg==
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=8Koy97LTMKXoxhTy94vHRhdcAtPY3V53aYF9Kn+3AGg=; b=jDdsp4O+s11XOGW8Ww7deevacs3hDRKhv/0l83KGuP4duCuknCx+cxnUHV+d5KG9SW ZeHlB9ZUHChLBVXGkWDEbQcjPg77qXrA6hCjQp6b1IF3yZeJ8+0IoD+ae4nRfKQrR2um RMcpjMpG/sa1yqeOSATPuB68Tr9CHSuxcHxiwj8TmelKUwajDrA2sEx8Lt53ScVXlFh/ 8vFnxxtlUaPRThaR9Dhfafi8flFVyjaDBsk8/uraorYoKZkpFNwt0l9ZOtJhYG49zw1+ 8QI3yAMavfJlWotgAW9nuQs4LPD5+iCrqRiWyusXGBCPKJaOI0stHVGF78MDtYbjlUSd 3wmw==
X-Gm-Message-State: APjAAAWhjVvQ3zfHZue8E5MCtufZ1jib+bFWyMO0qjzwasV67KqeqwXU mt6GwvETih+e/1PhQXF57tg33xUQK5ty5F495u0tLGKj
X-Google-Smtp-Source: APXvYqzBJIyHdIfmt2vziIyrcwxmJy7x7rErKp6tw1IosDybRAM0suu5SnGoYaLSYQdrQ1I3BsC9cmc22lU35hQe7pc=
X-Received: by 2002:a24:4614:: with SMTP id j20mr4094847itb.72.1557431179069;  Thu, 09 May 2019 12:46:19 -0700 (PDT)
MIME-Version: 1.0
References:  <3801ae30-0de4-8a82-f283-fd7b3fdb2ac5@connect2id.com>
In-Reply-To: <3801ae30-0de4-8a82-f283-fd7b3fdb2ac5@connect2id.com>
From: Rifaat Shekh-Yusef 
Date: Thu, 9 May 2019 15:46:08 -0400
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000030cea4058879b483"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations
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, 09 May 2019 19:46:28 -0000

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

Thanks Vladimir!

On Mon, May 6, 2019 at 2:40 PM Vladimir Dzhuvinov 
wrote:

> Hi Rifaat,
>
> On 02/05/2019 23:46, Rifaat Shekh-Yusef wrote:
> > All,
> >
> > As part of the shepherd write-up for the *JWT Response for OAuth Token
> > Introspection* draft, we are looking for information about
> implementations
> > for this document:
> >
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
> >
> > Are you aware of any implementations?
>
> Here is a production implementation of the JWT introspection response:
>
> https://connect2id.com/products/server/docs/api/token-introspection
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Thanks=C2=A0Vladimir!

=

On Mon, May 6, 2019 at 2:40 PM Vladim=
ir Dzhuvinov <vladimir@connec=
t2id.com> wrote:
Hi Rifaat,



On 02/05/2019 23:46, Rifaat Shekh-Yusef wrote:

> All,

>

> As part of the shepherd write-up for the *JWT Response for OAuth Token=


> Introspection* draft, we are looking for information about implementat=
ions

> for this document:

> https://datatracke=
r.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

>

> Are you aware of any implementations?



Here is a production implementation of the JWT introspection response:



https://connect2id.com/products/s=
erver/docs/api/token-introspection



Vladimir



-- 

Vladimir Dzhuvinov



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000030cea4058879b483--


From nobody Fri May 10 06:52: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 7954512008D for ; Fri, 10 May 2019 06:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY7sDuTv3ni8 for ; Fri, 10 May 2019 06:52:25 -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 3021A120020 for ; Fri, 10 May 2019 06:52:25 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id 66so5653096otq.0 for ; Fri, 10 May 2019 06:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E2PahQQI7oENoFkKKiX7BaiAV6FowwLSvjoJDvzAlZk=; b=AMwmboQx1Qha+H8U4fYDkDKgOUN5ZbMVTParrUtmSOxYf/37PyNMaDJoRkBo5I0pxp SuDiZ9FYeLU5fGwLSC8r/V3eibT3Df8Ahh9GWSyjioiBKTNgvvTVxtJhJogSITV/mCES vphrrgB8G8w6qFyJxd3767rjbF0nlS2ayqRdY=
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=E2PahQQI7oENoFkKKiX7BaiAV6FowwLSvjoJDvzAlZk=; b=oB5Q4RbLqG72u9NuOyATPGgaXDnaNTgLAy4MTuPIrYX1O6P9suM6ej93pm5yoI+Zvj Cb8sYldKwgTqiF20V0pop0AoSUkLBVKpkBNtRVfTG56/O5GcUwcyEGkDgZGGC5Ez8XAP hFJ/AFeminCHY0vlrCV1GrDwVS8DLsu3gzq2K7qWuZeGhrF7fPNyqnxVUuwu9ntg9NRc jo7ADekKnvzhcxxdE2OlB/x8SzgInQRYFZSvK+GDvN+C1WJqLogdY3NtQu0+USafzyhP d6b9d/+GCf3Hy+6KLoliOb9doFNXGA1QooQEpxpGZTc2nlIM5SNrzU33wyzUHhv7oyrp FzAA==
X-Gm-Message-State: APjAAAXCaK9W+RmksZE8y+uQUxURjrvmMRFZt+kJKHg2CqQ9ADGmlssV xzOPutLrXQBWbhgmBCuhKJVBD/vmGNtcOaMhZVObaQ==
X-Google-Smtp-Source: APXvYqzmKTsMIjAbKmlg65Fop6DQb40W6CZSsFUbEhfPvRur7iJqBicgke756EY6+RdkYoN34m36VvWNxsF0k8/ka4Y=
X-Received: by 2002:a9d:5e02:: with SMTP id d2mr4357806oti.222.1557496344286;  Fri, 10 May 2019 06:52:24 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net> <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com>
In-Reply-To: <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com>
From: Dave Tonge 
Date: Fri, 10 May 2019 15:52:12 +0200
Message-ID: 
To: George Fletcher 
Cc: Torsten Lodderstedt , Sascha Preibisch , oauth 
Content-Type: multipart/alternative; boundary="0000000000005730cd058888e08c"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
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, 10 May 2019 13:52:26 -0000

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

Thanks Torsten for this article - it is incredibly helpful.

I'm very much in favour of the "structured_scope" approach.

While I understand George's point I think the line is very blurred between
coarse-grained scopes and fine-grained transaction consent. In addition
fine-grained authorisation metadata is needed for ongoing access APIs as
well, e.g. how can a client ask for ongoing access to:
 - transactions in a users accounts with ids abc123 and abc124

>From a UX perspective it is beneficial for the AS to ask the user for
consent once. The AS therefore needs to have all the information about
relating to the consent available when the user is redirected to the
authorization endpoint. There should be a standard way for the Client to
pass this data to the AS and I think structured scopes either sent as a
query param or in a request object are a neat way of doing this.

Dave

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


Thanks Torsten for this article - it is i=
ncredibly helpful.

I'm very much in favour of the "=
structured_scope" approach.=C2=A0

While I understand Ge=
orge's point I think the line is very blurred between coarse-grained sc=
opes and fine-grained transaction consent. In addition fine-grained authori=
sation metadata is needed for ongoing access APIs as well, e.g. how can a c=
lient ask for ongoing access to:
=C2=A0- transactions in a users accou=
nts with ids abc123 and abc124

From a UX perspective it is b=
eneficial for the AS to ask the user for consent once. The AS therefore nee=
ds to have all the information about relating to the consent available when=
 the user is redirected to the authorization endpoint. There should be a st=
andard way for the Client to pass this data to the AS and I think structure=
d scopes either sent as a query param or in a request object are a neat way=
 of doing this.=C2=A0

Dave



--0000000000005730cd058888e08c--


From nobody Fri May 10 13:27:15 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 46B7D1200B8 for ; Fri, 10 May 2019 13:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 mUkKT13OQrgs for ; Fri, 10 May 2019 13:27:11 -0700 (PDT)
Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 3A5DD1200F4 for ; Fri, 10 May 2019 13:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557520030; bh=3FS8QtBJtXUcwQTfOajDjwBVW42JWX7ictGCOrsL3tk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=RkKm0zi+vMjIJ1a3hRlwZuapDnaAm0Di3Ls3rtQ3gwC7Bgfr6DHEJdLUG6gknJYWgsTDbwm/CzgzlOM6t7aTApjWH108vmacuq5wnpDVMIkzVPb4qzikU/tXcnzAkO95ojk/uzH5fF8MDumzSlQmomW+121ds/D+UKmX6ftg6ky1lxnXLV4Fl+Memd9c/OO0FkqwsvnqJpO8R5oKREqvPGYdO77oWIWL/8Jm8xcgQLeLnhTBpXE3sT4DCO+ZXwGkzi+ORKHBlKPl6Q86M3QIZbSkYbj6QOB9FKLMm47OwSHzmv54J8PrjAi4sHiy1C9kFZ3sdXeIjympW/FpYxjKjw==
X-YMail-OSG: MvknDbsVM1kxfBGvWH6W9po_xocwr9grl7pnj8c4EooGdWtsXCFVOrxWmv.1pg7 oQiYqd3uJYLac7ZOC12FexYGajyfp3fYXOHEreRgqiEyOTQNcRiMtoogiDKGiXR2HBJsjtGYgnfP 0zplJh7TN6YE8ZrHm3o91tVkHvO58xSA2F5xP1Yh9EFiqVNplm51GoQaVJ11FXXDF2GuwaaFvHh4 KPXy8kDaiMQi_KrI5sELdgLHnoe.bLJnnu5FNOfmtCmR7SJfPewGkOOllvIEOeDIOpkdLII2GqTe hJkgZCz94h9u0KoFkxNm0rlrp.V8OuZsMaUrWiSMxFq2xwnXl0CoEpb3uADp1JiimTACZih_5qdF q7UgQPxb8Jca0W4M2.CRNYkjSsZUOEGGRMNHiTB215ahQA2J3wmD7OS3EXLNmscTl_ja2JOzNdJ8 _.Eprh2iWsDzZ3uYF_a04WGZf5d97xkudKXpJJM9Wu5fadegaPliB8W6u2aejHImmFDTCiZENfJr BexFhtN2U0dEW4vWfdLIik3E0u4sZ.tAHUd7NkQTfLR1f1U10DmQVLrVxCdgdKw2PRGWiyBEpFNV t_jwwxAnQ4.80cqAMJG6C45L4xu7INhZhaT52JxdGCiUL8hICJWVa.X_pWyRa2JnLOUUrmagziag etFdAwdh0TuO.5ctmPP.TGH.dkvvv.Lx_JW4M_Kd9CvNFygw9fTkbCDMdPYq.K1RspN836t1Mdmj jM3r4vwGFPL2b6Fzz_oFTQNTwPFDljUExq4z9C81HS.n5U3Sb0G_IuM_d7xZMgU1LEkfKdoBeSnE .YrFrCm_bqmJS3eMiNSafcezasGJgc37_p.dj7BJ.jQZfpggxT4CkLpxuz7sC8Sb.p2ZLcUGo5RM c29ASfGpHdz3GbwH1Bt_mGHKIXmsihCcK5PoBS3mqGeNaF5r4WrEs2lSiF_XM2IoAdPzo.53k.55 dETlhPTdiq99Y43Raup3p8UWsVirtFxArsU5g3VSZbh06nS9ynxOTEytDoPMRkig.n_jwl_OAgkV zQmZAohbX2BAAgidfdQ._WOjT8PuQNvlxL__Sg9z61CNCBC9wVqCKCQ_G8VMC_u.aybySxk_iHH6 ryk.AU4mKvPvmUBGnVP3OmypYL1oNQkN20MLcbDX9qjjzHs1Ey9eAGU9XE3sbZvwp.2E-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 10 May 2019 20:27:10 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 96bcd5ad374cd04c0d8ea177f35be65d;  Fri, 10 May 2019 20:27:07 +0000 (UTC)
To: Dave Tonge 
Cc: Torsten Lodderstedt , Sascha Preibisch , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net> <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <10e7ee87-4877-4790-dbdc-8f599d401cbe@aol.com>
Date: Fri, 10 May 2019 16:27:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E489D4CD099C2C0BB3CC9F2B"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
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, 10 May 2019 20:27:13 -0000

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

One thing to keep in mind with the "Push Request Object" model and the 
concept of a more detailed scope structure, if the specified values are 
not for a single transaction, then the AS will be required to keep the 
"Pushed Request Object" for the "lifetime" of the access_token and 
possibly the refresh_token depending on the use case. This could have 
some implementation issues for the AS.

Thanks,
George

On 5/10/19 9:52 AM, Dave Tonge wrote:
> Thanks Torsten for this article - it is incredibly helpful.
>
> I'm very much in favour of the "structured_scope" approach.
>
> While I understand George's point I think the line is very blurred 
> between coarse-grained scopes and fine-grained transaction consent. In 
> addition fine-grained authorisation metadata is needed for ongoing 
> access APIs as well, e.g. how can a client ask for ongoing access to:
>  - transactions in a users accounts with ids abc123 and abc124
>
> From a UX perspective it is beneficial for the AS to ask the user for 
> consent once. The AS therefore needs to have all the information about 
> relating to the consent available when the user is redirected to the 
> authorization endpoint. There should be a standard way for the Client 
> to pass this data to the AS and I think structured scopes either sent 
> as a query param or in a request object are a neat way of doing this.
>
> Dave
>


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


  
    
  
  
    One thing to keep in mind with the "Push Request Object" model and
    the concept of a more detailed scope structure, if the specified
    values are not for a single transaction, then the AS will be
    required to keep the "Pushed Request Object" for the "lifetime" of
    the access_token and possibly the refresh_token depending on the use
    case. This could have some implementation issues for the AS.

    

    Thanks,

    George

    

    
On 5/10/19 9:52 AM, Dave Tonge wrote:

    

    

      
      

        

          
Thanks Torsten for this article - it is
            incredibly helpful.

          


          

          
I'm very much in favour of the
            "structured_scope" approach. 

          


          

          
While I understand George's point I think the
            line is very blurred between coarse-grained scopes and
            fine-grained transaction consent. In addition fine-grained
            authorisation metadata is needed for ongoing access APIs as
            well, e.g. how can a client ask for ongoing access to:

          
 - transactions in a users accounts with ids
            abc123 and abc124

          


          

          
From a UX perspective it is beneficial for
            the AS to ask the user for consent once. The AS therefore
            needs to have all the information about relating to the
            consent available when the user is redirected to the
            authorization endpoint. There should be a standard way for
            the Client to pass this data to the AS and I think
            structured scopes either sent as a query param or in a
            request object are a neat way of doing this. 

          


          

          
Dave

        

        

          


          

        

      

    

    

  


--------------E489D4CD099C2C0BB3CC9F2B--


From nobody Sun May 12 06:37: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 837941200A4 for ; Sun, 12 May 2019 06:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubkjFoM9oSEW for ; Sun, 12 May 2019 06:37:45 -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 3314A12002F for ; Sun, 12 May 2019 06:37:45 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id c5so12306501wrs.11 for ; Sun, 12 May 2019 06:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yOiNJ0Znm5xT/VuO6bZ5mcevyZQGWt/9y5b0KX6gPzI=; b=ipAti5zGylGYr5LweqbMHJI0ZGjesydHKU4fM788ghOi3PSNElor8yTeReUPh7P0/r 1XDs1r1AIsYVnjpoS6P0GoQBVbujLfiZr/ITO78Q+/rez3t+RbSgEB/F2aXtmtpznkM3 N1NcNxQ+8Tdy9mgkQg9ML7qpHC+Qx8Zd63OTw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yOiNJ0Znm5xT/VuO6bZ5mcevyZQGWt/9y5b0KX6gPzI=; b=mSLP8yDjCgWSu7HdmwSMun1mIO0phGrNwLDib5onzaXiHuX0/49JytbUjwDiBWuGjd z9fAQOvQJ+4s40Oo2Jt+SaRdRQ9isc4H+JAokfVDcYJ33JmxbyknGD9EkNOSsM+VavtS 4kkgXzJuG21XOPKQtjxmvadqZTkqD5eJSOIZkqf6+bfONlx+kF/D9nhLR7Yc9Dl5UK6k kYtDGsNrJ3mtdFrYE7B/h473b0R3gq1Tsr5oQW1quplPCgbq2uaWe50eupWkoZEKNV1p wg+OO6CDcUlb6wEn/ex4jLvk7pTmacxxK2/mPYqlbVuHp7Ek8lsOe0YanRLjdXetfvkh pTRA==
X-Gm-Message-State: APjAAAWrd50RLsouOStCTS24YEPv+35u4TI0pnnVRzDvqBvS59vV+wwr L1U7/rk6FyPwCThoEEerYIKJtA==
X-Google-Smtp-Source: APXvYqxWWE7Hmd4CQUP9VWv6umeIMmZbhHuGZefxZt2j7bWW+U2v5FYDoDivxImHoygwJZvP4L37ew==
X-Received: by 2002:a5d:5282:: with SMTP id c2mr14421028wrv.88.1557668263327;  Sun, 12 May 2019 06:37:43 -0700 (PDT)
Received: from [192.168.1.64] (29.87.75.194.dyn.plus.net. [194.75.87.29]) by smtp.gmail.com with ESMTPSA id w14sm9866018wrr.41.2019.05.12.06.37.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 06:37:42 -0700 (PDT)
From: Neil Madden 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7EFF88E7-5056-46D8-B74A-167CC7ECCE39"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 12 May 2019 14:37:40 +0100
In-Reply-To: <6F0B4144-C0E9-48E4-8BE0-0B305FC32B32@forgerock.com>
Cc: IETF oauth WG 
To: Vittorio Bertocci 
References:   <3B27C5F4-3D67-4F37-9522-0883F0D18B85@forgerock.com> <6F0B4144-C0E9-48E4-8BE0-0B305FC32B32@forgerock.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] Public key authenticated encryption for JWTs [Was Re: JWT ATs and authenticated encryption]
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, 12 May 2019 13:37:50 -0000

--Apple-Mail=_7EFF88E7-5056-46D8-B74A-167CC7ECCE39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I have published a -01 version with example computations for both =
ECDH-1PU over P-256 and also a two-way interactive handshake using it =
with X448 keys. I also fleshed out the security considerations and added =
a =E2=80=9Cskid=E2=80=9D (Sender Key ID) header parameter.

I think this is potentially very useful in OAuth/OIDC for JWT-based =
access tokens, encrypted request parameters, ID tokens, and maybe also =
PoP.


A new version of I-D, draft-madden-jose-ecdh-1pu-01.txt
has been successfully submitted by Neil Madden and posted to the
IETF repository.

Name:		draft-madden-jose-ecdh-1pu
Revision:	01
Title:		Public Key Authenticated Encryption for JOSE: ECDH-1PU
Document date:	2019-05-10
Group:		Individual Submission
Pages:		22
URL:            =
https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu-01.txt =

Status:         =
https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ =

Htmlized:       =
https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01 =

Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu =

Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-madden-jose-ecdh-1pu-01 =


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.  The mode is also a useful building block for constructing
  interactive handshake protocols on top of JOSE.

Cheers,

Neil

> On 9 May 2019, at 17:15, Neil Madden  =
wrote:
>=20
> OK, I have put together a (very) rough first draft here - =
https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/ =

>=20
> I have an implementation so I will try to find some time to generate =
some test vectors, but essentially you do exactly the same as for =
ECDH-ES but you derive a second shared secret between the sender=E2=80=99s=
 static private key and the recipient=E2=80=99s static private key, then =
concatenate them together and run it through Concat-KDF as before.
>=20
> I also have a GitHub for the draft =
https://github.com/NeilMadden/jose-ecdh-1pu =
 that has a README with =
some more informal discussion.
>=20
> I think this is potentially a very useful mode for JWT access tokens =
in particular where you want to encrypt and authenticate the AT to pass =
through the client to the RS without the overhead of nested =
signed+encrypted JWTs or the security risks of shared secrets.
>=20
> Cheers,
>=20
> Neil
>=20
>> On 27 Mar 2019, at 13:51, Neil Madden > wrote:
>>=20
>> Yes - a separate doc. Given that it is potentially useful in the =
context of OAuth, it might be something that the OAuth WG could =
consider, given that the JOSE WG is disbanded. I=E2=80=99ll see if I can =
find some time to put a draft together. (In markdown now that my mind =
has been blown that I don=E2=80=99t have to do everything in XML!)
>>=20
>>> On 26 Mar 2019, at 16:50, Vittorio Bertocci > wrote:
>>>=20
>>> Hi Neil,
>>> thanks! This does sound very interesting. Just to clarify, you would =
document this in a separate doc extending JOSE?
>>> We could then mention it from the JWT AT profile, whihc would remain =
lightweight and implementation independent.
>>> thanks
>>> V.
>>>=20
>>> On Tue, Mar 26, 2019 at 3:11 AM Neil Madden =
> wrote:
>>> There was a brief discussion at OSW about signing vs encryption for =
JWT-based access tokens. I think it was Brian Campbell that pointed out =
that you often want authenticated encryption rather than signing, and I =
agree with this.
>>>=20
>>> Currently JOSE only supports authenticated encryption for symmetric =
cryptography, which means that the AS and RS must agree a shared secret =
key beforehand. (Or else the RS uses the token introspection endpoint =
and doesn=E2=80=99t decrypt the token itself). Symmetric cryptography is =
less than ideal when the AS and RS are in separate trust boundaries =
(e.g., different companies).
>>>=20
>>> There are actually ways to do *public key* authenticated encryption, =
but JOSE doesn=E2=80=99t support them yet. I wrote a 3-part blog series =
about this recently [1], but I=E2=80=99ll summarise the tl;dr version =
here. I think for JWT-based access tokens that contain identity =
assertions, this is probably what you want in most cases as it provides =
both confidentiality and authenticity without needing a bulky nested =
signed-then-encrypted JWT. Is this something people would be interested =
in, if I propose a draft?
>>>=20
>>> Details:
>>>=20
>>> The basic idea is to introduce one or more variants on ECDH-ES that =
provide sender authentication. The most straightforward is to use =
ECDH-SS =E2=80=94 i.e., Diffie-Hellman between two static key pairs, one =
for the sender and one for the recipient, with no ephemeral keys. This =
provides authenticated encryption so long as the content encryption =
method is authenticated (which they all are in JOSE). But it has a =
number of security downsides, which I describe in more detail in the =
blog. (It might be useful in some IoT scenarios though).
>>>=20
>>> The better variant is to instead do ECDH-ESSS. That is, we generate =
a random ephemeral key pair and do an agreement with the recipient=E2=80=99=
s static public key, just like in ECDH-ES, but then we do another key =
agreement between the sender=E2=80=99s static private key and the =
recipient=E2=80=99s static private key. We then concatenate the two =
shared secrets and feed them into ConcatKDF just like you would for =
ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass =
unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is =
also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the =
Noise protocol framework [3].
>>>=20
>>> To spell it out, the process for encrypting a JWE with this new =
scheme is as follows:
>>>=20
>>> Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk =
(ssk =3D sender secret key, etc)
>>> Recipient has long-term static key pair: rsk, rpk
>>>=20
>>> 1. Sender generates a random ephemeral key pair: esk, epk
>>> 2. Calculate Ze :=3D ecdh(esk, rpk)  =E2=80=94 just like in ECDH-ES
>>> 3. Calculate Zs :=3D ecdh(ssk, rpk)
>>> 4. Let Z =3D Ze || Zs where || is concatenation
>>> 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in =
ECDH-ES
>>> 6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D =
encryption method using the key derived in step 5.
>>>=20
>>> On its own ECDH-ESSS has some decent security properties (including =
authenticated encryption), but it is especially good when you want to =
exchange lots of messages with the recipient. If the recipient replies =
to your initial message using ECDH-ESSS but using the ephemeral public =
key you sent in the first message as if it was your static public key, =
then what you get is an interactive handshake very similar to the Noise =
KK pattern [4] (squinting quite hard at this point). Both parties can =
then use the derived key from step 5 of the second message as a shared =
session key and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each =
other from that point on. This provides very strong security properties =
listed later in the Noise spec, including forward secrecy and both =
sender and recipient authentication with resistance to key compromise =
impersonation. So beyond its usefulness for Access Token JWTs, this =
scheme is a really versatile building block that you can use for lots of =
advanced use-cases (e.g., PoP schemes).
>>>=20
>>> There are even nice formal models of the Noise handshake patterns in =
ProVerif [5], but I think they are only valid for the specific details =
of how Noise performs key derivation and transcript hashing so they =
wouldn=E2=80=99t directly apply to a JOSE version.
>>>=20
>>> [1] =
https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and=
-why-you-want-it-part-i/ =

>>> [2] =
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd=
f =

>>> [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns =
=20
>>> [4] =
https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundam=
ental =
=20
>>> [5] https://noiseexplorer.com 
>>>=20
>>> Cheers,
>>>=20
>>> Neil
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_7EFF88E7-5056-46D8-B74A-167CC7ECCE39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
have published a -01 version with example computations for both ECDH-1PU =
over P-256 and also a two-way interactive handshake using it with X448 =
keys. I also fleshed out the security considerations and added a =
=E2=80=9Cskid=E2=80=9D (Sender Key ID) header parameter.

I think this is =
potentially very useful in OAuth/OIDC for JWT-based access tokens, =
encrypted request parameters, ID tokens, and maybe also PoP.


A new version of I-D, =
draft-madden-jose-ecdh-1pu-01.txt
has been successfully submitted by Neil Madden and posted to =
the
IETF =
repository.
Name:		=
draft-madden-jose-ecdh-1pu
Revision:	=
01Title:		=
Public Key =
Authenticated Encryption for JOSE: ECDH-1PU
Document =
date:	2019-05-10
Group:	=
	Individual Submission
Pages:		=
22URL: =
           <=
a =
href=3D"https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu-01=
.txt" style=3D"font-family: HelveticaNeue;" =
class=3D"">https://www.ietf.org/internet-drafts/draft-madden-jose-ecdh-1pu=
-01.txt
Status: =
        https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/
Htmlized: =
      https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01Htmlized: =
      https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1p=
u
Diff: =
          https://www.ietf.org/rfcdiff?url2=3Ddraft-madden-jose-ecdh-1pu-=
01

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.  The mode is also a useful =
building block for constructing
  interactive handshake protocols on top of =
JOSE.

Cheers,

Neil

On 9 May 2019, at 17:15, Neil Madden <neil.madden@forgerock.com> wrote:

OK, I have put =
together a (very) rough first draft here - https://datatracker.ietf.org/doc/draft-madden-jose-ecdh-1pu/

I have an =
implementation so I will try to find some time to generate some test =
vectors, but essentially you do exactly the same as for ECDH-ES but you =
derive a second shared secret between the sender=E2=80=99s static =
private key and the recipient=E2=80=99s static private key, then =
concatenate them together and run it through Concat-KDF as =
before.

I also =
have a GitHub for the draft https://github.com/NeilMadden/jose-ecdh-1pu that has =
a README with some more informal discussion.

I think this is potentially a very =
useful mode for JWT access tokens in particular where you want to =
encrypt and authenticate the AT to pass through the client to the RS =
without the overhead of nested signed+encrypted JWTs or the security =
risks of shared secrets.

Cheers,

Neil

On 27 Mar 2019, at 13:51, Neil =
Madden <neil.madden@forgerock.com> wrote:

Yes =
- a separate doc. Given that it is potentially useful in the context of =
OAuth, it might be something that the OAuth WG could consider, given =
that the JOSE WG is disbanded. I=E2=80=99ll see if I can find some time =
to put a draft together. (In markdown now that my mind has been blown =
that I don=E2=80=99t have to do everything in XML!)

On 26 Mar 2019, at =
16:50, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hi Neil,
thanks! This does sound very =
interesting. Just to clarify, you would document this in a separate doc =
extending JOSE?
We could then mention it from the JWT AT =
profile, whihc would remain lightweight and implementation =
independent.
thanks
V.

On Tue, Mar 26, 2019 at 3:11 AM Neil Madden <neil.madden@forgerock.com> wrote:
There =
was a brief discussion at OSW about signing vs encryption for JWT-based =
access tokens. I think it was Brian Campbell that pointed out that you =
often want authenticated encryption rather than signing, and I agree =
with this.

Currently JOSE only supports =
authenticated encryption for symmetric cryptography, which means that =
the AS and RS must agree a shared secret key beforehand. (Or else the RS =
uses the token introspection endpoint and doesn=E2=80=99t decrypt the =
token itself). Symmetric cryptography is less than ideal when the AS and =
RS are in separate trust boundaries (e.g., different companies).

There are actually ways to do *public key* =
authenticated encryption, but JOSE doesn=E2=80=99t support them yet. I =
wrote a 3-part blog series about this recently [1], but I=E2=80=99ll =
summarise the tl;dr version here. I think for JWT-based access tokens =
that contain identity assertions, this is probably what you want in most =
cases as it provides both confidentiality and authenticity without =
needing a bulky nested signed-then-encrypted JWT. Is this something =
people would be interested in, if I propose a draft?

Details:

The basic idea is to =
introduce one or more variants on ECDH-ES that provide sender =
authentication. The most straightforward is to use ECDH-SS =E2=80=94 =
i.e., Diffie-Hellman between two static key pairs, one for the sender =
and one for the recipient, with no ephemeral keys. This provides =
authenticated encryption so long as the content encryption method is =
authenticated (which they all are in JOSE). But it has a number of =
security downsides, which I describe in more detail in the blog. (It =
might be useful in some IoT scenarios though).

The better variant is to instead do ECDH-ESSS. That is, we =
generate a random ephemeral key pair and do an agreement with the =
recipient=E2=80=99s static public key, just like in ECDH-ES, but then we =
do another key agreement between the sender=E2=80=99s static private key =
and the recipient=E2=80=99s static private key. We then concatenate the =
two shared secrets and feed them into ConcatKDF just like you would for =
ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass =
unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is =
also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the =
Noise protocol framework [3].

To spell it =
out, the process for encrypting a JWE with this new scheme is as =
follows:

Sender has long-term =E2=80=9Cstatic=
=E2=80=9D key pair: ssk,_spk (ssk =3D sender secret key, etc)
Recipient has long-term static key pair: rsk, rpk

1. Sender generates a random ephemeral key =
pair: esk, epk
2. Calculate Ze :=3D ecdh(esk, rpk) =
 =E2=80=94 just like in ECDH-ES
3. Calculate Zs :=3D =
ecdh(ssk, rpk)
4. Let Z =3D Ze || Zs where || is =
concatenation
5. Run Z through ConcatKDF with =
PartyUInfo/PartyVInfo just as in ECDH-ES
6. Encrypt the =
message using the chosen =E2=80=9Cenc=E2=80=9D encryption method using =
the key derived in step 5.

On its own =
ECDH-ESSS has some decent security properties (including authenticated =
encryption), but it is especially good when you want to exchange lots of =
messages with the recipient. If the recipient replies to your initial =
message using ECDH-ESSS but using the ephemeral public key you sent in =
the first message as if it was your static public key, then what you get =
is an interactive handshake very similar to the Noise KK pattern [4] =
(squinting quite hard at this point). Both parties can then use the =
derived key from step 5 of the second message as a shared session key =
and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each other from that =
point on. This provides very strong security properties listed later in =
the Noise spec, including forward secrecy and both sender and recipient =
authentication with resistance to key compromise impersonation. So =
beyond its usefulness for Access Token JWTs, this scheme is a really =
versatile building block that you can use for lots of advanced use-cases =
(e.g., PoP schemes).

There are even nice =
formal models of the Noise handshake patterns in ProVerif [5], but I =
think they are only valid for the specific details of how Noise performs =
key derivation and transcript hashing so they wouldn=E2=80=99t directly =
apply to a JOSE version.

[1] https://neilmadden.blog/2018/11/14/public-key-authenticated-enc=
ryption-and-why-you-want-it-part-i/
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8=
00-56Ar3.pdf
[3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns=
 
[4] https://noiseprotocol.org/noise.html#interactive-handshake-patt=
erns-fundamental 
[5] https://noiseexplorer.com

Cheers,

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


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

=

--Apple-Mail=_7EFF88E7-5056-46D8-B74A-167CC7ECCE39--


From nobody Sun May 12 12:17:29 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 5AFE7120128 for ; Sun, 12 May 2019 12:17: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=Hn3jiUmf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RF2Ho42c
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4bLPscjO0Vm for ; Sun, 12 May 2019 12:17:26 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE212120041 for ; Sun, 12 May 2019 12:17:26 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1F92331C; Sun, 12 May 2019 15:17:26 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 12 May 2019 15:17:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=afgBxz4YFZ1XOvRjgNaEOwPXN8GOVONv7VGwJnOcL0g=; b=Hn3jiUmfDucI K1fx/RTjujV+eO9t+Ewc0/KPpCC1wFRUPltZJt9a4fEm0tPBnk2sBM1MtiOP+3Cy wIuaiBntKBlhZdBCgCTL4R8s+lZKjA3BlYlMgvJHw7vNtM+YHoGSIm8Hb7aZkIoh aafUi1TUahciqJxnH9V215mnXYfbpsk=
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=fm2; bh=afgBxz4YFZ1XOvRjgNaEOwPXN8GOVONv7VGwJnOcL 0g=; b=RF2Ho42cIF0TF8Ls32QPHCUpswkirybyzfIDVMuSMV9ipW0Nk53r4ZI/3 4gNA3CUrwDxA3UztcTY8SjPH2WWC0tHg00qpY8AWV1SXxa/hFHcIwgJxDAdibmMa dGkV5JrHaecn5v4MJ9/884v1FIMhXjaP25N+4Yv19haEZ0moF7qfIuVEXYdy+qkC 8IZ7Qp2iV8GuQPvFOMmjkAHllmlOAq5BVhNvLMG04yKIey++UdOa34kycHiL2oz8 hCxurgn4pH293fmLDtKyOO92Y3fRoU/y80itHyLBVZyT8reb/NuM5F45R9cNLokQ Ku+DzfQe659kuprXIByL0kxE2bEFQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrledvgddufeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthhqredttdefjeenucfhrhhomhepgfhvvghr thcurfhothcuoehmvgesvghvvghrthhpohhtrdgtohhmqeenucffohhmrghinhepghhith hhuhgsrdgtohhmpdhivghtfhdrohhrghenucfkphepudeltddrudelvddrvdejrddvvddu necurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhmnecuve hluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: from [192.168.0.14] (unknown [190.192.27.221]) by mail.messagingengine.com (Postfix) with ESMTPA id B95CA103CC; Sun, 12 May 2019 15:17:23 -0400 (EDT)
To: Neil Madden 
Cc: oauth@ietf.org
References: <3a82cdf2-af33-c76c-958f-b2317e5373b7@evertpot.com> 
From: Evert Pot 
Openpgp: preference=signencrypt
Autocrypt: addr=me@evertpot.com; keydata= mQINBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABtBtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT6JAlQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFbkCDQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAYkCPAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA
Message-ID: <221fefd4-bdc2-a8ba-922c-a0c096477569@evertpot.com>
Date: Sun, 12 May 2019 15:17:21 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Link relations for authenticating
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, 12 May 2019 19:17:28 -0000

On 2019-05-06 2:35 p.m., Neil Madden wrote:
> I don=E2=80=99t know the relative merits of Link headers vs .well-known=
, but
> there is at least one other draft standard I know of that is going
> down the .well-known route for this kind of thing (password changes in
> this case):
>
> https://github.com/WICG/change-password-url/blob/gh-pages/explainer.md
>
> =E2=80=94 Neil

Hi Neil,

The RFC describes this a bit:
https://tools.ietf.org/html/rfc5785#section-3

The prime use-case for me is finding domain-wide services, especially in
cases where no full context-uri exists. A great example is answering the
question: Where is the CalDAV server for a given email address. Given
that an email address only has a hostname and not a full uri,
=2Ewell-known is a good way to find related services.

But .well-known doesn't really do everything that Web Linking (rfc8288)
does, and for people like me that want to build web services and
standards on the web, creating new relationship types is really the way
to go.

They're also pretty low risk and simple to register. They just need a
stable specification, and a RFC is great for this.

I actually do intend to use this with OAuth2, because I want my resource
services to link to an oauth2 authorization endpoint via the
'authentication' link.

Evert



From nobody Mon May 13 05:20: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 472E51200EB for ; Mon, 13 May 2019 05:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUJLSzzXBX6W for ; Mon, 13 May 2019 05:20:29 -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 D14361200E0 for ; Mon, 13 May 2019 05:20:28 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id x64so2413524wmb.5 for ; Mon, 13 May 2019 05:20: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:content-transfer-encoding; bh=+ABXOWYjmd7Y6C4nS1vCUrptxdgCkbW0D8c51gZVr70=; b=egTdpuwVHCIRhGv7s14vwWd5cXp8LftD0s8Fij5rJX5/+kRKV7dV63EgUtpy0NQAOG tgaWGqOUCFN5w9CX6Kv97n/LTbjZnSeynGjw99rJEAYKoj2dGkEwkZWDlOQXNfNHZa6T J1guogzw6DC7OPmvWfurlXN/m9OGwwQ+iAkuWlMIfUw/3m11OyGalgaO8xL/smWpfkXU 3WRD8BQKAFmvttSQq0EZM5JTp7gg6WSRn/C+9i9Nf5B1cUzOqX2oJ8/lFDbPmXwLdojB 2aDyMY9HC97OivWQ1idDHPWDQEmbU4PHM9/11tTq3PF57sfzsUjHNEefRjW8mH10xJDm unow==
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=+ABXOWYjmd7Y6C4nS1vCUrptxdgCkbW0D8c51gZVr70=; b=ecNZuRyhkePs/0m1TF82QqW+oQ1heZ/wEFyLjwLiLAQWFbVe7j9L7xPOD8StWXN7ib RRzCASMnQASWONM5QqJo/Pm2doLg6BXrOE7v6D4S6qfkbxMJFF4OhKRvNeFsp4FuLz// hB7DFgyRq3dzw9C9Q7kq/jV2/zgNB0tk6TT1wZWIRSkwI4+dl6Y3t5K0eY45FFev/agl QRD8gLOj4JgQnGzUbr5qdRLuipCKq3lVvpBEvj9ONGwRujtgRveDfm6kP1roRZCizByy VsCCsO/zPYmbhY3n64RBLLGLO7ICzq4CJx9Zs7qiOgBxHSffMSnOSSTwz5ei0xZ3beSP j2Jg==
X-Gm-Message-State: APjAAAUytdTViEX+cwcRi0MgDNTJ5o8zZCOQ2Wnig1ZQogAAtYvUFFfm Fj7/CTWr2ycc1n5K0w8KkCbQHoyv5CV/wMCxEPs=
X-Google-Smtp-Source: APXvYqz9hXgvjHLKGaLwjssaYaF5G7PuFK6kTsRk0iMLFdgzx0JHQpuIrTDfODJw1Lu+3Hdbu62mLn4oI2+mISABe40=
X-Received: by 2002:a1c:2245:: with SMTP id i66mr282311wmi.19.1557750026885; Mon, 13 May 2019 05:20:26 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net> <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com>  <10e7ee87-4877-4790-dbdc-8f599d401cbe@aol.com>
In-Reply-To: <10e7ee87-4877-4790-dbdc-8f599d401cbe@aol.com>
From: Nat Sakimura 
Date: Mon, 13 May 2019 14:20:15 +0200
Message-ID: 
To: George Fletcher 
Cc: Dave Tonge ,  Sascha Preibisch , oauth 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
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, 13 May 2019 12:20:31 -0000

Indeed but at the same time, it may be needed for the AS to keep it
anyways for compliance purposes.

I have not gone through the thread yet, but here is my brief response
to Torsten's post.

https://nat.sakimura.org/2019/05/12/comments-back-to-transaction-authorizat=
ion-or-why-we-need-to-re-think-oauth-scopes-by-torsten/

Cheers,

Nat Sakimura

On Fri, May 10, 2019 at 10:27 PM George Fletcher
 wrote:
>
> One thing to keep in mind with the "Push Request Object" model and the co=
ncept of a more detailed scope structure, if the specified values are not f=
or a single transaction, then the AS will be required to keep the "Pushed R=
equest Object" for the "lifetime" of the access_token and possibly the refr=
esh_token depending on the use case. This could have some implementation is=
sues for the AS.
>
> Thanks,
> George
>
> On 5/10/19 9:52 AM, Dave Tonge wrote:
>
> Thanks Torsten for this article - it is incredibly helpful.
>
> I'm very much in favour of the "structured_scope" approach.
>
> While I understand George's point I think the line is very blurred betwee=
n coarse-grained scopes and fine-grained transaction consent. In addition f=
ine-grained authorisation metadata is needed for ongoing access APIs as wel=
l, e.g. how can a client ask for ongoing access to:
>  - transactions in a users accounts with ids abc123 and abc124
>
> From a UX perspective it is beneficial for the AS to ask the user for con=
sent once. The AS therefore needs to have all the information about relatin=
g to the consent available when the user is redirected to the authorization=
 endpoint. There should be a standard way for the Client to pass this data =
to the AS and I think structured scopes either sent as a query param or in =
a request object are a neat way of doing this.
>
> Dave
>
>
> _______________________________________________
> 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


From nobody Mon May 13 11:06: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 AD1B2120242 for ; Mon, 13 May 2019 11:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSuB27m4jihM for ; Mon, 13 May 2019 11:06:22 -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 2BDE112021C for ; Mon, 13 May 2019 11:06:21 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x4DI5vlR004926; Mon, 13 May 2019 14:06:11 -0400
Received: from w92expo8.exchange.mit.edu (18.7.74.62) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 13 May 2019 14:05:43 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo8.exchange.mit.edu (18.7.74.62) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 13 May 2019 14:05:56 -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, 13 May 2019 14:05:56 -0400
From: Justin Richer 
To: RFC Errata System 
CC: "dick.hardt@gmail.com" , "rdd@cert.org" , Benjamin J Kaduk , "Hannes.Tschofenig@gmx.net" , "rifaat.ietf@gmail.com" , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)
Thread-Index: AQHU/oc1voaHnCPdv0iQAbSytvG7DaZpswSA
Date: Mon, 13 May 2019 18:05:56 +0000
Message-ID: <24DA2F1C-3EDD-40D7-A613-F72E1B565E51@mit.edu>
References: <20190429122916.42411B81DDA@rfc-editor.org>
In-Reply-To: <20190429122916.42411B81DDA@rfc-editor.org>
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_24DA2F1C3EDD40D7A613F72E1B565E51mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)
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, 13 May 2019 18:06:25 -0000

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

SSBzZWUgdGhlIGludGVudCBvZiB0aGUgY2hhbmdlIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBp
cyBhY3R1YWxseSBhdCB0aGUgbGV2ZWwgb2YgYW4gZXJyYXR1bS4gVGhpcyBzZWVtcyB0byBiZSBh
IG5vcm1hdGl2ZSBjaGFuZ2Ugb24gYSBrZXkgZXh0ZW5zaW9uIHBvaW50Lg0KDQpBZGRpdGlvbmFs
bHksIHdpdGggdGhlIHNpbmdsZXRvbiBuYXR1cmUgaW1wb3NlZCBieSB0aGUgY3VycmVudCB0ZXh0
LCB0aGVyZeKAmXMgYSAxOjEgbWFwcGluZyBiZXR3ZWVuIHRoZSByZXF1ZXN0IHBhcmFtZXRlcnMg
YW5kIGEgSlNPTiBvYmplY3QsIGFzIHdvdWxkIGJlIGZvdW5kIGluIGEgc2lnbmVkIHJlcXVlc3Qg
b2JqZWN0LiBBbnl0aGluZyB0aGF0IGNoYW5nZXMgdGhhdCBhc3N1bXB0aW9uIHNob3VsZCBub3Qg
YmUgdGFrZW4gbGlnaHRseS4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBBcHIgMjksIDIwMTksIGF0IDg6
MjkgQU0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0
bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPj4gd3JvdGU6DQoNClRoZSBmb2xsb3dpbmcgZXJy
YXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzY3NDksDQoiVGhlIE9BdXRoIDIu
MCBBdXRob3JpemF0aW9uIEZyYW1ld29yayIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0
dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU3MDgNCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClR5cGU6IEVkaXRvcmlhbA0KUmVwb3J0ZWQgYnk6IEJy
aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCg0KU2VjdGlvbjogMy4x
IGFuZCAzLjINCg0KT3JpZ2luYWwgVGV4dA0KLS0tLS0tLS0tLS0tLQ0KUGFyYW1ldGVycyBzZW50
IHdpdGhvdXQgYSB2YWx1ZSBNVVNUIGJlIHRyZWF0ZWQgYXMgaWYgdGhleSB3ZXJlDQpvbWl0dGVk
IGZyb20gdGhlIHJlcXVlc3QuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpZ25vcmUN
CnVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFtZXRlcnMuICBSZXF1ZXN0IGFuZCByZXNwb25zZSBw
YXJhbWV0ZXJzDQpNVVNUIE5PVCBiZSBpbmNsdWRlZCBtb3JlIHRoYW4gb25jZS4NCg0KQ29ycmVj
dGVkIFRleHQNCi0tLS0tLS0tLS0tLS0tDQpQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVl
IE1VU1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUNCm9taXR0ZWQgZnJvbSB0aGUgcmVxdWVz
dC4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGlnbm9yZQ0KdW5yZWNvZ25pemVkIHJl
cXVlc3QgcGFyYW1ldGVycy4gIFJlcXVlc3QgYW5kIHJlc3BvbnNlIHBhcmFtZXRlcnMNCmRlZmlu
ZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBv
bmNlLg0KDQpOb3Rlcw0KLS0tLS0NCkFkZHMgdGhlIHRleHQgImRlZmluZWQgYnkgdGhpcyBzcGVj
aWZpY2F0aW9uIiB0byB0aGUgbGFzdCBzZW50ZW5jZSB0byBjbGFyaWZ5IHRoYXQgdGhlIHJlc3Ry
aWN0aW9uIG9ubHkgYXBwbGllcyB0byBwYXJhbWV0ZXJzIGRlZmluZWQgaW4gUkZDIDY3NDkgYW5k
IG5vdCB0byB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBvciBwYXJhbWV0ZXJzIGRlZmluZWQgYnkg
ZXh0ZW5zaW9uLg0KDQpJbnN0cnVjdGlvbnM6DQotLS0tLS0tLS0tLS0tDQpUaGlzIGVycmF0dW0g
aXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0K
dXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQg
b3INCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBw
YXJ0eQ0KY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0
LCBpZiBuZWNlc3NhcnkuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpSRkM2NzQ5IChkcmFmdC1pZXRmLW9hdXRoLXYyLTMxKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NClRpdGxlICAgICAgICAgICAgICAgOiBUaGUgT0F1dGggMi4wIEF1
dGhvcml6YXRpb24gRnJhbWV3b3JrDQpQdWJsaWNhdGlvbiBEYXRlICAgIDogT2N0b2JlciAyMDEy
DQpBdXRob3IocykgICAgICAgICAgIDogRC4gSGFyZHQsIEVkLg0KQ2F0ZWdvcnkgICAgICAgICAg
ICA6IFBST1BPU0VEIFNUQU5EQVJEDQpTb3VyY2UgICAgICAgICAgICAgIDogV2ViIEF1dGhvcml6
YXRpb24gUHJvdG9jb2wNCkFyZWEgICAgICAgICAgICAgICAgOiBTZWN1cml0eQ0KU3RyZWFtICAg
ICAgICAgICAgICA6IElFVEYNClZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgc2VlIHRoZSBpbnRlbnQgb2YgdGhlIGNoYW5n
ZSBidXQgSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYWN0dWFsbHkgYXQgdGhlIGxldmVsIG9mIGFu
IGVycmF0dW0uIFRoaXMgc2VlbXMgdG8gYmUgYSBub3JtYXRpdmUgY2hhbmdlIG9uIGEga2V5IGV4
dGVuc2lvbiBwb2ludC4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPkFkZGl0aW9uYWxseSwgd2l0aCB0aGUgc2luZ2xldG9uIG5hdHVyZSBp
bXBvc2VkIGJ5IHRoZSBjdXJyZW50IHRleHQsIHRoZXJl4oCZcyBhIDE6MSBtYXBwaW5nIGJldHdl
ZW4gdGhlIHJlcXVlc3QgcGFyYW1ldGVycyBhbmQgYSBKU09OIG9iamVjdCwgYXMgd291bGQgYmUg
Zm91bmQgaW4gYSBzaWduZWQgcmVxdWVzdCBvYmplY3QuIEFueXRoaW5nIHRoYXQgY2hhbmdlcyB0
aGF0IGFzc3VtcHRpb24gc2hvdWxkIG5vdCBiZSB0YWtlbg0KIGxpZ2h0bHkuJm5ic3A7PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6
IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+
DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciAyOSwgMjAxOSwg
YXQgODoyOSBBTSwgUkZDIEVycmF0YSBTeXN0ZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRp
dG9yQHJmYy1lZGl0b3Iub3JnIiBjbGFzcz0iIj5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVw
b3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNjc0OSw8YnIgY2xhc3M9IiI+DQomcXVvdDtU
aGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrJnF1b3Q7LjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy
IGNsYXNzPSIiPg0KWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJyIGNs
YXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTcw
OCIgY2xhc3M9IiI+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTcwODwvYT48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NClR5cGU6IEVkaXRvcmlhbDxiciBjbGFzcz0iIj4NClJl
cG9ydGVkIGJ5OiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20m
Z3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbjogMy4xIGFuZCAzLjI8YnIg
Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPcmlnaW5hbCBUZXh0PGJyIGNsYXNzPSIiPg0KLS0t
LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NClBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUg
TVVTVCBiZSB0cmVhdGVkIGFzIGlmIHRoZXkgd2VyZTxiciBjbGFzcz0iIj4NCm9taXR0ZWQgZnJv
bSB0aGUgcmVxdWVzdC4gJm5ic3A7VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3Jl
PGJyIGNsYXNzPSIiPg0KdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVycy4gJm5ic3A7UmVx
dWVzdCBhbmQgcmVzcG9uc2UgcGFyYW1ldGVyczxiciBjbGFzcz0iIj4NCk1VU1QgTk9UIGJlIGlu
Y2x1ZGVkIG1vcmUgdGhhbiBvbmNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNvcnJl
Y3RlZCBUZXh0PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpQYXJh
bWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5IHdl
cmU8YnIgY2xhc3M9IiI+DQpvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuICZuYnNwO1RoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciBNVVNUIGlnbm9yZTxiciBjbGFzcz0iIj4NCnVucmVjb2duaXplZCBy
ZXF1ZXN0IHBhcmFtZXRlcnMuICZuYnNwO1JlcXVlc3QgYW5kIHJlc3BvbnNlIHBhcmFtZXRlcnM8
YnIgY2xhc3M9IiI+DQpkZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIE5PVCBiZSBp
bmNsdWRlZCBtb3JlIHRoYW4gb25jZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3Rl
czxiciBjbGFzcz0iIj4NCi0tLS0tPGJyIGNsYXNzPSIiPg0KQWRkcyB0aGUgdGV4dCAmcXVvdDtk
ZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiZxdW90OyB0byB0aGUgbGFzdCBzZW50ZW5jZSB0
byBjbGFyaWZ5IHRoYXQgdGhlIHJlc3RyaWN0aW9uIG9ubHkgYXBwbGllcyB0byBwYXJhbWV0ZXJz
IGRlZmluZWQgaW4gUkZDIDY3NDkgYW5kIG5vdCB0byB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBv
ciBwYXJhbWV0ZXJzIGRlZmluZWQgYnkgZXh0ZW5zaW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCkluc3RydWN0aW9uczo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tPGJyIGNsYXNz
PSIiPg0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQm
cXVvdDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyIGNsYXNzPSIiPg0KdXNlICZxdW90O1JlcGx5
IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJy
IGNsYXNzPSIiPg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVy
aWZ5aW5nIHBhcnR5ICZuYnNwOzxiciBjbGFzcz0iIj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRo
ZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiA8YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi
ciBjbGFzcz0iIj4NClJGQzY3NDkgKGRyYWZ0LWlldGYtb2F1dGgtdjItMzEpPGJyIGNsYXNzPSIi
Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpU
aXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFRoZSBPQXV0aCAyLjAgQXV0aG9yaXph
dGlvbiBGcmFtZXdvcms8YnIgY2xhc3M9IiI+DQpQdWJsaWNhdGlvbiBEYXRlICZuYnNwOyZuYnNw
OyZuYnNwOzogT2N0b2JlciAyMDEyPGJyIGNsYXNzPSIiPg0KQXV0aG9yKHMpICZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogRC4gSGFy
ZHQsIEVkLjxiciBjbGFzcz0iIj4NCkNhdGVnb3J5ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogUFJPUE9TRUQgU1RBTkRB
UkQ8YnIgY2xhc3M9IiI+DQpTb3VyY2UgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBXZWIgQXV0aG9y
aXphdGlvbiBQcm90b2NvbDxiciBjbGFzcz0iIj4NCkFyZWEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7OiBTZWN1cml0eTxiciBjbGFzcz0iIj4NClN0cmVhbSAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs6IElFVEY8YnIgY2xhc3M9IiI+DQpWZXJpZnlpbmcgUGFydHkgJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7OiBJRVNHPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0
aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpPQXV0aEBpZXRmLm9yZzxiciBjbGFzcz0iIj4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_24DA2F1C3EDD40D7A613F72E1B565E51mitedu_--


From nobody Mon May 13 12:21: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 98E0F12023C for ; Mon, 13 May 2019 12:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level: 
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 Iy5xM83PvOe3 for ; Mon, 13 May 2019 12:20:57 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 D0E4D1200C5 for ; Mon, 13 May 2019 12:20:56 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id h126so9924663lfh.4 for ; Mon, 13 May 2019 12:20:56 -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=TjVwjjqaE9XxGutlyg1gG767QRNISSJ19F6z58De9rc=; b=VvYLvfcJt6DiW4uy5hFxBMsaLkwIUEENNAB0Tc9RCGMUgE2TKYhoplt6LBX64ts3tG ntiYZrZt5uhVgpfs8gqevm1gRw3MgtJMknu5xA390e7MwbKa6r+VMt19ulgzekzViLA3 fPDy2K+K6WlfOl5upheCv2EBagi+T008mBnHFTXQs0kzAXpLiO8XlNbf3ko54z27540p PGyNmdBIDyNwwNLnNqzV/AQhUh0LbFABsVtjr4iYrcQ4NJx6w0ny4EjigzNLQrf0AiqA SiVQw2sCTrmax4kicD5wQShk4+QaS0N4W3YLpf+Ey0bWFsYwlIc93HxrbGzlHjwSCNdk aZjw==
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=TjVwjjqaE9XxGutlyg1gG767QRNISSJ19F6z58De9rc=; b=R5fqK7FUhpWUfyEkJXX+A39v9dLzdlxyVeyil8YiNHz0KC+RF/lbHd8J5f4N0iNL6Z gBzEC+WbSBMlMZmERjmLy6iDAU1bciZHbjZNxs4TEtDG4su/SLPvetiwjMcjjYE/kJNw EM2/d9pt+5KxTo7ic3w9ymE+OX4OpE57ZHU1UrqcTMrF9c6mtiYjCSvFHD1O2rVoKQlO EGSSRABF7z62sKS0BVeQ1dbZ+OAk91tsLG/DPUCPcK1v8MpvfGxtH0rDrHyUVzbrpaXS ySUV4HiOr12SFUCevGmmMSvrBLWbe4KUVB3cYrgd7454CRS4VZV4gqkQSKnlQmyRZgNO VvZQ==
X-Gm-Message-State: APjAAAXgHrdQAcyy4GTU9Vs7jEgCTS56o0l7IhkDvDHLP8YL4clTaFEk XnxcLZ1IJ5ppSIh+UDP9sMfmnx3ubpalVsjfmnhNrQ==
X-Google-Smtp-Source: APXvYqwKchlVm+Yjnmneb3pgHqpvy8Mu5Vd+A224LaZLxyBqHq3jZ1KBziR3epeUKnJsgCMKMp8Xe46BccM1mCaGV/I=
X-Received: by 2002:ac2:4357:: with SMTP id o23mr15358394lfl.146.1557775254207;  Mon, 13 May 2019 12:20:54 -0700 (PDT)
MIME-Version: 1.0
References: <20190429122916.42411B81DDA@rfc-editor.org> <24DA2F1C-3EDD-40D7-A613-F72E1B565E51@mit.edu>
In-Reply-To: <24DA2F1C-3EDD-40D7-A613-F72E1B565E51@mit.edu>
From: William Denniss 
Date: Mon, 13 May 2019 12:20:42 -0700
Message-ID: 
To: Justin Richer 
Cc: RFC Errata System , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ab4b6f0588c9d038"
Archived-At: 
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)
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, 13 May 2019 19:21:00 -0000

--000000000000ab4b6f0588c9d038
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 to Justin

Could this be handled in the extension spec potentially? Eg calling out
that OAuth has that requirement, but documenting an extension-specific case
that modifies it?

William


*From: *Justin Richer 
*Date: *Mon, May 13, 2019 at 11:06 AM
*To: *RFC Errata System
*Cc: *oauth@ietf.org

I see the intent of the change but I don=E2=80=99t think this is actually a=
t the
> level of an erratum. This seems to be a normative change on a key extensi=
on
> point.
>
> Additionally, with the singleton nature imposed by the current text,
> there=E2=80=99s a 1:1 mapping between the request parameters and a JSON o=
bject, as
> would be found in a signed request object. Anything that changes that
> assumption should not be taken lightly.
>
> =E2=80=94 Justin
>
> On Apr 29, 2019, at 8:29 AM, RFC Errata System 
> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5708
>
> --------------------------------------
> Type: Editorial
> Reported by: Brian Campbell 
>
> Section: 3.1 and 3.2
>
> Original Text
> -------------
> Parameters sent without a value MUST be treated as if they were
> omitted from the request.  The authorization server MUST ignore
> unrecognized request parameters.  Request and response parameters
> MUST NOT be included more than once.
>
> Corrected Text
> --------------
> Parameters sent without a value MUST be treated as if they were
> omitted from the request.  The authorization server MUST ignore
> unrecognized request parameters.  Request and response parameters
> defined by this specification MUST NOT be included more than once.
>
> Notes
> -----
> Adds the text "defined by this specification" to the last sentence to
> clarify that the restriction only applies to parameters defined in RFC 67=
49
> and not to unrecognized parameters or parameters defined by extension.
>
> 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.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> 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
>

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


+1 to Justin

=

Could this be handled in the extension spec potentially? =
Eg calling out that OAuth has that requirement, but documenting an extensio=
n-specific case that modifies it?

William


<=
strong>From: Justin Richer <jricher@mit.edu>
Date: =
Mon, May 13, 2019 at 11:06 AM
To: RFC Errata System
=
Cc: oauth@ietf.org






I see the intent of the change but I don=E2=80=99t think this is actually a=
t the level of an erratum. This seems to be a normative change on a key ext=
ension point.=C2=A0






Additionally, with the singleton nature imposed by the current text, t=
here=E2=80=99s a 1:1 mapping between the request parameters and a JSON obje=
ct, as would be found in a signed request object. Anything that changes tha=
t assumption should not be taken
 lightly.=C2=A0








=E2=80=94 Justin









On Apr 29, 2019, at 8:29 AM, RFC Errata System <rfc-editor@rfc-editor.org&g=
t; wrote:






The following errata report has been submitted for RFC6749,

"The OAuth 2.0 Authorization Framework".



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

You may review the report below and at:

http=
://www.rfc-editor.org/errata/eid5708



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

Type: Editorial

Reported by: Brian Campbell <bcampbell@pingidentity.com>



Section: 3.1 and 3.2



Original Text

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

Parameters sent without a value MUST be treated as if they were

omitted from the request.=C2=A0 The authorization server MUST ignore

unrecognized request parameters.=C2=A0 Request and response parameters

MUST NOT be included more than once.



Corrected Text

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

Parameters sent without a value MUST be treated as if they were

omitted from the request.=C2=A0 The authorization server MUST ignore

unrecognized request parameters.=C2=A0 Request and response parameters

defined by this specification MUST NOT be included more than once.



Notes

-----

Adds the text "defined by this specification" to the last sentenc=
e to clarify that the restriction only applies to parameters defined in RFC=
 6749 and not to unrecognized parameters or parameters defined by extension=
.



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. 



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

RFC6749 (draft-ietf-oauth-v2-31)

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

Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0: The OAuth 2.0 Authorization Framework

Publication Date =C2=A0=C2=A0=C2=A0: October 2012

Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: D. =
Hardt, Ed.

Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
: PROPOSED STANDARD

Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=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=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0: IETF

Verifying Party =C2=A0=C2=A0=C2=A0=C2=A0: IESG



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000ab4b6f0588c9d038--


From Shishir.Narain@lloydsbanking.com  Tue May 14 00:45: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 011F01201E4 for ; Tue, 14 May 2019 00:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lloydsbanking.com header.b=Rl/WYDvl; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=lloydsbanking.onmicrosoft.com header.b=A/W3NpG/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXNIsIhxtaHq for ; Tue, 14 May 2019 00:45:11 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.3]) (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 6ECE212008A for ; Tue, 14 May 2019 00:45:10 -0700 (PDT)
Received: from [85.158.142.97] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-a.eu-central-1.aws.symcld.net id E6/63-19557-3027ADC5; Tue, 14 May 2019 07:45:07 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0gUURiGPTPj7HiZGndNPyWjlgQrdnUpS7t AP6KECIqgwgQbc9wdWEebXUn7ZUSCWlqbhNtmhUlGhMoaWa633SxJisrKSumy6SZtSTchxKzm sl3/fDznvO9833sOZyhcW65JpLhSOycKrFVPRhJe/cQ3Ay6O5KS1DMzNuD0ZJNejrKamaWwry g7nhbyi0j3hlsDAV7K4/gRWGvT34+WoqxarQpEUwcwQUNnei6pQBBXBWOBYoIKQOZrRwdPm+w oDQ0P/hfpwlbfDu5pZXGYt40Fw916k3EjLDCCYmbqI1IUPweiZPkJdTCBocXgIdZ4Hh2DP9ZB Si0Gn40nom2cIPrX1KUlIJhd6HW8UjmWSoefmI43MOiYBZtt/aNT9BTB6xxNiI1x1NSqpCMnf NzyspKWZ3eCtdyt9EBMHXwcvYzLjTDyMjJ/F1BPFQKOrC1c5Dr53+km1D8Dpx72YyvFQ2TMd2 k8Ax+ep0G0sgAsdX3D5AMB04+D9OEmqw/LA1e4gVdNC6Lh1JMRJMHS2WgpESbwFhi6aj6H0U3 9FUlmAWYePPKUcIQZuO8eJf5mSPEugtTNVtS+Cumq/5n87zqTA4dMNmr8951DEJZSZJ/Jmi72 Q5a0GU1qawWRabjAZTKsyjOwBA2vkSgx7OcEuspJqZPfbjLaywr3WfKPA2d1Iem/5+5D7Gqpr NvtQAoXp59FjNU9ztHPyivLLLKzNkiuWWDmbD82nKD3QO4pHcrQxImfmSgt4q/Rof8lARetj6 RZZpm3FbKGNN6vSINpM9TX6G3Dqyss3Uu1UqtM5IdUXXrlOylVLCEUClxhPp++TWjByC0uJ8H vArx9jCCUl6mgUFhamjS7mxELe/q8eRPEU0utotxwkmhfsv3MEpYiYFDGTVyLa2T9SYjkKP/S qdVvKd+f7cu+6QNogVr8248HJx8n641mWtkZs+nl2U4or11i3inN9XJ3pHggk3XhYJhY0mMbO N8175Y/KyjR5NvFH38VNkb7FFQd3bp2JqnS0Ly3wvI09pMuqLXi9okIbWJnb6xxaVLcrdeOZ9 O7nG4bXfFjmK+tG54Ipj7r0hM3Cmpbioo39CZD+teUTBAAA
X-Env-Sender: Shishir.Narain@lloydsbanking.com
X-Msg-Ref: server-29.tower-222.messagelabs.com!1557819906!1819939!1
X-Originating-IP: [193.34.231.252]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received: 
X-StarScan-Version: 9.31.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26321 invoked from network); 14 May 2019 07:45:07 -0000
Received: from mailgate2.lloydstsb.co.uk (HELO MGWLSPET03F003.machine.group) (193.34.231.252) by server-29.tower-222.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 14 May 2019 07:45:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lloydsbanking.com; i=@lloydsbanking.com; l=8192; q=dns/txt; s=LBG20130210; t=1557819906; x=1589355906; h=from:to:subject:date:message-id:mime-version; bh=K3A4DWxrsoaYd6XPSI29UAJ4Fg0Z+Q0aPDZ1CnyJT3I=; b=Rl/WYDvljxBvLrLke2uIcSD/aDnvic4rWFMe9uh1NR6avSA2Nf4qYtcu 3IOOCQI2LCa3MuIYu361l/qa04lzd8052gtYR2mVpS03eb0FURYSDrB91 7UnFS5T/PU0vVCrSQBSOfMTn7o4Rb/09xDwiwy21xBIh7lLyp16J1r/Fi ZZY76wWsIoPSK4aKF1ImxLb+hUZVuT1gyy//Y6GnGCJmajgiluoa/0TZV tXVJXkuqeYVbjWbtCBOqIGBrfiJ/XaZkwloNmA5WrlMZ10h8GC8OrR4R8 OOM82xA/iti2FipLAdWiENKVUz7NNUwwPmISZO3t355pl10WglCX4O0zQ g==;
IronPort-SDR: +fEnzJ18cyYaj+eeeAXFgJLklBg1xApF/IaKFNEaSCZoTKMbkNKuUlyhKEAJ1fU9TfeSGrd1gW Vv2nkSafsbCQ==
LexicalCheck: NOTOK
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,467,1549929600";  d="scan'208,217";a="478941548"
Received: from unknown (HELO EXCLGVIRTUAL00B.Global.Lloydstsb.Com) ([10.12.225.232]) by MGWLSPET03F003.machine.group with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2019 08:45:05 +0100
Received: from EXCLGP0005.Global.Lloydstsb.Com (10.79.135.103) by EXCLGVIRTUAL00B.Global.Lloydstsb.Com (10.125.226.11) with Microsoft SMTP Server (TLS) id 8.3.515.0; Tue, 14 May 2019 08:45:05 +0100
Received: from EXCLGV0013.Global.Lloydstsb.Com (10.75.49.45) by EXCLGP0005.Global.Lloydstsb.Com (10.79.135.103) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 14 May 2019 08:45:05 +0100
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (10.79.242.118) by EXCLGV0013.Global.Lloydstsb.Com (10.75.49.45) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 14 May 2019 08:45:05 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lloydsbanking.onmicrosoft.com; s=selector2-lloydsbanking-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Eq2OT0gTddiaRkzvEPSRWTPq26l9pGS+Nnljl8h7ZoQ=; b=A/W3NpG/4Q2G5I2qUPID+Pbk5S9/wHYv8hYcouTfn6tadDrM9Jbtz0PCSLzUJQgnUqmQ0MKdYIV8AaSl91TiWi9x9Edqz/mQ88RajGLHS7H3Bfj+ENzdxxTEkPndbV0/5QQrvAEqc+oTE29+2Wp3Vy6NCnl0B2EI8FoBPiaNPXk=
Received: from CWXP123MB2214.GBRP123.PROD.OUTLOOK.COM (20.179.109.150) by CWXP123MB1894.GBRP123.PROD.OUTLOOK.COM (20.179.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Tue, 14 May 2019 07:45:03 +0000
Received: from CWXP123MB2214.GBRP123.PROD.OUTLOOK.COM ([fe80::1ca4:dba9:96e:ffc]) by CWXP123MB2214.GBRP123.PROD.OUTLOOK.COM ([fe80::1ca4:dba9:96e:ffc%7]) with mapi id 15.20.1878.024; Tue, 14 May 2019 07:45:03 +0000
From: "NARAIN, SHISHIR (DD & MI (L), Group Transformation)" 
To: "oauth@ietf.org" 
Thread-Topic: Query on RFC6749
Thread-Index: AdUKJ3OMXVIvW9o7QE+BqBZU+RkdjQ==
Date: Tue, 14 May 2019 07:45:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-version: 11.0.300.84
dlp-reaction: no-action
dlp-product: dlpe-windows
x-lloydsclassification: Public
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvbGJnLmludHJhbmV0Lmdyb3VwXC9sYmdfY29tbXNcLyIsImlkIjoiNDdhMzM1MGYtNzQyMC00MWEyLTgxNzAtMTcyNjU0ZmQ4MTJlIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiUHVibGljIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuOS4yIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlcL21qVDRWOUVlQzVDblN6Q1FUUHlqcnpjNE94eWtDNnBENnY4eFpcLzg0blJqNngyc1dTSk1NNEJBRWhCSWRMZiJ9
x-originating-ip: [141.92.69.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b9c42d1d-0cb4-449e-25f5-08d6d8401388
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CWXP123MB1894; 
x-ms-traffictypediagnostic: CWXP123MB1894:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(346002)(376002)(136003)(40764003)(199004)(189003)(2501003)(102836004)(486006)(55016002)(52536014)(6916009)(7736002)(66446008)(256004)(14444005)(186003)(2351001)(66556008)(66476007)(64756008)(74316002)(71200400001)(26005)(73956011)(476003)(76116006)(66946007)(790700001)(6116002)(3846002)(14454004)(1730700003)(81166006)(71190400001)(8676002)(81156014)(8936002)(7116003)(53936002)(66066001)(478600001)(606006)(966005)(33656002)(316002)(72206003)(4744005)(99286004)(6436002)(54896002)(6306002)(2906002)(68736007)(6506007)(236005)(25786009)(9686003)(7696005)(86362001)(5640700003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:CWXP123MB1894; H:CWXP123MB2214.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: lloydsbanking.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cqHMCbdUHpbMpkMY+WksY9Rm0PdQmKiw7RfBTP82SjsPOBaKU8G/iiXzRLifLhn1pW859sZhC+3xmMXjVw7pcbJ5H0TS31MwssITIFWWWYQQ/+grPfC0M8k7cSyXDXqfrRSK/r+aifclB4EoC1lRyAPIGK8TSfcN2opdD16hg1jtV38sDrwYqAsJ6xJkJTd5l9CO/cUs3TCx30AUvWYxghDeXAbkCwQhFv29wbxLKysn8Z+0tWfEVXlNKmII3XWh9OU/FypWAmztSlDqrpL0de/O6cqbO+W9aoLitIn3RHAwTN04FrRcdTRQjiAGW6pR6ArZqs0fqO3B5Qb060CpwQ9iqYsUkW6NTxhtPXW2NPbiXiqwuK7NNVCWTLBon0ooqUW4X/0qZgGlAZVPUsslkJhlY0lV8MeKfw2Fvr/oI/w=
Content-Type: multipart/alternative; boundary="_000_CWXP123MB2214A956DF5C9EE7156E1EC295080CWXP123MB2214GBRP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b9c42d1d-0cb4-449e-25f5-08d6d8401388
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 07:45:03.5420 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3ded2960-214a-46ff-8cf4-611f125e2398
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP123MB1894
X-OriginatorOrg: lloydsbanking.com
X-Cfilter: Forwarded
Archived-At: 
X-Mailman-Approved-At: Tue, 14 May 2019 08:01:27 -0700
Subject: [OAUTH-WG] Query on RFC6749
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, 14 May 2019 07:47:59 -0000

--_000_CWXP123MB2214A956DF5C9EE7156E1EC295080CWXP123MB2214GBRP_
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q2xhc3NpZmljYXRpb246IFB1YmxpYwoKSGVsbG8sCkkgaGF2ZSBhIHF1ZXJ5IGFib3V0IE9BdXRo
IGVycm9yIG1lc3NhZ2Ugc3RydWN0dXJlLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgbWVzc2FnZSBz
dHJ1Y3R1cmUgaXMgZGVmaW5lZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0
OSNzZWN0aW9uLTUuMiBidXQgSSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5nIHJlc3BvbnNl
IGlzIGEgdmFsaWQgT0F1dGggcmVzcG9uc2UgYXMgcGVyIHRoZSBzcGVjPwoKSFRUUC8xLjEgNDAw
IEJhZCBSZXF1ZXN0CkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04
CkNhY2hlLUNvbnRyb2w6IG5vLXN0b3JlClByYWdtYTogbm8tY2FjaGUKewogICAgICAgICAgICAg
ICAgImVycm9yIjogImludmFsaWRfcmVxdWVzdCIsCiAgICAgICAgICAgICAgICAidHJhbnNhY3Rp
b25faWQiOiAiMTEyMjIzMzMiCn0KCkkgd2FudGVkIHRvIGNoZWNrIGlmIGFkZGl0aW9uYWwgY2xh
aW0gbGlrZSB0cmFuc2FjdGlvbl9pZCBjYW4gYmUgYWRkZWQgaW4gdGhlIHJlc3BvbnNlLgoKVGhh
bmtzIGZvciB5b3VyIGhlbHAuCgpSZWdhcmRzLApTaGlzaGlyIE5hcmFpbgpBUEkgRW5hYmxlciBU
ZWFtLApMbG95ZHMgQmFua2luZyBHcm91cCB8IEdyb3VwIElUCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCk06ICs0NCAoMCkgNzQgMzg4OSAzODU3IHwgRTogU2hpc2hpci5OYXJhaW5A
bGxveWRzYmFua2luZy5jb208bWFpbHRvOlNoaXNoaXIuTmFyYWluQGxsb3lkc2JhbmtpbmcuY29t
PgpBOiAybmQgRmxvb3IsIFJlZCBMaW9uIENvdXJ0LCA0Ni00OCBQYXJrIFN0cmVldCwgTG9uZG9u
LCBTRTEgOUVRCgoKCkxsb3lkcyBCYW5raW5nIEdyb3VwIHBsYy4gUmVnaXN0ZXJlZCBPZmZpY2U6
IFRoZSBNb3VuZCwgRWRpbmJ1cmdoIEVIMSAxWVouIFJlZ2lzdGVyZWQgaW4gU2NvdGxhbmQgbm8u
IFNDOTUwMDAuIFRlbGVwaG9uZTogMDEzMSAyMjUgNDU1NS4KCgoKTGxveWRzIEJhbmsgcGxjLiBS
ZWdpc3RlcmVkIE9mZmljZTogMjUgR3Jlc2hhbSBTdHJlZXQsIExvbmRvbiBFQzJWIDdITi4gUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBuby4gMjA2NS4gVGVsZXBob25lIDAyMDc2MjYg
MTUwMC4KCgoKQmFuayBvZiBTY290bGFuZCBwbGMuIFJlZ2lzdGVyZWQgT2ZmaWNlOiBUaGUgTW91
bmQsIEVkaW5idXJnaCBFSDEgMVlaLiBSZWdpc3RlcmVkIGluIFNjb3RsYW5kIG5vLiBTQzMyNzAw
MC4gVGVsZXBob25lOiAwMzQ1NyA4MDEgODAxLiAKCgoKTGxveWRzIEJhbmsgQ29ycG9yYXRlIE1h
cmtldHMgcGxjLiBSZWdpc3RlcmVkIG9mZmljZTogMjUgR3Jlc2hhbSBTdHJlZXQsIExvbmRvbiBF
QzJWIDdITi4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBuby4gMTAzOTk4NTAuCgoK
Ckxsb3lkcyBCYW5rIHBsYywgQmFuayBvZiBTY290bGFuZCBwbGMgYW5kIExsb3lkcyBCYW5rIENv
cnBvcmF0ZSBNYXJrZXRzIHBsYyBhcmUgYXV0aG9yaXNlZCBieSB0aGUgUHJ1ZGVudGlhbCBSZWd1
bGF0aW9uIEF1dGhvcml0eSBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNpYWwgQ29uZHVjdCBB
dXRob3JpdHkgYW5kIFBydWRlbnRpYWwgUmVndWxhdGlvbiBBdXRob3JpdHkuCgoKCkxsb3lkcyBC
YW5rIENvcnBvcmF0ZSBNYXJrZXRzIFdlcnRwYXBpZXJoYW5kZWxzYmFuayBHbWJIIGlzIGEgd2hv
bGx5LW93bmVkIHN1YnNpZGlhcnkgb2YgTGxveWRzIEJhbmsgQ29ycG9yYXRlIE1hcmtldHMgcGxj
LiAgTGxveWRzIEJhbmsgQ29ycG9yYXRlIE1hcmtldHMgV2VydHBhcGllcmhhbmRlbHNiYW5rIEdt
YkggaGFzIGl0cyByZWdpc3RlcmVkIG9mZmljZSBhdCBUaHVybi11bmQtVGF4aXMgUGxhdHogNiwg
NjAzMTMgRnJhbmtmdXJ0LCBHZXJtYW55LiBUaGUgY29tcGFueSBpcyByZWdpc3RlcmVkIHdpdGgg
dGhlIEFtdHNnZXJpY2h0IEZyYW5rZnVydCBhbSBNYWluLCBIUkIgMTExNjUwLiBMbG95ZHMgQmFu
ayBDb3Jwb3JhdGUgTWFya2V0cyBXZXJ0cGFwaWVyaGFuZGVsc2JhbmsgR21iSCBpcyBzdXBlcnZp
c2VkIGJ5IHRoZSBCdW5kZXNhbnN0YWx0IGbDvHIgRmluYW56ZGllbnN0bGVpc3R1bmdzYXVmc2lj
aHQuCgoKCkhhbGlmYXggaXMgYSBkaXZpc2lvbiBvZiBCYW5rIG9mIFNjb3RsYW5kIHBsYy4KCgoK
SEJPUyBwbGMuIFJlZ2lzdGVyZWQgT2ZmaWNlOiBUaGUgTW91bmQsIEVkaW5idXJnaCBFSDEgMVla
LiBSZWdpc3RlcmVkIGluIFNjb3RsYW5kIG5vLiBTQzIxODgxMy4KCgoKVGhpcyBlLW1haWwgKGlu
Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIHByaXZhdGUgYW5kIGNvbmZpZGVudGlhbCBhbmQg
bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBtYXRlcmlhbC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGl0
IChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpbW1lZGlhdGVseS4gWW91IG11c3Qgbm90IGNv
cHksIGRpc3RyaWJ1dGUsIGRpc2Nsb3NlIG9yIHVzZSBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGlu
IGl0IG9yIGFueSBhdHRhY2htZW50cy4gVGVsZXBob25lIGNhbGxzIG1heSBiZSBtb25pdG9yZWQg
b3IgcmVjb3JkZWQuCg==

--_000_CWXP123MB2214A956DF5C9EE7156E1EC295080CWXP123MB2214GBRP_
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8IS0tW2lm
ICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9Cm9cOioge2Jl
aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN
TCk7fQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30KPC9zdHlsZT48IVtlbmRp
Zl0tLT48c3R5bGU+PCEtLQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250
LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpA
Zm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0
IDMgMiA0O30KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglm
b250LXNpemU6MTEuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgltc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsKCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojMDU2M0MxOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsKCWNvbG9yOiM5NTRGNzI7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30K
c3Bhbi5FbWFpbFN0eWxlMTcKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOwoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjp3aW5kb3d0ZXh0O30KLk1zb0No
cERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOwoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQpAcGFnZSBXb3Jk
U2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy
LjBwdCA3Mi4wcHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+
Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+CjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2xhc3Np
ZmljYXRpb246CjxzcGFuIHN0eWxlPSJjb2xvcjojMzNDQzAwIj5QdWJsaWM8L3NwYW4+PC9zcGFu
Pjwvc3Ryb25nPjxicj4KPGJyPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48
L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwv
cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgcXVlcnkgYWJvdXQgT0F1dGggZXJyb3Ig
bWVzc2FnZSBzdHJ1Y3R1cmUuIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBtZXNzYWdlIHN0cnVjdHVy
ZSBpcyBkZWZpbmVkIGF0CjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2
NzQ5I3NlY3Rpb24tNS4yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0
aW9uLTUuMjwvYT4gYnV0IEkgYW0gbm90IHN1cmUgaWYgdGhlIGZvbGxvd2luZyByZXNwb25zZSBp
cyBhIHZhbGlkIE9BdXRoIHJlc3BvbnNlIGFzIHBlciB0aGUgc3BlYz88bzpwPjwvbzpwPjwvcD4K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhUVFAvMS4xIDQwMCBCYWQgUmVxdWVz
dDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6
MzYuMHB0Ij5Db250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtODxvOnA+
PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij5DYWNoZS1Db250cm9sOiBuby1zdG9yZTxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5QcmFnbWE6IG5vLWNhY2hlPG86cD48L286
cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPns8
bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjODIyMDtlcnJvciYjODIy
MTs6ICYjODIyMDtpbnZhbGlkX3JlcXVlc3QmIzgyMjE7LDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJiM4MjIwO3RyYW5zYWN0aW9uX2lkJiM4MjIxOzogJiM4MjIwOzEx
MjIyMzMzJiM4MjIxOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij59PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnRlZCB0byBj
aGVjayBpZiBhZGRpdGlvbmFsIGNsYWltIGxpa2UgdHJhbnNhY3Rpb25faWQgY2FuIGJlIGFkZGVk
IGluIHRoZSByZXNwb25zZS48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBo
ZWxwLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyMCUiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tR0IiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIwJSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U2hp
c2hpciBOYXJhaW48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
bGluZS1oZWlnaHQ6MTIwJTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+QVBJIEVuYWJsZXIg
VGVhbSwKPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bGluZS1oZWlnaHQ6MTIwJSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bGluZS1o
ZWlnaHQ6MTIwJTtjb2xvcjojMDA4NjRGO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5MbG95
ZHMgQmFua2luZyBHcm91cCB8IEdyb3VwIElUPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtsaW5lLWhlaWdodDoxMjAlO2NvbG9yOm5hdnk7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPGRpdj4KPGRpdj4KPGRpdiBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtjb2xvcjpuYXZ5O21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLUdCIj4KPGhyIHNpemU9IjIiIHdpZHRoPSI1NDMiIHN0eWxlPSJ3aWR0aDo0MDcuMjVwdCIg
bm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6IzAwODY0RiIgYWxpZ249ImxlZnQiPgo8L3NwYW4+PC9k
aXY+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0
OjEyMCUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtj
b2xvcjojMDA4NjRGO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5NOgo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtjb2xvcjpibGFjaztt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+JiM0Mzs0NCAoMCkgNzQgMzg4OSAzODU3Cjwvc3Bh
bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Y29sb3I6
IzAwODY0Rjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+fCBFOgo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTIwJTttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1HQiI+PGEgaHJlZj0ibWFpbHRvOlNoaXNoaXIuTmFyYWluQGxsb3lkc2Jhbmtpbmcu
Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+U2hpc2hpci5OYXJhaW5AbGxveWRzYmFua2lu
Zy5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2xpbmUt
aGVpZ2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMjAlIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2xpbmUtaGVpZ2h0OjEyMCU7Y29sb3I6IzAwODY0Rjttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1HQiI+QToKPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2xpbmUtaGVpZ2h0OjEyMCU7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
R0IiPjJuZCBGbG9vciwgUmVkIExpb24gQ291cnQsIDQ2LTQ4IFBhcmsgU3RyZWV0LCBMb25kb24s
IFNFMSA5RVE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtsaW5lLWhlaWdodDox
MjAlO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rp
dj4KPHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAw
MDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNp
emU6IDEzcHg7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogMTAwJTsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDE1Ljg2cHg7IG9ycGhhbnM6IDI7
IHBhZGRpbmctYm90dG9tOiAwcHg7IHBhZGRpbmctbGVmdDogMHB4OyBwYWRkaW5nLXJpZ2h0OiAw
cHg7IHBhZGRpbmctdG9wOiAwcHg7IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjog
bm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7Ij4NCg0KPC9wPjxwIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29s
b3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJp
ZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y
bWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBtYXJnaW4tYm90
dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9w
OiAwcHg7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9u
ZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICZhbXA7cXVvdDtBcmlhbCIsc2Fucy1zZXJpZjsg
Zm9udC1zaXplOiAxMy4zM3B4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7
IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7Jz48YnI+PC9zcGFuPjwvcD48cCBz
dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGNvbG9yOiAjMDAwMDAwOyBmb250
LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4t
bGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBvcnBoYW5zOiAy
OyB0ZXh0LWFsaWduOiBsZWZ0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyI+PHNwYW4gc3R5bGU9J2Zv
bnQtZmFtaWx5OiAmYW1wO3F1b3Q7QXJpYWwiLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTMuMzNw
eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBw
eDsgbWFyZ2luLXRvcDogMHB4Oyc+TGxveWRzIEJhbmtpbmcgR3JvdXANCnBsYy4gUmVnaXN0ZXJl
ZCBPZmZpY2U6IFRoZSBNb3VuZCwgRWRpbmJ1cmdoIEVIMSAxWVouIFJlZ2lzdGVyZWQgaW4gU2Nv
dGxhbmQNCm5vLiBTQzk1MDAwLiBUZWxlcGhvbmU6IDAxMzEgMjI1IDQ1NTUuPC9zcGFuPjwvcD48
cCBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGNvbG9yOiAjMDAwMDAwOyBm
b250LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog
MTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln
aHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJn
aW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBvcnBoYW5z
OiAyOyB0ZXh0LWFsaWduOiBsZWZ0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyI+PHNwYW4gc3R5bGU9
J2ZvbnQtZmFtaWx5OiAmYW1wO3F1b3Q7QXJpYWwiLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTMu
MzNweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6
IDBweDsgbWFyZ2luLXRvcDogMHB4Oyc+PGJyPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImJhY2tncm91
bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFs
LGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFy
Z2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjog
bGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjwvcD48cCBzdHlsZT0iYmFja2dyb3VuZC1jb2xv
cjogdHJhbnNwYXJlbnQ7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogYXJpYWwsaGVsdmV0
aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6
IG5vcm1hbDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmln
aHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBsZWZ0OyB0
ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAmYW1wO3F1b3Q7
QXJpYWwiLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTMuMzNweDsgbWFyZ2luLWJvdHRvbTogMHB4
OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4Oyc+
TGxveWRzIEJhbmsgcGxjLg0KUmVnaXN0ZXJlZCBPZmZpY2U6IDI1IEdyZXNoYW0gU3RyZWV0LCBM
b25kb24gRUMyViA3SE4uIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZA0KYW5kIFdhbGVzIG5vLiAyMDY1
LiBUZWxlcGhvbmUgMDIwNzYyNiAxNTAwLjwvc3Bhbj48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQt
Y29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhl
bHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2lu
LXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVm
dDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtx
dW90O0FyaWFsIixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206
IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBw
eDsnPjxicj48L3NwYW4+PC9wPjxwIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVu
dDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fu
cy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dDogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBtYXJn
aW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJn
aW4tdG9wOiAwcHg7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7Ij48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xv
cjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlm
OyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0
b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6
IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsi
PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNlcmlmOyBm
b250LXNpemU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsg
bWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsnPkJhbmsgb2YgU2NvdGxhbmQgcGxj
Lg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFRoZSBNb3VuZCwgRWRpbmJ1cmdoIEVIMSAxWVouIFJlZ2lz
dGVyZWQgaW4gU2NvdGxhbmQgbm8uDQpTQzMyNzAwMC4gVGVsZXBob25lOiAwMzQ1NyA4MDEgODAx
LiZuYnNwOzwvc3Bhbj48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50
OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5z
LXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdp
bi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdp
bi10b3A6IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9u
OiBub25lOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNl
cmlmOyBmb250LXNpemU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6
IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsnPjxicj48L3NwYW4+PC9w
PjxwIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29sb3I6ICMwMDAwMDA7
IGZvbnQtZmFtaWx5OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXpl
OiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl
aWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBtYXJnaW4tYm90dG9tOiAwcHg7IG1h
cmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG9ycGhh
bnM6IDI7IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7Ij48c3BhbiBzdHls
ZT0nZm9udC1mYW1pbHk6ICZhbXA7cXVvdDtBcmlhbCIsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx
My4zM3B4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdo
dDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7Jz5MbG95ZHMgQmFuayBDb3Jwb3JhdGUNCk1hcmtldHMg
cGxjLiBSZWdpc3RlcmVkIG9mZmljZTogMjUgR3Jlc2hhbSBTdHJlZXQsIExvbmRvbiBFQzJWIDdI
Ti4gUmVnaXN0ZXJlZA0KaW4gRW5nbGFuZCBhbmQgV2FsZXMgbm8uIDEwMzk5ODUwLjwvc3Bhbj48
L3A+PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAw
MDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNp
emU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBweDsg
bWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3Jw
aGFuczogMjsgdGV4dC1hbGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjxzcGFuIHN0
eWxlPSdmb250LWZhbWlseTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNlcmlmOyBmb250LXNpemU6
IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJp
Z2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsnPjxicj48L3NwYW4+PC9wPjxwIHN0eWxlPSJiYWNr
Z3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBh
cmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7
IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG9ycGhhbnM6IDI7IHRleHQtYWxp
Z246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd2hpdGUtc3Bh
Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6
ICZhbXA7cXVvdDtBcmlhbCIsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMy4zM3B4OyBtYXJnaW4t
Ym90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4t
dG9wOiAwcHg7Jz5MbG95ZHMgQmFuayBwbGMsIEJhbmsNCm9mIFNjb3RsYW5kIHBsYyBhbmQgTGxv
eWRzIEJhbmsgQ29ycG9yYXRlIE1hcmtldHMgcGxjIGFyZSBhdXRob3Jpc2VkIGJ5IHRoZQ0KUHJ1
ZGVudGlhbCBSZWd1bGF0aW9uIEF1dGhvcml0eSBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNp
YWwgQ29uZHVjdA0KQXV0aG9yaXR5IGFuZCBQcnVkZW50aWFsIFJlZ3VsYXRpb24gQXV0aG9yaXR5
Ljwvc3Bhbj48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xv
cjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlm
OyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0
b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6
IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25l
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsi
PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNlcmlmOyBm
b250LXNpemU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsg
bWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsnPjxicj48L3NwYW4+PC9wPjxwIHN0
eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29sb3I6ICMwMDAwMDA7IGZvbnQt
ZmFtaWx5OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog
NDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1s
ZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG9ycGhhbnM6IDI7
IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7Ij48c3BhbiBzdHlsZT0nZm9u
dC1mYW1pbHk6ICZhbXA7cXVvdDtBcmlhbCIsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMy4zM3B4
OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4
OyBtYXJnaW4tdG9wOiAwcHg7Jz5MbG95ZHMgQmFuayBDb3Jwb3JhdGUgTWFya2V0cyBXZXJ0cGFw
aWVyaGFuZGVsc2JhbmsgR21iSCBpcw0KYSB3aG9sbHktb3duZWQgc3Vic2lkaWFyeSBvZiBMbG95
ZHMgQmFuayBDb3Jwb3JhdGUgTWFya2V0cyBwbGMuJm5ic3A7IExsb3lkcw0KQmFuayBDb3Jwb3Jh
dGUgTWFya2V0cyBXZXJ0cGFwaWVyaGFuZGVsc2JhbmsgR21iSCBoYXMgaXRzIHJlZ2lzdGVyZWQg
b2ZmaWNlIGF0DQpUaHVybi11bmQtVGF4aXMgUGxhdHogNiwgNjAzMTMgRnJhbmtmdXJ0LCBHZXJt
YW55LiBUaGUgY29tcGFueSBpcyByZWdpc3RlcmVkDQp3aXRoIHRoZSBBbXRzZ2VyaWNodCBGcmFu
a2Z1cnQgYW0gTWFpbiwgSFJCIDExMTY1MC4gTGxveWRzIEJhbmsgQ29ycG9yYXRlDQpNYXJrZXRz
IFdlcnRwYXBpZXJoYW5kZWxzYmFuayBHbWJIIGlzIHN1cGVydmlzZWQgYnkgdGhlIEJ1bmRlc2Fu
c3RhbHQgZsO8cg0KRmluYW56ZGllbnN0bGVpc3R1bmdzYXVmc2ljaHQuPC9zcGFuPjwvcD48cCBz
dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGNvbG9yOiAjMDAwMDAwOyBmb250
LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4t
bGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBvcnBoYW5zOiAy
OyB0ZXh0LWFsaWduOiBsZWZ0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyI+PHNwYW4gc3R5bGU9J2Zv
bnQtZmFtaWx5OiAmYW1wO3F1b3Q7QXJpYWwiLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTMuMzNw
eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBw
eDsgbWFyZ2luLXRvcDogMHB4Oyc+PGJyPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQt
Y29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhl
bHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2lu
LXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVm
dDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtx
dW90O0FyaWFsIixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206
IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBw
eDsnPkhhbGlmYXggaXMgYSBkaXZpc2lvbg0Kb2YgQmFuayBvZiBTY290bGFuZCBwbGMuPC9zcGFu
PjwvcD48cCBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGNvbG9yOiAjMDAw
MDAwOyBmb250LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQt
c2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u
dC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbWFyZ2luLWJvdHRvbTogMHB4
OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBv
cnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBsZWZ0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQt
aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyI+PHNwYW4g
c3R5bGU9J2ZvbnQtZmFtaWx5OiAmYW1wO3F1b3Q7QXJpYWwiLHNhbnMtc2VyaWY7IGZvbnQtc2l6
ZTogMTMuMzNweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBtYXJnaW4t
cmlnaHQ6IDBweDsgbWFyZ2luLXRvcDogMHB4Oyc+PGJyPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImJh
Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6
IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQt
c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBw
eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3JwaGFuczogMjsgdGV4dC1h
bGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzLjMzcHg7IG1hcmdp
bi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdp
bi10b3A6IDBweDsnPkhCT1MgcGxjLiBSZWdpc3RlcmVkDQpPZmZpY2U6IFRoZSBNb3VuZCwgRWRp
bmJ1cmdoIEVIMSAxWVouIFJlZ2lzdGVyZWQgaW4gU2NvdGxhbmQgbm8uIFNDMjE4ODEzLjwvc3Bh
bj48L3A+PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAw
MDAwMDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250
LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG1hcmdpbi1ib3R0b206IDBw
eDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsg
b3JwaGFuczogMjsgdGV4dC1hbGlnbjogbGVmdDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsiPjxzcGFu
IHN0eWxlPSdmb250LWZhbWlseTogJmFtcDtxdW90O0FyaWFsIixzYW5zLXNlcmlmOyBmb250LXNp
emU6IDEzLjMzcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgbWFyZ2lu
LXJpZ2h0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsnPjxicj48L3NwYW4+PC9wPjxwIHN0eWxlPSJi
YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5
OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAw
cHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG9ycGhhbnM6IDI7IHRleHQt
YWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7Ij48c3BhbiBzdHlsZT0nZm9udC1mYW1p
bHk6ICZhbXA7cXVvdDtBcmlhbCIsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMy4zM3B4OyBtYXJn
aW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJn
aW4tdG9wOiAwcHg7Jz5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nDQphbnkgYXR0YWNobWVudHMpIGlz
IHByaXZhdGUgYW5kIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZA0KbWF0
ZXJpYWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXINCmFuZCBkZWxldGUgaXQgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu
dHMpIGltbWVkaWF0ZWx5LiBZb3UgbXVzdCBub3QgY29weSwNCmRpc3RyaWJ1dGUsIGRpc2Nsb3Nl
IG9yIHVzZSBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGluIGl0IG9yIGFueSBhdHRhY2htZW50cy4N
ClRlbGVwaG9uZSBjYWxscyBtYXkgYmUgbW9uaXRvcmVkIG9yIHJlY29yZGVkLjwvc3Bhbj48L3A+
PHAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBjb2xvcjogIzAwMDAwMDsg
Zm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6
IDEzcHg7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogMTAwJTsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDE1Ljg2cHg7IG9ycGhhbnM6IDI7IHBh
ZGRpbmctYm90dG9tOiAwcHg7IHBhZGRpbmctbGVmdDogMHB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7
IHBhZGRpbmctdG9wOiAwcHg7IHRleHQtYWxpZ246IGxlZnQ7IHRleHQtZGVjb3JhdGlvbjogbm9u
ZTsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7
Ij4NCg0KPHN0cm9uZyBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IGZvbnQt
ZmFtaWx5OiBhcmlhbCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4
OyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IDEwMCU7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA3MDA7IGxpbmUtaGVp
Z2h0OiAxNS44NnB4OyBwYWRkaW5nLWJvdHRvbTogMHB4OyBwYWRkaW5nLWxlZnQ6IDBweDsgcGFk
ZGluZy1yaWdodDogMHB4OyBwYWRkaW5nLXRvcDogMHB4OyI+PC9zdHJvbmc+PGVtIHN0eWxlPSJi
YWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGlj
YSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5v
bmU7IGZvbnQtc3RyZXRjaDogMTAwJTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LXZhcmlhbnQ6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgbGluZS1oZWlnaHQ6IDE1Ljg2cHg7IHBhZGRpbmct
Ym90dG9tOiAwcHg7IHBhZGRpbmctbGVmdDogMHB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7IHBhZGRp
bmctdG9wOiAwcHg7Ij48L2VtPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu
ZTsiPjwvc3Bhbj48c3ViIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgZm9u
dC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBmb250LXNpemU6IDlw
eDsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiAxMDAlOyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsaW5lLWhl
aWdodDogMTAuOThweDsgcGFkZGluZy1ib3R0b206IDBweDsgcGFkZGluZy1sZWZ0OiAwcHg7IHBh
ZGRpbmctcmlnaHQ6IDBweDsgcGFkZGluZy10b3A6IDBweDsiPjwvc3ViPjxzdXAgc3R5bGU9ImJh
Y2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyBmb250LWZhbWlseTogYXJpYWwsaGVsdmV0aWNh
LGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogOXB4OyBmb250LXNpemUtYWRqdXN0OiBub25l
OyBmb250LXN0cmV0Y2g6IDEwMCU7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxpbmUtaGVpZ2h0OiAxMC45OHB4OyBwYWRkaW5nLWJv
dHRvbTogMHB4OyBwYWRkaW5nLWxlZnQ6IDBweDsgcGFkZGluZy1yaWdodDogMHB4OyBwYWRkaW5n
LXRvcDogMHB4OyI+PC9zdXA+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjogbGluZS10aHJv
dWdoOyI+PC9zcGFuPjxmb250IHNpemU9IjMiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiB0cmFu
c3BhcmVudDsgZm9udC1mYW1pbHk6IGFyaWFsLGhlbHZldGljYSxjbGVhbixzYW5zLXNlcmlmOyBm
b250LXNpemU6IDE2cHg7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDogMTAw
JTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IDQwMDsgbGluZS1oZWlnaHQ6IDE5LjUycHg7IHBhZGRpbmctYm90dG9tOiAwcHg7IHBhZGRpbmct
bGVmdDogMHB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7IHBhZGRpbmctdG9wOiAwcHg7Ij48L2ZvbnQ+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47Ij48L3NwYW4+PC9wPjxw
IHN0eWxlPSJtYXJnaW46IDBweDsgdGV4dC1hbGlnbjogbGVmdDsgY29sb3I6ICMwMDAwMDA7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBmb250LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLGNsZWFuLHNhbnMtc2VyaWY7IGZvbnQt
c2l6ZTogMTNweDsgZm9udC12YXJpYW50OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyBvcnBoYW5zOiAyOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+PC9wPjxwIHN0eWxlPSJiYWNrZ3Jv
dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBhcmlh
bCxoZWx2ZXRpY2EsY2xlYW4sc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXNpemUt
YWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IDEwMCU7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiAxNS44NnB4OyBvcnBoYW5zOiAyOyBwYWRkaW5nLWJvdHRvbTogMHB4
OyBwYWRkaW5nLWxlZnQ6IDBweDsgcGFkZGluZy1yaWdodDogMHB4OyBwYWRkaW5nLXRvcDogMHB4
OyB0ZXh0LWFsaWduOiBsZWZ0OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyI+DQoNCjwvcD48L2JvZHk+
CjwvaHRtbD4K

--_000_CWXP123MB2214A956DF5C9EE7156E1EC295080CWXP123MB2214GBRP_--


From nobody Tue May 14 10:30:27 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 1E83712013F for ; Tue, 14 May 2019 10:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=datev.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwBmoJgPBgt0 for ; Tue, 14 May 2019 10:30:23 -0700 (PDT)
Received: from idvmailout04.datev.com (idvmailout04.datev.com [IPv6:2a00:e50:f155:7:5b23:6636:dabd:e882]) (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 124CC1200B1 for ; Tue, 14 May 2019 10:30:22 -0700 (PDT)
Received: from biem02.services.datev.de (idvmailproxy02v1.services.datev.de [10.252.82.156]) by idvmailout04.datev.com (Postfix) with ESMTP id 453PpK0zdyzK8Yk for ; Tue, 14 May 2019 19:30:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datev.de; s=Vxdd; t=1557855016; x=1562855016; bh=zV01zU+IVEZBFoGY6lnHT6aLznatTBBIYj9Zl3kWpuQ=; h=From:To:Subject:Date:Message-ID:Content-Type:from:reply-to: subject:date:to:cc:content-type:message-id; b=AsF2j+WGc2bUVQRA2srX4S9wB8NE5wqdA08F8uHEDADlEulio02Qu1VG7TLhiqKw8 DGwpzQ4u3+b4/RqFowLH6Sw3kmLp5f6eIut+vHp9BzxauXVxF2UyuuEvgqdfV2c6mk yv/tQNwJFr4zFWO6vdSPhsLxH7AH7B7sW+Xvs3e3kWaiZ/YSsscHZ0SeRxVrUXsvcB nXIB73ei00Dn/Ji80wARObe6vK9DWda6h8Wu+mgKlwOiUx19ENduXQyU2GYPZitTzm mRdrGjqmbrQMZy0XRCZFtEngufcl2Lc8Bo+9XHx5n0P2fRbkkgWedENU8jarewVtD1 K5nmDcojuYOwA==
X-Virus-Scanned: amavisd-new-2.11.0 on idvmailproxy02.services.datev.de
Received: from WEXCSB009.bk.datev.de (9.40.130.10.in-addr.arpa [10.130.40.9]) by biem02.services.datev.de (Postfix) with ESMTP id 453PpH51KPz28Gh for ; Tue, 14 May 2019 19:30:15 +0200 (CEST)
Received: from WEXCSB010.bk.datev.de (10.130.40.10) by WEXCSB009.bk.datev.de (10.130.40.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 14 May 2019 19:30:15 +0200
Received: from WEXCSB010.bk.datev.de ([10.130.40.10]) by WEXCSB010.bk.datev.de ([10.130.40.10]) with mapi id 15.01.1713.006; Tue, 14 May 2019 19:30:15 +0200
From: "Sahler, Frank" 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
Thread-Index: AdUKeoGh7sk3MCGsRg6qQGZqNy3Qaw==
Date: Tue, 14 May 2019 17:30:14 +0000
Message-ID: <8fe77fc8247e4eebb835b0f59bd4671e@datev.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
versandeinstellungen: Signieren=True; Verschluesseln=False; Konvertieren=True;  EnglischerDisclaimer=False
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha256; boundary="=-_DvNextPart_0006_6F92F0C2.22E2D10A"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
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, 14 May 2019 17:30:26 -0000

This is a multi-part message in MIME format.

--=-_DvNextPart_0006_6F92F0C2.22E2D10A
Content-Type: multipart/alternative;
	boundary="_000_8fe77fc8247e4eebb835b0f59bd4671edatevde_"

--_000_8fe77fc8247e4eebb835b0f59bd4671edatevde_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
I read in the dynamic client registration documentation of the company curi=
ty (https://developer.curity.io/tutorials/dynamic-client-registration-overv=
iew) that they use the scope "dcr" in the authorization request to get an i=
nitial access token i.e. a bearer token that only allows access to the regi=
stration endpoint.

Is this also from your point of view a feasible way to initiate the client =
registration?

Unfortunately the specification says nothing about how to get the token and=
 how its purpose is limited to the registration endpoint. These two points =
are "out of scope for this specification".

Regards
Frank Sahler
Security Consultant
DATEV eG, Nuremberg, Germany
________________________________
Signatur
Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit k?nnen=
 Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie ei=
ne Meldung erhalten, dass die Signatur ung?ltig ist oder nicht gepr?ft werd=
en kann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner. Informa=
tionen zu Zertifikaten und zur digitalen Signatur finden Sie unter https://=
www.datev.de/zertifikate im Internet.
________________________________
DATEV eG
90329 N?rnberg
Telefon +49 911 319-0

E-Mail: info@datev.de
Internet: https://www.datev.de
Sitz: 90429 N?rnberg, Paumgartnerstra?e 6-14
Registergericht N?rnberg, GenReg Nr. 70

Vorstand
Dr. Robert Mayr (Vorsitzender)
Eckhard Schwarzer (stellv. Vorsitzender)
Julia Bangerth
Prof. Dr. Peter Krug
Diana Windmei?er

Vorsitzender des Aufsichtsrates: Nicolas Hofmann


--_000_8fe77fc8247e4eebb835b0f59bd4671edatevde_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,




I read in the dynamic client registration documentat=
ion of the company curity (https://developer.curity.io/tutorial=
s/dynamic-client-registration-overview)
 that they use the scope "dcr" in the authorization request to ge=
t an initial access token i.e. a bearer token that only allows access to th=
e registration endpoint.



 


Is this also from your point of view a feasible way =
to initiate the client registration?


 


Unfortunately the specification says nothing about h=
ow to get the token and how its purpose is limited to the registration endp=
oint. These two points are "out of scope for this
 specification".


 


Regards


Frank Sahler


Security Consultant


DATEV eG, Nuremberg, Germany







Signatur

Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit kö=
;nnen Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn S=
ie eine Meldung erhalten, dass die Signatur ungültig ist oder nicht ge=
prüft werden kann, fehlt das Zertifikat zu
 dieser Signatur auf Ihrem Rechner. Informationen zu Zertifikaten und zur d=
igitalen Signatur finden Sie unter
https://www.datev.de/zertifika=
te im Internet.








DATEV eG

90329 Nürnberg		




Telefon +49 911 319-0






E-Mail: info@datev.de

Internet: https://www.datev.de		




Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14

Registergericht Nürnberg, GenReg Nr. 70		












Vorstand

Dr. Robert Mayr (Vorsitzender)

Eckhard Schwarzer (stellv. Vorsitzender) 

Julia Bangerth 

Prof. Dr. Peter Krug 

Diana Windmeißer 



Vorsitzender des Aufsichtsrates: Nicolas Hofmann 		










--_000_8fe77fc8247e4eebb835b0f59bd4671edatevde_--

--=-_DvNextPart_0006_6F92F0C2.22E2D10A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIE
4jCCA8qgAwIBAgIIf/FWQItVv5QwDQYJKoZIhvcNAQELBQAwOTELMAkGA1UEBhMCREUxETAPBgNV
BAoMCERBVEVWIGVHMRcwFQYDVQQDDA5DQSBEQVRFViBFTSAwMjAeFw0xNTExMDkxMjQ0MTNaFw0y
MDExMDkyMDU5NTlaMGkxFTATBgNVBAMMDEZyYW5rIFNhaGxlcjEdMBsGA1UEBRMUMDAwMDAwMDAw
MTU3OTQzMDUwMDExCzAJBgNVBAYTAkRFMSQwIgYJKoZIhvcNAQkBFhVmcmFuay5zYWhsZXJAZGF0
ZXYuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCT7xcR7XrtJJmFfeLDN08OFpec
4fZS/zlIBSeYQmN72U955L+Sf7Eq9y53X1Q3rf9kdpguMjOuXxisxGdd7zd1mgPc+1u7bxcjQT2i
GT8ALJLLBXuJWchs/PH73dbs+tsETsNqqUEl/wIKWakaj7vnc1qVD90zLL88lNaWHLSuYjtDKN/Q
K9jMIE/LFbLdSsOoSLbBTJ8uC1im+TfA98z44DN9Q5GzndHZVOhqSm/y+kMoSw08tBrWLZImjyrw
6NQlKmCQN0F+pw9oz3YMpcim9YNklUHWnaNuBFEZjgSFCHn4m2RwmIof9aTbttcF91z+YwRlO6Um
IeJbmBNqt+xdAgMBAAGjggG8MIIBuDBwBgNVHSMEaTBngBR1v3Ew7smsGxvy3Q5dM4/+zW/z26E9
pDswOTELMAkGA1UEBhMCREUxETAPBgNVBAoMCERBVEVWIGVHMRcwFQYDVQQDDA5DQSBEQVRFViBF
TSAwMoIQbhKe1F05f3FL5xNbleacFTAdBgNVHQ4EFgQUom5xsjii60QAQMNu6g2b5mFkENcwDgYD
VR0PAQH/BAQDAgSwMCAGA1UdEQQZMBeBFWZyYW5rLnNhaGxlckBkYXRldi5kZTCBtQYDVR0fBIGt
MIGqMDygOqA4hjZodHRwOi8vd3d3LmNybC5lc2VjdXJlLmRhdGV2LmRlL2NhLWRhdGV2LWVtLTAy
L2NybC5jcmwwaqBooGaGZGxkYXA6Ly9sZGFwLmNybC5lc2VjdXJlLmRhdGV2LmRlL0NOPUNBJTIw
REFURVYlMjBFTSUyMDAyLE89REFURVYlMjBlRyxDPURFP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp
c3QwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vd3d3LmRpci5lc2VjdXJlLmRh
dGV2LmRlMA0GCSqGSIb3DQEBCwUAA4IBAQCmokWR/VBT2mt49YiYbGRiO9BfcDYzW2Hm+zYNe0Bz
G4jjX869OPHIOh8AWJLnr9s0EpTo6oyFu/qL+lxXn67Vg8FgCbleSOqdW3zuJcJ5D+ogPfG2T1SY
VlZ7jsKP4kg0zxfd1NK6AzTc+XcBHfUD9fqn8wPHVjbjElsPvF+RDB9/BWeJkg8fKX4Rotg0W9UY
UYjhnqdceaxvCRCB+dHFpMFI0lDXjYrmGlAfAl0CJIsNhO/6IYhSeoqHx3dyTzPY3+C8qc+b2xnK
lgqe4AeHeFs4nRYbCmEY765mZT/bTnu+kUlPOCaB3I9Iny+y7DOjUCFYvpAnvM+mgSUVcuZ7AAAx
ggHbMIIB1wIBATBFMDkxCzAJBgNVBAYTAkRFMREwDwYDVQQKDAhEQVRFViBlRzEXMBUGA1UEAwwO
Q0EgREFURVYgRU0gMDICCH/xVkCLVb+UMA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MTczMDE2WjAvBgkqhkiG9w0BCQQxIgQg
LrVto/vVFloxiChis95Ex7+HxJ9xY/hAGwwgU6Zwv7AwDQYJKoZIhvcNAQEBBQAEggEAAExMMNnJ
mdqdRIQ9hJTb836120TWaalOleK76EAZSwee3F0+ciiZyQk46pq35ju0Fb1zdnFM86BCastYuFKu
yRBP4yAxR0mMtKiWe5CxjRyMxZIA7qLPhEUwdQpCZiCkhIjeH99DMykf6OEwodjigH2iv9hpvjiv
cS5YzHRXKn3qALn0Zz3shtZVAXQk2wxHmfT2ubItIde6ytLvgMSoKlB9wAeru93AvdLW20cm4aqQ
KKvwmipBNBGe96MhQZqpteGd+HN5esE0ksnqruHGb9r2/4lpe2mOVsqPHitF4jkXpO8x2NaQ4XWK
sRwXvyy6xCBzMiL2h7MPaT1jzED6nAAAAAAAAA==

--=-_DvNextPart_0006_6F92F0C2.22E2D10A--


From nobody Wed May 15 10:54: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 CFC5D120359 for ; Wed, 15 May 2019 10:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKap0178M9aD for ; Wed, 15 May 2019 10:54:31 -0700 (PDT)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D630120119 for ; Wed, 15 May 2019 10:54:30 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x4FHrrvT005176; Wed, 15 May 2019 13:54:13 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 13:52:59 -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; Wed, 15 May 2019 13:53:38 -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; Wed, 15 May 2019 13:53:38 -0400
From: Justin Richer 
To: "Sahler, Frank" 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
Thread-Index: AdUKeoGh7sk3MCGsRg6qQGZqNy3QawA7iSOA
Date: Wed, 15 May 2019 17:53:37 +0000
Message-ID: <439B2D92-5BC1-44C7-B9E9-63C01D015E3E@mit.edu>
References: <8fe77fc8247e4eebb835b0f59bd4671e@datev.de>
In-Reply-To: <8fe77fc8247e4eebb835b0f59bd4671e@datev.de>
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_439B2D925BC144C7B9E963C01D015E3Emitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
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, 15 May 2019 17:54:34 -0000

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

T24gdGhlIHN1cmZhY2UgdGhpcyBpcyBmaW5lLCBidXQgaXQgaGlkZXMgYW4gaW1wb3J0YW50IGRl
dGFpbDogeW91IG5lZWQgdG8gaGF2ZSBhIGNsaWVudCByZWdpc3RlcmVkIHdpdGggdGhlIHN5c3Rl
bSBpbiBvcmRlciB0byBtYWtlIGEgdG9rZW4gcmVxdWVzdCwgbWVhbmluZyB0aGF0IHRoZSDigJxk
Y3LigJ0gdG9rZW4gd2FzIGlzc3VlZCB0byBhIGRpZmZlcmVudCBjbGllbnQgdGhhbiB0aGUgb25l
IG1ha2luZyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuIFNvIHRoYXQganVzdCBtZWFucyB0aGF0
IHRoZSBkZXZlbG9wZXIgaXMgZ29pbmcgdG8gaGF2ZSB0byBjb3B5IGl0IGJ5IGhhbmQgaW50byBh
IGNvbmZpZ3VyYXRpb24sIG9yIG90aGVyd2lzZSBwYXNzIGl0IHRvIHRoZSBpbnN0YW5jZXMgYXQg
cnVudGltZS4NCg0KSXMgaXQgYWxsb3dhYmxlPyBTdXJlLCBhcyB0aGUgUkZDIGRvZXNu4oCZdCBz
dGF0ZSAob3IgY2FyZSkgaG93IHlvdSBnb3QgdGhlIGluaXRpYWwgYWNjZXNzIHRva2VuIGZvciB0
aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuIElzIGl0IHN0YW5kYXJkPyBXZWxsLCB0aGUg4oCcZGNy
4oCdIHNjb3BlIGlzIHNwZWNpZmljIHRvIHRoaXMgY29tcGFueeKAmXMgaW1wbGVtZW50YXRpb24s
IGFuZCBpdOKAmXMgYSBsaXR0bGUgb2RkIHVzaW5nIGFuIGF1dG9tYXRlZCBwcm9jZXNzIHRvIGdl
dCBhIHRva2VuIGZvciB3aGF0IHdpbGwgYmUgYW4gYXV0b21hdGVkIHByb2Nlc3MuIFRoYXQgYmFz
aWNhbGx5IGxlYXZlcyBvbmUgaW5zdGFuY2Ugb2YgdGhlIGFwcGxpY2F0aW9uIGFzIHRoZSDigJxw
cmltYXJ54oCdIGluc3RhbmNlIGFuZCBldmVyeXRoaW5nIGVsc2UgYnVpbGRzIG9mZiBvZiB0aGF0
Lg0KDQpJdOKAmXMgbW9yZSBjb21tb24gdG8gdXNlIGEgc29mdHdhcmUgc3RhdGVtZW50LCB3aGlj
aCBhbHNvIGxvY2tzIGRvd24gYSBzZXQgb2YgY2xpZW50IGF0dHJpYnV0ZXMgaW4gYSBzaWduZWQg
c3RhdGVtZW50LiBJbiBmYWN0LCBpbiB0aGUgb3JpZ2luYWwgdmVyc2lvbiBvZiB0aGlzIHBhcnQg
b2YgdGhlIHNwZWNpZmljYXRpb24sIHdoaWNoIGNhbWUgZnJvbSB0aGUgQmx1ZUJ1dHRvbitSRVNU
IHByb2plY3QsIHRoZSDigJxzb2Z0d2FyZSBzdGF0ZW1lbnTigJ0gYW5kIOKAnGluaXRpYWwgYWNj
ZXNzIHRva2Vu4oCdIHdlcmUgb25lIGFuZCB0aGUgc2FtZS4gVGhpcyB3b3JraW5nIGdyb3VwIGRl
Y2lkZWQgdGhhdCB0aGUgZnVuY3Rpb25hbGl0eSB3YXMgYmV0dGVyIHNlcGFyYXRlZC4NCg0K4oCU
IEp1c3Rpbg0KDQpPbiBNYXkgMTQsIDIwMTksIGF0IDE6MzAgUE0sIFNhaGxlciwgRnJhbmsgPGZy
YW5rLnNhaGxlckBkYXRldi5kZTxtYWlsdG86ZnJhbmsuc2FobGVyQGRhdGV2LmRlPj4gd3JvdGU6
DQoNCkhlbGxvLA0KSSByZWFkIGluIHRoZSBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gZG9j
dW1lbnRhdGlvbiBvZiB0aGUgY29tcGFueSBjdXJpdHkgKGh0dHBzOi8vZGV2ZWxvcGVyLmN1cml0
eS5pby90dXRvcmlhbHMvZHluYW1pYy1jbGllbnQtcmVnaXN0cmF0aW9uLW92ZXJ2aWV3KSB0aGF0
IHRoZXkgdXNlIHRoZSBzY29wZSAiZGNyIiBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRv
IGdldCBhbiBpbml0aWFsIGFjY2VzcyB0b2tlbiBpLmUuIGEgYmVhcmVyIHRva2VuIHRoYXQgb25s
eSBhbGxvd3MgYWNjZXNzIHRvIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQuDQoNCklzIHRoaXMg
YWxzbyBmcm9tIHlvdXIgcG9pbnQgb2YgdmlldyBhIGZlYXNpYmxlIHdheSB0byBpbml0aWF0ZSB0
aGUgY2xpZW50IHJlZ2lzdHJhdGlvbj8NCg0KVW5mb3J0dW5hdGVseSB0aGUgc3BlY2lmaWNhdGlv
biBzYXlzIG5vdGhpbmcgYWJvdXQgaG93IHRvIGdldCB0aGUgdG9rZW4gYW5kIGhvdyBpdHMgcHVy
cG9zZSBpcyBsaW1pdGVkIHRvIHRoZSByZWdpc3RyYXRpb24gZW5kcG9pbnQuIFRoZXNlIHR3byBw
b2ludHMgYXJlICJvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiIuDQoNClJlZ2Fy
ZHMNCkZyYW5rIFNhaGxlcg0KU2VjdXJpdHkgQ29uc3VsdGFudA0KREFURVYgZUcsIE51cmVtYmVy
ZywgR2VybWFueQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpZ25hdHVyDQpE
aWVzZSBFLU1haWwgd3VyZGUgbWl0IGVpbmVtIFplcnRpZmlrYXQgZGVyIERBVEVWIGVHIHNpZ25p
ZXJ0LiBEYW1pdCBrw7ZubmVuIFNpZSBzaWNoZXIgc2VpbiwgZGFzcyBkaWUgTmFjaHJpY2h0IHNv
IHZvbiB1bnMgZ2VzZW5kZXQgd3VyZGUuIFdlbm4gU2llIGVpbmUgTWVsZHVuZyBlcmhhbHRlbiwg
ZGFzcyBkaWUgU2lnbmF0dXIgdW5nw7xsdGlnIGlzdCBvZGVyIG5pY2h0IGdlcHLDvGZ0IHdlcmRl
biBrYW5uLCBmZWhsdCBkYXMgWmVydGlmaWthdCB6dSBkaWVzZXIgU2lnbmF0dXIgYXVmIElocmVt
IFJlY2huZXIuIEluZm9ybWF0aW9uZW4genUgWmVydGlmaWthdGVuIHVuZCB6dXIgZGlnaXRhbGVu
IFNpZ25hdHVyIGZpbmRlbiBTaWUgdW50ZXIgaHR0cHM6Ly93d3cuZGF0ZXYuZGUvemVydGlmaWth
dGUgaW0gSW50ZXJuZXQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KREFURVYg
ZUcNCjkwMzI5IE7DvHJuYmVyZw0KVGVsZWZvbiArNDkgOTExIDMxOS0wDQoNCkUtTWFpbDogaW5m
b0BkYXRldi5kZTxtYWlsdG86aW5mb0BkYXRldi5kZT4NCkludGVybmV0OiBodHRwczovL3d3dy5k
YXRldi5kZTxodHRwczovL3d3dy5kYXRldi5kZS8+DQpTaXR6OiA5MDQyOSBOw7xybmJlcmcsIFBh
dW1nYXJ0bmVyc3RyYcOfZSA2LTE0DQpSZWdpc3RlcmdlcmljaHQgTsO8cm5iZXJnLCBHZW5SZWcg
TnIuIDcwDQoNClZvcnN0YW5kDQpEci4gUm9iZXJ0IE1heXIgKFZvcnNpdHplbmRlcikNCkVja2hh
cmQgU2Nod2FyemVyIChzdGVsbHYuIFZvcnNpdHplbmRlcikNCkp1bGlhIEJhbmdlcnRoDQpQcm9m
LiBEci4gUGV0ZXIgS3J1Zw0KRGlhbmEgV2luZG1lacOfZXINCg0KVm9yc2l0emVuZGVyIGRlcyBB
dWZzaWNodHNyYXRlczogTmljb2xhcyBIb2ZtYW5uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0K

--_000_439B2D925BC144C7B9E963C01D015E3Emitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <3B8DBEC4C69F2541A15416612E8E3AB2@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uIHRoZSBzdXJmYWNlIHRoaXMgaXMgZmluZSwg
YnV0IGl0IGhpZGVzIGFuIGltcG9ydGFudCBkZXRhaWw6IHlvdSBuZWVkIHRvIGhhdmUgYSBjbGll
bnQgcmVnaXN0ZXJlZCB3aXRoIHRoZSBzeXN0ZW0gaW4gb3JkZXIgdG8gbWFrZSBhIHRva2VuIHJl
cXVlc3QsIG1lYW5pbmcgdGhhdCB0aGUg4oCcZGNy4oCdIHRva2VuIHdhcyBpc3N1ZWQgdG8gYSBk
aWZmZXJlbnQgY2xpZW50IHRoYW4gdGhlIG9uZSBtYWtpbmcgdGhlIHJlZ2lzdHJhdGlvbiByZXF1
ZXN0Lg0KIFNvIHRoYXQganVzdCBtZWFucyB0aGF0IHRoZSBkZXZlbG9wZXIgaXMgZ29pbmcgdG8g
aGF2ZSB0byBjb3B5IGl0IGJ5IGhhbmQgaW50byBhIGNvbmZpZ3VyYXRpb24sIG9yIG90aGVyd2lz
ZSBwYXNzIGl0IHRvIHRoZSBpbnN0YW5jZXMgYXQgcnVudGltZS4mbmJzcDsNCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklzIGl0IGFsbG93YWJsZT8g
U3VyZSwgYXMgdGhlIFJGQyBkb2VzbuKAmXQgc3RhdGUgKG9yIGNhcmUpIGhvdyB5b3UgZ290IHRo
ZSBpbml0aWFsIGFjY2VzcyB0b2tlbiBmb3IgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LiBJcyBp
dCBzdGFuZGFyZD8gV2VsbCwgdGhlIOKAnGRjcuKAnSBzY29wZSBpcyBzcGVjaWZpYyB0byB0aGlz
IGNvbXBhbnnigJlzIGltcGxlbWVudGF0aW9uLCBhbmQgaXTigJlzIGEgbGl0dGxlIG9kZCB1c2lu
ZyBhbiBhdXRvbWF0ZWQNCiBwcm9jZXNzIHRvIGdldCBhIHRva2VuIGZvciB3aGF0IHdpbGwgYmUg
YW4gYXV0b21hdGVkIHByb2Nlc3MuIFRoYXQgYmFzaWNhbGx5IGxlYXZlcyBvbmUgaW5zdGFuY2Ug
b2YgdGhlIGFwcGxpY2F0aW9uIGFzIHRoZSDigJxwcmltYXJ54oCdIGluc3RhbmNlIGFuZCBldmVy
eXRoaW5nIGVsc2UgYnVpbGRzIG9mZiBvZiB0aGF0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXTigJlzIG1vcmUgY29tbW9u
IHRvIHVzZSBhIHNvZnR3YXJlIHN0YXRlbWVudCwgd2hpY2ggYWxzbyBsb2NrcyBkb3duIGEgc2V0
IG9mIGNsaWVudCBhdHRyaWJ1dGVzIGluIGEgc2lnbmVkIHN0YXRlbWVudC4gSW4gZmFjdCwgaW4g
dGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgdGhpcyBwYXJ0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLCB3
aGljaCBjYW1lIGZyb20gdGhlIEJsdWVCdXR0b24mIzQzO1JFU1QgcHJvamVjdCwgdGhlIOKAnHNv
ZnR3YXJlDQogc3RhdGVtZW504oCdIGFuZCDigJxpbml0aWFsIGFjY2VzcyB0b2tlbuKAnSB3ZXJl
IG9uZSBhbmQgdGhlIHNhbWUuIFRoaXMgd29ya2luZyBncm91cCBkZWNpZGVkIHRoYXQgdGhlIGZ1
bmN0aW9uYWxpdHkgd2FzIGJldHRlciBzZXBhcmF0ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk
b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh
dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u
ZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkgMTQsIDIw
MTksIGF0IDE6MzAgUE0sIFNhaGxlciwgRnJhbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuay5z
YWhsZXJAZGF0ZXYuZGUiIGNsYXNzPSIiPmZyYW5rLnNhaGxlckBkYXRldi5kZTwvYT4mZ3Q7IHdy
b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2Vj
dGlvbjE7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90Oywgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkhlbGxv
LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7U2Vnb2UgVUkmcXVvdDssIHNhbnMtc2VyaWY7IiBj
bGFzcz0iIj5JIHJlYWQgaW4gdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBkb2N1bWVu
dGF0aW9uIG9mIHRoZSBjb21wYW55IGN1cml0eSAoPGEgaHJlZj0iaHR0cHM6Ly9kZXZlbG9wZXIu
Y3VyaXR5LmlvL3R1dG9yaWFscy9keW5hbWljLWNsaWVudC1yZWdpc3RyYXRpb24tb3ZlcnZpZXci
IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz
PSIiPmh0dHBzOi8vZGV2ZWxvcGVyLmN1cml0eS5pby90dXRvcmlhbHMvZHluYW1pYy1jbGllbnQt
cmVnaXN0cmF0aW9uLW92ZXJ2aWV3PC9hPikNCiB0aGF0IHRoZXkgdXNlIHRoZSBzY29wZSAmcXVv
dDtkY3ImcXVvdDsgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0byBnZXQgYW4gaW5pdGlh
bCBhY2Nlc3MgdG9rZW4gaS5lLiBhIGJlYXJlciB0b2tlbiB0aGF0IG9ubHkgYWxsb3dzIGFjY2Vz
cyB0byB0aGUgcmVnaXN0cmF0aW9uIGVuZHBvaW50LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu
PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6
IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90Oywg
c2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEx
cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90Oywgc2Fu
cy1zZXJpZjsiIGNsYXNzPSIiPklzIHRoaXMgYWxzbyBmcm9tIHlvdXIgcG9pbnQgb2YgdmlldyBh
IGZlYXNpYmxlIHdheSB0byBpbml0aWF0ZSB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbj88bzpwIGNs
YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1
b3Q7U2Vnb2UgVUkmcXVvdDssIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi
IGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7
U2Vnb2UgVUkmcXVvdDssIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5VbmZvcnR1bmF0ZWx5IHRoZSBz
cGVjaWZpY2F0aW9uIHNheXMgbm90aGluZyBhYm91dCBob3cgdG8gZ2V0IHRoZSB0b2tlbiBhbmQg
aG93IGl0cyBwdXJwb3NlIGlzIGxpbWl0ZWQgdG8gdGhlIHJlZ2lzdHJhdGlvbiBlbmRwb2ludC4g
VGhlc2UgdHdvIHBvaW50cyBhcmUgJnF1b3Q7b3V0IG9mIHNjb3BlIGZvciB0aGlzIHNwZWNpZmlj
YXRpb24mcXVvdDsuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1mYW1pbHk6ICZxdW90O1NlZ29lIFVJJnF1b3Q7LCBzYW5zLXNlcmlmOyIgY2xhc3M9
IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1mYW1pbHk6ICZxdW90O1NlZ29lIFVJJnF1b3Q7LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+
UmVnYXJkczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90Oywgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZy
YW5rIFNhaGxlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90Oywgc2Fucy1zZXJpZjsiIGNsYXNzPSIi
PlNlY3VyaXR5IENvbnN1bHRhbnQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7U2Vnb2UgVUkmcXVvdDssIHNhbnMtc2VyaWY7
IiBjbGFzcz0iIj5EQVRFViBlRywgTnVyZW1iZXJnLCBHZXJtYW55PG86cCBjbGFzcz0iIj48L286
cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGhyIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiBncmV5OyBiYWNrZ3JvdW5kLWNv
bG9yOiBncmV5OyB0ZXh0LWFsaWduOiBsZWZ0OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0
LWRlY29yYXRpb246IG5vbmU7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O3Nl
Z29lIHVpJnF1b3Q7LCB2ZXJkYW5hOyBjb2xvcjogcmdiKDEwMiwgMTAyLCAxMDIpOyIgY2xhc3M9
IiI+PHN0cm9uZyBjbGFzcz0iIj5TaWduYXR1cjwvc3Ryb25nPjxiciBjbGFzcz0iIj4NCkRpZXNl
IEUtTWFpbCB3dXJkZSBtaXQgZWluZW0gWmVydGlmaWthdCBkZXIgREFURVYgZUcgc2lnbmllcnQu
IERhbWl0IGvDtm5uZW4gU2llIHNpY2hlciBzZWluLCBkYXNzIGRpZSBOYWNocmljaHQgc28gdm9u
IHVucyBnZXNlbmRldCB3dXJkZS4gV2VubiBTaWUgZWluZSBNZWxkdW5nIGVyaGFsdGVuLCBkYXNz
IGRpZSBTaWduYXR1ciB1bmfDvGx0aWcgaXN0IG9kZXIgbmljaHQgZ2VwcsO8ZnQgd2VyZGVuIGth
bm4sIGZlaGx0IGRhcyBaZXJ0aWZpa2F0IHp1DQogZGllc2VyIFNpZ25hdHVyIGF1ZiBJaHJlbSBS
ZWNobmVyLiBJbmZvcm1hdGlvbmVuIHp1IFplcnRpZmlrYXRlbiB1bmQgenVyIGRpZ2l0YWxlbiBT
aWduYXR1ciBmaW5kZW4gU2llIHVudGVyPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmRhdGV2LmRlL3plcnRpZmlrYXRl
IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz
cz0iIj5odHRwczovL3d3dy5kYXRldi5kZS96ZXJ0aWZpa2F0ZTwvYT48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+aW0NCiBJbnRlcm5ldC48L3NwYW4+PHNw
YW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3Bs
YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PC9zcGFuPg0KPGhyIHN0eWxlPSJmb250
LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiBncmV5OyBiYWNr
Z3JvdW5kLWNvbG9yOiBncmV5OyB0ZXh0LWFsaWduOiBsZWZ0OyIgY2xhc3M9IiI+DQo8dGFibGUg
c3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog
MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LXNpemU6IDEwcHQ7IGZvbnQt
ZmFtaWx5OiAmcXVvdDtzZWdvZSB1aSZxdW90OywgdmVyZGFuYTsgY29sb3I6IHJnYigxMDIsIDEw
MiwgMTAyKTsiIGNsYXNzPSIiPg0KPHRib2R5IGNsYXNzPSIiPg0KPHRyIGNsYXNzPSIiPg0KPHRk
IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtzZWdvZSB1aSZxdW90
OywgdmVyZGFuYTsgY29sb3I6IHJnYigxMDIsIDEwMiwgMTAyKTsiIGNsYXNzPSIiPg0KPHN0cm9u
ZyBjbGFzcz0iIj5EQVRFViBlRzwvc3Ryb25nPjxiciBjbGFzcz0iIj4NCjkwMzI5IE7DvHJuYmVy
ZzwvdGQ+DQo8L3RyPg0KPHRyIGNsYXNzPSIiPg0KPHRkIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7
IGZvbnQtZmFtaWx5OiAmcXVvdDtzZWdvZSB1aSZxdW90OywgdmVyZGFuYTsgY29sb3I6IHJnYigx
MDIsIDEwMiwgMTAyKTsiIGNsYXNzPSIiPg0KVGVsZWZvbiAmIzQzOzQ5IDkxMSAzMTktMDxiciBj
bGFzcz0iIj4NCjwvdGQ+DQo8L3RyPg0KPHRyIGNsYXNzPSIiPg0KPHRkIHN0eWxlPSJmb250LXNp
emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtzZWdvZSB1aSZxdW90OywgdmVyZGFuYTsgY29s
b3I6IHJnYigxMDIsIDEwMiwgMTAyKTsiIGNsYXNzPSIiPg0KRS1NYWlsOjxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW5mb0Bk
YXRldi5kZSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l
OyIgY2xhc3M9IiI+aW5mb0BkYXRldi5kZTwvYT48YnIgY2xhc3M9IiI+DQpJbnRlcm5ldDo8c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0
cHM6Ly93d3cuZGF0ZXYuZGUvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u
OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5kYXRldi5kZTwvYT48L3RkPg0KPC90
cj4NCjx0ciBjbGFzcz0iIj4NCjx0ZCBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls
eTogJnF1b3Q7c2Vnb2UgdWkmcXVvdDssIHZlcmRhbmE7IGNvbG9yOiByZ2IoMTAyLCAxMDIsIDEw
Mik7IiBjbGFzcz0iIj4NClNpdHo6IDkwNDI5IE7DvHJuYmVyZywgUGF1bWdhcnRuZXJzdHJhw59l
IDYtMTQ8YnIgY2xhc3M9IiI+DQpSZWdpc3RlcmdlcmljaHQgTsO8cm5iZXJnLCBHZW5SZWcgTnIu
IDcwPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxiciBzdHlsZT0iY2FyZXQtY29s
b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4
dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8dGFibGUgc3R5bGU9ImxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt
c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k
ZWNvcmF0aW9uOiBub25lOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtzZWdv
ZSB1aSZxdW90OywgdmVyZGFuYTsgY29sb3I6IHJnYigxMDIsIDEwMiwgMTAyKTsiIGNsYXNzPSIi
Pg0KPHRib2R5IGNsYXNzPSIiPg0KPHRyIGNsYXNzPSIiPg0KPHRkIHN0eWxlPSJmb250LXNpemU6
IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtzZWdvZSB1aSZxdW90OywgdmVyZGFuYTsgY29sb3I6
IHJnYigxMDIsIDEwMiwgMTAyKTsiIGNsYXNzPSIiPg0KPHN0cm9uZyBjbGFzcz0iIj5Wb3JzdGFu
ZDwvc3Ryb25nPjxiciBjbGFzcz0iIj4NCkRyLiBSb2JlcnQgTWF5ciAoVm9yc2l0emVuZGVyKTxi
ciBjbGFzcz0iIj4NCkVja2hhcmQgU2Nod2FyemVyIChzdGVsbHYuIFZvcnNpdHplbmRlcik8c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIi
Pg0KSnVsaWEgQmFuZ2VydGg8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KUHJvZi4gRHIuIFBldGVyIEtydWc8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KRGlhbmEg
V2luZG1lacOfZXI8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVm9yc2l0emVuZGVyIGRlcyBBdWZzaWNo
dHNyYXRlczogTmljb2xhcyBIb2ZtYW5uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8YnIgc3R5
bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9
ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu
ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v
cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm
b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h
bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy
LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7
IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9BdXRo
DQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu
b25lOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHN0eWxlPSJj
b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIg
c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9y
OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_439B2D925BC144C7B9E963C01D015E3Emitedu_--


From nobody Wed May 15 11:39: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 098451206DA for ; Wed, 15 May 2019 11:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=unavailable 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 rOHJ2qb2Ylva for ; Wed, 15 May 2019 11:39:02 -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 D679612069F for ; Wed, 15 May 2019 11:38:46 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x4FIceT9000969; Wed, 15 May 2019 14:38:42 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 14:38:12 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 15 May 2019 14:38:30 -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; Wed, 15 May 2019 14:38:30 -0400
From: Justin Richer 
To: George Fletcher 
CC: Pedro Igor Silva , Jaap Francke , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
Thread-Index: AQHU+zhINZZlusRlskuXC59Zp2p6IqZOvx+AgAAJo4CAHh6egA==
Date: Wed, 15 May 2019 18:38:30 +0000
Message-ID: <6DB0AFDC-5637-4CC2-AB43-7BECDBF978DB@mit.edu>
References:  <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>  <1099fde4-1bca-d521-30cb-65bf834d0d86@aol.com>
In-Reply-To: <1099fde4-1bca-d521-30cb-65bf834d0d86@aol.com>
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_6DB0AFDC56374CC2AB437BECDBF978DBmitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
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, 15 May 2019 18:39:05 -0000

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

SSBhZ3JlZSB3aXRoIHNlcGFyYXRpbmcgdGhlc2UgY29uY2VybnMsIGJ1dCBub3QgcXVpdGUgd2l0
aCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGdvYWwgb2Ygc2NvcGVzLiBXaGF0IGEgc2NvcGUgcmVh
bGx5IHJlcHJlc2VudHMsIGluIG15IG1pbmQsIGlzIGEgc2hvcnRoYW5kIGZvciBhIHNldCBvZiBj
YXBhYmlsaXRpZXMgYXZhaWxhYmxlIGF0IGFuIEFQSS4gVGhpcyBzaG9ydGhhbmQgaXMgYmFrZWQg
aW50byB0aGUgQVBJIGFuZCBzbyBuZWVkcyB0byBiZSB1c2VmdWwgYWNyb3NzIG11bHRpcGxlIGNs
aWVudHMgYW5kIHJlcXVlc3RzIGluIG9yZGVyIGZvciBpdCB0byBiZSB3b3J0aCBkZWZpbmluZyBh
cyBhIHNlcGFyYXRlIHNjb3BlLiBXaXRoIHRoaXMgcHJvcG9zYWwsIHRoaW5ncyBhcmUgdGllZCBt
b3JlIHRvIHRoZSBzcGVjaWZpYyByZXF1ZXN0IGFuZCBkb27igJl0IG5lZWQgdG8gYmUgcmUtdXNh
YmxlLg0KDQpCb3RoIGNvbmNlcHRzIGFyZSB1c2VmdWwsIHRob3VnaCwgYW5kIHRoaXMgaXMgc29t
ZXRoaW5nIEnigJl2ZSBhZGRlZCBpbiB0aGUgWFlaIHN0cmF3bWFuIHByb3Bvc2FsIChodHRwczov
L29hdXRoLnh5ei8pOiBhIHJlZ3VsYXIgcmVxdWVzdCBoYXMgYSDigJxyZXNvdXJjZXPigJ0gc2Vj
dGlvbiB3aGljaCB3b3VsZCBiZSBzdHJ1Y3R1cmVkIGxpa2UgVG9yc3RlbuKAmXMgc3RydWN0dXJl
ZCBzY29wZSBpZGVhLCBidXQgd2l0aCB0aGUgY29uY2VwdCBvZiB0aGUg4oCcaGFuZGxl4oCdIGlu
dHJvZHVjZWQgaW4gWFlaIHlvdSBnZXQgYSBjb3VwbGUgb2YgaW50ZXJlc3RpbmcgZWxlbWVudHMu
IEZpcnN0LCBhbiBBUEkgY2FuIHByZS1kZWZpbmUgYSBzZXQgb2YgaGFuZGxlIHN0cmluZ3MgdGhh
dCB0aGUgY2xpZW50IGNhbiB1c2UgaW4gaXRzIHJlcXVlc3QsIG11Y2ggbGlrZSBzY29wZXMgYXJl
IHVzZWQgdG9kYXkuIFRoZXNlIHdvdWxkIGJlIHRoZSBtb3JlIGdlbmVyYWwtcHVycG9zZSByZXNv
dXJjZSBzZXRzLiBCdXQgdGhlbiBhIGNsaWVudCBtYWtpbmcgYSBtb3JlIHNwZWNpZmljIHJlcXVl
c3QgY2FuIGJlIGlzc3VlZCBhIHJhbmRvbWx5LWdlbmVyYXRlZCBoYW5kbGUgdGhhdCBvbmx5IGl0
IGNhbiB1c2UsIGFuZCB0aGUgQVMgY2FuIGxvb2sgdXAgdGhhdCBoYW5kbGXigJlzIHZhbHVlIGFu
ZCB0aWUgaXQgdG8gdGhlIG9yaWdpbmFsIHJlcXVlc3RlZCByZXNvdXJjZSBzZXQuIFRoaXMgaXMg
ZWZmZWN0aXZlbHkgYSDigJxzY29wZeKAnSBidXQgc3BlY2lmaWNhbGx5IGZvciB0aGUgY2xpZW50
4oCZcyBzcGVjaWZpYyByZXF1ZXN0Lg0KDQpJ4oCZZCBhbHNvIGxpa2UgdG8gcG9pbnQgb3V0IHRo
YXQgdGhlIOKAnGNsYWltX3Rva2Vu4oCdIGlkZWEgYmVsb3cgaXMgZXhhY3RseSB3aGF04oCZcyBk
b25lIHdpdGggVU1BIDLigJlzIOKAnHBlcm1pc3Npb24gdGlja2V04oCdIHJlc3BvbnNlIGZyb20g
dGhlIFJTLCBhbmQgdGhhdCBpcyBwYXNzZWQgYWxvbmcgdG8gdGhlIEFTIHdpdGggdGhlIHRva2Vu
IHJlcXVlc3QgaW4gVU1BLiBUaGlzIHNhbWUgcGF0dGVybiBjYW4gaGFwcGVuIHdpdGggWFlaLCBm
b3Igd2hhdCBpdOKAmXMgd29ydGgsIHdpdGggdGhlIFJTIHJldHVybmluZyBhIHJlc291cmNlIGhh
bmRsZSB0aGF0IHRoZSBjbGllbnQgY2FuIHNlbmQgYWxvbmcgd2l0aCBpdHMgb3duIHJlc291cmNl
cyByZXF1ZXN0Lg0KDQrigJQgSnVzdGluDQoNCk9uIEFwciAyNiwgMjAxOSwgYXQgMTA6NDEgQU0s
IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPG1haWx0
bzpnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KSSBhZ3JlZSB0
aGF0IHdlIGRlZmluaXRlbHkgbmVlZCBiZXR0ZXIgZGVmaW5pdGlvbiBhbmQgZ3VpZGFuY2UgYXJv
dW5kIHNjb3BlcyBhbmQgYXV0aG9yaXplZCBhY2Nlc3MgcGF0dGVybnMuDQoNCkkgdGhpbmsgd2hh
dCBpcyB1bmlxdWUgYWJvdXQgd2hhdCBUb3JzdGVuIGlzIHByb3Bvc2luZyBpcyB0aGF0IGluIGhp
cyBjYXNlIGhlIHdhbnRzIHRvIGF1dGhvcml6ZSBhbiBpbmRpdmlkdWFsIHRyYW5zYWN0aW9uIChu
b3QgYSBzZXQgb2YgdHJhbnNhY3Rpb25zKS4gTm9ybWFsbHksIHdpdGggc2NvcGVzIGFuZCBhY2Nl
c3MgdG9rZW5zIHRoZSBnb2FsIGlzIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4gdGhhdCBjYW4gcGVy
Zm9ybSBhIG51bWJlciBvZiB0cmFuc2FjdGlvbnMgd2l0aCBhIHJlc3RyaWN0ZWQgc2V0IG9mIGNh
cGFiaWxpdGllcy4NCg0KSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZSBjb25jZXB0IG9m
IHRyYW5zYWN0aW9uYWwgYXV0aG9yaXphdGlvbiBmcm9tIGNhcGFiaWxpdHkgYXV0aG9yaXphdGlv
bi4NCg0KT24gNC8yNi8xOSAxMDowNiBBTSwgUGVkcm8gSWdvciBTaWx2YSB3cm90ZToNCkhpIEph
YXAsDQoNClZlcnkgZ29vZCBwb2ludHMuIEkgaGF2ZSB0aGUgc2FtZSBvcGluaW9uIGFib3V0IHdo
YXQgeW91IHNhaWQgYWJvdXQgdGhlIG1lYW5pbmcgb2Ygc2NvcGVzIChhbmQgaG93IHBlb3BsZSBh
cmUgYWN0dWFsbHkgdXNpbmcgdGhlbSksIHRoZSByZXNvdXJjZS1zY29wZSByZWxhdGlvbnNoaXAg
YW5kIHRoZSBpbXBvcnRhbmNlIG9mIGEgc3RhbmRhcmRpemVkIHdheSBvZiBkb2luZyB0aGlzIGZv
cm0gb2YgYXV0aG9yaXphdGlvbiB0byBhZGRyZXNzIGRpZmZlcmVudCB1c2UgY2FzZXMsIG5vdCBv
bmx5IGRlbGVnYXRpb24uIExpa2UgR2VvcmdlIHNhaWQgaW4gb25lIG9mIGhpcyBtZXNzYWdlcywg
Ym90aCAxc3QgYW5kIDNyZCBwYXJ0eSB1c2UgY2FzZXMgY291bGQgYmUgY29uc2lkZXJlZCBieSBh
IHNvbHV0aW9uIGxpa2UgdGhhdC4NCg0KSSB3b3VsZCBsb3ZlIHRvIHNlZSBzb21ldGhpbmcgYmFz
ZWQgb24gT0F1dGggbGlrZSB0aGlzOg0KDQojMSkgQ2xpZW50IHRyaWVzIHRvIGFjY2VzcyBhIHBy
b3RlY3RlZCByZXNvdXJjZS4gQXQgdGhpcyBwb2ludCwgdGhlIGNsaWVudCBkb2VzIG5vdCB5ZXQg
aGF2ZSBhIGJlYXJlciB0b2tlbiBvciB0aGUgYmVhcmVyIHRva2VuIGlzIGxhY2tpbmcgdGhlIHJl
cXVpcmVkIHNjb3Blcy9wZXJtaXNzaW9ucy4gVGhlIHJlc291cmNlIHNlcnZlciByZXNwb25kcyB3
aXRoOg0KDQpIVFRQLzEuMSA0MDMgVW5hdXRob3JpemVkPz8NCldXVy1BdXRoZW50aWNhdGU6IEJl
YXJlciByZWFsbT0iZXhhbXBsZSIsIGVycm9yPSJpbnZhbGlkX3Rva2VuIiw/P2NsYWltX3Rva2Vu
PSJhY2NWa2pjSnliNEJXQ3hHc25kRVNDSlFiZEZNb2dVQzVQYlJEcWNlTFRDIg0KDQpUaGUgY2xh
aW1fdG9rZW4gcmVzcG9uc2UgcGFyYW1ldGVyIHJldHVybmVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2
ZXIgcmVwcmVzZW50cyBhbGwgdGhlIHNlY3VyaXR5IGNvbnN0cmFpbnRzIChlLmcuOiBzY29wZXMp
IGFuZCBpbmZvcm1hdGlvbiAoZS5nLjogY29udGV4dHVhbCkgdGhhdCB0aGUgY2xpZW50IG5lZWRz
IGluIG9yZGVyIHRvIG9idGFpbiBhIHZhbGlkIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBBUy4gVGhp
cyB0b2tlbiBjYW4gYmUgYnVpbHQgYnkgdGhlIFJTIG9yIGV2ZW4gdXNlIHNvbWUgZW5kcG9pbnQg
YXQgdGhlIEFTLCBhcyBVTUEgZG9lcy4gSXQgY2FuIGJlIGp1c3QgYSByZWZlcmVuY2UgdG9rZW4g
dG9vLg0KDQojMikgQ2xpZW50IG9idGFpbnMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2Vu
IGVuZHBvaW50IGF0IHRoZSBBUzoNCg0KUE9TVCAvYXMvdG9rZW4ub2F1dGgyIEhUVFAvMS4xDQpI
b3N0Oj8/YXMuZXhhbXBsZS5jb208aHR0cDovL2FzLmV4YW1wbGUuY29tLz4NCkNvbnRlbnQtVHlw
ZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQpncmFudF90eXBlPXVybiUzQWll
dGYlM0FwYXJhbXMlM0FvYXV0aCUzQWdyYW50LXR5cGUlM0FwZXJtaXNzaW9uDQomcmVzb3VyY2U9
aHR0cHMlM0ElMkYlMkZiYWNrZW5kLmV4YW1wbGUuY29tPGh0dHA6Ly8yZmJhY2tlbmQuZXhhbXBs
ZS5jb20vPiUyRmFwaSUyMA0KJmNsYWltX3Rva2VuPWFjY1ZramNKeWI0QldDeEdzbmRFU0NKUWJk
Rk1vZ1VDNVBiUkRxY2VMVEMNCiZzdWJqZWN0X3Rva2VuPWFjY1ZramNKeWI0QldDeEdzbmRFU0NK
UWJkRk1vZ1VDNVBiUkRxY2VMVEMNCiZzdWJqZWN0X3Rva2VuX3R5cGU9dXJuJTNBaWV0ZiUzQXBh
cmFtcyUzQW9hdXRoJTNBdG9rZW4tdHlwZSUzQWFjY2Vzc190b2tlbg0KDQpUaGUgZXhhbXBsZSBh
Ym92ZSBzaG93cyBhIGNsaWVudCByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aGVuIHRo
ZSBjbGllbnQgYWxyZWFkeSBoYXMgYW4gYWNjZXNzIHRva2VuIGFuZCB3YW50cyBhIG5ldyB0b2tl
biB3aXRoIHBlcm1pc3Npb25zIHRvIGFjY2VzcyBhIHJlc291cmNlLg0KDQojMykgSnVzdCBsaWtl
IGFueSBvdGhlciBPQXV0aCBncmFudCB0eXBlLCB0aGUgdG9rZW4gZW5kcG9pbnQgcmVzcG9uZHMg
dG8gdGhlIGNsaWVudCBhcyBmb2xsb3dzIChzdWNjZXNzKToNCg0KSFRUUC8xLjEgMjAwIE9LDQpD
b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOA0KQ2FjaGUtQ29udHJv
bDogbm8tc3RvcmUNClByYWdtYTogbm8tY2FjaGUNCg0Kew0KImFjY2Vzc190b2tlbiI6IjJZb3Ru
RlpGRWpyMXpDc2ljTVdwQUEiDQoidG9rZW5fdHlwZSI6ImV4YW1wbGUiLA0KImV4cGlyZXNfaW4i
OjM2MDAsDQoicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiDQp9Pz8NCg0K
IzQpIENsaWVudHMgY2FuIG5vdyBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcyB1c2luZyB0aGUg
YWNjZXNzIHRva2VuIHdpdGggYWxsIHBlcm1pc3Npb25zIGdyYW50ZWQgYnkgdGhlIHNlcnZlcg0K
DQpJdCBpcyBub3QgY29pbmNpZGVuY2UgdGhlIHNpbWlsYXJpdGllcyB3aXRoIGFuZCB0aGUgdXNh
Z2Ugb2Ygc3BlY3MvZHJhZnRzIGxpa2UgdG9rZW4gZXhjaGFuZ2UsIHJlc291cmNlLWluZGljYXRv
ciwgVU1BLD8/TG9kZ2luZyBJbnRlbnQgUGF0dGVybiw/P29yIGV2ZW4gQUNFJ3MgIkFTIFJlcXVl
c3QgQ3JlYXRpb24gSGludHMiIG1lc3NhZ2UuIFRoZSBwb2ludCBJIHdvdWxkIGxpa2UgdG8gbWFr
ZSBpcyB0aGF0IHdlIGNvdWxkIGxldmVyYWdlIHRoZSBzdGFuZGFyZHMvc3BlY3MgdGhhdCBleGlz
dCB0b2RheSB0byBhZGRyZXNzIHRoZSBwcm9ibGVtIHdpdGhvdXQgcmVpbnZlbnRpbmcgdGhlIHdo
ZWVsLg0KDQpUaGVyZSBhcmUgdmVyeSBpbnRlcmVzdGluZyB0aGluZ3MgaW4gVU1BIHNwZWNzIHRo
YXQgY2FuIGJlIHVzZWQgaGVyZSB0b28sIHN1Y2ggYXMgdGhlIHBvc3NpYmlsaXR5IHRvIHBlcmZv
cm0gaW5jcmVtZW50YWwgYXV0aG9yaXphdGlvbiBvciB0b2tlbiB1cGdyYWRlLCBldGMuDQoNClJl
Z2FyZHMuDQpQZWRybyBJZ29yDQoNCk9uIFRodSwgQXByIDI1LCAyMDE5IGF0IDQ6MjcgQU0gSmFh
cCBGcmFuY2tlIDxqYWFwLmZyYW5ja2U9NDBpd2VsY29tZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp
bHRvOjQwaXdlbGNvbWUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIaSBUb3JzdGVuIGFu
ZCBvdGhlcnMsDQoNCkkganVzdCByZWFkIHlvdXIgYmxvZyAtIGhhdmluZyA/Pz93ZSBuZWVkIHRv
IHJlLXRoaW5rIE9BdXRoIHNjb3Blcz8/PyBpbiB0aGUgdGl0bGUgaW1tZWRpYXRlbHkgZHJldyBt
eSBhdHRlbnRpb24uPz8NCkkgZmluZCB0aGlzIGludGVyZXN0aW5nIHNpbmNlIEk/Pz9tIHN0cnVn
Z2xpbmcgd2l0aCB0aGUgY29uY2VwdCBvZiBzY29wZXMgZnJvbSB0aW1lLXRvLXRpbWUuDQpJPz8/
bGwgaGF2ZSB0byByZWFkIHRoZSBibG9nIGEgZmV3IHRpbWVzIG1vcmUgdG8gZ2V0IGEgZ29vZCB1
bmRlcnN0YW5kaW5nLCBidXQgSSB3b3VsZCBsaWtlIHRvIHNoYXJlIHNvbWUgb2YgbXkgdGhvdWdo
dHMgb24gc2NvcGVzLg0KDQpJIGJlbGlldmUgdGhlIE9BdXRoIHNjb3BlIGNvbmNlcHQgaGFzIGl0
Pz8/cyBsaW1pdGF0aW9ucyBub3Qgb25seSBmb3IgdHJhbnNhY3Rpb25zIGJ1dCBhbHNvIGZvciB0
aGUgbW9yZSB0cmFkaXRpb25hbCA/Pz9yZXNvdXJjZT8/PyBjb25jZXB0Lg0KUkZDIDY3NDkgZGVm
aW5lcyBzY29wZXMgYXMgZm9sbG93czoNCiJUaGUgdmFsdWUgb2YgdGhlIHNjb3BlIHBhcmFtZXRl
ciBpcyBleHByZXNzZWQgYXMgYSBsaXN0IG9mIHNwYWNlLQ0KPz8/PyBkZWxpbWl0ZWQsIGNhc2Ut
c2Vuc2l0aXZlIHN0cmluZ3MuPz8gVGhlIHN0cmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlDQo/Pz8/
IGF1dGhvcml6YXRpb24gc2VydmVyLj8/IElmIHRoZSB2YWx1ZSBjb250YWlucyBtdWx0aXBsZSBz
cGFjZS1kZWxpbWl0ZWQNCj8/Pz8gc3RyaW5ncywgdGhlaXIgb3JkZXIgZG9lcyBub3QgbWF0dGVy
LCBhbmQgZWFjaCBzdHJpbmcgYWRkcyBhbg0KPz8/PyBhZGRpdGlvbmFsIGFjY2VzcyByYW5nZSB0
byB0aGUgcmVxdWVzdGVkIHNjb3BlLj8/Pw0KDQpJIHNlZSAyIGFzcGVjdHMgaW4gdGhpcyBkZWZp
bml0aW9uOg0KLSBob3cgdGhlIHN0cmluZ3Mgc2hvdWxkIGxvb2sgbGlrZSBpcyBiZXlvbmQgdGhl
IHNjb3BlIG9mIHRoZSBSRkMNCi0gZWFjaCBzdHJpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIGF1dGhv
cmlzYXRpb24NCg0KU2NvcGVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYWNjZXNzX3Rva2Vucywgd2hp
Y2ggdHlwaWNhbGx5IGFyZSBiZWFyZXIgdG9rZW5zIGFzIGRlZmluZWQgYnkgUkZDIDY3NTAgYXM6
DQo/Pz8/Pz8/Pz8/IEEgc2VjdXJpdHkgdG9rZW4gd2l0aCB0aGUgcHJvcGVydHkgdGhhdCBhbnkg
cGFydHkgaW4gcG9zc2Vzc2lvbiBvZg0KPz8/Pz8/Pz8/PyB0aGUgdG9rZW4gKGEgImJlYXJlciIp
IGNhbiB1c2UgdGhlIHRva2VuIGluIGFueSB3YXkgdGhhdCBhbnkgb3RoZXINCj8/Pz8/Pz8/Pz8g
cGFydHkgaW4gcG9zc2Vzc2lvbiBvZiBpdCBjYW4uPz8gVXNpbmcgYSBiZWFyZXIgdG9rZW4gZG9l
cyBub3QNCj8/Pz8/Pz8/Pz8gcmVxdWlyZSBhIGJlYXJlciB0byBwcm92ZSBwb3NzZXNzaW9uIG9m
IGNyeXB0b2dyYXBoaWMga2V5IG1hdGVyaWFsDQo/Pz8/Pz8/Pz8/IChwcm9vZi1vZi1wb3NzZXNz
aW9uKS4/Pz8NCg0KVGhpcyBpbXBsaWVzIHRoYXQgZXZlcnkgc2NvcGUgdmFsdWUgc2hvdWxkIGZ1
bGx5IGRlc2NyaWJlIHRoZSBhdXRob3Jpc2F0aW9uIHRoYXQgaXMgZ2l2ZW4uIEluIG15IHZpZXcg
dGhhdCBpcyByYXJlbHkgZG9uZSwgd2hpY2ggaXMgdGhlIG1haW4gcmVhc29uIHdoeSBJIGZpbmQg
bXlzZWxmIHN0cnVnZ2xpbmcgd2l0aCBzY29wZS1jb25jZXB0Lg0KDQpIZXJlIHdlIGhhdmUgYSBj
b2xsZWN0aW9uIG9mIGV4YW1wbGVzLCB3aGljaCBkZW1vbnN0cmF0ZSB0byBtZSB0aGF0IGV2ZXJ5
b25lIGlzIGludmVudGluZyB0aGVpciBvd24gd2hlZWxzIGFjY29yZGluZyB0byB0aGVpciBzcGVj
ZmljIG5lZWRzOg0KaHR0cHM6Ly9icmFuZHVyLm9yZy9vYXV0aC1zY29wZQ0KaHR0cHM6Ly9hcGku
c2xhY2suY29tL2RvY3Mvb2F1dGgtc2NvcGVzDQoNCkluIHZhcmlvdXMgb3RoZXIgKGRyYWZ0KSBz
dGFuZGFyZHMgSSBzZWUgYml0cyBhbmQgcGllY2VzIHRoYXQgc2VlbSB0byBhZGRyZXNzIHRoaXMg
aXNzdWUuDQoNCkluIFVNQSBhbiBhdXRob3Jpc2F0aW9uIGlzIGNvbmNlcHR1YWxseSBicm9rZW4g
ZG93biBpbnRvOg0KLSBzdWJqZWN0IC0+IHJlcXVlc3RpbmcgcGFydHkNCi0gdmVyYnMgLT4gc2Nv
cGVzIG9mIGFjY2Vzcw0KLSBvYmplY3QgLT4gcmVzb3VyY2Ugc2V0Lg0KSSBsaWtlIHRoaXMgbGlu
ZSBvZiB0aGlua2luZyBhbmQgdGVybWluaWxvZ3kuPz8gSG93ZXZlciwgaWYgYWNjZXNzX3Rva2Vu
cyBhcmUgYmVhcmVyIHRva2VucywgSSB0aGluayA/Pz9zdWJqZWN0Pz8/IGlzIHRoZSBiZWFyZXIg
b2YgdGhlIHRva2VuLg0KDQoNClRoZSBtb3N0IGNvbW1vbiBwcmFjdGljZSwgSSB0aGluaywgaXMg
dG8gdXNlIE9JREM/Pz9zIElEVG9rZW5zIHRvIGNvbnRhaW4gYSBzZXQgb2YgY2xhaW1zIHRoYXQg
c2NvcGUgdGhlIHNjb3BlIG9mIHRoZSBzY29wZSA6LSkuPz8NCg0KSSBtZWFuIHRoYXQgdGhlIGNs
YWltcyBpbiB0aGUgSUQtVG9rZW5zIGFyZSB1c2VkIHRvIHNjb3BlIHRoZSBvYmplY3RzIGFzIHdl
bGwgYXMgdGhlIHZlcmJzL3Njb3BlcyBvZiBhY2Nlc3MuDQoNClRoZSBjb3JlIGludGVudGlvbiBi
ZWhpbmQgSUQtdG9rZW4gaXMgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVu
dGljYXRlZCB1c2VyIGFuZCBub3QgbmVjZXNzYXJpbHkgYWJvdXQgdGhlIHJlc291cmNlcyB0aGF0
IGFyZSBhY2Nlc3NlZC4gSW4gcHJhY3RpY2UsIGNsYWltcyBhYm91dCB0aGUgYXV0aGVudGljYXRl
ZCB1c2VycyBpbmRpY2F0ZSB3aGljaCByZXNvdXJjZXMgKHBob3RvcykgY2FuIGJlIGFjY2Vzc2Vk
IGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIuDQoNCg0KDQoNCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhp
cyBkcmFmdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNv
dXJjZS1pbmRpY2F0b3JzLTAyDQoNCmlzIHRoYXQgdGhlIG9iamVjdC9yZXNvdXJjZSBhc3BlY3Qg
b2YgYXV0aG9yaXNhdGlvbiBpcyB0YWtlbiBzb21ld2hhdCBvdXQgb2YgdGhlIHNjb3BlIGFuZCBw
dXQgaW50byBhIGRlZGljYXRlZCBwYXJhbWV0ZXIuIEFsdGhvdWdoICh1c2luZyB0aGUgZXhhbXBs
ZSBmcm9tIFJGQyA2NzQ5KSB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGluZGljYXRlcyB0aGUgcmVz
b3VyY2Ugc2VydmVyIChvciBhcHBsaWNhdGlvbiwNCg0KICAgQVBJLCBldGMuKSByYXRoZXIgdGhh
biBhbiBpbmRpdmlkdWFsIHJlc291cmNlIHRoYXQgaXMgc3RvcmVkIGF0IHRoZSByZXNvdXJjZSBz
ZXJ2ZXIuIFNvIGFkZGl0aW9uYWwgc2NvcGluZyBvZiBvYmplY3QvcmVzb3VyY2Ugc2V0IGlzIHN0
aWxsIG5lZWRlZCBpbiBhZGRpdGlvbiB0byB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyLg0KDQoNCkZ1
cnRoZXJtb3JlLD8/aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt
c2VjdXJpdHktdG9waWNzLTEyPz9tYWtlcyBzb21lIGludGVyZXN0aW5nIHN0YXRlbWVudHMgdGhh
dCBhcmUgcmVsZXZhbnQgaW4gbXkgdmlldzoNClRoZSBzZWN0aW9uIG9uIEFjY2VzcyBUb2tlbiBw
cml2aWxlZ2UgcmVzdHJpY3Rpb24gc2F5cyAiYWNjZXNzIHRva2VucyBTSE9VTEQgYmUgcmVzdHJp
Y3RlZCB0byBjZXJ0YWluIHJlc291cmNlcw0KDQogICBhbmQgYWN0aW9ucyBvbiByZXNvdXJjZSBz
ZXJ2ZXJzIG9yIHJlc291cmNlcy4/Pz8gU28gdGhlIE9BdXRoIHNjb3BlLXN0cmluZyBzdGlsbCBu
ZWVkcyB0byBzb21laG93IGluZGljYXRlIHRoZSByZXNvdXJjZS1zY29wZSBvZiB0aGUgcHJpdmls
ZWdlIHRoYXQgaXMgY29tbXVuaWNhdGVkLg0KDQoNCg0KDQoiIFRoZSBjbGllbnQgbmVlZHMgdG8g
dGVsbCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGF0IHdoaWNoIFVSTCBpdA0KDQogICB3aWxs
IHVzZSB0aGUgYWNjZXNzIHRva2VuIGl0IGlzIHJlcXVlc3RpbmcuICBJdCBjb3VsZCB1c2UgdGhl
DQogICBtZWNoYW5pc20gcHJvcG9zZWQgW0ktRC5pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRv
cnM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHkt
dG9waWNzLTEyI3JlZi1JLUQuaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzPl0gb3IgZW5j
b2RlIHRoZQ0KICAgaW5mb3JtYXRpb24gaW4gdGhlIHNjb3BlIHZhbHVlLj8/Pw0KDQpJPz8/bSBu
b3Qgc3VyZSB3aGljaCBwb2ludCBJPz8/bSB0cnlpbmcgdG8gbWFrZTsgaSBndWVzcyB0aGUgbmVl
ZCBmb3Igc3RhbmRhcmRpc2F0aW9uIGhvdyB0byB1c2UgYW5kIGRlZmluZSBPQXV0aC1zY29wZXMu
DQoNCkkgbGlrZSB0aGUgTG9kZ2luZyBJbnRlbnQgUGF0dGVybiBhbmQgbmVlZCB0byBkbyBzb21l
IG1vcmUgcmVhZGluZy90aGlua2luZyBhYm91dCB0aGUgc3RydWN0dXJlZC1zY29wZSBhbmQgcHVz
aGVkIHJlcXVlc3Qgb2JqZWN0cy4NCg0KSSBmZWVsIHRoZXNlIGNvbmNlcHRzIGFyZSBub3Qgb25s
eSByZWxldmFudCBmb3IgYXV0aG9yaXNhdGlvbiBvZiB0cmFuc2FjdGlvbnMsIGJ1dCBhbHNvIGZv
ciBhbnkgYWNjZXNzIHRoYXQgbmVlZHMgYXV0aG9yaXNhdGlvbi4NCg0KDQoNCg0KST8/P20gbm90
IHN1cmUgaWYgaSBleHByZXNzIG15c2VsZiBjbGVhcmx5LCBuZXZlcnRoZWxlc3MgYW55IGZlZWRi
YWNrIGlzIHdlbGNvbWUsIGlmIG5vdCBhbG9uZSB0byBnZXQgbXkgdW5kZXJzdGFuZGluZyBvZiB0
aGUgdmFyaW91cyBjb25jZXB0cyBvbiBhIGhpZ2hlciBsZXZlbC4NCg0KDQoNCg0KVGhhbmtzIGlu
IGFkdmFuY2UsIGtpbmQgcmVnYXJkcw0KDQoNCg0KDQpKYWFwDQoNCg0KDQoNCg0KTWVzc2FnZTog
MQ0KRGF0ZTogV2VkLCAyNCBBcHIgMjAxOSAxOTowODoyNSArMDIwMA0KRnJvbTogVG9yc3RlbiBM
b2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVy
c3RlZHQubmV0Pj4NClRvOiBTYXNjaGEgUHJlaWJpc2NoIDxzYXNjaGFwcmVpYmlzY2hAZ21haWwu
Y29tPG1haWx0bzpzYXNjaGFwcmVpYmlzY2hAZ21haWwuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd
IFRyYW5zYWN0aW9uIEF1dGhvcml6YXRpb24gd2l0aCBPQXV0aA0KTWVzc2FnZS1JRDogPDI5OTdC
NTUwLUM4MkItNEQzQS05NjM5LTE1QTAwNEYyRjZDNUBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOjI5
OTdCNTUwLUM4MkItNEQzQS05NjM5LTE1QTAwNEYyRjZDNUBsb2RkZXJzdGVkdC5uZXQ+Pg0KQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04DQoNCkhpIFNhc2NoYSwNCg0KSSBz
ZWUuIEkgYXNzdW1lIGV2ZXJ5IGVsZW1lbnQgd2l0aGluIHRoZSBzdHJ1Y3R1cmVkIHNjb3BlIGVs
ZW1lbnQgdG8gYmUgYW4gaW5kZXBlbmRlbnQgc2NvcGUgKHZhbHVlKSBvYmplY3QgYW5kIGludGVu
ZGVkIHRvIHVzZSB0aGUgbmFtZSBvZiB0aGF0IG9iamVjdCBhcyBraW5kIG9mIGNvbnRlbnQgdHlw
ZSBkZWZpbml0aW9uLg0KDQpJbiBteSBsYXN0IGV4YW1wbGUsIHRoZSBzY29wZSBpcyBkZWZpbmVk
IGFzDQoNCj8/Pz8ic3RydWN0dXJlZF9zY29wZSI6eyA/Pw0KPz8/Pz8/Pz8/PyJzaWduIjp7ID8/
DQo/Pz8/Pz8/Pz8/Pz8/Pz8/ImNyZWRlbnRpYWxJRCI6InFlc19laWRhcyIsDQo/Pz8/Pz8/Pz8/
Pz8/Pz8/ImRvY3VtZW50RGlnZXN0cyI6WyA/Pw0KPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/P3sgPz8N
Cj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8iaGFzaCI6DQo/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/
Pz8/Pz8/Pz8/Pz8/PyJzVE9nd09tKzQ3NGdGajBxMHgxaVNOc3BLcWJjc2U0SWVpcWxEZy9IV3VJ
PSIsDQo/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ImxhYmVsIjoiTW9iaWxlIFN1YnNjcmlw
dGlvbiBDb250cmFjdCINCj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz99DQo/Pz8/Pz8/Pz8/Pz8/Pz8/
XSwNCj8/Pz8/Pz8/Pz8/Pz8/Pz8iaGFzaEFsZ29yaXRobU9JRCI6IjIuMTYuODQwLjEuMTAxLjMu
NC4yLjEiDQo/Pz8/Pz8/Pz8/fSwNCj8/Pz8/Pz8/Pz8icGF5bWVudCI6eyA/Pw0KPz8/Pz8/Pz8/
Pz8/Pz8/PyJ0eXBlIjoic2VwYS1jcmVkaXQtdHJhbnNmZXIiLA0KPz8/Pz8/Pz8/Pz8/Pz8/PyJp
bnN0cnVjdGVkQW1vdW50Ijp7ID8/DQo/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/ImN1cnJlbmN5Ijoi
RVVSIiwNCj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8iYW1vdW50IjoiMTIzLjUwIg0KPz8/Pz8/Pz8/
Pz8/Pz8/P30sDQo/Pz8/Pz8/Pz8/Pz8/Pz8/ImRlYnRvckFjY291bnQiOnsgPz8NCj8/Pz8/Pz8/
Pz8/Pz8/Pz8/Pz8/Pz8iaWJhbiI6IkRFNDAxMDAxMDAxMDMzMDcxMTg2MDgiDQo/Pz8/Pz8/Pz8/
Pz8/Pz8/fSwNCj8/Pz8/Pz8/Pz8/Pz8/Pz8iY3JlZGl0b3JOYW1lIjoiTWVyY2hhbnQxMjMiLA0K
Pz8/Pz8/Pz8/Pz8/Pz8/PyJjcmVkaXRvckFjY291bnQiOnsgPz8NCj8/Pz8/Pz8/Pz8/Pz8/Pz8/
Pz8/Pz8iaWJhbiI6IkRFMDIxMDAxMDAxMDkzMDcxMTg2MDMiDQo/Pz8/Pz8/Pz8/Pz8/Pz8/fSwN
Cj8/Pz8/Pz8/Pz8/Pz8/Pz8icmVtaXR0YW5jZUluZm9ybWF0aW9uVW5zdHJ1Y3R1cmVkIjoibmV3
IFNtYXJ0cGhvbmUiDQo/Pz8/Pz8/Pz8/fQ0KDQpUaGlzIG1lYW5zID9zaWduIiBhbmQgP3BheW1l
bnQiIHdvdWxkIGRldGVybWluZSB0aGUgc2NoZW1lIG9mIHRoZSByZXNwZWN0aXZlIG9iamVjdC4N
Cg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCmJlc3QgcmVnYXJkcywNClRvcnN0ZW4uDQoNCk9uIDIz
LiBBcHIgMjAxOSwgYXQgMTc6MTQsIFNhc2NoYSBQcmVpYmlzY2ggPHNhc2NoYXByZWliaXNjaEBn
bWFpbC5jb208bWFpbHRvOnNhc2NoYXByZWliaXNjaEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkg
VG9yc3RlbiENCg0KSWYgJ3N0cnVjdHVyZWRfc2NvcGUnIHdvdWxkIGJlY29tZSBhIGdlbmVyaWMg
ZmllbGQgZm9yIGFwcGxpY2F0aW9uDQpzcGVjaWZpYyBjb250ZW50LCBJIGJlbGlldmUgYW4gaW5k
aWNhdG9yIGZvciB0aGUgdHlwZSBvZiBjb250ZW50IHdvdWxkDQpiZSBuZWVkZWQgb24gdGhlIGxv
bmcgcnVuLiBUaGF0IGlzIHdoYXQgSSBtZWFudCBteSAncHJvZmlsZScuIEkgaG9wZQ0KdGhpcyBo
ZWxwcyENCg0KVGhhbmsgeW91LA0KU2FzY2hhDQoNCkFtIE1vLiwgMjIuIEFwci4gMjAxOSB1bSAy
MjowNiBVaHIgc2NocmllYiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo8dG9yc3RlbkBsb2RkZXJzdGVk
dC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj46DQoNCkhpIFNhc2NoYSwNCg0K
QW0gMjIuMDQuMjAxOSB1bSAyMDozNCBzY2hyaWViIFNhc2NoYSBQcmVpYmlzY2ggPHNhc2NoYXBy
ZWliaXNjaEBnbWFpbC5jb208bWFpbHRvOnNhc2NoYXByZWliaXNjaEBnbWFpbC5jb20+PjoNCg0K
VGhhbmsgeW91IGZvciB0aGUgYXJ0aWNsZSwgVG9yc3RlbiENCg0KbXkgcGxlYXN1cmUgOi0pDQoN
Cg0KSSBsaWtlIHRoYXQgJ3Njb3BlJyBpcyBvdXQgb2YgdGhlIGdhbWUgZm9yIHRoZXNlIGtpbmRz
IG9mIGF1dGhvcml6YXRpb25zLg0KDQpXaGF0IEkgY2FuIHNlZSBmb3IgdGhlIGdlbmVyYWwgdXNl
IGNhc2UgaXMgYSByZXF1aXJlZCBpZGVudGlmaWVyDQp3aXRoaW4gdGhlICdzdHJ1Y3R1cmVzX3Nj
b3BlJyBkb2N1bWVudCB0aGF0IGlkZW50aWZpZXMgdGhlIHByb2ZpbGUgaXQNCnNob3VsZCBiZSB1
c2VkIGZvci4NCg0KV2hhdCBkb2VzIHByb2ZpbGUgbWVhbiBpbiB0aGlzIGNvbnRleHQ/DQoNCmJl
c3QgcmVnYXJkcywNClRvcnN0ZW4uDQoNClRoYW5rIHlvdSwNClNhc2NoYQ0KDQpBbSBTYS4sIDIw
LiBBcHIuIDIwMTkgdW0gMTE6MjEgVWhyIHNjaHJpZWIgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPHRv
cnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+Og0K
DQpIaSBhbGwsDQoNCkkganVzdCBwdWJsaXNoZWQgYW4gYXJ0aWNsZSBhYm91dCB0aGUgc3ViamVj
dCBhdDogaHR0cHM6Ly9tZWRpdW0uY29tL29hdXRoLTIvdHJhbnNhY3Rpb24tYXV0aG9yaXphdGlv
bi1vci13aHktd2UtbmVlZC10by1yZS10aGluay1vYXV0aC1zY29wZXMtMjMyNmUyMDM4OTQ4PGh0
dHBzOi8vbWVkaXVtLi5jb20vb2F1dGgtMi90cmFuc2FjdGlvbi1hdXRob3JpemF0aW9uLW9yLXdo
eS13ZS1uZWVkLXRvLXJlLXRoaW5rLW9hdXRoLXNjb3Blcy0yMzI2ZTIwMzg5NDg+DQoNCkkgbG9v
ayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVkYmFjay4NCg0Ka2luZCByZWdhcmRzLA0KVG9y
c3Rlbi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KRW5kIG9mIE9BdXRoIERpZ2VzdCwgVm9sIDEyNiwgSXNzdWUgNTgN
CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN
Cg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgd2l0aCBzZXBhcmF0aW5nIHRoZXNl
IGNvbmNlcm5zLCBidXQgbm90IHF1aXRlIHdpdGggdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBnb2Fs
IG9mIHNjb3Blcy4gV2hhdCBhIHNjb3BlIHJlYWxseSByZXByZXNlbnRzLCBpbiBteSBtaW5kLCBp
cyBhIHNob3J0aGFuZCBmb3IgYSBzZXQgb2YgY2FwYWJpbGl0aWVzIGF2YWlsYWJsZSBhdCBhbiBB
UEkuIFRoaXMgc2hvcnRoYW5kIGlzIGJha2VkIGludG8gdGhlIEFQSSBhbmQgc28gbmVlZHMgdG8N
CiBiZSB1c2VmdWwgYWNyb3NzIG11bHRpcGxlIGNsaWVudHMgYW5kIHJlcXVlc3RzIGluIG9yZGVy
IGZvciBpdCB0byBiZSB3b3J0aCBkZWZpbmluZyBhcyBhIHNlcGFyYXRlIHNjb3BlLiBXaXRoIHRo
aXMgcHJvcG9zYWwsIHRoaW5ncyBhcmUgdGllZCBtb3JlIHRvIHRoZSBzcGVjaWZpYyByZXF1ZXN0
IGFuZCBkb27igJl0IG5lZWQgdG8gYmUgcmUtdXNhYmxlLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Qm90aCBjb25jZXB0cyBhcmUgdXNl
ZnVsLCB0aG91Z2gsIGFuZCB0aGlzIGlzIHNvbWV0aGluZyBJ4oCZdmUgYWRkZWQgaW4gdGhlIFhZ
WiBzdHJhd21hbiBwcm9wb3NhbCAoPGEgaHJlZj0iaHR0cHM6Ly9vYXV0aC54eXovIiBjbGFzcz0i
Ij5odHRwczovL29hdXRoLnh5ei88L2E+KTogYSByZWd1bGFyIHJlcXVlc3QgaGFzIGEg4oCccmVz
b3VyY2Vz4oCdIHNlY3Rpb24gd2hpY2ggd291bGQgYmUgc3RydWN0dXJlZCBsaWtlIFRvcnN0ZW7i
gJlzDQogc3RydWN0dXJlZCBzY29wZSBpZGVhLCBidXQgd2l0aCB0aGUgY29uY2VwdCBvZiB0aGUg
4oCcaGFuZGxl4oCdIGludHJvZHVjZWQgaW4gWFlaIHlvdSBnZXQgYSBjb3VwbGUgb2YgaW50ZXJl
c3RpbmcgZWxlbWVudHMuIEZpcnN0LCBhbiBBUEkgY2FuIHByZS1kZWZpbmUgYSBzZXQgb2YgaGFu
ZGxlIHN0cmluZ3MgdGhhdCB0aGUgY2xpZW50IGNhbiB1c2UgaW4gaXRzIHJlcXVlc3QsIG11Y2gg
bGlrZSBzY29wZXMgYXJlIHVzZWQgdG9kYXkuIFRoZXNlIHdvdWxkDQogYmUgdGhlIG1vcmUgZ2Vu
ZXJhbC1wdXJwb3NlIHJlc291cmNlIHNldHMuIEJ1dCB0aGVuIGEgY2xpZW50IG1ha2luZyBhIG1v
cmUgc3BlY2lmaWMgcmVxdWVzdCBjYW4gYmUgaXNzdWVkIGEgcmFuZG9tbHktZ2VuZXJhdGVkIGhh
bmRsZSB0aGF0IG9ubHkgaXQgY2FuIHVzZSwgYW5kIHRoZSBBUyBjYW4gbG9vayB1cCB0aGF0IGhh
bmRsZeKAmXMgdmFsdWUgYW5kIHRpZSBpdCB0byB0aGUgb3JpZ2luYWwgcmVxdWVzdGVkIHJlc291
cmNlIHNldC4gVGhpcyBpcw0KIGVmZmVjdGl2ZWx5IGEg4oCcc2NvcGXigJ0gYnV0IHNwZWNpZmlj
YWxseSBmb3IgdGhlIGNsaWVudOKAmXMgc3BlY2lmaWMgcmVxdWVzdC48L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPknigJlkIGFsc28gbGlr
ZSB0byBwb2ludCBvdXQgdGhhdCB0aGUg4oCcY2xhaW1fdG9rZW7igJ0gaWRlYSBiZWxvdyBpcyBl
eGFjdGx5IHdoYXTigJlzIGRvbmUgd2l0aCBVTUEgMuKAmXMg4oCccGVybWlzc2lvbiB0aWNrZXTi
gJ0gcmVzcG9uc2UgZnJvbSB0aGUgUlMsIGFuZCB0aGF0IGlzIHBhc3NlZCBhbG9uZyB0byB0aGUg
QVMgd2l0aCB0aGUgdG9rZW4gcmVxdWVzdCBpbiBVTUEuIFRoaXMgc2FtZSBwYXR0ZXJuIGNhbiBo
YXBwZW4gd2l0aCBYWVosDQogZm9yIHdoYXQgaXTigJlzIHdvcnRoLCB3aXRoIHRoZSBSUyByZXR1
cm5pbmcgYSByZXNvdXJjZSBoYW5kbGUgdGhhdCB0aGUgY2xpZW50IGNhbiBzZW5kIGFsb25nIHdp
dGggaXRzIG93biByZXNvdXJjZXMgcmVxdWVzdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJl
dC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQg
SnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciAyNiwgMjAxOSwgYXQgMTA6
NDEgQU0sIEdlb3JnZSBGbGV0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoPTQwYW9s
LmNvbUBkbWFyYy5pZXRmLm9yZyIgY2xhc3M9IiI+Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmll
dGYub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl
LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0i
I0ZGRkZGRiIgY2xhc3M9IiI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJp
ZiIgY2xhc3M9IiI+SSBhZ3JlZSB0aGF0IHdlIGRlZmluaXRlbHkgbmVlZCBiZXR0ZXIgZGVmaW5p
dGlvbiBhbmQgZ3VpZGFuY2UgYXJvdW5kIHNjb3BlcyBhbmQgYXV0aG9yaXplZCBhY2Nlc3MgcGF0
dGVybnMuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIHdoYXQgaXMgdW5p
cXVlIGFib3V0IHdoYXQgVG9yc3RlbiBpcyBwcm9wb3NpbmcgaXMgdGhhdCBpbiBoaXMgY2FzZSBo
ZSB3YW50cyB0byBhdXRob3JpemUgYW4gaW5kaXZpZHVhbCB0cmFuc2FjdGlvbiAobm90IGEgc2V0
IG9mIHRyYW5zYWN0aW9ucykuIE5vcm1hbGx5LCB3aXRoIHNjb3BlcyBhbmQgYWNjZXNzIHRva2Vu
cyB0aGUgZ29hbCBpcyB0byBnZXQgYW4gYWNjZXNzIHRva2VuIHRoYXQgY2FuIHBlcmZvcm0gYSBu
dW1iZXIgb2YgdHJhbnNhY3Rpb25zDQogd2l0aCBhIHJlc3RyaWN0ZWQgc2V0IG9mIGNhcGFiaWxp
dGllcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIHdlIG5lZWQgdG8gc2Vw
YXJhdGUgdGhlIGNvbmNlcHQgb2YgdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9uIGZyb20gY2Fw
YWJpbGl0eSBhdXRob3JpemF0aW9uLjxiciBjbGFzcz0iIj4NCjwvZm9udD48YnIgY2xhc3M9IiI+
DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDQvMjYvMTkgMTA6MDYgQU0sIFBlZHJv
IElnb3IgU2lsdmEgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIiBjaXRlPSJtaWQ6Q0FKcmNEQmNpZGJwMTFvelU1Q05jWV9PRVlfWGVTbmFZaWgzX2JK
MV93PTl2WiYjNDM7OE5SQUBtYWlsLmdtYWlsLmNvbSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRy
IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBK
YWFwLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+VmVyeSBnb29kIHBvaW50cy4gSSBoYXZlIHRoZSBzYW1lIG9waW5pb24gYWJvdXQgd2hh
dCB5b3Ugc2FpZCBhYm91dCB0aGUgbWVhbmluZyBvZiBzY29wZXMgKGFuZCBob3cgcGVvcGxlIGFy
ZSBhY3R1YWxseSB1c2luZyB0aGVtKSwgdGhlIHJlc291cmNlLXNjb3BlIHJlbGF0aW9uc2hpcCBh
bmQgdGhlIGltcG9ydGFuY2Ugb2YgYSBzdGFuZGFyZGl6ZWQgd2F5IG9mIGRvaW5nIHRoaXMgZm9y
bSBvZiBhdXRob3JpemF0aW9uIHRvDQogYWRkcmVzcyBkaWZmZXJlbnQgdXNlIGNhc2VzLCBub3Qg
b25seSBkZWxlZ2F0aW9uLiBMaWtlIEdlb3JnZSBzYWlkIGluIG9uZSBvZiBoaXMgbWVzc2FnZXMs
IGJvdGggMXN0IGFuZCAzcmQgcGFydHkgdXNlIGNhc2VzIGNvdWxkIGJlIGNvbnNpZGVyZWQgYnkg
YSBzb2x1dGlvbiBsaWtlIHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHdvdWxkIGxvdmUgdG8gc2VlIHNvbWV0aGluZyBiYXNl
ZCBvbiBPQXV0aCBsaWtlIHRoaXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+IzEpIENsaWVudCB0cmllcyB0
byBhY2Nlc3MgYSBwcm90ZWN0ZWQgcmVzb3VyY2UuIEF0IHRoaXMgcG9pbnQsIHRoZSBjbGllbnQg
ZG9lcyBub3QgeWV0IGhhdmUgYSBiZWFyZXIgdG9rZW4gb3IgdGhlIGJlYXJlciB0b2tlbiBpcyBs
YWNraW5nIHRoZSByZXF1aXJlZCBzY29wZXMvcGVybWlzc2lvbnMuIFRoZSByZXNvdXJjZSBzZXJ2
ZXIgcmVzcG9uZHMgd2l0aDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPkhUVFAvMS4xIDQwMyBVbmF1dGhvcml6ZWQ/
PzwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+V1dXLUF1dGhlbnRpY2F0ZTog
QmVhcmVyIHJlYWxtPSZxdW90O2V4YW1wbGUmcXVvdDssIGVycm9yPSZxdW90O2ludmFsaWRfdG9r
ZW4mcXVvdDssPz88YiBjbGFzcz0iIj5jbGFpbV90b2tlbjwvYj49JnF1b3Q7YWNjVmtqY0p5YjRC
V0N4R3NuZEVTQ0pRYmRGTW9nVUM1UGJSRHFjZUxUQyZxdW90OzwvaT48YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PlRoZSBjbGFpbV90b2tlbiByZXNwb25zZSBwYXJhbWV0ZXIgcmV0dXJuZWQgYnkgdGhlIHJlc291
cmNlIHNlcnZlciByZXByZXNlbnRzIGFsbCB0aGUgc2VjdXJpdHkgY29uc3RyYWludHMgKGUuZy46
IHNjb3BlcykgYW5kIGluZm9ybWF0aW9uIChlLmcuOiBjb250ZXh0dWFsKSB0aGF0IHRoZSBjbGll
bnQgbmVlZHMgaW4gb3JkZXIgdG8gb2J0YWluIGEgdmFsaWQgYWNjZXNzIHRva2VuIGZyb20gdGhl
IEFTLiBUaGlzIHRva2VuDQogY2FuIGJlIGJ1aWx0IGJ5IHRoZSBSUyBvciBldmVuIHVzZSBzb21l
IGVuZHBvaW50IGF0IHRoZSBBUywgYXMgVU1BIGRvZXMuIEl0IGNhbiBiZSBqdXN0IGEgcmVmZXJl
bmNlIHRva2VuIHRvby48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPiMyKSBDbGllbnQgb2J0YWlucyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0
aGUgdG9rZW4gZW5kcG9pbnQgYXQgdGhlIEFTOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIi
PlBPU1QgL2FzL3Rva2VuLm9hdXRoMiBIVFRQLzEuMTwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
PGkgY2xhc3M9IiI+SG9zdDo/PzxhIGhyZWY9Imh0dHA6Ly9hcy5leGFtcGxlLmNvbS8iIHRhcmdl
dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmFzLmV4YW1wbGUuY29t
PC9hPjwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+Q29udGVudC1UeXBlOiBh
cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxpIGNsYXNzPSIiPmdyYW50X3R5cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoJTNBZ3Jh
bnQtdHlwZSUzQXBlcm1pc3Npb248L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIi
PiZhbXA7cmVzb3VyY2U9aHR0cHMlM0ElMkYlPGEgaHJlZj0iaHR0cDovLzJmYmFja2VuZC5leGFt
cGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIi
PjJGYmFja2VuZC5leGFtcGxlLmNvbTwvYT4lMkZhcGklMjA8L2k+PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxpIGNsYXNzPSIiPiZhbXA7PGIgY2xhc3M9IiI+Y2xhaW1fdG9rZW48L2I+PWFjY1ZramNK
eWI0QldDeEdzbmRFU0NKUWJkRk1vZ1VDNVBiUkRxY2VMVEM8L2k+PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxpIGNsYXNzPSIiPiZhbXA7c3ViamVjdF90b2tlbj1hY2NWa2pjSnliNEJXQ3hHc25kRVND
SlFiZEZNb2dVQzVQYlJEcWNlTFRDPC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0i
Ij4mYW1wO3N1YmplY3RfdG9rZW5fdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGglM0F0
b2tlbi10eXBlJTNBYWNjZXNzX3Rva2VuPC9pPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgZXhhbXBsZSBhYm92ZSBz
aG93cyBhIGNsaWVudCByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aGVuIHRoZSBjbGll
bnQgYWxyZWFkeSBoYXMgYW4gYWNjZXNzIHRva2VuIGFuZCB3YW50cyBhIG5ldyB0b2tlbiB3aXRo
IHBlcm1pc3Npb25zIHRvIGFjY2VzcyBhIHJlc291cmNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+IzMpIEp1c3QgbGlrZSBhbnkgb3Ro
ZXIgT0F1dGggZ3JhbnQgdHlwZSwgdGhlIHRva2VuIGVuZHBvaW50IHJlc3BvbmRzIHRvIHRoZSBj
bGllbnQgYXMgZm9sbG93cyAoc3VjY2Vzcyk6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+
SFRUUC8xLjEgMjAwIE9LPC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0iIj5Db250
ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtODwvaT48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PGkgY2xhc3M9IiI+Q2FjaGUtQ29udHJvbDogbm8tc3RvcmU8L2k+PC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPlByYWdtYTogbm8tY2FjaGU8L2k+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvaT48L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+PGkgY2xhc3M9IiI+ezwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+
JnF1b3Q7YWNjZXNzX3Rva2VuJnF1b3Q7OiZxdW90OzJZb3RuRlpGRWpyMXpDc2ljTVdwQUEmcXVv
dDs8L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPiZxdW90O3Rva2VuX3R5cGUm
cXVvdDs6JnF1b3Q7ZXhhbXBsZSZxdW90Oyw8L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNs
YXNzPSIiPiZxdW90O2V4cGlyZXNfaW4mcXVvdDs6MzYwMCw8L2k+PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxpIGNsYXNzPSIiPiZxdW90O3JlZnJlc2hfdG9rZW4mcXVvdDs6JnF1b3Q7dEd6djNKT2tG
MFhHNVF4MlRsS1dJQSZxdW90OzwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGkgY2xhc3M9IiI+
fT8/PC9pPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+IzQpIENsaWVudHMgY2FuIG5vdyBhY2Nl
c3MgcHJvdGVjdGVkIHJlc291cmNlcyB1c2luZyB0aGUgYWNjZXNzIHRva2VuIHdpdGggYWxsIHBl
cm1pc3Npb25zIGdyYW50ZWQgYnkgdGhlIHNlcnZlcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgaXMgbm90IGNvaW5jaWRlbmNlIHRo
ZSBzaW1pbGFyaXRpZXMgd2l0aCBhbmQgdGhlIHVzYWdlIG9mIHNwZWNzL2RyYWZ0cyBsaWtlIHRv
a2VuIGV4Y2hhbmdlLCByZXNvdXJjZS1pbmRpY2F0b3IsIFVNQSw/PzxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEzLjMzMzNweCIgY2xhc3M9IiI+TG9kZ2luZyBJ
bnRlbnQgUGF0dGVybiw8L3NwYW4+Pz9vciBldmVuIEFDRSdzICZxdW90O0FTIFJlcXVlc3QNCiBD
cmVhdGlvbiBIaW50cyZxdW90OyBtZXNzYWdlLiBUaGUgcG9pbnQgSSB3b3VsZCBsaWtlIHRvIG1h
a2UgaXMgdGhhdCB3ZSBjb3VsZCBsZXZlcmFnZSB0aGUgc3RhbmRhcmRzL3NwZWNzIHRoYXQgZXhp
c3QgdG9kYXkgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbSB3aXRob3V0IHJlaW52ZW50aW5nIHRoZSB3
aGVlbC48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+VGhlcmUgYXJlIHZlcnkgaW50ZXJlc3RpbmcgdGhpbmdzIGluIFVNQSBz
cGVjcyB0aGF0IGNhbiBiZSB1c2VkIGhlcmUgdG9vLCBzdWNoIGFzIHRoZSBwb3NzaWJpbGl0eSB0
byBwZXJmb3JtIGluY3JlbWVudGFsIGF1dGhvcml6YXRpb24gb3IgdG9rZW4gdXBncmFkZSwgZXRj
LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+UmVnYXJkcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGVkcm8gSWdvcjwvZGl2Pg0KPGJyIGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9
ImdtYWlsX2F0dHIiPk9uIFRodSwgQXByIDI1LCAyMDE5IGF0IDQ6MjcgQU0gSmFhcCBGcmFuY2tl
ICZsdDtqYWFwLmZyYW5ja2U9PGEgaHJlZj0ibWFpbHRvOjQwaXdlbGNvbWUuY29tQGRtYXJjLmll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj40
MGl3ZWxjb21lLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw
eCAwcHggMHB4DQogICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAg
ICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBjbGFz
cz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgVG9yc3RlbiBhbmQgb3RoZXJzLDwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBqdXN0IHJlYWQg
eW91ciBibG9nIC0gaGF2aW5nID8/P3dlIG5lZWQgdG8gcmUtdGhpbmsgT0F1dGggc2NvcGVzPz8/
IGluIHRoZSB0aXRsZSBpbW1lZGlhdGVseSBkcmV3IG15IGF0dGVudGlvbi4/PzwvZGl2Pg0KPGRp
diBjbGFzcz0iIj5JIGZpbmQgdGhpcyBpbnRlcmVzdGluZyBzaW5jZSBJPz8/bSBzdHJ1Z2dsaW5n
IHdpdGggdGhlIGNvbmNlcHQgb2Ygc2NvcGVzIGZyb20gdGltZS10by10aW1lLjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj5JPz8/bGwgaGF2ZSB0byByZWFkIHRoZSBibG9nIGEgZmV3IHRpbWVzIG1vcmUg
dG8gZ2V0IGEgZ29vZCB1bmRlcnN0YW5kaW5nLCBidXQgSSB3b3VsZCBsaWtlIHRvIHNoYXJlIHNv
bWUgb2YgbXkgdGhvdWdodHMgb24gc2NvcGVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBiZWxpZXZlIHRoZSBPQXV0aCBzY29wZSBj
b25jZXB0IGhhcyBpdD8/P3MgbGltaXRhdGlvbnMgbm90IG9ubHkgZm9yIHRyYW5zYWN0aW9ucyBi
dXQgYWxzbyBmb3IgdGhlIG1vcmUgdHJhZGl0aW9uYWwgPz8/cmVzb3VyY2U/Pz8gY29uY2VwdC48
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UkZDIDY3NDkgZGVmaW5lcyBzY29wZXMgYXMgZm9sbG93czo8
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0
eWxlOml0YWxpYyIgY2xhc3M9IiI+JnF1b3Q7VGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0
ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlzdCBvZiBzcGFjZS08L3NwYW4+PC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOml0YWxpYyIgY2xhc3M9IiI+Pz8/PyBkZWxp
bWl0ZWQsIGNhc2Utc2Vuc2l0aXZlIHN0cmluZ3MuPz8gVGhlIHN0cmluZ3MgYXJlIGRlZmluZWQg
YnkgdGhlPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHls
ZTppdGFsaWMiIGNsYXNzPSIiPj8/Pz8gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuPz8gSWYgdGhlIHZh
bHVlIGNvbnRhaW5zIG11bHRpcGxlIHNwYWNlLWRlbGltaXRlZDwvc3Bhbj48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6aXRhbGljIiBjbGFzcz0iIj4/Pz8/IHN0
cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3RyaW5nIGFkZHMg
YW48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOml0
YWxpYyIgY2xhc3M9IiI+Pz8/PyBhZGRpdGlvbmFsIGFjY2VzcyByYW5nZSB0byB0aGUgcmVxdWVz
dGVkIHNjb3BlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiIGNsYXNzPSIi
Pj8/Pzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6
aXRhbGljIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbCIgY2xhc3M9IiI+SSBzZWUgMiBhc3Bl
Y3RzIGluIHRoaXMgZGVmaW5pdGlvbjo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFu
IHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbCIgY2xhc3M9IiI+LSBob3cgdGhlIHN0cmluZ3Mgc2hv
dWxkIGxvb2sgbGlrZSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBSRkM8L3NwYW4+PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbCIgY2xhc3M9IiI+
LSBlYWNoIHN0cmluZyBhZGRzIGFuIGFkZGl0aW9uYWwgYXV0aG9yaXNhdGlvbjwvc3Bhbj48L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6aXRhbGljIiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Nv
cGVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYWNjZXNzX3Rva2Vucywgd2hpY2ggdHlwaWNhbGx5IGFy
ZSBiZWFyZXIgdG9rZW5zIGFzIGRlZmluZWQgYnkgUkZDIDY3NTAgYXM6PC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiIGNs
YXNzPSIiPj8/Pz8/Pz8/Pz8gQSBzZWN1cml0eSB0b2tlbiB3aXRoIHRoZSBwcm9wZXJ0eSB0aGF0
IGFueSBwYXJ0eSBpbiBwb3NzZXNzaW9uIG9mPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiIGNsYXNzPSIiPj8/Pz8/Pz8/Pz8gdGhlIHRv
a2VuIChhICZxdW90O2JlYXJlciZxdW90OykgY2FuIHVzZSB0aGUgdG9rZW4gaW4gYW55IHdheSB0
aGF0IGFueSBvdGhlcjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv
bnQtc3R5bGU6aXRhbGljIiBjbGFzcz0iIj4/Pz8/Pz8/Pz8/IHBhcnR5IGluIHBvc3Nlc3Npb24g
b2YgaXQgY2FuLj8/IFVzaW5nIGEgYmVhcmVyIHRva2VuIGRvZXMgbm90PC9zcGFuPjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiIGNsYXNzPSIiPj8/
Pz8/Pz8/Pz8gcmVxdWlyZSBhIGJlYXJlciB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIGNyeXB0b2dy
YXBoaWMga2V5IG1hdGVyaWFsPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHls
ZT0iZm9udC1zdHlsZTppdGFsaWMiIGNsYXNzPSIiPj8/Pz8/Pz8/Pz8gKHByb29mLW9mLXBvc3Nl
c3Npb24pLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiIGNsYXNzPSIiPj8/
Pzwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6aXRh
bGljIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbCIgY2xhc3M9IiI+VGhpcyBpbXBsaWVzIHRo
YXQgZXZlcnkgc2NvcGUgdmFsdWUgc2hvdWxkIGZ1bGx5IGRlc2NyaWJlIHRoZSBhdXRob3Jpc2F0
aW9uIHRoYXQgaXMgZ2l2ZW4uIEluIG15IHZpZXcgdGhhdCBpcyByYXJlbHkgZG9uZSwgd2hpY2gg
aXMgdGhlIG1haW4gcmVhc29uIHdoeSBJIGZpbmQgbXlzZWxmIHN0cnVnZ2xpbmcgd2l0aCBzY29w
ZS1jb25jZXB0Ljwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt
c3R5bGU6bm9ybWFsIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbCIgY2xhc3M9IiI+SGVyZSB3
ZSBoYXZlIGEgY29sbGVjdGlvbiBvZiBleGFtcGxlcywgd2hpY2ggZGVtb25zdHJhdGUgdG8gbWUg
dGhhdCBldmVyeW9uZSBpcyBpbnZlbnRpbmcgdGhlaXIgb3duIHdoZWVscyBhY2NvcmRpbmcgdG8g
dGhlaXIgc3BlY2ZpYyBuZWVkczo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9
Imh0dHBzOi8vYnJhbmR1ci5vcmcvb2F1dGgtc2NvcGUiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0dHBzOi8vYnJhbmR1ci5vcmcvb2F1dGgtc2NvcGU8
L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vYXBpLnNsYWNrLmNvbS9k
b2NzL29hdXRoLXNjb3BlcyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg
Y2xhc3M9IiI+aHR0cHM6Ly9hcGkuc2xhY2suY29tL2RvY3Mvb2F1dGgtc2NvcGVzPC9hPjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4g
dmFyaW91cyBvdGhlciAoZHJhZnQpIHN0YW5kYXJkcyBJIHNlZSBiaXRzIGFuZCBwaWVjZXMgdGhh
dCBzZWVtIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JbiBVTUEgYW4g
YXV0aG9yaXNhdGlvbiBpcyBjb25jZXB0dWFsbHkgYnJva2VuIGRvd24gaW50bzo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+LSBzdWJqZWN0IC0mZ3Q7IHJlcXVlc3RpbmcgcGFydHk8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+LSB2ZXJicyAtJmd0OyBzY29wZXMgb2YgYWNjZXNzPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPi0gb2JqZWN0IC0mZ3Q7IHJlc291cmNlIHNldC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBs
aWtlIHRoaXMgbGluZSBvZiB0aGlua2luZyBhbmQgdGVybWluaWxvZ3kuPz8gSG93ZXZlciwgaWYg
YWNjZXNzX3Rva2VucyBhcmUgYmVhcmVyIHRva2VucywgSSB0aGluayA/Pz9zdWJqZWN0Pz8/IGlz
IHRoZSBiZWFyZXIgb2YgdGhlIHRva2VuLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3
MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0i
Zm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVh
ay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+PGZvbnQgZmFjZT0i
SGVsdmV0aWNhIiBjbGFzcz0iIj5UaGUgbW9zdCBjb21tb24gcHJhY3RpY2UsIEkgdGhpbmssIGlz
IHRvIHVzZSBPSURDPz8/cyBJRFRva2VucyB0byBjb250YWluIGEgc2V0IG9mIGNsYWltcyB0aGF0
IHNjb3BlIHRoZSBzY29wZSBvZiB0aGUgc2NvcGUgOi0pLj8/PC9mb250PjwvcHJlPg0KPHByZSBj
bGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21haWwtbV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5l
d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1i
b3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFs
Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPkkgbWVhbiB0aGF0IHRoZSBjbGFpbXMg
aW4gdGhlIElELVRva2VucyBhcmUgdXNlZCB0byBzY29wZSB0aGUgb2JqZWN0cyBhcyB3ZWxsIGFz
IHRoZSB2ZXJicy9zY29wZXMgb2YgYWNjZXNzLjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im1f
NzM4MjU3MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2NTM0NjRuZXdwYWdlIiBz
dHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBw
eDticmVhay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+PGZvbnQg
ZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj5UaGUgY29yZSBpbnRlbnRpb24gYmVoaW5kIElELXRv
a2VuIGlzIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNl
ciBhbmQgbm90IG5lY2Vzc2FyaWx5IGFib3V0IHRoZSByZXNvdXJjZXMgdGhhdCBhcmUgYWNjZXNz
ZWQuIEluIHByYWN0aWNlLCBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlcnMgaW5k
aWNhdGUgd2hpY2ggcmVzb3VyY2VzIChwaG90b3MpIGNhbiBiZSBhY2Nlc3NlZCBhdCB0aGUgcmVz
b3VyY2Ugc2VydmVyLiA8L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIy
MTM2NzRnbWFpbC1tXy01MzM5Mjc2NTQzMDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6
ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3Jl
OnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPjxmb250IGZhY2U9IkhlbHZldGlj
YSIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIy
MTM2NzRnbWFpbC1tXy01MzM5Mjc2NTQzMDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6
ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3Jl
OnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPjxmb250IGZhY2U9IkhlbHZldGlj
YSIgY2xhc3M9IiI+TXkgdW5kZXJzdGFuZGluZyBvZiB0aGlzIGRyYWZ0IDwvZm9udD48YSBocmVm
PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p
bmRpY2F0b3JzLTAyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFz
cz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj
ZS1pbmRpY2F0b3JzLTAyPC9hPjwvcHJlPg0KPHByZSBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEz
Njc0Z21haWwtbV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6
MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpw
YWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2Ei
IGNsYXNzPSIiPmlzIHRoYXQgdGhlIG9iamVjdC9yZXNvdXJjZSBhc3BlY3Qgb2YgYXV0aG9yaXNh
dGlvbiBpcyB0YWtlbiBzb21ld2hhdCBvdXQgb2YgdGhlIHNjb3BlIGFuZCBwdXQgaW50byBhIGRl
ZGljYXRlZCBwYXJhbWV0ZXIuIEFsdGhvdWdoICh1c2luZyB0aGUgZXhhbXBsZSBmcm9tIFJGQyA2
NzQ5KSB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGluZGljYXRlcyB0aGU8L2ZvbnQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiIGNsYXNzPSIiPjxmb250IGZhY2U9IkhlbHZldGljYSIg
Y2xhc3M9IiI+IHJlc291cmNlIHNlcnZlciAob3IgYXBwbGljYXRpb24sPC9mb250Pjwvc3Bhbj48
L3ByZT4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1
NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9w
OjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGln
YXR1cmVzOm5vcm1hbCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj4gICBBUEksIGV0
Yy4pIHJhdGhlciB0aGFuIGFuIGluZGl2aWR1YWwgcmVzb3VyY2UgdGhhdCBpcyBzdG9yZWQgYXQg
dGhlIHJlc291cmNlIHNlcnZlci4gU28gYWRkaXRpb25hbCBzY29waW5nIG9mIG9iamVjdC9yZXNv
dXJjZSBzZXQgaXMgc3RpbGwgbmVlZGVkIGluIGFkZGl0aW9uIHRvIHRoZSByZXNvdXJjZSBwYXJh
bWV0ZXIuPC9mb250PjwvcHJlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RnVydGhlcm1vcmUsPz88YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTIi
IHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMjwv
YT4/P21ha2VzIHNvbWUgaW50ZXJlc3Rpbmcgc3RhdGVtZW50cyB0aGF0DQogYXJlIHJlbGV2YW50
IGluIG15IHZpZXc6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBzZWN0aW9uIG9uIEFjY2VzcyBU
b2tlbiBwcml2aWxlZ2UgcmVzdHJpY3Rpb24gc2F5cyAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweCIgY2xhc3M9IiI+YWNjZXNzIHRva2VucyBTSE9VTEQgYmUgcmVzdHJpY3Rl
ZCB0byBjZXJ0YWluIHJlc291cmNlczwvc3Bhbj48L2Rpdj4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3
MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0i
Zm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVh
ay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+PGZvbnQgZmFjZT0i
SGVsdmV0aWNhIiBjbGFzcz0iIj4gICBhbmQgYWN0aW9ucyBvbiByZXNvdXJjZSBzZXJ2ZXJzIG9y
IHJlc291cmNlcy4/Pz8gU28gdGhlIE9BdXRoIHNjb3BlLXN0cmluZyBzdGlsbCBuZWVkcyB0byBz
b21laG93IGluZGljYXRlIHRoZSByZXNvdXJjZS1zY29wZSBvZiB0aGUgcHJpdmlsZWdlIHRoYXQg
aXMgY29tbXVuaWNhdGVkLjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3MjEwMjg1
MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZv
cmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+PGZvbnQgZmFjZT0iSGVsdmV0
aWNhIiBjbGFzcz0iIj4NCjwvZm9udD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiIGNsYXNzPSIiPiBUaGUgY2xpZW50IG5lZWRzIHRv
IHRlbGwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhdCB3aGljaCBVUkwgaXQ8L3NwYW4+PC9k
aXY+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIyMTM2NzRnbWFpbC1tXy01MzM5Mjc2NTQz
MDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDow
cHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0
dXJlczpub3JtYWwiPiAgIHdpbGwgdXNlIHRoZSBhY2Nlc3MgdG9rZW4gaXQgaXMgcmVxdWVzdGlu
Zy4gIEl0IGNvdWxkIHVzZSB0aGUNCiAgIG1lY2hhbmlzbSBwcm9wb3NlZCBbPGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNz
LTEyI3JlZi1JLUQuaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIiB0aXRsZT0iJnF1b3Q7
UmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJnF1b3Q7IiB0YXJnZXQ9Il9ibGFuayIg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5JLUQuaWV0Zi1vYXV0aC1yZXNvdXJjZS1p
bmRpY2F0b3JzPC9hPl0gb3IgZW5jb2RlIHRoZQ0KICAgaW5mb3JtYXRpb24gaW4gdGhlIHNjb3Bl
IHZhbHVlLj8/PzwvcHJlPg0KPHByZSBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21haWwt
bV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4
O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO2ZvbnQt
dmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48L3ByZT4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3MjEw
Mjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0iZm9u
dC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1i
ZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+PGZvbnQgZmFjZT0iSGVs
dmV0aWNhIiBjbGFzcz0iIj5JPz8/bSBub3Qgc3VyZSB3aGljaCBwb2ludCBJPz8/bSB0cnlpbmcg
dG8gbWFrZTsgaSBndWVzcyB0aGUgbmVlZCBmb3Igc3RhbmRhcmRpc2F0aW9uIGhvdyB0byB1c2Ug
YW5kIGRlZmluZSBPQXV0aC1zY29wZXMuPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibV83Mzgy
NTcyMTAyODUyMjEzNjc0Z21haWwtbV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxl
PSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2Jy
ZWFrLWJlZm9yZTpwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48Zm9udCBmYWNl
PSJIZWx2ZXRpY2EiIGNsYXNzPSIiPkkgbGlrZSB0aGUgTG9kZ2luZyBJbnRlbnQgUGF0dGVybiBh
bmQgbmVlZCB0byBkbyBzb21lIG1vcmUgcmVhZGluZy90aGlua2luZyBhYm91dCB0aGUgc3RydWN0
dXJlZC1zY29wZSBhbmQgcHVzaGVkIHJlcXVlc3Qgb2JqZWN0cy48L2ZvbnQ+PC9wcmU+DQo8cHJl
IGNsYXNzPSJtXzczODI1NzIxMDI4NTIyMTM2NzRnbWFpbC1tXy01MzM5Mjc2NTQzMDU1NjUzNDY0
bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2lu
LWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3Jt
YWwiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+SSBmZWVsIHRoZXNlIGNvbmNlcHRz
IGFyZSBub3Qgb25seSByZWxldmFudCBmb3IgYXV0aG9yaXNhdGlvbiBvZiB0cmFuc2FjdGlvbnMs
IGJ1dCBhbHNvIGZvciBhbnkgYWNjZXNzIHRoYXQgbmVlZHMgYXV0aG9yaXNhdGlvbi48L2ZvbnQ+
PC9wcmU+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIyMTM2NzRnbWFpbC1tXy01MzM5Mjc2
NTQzMDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRv
cDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxp
Z2F0dXJlczpub3JtYWwiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+DQo8L2ZvbnQ+
PC9wcmU+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIyMTM2NzRnbWFpbC1tXy01MzM5Mjc2
NTQzMDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206
MHB4O2JyZWFrLWJlZm9yZTpwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48Zm9u
dCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPjxmb250IHNpemU9IjIiIGNsYXNzPSIiPkk/Pz9t
IG5vdCBzdXJlIGlmIGkgZXhwcmVzcyBteXNlbGYgY2xlYXJseSwgbmV2ZXJ0aGVsZXNzIGFueSBm
ZWVkYmFjayBpcyB3ZWxjb21lLCBpZiBub3QgYWxvbmUgdG8gZ2V0IG15IHVuZGVyc3RhbmRpbmcg
b2YgdGhlIHZhcmlvdXMgY29uY2VwdHMgb24gYSBoaWdoZXIgbGV2ZWwuPC9mb250PjwvZm9udD48
L3ByZT4NCjxwcmUgY2xhc3M9Im1fNzM4MjU3MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1
NDMwNTU2NTM0NjRuZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTow
cHg7YnJlYWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPjxmb250
IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+DQo8L2Zv
bnQ+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21haWwt
bV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJn
aW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5v
cm1hbCI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFz
cz0iIj5UaGFua3MgaW4gYWR2YW5jZSwga2luZCByZWdhcmRzPC9mb250PjwvZm9udD48L3ByZT4N
CjxwcmUgY2xhc3M9Im1fNzM4MjU3MjEwMjg1MjIxMzY3NGdtYWlsLW1fLTUzMzkyNzY1NDMwNTU2
NTM0NjRuZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJl
YWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWwiPjxmb250IGZhY2U9
IkhlbHZldGljYSIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9m
b250PjwvcHJlPg0KPHByZSBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21haWwtbV8tNTMz
OTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90
dG9tOjBweDticmVhay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+
PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5K
YWFwPC9mb250PjwvZm9udD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8cHJlIGNsYXNzPSJtXzczODI1NzIxMDI4NTIyMTM2NzRnbWFpbC1tXy01MzM5Mjc2NTQz
MDU1NjUzNDY0bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDow
cHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0
dXJlczpub3JtYWwiPjwvcHJlPg0KPHByZSBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21h
aWwtbV8tNTMzOTI3NjU0MzA1NTY1MzQ2NG5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2JyZWFrLWJlZm9yZTpwYWdlO2Zv
bnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsIj48L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1lc3NhZ2U6IDE8YnIgY2xhc3M9IiI+DQpEYXRlOiBXZWQs
IDI0IEFwciAyMDE5IDE5OjA4OjI1ICYjNDM7MDIwMDxiciBjbGFzcz0iIj4NCkZyb206IFRvcnN0
ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l
dCIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+dG9yc3Rl
bkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OzxiciBjbGFzcz0iIj4NClRvOiBTYXNjaGEgUHJlaWJp
c2NoICZsdDs8YSBocmVmPSJtYWlsdG86c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+c2FzY2hhcHJlaWJpc2No
QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KQ2M6IG9hdXRoICZsdDs8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBUcmFuc2FjdGlvbiBBdXRob3JpemF0aW9uIHdpdGggT0F1dGg8YnIg
Y2xhc3M9IiI+DQpNZXNzYWdlLUlEOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOjI5OTdCNTUwLUM4MkIt
NEQzQS05NjM5LTE1QTAwNEYyRjZDNUBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIiBt
b3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPjI5OTdCNTUwLUM4MkItNEQzQS05NjM5LTE1
QTAwNEYyRjZDNUBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCkNvbnRlbnQt
VHlwZTogdGV4dC9wbGFpbjs8c3BhbiBjbGFzcz0ibV83MzgyNTcyMTAyODUyMjEzNjc0Z21haWwt
bV8tNTMzOTI3NjU0MzA1NTY1MzQ2NEFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6
cHJlLXdyYXAiPg0KPC9zcGFuPmNoYXJzZXQ9dXRmLTg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQpIaSBTYXNjaGEsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBzZWUuIEkgYXNz
dW1lIGV2ZXJ5IGVsZW1lbnQgd2l0aGluIHRoZSBzdHJ1Y3R1cmVkIHNjb3BlIGVsZW1lbnQgdG8g
YmUgYW4gaW5kZXBlbmRlbnQgc2NvcGUgKHZhbHVlKSBvYmplY3QgYW5kIGludGVuZGVkIHRvIHVz
ZSB0aGUgbmFtZSBvZiB0aGF0IG9iamVjdCBhcyBraW5kIG9mIGNvbnRlbnQgdHlwZSBkZWZpbml0
aW9uLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gbXkgbGFzdCBleGFtcGxlLCB0
aGUgc2NvcGUgaXMgZGVmaW5lZCBhcyA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo/Pz8/
JnF1b3Q7c3RydWN0dXJlZF9zY29wZSZxdW90Ozp7ID8/PGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/
PyZxdW90O3NpZ24mcXVvdDs6eyA/PzxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz8mcXVv
dDtjcmVkZW50aWFsSUQmcXVvdDs6JnF1b3Q7cWVzX2VpZGFzJnF1b3Q7LDxiciBjbGFzcz0iIj4N
Cj8/Pz8/Pz8/Pz8/Pz8/Pz8mcXVvdDtkb2N1bWVudERpZ2VzdHMmcXVvdDs6WyA/PzxiciBjbGFz
cz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz97ID8/PGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/
Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PyZxdW90O2hhc2gmcXVvdDs6PGJyIGNsYXNzPSIiPg0KPz8/Pz8/
Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8mcXVvdDtzVE9nd09tJiM0Mzs0NzRnRmowcTB4MWlT
TnNwS3FiY3NlNEllaXFsRGcvSFd1ST0mcXVvdDssPGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/
Pz8/Pz8/Pz8/Pz8/Pz8/PyZxdW90O2xhYmVsJnF1b3Q7OiZxdW90O01vYmlsZSBTdWJzY3JpcHRp
b24gQ29udHJhY3QmcXVvdDs8YnIgY2xhc3M9IiI+DQo/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/fTxi
ciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz9dLDxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/
Pz8/Pz8mcXVvdDtoYXNoQWxnb3JpdGhtT0lEJnF1b3Q7OiZxdW90OzIuMTYuODQwLjEuMTAxLjMu
NC4yLjEmcXVvdDs8YnIgY2xhc3M9IiI+DQo/Pz8/Pz8/Pz8/fSw8YnIgY2xhc3M9IiI+DQo/Pz8/
Pz8/Pz8/JnF1b3Q7cGF5bWVudCZxdW90Ozp7ID8/PGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/
Pz8/PyZxdW90O3R5cGUmcXVvdDs6JnF1b3Q7c2VwYS1jcmVkaXQtdHJhbnNmZXImcXVvdDssPGJy
IGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/Pz8/PyZxdW90O2luc3RydWN0ZWRBbW91bnQmcXVvdDs6
eyA/PzxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8mcXVvdDtjdXJyZW5jeSZx
dW90OzomcXVvdDtFVVImcXVvdDssPGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/
PyZxdW90O2Ftb3VudCZxdW90OzomcXVvdDsxMjMuNTAmcXVvdDs8YnIgY2xhc3M9IiI+DQo/Pz8/
Pz8/Pz8/Pz8/Pz8/fSw8YnIgY2xhc3M9IiI+DQo/Pz8/Pz8/Pz8/Pz8/Pz8/JnF1b3Q7ZGVidG9y
QWNjb3VudCZxdW90Ozp7ID8/PGJyIGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PyZx
dW90O2liYW4mcXVvdDs6JnF1b3Q7REU0MDEwMDEwMDEwMzMwNzExODYwOCZxdW90OzxiciBjbGFz
cz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz99LDxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz8m
cXVvdDtjcmVkaXRvck5hbWUmcXVvdDs6JnF1b3Q7TWVyY2hhbnQxMjMmcXVvdDssPGJyIGNsYXNz
PSIiPg0KPz8/Pz8/Pz8/Pz8/Pz8/PyZxdW90O2NyZWRpdG9yQWNjb3VudCZxdW90Ozp7ID8/PGJy
IGNsYXNzPSIiPg0KPz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PyZxdW90O2liYW4mcXVvdDs6JnF1b3Q7
REUwMjEwMDEwMDEwOTMwNzExODYwMyZxdW90OzxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/
Pz99LDxiciBjbGFzcz0iIj4NCj8/Pz8/Pz8/Pz8/Pz8/Pz8mcXVvdDtyZW1pdHRhbmNlSW5mb3Jt
YXRpb25VbnN0cnVjdHVyZWQmcXVvdDs6JnF1b3Q7bmV3IFNtYXJ0cGhvbmUmcXVvdDs8YnIgY2xh
c3M9IiI+DQo/Pz8/Pz8/Pz8/fTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgbWVh
bnMgP3NpZ24mcXVvdDsgYW5kID9wYXltZW50JnF1b3Q7IHdvdWxkIGRldGVybWluZSB0aGUgc2No
ZW1lIG9mIHRoZSByZXNwZWN0aXZlIG9iamVjdC4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCldoYXQgZG8geW91IHRoaW5rPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmJlc3Qg
cmVnYXJkcywgPGJyIGNsYXNzPSIiPg0KVG9yc3Rlbi4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gMjMuIEFwciAyMDE5LCBh
dCAxNzoxNCwgU2FzY2hhIFByZWliaXNjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhc2NoYXByZWli
aXNjaEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNs
YXNzPSIiPnNhc2NoYXByZWliaXNjaEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBUb3JzdGVuITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCklmICdzdHJ1Y3R1cmVkX3Njb3BlJyB3b3VsZCBiZWNvbWUgYSBnZW5lcmljIGZpZWxkIGZv
ciBhcHBsaWNhdGlvbjxiciBjbGFzcz0iIj4NCnNwZWNpZmljIGNvbnRlbnQsIEkgYmVsaWV2ZSBh
biBpbmRpY2F0b3IgZm9yIHRoZSB0eXBlIG9mIGNvbnRlbnQgd291bGQ8YnIgY2xhc3M9IiI+DQpi
ZSBuZWVkZWQgb24gdGhlIGxvbmcgcnVuLiBUaGF0IGlzIHdoYXQgSSBtZWFudCBteSAncHJvZmls
ZScuIEkgaG9wZTxiciBjbGFzcz0iIj4NCnRoaXMgaGVscHMhPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KVGhhbmsgeW91LDxiciBjbGFzcz0iIj4NClNhc2NoYTxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCkFtIE1vLiwgMjIuIEFwci4gMjAxOSB1bSAyMjowNiBVaHIgc2NocmllYiBU
b3JzdGVuIExvZGRlcnN0ZWR0PGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzp0b3Jz
dGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSIgY2xhc3M9IiI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0Ozo8YnIgY2xhc3M9IiI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpIaSBTYXNj
aGEsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg
Y2xhc3M9IiI+QW0gMjIuMDQuMjAxOSB1bSAyMDozNCBzY2hyaWViIFNhc2NoYSBQcmVpYmlzY2gg
Jmx0OzxhIGhyZWY9Im1haWx0bzpzYXNjaGFwcmVpYmlzY2hAZ21haWwuY29tIiB0YXJnZXQ9Il9i
bGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5zYXNjaGFwcmVpYmlzY2hAZ21h
aWwuY29tPC9hPiZndDs6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmsgeW91IGZv
ciB0aGUgYXJ0aWNsZSwgVG9yc3RlbiE8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg
Y2xhc3M9IiI+DQpteSBwbGVhc3VyZSA6LSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8
YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpJIGxpa2UgdGhh
dCAnc2NvcGUnIGlzIG91dCBvZiB0aGUgZ2FtZSBmb3IgdGhlc2Uga2luZHMgb2YgYXV0aG9yaXph
dGlvbnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hhdCBJIGNhbiBzZWUgZm9yIHRo
ZSBnZW5lcmFsIHVzZSBjYXNlIGlzIGEgcmVxdWlyZWQgaWRlbnRpZmllcjxiciBjbGFzcz0iIj4N
CndpdGhpbiB0aGUgJ3N0cnVjdHVyZXNfc2NvcGUnIGRvY3VtZW50IHRoYXQgaWRlbnRpZmllcyB0
aGUgcHJvZmlsZSBpdDxiciBjbGFzcz0iIj4NCnNob3VsZCBiZSB1c2VkIGZvci48YnIgY2xhc3M9
IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IGRvZXMgcHJvZmlsZSBtZWFu
IGluIHRoaXMgY29udGV4dD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpiZXN0IHJlZ2Fy
ZHMsPGJyIGNsYXNzPSIiPg0KVG9yc3Rlbi48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGFuayB5b3UsPGJyIGNsYXNzPSIiPg0K
U2FzY2hhPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQW0gU2EuLCAyMC4gQXByLiAyMDE5
IHVtIDExOjIxIFVociBzY2hyaWViIFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnIgY2xhc3M9IiI+DQom
bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu
ayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l
dDwvYT4mZ3Q7OjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCkhpIGFsbCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGp1
c3QgcHVibGlzaGVkIGFuIGFydGljbGUgYWJvdXQgdGhlIHN1YmplY3QgYXQ6IDxhIGhyZWY9Imh0
dHBzOi8vbWVkaXVtLi5jb20vb2F1dGgtMi90cmFuc2FjdGlvbi1hdXRob3JpemF0aW9uLW9yLXdo
eS13ZS1uZWVkLXRvLXJlLXRoaW5rLW9hdXRoLXNjb3Blcy0yMzI2ZTIwMzg5NDgiIHRhcmdldD0i
X2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPg0KaHR0cHM6Ly9tZWRpdW0u
Y29tL29hdXRoLTIvdHJhbnNhY3Rpb24tYXV0aG9yaXphdGlvbi1vci13aHktd2UtbmVlZC10by1y
ZS10aGluay1vYXV0aC1zY29wZXMtMjMyNmUyMDM4OTQ4PC9hPjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCkkgbG9vayBmb3J3YXJkIHRvIGdldHRpbmcgeW91ciBmZWVkYmFjay48YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpraW5kIHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KVG9yc3Rl
bi48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0
PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBEaWdlc3Qg
Rm9vdGVyPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9h
PjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNz
PSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRW5kIG9mIE9BdXRoIERp
Z2VzdCwgVm9sIDEyNiwgSXNzdWUgNTg8YnIgY2xhc3M9IiI+DQoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPk9BdXRoQGlldGYub3Jn
PC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50
SGVhZGVyIj48L2ZpZWxkc2V0Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQt
bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4N
CjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRo
IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_6DB0AFDC56374CC2AB437BECDBF978DBmitedu_--


From nobody Wed May 15 13:55: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 EA5AD12010F for ; Wed, 15 May 2019 13:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkknf0eWqWUs for ; Wed, 15 May 2019 13:54:46 -0700 (PDT)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA25120106 for ; Wed, 15 May 2019 13:54:45 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x4FKsTgt019064; Wed, 15 May 2019 16:54:45 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 16:54:31 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 15 May 2019 16:54:34 -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; Wed, 15 May 2019 16:54:34 -0400
From: Justin Richer 
To: Takahiko Kawasaki 
CC: oauth 
Thread-Topic: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection
Thread-Index: AQHVBKI2qWhovuHGfke9RwvZb6FCqaZs+pWA
Date: Wed, 15 May 2019 20:54:33 +0000
Message-ID: 
References: 
In-Reply-To: 
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_FB6515762A014E73800FD6AC221BCB6Amitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection
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, 15 May 2019 20:54:55 -0000

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

VGhpcyBpcyBub3QgYW4gZWFzeSBxdWVzdGlvbiB0byBhbnN3ZXIsIGFzIHJlc291cmNlIHNlcnZl
cnMgaW4gT0F1dGggaGF2ZSBuZXZlciByZWFsbHkgaGFkIGEgc3Ryb25nIGlkZW50aXR5IChvciBp
ZGVudGlmaWVyKSB3aXRoaW4gdGhlIE9BdXRoIGVjb3N5c3RlbS4gVGhlIFJlc291cmNlIElkZW50
aWZpZXJzIGRyYWZ0IFsxXSB0cmllcyB0byBhZGRyZXNzIHRoaXMgc29tZXdoYXQuIEluIHByYWN0
aWNlLCBtYW55IHJlc291cmNlIHNlcnZlcnMgYXJlIHJlZ2lzdGVyZWQgYW5kIHN0b3JlZCBhcyDi
gJxjbGllbnRz4oCdIGF0IGFuIEFTIHNvIHRoYXQgdGhlIEFTIGNhbiByZS11c2UgYXV0aGVudGlj
YXRpb24gY29kZSBwYXRocyBhbmQgc3RvcmFnZSBzeXN0ZW1zLiBJIGtub3cgdGhhdCBpbiBzZXZl
cmFsIGxhcmdlIGRlcGxveW1lbnRzIHRoYXQgSeKAmXZlIHdvcmtlZCBvbiwgcmVzb3VyY2VzIGFy
ZSBzdG9yZWQgYXMgY2xpZW50cyB3aXRoIGVtcHR5IOKAnGdyYW50X3R5cGVz4oCdIGFuZCDigJxy
ZXNwb25zZV90eXBlc+KAnSBhcnJheXMsIGFuZCB3aXRoIGEgZmxhZyBzZXQgdG8gYWxsb3cgdGhl
bSB0byBjYWxsIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50LiBPdGhlcndpc2UgdGhleSBhcmUg
YWxsIOKAnGNsaWVudOKAnSBvYmplY3RzIGFuZCB0aGVyZWZvcmUgZ2V0IOKAmGNsaWVudF9pZOKA
mSBmaWVsZHMgYXNzaWduZWQgdG8gdGhlbSwgd2hpY2ggd291bGQgYmUgd2hhdCB0aGUg4oCcYXVk
4oCdIHdvdWxkIGJlIGluIHRoaXMgY2FzZSwgbW9zdCBsaWtlbHkuDQoNCkhvd2V2ZXIsIHVubGlr
ZSBjbGllbnRzLCByZXNvdXJjZSBzZXJ2ZXJzIGFyZ3VhYmx5IGFsd2F5cyBoYXZlIGF0IGxlYXN0
IG9uZSBVUkwgYXNzb2NpYXRlZCB3aXRoIHRoZW0uIFRoZSByZWFsIHByb2JsZW0gY29tZXMgZnJv
bSB0aGUgZmFjdCB0aGF0IHRoZSDigJxyZXNvdXJjZeKAnSBpc27igJl0IGVhc2lseSBkZWZpbmVk
IGJ5IGEgc2luZ2xlIFVSTC4NCg0K4oCUIEp1c3Rpbg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycw0KDQoNCk9uIE1h
eSA3LCAyMDE5LCBhdCAyOjU3IEFNLCBUYWthaGlrbyBLYXdhc2FraSA8dGFrYUBhdXRobGV0ZS5j
b208bWFpbHRvOnRha2FAYXV0aGxldGUuY29tPj4gd3JvdGU6DQoNCkhlbGxvLA0KDQpJIGhhdmUg
YSBxdWVzdGlvbiByZWdhcmRpbmcgIkpXVCBSZXNwb25zZSBmb3IgT0F1dGggVG9rZW4gSW50cm9z
cGVjdGlvbiIgKGRyYWZ0LTAyKS4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS8/aW5jbHVkZV90ZXh0
PTENCg0KSG93IHRvIGRldGVybWluZSB0aGUgdmFsdWUgb2YgImF1ZCIgaW4gdGhlIHJlc3BvbnNl
IEpXVD8NCg0KVGhlIGV4YW1wbGUgcGF5bG9hZCB1c2VzICJodHRwczovL3Byb3RlY3RlZC5leGFt
cGxlLm5ldC9yZXNvdXJjZSIgYXMgdGhlIHZhbHVlIG9mICJhdWQiLiBUaGUgZXhhbXBsZSB2YWx1
ZSBpbXBsaWVzIHRoYXQgaXQgcmVwcmVzZW50cyB0aGUgaWRlbnRpZmllciBvZiB0aGUgdGFyZ2V0
IHJlc291cmNlIG9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGJ1dCBob3cgZG9lcyBhbiBhdXRob3Jp
emF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBrbm93IHRoZSBpZGVudGlmaWVyPyBJJ20gc29y
cnkgaWYgdGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZC4NCg0KVG8gYmUgaG9uZXN0LCBJ
IGZlYXIgdGhhdCBzb21lIGluY29uc2lzdGVuY2llcyBtaWdodCBvY2N1ciBpbiBmdXR1cmUgYnkg
dHJlYXRpbmcgcmVzb3VyY2Ugc2VydmVycyBhcyBjbGllbnRzLiBJZiBJIGhhZCB0byB3cml0ZSB0
aGUgc3BlY2lmaWNhdGlvbiwgSSB3b3VsZCBzdGFydCBmcm9tIGRlZmluaW5nICJyZXNvdXJjZSBz
ZXJ2ZXIgbWV0YWRhdGEiIChlLmcuIGV4cGlyZWQgZHJhZnQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWpvbmVzLW9hdXRoLXJlc291cmNlLW1ldGFkYXRhLykgYW5kIGRl
dmlzaW5nIGEgd2F5IHRvIHJlZ2lzdGVyIHJlc291cmNlIHNlcnZlcnMgaW50byBhbiBhdXRob3Jp
emF0aW9uIHNlcnZlciBhbmQgaXNzdWUgcmVzb3VyY2Ugc2VydmVyIGNyZWRlbnRpYWxzIChlLmcu
IHJzX2lkIGFuZCByc19zZWNyZXQsIFJTIEpXSyBTZXQsIGV0Yy4pIGluIG9yZGVyIHRvIHRyZWF0
IHJlc291cmNlIHNlcnZlcnMgYW5kIGNsaWVudHMgYXMgZGlmZmVyZW50IGVudGl0aWVzIGV4cGxp
Y2l0bHkuIEkgaG9wZSB0aGF0IGRpc2N1c3Npb24gZm9yIGRpc3Rpbmd1aXNoaW5nICJyZXNvdXJj
ZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24iIGZyb20gImNsaWVudCBhdXRoZW50aWNhdGlvbiIgd2ls
bCBiZSBpbml0aWF0ZWQgc29tZXRpbWUgaW4gZnV0dXJlLg0KDQpCZXN0IFJlZ2FyZHMsDQpUYWth
aGlrbyBLYXdhc2FraQ0KQXV0aGxldGUsIEluYy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0KDQo=

--_000_FB6515762A014E73800FD6AC221BCB6Amitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <550F8E496AB56C4E88FCD9A7B9B0EC8F@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoaXMgaXMgbm90IGFuIGVhc3kgcXVlc3Rpb24g
dG8gYW5zd2VyLCBhcyByZXNvdXJjZSBzZXJ2ZXJzIGluIE9BdXRoIGhhdmUgbmV2ZXIgcmVhbGx5
IGhhZCBhIHN0cm9uZyBpZGVudGl0eSAob3IgaWRlbnRpZmllcikgd2l0aGluIHRoZSBPQXV0aCBl
Y29zeXN0ZW0uIFRoZSBSZXNvdXJjZSBJZGVudGlmaWVycyBkcmFmdCBbMV0gdHJpZXMgdG8gYWRk
cmVzcyB0aGlzIHNvbWV3aGF0LiBJbiBwcmFjdGljZSwgbWFueSByZXNvdXJjZSBzZXJ2ZXJzIGFy
ZQ0KIHJlZ2lzdGVyZWQgYW5kIHN0b3JlZCBhcyDigJxjbGllbnRz4oCdIGF0IGFuIEFTIHNvIHRo
YXQgdGhlIEFTIGNhbiByZS11c2UgYXV0aGVudGljYXRpb24gY29kZSBwYXRocyBhbmQgc3RvcmFn
ZSBzeXN0ZW1zLiBJIGtub3cgdGhhdCBpbiBzZXZlcmFsIGxhcmdlIGRlcGxveW1lbnRzIHRoYXQg
SeKAmXZlIHdvcmtlZCBvbiwgcmVzb3VyY2VzIGFyZSBzdG9yZWQgYXMgY2xpZW50cyB3aXRoIGVt
cHR5IOKAnGdyYW50X3R5cGVz4oCdIGFuZCDigJxyZXNwb25zZV90eXBlc+KAnQ0KIGFycmF5cywg
YW5kIHdpdGggYSBmbGFnIHNldCB0byBhbGxvdyB0aGVtIHRvIGNhbGwgdGhlIGludHJvc3BlY3Rp
b24gZW5kcG9pbnQuIE90aGVyd2lzZSB0aGV5IGFyZSBhbGwg4oCcY2xpZW504oCdIG9iamVjdHMg
YW5kIHRoZXJlZm9yZSBnZXQg4oCYY2xpZW50X2lk4oCZIGZpZWxkcyBhc3NpZ25lZCB0byB0aGVt
LCB3aGljaCB3b3VsZCBiZSB3aGF0IHRoZSDigJxhdWTigJ0gd291bGQgYmUgaW4gdGhpcyBjYXNl
LCBtb3N0IGxpa2VseS4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIsIHVubGlrZSBjbGllbnRzLCByZXNvdXJjZSBzZXJ2ZXJz
IGFyZ3VhYmx5IGFsd2F5cyBoYXZlIGF0IGxlYXN0IG9uZSBVUkwgYXNzb2NpYXRlZCB3aXRoIHRo
ZW0uIFRoZSByZWFsIHByb2JsZW0gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSDigJxyZXNv
dXJjZeKAnSBpc27igJl0IGVhc2lseSBkZWZpbmVkIGJ5IGEgc2luZ2xlIFVSTC48YnIgY2xhc3M9
IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh
dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyIgY2xhc3M9
IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut
aW5kaWNhdG9yczwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K
PGRpdiBjbGFzcz0iIj5PbiBNYXkgNywgMjAxOSwgYXQgMjo1NyBBTSwgVGFrYWhpa28gS2F3YXNh
a2kgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWthQGF1dGhsZXRlLmNvbSIgY2xhc3M9IiI+dGFrYUBh
dXRobGV0ZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj
aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+
DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj5IZWxsbyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPkkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyAmcXVvdDtKV1Qg
UmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24mcXVvdDsgKGRyYWZ0LTAyKS48
L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1
dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UvP2luY2x1ZGVfdGV4dD0xIiBjbGFzcz0iIj5o
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRy
b3NwZWN0aW9uLXJlc3BvbnNlLz9pbmNsdWRlX3RleHQ9MTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhvdyB0byBkZXRlcm1pbmUg
dGhlIHZhbHVlIG9mICZxdW90O2F1ZCZxdW90OyBpbiB0aGUgcmVzcG9uc2UgSldUPzwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGV4
YW1wbGUgcGF5bG9hZCB1c2VzICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdGVkLmV4YW1w
bGUubmV0L3Jlc291cmNlIiBjbGFzcz0iIj5odHRwczovL3Byb3RlY3RlZC5leGFtcGxlLm5ldC9y
ZXNvdXJjZTwvYT4mcXVvdDsgYXMgdGhlIHZhbHVlIG9mICZxdW90O2F1ZCZxdW90Oy4gVGhlIGV4
YW1wbGUgdmFsdWUgaW1wbGllcyB0aGF0IGl0IHJlcHJlc2VudHMgdGhlIGlkZW50aWZpZXIgb2Yg
dGhlIHRhcmdldCByZXNvdXJjZSBvciB0aGUgcmVzb3VyY2UNCiBzZXJ2ZXIsIGJ1dCBob3cgZG9l
cyBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBrbm93IHRoZSBpZGVudGlm
aWVyPyBJJ20gc29ycnkgaWYgdGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZC48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvIGJl
IGhvbmVzdCwgSSBmZWFyIHRoYXQgc29tZSBpbmNvbnNpc3RlbmNpZXMgbWlnaHQgb2NjdXIgaW4g
ZnV0dXJlIGJ5IHRyZWF0aW5nIHJlc291cmNlIHNlcnZlcnMgYXMgY2xpZW50cy4gSWYgSSBoYWQg
dG8gd3JpdGUgdGhlIHNwZWNpZmljYXRpb24sIEkgd291bGQgc3RhcnQgZnJvbSBkZWZpbmluZyAm
cXVvdDtyZXNvdXJjZSBzZXJ2ZXIgbWV0YWRhdGEmcXVvdDsgKGUuZy4gZXhwaXJlZCBkcmFmdDom
bmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb25l
cy1vYXV0aC1yZXNvdXJjZS1tZXRhZGF0YS8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWpvbmVzLW9hdXRoLXJlc291cmNlLW1ldGFkYXRhLzwvYT4pDQog
YW5kIGRldmlzaW5nIGEgd2F5IHRvIHJlZ2lzdGVyIHJlc291cmNlIHNlcnZlcnMgaW50byBhbiBh
dXRob3JpemF0aW9uIHNlcnZlciBhbmQgaXNzdWUgcmVzb3VyY2Ugc2VydmVyIGNyZWRlbnRpYWxz
IChlLmcuIHJzX2lkIGFuZCByc19zZWNyZXQsIFJTIEpXSyBTZXQsIGV0Yy4pIGluIG9yZGVyIHRv
IHRyZWF0IHJlc291cmNlIHNlcnZlcnMgYW5kIGNsaWVudHMgYXMgZGlmZmVyZW50IGVudGl0aWVz
IGV4cGxpY2l0bHkuIEkgaG9wZSB0aGF0IGRpc2N1c3Npb24NCiBmb3IgZGlzdGluZ3Vpc2hpbmcg
JnF1b3Q7cmVzb3VyY2Ugc2VydmVyIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IGZyb20gJnF1b3Q7Y2xp
ZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7IHdpbGwgYmUgaW5pdGlhdGVkIHNvbWV0aW1lIGluIGZ1
dHVyZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPkJlc3QgUmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGFrYWhpa28gS2F3YXNh
a2k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXV0aGxldGUsIEluYy48L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9B
dXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm
Lm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_FB6515762A014E73800FD6AC221BCB6Amitedu_--


From nobody Wed May 15 14:07: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 7D1A8120857 for ; Wed, 15 May 2019 14:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quHiICTA2Iz9 for ; Wed, 15 May 2019 14:07:17 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 9A3C91207FF for ; Wed, 15 May 2019 14:07:12 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x4FL8PSc026404; Wed, 15 May 2019 17:08:25 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 17:06:28 -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; Wed, 15 May 2019 17:07:08 -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; Wed, 15 May 2019 17:07:08 -0400
From: Justin Richer 
To: Hannes Tschofenig 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] MTLS vs. DPOP
Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQG1poeA
Date: Wed, 15 May 2019 21:07:07 +0000
Message-ID: <9FDD4D1A-7548-4415-9276-F22AE8ACB2A3@mit.edu>
References: 
In-Reply-To: 
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_9FDD4D1A754844159276F22AE8ACB2A3mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS vs. DPOP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 21:07:20 -0000

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

Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCBpZiB3ZSB0aGluayBvZiB0aGluZ3MgYSBsaXR0bGUgYml0
IGRpZmZlcmVudGx5LCB3ZSBjYW4gc3VwcG9ydCBib3RoIHR5cGVzIG9mIGtleSBwcmVzZW50YXRp
b24gYW5kIHBvc3Nlc3Npb24gcHJvb2ZzIGluIHBhcmFsbGVsLiBNeSB0aGlua2luZyB3YXMgdGhh
dCBpbiBib3RoIHRoZSBNVExTIGFuZCBEUG9QIGNhc2VzLCB0aGUgY2xpZW50IHByb3ZlcyB0aGF0
IGl0IGhhcyBhY2Nlc3MgdG8gYSBrZXkgYW5kIHRoZW4gdXNlcyB0aGF0IGtleSB3aXRoIHRoZSBS
UyBpbiB0aGUgc2FtZSB3YXkgaXQgdXNlcyBpdCB3aXRoIHRoZSBBUy4gVGhlIGZvcm1hdCBvZiB0
aGUga2V5IGFuZCBpdHMgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBkaWZmZXIsIGJ1dCBvdGhlcndp
c2UgdGhlcmUgcmVhbGx5IGFyZSBhIGxvdCBvZiBwYXJhbGxlbHMuIFRoaXMgaXMgaG93IEnigJl2
ZSBiZWVuIHRoaW5raW5nIG9mIGl0IGluIHRoZSBYWVogcHJvamVjdDoNCg0KaHR0cHM6Ly9vYXV0
aC54eXova2V5cy8NCg0KSXTigJlzIHN0aWxsIHZlcnktZHJhZnR5IGF0IHRoZSBtb21lbnQsIGJ1
dCBpdCBmb2xsb3dzIGFzIGFuIGFic3RyYWN0aW9uIHRvIHRoaXMgdGhpbmtpbmcuIEluIFhZWiB0
aGlzIGlzIGEgYml0IHNpbXBsaWZpZWQgYmVjYXVzZSB0aGUgY2xpZW50IGFsd2F5cyBzdGFydHMg
YXQgdGhlIGJhY2tjaGFubmVsIGVuZHBvaW50IChlcXVpdmFsZW50IHRvIHRoZSB0b2tlbiBlbmRw
b2ludCkuIEluIE9BdXRoMiwgdGhpcyB3b3VsZCBoYXBwZW4gZHVyaW5nIHRoZSBjYWxsIHRvIHRo
ZSB0b2tlbiBlbmRwb2ludCwgYXMgaW4gdGhlIERQb1AgYW5kIE1UTFMgZHJhZnRzLg0KDQrigJQg
SnVzdGluDQoNCk9uIE1heSA3LCAyMDE5LCBhdCA0OjI1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8
SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv
bT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkluIHRoZSBPQXV0aCBjb25mZXJlbmNlIGNhbGwgdG9k
YXkgVml0dG9yaW8gbWVudGlvbmVkIHRoYXQgc29tZSBmb2xrcyBhcmUgd29uZGVyaW5nIHdoZXRo
ZXIgRFBPUCBpcyBlc3NlbnRpYWxseSBhIHN1cGVyc2V0IG9mIE1UTFMgYW5kIHdoZXRoZXIgaXQg
bWFrZXMgc2Vuc2UgdG8gb25seSBwcm9jZWVkIHdpdGggb25lIHNvbHV0aW9uIHJhdGhlciBwb3Rl
bnRpYWxseSB0d28uDQoNCkkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIG90aGVycyBpbiB0aGUgZ3Jv
dXAgaGF2ZSBhIGZldyBhYm91dCB0aGlzIGFzcGVjdD8NCg0KQ2lhbw0KSGFubmVzDQoNCklNUE9S
VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy
ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt
bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw
ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y
bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0KDQo=

--_000_9FDD4D1A754844159276F22AE8ACB2A3mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <7A768CD8FAA1904594FE0F45C393B313@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZvciB3aGF0IGl04oCZcyB3b3J0aCwgaWYgd2Ug
dGhpbmsgb2YgdGhpbmdzIGEgbGl0dGxlIGJpdCBkaWZmZXJlbnRseSwgd2UgY2FuIHN1cHBvcnQg
Ym90aCB0eXBlcyBvZiBrZXkgcHJlc2VudGF0aW9uIGFuZCBwb3NzZXNzaW9uIHByb29mcyBpbiBw
YXJhbGxlbC4mbmJzcDtNeSB0aGlua2luZyB3YXMgdGhhdCBpbiBib3RoIHRoZSBNVExTIGFuZCBE
UG9QIGNhc2VzLCB0aGUgY2xpZW50IHByb3ZlcyB0aGF0IGl0IGhhcyBhY2Nlc3MgdG8gYSBrZXkg
YW5kIHRoZW4NCiB1c2VzIHRoYXQga2V5IHdpdGggdGhlIFJTIGluIHRoZSBzYW1lIHdheSBpdCB1
c2VzIGl0IHdpdGggdGhlIEFTLiBUaGUgZm9ybWF0IG9mIHRoZSBrZXkgYW5kIGl0cyBwcmVzZW50
YXRpb24gbWVjaGFuaXNtIGRpZmZlciwgYnV0IG90aGVyd2lzZSB0aGVyZSByZWFsbHkgYXJlIGEg
bG90IG9mIHBhcmFsbGVscy4gVGhpcyBpcyBob3cgSeKAmXZlIGJlZW4gdGhpbmtpbmcgb2YgaXQg
aW4gdGhlIFhZWiBwcm9qZWN0Og0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9vYXV0aC54eXova2V5cy8iIGNsYXNzPSIi
Pmh0dHBzOi8vb2F1dGgueHl6L2tleXMvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXTigJlzIHN0aWxsIHZlcnktZHJhZnR5IGF0
IHRoZSBtb21lbnQsIGJ1dCBpdCBmb2xsb3dzIGFzIGFuIGFic3RyYWN0aW9uIHRvIHRoaXMgdGhp
bmtpbmcuIEluIFhZWiB0aGlzIGlzIGEgYml0IHNpbXBsaWZpZWQgYmVjYXVzZSB0aGUgY2xpZW50
IGFsd2F5cyBzdGFydHMgYXQgdGhlIGJhY2tjaGFubmVsIGVuZHBvaW50IChlcXVpdmFsZW50IHRv
IHRoZSB0b2tlbiBlbmRwb2ludCkuIEluIE9BdXRoMiwgdGhpcyB3b3VsZCBoYXBwZW4NCiBkdXJp
bmcgdGhlIGNhbGwgdG8gdGhlIHRva2VuIGVuZHBvaW50LCBhcyBpbiB0aGUgRFBvUCBhbmQgTVRM
UyBkcmFmdHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAs
IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h
bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6
ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv
cmF0aW9uOiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz
PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u
IE1heSA3LCAyMDE5LCBhdCA0OjI1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIGNsYXNzPSIiPkhhbm5lcy5Uc2Nob2Zl
bmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj
aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
IiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm
b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h
bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy
LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7
Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu
Zz0iRU4tVVMiIGNsYXNzPSIiPkhpIGFsbCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp
dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu
Zz0iRU4tVVMiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5n
PSJFTi1VUyIgY2xhc3M9IiI+SW4gdGhlIE9BdXRoIGNvbmZlcmVuY2UgY2FsbCB0b2RheSBWaXR0
b3JpbyBtZW50aW9uZWQgdGhhdCBzb21lIGZvbGtzIGFyZSB3b25kZXJpbmcgd2hldGhlciBEUE9Q
IGlzIGVzc2VudGlhbGx5IGEgc3VwZXJzZXQgb2YgTVRMUyBhbmQgd2hldGhlciBpdCBtYWtlcyBz
ZW5zZSB0byBvbmx5IHByb2NlZWQgd2l0aCBvbmUgc29sdXRpb24gcmF0aGVyIHBvdGVudGlhbGx5
IHR3by48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp
bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy
aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxv
OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+SSB3
YXMgd29uZGVyaW5nIHdoZXRoZXIgb3RoZXJzIGluIHRoZSBncm91cCBoYXZlIGEgZmV3IGFib3V0
IHRoaXMgYXNwZWN0PzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xh
c3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFz
cz0iIj5DaWFvPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0i
Ij5IYW5uZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIi
PjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBz
dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTog
aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JTVBPUlRBTlQNCiBOT1RJQ0U6IFRoZSBjb250
ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh
bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl
Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg
ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55
IHB1cnBvc2UsIG9yDQogc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1
bS4gVGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz
PSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5
OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5v
bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T0F1dGgNCiBtYWlsaW5n
IGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh
bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl
YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz
cz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiByZ2Io
MTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHN0eWxlPSJjb2xv
cjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6
IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_9FDD4D1A754844159276F22AE8ACB2A3mitedu_--


From nobody Wed May 15 14:08: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 8BFBA1200A2 for ; Wed, 15 May 2019 14:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0lSpV9nhuug for ; Wed, 15 May 2019 14:08:28 -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 16B29120074 for ; Wed, 15 May 2019 14:08:27 -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 x4FL8OFL011238 for ; Wed, 15 May 2019 17:08:26 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 17:08:22 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 15 May 2019 17:08:24 -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; Wed, 15 May 2019 17:08:24 -0400
From: Justin Richer 
To: oauth 
Thread-Topic: [OAUTH-WG] XYZ and Transactional OAuth
Thread-Index: AQHVBEP7W/TPKVA82ke/Vd+HgyQ+VKZs/y4A
Date: Wed, 15 May 2019 21:08:24 +0000
Message-ID: <3C145BC0-E740-413A-84F1-ECD62DFB096A@mit.edu>
References: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@mit.edu>
In-Reply-To: <5C245C9E-DB46-4D4C-8788-821F5C11C8FD@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_3C145BC0E740413A84F1ECD62DFB096Amitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] XYZ and Transactional OAuth
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, 15 May 2019 21:08:30 -0000

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

SeKAmXZlIHN1Ym1pdHRlZCBteSBkcmFmdCBvZiBYWVogYXMgYW4gSUQ6DQoNCmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wMA0KDQri
gJQgSnVzdGluDQoNCk9uIE1heSA2LCAyMDE5LCBhdCAzOjQzIFBNLCBKdXN0aW4gUmljaGVyIDxq
cmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpJbiBhIHZl
aW4gcmVsYXRlZCB0byBUb3JzdGVu4oCZcyByZWNlbnQgdGhyZWFkIGFuZCBibG9nIHBvc3QsIEni
gJl2ZSBhbHNvIGJlZW4gd29ya2luZyBvbiBhIHByb3Bvc2FsIGFyb3VuZCBUcmFuc2FjdGlvbmFs
IE9BdXRoLiBBcyBtYW55IG9mIHlvdSBrbm93LCBJIHdyb3RlIGEgYmxvZyBwb3N0IGFib3V0IHRo
ZSBiYXNpYyBpZGVhIGxhc3QgZmFsbCwgYW5kIG5vdyBJ4oCZdmUgZ290IHNvbWV0aGluZyBhIGJp
dCBtb3JlIGNvbmNyZXRlIG9ubGluZSB0aGF0IHBlb3BsZSBjYW4gcG9rZSBhcm91bmQgd2l0aC4g
SeKAmW0gY2FsbGluZyBpdCDigJxYWVrigJ0ganVzdCB0byBnaXZlIGl0IGEgbmFtZSwgYW5kIGl0
4oCZcyBvbmxpbmUgaGVyZToNCg0KaHR0cHM6Ly9vYXV0aC54eXovDQoNCkkgbmVlZCB0byBiZSB2
ZXJ5IGNsZWFyOiBUaGlzIGlzIG5vdCB3aXJlLWNvbXBhdGlibGUgd2l0aCBPQXV0aDIsIGJ1dCBp
cyBpbnN0ZWFkIGEgdHJhbnNhY3Rpb25hbCAoaW50ZW50LXBhdHRlcm4pIHByb3RvY29sIHRoYXQg
aW1wbGVtZW50cyBhIGxvdCBvZiB0aGUgY29yZSBjb25jZXB0cyBhbmQgYSBmZXcgbmV3IG9uZXMg
aW4gYSBkaWZmZXJlbnQgZnJhbWV3b3JrLiBUaGVyZSBoYXZlIGJlZW4gYSBsb3Qgb2YgYXR0ZW1w
dHMgdG8gZXh0ZW5kIGFuZCBhZGFwdCBPQXV0aCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMsIGFuZCBp
biBteSBvcGluaW9uIHRoYXTigJlzIGdvdHRlbiB1cyBwYWludGVkIGludG8gYSBiaXQgb2YgYSBj
b3JuZXIgYXMgd2Uga2VlcCB0cnlpbmcgdG8gc29sdmUgbmV3IHByb2JsZW1zLiBCeSBicmVha2lu
ZyBhd2F5IGZyb20gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIEkgZm91bmQgdGhhdCB3YXMgYWJs
ZSB0byBib3RoIHNpbXBsaWZ5IGEgbG90IG9mIHRoZSBjb25jZXB0cywgbWFrZSBkaWZmZXJlbnQg
YWN0aW9ucyBtb3JlIGNvbnNpc3RlbnQsIGFuZCBtYWtlIGl0IG1vcmUgd2lkZWx5IGZsZXhpYmxl
Lg0KDQpBbHNvIHRvIG5vdGUsIEnigJl2ZSByZWFkIHRocm91Z2ggVG9yc3RlbuKAmXMgZHJhZnQs
IGFuZCBJIHRoaW5rIHRoYXQgaGlzIGlkZWFzIG9mIHdoYXTigJlzIGluIGEg4oCcU3RydWN0dXJl
ZCBTY29wZeKAnSBjb3VsZCBiZSBhIHJlcGxhY2VtZW50IGZvciB0aGUgaGFuZC13YXZpbmcgaWRl
YSBJIGhhdmUgaW4gdGhlIOKAnHJlc291cmNlc+KAnSBzZWN0aW9uIG9mIFhZWi4gSeKAmW0gY29u
dGludWluZyBkZXZlbG9wbWVudCBvZiB0aGlzIHByb3RvY29sLCBpbmNsdWRpbmcgYSBjb3VwbGUg
dG95IGltcGxlbWVudGF0aW9ucywgYWxsIG9mIHRoZW0gb3BlbiBzb3VyY2UuIEkgaGF2ZSBzdGFy
dGVkIGEgd3JpdGV1cCBpbiBzcGVjLWxhbmd1YWdlLCBhbmQgSSBwbGFuIHRvIGhhdmUgaXQgY2xl
YW5lZCB1cCBhbmQgc3VibWl0dGVkIHByaW9yIHRvIE1vbnRyZWFsIOKAlCB3aGVyZSBJ4oCZbGwg
YmUgYXR0ZW5kaW5nIGluIHBlcnNvbiBhbmQgaG9wZSB0byBkaXNjdXNzIHRoaXMgYXMgYSBwb3Rl
bnRpYWwgV0cgaXRlbS4NCg0K4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJl2ZSBzdWJtaXR0ZWQgbXkgZHJhZnQgb2Yg
WFlaIGFzIGFuIElEOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hl
ci10cmFuc2FjdGlvbmFsLWF1dGh6LTAwIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDA8L2E+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJl
dC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQrigJQg
SnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSA2LCAyMDE5LCBhdCAzOjQz
IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBj
bGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i
QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i
d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl
YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJbiBhIHZlaW4gcmVsYXRlZCB0byBU
b3JzdGVu4oCZcyByZWNlbnQgdGhyZWFkIGFuZCBibG9nIHBvc3QsIEnigJl2ZSBhbHNvIGJlZW4g
d29ya2luZyBvbiBhIHByb3Bvc2FsIGFyb3VuZCBUcmFuc2FjdGlvbmFsIE9BdXRoLiBBcyBtYW55
IG9mIHlvdSBrbm93LCBJIHdyb3RlIGEgYmxvZyBwb3N0IGFib3V0IHRoZSBiYXNpYyBpZGVhIGxh
c3QgZmFsbCwgYW5kIG5vdyBJ4oCZdmUgZ290IHNvbWV0aGluZyBhIGJpdCBtb3JlIGNvbmNyZXRl
IG9ubGluZSB0aGF0DQogcGVvcGxlIGNhbiBwb2tlIGFyb3VuZCB3aXRoLiBJ4oCZbSBjYWxsaW5n
IGl0IOKAnFhZWuKAnSBqdXN0IHRvIGdpdmUgaXQgYSBuYW1lLCBhbmQgaXTigJlzIG9ubGluZSBo
ZXJlOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
PGEgaHJlZj0iaHR0cHM6Ly9vYXV0aC54eXovIiBjbGFzcz0iIj5odHRwczovL29hdXRoLnh5ei88
L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj5JIG5lZWQgdG8gYmUgdmVyeSBjbGVhcjogVGhpcyBpcyBub3Qgd2lyZS1jb21wYXRpYmxl
IHdpdGggT0F1dGgyLCBidXQgaXMgaW5zdGVhZCBhIHRyYW5zYWN0aW9uYWwgKGludGVudC1wYXR0
ZXJuKSBwcm90b2NvbCB0aGF0IGltcGxlbWVudHMgYSBsb3Qgb2YgdGhlIGNvcmUgY29uY2VwdHMg
YW5kIGEgZmV3IG5ldyBvbmVzIGluIGEgZGlmZmVyZW50IGZyYW1ld29yay4gVGhlcmUgaGF2ZSBi
ZWVuIGEgbG90IG9mIGF0dGVtcHRzDQogdG8gZXh0ZW5kIGFuZCBhZGFwdCBPQXV0aCBpbiB0aGUg
bGFzdCBmZXcgeWVhcnMsIGFuZCBpbiBteSBvcGluaW9uIHRoYXTigJlzIGdvdHRlbiB1cyBwYWlu
dGVkIGludG8gYSBiaXQgb2YgYSBjb3JuZXIgYXMgd2Uga2VlcCB0cnlpbmcgdG8gc29sdmUgbmV3
IHByb2JsZW1zLiBCeSBicmVha2luZyBhd2F5IGZyb20gYmFja3dhcmRzIGNvbXBhdGliaWxpdHks
IEkgZm91bmQgdGhhdCB3YXMgYWJsZSB0byBib3RoIHNpbXBsaWZ5IGEgbG90IG9mIHRoZSBjb25j
ZXB0cywNCiBtYWtlIGRpZmZlcmVudCBhY3Rpb25zIG1vcmUgY29uc2lzdGVudCwgYW5kIG1ha2Ug
aXQgbW9yZSB3aWRlbHkgZmxleGlibGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbHNvIHRvIG5vdGUsIEnigJl2ZSByZWFk
IHRocm91Z2ggVG9yc3RlbuKAmXMgZHJhZnQsIGFuZCBJIHRoaW5rIHRoYXQgaGlzIGlkZWFzIG9m
IHdoYXTigJlzIGluIGEg4oCcU3RydWN0dXJlZCBTY29wZeKAnSBjb3VsZCBiZSBhIHJlcGxhY2Vt
ZW50IGZvciB0aGUgaGFuZC13YXZpbmcgaWRlYSBJIGhhdmUgaW4gdGhlIOKAnHJlc291cmNlc+KA
nSBzZWN0aW9uIG9mIFhZWi4gSeKAmW0gY29udGludWluZyBkZXZlbG9wbWVudCBvZiB0aGlzIHBy
b3RvY29sLA0KIGluY2x1ZGluZyBhIGNvdXBsZSB0b3kgaW1wbGVtZW50YXRpb25zLCBhbGwgb2Yg
dGhlbSBvcGVuIHNvdXJjZS4gSSBoYXZlIHN0YXJ0ZWQgYSB3cml0ZXVwIGluIHNwZWMtbGFuZ3Vh
Z2UsIGFuZCBJIHBsYW4gdG8gaGF2ZSBpdCBjbGVhbmVkIHVwIGFuZCBzdWJtaXR0ZWQgcHJpb3Ig
dG8gTW9udHJlYWwg4oCUIHdoZXJlIEnigJlsbCBiZSBhdHRlbmRpbmcgaW4gcGVyc29uIGFuZCBo
b3BlIHRvIGRpc2N1c3MgdGhpcyBhcyBhIHBvdGVudGlhbCBXRyBpdGVtLjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQt
Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx
MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg
dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rp
dj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlz
dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3C145BC0E740413A84F1ECD62DFB096Amitedu_--


From nobody Thu May 16 01:33: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 9FEF812010F for ; Thu, 16 May 2019 01:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=datev.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjzU9orJFWA1 for ; Thu, 16 May 2019 01:33:21 -0700 (PDT)
Received: from idvmailout04.datev.com (idvmailout04.datev.com [193.27.49.130]) (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 18740120059 for ; Thu, 16 May 2019 01:33:20 -0700 (PDT)
Received: from biem02.services.datev.de (idvmailproxy02v1.services.datev.de [10.252.82.156]) by idvmailout04.datev.com (Postfix) with ESMTP id 454Pnm0vY4zK8Yb; Thu, 16 May 2019 10:33:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datev.de; s=Vxdd; t=1557995595; x=1562995595; bh=eJYDB6IwEHuikmv0YHpr+fi7V9/aC7Yv/rxGS8oC8yE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=r+YwhcwRHt9Do8xbhBJ7EuA8b0rGVDGh3AxBDEpjmUgWkxpJB+7EJmFEvvTQDL/CV IUp8s+Ma1OxvamlIrkV2OLsj/9jsxJudxB1iUCmDFkxYG/CmtRAx91TCxaDLtablxL xe29yk9G3H6xTAQvX912ha5oqLk+s2KRjm0NqotvMZgH0y74zll484vpE7mNFbrb6Q 4UXb9vScPp1ihYkdSFP234HMVoLrZ3eaMNuuKP0A+n51t35ucu2VpgE3/IK1WLWY+9 PLpnOldVWSGBr1OXhRjGYNGPoKRBp7QaF+GNBYkNt3vXgLvegcUIQNjQLI4VOCpn4M zmNg60+ZoDXew==
X-Virus-Scanned: amavisd-new-2.11.0 on idvmailproxy02.services.datev.de
Received: from WEXCSB002.bk.datev.de (2.40.130.10.in-addr.arpa [10.130.40.2]) by biem02.services.datev.de (Postfix) with ESMTP id 454Pnk4T2zz28Gh;  Thu, 16 May 2019 10:33:14 +0200 (CEST)
Received: from WEXCSB010.bk.datev.de (10.130.40.10) by WEXCSB002.bk.datev.de (10.130.40.2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 16 May 2019 10:33:14 +0200
Received: from WEXCSB010.bk.datev.de ([10.130.40.10]) by WEXCSB010.bk.datev.de ([10.130.40.10]) with mapi id 15.01.1713.006; Thu, 16 May 2019 10:33:14 +0200
From: "Sahler, Frank" 
To: 'Justin Richer' 
CC: "'oauth@ietf.org'" 
Thread-Topic: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol 
Thread-Index: AdULR5pWZEE5HKV3Q2aM1px2/PKpxwAdapzg
Date: Thu, 16 May 2019 08:33:14 +0000
Message-ID: <480b151b02714a7fb7cedc871df429de@datev.de>
References: <9FDB4A17E451433AB2EDF31BEF4F2EF9@bk.datev.de>
In-Reply-To: <9FDB4A17E451433AB2EDF31BEF4F2EF9@bk.datev.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
versandeinstellungen: Signieren=True; Verschluesseln=False; Konvertieren=True;  EnglischerDisclaimer=False
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha256; boundary="=-_DvNextPart_0005_519B127B.36B9AAF6"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
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, 16 May 2019 08:33:25 -0000

This is a multi-part message in MIME format.

--=-_DvNextPart_0005_519B127B.36B9AAF6
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSnVzdGluLA0KYmFja2dyb3VuZCBvZiBteSBxdWVyeSBpcyB0aGF0IHdlIHdhbnQgdG8gb2Zm
ZXIgaW4gb3VyIGNvbXBhbnkgdGhlIHBvc3NpYmlsaXR5IG9mIGR5bmFtaWMgY2xpZW50IHJlZ2lz
dHJhdGlvbi4NClVuZm9ydHVuYXRlbHksIHRoZSB0b3BpYyBpbml0aWFsIGFjY2VzcyB0b2tlbiAt
IGhvdyBkbyBJIGdldCBpdCBhbmQgaG93IGV4YWN0bHkgaXQgaXMgY29uc3RydWN0ZWQgLSBpcyBu
b3QgZXhhY3RseSBzcGVjaWZpZWQgLSBpdCBpcyBvdXQgb2Ygc2NvcGUuDQpUaGF0IGlzIHRoZSBy
ZWFzb24gd2h5IEkgc2VhcmNoZWQgaW4gaW50ZXJuZXQgYW5kIGZvdW5kIHRoZSBzY29wZSAiZGNy
IiBpbiBjdXJpdHkgZG9jdW1lbnRhdGlvbi4NCg0KQ2VudHJhbCBxdWVzdGlvbiBpbiB0aGUgbW9t
ZW50OiBob3cgZG9lcyB0aGUgdXNlciB3aG8gd2FudCB0byByZWdpc3RlciBhIGNsaWVudCBnZXQg
dGhlIGluaXRpYWwgYWNjZXNzIHRva2VuPw0KTXkgaWRlYToNCldlIGFyZSB1c2luZyBhIHByb3Rl
Y3RlZCBjbGllbnQgcmVnaXN0cmF0aW9uIHNvIHRoZSB1c2VyIGZpcnN0IGhhcyB0byBhdXRoZW50
aWNhdGUgaGltc2VsZi4NCkluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QsIHRoZSBzY29wZSAi
ZGNyIiAob3IgYW55IG90aGVyPykgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyIGFuZCBhcyBhIHJlc3VsdCB0aGVyZSBpcyB0aGUgaW5pdGlhbCBhY2Nlc3MgdG9rZW4g
Zm9yIHRoaXMgdXNlciBhbmQgdGhpcyBjbGllbnQuIFNvLCBpbiBteSBvcGluaW9uLCBpdCBpcyBn
dWFyYW50ZWVkIHRoYXQgb25lIGdldHMgdGhlIGluaXRpYWwgYWNjZXNzIHRva2VuLCB3aGljaCBo
YXMgYWxzbyByZXF1ZXN0ZWQgaXQuDQoNCldpdGggdGhlIGlkZWEgdG8gdXNlIHRoZSBzb2Z0d2Fy
ZSBzdGF0ZW1lbnQsIEkgaGF2ZSB0byB3b3JrIG1vcmUgaW50ZW5zaXZlbHkuIEkgaGFkIG5vdCBz
ZWVuIHRoYXQgd2F5IGJlZm9yZS4gUGVyaGFwcyB0aGUgaW5pdGlhbCBhY2Nlc3MgdG9rZW4gY2Fu
IGV2ZW4gYmUgcmVwbGFjZWQgYnkgdGhpcy4gQnV0IGFsc28gdGhlcmUgaXMgdGhlIHF1ZXN0aW9u
LCBob3cgaXMgaXQgcmVxdWVzdGVkPw0KDQpHcmVldGluZ3MNCkZyYW5rDQoNCg0KLS0tLS1VcnNw
csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p
dC5lZHU+DQpHZXNlbmRldDogTWl0dHdvY2gsIDE1LiBNYWkgMjAxOSAxOTo1Nw0KQW46IFNhaGxl
ciwgRnJhbmsgPGZyYW5rLnNhaGxlckBkYXRldi5kZT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KQmV0
cmVmZjogUmU6IFtPQVVUSC1XR10gUXVlcnkgb24gUkZDIDc1OTEgLSBkeW5hbWljIGNsaWVudCBy
ZWdpc3RyYXRpb24gcHJvdG9jb2wNCg0KT24gdGhlIHN1cmZhY2UgdGhpcyBpcyBmaW5lLCBidXQg
aXQgaGlkZXMgYW4gaW1wb3J0YW50IGRldGFpbDogeW91IG5lZWQgdG8gaGF2ZSBhIGNsaWVudCBy
ZWdpc3RlcmVkIHdpdGggdGhlIHN5c3RlbSBpbiBvcmRlciB0byBtYWtlIGEgdG9rZW4gcmVxdWVz
dCwgbWVhbmluZyB0aGF0IHRoZSDigJxkY3LigJ0gdG9rZW4gd2FzIGlzc3VlZCB0byBhIGRpZmZl
cmVudCBjbGllbnQgdGhhbiB0aGUgb25lIG1ha2luZyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3Qu
IFNvIHRoYXQganVzdCBtZWFucyB0aGF0IHRoZSBkZXZlbG9wZXIgaXMgZ29pbmcgdG8gaGF2ZSB0
byBjb3B5IGl0IGJ5IGhhbmQgaW50byBhIGNvbmZpZ3VyYXRpb24sIG9yIG90aGVyd2lzZSBwYXNz
IGl0IHRvIHRoZSBpbnN0YW5jZXMgYXQgcnVudGltZS4NCg0KSXMgaXQgYWxsb3dhYmxlPyBTdXJl
LCBhcyB0aGUgUkZDIGRvZXNu4oCZdCBzdGF0ZSAob3IgY2FyZSkgaG93IHlvdSBnb3QgdGhlIGlu
aXRpYWwgYWNjZXNzIHRva2VuIGZvciB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QuIElzIGl0IHN0
YW5kYXJkPyBXZWxsLCB0aGUg4oCcZGNy4oCdIHNjb3BlIGlzIHNwZWNpZmljIHRvIHRoaXMgY29t
cGFueeKAmXMgaW1wbGVtZW50YXRpb24sIGFuZCBpdOKAmXMgYSBsaXR0bGUgb2RkIHVzaW5nIGFu
IGF1dG9tYXRlZCBwcm9jZXNzIHRvIGdldCBhIHRva2VuIGZvciB3aGF0IHdpbGwgYmUgYW4gYXV0
b21hdGVkIHByb2Nlc3MuIFRoYXQgYmFzaWNhbGx5IGxlYXZlcyBvbmUgaW5zdGFuY2Ugb2YgdGhl
IGFwcGxpY2F0aW9uIGFzIHRoZSDigJxwcmltYXJ54oCdIGluc3RhbmNlIGFuZCBldmVyeXRoaW5n
IGVsc2UgYnVpbGRzIG9mZiBvZiB0aGF0Lg0KDQpJdOKAmXMgbW9yZSBjb21tb24gdG8gdXNlIGEg
c29mdHdhcmUgc3RhdGVtZW50LCB3aGljaCBhbHNvIGxvY2tzIGRvd24gYSBzZXQgb2YgY2xpZW50
IGF0dHJpYnV0ZXMgaW4gYSBzaWduZWQgc3RhdGVtZW50LiBJbiBmYWN0LCBpbiB0aGUgb3JpZ2lu
YWwgdmVyc2lvbiBvZiB0aGlzIHBhcnQgb2YgdGhlIHNwZWNpZmljYXRpb24sIHdoaWNoIGNhbWUg
ZnJvbSB0aGUgQmx1ZUJ1dHRvbitSRVNUIHByb2plY3QsIHRoZSDigJxzb2Z0d2FyZSBzdGF0ZW1l
bnTigJ0gYW5kIOKAnGluaXRpYWwgYWNjZXNzIHRva2Vu4oCdIHdlcmUgb25lIGFuZCB0aGUgc2Ft
ZS4gVGhpcyB3b3JraW5nIGdyb3VwIGRlY2lkZWQgdGhhdCB0aGUgZnVuY3Rpb25hbGl0eSB3YXMg
YmV0dGVyIHNlcGFyYXRlZC4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBNYXkgMTQsIDIwMTksIGF0IDE6
MzAgUE0sIFNhaGxlciwgRnJhbmsgPGZyYW5rLnNhaGxlckBkYXRldi5kZTxtYWlsdG86ZnJhbmsu
c2FobGVyQGRhdGV2LmRlPj4gd3JvdGU6DQoNCkhlbGxvLA0KSSByZWFkIGluIHRoZSBkeW5hbWlj
IGNsaWVudCByZWdpc3RyYXRpb24gZG9jdW1lbnRhdGlvbiBvZiB0aGUgY29tcGFueSBjdXJpdHkg
KGh0dHBzOi8vZGV2ZWxvcGVyLmN1cml0eS5pby90dXRvcmlhbHMvZHluYW1pYy1jbGllbnQtcmVn
aXN0cmF0aW9uLW92ZXJ2aWV3KSB0aGF0IHRoZXkgdXNlIHRoZSBzY29wZSAiZGNyIiBpbiB0aGUg
YXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvIGdldCBhbiBpbml0aWFsIGFjY2VzcyB0b2tlbiBpLmUu
IGEgYmVhcmVyIHRva2VuIHRoYXQgb25seSBhbGxvd3MgYWNjZXNzIHRvIHRoZSByZWdpc3RyYXRp
b24gZW5kcG9pbnQuDQoNCklzIHRoaXMgYWxzbyBmcm9tIHlvdXIgcG9pbnQgb2YgdmlldyBhIGZl
YXNpYmxlIHdheSB0byBpbml0aWF0ZSB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbj8NCg0KVW5mb3J0
dW5hdGVseSB0aGUgc3BlY2lmaWNhdGlvbiBzYXlzIG5vdGhpbmcgYWJvdXQgaG93IHRvIGdldCB0
aGUgdG9rZW4gYW5kIGhvdyBpdHMgcHVycG9zZSBpcyBsaW1pdGVkIHRvIHRoZSByZWdpc3RyYXRp
b24gZW5kcG9pbnQuIFRoZXNlIHR3byBwb2ludHMgYXJlICJvdXQgb2Ygc2NvcGUgZm9yIHRoaXMg
c3BlY2lmaWNhdGlvbiIuDQoNClJlZ2FyZHMNCkZyYW5rIFNhaGxlcg0KU2VjdXJpdHkgQ29uc3Vs
dGFudA0KREFURVYgZUcsIE51cmVtYmVyZywgR2VybWFueQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClNpZ25hdHVyDQpEaWVzZSBFLU1haWwgd3VyZGUgbWl0IGVpbmVtIFplcnRp
ZmlrYXQgZGVyIERBVEVWIGVHIHNpZ25pZXJ0LiBEYW1pdCBrw7ZubmVuIFNpZSBzaWNoZXIgc2Vp
biwgZGFzcyBkaWUgTmFjaHJpY2h0IHNvIHZvbiB1bnMgZ2VzZW5kZXQgd3VyZGUuIFdlbm4gU2ll
IGVpbmUgTWVsZHVuZyBlcmhhbHRlbiwgZGFzcyBkaWUgU2lnbmF0dXIgdW5nw7xsdGlnIGlzdCBv
ZGVyIG5pY2h0IGdlcHLDvGZ0IHdlcmRlbiBrYW5uLCBmZWhsdCBkYXMgWmVydGlmaWthdCB6dSBk
aWVzZXIgU2lnbmF0dXIgYXVmIElocmVtIFJlY2huZXIuIEluZm9ybWF0aW9uZW4genUgWmVydGlm
aWthdGVuIHVuZCB6dXIgZGlnaXRhbGVuIFNpZ25hdHVyIGZpbmRlbiBTaWUgdW50ZXIgaHR0cHM6
Ly93d3cuZGF0ZXYuZGUvemVydGlmaWthdGUgaW0gSW50ZXJuZXQuDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KREFURVYgZUcNCjkwMzI5IE7DvHJuYmVyZw0KVGVsZWZvbiArNDkg
OTExIDMxOS0wDQoNCkUtTWFpbDogaW5mb0BkYXRldi5kZTxtYWlsdG86aW5mb0BkYXRldi5kZT4N
CkludGVybmV0OiBodHRwczovL3d3dy5kYXRldi5kZTxodHRwczovL3d3dy5kYXRldi5kZS8+DQpT
aXR6OiA5MDQyOSBOw7xybmJlcmcsIFBhdW1nYXJ0bmVyc3RyYcOfZSA2LTE0DQpSZWdpc3Rlcmdl
cmljaHQgTsO8cm5iZXJnLCBHZW5SZWcgTnIuIDcwDQoNClZvcnN0YW5kDQpEci4gUm9iZXJ0IE1h
eXIgKFZvcnNpdHplbmRlcikNCkVja2hhcmQgU2Nod2FyemVyIChzdGVsbHYuIFZvcnNpdHplbmRl
cikNCkp1bGlhIEJhbmdlcnRoDQpQcm9mLiBEci4gUGV0ZXIgS3J1Zw0KRGlhbmEgV2luZG1lacOf
ZXINCg0KVm9yc2l0emVuZGVyIGRlcyBBdWZzaWNodHNyYXRlczogTmljb2xhcyBIb2ZtYW5uDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt
YWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCiBTaWduYXR1cg0KRGllc2UgRS1NYWlsIHd1cmRlIG1pdCBlaW5l
bSBaZXJ0aWZpa2F0IGRlciBEQVRFViBlRyBzaWduaWVydC4gRGFtaXQga8O2bm5lbiBTaWUgc2lj
aGVyIHNlaW4sIGRhc3MgZGllIE5hY2hyaWNodCBzbyB2b24gdW5zIGdlc2VuZGV0IHd1cmRlLiBX
ZW5uIFNpZSBlaW5lIE1lbGR1bmcgZXJoYWx0ZW4sIGRhc3MgZGllIFNpZ25hdHVyIHVuZ8O8bHRp
ZyBpc3Qgb2RlciBuaWNodCBnZXByw7xmdCB3ZXJkZW4ga2FubiwgZmVobHQgZGFzIFplcnRpZmlr
YXQgenUgZGllc2VyIFNpZ25hdHVyIGF1ZiBJaHJlbSBSZWNobmVyLiBJbmZvcm1hdGlvbmVuIHp1
IFplcnRpZmlrYXRlbiB1bmQgenVyIGRpZ2l0YWxlbiBTaWduYXR1ciBmaW5kZW4gU2llIHVudGVy
IGh0dHBzOi8vd3d3LmRhdGV2LmRlL3plcnRpZmlrYXRlIGltIEludGVybmV0Lg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KREFURVYgZUcNCjkwMzI5IE7DvHJuYmVyZw0KVGVs
ZWZvbiArNDkgOTExIDMxOS0wDQoNCkUtTWFpbDogaW5mb0BkYXRldi5kZQ0KSW50ZXJuZXQ6IGh0
dHBzOi8vd3d3LmRhdGV2LmRlDQpTaXR6OiA5MDQyOSBOw7xybmJlcmcsIFBhdW1nYXJ0bmVyc3Ry
YcOfZSA2LTE0DQpSZWdpc3RlcmdlcmljaHQgTsO8cm5iZXJnLCBHZW5SZWcgTnIuIDcwDQoNClZv
cnN0YW5kDQpEci4gUm9iZXJ0IE1heXIgKFZvcnNpdHplbmRlcikNCkVja2hhcmQgU2Nod2FyemVy
IChzdGVsbHYuIFZvcnNpdHplbmRlcikNCkp1bGlhIEJhbmdlcnRoDQpQcm9mLiBEci4gUGV0ZXIg
S3J1Zw0KRGlhbmEgV2luZG1lacOfZXINCg0KVm9yc2l0emVuZGVyIGRlcyBBdWZzaWNodHNyYXRl
czogTmljb2xhcyBIb2ZtYW5uDQoNCg==

--=-_DvNextPart_0005_519B127B.36B9AAF6
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIE
4jCCA8qgAwIBAgIIf/FWQItVv5QwDQYJKoZIhvcNAQELBQAwOTELMAkGA1UEBhMCREUxETAPBgNV
BAoMCERBVEVWIGVHMRcwFQYDVQQDDA5DQSBEQVRFViBFTSAwMjAeFw0xNTExMDkxMjQ0MTNaFw0y
MDExMDkyMDU5NTlaMGkxFTATBgNVBAMMDEZyYW5rIFNhaGxlcjEdMBsGA1UEBRMUMDAwMDAwMDAw
MTU3OTQzMDUwMDExCzAJBgNVBAYTAkRFMSQwIgYJKoZIhvcNAQkBFhVmcmFuay5zYWhsZXJAZGF0
ZXYuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCT7xcR7XrtJJmFfeLDN08OFpec
4fZS/zlIBSeYQmN72U955L+Sf7Eq9y53X1Q3rf9kdpguMjOuXxisxGdd7zd1mgPc+1u7bxcjQT2i
GT8ALJLLBXuJWchs/PH73dbs+tsETsNqqUEl/wIKWakaj7vnc1qVD90zLL88lNaWHLSuYjtDKN/Q
K9jMIE/LFbLdSsOoSLbBTJ8uC1im+TfA98z44DN9Q5GzndHZVOhqSm/y+kMoSw08tBrWLZImjyrw
6NQlKmCQN0F+pw9oz3YMpcim9YNklUHWnaNuBFEZjgSFCHn4m2RwmIof9aTbttcF91z+YwRlO6Um
IeJbmBNqt+xdAgMBAAGjggG8MIIBuDBwBgNVHSMEaTBngBR1v3Ew7smsGxvy3Q5dM4/+zW/z26E9
pDswOTELMAkGA1UEBhMCREUxETAPBgNVBAoMCERBVEVWIGVHMRcwFQYDVQQDDA5DQSBEQVRFViBF
TSAwMoIQbhKe1F05f3FL5xNbleacFTAdBgNVHQ4EFgQUom5xsjii60QAQMNu6g2b5mFkENcwDgYD
VR0PAQH/BAQDAgSwMCAGA1UdEQQZMBeBFWZyYW5rLnNhaGxlckBkYXRldi5kZTCBtQYDVR0fBIGt
MIGqMDygOqA4hjZodHRwOi8vd3d3LmNybC5lc2VjdXJlLmRhdGV2LmRlL2NhLWRhdGV2LWVtLTAy
L2NybC5jcmwwaqBooGaGZGxkYXA6Ly9sZGFwLmNybC5lc2VjdXJlLmRhdGV2LmRlL0NOPUNBJTIw
REFURVYlMjBFTSUyMDAyLE89REFURVYlMjBlRyxDPURFP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp
c3QwOwYIKwYBBQUHAQEELzAtMCsGCCsGAQUFBzABhh9odHRwOi8vd3d3LmRpci5lc2VjdXJlLmRh
dGV2LmRlMA0GCSqGSIb3DQEBCwUAA4IBAQCmokWR/VBT2mt49YiYbGRiO9BfcDYzW2Hm+zYNe0Bz
G4jjX869OPHIOh8AWJLnr9s0EpTo6oyFu/qL+lxXn67Vg8FgCbleSOqdW3zuJcJ5D+ogPfG2T1SY
VlZ7jsKP4kg0zxfd1NK6AzTc+XcBHfUD9fqn8wPHVjbjElsPvF+RDB9/BWeJkg8fKX4Rotg0W9UY
UYjhnqdceaxvCRCB+dHFpMFI0lDXjYrmGlAfAl0CJIsNhO/6IYhSeoqHx3dyTzPY3+C8qc+b2xnK
lgqe4AeHeFs4nRYbCmEY765mZT/bTnu+kUlPOCaB3I9Iny+y7DOjUCFYvpAnvM+mgSUVcuZ7AAAx
ggHbMIIB1wIBATBFMDkxCzAJBgNVBAYTAkRFMREwDwYDVQQKDAhEQVRFViBlRzEXMBUGA1UEAwwO
Q0EgREFURVYgRU0gMDICCH/xVkCLVb+UMA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE2MDgzMzE1WjAvBgkqhkiG9w0BCQQxIgQg
uOdHI4PduN11zmWQuH6+wQY9KRdanTjZcVMYHWS9RkQwDQYJKoZIhvcNAQEBBQAEggEAAgjy3YXz
Npt3eyPZhKx+jq8cthFCEu6vugLScebP8H0qd6ocxdpyO97Qw+oM8T2oHn51bk54MZWpBqK9QRRg
dSXJhuiwqUrr6ktzFz6AA3RWfN3g3d4yzsszDFifCHAGM6qntYm/9S7745lQahIL5rtwolLRs+kZ
U83bDU3QTN0fkZx+oGGdIJnH/ETG5xj6RBNNGRlxdddtu2Fsc8R2cv29AZi1oUlpHTR732l3U/Ov
uUvbSnfK25vmgrWdZwLoH9RdCxqhSAfD8eo8IKrNm8gSq6gnLSkq2/+qgywcb2nIjwr0nW0Wehyc
8JGr21lmgvpxqbhb0vczt2rBWZD2ZgAAAAAAAA==

--=-_DvNextPart_0005_519B127B.36B9AAF6--


From nobody Thu May 16 03:53:12 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 8BCD0120074; Thu, 16 May 2019 03:53:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <155800399049.19827.6901373712560962485@ietfa.amsl.com>
Date: Thu, 16 May 2019 03:53:10 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-18.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, 16 May 2019 10:53:11 -0000

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

        Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-18.txt
	Pages           : 27
	Date            : 2019-05-16

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-18
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-18

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


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 May 16 09:42: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 A4A631200B3 for ; Thu, 16 May 2019 09:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5onmxrVh_uHO for ; Thu, 16 May 2019 09:42:11 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 C7C9412011D for ; Thu, 16 May 2019 09:42:11 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4GGSPjU055649; Thu, 16 May 2019 16:42:03 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=2RlIvW9N1mgVoa9G1B6J0chivtMEoZtXTnGgYO4sSCI=; b=SM3UwFbNWdx/gkADiNMkBOujsXrScKgSZTV2CvUrIuyOWrZE9mLrs/kMYtDxy//KUnIo svg+B2hDKN9JLt3lRPmtY20pUkWCUTY2mNcFgRqK8ff8EYTlb9LcxDVhSqAd/uHtzSKj RE4wgRu4LygelFJj70iipzEWzuibDN+l2Q4WMN+hLvvrEgLfnzu+ZH7XZAWyIjFC+XI1 U1dMv8y261Sf2gqTuWOywrsllSL/0bJNqzZbLUbEypQikGQndvC1/jOlLlpl31QBOnD3 Orx764pON5fxzboaDxbkWgEZD/4OhW96Vp3Fm/yDrd6sx5ARg18WPoPPnDt7XaLT24Ig qw== 
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 2sdkwe4xd1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 May 2019 16:42:03 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4GGcGRw126404; Thu, 16 May 2019 16:40:02 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2sgkx46p7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 May 2019 16:40:02 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4GGe0wa009071; Thu, 16 May 2019 16:40:00 GMT
Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 May 2019 09:40:00 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <480b151b02714a7fb7cedc871df429de@datev.de>
Date: Thu, 16 May 2019 09:39:59 -0700
Cc: Justin Richer , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9FDB4A17E451433AB2EDF31BEF4F2EF9@bk.datev.de> <480b151b02714a7fb7cedc871df429de@datev.de>
To: "Sahler, Frank" 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9259 signatures=668687
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-1810050000 definitions=main-1905160105
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9259 signatures=668687
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160105
Archived-At: 
Subject: Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration protocol
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, 16 May 2019 16:42:15 -0000

We looked at giving clients a public client id they could use to perform an a=
uthorize with scope =E2=80=9Cdcr=E2=80=9D to get an AT to be used as an IAT.=
=20

While it works it seems like overkill. The main risk with the DCR endpoint i=
s generating too many IDs ... a DoS issue primarily since having an ID is no=
t authorization.=20

Because of the perceived developer complexity and confusion over dealing wit=
h a public and confidential client id, my feeling was that software statemen=
ts are sufficient. They provide a signed assertion the developer can pass in=
 so the DCR can establish what the client claims to be registering as. This i=
s enough to establish some access policy at the DCR endpoint.=20

Phil

> On May 16, 2019, at 1:33 AM, Sahler, Frank  wrote:
>=20
> Hi Justin,
> background of my query is that we want to offer in our company the possibi=
lity of dynamic client registration.
> Unfortunately, the topic initial access token - how do I get it and how ex=
actly it is constructed - is not exactly specified - it is out of scope.
> That is the reason why I searched in internet and found the scope "dcr" in=
 curity documentation.
>=20
> Central question in the moment: how does the user who want to register a c=
lient get the initial access token?
> My idea:
> We are using a protected client registration so the user first has to auth=
enticate himself.
> In the authorization request, the scope "dcr" (or any other?) is transferr=
ed to the authorization server and as a result there is the initial access t=
oken for this user and this client. So, in my opinion, it is guaranteed that=
 one gets the initial access token, which has also requested it.
>=20
> With the idea to use the software statement, I have to work more intensive=
ly. I had not seen that way before. Perhaps the initial access token can eve=
n be replaced by this. But also there is the question, how is it requested?
>=20
> Greetings
> Frank
>=20
>=20
> -----Urspr=C3=BCngliche Nachricht-----
> Von: Justin Richer 
> Gesendet: Mittwoch, 15. Mai 2019 19:57
> An: Sahler, Frank 
> Cc: oauth@ietf.org
> Betreff: Re: [OAUTH-WG] Query on RFC 7591 - dynamic client registration pr=
otocol
>=20
> On the surface this is fine, but it hides an important detail: you need to=
 have a client registered with the system in order to make a token request, m=
eaning that the =E2=80=9Cdcr=E2=80=9D token was issued to a different client=
 than the one making the registration request. So that just means that the d=
eveloper is going to have to copy it by hand into a configuration, or otherw=
ise pass it to the instances at runtime.
>=20
> Is it allowable? Sure, as the RFC doesn=E2=80=99t state (or care) how you g=
ot the initial access token for the registration request. Is it standard? We=
ll, the =E2=80=9Cdcr=E2=80=9D scope is specific to this company=E2=80=99s im=
plementation, and it=E2=80=99s a little odd using an automated process to ge=
t a token for what will be an automated process. That basically leaves one i=
nstance of the application as the =E2=80=9Cprimary=E2=80=9D instance and eve=
rything else builds off of that.
>=20
> It=E2=80=99s more common to use a software statement, which also locks dow=
n a set of client attributes in a signed statement. In fact, in the original=
 version of this part of the specification, which came from the BlueButton+R=
EST project, the =E2=80=9Csoftware statement=E2=80=9D and =E2=80=9Cinitial a=
ccess token=E2=80=9D were one and the same. This working group decided that t=
he functionality was better separated.
>=20
> =E2=80=94 Justin
>=20
> On May 14, 2019, at 1:30 PM, Sahler, Frank > wrote:
>=20
> Hello,
> I read in the dynamic client registration documentation of the company cur=
ity (https://developer.curity.io/tutorials/dynamic-client-registration-overv=
iew) that they use the scope "dcr" in the authorization request to get an in=
itial access token i.e. a bearer token that only allows access to the regist=
ration endpoint.
>=20
> Is this also from your point of view a feasible way to initiate the client=
 registration?
>=20
> Unfortunately the specification says nothing about how to get the token an=
d how its purpose is limited to the registration endpoint. These two points a=
re "out of scope for this specification".
>=20
> Regards
> Frank Sahler
> Security Consultant
> DATEV eG, Nuremberg, Germany
> ________________________________
> Signatur
> Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit k=C3=B6=
nnen Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie=
 eine Meldung erhalten, dass die Signatur ung=C3=BCltig ist oder nicht gepr=C3=
=BCft werden kann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner=
. Informationen zu Zertifikaten und zur digitalen Signatur finden Sie unter h=
ttps://www.datev.de/zertifikate im Internet.
> ________________________________
> DATEV eG
> 90329 N=C3=BCrnberg
> Telefon +49 911 319-0
>=20
> E-Mail: info@datev.de
> Internet: https://www.datev.de
> Sitz: 90429 N=C3=BCrnberg, Paumgartnerstra=C3=9Fe 6-14
> Registergericht N=C3=BCrnberg, GenReg Nr. 70
>=20
> Vorstand
> Dr. Robert Mayr (Vorsitzender)
> Eckhard Schwarzer (stellv. Vorsitzender)
> Julia Bangerth
> Prof. Dr. Peter Krug
> Diana Windmei=C3=9Fer
>=20
> Vorsitzender des Aufsichtsrates: Nicolas Hofmann
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
> ________________________________
> Signatur
> Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit k=C3=B6=
nnen Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie=
 eine Meldung erhalten, dass die Signatur ung=C3=BCltig ist oder nicht gepr=C3=
=BCft werden kann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner=
. Informationen zu Zertifikaten und zur digitalen Signatur finden Sie unter h=
ttps://www.datev.de/zertifikate im Internet.
> ________________________________
>=20
> DATEV eG
> 90329 N=C3=BCrnberg
> Telefon +49 911 319-0
>=20
> E-Mail: info@datev.de
> Internet: https://www.datev.de
> Sitz: 90429 N=C3=BCrnberg, Paumgartnerstra=C3=9Fe 6-14
> Registergericht N=C3=BCrnberg, GenReg Nr. 70
>=20
> Vorstand
> Dr. Robert Mayr (Vorsitzender)
> Eckhard Schwarzer (stellv. Vorsitzender)
> Julia Bangerth
> Prof. Dr. Peter Krug
> Diana Windmei=C3=9Fer
>=20
> Vorsitzender des Aufsichtsrates: Nicolas Hofmann
>=20


From nobody Thu May 16 10:11:48 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 EF512120043 for ; Thu, 16 May 2019 10:11:45 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISfT8IcmmDIN for ; Thu, 16 May 2019 10:11:38 -0700 (PDT)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (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 9E11612014F for ; Thu, 16 May 2019 10:10:24 -0700 (PDT)
Received: from [80.187.102.145] (helo=[10.155.44.35]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hRJta-0001i7-Rj; Thu, 16 May 2019 19:10:19 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-E65621CA-AEDA-424E-8730-16CD4134EA56; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16F156)
In-Reply-To: <10e7ee87-4877-4790-dbdc-8f599d401cbe@aol.com>
Date: Thu, 16 May 2019 19:10:16 +0200
Cc: Dave Tonge , Sascha Preibisch , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <8134EC64-CD0F-4AAE-B406-8F425B41F72D@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net> <968aa387-16fe-4ed0-5ec2-d0f3426a0afa@aol.com>  <10e7ee87-4877-4790-dbdc-8f599d401cbe@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
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, 16 May 2019 17:11:46 -0000

--Apple-Mail-E65621CA-AEDA-424E-8730-16CD4134EA56
Content-Type: multipart/alternative;
	boundary=Apple-Mail-87A49FA8-3EC3-42C9-9863-0E23F57FACCA
Content-Transfer-Encoding: 7bit


--Apple-Mail-87A49FA8-3EC3-42C9-9863-0E23F57FACCA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 10.05.2019 um 22:27 schrieb George Fletcher :
>=20
> One thing to keep in mind with the "Push Request Object" model and the con=
cept of a more detailed scope structure, if the specified values are not for=
 a single transaction, then the AS will be required to keep the "Pushed Requ=
est Object" for the "lifetime" of the access_token and possibly the refresh_=
token depending on the use case. This could have some implementation issues f=
or the AS.

It=E2=80=99s not necessarily the request object but the client id and the sc=
ope. Can you please explain what implementation issue you expect? I don=E2=80=
=99t see much of a difference between storing/maintaining simple scope value=
s and a JSON document for a grant.


>=20
> Thanks,
> George
>=20
>> On 5/10/19 9:52 AM, Dave Tonge wrote:
>> Thanks Torsten for this article - it is incredibly helpful.
>>=20
>> I'm very much in favour of the "structured_scope" approach.=20
>>=20
>> While I understand George's point I think the line is very blurred betwee=
n coarse-grained scopes and fine-grained transaction consent. In addition fi=
ne-grained authorisation metadata is needed for ongoing access APIs as well,=
 e.g. how can a client ask for ongoing access to:
>>  - transactions in a users accounts with ids abc123 and abc124
>>=20
>> =46rom a UX perspective it is beneficial for the AS to ask the user for c=
onsent once. The AS therefore needs to have all the information about relati=
ng to the consent available when the user is redirected to the authorization=
 endpoint. There should be a standard way for the Client to pass this data t=
o the AS and I think structured scopes either sent as a query param or in a =
            request object are a neat way of doing this.=20
>>=20
>> Dave
>>=20
>=20

--Apple-Mail-87A49FA8-3EC3-42C9-9863-0E23F57FACCA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 10.05.2019 um 22:27 schrieb George Fletcher &=
lt;gffletch@aol.com>:


 =20
    
 =20
 =20
    One thing to keep in mind with the "Push Request Object" model and
    the concept of a more detailed scope structure, if the specified
    values are not for a single transaction, then the AS will be
    required to keep the "Pushed Request Object" for the "lifetime" of
    the access_token and possibly the refresh_token depending on the use
    case. This could have some implementation issues for the AS.

It=E2=80=99s not necessarily the request obje=
ct but the client id and the scope. Can you please explain what implementati=
on issue you expect? I don=E2=80=99t see much of a difference between storin=
g/maintaining simple scope values and a JSON document for a grant.



    

    Thanks,

    George

    

    
On 5/10/19 9:52 AM, Dave Tonge wrote:
=

    

    

      
      

        

          
Thanks Torsten for this article - it is
            incredibly helpful.

          


          

          
I'm very much in favour of the
            "structured_scope" approach. 

          


          

          
While I understand George's point I think the
            line is very blurred between coarse-grained scopes and
            fine-grained transaction consent. In addition fine-grained
            authorisation metadata is needed for ongoing access APIs as
            well, e.g. how can a client ask for ongoing access to:

          
 - transactions in a users accounts with ids=

            abc123 and abc124

          


          

          
=46rom a UX perspective it is beneficial for
            the AS to ask the user for consent once. The AS therefore
            needs to have all the information about relating to the
            consent available when the user is redirected to the
            authorization endpoint. There should be a standard way for
            the Client to pass this data to the AS and I think
            structured scopes either sent as a query param or in a
            request object are a neat way of doing this. 

          


          

          
Dave

        

        

          


          

        

      

    

    

 =20


=

--Apple-Mail-87A49FA8-3EC3-42C9-9863-0E23F57FACCA--

--Apple-Mail-E65621CA-AEDA-424E-8730-16CD4134EA56
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
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
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE2MTcxMDE2WjAvBgkqhkiG9w0BCQQxIgQg
U2xUsfJszuwzo3j+w18vwFA8KweZIZ5F+aTcPBVuqqgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAKN6AeoHkv/4E+7X
OtRsb/dPdr6Rgu32kjCCpXZeIAhnREDFiv4TpZs5Znyo5lQXUF+lxgFgIz4eqJ39ApPc1XGxlXrY
FTIB3P7vSMxn59pejyoobObhlwew32tOQtIdc611xiFKjiMu6WuXYuTPVQIDVjqLvXN2/nDdz1zl
zhtebwDpsI4IQqjoR1cighYRRoMBZ/k13AR9Ag6ytzb8aFBHyhxibXFS44oBcXL0BdZqclAPF0Bz
apZS60MqmB9sRsmHcgWSI4QGmdYMyGXCFZSLqm8p3kX20JtJoMx2LH5zntdeTNwGF49sHZaFVoNY
SDLTyt9BMU95XgcgRodEzkYAAAAAAAA=

--Apple-Mail-E65621CA-AEDA-424E-8730-16CD4134EA56--


From nobody Fri May 17 07:22: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 77F82120161 for ; Fri, 17 May 2019 07:21: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0MXsVm5TQZs for ; Fri, 17 May 2019 07:21:56 -0700 (PDT)
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 B4DF512012A for ; Fri, 17 May 2019 07:21:55 -0700 (PDT)
Received: by mail-ed1-x542.google.com with SMTP id w37so10853506edw.4 for ; Fri, 17 May 2019 07:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJdZPEAPjoaE4gFVfFLwNPh9Xjbtfk3qHhKk4FWsoZw=; b=LeFXUA8zfKvqKLs9HjBf6KbOJOs+qZoEhumr23GP0pE6kUKM26Aey8w/CY1jFHWdl4 FMc+FX9WOYSiazu+jEjz/H+d/IlRQyRzJ4l4oM/h4i6QdFj9zA/0AQmPq4HkKxCDzhny /rdBDKiIeIBpE8aFQ3VQieRbfWQ/rRt8cKvsQ=
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=IJdZPEAPjoaE4gFVfFLwNPh9Xjbtfk3qHhKk4FWsoZw=; b=VAa8x1CUEkQexCe1y8+x0pnf7wIgrTXeodJPRkftW7rckIbSR/APxIsQILPnNwqnA2 BS9qXB3GIv5KMepjKFoffBE8qaj/tYBofr+ppfUAg3kZ2pihKN3b1R51IgTbIoaLP6WB HjdmNJY4VXq1T71pD08DyX0kP1kLXhI6hDsrO2bqep/V3lc+Mchrotb5CuNmjGkYZV6t tNeehh4mFcmZd13hlNrLqa3uJN5Exq3DS/Ez2MTrqTvgRZ4TAWyCdf60SR1hCORk+qd9 elAE9vb/DVpHtfN42kFPoGOJaUPDZUJdPfbj+hlSb3NGXFKHP8rbXOF8tyTuxY9m6pEw +/Eg==
X-Gm-Message-State: APjAAAV6yC3YWzV65ynUGkRPH+P67F0exJFwcn9m42f8PZ0U9hIeMCUf /bq15537L94qb6xR1St7+KMMyg==
X-Google-Smtp-Source: APXvYqzp4PXH+XqHL2IOsmMtj21Fk/KBvg+uaevsYacOW7w6g1W2GzAPPF8Vyg8ya41g8KijFJazyw==
X-Received: by 2002:a50:ad77:: with SMTP id z52mr58055473edc.174.1558102914166;  Fri, 17 May 2019 07:21:54 -0700 (PDT)
Received: from shiva.fritz.box ([134.101.243.215]) by smtp.gmail.com with ESMTPSA id m12sm1554023ejr.19.2019.05.17.07.21.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2019 07:21:53 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Steffo Weber 
In-Reply-To: 
Date: Fri, 17 May 2019 16:21:51 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ACAE0E9-2077-4764-9C80-6A562F8193D7@forgerock.com>
References: 
To: Rifaat Shekh-Yusef 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations
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, 17 May 2019 14:21:59 -0000

Hi Rifaat

We did one as part of the ForgeRock platform (on a per project basis). =
Artefact can be found at: =
https://github.com/ForgeRock/PSD2-Accelerators/tree/yes.com/openig/yes-ope=
nig-signed-introspect-filter
We might move that to a different service within the platform at a later =
stage.

HTH

Steffo

> On 2. May 2019, at 22:46, Rifaat Shekh-Yusef  =
wrote:
>=20
> All,
>=20
> As part of the shepherd write-up for the JWT Response for OAuth Token =
Introspection draft, we are looking for information about =
implementations for this document:
> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon=
se/
>=20
> Are you aware of any implementations?
>=20
> Regards,
>  Rifaat
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--
Dr Steffo Weber | Architect
ForgeRock

http://flip.it/caxRa

Phone: +49 151 5167 9521
Skype: steffo.weber








From nobody Fri May 17 10:39:47 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 23B8612015A for ; Fri, 17 May 2019 10:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJV_j758AXkO for ; Fri, 17 May 2019 10:39:44 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 5CED612013F for ; Fri, 17 May 2019 10:39:44 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id f22so6098488iol.11 for ; Fri, 17 May 2019 10:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fp4qDpLIh7UlpZ9KcCkP5RZM1jd9dqMAgaLVtNr9tdY=; b=ldHu7Pm+V04mw8OvlzBVHOjwEZB7KCBExTTHwJVBoerBok/9jKwiNjGOooIzoWgdgl eMRzqsbZIllme9CVNPD6PEWZbtTdTAUNhEhitt3BVFJL+XmchgIhlyKa8RHKGOmx8MH9 hJCu+lU0uO36jtapL/BiglBBUTErwWq5nyf9S7NE5rQFKwldq2hSQHqdw3/gO6OpjkVU kgdPIKrHgbjlgci1lfKqExhbnSj3W8u1jTCpmr8hoFCPenLYkxPFyi1pO2FAeVQMFZYB j6u83msjtVtzrxVAmc+W5o/t0LChaSgzUcZfY/huRdbEfqJeXL4ZsIk20c+9Sqmfw2kd cVLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fp4qDpLIh7UlpZ9KcCkP5RZM1jd9dqMAgaLVtNr9tdY=; b=VigjINh89ODgdy1mO0U/5rpZb9lqOJzNKScK0HdQ6xj3xsO7MiuGaHYl070m7/LVis ThLm64Sg0kwSpOMf4qveIQkzIgoKXzADHZnapyjpxRmKjUmgfuf4aVwoxKiTgEWxzdat 7lDg9sqo5nk9gfWCR8BZm2xT/7d0xuEVlD7j/W+IvDUwZdNz9ds2W3x+8E2FTrt2Oq/v D3J/nEZQsLcBIzfBoigLccweGx61dnYuh61AbWq+eN/glkI6xLT3dwAdBy3AVsFpuzb8 mOhulky/tWezFoBGtzTKlmpJ0SYvwWY3zaVtL/oJOeC78bIYmMUOWsQAXfWfbEFkrtp6 AnEA==
X-Gm-Message-State: APjAAAW/OOg/x2HB8qnwDxGqc7443aupyjPyZ15xW6/FrArPoUOdaGEA m2pnGio/mlRgaSCYKF3++Eb5IU637fyWZWvKmuc=
X-Google-Smtp-Source: APXvYqw3+ZITd4dJmpE5Bg5nVOyFvRj0R8mfETk4rO6PXMJ2oP1sX5ShcdpNtwiY8gkb812HNlMTjWJ77jQNr6uYd5g=
X-Received: by 2002:a6b:9306:: with SMTP id v6mr14040513iod.278.1558114783539;  Fri, 17 May 2019 10:39:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7794:0:0:0:0:0 with HTTP; Fri, 17 May 2019 10:39:42 -0700 (PDT)
In-Reply-To: <6ACAE0E9-2077-4764-9C80-6A562F8193D7@forgerock.com>
References:  <6ACAE0E9-2077-4764-9C80-6A562F8193D7@forgerock.com>
From: Rifaat Shekh-Yusef 
Date: Fri, 17 May 2019 13:39:42 -0400
Message-ID: 
To: Steffo Weber 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000313443058918de54"
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations
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, 17 May 2019 17:39:46 -0000

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

Thanks Steffo!

On Friday, May 17, 2019, Steffo Weber  wrote:

> Hi Rifaat
>
> We did one as part of the ForgeRock platform (on a per project basis).
> Artefact can be found at: https://github.com/ForgeRock/
> PSD2-Accelerators/tree/yes.com/openig/yes-openig-signed-introspect-filter
> We might move that to a different service within the platform at a later
> stage.
>
> HTH
>
> Steffo
>
> > On 2. May 2019, at 22:46, Rifaat Shekh-Yusef 
> wrote:
> >
> > All,
> >
> > As part of the shepherd write-up for the JWT Response for OAuth Token
> Introspection draft, we are looking for information about implementations
> for this document:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-
> introspection-response/
> >
> > Are you aware of any implementations?
> >
> > Regards,
> >  Rifaat
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Dr Steffo Weber | Architect
> ForgeRock
>
> http://flip.it/caxRa
>
> Phone: +49 151 5167 9521
> Skype: steffo.weber
>
>
>
>
>
>
>
>

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

Thanks Steffo!

On Friday, May 17, 2019, Steffo Weber <steffo.weber@forgerock.com> wrote=
:
Hi Rifaat



We did one as part of the ForgeRock platform (on a per project basis). Arte=
fact can be found at: https://github.com/ForgeRock/PSD2-Accelerators/tree/yes.com/=
openig/yes-openig-signed-introspect-filter

We might move that to a different service within the platform at a later st=
age.



HTH



Steffo



> On 2. May 2019, at 22:46, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

> 

> All,

> 

> As part of the shepherd write-up for the JWT Response for OAuth Token =
Introspection draft, we are looking for information about implementations f=
or this document:

> https://datatracker.ietf.org/doc=
/draft-ietf-oauth-jwt-introspection-response/

> 

> Are you aware of any implementations?

> 

> Regards,

>=C2=A0 Rifaat

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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





--

Dr Steffo Weber | Architect

ForgeRock



http://flip.it/caxRa=




Phone: +49 151 5167 9521

Skype: steffo.weber


















--000000000000313443058918de54--


From nobody Mon May 20 08:41: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 2E1A81201BB for ; Mon, 20 May 2019 08:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDzvRmEp17tw for ; Mon, 20 May 2019 08:41:25 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 094021201A8 for ; Mon, 20 May 2019 08:41:09 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id t184so3759678itf.2 for ; Mon, 20 May 2019 08:41:08 -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=v2JaOCeVgHT3GqcRAfnrq01lqHr/Y0IqFXR+6sMLVi0=; b=g6wbfA6MNVyK8nkK+iasE8eYFr7p0dGlsD292etE8sIquHCNVm2ARh3lEreoO2zydH riNrPmUF+YPtNpkXd0ZgHAy54EfkEj79OhL93/1Wbovq3X7x3f8MeB1dUbL2XCJK5m5G Ar6DCPLObjHY1vejMoXmCFZLYh6By6qUtkdDGXIk7XiN+Zaz2o17/1z4D7KWuaEOvOR3 ge/SRIfc/DaM5sJiJsWNxBv6ITL7QQnTwJoMfmu/zXvQwW2i+SKei9PLn0MTJ88D0O0E ZK/pLpwFVJc/Z35Z5bwHRYh4vE2nO+clWxcgLaLPs45TE6IJnSBDzcVnjNHmKF7qxC17 VTcg==
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=v2JaOCeVgHT3GqcRAfnrq01lqHr/Y0IqFXR+6sMLVi0=; b=dwOyPW3dt30lxp0LGyymncNOf1lPWpgAiAPG2BBEjJ6cjqj5EOFdFwBi8EipWwXAMw 2DfPBypdPWz888xwrpw+Z+gtm6JENcFNIwQ0Ku9q96ts7ECacr9xHQn621osp37XWJbO j50PbNbcIcHfqxbmWzGthfxlpAr2Nq1FAJUaLBNyTzXnPQNxBmpQ/mHevKry6WJYqF08 2KvTjaMapvh5PmIuiAvz6eB+O4/Doby3z+BXQa0bqV4hbyNSTi7crwiN5xyuz06e02KM ZVDPLpQfKgJcrXCrSYHvVCcuW2Rnr8IskOIrjj4vCFlrItXZ4wUJGykhBiD6Whgn5v0K Gn2A==
X-Gm-Message-State: APjAAAU5BupBq6rYscN02PTc0Uvqf7VWEmZoO8n6aJqRf+RWPVHbaCYt eM6B75jU+xuUTVU0O+L2D0XhDayALSKDsQtAQKolFQ==
X-Google-Smtp-Source: APXvYqzTCldd4fyPTj1vw846/C3sgThaNEzpfJVxsDO6UOF2fTjqZpTnNMTSYCWyG5a+ZrpCM+ecfrb0GrqpyUreBrE=
X-Received: by 2002:a24:19cd:: with SMTP id b196mr29226104itb.74.1558366867875;  Mon, 20 May 2019 08:41:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7794:0:0:0:0:0 with HTTP; Mon, 20 May 2019 08:41:06 -0700 (PDT)
From: Rifaat Shekh-Yusef 
Date: Mon, 20 May 2019 11:41:06 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000096f4840589538f2c"
Archived-At: 
Subject: [OAUTH-WG] OAuth WG Virtual Office
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, 20 May 2019 15:41:27 -0000

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

All,

Unfortunately Hannes and I have conflicts and will not be able to join the
meeting today.

Regards,
 Rifaat & Hannes

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

All,

Unfortunately Hannes and I have conflicts and will =
not be able to join the meeting today.

Regards,
=C2=A0Rifaat & Hannes



--00000000000096f4840589538f2c--


From nobody Mon May 20 22:21: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 3424A120121 for ; Mon, 20 May 2019 22:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3FwT6hN4vL9 for ; Mon, 20 May 2019 22:21:15 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE06412009C for ; Mon, 20 May 2019 22:21:14 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id m3so3973058wrv.2 for ; Mon, 20 May 2019 22:21:14 -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=LnJN0VoXNr6pL4rZXefpU7ZU/VfQVoNxsR4jzZerjY4=; b=TGMQAu7BwGPaTLGFcOergribzRRGJXauvrpHR7aJ3Ktq18eOgJg1s/nC0U2HFuzC8P yp6l6jNkmpjMDKm1FOQVDF849c5k02UW8d+tskr97rg1DixMktD7iR96f4OJ+eYrRgd2 BH1KPkyWQGJlDPec3L+3V+8nu2mT+exFcrY3i5Py87CDsbKInFc+eZGoeG4jxKHqRHET dvRhUNpZThVH+kRM/KrLLdPe6yyMhMwj/Dcs92tY4fl2+tnAv09UtR+tie6+wJnCYn/1 /oqFb5CDp9KQOrawHWoXcLRaAVKCXYkKEsF6R2EtQ8QkFGG724nYrgDvYSsNExGXYiBb Qm3Q==
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=LnJN0VoXNr6pL4rZXefpU7ZU/VfQVoNxsR4jzZerjY4=; b=EjxVTrH65OnglFDSDymz25iCt04/gQw0kAvbRun3PrRMMDtFrSMI2w5sHpn08lwvHo WEQ1sCo1xtb7TKoBBgn2sZ0Ojn6oyGD+gvChZ7y5RbKcCoAonCOA+Dq7mTSGd7EAV++w u6dX4LVy1LaBSvEOxPuIpwWg6oxspN9vkxDB4Y6I4TJMbJbedMBYS6h75kD7hSyGrVL+ Bt0YH36uvs33TMPddJRAwsOTghPmYyjYrIKWLr1MW8j2Puf+sTf9g1tWSfb/WDhomEvf 4Hz5SCvhBZVFOe5arZN1YE7KEcQHQ0MavH6LkipUyAuDO7Isx1HPOawHB3fFXt43pxVV lsrQ==
X-Gm-Message-State: APjAAAW6jNQswz0Y9krygP21LaERCDGDlF+OFNTnh6UbNlo1zcgrPZkt 6/1nEx8ByoRMT6uBpKzdbD9fW7oPdBJ3+OW4nWWdh5bq
X-Google-Smtp-Source: APXvYqxwT4VpGYsca3kNXiI/T1zmKPtENxI31m9bPQCidzEO3GZslOFqYJvDHcqmysxBQk4hi8qgLCE5Mq0uSbz1Dw0=
X-Received: by 2002:a5d:45c1:: with SMTP id b1mr38282995wrs.252.1558416073374;  Mon, 20 May 2019 22:21:13 -0700 (PDT)
MIME-Version: 1.0
From: Janak Amarasena 
Date: Tue, 21 May 2019 10:51:02 +0530
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000773eaa05895f04fd"
Archived-At: 
Subject: [OAUTH-WG] Device Authorization Grant Interval
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, 21 May 2019 05:21:16 -0000

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

Hi all,

In the OAuth2 Device Authorization Grant, what would be an appropriate
response if the client does not respect the set polling interval and keeps
on polling with a lower interval?

Thank you,
Best Regards,

Janak Amarasena

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


Hi all,

In the OAuth2 Device Authorizat=
ion Grant, what would be an appropriate response if the client does not res=
pect the set polling interval and keeps on polling with a lower interval?

Thank you,
Best Regards,

Janak Amarasena


--000000000000773eaa05895f04fd--


From nobody Tue May 21 11:08:52 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 5F0B712004C; Tue, 21 May 2019 11:08:51 -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.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <155846213135.2459.4502839665574510792@ietfa.amsl.com>
Date: Tue, 21 May 2019 11:08:51 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 18:08:51 -0000

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

        Title           : JWT Response for OAuth Token Introspection
        Authors         : Torsten Lodderstedt
                          Vladimir Dzhuvinov
	Filename        : draft-ietf-oauth-jwt-introspection-response-03.txt
	Pages           : 16
	Date            : 2019-05-21

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-03


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

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


From nobody Mon May 27 14: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 3CC0B120116 for ; Mon, 27 May 2019 14:04:09 -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 q67ZSXy8kYW2 for ; Mon, 27 May 2019 14:04:08 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03731120052 for ; Mon, 27 May 2019 14:04:08 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id h20so1018012itk.4 for ; Mon, 27 May 2019 14:04:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=HLrc+z38zgHPb6VkcUr5CqPjF8861N7uEHpHA9/wh3Y=; b=mny9sOYltQzVq+7q4Oay/kKZgzVlGcw6nFYKH65/fyOr3xGvZPCpnHxJtFohzFST1Y cOtDZY7KPpC/WXrf8QFgunfsd9ub+lgs7mK+P7h/QQoBPIbGRLe5VN1bbXzrx6dxe6Of Tns62TdeLijxK19PqoSn/4Xl7e2Jjdvprjig92ONbDpzg5pglwWJjOuLujW6T01vDLUQ N02xMAUtUtG6czDPrHMTYf/5QobDb7gm180GMI+xDAI7ibdgXTvBEfpOQYrw9zYj/W1o SxIjqPXsSAjDe8iy7tQwtfAyzexRfCj7Me8GyoEA2i4rg8NIi2kWvspgf/aDQP/HJ5wT CkZw==
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=HLrc+z38zgHPb6VkcUr5CqPjF8861N7uEHpHA9/wh3Y=; b=jGWa0/uByrw7JH1DNkHE0I0f0eDXnaItJLApTz+u7qwOUXZ7c3VSTxQ6UXaO/7/irB US8DiN9gfEHq1QDe5MtL8aG1+JBkyzLRqA5tmiCCN6o8by+tZ75oybXGfELwrCx5Su9k m3VCjhA93Qbdkt1vTrXZDt8VUEdj01WGTqe1DH4hvT2tQFTeNGJs/ekfLsb52scbA8x+ BausT42XtMY1UesT+Y8aUq9WL1yz/+6TKFTLOwGKDNMG/pVG5j5iCR6dGCETdBXg8c62 +SD/M2WAj+lQOPBCMsMybqhvrCju0d4M74eS3nqpZNuFcqW1ELn86DObPHywVXyKyP3J vrXg==
X-Gm-Message-State: APjAAAWCB3QVtWLkb86mSXsIylAjD0mhAau3TgcBAY/c6UYh7iDtAJrj uYtFRhbUaoNjXzcchFuDQemnFf2oC0dTw8qxDhPBhklw
X-Google-Smtp-Source: APXvYqxp18vBk5iQp3VFfwbWqnfvSPdiN5kvHMbUqFdeJsWa+C8o74o91rvp0Hmg9qcqoQhekn9hsgKjO/v+tJdD9sU=
X-Received: by 2002:a24:e3c6:: with SMTP id d189mr649501ith.145.1558991047228;  Mon, 27 May 2019 14:04:07 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 27 May 2019 17:03:56 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000009403560589e4e3e7"
Archived-At: 
Subject: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 27 May 2019 21:04:09 -0000

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

All,

Please, let us know if you have any topics that you would like to discuss
in Montreal.

Regards,
 Rifaat & Hannes

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


All,

Please, let us know if you have an=
y topics that you would like to discuss in Montreal.

Regards,
=C2=A0Rifaat & Hannes



--0000000000009403560589e4e3e7--


From nobody Tue May 28 05:51:27 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 4ED0412012E for ; Tue, 28 May 2019 05:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxlfcJ8h51vt for ; Tue, 28 May 2019 05:51:22 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40058.outbound.protection.outlook.com [40.107.4.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F011200CD for ; Tue, 28 May 2019 05:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/Sfnj+eVHvu3jSf8BSBNqnR13pCOhuQ0RLA68RDQj2k=; b=YW3TW6kfrXysA51LVLaN06K1LWqevcYYXYAEKACdbn1CH+UHVAkFn4rHJbogCpCcVSw/8aPe5+MLOEvWfQW/FCzEcq4WDUmUKopc/sB0F1K4FJxCxjY4CnwtSJr+ZwxVwJVoKISLMLoIelK0XE5n8U88yPQINbvGMcGmJ4liHEY=
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4743.eurprd08.prod.outlook.com (10.255.79.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.19; Tue, 28 May 2019 12:51:19 +0000
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::91a5:7d70:3c7e:d096]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::91a5:7d70:3c7e:d096%6]) with mapi id 15.20.1922.021; Tue, 28 May 2019 12:51:19 +0000
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Thread-Topic: Virtual Interim Meeting: Doodle Poll
Thread-Index: AdUVU6RjNye+1DF9QQKpneYB5r0XQA==
Date: Tue, 28 May 2019 12:51:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.123.119]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e91e1f35-858c-48b4-bbe7-08d6e36b2e2f
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:DBBPR08MB4743; 
x-ms-traffictypediagnostic: DBBPR08MB4743:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39860400002)(376002)(346002)(189003)(53754006)(40434004)(199004)(6916009)(6116002)(3846002)(5660300002)(790700001)(102836004)(74316002)(73956011)(478600001)(76116006)(71200400001)(8676002)(4744005)(8936002)(7696005)(81166006)(81156014)(14444005)(256004)(5024004)(6506007)(71190400001)(2501003)(66946007)(33656002)(1730700003)(2906002)(68736007)(25786009)(26005)(66066001)(186003)(52536014)(99286004)(86362001)(14454004)(54896002)(9686003)(486006)(316002)(476003)(53936002)(7736002)(64756008)(66556008)(66446008)(66476007)(966005)(72206003)(2351001)(6436002)(5640700003)(55016002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4743; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tm2+TelHCPm4llbIVry7HICmSUn4q9/oUX7tq5krXkg/Z130D2wvom8UkvLnSe675pMvXH54nKe3r6mFGth2O3zegpBj8bUFnFhYlXGVoCe+lArOB8PZbaGdfSwsdA0s4bei7Rgcyu8FqIBz6tFTH4MPALDSLn+H0sBb49A5x0wOAFySt6v7hn+C0zG2iKhjP+u4KH9pvFSjnaRiO8j5IsWMosK0bg6AnmugWOZUGkcU+LNAX2e4ZqnbOP05j29Dg2dI1Qp6A2Ag5kGmCBr/yAtIzYSQrH36AE6+61yeGapXBchha61Y4t515ykYg75V/iDTQhTLkvX/lqsesx5C8wzpZLk4aYyZyWKD70Nbj4kVfb5lBtQxhrDnbQRpKr9u+yViHprBm8ixnv5D0UxoIJLVOcYnI7A/As2txgxEPSY=
Content-Type: multipart/alternative; boundary="_000_DBBPR08MB4539D3825A9F76C29CDA3FD9FA1E0DBBPR08MB4539eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e91e1f35-858c-48b4-bbe7-08d6e36b2e2f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 12:51:19.3820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hannes.Tschofenig@arm.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4743
Archived-At: 
Subject: [OAUTH-WG] Virtual Interim Meeting: Doodle Poll
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, 28 May 2019 12:51:25 -0000

--_000_DBBPR08MB4539D3825A9F76C29CDA3FD9FA1E0DBBPR08MB4539eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

at the Prague IETF meeting we ran a bit out of time during the working grou=
p session and therefore we would like to schedule an interim meeting to con=
tinue the conversation about UMA.

Rifaat and I have set up a Doodle poll with two possible dates (1 hour slot=
s at the bi-weekly OAuth WG office hour time slots). Please indicate your a=
vailability by June 6th:
https://doodle.com/poll/gde6z2t3ngwcesnc


Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.

--_000_DBBPR08MB4539D3825A9F76C29CDA3FD9FA1E0DBBPR08MB4539eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 


at the Prague IETF meeting we ran a bit out of time =
during the working group session and therefore we would like to schedule an=
 interim meeting to continue the conversation about UMA.



 


Rifaat and I have set up a Doodle poll with two poss=
ible dates (1 hour slots at the bi-weekly OAuth WG office hour time slots).=
 Please indicate your availability by June 6th:



https://doodle.com/poll/gde6z2t3ngwcesnc<=
/p>

 


 


Ciao


Hannes & Rifaat



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



--_000_DBBPR08MB4539D3825A9F76C29CDA3FD9FA1E0DBBPR08MB4539eurp_--


From nobody Tue May 28 07:33: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 3EB30120127 for ; Tue, 28 May 2019 07:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 kSrkG2Un5s_G for ; Tue, 28 May 2019 07:33:34 -0700 (PDT)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 34FE61200B6 for ; Tue, 28 May 2019 07:33:34 -0700 (PDT)
Received: by mail-wr1-x441.google.com with SMTP id w13so12130149wru.11 for ; Tue, 28 May 2019 07:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yDC68VUeTZFDoIg1z4XziBObgrzycII0Uw1kK3nbXUw=; b=hHReMvki8+gUJsTkyCgo6NmMsw7shi3MqNa3iEgqMBTWXyYCye7069OhVrFyM59xTv /qsKxhQudAF3S6jKSf+ChZxOGtuHE/WBwGDOfy2wKFGgvz+EyQGZ1gPkF+IZFNUWPb7a J2tRrAJ8VIumQmQW6bEwvsyCSj6JPVOzIvgXk=
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=yDC68VUeTZFDoIg1z4XziBObgrzycII0Uw1kK3nbXUw=; b=s+I/hXNEZVIQ9pBd9jWNS2VRFXg7KaF7oIcL7p9BgQkSmcMv7Br4KHhW1tsdCok470 BWZQ8BWEqJm9Zt60PazGeNg7dkZ6w+Qdozll72e+WWvAuSo6Zbfm6z+qDtgnpmUTLO+g x/FwKgU6RHDnb8MwgxiYFR85/6Hq8zrHhygYtGlVxRVG5esq2NeEiEeLff+7DY2GQLrZ POQDoxfcmTGT4HvBGITaPJ0wCQoI36JV00MdEzIO9l75VjCxL85R1/hS9MAfVOdMO4gX PZ9ei/3Q921xu2Vpo92UJ5jLJqzMPIZ/A7emAPOoM7AXVwUuchd0GHLime4WMJWOlon3 JJnA==
X-Gm-Message-State: APjAAAWdHa/X7mMuBgRVoAKbVQzkps+fjF4mfMgPhazO2FdQJUFKIheO c6M4C53SRott/nSOKhngNtFXsw==
X-Google-Smtp-Source: APXvYqxA9Uizeq1Blsl7BFtmPJdhvYPWGvtJvAi3Ripg5xSIzg0LOaEZrH9HydsAxUpMdcq2bMGXDA==
X-Received: by 2002:adf:efc3:: with SMTP id i3mr63738647wrp.45.1559054012171;  Tue, 28 May 2019 07:33:32 -0700 (PDT)
Received: from [192.168.2.122] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id b2sm13096580wrt.20.2019.05.28.07.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 07:33:31 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden 
In-Reply-To: 
Date: Tue, 28 May 2019 15:33:29 +0100
Cc: IETF oauth WG , Daniel Fett 
Content-Transfer-Encoding: quoted-printable
Message-Id: <26453CD1-45A3-43F0-92D4-77CD42972AF3@forgerock.com>
References: <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <38C30749-0AF1-455B-84DA-29440864E198@forgerock.com> <1BEB5CBA-6AD0-4EB0-88F5-A2FCEF53A48C@lodderstedt.net>  
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth security topics
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, 28 May 2019 14:33:38 -0000

Hi Torsten,

Apologies for the late reply. Suggested text:

----
4.x Client Impersonation of Resource Owner

Resource servers may make access control decisions based on the identity =
of the resource owner as communicated in the "sub" claim returned by the =
authorization server in a token introspection response [RFC 7662] or =
other mechanism. If a client is able to choose its own client_id during =
registration with the authorization server, then there is a risk that it =
can register with the same "sub" value as a privileged user. A =
subsequent access token obtained under the client_credentials grant may =
be mistaken as an access token authorized by the privileged user if the =
resource server does not perform additional checks.

4.1.x Proposed Countermeasures

Authorization servers SHOULD NOT allow clients to influence their =
client_id or "sub" value or any other claim that might cause confusion =
with a genuine resource owner. Where this cannot be avoided, =
authorization servers MUST provide another means for the resource server =
to distinguish between access tokens authorized by a resource owner from =
access tokens authorized by the client itself.
----

Open to revisions/suggestions.

-- Neil


> On 8 May 2019, at 13:15, Torsten Lodderstedt  =
wrote:
>=20
> You are right. May I ask you to propose text (threat description, =
advice, ...) to be included in the BCP?=20
>=20
>> On 7. May 2019, at 13:23, Neil Madden  =
wrote:
>>=20
>> The same issue applies to token introspection responses though.
>>=20
>>> On 7 May 2019, at 12:21, Torsten Lodderstedt =
 wrote:
>>>=20
>>> Hi Neil,
>>>=20
>>> you raised a very important issue but the Security BCP does not talk =
about JWT content like the Access Token JWT BCP.
>>>=20
>>> I therefore think the security advise should go into the security =
considerations section of the Access Token JWT BCP.
>>>=20
>>> best regards,
>>> Torsten.
>>>=20
>>> Am 07.05.2019 um 11:18 schrieb Neil Madden =
:
>>>=20
>>>> Is it too late to add the observation below to the OAuth security =
topics BCP draft?
>>>>=20
>>>>=20
>>>>> Begin forwarded message:
>>>>>=20
>>>>> From: Neil Madden 
>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>> Date: 7 May 2019 at 09:37:29 BST
>>>>> To: Vittorio Bertocci 
>>>>> Cc: Hans Zandbelt , Karl McGuinness =
, John Bradley , IETF oauth WG =

>>>>>=20
>>>>> I wasn=E2=80=99t at IIW so I may be missing some context.
>>>>>=20
>>>>> There is a potential security issue if the client_id is used as =
the =E2=80=9Csub=E2=80=9D for an AT obtained via client_credentials. If =
the client can register itself with a self-chosen client_id then it may =
deliberately chose a client_id that matches the user name of a =
privileged user. An RS that just blindly looks at the =E2=80=9Csub=E2=80=9D=
 claim may then erroneously let the client perform privileged actions.
>>>>>=20
>>>>> Is this the context of the discussion?
>>>>>=20
>>>>> Given that there are a lot of RSes in existence, many of which are =
probably just looking at the =E2=80=9Csub=E2=80=9D claim to identify the =
resource owner, I think the onus is on the AS to ensure that no such =
ambiguity can arise in the first place by ensuring that the space of =
=E2=80=9Csub=E2=80=9D values for client credentials is disjoint with the =
space for genuine users or by disallowing the client_credentials grant =
altogether.
>>>>>=20
>>>>> This issue already arises in token introspection though, so maybe =
ought to be mentioned in the OAuth security topics draft rather than =
specific to the JWT AT draft?
>>>>>=20
>>>>> =E2=80=94 Neil
>>>>>=20
>>>>>> On 6 May 2019, at 18:32, Vittorio Bertocci =
 wrote:
>>>>>>=20
>>>>>> Hi all,
>>>>>> thanks for your patience during this month long hiatus, and =
thanks for the comments.
>>>>>> Last week at IIW I had the opportunity to discuss this with many =
of the people on the list. Here's a summary of where the discussion =
landaed on the subject of the sub (pun intended).
>>>>>>=20
>>>>>> - It seems that RFC 7519 has pretty clear language on the use of =
sub- I didn't check it back when we started the discussion. I do agree =
with the people saying that we shouldn't violate existing =
specifications, hence it looks like we do need to have sub also in the =
case in which we have app-only tokens carrying claims about the app =
itself. I understand this will cause some implementation to break, but =
unfortunately that's intrinsic in the process of coming up with a common =
approach and standards compliance is probably one of the strongest =
reasons to tolerate that.
>>>>>> - That said, I am strongly committed to preserve existing =
functionality. One of the main reasons that was brought up for including =
sub only for user based ATs was to use it as heuristic for telling those =
tokens apart from app-only ones. To that end, Karl MCGuinness suggested =
that we include grant_type as a return claim, which the RS could use to =
the same effect. I find the proposal very clever, and the people at IIW =
thought so as well. What you think?
>>>>>> Note, John Bradley observed that in some cases this might lead to =
ambiguous results if an extension grant is used (say an assertion =
profile) but that seems like a relatively fringe occurrence.
>>>>>>=20
>>>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt =
 wrote:
>>>>>> I also meant to say that (of course) the JWT standard doesn't say =
that the JWT is supposed to be about the client or about the resource =
owner, hence both are valid
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones =
 wrote:
>>>>>> I get that existing practice is likely to be all over the map, =
but if we=E2=80=99re to create a JWT access token standard, it=E2=80=99s =
reasonable to require that the claims usage comply with the JWT =
standards.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>                                                                -- =
Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> From: Hans Zandbelt =20
>>>>>> Sent: Thursday, April 4, 2019 12:59 PM
>>>>>> To: Mike Jones 
>>>>>> Cc: George Fletcher ; =
Vittorio Bertocci ; IETF oauth WG =

>>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> the definition of RFC 7519 is actually "petitio principii" and a =
lot of deployments put claims about the Resource Owner in the access =
token (as a Resource Server implementer I've suffered a lot from this)
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones =
 wrote:
>>>>>>=20
>>>>>> I agree with George that the subject of a token must be the =
principal of that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim =
is for.  Indeed, the first sentence of the =E2=80=9Csub=E2=80=9D =
definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>>>>>>=20
>>>>>> The "sub" (subject) claim identifies the principal that is the =
subject of the JWT.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must =
comply with the definition from RFC 7519.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>                                                                -- =
Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> From: OAuth  On Behalf Of George Fletcher
>>>>>> Sent: Thursday, April 4, 2019 8:51 AM
>>>>>> To: Hans Zandbelt 
>>>>>> Cc: Vittorio Bertocci ; =
IETF oauth WG 
>>>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> The more I think about this the more I land in the "No" camp.
>>>>>>=20
>>>>>> The subject of a token should be the principal of that token. It =
shouldn't matter whether that is a machine, a user, or a device. Trying =
to separate out "humans" as a special class will just make things more =
complicated. If we need a claim to identify the subject is a "human" =
then why not just add that. This doesn't break anything and makes it =
easy for people to detect this case in those use cases where it's =
required.
>>>>>>=20
>>>>>> Thanks,
>>>>>> George
>>>>>>=20
>>>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>>>>>>=20
>>>>>> I will argue that in a way such deployments are already broken =
e.g. in the typical use case of onboarding client accounts in the same =
directory/OU/namespace as user accounts and we don't need to cater for =
that.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher =
 wrote:
>>>>>>=20
>>>>>> I agree that this will break a lot of existing flows... =
especially those using any form of the client_credentials flow. In that =
sense I'm not completely on board yet :)
>>>>>>=20
>>>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>>>>>=20
>>>>>> great summary! this will hurt quite a few existing m2m =
deployments but I do like the rigidness of it all: it is very explicit, =
cannot misinterpreted and thus prevents failure (which is really what =
Dominick is after); I'm on board
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci =
 wrote:
>>>>>>=20
>>>>>> thank you Steinar and everyone else for the comments on this!
>>>>>>=20
>>>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, =
Nov, Bertrand recommend using sub only for users. Martin would like to =
have the sub for app only flows as well. Hans is neutral.
>>>>>>=20
>>>>>> That does sound like the sub as user has more consensus, tho =
before changing it I'd wait for the people currently at IETF104 to have =
more time to comment as well.
>>>>>>=20
>>>>>> Clarification. If the goal is to be able to apply the logic "if =
there's a sub, it's a user flow", we have to explicitly disallow (MUST =
NOT) the use of sub when that's not the case. Are all OK with it?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Dave, the suggestion of having explicit typing for app only vs =
user only is interesting! For the purpose of putting together an =
interoperable profile, tho, I would suggest we table it for v1 in the =
interest of getting to something easy to adopt (hence with small delta =
vs existing implementations) faster.    =20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  =
wrote:
>>>>>>=20
>>>>>> Hi Vittorio, we  (the national federation-gateway for the health =
services in norway - "HelseID")  think his is a really valuable =
initiative!
>>>>>>=20
>>>>>> We also agree with Dominick concerning definition of the "sub" =
claim.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Steinar
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier =
:
>>>>>>=20
>>>>>> =46rom an access token consumer (aka API) developer point of =
view, I prefer this logic
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> "If sub is present - client acts on behalf of a user, if not - =
not."
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Anything more complicated has a potential of going wrong.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) =
wrote:
>>>>>>=20
>>>>>> Hi Vittorio,
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Yeah, I=E2=80=99m concerning user & client ids collision.
>>>>>>=20
>>>>>> I haven=E2=80=99t seen such implementations, but user-select =
username as sub, or incremental integer as sub & client_id will be =
easily collide.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> If you can enforce collision resistant IDs between user & client =
instances, it=E2=80=99ll works fine. I feel its overkill though.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Sent from my iPhone
>>>>>>=20
>>>>>>=20
>>>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci  =
wrote:
>>>>>>=20
>>>>>> Hey Nov, Dominick, Hans-
>>>>>>=20
>>>>>> thanks for the comments. That was an area I was expecting to =
cause more discussion, and I am glad we are having this opportunity to =
clarify.
>>>>>>=20
>>>>>> The current language in the draft traces the etymology of sub to =
OpenID Connect core, hence Dominick observation is on point. However in =
the description I express something in line with 7519, which was in fact =
my intent.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> The idea was to provide an identifier of the calling subject that =
is guaranteed to be present in all cases- this would allow an SDK =
developer to use the same code for things like lookups and membership =
checks regardless of the nature of the caller (user in a delegated case, =
app in app-only grants). The information to discriminate between user =
and app callers is always available in the token (say, the caller is a =
user if sub!=3Dclient_id, where client_id is always guaranteed to be =
present as well) hence there's no loss in expressive power, should that =
difference be relevant for the resource server.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Dominick, Hans- I probably missed the security issue you guys are =
thinking of in this case. Of course, if this would introduce a risk I =
completely agree it should be changed- I'd just like to understand =
better the problem. Could you expand it in a scenario/use case to =
clarify the risk?
>>>>>>=20
>>>>>> Nov- playing this back: is the concern that a user and a client =
might have the same identifier within an IDP? When using collision =
resistant IDs, as it is usually the case, that seems to be a remote =
possibility- did you stumble in such scenario in production?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Thanks
>>>>>>=20
>>>>>> V.=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt =
 wrote:
>>>>>>=20
>>>>>> I believe there are plenty of OAuth 2.0 only use cases out =
there... but nevertheless I agree with the potential confusion and thus =
security problems arising from that (though one may argue the semantics =
are the same).
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier =
 wrote:
>>>>>>=20
>>>>>> Yes I know - and I think in hindsight it was a mistake to use the =
same claim type for multiple semantics.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience =
almost no-one (that I know) does OIDC only - nor OAuth only. They always =
combine it.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> In reality this leads to potential security problems - this spec =
has the potential to rectify the situation.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Dominick
>>>>>>=20
>>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt =
(hans.zandbelt@zmartzone.eu) wrote:
>>>>>>=20
>>>>>> Without agreeing or disagreeing: OIDC does not apply here since =
it is not OAuth and an access token is not an id_token.
>>>>>>=20
>>>>>> The JWT spec says in =
https://tools.ietf.org/html/rfc7519#section-4.1.2:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> "The "sub" (subject) claim identifies the principal that is the
>>>>>>=20
>>>>>>   subject of the JWT.  The claims in a JWT are normally =
statements
>>>>>>=20
>>>>>>   about the subject.  The subject value MUST either be scoped to =
be
>>>>>>=20
>>>>>>   locally unique in the context of the issuer or be globally =
unique.
>>>>>>=20
>>>>>>   The processing of this claim is generally application specific"
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> which kind of spells "client" in case of the client credentials =
grant but I also do worry about Resource Servers thinking/acting only in =
terms of users
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier =
 wrote:
>>>>>>=20
>>>>>> IMHO the sub claim should always refer to the user - and nothing =
else.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> OIDC says:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> client_id should be used to identify clients.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> cheers
>>>>>>=20
>>>>>> Dominick
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) =
wrote:
>>>>>>=20
>>>>>> Hi Vittorio,
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Thanks for the good starting point of standardizing JWT-ized AT.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> One feedback.
>>>>>>=20
>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of =
identifier, end-user and client, in this spec.
>>>>>>=20
>>>>>> It requires those 2 types of identifiers to be unique each other =
in the IdP context.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged =
context, so that no such constraint needed.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> thanks
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> nov
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci =
 wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Dear all,
>>>>>>=20
>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 =
access tokens. You can find it in =
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>>>>>>=20
>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be =
presenting remotely). I look forward for your comments!
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Here's just a bit of backstory, in case you are interested in how =
this doc came to be. The trajectory it followed is somewhat unusual.
>>>>>>=20
>>>>>> 	=E2=80=A2 Despite OAuth2 not requiring any specific format for =
ATs, through the years I have come across multiple proprietary solution =
using JWT for their access token. The intent and scenarios addressed by =
those solutions are mostly the same across vendors, but the syntax and =
interpretations in the implementations are different enough to prevent =
developers from reusing code and skills when moving from product to =
product.
>>>>>> 	=E2=80=A2 I asked several individuals from key products and =
services to share with me concrete examples of their JWT access tokens =
(THANK YOU Dominick Baier (IdentityServer), Brian Campbell =
(PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for =
the tokens and explanations!).
>>>>>> I studied and compared all those instances, identifying =
commonalities and differences.=20
>>>>>> 	=E2=80=A2 I put together a presentation summarizing my findings =
and suggesting a rough interoperable profile (slides: =
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt=
_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. =
Thx Filip!
>>>>>> 	=E2=80=A2 The presentation was followed up by 1.5 hours of =
unconference discussion, which was incredibly valuable to get tight-loop =
feedback and incorporate new ideas. John Bradley, Brian Campbell =
Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig =
were all there and contributed generously to the discussion. Thank =
you!!!
>>>>>> Note: if you were at OSW2019, participated in the discussion and =
didn't get credited in the draft, my apologies: please send me a note =
and I'll make things right at the next update.
>>>>>> 	=E2=80=A2 On my flight back I did my best to incorporate all the =
ideas and feedback in a draft, which will be discussed at IETF104 =
tomorrow. Rifaat, Hannes and above all Brian were all super helpful in =
negotiating the mysterious syntax of the RFC format and submission =
process.
>>>>>> I was blown away by the availability, involvement and willingness =
to invest time to get things right that everyone demonstrated in the =
process. This is an amazing community.=20
>>>>>>=20
>>>>>> V.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>=20
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>=20
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> Vennlig hilsen
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Steinar Noem
>>>>>>=20
>>>>>> Partner Udelt AS
>>>>>>=20
>>>>>> Systemutvikler
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | =
www.udelt.no |=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>=20
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>=20
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>>=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>>=20
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --=20
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>=20
>>=20
>=20


From nobody Tue May 28 08:29: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 A387F12013A for ; Tue, 28 May 2019 08:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level: 
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdAPhX0zsRHp for ; Tue, 28 May 2019 08:29:06 -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 BEE49120115 for ; Tue, 28 May 2019 08:29:06 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id g18so18113134otj.11 for ; Tue, 28 May 2019 08:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:from:date:message-id:subject:to; bh=PJCyuP7bCVjsBRy2FCugSrpda4vBr6PJ9px1+3XzB1Q=; b=MlhszMpSDOB21UB+uirsv98A596+GE+L55CvnxByWuQV0rFYIQ/T7HpM0/Z9oZNTHf wXDJKr9uOuGEPfZq0J13aNyt0Nq9ELRGcjJCaV7az6yAUsoXMRi/YPWjtNN1jQzCVGh1 c86F5G7p84o0JOVAl4jnS1qXnNBvZiArZc+h4=
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=PJCyuP7bCVjsBRy2FCugSrpda4vBr6PJ9px1+3XzB1Q=; b=t4IzVzj71bC0ysQ6si892W1HdwJ/coRysugqU15rIvTuT2/VSmW9dYRe9D9GCth57J 1d9eIKC/nyuckvhW41GjFJG/PvVply1Sqr16zYSYGcRq8S1hZEn0GBFzBaoGr2N9Ng3v iCzKjqZ5EKibM1LIMvoPKEHPepTPxwIVYel4wMaFXVdvQqOJ9lrGOe5YmBbDCJnZ/BYE T01PnfwTxA8KnmwP0SIrurHYTCjDFAo13iy6exz9NprwuFiCov0evh4Gh6qYmEkldY3w W/YkcavkrvDd5mwtXLGoEHxhNA4bgce9Ygvn5hbFP0Pg2oe03sN9wJA3eQ5u3PFktxv0 1aOA==
X-Gm-Message-State: APjAAAUd1llPfCx7sIdj7CTvZ/dqr2PGvwcMnYs+C2RPB+EKQbrz2DB5 GQ7yLzqtiRrTMirHqu4zOWhSa5xLuXoCByAR51jWEfNbQu1IOg==
X-Google-Smtp-Source: APXvYqwS8Luf1WLK0hd2zNKlBOOuHtzR1p2GVd+atenx/mkFfEhgEOgSQtIiPn3QgMIEzpHOCGuwFFouC89SnSi2OcQ=
X-Received: by 2002:a9d:7a53:: with SMTP id z19mr31711343otm.260.1559057345483;  Tue, 28 May 2019 08:29:05 -0700 (PDT)
MIME-Version: 1.0
From: Dave Tonge 
Date: Tue, 28 May 2019 17:28:54 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000004346e80589f453fe"
Archived-At: 
Subject: [OAUTH-WG] Client assertions to endpoints other than the token endpoint
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 May 2019 15:29:09 -0000

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

Dear OAuth WG

We have an issue that we are discussing in the OIDF MODRNA work group
relating to the Client Initiated Back Authentication spec (which is an
OAuth 2 extension). As the issue affects the wider OAuth ecosystem we
wanted to post it here and gain feedback from the OAuth Working Group.

Full details of the issue are here:
https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to
(including
a helpful context setting by Brian), but the summary is:

*What audience value should a Client use when using a client assertion
(RFC7521) to authenticate at an endpoint other than the token endpoint?*

The three options we have are:
1. the token endpoint (as RFC7521 says)
2. the endpoint the assertion is being sent to (e.g. revocation,
backchannel)
3. the issuer

We are leaning towards requiring the Authorization Server to accept any of
the above values, but recommending that the Client use the issuer value.

The reasons for this are:
1. All of the above values are arguably valid, so in the interest of
interoperability the AS should accept them all.
2. We see no clear security benefit to requiring the audience to be the
value of the endpoint the assertion is being sent to, and therefore think
that the issuer value is the one we should recommend that clients use.

We would be grateful for your feedback on this issue and believe it would
be in the best interest of the ecosystem for there to be a consistent
approach to this across OAuth 2 extensions and profiles.

Thanks

Dave Tonge

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


Dear OAuth WG

We have an issue that we are =
discussing in the OIDF MODRNA work group relating to the Client Initiated B=
ack Authentication spec (which is an OAuth 2 extension). As the issue affec=
ts the wider OAuth ecosystem we wanted to post it here and gain feedback fr=
om the OAuth Working Group.

Full details of the issue are he=
re:=C2=A0https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client=
_assertion-passed-to=C2=A0(including a helpful context setting by Brian=
), but the summary is:

What audience value should a Clien=
t use when using a client assertion (RFC7521) to authenticate at an endpoin=
t other than the token endpoint?

The three option=
s we have are:
1.=C2=A0the token endpoint (as RFC7521 says)
2. the endpoint the assertion is being sent to (e.g. revocat=
ion, backchannel)
3. the issuer<=
/span>

We are leaning towards requiring the =
Authorization Server to accept any of the above values, but recommending th=
at the Client use the issuer value.

1. All of the above values are=
 arguably valid, so in the interest of interoperability the AS should accep=
t them all.
2. We see no clear security benefit to requiri=
ng the audience to be the value of the endpoint the assertion is being sent=
 to, and therefore think that the issuer value is the one we should recomme=
nd that clients use.=C2=A0

We would =
be grateful for your feedback on this issue and believe it would be in the =
best interest of the ecosystem for there to be a consistent approach to thi=
s across OAuth 2 extensions and profiles.

Thanks

Dave Tonge
<=
div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s=
ans-serif">


--0000000000004346e80589f453fe--


From nobody Wed May 29 09:35: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 50443120136 for ; Wed, 29 May 2019 09:35:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 e0pvsGtcMc-K for ; Wed, 29 May 2019 09:35:19 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36047120183 for ; Wed, 29 May 2019 09:35:16 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x4TGZeRF010330; Wed, 29 May 2019 12:35:41 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 29 May 2019 12:34:19 -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; Wed, 29 May 2019 12:35:14 -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; Wed, 29 May 2019 12:35:14 -0400
From: Justin Richer 
To: Rifaat Shekh-Yusef 
CC: oauth 
Thread-Topic: [OAUTH-WG] OAuth WG Sessions in Montreal
Thread-Index: AQHVFM++Uk/fIcCvZkGxo7q0DCNHraaCkmoA
Date: Wed, 29 May 2019 16:35:14 +0000
Message-ID: <3545B999-A875-4327-A5CF-44306585A012@mit.edu>
References: 
In-Reply-To: 
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_3545B999A8754327A5CF44306585A012mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 29 May 2019 16:35:21 -0000

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

SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhlIFRyYW5zYWN0aW9uYWwgQXV0aG9yaXphdGlvbiAo
WFlaKSBkcmFmdC4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10
cmFuc2FjdGlvbmFsLWF1dGh6LTAwDQoNCuKAlCBKdXN0aW4NCg0KT24gTWF5IDI3LCAyMDE5LCBh
dCA1OjAzIFBNLCBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWls
dG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkFsbCwNCg0KUGxlYXNlLCBsZXQg
dXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgdG9waWNzIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gZGlz
Y3VzcyBpbiBNb250cmVhbC4NCg0KUmVnYXJkcywNCiBSaWZhYXQgJiBIYW5uZXMNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRoZSBU
cmFuc2FjdGlvbmFsIEF1dGhvcml6YXRpb24gKFhZWikgZHJhZnQuDQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDAiIGNsYXNz
PSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25h
bC1hdXRoei0wMDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0
LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIg
Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+T24gTWF5IDI3LCAyMDE5LCBhdCA1OjAzIFBNLCBSaWZhYXQgU2hla2gtWXVzZWYgJmx0Ozxh
IGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnJpZmFhdC5pZXRm
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo
YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5B
bGwsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Q
bGVhc2UsIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSB0b3BpY3MgdGhhdCB5b3Ugd291bGQg
bGlrZSB0byBkaXNjdXNzIGluIE1vbnRyZWFsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+Jm5ic3A7UmlmYWF0ICZhbXA7IEhhbm5lczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp
dj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs
YXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_3545B999A8754327A5CF44306585A012mitedu_--


From nobody Wed May 29 12:46:15 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 34CA8120125 for ; Wed, 29 May 2019 12:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 cN8QAIki5o-N for ; Wed, 29 May 2019 12:46:12 -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 38D0012001B for ; Wed, 29 May 2019 12:46:12 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id p2so2947711iol.2 for ; Wed, 29 May 2019 12:46:12 -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=f6AoIm4HPDzyzbKT/I37QErtTWozcPCAO4RNuFc03Kg=; b=CQ44Y06A6B57r+VPEjhqO229aDCw33MeR1qFBtC1DTnrMPY6zkv7R2xA99MgWgNC96 owaskuJVPx9db0Nb8zMm6ndv3zmgE6/X7iwmnFinEz5wRI59GHi4eUwTSDifh5XVsw49 qlrfPRiBx7+jIRsaLraPHbd3A0K45QXCcm3to=
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=f6AoIm4HPDzyzbKT/I37QErtTWozcPCAO4RNuFc03Kg=; b=i3qeYpoXCu4wcje2XP1Q1dv5q5CQ0m3SMZSUuf8LKTiz/wGpGr8twtlYup4i7HxRRD gcckgwQFSZerzJeS1OBaAYpNoVot/shJ1mA72SHpUjCT1FkVvSoatTX+kI+sHkNDtFLD GB9zbWCw295COHE40hhgxnagnw/wcjITfHgCFmF2MvDOJTFnc1MS/Ur0oBRge2u507N+ 1xj1z7ogqMFtKBqRIyoMatzgwhYNkPp2nkzTJS/yCdVcJQU6gNtybeyaOIiM1lY838Ku jPt3/DOOblZXrqZv2qhwI/2vVq6qsXUrgmNdAECt+bbItysYKJ17U71zk5/4cnsnlcrN 3cwA==
X-Gm-Message-State: APjAAAUFFv25lELq+VhDbg0aYyCC8d/i2j0HCZoY89HUlaCurOSbEJNo Pk56SL5SK3cYBaRPg8ifT/uKjB1Gy1+wbARkDht4HNW2eD6VxXIOHQcloLpYBqOKSzOhjBPy5JP Ew6scnrKZ5JsW+Q==
X-Google-Smtp-Source: APXvYqz/OPpdCdI6tn+n/vKbH6ng5pJwR6XYLgH/6Xps5U9R4F/z47BHHVrjTl3iVdRGiJPZ7GEK/v4c4pYlWNQ3OHA=
X-Received: by 2002:a6b:7312:: with SMTP id e18mr1925417ioh.156.1559159166631;  Wed, 29 May 2019 12:46:06 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Wed, 29 May 2019 13:45:40 -0600
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000004693c7058a0c0854"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 29 May 2019 19:46:14 -0000

--0000000000004693c7058a0c0854
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Please allow some time for presentation and discussion of DPoP.

https://tools.ietf.org/html/draft-fett-oauth-dpop-01 is the latest draft
but I hope and expect that there will be an update before Montreal.

On Mon, May 27, 2019 at 3:04 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to discuss
> in Montreal.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> 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._

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


Please allow some time for presentation and discussio=
n of DPoP.=C2=A0 

https://tools.ietf.o=
rg/html/draft-fett-oauth-dpop-01 is the latest draft but I hope and exp=
ect that there will be an update before Montreal.

On Mon, May 27, 2019=
 at 3:04 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Please, let us know if you have any topics that you would like to dis=
cuss in Montreal.

Regards,
=C2=A0Rifaat =
& Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000004693c7058a0c0854--


From nobody Wed May 29 13:06: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 5026712006E for ; Wed, 29 May 2019 13:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 yxZx2sNQBd_7 for ; Wed, 29 May 2019 13:06:49 -0700 (PDT)
Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 3DA6612001B for ; Wed, 29 May 2019 13:06:49 -0700 (PDT)
Received: by mail-it1-x133.google.com with SMTP id h11so5640978itf.5 for ; Wed, 29 May 2019 13:06:49 -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; bh=kEM2SWzSLB8QfV8ju3lZppd8hV9ZH4z8dbZUie14yhs=; b=jBqy1SLud38iV8AUbnsIosPOwOOoRUGBCymNENmsW5v8OCv9c+F284RpeK4ShoKz2C gOJgbeK2boeCoheal/LbUA1itKUVGgDLbIZAa+AxkOyapL9Pj8sW9od1U9FSDHW2/x1E j7l6I4jZjB+HjytMY0VLkOoNjdigEDgDKfviGukAGsG4jxlfIqSGuhWybhnwdseV8Esy M+A9Hb/0Lgr/9VtVjX1VBTrduABSYmH83T36avvdQVh+PdKaf9AKkTA8Zv5tmNYZ/F0t +2SYzirus9GWMglRjqP6t9Vyk3Y9pblzmLz5hU7x6LVcn3eb49Jm9dUu4mEQEGvw0Ws8 7gBw==
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=kEM2SWzSLB8QfV8ju3lZppd8hV9ZH4z8dbZUie14yhs=; b=twoqsvku3nf59mYsfwBEzuYiC/qqgAiVvH/rMYFMaIazLuv1qPcNIPfq0h78oURGc/ nKt3UduEkidCKyl56u3knAlP3dEaDzPlQz5rItTui9if5hFeGrjI0rmZPZ5P0QGP0kjo oEFeJolg9W/7OW/Kb8iEEWit79ofOf7ovMxpgJB1ucznluO/B1Xf+/3lGf9R8vzRJGGk fGLWlNYIN/F2fv1Fdmd9iEW6WhwjGEe9zmJiCIJtv4x4xKwrsykjpeIYyB1I/Xolyakh hs1Ft8cz2UTyfgjwFk5RScAqXXUv3NVW2CIuLOtDkhqhCdvD9XhQY5exOp0MZ/wu8q/h LWcw==
X-Gm-Message-State: APjAAAVHUJMliAjc/Skb0cM06+stIoEst/bdBG6nrNR0Mr69VNy4x4/9 bzVz6NpwrpgYP4jCDVIHNm2jFHVN6yR2Kw==
X-Google-Smtp-Source: APXvYqxhHr97aQxmWmaVr7k4JWCkCVxKhw0uYpvFYQMGAfKFE0xUY4SAchMA6mnRf2Kf9UvrXlM3zg==
X-Received: by 2002:a05:660c:48b:: with SMTP id a11mr52111itk.11.1559160408275;  Wed, 29 May 2019 13:06:48 -0700 (PDT)
Received: from mail-it1-f176.google.com (mail-it1-f176.google.com. [209.85.166.176]) by smtp.gmail.com with ESMTPSA id p63sm144403iof.45.2019.05.29.13.06.47 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 13:06:47 -0700 (PDT)
Received: by mail-it1-f176.google.com with SMTP id i63so1372010ita.3 for ; Wed, 29 May 2019 13:06:47 -0700 (PDT)
X-Received: by 2002:a24:7b11:: with SMTP id q17mr43101itc.49.1559160407525; Wed, 29 May 2019 13:06:47 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 29 May 2019 16:06:35 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000003d115b058a0c5277"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 29 May 2019 20:06:51 -0000

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

I would like to discuss OAuth for browser based apps. I will be publishing
a new version in advance of the meeting.

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

Aaron Parecki



On Mon, May 27, 2019 at 5:04 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to discuss
> in Montreal.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk 

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


I would like to discuss OAuth for browser based apps=
. I will be publishing a new version in advance of the meeting.
=


Aaron Parecki

=


On Mon, May 27, 2019 at 5:04 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Pl=
ease, let us know if you have any topics that you would like to discuss in =
Montreal.

Regards,
=C2=A0Rifaat & Ha=
nnes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
----
Aaron Parecki
<=
div>aaronparecki.com<=
/a>



--0000000000003d115b058a0c5277--


From nobody Wed May 29 15:35: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 BC2A0120125 for ; Wed, 29 May 2019 15:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIaZwklCWF7m for ; Wed, 29 May 2019 15:35:40 -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 A4BF612000F for ; Wed, 29 May 2019 15:35:39 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id m22so3901773ljc.3 for ; Wed, 29 May 2019 15:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dSRRSowp3WA9eYHCqfuxfhK7AtRO5wyEu9t40REBTnQ=; b=YdGoyBLJ8XKyTuZQtby7rX5BcVBvjbtFGy7gkkZ8/r6XfzAjBVkOnPjLfUK90RtBjY UwITy4eaiwo2r9xhn4LZ0oHjW/MxZEcG0g27efkZp/nvjxYeXL/XsuIt6482qFwEZAc/ nCgsHp7HP2vi28hi98JCf82LiaTOc5hc+YecbQZ55aVgean6lKm9yRIEnqGbu1hL4lf9 ezr7oqPcReJ8cyaYYnpKJs9z1Tr+91bDJeJUvhsEwTl1Bt1yK0qMJqB6V16L+9PzE3JN ps/12DrGxd/JXydpqjfANb/RaY3PlZmja5WdfZkXI1QWPSctvO/4iQdrZXF0P5I1S5Yo yJVQ==
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=dSRRSowp3WA9eYHCqfuxfhK7AtRO5wyEu9t40REBTnQ=; b=pcPg5DLAlqs0RHdIh9BocVRhI0W0x8sKIgQsSeRrLI4m61xRWQC066MjKJvX5jo9mK mgKHScgpU0UkAw5t33se7XoOND8Y5k2jii422GePCyPyN5gNjOAbcA5T2J1AR0AeYhqJ MeZevtY0B1W+K+3fhLR9sUlyr+KYsf3fYuo61vSsr60B+tbEwBwwmZ/lYWxijGEM10EQ u6lxJ3pkl5uQjgMmxtRQV6Zj37+lE20HOdGiYaJO/C93riLTUvZ+jiSO7lz4i+9/5nDv 2F9y68Zfn3zoUUyOQg+b7KpqXA+8Vs5OLCZN/Itj5/bGyVK6RHXfGUK1L4p0H1su6vvg 0GGg==
X-Gm-Message-State: APjAAAX+XbXWmnIqYKlGJCK13wdJX7eL2wZqNS9+/wUELwVHi0snOjiJ oH1Z3bq76gjwvr85k/uTLMI0o4FlhR7NWo2pDVqTNw==
X-Google-Smtp-Source: APXvYqw7u5jCcDQz3SNq9XgjFBO0xx/yFXgvAVo7FCDSrl/fRLHgyof7biYJXES6UO4pqA6vUwwzs4nY5xjyFbHwF7c=
X-Received: by 2002:a2e:9ed6:: with SMTP id h22mr158164ljk.29.1559169337564; Wed, 29 May 2019 15:35:37 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Vittorio Bertocci 
Date: Wed, 29 May 2019 15:35:27 -0700
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000082b71b058a0e661a"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 29 May 2019 22:35:42 -0000

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

I will publish an update of the JWT profile for ATs by then. If there is a
slot available, I would love to discuss it. I will attend in person this
time.

On Mon, May 27, 2019 at 2:04 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to discuss
> in Montreal.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I will publish an update of the JWT profile for ATs by the=
n. If there is a slot available, I would love to discuss it. I will attend =
in person this time.

On Mon, May 27, 2019 at 2:04 PM Rifaat Shekh-Yusef <=
rifaat.ietf@gmail.com> wrot=
e:
All,

Please, let us know if you have any topics that=
 you would like to discuss in Montreal.

Regards,
=C2=A0Rifaat & Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000082b71b058a0e661a--


From nobody Thu May 30 11:52: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 5826712016D for ; Thu, 30 May 2019 11:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e4vcQSQ1lu6t for ; Thu, 30 May 2019 11:52:22 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E343C12016E for ; Thu, 30 May 2019 11:52:19 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id g21so2937947plq.0 for ; Thu, 30 May 2019 11:52:19 -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=PvPcSPXAstMrjwRcPJPjEj2MmiRcCYeWHnMPS/ZViyo=; b=Y4LRzMI5gGL4CmlajQIcCOYfyX6iXYm/JdP4qRpzPYcytZV9Qhu6PMzT0YJI9jEbV2 wg0Wb04DvBxL+EE4vzpjO9eNiqWzS3MPb1JE4gxwHecUqek1YSaCrQqBb1YkXFlIVaB2 OlhyJI6gaY8644O4nGs25lLJ5y420bddc99Xc/c7CsxOFVrhNYwkL/RAHS/XfU5O6uGO wcDDL38X6eXZZFzEfashjLcI64yYL4Tycd8GLKXVy2QalSS6Mw2qO8dqwYHocFWRAZCs JiQM0Y9tsaBHivIuZezEcnJVUv2USmxzZABe9OCtqqbHWXZDnGJvHJiF5b8lO+zgCtYI 1XwQ==
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=PvPcSPXAstMrjwRcPJPjEj2MmiRcCYeWHnMPS/ZViyo=; b=jfY5+lP++EeUFyYXWVr0ZTIK2d5KYb1zsjaFiFhzXXfva+Ub15wR5pQ3w1TqRzFEyP c6nt48hY6GSWK2JuoLGll+XpPTDD9yE7TrgMoSI5CnCH5ThqGj6e84/62EIAeFyY9M5b BRdcWDUQ1Ji5QdfjnOBEWcQN4c2tZh8AYN4AeMhqwkfmKI7aF1AqgGG09roRRXUv32VN aL3ppUYjQHXXJiuszaQxwlur1d2dg9itMEgPeM6794zFdGYHLqkNEvfWjTki8EUGAhTN aXjjGhATrVuAugItaQzg/boylq4XPkXQLom1uwAVXCPR17+xX8TY9NQJOUZiRbeYpVkI 4uZg==
X-Gm-Message-State: APjAAAXpIYCUWm+sxocfyf8a5BJYhq58pOGsHTrmQTWITKc1zYXC5BcJ AAODTjsCPeJC3PPkq33sNt34GIqmFt3r+1jsbEk=
X-Google-Smtp-Source: APXvYqxFbKhPcQoJZtYOX8TMgm3r/eGp0PFXWoK0wn84VfiN/psxdi5RMsKwMq0Sdd1zo5+4Ivz460kN0sw+4EKbyhs=
X-Received: by 2002:a17:902:e409:: with SMTP id ci9mr5072232plb.103.1559242339049;  Thu, 30 May 2019 11:52:19 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 30 May 2019 11:52:07 -0700
Message-ID: 
To: Vittorio Bertocci 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="000000000000bceb3a058a1f65c1"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG Sessions in Montreal
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, 30 May 2019 18:52:24 -0000

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

I will update the Reciprocal OAuth draft and provide an update. I will be
there in person.

On Wed, May 29, 2019 at 3:35 PM Vittorio Bertocci  wrote:

> I will publish an update of the JWT profile for ATs by then. If there is a
> slot available, I would love to discuss it. I will attend in person this
> time.
>
> On Mon, May 27, 2019 at 2:04 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> Please, let us know if you have any topics that you would like to discuss
>> in Montreal.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I will update the Reciprocal OAuth draft and provide an up=
date. I will be there in person.

On Wed, May 29, 2019 at 3:35 PM Vittorio Be=
rtocci <Vittorio=3D40auth0=
.com@dmarc.ietf.org> wrote:
I will publish an update of the JWT pro=
file for ATs by then. If there is a slot available, I would love to discuss=
 it. I will attend in person this time.

On Mon, May 27, 2019 at 2:04 PM Rifa=
at Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Please, let us know if you=
 have any topics that you would like to discuss in Montreal.

=

Regards,
=C2=A0Rifaat & Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000bceb3a058a1f65c1--


From nobody Fri May 31 05:25: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 3BFDD1200B2 for ; Fri, 31 May 2019 05:25:19 -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 IQbMJQz7sOps for ; Fri, 31 May 2019 05:25:17 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 742E41200A1 for ; Fri, 31 May 2019 05:25:17 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id m141so15367173ita.3 for ; Fri, 31 May 2019 05:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=H2KX//2gyK4ShLy2mU9yBN0HXt4GaukEm9WHbFE7/7Q=; b=aF5dax8bwHHvE+j4PozL5l64WTOxtthLJ1diafboztshDH93/Cz/M0xD/LMgct5om+ WURxHUGO9VCE5SQ9qamMF7cslPBrHd/CtFXIYwGgt1dysmANp/GHPlgyvUDBC0GQiuM2 fMpJ80MEqPEfcCQ6uDtSqpCWgnSx+XLUv6WNukwq1XGNTwAo3c4x4Vwubu7UP731gwYL T61c4bqEnQ/76X/NhsbcdayDrTcJ/A/A8LJjhLVHk7lkHmjw39hTSr3oQy15JDkMHmop FYxznCJylv/+UHG1Iw2WougBrWxzsSd7wybf4BvfDwshoMluDFuwHWyrV1KMsL6MDZSw cCkQ==
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=H2KX//2gyK4ShLy2mU9yBN0HXt4GaukEm9WHbFE7/7Q=; b=HFvIUJ8Gk684G0GSGhUIitdyAjnNBGhLkSVUQWLmyl3PCA2WwSStJmTUaAIqzAYWUE VT69CCdGquR2Mud4SCMahEc3490IocMm6Uu5pralUZm4SMy3oi+X+7mZdoFlECzaWeAK moETQKlzvmq9GAAbCWPVnUMZFwybrzxxx6a9HrxHMK8ROuszdeq0kLAXR4jzKAO3gFq7 2EUpImHZqkSmfHiQYkGKVJYwF+mQDcO/1I465XUziyuqn4RioPyM+6EKashtO0i7BA9I cqaNYEcB4WLY1XRFqrkXZ5uPqF9askc/kgctNPbPSNybxE+crSNP7BlAssnA73/Zqbgk QD8g==
X-Gm-Message-State: APjAAAXQxR9Hu5IBoooJpPisv32neZZCJlJYcoTQnTMdmdbQJRsTEtF6 7mVCh02eZhIPW8Y5yj82Fj2oOqyrIa0KXiP7hJg=
X-Google-Smtp-Source: APXvYqxvwwOTXUdfDUUE0aVrvpxXSGfdJCql5ZBZU6olzqlqmdJGRTmniIYQ7LuDXTHLkPvYFXVh/THfJQs100H4dFg=
X-Received: by 2002:a24:7b8f:: with SMTP id q137mr6483977itc.21.1559305516761;  Fri, 31 May 2019 05:25:16 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Fri, 31 May 2019 08:25:05 -0400
Message-ID: 
To: Torsten Lodderstedt , Vladimir Dzhuvinov , oauth 
Content-Type: multipart/alternative; boundary="0000000000006c47e6058a2e1bf3"
Archived-At: 
Subject: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
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, 31 May 2019 12:25:19 -0000

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

Torsten and Vladimir,

As part of the shepherd write-up for the *JWT Response for OAuth Token
Introspection* document, we need an IPR disclosure from you.

Are you aware of any IPRs related to this document?
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

Regards,
 Rifaat

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


Torsten and Vladimir,

As part of the shepherd write-up for =
the JWT Response for OAuth Token Introspection document, we need an =
IPR disclosure from you.

Are you aware of any IPRs related to this=
 document?

Regards,=

=
=C2=A0Rifaat


--0000000000006c47e6058a2e1bf3--


From nobody Fri May 31 09:44: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 DBE8E1202D5 for ; Fri, 31 May 2019 09:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu95_4jeafyP for ; Fri, 31 May 2019 09:44:38 -0700 (PDT)
Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (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 7FDD91202D6 for ; Fri, 31 May 2019 09:44:23 -0700 (PDT)
Received: from [192.168.88.6] ([83.34.74.227]) by :SMTPAUTH: with ESMTPSA id Wkdghws3GTLVJWkdhh9uXv; Fri, 31 May 2019 09:44:23 -0700
To: Rifaat Shekh-Yusef , Torsten Lodderstedt , oauth 
References: 
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <7f266037-182b-a525-9970-8ced9ce68515@connect2id.com>
Date: Fri, 31 May 2019 19:44:19 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000203080801020002000100"
X-CMAE-Envelope: MS4wfM9XW9OMBWUb8Wr3Mb+WNvA9kwv81vdzngASuyl4AuqMKSZJc04cFeoDWJ/jLZhxNEBVwCivZAutY0/pY9lqcelhnMPMZUoE8NBYMnS4ANfPe6JtQllH nOEA8CIprIQSIsjvkf7JqE0yi4YAUkO7KV76lOSuTDF1W+UmLqGchNOvK9UHuN8QijsP0VqQkmTWTPK4hK9fOun+Rsy92aQvDTFuwrMGyceIplvJvmlcMoLH
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
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, 31 May 2019 16:44:41 -0000

This is a cryptographically signed message in MIME format.

--------------ms000203080801020002000100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hello Rifaat,

On 31/05/2019 15:25, Rifaat Shekh-Yusef wrote:
> Torsten and Vladimir,
>
> As part of the shepherd write-up for the *JWT Response for OAuth Token
> Introspection* document, we need an IPR disclosure from you.
>
> Are you aware of any IPRs related to this document?
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-res=
ponse/
No, I'm not aware of any existing IPRs that may pertain to this spec.
> Regards,
>  Rifaat
Vladimir

--=20
Vladimir Dzhuvinov



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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
C0owggUyMIIEGqADAgECAhEA/VhMPWMqpC6zn4TfMJuPczANBgkqhkiG9w0BAQsFADCBljEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTA1MDkwMDAw
MDBaFw0xOTA2MDgyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3ZsYWRpbWlyQGNvbm5lY3Qy
aWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs2m8UNRxE59seMUDgBKL
SqUFWthspN6xYqSPo250LGHylEQr1HMxRFdkc13DaevaqYmoA/RZbkU5AXmSsf0l7+RclrAV
3454MD6QjThZ+R+66ABcIhrUtIapObk9wKiQE1dqapcwLJcdBeSoEm5WBKhAdS42j13VomAZ
gJ4YRf4//kTkQvpNQ5nH2hbcnLOepe/3VknRmYcFg+pNUEUHivAZrz+IFhtESgthnSKU9pB0
mILJM3eEd5gO5ga3iZUjAeRSqDOMkNFUzADjrtRgOZYxQn/J4v12KIPn6vgsJsC3Mh5cAqPV
wmwme4LETa9SN2UTt4GkXUygLMMMXAA8KQIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy
/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFEtKuAAihkgPLmCpJNBiqV5WTu4+MA4GA1Ud
DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx
AQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAj
BggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJ
aHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25h
bmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRw
Oi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAi
BgNVHREEGzAZgRd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEA
uxlVzkBXm5Ju2Vrl9T3xHW7N/1hwI1ZbRty94V3OzmcPcIWYuvjVuF1ztmRApA35AU1DIlGY
ItXv4fw9j9uKUw4AwY3VFK6sSzgUjGYRalaM3mHdQ/dck+edhltccY7Zh3mL3S951eQL4E2d
MX2uPTh3sRrmfJBUvZMdngrVJ9ylEaJlXgdpzAdliqt4cOUUEgdn6iCAY7ER8p3qmPmGh57g
N5zRQH+4ldvjoeKlMBIboKp76CmbXDffeoD59PuNvh4sPO/2MuonPJb1t7+ZRDURE3kK9UxI
Axfjx2m7hzY7HdW224qGddA1BqyfoLdeVll4ehgkoiepamz13JH5zDCCBhAwggP4oAMCAQIC
EE2ULBDUO+CUCcWBLTorBk8wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVT
RVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMwMTIzMTIzNTk1OVowgZYxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAW
BgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkqKtLNnFCBP22ULvOX
qGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfbM3wccaNDZvZe
/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+LbnTeef8h
Nfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmHfpsE
kzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQU
CcDy/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQ
BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNB
Q2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAC
hjNodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQAD
ggIBAEFEdQCrOcIV9d6OlW0ycWiMAN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklC
szzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vhNn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxp
wi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHitcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRr
ZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDpVRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6
hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7T2wwC+IzXVDQO4xnnvrQJ07ZWemx
c/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI9oKSChwGDQQFixtkNnxuwbdr
TwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RIZllX4dH8mHqsRpU8NEX8
IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDonM8V/2kuQAUVazVA3
I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQz3lCNObL6sNa
OQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIENTCCBDECAQEwgawwgZYxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9WEw9YyqkLrOfhN8wm49z
MA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xOTA1MzExNjQ0MTlaMC8GCSqGSIb3DQEJBDEiBCDim7hTEfUJg2gxyxbirXBM
MrsKf0BT77EloL51MbiN4TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB
ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNV
BAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9WEw9YyqkLrOfhN8wm49zMIG/Bgsq
hkiG9w0BCRACCzGBr6CBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w
PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF
bWFpbCBDQQIRAP1YTD1jKqQus5+E3zCbj3MwDQYJKoZIhvcNAQEBBQAEggEAhz55Xj62oBIY
FfnpKBpbZmMbzNLB0KKUoaS94k8gJS9w/BSWlmHsVc5cNvYgJKfxklSakiovqIgrXcyZj+zn
oHQuphFCHfIXuM714Mu59iRpEEA0jLX4r5jnSfW3//n9xqondKW1jB29uA/uMXk3hC6FldQu
VusdiwIMCInpYUjoP3tC/wvE+pq711ZGBsivKnFXFfxLjeXbIdGDJUE19VF+IOyHcX5tymcg
bqlam4WLa3Z9SkbsQjJtAmYEK5tkFFY6qdRBmh0F6mqaao0L0fvRl+k/HbeSiHHmHwBOTbOw
0XYICs7gXcKYYw+YUrLbGfDsNCGBjoF2IzCzKn6tEgAAAAAAAA==
--------------ms000203080801020002000100--


From nobody Fri May 31 11:47:29 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 1981112035F for ; Fri, 31 May 2019 11:47: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, 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=aol.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 u9Yv7lXPjwO7 for ; Fri, 31 May 2019 11:47:25 -0700 (PDT)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 A7F55120319 for ; Fri, 31 May 2019 11:47:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1559328444; bh=XMxV7xgl1LvvMVtdum22+NpNfIXWzS0nF2YNxE3ooEY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=liRxSFyiojY+6rVPqIl93GjkPVXbHsppno5CqjyH1ynSIK+1XUawynWRgxrhLeHTy/kUKxRaYksLigY5WXsVAptlJBN3hj05RwF+LBxoO6oyhcL3TqMnd6un6+OUGX2x7aijp7Ub3OInRu/6W9tURhnewBEXCmaWqRQyepKXH9NN2r+++V91SXN/hk8W2V0POXNklzc9a+ElvBC21rR46Y9+Cih48lfq27OKToIug0m5FhT8QvPctf/akU+3ebU5w6ywcv7p71cebV9R0D583m5b4IJuSIQENFgLMHxtyfho2AOXHwvmdtxpEk5s4DjLixZtZVOL/ZZkVrfc35ZY9g==
X-YMail-OSG: KK4hqYsVM1kDrkachcD84vDbmL6Vj2m1p1srqUZPSEWxLHFJdLJEYA7Dt5PUlbt zPWQXoPqxgGZsblY4cVsGEmuhiiU4TK3mE6mNuPpIkaZ6ksPxk6nVdiaeRIT0FHUscvkOXpCv6K7 ISvAc1t2JQYNFji8LPVDCDxMOkPKbHkqiaf494_1Y5PnojGC9_jfuTrpNfZdQ5P6KPJt2.nGoWDy X7nySvF0pEFrb9.LX90GCHflutqoMPT0Bj01TW.CYleHD..cCkvSWUcVqrJTWyUlTC54kWfOGVQm bhklgE7dJ.n234oC9bJG77KxPfJfT2qoEPvUSf._qOIJFdiYD3QhvO51_8nfgDCzc_PgVBQVjoom 7xAoe8r8qIQ4i0WGeek7MRcXD6fuO91fvnUCuyKTs4cpqf7tc1ZSPOXKoZAj8B6uBmwgRXYUys0q ZUBzXswMVXjgMd5IC8QQwLC9_aspPLiQvDMzD5tJgpYfmIOERA0rjzbG7vzjmPAo7Tku1YB7fK0i kN58EBDoQNx7XaoNmvYHFr00Mo3H6BnJXRshk0b2RGQUaAJR01zufiJwBcnQSNvumU2Wioh1exNo 1Z88L6RkHKHE4dT05XEXkECt.1rglC7mcRuR1yWGojFCQ5DeA589DxFmwJwBnFSItQNOhizlKs_Y .jqenmWcAidpuqapJNF4co5gksZaMhDNmO6zqAzghaJGYw5Q1EVgoJqwZq7za3d5_xrKnpLMfRoi SH.AyOqTlqtgpBVKnCsoYJMMBAfvJZekrnbVGnDmj74n3H_l28GPgOhHZM6i7x33sgqisnJcGzZV kdTfuG4mPkbtq42MqlJBctj698FA4u5EdMzkwM5pLE6uiiPFKhv.j0FHBJ99Va9fmeIb9JEAq.jF PMLknHhPu.lV9DVEs0I_NPjcLU6Nqeon65pV42ueTAp42mtWzCFJvPgu76GYgaq4FWJ48qPi_cwf bDYwQDCqImOz4nfd_mvqrORMy2GBTiRthINogTJdLDcp7IBBvc1EiSebIRMLCnrJz7LvPBtbMdbL MFDgJc2M.M8JPNcYiSoCZRHk1cF_XsBpFIuT9QvAzw5TiPhuNGVW2o8ljdo2VqYxxG_iwOKypdiZ C.JjcZHvzzq1JB0CMNGm.nb0bXqkxfiOFzzf3VOM5Q86gL7Kom58jEO0lTWPcuwATWrR2.p3v4BL s7JYLCVCh.L2XaSEVvtrsPj8MeA8tpujssDhkXz4DGesAHyS0nc7.Buqkkw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 31 May 2019 18:47:24 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2d02ef1f147b4cc69698da797da5cf89;  Fri, 31 May 2019 18:47:21 +0000 (UTC)
To: Dave Tonge , oauth 
References: 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Fri, 31 May 2019 14:47:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F1A984C16153F7F2B07927A3"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 May 2019 18:47:28 -0000

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

So if by "other endpoints" we mean "other endpoints at the AS" then I 
think issuer makes a lot of sense and could be recommended value.

However, if the client assertion is being sent to an endpoint not 
managed by the AS, then it should use a value that identifies that 
"audience". In this case, something more akin to the "resource 
identifier" of the endpoint is probably best. Abeit, that is still a 
very fuzzy definition :)

On 5/28/19 11:28 AM, Dave Tonge wrote:
> Dear OAuth WG
>
> We have an issue that we are discussing in the OIDF MODRNA work group 
> relating to the Client Initiated Back Authentication spec (which is an 
> OAuth 2 extension). As the issue affects the wider OAuth ecosystem we 
> wanted to post it here and gain feedback from the OAuth Working Group.
>
> Full details of the issue are here: 
> https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including 
> a helpful context setting by Brian), but the summary is:
>
> *What audience value should a Client use when using a client assertion 
> (RFC7521) to authenticate at an endpoint other than the token endpoint?*
> *
> *
> The three options we have are:
> 1. the token endpoint (as RFC7521 says)
> 2. the endpoint the assertion is being sent to (e.g. revocation, 
> backchannel)
> 3. the issuer
>
> We are leaning towards requiring the Authorization Server to accept 
> any of the above values, but recommending that the Client use the 
> issuer value.
>
> The reasons for this are:
> 1. All of the above values are arguably valid, so in the interest of 
> interoperability the AS should accept them all.
> 2. We see no clear security benefit to requiring the audience to be 
> the value of the endpoint the assertion is being sent to, and 
> therefore think that the issuer value is the one we should recommend 
> that clients use.
>
> We would be grateful for your feedback on this issue and believe it 
> would be in the best interest of the ecosystem for there to be a 
> consistent approach to this across OAuth 2 extensions and profiles.
>
> Thanks
>
> Dave Tonge
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    So if by "other endpoints"
      we mean "other endpoints at the AS" then I think issuer makes a
      lot of sense and could be recommended value.

      

      However, if the client assertion is being sent to an endpoint not
      managed by the AS, then it should use a value that identifies that
      "audience". In this case, something more akin to the "resource
      identifier" of the endpoint is probably best. Abeit, that is still
      a very fuzzy definition :)

    

    
On 5/28/19 11:28 AM, Dave Tonge wrote:

    

    

      
      

        
Dear OAuth WG

        


        

        
We have an issue that we are discussing in the
          OIDF MODRNA work group relating to the Client Initiated Back
          Authentication spec (which is an OAuth 2 extension). As the
          issue affects the wider OAuth ecosystem we wanted to post it
          here and gain feedback from the OAuth Working Group.

        


        

        
Full details of the issue are here:??https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including
          a helpful context setting by Brian), but the summary is:

        


        

        
What audience value should a Client use when
            using a client assertion (RFC7521) to authenticate at an
            endpoint other than the token endpoint?

        


          

        
The three options we have are:

        
1.??the token
            endpoint (as RFC7521 says)

        2. the endpoint the assertion is being sent to
          (e.g. revocation, backchannel)

        3. the issuer
        


        

        

          
We are leaning towards requiring the
            Authorization Server to accept any of the above values, but
            recommending that the Client use the issuer value.

          


          

          
The reasons for this are:

          
1. All of the above values are arguably
            valid, so in the interest of interoperability the AS should
            accept them all.

          
2. We see no clear security benefit to
            requiring the audience to be the value of the endpoint the
            assertion is being sent to, and therefore think that the
            issuer value is the one we should recommend that clients
            use.??

          


          

          
We would be grateful for your feedback
            on this issue and believe it would be in the best interest
            of the ecosystem for there to be a consistent approach to
            this across OAuth 2 extensions and profiles.

          


          

          
Thanks

        

        


        

        
Dave Tonge

        


        

      

      

      

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


    

    

  


--------------F1A984C16153F7F2B07927A3--


From nobody Fri May 31 12:29: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 7FCA212010D for ; Fri, 31 May 2019 12:29:18 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2RlNzAEOn8B for ; Fri, 31 May 2019 12:29:16 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5169E1200FA for ; Fri, 31 May 2019 12:29:16 -0700 (PDT)
Received: from [80.187.98.201] (helo=[10.47.129.184]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hWnDC-0005zp-DP; Fri, 31 May 2019 21:29:12 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-E7B2A8DD-9D58-4AA9-AF3A-36CFB432E6BE; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: 
Date: Fri, 31 May 2019 21:27:12 +0200
Cc: Vladimir Dzhuvinov , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <4EED26DA-175B-40DF-9147-A9B644AAF37E@lodderstedt.net>
References: 
To: Rifaat Shekh-Yusef 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
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, 31 May 2019 19:29:19 -0000

--Apple-Mail-E7B2A8DD-9D58-4AA9-AF3A-36CFB432E6BE
Content-Type: multipart/alternative;
	boundary=Apple-Mail-08A870FE-7C2F-4117-9862-BA03B58F4A12
Content-Transfer-Encoding: 7bit


--Apple-Mail-08A870FE-7C2F-4117-9862-BA03B58F4A12
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Rifaat,

I=E2=80=99m not aware of any IPR regarding https://datatracker.ietf.org/doc/=
draft-ietf-oauth-jwt-introspection-response/.

kind regards,
Torsten.

> Am 31.05.2019 um 14:25 schrieb Rifaat Shekh-Yusef :=

>=20
> Torsten and Vladimir,
>=20
> As part of the shepherd write-up for the JWT Response for OAuth Token Intr=
ospection document, we need an IPR disclosure from you.
>=20
> Are you aware of any IPRs related to this document?
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon=
se/
>=20
> Regards,
>  Rifaat

--Apple-Mail-08A870FE-7C2F-4117-9862-BA03B58F4A12
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Rif=
aat,


kind regards,
To=
rsten.

Am 31.05.2019 um 14:25 schrieb Rifaa=
t Shekh-Yusef <rifaat.ietf@gmail=
.com>:

=
Torsten and Vladimir,

As part of the shepherd write-up for the JWT=
 Response for OAuth Token Introspection document, we need an IPR disclos=
ure from you.

Are you aware of any IPRs related to this document?

Regards,
 Rifaat


=

--Apple-Mail-08A870FE-7C2F-4117-9862-BA03B58F4A12--

--Apple-Mail-E7B2A8DD-9D58-4AA9-AF3A-36CFB432E6BE
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
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
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTMxMTkyNzEyWjAvBgkqhkiG9w0BCQQxIgQg
qbPKrFb2EY4T6i66G3xYYJsu+r0eEIXGsNu4tci5zTMwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAFEtyQvp9WTQeUYj
kCNKUtvz2lNW0rL/Vx1k8j50gITonDLoP2pXxNb8P57n+9rFUyxItNjDH8e0vuzfc/yBW/bt9Afn
yApnyslzOGlRRDN2ej3PAfaml99aCAl2SmsUIznjCJlGsGJpB2bCFlQQPbhsofqAM6hEDQxGdoC0
b2P3e6q6eEr+MI6bN5dqdViXjeDX0871rFeQEiXfaV50Os5/BHV9q0Fj7IeJdbx+vEeT0JsgS53W
1WvqGhgCPSR9p4mDH2yOexOXQILi8YfKl6qzyQxLI5Cqq7bRHBKOF6hKVboP/e3GQvbTIiM3GOB1
wAj+G4cyLLKo75xWd9fitdEAAAAAAAA=

--Apple-Mail-E7B2A8DD-9D58-4AA9-AF3A-36CFB432E6BE--


From nobody Fri May 31 12:55:06 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 AD5F61200EA for ; Fri, 31 May 2019 12:55:04 -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 (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 1OxxNg9Sw-QD for ; Fri, 31 May 2019 12:55:02 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB45B120046 for ; Fri, 31 May 2019 12:55:01 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id m3so17797225itl.1 for ; Fri, 31 May 2019 12:55:01 -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=SYHp3cwEq7WW/fCnUs2EYObcfwIVostidszosbavUks=; b=UlQAsnWirHHXIioEXJ/msBRCzED/rh09ii/ZknnjLuIj6xJSnwv5tIDV7GQkdpezG/ oYS+AbK7m1Xv9ImfJT1cA+z8ZFOUQdJqkKIM+HceKb1W5PzBfpzfFJF1siDBvZS0bfLl lftWu0eY3rmZSe9eZVeag+XcVMch/JB/fE/GI=
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=SYHp3cwEq7WW/fCnUs2EYObcfwIVostidszosbavUks=; b=rVO2HT5O4e9KMVA6cz4+LEbrL2uEu3+N1SnO2DhSHKr1eRbhwbF866j2g1/WHf8ueS +Iaik90XcYT+eGVexz77xHXh6FIVwBzGUfz2CqVnDzCpAvM4SxgAEE8nfyra1F0o75/f Dmrpvuv8H44TMVuyloGoEmVgWxTmwHR15dDN65W5OeG/mF1hDIEpMT2PEtsWM2aaxTBP yJ9mGZrWFedzabVwJY6W7WoXTLHkJ+jxGy5s5sSzuKNM3lGtDEu2uCYkQIoIw1MbQbmK R9Xfiv283ruQpbhvjYuzZSIOmRooTr78ROd2VJxf+Da39OUEaFJANzEXl1Lnsa8oX4Oq nu9A==
X-Gm-Message-State: APjAAAWShNewik6z574Fj2GgTpUFcXxhdFJ26F/XIxauN/iYcXj1Tf4g Ro0DtYKEtHgvdIrsTR9/Oc7QIguI2J3BUdCo9q7HuujIme9RYTw/JRNdld3R/KpDi2rJTNREq1S JbVVWCP+20HeAEQ==
X-Google-Smtp-Source: APXvYqzSdsLFLflKFA1wDbs1WmtjyqytHybuQ+DHx4qjH8hxKtu1voXSq4DvpLJHQZJZBWhVON/bXeYMw4eYkjCmJW0=
X-Received: by 2002:a24:378b:: with SMTP id r133mr7980427itr.154.1559332501068;  Fri, 31 May 2019 12:55:01 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 31 May 2019 13:54:34 -0600
Message-ID: 
To: George Fletcher 
Cc: Dave Tonge , oauth 
Content-Type: multipart/alternative; boundary="000000000000d043ab058a34630c"
Archived-At: 
Subject: Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 May 2019 19:55:05 -0000

--000000000000d043ab058a34630c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah, the discussion was/is definitely about "other endpoints at the AS"
like revocation, introspection, device authorization, etc.

On Fri, May 31, 2019 at 12:47 PM George Fletcher  wrote:

> So if by "other endpoints" we mean "other endpoints at the AS" then I
> think issuer makes a lot of sense and could be recommended value.
>
> However, if the client assertion is being sent to an endpoint not managed
> by the AS, then it should use a value that identifies that "audience". In
> this case, something more akin to the "resource identifier" of the endpoi=
nt
> is probably best. Abeit, that is still a very fuzzy definition :)
>
> On 5/28/19 11:28 AM, Dave Tonge wrote:
>
> Dear OAuth WG
>
> We have an issue that we are discussing in the OIDF MODRNA work group
> relating to the Client Initiated Back Authentication spec (which is an
> OAuth 2 extension). As the issue affects the wider OAuth ecosystem we
> wanted to post it here and gain feedback from the OAuth Working Group.
>
> Full details of the issue are here:??
> https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_asser=
tion-passed-to??(including
> a helpful context setting by Brian), but the summary is:
>
> *What audience value should a Client use when using a client assertion
> (RFC7521) to authenticate at an endpoint other than the token endpoint?*
>
> The three options we have are:
> 1.??the token endpoint (as RFC7521 says)
> 2. the endpoint the assertion is being sent to (e.g. revocation,
> backchannel)
> 3. the issuer
>
> We are leaning towards requiring the Authorization Server to accept any o=
f
> the above values, but recommending that the Client use the issuer value.
>
> The reasons for this are:
> 1. All of the above values are arguably valid, so in the interest of
> interoperability the AS should accept them all.
> 2. We see no clear security benefit to requiring the audience to be the
> value of the endpoint the assertion is being sent to, and therefore think
> that the issuer value is the one we should recommend that clients use.??
>
> We would be grateful for your feedback on this issue and believe it would
> be in the best interest of the ecosystem for there to be a consistent
> approach to this across OAuth 2 extensions and profiles.
>
> Thanks
>
> Dave Tonge
>
>
> _______________________________________________
> 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
_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._

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


Yeah, the discussion was/is definitely about "other endpoints at the AS" like r=
evocation, introspection, device authorization, etc. 

<=
div class=3D"gmail_quote">
On Fri, May=
 31, 2019 at 12:47 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

 =20
   =20
 =20
  

    So if by "other endpoi=
nts"
      we mean "other endpoints at the AS" then I think issuer mak=
es a
      lot of sense and could be recommended value.

      

      However, if the client assertion is being sent to an endpoint not
      managed by the AS, then it should use a value that identifies that
      "audience". In this case, something more akin to the "=
resource
      identifier" of the endpoint is probably best. Abeit, that is sti=
ll
      a very fuzzy definition :)

    

    
On 5/28/19 1=
1:28 AM, Dave Tonge wrote:

    

    

     =20
      

        
Dear OAuth WG

        


        

        
We have an issue that we are discussing in the
          OIDF MODRNA work group relating to the Client Initiated Back
          Authentication spec (which is an OAuth 2 extension). As the
          issue affects the wider OAuth ecosystem we wanted to post it
          here and gain feedback from the OAuth Working Group.

        


        

        
Full details of the issue are here:??https://bitbu=
cket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to<=
/a>??(including
          a helpful context setting by Brian), but the summary is:

        


        

        
What audience value should a Client use when
            using a client assertion (RFC7521) to authenticate at an
            endpoint other than the token endpoint?

        


          

        
The three options we have are:

        
1.??the toke=
n
            endpoint (as RFC7521 says)

        2. the endpoint the assertion is being sent to
          (e.g. revocation, backchannel)

        3. the issuer
        


        

        

          
We are leaning towards requiring the
            Authorization Server to accept any of the above values, but
            recommending that the Client use the issuer value.

          


          

          
The reasons for this are:

          
1. All of the above values are argua=
bly
            valid, so in the interest of interoperability the AS should
            accept them all.

          
2. We see no clear security benefit =
to
            requiring the audience to be the value of the endpoint the
            assertion is being sent to, and therefore think that the
            issuer value is the one we should recommend that clients
            use.??

          


          

          
We would be grateful for your feedba=
ck
            on this issue and believe it would be in the best interest
            of the ecosystem for there to be a consistent approach to
            this across OAuth 2 extensions and profiles.

          


          

          
Thanks

        

        


        

        
Dave Tonge

        


        

      

      

      
=


      
____________=
___________________________________
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.
--000000000000d043ab058a34630c--