From nobody Tue Jul 2 13:21:00 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 5B612120708; Tue, 2 Jul 2019 13:20:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2019 13:20:51 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 20:20:52 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. Once this (and some of the more substantive items in the Comment section) is resolved, I'd be happy to ballot Yes. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? Maybe just talking about what an expected use case could be would help alleviate my unease. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When the client does not want to do the crypto. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. How can you "not want to do [the] crypto" but still be doing TLS (with crypto)? Perhaps we're looking for "not want to pay the additional overhead of JWS/JWE cryptography on top of TLS"? Section 1.1 RFC 8174 has updated BCP 14 boilerplate text to use. Section 3 nit: should this section be 2.3 to get wrapped into "terminology"? It might also be worth putting references in for the terms, though they are largely common knowledge at this point. Section 4 A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contains all the OAuth 2.0 [RFC6749] authorization request parameters including extension parameters. The parameters are represented as nit: "all the parameters" kind of sounds like "all that are defined". But I think the intent here is "any parameter used to process the request must come from the request object and URL query parameters are ignored", so maybe "MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request; parameters from other sources MUST NOT be used", akin to what we say down in Sections 5 and 6.3. But we need to be careful about the wording to not exclude the usage of the "request" and "request_uri" query parameters to find the Request Object! the JWT claims. Parameter names and string values MUST be included nit: maybe "the JWT claims of the object"? any extension parameters. This JSON [RFC7159] constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted. nit: I think we want "This JSON [RFC7159] object". (Long quote incoming) The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes extension variables such as "nonce" and "max_age". { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } Signing it with the "RS256" algorithm results in this Request Object value (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw Decoding the base64 of the body, we see: { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null }, "id_token": { "gender": null, "birthdate": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } I'm not sure where the "claims" claim is coming from -- 6749 doesn't seem to talk about it. (Note that this example is used later on as well.) Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED that it be removed after a reasonable timeout unless access control measures are taken. It sounds like a link to https://www.w3.org/TR/capability-urls/ might also be useful. Section 5.2.2 Do we want to remind the reader that the other query parameters are just for backwards compatibility? Section 5.2.3 The following is an example of this fetch process: GET /request.jwt HTTP/1.1 Host: tfp.example.org It's useful to show good hygeine in examples; can we get the extra entropy in this request that we have in the previous example(s)? Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. Does "the pre-registered algorithm" concept exist in the specs outside of draft-ietf-oauth-jwt-bcp? Section 9 The error codes we list in Section 7 are already registered, for the OIDC usage. Do we want to say anything about that? (I guess it would be disallowed by process to try to update the existing registration to also point at this document.) Section 10 We probably also want to reference draft-ietf-oauth-jwt-bcp. Section 10.1 When sending the authorization request object through "request" parameter, it MUST either be signed using JWS [RFC7515] or encrypted using JWE [RFC7516] with then considered appropriate algorithm. Up in Section 5 we only allow (a) signed and (b) signed then encrypted; similarly, in Section 4 we reiterate "signed then encrypted". Why is it okay to talk about just "signed or encrypted" here? Section 10.2 (b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Similarly to the previous point, you also need to check the signature, which will always be there. (d) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. In this I don't think this is a complete sentence (and it's definitely not a parallel construction with (a)-(c)!). I think perhaps a crisp one-line summary of this method would be "Delegating the authorization check to a separate "Request Object to Request Object URI" endpoint on the Authorization Server". (The writing in the rest of this paragraph could also use an editing pass.) (e) A third party, such as a Trust Framework Provider, provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) above apply. In addition, the Authorization Server MUST know out-of-band that the Client utilizes the Trust Framework Operator. The Authorization Server also has to trust the third-party provider to actually do its job and not misbehave, right? Section 10.3 I'm not entirely sure what "[t]he endpoints ithat come into question in this specification" is supposed to mean -- is it just "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"? In [RFC6749], while Redirection URI is included, others are not included in the Authorization Request. As the result, the same applies to Authorization Request Object. nit: included in what? Section 10.4 It's probably also worth citing the generic URI security considerations from RFC 3986, here. Section 10.4.1 "request_uri", and (d) do not perform recursive GET on the "request_uri". nit: remove the "do" in order to make the construction parallel. Section 12.1 It is often hard for the user to find out if the personal data asked for is strictly necessary. A Trust Framework Provider can help the user by examining the Client request and comparing to the proposed processing by the Client and certifying the request. After the certification, the Client, when making an Authorization Request, can submit Authorization Request to the Trust Framework Provider to obtain the Request Object URI. side note: In my head the act of certification was the act of making the translation to a Request Object URI, so I'm kind of curious where my vision differs from reality. The third paragraph seems to mostly just be describing the procedure of how this flow works, which would not necessarily be specific to the privacy considerations section. Section 12.2.2 Even if the protected resource does not include a personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent per-user Request Object URI is used. A third party may observe it through browser nit: need an article for "persistent per-user Request Object URI" (or make it plural, as "URIs are used"). Therefore, per-user Request Object URI should be avoided. nit: I think this is better as "static per-user Requeste Object URIs". Section 13 Are there two different paragraphs for "contributions from the OAuth WG members"? Are they reflecting different types of contribution? From nobody Wed Jul 3 04:19:23 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 7D6E91201F1; Wed, 3 Jul 2019 04:19:21 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156215276143.14658.4306548919501761857@ietfa.amsl.com> Date: Wed, 03 Jul 2019 04:19:21 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 11:19:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-15.txt Pages : 30 Date : 2019-07-03 Abstract: This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 3 04:29: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 3923212021C for ; Wed, 3 Jul 2019 04:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8ExbagP38Sk for ; Wed, 3 Jul 2019 04:29:12 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C3D120778 for ; Wed, 3 Jul 2019 04:29:11 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id i10so3816766iol.13 for ; Wed, 03 Jul 2019 04:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n3Dz5qeyBfMnLBEHPZm8giTKzjT5npZDEBCy3KpvXKM=; b=Ee+KyKlnkrOCbQEAPB8GYqUFJICnNcomMy2GLfET9VOv1Dwsn2Gm0NRBhXx5PVeQ4W B9bm9hXq+Y2ljY64EDfw+IApIDmGAc4irMOpPPuQYfScTyWThy+cmh9T8htwTkM44oXs S7k5h0kMfjwB9ZaTFJ56kve8ymCIDatj1bLLI= 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=n3Dz5qeyBfMnLBEHPZm8giTKzjT5npZDEBCy3KpvXKM=; b=Kqn88/r5Rq5t1rUCox2xGZ9u2IBKhRAvn1mqMB7gS001JSmk5QrobnqmKoiP54z2z7 pvOn99FYU+Gd0qScd9xoGi8fLwq2ojY7VH0lvpbrCNjerApRKkT55UUa6G+qoK6yZj28 98a48utkBocqUTzZJT27xlpGlOTs325+Kqd0OJ8w7vKTUKsE37EZcZKkr/F65bCSZcf4 xZGpRsTE9vr+OkmXlkOVSXEx7FxGZ4n7S9UhW5v7AjPvjGBGn/MLUc6+wUBiwH7C+GEb a/zU4n79hGdxPLc1d+AE62ItoJimWTLW3lTy/1LYRtrjyC0RrEYdCYilBzEA/tZOovyY qyzw== X-Gm-Message-State: APjAAAVBBe7T+G2t/N237cqxgVk2Dmq10nBQ96ln0t3JTcIJFtNAbpuY WZS0xGAWbDp64xjG5KNMFJB+IiO7YGt8mnwvHmjhCZcI2lw2LQx/CY2YklUqJ3HHwZ8l2lBko69 a/WJMXdyMmWfyXQ== X-Google-Smtp-Source: APXvYqzaEFZsal09jM3gmiR8/5QgdW26AiPxZC1V/i4fh2Zfezt1Nc2iaIufT7yEnlLiuTagP+cd/93Ygo087Jgy8ng= X-Received: by 2002:a6b:ce19:: with SMTP id p25mr8752840iob.201.1562153351003; Wed, 03 Jul 2019 04:29:11 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> <359EC4B99E040048A7131E0F4E113AFC01B33A3BFC@marathon> In-Reply-To: From: Brian Campbell Date: Wed, 3 Jul 2019 07:28:44 -0400 Message-ID: To: Roman Danyliw Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009260f8058cc52bde" Archived-At: Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Jul 2019 11:29:15 -0000 --0000000000009260f8058cc52bde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, -15 has been published and incorporates those fixes and suggestions: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-15 On Mon, Jun 24, 2019 at 5:04 PM Brian Campbell wrote: > Thanks Roman, I'll work to incorporate those suggestions into the next > revision before the impending I-D submission cutoff date. > > On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw wrote: > >> Hi Brian! >> >> >> >> My response is inline ... >> >> >> >> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] >> *Sent:* Monday, June 24, 2019 1:17 PM >> *To:* Roman Danyliw >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls >> >> >> >> Thanks for the additional review, Roman. I feel lucky, it's not often on= e >> gets *two* AD reviews :) Please see below for replies inline with a few >> followup questions. >> >> >> >> [Roman] *chuckle* >> >> >> >> On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw wrote: >> >> Hi! >> >> I conducted as second AD review of draft-ietf-oauth-mtls per the AD >> hand-off. I have the following additional feedback: >> >> ** Per ekr's earlier review at >> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing: >> -- Section 2.1.2, How is these metadata parameters being obtained? >> >> >> >> The authorization server can obtain client metadata via the Dynamic >> Client Registration Protocol [RFC7591], which is referenced in the top o= f >> that section. Also the metadata defined by RFC7591, and registered >> extensions to it, implies a general data model for clients that is used = by >> most authorization server implementations even when the Dynamic Client >> Registration Protocol isn't in play. Such implementations typically have >> some sort of user interface available for managing client configuration= . >> >> >> >> Dose that answer your question? Do you believe more should be said in th= e >> document to better explain or clarify that? >> >> >> >> [Roman] It does clear it up. Thanks. I think it=E2=80=99s worth a sho= rt >> statement about how the AS would get the fields. >> >> >> >> >> >> -- Section 3.2, Figure 3. In this example, what new information is the >> auth server providing to the relying party here? >> >> >> >> The new info here (and in Section 3.1 too) is the hash of the client >> certificate to which the access token is bound, which is in the "cnf" >> confirmation method at the bottom as the "x5t#S256" member. >> >> >> >> [Roman] Makes sense. To make the example clearer, I=E2=80=99d call out= this out >> in the prose introducing the example. >> >> >> >> >> ** Section 2.0. What is the expected behavior if the presented >> certificate doesn't match expected client_id? How is this signaled? >> >> >> >> With a normal OAuth 2.0 error response using the "invalid_client" error >> code per https://tools.ietf.org/html/rfc6749#section-5.2 >> >> >> >> Do you think that needs to be stated more explicitly in this document? >> >> >> >> [Roman] Yes, I=E2=80=99d explicit state it with that citation, especiall= y since >> Section 3 discusses of how errors are returned. >> >> >> >> >> ** Section 2.2. Per the sentence "As pre-requisite, the client register= s >> its X.509 certificate ... or a trusted source for its X.509 certificates >> ... with the authorization server. >> -- Editorial: s/As pre-requisite/As a prerequisite/ >> >> >> >> done >> >> >> >> -- What's a "trusted source" in this case? Is that just a jwks_uri? If >> so, maybe s/a trusted source/a reference to a trust source/. If not, ca= n >> you please elaborate. >> >> >> >> Yes, it's just a jwks_uri. I'll change that. >> >> >> >> >> A few editorial nits: >> ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ >> >> >> >> fixed >> >> >> >> >> ** Section 3.1 Cite DER encoding as: >> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: >> Specification of Basic Encoding Rules (BER), Canonical >> Encoding Rules (CER) and Distinguished Encoding Rules >> (DER)", ITU-T Recommendation X.690, 2015. >> >> >> >> will do >> >> >> >> ** Section 5. Typo. s/metatdata/metadata/ >> >> >> >> yup >> >> >> >> >> ** Section 6. Typo. s/The the/The/ >> >> >> >> got it >> >> >> >> >> ** Section 7.2. Typo. s/the the/the/ >> >> >> >> done >> >> >> >> >> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing th= e >> contents of the section. >> >> >> >> will do >> >> >> >> >> The shepherd write-up is in good shape. Thank you. >> >> Regards, >> Roman >> >> >> >> [Roman] Thanks for all of the above. >> >> >> >> Roman >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000009260f8058cc52bde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, -15 has been published and inc= orporates those fixes and suggestions: https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-oauth-mtls-15

On Mon, Jun 24, 2019= at 5:04 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
Thanks Roman, I'll work to incorporate those suggestions into the = next revision before the impending I-D submission cutoff date.
On Mon, = Jun 24, 2019 at 2:14 PM Roman Danyliw <rdd@cert.org> wrote:

Hi Brian!

=C2= =A0

My response is inline ...=

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Monday, June 24, 2019 1:17 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

=C2=A0

Thanks for the additional review, Roman. I feel luck= y, it's not often one gets *two* AD reviews :)=C2=A0 Please see below f= or replies inline with a few followup questions.

=C2=A0

[Roman] *chuckl= e*

=C2=A0

On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw <<= a href=3D"mailto:rdd@cert.org" target=3D"_blank">rdd@cert.org> wrote= :

Hi!

I conducted as second AD review of draft-ietf-oauth-mtls per the AD hand-of= f.=C2=A0 I have the following additional feedback:

** Per ekr's earlier review at https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
-- Section 2.1.2, How is these metadata parameters being obtained?

=C2=A0

The authorization server can obtain client metadata = via the Dynamic Client Registration Protocol [RFC7591], which is referenced= in the top of that section. Also the metadata defined by RFC7591, and regi= stered extensions to it, implies a general data model for clients that is used by most authorization server i= mplementations even when the Dynamic Client Registration Protocol isn't= in play. Such implementations typically have some sort of=C2=A0 user inter= face available for managing client configuration.

=C2=A0

Dose that answer your question? Do you believe more = should be said in the document to better explain or clarify that?

=C2=A0

[Roman]=C2=A0 It does clear it u= p.=C2=A0 Thanks.=C2=A0 I think it=E2=80=99s worth a short statement about h= ow the AS would get the fields.

=C2=A0

=C2=A0

-- Section 3.2, Figure 3.=C2=A0 In this example, wha= t new information is the auth server providing to the relying party here?

=C2=A0

The new info here (and in Section 3.1 too) is the ha= sh of the client certificate to which the access token is bound, which is i= n the "cnf" confirmation method at the bottom as the "x5t#S2= 56" member.

=C2=A0

[Roman]=C2=A0 Makes sense.=C2=A0= To make the example clearer, I=E2=80=99d call out this out in the prose in= troducing the example.

=C2=A0


** Section 2.0.=C2=A0 What is the expected behavior if the presented certif= icate doesn't match expected client_id?=C2=A0 How is this signaled?<= /u>

=C2=A0

With a normal OAuth 2.0 error response using the &qu= ot;invalid_client" error code per https://tools.ietf.org/html/rfc6749#section-5.2

=C2=A0

Do you think that needs to be stated more explicitly= in this document?

=C2=A0

[Roman] Yes, I= =E2=80=99d explicit state it with that citation, especially since Section 3= discusses of how errors are returned.=C2=A0

=C2=A0


** Section 2.2.=C2=A0 Per the sentence "As pre-requisite, the client r= egisters its X.509 certificate ... or a trusted source for its X.509 certif= icates ... with the authorization server.
-- Editorial: s/As pre-requisite/As a prerequisite/

=C2=A0

done

=C2=A0

-- What's a "trusted source" in this c= ase?=C2=A0 Is that just a jwks_uri?=C2=A0 If so, maybe s/a trusted source/a= reference to a trust source/.=C2=A0 If not, can you please elaborate.

=C2=A0

Yes, it's just a jwks_uri. I'll change that.=

=C2=A0


A few editorial nits:
** Section 2.2.2.=C2=A0 Typo.=C2=A0 s/sec 4.7/Section 4.7/

=C2=A0

fixed

=C2=A0


** Section 3.1=C2=A0 Cite DER encoding as:
=C2=A0 =C2=A0 [X690]=C2=A0 =C2=A0 =C2=A0ITU-T, "Information Technology= -- ASN.1 encoding rules:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specification of Basic Enc= oding Rules (BER), Canonical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encoding Rules (CER) and D= istinguished Encoding Rules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (DER)", ITU-T Recomme= ndation X.690, 2015.

=C2=A0

will do

=C2=A0

** Section 5.=C2=A0 Typo. s/metatdata/metadata/

=C2=A0

yup

=C2=A0


** Section 6.=C2=A0 Typo.=C2=A0 s/The the/The/

=C2=A0

got it

=C2=A0


** Section 7.2. Typo.=C2=A0 s/the the/the/

=C2=A0

done

=C2=A0


** Appendix. Cite the figures numbers (#5 - 7) in the text describing the c= ontents of the section.

=C2=A0

will do

=C2=A0


The shepherd write-up is in good shape.=C2=A0 Thank you.

Regards,
Roman

=C2=A0

[Roman] Thanks for all of the ab= ove.

=C2=A0

Roman

=C2=A0


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


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000009260f8058cc52bde-- From nobody Wed Jul 3 07:26: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 9FD2412023D for ; Wed, 3 Jul 2019 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjw5Y9rUh1mG for ; Wed, 3 Jul 2019 07:26:29 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341B3120232 for ; Wed, 3 Jul 2019 07:26:29 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id h21so1258088qtn.13 for ; Wed, 03 Jul 2019 07:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=EBuDMXVuIllUpRjE9FxdIN5sx/GIFE6FigOAC978TAA=; b=WT1l2BuaaAvxzQ9qPO1QXtBJZMvyVqU485LmPZqgq60bxYBpS2Mdu1uBCng4fG5mBG Ram5fNZ2zKZm20Wm+a5wvbDLITK8WAjMuChkeKTZ79jbzydV99CQezFa27Y5PeTkOt7i +7UgRSLwipP511kQD8xBtmn7fSgmBS2MmKYyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EBuDMXVuIllUpRjE9FxdIN5sx/GIFE6FigOAC978TAA=; b=RYcCKRqD1BIG9xaNyjI0zpOnSdFKuKb0XRUQx1A51GJWaoIv1wJmXasZeVi2Z4L9ho RpY2ODpoJhb+C/qAlbgtR+uCtGTUTGi5h48RR2pgClPmhQaSPKWgn+M8acN45yuHxqD8 lEiAheAux/AZUFzs1+dx4kTNc2yCkIvYnuEdIPMjr131sds+9WD4YDxoZ0PnJVMbETvg L6drNIRaVeFweHb8zD9UOuSOaS2ag4M5Nid3lLsN6iyHukWzmJz3pqaGUVD6n0A1pb6d cZ+ulNWwluLNpYuUaQWQHuIFz6BT/pO8Lh72dzMC77x4IDAlwHBNKLCIerxhDjJXKQqQ C0NA== X-Gm-Message-State: APjAAAVwVH/ME1CsPjx20XpKDP2gfi4hVd7E035yKqFLZNbIqGdMhOLe VtrfzpKLZC1CzN75sa3ILi/bzBmAFgwK+xomH6IDCcau X-Google-Smtp-Source: APXvYqza4ZlJbawXxknYxXeebICtCuDs/boPx7jnIaVNABiLixUFd6VJ1IXnXD59M08Ar3P+91igPGPEYjPZ44hHKBM= X-Received: by 2002:ac8:2309:: with SMTP id a9mr29908887qta.103.1562163988009; Wed, 03 Jul 2019 07:26:28 -0700 (PDT) MIME-Version: 1.0 From: Daniel Roesler Date: Wed, 3 Jul 2019 09:25:51 -0500 Message-ID: To: OAUTH-WG Cc: "Donald F. Coffin" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] OAuth 2.0 UI/UX Resources? X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Jul 2019 14:26:31 -0000 Howdy all, Apologies if this is slightly off topic. I'm a part of the Green Button Alliance, the non-profit standards body around sharing energy data, and the customer consent process is based on OAuth 2.0 (e.g. granting access to your smart meter data in order to have an energy audit done). However, most utilities we work with are unfamiliar with OAuth 2.0, so we often have to explain how it works and what the best practices are. There are plenty of resources we can point them to for the actual protocol handshake, but I haven't been able to find any resources around best practices for designing the user interface and experience of OAuth. Unfortunately, in the energy industry, UI/UX design isn't our strong suit, so it would be very helpful if we had design lessons-learned from other industries to use as a reference. Does anyone here know of any resources, talks, blog posts, examples, etc. for making good OAuth 2.0 UI/UX? Thanks! Daniel Roesler From nobody Wed Jul 3 07:51: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 83E9D1203F5 for ; Wed, 3 Jul 2019 07:51:16 -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 knobr0dnvD-e for ; Wed, 3 Jul 2019 07:51:13 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE97D120414 for ; Wed, 3 Jul 2019 07:51:10 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id 65so2259827oid.13 for ; Wed, 03 Jul 2019 07:51:10 -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=5OGpDAnyqy99GBTdVNN/pxjNukC6NsLaR2IX+sxI9+o=; b=hWXhNiD4V/ZEYsSua14a1JlkCtDGkewMh0sA94Opb9GTZx1Ros18TLpxhXX/iNSQOk Jczr7mRtU2zpkonNhaddCiKkIjTKCkn0BIZpiigOl7TnatEmNj5R4h9kxF929ldv3nxX qDZiBiK7AxLpmbsAbcGrEOiYRLImuvWuwHtANRVKrL1VihenPEBB7JK44wY217+msdKw U9lVgyw4ZPufumj3880B/cymfeMaNPx7x5gTAQdSQigTdqS5XBD/yQqa9rQocxehHjDk Ktwo/XW8qiKOoKWzxo9L9rpMxNdvoazofmLBuaQa9EasRrsmfDk4upP8e3nGn6vIrsqp IrQA== 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=5OGpDAnyqy99GBTdVNN/pxjNukC6NsLaR2IX+sxI9+o=; b=U6etOrVohRu9qiubmbnkkPloI+VtZXf9A4c5FxAgRFkvPb1qFOZGp7f4mrgeBPE6yQ fAXaTVBctxSEfJ90IUIZiGsdvZP4Fv15Ueg25ktkF4Zy8H7wBkebOqj+GfmW0a8KfVX5 ClZH/9dJqtAvr02miQKapasyK6dyUgQZsw2HlqNlzgQTJXz2SxsEZ08EjbLqQ1v/iUx4 8TdOPKK05Icw1AAWIh89uGY3NcKomXvC0TxIRSTv3jOHEesSoOit3iHdm19xjuEY7yRI vksQywDtVWnmkQjIMSv6Gehlcft7Js62PJ7kPVqrkXRZm/x9ZMYAqL50IXstCoC+6mCa S0Ng== X-Gm-Message-State: APjAAAWfZqXWTR2DMZyi2OWDNNMfO920Clj4SRxLmGXWH3JtdnzK1PRA Ou3xyKxaneqcWGD0p4gaK93j7wM1i8xXS22c+braCS6pvIim X-Google-Smtp-Source: APXvYqxNn4uW1CiI04WmXSEFJf+2QjimQ1/KJf4B9zhzTM8dNuqclx4yrqLxwoLUDaH8ZVZIaFHqBHocinhKGASjASM= X-Received: by 2002:aca:cc49:: with SMTP id c70mr3947723oig.174.1562165470019; Wed, 03 Jul 2019 07:51:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Wed, 3 Jul 2019 16:50:58 +0200 Message-ID: To: Daniel Roesler , "Donald F. Coffin" Cc: OAUTH-WG Content-Type: multipart/alternative; boundary="000000000000ebc542058cc7fdb6" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 UI/UX Resources? X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Jul 2019 14:51:21 -0000 --000000000000ebc542058cc7fdb6 Content-Type: text/plain; charset="UTF-8" Hello Daniel, you may gather inspiration and explore Auth0's flows all-in-one page at https://flows.auth0.com Best, *Filip Skokan* On Wed, 3 Jul 2019 at 16:26, Daniel Roesler wrote: > Howdy all, > > Apologies if this is slightly off topic. > > I'm a part of the Green Button Alliance, the non-profit standards body > around sharing energy data, and the customer consent process is based > on OAuth 2.0 (e.g. granting access to your smart meter data in order > to have an energy audit done). > > However, most utilities we work with are unfamiliar with OAuth 2.0, so > we often have to explain how it works and what the best practices are. > There are plenty of resources we can point them to for the actual > protocol handshake, but I haven't been able to find any resources > around best practices for designing the user interface and experience > of OAuth. Unfortunately, in the energy industry, UI/UX design isn't > our strong suit, so it would be very helpful if we had design > lessons-learned from other industries to use as a reference. > > Does anyone here know of any resources, talks, blog posts, examples, > etc. for making good OAuth 2.0 UI/UX? > > Thanks! > Daniel Roesler > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ebc542058cc7fdb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Daniel,

you= may gather inspiration and explore Auth0's flows all-in-one page at=C2= =A0https://flows.auth0.com

Best,
Filip Skokan


On Wed, 3 Jul 2019 at 16:26, Daniel Roesler <daniel=3D40utilityapi.com@dmarc.ietf.org= > wrote:
= Howdy all,

Apologies if this is slightly off topic.

I'm a part of the Green Button Alliance, the non-profit standards body<= br> around sharing energy data, and the customer consent process is based
on OAuth 2.0 (e.g. granting access to your smart meter data in order
to have an energy audit done).

However, most utilities we work with are unfamiliar with OAuth 2.0, so
we often have to explain how it works and what the best practices are.
There are plenty of resources we can point them to for the actual
protocol handshake, but I haven't been able to find any resources
around best practices for designing the user interface and experience
of OAuth. Unfortunately, in the energy industry, UI/UX design isn't
our strong suit, so it would be very helpful if we had design
lessons-learned from other industries to use as a reference.

Does anyone here know of any resources, talks, blog posts, examples,
etc. for making good OAuth 2.0 UI/UX?

Thanks!
Daniel Roesler

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ebc542058cc7fdb6-- From nobody Wed Jul 3 11:59:15 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 0ED1D1200D7; Wed, 3 Jul 2019 11:59:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2019 11:59:05 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 18:59:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My apologies; my previous position was incomplete. Updated to note namespacing issues, and one minor terminology nit about "DNS-ID". There seem to be some pretty serious namespacing issues that are not discussed at all in this document. Specifically, using JWT as a container for OAuth 2.0 authorization request parameters (including extension parameters) introduces the usage of many new names (of JSON name/value pairs) into the JWT claims namespace. Furthermore, the addition is not bounded, as any new OAuth extension parameters are implicitly permitted to be used as well! The IANA Considerations make no mention of the collapsed namespace for JWT claims and OAuth 2.0 (authorization request) parameters, leaving substantial potential for collisions in the future. Relatedly, using "application/jwt" as the Content-type of the HTTP response from dereferencing the request_uri with no explicit indication of the type/profile of JWT used (whether in the content type or in the JWT claims themselves) gives some risk of misinterpretation of the content. Consider, for example, when that request_uri is dereferenced not by the authorization server in the process of fulfilling an authorization request, but instead by some other service that expects a different type of JWT. This second point is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When the client does not want to do the crypto. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. How can you "not want to do [the] crypto" but still be doing TLS (with crypto)? Perhaps we're looking for "not want to pay the additional overhead of JWS/JWE cryptography on top of TLS"? Section 1.1 RFC 8174 has updated BCP 14 boilerplate text to use. Section 3 nit: should this section be 2.3 to get wrapped into "terminology"? It might also be worth putting references in for the terms, though they are largely common knowledge at this point. Section 4 A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contains all the OAuth 2.0 [RFC6749] authorization request parameters including extension parameters. The parameters are represented as nit: "all the parameters" kind of sounds like "all that are defined". But I think the intent here is "any parameter used to process the request must come from the request object and URL query parameters are ignored", so maybe "MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request; parameters from other sources MUST NOT be used", akin to what we say down in Sections 5 and 6.3. But we need to be careful about the wording to not exclude the usage of the "request" and "request_uri" query parameters to find the Request Object! the JWT claims. Parameter names and string values MUST be included nit: maybe "the JWT claims of the object"? any extension parameters. This JSON [RFC7159] constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted. nit: I think we want "This JSON [RFC7159] object". (Long quote incoming) The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes extension variables such as "nonce" and "max_age". { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } Signing it with the "RS256" algorithm results in this Request Object value (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw Decoding the base64 of the body, we see: { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null }, "id_token": { "gender": null, "birthdate": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } I'm not sure where the "claims" claim is coming from -- 6749 doesn't seem to talk about it. (Note that this example is used later on as well.) Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED that it be removed after a reasonable timeout unless access control measures are taken. It sounds like a link to https://www.w3.org/TR/capability-urls/ might also be useful. Section 5.2.2 Do we want to remind the reader that the other query parameters are just for backwards compatibility? Section 5.2.3 The following is an example of this fetch process: GET /request.jwt HTTP/1.1 Host: tfp.example.org It's useful to show good hygeine in examples; can we get the extra entropy in this request that we have in the previous example(s)? Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. Does "the pre-registered algorithm" concept exist in the specs outside of draft-ietf-oauth-jwt-bcp? Section 8 HTTP clients MUST also verify the TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in It's probably easier to just say "using DNS-ID [RFC6125], to avoid man-in-the-middle attacks". Section 9 The error codes we list in Section 7 are already registered, for the OIDC usage. Do we want to say anything about that? (I guess it would be disallowed by process to try to update the existing registration to also point at this document.) Section 10 We probably also want to reference draft-ietf-oauth-jwt-bcp. Section 10.1 When sending the authorization request object through "request" parameter, it MUST either be signed using JWS [RFC7515] or encrypted using JWE [RFC7516] with then considered appropriate algorithm. Up in Section 5 we only allow (a) signed and (b) signed then encrypted; similarly, in Section 4 we reiterate "signed then encrypted". Why is it okay to talk about just "signed or encrypted" here? Section 10.2 (b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Similarly to the previous point, you also need to check the signature, which will always be there. (d) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. In this I don't think this is a complete sentence (and it's definitely not a parallel construction with (a)-(c)!). I think perhaps a crisp one-line summary of this method would be "Delegating the authorization check to a separate "Request Object to Request Object URI" endpoint on the Authorization Server". (The writing in the rest of this paragraph could also use an editing pass.) (e) A third party, such as a Trust Framework Provider, provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) above apply. In addition, the Authorization Server MUST know out-of-band that the Client utilizes the Trust Framework Operator. The Authorization Server also has to trust the third-party provider to actually do its job and not misbehave, right? Section 10.3 I'm not entirely sure what "[t]he endpoints ithat come into question in this specification" is supposed to mean -- is it just "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"? In [RFC6749], while Redirection URI is included, others are not included in the Authorization Request. As the result, the same applies to Authorization Request Object. nit: included in what? Section 10.4 It's probably also worth citing the generic URI security considerations from RFC 3986, here. Section 10.4.1 "request_uri", and (d) do not perform recursive GET on the "request_uri". nit: remove the "do" in order to make the construction parallel. Section 12.1 It is often hard for the user to find out if the personal data asked for is strictly necessary. A Trust Framework Provider can help the user by examining the Client request and comparing to the proposed processing by the Client and certifying the request. After the certification, the Client, when making an Authorization Request, can submit Authorization Request to the Trust Framework Provider to obtain the Request Object URI. side note: In my head the act of certification was the act of making the translation to a Request Object URI, so I'm kind of curious where my vision differs from reality. The third paragraph seems to mostly just be describing the procedure of how this flow works, which would not necessarily be specific to the privacy considerations section. Section 12.2.2 Even if the protected resource does not include a personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent per-user Request Object URI is used. A third party may observe it through browser nit: need an article for "persistent per-user Request Object URI" (or make it plural, as "URIs are used"). Therefore, per-user Request Object URI should be avoided. nit: I think this is better as "static per-user Requeste Object URIs". Section 13 Are there two different paragraphs for "contributions from the OAuth WG members"? Are they reflecting different types of contribution? From nobody Wed Jul 3 14:03:01 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 1206F1200C7; Wed, 3 Jul 2019 14:03:00 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156218777992.14666.16140271928439009292@ietfa.amsl.com> Date: Wed, 03 Jul 2019 14:02:59 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-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: Wed, 03 Jul 2019 21:03:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Reciprocal OAuth Author : Dick Hardt Filename : draft-ietf-oauth-reciprocal-02.txt Pages : 7 Date : 2019-07-03 Abstract: There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seamless experience for the user to grant access to a pair of protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-reciprocal-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 Thu Jul 4 18:32: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 4B8F0120220 for ; Thu, 4 Jul 2019 18:32:54 -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, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QF162BXunFm for ; Thu, 4 Jul 2019 18:32:53 -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 F0A2D1201A0 for ; Thu, 4 Jul 2019 18:32:52 -0700 (PDT) Received: from [192.168.1.125] (c-98-246-106-124.hsd1.or.comcast.net [98.246.106.124]) by alkaline-solutions.com (Postfix) with ESMTPSA id 1B66A31765; Fri, 5 Jul 2019 01:32:51 +0000 (UTC) From: David Waite Message-Id: <6FA4E237-3529-4F32-A7DA-D1B801BBED79@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 4 Jul 2019 18:32:50 -0700 In-Reply-To: Cc: David Sautter , oauth@ietf.org To: david@davidsautter.de References: <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices X-BeenThere: oauth@ietf.org X-Mailman-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, 05 Jul 2019 01:32:54 -0000 --Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 3, 2019, at 1:44 AM, david@davidsautter.de wrote: > I understood, that you could also secure this variant of the = Authorization Code Flow with PKCE in order to protect the redirect = steps. I noticed, that this is rarely discussed "in public" (e.g. blogs, = Stackoverflow etc) because some people say PKCE is considered to only be = beneficial in native applications. I know it was invented for protecting = the IPC steps of those, but why isn't it beneficial to also protect the = browser redirect steps? The PKCE guidance is slowly changing. Previously, PKCE was used mostly = for native apps as the code could be intercepted in between the front = channel and back channel calls. This is because operating systems do not = restrict registration of a custom URI scheme to a single application, so = the redirect back into the application (with the code) could actually go = to another app. The security-topics draft (and browser apps draft which refers to it) = expands this to all code flow. The reasoning is that this replaces some = of the security mitigations pushed onto the state parameter (such as to = prevent CSRF) - PKCE is both a more obvious place for it, and a client = which does not support PKCE correctly is detectable by the AS. -DW= --Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 3, 2019, at 1:44 AM, david@davidsautter.de= wrote:

<snip>

I understood, that you could also secure this variant of the = Authorization Code Flow with PKCE in order to protect the redirect = steps. I noticed, that this is rarely discussed "in public" (e.g. blogs, = Stackoverflow etc) because some people say PKCE is considered to only be = beneficial in native applications. I know it was invented for protecting = the IPC steps of those, but why isn't it beneficial to also protect the = browser redirect steps?

The PKCE guidance is slowly changing. Previously, PKCE = was used mostly for native apps as the code could be intercepted in = between the front channel and back channel calls. This is because = operating systems do not restrict registration of a custom URI scheme to = a single application, so the redirect back into the application (with = the code) could actually go to another app.

The security-topics draft (and browser apps draft = which refers to it) expands this to all code flow. The reasoning is that = this replaces some of the security mitigations pushed onto the state = parameter (such as to prevent CSRF) - PKCE is both a more obvious place = for it, and a client which does not support PKCE correctly is detectable = by the AS.

-DW
= --Apple-Mail=_2969B2AE-96A2-4B15-9F20-BC86D9D40C35-- From nobody Fri Jul 5 06:56:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3A11200B3 for ; Fri, 5 Jul 2019 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJD0RDPQEB7H for ; Fri, 5 Jul 2019 06:56:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CAB1200B2 for ; Fri, 5 Jul 2019 06:56:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F345BB8223A; Fri, 5 Jul 2019 06:56:06 -0700 (PDT) To: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dziekan.jan@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190705135606.F345BB8223A@rfc-editor.org> Date: Fri, 5 Jul 2019 06:56:06 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776) X-BeenThere: oauth@ietf.org X-Mailman-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, 05 Jul 2019 13:56:19 -0000 The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5776 -------------------------------------- Type: Editorial Reported by: Jan Dziekan Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- RFC8252 references specific Sections of RFC6749, however urls are pointing to Sections in RFC8252. For example, in Section 6 there is a statement "code grant type per Section 4.1 of OAuth 2.0 [RFC6749]", where "Section 4.1" links to https://tools.ietf.org/html/rfc8252#section-4.1 instead of https://tools.ietf.org/html/rfc6749#section-4.1 I have found such misplaced links in the following sections: 6, 8.2, 8.4, 8.5, 8.6, 8.12 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8252 (draft-ietf-oauth-native-apps-12) -------------------------------------- Title : OAuth 2.0 for Native Apps Publication Date : October 2017 Author(s) : W. Denniss, J. Bradley Category : BEST CURRENT PRACTICE Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jul 5 08:17: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 794081200C5; Fri, 5 Jul 2019 08:16: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z8N5AWTI4qr; Fri, 5 Jul 2019 08:16:40 -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 1033C12006A; Fri, 5 Jul 2019 08:16:40 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id p13so10279856wru.10; Fri, 05 Jul 2019 08:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jqEGlTVAgiaNB5Ipxrqrwa8w5LGRJLf+ZE1UxhrC/p8=; b=JNsgiGg8tQAPjWiaC+A3HpPvKuJ4QHv/lONedZLDQD37o+Xf1rpDKPByRT/Fc/w0Qh i30Jy+rDBmPwwJk/h9gNJYPKZM/O88mbOmGInnh25VYnqUT4NV1Sd3bvsQYqR4f9WGWN Zzi5JloEy8jSbSjdcKGMvdQv25vC9Ei+bRxSez3NpTdbljA/CGCp1j2SIL0CdTQuaNQn 6+bWj9vo3OKKOoTGm2Mh7BTOTkYKgh/hAaDvv6Ln9NvcogYSgzVJ3tAN6Pgp/dJVZ7zI mAMm2Bbr4H0PaLKTzgGmXF3eTaZX8ixC+SrB+tb/kyWgGafEZGZocHqn4uEofHFJ/HdN fPww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jqEGlTVAgiaNB5Ipxrqrwa8w5LGRJLf+ZE1UxhrC/p8=; b=MSRrydunxdzXhfCCs76fdvZCglGm3Bb90y0zgmaYa6Tz7s7tYJtZbX/9beayX+oNI/ B/hnheap/GigD9hFS/viEZFmRk94YvAOkVvRk1o1ibG8DPKKSKAXBD5lX8hmxPRxjGrD FOq/cqsJm2EepyUniqi5Tgjcp8HZUFCz7eJADAqkguz/rhhAE0UBLNqmjhB+sLNztfV1 D8sXEBtusFrTqz/qMeStWJ1p57NEhR/izmwtdPGejbVxPPIfIKFNv3GU1yF2g0xvjZr2 KrIrQi4ZSSImFAZe8tjCwXFrUUQE5OTf/tnWCzJ15kpM3PJPrr82SCdGgF70M4pWugP0 cnAQ== X-Gm-Message-State: APjAAAWNkYmceP1V+zfUzqxVHxaZJl/A3zCMkzX0gEcD2Q1OR0FjsJ9c zcZA+kk8O1kn2dVjNyEbr0FSxQho X-Google-Smtp-Source: APXvYqwsNrokdO7WY3XeQhuD55ryrgUFots1cXd1tH3/FS6NNK4CKaHohSfbDvWvXZP3RJ3sURpfEA== X-Received: by 2002:adf:ce88:: with SMTP id r8mr4922261wrn.42.1562339798362; Fri, 05 Jul 2019 08:16:38 -0700 (PDT) Received: from [10.0.0.156] (bzq-109-67-125-172.red.bezeqint.net. [109.67.125.172]) by smtp.gmail.com with ESMTPSA id q1sm5823032wmq.25.2019.07.05.08.16.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 08:16:37 -0700 (PDT) To: Martin Vigoureux , The IESG Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, oauth@ietf.org References: <156155924331.20056.18009078917506280190.idtracker@ietfa.amsl.com> From: Yaron Sheffer Message-ID: <1ad67fc2-d2bd-95a1-31e1-869a34920421@gmail.com> Date: Fri, 5 Jul 2019 18:16:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156155924331.20056.18009078917506280190.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Martin Vigoureux's No Objection on draft-ietf-oauth-jwt-bcp-06: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:16:54 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hello, thank you for this document. > > I wonder whether [nist-sp-800-56a-r3] should be a normative reference. > > Thanks > -m > > Correct, as it is used in a MUST requirement. Will be fixed in -07. From nobody Fri Jul 5 08:33: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 E925E120183; Fri, 5 Jul 2019 08:33: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj5QbfsO_HBy; Fri, 5 Jul 2019 08:33:29 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671721200C3; Fri, 5 Jul 2019 08:33:29 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id p74so6461452wme.4; Fri, 05 Jul 2019 08:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7///RpGhMSF9BASaw6TL49mjeeDrRzZuHG4VI3/09e8=; b=f4tPrW2dcFBeA3kMmTHLtZt774gQcl6GsV03QYSZDn/6IhF7ml9If01Pe6iJhurICN lZ24hps+/1ruBxorLt5n5fFiRv1cW8TI2lBUHS++fdA80o2B4cTkUq3qj4jDwWS6AvC4 MVBsrGddkm8VoBIMfKj+T8JX+Hb/EgbcymwEdwXJZxc8CcvJAOsqIP+gM8F55RHYeRSP 1JwfgS/YRlGPu+1pfWkBdwQAH/6ld/n8UHBJRRmY+60BRDcCssKaxZOQABu2RsqmhJQb QWoykBtqxYqXtB2BjGjxzx4H4NWB9uNIWMYDH242B0PZOCWpiaxCJDIi8zhc1CPMPmEG hxEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7///RpGhMSF9BASaw6TL49mjeeDrRzZuHG4VI3/09e8=; b=ow09YHz31r4cfhOsn5gFErr76d112wVCCuyzeWBzgXJmGSQt8fG7QmnV9FVY5ipcQk bOcNwMQQJeKZis9x9C81ZOo2hq7LFBSFFPeApxZ1tiu5YNrxixSf8lfCOcPq8uWk9jVE 83CS7OAaAXqpL2hHFb5pRsKZBefGxvoLAstklPPLBqaPNKRsY2/ZkqOgrtcSGK54lZl7 1E/cvKxA/F+ySHdxviliPcLcPZL8loeq/IWzhmlLK90emFwajvRSp0UU+BHu7ntHf3m8 PxPG/aFsXmeVGOI6CLuh7f9b2AjmmQimpmaJNeva5GhTX5mQqlEwh5KZgPGAXxGsw9xc Lcmw== X-Gm-Message-State: APjAAAU5cUXTW2qUxEMVUadLZEZ+0/AaFahcqjag1BHAK4K12wfqmjtc UtkR7YB1pWba/MxzHEwI2xspjDFa X-Google-Smtp-Source: APXvYqwfkAW1rk8PXrdUvR83Q2HkTS4iuM3A/DzEDTlAGglAViSRjHNKoolhoEjl4mRIRUNZywOudg== X-Received: by 2002:a1c:f212:: with SMTP id s18mr3649318wmc.86.1562340807691; Fri, 05 Jul 2019 08:33:27 -0700 (PDT) Received: from [10.0.0.156] (bzq-109-67-125-172.red.bezeqint.net. [109.67.125.172]) by smtp.gmail.com with ESMTPSA id y24sm9364346wmi.10.2019.07.05.08.33.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 08:33:27 -0700 (PDT) To: Adam Roach , The IESG Cc: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, oauth@ietf.org References: <156143908719.24005.13391480103830414058.idtracker@ietfa.amsl.com> From: Yaron Sheffer Message-ID: <4c470be6-67e7-41f5-d8c9-6501b48f3609@gmail.com> Date: Fri, 5 Jul 2019 18:33:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156143908719.24005.13391480103830414058.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 15:33:40 -0000 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for everyone who worked to get this document out the door. I found it to > be well-organized and easy to read. > > --------------------------------------------------------------------------- > > This is a process discuss for Roman to handle, and I plan to clear it > during the IESG formal telechat. > > This document is intended for BCP status. It has a normative reference to RFC > 8017, which is an informational document. Checking the last call text > (https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/edit/lastcalltext/), > there is no mention of RFC 8017, nor does RFC 8017 appear in the downref > registry (https://datatracker.ietf.org/doc/downref/). > > Thanks to RFC 8067, we are not required to run this document through IETF LC > again (and, given that RFC 8017's predecessor, RFC 3447, is in the registry, > we probably don't want to). However, we'll need to minute that the point was > raised and addressed. There is also at least one additional requirement > imposed by section 2 of RFC 8067 that needs to be satisfied (see the last > sentence in that section). > Resolved by Roman in a subsequent message. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > §3.2: > >> That said, if a JWT is cryptographically protected by a transport >> layer, such as TLS using cryptographically current algorithms, there >> may be no need to apply another layer of cryptographic protections to >> the JWT. > > It may be helpful to distinguish between end-to-end TLS encryption (such as that > seen in HTTPS, even in the presence of proxies) and hop-by-hop TLS encryption > (such as that seen in SIPS when proxies are present). In the latter case, > intermediaries may perform attacks that would otherwise only be possible to > mount by the endpoints. > > My concrete suggestion is to modify the above text to read "...protected > end-to-end by a transport layer, such as..." > Yes. Fixed in the upcoming -07. > --------------------------------------------------------------------------- > > §3.2: > >> - Avoid all RSA-PKCS1 v1.5 [RFC2313] encryption algorithms, >> preferring RSA-OAEP ([RFC8017], Sec. 7.1). > > It's not clear to me what this recommendation intends to say regarding the > algorithms in RFC 2437 and RFC 3447. One might infer that they're deprecated > as well. If this is the intention, please be explicit. > > Yes this is confusing. For consistency, we will also reference PKCS1 v1.5 from RFC 8017 (which is the only recent, non-obsoleted RFC out of this chain). Thanks, Yaron From nobody Fri Jul 5 09:13:14 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EE31200B9; Fri, 5 Jul 2019 09:13:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156234319209.21816.7097958320636574909@ietfa.amsl.com> Date: Fri, 05 Jul 2019 09:13:12 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-17.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 16:13:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-17.txt Pages : 35 Date : 2019-07-05 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 5 10:06:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675DE1202ED for ; Fri, 5 Jul 2019 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u--VawMQDV5o for ; Fri, 5 Jul 2019 10:06:35 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6551201D6 for ; Fri, 5 Jul 2019 10:03:49 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id j5so1098179ioj.8 for ; Fri, 05 Jul 2019 10:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0pN6QwgtQWdI6d2X+n80PnTSr/gbeFEkz+A7oHdpwzE=; b=UGhcfJQxNWUn7Zuxlr/FhrRbQV7XQhbIFqCNMsiZ55rGLHRIRyfoV5vBVAivoi3GoT ZcdU+YuiNrisrv0FDd/wa7ZvOcp6j/eLsB613oDwFLtf231MGAg47tJO5RBbQ6H646Cv EunvYajree5uw7tgP/xsYvmNprN9cn8D0aHIo= 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=0pN6QwgtQWdI6d2X+n80PnTSr/gbeFEkz+A7oHdpwzE=; b=OnlXDfF7OpjkEP3wwEGGLszQEMC4DWzw1fjrMT2xPNqZFQ9su6Z7vYxkEpmVGDBSS1 oh0oDWI7r9BE0bywhK+J343jMnmE3zwQR4RrcsvRnTq2zKlkSCWKPf/VlWK6gUfhSSCx 9ArzdSHmzZPNCiZEr9w153cBXAtH4H0Jju1P842VuKxfL7p4KZFRPzrU2S69JpTBsSfr AXNqvMqMI3jUFqhw3qBl9cwF4PQLDyEV0iTONR0JVH+RhRb15WOGlcrbKaWBJJdAceDb LJiP28SLmIIYmSZ5/c6vyi+UgOM9rAPj6msiOUnSc03qaI8kymj7ftWDfV0q821pVIqU Kd3Q== X-Gm-Message-State: APjAAAWNS82lwEuw73tjn5xAB1ADPo8L5jvfqGQZeMUfAfygE0uwZIqg eTJd6rvccDSDH4ptyeiHCpwxb+BbVrgxMqDp+XWcW8gI8EV17oZh27X0qw7jEJ0UYQDx/kMhgZJ f+KBZ7m0OHP2/Vg== X-Google-Smtp-Source: APXvYqx+EAZtNhvLUjxF0ANztpeMdOR8YHLDUivfdVud3V0EpsaUEC2ULc7IpaRyz8GHT3+SRHhGDheS4+3HV5HgvSc= X-Received: by 2002:a5e:d60a:: with SMTP id w10mr5609384iom.78.1562346228296; Fri, 05 Jul 2019 10:03:48 -0700 (PDT) MIME-Version: 1.0 References: <154280782366.11474.16509452820433630629.idtracker@ietfa.amsl.com> <20190111161321.GJ28515@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Fri, 5 Jul 2019 13:03:22 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000f45f74058cf2137e" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:06:44 -0000 --000000000000f45f74058cf2137e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ben, It took more time than expected but the early registry allocations have been approved and completed. They can all be found (qualified as 'TEMPORARY') at https://www.iana.org/assignments/oauth-parameters and https://www.iana.org/assignments/jwt I've also published draft -17 of the document https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17 with changes that believe (or hope anyway) address all of your comments. As such, I'd respectfully request that you review the changes and clear the discuss. Thank you, Brian On Sat, Jan 19, 2019 at 8:58 AM Brian Campbell wrote: > This response is slow but somewhat less slow than those that came before. > So I also apologize again but somewhat less so :) I do apologize for > sending on a weekend but I just wasn't able to finish and make it to the > "send" button before the end of my Friday. > > I've endeavored to continue the exchange inline below where appropriate > and removed portions that needed no further discussion. > > > On Fri, Jan 11, 2019 at 9:13 AM Benjamin Kaduk wrote: > >> I also apologize for the slow response (I gave Brian a unicast heads-up >> earlier) -- between vacation, the holidays, and a death in a the family = I >> was away from email for quite some time. >> >> On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: >> > I apologize for the slow response, Ben. I was on vacation with my fami= ly >> > around the Thanksgiving holiday when the ballot position came in. And >> even >> > on returning and starting to work on it, there's an awful lot here to >> get >> > through and this kind of thing is very time consuming for me. But than= k >> you >> > for the review - I've attempted to reply, as best I can, to your >> > comments/questions inline below. >> > >> > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: >> > >> > > Benjamin Kaduk has entered the following ballot position for >> > > draft-ietf-oauth-token-exchange-16: Discuss >> > > >> > > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > > for more information about IESG DISCUSS and COMMENT positions. >> > > >> > > >> > > The document, along with other ballot positions, can be found here: >> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >> > > >> > > --------------------------------------------------------------------= -- >> > > DISCUSS: >> > > --------------------------------------------------------------------= -- >> > > >> >> >> There's two obvious routes -- first, to change the text to use >> placeholders >> like "TBD1" or "the token-exchange URI" (e.g., as opposed to >> urn:ietf:params:oauth:grant-type:token-exchange specifically) and reques= t >> that IANA allocate the specific suggested values; or >> to get IANA to explicitly confirm that >> these values can be registered and will be marked as pending until this >> document is finalized (to prevent allocation "under our nose" by other >> means). Ekr and I can help mediate any IANA interaction needed for >> whatever route we end up taking, if needed. >> >> (Basically, this is a process concern -- the IESG should not give its >> stamp >> of approval to a document in a state that does something we don't want >> other people to do, even if the final published RFC will be able to make >> these claims correctly.) >> > > I'd then ask that the AD(s) initiate and mediate interactions with IANA t= o > have them explicitly confirm that these values can be registered and have > them somehow marked as pending until the document is finalized. > > > > >> > >> >> >> Before I start trying to tweak text, can you confirm that the actor_toke= n >> request parameter is okay to use in both delegation and impersonation >> scenarios? >> > > Yes, it's certainly okay to use the actor_token in both delegation and > impersonation scenarios. It's necessary for delegation and kinda makes mo= re > sense in that scenario but could still be sent by the client and have the > STS issue a new token with impersonation semantics. > > > > >> > > >> > > Are the privacy considerations (e.g., risk of a tailed per-request >> > > error_uri) relating to the use of error_uri discussed in some other >> > > document that we can refer to from this document's security >> > > considerations? (I say a bit more about this in my COMMENT.) >> > > >> > >> > I am not aware of any document with such considerations and I've >> searched >> > the likely suspects of RFC 6749 and RFC 6819 but don't find anything. >> > >> > The error_uri token endpoint response parameter was defined in the >> original >> > OAuth 2.0 framework document (RFC 6749) and any considerations around = it >> > are applicable to considerably more than this document. It's also very >> > rarely used in practice as far as I know. I don't think that this >> document, >> > which is a narrow extension of a whole framework with a series of othe= r >> > documents that use error_uri, is the appropriate place to add privacy = or >> > security considerations about error_uri. Perhaps >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >> would be >> > more appropriate in scope and content? >> >> Oh, definitely -- I only asked if there was something existing we could >> cheaply reference; this is definitely not the place to be writing this >> down >> from scratch. Thanks for doing the search! >> > > Just to clarify, that draft doesn't currently have anything about > error_uri. However, it seems like a more appropriate place for that in > terms of its scope to have any such guidance. And that, to the extent suc= h > guidance or text is needed, it should go in to that draft (which is a WG > draft in progress) rather than into the token exchange draft. > > > >> > I could remove the one mention of error_uri in this document? It's usa= ge >> > would still be possible/valid by virtue of this document being an >> extension >> > of RFC 6749 but, out of sight and out of mind, and this doc wouldn't >> then >> > encourage new usage of it anyway. While usage isn't really happening >> anyway. >> >> I don't mind having the reference there; it's not really causing problem= s >> and could potentially be helpful. We should be able to get away with a >> generic reference to this class of thing elsewhere and one-sentence >> description ("when a proxy or similar mechanism is in place to protect >> client privacy, the error_uri mechanism can induce the client to lose so= me >> anonymity by dereferencing a URI pointing to a third party server that c= an >> leak information to the attacker, in a similar fashion as [ref]"). I >> don't >> have a [ref] handy right now, though; I'll need to ask around. >> > > If you can provide such a [ref], I can add such a sentence to the draft. > > But I'm still of the opinion that it would be out of place in this > document. > > > In a pinch we could fallback to analogy to open-redirector issues, though >> we differ in which actors are receiving/conveying/acting on untrusted >> input, and we can have issues just by making the request as opposed to t= he >> user mis-interpreting the returned resource. But to reiterate, I'm only >> looking for a brief mention that some clients might care and don't need = an >> exhaustive description. >> > > Perhaps then the sentence you had above but without the "in a similar > fashion as [ref]" part might suffice as the aforementioned brief mention? > > > > >> > >> > > >> > > Section 2.1 has: >> > > audience >> > > OPTIONAL. The logical name of the target service where the >> client >> > > intends to use the requested security token. This serves a >> > > purpose similar to the "resource" parameter, but with the clie= nt >> > > providing a logical name rather than a location. Interpretati= on >> > > of the name requires that the value be something that both the >> > > client and the authorization server understand. An OAuth clie= nt >> > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], >> an >> > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are >> > > examples of things that might be used as "audience" parameter >> > > values. [...] >> > > >> > > How does the STS know what type of identifier it is supposed >> > > to interpret the provided audience value as? >> > > >> > >> > The STS will have policy and configuration for the target entities for >> > which it supports the issuance of tokens to in this flow, even if/when >> > those entities are different types of things. The STS will have to >> search >> > that set of things to find the right one for the given name. In theory= I >> > suppose there's potential ambiguity or even name collision. But in >> practice >> > (as it is the STS that ultimately decides the names it supports and ca= n >> > service) I don't believe there is an actual issue. >> >> Okay, so at some point we're essentially just doing a lookup based on >> audience string, and the type information is attached to the lookup >> results >> (along with everything else needed). >> >> Do you think it makes sense to add a sentence after the non-elided quote= d >> portion, something like ``However, "audience" values used on a given >> authorization server must be unique within that server, to ensure that >> they >> are properly interpreted as the intended type of value.''? (I'm of cour= se >> open to other suggestions, including "just leave it as it is"; I think >> what >> triggered me to comment here is that "both the client and the >> authorization >> server understand" leaves open the possibility that the AS might share o= ne >> understanding of a string with one client and a different understanding = of >> that same string with a second client, since it's only a pairwise >> condition >> but we probably are safer with a global condition.) >> > > My inclination would be to "just leave it as it is" because well that's > the easiest thing to do but it could also make sense to add something lik= e > that sentence you had. > > The idea/intent behind "both the client and the authorization server > understand" was that they both understand the thing and understand the sa= me > way. > > > > >> > >> > > >> > > --------------------------------------------------------------------= -- >> > > COMMENT: >> > > --------------------------------------------------------------------= -- >> > > >> > > The document could perhaps benefit from greater clarity as to whethe= r >> > > "security token"s refer to inputs, outputs, or both, of the token >> > > endpoint (for the interactions defined in this specification). >> > > >> > >> > I have been aware of the potential need here and endeavored to be clea= r >> > about it throughout the document without being overly repetitive or >> wordy. >> > I will take another pass through the text and look for opportunities t= o >> > further clarity. But if there are specific points in the doc that you >> > believe need attention, please point them out so I can be sure they ge= t >> > addressed. >> >> I made another quick pass, and it is better than I remembered. So thank= s >> for the efforts, and sorry for maligning the document! >> > > No apology necessary! > > > >> Maybe 2.2.1's "token_type" description could reiterate "issued security >> token" both times that "security token" appears instead of just the seco= nd >> time, though the context really ought to be enough to make this one clea= r. >> Other than that, the only potential trouble I see is in the introduction >> when we get a barrage of the string all at once. And even that's in >> reasonable shape, with the only potential changes I see being in the fir= st >> sentence of the second paragraph, something like "capable of validing >> security tokens provided to it and issuing new security tokens in >> response". >> > > Thanks for the specifics, I'll make those updates. > > > >> > >> >> > >> > > >> > > In the absence of one-time-use or other semantics specific to the >> > > token type, the act of performing a token exchange has no impact = on >> > > the validity of the subject token or actor token. Furthermore, t= he >> > > validity of the subject token or actor token have no impact on th= e >> > > validity of the issued token after the exchange has occurred. >> > > >> > > Do we really want this strong of a statement? I suspect that in man= y >> > > environments propagating, e.g., expiration time to the exchanged >> > > credential may be desired. >> > > >> > >> > The statement was not in any way intended to prohibit propagating >> > expiration time (or other criteria) to the exchanged credential. The >> > statement was added, best I can recall, in response to a question that >> came >> > up in a WG chair review asking if the input token(s) would somehow >> become >> > invalid once used as input to the exchange. Or if some later expiratio= n >> or >> > other invalidation of the input token(s) would somehow invalidate the >> new >> > token. The point of the statement in the doc was to try and say that >> there >> > is no inherit linkage effectual relationship between the tokens outsid= e >> the >> > exchange event. There could be but that's not a general property of th= e >> STS >> > protocol a would be specific to a particular token type or deployment. >> > >> > Does that make any more sense? Do you think the wording could/should b= e >> > adjusted? >> >> That makes perfect sense for what we want to happen, yes. >> >> I wonder if we really want the second sentence to be saying something li= ke >> "The exchange is a one-time event and does not create a tight linkage >> betwee the input and output tokens, so that (for example) while the >> expiration >> time of the output token may be influenced by that of the input token, >> renewal or extension of the input token is not expected to be reflected = in >> the ouput token's properties. It may still be appropriate to propagate >> token revocation events, though." (This bit about revocation is perhaps >> even more interesting than expiration time, and would seem to be prevent= ed >> by the current text.) >> > > Yeah, I kinda think that or something along those lines might be indeed b= e > better. Propagation of revocation wasn't intended to be prevented. Rather= I > was just aiming to say that such propagation wasn't required or even > expected. > > > >> >> >> > > >> > > Would it be appropriate to note (here or elsewhere) that for non-JWT >> > > token formats that are a binary format, the URI used for conveying >> them >> > > needs to be associated with the semantics of base64 (or otherwise) >> > > encoding them for usage with OAuth? >> > > >> > >> > My thinking had been that it'd be more or less self-evident to the ver= y >> > small group and type of people who would ever undertake such a thing. >> But a >> > brief note to that effect couldn't hurt. I'll add something as such. >> > >> >> To be clear, I wouldn't mind if you decided to leave it as is. But than= ks >> :) >> > > Fair enough, thanks :) > > > >> >> >> > On looking at it again, I agree "May Act For" isn't a particularly goo= d >> > name nor is it helpful in understanding it. I admit to having a hard >> time >> > with the language here. But, yeah, "May Act For" isn't very good. >> > >> > What about "Authorized Actor" in the parenthetical and "Authorized >> Actor - >> > the party that is authorized to become the actor" for the Claim >> Description >> > in registration? >> > >> >> I think that's an improvement, thanks. >> >> > > Thanks for confirming, I'll make that change. > > > >> > < snip> >> >> > > Appendix A.1.1 >> > > >> > > In the following token exchange request, a client is requesting a >> > > token with impersonation semantics. [...] >> > > >> > > What part of the request indicates that impersonation semantics are >> > > requested? >> > > >> > >> > I guess it's not explicitly requesting impersonation semantics per se >> but >> > only a subject_token is being supplied in the request so impersonation >> is >> > kinda implied as there is no party identified that could be delegated >> to. >> > >> > Do you think the wording should be qualified as such or otherwise >> adjusted? >> >> I could go either way, but if I was adding something, I'd go for a >> parenthetical "(with only a subject_token and no actor_token, delegation >> is >> impossible)". >> > > That works, I'll add that. > > > >> >> >> -Benjamin >> > --=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._ --000000000000f45f74058cf2137e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

It took more time than = expected but the early registry allocations have been approved and complete= d. They can all be found (qualified as 'TEMPORARY') at https://www.iana.org/assignments/oauth-parameters and https://www.iana.org/assignments/jwt

I&#= 39;ve also published draft -17 of the document https://to= ols.ietf.org/html/draft-ietf-oauth-token-exchange-17 with changes that = believe (or hope anyway) address all of your comments. As such, I'd res= pectfully request that you review the changes and clear the discuss.

Thank you,
Brian

<= div>


On Sat, Jan 19, 2019 at 8:58 AM Brian Campbel= l <bcamp= bell@pingidentity.com> wrote:
This = response is slow but somewhat less slow than those that came before. So I a= lso apologize again but somewhat less so :)=C2=A0 I do apologize for sendin= g on a weekend but I just wasn't able to finish and make it to the &quo= t;send" button before the end of my Friday.

<= div>I've endeavored to continue the exchange inline below where appropriate and removed portions = that needed no further discussion.


On Fri= , Jan 11, 2019 at 9:13 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
I also apologize for the slow respon= se (I gave Brian a unicast heads-up
earlier) -- between vacation, the holidays, and a death in a the family I was away from email for quite some time.

On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote:
> I apologize for the slow response, Ben. I was on vacation with my fami= ly
> around the Thanksgiving holiday when the ballot position came in. And = even
> on returning and starting to work on it, there's an awful lot here= to get
> through and this kind of thing is very time consuming for me. But than= k you
> for the review - I've attempted to reply, as best I can, to your > comments/questions inline below.
>
> On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-token-exchange-16: Discuss
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.= org/doc/draft-ietf-oauth-token-exchange/
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
=C2=A0<snip>

There's two obvious routes -- first, to change the text to use placehol= ders
like "TBD1" or "the token-exchange URI" (e.g., as oppos= ed to
urn:ietf:params:oauth:grant-type:token-exchange specifically) and request that IANA allocate the specific suggested values; or
to get IANA to explicitly confirm that
these values can be registered and will be marked as pending until this
document is finalized (to prevent allocation "under our nose" by = other
means).=C2=A0 Ekr and I can help mediate any IANA interaction needed for whatever route we end up taking, if needed.

(Basically, this is a process concern -- the IESG should not give its stamp=
of approval to a document in a state that does something we don't want<= br> other people to do, even if the final published RFC will be able to make these claims correctly.)

I'd = then ask that the AD(s) initiate and mediate interactions with IANA to have= them explicitly confirm that these values can be registered and have them = somehow marked as pending until the document is finalized.
= =C2=A0

=C2=A0
>
=C2=A0<snip>

Before I start trying to tweak text, can you confirm that the actor_token request parameter is okay to use in both delegation and impersonation
scenarios?

Yes, it's certainl= y okay to use the actor_token in both delegation and impersonation scenario= s. It's necessary for delegation and kinda makes more sense in that sce= nario but could still be sent by the client and have the STS issue a new to= ken with impersonation semantics.


<= div>=C2=A0
> >
> > Are the privacy considerations (e.g., risk of a tailed per-reques= t
> > error_uri) relating to the use of error_uri discussed in some oth= er
> > document that we can refer to from this document's security > > considerations?=C2=A0 (I say a bit more about this in my COMMENT.= )
> >
>
> I am not aware of any document with such considerations and I've s= earched
> the likely suspects of RFC 6749 and RFC 6819 but don't find anythi= ng.
>
> The error_uri token endpoint response parameter was defined in the ori= ginal
> OAuth 2.0 framework document (RFC 6749) and any considerations around = it
> are applicable to considerably more than this document. It's also = very
> rarely used in practice as far as I know. I don't think that this = document,
> which is a narrow extension of a whole framework with a series of othe= r
> documents that use error_uri, is the appropriate place to add privacy = or
> security considerations about error_uri.=C2=A0 Perhaps
> https://datatracker.ietf.org/= doc/draft-ietf-oauth-security-topics/ would be
> more appropriate in scope and content?

Oh, definitely -- I only asked if there was something existing we could
cheaply reference; this is definitely not the place to be writing this down=
from scratch.=C2=A0 Thanks for doing the search!

<= /div>
Just to clarify, that draft doesn't currently have anything a= bout error_uri. However, it seems like a more appropriate place for that in= terms of its scope to have any such guidance. And that, to the extent such= guidance or text is needed, it should go in to that draft (which is a WG d= raft in progress) rather than into the token exchange draft.

=C2=A0
> I could remove the one mention of error_uri in this document? It's= usage
> would still be possible/valid by virtue of this document being an exte= nsion
> of RFC 6749 but, out of sight and out of mind, and this doc wouldn'= ;t then
> encourage new usage of it anyway. While usage isn't really happeni= ng anyway.

I don't mind having the reference there; it's not really causing pr= oblems
and could potentially be helpful.=C2=A0 We should be able to get away with = a
generic reference to this class of thing elsewhere and one-sentence
description ("when a proxy or similar mechanism is in place to protect=
client privacy, the error_uri mechanism can induce the client to lose some<= br> anonymity by dereferencing a URI pointing to a third party server that can<= br> leak information to the attacker, in a similar fashion as [ref]").=C2= =A0 I don't
have a [ref] handy right now, though; I'll need to ask around.

If you can provide such a [ref], I can add such= a sentence to the draft.

But I'm still o= f the opinion that it would be out of place in this document.
=C2=A0

In a pinch we could fallback to analogy to open-redirector issues, though we differ in which actors are receiving/conveying/acting on untrusted
input, and we can have issues just by making the request as opposed to the<= br> user mis-interpreting the returned resource.=C2=A0 But to reiterate, I'= m only
looking for a brief mention that some clients might care and don't need= an
exhaustive description.

Perhaps then th= e sentence you had above but without the "in a similar fashion as [ref= ]" part might suffice as the aforementioned brief mention?
<= br>

>
>
> >
> > Section 2.1 has:
> >=C2=A0 =C2=A0 audience
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OPTIONAL.=C2=A0 The logical name of the= target service where the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0intends to use the requested security t= oken.=C2=A0 This serves a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0purpose similar to the "resource&q= uot; parameter, but with the client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0providing a logical name rather than a = location.=C2=A0 Interpretation
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of the name requires that the value be = something that both the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client and the authorization server und= erstand.=C2=A0 An OAuth client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0identifier, a SAML entity identifier [O= ASIS.saml-core-2.0-os], an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0OpenID Connect Issuer Identifier [OpenI= D.Core], or a URI are
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0examples of things that might be used a= s "audience" parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0values.=C2=A0 [...]
> >
> > How does the STS know what type of identifier it is supposed
> > to interpret the provided audience value as?
> >
>
> The STS will have policy and configuration for the target entities for=
> which it supports the issuance of tokens to in this flow, even if/when=
> those entities are different types of things. The STS will have to sea= rch
> that set of things to find the right one for the given name. In theory= I
> suppose there's potential ambiguity or even name collision. But in= practice
> (as it is the STS that ultimately decides the names it supports and ca= n
> service) I don't believe there is an actual issue.

Okay, so at some point we're essentially just doing a lookup based on audience string, and the type information is attached to the lookup results=
(along with everything else needed).

Do you think it makes sense to add a sentence after the non-elided quoted portion, something like ``However, "audience" values used on a gi= ven
authorization server must be unique within that server, to ensure that they=
are properly interpreted as the intended type of value.''?=C2=A0 (I= 'm of course
open to other suggestions, including "just leave it as it is"; I = think what
triggered me to comment here is that "both the client and the authoriz= ation
server understand" leaves open the possibility that the AS might share= one
understanding of a string with one client and a different understanding of<= br> that same string with a second client, since it's only a pairwise condi= tion
but we probably are safer with a global condition.)
My inclination would be to "just leave it as it is" = because well that's the easiest thing to do but it could also make sens= e to add something like that sentence you had.
=C2=A0
The idea/intent behind "both the client and the authorization serve= r understand" was that they both understand the thing and understand t= he same way.


>
>
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > The document could perhaps benefit from greater clarity as to whe= ther
> > "security token"s refer to inputs, outputs, or both, of= the token
> > endpoint (for the interactions defined in this specification). > >
>
> I have been aware of the potential need here and endeavored to be clea= r
> about it throughout the document without being overly repetitive or wo= rdy.
> I will take another pass through the text and look for opportunities t= o
> further clarity. But if there are specific points in the doc that you<= br> > believe need attention, please point them out so I can be sure they ge= t
> addressed.

I made another quick pass, and it is better than I remembered.=C2=A0 So tha= nks
for the efforts, and sorry for maligning the document!

No apology necessary!
=C2=A0

<= /div>

Maybe 2.2.1's "token_type" description could reiterate "= issued security
token" both times that "security token" appears instead of j= ust the second
time, though the context really ought to be enough to make this one clear.<= br> Other than that, the only potential trouble I see is in the introduction when we get a barrage of the string all at once.=C2=A0 And even that's = in
reasonable shape, with the only potential changes I see being in the first<= br> sentence of the second paragraph, something like "capable of validing<= br> security tokens provided to it and issuing new security tokens in
response".

Thanks for the specific= s, I'll make those updates.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> >=C2=A0 <snip> <snip> <snip>

>
> >
> >=C2=A0 =C2=A0 In the absence of one-time-use or other semantics sp= ecific to the
> >=C2=A0 =C2=A0 token type, the act of performing a token exchange h= as no impact on
> >=C2=A0 =C2=A0 the validity of the subject token or actor token.=C2= =A0 Furthermore, the
> >=C2=A0 =C2=A0 validity of the subject token or actor token have no= impact on the
> >=C2=A0 =C2=A0 validity of the issued token after the exchange has = occurred.
> >
> > Do we really want this strong of a statement?=C2=A0 I suspect tha= t in many
> > environments propagating, e.g., expiration time to the exchanged<= br> > > credential may be desired.
> >
>
> The statement was not in any way intended to prohibit propagating
> expiration time (or other criteria) to the exchanged credential. The > statement was added, best I can recall, in response to a question that= came
> up in a WG chair review asking if the input token(s) would somehow bec= ome
> invalid once used as input to the exchange. Or if some later expiratio= n or
> other invalidation of the input token(s) would somehow invalidate the = new
> token.=C2=A0 The point of the statement in the doc was to try and say = that there
> is no inherit linkage effectual relationship between the tokens outsid= e the
> exchange event. There could be but that's not a general property o= f the STS
> protocol a would be specific to a particular token type or deployment.=
>
> Does that make any more sense? Do you think the wording could/should b= e
> adjusted?

That makes perfect sense for what we want to happen, yes.

I wonder if we really want the second sentence to be saying something like<= br> "The exchange is a one-time event and does not create a tight linkage<= br> betwee the input and output tokens, so that (for example) while the expirat= ion
time of the output token may be influenced by that of the input token,
renewal or extension of the input token is not expected to be reflected in<= br> the ouput token's properties.=C2=A0 It may still be appropriate to prop= agate
token revocation events, though."=C2=A0 (This bit about revocation is = perhaps
even more interesting than expiration time, and would seem to be prevented<= br> by the current text.)

Yeah, I kin= da think that or something along those lines might be indeed be better. Pro= pagation of revocation wasn't intended to be prevented. Rather I was ju= st aiming to say that such propagation wasn't required or even expected= .

=C2=A0
<snip> <snip>

> >
> > Would it be appropriate to note (here or elsewhere) that for non-= JWT
> > token formats that are a binary format, the URI used for conveyin= g them
> > needs to be associated with the semantics of base64 (or otherwise= )
> > encoding them for usage with OAuth?
> >
>
> My thinking had been that it'd be more or less self-evident to the= very
> small group and type of people who would ever undertake such a thing. = But a
> brief note to that effect couldn't hurt. I'll add something as= such.
>

To be clear, I wouldn't mind if you decided to leave it as is.=C2=A0 Bu= t thanks
:)

Fair enough, thanks :)
=C2=A0


<snip> <snip> <snip>
=

> On looking at it again, I agree "May Act For" isn't a pa= rticularly good
> name nor is it helpful in understanding it. I admit to having a hard t= ime
> with the language here. But, yeah, "May Act For" isn't v= ery good.
>
> What about "Authorized Actor" in the parenthetical and "= ;Authorized Actor -
> the party that is authorized to become the actor" for the Claim D= escription
> in registration?
>

I think that's an improvement, thanks.
=C2=A0

Thanks for confirming, I'll = make that change.

=C2=A0
>=C2=A0 < snip> <snip>

> > Appendix A.1.1
> >
> >=C2=A0 =C2=A0 In the following token exchange request, a client is= requesting a
> >=C2=A0 =C2=A0 token with impersonation semantics. [...]
> >
> > What part of the request indicates that impersonation semantics a= re
> > requested?
> >
>
> I guess it's not explicitly requesting impersonation semantics per= se but
> only a subject_token is being supplied in the request so impersonation= is
> kinda implied as there is no party identified that could be delegated = to.
>
> Do you think the wording should be qualified as such or otherwise adju= sted?

I could go either way, but if I was adding something, I'd go for a
parenthetical "(with only a subject_token and no actor_token, delegati= on is
impossible)".

That works, I&= #39;ll add that.
=C2=A0


<snip> <snip>

-Benjamin

<= 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. --000000000000f45f74058cf2137e-- From nobody Fri Jul 5 10:07: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 04AF41202F3 for ; Fri, 5 Jul 2019 10:07:06 -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 7QKWm4npzOhy for ; Fri, 5 Jul 2019 10:07:03 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D8A120121 for ; Fri, 5 Jul 2019 10:05:14 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id f4so4985142ioh.6 for ; Fri, 05 Jul 2019 10:05:14 -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=VovFWVRTHSm2V3K+MwOvCvDMiDYz6KBMsKxqVdlUyog=; b=AVyf7DT1jZ6gQv59Vr8GNkQAzaEsr/4D3v/OOeIKlbrsGXr90n0fOJoY0bEL/boAgU A66eDv86GBO2NjH3sR8av1fEBqnO9LeAEF2dqZPEYkItRugR/v7jn1uVTmpRFxjwG4o1 tKeYkyCgty36UdTq1aBO+oG2lKb8rRbDHHDfg= 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=VovFWVRTHSm2V3K+MwOvCvDMiDYz6KBMsKxqVdlUyog=; b=ZF2NgWRgbE2VR425na7t8ltWdronyhFhDXf6wN3deOio4iU4LrfvOfO5BHVdW7UW2S qC4SMFj7j0uH7IxRJ6nhn7KpMa0USZIMFqjlvQYkS1SFWnWedd5wsFNcZFgob+JQGtsx rgY9fbW6T9QNLsfUF9z0uaPPQM/ac/IH8SM6VoWcZgbjPmy1SGOSEF33WYN5fPausYgo QQUHgkTO0QDj9xd+e3jfcFoctLyds3VpCOHcstaX8Q30AvUx5JtUjd7QxGyUY+8xQmdm Kga+urcrFuF2AibiBpm99CHgRGvKosWo7LZwUaGcpzx8t7oIuKO+doBLlpf4zxgecioz Beng== X-Gm-Message-State: APjAAAX1VOxsFTmFjMrnlkonN0Q/cgaUbRXPy1Af5kk1N7UC6gq1uhc+ fOz7I90V7TkaJuAnuNP4iCwix4+KzyZy8kSDtPWGqq7QVtoPjyypdhb9P/AfRonIHDJFADR/avu mMiQSk3cwVJtsk9dcMSo= X-Google-Smtp-Source: APXvYqx9j72M7AnEHpbm7sKcrC2j+nEDyA+DHgDEkoqom3O/KOS03rgergtJRY4rTOb3VvCdXmcZLsxrJ6KxjOFb0uU= X-Received: by 2002:a6b:6e01:: with SMTP id d1mr173086ioh.156.1562346313563; Fri, 05 Jul 2019 10:05:13 -0700 (PDT) MIME-Version: 1.0 References: <154274344398.29963.11727425335350408375.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 5 Jul 2019 13:04:47 -0400 Message-ID: To: Alissa Cooper Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000009595a058cf219bd" Archived-At: Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:07:10 -0000 --00000000000009595a058cf219bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alissa, Having not heard anything more on the issue, I went ahead and made those changes to the Privacy Consideration section. I believe they address the question/concern in your DISCUSS ballot. As such, I'd respectfully request that you review the changes and clear the discuss. Thank you, Brian On Wed, Nov 28, 2018 at 1:38 PM Brian Campbell wrote: > Thank you, Alissa, for the review. Please see below for inline > comments/responses and note that this is also my response to your last > message on the related thread at > https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4 > > > On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper wrote: > >> Alissa Cooper has entered the following ballot position for >> draft-ietf-oauth-token-exchange-16: Discuss >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 6: The requirements around confidentiality here are weaker than >> in both >> RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why? >> > > I think the why of it is some unintentional drift in the language along > with my general reluctance in using the 2119 words out of a fear of > overusing them (which I'm admittedly inconsistent about but it certainly > manifested itself in this text). > > They should all say basically the same thing, which was really the intent= , > if the actual wording didn't end up that way. > > I think that changing a few of the little shoulds to big MUSTs or SHOULDs > would bring the requirements around confidentiality here in line with RFC > 7519 Sec. 12 and RFC 6749 Sec. 10.8.. That updated text would be as > follows. Would this address your question/concern? > > Tokens employed in the context of the functionality described herein > may contain privacy-sensitive information and, to prevent disclosure > of such information to unintended parties, MUST only be transmitted > over encrypted channels, such as Transport Layer Security (TLS). In > cases where it is desirable to prevent disclosure of certain > information to the client, the token MUST be encrypted to its > intended recipient. Deployments SHOULD determine the minimally > necessary amount of data and only include such information in issued > tokens. In some cases, data minimization may include representing > only an anonymous or pseudonymous user. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 3: >> >> If I understand this correctly: >> >> "The distinction between an access token and a JWT is subtle." >> >> I think it would be clearer if it said: >> >> "The distinction between an access token type and a JWT token type is >> subtle." >> > > In that sentence and paragraph I'm really meaning to talk about the thing= s > themselves (access tokens and JWTs) rather than the type, which is more > like a way of naming those things. I don't think it's necessarily wrong > either way but my intention in writing is better reflected in the current > text. Furthermore, when the acronym in "JWT token" is expanded you get > "JSON Web Token token", which is something I'd like to avoid having in th= e > document. > > > >> Section 4.1: >> >> What is the value of maintaining the whole delegation chain rather than >> expressing just the most recent delegation? Doesn't it potentially expos= e >> information about past exchanges unnecessarily? >> > > There's value, in some situations, to being able to see/track the whole > delegation chain - primarily for auditing and troubleshooting type purpos= es > and typically when the parties in the chain are under the same domain of > organizational control where allowing that information to be available > isn't a concern but rather a benefit. > > And, of course, there's no requirement that the whole delegation chain be > maintained. The syntax and structure of the claim allows for the info to = be > represented when appropriate but doesn't mean that it has to be. > > > --=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._ --00000000000009595a058cf219bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alissa,

Having not heard any= thing more on the issue, I went ahead and made those changes to the Privacy= Consideration section. I believe they address the question/concern in your= DISCUSS ballot. As such, I'd respectfully request that you review the = changes and clear the discuss.

Thank you,
Brian

On Wed, Nov 28, 2018 at 1:38 PM Brian Campbell <bcampbell@pingiden= tity.com> wrote:
Thank you, Alissa, for the review. = Please see below for inline comments/responses and note that this is also m= y response to your last message on the related thread at https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB3= 8nWv4


On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper <alissa@cooperw.in> wrote:
Alissa Cooper has = entered the following ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/



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

Section 6: The requirements around confidentiality here are weaker than in = both
RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?

I think the why of it is some unintentional drift in the language al= ong with my general reluctance in using the 2119 words out of a fear of ove= rusing them (which I'm admittedly inconsistent about but it certainly m= anifested itself in this text).
=C2=A0
They shoul= d all say basically the same thing, which was really the intent, if the act= ual wording didn't end up that way.

I think th= at changing a few of the little shoulds to big MUSTs or SHOULDs would bring= the requirements around confidentiality here in line with RFC 7519 Sec. 12= and RFC 6749 Sec. 10.8.. That updated text would be as follows. Would this= address your question/concern?=C2=A0 
   Tokens employed in the context of the functionality descri=
bed herein
   may contain privacy-sensitive information and, to prevent disclosure
   of such information to unintended parties, MUST only be transmitted
   over encrypted channels, such as Transport Layer Security (TLS).  In
   cases where it is desirable to prevent disclosure of certain
   information to the client, the token MUST be encrypted to its
   intended recipient.  Deployments SHOULD determine the minimally
   necessary amount of data and only include such information in issued
   tokens.  In some cases, data minimization may include representing
   only an anonymous or pseudonymous user.


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

Section 3:

If I understand this correctly:

"The distinction between an access token and a JWT is subtle."
I think it would be clearer if it said:

"The distinction between an access token type and a JWT token type is = subtle."

In that sentence and para= graph I'm really meaning to talk about the things themselves (access to= kens and JWTs) rather than the type, which is more like a way of naming tho= se things. I don't think it's necessarily wrong either way but my i= ntention in writing is better reflected in the current text. Furthermore, w= hen the acronym in "JWT token" is expanded you get "JSON Web= Token token", which is something I'd like to avoid having in the = document.=C2=A0

=C2=A0
Section 4.1:

What is the value of maintaining the whole delegation chain rather than
expressing just the most recent delegation? Doesn't it potentially expo= se
information about past exchanges unnecessarily?

There's value, in some situations, to being able to see/track = the whole delegation chain - primarily for auditing and troubleshooting typ= e purposes and typically when the parties in the chain are under the same d= omain of organizational control where allowing that information to be avail= able isn't a concern but rather a benefit.

And, of course, there's no requirement that the whole delegation chai= n be maintained. The syntax and structure of the claim allows for the info = to be represented when appropriate but doesn't mean that it has to be. =



<= 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. --00000000000009595a058cf219bd-- From nobody Fri Jul 5 10:09: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 8E9C41200EB for ; Fri, 5 Jul 2019 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r74NSaozZ1im for ; Fri, 5 Jul 2019 10:08:55 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3751200EF for ; Fri, 5 Jul 2019 10:08:55 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id o9so4927982iom.3 for ; Fri, 05 Jul 2019 10:08:55 -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=LjlKKKRE4O3W3zx+JakqyJ/rYx9x0CVksKthpe3Jd6Y=; b=OUgKDxPy7iFuDwwfnJ7p9qcVLNIXUdI2W1DkdSNlJxPIz0HuL4eEDryHT1M8KSAn+5 iapiVBBy5xwAg7N0Tsshg/WAyYeSPbaEKeLYP5rtotSG0MbQo4dycl49WILgn3htgdFN STVzbcEDcodMYlbnA/rf4s05oTaggRdmjviTU= 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=LjlKKKRE4O3W3zx+JakqyJ/rYx9x0CVksKthpe3Jd6Y=; b=eSG3TJrFttDsWSBikUHdw8Wyv5PDitOYBdQMtFEEW9pmZHUGCWLgih5WJZXNOLibzT g6jI7rNpO7Q96jpO2StSXnMXgomplPMdFY+k4XrzS20jwlYilHWCh9Z6HtGZio05dKMZ 5mtHIv5tNiUHShvx3y26FxHa04+uM7t5LipPSKXXfYNp0KyMmO3J51u+B/JsrFVyEGZ4 J7dUqvTTNcGH2d9nwh4RvnlP2oHjG4q/C2Dq5YDtXWZ22z3/SBgl/l1GIJvLqr9/4L+A FYvSlqksPQkdLaDQ8+su9U5Kg1B3ESgYrf78Jr/iRhlEM/1QOo1aJltPSZf0lZxE5f97 EBOg== X-Gm-Message-State: APjAAAVtqLr4u024W8IsgyyT3sD8zbrPnC6b/tYE0UHjFfulUXyOhNDr zJ8gg8VTKhcnZorTF/tYGVz34IQINopy5Lq5YfJP9hBWVX89Sw90D5hGvdaIM/Ue9+sogFAcvtL vz30P/R8PN9OVOg== X-Google-Smtp-Source: APXvYqzREm+9pDhvgT9+JdDOwBcsoi5zzN1sB8AEcJpHv5G5JzeE3PEqOkEtAcatx/v0F29P9/kyKr8fjaodnpFVXQc= X-Received: by 2002:a6b:fd10:: with SMTP id c16mr4976208ioi.217.1562346534765; Fri, 05 Jul 2019 10:08:54 -0700 (PDT) MIME-Version: 1.0 References: <154275717351.29758.7019772753190449469.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 5 Jul 2019 13:08:28 -0400 Message-ID: To: Adam Roach Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000038a09f058cf22638" Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 17:08:59 -0000 --00000000000038a09f058cf22638 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adam, I went ahead and assumed that your silence constituted acceptance of the proposal to use RFC6749's Appendix B. on the "Use of application/x-www-form-urlencoded Media Type" as a citation for the media type. So I added that bit and also fixed the other nits you identified in -17 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17. As such, I'd respectfully request that you review the changes and clear the discuss. Thank you, Brian On Wed, Nov 28, 2018 at 8:19 AM Brian Campbell wrote: > Thank you for the review, Adam. I do sincerely hope that your time with > the document didn't drive you to drink (too much anyway). Please see belo= w > for inline comments/responses. > > On Tue, Nov 20, 2018 at 4:39 PM Adam Roach wrote: > >> Adam Roach has entered the following ballot position for >> draft-ietf-oauth-token-exchange-16: Discuss >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who worked on this document. I have a blocking issue >> that >> should be easy to resolve, and a handful of more minor issues. >> >> =C2=A72.1: >> >> > The client makes a token exchange request to the token endpoint with >> > an extension grant type by including the following parameters using >> > the "application/x-www-form-urlencoded" format >> >> This document needs a normative citation for this media type. >> >> My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as >> this >> appears to be the most recent stable description of how to encode this >> media >> type. I'd love to hear rationale behind other citations being more >> appropriate, >> since I'm not entirely happy with the one I suggest above (given that >> it's been >> superseded by HTML 5.2); but every other plausible citation I can find i= s >> even >> less palatable (with HTML 5.2 itself having the drawback of not actually >> defining how to encode the media type, instead pointing to an unstable, >> unversioned document). >> > > What about a pointer to RFC6749's Appendix B. on the "Use of > application/x-www-form-urlencoded Media Type" > ? I had admittedly > forgot about it until looking back at the original OAuth 2.0 document as = a > result of you raising this DISCUSS to see what citation was used there. > > Despite citing an older HTML document I think the few paragraphs there do > a nice job of explaining the situation in a pragmatic and actionable way. > And as the original OAuth 2.0 Authorization Framework is responsible for > the use of "application/x-www-form-urlencoded" in extensions like this > token exchange, it seems fitting to point back to it. > > I'm happy to cite REC-html5-20141028 section 4.10.22.6, if you feel that'= s > more appropriate. But wanted to throw that other idea out there to see if > you find that any more palatable. > > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Abstract: >> >> > This specification defines a protocol for an HTTP- and JSON- based >> >> Nit: "...JSON-based..." >> >> > Will fix. > > > >> >> ------------------------------------------------------------------------= --- >> >> =C2=A71.1: >> >> > impersonates principal B, then in so far as any entity receiving such >> >> Nit: "insofar" >> >> > This will be fixed insofar as you are right. > > > -------------------------------------------------------------------------= -- >> >> =C2=A72.1: >> >> > The client makes a token exchange request to the token endpoint with >> > an extension grant type by including the following parameters using >> > the "application/x-www-form-urlencoded" format with a character >> > encoding of UTF-8 in the HTTP request entity-body: >> >> I think there's an implication here that POST is used, but that probably >> needs >> to be made explicit. >> > > The use of POST is effectively inherited by token exchange utilizing an e= xtension > grant via the token > endpoint where the > 'client MUST use the HTTP "POST" method when making access token requests= '. > > But there's no harm in this document restating that its POST. So I'll > change it to make that explicit. > > > >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A72.2.1: >> >> > response using the "application/json" media type, as specified by >> > [RFC7159], and an HTTP 200 status code. The parameters are >> >> RFC 7159 has been replaced by RFC 8259. >> > > I remember feeling rather cutting edge 3ish years ago when using the RFC > 7159 citation rather than 4627. But times change. I'll update the documen= t > to cite 8259. > > > >> >> ------------------------------------------------------------------------= --- >> >> =C2=A73: >> >> > urn:ietf:params:oauth:token-type:refresh_token >> > Indicates that the token is an OAuth 2.0 refreshe token issued by >> >> nit: "refresh" >> > > I seem to have had a bit of a Freudian slip there revealing my affection > for (or addiction to) the cheap Safeway store brand of sparkling water. > I'll fix that in the document. > --=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._ --00000000000038a09f058cf22638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adam,

= I went ahead and assumed that your silence constituted acceptance of the pr= oposal to use RFC6749's Appendix B. on the "Use of application/x-w= ww-form-urlencoded Media Type" as a citation for the media type. So I = added that bit and also fixed the other nits you identified in -17 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17<= /a>. As such, I'd respectfully request that you review the changes and = clear the discuss.



On Wed, Nov 28, 2018 at 8:19 AM Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:
<= div dir=3D"ltr">
Thank you for the revi= ew, Adam. I do sincerely hope that your time with the document didn't d= rive you to drink (too much anyway). Please see below for inline comments/r= esponses.=C2=A0

On= Tue, Nov 20, 2018 at 4:39 PM Adam Roach <adam@nostrum.com> wrote:
Adam Roach has entered the followin= g ballot position for
draft-ietf-oauth-token-exchange-16: Discuss

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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/



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

Thanks to everyone who worked on this document. I have a blocking issue tha= t
should be easy to resolve, and a handful of more minor issues.

=C2=A72.1:

>=C2=A0 The client makes a token exchange request to the token endpoint = with
>=C2=A0 an extension grant type by including the following parameters us= ing
>=C2=A0 the "application/x-www-form-urlencoded" format

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as thi= s
appears to be the most recent stable description of how to encode this medi= a
type. I'd love to hear rationale behind other citations being more appr= opriate,
since I'm not entirely happy with the one I suggest above (given that i= t's been
superseded by HTML 5.2); but every other plausible citation I can find is e= ven
less palatable (with HTML 5.2 itself having the drawback of not actually defining how to encode the media type, instead pointing to an unstable,
unversioned document).

What about a poi= nter to RFC6749's Appendix B. on the "Use of application/x-www= -form-urlencoded Media Type"? I had admittedly forgot about it unt= il looking back at the original OAuth 2.0 document as a result of you raisi= ng this DISCUSS to see what citation was used there.

Despite citing an older HTML document I think the few paragraphs there = do a nice job of explaining the situation in a pragmatic and actionable way= .=C2=A0 And as the original OAuth 2.0 Authorization Framework is responsibl= e for the use of "application/x-www-form-urlencoded" in extension= s like this token exchange, it seems fitting to point back to it.

I'm happy to cite REC-html5-20141028 section 4.10.22.6,= if you feel that's more appropriate. But wanted to throw that other id= ea out there to see if you find that any more palatable.
=C2= =A0



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

Abstract:

>=C2=A0 This specification defines a protocol for an HTTP- and JSON- bas= ed

Nit: "...JSON-based..."


Will fix.

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

=C2=A71.1:

>=C2=A0 impersonates principal B, then in so far as any entity receiving= such

Nit: "insofar"


This will be fixed insofar as you are = right.
=C2=A0

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

=C2=A72.1:

>=C2=A0 The client makes a token exchange request to the token endpoint = with
>=C2=A0 an extension grant type by including the following parameters us= ing
>=C2=A0 the "application/x-www-form-urlencoded" format with a = character
>=C2=A0 encoding of UTF-8 in the HTTP request entity-body:

I think there's an implication here that POST is used, but that probabl= y needs
to be made explicit.

The use of POST is= effectively inherited by token exchange utilizing an extension grant via the token endpoint where the 'client MUST use the HTTP &qu= ot;POST" method when making access token requests'.

But there's no harm in this document restating that its= POST. So I'll change it to make that explicit.

=C2=A0

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

=C2=A72.2.1:

>=C2=A0 response using the "application/json" media type, as s= pecified by
>=C2=A0 [RFC7159], and an HTTP 200 status code.=C2=A0 The parameters are=

RFC 7159 has been replaced by RFC 8259.

I remember feeling rather cutting edge 3ish years ago when using the RFC 7= 159 citation rather than 4627. But times change. I'll update the docume= nt to cite 8259.
=C2=A0


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

=C2=A73:

>=C2=A0 urn:ietf:params:oauth:token-type:refresh_token
>=C2=A0 =C2=A0 =C2=A0Indicates that the token is an OAuth 2.0 refreshe t= oken issued by

nit: "refresh"

I seem to have= had a bit of a Freudian slip there revealing my affection for (or addictio= n to) the cheap Safeway store brand of sparkling water. I'll fix that i= n the document.
<= /div>
<= 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. --00000000000038a09f058cf22638-- From nobody Fri Jul 5 13:09:37 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FEF120118; Fri, 5 Jul 2019 13:09:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156235736392.22030.15053165046861447006.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2019 13:09:23 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 20:09:24 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-token-exchange-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and comment points. From nobody Fri Jul 5 20:56:51 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 C741C120254; Fri, 5 Jul 2019 20:56:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2019 20:56:42 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 03:56:43 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-token-exchange-17: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting Yes; this document is solid and well-written. I do have a few additional (largely editorial) suggestions and a question or two, though. Section 2.1 The client makes a token exchange request to the token endpoint with an extension grant type using the HTTP "POST" method and including the following parameters using the "application/x-www-form- urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body as described in Appendix B of RFC6749 [RFC6749]. This is a really long sentence. I see how it got that way, and the RFC Editor staff will probably have some thoughts on how to reword it, but if you happen to have thoughts as well, feel free to have at it. Section 2.2.1 expires_in RECOMMENDED. The validity lifetime, in seconds, of the token issued by the authorization server. Oftentimes the client will not have the inclination or capability to inspect the content of the token and this parameter provides a consistent and token type agnostic indication of how long the token can be expected to be valid. For example, the value 1800 denotes that the token will nit: hyphenate "token-type-agnostic". Section 4.4 Refresh my memory: did we already have a discussion about may_act as an object vs. an array of objects? Section 5 I'd consider also mentioning/linking the OAuth 2.0 security considerations -- the fact that the STS is colocated with the token endpoint takes care of ensuring a lot of its security properties. Section 7 It's common (but not required, since it will not be relevant upon publication as an RFC) to note that the indicated values are reflected in early allocations from the indicated IANA registries. In this case I'd say "don't bother"... Appendix B Uh-oh, now we are up to five security ADs that have been around for this document... From nobody Sat Jul 6 06:00: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 E34ED1201A2 for ; Sat, 6 Jul 2019 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NJeYeHBaE3Oe for ; Sat, 6 Jul 2019 05:59:57 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD21C120048 for ; Sat, 6 Jul 2019 05:59:56 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id g20so3735685ioc.12 for ; Sat, 06 Jul 2019 05:59:56 -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=/h0CSDMfrKNSBLGbBNt64d255e6fPGYsYwC1IrhGmNY=; b=ijuhoyeH4o0mUyPPGws2ffjdg10CAoXggSgRNdGJX8wMWShTbmRIRdE62LI6+Bd7JM OeJbcOjV97Z0rh1yZMTQyntQj1FfAJZSrZ1EaWnJQNZgxhPq39KY/gcuoSTXEQz900go 1PV3ObTJMtumKJvWEiglwwUJQfPtdjljxPSlM= 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=/h0CSDMfrKNSBLGbBNt64d255e6fPGYsYwC1IrhGmNY=; b=QjJBd64cBpvbXgZzWi6fcGPm9Z4gzWQUmdRP4/56wW8Tklp6RSxJCFZnr+bsBaZQQ8 wnzs2hdk+3Wswk6lA7XB16/cpLYxuQEAzhukzNCPe7+qHtueK50tTqUeiYD3u+Dt3A2b /ofvxspQr31aIKN5No36PpDi1SW0VzJ+77YjOZlAZj5QZXjymBS6e4jd6b8NII//ZrxU c0APd8H5nd4d1Z8gqg5M/dpDpK5vMgPgfIKZuBgXK8L52moLJOn79DU9DpHem/hILT2f mirb7hYzeGqYBO69uQOG7Tz0U2ODKYGmBCPT8+FgYaNh6EN/oSeLwaJfoopBlV4zXYpW NfOw== X-Gm-Message-State: APjAAAXbgxPJlksHcAm3/iq+eYku89TeOf0meYsjmYsmkhHsObB1ne8T Vi+NXgNV9dZ+i/VC8fusgRVWR1aX7uBUsIvrKgYMxOt2P9W7RdTA0c2XXGrDIuUKfY2XVSgecCz CUK5BWrgmeE10Ig== X-Google-Smtp-Source: APXvYqzoklKXePlRNFBm4EpEHwudloxuc+CDtP09ySH/etpseRPqij3sXZpKx2TJUtyxU09NMOJ+PKr7T9OfWLbnT+Y= X-Received: by 2002:a02:a07:: with SMTP id 7mr10389867jaw.65.1562417996097; Sat, 06 Jul 2019 05:59:56 -0700 (PDT) MIME-Version: 1.0 References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> In-Reply-To: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Sat, 6 Jul 2019 08:59:30 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a60494058d02c947" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 13:00:00 -0000 --000000000000a60494058d02c947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more detail is inline below. On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting Yes; this document is solid and well-written. Thanks! I do have a > few additional (largely editorial) suggestions and a question or two, > though. > > Section 2.1 > > The client makes a token exchange request to the token endpoint with > an extension grant type using the HTTP "POST" method and including > the following parameters using the "application/x-www-form- > urlencoded" format with a character encoding of UTF-8 in the HTTP > request entity-body as described in Appendix B of RFC6749 [RFC6749]. > > This is a really long sentence. I see how it got that way, and the RFC > Editor staff will probably have some thoughts on how to reword it, but > if you happen to have thoughts as well, feel free to have at it. > I had at it a little bit and broke it up into two sentences. > > Section 2.2.1 > > expires_in > RECOMMENDED. The validity lifetime, in seconds, of the token > issued by the authorization server. Oftentimes the client will > not have the inclination or capability to inspect the content of > the token and this parameter provides a consistent and token type > agnostic indication of how long the token can be expected to be > valid. For example, the value 1800 denotes that the token will > > nit: hyphenate "token-type-agnostic". > done > Section 4.4 > > Refresh my memory: did we already have a discussion about may_act as an > object vs. an array of objects? > Not to my recollection. I'm honestly not even sure what an array would mean for "may_act". Do you mean for "act"? I suppose an array of objects could be used as the value of "act" as a way to express a chain of delegation. However, the object with optional nesting seemed (to me) a more natural way to express it and has no overhead for the likely most common case of just a single actor. > > Section 5 > > I'd consider also mentioning/linking the OAuth 2.0 security > considerations -- the fact that the STS is colocated with the token > endpoint takes care of ensuring a lot of its security properties. > Makes sense. I'll add that. And refs to RFC6819 and draft-ietf-oauth-security-topics to round it out. > Section 7 > > It's common (but not required, since it will not be relevant upon > publication as an RFC) to note that the indicated values are reflected > in early allocations from the indicated IANA registries. In this case > I'd say "don't bother"... > Not bothering... > Appendix B > > Uh-oh, now we are up to five security ADs that have been around for this > document... > an oversight on my part and unfortunate reminder about just how long this document has been in progress. I'll add Roman. --=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._ --000000000000a60494058d02c947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben, I'll publish an -18 shortly with thes= e suggestions. A bit more detail is inline below.

=
On Fri= , Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:

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

I'm balloting Yes; this document is solid and well-written.

Thanks!
=C2=A0

=C2=A0 I do have a
few additional (largely editorial) suggestions and a question or two,
though.

Section 2.1

=C2=A0 =C2=A0The client makes a token exchange request to the token endpoin= t with
=C2=A0 =C2=A0an extension grant type using the HTTP "POST" method= and including
=C2=A0 =C2=A0the following parameters using the "application/x-www-for= m-
=C2=A0 =C2=A0urlencoded" format with a character encoding of UTF-8 in = the HTTP
=C2=A0 =C2=A0request entity-body as described in Appendix B of RFC6749 [RFC= 6749].

This is a really long sentence.=C2=A0 I see how it got that way, and the RF= C
Editor staff will probably have some thoughts on how to reword it, but
if you happen to have thoughts as well, feel free to have at it.

I had at it a little bit and broke it up into two= sentences.

=C2=A0

Section 2.2.1

=C2=A0 =C2=A0expires_in
=C2=A0 =C2=A0 =C2=A0 RECOMMENDED.=C2=A0 The validity lifetime, in seconds, = of the token
=C2=A0 =C2=A0 =C2=A0 issued by the authorization server.=C2=A0 Oftentimes t= he client will
=C2=A0 =C2=A0 =C2=A0 not have the inclination or capability to inspect the = content of
=C2=A0 =C2=A0 =C2=A0 the token and this parameter provides a consistent and= token type
=C2=A0 =C2=A0 =C2=A0 agnostic indication of how long the token can be expec= ted to be
=C2=A0 =C2=A0 =C2=A0 valid.=C2=A0 For example, the value 1800 denotes that = the token will

nit: hyphenate "token-type-agnostic".

done
=C2=A0


Section 4.4

Refresh my memory: did we already have a discussion about may_act as an
object vs. an array of objects?

Not to = my recollection. I'm honestly not even sure what an array would mean fo= r "may_act". Do you mean for "act"? I suppose an array = of objects could be used as the value of "act" as a way to expres= s a chain of delegation. However, the object with optional nesting seemed (= to me) a more natural way to express it and has no overhead for the likely = most common case of just a single actor.


=
=C2=A0

Section 5

I'd consider also mentioning/linking the OAuth 2.0 security
considerations -- the fact that the STS is colocated with the token
endpoint takes care of ensuring a lot of its security properties.

Makes sense. I'll add that. And refs to RFC6= 819 and draft-ietf-oauth-security-topics to round it out.
= =C2=A0


Appendix B

Uh-oh, now we are up to five security ADs that have been around for this document...

<sigh> an oversight o= n my part and unfortunate reminder about just how long this document has be= en in progress.

I'll add Roman.




<= 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. --000000000000a60494058d02c947-- From nobody Sat Jul 6 06:03:37 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07071120018; Sat, 6 Jul 2019 06:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156241821494.15191.8521431058497835090@ietfa.amsl.com> Date: Sat, 06 Jul 2019 06:03:35 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-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: Sat, 06 Jul 2019 13:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-18.txt Pages : 36 Date : 2019-07-06 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-18 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-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 Sat Jul 6 11:42: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 733C2120041; Sat, 6 Jul 2019 11:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs919JFbG26u; Sat, 6 Jul 2019 11:42:33 -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 923B912000E; Sat, 6 Jul 2019 11:42:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x66IgSjO019611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 6 Jul 2019 14:42:31 -0400 Date: Sat, 6 Jul 2019 13:42:27 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Message-ID: <20190706184226.GA13047@kduck.mit.edu> References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 18:42:37 -0000 On Sat, Jul 06, 2019 at 08:59:30AM -0400, Brian Campbell wrote: > Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more > detail is inline below. > > > On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm balloting Yes; this document is solid and well-written. > > > Thanks! > > > I do have a > > few additional (largely editorial) suggestions and a question or two, > > though. > > > > Section 2.1 > > > > The client makes a token exchange request to the token endpoint with > > an extension grant type using the HTTP "POST" method and including > > the following parameters using the "application/x-www-form- > > urlencoded" format with a character encoding of UTF-8 in the HTTP > > request entity-body as described in Appendix B of RFC6749 [RFC6749]. > > > > This is a really long sentence. I see how it got that way, and the RFC > > Editor staff will probably have some thoughts on how to reword it, but > > if you happen to have thoughts as well, feel free to have at it. > > > > I had at it a little bit and broke it up into two sentences. > > > > > > > Section 2.2.1 > > > > expires_in > > RECOMMENDED. The validity lifetime, in seconds, of the token > > issued by the authorization server. Oftentimes the client will > > not have the inclination or capability to inspect the content of > > the token and this parameter provides a consistent and token type > > agnostic indication of how long the token can be expected to be > > valid. For example, the value 1800 denotes that the token will > > > > nit: hyphenate "token-type-agnostic". > > > > done > > > > > Section 4.4 > > > > Refresh my memory: did we already have a discussion about may_act as an > > object vs. an array of objects? > > > > Not to my recollection. I'm honestly not even sure what an array would mean > for "may_act". Do you mean for "act"? I suppose an array of objects could > be used as the value of "act" as a way to express a chain of delegation. > However, the object with optional nesting seemed (to me) a more natural way > to express it and has no overhead for the likely most common case of just a > single actor. Currently we can say that admin@example.com "may act" as user@example.com. But IIUC we don't have a way to say that either admin1@example.com or admin2@example.com may do so. An array would let us indicate multiple authorized parties. I'm reluctant to actually make such a change at this point, though, since this is already deployed some places, right? -Ben > > > > > > > Section 5 > > > > I'd consider also mentioning/linking the OAuth 2.0 security > > considerations -- the fact that the STS is colocated with the token > > endpoint takes care of ensuring a lot of its security properties. > > > > Makes sense. I'll add that. And refs to RFC6819 and > draft-ietf-oauth-security-topics to round it out. > > > > > Section 7 > > > > It's common (but not required, since it will not be relevant upon > > publication as an RFC) to note that the indicated values are reflected > > in early allocations from the indicated IANA registries. In this case > > I'd say "don't bother"... > > > > Not bothering... > > > > > Appendix B > > > > Uh-oh, now we are up to five security ADs that have been around for this > > document... > > > > an oversight on my part and unfortunate reminder about just how long > this document has been in progress. > > I'll add Roman. > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.  If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ From nobody Sun Jul 7 06:32: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 4289712003E for ; Sun, 7 Jul 2019 06:32: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiUmwWC1pxD2 for ; Sun, 7 Jul 2019 06:32:44 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49848120058 for ; Sun, 7 Jul 2019 06:32:42 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id f4so13435591ioh.6 for ; Sun, 07 Jul 2019 06:32:42 -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=iczYxVLZnRRlfiQtZYM5J+uFP5CeB50Exzo2Ez+MQl4=; b=P50aw+1+FETtmR45WYjWL1bqTyA3EXn06lKLrXkanMt2L1KTjxbbs4z6HeHwXqXZWt UBh8V46E53oulielmsSh8UEzgMQ+klkZHqWOYR3qmDomWXyuTKO+hqKjP0J0J1czVhlA MZwcFvcjKEkVEfEjtjakbC+nihltxV0JH85D0= 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=iczYxVLZnRRlfiQtZYM5J+uFP5CeB50Exzo2Ez+MQl4=; b=hlSBjHGdSnC5BIORIIWbGq4vJWqqRs9JNVya8iWR2GE/P6D/6jaH+VGMoqRDHColyV 1222euujZb5QH4CiosHy6A+OMmEZALyMlIYvzSO5pDS3RC+uQ47jeXmP5tvj39mboh9f lUCDkot1KCbV2wIM/FrU3Prbt5puk2Lgn5NEQxaiPv6FNCOvowmRGgnV88zDfyIJI9Fr JSZ+/vHrzbpa9PeVUxTk239fZrhSZet905ePFge4ZPLiZJK38Zc8iyVWz1nxj7C/6fg4 d2ruiC9wSadyinT2ASemWoq0LWqwCtI7x9CUYSYj+WQvvkF3c10YTcdCBEEje0vjBqxh SecQ== X-Gm-Message-State: APjAAAWB86HZ/6c2SgDmUGHDd8DtCf+8pt/50SfQ/4ygIfMJ9iRAeHsE B3YbYbwARy32qu+O3uCPrZs1Uak/P4gNQ+t9cUwrIk1nMto9E8B/9vo/gSy2lDZZlm40o8I6zrz eW/5yyDHyQrH/Mt9r67g= X-Google-Smtp-Source: APXvYqynaK2EZyRfxphv5/Y9ncepaYifi9SKEMsBILyTfSJO+kH6DPh7/glT0pE/cVo0MbuDf6wHCYI2ZL4dMkRRk6o= X-Received: by 2002:a5e:d60a:: with SMTP id w10mr14547328iom.78.1562506361439; Sun, 07 Jul 2019 06:32:41 -0700 (PDT) MIME-Version: 1.0 References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> <20190706184226.GA13047@kduck.mit.edu> In-Reply-To: <20190706184226.GA13047@kduck.mit.edu> From: Brian Campbell Date: Sun, 7 Jul 2019 09:32:15 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a22e19058d175c4f" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 13:32:47 -0000 --000000000000a22e19058d175c4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > Not to my recollection. I'm honestly not even sure what an array would > mean > > for "may_act". Do you mean for "act"? > > Currently we can say that admin@example.com "may act" as user@example.com= . > But IIUC we don't have a way to say that either admin1@example.com or > admin2@example.com may do so. An array would let us indicate multiple > authorized parties. I'm reluctant to actually make such a change at this > point, though, since this is already deployed some places, right? > Okay, sorry, I'm a bit slow but I follow you now. Indeed this has been deployed in a number of places already. I'd honestly don't know if anyone is making use of this particular claim but changing from an object to array of objects would be a breaking change. And a breaking change is something I'd really like to avoid unless there's a very compelling reason to do so. And while your point here is taken, I don't think it rises to that level of compelling. I see two options at this point: 1) leave it as is 2) adjust the language around "may_act" such that it could also identify an eligible group - this would allow for it to indicate multiple authorized parties but just not by one by one name, which is maybe more desirable anyway What do you think? --=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._ --000000000000a22e19058d175c4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jul 6, 2019 at 2:42 PM Benjam= in Kaduk <kaduk@mit.e= du> wrote:
admin@example.com "may act" as user@example.com.
But IIUC we don't have a way to say that either admin1@example.com or
admin2@example.com<= /a> may do so.=C2=A0 An array would let us indicate multiple
authorized parties.=C2=A0 I'm reluctant to actually make such a change = at this
point, though, since this is already deployed some places, right?
=

Okay, sorry, I'm a bit slow but I foll= ow you now.=C2=A0

Indeed this has been deploy= ed in a number of places already. I'd honestly don't know if anyone= is making use of this particular claim but changing from an object to arra= y of objects would be a breaking change. And a breaking change is something= I'd really like to avoid unless there's a very compelling reason t= o do so.=C2=A0 And while your point here is taken, I don't think it ris= es to that level of compelling.

I see two options = at this point:
1) leave it as is
2) adjust the language= around=C2=A0 "may_act" such that it could also identify an eligi= ble group - this would allow for it to indicate multiple authorized parties= but just not by one by one name, which is maybe more desirable anyway
=

What do you think?

=

<= 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. --000000000000a22e19058d175c4f-- From will@icog.net Fri Jul 5 09:51:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7731200EF for ; Fri, 5 Jul 2019 09:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wdenniss-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 ie90APJo030D for ; Fri, 5 Jul 2019 09:51:22 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B33312008C for ; Fri, 5 Jul 2019 09:51:21 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id o9so4822858iom.3 for ; Fri, 05 Jul 2019 09:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wdenniss-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0rmORz94lq909qlyoaEZUlldybRaPm8TEs/XgI4z/zc=; b=Kb3eDjL5wLy5VJ40VB/e/7UwrEgs2W7KL+QO6+9zMHXEb05miRCgDz4rr1VPVwrpPt Xcl8d+czt448GUmOcZAqKDTaqXXnHvKgbStV6y3uI8K3466/809nB22mHmlJTziAke8j wt3Ol41rhBPRSH9aB/vgpp+bgFWeA68BSp0QUwi0dBjaWIHZs4RTN2jX18/vEXHJyLNd pZHlA2G2Hn36VJKokpA8JTqQbZi50FU4NTjL9kkNfj5gQgMCC8lbIJe8o4iuigBkOXzt bqR1GmUgzAy8Jw8cAAdP0IbGuorfcwCuw7xsayGDcOXHAuxshrb0BI4yuwfQqyAgyYUb aHiw== 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=0rmORz94lq909qlyoaEZUlldybRaPm8TEs/XgI4z/zc=; b=k19F8mkpBGSFgS7401BkRbi5ob9lNMEWaj5mnRPNtjkkWpneFnrGpDVXOul6pfoUzX EHrfC0s/3iYLXCBUX58ur4pjrfoU9j5ZHIOqtdhjpLD1esYrn1op/tqBDOW6HG+lfSoh l8zRNJL2bFV1ZpauVSOcOgTXJAawyZ43GNAo+w+CQ44WQiexb+1PWDLm4sbyYba5vCe2 M1qqzkZVYus/ZJsgL1qbH43sY88D0k9vObPZhqwfS32JNJGSeYp4awqp/C/0lfEIsNE/ 3hmISWCFbWBicnLwbjI2HcF95Y5cM9IApqfe/hkZZbh+PG4I/VrJov1JN8r/jPP0qh/Y gdJA== X-Gm-Message-State: APjAAAW1gR26dRbyWDtq/SvvtfwGbp9mZt8H5/8NGmhRp7PbH0j1aKhE YEXNFcglXqA51ide5QUGoDUW6c15wxUk3RYMr02sAw== X-Google-Smtp-Source: APXvYqzcaJ9wMtFRCxMxRNwwmH0sn4SkgXa6z/ZniT+xBme2XuMg/xAB748e1nr/Ij7u2MviAwU43CSFXS7C8AFpiQ0= X-Received: by 2002:a6b:7d49:: with SMTP id d9mr5226893ioq.50.1562345481028; Fri, 05 Jul 2019 09:51:21 -0700 (PDT) MIME-Version: 1.0 References: <20190705135606.F345BB8223A@rfc-editor.org> In-Reply-To: <20190705135606.F345BB8223A@rfc-editor.org> From: William Denniss Date: Fri, 5 Jul 2019 09:51:12 -0700 Message-ID: To: RFC Errata System Cc: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com, dziekan.jan@gmail.com, oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000069db04058cf1e733" Archived-At: X-Mailman-Approved-At: Sun, 07 Jul 2019 08:19:27 -0700 Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776) X-BeenThere: oauth@ietf.org X-Mailman-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, 05 Jul 2019 21:49:29 -0000 --00000000000069db04058cf1e733 Content-Type: text/plain; charset="UTF-8" This is an issue with the HTML auto generation, not the normative document. I believe this errata should be rejected. William On Fri, 5 Jul 2019 at 06:56, RFC Errata System wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5776 > > -------------------------------------- > Type: Editorial > Reported by: Jan Dziekan > > Section: GLOBAL > > Original Text > ------------- > > > Corrected Text > -------------- > > > Notes > ----- > RFC8252 references specific Sections of RFC6749, however urls are pointing > to Sections in RFC8252. > For example, in Section 6 there is a statement "code grant type per > Section 4.1 of OAuth 2.0 [RFC6749]", where "Section 4.1" links to > https://tools.ietf.org/html/rfc8252#section-4.1 instead of > https://tools.ietf.org/html/rfc6749#section-4.1 > I have found such misplaced links in the following sections: 6, 8.2, 8.4, > 8.5, 8.6, 8.12 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > --00000000000069db04058cf1e733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is an issue with the HTML auto generation, not t= he normative document. I believe this errata should be rejected.
=
William

On Fri, 5 Jul 2019 at 06:56, RFC Errata System <rfc-editor@rfc-editor.org>= ; wrote:
The fol= lowing errata report has been submitted for RFC8252,
"OAuth 2.0 for Native Apps".

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

--------------------------------------
Type: Editorial
Reported by: Jan Dziekan <dziekan.jan@gmail.com>

Section: GLOBAL

Original Text
-------------


Corrected Text
--------------


Notes
-----
RFC8252 references specific Sections of RFC6749, however urls are pointing = to Sections in RFC8252.
For example, in Section 6 there is a statement "code grant type per Se= ction 4.1 of OAuth 2.0 [RFC6749]", where "Section 4.1" links= to https://tools.ietf.org/html/rfc8252#section-4.1 instead of https://tools.ietf.org/html/rfc6749#sec= tion-4.1
I have found such misplaced links in the following sections: 6, 8.2, 8.4, 8= .5, 8.6, 8.12

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

--------------------------------------
RFC8252 (draft-ietf-oauth-native-apps-12)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 for= Native Apps
Publication Date=C2=A0 =C2=A0 : October 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: W. Denniss, J. Bradley<= br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : BEST CURRENT PRACTICE Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authorization = Protocol
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--00000000000069db04058cf1e733-- From nobody Mon Jul 8 01:24: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 A007D120127 for ; Mon, 8 Jul 2019 01:24:45 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH5caFsRPglJ for ; Mon, 8 Jul 2019 01:24:43 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.2]) (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 DD5BB1200B6 for ; Mon, 8 Jul 2019 01:24:42 -0700 (PDT) Received: from [46.226.52.104] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id 09/56-11177-8CDF22D5; Mon, 08 Jul 2019 08:24:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRWlGSWpSXmKPExsVy8Nv7NN0Tf5V iDfacFrE4+fYVmwOjx5IlP5kCGKNYM/OS8isSWDNOfPjCWtCoXPH35B22Bsbv8l2MXBxCAmsY JXr+NTBCOOsZJSZ/usEE4RxglNh59Tp7FyMnB5uArsTmXUfAbBEBVYl9R6+A2cICghLb581kg oiLSbxcfIwFwtaTuNW6kxHEZhFQkfizYzoriM0r4C5xdd9SNhCbEaj++6k1YL3MAuISt57MB7 MlBAQkluw5zwxhi0q8fPyPFeQgXoG7LBJzF/2AKjKQ2Lp0HwuELSexftZ8NgjbTKJnw0xmiKE 5Eu+OL2KCWCwocXLmE7B6IaAHFv9qAarnAKq3kPh1nmMCo9gsJGfMQtI9C0k3RFxHYsHuT2wQ trbEsoWvmWHsMwceMyGLL2BkX8VokVSUmZ5RkpuYmaNraGCga2hopGtoaaprZGSgl1ilm6iXW qpbnlpcomuol1herFdcmZuck6KXl1qyiREYsykFh+/sYHw2643eIUZJDiYlUd6QVPlYIb6k/J TKjMTijPii0pzU4kOMMhwcShK88/8oxQoJFqWmp1akZeYA0wdMWoKDR0mEd+tvoDRvcUFibnF mOkTqFKMrx4SXcxcxcxw8Og9Ivvu5GEh+XLUESH4HkUIsefl5qVLivAdBZguANGeU5sGNhqW+ S4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJWEeQVApvBk5pXAXfAK6DgmoOPqIsGOK0lESEk1M C1mMJUJmjBLuOL7lobVyskrsp4VOx2N/Ou9L28Hs3GK8vRPrzeLCrlzrVn7ICfnFWPRTJ2w/V VzbVq/LuROXbqmtPvV/cWPJPfe9y2x/5Z05iHvUb3CF0Lts9vK6zqsbm9Q9srWuy4a657anxX sG+z01PpAqEXN787gWb9mLPnm8uD7qn0iZjIs7/7PMPFteh0kKPD42tmfRxYKX+9i2G3Rba43 NeGRbHPGn4PZPxa8yvoUMePV1/06ZpedVv7Ye3nZgnfXT2ZJChTN9nDKDDvuuJS3aXqN6xudH bf8J7O/+FK/V+blvQdPQ7zWWcVd3T65aKtdk66414cZZ00qqhcbXV744XCZktrsuYsPrqlTYi nOSDTUYi4qTgQA3ZbZTvgDAAA= X-Env-Sender: Lee_McGovern@swissre.com X-Msg-Ref: server-15.tower-268.messagelabs.com!1562574279!726533!1 X-Originating-IP: [193.246.239.102] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=swissre.com,-,- X-VirusChecked: Checked Received: (qmail 1062 invoked from network); 8 Jul 2019 08:24:40 -0000 Received: from edge.swissre.com (HELO edge.swissre.com) (193.246.239.102) by server-15.tower-268.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 8 Jul 2019 08:24:40 -0000 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by edge.swissre.com (193.246.239.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 10:24:38 +0200 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5009.corp.gwpnet.com (10.53.1.44) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 10:24:38 +0200 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1473.003; Mon, 8 Jul 2019 10:24:38 +0200 From: Lee McGovern To: "oauth@ietf.org" Thread-Topic: OBO Flow Thread-Index: AdU1ZjJ6jhtWavl2ShC7aP4dgKcQaA== Date: Mon, 8 Jul 2019 08:24:38 +0000 Message-ID: <3a0d6d1dd94240b9ad1e1f53dd7fe417@CHRP5009.corp.gwpnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2019-07-08T08:24:36.0988705Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.9] x-rcom-deduphash: 3ba13f93-363b-4d80-8778-82777fe4bd38 Content-Type: multipart/alternative; boundary="_000_3a0d6d1dd94240b9ad1e1f53dd7fe417CHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: Cp/xjltkJtKf69q45xWNxM3LJvUebDXGbVZfKwNID58= Archived-At: Subject: [OAUTH-WG] OBO Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 08:24:46 -0000 --_000_3a0d6d1dd94240b9ad1e1f53dd7fe417CHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does it appear strange that Microsoft have called their token exchange flo= w implementation (https://docs.microsoft.com/en-us/azure/active-directory/= develop/v2-oauth2-on-behalf-of-flow) On-Behalf-Of flow? I was under the im= pression that delegation was the core use case for oauth development i.e. = when Yelp wants access to your Google contacts a scope is defined and cons= ent is granted for that client to act on your behalf... Best, Lee McGovern | IAM Architect | Lee_McGovern@swissre.com This e-mail, including attachments, is intended for the person(s) or compa= ny named and may contain confidential and/or legally privileged informatio= n. Unauthorized disclosure, copying or use of this information may be unlawfu= l and is prohibited. If you are not the intended recipient, please delete = this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Elect= ronic Message Repository. If you do not wish the retention of potentially private e-mails=20by Swiss= Re, we strongly advise you not to use the Swiss Re e-mail account for any= private, non-business related communications. --_000_3a0d6d1dd94240b9ad1e1f53dd7fe417CHRP5009corpgwpnetcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Best,

 

Lee McGovern | IAM Architect | Lee_McGovern@swissre.com


This e-mail, including attachments, is intended for the person(s) or compa= ny named and may contain confidential and/or legally privileged informatio= n.
Unauthorized disclosure, copying or use of this information may be unlawfu= l and is prohibited. If you are not the intended recipient, please delete = this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Elect= ronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss R= e, we strongly advise you not to use the Swiss Re e-mail account for any p= rivate, non-business related communications.
--_000_3a0d6d1dd94240b9ad1e1f53dd7fe417CHRP5009corpgwpnetcom_-- From nobody Mon Jul 8 02:04:44 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 372751200E7; Mon, 8 Jul 2019 02:04:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156257667516.734.2766431022794278816@ietfa.amsl.com> Date: Mon, 08 Jul 2019 02:04:35 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 09:04:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-13.txt Pages : 43 Date : 2019-07-08 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 05:54:19 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 D980712021F; Mon, 8 Jul 2019 05:54:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156259044888.808.2545040196103489140.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2019 05:54:08 -0700 Archived-At: Subject: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:54:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-oauth-token-exchange-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT. Apologies for the delay on my part. From nobody Mon Jul 8 06:29: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 3BE54120182 for ; Mon, 8 Jul 2019 06:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 oM90KWlnw1Tu for ; Mon, 8 Jul 2019 06:29:53 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E49120178 for ; Mon, 8 Jul 2019 06:29:53 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q22so13382535iog.4 for ; Mon, 08 Jul 2019 06:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=VlJtt5WErJBPw0tepTymq4JIKYSu0LfyIPGUY8FVpM8=; b=XidF2mlP9HF9mD5KVTmK2G//txqzaB9OI4YQCTfOPMs28HAEZ6oh47EJ6BFCtFp7n3 8jc4FzJUuGCqvAuUp+ZawH5S++8q43VuKjaTyVq1YyqruZIxRxJelqdVmytYZ8AHaoCm fY5Drzwe04o639P3zECrjGT8qhRk9WnpIZkRQoBs4N757hhpF94dM3VCoL3OvT9aO3Tu b/Bw432GYF4PoSjcyGLJnkzwDe7+JBaHSdN1hW8IlvFxd7UanxmFmjVEBML+0stHMU6k Usjk/JjbgOtJAfS2bUPxqrFnnYtDinpYnSsZLHvNE9kC96TST6L7OnzHBkEsWfE4jHsL SclQ== 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=VlJtt5WErJBPw0tepTymq4JIKYSu0LfyIPGUY8FVpM8=; b=cRbMBWvsavcr4otiHuqCgQ2njrvAXkJFhCnjejwDn8+95DVvHKqqtPwd+UUECjSWm+ +rsgNZJvuIY99iLkrrV5YllkqnQwPKpcPmM4yUfXqg/Lj7T3YMw3xLndb8pCuE6Q3kxP knXo4RLcQ1Udhl2EU0rVvKC4/L0a+LPwhEdsHyXKYT64rJYNcE0gEzTUmBVTiyN+RR59 VRtlWpR6iyrzQATyVjUe8JnooIa3DNt38nYqnoe/ZoXf/EIWRiTolhwLFAGTA5lvKotD VMz6J8LZzVRRghy9OzSH5z5vM3yDcGv14z1gQx3nihM+aPUxVgeRnqKKhxSeEWLbIUwe +toA== X-Gm-Message-State: APjAAAXdFX0zNeR3gkKETveblk5EbPYP2SEknPJ7QxkmUTyvUEFbjvyT KEoyV0AkQJJuhpSicG1PTv9rGmBKEiWxlNjAIoElQcOJbto= X-Google-Smtp-Source: APXvYqxnhAGzZGl++aR+8GduMuuWsLw3TshH4q36fedgVD4xTfL1LlwA20+HyghPRavPTvM/Mcv/Knep1RMiKeCtl3o= X-Received: by 2002:a02:1948:: with SMTP id b69mr21613263jab.55.1562592592600; Mon, 08 Jul 2019 06:29:52 -0700 (PDT) MIME-Version: 1.0 From: Daniel Fett Date: Mon, 8 Jul 2019 15:29:41 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000692ae4058d2b7044" Archived-At: Subject: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:29:55 -0000 --000000000000692ae4058d2b7044 Content-Type: text/plain; charset="UTF-8" All, In preparation for the meeting in Montreal, I just uploaded a new version of the DPoP draft: https://tools.ietf.org/html/draft-fett-oauth-dpop-02 Please have a look and let me know what you think. We should make this a working group item soon. As you might have noticed, there is also a new version of the Security Best Current Practice draft: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 -Daniel --000000000000692ae4058d2b7044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

In preparation for the = meeting in Montreal, I just uploaded a new version of the DPoP draft:
=

Please have a look and let me know what you think. We should make this a = working group item soon.

As you might have noticed= , there is also a new version of the Security Best Current Practice draft: =

-Daniel
--000000000000692ae4058d2b7044-- From nobody Mon Jul 8 08:15: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 21F25120242 for ; Mon, 8 Jul 2019 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VpWWvDkygkBu for ; Mon, 8 Jul 2019 08:15:27 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A5512026F for ; Mon, 8 Jul 2019 08:15:27 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id r6so16568796oti.3 for ; Mon, 08 Jul 2019 08:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hx7lLcvO+1PuP8Z9NFD641cz+nxIGNs5rOxjeNUweFs=; b=ur5MxVOEgJh+L5Rc1zDVhE0SfEdR6c4tQheCXVUnT7O+c5rIZJ8AVY79NN68vy3pfP Dq7SRxtZ2e1ueOmHg2i1ciJtO7SRgOq93PPssSX6cCVafvCbbJFV19RGlGy6ZkLpWt5+ FygB/FwhSlJhztav6w+j52dgydptGzr+ej9UwzlqBdmfhlinUJ2kw3QT9LmyBczeTyWa mLa8+CXnDol5fmAKBctcmP2/40rRYcpUxKDd6gKqJWbArIO2QFPvar4t1Uzh9e6SLSqo nk0zktIQ0hsr5gGZenOzRfpgCGrWY/8jDKEOPThvLftpsxK9GqiQcG8EBAbYeTC9kHwl 2pjw== 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=hx7lLcvO+1PuP8Z9NFD641cz+nxIGNs5rOxjeNUweFs=; b=MY3M8iv3pkw6qhOtriq9F3NQCdxbKmH4DcHOpWJYqk7zDl/FXZIFI4RhXHqnO34d7B TJbmc7XNW3cYN6EFEznURQJcal7aaPH0cfKzprBt39TLiMfFY2mFQWfxDIxK0eN+APs7 B6dnJOO5DQz7sGQCJa9zKem13PvBJhGIpFG5ONirKBMLfZkiAXlY/M5uOADShIcav2IF yRxhV/6DXzUkQOKxbm3Vt5I0vIBPYHyYgFA8C8f1P5bGOpW9XiocqeEuzuz5Htf4exSr 2IqY4e/wAKQl64Qosxp+oB4jACRkiOP/uToSD8fCFDcTfvbb0Ium45jZCx3JwwronW7K Jhag== X-Gm-Message-State: APjAAAU1QKWA729eJczAHYGI6RoS5nNv0hhNYLvenWW6Z+rrOWtwuq7S tJal2kMMO9AC+SflUI4udclhc72ViFg77LMv5fthgGND/A== X-Google-Smtp-Source: APXvYqyo7t3etSa2jwhzIbnuiREsiO33DHLEcDzK0E9kkeZgQGViSWSBk6EdKekzbJfmACGMY9Wb6DoUyAnx2HcJpPo= X-Received: by 2002:a9d:7a4e:: with SMTP id z14mr15576675otm.258.1562598926279; Mon, 08 Jul 2019 08:15:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Mon, 8 Jul 2019 17:15:15 +0200 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="000000000000ed690b058d2ce95d" Archived-At: Subject: Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 15:15:37 -0000 --000000000000ed690b058d2ce95d Content-Type: text/plain; charset="UTF-8" I've updated my OP projects draft implementation to 02 as well as the example browser based client using DPoP for those interested RP: https://murmuring-journey-60982.herokuapp.com OP: https://op.panva.cz/.well-known/openid-configuration As I've mentioned in the github issue tracker i think a server discovery medatata will be needed so that the RP can know upfront which DSAs are supported on the OP side to validate DPoP Proof JWTs with Best, *Filip Skokan* On Mon, 8 Jul 2019 at 15:30, Daniel Fett wrote: > All, > > In preparation for the meeting in Montreal, I just uploaded a new version > of the DPoP draft: > https://tools.ietf.org/html/draft-fett-oauth-dpop-02 > > Please have a look and let me know what you think. We should make this a > working group item soon. > > As you might have noticed, there is also a new version of the Security > Best Current Practice draft: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > -Daniel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ed690b058d2ce95d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've updated my OP projects draft implementation to 02= as well as the example browser based client using DPoP for those intereste= d


=
As I've mentioned in the github issue tracker i think a server dis= covery medatata will be needed so that the RP can know upfront which DSAs a= re supported on the OP side to validate DPoP Proof JWTs with
<= br clear=3D"all">
Best,
Filip Skokan

=

On Mon, 8 Jul 2019 at 15:30, Daniel Fett <danielf+oauth@yes.com> wrote:
All,

In preparation for the meeting in Montreal, I just u= ploaded a new version of the DPoP draft:

Please ha= ve a look and let me know what you think. We should make this a working gro= up item soon.

As you might have noticed, there is = also a new version of the Security Best Current Practice draft:
<= div>https://tools.ietf.org/html/draft-ietf-oauth-securit= y-topics-13

-Daniel
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ed690b058d2ce95d-- From nobody Mon Jul 8 11:21: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 CCA0C120699 for ; Mon, 8 Jul 2019 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pcyCcf9wbVby for ; Mon, 8 Jul 2019 11:20:56 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7121202E9 for ; Mon, 8 Jul 2019 11:20:41 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id m24so27966533ioo.2 for ; Mon, 08 Jul 2019 11:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=TEcJd3mh9V14Zd1HUWl4QdIuhDyIqwU1n+B4IYED23Q=; b=K7t84uEAqw08iAuT0sLBFrelLsHD/PLOqKRFck7jeGZ47aFTQ12RR9bO2g+JMd3fMy pMmrKMhDgiUVaeFPvvKrR5X8GPu4fghhSuMpKy6ufRhZJ5oUkrgwboExZOPQxqpiTYaA AkDVpckZA+JyPX/r9TVvR9Vv1kS/99zFWBRy8fs3lNE5Wg8vhq0K3H2DoUiWqeYCRUEO hs1v0kbhrvz9InxVhidGtwWTltW6fAKxBqV4hegxqB4+2mcOoaaSyXE+sZZ3KPXe8Xy4 DUV17Sm3bgX9iE+xi6sQj6XOM5Cka25xP0+98jpSKPQraoNESzMZVuh5RjdF/nIT3WcH GBdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TEcJd3mh9V14Zd1HUWl4QdIuhDyIqwU1n+B4IYED23Q=; b=KCGRUP/WNLRYVU28AoZPRd+grpy+diHTTzc2RDpLhuqmxHeckEe0iMGZWUhjqdm1L1 lIl3MwdneRZhruFuIgNl+WeOrg8rd2/w69uNKjbRpiUf8w15phrJ1QTSve+5CzUqqSpH iXc03Yqtx3/NTKwAVaBLWR45pQTtP1qomFaSe0smDFl0Xl2BrXcELauofpt6CedZx2oT 6jpD19053TiEWebKd85xAWX0xDTqNVvA2PCS0Jf5Jzcs+yPFAAQQ4bpr9v5iMv8VFKbt ftgR8RQjM86SQKcW4wsJEMXP7wpOqnqFIvhJeTSDU1HyFJpkd7jfBeTsvt4vmJsTVYLr o1MA== X-Gm-Message-State: APjAAAXbvNH+HZUqeCNstXJZ2p6DlMFMZe7+k/um+WPjhy4wYEbD6lmA 8Gk0nmCGWVJPEeknFOwskoS0mQU2oOl3/+stFq/9WJ+F X-Google-Smtp-Source: APXvYqxI0lulXFP/GSyTGOdpzqCSCwtlyvXOzqZhDybuSSd7Ce7SarTO2Aog5g0jtY9lGLaHCaiN3hWM1slPN/DsqKI= X-Received: by 2002:a5e:d618:: with SMTP id w24mr20823340iom.73.1562610040677; Mon, 08 Jul 2019 11:20:40 -0700 (PDT) MIME-Version: 1.0 References: <156260979358.887.5464253847395300154.idtracker@ietfa.amsl.com> In-Reply-To: <156260979358.887.5464253847395300154.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Mon, 8 Jul 2019 14:20:29 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000065a9e2058d2f802c" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-yusef-oauth-nested-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:21:07 -0000 --00000000000065a9e2058d2f802c Content-Type: text/plain; charset="UTF-8" All, I have updated this short draft with the use case that motivated this document. Please, take a look and let me know if you have any comments. Regards, Rifaat ---------- Forwarded message --------- From: Date: Mon, Jul 8, 2019 at 2:16 PM Subject: New Version Notification for draft-yusef-oauth-nested-jwt-01.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-oauth-nested-jwt-01.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-oauth-nested-jwt Revision: 01 Title: Nested JSON Web Token (JWT) Document date: 2019-07-08 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-yusef-oauth-nested-jwt-01.txt Status: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ Htmlized: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff: https://www.ietf.org/rfcdiff?url2=draft-yusef-oauth-nested-jwt-01 Abstract: This specification extends the scope of the Nested JSON Web Token (JWT) to allow the enclosing JWT to contain its own Claims Set in addition to the enclosed JWT. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000065a9e2058d2f802c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I have updated this short draft wi= th the use case that motivated this document.
Please, take=C2=A0a= look and let me know if you have=C2=A0any comments.

Regards,
=C2=A0Rifaat


---------- Forwarded= message ---------
From: <internet-drafts@ietf.org>
Date: Mon, J= ul 8, 2019 at 2:16 PM
Subject: New Version Notification for draft-yusef-= oauth-nested-jwt-01.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-oauth-nested-jwt-01.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-oauth-nested-jwt<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nested JSON Web Token (JWT)
Document date:=C2=A0 2019-07-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-yusef-oauth-ne= sted-jwt-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-yusef-oauth-nested-j= wt-01

Abstract:
=C2=A0 =C2=A0This specification extends the scope of the Nested JSON Web To= ken
=C2=A0 =C2=A0(JWT) to allow the enclosing JWT to contain its own Claims Set= in
=C2=A0 =C2=A0addition to the enclosed JWT.




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

The IETF Secretariat

--00000000000065a9e2058d2f802c-- From nobody Mon Jul 8 15:55:40 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F3120356; Mon, 8 Jul 2019 15:55:24 -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.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156262652452.1077.3483146258578174780@ietfa.amsl.com> Date: Mon, 08 Jul 2019 15:55:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-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: Mon, 08 Jul 2019 22:55:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-02.txt Pages : 18 Date : 2019-07-08 Abstract: OAuth 2.0 authorization requests from browser-based apps must be made using the authorization code grant with the PKCE extension, and should not be issued a client secret when registered. This specification details the security considerations that must be taken into account when developing browser-based applications, as well as best practices for how they can securely implement OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-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 Mon Jul 8 16:03: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 7600412033D for ; Mon, 8 Jul 2019 16:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 aN2w5J53Eaoy for ; Mon, 8 Jul 2019 16:03:24 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94942120305 for ; Mon, 8 Jul 2019 16:03:24 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q22so17257382iog.4 for ; Mon, 08 Jul 2019 16:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YpPCM/XsnpuHDihifrz6bZVoA34Nzo0zSlc4BmlxPtY=; b=YR64CJsrM7A5sa3yuw27gU+AuSF/WUAkGrL23XQXiLo5MzylgFeHJH3C5MHTShgeGN FRZbI919a6swVjAHAXMPyhel67lwnnc6+4cOOCa8aRUzLjDIDS0IO4A/uOfhNGLMwMEx qcPxfRx1afC32QXKO5gxVuVuM1vzgMVJhfsnsOsKG/W45JAGmtEUyDxCuxYjIOYg+oa8 vEKgHNWiKJZ22O4l4WXtCFsijMgKPNlAF7a4aBhttDNCx/kiZvHjIkDFG4sDFbYWXYO3 nVFkkKKUYrPY556QpUdNbe23a4Co08NuWh/OsDOeXD8mrB4oaVhjPoeHmY9HPmws60rC 0aYQ== 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=YpPCM/XsnpuHDihifrz6bZVoA34Nzo0zSlc4BmlxPtY=; b=B/73Kts3uR/izd+h2mh7u6x/lRXNhO58EcJIsRpGryekIjLFBzu8OXs5gwxqAl367g h+bpqk0MWFSjgw827N+5MZc9TL30fteVMAI5u4XHGH7Sytw3fiafcjr/8pShHIeTieWN k7FKIX/RiA/t2qp+K6ogMJSqIYSlcPGE4oOwYWhIbog28AHkToqPmQQNK3HPfh5162IS rS697qO1tGJApibBRTLgvltQfJOpZVefPigMN3rZ8NRfS9ZVw8eRrMMp3XQiWswnpPXb ys9bOYP4cQEJVvyIbP+pOupHgOkLBfhTJBeq5Jb7mYSGP9X91XvWp2owCfU2D0t/rmIQ T4dQ== X-Gm-Message-State: APjAAAVM7cwUutDlgEPIHiPX/15+nS94Vimm3lCTu7/9lgfgt1CXasxh qBXUZe2XfQMrEANbN86FkCcsmt6TF3w= X-Google-Smtp-Source: APXvYqxQUN9CsATJ1Cok3iWPv7MEDKCEjdYNVasfwl45kb2WcdWuJrNwnUwyVG9/FNVEcY/Us2ukgQ== X-Received: by 2002:a02:b68f:: with SMTP id i15mr24176029jam.107.1562627003607; Mon, 08 Jul 2019 16:03:23 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id c17sm16266645ioo.82.2019.07.08.16.03.23 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 16:03:23 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id k8so39150567iot.1 for ; Mon, 08 Jul 2019 16:03:23 -0700 (PDT) X-Received: by 2002:a6b:7a42:: with SMTP id k2mr15210061iop.214.1562627002936; Mon, 08 Jul 2019 16:03:22 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Mon, 8 Jul 2019 16:03:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000006d35dc058d3373a2" Archived-At: Subject: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:03:38 -0000 --0000000000006d35dc058d3373a2 Content-Type: text/plain; charset="UTF-8" Hi all, I've just uploaded a new version of oauth-browser-based-apps in preparation for the meeting in Montreal. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 This draft incorporates much of the feedback I've received over the last couple months, as well as what we discussed at the last meeting in Prague. The primary change is a significant rewrite and addition of Section 6 to highlight the two common deployment patterns, a SPA with and without a dynamic backend. Please have a look and let me know what you think. I have a slot in the agenda for Montreal to present on this as well. Thanks! ---- Aaron Parecki aaronparecki.com --0000000000006d35dc058d3373a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I've just upload= ed a new version of oauth-browser-based-apps in preparation for the meeting= in Montreal.=C2=A0


This = draft incorporates much of the feedback I've received over the last cou= ple months, as well as what we discussed at the last meeting in Prague.

The primary change is a significant rewrite and addit= ion of Section 6 to highlight the two common deployment patterns, a SPA wit= h and without a dynamic backend.=C2=A0

Please have= a look and let me know what you think. I have a slot in the agenda for Mon= treal to present on this as well.

Thanks!

----
Aaron Parecki

=
--0000000000006d35dc058d3373a2-- From nobody Mon Jul 8 17:44: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 67A7B120090 for ; Mon, 8 Jul 2019 17:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UUi2GWoA8HbX for ; Mon, 8 Jul 2019 17:44:43 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8053312023F for ; Mon, 8 Jul 2019 17:44:43 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id az7so1673336plb.5 for ; Mon, 08 Jul 2019 17:44:43 -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=8p/OkHqesq7qStWDom5uUp4ie3iV/3kCzVNO6jvYYYs=; b=pKzoElta7t6/ugXpt2xz6OemtDvz/funFYOguBpWym4SppdtOchVkbtfr+7h0VFHxj 6CqWTf2PqdOKzBD7LBOfAHpXzS2vbGC3FKL0VjL2DqbbLbJ3E9Z50CYGn1grzM1MzeRy 4/Q6oKg5BCVaY/KKxiaWXHAsUHDGobSWiVYPXaVALfDjuY39ZfNXOBHBa+X4tX+BndJ3 ZYA3W5L5JSZHo1k59cFe9XlPmQ102W73BIK1tCPL3gVZ5zD9PV/BGl1m6Bsa3KzGcZ28 byVxamjx0ypF7m/wfbEjLKFjpQNwaBEVm1hNMErwnZVnWdB3Wme07rcwZ2OXEtfgKbbX GQxA== 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=8p/OkHqesq7qStWDom5uUp4ie3iV/3kCzVNO6jvYYYs=; b=HCKYl9LwcFw/XXs63XCNVoRY0LUCDFQHaPf08HyH6J1gZjOVqklolugVhOW64gMNHb rx7E67Igqo72iNptuAzY6HBHzGtJxDsCCAPkTgrveu/lsYsxeHrKa44Z2sPCX9vapFGr UbNFPtXNK/NcODnO8eblhs2ry6iXRxznhQQHExsbm7SXVIcT6I3m1Mpq182s8/07LU+o 3rLXyQc+Y7YyoYlT4p8194UuNDbOY7HYZBW1CWk+tjjqzO9mDizZycM5PbKGMJFOExIa pQhySzxiqmdSuAXWQ8Lok9Y3D8+tahH44BddN3Pr0ni8Axmgbf/TPLcGD7JiSteQhaNS CFPw== X-Gm-Message-State: APjAAAWCjqTOz+YFTwISvXx645Ionab4PErsDNkIXZe6EiG1VlIFvEir 9asNRJHRk34gn/FwgSNS7KgZDqGm+Rniq2tIc3LXqqMPOXM= X-Google-Smtp-Source: APXvYqxOK72dCg0+LvmrUSB+pocOTQQuVugc/aghaJXSp7i/wjpd4RwaFlAbj2nGWjXmGsGuyOZ43V/XrTqFMmjh8pI= X-Received: by 2002:a17:902:4283:: with SMTP id h3mr27680227pld.15.1562633082779; Mon, 08 Jul 2019 17:44:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Leo Tohill Date: Mon, 8 Jul 2019 20:44:31 -0400 Message-ID: To: Aaron Parecki Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000d03c32058d34dd45" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 00:44:46 -0000 --000000000000d03c32058d34dd45 Content-Type: text/plain; charset="UTF-8" regarding 6.1. Apps Served from a Common Domain as the Resource Server Isn't this recommendation neglecting some benefits or use cases of Oauth? * An application that doesn't collect user credentials is an app that doesn't need to be audited for problems such as password leakage into log files. * Applications that offload authentication to a identity server can delegate to that server the complexities of MFA, password recovery,and the like. Of course these CAN be done in the app, but isn't it sometimes better to centralize those features in a identity server? Especially if the organization has multiple apps that require these features. I would soften " it is likely a better decision" to "it may be a better decision". Leo On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki wrote: > Hi all, > > I've just uploaded a new version of oauth-browser-based-apps in > preparation for the meeting in Montreal. > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 > > This draft incorporates much of the feedback I've received over the last > couple months, as well as what we discussed at the last meeting in Prague. > > The primary change is a significant rewrite and addition of Section 6 to > highlight the two common deployment patterns, a SPA with and without a > dynamic backend. > > Please have a look and let me know what you think. I have a slot in the > agenda for Montreal to present on this as well. > > Thanks! > > ---- > Aaron Parecki > aaronparecki.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d03c32058d34dd45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0regarding=20 6.1. Apps Served from a Common Domain as the Resource Server

I= sn't this recommendation neglecting some benefits=C2=A0 or use cases of= Oauth?=C2=A0

* An application that doesn'= ;t collect user credentials is an app that doesn't need to be audited f= or problems such as password leakage into log files.
* Appli= cations that offload authentication to a identity server can delegate to th= at server the complexities of MFA, password recovery,and the like.=C2=A0 Of= course these CAN be done in the app, but isn't it sometimes better to = centralize those features in a identity server?=C2=A0 Especially if the org= anization has multiple apps that require these features.

I would soften " it is likely a better decision"=C2=A0 to "it may be a better deci= sion".

Leo


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
=
Hi = all,

I've just uploaded a new version of oauth= -browser-based-apps in preparation for the meeting in Montreal.=C2=A0
=


This draft i= ncorporates much of the feedback I've received over the last couple mon= ths, as well as what we discussed at the last meeting in Prague.
=
The primary change is a significant rewrite and addition of = Section 6 to highlight the two common deployment patterns, a SPA with and w= ithout a dynamic backend.=C2=A0

Please have a look= and let me know what you think. I have a slot in the agenda for Montreal t= o present on this as well.

Thanks!

----
Aaron Parecki
<= a href=3D"http://aaronparecki.com" target=3D"_blank">aaronparecki.com

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d03c32058d34dd45-- From nobody Mon Jul 8 18:09: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 785B912024E for ; Mon, 8 Jul 2019 18:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vadnWC9PYHWK for ; Mon, 8 Jul 2019 18:09:05 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA2C120192 for ; Mon, 8 Jul 2019 18:09:05 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id m30so8420521pff.8 for ; Mon, 08 Jul 2019 18:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GgEIoW6cYH078rJlzEeyrH/syevpPHpbVi2l8D93KwE=; b=BWZMkSBUgB66dihicgqTTPzMuJTxMQguiGoXhG9dkmF93yfkHPL5NVw3Pemhe4FbLi ahnSXJi07nBHeY8OLr8fe9M+7aRBr6hlksqnA+sBzXAJhEWpByw6eQeFR/5GyaoJrRL6 N/Fze1IDFhLNhRndSmCo29+AkHIMNoikbxKeJi0QFUvzf1U7jJYUfMmykpZwtTL3Jdmw yhmq8JErfr9wBUx7y3pwllkOT36zcwwUe0EuEj2CmhHyRvkxvVCobMwtx4pEDyepen41 R7C1CQO5VTu3solYc5cXXtCXDN+HyPe35z4bUi7X70cr6CVAjdpiZ7j9NT13uH83K1f/ Bh1w== 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=GgEIoW6cYH078rJlzEeyrH/syevpPHpbVi2l8D93KwE=; b=tqdVbH40smfyzrMLf3r9LYFQCTacKeLsT0QI28L/2dAwvqJv7WUmX6Q5eM2Ud+uiyW iGAEas7tU8OhgFF+tK3hNmINem2Gw6+MC+ghccOoujdf0YIbznLgPZXbeolmkXhm1D6w BTO8q4P58RsQxsser2jz0XmzTkHXmaCAw3uZX7W+0UYkA2uzUYeo/Sb+oAP2tz4jw5tu tBKHM7Bzs0HqAQ7BAZEWbBw6RBZ90lg4+EuGC2TnhZubSyPWzgET3dccq3N9LWDN1aPi zvWshGG0oFvhrWZS7t3/0R1Q9mx0BGzHYizUI7+W27fTNURYyECfEwbrrqIxcJmuc51b U4ow== X-Gm-Message-State: APjAAAVkUrLHy38ZSSS9STuaRo0k6g4VZJUF1nCjgCqCdY2GNkZaTmlj zsaKhlXHpApDfwSxpQBV2ab4WnaJLJmrAbQI9AQ= X-Google-Smtp-Source: APXvYqyBz4IVNS2oGQOp9DCVdnzmr5niD/K9YbcpRpiUgf7HVpEe80ehRA5xroNm6U+zhuexHSnW6qxrwm9jKVsLtk4= X-Received: by 2002:a17:90a:338b:: with SMTP id n11mr28913559pjb.21.1562634544989; Mon, 08 Jul 2019 18:09:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Leo Tohill Date: Mon, 8 Jul 2019 21:08:53 -0400 Message-ID: To: Aaron Parecki Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000f7cc3c058d353444" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 01:09:08 -0000 --000000000000f7cc3c058d353444 Content-Type: text/plain; charset="UTF-8" (should I start a new thread instead of making multiple replies to this message?) Re: Sec Typo/grammar in: "First- party apps are applications where by the same organization that provides the API being accessed by the application." Suggested rewrite: "First- party apps are applications where the same organization provides both the api and the application." On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > regarding 6.1. Apps Served from a Common Domain as the Resource Server > > Isn't this recommendation neglecting some benefits or use cases of > Oauth? > > * An application that doesn't collect user credentials is an app that > doesn't need to be audited for problems such as password leakage into log > files. > * Applications that offload authentication to a identity server can > delegate to that server the complexities of MFA, password recovery,and the > like. Of course these CAN be done in the app, but isn't it sometimes > better to centralize those features in a identity server? Especially if > the organization has multiple apps that require these features. > > > I would soften " it is likely a better decision" to "it may be a better > decision". > > Leo > > > On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki wrote: > >> Hi all, >> >> I've just uploaded a new version of oauth-browser-based-apps in >> preparation for the meeting in Montreal. >> >> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 >> >> This draft incorporates much of the feedback I've received over the last >> couple months, as well as what we discussed at the last meeting in Prague. >> >> The primary change is a significant rewrite and addition of Section 6 to >> highlight the two common deployment patterns, a SPA with and without a >> dynamic backend. >> >> Please have a look and let me know what you think. I have a slot in the >> agenda for Montreal to present on this as well. >> >> Thanks! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000f7cc3c058d353444 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(should I start a new thread instead of making multip= le replies to this message?)

Re: Sec
Typ= o/grammar in:
"First- party apps are applications where = by the same organization that provides the API being accessed by the applic= ation."

Suggested rewrite:
"Fi= rst- party apps are applications where the same organization provides both = the api and the application."

On Mon, Jul 8, 2019 at 8:44 PM Leo = Tohill <leotohill@gmail.com&g= t; wrote:
=C2=A0regarding=20 6.1. Apps Served from a Common Domain as the Resource Server
=

Isn't this recommendation neglecting some ben= efits=C2=A0 or use cases of Oauth?=C2=A0

* An= application that doesn't collect user credentials is an app that doesn= 't need to be audited for problems such as password leakage into log fi= les.
* Applications that offload authentication to a identit= y server can delegate to that server the complexities of MFA, password reco= very,and the like.=C2=A0 Of course these CAN be done in the app, but isn= 9;t it sometimes better to centralize those features in a identity server?= =C2=A0 Especially if the organization has multiple apps that require these = features.


I would soften " it is likely a better decision"=C2=A0 to "it may be a better deci= sion".

Leo


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
=
Hi = all,

I've just uploaded a new version of oauth= -browser-based-apps in preparation for the meeting in Montreal.=C2=A0
=


This draft i= ncorporates much of the feedback I've received over the last couple mon= ths, as well as what we discussed at the last meeting in Prague.
=
The primary change is a significant rewrite and addition of = Section 6 to highlight the two common deployment patterns, a SPA with and w= ithout a dynamic backend.=C2=A0

Please have a look= and let me know what you think. I have a slot in the agenda for Montreal t= o present on this as well.

Thanks!

----
Aaron Parecki

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f7cc3c058d353444-- From nobody Mon Jul 8 18: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 B4726120096 for ; Mon, 8 Jul 2019 18:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 r8u-RoWUcp3W for ; Mon, 8 Jul 2019 18:13:04 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0CE120090 for ; Mon, 8 Jul 2019 18:13:00 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id r7so8438110pfl.3 for ; Mon, 08 Jul 2019 18:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+2EguXET8jbF913EtqSJRHxzdG3bT2ZsKoBDwSYXBM=; b=M1peP+FSTU33Os7sPZaLUESfvHKcz44DM5Lo3rFtAw3wsjwZ3t9NRBQMe9uegOLm9X jdVlS9MLyh35+JG2nVtn4K8/QpiV/GkzOLOrnjIzk3k2Lmj9YnwgwBd1e69gRzphiG7x NEuY7Zbk16v5X8x6IMl5pSZiJTApc4talqCqqrBSnWLb0sLWWnJpW1kshnpFH4yj2rrE ufk25fiVAYVohubLsPUOV6AfNL5D+Wd+YK7cRsz9pa6SciooH6/vq68WBM552Lb92b/F cokR2dUfCl4CVB5M4pNZoQZhurI6Z5Q80nVi+grNSSCjJdJVBLBSO65E0Jzb7aXvtI9o QZeA== 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=X+2EguXET8jbF913EtqSJRHxzdG3bT2ZsKoBDwSYXBM=; b=dBPrxOJ7JJTp9sSzHra5iy4ajMqjzErf/DFeGfHLaJJTcIKMi3YIUZ/w3iP2wxbgB8 3a1j9ZWMbKlRgAPuJ/dCo4JbLsk/eCUunguFhKzpKLrdrPosjOhLfngKhIVZ3utN3DSU hrqfRg1ha/ZR1lzlT5ZMh9VJxLi6aF7h6yRlvtljigvOuh4IDKl/wLXqqZx9ELPzeXIH VakfiZZcKoU5wG5w4vwHFUvvwfYiSZLe0l80XO7gvxwulg2L2twmtzOtYdm5h3TMxpWq z4jj/lhrHHQjomou2QlmpyyxQqAUWkCgpNhz6lcgcVqgNbVw6LXXMvzVTRabv9H1XfSh 4Hww== X-Gm-Message-State: APjAAAVxQ1Xb1bE5tU5CJ5ftljklK1q5hcmWHJyolb7jKZ1gNl1x5QGo QKJnRDxlRdmI6+3tDsopeV63iXLFaHYxFrTgyG+6QMkByWk= X-Google-Smtp-Source: APXvYqyHiCpfEf7GlVQ0ZDpO8TsqeQYQD04AfSGB1Mta6/jW3UBsBgnu2hytJQSzQT4wdtM4bRVx2tdP8DPD8J8yAFw= X-Received: by 2002:a63:8c0f:: with SMTP id m15mr27131039pgd.441.1562634779781; Mon, 08 Jul 2019 18:12:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Leo Tohill Date: Mon, 8 Jul 2019 21:12:48 -0400 Message-ID: To: Aaron Parecki Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000f66e40058d3542a0" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 01:13:07 -0000 --000000000000f66e40058d3542a0 Content-Type: text/plain; charset="UTF-8" I see now that my arguments for softening the 6.1 language are backed and expanded on by the last paragraph of section 5, starting with " By redirecting to the authorization server,..." On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > regarding 6.1. Apps Served from a Common Domain as the Resource Server > > Isn't this recommendation neglecting some benefits or use cases of > Oauth? > > * An application that doesn't collect user credentials is an app that > doesn't need to be audited for problems such as password leakage into log > files. > * Applications that offload authentication to a identity server can > delegate to that server the complexities of MFA, password recovery,and the > like. Of course these CAN be done in the app, but isn't it sometimes > better to centralize those features in a identity server? Especially if > the organization has multiple apps that require these features. > > > I would soften " it is likely a better decision" to "it may be a better > decision". > > Leo > > > On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki wrote: > >> Hi all, >> >> I've just uploaded a new version of oauth-browser-based-apps in >> preparation for the meeting in Montreal. >> >> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 >> >> This draft incorporates much of the feedback I've received over the last >> couple months, as well as what we discussed at the last meeting in Prague. >> >> The primary change is a significant rewrite and addition of Section 6 to >> highlight the two common deployment patterns, a SPA with and without a >> dynamic backend. >> >> Please have a look and let me know what you think. I have a slot in the >> agenda for Montreal to present on this as well. >> >> Thanks! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000f66e40058d3542a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see now that my arguments for softening the 6.1 language= are backed and expanded on by the last paragraph of section 5, starting wi= th " By redirecting to the authorization server,..."


On Mo= n, Jul 8, 2019 at 8:44 PM Leo Tohill <leotohill@gmail.com> wrote:
=C2=A0regarding=20 6.1. Apps Served from a Common Domain as the Resource Server
=

Isn't this recommendation neglecting some ben= efits=C2=A0 or use cases of Oauth?=C2=A0

* An= application that doesn't collect user credentials is an app that doesn= 't need to be audited for problems such as password leakage into log fi= les.
* Applications that offload authentication to a identit= y server can delegate to that server the complexities of MFA, password reco= very,and the like.=C2=A0 Of course these CAN be done in the app, but isn= 9;t it sometimes better to centralize those features in a identity server?= =C2=A0 Especially if the organization has multiple apps that require these = features.


I would soften " it is likely a better decision"=C2=A0 to "it may be a better deci= sion".

Leo


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
=
Hi = all,

I've just uploaded a new version of oauth= -browser-based-apps in preparation for the meeting in Montreal.=C2=A0
=


This draft i= ncorporates much of the feedback I've received over the last couple mon= ths, as well as what we discussed at the last meeting in Prague.
=
The primary change is a significant rewrite and addition of = Section 6 to highlight the two common deployment patterns, a SPA with and w= ithout a dynamic backend.=C2=A0

Please have a look= and let me know what you think. I have a slot in the agenda for Montreal t= o present on this as well.

Thanks!

----
Aaron Parecki

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f66e40058d3542a0-- From nobody Mon Jul 8 19:10: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 2F6B8120390 for ; Mon, 8 Jul 2019 19:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 S91WUgMH0YBg for ; Mon, 8 Jul 2019 19:10:29 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0: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 0677E120365 for ; Mon, 8 Jul 2019 19:10:28 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id i8so8581592pgm.13 for ; Mon, 08 Jul 2019 19:10:28 -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=UD04SfxctXv+GdutYCoixD4T/4L/snz6eYVNjpVVygY=; b=BboNM51/oOPF+Ix8ybAJzf5RyGLF+VT/IaYrfbyeXIpRvEgh7GTA602K4rq/NlbkAT yCTV59D7h5EGwG1fzYoaRLeW5wYgK+3bLrBgm9siKBtMsBVu+JHQpfxF8t4ZnquxWjz4 qTEAXfNmLXdN/ZZGK9v59lPglGw/835PX+lYZOSKUuTofseHpUV7YUaiuMjes0/ZgTaH 4pfgZgzsW1Lbckrd+mHDsdZPrzFL6fSuX/bJtEZIF9gpFSSs6Y1AzibewuBW4ero/0oQ 2f01e0M/i8TBVDLguFKf4tF9GbWN8MaMJcapLMD93iowOGI6hgpt/mFKk06sNDRZrr0L BmlQ== 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=UD04SfxctXv+GdutYCoixD4T/4L/snz6eYVNjpVVygY=; b=m/Oz0h6r9WBWi6SEr4mVlECB4wGkHqqkX0WCljayDNh7UvaNZNExDp44qW8FDnCu9D w/35LoA9/2peAg6Fwha5C7UJwVUn/8ho2E6d0CgdR5weHW+cV8bnCVoby3qjH7PHu+4q UbANOXstNtoRPdp9RXYvPpFdSbWaQ1CRpyVhhtQcnVDYqmHT5WK5ppD3EFvdc7ocDwPC yl8IqxNcinOX+lAR5gRfVfKEMuny/Eeq2LGM/OzzWv7UnbtXEQg9EuYq/AxRlTlkUmwd zKhrOinUfn88j1urM3fBShf87OK7YOWtFIQ5UTorOYHlplGdDXfud2Xrder85mC8j0VH HCQg== X-Gm-Message-State: APjAAAVsFM2BpKLzj/4ueT+nQyoV5EcoSCAImU28KaEXvE2SsDVIZyqE +DU/SuU31+wUJIFMkIkrakjLXTnTqsB1V0exe2qxJE0hb4Y= X-Google-Smtp-Source: APXvYqw46VGsvxL213KvyRhC/jwKkWqNWtGnpV+ZwwPGdap+oeNafvnRlUuWjddh4zI/kkAo54K5XfOYCOIgnw9JsvE= X-Received: by 2002:a63:fe15:: with SMTP id p21mr7185781pgh.149.1562638227120; Mon, 08 Jul 2019 19:10:27 -0700 (PDT) MIME-Version: 1.0 From: Leo Tohill Date: Mon, 8 Jul 2019 22:10:15 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="00000000000070a401058d36109e" Archived-At: Subject: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:10:41 -0000 --00000000000070a401058d36109e Content-Type: text/plain; charset="UTF-8" Ok, I'm creating a new posting for this feedback. :) Here's where I probably just need some enlightenment, so please help me out. Re 8. Refresh Tokens "For public clients, the risk of a leaked refresh token is much greater than leaked access tokens, since an attacker can potentially continue using the stolen refresh token to obtain new access without being detectable by the authorization server. " (first, note the typo "stoken".) Is it always "higher risk"? I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires. A leaked refresh token, to be useful, requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked). (of course revocation might NOT have happened, but then again, it might have.) Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs). Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed? "Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked." The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right? This sentence could be changed to "... by which *a token* can be leaked." A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL. But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive. The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft. Which scenario is safer? A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL B) using an access token with a 1 hour TTL, and no refresh token. I'd say that A is safer. (Unless, when the refresh token is used, a new refresh token is issued, the NEW refresh token gets another 1 hour. If this is the case, one could maintain refresh tokens infinitely. Is this point addressed somewhere?) --00000000000070a401058d36109e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, I'm creating a new posting for this feedback.= :)

Here's where I probably just need some enl= ightenment, so please help me out.

Re 8. Refr= esh Tokens

=C2=A0=C2=A0 "For public clients, the risk of a leak= ed refresh token is much
=C2=A0 =C2=A0greater than leaked access tokens,= since an attacker can potentially
=C2=A0 =C2=A0continue using the stole= n refresh token to obtain new access without
=C2=A0 =C2=A0being detectab= le by the authorization server.=C2=A0 "

(firs= t, note the typo "stoken".)

Is it always= "higher risk"?=C2=A0 I could even argue that leakage of a refres= h token is lower risk. As a bearer document, a leaked access token allows a= ccess to resources until it expires.=C2=A0 A leaked refresh token, to be us= eful,=C2=A0 requires an exchange with the AS, and the AS would have the opp= ortunity to check whether the refresh token is still valid (has not been re= voked).=C2=A0 (of course revocation might NOT have happened, but then again= , it might have.)

Furthermore, since the acce= ss token is transmitted to other servers, the risk of exposure is greater, = due to possible vulnerabilities in those called systems (e.g., logs).=C2=A0= Isn't this the reason that we have refresh tokens? Don't refresh t= okens exist because access tokens should have short TTL, because they are w= idely distributed?

"Additionally, browser= -based applications provide many attack vectors by which a refresh token ca= n be leaked."

The risks of leaking a refresh = token from the browser are identical to the risks of leaking an access toke= n, right?=C2=A0 This sentence could be changed to "... by which a t= oken can be leaked."

A refresh token = is "higher risk" because its TTL is usually greater than the acce= ss token's TTL.=C2=A0 But if our advice here leads to people using long= er-lived access tokens (because of the problems with getting a new access t= oken without involving the user), then the advice will be counter productiv= e.=C2=A0=C2=A0 The longer life gives more time for the usefulness of a brow= ser-side theft, and more time for the usefulness of a server-side theft.=C2= =A0

Which scenario is safer?

A) using an access token with a 10 minute TTL, accompanied by a re= fresh token with a 1 hour TTL
B) using an access token with a 1 h= our TTL, and no refresh token.

I'd say th= at A is safer. (Unless, when the refresh token is used, a new refresh token= is issued, the NEW refresh token gets another 1 hour.=C2=A0 If this is the= case, one could maintain refresh tokens infinitely. Is this point addresse= d somewhere?)



--00000000000070a401058d36109e-- From nobody Mon Jul 8 20:17: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 9F4431200EF for ; Mon, 8 Jul 2019 20:17: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, 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 m2hYJKqjrXge for ; Mon, 8 Jul 2019 20:17: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 791021200F4 for ; Mon, 8 Jul 2019 20:17:45 -0700 (PDT) Received: from [192.168.1.125] (c-98-246-106-124.hsd1.or.comcast.net [98.246.106.124]) by alkaline-solutions.com (Postfix) with ESMTPSA id 399F5315AB; Tue, 9 Jul 2019 03:17:41 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1451B381-8364-45D6-BF9B-9381ABF92262" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Mon, 8 Jul 2019 20:17:39 -0700 In-Reply-To: Cc: OAuth WG To: Leo Tohill References: X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 03:17:49 -0000 --Apple-Mail=_1451B381-8364-45D6-BF9B-9381ABF92262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: > Re 8. Refresh Tokens >=20 > "For public clients, the risk of a leaked refresh token is much > greater than leaked access tokens, since an attacker can = potentially > continue using the stolen refresh token to obtain new access = without > being detectable by the authorization server. " >=20 > (first, note the typo "stoken".) >=20 > Is it always "higher risk"? I could even argue that leakage of a = refresh token is lower risk. As a bearer document, a leaked access token = allows access to resources until it expires. A leaked refresh token, to = be useful, requires an exchange with the AS, and the AS would have the = opportunity to check whether the refresh token is still valid (has not = been revoked). (of course revocation might NOT have happened, but then = again, it might have.)=20 I agree (with caveats, of course). Access tokens and refresh tokens may or may not be attached (by policy) = to an authentication session lifetime. It is far easier to picture = refresh tokens which are not attached to an authentication session = (sometimes called =E2=80=98offline=E2=80=99 access) being inappropriate = for a browser-based app, which is nearly always a client that the = resource owner is interacting with. Variants that may want offline tokens are less easy to imagine - perhaps = browser extensions? I believe the language currently there is due to AS implementations = predominantly treating refresh tokens as being for offline access, and = access token lifetime being short enough to not outlast an = authentication session. > Furthermore, since the access token is transmitted to other servers, = the risk of exposure is greater, due to possible vulnerabilities in = those called systems (e.g., logs). Isn't this the reason that we have = refresh tokens? Don't refresh tokens exist because access tokens should = have short TTL, because they are widely distributed? Yes. Once you acknowledge the existence of =E2=80=98online=E2=80=99 = refresh tokens, they become a strong security component: - Refresh tokens let you shorten the access token lifetime - A shorter access token lifetime lets you have centralized policy to = invalidate access without needing to resort to token = introspection/revocation - Token refresh can theoretically be used to represent other policy = changes by both the client (creating tokens targeting a new resource = server or with reduced scopes) and server (changing entitlements and = attributes/claims embedded within a structured token) - Refresh tokens can be one-time-use, as recommenced by the security = BCP. A exfiltrated refresh token will result in either the attacker or = the user losing access on the next refresh, and a double refresh is a = detectable security event by the AS. > "Additionally, browser-based applications provide many attack vectors = by which a refresh token can be leaked." >=20 > The risks of leaking a refresh token from the browser are identical to = the risks of leaking an access token, right? This sentence could be = changed to "... by which a token can be leaked." >=20 > A refresh token is "higher risk" because its TTL is usually greater = than the access token's TTL. But if our advice here leads to people = using longer-lived access tokens (because of the problems with getting a = new access token without involving the user), then the advice will be = counter productive. The longer life gives more time for the usefulness = of a browser-side theft, and more time for the usefulness of a = server-side theft. =20 >=20 > Which scenario is safer? > A) using an access token with a 10 minute TTL, accompanied by a = refresh token with a 1 hour TTL > B) using an access token with a 1 hour TTL, and no refresh token.=20 Given tokens that track authentication lifetime, it is hard to make a = case that refresh tokens which last for the authentication session are a = greater security risk than opaque access tokens (requiring token = introspection) that will last the same time.=20 Typically an AS (or OP) would issue a structured access token with a = lifetime expected to expire before the authentication session, with new = tokens issued via requests made in an embedded, iframe (hidden, = prompt=3Dnone). There may be benefits here of user cookies (or perhaps = managed-device information) against an authorization endpoint being used = to make decisions that could not be made by a refresh against the token = endpoint.=20 I=E2=80=99d be interested in hearing how strong of an implementation = issue this might be for deployments - I could see a non-security = argument that the BCP should only have one recommended approach here, = and that there are deployments needing the iframe approach. -DW --Apple-Mail=_1451B381-8364-45D6-BF9B-9381ABF92262 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com>= wrote:
Re 8. Refresh Tokens

   = "For public clients, the risk of a leaked refresh token is much
   greater than leaked access tokens, since an = attacker can potentially
   continue using the = stolen refresh token to obtain new access without
  =  being detectable by the authorization server.  "

(first, note the typo = "stoken".)

Is = it always "higher risk"?  I could even argue that leakage of a = refresh token is lower risk. As a bearer document, a leaked access token = allows access to resources until it expires.  A leaked refresh = token, to be useful,  requires an exchange with the AS, and the AS = would have the opportunity to check whether the refresh token is still = valid (has not been revoked).  (of course revocation might NOT have = happened, but then again, it might have.)

I = agree (with caveats, of course).

Access tokens and refresh tokens may or may not be = attached (by policy) to an authentication session lifetime. It is far = easier to picture refresh tokens which are not attached to an = authentication session (sometimes called =E2=80=98offline=E2=80=99 = access) being inappropriate for a browser-based app, which is nearly = always a client that the resource owner is interacting = with.

Variants that may want offline = tokens are less easy to imagine - perhaps browser = extensions?

I believe the language = currently there is due to AS implementations predominantly treating = refresh tokens as being for offline access, and access token lifetime = being short enough to not outlast an authentication = session.

Furthermore, since the access token is transmitted to other = servers, the risk of exposure is greater, due to possible = vulnerabilities in those called systems (e.g., logs).  Isn't this = the reason that we have refresh tokens? Don't refresh tokens exist = because access tokens should have short TTL, because they are widely = distributed?

Yes. Once you acknowledge the existence of =E2=80=98onlin= e=E2=80=99 refresh tokens, they become a strong security = component:

- Refresh tokens let you = shorten the access token lifetime
- A shorter access token = lifetime lets you have centralized policy to invalidate access without = needing to resort to token introspection/revocation
- Token = refresh can theoretically be used to represent other policy changes by = both the client (creating tokens targeting a new resource server or with = reduced scopes) and server (changing entitlements and attributes/claims = embedded within a structured token)
- Refresh tokens can be = one-time-use, as recommenced by the security BCP. A exfiltrated refresh = token will result in either the attacker or the user losing access on = the next refresh, and a double refresh is a detectable security event by = the AS.

"Additionally, browser-based applications provide many attack = vectors by which a refresh token can be leaked."

The risks of leaking a refresh token = from the browser are identical to the risks of leaking an access token, = right?  This sentence could be changed to "... by which a token can be leaked."

A refresh token is = "higher risk" because its TTL is usually greater than the access token's = TTL.  But if our advice here leads to people using longer-lived = access tokens (because of the problems with getting a new access token = without involving the user), then the advice will be counter = productive.   The longer life gives more time for the = usefulness of a browser-side theft, and more time for the usefulness of = a server-side theft. 

Which scenario is = safer?
A) using an access token with a = 10 minute TTL, accompanied by a refresh token with a 1 hour = TTL
B) using an access token with a 1 hour TTL, and = no refresh token. 


Given tokens = that track authentication lifetime, it is hard to make a case that = refresh tokens which last for the authentication session are a greater = security risk than opaque access tokens (requiring token introspection) = that will last the same time. 

Typically an AS (or OP) would issue a structured = access token with a lifetime expected to expire before the = authentication session, with new tokens issued via requests made in an = embedded, iframe (hidden, prompt=3Dnone). There may be benefits here of = user cookies (or perhaps managed-device information) against an = authorization endpoint being used to make decisions that could not be = made by a refresh against the token endpoint. 

I=E2=80=99d be interested in hearing how strong of = an implementation issue this might be for deployments - I could see a = non-security argument that the BCP should only have one recommended = approach here, and that there are deployments needing the iframe = approach.

-DW

= --Apple-Mail=_1451B381-8364-45D6-BF9B-9381ABF92262-- From nobody Mon Jul 8 20:40: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 1F6B81200F1 for ; Mon, 8 Jul 2019 20:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VHJNdRMWHyTl for ; Mon, 8 Jul 2019 20:40:07 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D331200DB for ; Mon, 8 Jul 2019 20:40:07 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u19so40078628ior.9 for ; Mon, 08 Jul 2019 20:40:07 -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=ctghg5Ao/bSp4t0ZrQDL1S/k+a2fCCaAhxq3n4IUlhs=; b=2E3b7DlWpIpFdXFaYJTMGkYM6wjeEAOmZhFRrLz2EjpheY1/zHqIVnJi6BrafElwqL aZdUQ+nZSqR10cYg1LOuSgNsYH++BTVVb/4o3q0fD6ef0mMB4Sf5PSUBV7xTiRI/Mem0 279pucilQnIKSibaYZoBjOOu1f7pk6VL26JhwEXrF0peUrcKf1yzk8pJX/9ppnDfaXA8 e6kKoP1DsdKCOdYQ70T/VhW9cMbrs7DZNZYMSzWZ3uwbQOjFQeGtJfeAUjti9ISzYy99 mojQ3s8q+9/t/9iT6FhGNsY9FHto3AtwNVD7A2qMvvXX/QgGnoLHXEHKV9dIjWMFUoN+ qBcQ== 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=ctghg5Ao/bSp4t0ZrQDL1S/k+a2fCCaAhxq3n4IUlhs=; b=RwQuJ+t/sKS9WhbXyYv4MiE6+MR/Z3dF5D6dGqV16GCs2/zixuok/ggh/LHqW4YGKw V9SmH+X/PSMfBV7EpJaolnOYSnC7p0uP1L+GH0bsVzJKiNfOlS7wotsg7HjpIpgizEAJ jWSfQQXJmDkdA1aHsCrXA/5JAEySPwaaLB2a7Tb2nuPhhKLMIHX5EdDVB0ODIXbhbDav b1rfHlBVozDmNdo1g4i8CfpKjRSCTuMB8pnaW5UumMhfbJGZUGH69mBoZthCrkPaluLF T5wWRC5dQ43h+RF00As0NTFC6nk7SFUVZv5zF4VvJSB1c2ppDuI9o5fvyI6l26v7d0dC Ps8g== X-Gm-Message-State: APjAAAVh2W3urAr4SHHuar5qe15hUwMMkMs14ZRuQGWQBsnOTokTzw5/ 2uxQIq5FBd0TZ4Vqae+fjnUPs6TGA6o= X-Google-Smtp-Source: APXvYqyRKjmBZxFY7uJT92nj+ikQUh3sG4Fddwy2lX3CAqJUaQynVcxmolSZg1P138Bm7OimUt6Hbg== X-Received: by 2002:a5d:8e08:: with SMTP id e8mr791942iod.139.1562643606429; Mon, 08 Jul 2019 20:40:06 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id 20sm18088467iog.62.2019.07.08.20.40.05 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 20:40:05 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id m24so30638169ioo.2 for ; Mon, 08 Jul 2019 20:40:05 -0700 (PDT) X-Received: by 2002:a6b:7a42:: with SMTP id k2mr16262076iop.214.1562643605625; Mon, 08 Jul 2019 20:40:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Mon, 8 Jul 2019 20:39:53 -0700 X-Gmail-Original-Message-ID: Message-ID: To: David Waite Cc: Leo Tohill , OAuth WG Content-Type: multipart/alternative; boundary="0000000000000626c9058d37517d" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 03:40:10 -0000 --0000000000000626c9058d37517d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable These are all very good points! I think the challenge here is figuring out where this kind of guidance is most appropriate. It does seem like some of these issues are unique to a browser environment (particularly where the browser itself is managing the access and refresh tokens), so maybe it makes the most sense to include this guidance in the browser based app BCP? If there are situations in which this advice is applicable in other scenarios in addition to browser apps, then I think it would make more sense to include it in the general OAuth security BCP. The Security BCP already has some language around refresh tokens, but I haven't reviewed it in a while to see if all of these points might be already covered there. If folks think the Browser BCP is the best place for this kind of thing I am definitely open to it, and I can work with David on the specific language to add. - Aaron On Mon, Jul 8, 2019 at 8:18 PM David Waite wrote: > > On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: > Re 8. Refresh Tokens > > "For public clients, the risk of a leaked refresh token is much > greater than leaked access tokens, since an attacker can potentially > continue using the stolen refresh token to obtain new access without > being detectable by the authorization server. " > > (first, note the typo "stoken".) > > Is it always "higher risk"? I could even argue that leakage of a refresh > token is lower risk. As a bearer document, a leaked access token allows > access to resources until it expires. A leaked refresh token, to be > useful, requires an exchange with the AS, and the AS would have the > opportunity to check whether the refresh token is still valid (has not be= en > revoked). (of course revocation might NOT have happened, but then again, > it might have.) > > > I agree (with caveats, of course). > > Access tokens and refresh tokens may or may not be attached (by policy) t= o > an authentication session lifetime. It is far easier to picture refresh > tokens which are not attached to an authentication session (sometimes > called =E2=80=98offline=E2=80=99 access) being inappropriate for a browse= r-based app, which > is nearly always a client that the resource owner is interacting with. > > Variants that may want offline tokens are less easy to imagine - perhaps > browser extensions? > > I believe the language currently there is due to AS implementations > predominantly treating refresh tokens as being for offline access, and > access token lifetime being short enough to not outlast an authentication > session. > > Furthermore, since the access token is transmitted to other servers, the > risk of exposure is greater, due to possible vulnerabilities in those > called systems (e.g., logs). Isn't this the reason that we have refresh > tokens? Don't refresh tokens exist because access tokens should have shor= t > TTL, because they are widely distributed? > > > Yes. Once you acknowledge the existence of =E2=80=98online=E2=80=99 refre= sh tokens, they > become a strong security component: > > - Refresh tokens let you shorten the access token lifetime > - A shorter access token lifetime lets you have centralized policy to > invalidate access without needing to resort to token > introspection/revocation > - Token refresh can theoretically be used to represent other policy > changes by both the client (creating tokens targeting a new resource serv= er > or with reduced scopes) and server (changing entitlements and > attributes/claims embedded within a structured token) > - Refresh tokens can be one-time-use, as recommenced by the security BCP. > A exfiltrated refresh token will result in either the attacker or the use= r > losing access on the next refresh, and a double refresh is a detectable > security event by the AS. > > "Additionally, browser-based applications provide many attack vectors by > which a refresh token can be leaked." > > The risks of leaking a refresh token from the browser are identical to th= e > risks of leaking an access token, right? This sentence could be changed = to > "... by which *a token* can be leaked." > > A refresh token is "higher risk" because its TTL is usually greater than > the access token's TTL. But if our advice here leads to people using > longer-lived access tokens (because of the problems with getting a new > access token without involving the user), then the advice will be counter > productive. The longer life gives more time for the usefulness of a > browser-side theft, and more time for the usefulness of a server-side > theft. > > Which scenario is safer? > > A) using an access token with a 10 minute TTL, accompanied by a refresh > token with a 1 hour TTL > B) using an access token with a 1 hour TTL, and no refresh token. > > > > Given tokens that track authentication lifetime, it is hard to make a cas= e > that refresh tokens which last for the authentication session are a great= er > security risk than opaque access tokens (requiring token introspection) > that will last the same time. > > Typically an AS (or OP) would issue a structured access token with a > lifetime expected to expire before the authentication session, with new > tokens issued via requests made in an embedded, iframe (hidden, > prompt=3Dnone). There may be benefits here of user cookies (or perhaps > managed-device information) against an authorization endpoint being used = to > make decisions that could not be made by a refresh against the token > endpoint. > > I=E2=80=99d be interested in hearing how strong of an implementation issu= e this > might be for deployments - I could see a non-security argument that the B= CP > should only have one recommended approach here, and that there are > deployments needing the iframe approach. > > -DW > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --0000000000000626c9058d37517d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These are all very good points! I think the challeng= e here is figuring out where this kind of guidance is most appropriate.

It does seem like som= e of these issues are unique to a browser environment (particularly where t= he browser itself is managing the access and refresh tokens), so maybe it m= akes the most sense to include this guidance in the browser based app BCP?<= /div>

If there are situations = in which this advice is applicable in other scenarios in addition to browse= r apps, then I think it would make more sense to include it in the general = OAuth security BCP.

The = Security BCP already has some language around refresh tokens, but I haven&#= 39;t reviewed it in a while to see if all of these points might be already = covered there.

If folks = think the Browser BCP is the best place for this kind of thing I am definit= ely open to it, and I can work with David on the specific language to add.<= /div>

- Aaron



On Mon, Jul 8, 2019 at 8:18 PM = David Waite <david@alkal= ine-solutions.com> wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com> wrote:



I agree (with caveats, of= course).






"Additionally, brows= er-based applications provide many attack vectors by which a refresh token = can be leaked."

The risks of leaking a refres= h token from the browser are identical to the risks of leaking an access to= ken, right?=C2=A0 This sentence could be changed to "... by which a= token can be leaked."

A refresh toke= n is "higher risk" because its TTL is usually greater than the ac= cess token's TTL.=C2=A0 But if our advice here leads to people using lo= nger-lived access tokens (because of the problems with getting a new access= token without involving the user), then the advice will be counter product= ive.=C2=A0=C2=A0 The longer life gives more time for the usefulness of a br= owser-side theft, and more time for the usefulness of a server-side theft.= =C2=A0

Which scenario is safer?
A) using an acce= ss token with a 10 minute TTL, accompanied by a refresh token with a 1 hour= TTL
B) using an access token with a 1 hour TTL, and no refresh t= oken.=C2=A0


Given token= s that track authentication lifetime, it is hard to make a case that refres= h tokens which last for the authentication session are a greater security r= isk than opaque access tokens (requiring token introspection) that will las= t the same time.=C2=A0

Typically an AS (or OP) wou= ld issue a structured access token with a lifetime expected to expire befor= e the authentication session, with new tokens issued via requests made in a= n embedded, iframe (hidden, prompt=3Dnone). There may be benefits here of u= ser cookies (or perhaps managed-device information) against an authorizatio= n endpoint being used to make decisions that could not be made by a refresh= against the token endpoint.=C2=A0

I=E2=80=99d be = interested in hearing how strong of an implementation issue this might be f= or deployments - I could see a non-security argument that the BCP should on= ly have one recommended approach here, and that there are deployments needi= ng the iframe approach.
= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--0000000000000626c9058d37517d-- From nobody Mon Jul 8 23:08: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 29F811202F8 for ; Mon, 8 Jul 2019 23:08: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, 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 KxdC_f-s_-qW for ; Mon, 8 Jul 2019 23:08:28 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 262771202E2 for ; Mon, 8 Jul 2019 23:08:28 -0700 (PDT) Received: from [192.168.1.125] (c-98-246-106-124.hsd1.or.comcast.net [98.246.106.124]) by alkaline-solutions.com (Postfix) with ESMTPSA id 9A491315AB; Tue, 9 Jul 2019 06:08:25 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8DE82827-D6A5-48C0-AF63-B70134015589" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Mon, 8 Jul 2019 23:08:24 -0700 In-Reply-To: Cc: Leo Tohill , OAuth WG To: Aaron Parecki References: X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 06:08:30 -0000 --Apple-Mail=_8DE82827-D6A5-48C0-AF63-B70134015589 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 8, 2019, at 8:39 PM, Aaron Parecki wrote: >=20 > These are all very good points! I think the challenge here is figuring = out where this kind of guidance is most appropriate. >=20 > It does seem like some of these issues are unique to a browser = environment (particularly where the browser itself is managing the = access and refresh tokens), so maybe it makes the most sense to include = this guidance in the browser based app BCP? Yes, the location is a challenge - the =E2=80=9Coffline=E2=80=9D = distinction is defined (arguably under-defined) by OpenID Connect. OAuth = (on the other hand) does not take a stand on user authentication = sessions, since the tokens are for delegated access. For confidential clients, both online and offline options make sense. = For native apps, the push is usually for long-term access or for a = session separate from the external user agent. But for browser apps, you = typically want to mirror user authentication. =20 > If there are situations in which this advice is applicable in other = scenarios in addition to browser apps, then I think it would make more = sense to include it in the general OAuth security BCP. >=20 > The Security BCP already has some language around refresh tokens, but = I haven't reviewed it in a while to see if all of these points might be = already covered there. >=20 > If folks think the Browser BCP is the best place for this kind of = thing I am definitely open to it, and I can work with David on the = specific language to add. >=20 > - Aaron -DW= --Apple-Mail=_8DE82827-D6A5-48C0-AF63-B70134015589 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 8, 2019, at 8:39 PM, Aaron Parecki <aaron@parecki.com> = wrote:

These are all very good points! I think the = challenge here is figuring out where this kind of guidance is most = appropriate.

It = does seem like some of these issues are unique to a browser environment = (particularly where the browser itself is managing the access and = refresh tokens), so maybe it makes the most sense to include this = guidance in the browser based app BCP?

Yes, the location is a challenge - the =E2=80=9Coffline=E2= =80=9D distinction is defined (arguably under-defined) by OpenID = Connect. OAuth (on the other hand) does not take a stand on user = authentication sessions, since the tokens are for delegated = access.

For confidential clients, = both online and offline options make sense. For native apps, the push is = usually for long-term access or for a session separate from the external = user agent. But for browser apps, you typically want to mirror user = authentication.
 
If there are situations in which this = advice is applicable in other scenarios in addition to browser apps, = then I think it would make more sense to include it in the general OAuth = security BCP.

The = Security BCP already has some language around refresh tokens, but I = haven't reviewed it in a while to see if all of these points might be = already covered there.

If = folks think the Browser BCP is the best place for this kind of thing I = am definitely open to it, and I can work with David on the specific = language to add.

- = Aaron

-DW
= --Apple-Mail=_8DE82827-D6A5-48C0-AF63-B70134015589-- From nobody Tue Jul 9 08:55: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 345B9120601 for ; Tue, 9 Jul 2019 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nV_XoqiqaEtd for ; Tue, 9 Jul 2019 08:55:20 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974881206BE for ; Tue, 9 Jul 2019 08:55:05 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id u17so9177279pgi.6 for ; Tue, 09 Jul 2019 08:55:05 -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=Sb6bgLttDbPk80g1LYpXimY6qBHLsOdgI/d2lfstOYI=; b=Z75hY7bROUYrqwV6jwd1JPwXziNLTL9+Iy9b6jOT7vQHXdPnFKZ0MGwMOQSdAoqp12 1cdtUL9TGDHLJJKKgtL27+9nHoeXpqEzC+8ae+iMFjQOozddXbmIHO/Aht6nBL7Z3qYS Asu2pfNz0D6A0d5yMY4cpxuytNLgfc822rn0+kqhF1HrgNK2tavwOd/ieHMBippIuYt3 5fC8xgu744FQ29VodlsDnuzEbW8YKq980LiuRucIVLGPXxJmLCvIonguqaAL3FsXwIH1 QZdbdbaBRknmOt151tZIMy6l/qKnpUNcD4w5GzzVWHeN4JHlKFYxZjFJOWqCuXEmBcMb 7tBg== 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=Sb6bgLttDbPk80g1LYpXimY6qBHLsOdgI/d2lfstOYI=; b=cm5xFfmTR4M9jnZrHPcbBZ/R1bU0khilQ1YxQ6hZt64PDiDNHHENqZEZybdYhrHmTm fsY8d0Hp+cOfX/Ri8RgVWleO1j2W3dveez+gDHyc31S+7lm8idMTGT5/AF2JiJFzS5Va RrDPDEqaEYYhkO8UreXAWRisNKIQHPgXQ9q6P9KawJl4kyQdiwv/7C+rj0FtAddzJnsJ 5OcMcsGheRUT6qLRjfwQv0artAlm+wxD6w0iAHzl5a3umaj1ROmmnY/SNsvA4GIcPORT pS0XoXkdO+tl6PQGuHGRcG7vK1h9eaC1OZFHryNvJ6D04kSXAa6Kp1Kjcz7XnnKPEhwb KkxA== X-Gm-Message-State: APjAAAUDPiybyQlo2iXchtINcOvrDUCykI4keSo9pkOWzxUPJh/WlD8H srB3NNSsXDpaK32/qNjDr2u4/iE1ucntaTNeNlERQRyBne8= X-Google-Smtp-Source: APXvYqz3WZ96bnzucVrN6+IJnNCbHR5Aq5MU/AU9ik9EAY0fdTAnIv/fvGUiyc3ahfejhhSdZ+dsfsaFlSGreXt288I= X-Received: by 2002:a63:fe15:: with SMTP id p21mr11274113pgh.149.1562687704593; Tue, 09 Jul 2019 08:55:04 -0700 (PDT) MIME-Version: 1.0 From: Leo Tohill Date: Tue, 9 Jul 2019 11:54:53 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="00000000000086fdae058d419564" Archived-At: Subject: [OAUTH-WG] historical note regarding use of url fragment in OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:55:22 -0000 --00000000000086fdae058d419564 Content-Type: text/plain; charset="UTF-8" re: 9.8.7 . Historic Note Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload. Now with the Session History API (described in "Session history and navigation" of [HTML ]), browsers have a mechanism to modify the path component of the URL without triggering a page reload, so this overloaded use of the fragment portion is no longer needed. Does this historical note mean to indicate that if the implicit flow were designed today, it could use path instead of fragment to carry the token? Doesn't this overlook the important aspect that fragments are not sent to the server? --00000000000086fdae058d419564 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 

re: 
9.8.7.  Histo=
ric Note


   Historically, the Implicit flow provided an advantage to single-page
   apps since JavaScript could always arbitrarily read and manipulate
   the fragment portion of the URL without triggering a page reload.
   Now with the Session History API (described in "Session history and
   navigation" of [HTML]),=
 browsers have a mechanism to modify the path
   component of the URL without triggering a page reload, so this
   overloaded use of the fragment portion is no longer needed.

Does this historical note mean to indicate that if the = implicit flow were designed today, it could use path instead of fragment to= carry the token?

Doesn't this overlook the im= portant aspect that fragments are not sent to the server?


--00000000000086fdae058d419564-- From nobody Tue Jul 9 09:15: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 EA2F41206E2 for ; Tue, 9 Jul 2019 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GUdlZHKphesN for ; Tue, 9 Jul 2019 09:15:45 -0700 (PDT) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE567120765 for ; Tue, 9 Jul 2019 09:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1562688938; bh=dBFeIV4UMXj5/fA4L9FVYkodmkFGh044WB3JZGvbYKU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=bnpgyDgikNdK1tUvEbFOwxRM0lLtku6doATpBnR8Ln5EMw10nAln0yVIM9SXe042LxnCum06swhQXJBm0M13H8kTMqg2SSMDQYOhHy4DMoU1YVbXfqSlKf6zTKbZ5QeSIiSC4BmdZNtzMmWsjJqJ4pTbKtvPSkOtrRyeVSXXBmWKUWzn6d5wf66iZSZX3HNDZRnu5BHJB5l0zq7wlVhNtQfgmBSVisxodjsYfw4XfeRdbWTE8l2xOXTB4dwjOXYuwtS3NgwxSjFnqPWatEUGGn9iwtM8q1cBLVFW05Yql2uqLi0U+GmNySkIe60wZZ91MF70I7gfgsFmiutFJPXq4Q== X-YMail-OSG: 0JwyJaoVM1l7MRso.NXSWEDxoQ2RQcO2XuBb06bA_x9A.8SCIUEffMlMEKCUUWL 1i.rRsLJDwJnBRhQlIwJTUZ7sCA3.899N0Q1Hihg3SnPF5EjRNE7VqCXfhJxYKrestw84jmb0R.Q LHenMX7pwBj7.7MbjwwWRsSHpq3iQfikiI6IkT5tvnXbNjYVBbsKx01aVY9q_SgD2YV5yJiIZOOU exIXQsRYhMLRUJht1pK8Bd8Rhb1_piOlFMBFM8eYsEV1fslxsgFHj7sf21McpuCJnGQKRQj1NnLl 2yShyKDLZTYgOMC3FY8oAVw1_DO_jOJ2vUndEE7f7zm_pU9zPrIdDOiRh8Cc7.nxZS676SM7DCAp UzaPwLMnCsp4mNOUcmNHW3mF3ER.NtY8zmpF3gLURZM3ZyV3wKwCH4.VIOXXYguAN.qHh2ALFHsG ugZNlz2IVfoeX1IBNJmoR2CyjcHT2RWqXyEbzT.DTvW35nzF6C0cUWlOd2Bn7s3_3Big46ZgfPHN USXZm94s0hW3wLcWi6IA6pw0DCW4XBFcUJwh8hMgV3v4zn1HsP1EbHRrxBV3Tb6dkLhummXsSqN2 DIu3aF4ZH16VliKPHSCIKXY.GsngXNYocdHLqgT.7g8m7gsD.lhL5ug6Lg3l.VgxqjgKziy9w.Zp azLtihgrPYKl0_TqscwY3lIfcqIvjm8DOrpBuztP6v6Z6rGCH3N4dkSr98vLx3C_0CNkVMVkeD2f RpsRulpr1w3v8REWn9Rd9KSIYSHCuje66rJkq03Wu.j.oz9BTHExDsVy704jvKc8gYuQxbB1TTuO nDvobjGyS5B3XRMbzwja5xavboVs8oAHlccs7_xowifXL.4qbT9FFF_KpP9TC17BcQxQDtn_IKUt W6tSXZBAiv1dS2i3JoD2aqhNgDkVaH9Z1DKfQrXsYYuTNZILIUfXOPnahCQZ3e4Lh1hVC8g_wyvz 2GIkvSkgANnBVLZqPy7fPD5nngrjUQKhWTJgZ5nkjb7rsvLXfONfrCsEjnPrHDtlBmMxztppWica 4THLiigm23VXLKKe0UDLG0vbI7vBxlyqYdVUMnlj2vsxnqDdHzhy0skOH77_xASZRWNiaC3yfnw3 EJyICSz5xWlThRiSHmRWp39m233b_Vezn1G46hvGqqhY3OHQgYbwEiE9HxyqmlstfVeEx.W9a6pY 8J8exBnT2ZZ64BNIHPI_qX6odgNvuht84lMPUsFs3mKaV.r.B4Rg7Jz4sRhH1WSrHbw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Tue, 9 Jul 2019 16:15:38 +0000 Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 565f05ab55547d330cb937b16930d7a7; Tue, 09 Jul 2019 16:15:34 +0000 (UTC) To: David Waite , Leo Tohill Cc: OAuth WG References: From: George Fletcher Organization: AOL LLC Message-ID: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> Date: Tue, 9 Jul 2019 12:15:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA2B0668FCC8D5BE69EA9D46" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:15:52 -0000 This is a multi-part message in MIME format. --------------EA2B0668FCC8D5BE69EA9D46 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'll just add a couple more thoughts around refresh_tokens. 1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there. 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser. 3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token. In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret. Thanks, George On 7/8/19 11:17 PM, David Waite wrote: > >> On Jul 8, 2019, at 7:10 PM, Leo Tohill > > wrote: >> Re 8. Refresh Tokens >> >> ???? "For public clients, the risk of a leaked refresh token is much >> ?? ??greater than leaked access tokens, since an attacker can potentially >> ?? ??continue using the stolen refresh token to obtain new access without >> ?? ??being detectable by the authorization server.?? " >> >> (first, note the typo "stoken".) >> >> Is it always "higher risk"??? I could even argue that leakage of a >> refresh token is lower risk. As a bearer document, a leaked access >> token allows access to resources until it expires.?? A leaked refresh >> token, to be useful,?? requires an exchange with the AS, and the AS >> would have the opportunity to check whether the refresh token is >> still valid (has not been revoked). (of course revocation might NOT >> have happened, but then again, it might have.) > > I agree (with caveats, of course). > > Access tokens and refresh tokens may or may not be attached (by > policy) to an authentication session lifetime. It is far easier to > picture refresh tokens which are not attached to an authentication > session (sometimes called ???offline??? access) being inappropriate for a > browser-based app, which is nearly always a client that the resource > owner is interacting with. > > Variants that may want offline tokens are less easy to imagine - > perhaps browser extensions? > > I believe the language currently there is due to AS implementations > predominantly treating refresh tokens as being for offline access, and > access token lifetime being short enough to not outlast an > authentication session. > >> Furthermore, since the access token is transmitted to other servers, >> the risk of exposure is greater, due to possible vulnerabilities in >> those called systems (e.g., logs).?? Isn't this the reason that we >> have refresh tokens? Don't refresh tokens exist because access tokens >> should have short TTL, because they are widely distributed? > > Yes. Once you acknowledge the existence of ???online??? refresh tokens, > they become a strong security component: > > - Refresh tokens let you shorten the access token lifetime > - A shorter access token lifetime lets you have centralized policy to > invalidate access without needing to resort to token > introspection/revocation > - Token refresh can theoretically be used to represent other policy > changes by both the client (creating tokens targeting a new resource > server or with reduced scopes) and server (changing entitlements and > attributes/claims embedded within a structured token) > - Refresh tokens can be one-time-use, as recommenced by the security > BCP. A exfiltrated refresh token will result in either the attacker or > the user losing access on the next refresh, and a double refresh is a > detectable security event by the AS. > >> "Additionally, browser-based applications provide many attack vectors >> by which a refresh token can be leaked." >> >> The risks of leaking a refresh token from the browser are identical >> to the risks of leaking an access token, right??? This sentence could >> be changed to "... by which /a token/ can be leaked." >> >> A refresh token is "higher risk" because its TTL is usually greater >> than the access token's TTL.?? But if our advice here leads to people >> using longer-lived access tokens (because of the problems with >> getting a new access token without involving the user), then the >> advice will be counter productive.???? The longer life gives more time >> for the usefulness of a browser-side theft, and more time for the >> usefulness of a server-side theft. >> >> Which scenario is safer? >> A) using an access token with a 10 minute TTL, accompanied by a >> refresh token with a 1 hour TTL >> B) using an access token with a 1 hour TTL, and no refresh token. > > > Given tokens that track authentication lifetime, it is hard to make a > case that refresh tokens which last for the authentication session are > a greater security risk than opaque access tokens (requiring token > introspection) that will last the same time. > > Typically an AS (or OP) would issue a structured access token with a > lifetime expected to expire before the authentication session, with > new tokens issued via requests made in an embedded, iframe (hidden, > prompt=none). There may be benefits here of user cookies (or perhaps > managed-device information) against an authorization endpoint being > used to make decisions that could not be made by a refresh against the > token endpoint. > > I???d be interested in hearing how strong of an implementation issue > this might be for deployments - I could see a non-security argument > that the BCP should only have one recommended approach here, and that > there are deployments needing the iframe approach. > > -DW > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------EA2B0668FCC8D5BE69EA9D46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com> wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perhaps browser extensions?

I believe the language currently there is due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

"Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a token can be leaked."

A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL.?? But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??

Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=none). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??

I???d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW


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

--------------EA2B0668FCC8D5BE69EA9D46-- From nobody Tue Jul 9 09:22: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 E70971202BC for ; Tue, 9 Jul 2019 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AZTOQOWeWmmk for ; Tue, 9 Jul 2019 09:22:27 -0700 (PDT) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D227B12017A for ; Tue, 9 Jul 2019 09:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1562689345; bh=+DIebvDp6ehkS8bCm3e3dEIzAfDSVI+aL+A8IhHGbkY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=V20TYv77dn0kB+11GIh1HNGpgvJLVDanE8v7xiv6mPkddAG0MfwNkD7bjIO7ezc3Goc+51GBbO9lO0lUjuPBs4Le1WU+ukqFYDo1O0BPrQDUfNJ3Sc3bJYxdEOPyuLmAHXArOriymDLEhlsZWkh1PX0n9n4OEpoGq4heWl6+jxy0xl9Vbot/KQA2bVN5jX+5vdYSTD1kmBB62ULIVBsmc+PmPM4mFaLiW9z9qWaMnPa01RM3OF7cXNYhlpy5vlC+kTxtGm0XLCuuqaG5t11VYgjEc2YNVnj2wEMRX2Lwc24IEPTeKV/jZhOmTykrezEXNogGgqmJwBoKVrQwcbWZ6w== X-YMail-OSG: 5efCxmgVM1k1moGiUcKzIiwWLcAVV8VBqHtwrxmB_yny5KcNGO8z6M5hobw3Ywe Af37Ab57T8K0xe5VWxolGYRnS09sInEKwnwirY.tUdyi0Io.ajKSEPoJUbilDOoUJqNERXthko3e KypO7udctpnV9IQazPnw2ppS.3bL8Mh0Jdvjad.o_h9szIQgHULO2ehN7UVF.sZ4U3Nez3vsuZio SSUYcBdAOKFih7gMeRcsbv1.VR4whAhICRo9BB25EoJWxqtWi03nBn6LfxFZaMZGvGPLjcDwjS_H jaCMt2yVLA34NCeMEVSgG8xjKfvq3BLihB3NfE4pnobFrA6goDTVWbtyFFrz2FJXmJb7foUJ_5x7 wrPe.ABuVNX9dPVIhsDHFxWRzey6fDgPgudvmPAmpKy.tmz3eADrg9ay2IM_qJmzln3hrSk6_JUi RxIaFowpGkwXNtoTHGRUzREQJrzAnnzfHdquomNtIOpJWssixisK2jrKsrpNM4b5em0Zq.U7rDA8 BWqMxXXLw79A6OmROYcQ.LOoCCvgJqM9hwOXuvhUOravJ3Ytx5b6ucRpmkgK5jxAT0ZnFsM0yQeI 4_mwNlHAEbtcX_mPisgwKb5hI3jKe1LR5l80pQ7yc477Etc_kfOZRqLI5FsecMHm.a9NIVeO3fBT L1RCxz6o0Idfs9iD1D.wYNB_l53NLXCxI.VFYUNR9KWGRuaW3k1KqhJQB_37AFhFsLoeHMxVb97P 4TDMPaBDi1wpvhkiC5BBnDinfL6H.gBd64dYawGtIIs5FwO9Z4zPZhqhcp4MbQQipW271EqNI6f7 45IJ5JLFfpYMxyUun7wMoSuLTUz4gYIdR2LazVNdHb2rIENdnHMWVXJ8QexhST_3devHReIgXilb jkxgY13QlAKGIBZo1gAYmMss1pmkvjTB.KCllwFYZQJGPeX0q4f20P0VClb8s5Z6cVuv4AFft8Ti GXlVjihYtbBRGd4xLqz8rnrBKLxAtQBUQIRSGsuPANaW3apBd0JPmk6j1xasAyZmxp9BKtYTD7oy .LGRwywdd318hpmVA5lWhWnxWgXnjm8Lp4WC57m62VN8.Ej5UH6wTvdbMUgaLSWSjWb6z8q2WEXg 1ralQrS2eQXi2dCSI99qVu573OhEq53Oau9hDhYPuIUW_7viZWUCAwisQT1eJqk569FISr4LDRH8 vJMiPvDORSNpZ.Jgg2d6y_81iTvek7EJMPU13Rrm2t3NQpa8LbYAN3Ddf8mHpq4HU_g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 9 Jul 2019 16:22:25 +0000 Received: by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fb297e7b50fddeb2526a2758e597ded0; Tue, 09 Jul 2019 16:22:20 +0000 (UTC) To: David Waite , Aaron Parecki Cc: OAuth WG References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 9 Jul 2019 12:22:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C33C12C564AD64691CD16998" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:22:29 -0000 This is a multi-part message in MIME format. --------------C33C12C564AD64691CD16998 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit For historical references only... the Google model around refresh tokens and the AOL model around refresh tokens were slightly different. So I proposed a bunch of the OIDC text around refresh tokens and offline access to allow for both models. At AOL, the model was that refresh_tokens were bound to the authentication session by default. The only way to get an "unbound" refresh_token was to request the 'offline_access' scope. We restricted which clients could request the 'offline_access' scope and limited it mostly to native apps. I'm happy to recommend errata text (as long as it's just explanatory) to the OIDC spec should someone have a recommendation they'd like to make:) On 7/9/19 2:08 AM, David Waite wrote: > > >> On Jul 8, 2019, at 8:39 PM, Aaron Parecki > > wrote: >> >> These are all very good points! I think the challenge here is >> figuring out where this kind of guidance is most appropriate. >> >> It does seem like some of these issues are unique to a browser >> environment (particularly where the browser itself is managing the >> access and refresh tokens), so maybe it makes the most sense to >> include this guidance in the browser based app BCP? > > Yes, the location is a challenge - the ???offline??? distinction is > defined (arguably under-defined) by OpenID Connect. OAuth (on the > other hand) does not take a stand on user authentication sessions, > since the tokens are for delegated access. > > For confidential clients, both online and offline options make sense. > For native apps, the push is usually for long-term access or for a > session separate from the external user agent. But for browser apps, > you typically want to mirror user authentication. > >> If there are situations in which this advice is applicable in other >> scenarios in addition to browser apps, then I think it would make >> more sense to include it in the general OAuth security BCP. >> >> The Security BCP already has some language around refresh tokens, but >> I haven't reviewed it in a while to see if all of these points might >> be already covered there. >> >> If folks think the Browser BCP is the best place for this kind of >> thing I am definitely open to it, and I can work with David on the >> specific language to add. >> >> - Aaron > > -DW > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------C33C12C564AD64691CD16998 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit For historical references only... the Google model around refresh tokens and the AOL model around refresh tokens were slightly different. So I proposed a bunch of the OIDC text around refresh tokens and offline access to allow for both models.

At AOL, the model was that refresh_tokens were bound to the authentication session by default. The only way to get an "unbound" refresh_token was to request the 'offline_access' scope. We restricted which clients could request the 'offline_access' scope and limited it mostly to native apps.

I'm happy to recommend errata text (as long as it's just explanatory) to the OIDC spec should someone have a recommendation they'd like to make:)

On 7/9/19 2:08 AM, David Waite wrote:


On Jul 8, 2019, at 8:39 PM, Aaron Parecki <aaron@parecki.com> wrote:

These are all very good points! I think the challenge here is figuring out where this kind of guidance is most appropriate.

It does seem like some of these issues are unique to a browser environment (particularly where the browser itself is managing the access and refresh tokens), so maybe it makes the most sense to include this guidance in the browser based app BCP?

Yes, the location is a challenge - the ???offline??? distinction is defined (arguably under-defined) by OpenID Connect. OAuth (on the other hand) does not take a stand on user authentication sessions, since the tokens are for delegated access.

For confidential clients, both online and offline options make sense. For native apps, the push is usually for long-term access or for a session separate from the external user agent. But for browser apps, you typically want to mirror user authentication.
??
If there are situations in which this advice is applicable in other scenarios in addition to browser apps, then I think it would make more sense to include it in the general OAuth security BCP.

The Security BCP already has some language around refresh tokens, but I haven't reviewed it in a while to see if all of these points might be already covered there.

If folks think the Browser BCP is the best place for this kind of thing I am definitely open to it, and I can work with David on the specific language to add.

- Aaron

-DW

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

--------------C33C12C564AD64691CD16998-- From nobody Tue Jul 9 12:48: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 42C071206AC for ; Tue, 9 Jul 2019 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 T0RUdsXx8fVF for ; Tue, 9 Jul 2019 12:48:17 -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 67C0C12068C for ; Tue, 9 Jul 2019 12:48:17 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x69JljOu012434 for ; Tue, 9 Jul 2019 15:47:59 -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; Tue, 9 Jul 2019 15:47:44 -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, 9 Jul 2019 15:47:46 -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, 9 Jul 2019 15:47:46 -0400 From: Justin Richer To: oauth Thread-Topic: Transaction Authorization Thread-Index: AQHVNo8uSe0/bWT6F0SpCA4rZQBM9A== Date: Tue, 9 Jul 2019 19:47:46 +0000 Message-ID: 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_BD2D90C8B6294955A22C6E80E6390EEEmitedu_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jul 2019 19:48:19 -0000 --_000_BD2D90C8B6294955A22C6E80E6390EEEmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJlcXVlc3RlZCB0aW1lIHRvIHByZXNlbnQgVHJhbnNhY3Rpb25hbCBBdXRob3JpemF0 aW9uICh0aGUgWFlaIHByb2plY3QpIGF0IHRoZSBNb250cmVhbCBtZWV0aW5nIGluIGEgY291cGxl IHdlZWtzLiBBaGVhZCBvZiB0aGF0LCBJ4oCZdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0 aGUgc3BlYzoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFu c2FjdGlvbmFsLWF1dGh6LTAyDQoNCkFkZGl0aW9uYWxseSwgSeKAmXZlIHVwZGF0ZWQgdGhlIHdy aXRldXAgYW5kIGV4YW1wbGVzIG9uIGh0dHBzOi8vb2F1dGgueHl6Lw0KDQpJIHBsYW4gdG8gYmUg aW4gTW9udHJlYWwgZm9yIHRoZSB3aG9sZSB3ZWVrLCBhbmQgSeKAmXZlIHJlcXVlc3RlZCBmcm9t IHRoZSBjaGFpcnMgdGhhdCBJIHByZXNlbnQgZHVyaW5nIHRoZSBUdWVzZGF5IHNlc3Npb24gZHVl IHRvIGxpbWl0ZWQgYXZhaWxhYmlsaXR5IG9mIHNvbWUga2V5IFdHIG1lbWJlcnMgb24gRnJpZGF5 Lg0KDQrigJQgSnVzdGluDQoNCg== --_000_BD2D90C8B6294955A22C6E80E6390EEEmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <66A533D1F45A304898508C3F2CC1619B@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgaGF2ZSByZXF1ZXN0ZWQgdGltZSB0byBwcmVz ZW50IFRyYW5zYWN0aW9uYWwgQXV0aG9yaXphdGlvbiAodGhlIFhZWiBwcm9qZWN0KSBhdCB0aGUg TW9udHJlYWwgbWVldGluZyBpbiBhIGNvdXBsZSB3ZWVrcy4gQWhlYWQgb2YgdGhhdCwgSeKAmXZl IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIHNwZWM6DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDIiIGNsYXNzPSIi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1h dXRoei0wMjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkFkZGl0aW9uYWxseSwgSeKAmXZlIHVwZGF0ZWQgdGhlIHdyaXRldXAgYW5k IGV4YW1wbGVzIG9uIDxhIGhyZWY9Imh0dHBzOi8vb2F1dGgueHl6LyIgY2xhc3M9IiI+DQpodHRw czovL29hdXRoLnh5ei88L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHBsYW4gdG8gYmUgaW4gTW9udHJlYWwgZm9yIHRo ZSB3aG9sZSB3ZWVrLCBhbmQgSeKAmXZlIHJlcXVlc3RlZCBmcm9tIHRoZSBjaGFpcnMgdGhhdCBJ IHByZXNlbnQgZHVyaW5nIHRoZSBUdWVzZGF5IHNlc3Npb24gZHVlIHRvIGxpbWl0ZWQgYXZhaWxh YmlsaXR5IG9mIHNvbWUga2V5IFdHIG1lbWJlcnMgb24gRnJpZGF5LiZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCU IEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BD2D90C8B6294955A22C6E80E6390EEEmitedu_-- From nobody Tue Jul 9 13:08: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 8841E12001A for ; Tue, 9 Jul 2019 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jleO5Q8Cd8r2 for ; Tue, 9 Jul 2019 13:08:07 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38F512007A for ; Tue, 9 Jul 2019 13:08:04 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id y4so128082wrm.2 for ; Tue, 09 Jul 2019 13:08:04 -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=nU4nj7qFr5Gqs5FYSfMEBN/4IA3uuhX5E1yFRxSe67E=; b=UFHZBxrvyyryusRJm4Ou6M3Z+wr/R6pmlIO1zJ4Ypn0Lf6Y9ZrADc6+a0JyA5QQnOu Ef+GIjZJa2/O6RS47FhQ4yldt1yw1WmNWwNZ4aLI8e/Xtp1UgFsj+fDoJVd0JKPzcTVi tixYSb/f4Z/bNovLvFj8rOWn/PQ6GkhlGIuLYD3YEVlC79q55ucwBehE6a0GrAtxGcAz 4V2VbkNU7dVqhxiMbXybTVN4mcepIUkckjRK+z0yO1t8ssIFjs2ugGgSkTenCLH64aoq yFo9NL9GYikFIllBsVV/pCLCNo75jo5gIqLlM9tkz6hSYtXzQpIFmkw6MEz3jj94EyXo 6seQ== 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=nU4nj7qFr5Gqs5FYSfMEBN/4IA3uuhX5E1yFRxSe67E=; b=Kkx0Kry57o+gAB4KM6EPqeifP61Z7CkC0+QELVsI63Dvn1QvXEzi11tspk4CUsAc9/ TkKvIyaj1o9++xYYX3Ae3IjDpC+eK0jJzi3N+fNEun/7uC+WdmBuWeVTaC0JW2Ki2adM vXQMpxreo16t2AdFohi5+1RFEfWCSsLSYhSqSIFAUn/YHGzw4bzIPphJOPYoPavTWDRa k075QLEBC3gevZcr2D0uraLofo+J0BZDdY4lTigto8TcU3gRsmlRk0hVH/xpLR9bGKOC QH00hAAha1S+na5/QxNnVNYI1EEAJ6qrhmM3xAcJ+8QRQWdKI+qs24PiS6HGN8r0Ubf+ IvJw== X-Gm-Message-State: APjAAAWpnnNh4KOaKn8+31j3k6fRzNZTVM5QSl/7s3XwbRxdn89TckMR tVcThqZoh/anvI9FL3V8m1kLeIOb5tlbn2ABb/mVPOtD X-Google-Smtp-Source: APXvYqxAgwXw8kBz/jPDVXZwRYVGembwZUU3rOERH7r9SgZREmUtZyq1mn/TME7Ru9vHPDnQNZgE6eXeNapp5CgTYu8= X-Received: by 2002:a5d:494d:: with SMTP id r13mr27936763wrs.152.1562702883406; Tue, 09 Jul 2019 13:08:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Janak Amarasena Date: Wed, 10 Jul 2019 01:37:56 +0530 Message-ID: To: Aaron Parecki Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000414af3058d451e58" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:08:10 -0000 --000000000000414af3058d451e58 Content-Type: text/plain; charset="UTF-8" Hi, A few rewording suggestions; *section-6.2* Original: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request *request *for an access token... Suggestion: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request for an access token. *section-7* Original: Public browser-based apps needing user authorization create an authorization request URI with the authorization code grant type per Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being received by the app. Suggestion: Public browser-based apps needing user authorization *should *create an authorization request URI with the authorization code grant type *as *per Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being received by the app. *section-8* Original: ... can potentially continue using the stoken refresh token to obtain new access without being detectable by the authorization server. Suggestion: can potentially continue using the *stolen *refresh token to obtain new access *tokens *without being detectable by the authorization server. Also in *section-9.6,* it is a bit hard to understand what is meant by the below statement. *If POSTs in particular from unsupported single-page applications* are to be rejected as errors per authorization server security policy... Best Regards, Janak Amarasena On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill wrote: > I see now that my arguments for softening the 6.1 language are backed and > expanded on by the last paragraph of section 5, starting with " By > redirecting to the authorization server,..." > > > On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > >> regarding 6.1. Apps Served from a Common Domain as the Resource Server >> >> Isn't this recommendation neglecting some benefits or use cases of >> Oauth? >> >> * An application that doesn't collect user credentials is an app that >> doesn't need to be audited for problems such as password leakage into log >> files. >> * Applications that offload authentication to a identity server can >> delegate to that server the complexities of MFA, password recovery,and the >> like. Of course these CAN be done in the app, but isn't it sometimes >> better to centralize those features in a identity server? Especially if >> the organization has multiple apps that require these features. >> >> >> I would soften " it is likely a better decision" to "it may be a better >> decision". >> >> Leo >> >> >> On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki wrote: >> >>> Hi all, >>> >>> I've just uploaded a new version of oauth-browser-based-apps in >>> preparation for the meeting in Montreal. >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 >>> >>> This draft incorporates much of the feedback I've received over the last >>> couple months, as well as what we discussed at the last meeting in Prague. >>> >>> The primary change is a significant rewrite and addition of Section 6 to >>> highlight the two common deployment patterns, a SPA with and without a >>> dynamic backend. >>> >>> Please have a look and let me know what you think. I have a slot in the >>> agenda for Montreal to present on this as well. >>> >>> Thanks! >>> >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000414af3058d451e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A few rewording suggestions;
<= div>
section-6.2
Original:
The= Application Server SHOULD use the OAuth 2.0 authorization code grant to in= itiate a request request for an access token...

=
Suggestion:
The Application Server SHOULD use the OAuth 2.0 = authorization code grant to initiate a request for an access token.

section-7
Original:=C2=A0
<= div>Public browser-based apps needing user authorization create an authoriz= ation request URI with the authorization code grant type per Section 4.1 of= OAuth 2.0 [RFC6749], using a redirect URI capable of being received by the= app.

Suggestion:=C2=A0=C2=A0
Public= browser-based apps needing user authorization should create an auth= orization request URI with the authorization code grant type as per = Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being r= eceived by the app.=C2=A0

section-8
=
Original:=C2=A0=C2=A0
... can potentially continue usi= ng the stoken refresh token to obtain new access without being detectable b= y the authorization server.

Suggestion:
= can potentially continue using the stolen refresh token to obtain ne= w access tokens without being detectable by the authorization server= .=C2=A0=C2=A0

Also in=C2=A0section-9.6,= =C2=A0it is a bit hard to understand what is meant by the below statement.<= br>
If POSTs in particular from unsupported single-page applic= ations are to be rejected as errors per authorization server security p= olicy...


Best Regards,
Janak Amarasena

On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill <= ;leotohill@gmail.com> wrote:<= br>
I see now that my arguments for softening the 6.1 language are backed and = expanded on by the last paragraph of section 5, starting with " By red= irecting to the authorization server,..."


On Mon, Jul 8, 2019 = at 8:44 PM Leo Tohill <leotohill@gmail.com> wrote:
=C2=A0regarding=20 6.1. Apps Served from a Common Domain as the


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
=
Hi = all,

I've just uploaded a new version of oauth= -browser-based-apps in preparation for the meeting in Montreal.=C2=A0
=


This draft i= ncorporates much of the feedback I've received over the last couple mon= ths, as well as what we discussed at the last meeting in Prague.
=
The primary change is a significant rewrite and addition of = Section 6 to highlight the two common deployment patterns, a SPA with and w= ithout a dynamic backend.=C2=A0

Please have a look= and let me know what you think. I have a slot in the agenda for Montreal t= o present on this as well.

Thanks!

----
Aaron Parecki

<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000414af3058d451e58-- From nobody Wed Jul 10 15:17: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 06A1C120241 for ; Wed, 10 Jul 2019 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZwimSCdjw7Cq for ; Wed, 10 Jul 2019 15:17:41 -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 AF5BA120248 for ; Wed, 10 Jul 2019 15:17:40 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id q22so8216897iog.4 for ; Wed, 10 Jul 2019 15:17:40 -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=18lIrGxvrMtb+nQvuIootfW/eoPBqjE1yJ2odaG1cx8=; b=Y7liEehhWIFtrNz1KvzraUfbneE7XFh5xGSbH4ii3j0kk6LqdYXgvePCls2VC+kgvk DgMxJ4I1FiMO0IHDA35drI4fHbx33G80ly6YLzmJK9ITdG1uDF7Zy8tQpNfFErmMtplz cUgdvhnEGd0gJ1drcx+Y2+JByjURNlSn2jFEWdXjN38QpTls1s8kgiXNZMN5jlNJH3j0 cOOKfxiXdT15sxIttpPZnJblcNQ3uqus0FChitFbzTh3USus7cIc/ihOaHr9YLy37X5j NZyMK73H9Wu30nfwpLh0xpu6nOvJUK+PhsVj3JhFSckvUAU5OKL7YRdwTkUPGqX9HWqO OU6g== 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=18lIrGxvrMtb+nQvuIootfW/eoPBqjE1yJ2odaG1cx8=; b=rJfM514W2d3z+oJIocAIjvoW5OjKmGao9xIwlpuONjEKZb3TTx8Ut925gT7axDhjc0 k1Nxc7rJ+yYEbMuUN2Yk/qGxTJ2W7JWLzwoQ+b/KRvhD6+VFq1troYvVVGel4C0HwDE+ QglcEaOc70y9VcZ/CwA/Dd7V0E0kAIyZoYyznDkR68+dAUtNwNgNy1rtGVmmZNZD2NJv WZCjxFLueQBwjbhKcBNnE6RmquJHH7ZXViraewJtNYc90sfADAObE7AAtFUMaG18IZEE bs21D6XTARENLg//Pxd55XxmOttOe2AXgylhr1TN5T7BUxjnUZ1uPzSA18rOhiXjeN6a 1H+A== X-Gm-Message-State: APjAAAXRRrwShfybv2rFvCMKsrMI6KfRxSzZF52u/avngs26C1NFFgYZ LYVBQzfh9kx1HP5C6lomwHdl9vRumY6Yt3Wla6L78lyWwaw= X-Google-Smtp-Source: APXvYqxmM5HvEu8h1AywrflHmbPBbpp7Cmkv7QzqdzQpo2NqgFU7KyBSzT8uWXVQB8Mq0nLMMeKaeKTcpza/yiRYlwY= X-Received: by 2002:a5d:8508:: with SMTP id q8mr500074ion.31.1562797059685; Wed, 10 Jul 2019 15:17:39 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 18:17:28 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000099432a058d5b0b74" Archived-At: Subject: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2019 22:17:43 -0000 --00000000000099432a058d5b0b74 Content-Type: text/plain; charset="UTF-8" All, Here is our draft agenda for the two sessions we have planned for Montreal: https://datatracker.ietf.org/meeting/105/materials/agenda-105-oauth-00 Please, take a look and let us know if you have any comments. Regards, Rifaat & Hannes --00000000000099432a058d5b0b74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Here is our draft agenda for the t= wo sessions we have planned for Montreal:

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

Regards,
=C2=A0Rifaat & Hannes
=C2=A0
--00000000000099432a058d5b0b74-- From nobody Wed Jul 10 15:19: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 1261A1201E5 for ; Wed, 10 Jul 2019 15:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xjL8r2X1WxVv for ; Wed, 10 Jul 2019 15:19:51 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC6012012A for ; Wed, 10 Jul 2019 15:19:51 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id r9so3679221ljg.5 for ; Wed, 10 Jul 2019 15:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BISNjLzdVly6hqBY1HC1DsjJWNY1QeYODRWeY2J5ZWk=; b=QTSo1wlFXehVqddF5tDHzn2Jbbp72nu33JIC8wKIcvxGTFOOkFMFeb0huht26I89S9 Rvx/4kjCeHVKyXXQdhqEUHu+mpj5t8Mz/mKizu2q3E+PBqfuBPAj75Hiz5klf3hND32A enz0i7pAQbWoYY/mvDTAtGj7WdVtroTgc46W7aLx2kXhFiqlKRteuTGdANL/7wXDhQR1 D0NmperHY3XKzA1oeiSYgBO3/lOVRCvgwGpUqOPNBVyzxRv+CZqr6AGRAGBp0n9iBftO 7dWn7XjuNaYT9PSEKIllmG8dcNNi3l+YEq/JyE3Zaq8s7iR4+ML8t+HfLvCauqSnZ4Et SILw== 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=BISNjLzdVly6hqBY1HC1DsjJWNY1QeYODRWeY2J5ZWk=; b=Z9Td0N2k7c9MJcr1gZx3LVmEG3ZEB/lM/egWM46Kmgta2Hambe3rvW1PUmXQYyjwa4 RAu7/puWK0Y0ZgG2xp0gl/p+nJKH8PiNNAGe5XWrqp2iXoUoc6k7eP6dXeiyOpu4yZKd BpsRAW2VLryNmz0n0YtdWzBtDp1J11+3Ax3yrwSoBpYjR5n42BsnM3NsC02S+7BNTmXK wChOpYPdGVbDGn18WVJV1XFIXRe/c+I9pCZStmNZdGZou7fN9iSzLb2B70UYp4rXVbhZ Zc/Wi+/0dvlN4OTyhAzK1rIcPQmAcwE/2yGr5p8m8vueYlYvD0y1YWEXI67EhxyCCyL8 DBag== X-Gm-Message-State: APjAAAXGjAjjMNAQ4WTxb5lRe4SBp/rzosmJFgaKdwGa93LAx62m9kNW jcHlVaA/WB0C+L8NPXD1pyzQxbF6881RIkNcOVQ= X-Google-Smtp-Source: APXvYqzg/1BLXNnycIxCjusf41qKf5/n0tT7yL2NYE2hjniTf7rzK7sIgOq5uN2alqnSEwWpWDhNVyZxF7QEOC7ISKQ= X-Received: by 2002:a2e:25a:: with SMTP id 87mr302489ljc.183.1562797189201; Wed, 10 Jul 2019 15:19:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 10 Jul 2019 15:19:38 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000005181eb058d5b13f2" Archived-At: Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jul 2019 22:19:53 -0000 --0000000000005181eb058d5b13f2 Content-Type: text/plain; charset="UTF-8" +1 I like it! :) On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef wrote: > All, > > Here is our draft agenda for the two sessions we have planned for Montreal: > https://datatracker.ietf.org/meeting/105/materials/agenda-105-oauth-00 > > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000005181eb058d5b13f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1=C2=A0

I like it! :)
<= br>
On Wed,= Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

Here is our draft agenda for the two sessions we have planned for Montreal= :

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

Regards,
=C2=A0Rifaat & Hannes
=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000005181eb058d5b13f2-- From nobody Wed Jul 10 16:28: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 B7B02120073 for ; Wed, 10 Jul 2019 16:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 D_A1lQ64gBb3 for ; Wed, 10 Jul 2019 16:28:04 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE360120019 for ; Wed, 10 Jul 2019 16:28:04 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id g20so8451656ioc.12 for ; Wed, 10 Jul 2019 16:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82Qk40EBTgE4uJGTMzou1iCz5rhFPjSbkHWzF1aP0rc=; b=b6SMGA4+nFGbUgk7nCykmH8jR03npessRqyx9luzsNHTCe5J9c71WpVZ7HHujVAtoY p9u9a7D7CKefW6E0YQRMgytFVjrdekMe2SGALRlhJRAevzV4XsaSKIXAWfuNirey738u V+SxRYUaG6Lkkp4MuJOUhCYrkWBggPaAajUUkSuRW12dYjQAD9z3Vlco1VNbyv0CZNNr 7GQ5jGCzn7exyJd3aP+D9Ki/yqafGdH1BHx+XAfPmbXfgavQmTMGF3NuLsKNrU+LHWds /lciN7OdnHEUtV1C0XgFSuw8JBRvKTci/VZgZZ567Yt3tuwKRMHEpaWn9RCP32NJcrw8 Dtgg== 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=82Qk40EBTgE4uJGTMzou1iCz5rhFPjSbkHWzF1aP0rc=; b=Ec/DDbstOSSVWXNnsfmo10XMkwZfV8MtieM7uqxht7CxqbTb/BwuJEft1lzYAVKABC aqA3yDzevbpV7nqCE14iQ4G207df+ORVLEskHkpjUJRT0fsHKO4c5XpW1sR9MIpZwazq pgT8Aoi1xnkQ0s58jlaQK7S85cL8c6/PDkWo9yQfG8p8u5AS1AJH4XROU85I5N375cll VqA3VUzUp9n2m624/cwGRcsG1OgErT/mw5OzFyS3vBVCLoBeP3n7XXhZnujzHmrC/Dnq hbtxDhONBWdmTSzNhhgakmr9RHElYI+QEIt2r0vfzu4S/Tn3jNY9n2qbl8Vq9tkdNoOE VR8Q== X-Gm-Message-State: APjAAAXjN2/UkMG+WUabGj96zE50P9kDOGu/yydFUWipRqZ2L7A7dfoP LxT3/kNYMT+R28NBBa8d61pFCsWI X-Google-Smtp-Source: APXvYqwlQOvTx7E1FfPzE0XszVVestk6If1u3rgmisYjIcs7CF7rT2HpZuapoMa49VaCMLdTZrrvCw== X-Received: by 2002:a5d:9bc6:: with SMTP id d6mr735661ion.160.1562801283741; Wed, 10 Jul 2019 16:28:03 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id c81sm4679191iof.28.2019.07.10.16.28.03 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:28:03 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id j6so8511576ioa.5 for ; Wed, 10 Jul 2019 16:28:03 -0700 (PDT) X-Received: by 2002:a6b:6e01:: with SMTP id d1mr768920ioh.156.1562801282920; Wed, 10 Jul 2019 16:28:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 10 Jul 2019 16:27:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Janak Amarasena Cc: OAuth WG Content-Type: multipart/alternative; boundary="00000000000052bca7058d5c07b6" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:28:07 -0000 --00000000000052bca7058d5c07b6 Content-Type: text/plain; charset="UTF-8" > > Isn't this recommendation neglecting some benefits or use cases of > Oauth? This recommendation doesn't say you can't still centralize your account management in a dedicated component. If that component shares a domain with the application, you don't need OAuth to hop back and forth, you can just have the centralized account system set a cookie on the same domain. That said, I also agree that it reads better as "it may be a better decision" anyway. Also in section-9.6, it is a bit hard to understand what is meant by the > below statement. > If POSTs in particular from unsupported single-page applications are to be > rejected as errors per authorization server security policy... I agree, it's confusingly worded and I'm not sure it actually adds anything to the section, so I'm removing it. Suggestion: > Public browser-based apps needing user authorization *should *create an > authorization request... I see the intent here, but I don't want to confuse this with normative wording like "SHOULD". I've rephrased this paragraph to better lead into the next two sections instead. Leo and Janak, thanks for the other typo fixes too. These edits are currently in my source file on GitHub, https://github.com/aaronpk/oauth-browser-based-apps as I believe it's no longer possible to publish an updated version to ietf until after the meeting. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 9, 2019 at 1:08 PM Janak Amarasena wrote: > Hi, > > A few rewording suggestions; > > *section-6.2* > Original: > The Application Server SHOULD use the OAuth 2.0 authorization code grant > to initiate a request *request *for an access token... > > Suggestion: > The Application Server SHOULD use the OAuth 2.0 authorization code grant > to initiate a request for an access token. > > *section-7* > Original: > Public browser-based apps needing user authorization create an > authorization request URI with the authorization code grant type per > Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being > received by the app. > > Suggestion: > Public browser-based apps needing user authorization *should *create an > authorization request URI with the authorization code grant type *as *per > Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being > received by the app. > > *section-8* > Original: > ... can potentially continue using the stoken refresh token to obtain new > access without being detectable by the authorization server. > > Suggestion: > can potentially continue using the *stolen *refresh token to obtain new > access *tokens *without being detectable by the authorization server. > > Also in *section-9.6,* it is a bit hard to understand what is meant by > the below statement. > *If POSTs in particular from unsupported single-page applications* are to > be rejected as errors per authorization server security policy... > > > Best Regards, > Janak Amarasena > > On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill wrote: > >> I see now that my arguments for softening the 6.1 language are backed and >> expanded on by the last paragraph of section 5, starting with " By >> redirecting to the authorization server,..." >> >> >> On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: >> >>> regarding 6.1. Apps Served from a Common Domain as the Resource Server >>> >>> Isn't this recommendation neglecting some benefits or use cases of >>> Oauth? >>> >>> * An application that doesn't collect user credentials is an app that >>> doesn't need to be audited for problems such as password leakage into log >>> files. >>> * Applications that offload authentication to a identity server can >>> delegate to that server the complexities of MFA, password recovery,and the >>> like. Of course these CAN be done in the app, but isn't it sometimes >>> better to centralize those features in a identity server? Especially if >>> the organization has multiple apps that require these features. >>> >>> >>> I would soften " it is likely a better decision" to "it may be a better >>> decision". >>> >>> Leo >>> >>> >>> On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki wrote: >>> >>>> Hi all, >>>> >>>> I've just uploaded a new version of oauth-browser-based-apps in >>>> preparation for the meeting in Montreal. >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 >>>> >>>> This draft incorporates much of the feedback I've received over the >>>> last couple months, as well as what we discussed at the last meeting in >>>> Prague. >>>> >>>> The primary change is a significant rewrite and addition of Section 6 >>>> to highlight the two common deployment patterns, a SPA with and without a >>>> dynamic backend. >>>> >>>> Please have a look and let me know what you think. I have a slot in the >>>> agenda for Montreal to present on this as well. >>>> >>>> Thanks! >>>> >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --00000000000052bca7058d5c07b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Isn't this recommendation neglecting some benefits=C2=A0 or = use cases of Oauth?=C2=A0=C2=A0

This recommendation doesn't say you can't still centralize your ac= count management in a dedicated component. If that component shares a domai= n with the application, you don't need OAuth to hop back and forth, you= can just have the centralized account system set a cookie on the same doma= in. That said, I also agree that it reads better as "it may be a bette= r decision" anyway.

Also in section-9.6, it is a bit hard to understand wha= t is meant by the below statement.
If POSTs in particular from unsupport= ed single-page applications are to be rejected as errors per authorization = server security policy...

I agree, it's= confusingly worded and I'm not sure it actually adds anything to the s= ection, so I'm removing it.

Suggestion:=C2=A0=C2=A0
Public browser-= based apps needing user authorization=C2=A0should=C2=A0create an aut= horization request...

I s= ee the intent here, but I don't want to confuse this with normative wor= ding like "SHOULD". I've rephrased this paragraph to better l= ead into the next two sections instead.

L= eo and Janak, thanks for the other typo fixes too.=C2=A0

These edits are currently in my source file on GitHub,=C2=A0https://github.com= /aaronpk/oauth-browser-based-apps=C2=A0as I believe it's no longer = possible to publish an updated version to ietf until after the meeting.

----
Aaron Parecki
<= div>@aaronpk




On Tu= e, Jul 9, 2019 at 1:08 PM Janak Amarasena <janakama360@gmail.com> wrote:
Hi,

A = few rewording suggestions;

section-6.2
<= /div>
Original:
The Application Server SHOULD use the OAuth 2= .0 authorization code grant to initiate a request request for an acc= ess token...

Suggestion:
The Application= Server SHOULD use the OAuth 2.0 authorization code grant to initiate a req= uest for an access token.

section-7
=
Original:=C2=A0
Public browser-based apps needing user= authorization create an authorization request URI with the authorization c= ode grant type per Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI= capable of being received by the app.

Suggestion:= =C2=A0=C2=A0
Public browser-based apps needing user authoriza= tion should create an authorization request URI with the authorizati= on code grant type as per Section 4.1 of OAuth 2.0 [RFC6749], using = a redirect URI capable of being received by the app.=C2=A0
section-8
Original:=C2=A0=C2=A0
... can potentially continue using the stoken refresh token to obtain new = access without being detectable by the authorization server.

=
Suggestion:
can potentially continue using the stol= en refresh token to obtain new access tokens without being detec= table by the authorization server.=C2=A0=C2=A0

Also in=C2=A0section-9.6,=C2=A0it is a bit hard to understand what = is meant by the below statement.
If POSTs in particular fr= om unsupported single-page applications are to be rejected as errors pe= r authorization server security policy...


Best Regards,
Janak Amarasena

On Tue, Jul = 9, 2019 at 6:43 AM Leo Tohill <leotohill@gmail.com> wrote:
I see now that my argum= ents for softening the 6.1 language are backed and expanded on by the last = paragraph of section 5, starting with " By redirecting to the authoriz= ation server,..."


On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill <= ;leotohill@gmail.c= om> wrote:
=C2=A0regarding=20 6.1. Apps Served from a Common Domain as the Resource Server

Isn't this recommendation neglecting some benefits=C2=A0 or use c= ases of Oauth?=C2=A0

* An application that do= esn't collect user credentials is an app that doesn't need to be au= dited for problems such as password leakage into log files.
= * Applications that offload authentication to a identity server can delegat= e to that server the complexities of MFA, password recovery,and the like.= =C2=A0 Of course these CAN be done in the app, but isn't it sometimes b= etter to centralize those features in a identity server?=C2=A0 Especially i= f the organization has multiple apps that require these features.


I would soften " it is likely a better decision"=C2=A0 to "it may be a better deci= sion".

Leo


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
=
Hi = all,

I've just uploaded a new version of oauth= -browser-based-apps in preparation for the meeting in Montreal.=C2=A0
=


This draft i= ncorporates much of the feedback I've received over the last couple mon= ths, as well as what we discussed at the last meeting in Prague.
=
The primary change is a significant rewrite and addition of = Section 6 to highlight the two common deployment patterns, a SPA with and w= ithout a dynamic backend.=C2=A0

Please have a look= and let me know what you think. I have a slot in the agenda for Montreal t= o present on this as well.

Thanks!

----
Aaron Parecki

_______________________________________________
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
--00000000000052bca7058d5c07b6-- From nobody Wed Jul 10 16:56: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 31F2412025D for ; Wed, 10 Jul 2019 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 O0LmGsV_Rxam for ; Wed, 10 Jul 2019 16:56:19 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA0612004D for ; Wed, 10 Jul 2019 16:56:18 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h6so8586173iom.7 for ; Wed, 10 Jul 2019 16:56:18 -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=pgvAEiKJrpkHVA8BIu3xHS7P8LwzDUd4G89jBUUeZps=; b=zl5gmmi9LvsAVoVRAM5LMxWlItJJ4eAKswktVALQbuyz1ZU3/e4BdQMCt7eBDquTZw ROddgEj/y3aQpyEm+MLnyFUwhWJQaKr5qnTdQyDkNYS/3zIVZyI/pMji2nbA3BimOt8Z 3C8+RPYH9XYQW+XymumcVOxQBRilKQ9cplFIVboRNDtZEFeHuqPMAK10si4v0tuEeVVJ diCALlWsy4185uTRJX4cMV6yA6gRr7CBr2n5YNbNvISdJDiMuvgDq2TJmobzQBWTpVr8 RbS+ZmApbJMlLNVRyFsqrW6aobHyfrRoRVw8xWv1LP4RT8MJcKFd5FQvP1nB+ZhEq0G5 5XMg== 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=pgvAEiKJrpkHVA8BIu3xHS7P8LwzDUd4G89jBUUeZps=; b=owSDlZ2hnVw1reT7MIM9X4BGcLrrmaHEcn/gNqQ2xoX5wO0+aw36yJZbhrYfEpuanT JPVI7h7y6b9QzaY9iOYjUlRA5MFEczekdj1Tp581kTp9kAsQb6lt0fe1LN+4n6sQWExr 8GsuT1Zl8QadCO/U2f51173TuMRHTaEk64JFWNjM2H2E6oW/n99RmXyRi+0GSQxG/NVt Hmp6JK5dGz6aaAr3trr3qSp//MEJqaB8EZrg367KMc8i/Deb7eTcC7lDxOSdJeAsq+WL 5d8PdxudtezmtEMnkjrDD9+yJkmlMI45EDbxPvtAtZzk9WVuCkLiLmEVttafKj3Lx3m4 KPFw== X-Gm-Message-State: APjAAAWSz6aDRvldWyuSTn041Vjbc852ArUfxS0O1Y95/cn4yV9J9+90 S6GwJUtMXzngqtj+Xv9/gH39vSJm X-Google-Smtp-Source: APXvYqwrSpyD5i+cWyBEEYegZguWHsKIA3q67MG5a+tkqQTYm0tfQYKL8wX0FsKhAL9JoClGW066DA== X-Received: by 2002:a5e:8f08:: with SMTP id c8mr27082iok.52.1562802977383; Wed, 10 Jul 2019 16:56:17 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id m20sm4237178ioh.4.2019.07.10.16.56.16 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:56:16 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id h6so8586020iom.7 for ; Wed, 10 Jul 2019 16:56:16 -0700 (PDT) X-Received: by 2002:a6b:7a42:: with SMTP id k2mr897065iop.214.1562802976057; Wed, 10 Jul 2019 16:56:16 -0700 (PDT) MIME-Version: 1.0 References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> In-Reply-To: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> From: Aaron Parecki Date: Wed, 10 Jul 2019 16:56:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: George Fletcher Cc: David Waite , Leo Tohill , OAuth WG Content-Type: multipart/alternative; boundary="0000000000003df0ee058d5c6caf" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:56:22 -0000 --0000000000003df0ee058d5c6caf Content-Type: text/plain; charset="UTF-8" > > 2. To use a refresh token at the /token endpoint, client authentication is > required. This is where it gets difficult for default SPAs because they are > public clients and the only mechanism to authenticate them is the client_id > which is itself public. For me, this is the real risk of exposing the > refresh_token in the browser. RFC6749 says "If the client type is confidential or the client was issued client credentials, the client MUST authenticate..." which I take to mean that refresh tokens could be used without a client_secret, both for native an javascript apps. This discussion of offline vs online refresh tokens is interesting, but I worry that we may be narrowing our focus here too much. There's a use where JavaScript apps may be able to take advantage of offline access, which is around Service Workers. This allows a website to install some code from a website which can continue to run in the background, though sometimes only while triggered from external events. One useful example of this is a syncing daemon, where a push notification can be sent from a web server to a Service Worker, which could cause that code in the browser to need to make a request to an API, which then may need to be able to get a new access token, which is effectively offline access. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 9, 2019 at 9:16 AM George Fletcher wrote: > I'll just add a couple more thoughts around refresh_tokens. > > 1. I agree with David that refresh_tokens are valuable in an "online" > scenario and should be used there. > > 2. To use a refresh token at the /token endpoint, client authentication is > required. This is where it gets difficult for default SPAs because they are > public clients and the only mechanism to authenticate them is the client_id > which is itself public. For me, this is the real risk of exposing the > refresh_token in the browser. > > 3. If the AS supports rotation of refresh_tokens and an attacker steals > one and uses it, then the SPA will get an error on it's next attempt > because it's refresh_token will now be invalid. If the refresh_tokens are > bound to the user's authentication session, then the user can logout to > lockout the attacker. However, that is a lot of "ifs" and still provides > the attacker with time to leverage access via the compromised refresh_token. > > In principle, I agree with the recommendation that SPAs shouldn't have > refresh_tokens in the browser. If it's not possible to easily refresh the > access token via a hidden iframe (becoming more difficult with all the > browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a > simple server component such that the backend for the SPA can use > authorization_code flow and protect a client_secret. > > Thanks, > George > > On 7/8/19 11:17 PM, David Waite wrote: > > > On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: > Re 8. Refresh Tokens > > ???? "For public clients, the risk of a leaked refresh token is much > ?? ??greater than leaked access tokens, since an attacker can potentially > ?? ??continue using the stolen refresh token to obtain new access without > ?? ??being detectable by the authorization server.?? " > > (first, note the typo "stoken".) > > Is it always "higher risk"??? I could even argue that leakage of a refresh > token is lower risk. As a bearer document, a leaked access token allows > access to resources until it expires.?? A leaked refresh token, to be > useful,?? requires an exchange with the AS, and the AS would have the > opportunity to check whether the refresh token is still valid (has not been > revoked).?? (of course revocation might NOT have happened, but then again, > it might have.) > > > I agree (with caveats, of course). > > Access tokens and refresh tokens may or may not be attached (by policy) to > an authentication session lifetime. It is far easier to picture refresh > tokens which are not attached to an authentication session (sometimes > called ???offline??? access) being inappropriate for a browser-based app, > which is nearly always a client that the resource owner is interacting with. > > Variants that may want offline tokens are less easy to imagine - perhaps > browser extensions? > > I believe the language currently there is due to AS implementations > predominantly treating refresh tokens as being for offline access, and > access token lifetime being short enough to not outlast an authentication > session. > > Furthermore, since the access token is transmitted to other servers, the > risk of exposure is greater, due to possible vulnerabilities in those > called systems (e.g., logs).?? Isn't this the reason that we have refresh > tokens? Don't refresh tokens exist because access tokens should have short > TTL, because they are widely distributed? > > > Yes. Once you acknowledge the existence of ???online??? refresh tokens, > they become a strong security component: > > - Refresh tokens let you shorten the access token lifetime > - A shorter access token lifetime lets you have centralized policy to > invalidate access without needing to resort to token > introspection/revocation > - Token refresh can theoretically be used to represent other policy > changes by both the client (creating tokens targeting a new resource server > or with reduced scopes) and server (changing entitlements and > attributes/claims embedded within a structured token) > - Refresh tokens can be one-time-use, as recommenced by the security BCP. > A exfiltrated refresh token will result in either the attacker or the user > losing access on the next refresh, and a double refresh is a detectable > security event by the AS. > > "Additionally, browser-based applications provide many attack vectors by > which a refresh token can be leaked." > > The risks of leaking a refresh token from the browser are identical to the > risks of leaking an access token, right??? This sentence could be changed > to "... by which *a token* can be leaked." > > A refresh token is "higher risk" because its TTL is usually greater than > the access token's TTL.?? But if our advice here leads to people using > longer-lived access tokens (because of the problems with getting a new > access token without involving the user), then the advice will be counter > productive.???? The longer life gives more time for the usefulness of a > browser-side theft, and more time for the usefulness of a server-side > theft.?? > > Which scenario is safer? > > A) using an access token with a 10 minute TTL, accompanied by a refresh > token with a 1 hour TTL > B) using an access token with a 1 hour TTL, and no refresh token.?? > > > > Given tokens that track authentication lifetime, it is hard to make a case > that refresh tokens which last for the authentication session are a greater > security risk than opaque access tokens (requiring token introspection) > that will last the same time.?? > > Typically an AS (or OP) would issue a structured access token with a > lifetime expected to expire before the authentication session, with new > tokens issued via requests made in an embedded, iframe (hidden, > prompt=none). There may be benefits here of user cookies (or perhaps > managed-device information) against an authorization endpoint being used to > make decisions that could not be made by a refresh against the token > endpoint.?? > > I???d be interested in hearing how strong of an implementation issue this > might be for deployments - I could see a non-security argument that the BCP > should only have one recommended approach here, and that there are > deployments needing the iframe approach. > > -DW > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003df0ee058d5c6caf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2. To use a refresh token at= the /token endpoint, client authentication is required. This is where it g= ets difficult for default SPAs because they are public clients and the only= mechanism to authenticate them is the client_id which is itself public. Fo= r me, this is the real risk of exposing the refresh_token in the browser.= =C2=A0

RFC6749 says "If= the client type is confidential or=C2=A0the client was issued client crede= ntials,=C2=A0the client MUST authenticate..." which I take to mean tha= t refresh tokens could be used without a client_secret, both for native an = javascript apps.

This discussion of offline vs onl= ine refresh tokens is interesting, but I worry that we may be narrowing our= focus here too much.

There's a use where Java= Script apps may be able to take advantage of offline access, which is aroun= d Service Workers. This allows a website to install some code from a websit= e which can continue to run in the background, though sometimes only while = triggered from external events. One useful example of this is a syncing dae= mon, where a push notification can be sent from a web server to a Service W= orker, which could cause that code in the browser to need to make a request= to an API, which then may need to be able to get a new access token, which= is effectively offline access.

----
Aar= on Parecki



On Tue, Jul 9= , 2019 at 9:16 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session= , then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easil= y refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11= :17 PM, David Waite wrote:
=20

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com> wrote:<= /div>
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "=

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) bein= g inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perhaps browser extensions?

I believe the language currently there is due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

"Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a token can be leaked."

A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL.?? B= ut if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??

Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=3Dnone). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??

I???d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW


= 
____________=
___________________________________
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
--0000000000003df0ee058d5c6caf-- From nobody Wed Jul 10 17:06: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 54146120222 for ; Wed, 10 Jul 2019 17:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 5w0cUJ96Fy-2 for ; Wed, 10 Jul 2019 17:06:12 -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 75925120019 for ; Wed, 10 Jul 2019 17:06:12 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id i10so8578326iol.13 for ; Wed, 10 Jul 2019 17:06:12 -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=VC4C1q2VgMt6OXHqob8/b6aHecFyABRUcBBguc6J/2M=; b=hlvwTlcb+U2H5ix4ILvRhf3eNWX2ebAKaUSpxKUYKU5SP+N3FylPP4K4Xyzf0BhtZv mt/d6iD8ga6xNAHiz+IiuhpT7k298mrmKHOU7S8z75IWetmojxrawydFGmeVBrf+Eyc4 eheMVtLOCcmoJtOkEGaLzyv7qrTm1CVT7ha+oMJ5a8Gv1/W6Nrg1oEdijP+aMEoFbjPs hWXAFchdPv74TxH47No8Q5qO611JRu6v5EznmWxa3XYYySh2RyWfvB04igNzBZxe++a7 XzvKQ6G0iCyHRiMSOgyCIs2OZQsaMZCplxZFtL5Kz5GeUQXuDY66o2fddjcSKK4oPyVw tPlw== 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=VC4C1q2VgMt6OXHqob8/b6aHecFyABRUcBBguc6J/2M=; b=WI08iny8eTcEgwOkQEwqBVAW7xSjAv75tbSAhwgzzncMUwMbT3cgebUlB98grlzHzf JwmOV0Zl/5uxNa8yFvFxHNc+OI9nV7eVGKlKX8zKwJ1dqVSN2zE8wq6b2NEwHZQbySRf 5w6tiV/SU4tVMHdXe3B9/pvtk6ur8yCtiTXJJc1M/Th35rFFk2E2zJPd/xpmkAjFloNE Nq83YXcWHACIu43qmvFnEPwXQx0hHrR5nWD3/mJ+6f7HLeRLJOjwMn/PUKcjBA7xuSOT ZHr3Ep4ZPCbSf5yzdQMf0PIzSOQcgsF135wqYWE71Kd5QlN145dViOnW1ihqNdNOSSBL 91Cw== X-Gm-Message-State: APjAAAUfESDl9JBF/dFAdWIYNqrsOje/ZN0QEG1BbNNRiiInyte8Rv3w 8oNDOEZoIASSh1sOrWcwqIfTNaus X-Google-Smtp-Source: APXvYqwbnewGX6VlJUAiB/DcjtTeCxUvTTy23+j1mP3ZhClcK1V/fW8aPlFn/lOG0PiOSqKp8oZ05w== X-Received: by 2002:a6b:dc08:: with SMTP id s8mr965988ioc.209.1562803571377; Wed, 10 Jul 2019 17:06:11 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id n17sm3422644iog.63.2019.07.10.17.06.10 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 17:06:10 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id i10so8578229iol.13 for ; Wed, 10 Jul 2019 17:06:10 -0700 (PDT) X-Received: by 2002:a6b:7a42:: with SMTP id k2mr945892iop.214.1562803570296; Wed, 10 Jul 2019 17:06:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 10 Jul 2019 17:05:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Leo Tohill Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000a94ce2058d5c8ffb" Archived-At: Subject: Re: [OAUTH-WG] historical note regarding use of url fragment in OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 00:06:14 -0000 --000000000000a94ce2058d5c8ffb Content-Type: text/plain; charset="UTF-8" > > Does this historical note mean to indicate that if the implicit flow were > designed today, it could use path instead of fragment to carry the token? I see how it reads that way, but that was not my intent. The implication is that now browsers can use the authorization code flow with no modifications needed, (getting the authorization code back in the query string rather than modifying it to use the fragment), since the Session History API can be used to remove it from the URL. I've updated the section to clarify that, so thanks! ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 9, 2019 at 8:55 AM Leo Tohill wrote: > > re: > > 9.8.7 . Historic Note > > Historically, the Implicit flow provided an advantage to single-page > apps since JavaScript could always arbitrarily read and manipulate > the fragment portion of the URL without triggering a page reload. > Now with the Session History API (described in "Session history and > navigation" of [HTML ]), browsers have a mechanism to modify the path > component of the URL without triggering a page reload, so this > overloaded use of the fragment portion is no longer needed. > > > Does this historical note mean to indicate that if the implicit flow were > designed today, it could use path instead of fragment to carry the token? > > Doesn't this overlook the important aspect that fragments are not sent to > the server? > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a94ce2058d5c8ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does this historical note mean to indicate that if the implicit = flow were designed today, it could use path instead of fragment to carry th= e token?

I see how it reads that way, but t= hat was not my intent. The implication is that now browsers can use the aut= horization code flow with no modifications needed, (getting the authorizati= on code back in the query string rather than modifying it to use the fragme= nt), since the Session History API can be used to remove it from the URL. I= 've updated the section to clarify that, so thanks!

----
Aaron Parecki


On Tue, Jul 9, 2019 at 8:55 AM Leo Tohill <leotohill@gmail.com> wrote:

re: 
9.8.7.  Historic Note


   Historically, the Implicit flow provided an advantage to single-page
   apps since JavaScript could always arbitrarily read and manipulate
   the fragment portion of the URL without triggering a page reload.
   Now with the Session History API (described in "Session history and
   navigation" of [HTML]), browsers have a mechanism to modify the path
   component of the URL without triggering a page reload, so this
   overloaded use of the fragment portion is no longer needed.

Does this historical note mean to indicate that if the = implicit flow were designed today, it could use path instead of fragment to= carry the token?

Doesn't this overlook the im= portant aspect that fragments are not sent to the server?


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a94ce2058d5c8ffb-- From nobody Wed Jul 10 20:18: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 2EB34120019 for ; Wed, 10 Jul 2019 20:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EydkbK3nXa1 for ; Wed, 10 Jul 2019 20:18:23 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D0B12006E for ; Wed, 10 Jul 2019 20:18:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B3C141C134A; Wed, 10 Jul 2019 20:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWah_1a4Ngoj; Wed, 10 Jul 2019 20:18:16 -0700 (PDT) Received: from [172.31.98.5] (unknown [96.229.48.220]) by c8a.amsl.com (Postfix) with ESMTPA id 6E1E81C1349; Wed, 10 Jul 2019 20:18:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20190705135606.F345BB8223A@rfc-editor.org> Date: Wed, 10 Jul 2019 20:18:21 -0700 Cc: rfc8252@wdenniss.com, rfc8252@ve7jtb.com, rdd@cert.org, kaduk@mit.edu, Hannes Tschofenig , rifaat.ietf@gmail.com, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <34FAE15F-85F6-4FA6-A8CD-40B465825E2A@amsl.com> References: <20190705135606.F345BB8223A@rfc-editor.org> To: RFC System , dziekan.jan@gmail.com X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776) X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Jul 2019 03:18:25 -0000 Hi Jan, Please note that this errata report has been removed. As stated at=20 https://www.rfc-editor.org/errata.php: "Errata are for the RFCs as available from rfc-editor.org." We have sent separate mail regarding this error to=20 webmaster@tools.ietf.org. Thank you. RFC Editor/mf On Jul 5, 2019, at 6:56 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5776 >=20 > -------------------------------------- > Type: Editorial > Reported by: Jan Dziekan >=20 > Section: GLOBAL >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > RFC8252 references specific Sections of RFC6749, however urls are = pointing to Sections in RFC8252. > For example, in Section 6 there is a statement "code grant type per = Section 4.1 of OAuth 2.0 [RFC6749]", where "Section 4.1" links to = https://tools.ietf.org/html/rfc8252#section-4.1 instead of = https://tools.ietf.org/html/rfc6749#section-4.1 > I have found such misplaced links in the following sections: 6, 8.2, = 8.4, 8.5, 8.6, 8.12 >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8252 (draft-ietf-oauth-native-apps-12) > -------------------------------------- > Title : OAuth 2.0 for Native Apps > Publication Date : October 2017 > Author(s) : W. Denniss, J. Bradley > Category : BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Jul 10 23:26: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 7D25B1200F8 for ; Wed, 10 Jul 2019 23:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 kRoaXAjaECjB for ; Wed, 10 Jul 2019 23:26:29 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0: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 1A0DA12008B for ; Wed, 10 Jul 2019 23:26:29 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id b7so4688504otl.11 for ; Wed, 10 Jul 2019 23:26:29 -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=XLulbiPV+kGK0BCYOVftQ4lDSdsgwMK8bwCEAOn81mo=; b=LjbV84ZdwBcCD3aTUcV0lClP+tIIUmV4HVIJD9Tz6MacEuILtvArjc/eoZXtPoTnCM RZ8NYqeAcjTD812jFkzw8gq44CHc26z6Hd1qzZuQDdB/lqedpUr4cVCxACOyZegrlugh K6dGaqbIN1N+XA2pkRkaja6izQH4k/oLtjWuaw5+Dm8pLmpHMLYzkRCVj3jqZns9H8SW aU+tI+MqLxnMgpqvijfL1yG+0e0DCLwovBl+hqoXuTntznG2/odgyTGznvttd1LHmbhf DesW0guihUS5x+zKsGPdoOnr0K2pPjedjYJgNVTg6PfsbBBLrFaQ2/GkYgFsfbTCO4ff KZMw== 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=XLulbiPV+kGK0BCYOVftQ4lDSdsgwMK8bwCEAOn81mo=; b=Wqiby4cx3fcH4L2wRlhab7ZzzJRoygsl0UM/3ov8Ka4mzmkiCarG4abTO7ZauZ3ckE ZS/WRczjnomRcHoOWZR0KfluqvbeWBcGJHO1OnLiX19AL/s86c5iIZyP8puDaDWx+UV3 2PzpdA/5PcFJCRnMvDuzubLtrIKZ+xInISMpjM9QfrmQksCUjqrbvXD3WeppA1rG4y2i 9P7nmZu8qqBNd3HylhoYLuKKuQqVFQQxkOYEJ2s+Kule0PzedntQZariGjeX9GMwLzo8 CPLztwMvqWWu1agXQmAg6BjyhUMqoUntqyh/n6O14pUTbT4KAUDkIV/S/AD02+TvOGhN rqeQ== X-Gm-Message-State: APjAAAXfEgzxXqa5tRud9E36auyJa5nuOq7o29pjAs0tSOjMOjMg1JS2 kTqJWdik/lIeTRA6ZS+cEkqTWPf5gY7WR/oQSmI= X-Google-Smtp-Source: APXvYqw9md9hFs47sQCUAqiW/7amnRjLB7AxP0AwkdbJcUBSavVxycQRqPVfFqb7jy858IrV1e1aAe/nVIORdQs4me0= X-Received: by 2002:a9d:73d0:: with SMTP id m16mr2133384otk.190.1562826388327; Wed, 10 Jul 2019 23:26:28 -0700 (PDT) MIME-Version: 1.0 References: <20190705135606.F345BB8223A@rfc-editor.org> <34FAE15F-85F6-4FA6-A8CD-40B465825E2A@amsl.com> In-Reply-To: <34FAE15F-85F6-4FA6-A8CD-40B465825E2A@amsl.com> From: Thomas Broyer Date: Thu, 11 Jul 2019 08:26:17 +0200 Message-ID: To: Megan Ferguson Cc: RFC System , dziekan.jan@gmail.com, rfc8252@wdenniss.com, rfc8252@ve7jtb.com, "" Content-Type: multipart/alternative; boundary="000000000000b8d3e3058d61dfa9" Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776) X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Jul 2019 06:26:30 -0000 --000000000000b8d3e3058d61dfa9 Content-Type: text/plain; charset="UTF-8" Hi Megan, On Thu, Jul 11, 2019 at 5:18 AM Megan Ferguson wrote: > Hi Jan, > > Please note that this errata report has been removed. As stated at > https://www.rfc-editor.org/errata.php: > > "Errata are for the RFCs as available from rfc-editor.org." > Well, fwiw, the issue is also present in https://www.rfc-editor.org/rfc/rfc8252.html#section-6 --000000000000b8d3e3058d61dfa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Megan,

On Thu, Jul 11, 2019 at 5:18 AM = Megan Ferguson <mferguson@amsl.com= > wrote:
= Hi Jan,

Please note that this errata report has been removed.=C2=A0 As stated at https://www.rfc-editor.org/errata.php:

"Errata are for the RFCs as available from rfc-editor.org."

Well, fwiw, the issue is also present in=C2= =A0https:= //www.rfc-editor.org/rfc/rfc8252.html#section-6

--000000000000b8d3e3058d61dfa9-- From nobody Thu Jul 11 12:52: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 2C20B120155 for ; Thu, 11 Jul 2019 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EekM4Hq6LPMy for ; Thu, 11 Jul 2019 12:52:04 -0700 (PDT) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9997912008B for ; Thu, 11 Jul 2019 12:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1562874722; bh=e4xpYzftk48jovj5GsjtrjKmFvh31+QtFqQ6+hamd28=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=p5vSrqDVSWAaoV5ahqdpImkwaHlYYOIRCQ8pld95nf2sfbeHEvtfd78wcRbyHxy1JKD3EUEbJFIV91kVBJ6hgPVFFut8uuSxboJWnlBchieaqlZc3n+68GUwzxVvyIkBX70y9j1c+0b26gDqnrWRn2yX+eCQrxuBMRUJF8YNrVvmTYWStg4rJwJJOB/6+ydLA8UXoAILFem+WQ5sQlXvOZT7qeQkZrxp2VYK1TT4z/v1sfoO+Hm7ofE1jO4bnKBiPWdHkMvnA6NN9sqvhJqb2JzR5PO+AsWLQ1iOew58UkRBF7DS29IQATdzy8gy1TimlIm2+pqv9vejTiXPAU5sMQ== X-YMail-OSG: kE54DDMVM1kawZbZiYcU0hDmAObSn5XjYz.3iWmvtTGCKK0Hzos0NG0SKZv1bSb q7_B24hlaIR256sD2k1f9xkRc_BJ11TH_PW.ccnXyO4Q6kQNZEPflxR6ZUKHEDdfHExf9Sx.tDZe 2VjACkKn7lzDlLkE8zJt8BI8WBfsTqBtoXe6QcfSj3I_LLI3QGCRzjnEKUQ1118puUw4pZF1ICeI 32W.MSSHl1cDzbD.8iqAY7fyqWlLCrCMbgQCXdEMB4zwxLSMhm5JS8zXKf7zKpFikTg4K3UE2BF4 J6l57lkZAW0DTiaoW7o8p6N8oOC5QTtzTHqPLtXghOdciMbQs6.oCy2.7cMrERa4SGpyjXhWCqZi 37ZthI85tGVsilCMd_APAxuiJTRl9sfMhIPWqODQZ1tK5VtTamn5rAsbVBay2TmLZbyeAB3fuJYO rC_KRrBBKY0F8IAQxwgQ7yZvfKParkAZxFWBvvgRFkwBUh7ZrYWsgI2m_I081O3vmhptyqka98ph xVyFcAssQI022_f9mJ0gyTUbmAaT9xwA5Kkvb6zhYgkWB8jR5LSFo8HRH6rUeU_eBpqq2exAGxbJ uqilm7hH7M0Lm1_J6.NC9A.V8ZwZMq_vAYcPvtSFT1mxB8TbEV6azNUmUSstD71fJ_1ZWAQi.Yuh _Ui5m10_6PZBHppJPBmtJdZWzxcx2Z.a_TPXFe_ma46MAlT2r9rKEE87yooZQboQHDBSvkdE7MJe F9oxaY0Obly0NV0if91nIkBNYXyuoktJpsC_YGd9IDo0nVmw9h61lwEDXo.wDcJVfH7HC968q3dE rY_w2XGOBH_dPD0qaNbnFStuZy3lOhAsK4fxGLzrNxPt9bjKB2sCMiaJYIxzwLX1cNVTeEbcUGEH fDcsBiy2nznQ8h5DfNujCV0rBNb7BUBWaoWzg5AvnhtEiiPGfmeb_Kr2osnD823J4dYtZdfWK6L6 IrUzPcFvSRdJJGy6IEb94zKx94FwLlG7bRqDuO_9x1Qvfphe3rPaHBeb5fNcCwJSlJy4OV2I1VJs YfSj.5RUmNV9aFeVE2UwguZI5XxB.TrjRekPXJuLAFEgfnfBuGh54YJMQsCW0MtPxYOCt62VgWH1 oAmWunAvYST.uox3uanfHIiVFz9_M6Tnap9Ua2aMvVh20taTg4_njmdYdWs7Yeq2CeQt7xWYaUPp SBlQdDX3W9CC_IvTzbaMKubP96mBhoo9jojjiJPGD87BLZur2yVaW_5eOFYYUEtoWt9e9r.85GBJ Wl2rAF3Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Thu, 11 Jul 2019 19:52:02 +0000 Received: by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8de5e085ccea99cdd059d40b9ceef9fb; Thu, 11 Jul 2019 19:51:58 +0000 (UTC) To: Aaron Parecki , George Fletcher Cc: OAuth WG References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> Date: Thu, 11 Jul 2019 15:51:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------09F48B8222D4A76839B427F3" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 19:52:07 -0000 This is a multi-part message in MIME format. --------------09F48B8222D4A76839B427F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof. Now if the SPA performs some sort of Dynamic Client Registration or DPoP then I think it's a completely different scenario and it doesn't bother me as much for their to be refresh_tokens in the browser. This of course is just my perspective:) On 7/10/19 7:56 PM, Aaron Parecki wrote: > > 2. To use a refresh token at the /token endpoint, client > authentication is required. This is where it gets difficult for > default SPAs because they are public clients and the only > mechanism to authenticate them is the client_id which is itself > public. For me, this is the real risk of exposing the > refresh_token in the browser. > > > RFC6749 says "If the client type is confidential or??the client was > issued client credentials,??the client MUST authenticate..." which I > take to mean that refresh tokens could be used without a > client_secret, both for native an javascript apps. > > This discussion of offline vs online refresh tokens is interesting, > but I worry that we may be narrowing our focus here too much. > > There's a use where JavaScript apps may be able to take advantage of > offline access, which is around Service Workers. This allows a website > to install some code from a website which can continue to run in the > background, though sometimes only while triggered from external > events. One useful example of this is a syncing daemon, where a push > notification can be sent from a web server to a Service Worker, which > could cause that code in the browser to need to make a request to an > API, which then may need to be able to get a new access token, which > is effectively offline access. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Tue, Jul 9, 2019 at 9:16 AM George Fletcher > > > wrote: > > I'll just add a couple more thoughts around refresh_tokens. > > 1. I agree with David that refresh_tokens are valuable in an > "online" scenario and should be used there. > > 2. To use a refresh token at the /token endpoint, client > authentication is required. This is where it gets difficult for > default SPAs because they are public clients and the only > mechanism to authenticate them is the client_id which is itself > public. For me, this is the real risk of exposing the > refresh_token in the browser. > > 3. If the AS supports rotation of refresh_tokens and an attacker > steals one and uses it, then the SPA will get an error on it's > next attempt because it's refresh_token will now be invalid. If > the refresh_tokens are bound to the user's authentication session, > then the user can logout to lockout the attacker. However, that is > a lot of "ifs" and still provides the attacker with time to > leverage access via the compromised refresh_token. > > In principle, I agree with the recommendation that SPAs shouldn't > have refresh_tokens in the browser. If it's not possible to easily > refresh the access token via a hidden iframe (becoming more > difficult with all the browser/privacy cookie changes. e.g. > ITP2.X) then I'd recommend to use a simple server component such > that the backend for the SPA can use authorization_code flow and > protect a client_secret. > > Thanks, > George > > On 7/8/19 11:17 PM, David Waite wrote: >> >>> On Jul 8, 2019, at 7:10 PM, Leo Tohill >> > wrote: >>> Re 8. Refresh Tokens >>> >>> ???? "For public clients, the risk of a leaked refresh token is much >>> ?? ??greater than leaked access tokens, since an attacker can >>> potentially >>> ?? ??continue using the stolen refresh token to obtain new >>> access without >>> ?? ??being detectable by the authorization server.?? " >>> >>> (first, note the typo "stoken".) >>> >>> Is it always "higher risk"??? I could even argue that leakage of >>> a refresh token is lower risk. As a bearer document, a leaked >>> access token allows access to resources until it expires.?? A >>> leaked refresh token, to be useful,?? requires an exchange with >>> the AS, and the AS would have the opportunity to check whether >>> the refresh token is still valid (has not been revoked).?? (of >>> course revocation might NOT have happened, but then again, it >>> might have.) >> >> I agree (with caveats, of course). >> >> Access tokens and refresh tokens may or may not be attached (by >> policy) to an authentication session lifetime. It is far easier >> to picture refresh tokens which are not attached to an >> authentication session (sometimes called ???offline??? access) >> being inappropriate for a browser-based app, which is nearly >> always a client that the resource owner is interacting with. >> >> Variants that may want offline tokens are less easy to imagine - >> perhaps browser extensions? >> >> I believe the language currently there is due to AS >> implementations predominantly treating refresh tokens as being >> for offline access, and access token lifetime being short enough >> to not outlast an authentication session. >> >>> Furthermore, since the access token is transmitted to other >>> servers, the risk of exposure is greater, due to possible >>> vulnerabilities in those called systems (e.g., logs).?? Isn't >>> this the reason that we have refresh tokens? Don't refresh >>> tokens exist because access tokens should have short TTL, >>> because they are widely distributed? >> >> Yes. Once you acknowledge the existence of ???online??? refresh >> tokens, they become a strong security component: >> >> - Refresh tokens let you shorten the access token lifetime >> - A shorter access token lifetime lets you have centralized >> policy to invalidate access without needing to resort to token >> introspection/revocation >> - Token refresh can theoretically be used to represent other >> policy changes by both the client (creating tokens targeting a >> new resource server or with reduced scopes) and server (changing >> entitlements and attributes/claims embedded within a structured >> token) >> - Refresh tokens can be one-time-use, as recommenced by the >> security BCP. A exfiltrated refresh token will result in either >> the attacker or the user losing access on the next refresh, and a >> double refresh is a detectable security event by the AS. >> >>> "Additionally, browser-based applications provide many attack >>> vectors by which a refresh token can be leaked." >>> >>> The risks of leaking a refresh token from the browser are >>> identical to the risks of leaking an access token, right??? This >>> sentence could be changed to "... by which /a token/ can be leaked." >>> >>> A refresh token is "higher risk" because its TTL is usually >>> greater than the access token's TTL.?? But if our advice here >>> leads to people using longer-lived access tokens (because of the >>> problems with getting a new access token without involving the >>> user), then the advice will be counter productive.???? The >>> longer life gives more time for the usefulness of a browser-side >>> theft, and more time for the usefulness of a server-side theft.?? >>> >>> Which scenario is safer? >>> A) using an access token with a 10 minute TTL, accompanied by a >>> refresh token with a 1 hour TTL >>> B) using an access token with a 1 hour TTL, and no refresh token.?? >> >> >> Given tokens that track authentication lifetime, it is hard to >> make a case that refresh tokens which last for the authentication >> session are a greater security risk than opaque access tokens >> (requiring token introspection) that will last the same time.?? >> >> Typically an AS (or OP) would issue a structured access token >> with a lifetime expected to expire before the authentication >> session, with new tokens issued via requests made in an embedded, >> iframe (hidden, prompt=none). There may be benefits here of user >> cookies (or perhaps managed-device information) against an >> authorization endpoint being used to make decisions that could >> not be made by a refresh against the token endpoint.?? >> >> I???d be interested in hearing how strong of an implementation >> issue this might be for deployments - I could see a non-security >> argument that the BCP should only have one recommended approach >> here, and that there are deployments needing the iframe approach. >> >> -DW >> >> >> _______________________________________________ >> 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 --------------09F48B8222D4A76839B427F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP then I think it's a completely different scenario and it doesn't bother me as much for their to be refresh_tokens in the browser. This of course is just my perspective:)

On 7/10/19 7:56 PM, Aaron Parecki wrote:
2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.??

RFC6749 says "If the client type is confidential or??the client was issued client credentials,??the client MUST authenticate..." which I take to mean that refresh tokens could be used without a client_secret, both for native an javascript apps.

This discussion of offline vs online refresh tokens is interesting, but I worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be able to take advantage of offline access, which is around Service Workers. This allows a website to install some code from a website which can continue to run in the background, though sometimes only while triggered from external events. One useful example of this is a syncing daemon, where a push notification can be sent from a web server to a Service Worker, which could cause that code in the browser to need to make a request to an API, which then may need to be able to get a new access token, which is effectively offline access.

----
Aaron Parecki



On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com> wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perhaps browser extensions?

I believe the language currently there is due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

"Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a token can be leaked."

A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL.?? But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??

Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=none). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??

I???d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW


_______________________________________________
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

--------------09F48B8222D4A76839B427F3-- From nobody Thu Jul 11 15:00:37 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D7120156; Thu, 11 Jul 2019 15:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156288242409.12177.17933031479241192325.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2019 15:00:24 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens) to Proposed Standard 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, 11 Jul 2019 22:00:24 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jul 12 07:51: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 B8F8E1201D0 for ; Fri, 12 Jul 2019 07:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6hkIdUf7a-GO for ; Fri, 12 Jul 2019 07:51:22 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10DA12012D for ; Fri, 12 Jul 2019 07:51:21 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id t76so7492015oih.4 for ; Fri, 12 Jul 2019 07:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZ+334CUd4cemVqBRtU8WjxO+CqaaZgYK1WzEAVvRz0=; b=gqCNAVFJkHVYzZ7WTG1LugRQyroYZhRICj53ZUwNJqpocMci/luLTnZaviLCZCHhet CKJCClmKi9vgJkKS/imbDCsyduU0J44VFirys+PfuyiucPiWDzRSVXrI73ytoAF6Qpdt SWFc+VQ7lk6Ds44pZ2B/7ZleazRzRPzhNEWsDg8FgIVQqurupK7tGq1hcLgDKRENP4il 8oUh3lrDNXmomx+kwx12uOEq+OaPKiBQGygPaziNcRYC8htXSmHzOGLMNhvOglFOVErJ 7vDFpI1V2f80sM3C/yNHU4n+6Qfw8Rivoh8byyA9mwPiZKlOKuXmmE5k5flfcnXzlfLr Zslw== 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=fZ+334CUd4cemVqBRtU8WjxO+CqaaZgYK1WzEAVvRz0=; b=Zaec137wF2LqGtr1qedry/YXlXsme/J9jKaD2hjDWxADM7PNsH412FlSZofSxc6Dqs 0MVBm5y+7UPm6h1CkR30TIwDMPF9385VQnt19rDKdZ4wHjj7I1x3VbfCm2Tn//OhA6oB 8J3n+HQxEt1O5wY78GiUPwaANYM0jCz68SQCIlixvqL0M1puQfoa9AjcAQLmhBSJ4Ibq sRwYFmCiSNW/m3pItEznLiN/oLgA+fVrIX9Qc7E/fKVl+6MoyhqpbvSmBW/ovBhhOUKQ qxpIAo0XZkxAhfGY/73OHbwlWMHWIDHnUrDtXqHdi8rnfcKOAt4PdY1C2iSwUboiOcmm gZpQ== X-Gm-Message-State: APjAAAWCNVZZHxOVMqNRr553IC//tIeCIoHhQ+KQCdXGQz0apK0SOKWR igg4GMTh+j5IuRYKxIF6MVFpsN+4Qk5KXKJCyw== X-Google-Smtp-Source: APXvYqx+AzVIxz/8NluTBd/1r64dumpuNy6yQtMnbypEq/GGdfoys1Ge3OSHnYmA+A5siVE/EcNOx1504/scf7WDG54= X-Received: by 2002:aca:f1c4:: with SMTP id p187mr5963744oih.149.1562943081227; Fri, 12 Jul 2019 07:51:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Fri, 12 Jul 2019 16:51:10 +0200 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="000000000000292a0c058d7d0bb8" Archived-At: Subject: Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 14:51:24 -0000 --000000000000292a0c058d7d0bb8 Content-Type: text/plain; charset="UTF-8" Hello Daniel, everyone, I don't know if this belongs to the DPoP document itself or each respective BCP (especially Browser-Based Apps), but one of the documents should give recommendation to implementers on how to 1. generate the unique private keys per installation / browser session 2. platform specific storage for them (e.g. in between browser navigation / app launches) I come asking for this guidance especially for the Browser-Based App use case. I think the clear recommendation is to use the Web Cryptography API (with extractable: false) for (1) and IndexedDB API for (2), but the more important question is how to deal with lack of those APIs in browsers that are known to not support them or be buggy (see data in https://caniuse.com), so - is it ok to use other means of generating the key when webcrypto is not available? - is it ok to generate keys through webcrypto (or other means) that are extractable and store them via other means than IndexedDB when indexed DB is not available, such as cookie or localstorage. Best, *Filip* On Mon, 8 Jul 2019 at 15:30, Daniel Fett wrote: > All, > > In preparation for the meeting in Montreal, I just uploaded a new version > of the DPoP draft: > https://tools.ietf.org/html/draft-fett-oauth-dpop-02 > > Please have a look and let me know what you think. We should make this a > working group item soon. > > As you might have noticed, there is also a new version of the Security > Best Current Practice draft: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > -Daniel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000292a0c058d7d0bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Daniel, everyone,

I do= n't know if this belongs to the DPoP document itself or each respective= BCP (especially Browser-Based Apps), but one of the documents should give = recommendation to implementers on how to
  1. generate the uni= que private keys per installation / browser session
  2. platform specif= ic storage for them (e.g. in between browser navigation / app launches)
I come asking for this guidance especially for the Browser-Based= App use case. I think the clear recommendation is to use the Web Cryp= tography API=C2=A0(with extractable: false) for (1) and IndexedDB API for (2), but the more important question is how to deal with lack of tho= se APIs in browsers that are known to not support them or be buggy (see dat= a in=C2=A0https://caniuse.com), so
  • is it ok to use other means of generating the key when webcr= ypto is not available?
  • is it ok to generate keys through webcrypto = (or other means) that are extractable and store them via other means than I= ndexedDB when indexed DB is not available, such as cookie or localstorage.<= /li>
Best,
Filip

On Mon, 8= Jul 2019 at 15:30, Daniel Fett <danielf+oauth@yes.com> wrote:
All,

In preparation for the meeting in Montreal, I just uploaded a new version= of the DPoP draft:

Please have a look and let me = know what you think. We should make this a working group item soon.

As you might have noticed, there is also a new version of= the Security Best Current Practice draft:
=

-Daniel
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000292a0c058d7d0bb8-- From nobody Fri Jul 12 18:14: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 E458312006A; Fri, 12 Jul 2019 18:13:54 -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_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 cJz7Lar1wWrg; Fri, 12 Jul 2019 18:13:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF666120041; Fri, 12 Jul 2019 18:13:52 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D1DlP4007164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 21:13:49 -0400 Date: Fri, 12 Jul 2019 20:13:46 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Message-ID: <20190713011346.GN16418@mit.edu> References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> <20190706184226.GA13047@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 01:13:55 -0000 On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote: > On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > > > > Not to my recollection. I'm honestly not even sure what an array would > > mean > > > for "may_act". Do you mean for "act"? > > > > Currently we can say that admin@example.com "may act" as user@example.com. > > But IIUC we don't have a way to say that either admin1@example.com or > > admin2@example.com may do so. An array would let us indicate multiple > > authorized parties. I'm reluctant to actually make such a change at this > > point, though, since this is already deployed some places, right? > > > > Okay, sorry, I'm a bit slow but I follow you now. > > Indeed this has been deployed in a number of places already. I'd honestly > don't know if anyone is making use of this particular claim but changing > from an object to array of objects would be a breaking change. And a > breaking change is something I'd really like to avoid unless there's a very > compelling reason to do so. And while your point here is taken, I don't > think it rises to that level of compelling. > > I see two options at this point: > 1) leave it as is > 2) adjust the language around "may_act" such that it could also identify > an eligible group - this would allow for it to indicate multiple authorized > parties but just not by one by one name, which is maybe more desirable > anyway > > What do you think? Either option is fine with me. I don't remember how much precedent we have in the OAuth ecosystem for groups that are identified in this manner, but if it's a fairly common thing that seems to be slighly preferred. (Even if we go with (1) and this does become an issue at some point, it shouldn't be too hard to add a "may_also_act" or similar with the array semantics.) -Ben From nobody Mon Jul 15 05:21: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 C3BC81200F4 for ; Mon, 15 Jul 2019 05:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykC80TksY0Fy for ; Mon, 15 Jul 2019 05:21:47 -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 EA105120112 for ; Mon, 15 Jul 2019 05:21:44 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id d17so15274289qtj.8 for ; Mon, 15 Jul 2019 05:21:44 -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=vIpSNEZ4TByEoZfu4T016YSmYsSOjavfunBEzmkkGVc=; b=TtkPc7G4+4wM2d/OERX0ue8QqPoM4g0bgiBV/DNKXpnsbnRTTWmJYpUa/B1JJxCWjQ jfp8bH+zoUETjzkoXbnCbmlWE1pTTe+BrZfqgN5KVbal5Vwa+Hsc9UqqhsvkAD62LltZ Md/AwXnaHfOJXVEVkJBY1GHdyuheHd09RfEbo= 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=vIpSNEZ4TByEoZfu4T016YSmYsSOjavfunBEzmkkGVc=; b=pdqSewSG/S5abzw6yP+ctYQttq8FQV6n0GERczymQ9rCKazn+HWWWxphHL7bKWxGhs cWkr6KulVQIeqkKLCOQDwoeriXKDSjP+cEhS/rCg2XZKvvdjTLrghkAKsh2tRZJWXTO3 i7qxcKds4rnVN3GLc5Tj5PgFHyL1XnpAfMJMDJk+zhVf868aJVOefH8gKzosLQpncUO3 oD6aLmJxrgvErwoLgKioBZSP1kMBx+1Z2d3v3YZRn+PZoLXZAir9vpSiLQfzNLKsHZm1 K8haudB8hPVSgl0IfGtCxfmj75gZ4Qv96CwcnNJ2TV1iF1FI/KKw2oCHA4AhAWSUvaaL 4uzg== X-Gm-Message-State: APjAAAVeYw//PoIm0Gs9bLs79N/si6/IMCqZKPOWvFgVPDXjiiNI5P6L RvAUZbS3v70jgyAxJ2heC2//RxG7Zx1FbrRaqVpeslV/2zp89oat604m2PuLpFi5cx+laUrel8X lZv1ev6XGtqv1Rg== X-Google-Smtp-Source: APXvYqxwnPirBeya0VKugQ43eWKWD/5uge4AmP7eHxlOTprVEcLC2qx/qbgEt4YwruKJI/VLkfCSESwexa4JTDKv7Kw= X-Received: by 2002:ac8:c0e:: with SMTP id k14mr17474564qti.72.1563193303956; Mon, 15 Jul 2019 05:21:43 -0700 (PDT) MIME-Version: 1.0 References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> <20190706184226.GA13047@kduck.mit.edu> <20190713011346.GN16418@mit.edu> In-Reply-To: <20190713011346.GN16418@mit.edu> From: Brian Campbell Date: Mon, 15 Jul 2019 06:21:17 -0600 Message-ID: To: Benjamin Kaduk Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009916de058db74de8" Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:21:49 -0000 --0000000000009916de058db74de8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe there's a fair amount of precedent for something like it but typically it's indicating group membership or roll(s) of a user that's uniquely identified by other claims in a JWT. And, as far as I know, there's nothing standardized for it so it's done more ad hoc. Thus there's not really precedent from a standards perspective and, as I think about it more, it's probably not a terribly good idea to try and define new semantics like that at the 11th hour. So I'm gonna go with the '1) leave it as is' option. And you're right that there are things that could be done without too much issue, should it ever prove to be an issue (which I kinda don't think will happen anyway). On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk wrote: > On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote: > > On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > > > > > > > Not to my recollection. I'm honestly not even sure what an array > would > > > mean > > > > for "may_act". Do you mean for "act"? > > > > > > Currently we can say that admin@example.com "may act" as > user@example.com. > > > But IIUC we don't have a way to say that either admin1@example.com or > > > admin2@example.com may do so. An array would let us indicate multipl= e > > > authorized parties. I'm reluctant to actually make such a change at > this > > > point, though, since this is already deployed some places, right? > > > > > > > Okay, sorry, I'm a bit slow but I follow you now. > > > > Indeed this has been deployed in a number of places already. I'd honest= ly > > don't know if anyone is making use of this particular claim but changin= g > > from an object to array of objects would be a breaking change. And a > > breaking change is something I'd really like to avoid unless there's a > very > > compelling reason to do so. And while your point here is taken, I don'= t > > think it rises to that level of compelling. > > > > I see two options at this point: > > 1) leave it as is > > 2) adjust the language around "may_act" such that it could also identi= fy > > an eligible group - this would allow for it to indicate multiple > authorized > > parties but just not by one by one name, which is maybe more desirable > > anyway > > > > What do you think? > > Either option is fine with me. I don't remember how much precedent we ha= ve > in the OAuth ecosystem for groups that are identified in this manner, b= ut > if it's a fairly common thing that seems to be slighly preferred. > (Even if we go with (1) and this does become an issue at some point, it > shouldn't be too hard to add a "may_also_act" or similar with the array > semantics.) > > -Ben > --=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._ --0000000000009916de058db74de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe there's a fair amount of pr= ecedent for something like it but typically it's indicating group membe= rship or roll(s) of a user that's uniquely identified by other claims i= n a JWT. And, as far as I know, there's nothing standardized for it so = it's done more ad hoc. Thus there's not really precedent from a sta= ndards perspective and, as I think about it more, it's probably not a t= erribly good idea to try and define new semantics like that at the 11th hou= r. So I'm gonna go with the '1) leave it as is' option. And you= 're right that there are things that could be done without too much iss= ue, should it ever prove to be an issue (which I kinda don't think will= happen anyway).


=

= On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campb= ell wrote:
> On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> >
> > > Not to my recollection. I'm honestly not even sure what = an array would
> > mean
> > > for "may_act". Do you mean for "act"? > >
> > Currently we can say that admin@example.com "may act" as user@example.com.
> > But IIUC we don't have a way to say that either admin1@example.com or
> > admin2@ex= ample.com may do so.=C2=A0 An array would let us indicate multiple
> > authorized parties.=C2=A0 I'm reluctant to actually make such= a change at this
> > point, though, since this is already deployed some places, right?=
> >
>
> Okay, sorry, I'm a bit slow but I follow you now.
>
> Indeed this has been deployed in a number of places already. I'd h= onestly
> don't know if anyone is making use of this particular claim but ch= anging
> from an object to array of objects would be a breaking change. And a > breaking change is something I'd really like to avoid unless there= 's a very
> compelling reason to do so.=C2=A0 And while your point here is taken, = I don't
> think it rises to that level of compelling.
>
> I see two options at this point:
> 1) leave it as is
> 2) adjust the language around=C2=A0 "may_act" such that it c= ould also identify
> an eligible group - this would allow for it to indicate multiple autho= rized
> parties but just not by one by one name, which is maybe more desirable=
> anyway
>
> What do you think?

Either option is fine with me.=C2=A0 I don't remember how much preceden= t we have
in the OAuth ecosystem for groups that are=C2=A0 identified in=C2=A0 this m= anner, but
if it's a fairly common thing that seems to be slighly preferred.
(Even if we go with (1) and this does become an issue at some point, it
shouldn't be too hard to add a "may_also_act" or similar with= the array
semantics.)

-Ben

<= 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. --0000000000009916de058db74de8-- From nobody Tue Jul 16 05:54: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 71C7E1201C7 for ; Tue, 16 Jul 2019 05:54:06 -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 zYHOBjvJThFI for ; Tue, 16 Jul 2019 05:54:04 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B185912004F for ; Tue, 16 Jul 2019 05:54:04 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id m24so39741688ioo.2 for ; Tue, 16 Jul 2019 05:54:04 -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=Ezb98Pyx0urTh1TQKvm+Qd7HQKoqmFPSwA5zK3M5RrA=; b=cbuBkm0du7IH8QlMn86cmq7fVyoy//ZEfhQ6I0JTC44/igFAjQl1N+IMhMUGqBdQ+p MqOtjU4wVM7B+4VSJLNG8+XullsyHRnC3hKkbMOvxy5xeieiUl/vJ12XaVhFFNHhJB1x d6JoN7hbeIlvtwXlaAlpM5EOSBcj8tYsQ3uyUqrBfGlvH/CDj6JjR1H0rlg6pafBglNQ 1CJe9S5jZA4lJOP7oeKwu5yRJuSXr+6lzE1xTl8U9Q/+5G7k5MJKFLq9VZ+jxmLlHICs B+dRvLOfX5R32VcmwF8CAjvmaqgvDB6V6Cx89o5sc/hOnILuQQKHo7x0XFOIQtYY0wOM CLJQ== 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=Ezb98Pyx0urTh1TQKvm+Qd7HQKoqmFPSwA5zK3M5RrA=; b=r9v1nIgdo1hAYKYt2PJNoAHRsca6fNinrm/Tatl+sM4CXDvOioYRELSLsbRyNeTv0v Fvu2X4CIMawaXnUrcGJPi9SreAgkVG3SJ/meDwh1hZoC9hxJvp2kpT7WpVS8hVTS8sVL eZ36C820+OXBTJl/cMb3yauRpOXARcdDDIbBFOijMKUmI2Yy959w2PB4rJ37WwIYcRoF 7QgavmC0bAOB1nGmvtmrW3sZ1HDHHJTQK6G+inZFMgjZR3GQwplOfF8kR8JcsJyshFtS HdFSs59yvhlA3N4cdd7jiw8PRo+WoHVDZasSfnbwu1gToNfh2lTzc2UXSQR3wCEWcDqz PeqQ== X-Gm-Message-State: APjAAAUKUjBzejBV8okAXu4U77CXg5JNqXrLm0cZwekSM7q1vHFazzaF E0E3Zb3mmf9lj4iPAnCkO4gCvECF/8WJb637mf+zgzKop2M= X-Google-Smtp-Source: APXvYqwxnwnlcav0WSigkCA6vCualqN0iPobgWYpJkUEqUWWHdmAVvBa7ruhCXA/xkOHW/wyYeYWhGwNYvPnqRDC7hM= X-Received: by 2002:a5d:9642:: with SMTP id d2mr8924417ios.278.1563281643459; Tue, 16 Jul 2019 05:54:03 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 16 Jul 2019 08:53:53 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000000adaf3058dcbdfb2" Archived-At: Subject: [OAUTH-WG] OAuth WG Presentations X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Jul 2019 12:54:06 -0000 --0000000000000adaf3058dcbdfb2 Content-Type: text/plain; charset="UTF-8" Presenters, The datatracker tool now allows you to upload your slides to meeting materials page. After you login to datatracker, go to the following link, and you should see a Propose Slides button in the slides section to allow you to upload your slides. https://datatracker.ietf.org/meeting/105/session/oauth Please, upload your slides as soon as possible to give people a chance to review the slide before the meeting. Regards, Rifaat --0000000000000adaf3058dcbdfb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Presenters,

The datatracker tool now al= lows you to upload your slides to meeting materials page.
After y= ou login to datatracker, go to the following link, and you should see a Pro= pose Slides button in the slides section to allow you to upload your slides= .
Please, upload your slides as soon as possible to give people = a chance to review the slide before the meeting.

R= egards,
=C2=A0Rifaat


=
=C2=A0
--0000000000000adaf3058dcbdfb2-- From nobody Tue Jul 16 16:23: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 D852D12002F for ; Tue, 16 Jul 2019 16:23: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, 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=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 iw9f9Ow_du7F for ; Tue, 16 Jul 2019 16:23:33 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D2A12002E for ; Tue, 16 Jul 2019 16:23:33 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6GNNWlC027017 for ; Tue, 16 Jul 2019 19:23:32 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6GNNWlC027017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563319412; bh=obx+rmOgpYoHlF7SIZsw04ovfE+a5lmu33ZZVHzo/2U=; h=From:To:Subject:Date:From; b=WKYEEVkIKdU0SHulBQQ4rYhpxLSgQ7fOOcKfO/K6NXzOsau23iZeemVYODri0nM3i ZZUBFJNoXPFrU8nOiMxiD6pxadI63kxifPT5rZE9HI7OcvKenfPlANufKgmahkUizi iptDmYtUs3Q5zaeHdSQpfyhKHeW7V4H9CNGLRGlA= 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 x6GNNUbo025410 for ; Tue, 16 Jul 2019 19:23:30 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 19:23:30 -0400 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfg== Date: Tue, 16 Jul 2019 23:23:29 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> 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 Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 23:23:35 -0000 Hi! The following is my AD review of draft-ietf-oauth-resource-indicators-02. = The document is in good shape. (1) Section 2. Per "The parameter can carry the location of a protected res= ource, typically as an https URL, or a more abstract identifier", is this "= abstract identifier" still an absolute URI per Section 4.3 of RFC3986? (2) Section 2.2. in the sentence "To the extent possible, when issuing acc= ess tokens, the authorization server should adapt the scope value associate= d with an access token to the value the respective resource is able to proc= ess and needs to know": -- is this language suggesting that the authorization server is modifying = the scope value based on the resource it sees? I'm trying to understand wh= at "adapt" means, especially in relation to the improved security and priva= cy the subsequent sentence suggests. -- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ? (3) Editorial ** Section 1 and 2.1. Multiple Typo. s/the the/the/g ** Section 2. Editorial. s/resource at which/resource to which/ ** Section 2. Editorial. =20 s/ And can also be used to inform the client that it has requested an inval= id combination of resource and scope./ It can also be used to inform the client that it has requested an invalid c= ombination of resource and scope./ ** Section 2.1. Multiple Typo. s/an an/an/g ** Section 2.2. Editorial. s/token request and response/token request (Fig= ure 3) and response (Figure 4)/ ** Section 3. Typo. s/a invalid/an invalid/ ** Section 3. Missing words. "A bearer token that has multiple intended r= ecipients (audiences) can be used by any one of those recipients at any oth= er." Is it protected resource? From nobody Wed Jul 17 09:17:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E624B120771 for ; Wed, 17 Jul 2019 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 aNEe8u8EPXWv for ; Wed, 17 Jul 2019 09:17:04 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160C71204ED for ; Wed, 17 Jul 2019 09:17:04 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HGH3kc007193 for ; Wed, 17 Jul 2019 12:17:03 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6HGH3kc007193 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563380223; bh=So6IxB3sgYF5qMuWYBctZLZT4KBad5zvsvRQ9g6Eago=; h=From:To:Subject:Date:From; b=gZmEtc6E/vCOFZ7hAEjt+Yopchpj5SreKDsKbV3BuyGfns4oLeSt0i3KYrM4X0ChD gXrGZNWLG4Esi3pIXcvg1Qu33I8uq1fxA54ftDfki5/4053EkUbXl6etyYnyKn9wvx syQEh0moIurgnofko2frkvd/+wu5ignJJdbrZisU= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HGH1IH010990 for ; Wed, 17 Jul 2019 12:17:01 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 12:17:01 -0400 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: AD Review: draft-ietf-oauth-jwt-introspection-response-03 Thread-Index: AdU8um9EYRsZS/zUTimSMgl/pofXXQ== Date: Wed, 17 Jul 2019 16:17:00 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> 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 Review: draft-ietf-oauth-jwt-introspection-response-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2019 16:17:06 -0000 Hi! The following is my AD review of draft-ietf-oauth-jwt-introspection-respons= e-03.=20 (1) Section 4. Per introspection_encrypted_response_alg, how is either sig= ning or encryption being requested? Is it by also including an introspecti= on_signed_response_alg? If that's the case, it is worth explicitly saying. (2) Section 4. Per introspection_encrypted_response_enc, I'm having troubl= e deconflicting these two sentences: [1] If "introspection_encrypted_response_alg" is specified, the default for= this value is A128CBC-HS256. =20 [2] When "introspection_encrypted_response_enc" is included, "introspection= _encrypted_response_alg" MUST also be provided Sentence [2] explicitly states that "introspection_encrypted_response_alg" = is required. However, the first sentence seems more tentative by saying th= at "if introspection_encrypted_response_enc" is present. (3) I want to talk through the personally identifiable information being sp= ecified as new introspection fields per Section 8.3 (e.g., name, birthday) = being exposed. I was looking to ensure that it would always be encrypted i= n transit (and that only authorized clients could get it). I read that in = Section 3, "[d]epending on the specific resource server policy the JWT is e= ither signed, or signed and encrypted" and that per Section 4 that "[t]he a= uthorization server determines what algorithm to employ to secure the JWT f= or a particular introspection response." Section 6.2 explicitly notes the = threat of token data leakage (a more general case of my concern so thanks f= or that text). [RFC7662], Section 4 notes only that "the server MUST suppor= t Transport Layer Security (TLS) 1.2", but "support" is different than "the= server MUST _use_ TLS". Therefore, it seems like there could be a case whe= re the server could return an introspection response in the clear (e.g., no= TLS, introspection_signed_response_alg). Am I missing something? =20 My bias is to say something on the order of "TLS MUST be used". (4) I also want to talk through an unscrupulous protected resource trying t= o harvest introspection meta-data. I was looking for guidance related to t= he authorization of the introspection transactions. I found: Section 2.2 of [RFC7662] says important things like "For instance, an autho= rization server MAY limit which scopes from a given token are returned for = each protected resource to prevent a protected resource from learning more = about the larger network than is necessary for its operation." Section 4 of [RFC7662] says "If left unprotected and un-throttled, the intr= ospection endpoint could present a means for an attacker to poll a series o= f possible token values, fishing for a valid token. To prevent this, the = authorization server MUST require authentication of protected resources t= hat need to access the introspection endpoint and SHOULD require protected = resources to be specifically authorized to call the introspection endpoint= ." Section 6.2 of this draft provides guidance on defending against unauthenti= cated clients. How does the authorization server restrict a protected resource that _can_ = authenticate to it from getting meta-data is shouldn't have access to? Som= ething on the order of "the authorization server = to determine what a given protected resource is allowed to see". (5) Editorial Nits ** Section 3. Per "This JWT MAY furthermore contain all other claims descr= ibed in Section 2.2. of [RFC7662] and beyond (e.g. as defined in [OpenID.Co= re])", would it be more timeless to say the fields specified in "OAuth Toke= n Introspection Response" registry? ** Section 4. The first sentence of each parameters descriptions don't par= se -- for example with introspection_signed_response_alg: "JWS [RFC7515] 'a= lg' algorithm JWA [RFC7518] REQUIRED", fully expanded that's "JSON Web Sign= ature (JWS) [RFC7515] "alg" algorithm JSON Web Algorithms (JWA) [RFC7518] R= EQUIRED ...". The same is true for the write-ups in Section 5. ** Section 4. Editorial. Per "introspection_encrypted_response_enc": s/REQUIRED for encrypting introspection responses/ REQUIRED for authenticated encryption of introspection responses/ Regards, Roman From nobody Wed Jul 17 11:28:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C719B12085E for ; Wed, 17 Jul 2019 11:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wcsy6xzEA-O for ; Wed, 17 Jul 2019 11:28:33 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31297120873 for ; Wed, 17 Jul 2019 11:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1563388113; x=1594924113; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kH4qcT65VRWrXF/JewzylTDPT+hakwiWTZay+oevMcY=; b=HP9clvjPWSarC5mchWqdJSk/nnXvWDTUGsIAGYRvKELdSYHmbmToUL/u Qx0+kvLeh16bk0xDqhYRYlYxmF4MEZUVPz+Ek1xP8EJwR/1yVyLkFQgUR f5zCUDA811KMvgrDW4R+/bDdYjw77m8aZmms6/e7cGtoqpAthk4QM7jLi o=; X-IronPort-AV: E=Sophos;i="5.64,275,1559520000"; d="scan'208,217";a="742233423" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 17 Jul 2019 18:28:31 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id BD4FDA22C5; Wed, 17 Jul 2019 18:28:30 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Jul 2019 18:28:29 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Jul 2019 18:28:29 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 17 Jul 2019 18:28:29 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] IETF105 OAuth WG Draft Agenda Thread-Index: AQHVN22SVXnWZcWV4kqcH8kYIV1t1abEbEQAgApKZIA= Date: Wed, 17 Jul 2019 18:28:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.219] Content-Type: multipart/alternative; boundary="_000_CB80ACC58A5542DFB08126EB345183A1amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 18:28:36 -0000 --_000_CB80ACC58A5542DFB08126EB345183A1amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gY29taW5nIGluIGxhdGUgdG8gdGhpcyBwYXJ0eSwgYnV0IEnigJl2ZSBiZWVuIGFza2Vk IGJ5IGEgZmV3IHBlb3BsZSBhYm91dCBob3cgQVdTIGhhbmRsZXMgcmVxdWVzdCBzaWduaW5nIGFu ZCBvdXIgZXhwZXJpZW5jZXMgd2l0aCBpdC4gR2l2ZW4gdGhlIHJlbmV3ZWQgaW50ZXJlc3QgaW4g SFRUUCByZXF1ZXN0IHNpZ25pbmcgYW5kIHRoZSBvbmdvaW5nIHdvcmsgb24gRFBvUCwgaXMgdGhp cyBzb21ldGhpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFy aW5nIGFib3V0IGR1cmluZyBvbmUgb2YgdGhlIHNlc3Npb25zPyBJIGNvdWxkIHB1dCB0b2dldGhl ciBhIHF1aWNrIDUtMTAgbWludXRlIG92ZXJ2aWV3IG9mIEFXUyBTaWdWNCBzaWduaW5nIGFuZCBz b21lIG9mIHRoZSBsZXNzb25zIHRoYXQgd2VudCBpbnRvIGl0cyBkZXNpZ24uDQoNClRob3VnaHRz Pw0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQVdTIElkZW50aXR5DQoNCg0KRnJv bTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0 IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgSnVseSAxMCwgMjAxOSBh dCAzOjIwIFBNDQpUbzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+ DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSUVU RjEwNSBPQXV0aCBXRyBEcmFmdCBBZ2VuZGENCg0KKzENCg0KSSBsaWtlIGl0ISA6KQ0KDQpPbiBX ZWQsIEp1bCAxMCwgMjAxOSBhdCAzOjE3IFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0Lmll dGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkFsbCwN Cg0KSGVyZSBpcyBvdXIgZHJhZnQgYWdlbmRhIGZvciB0aGUgdHdvIHNlc3Npb25zIHdlIGhhdmUg cGxhbm5lZCBmb3IgTW9udHJlYWw6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRp bmcvMTA1L21hdGVyaWFscy9hZ2VuZGEtMTA1LW9hdXRoLTAwDQoNClBsZWFzZSwgdGFrZSBhIGxv b2sgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy4NCg0KUmVnYXJkcywN CiBSaWZhYXQgJiBIYW5uZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K --_000_CB80ACC58A5542DFB08126EB345183A1amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2FD69A224E5F6945A54E87EBE7A0AAAC@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBjb21pbmcg aW4gbGF0ZSB0byB0aGlzIHBhcnR5LCBidXQgSeKAmXZlIGJlZW4gYXNrZWQgYnkgYSBmZXcgcGVv cGxlIGFib3V0IGhvdyBBV1MgaGFuZGxlcyByZXF1ZXN0IHNpZ25pbmcgYW5kIG91ciBleHBlcmll bmNlcyB3aXRoIGl0LiBHaXZlbiB0aGUgcmVuZXdlZCBpbnRlcmVzdCBpbiBIVFRQIHJlcXVlc3Qg c2lnbmluZyBhbmQgdGhlIG9uZ29pbmcgd29yayBvbiBEUG9QLCBpcyB0aGlzIHNvbWV0aGluZw0K IHRoZSB3b3JraW5nIGdyb3VwIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyBhYm91dCBk dXJpbmcgb25lIG9mIHRoZSBzZXNzaW9ucz8gSSBjb3VsZCBwdXQgdG9nZXRoZXIgYSBxdWljayA1 LTEwIG1pbnV0ZSBvdmVydmlldyBvZiBBV1MgU2lnVjQgc2lnbmluZyBhbmQgc29tZSBvZiB0aGUg bGVzc29ucyB0aGF0IHdlbnQgaW50byBpdHMgZGVzaWduLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFX UyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5P QXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFy ZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIEp1bHkgMTAsIDIwMTkgYXQgMzoyMCBQTTxicj4NCjxiPlRvOiA8L2I+UmlmYWF0IFNoZWto LVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5vYXV0 aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgt V0ddIElFVEYxMDUgT0F1dGggV0cgRHJhZnQgQWdlbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbGlrZSBpdCEgOik8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBKdWwgMTAsIDIwMTkgYXQgMzoxNyBQTSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IZXJlIGlzIG91ciBkcmFmdCBhZ2VuZGEgZm9yIHRoZSB0d28gc2Vzc2lv bnMgd2UgaGF2ZSBwbGFubmVkIGZvciBNb250cmVhbDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy8xMDUvbWF0ZXJpYWxzL2FnZW5kYS0xMDUtb2F1dGgtMDAiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA1L21hdGVy aWFscy9hZ2VuZGEtMTA1LW9hdXRoLTAwPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UsIHRha2UgYSBsb29rIGFuZCBs ZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtSaWZhYXQgJmFtcDsg SGFubmVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Ck9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CB80ACC58A5542DFB08126EB345183A1amazoncom_-- From nobody Wed Jul 17 11:46: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 2A20C120026 for ; Wed, 17 Jul 2019 11:46:53 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymKxq7hwkuy0 for ; Wed, 17 Jul 2019 11:46:50 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640104.outbound.protection.outlook.com [40.107.64.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF701201CF for ; Wed, 17 Jul 2019 11:46:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gE0P99ur0schEugiAsC+6lm88OrQoMMTCD3TLwLT/DXagjYZc74/QPzTUKP5hSOTe2LJHzRbZmLAANGiNhaSqY0havyHNa4CupqV5L/4YIqxEt/eQcrdWokYJb9Wy2XRy2cpKk9wVUkE/kxZFXXrXJu4FY9BuWBwppFIDW8VQSeQIOx6biGhx5keJctiW4T87NNSIVLfSjpf48fKn3X0ETkzXMT/mTqUaICTkmzx2wwwk1Ci80KyjjqVEpZaE1h7HPgKQZ/DZ/COrCUOJbSOIQ0y6fsO6i/BDvr4onaO0gWnzLP/EU7lra4emPwP2z4Q/JqMChqsdXKHhvuhtvCJ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rIVWxo7MbT5ycke7cDDyabgvMcVxBSFBHDFWTOGcZlk=; b=kZRYO4bvZMGtE06WztoXnXGoAwKBqqlHk67HbcopN7sB/hRRh2liUiaRUm61bxZ7hkkKHesVqUb3y+THSZxEIyRGOXqYMUIfH9JyQypNzRq10oGaVRVyJo4V4vplzIE0l5k5e9neprdtbAtgnm/KnmS3p0w1ORIEZFPLsgIMHso4vPjcYnz41yvjItvxDYNc5iA8PaRc4VjDJra/sdjbi2k3mnbnM42/q3f1dDOsnwOcSrSP4xg8WzYUWZu7T+uyudcqPSkMDlnR/eZXnRlFnPZ5XvYaZLjBqmcdoVzFx4HSifzwItPaEAGGZZW/OOdU9ivAE+AtWsk0BEGYsYP4zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rIVWxo7MbT5ycke7cDDyabgvMcVxBSFBHDFWTOGcZlk=; b=Y5lZ2uZ/mtRfAkGK6x3XZPipGapZn0gSfCmkvNe18fHFwfmudhIjs739FJAMw5ZEnxRYAR1Vp+0rrqOkLsEeWr+5QI8iMKFS3QXsmRvE/GhbrJToKaEmOjBdhTjazULR2IDrOoIGAmHxh1RyS1j7cEgNPY9zgaQqLodAhEeaxJ8= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0403.namprd00.prod.outlook.com (52.132.20.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2134.0; Wed, 17 Jul 2019 18:46:30 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::dc57:292b:1bf4:482a]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::dc57:292b:1bf4:482a%4]) with mapi id 15.20.2134.000; Wed, 17 Jul 2019 18:46:30 +0000 From: Mike Jones To: "Richard Backman, Annabelle" , Dick Hardt , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] IETF105 OAuth WG Draft Agenda Thread-Index: AQHVN21Vbkyf/okxA0arvKarf1KOfabEbEQAgAq/vYCAAATxMA== Date: Wed, 17 Jul 2019 18:46:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0c235db7-2053-472d-b510-0000caa22d1c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-17T18:46:10Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66ce257d-5c08-4d57-e365-08d70ae7154b 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:BL0PR00MB0403; x-ms-traffictypediagnostic: BL0PR00MB0403: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1417; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(199004)(189003)(99286004)(10090500001)(316002)(110136005)(22452003)(5660300002)(478600001)(256004)(966005)(86362001)(6246003)(4326008)(446003)(53936002)(52536014)(9686003)(236005)(54896002)(6306002)(55016002)(6436002)(476003)(10290500003)(7696005)(74316002)(11346002)(102836004)(229853002)(8990500004)(14444005)(3846002)(6116002)(2906002)(790700001)(81166006)(26005)(486006)(25786009)(606006)(68736007)(7736002)(14454004)(186003)(33656002)(66556008)(53546011)(6506007)(66446008)(76176011)(66476007)(64756008)(8936002)(66066001)(8676002)(76116006)(71200400001)(71190400001)(66946007)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0403; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1CLeyUs6TN1y+ycRB3VhmgGraWg/G96QrhH9qX5X8K7gEQ1INpoC8IXvhdr/h8OFC6htjQmfd56BS5AZdEHqIQn8k4QIpFnE9TileQg2HFBQQmKaAXHZvPiM6KgZuaHHXhwePxX+pa1CsvgNHeOr8uow4XAnPV6ZnY91DnEBpW4vN/IBXCrUqYr07VMNVhau9De/ktxjCjL2wlM84716ghL12rMSnIjvEKgipPxkK3CYzIwxlaEmeUP6TQNpw6qfMiIbPGChXTuLbOvg9vqiWsDG4Fwzi9j++sARi2Vurkbtri5O4/Cvxcvj2RnN0X2qGElvVOObEJAYwEUMJrjOVyjwpy2BnfTXvL3y5jHDPaLI6pstWaCBXLjTw9odqrsEDUyJFaLX+iF3D/D2MsO7U4o0v1rlf5Tqmm4MNk5liLs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR00MB02927D26A0ADAE21CD2080BDF5C90BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66ce257d-5c08-4d57-e365-08d70ae7154b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 18:46:30.5683 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbj@microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0403 Archived-At: Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2019 18:46:53 -0000 --_000_BL0PR00MB02927D26A0ADAE21CD2080BDF5C90BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHRoYXQgcHJlc2VudGF0aW9uIOKAkyBwYXJ0 aWN1bGFybHkgdGhlIOKAnGxlc3NvbnPigJ0gcGFydC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGgg PG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDExOjI4IEFNDQpUbzogRGlj ayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+OyBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFh dC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBJRVRGMTA1IE9BdXRoIFdHIERyYWZ0IEFnZW5kYQ0KDQpJ4oCZbSBjb21p bmcgaW4gbGF0ZSB0byB0aGlzIHBhcnR5LCBidXQgSeKAmXZlIGJlZW4gYXNrZWQgYnkgYSBmZXcg cGVvcGxlIGFib3V0IGhvdyBBV1MgaGFuZGxlcyByZXF1ZXN0IHNpZ25pbmcgYW5kIG91ciBleHBl cmllbmNlcyB3aXRoIGl0LiBHaXZlbiB0aGUgcmVuZXdlZCBpbnRlcmVzdCBpbiBIVFRQIHJlcXVl c3Qgc2lnbmluZyBhbmQgdGhlIG9uZ29pbmcgd29yayBvbiBEUG9QLCBpcyB0aGlzIHNvbWV0aGlu ZyB0aGUgd29ya2luZyBncm91cCB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYWJvdXQg ZHVyaW5nIG9uZSBvZiB0aGUgc2Vzc2lvbnM/IEkgY291bGQgcHV0IHRvZ2V0aGVyIGEgcXVpY2sg NS0xMCBtaW51dGUgb3ZlcnZpZXcgb2YgQVdTIFNpZ1Y0IHNpZ25pbmcgYW5kIHNvbWUgb2YgdGhl IGxlc3NvbnMgdGhhdCB3ZW50IGludG8gaXRzIGRlc2lnbi4NCg0KVGhvdWdodHM/DQoNCi0tDQpB bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBPQXV0aCA8 b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDEwLCAyMDE5IGF0IDM6MjAg UE0NClRvOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 cmlmYWF0LmlldGZAZ21haWwuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIElFVEYxMDUgT0F1dGgg V0cgRHJhZnQgQWdlbmRhDQoNCisxDQoNCkkgbGlrZSBpdCEgOikNCg0KT24gV2VkLCBKdWwgMTAs IDIwMTkgYXQgMzoxNyBQTSBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNv bTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpBbGwsDQoNCkhlcmUgaXMg b3VyIGRyYWZ0IGFnZW5kYSBmb3IgdGhlIHR3byBzZXNzaW9ucyB3ZSBoYXZlIHBsYW5uZWQgZm9y IE1vbnRyZWFsOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNS9tYXRl cmlhbHMvYWdlbmRhLTEwNS1vYXV0aC0wMDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy Rm1lZXRpbmclMkYxMDUlMkZtYXRlcmlhbHMlMkZhZ2VuZGEtMTA1LW9hdXRoLTAwJmRhdGE9MDIl N0MwMSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyZjg4NTMxNzBiNDc2NzY1 YTYwOGQ3MGFlNDlhZTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2OTg5ODQ5MzAwMTk2NTg0JnNkYXRhPUd5WXdSRlBpelJuQnZOYjF1NnVBR1lOb084MTZX b3lJVHNia3JzVjBycWMlM0QmcmVzZXJ2ZWQ9MD4NCg0KUGxlYXNlLCB0YWtlIGEgbG9vayBhbmQg bGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzLg0KDQpSZWdhcmRzLA0KIFJpZmFh dCAmIEhhbm5lcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmRhdGE9MDIlN0Mw MSU3Q01pY2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNDQyZjg4NTMxNzBiNDc2NzY1YTYw OGQ3MGFlNDlhZTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2OTg5ODQ5MzAwMTk2NTg0JnNkYXRhPWVNQ2klMkJ3OGdGWTZEZFNhUmNaaWp1WUVSJTJGck1k dTJab1FnNSUyRlM0WkVaSkUlM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_BL0PR00MB02927D26A0ADAE21CD2080BDF5C90BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkni gJlkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyB0aGF0IHByZXNlbnRhdGlvbiDigJMgcGFydGlj dWxhcmx5IHRoZSDigJxsZXNzb25z4oCdIHBhcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9i Pg0KUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKdWx5IDE3LCAyMDE5IDExOjI4IEFNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDtk aWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0Lmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBJRVRGMTA1IE9BdXRoIFdH IERyYWZ0IEFnZW5kYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mW0gY29taW5nIGluIGxhdGUgdG8gdGhpcyBwYXJ0eSwgYnV0IEnigJl2ZSBiZWVuIGFza2VkIGJ5 IGEgZmV3IHBlb3BsZSBhYm91dCBob3cgQVdTIGhhbmRsZXMgcmVxdWVzdCBzaWduaW5nIGFuZCBv dXIgZXhwZXJpZW5jZXMgd2l0aCBpdC4gR2l2ZW4gdGhlIHJlbmV3ZWQgaW50ZXJlc3QgaW4gSFRU UCByZXF1ZXN0IHNpZ25pbmcgYW5kIHRoZSBvbmdvaW5nIHdvcmsgb24gRFBvUCwgaXMgdGhpcyBz b21ldGhpbmcNCiB0aGUgd29ya2luZyBncm91cCB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJp bmcgYWJvdXQgZHVyaW5nIG9uZSBvZiB0aGUgc2Vzc2lvbnM/IEkgY291bGQgcHV0IHRvZ2V0aGVy IGEgcXVpY2sgNS0xMCBtaW51dGUgb3ZlcnZpZXcgb2YgQVdTIFNpZ1Y0IHNpZ25pbmcgYW5kIHNv bWUgb2YgdGhlIGxlc3NvbnMgdGhhdCB3ZW50IGludG8gaXRzIGRlc2lnbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Ij5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1bHkgMTAsIDIwMTkg YXQgMzoyMCBQTTxicj4NCjxiPlRvOiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVm PSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09B VVRILVdHXSBJRVRGMTA1IE9BdXRoIFdHIERyYWZ0IEFnZW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgaXQhIDop PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgSnVsIDEwLCAyMDE5IGF0IDM6MTcgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBo cmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxsLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhl cmUgaXMgb3VyIGRyYWZ0IGFnZW5kYSBmb3IgdGhlIHR3byBzZXNzaW9ucyB3ZSBoYXZlIHBsYW5u ZWQgZm9yIE1vbnRyZWFsOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZtZWV0 aW5nJTJGMTA1JTJGbWF0ZXJpYWxzJTJGYWdlbmRhLTEwNS1vYXV0aC0wMCZhbXA7ZGF0YT0wMiU3 QzAxJTdDTWljaGFlbC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M0NDJmODg1MzE3MGI0NzY3NjVh NjA4ZDcwYWU0OWFlOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY5ODk4NDkzMDAxOTY1ODQmYW1wO3NkYXRhPUd5WXdSRlBpelJuQnZOYjF1NnVBR1lOb084 MTZXb3lJVHNia3JzVjBycWMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA1L21hdGVyaWFscy9hZ2VuZGEtMTA1 LW9hdXRoLTAwPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UsIHRha2UgYSBsb29rIGFuZCBsZXQgdXMga25vdyBpZiB5 b3UgaGF2ZSBhbnkgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtSaWZhYXQgJmFtcDsgSGFubmVzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkpv bmVzJTQwbWljcm9zb2Z0LmNvbSU3QzQ0MmY4ODUzMTcwYjQ3Njc2NWE2MDhkNzBhZTQ5YWU5JTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk4OTg0OTMwMDE5 NjU4NCZhbXA7c2RhdGE9ZU1DaSUyQnc4Z0ZZNkRkU2FSY1ppanVZRVIlMkZyTWR1MlpvUWc1JTJG UzRaRVpKRSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR00MB02927D26A0ADAE21CD2080BDF5C90BL0PR00MB0292namp_-- From nobody Wed Jul 17 13:35: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 B7364120018 for ; Wed, 17 Jul 2019 13:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTeQEtpJifDM for ; Wed, 17 Jul 2019 13:35:45 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52496120086 for ; Wed, 17 Jul 2019 13:35:45 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id h18so24792303qtm.9 for ; Wed, 17 Jul 2019 13:35:45 -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=NnCI2OA58G6mTOihK1Hk3/ZGsBsUiOWWpX2Kl9ib0A0=; b=A+PwggcE33/xCZJG7Tf7SSsUrzVRYsBGVNch6XGgyJVeD22JXtfplYwiEzTtvancqE kyWYR0iEkOPEz9cDv0HGWG6DnL1WBpRKs5/si848gM5Jr6tysoDI1rYp0mjjr11CN4kk mqlvVwCk2kFnHUp5AiD6yrL6+Jf8dfbXz8g0g= 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=NnCI2OA58G6mTOihK1Hk3/ZGsBsUiOWWpX2Kl9ib0A0=; b=DmWRV2CbL96+J6EFPUzJu6ADNIi3FRaanSPIbWLETuI/UZawY+TEqvy5zO51Emt6yy iVSukF4RyVji6OwIxSBuJ3MS8FUFQXeHWQWx6uyviQNzEiN89uEW5WBhxOU8BOO7Xhfe BYb5NL4l9DovD4Ib8+nWDNIOxra+G5bjB8GGHMIw+4Q5IOyhU5Gdz93D+aZDMP3M8ZEo +Ego2P8QLDuJa1IHVuUElmuFJiNl55Lsz5VTwKSxM/yYAWraFcn1CMcxhMBYIAVknya1 YQdPC5uvnn6Sejj98PKSp3H+NMcrgOyqt9Gda0TuwcN19NK/zf1uer6Zzth5+sFulRM0 gj+Q== X-Gm-Message-State: APjAAAUDw3Jb8qwaD4VKhegRFA10GhkZtSVZqwcEH7GD7QQXaGEnsALA m8SdW0mHZbUbgJFYbQ0A141A+msdEW8WNAw6RAk7mPlggHXbSF8XzOvRZGLZu6nos20Wy+ObAG7 DLD719sKogvsQRw== X-Google-Smtp-Source: APXvYqxssnbFwRn8K/2Mk1LfExrdwDdyht8/VWfzMyTLDZOCIHPyyIAaBaoC9AwO/KD22zU8zThT5a1gcUoVk8hFJlw= X-Received: by 2002:a0c:b786:: with SMTP id l6mr30173382qve.148.1563395744171; Wed, 17 Jul 2019 13:35:44 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> From: Brian Campbell Date: Wed, 17 Jul 2019 14:35:17 -0600 Message-ID: To: Roman Danyliw Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f9a785058de66f4d" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 20:35:48 -0000 --000000000000f9a785058de66f4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Roman, for the review. Some replies are inline below. I'll aim to push out a -03 addressing this stuff sometime not too long after the I-D submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw wrote: > Hi! > > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. > That's always nice to hear :-) > > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is > this "abstract identifier" still an absolute URI per Section 4.3 of RFC39= 86? > Absolutely (see what I did there? sigh...). Syntactically it's an absolute URI. Semantically, while it might be an actual network addressable location identified by an HTTPS URL, it might also be a URN or something that more abstractly indicates a resource or grouping of resources. But its format is an absolute URI regardless. I'm not sure what, if anything, can be added or changed here to help clarify. But I'm happy to entertain suggestions, if you've got em and/or think something is needed. > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > -- is this language suggesting that the authorization server is modifyin= g > the scope value based on the resource it sees? I'm trying to understand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > Perhaps "adapt" wasn't the best choice of word but it's meant to say that an authorization server with sufficient understanding of what scopes are applicable to what resources (which won't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really) to only the scope that is applicable to the resource. Some of the examples (figures 2 - 6) attempt to show, among other things, a hypothetical case of how this might go down. In Figure 2 the initial authorization request that's approved has scope of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/ A subsequent access token request (Figure 3) has resource https://cal.example.com/ and the issued access token scope (Figure 4) is "adapted" to that resource to be only calendar Another subsequent access token request (Figure 5) has resource https://contacts.example.com/ and the issued access token scope (Figure 6) is downscoped based on that resource to be only contacts Would it be easier to understand if the word "downscope" was used rather than "adapt"? > > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? > I'm not sure, to be honest. Downscopping when possible and to the extent possible is usually a good idea (least privilege and all that) but I think maybe I'm missing your point/question. > > (3) Editorial > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > Apparently I'm fond of the double "the" and have a hard time spotting it myself. I think this is the second review in as many weeks that you've caught a few of those. Will fix. > > ** Section 2. Editorial. s/resource at which/resource to which/ > Okay. > > ** Section 2. Editorial. > s/ And can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > It can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > Yup. > > ** Section 2.1. Multiple Typo. s/an an/an/g > Again with the double words. Sigh. A double double even. > ** Section 2.2. Editorial. s/token request and response/token request > (Figure 3) and response (Figure 4)/ > Makes sense. > ** Section 3. Typo. s/a invalid/an invalid/ > Of course. > > ** Section 3. Missing words. "A bearer token that has multiple intended > recipients (audiences) can be used by any one of those recipients at any > other." Is it protected resource? > Well, those are all the words that I'd intended to be there :/ But it does read a little curtly. How about the following instead? "A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources." --=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._ --000000000000f9a785058de66f4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Roman, for the review. So= me replies are inline below. I'll aim to push out a -03 addressing this= stuff sometime not too long after the I-D submission embargo is lifted nex= t week.=C2=A0


On Tue, Jul 16, 2019 at 5:23 PM Roman Dan= yliw <rdd@cert.org= > wrote:
Hi!<= br>
The following is my AD review of draft-ietf-oauth-resource-indicators-02.= =C2=A0 The document is in good shape.

T= hat's always nice to hear :-)
=C2=A0

(1) Section 2. Per "The parameter can carry the location of a protecte= d resource, typically as an https URL, or a more abstract identifier",= is this "abstract identifier" still an absolute URI per Section = 4.3 of RFC3986?

Absolutely (see what I = did there? sigh...). Syntactically it's an absolute URI. Semantically, = while it might be an actual network addressable location identified by an H= TTPS URL, it might also be a URN or something that more abstractly indicate= s a resource or grouping of resources. But its format is an absolute URI re= gardless.

I'm not sure what, if anything,= can be added or changed here to help clarify. But I'm happy to enterta= in suggestions, if you've got em and/or think something is needed.=C2= =A0
=C2=A0


(2) Section 2.2.=C2=A0 in the sentence "To the extent possible, when i= ssuing access tokens, the authorization server should adapt the scope value= associated with an access token to the value the respective resource is ab= le to process and needs to know":

--=C2=A0 is this language suggesting that the authorization server is modif= ying the scope value based on the resource it sees?=C2=A0 I'm trying to= understand what "adapt" means, especially in relation to the imp= roved security and privacy the subsequent sentence suggests.

Perhaps "adapt" wasn't the best choice = of word but it's meant to say that an authorization server with suffici= ent understanding of what scopes are applicable to what resources (which wo= n't always be the case or even possible but sometimes) could limit the = scope associated with an access token (downscoping really) to only the scop= e that is applicable to the resource.=C2=A0

S= ome of the examples (figures 2 - 6) attempt to show, among other things, a = hypothetical case of how this might go down.

= In Figure 2 the initial authorization request that's approved has scope= of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/

A sub= sequent access token request (Figure 3) has resource https://cal.example.com/ and the issued access token sco= pe (Figure 4) is "adapted" to that resource to be only calendar

Another subsequent access token request (Figur= e 5) has resource=20 https://contacts.example.com/= and the issued access token scope (Figure 6) is downscoped based on that r= esource to be only contacts

Would it be easier to = understand if the word "downscope" was used rather than "ada= pt"?

=C2=A0

-- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ?

I'm not sure, to be honest. Downs= copping when possible and to the extent possible is usually a good idea (least privilege and all that) but I think maybe I'm missing your po= int/question.

=C2=A0

(3) Editorial
** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g

Apparently I'm fond of the double "the&q= uot; and have a hard time spotting it myself. I think this is the second re= view in as many weeks that you've caught a few of those. Will fix.
=
=C2=A0

** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/

Okay.
=C2=A0

** Section 2.=C2=A0 Editorial.=C2=A0
s/ And can also be used to inform the client that it has requested an inval= id combination of resource and scope./
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 It can also be used to inform the client that it has requested an= invalid combination of resource and scope./

Yup.
=C2=A0

** Section 2.1. Multiple Typo. s/an an/an/g

=
Again with the double words. Sigh. A double double even.=C2=A0
=C2=A0


** Section 2.2.=C2=A0 Editorial. s/token request and response/token request= (Figure 3) and response (Figure 4)/

Ma= kes sense.

=C2=A0
** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/

Of course.
=C2=A0

** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has mult= iple intended recipients (audiences) can be used by any one of those recipi= ents at any other."=C2=A0 Is it protected resource?

Well, those are all the words that I'd intended to be= there :/ But it does read a little curtly. How about the following instead= ?

"A bearer token that has multiple inte= nded recipients (audiences) indicating that the token is valid at more than= one protected resource can be used by any one of those protected resources= to access any of the other protected resources."

<= /div>
<= 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. --000000000000f9a785058de66f4d-- From nobody Wed Jul 17 14:13: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 A27AE120116 for ; Wed, 17 Jul 2019 14:13:15 -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=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 pCGZUwREHxyl for ; Wed, 17 Jul 2019 14:13:14 -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 E1BEB1200FD for ; Wed, 17 Jul 2019 14:13:13 -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 x6HLDCsZ007274 for ; Wed, 17 Jul 2019 17:13:12 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6HLDCsZ007274 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563397992; bh=XDzTnRgkPAII2XBoENs8MGtyaD+qBOqf1Qe6vF9B1go=; h=From:To:Subject:Date:References:In-Reply-To:From; b=rETuku1evRf4bUtO6CWLiHnOPh6fQ7u9deijX/Ie+PfScHz1CZF7PdzNUWd50ajky NwscD6885NvAl+DQqqC0XUJSQORlSQ1B0XK9JOC5Uih3wiBud94kcVIkhMdedV1I7Z D533s1uddV94Ui6wYBCg6AF3g0WTfhKs9atGz7UQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HLD8lS017367 for ; Wed, 17 Jul 2019 17:13:08 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 17:13:08 -0400 From: Roman Danyliw To: "'oauth@ietf.org'" Thread-Topic: AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgAs5qCA Date: Wed, 17 Jul 2019 21:13:07 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> 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: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:13:16 -0000 Hi! I forgot one more thing about this draft after re-reading draft-ietf-oauth-= token-exchange. Per the IANA action in Section 4.1, I need help understanding on the thinki= ng to resolve this TODO: o Parameter usage location: authorization request, token request [[TODO: draft-ietf-oauth-token-exchange will have already registered this for 'token request' and this draft has a more generalized usage and needs to somehow either update that registration or do a partial registration and reference]] o Change controller: IESG o Specification document(s): [[ this specification ]] My read of draft-ietf-oauth-token-exchange it that it defines 'resource' fo= r 'token exchange'. This draft (draft-ietf-oauth-resource-indicators) has = guidance on 'resource' for 'authorization request' but also additional guid= ance for 'token request'. Is the token guidance request stated here applic= able to draft-ietf-oauth-token-exchange too (i.e., is the text effectively = saying oauth-resource-indicators updates oauth-token-exhange)? I ask becau= se these drafts don't reference each other. Correct me because there is likely a history, but it seems the TODO is that= there is a dependency to resolve and a need to coming up with a way to sig= nal in the registry which draft should be read for what usage location. Co= uld draft-ietf-oauth-resource-indicators officially register 'resource'; an= d instead of draft-ietf-oauth-token-exchange including the text defining 'r= esource' in Section 2.1, it would make a normative reference to Section 2 o= f draft-ietf-oauth-resource-indicators? Roman > -----Original Message----- > From: Roman Danyliw > Sent: Tuesday, July 16, 2019 7:23 PM > To: oauth@ietf.org > Subject: AD Review: draft-ietf-oauth-resource-indicators-02 >=20 > Hi! >=20 > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. >=20 > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is t= his > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? >=20 > (2) Section 2.2. in the sentence "To the extent possible, when issuing a= ccess > tokens, the authorization server should adapt the scope value associated > with an access token to the value the respective resource is able to proc= ess > and needs to know": >=20 > -- is this language suggesting that the authorization server is modifyin= g the > scope value based on the resource it sees? I'm trying to understand what > "adapt" means, especially in relation to the improved security and privac= y the > subsequent sentence suggests. >=20 > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? >=20 > (3) Editorial > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g >=20 > ** Section 2. Editorial. s/resource at which/resource to which/ >=20 > ** Section 2. Editorial. > s/ And can also be used to inform the client that it has requested an inv= alid > combination of resource and scope./ It can also be used to inform the cli= ent > that it has requested an invalid combination of resource and scope./ >=20 > ** Section 2.1. Multiple Typo. s/an an/an/g >=20 > ** Section 2.2. Editorial. s/token request and response/token request > (Figure 3) and response (Figure 4)/ >=20 > ** Section 3. Typo. s/a invalid/an invalid/ >=20 > ** Section 3. Missing words. "A bearer token that has multiple intended > recipients (audiences) can be used by any one of those recipients at any > other." Is it protected resource? From nobody Wed Jul 17 15:04: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 B29B712006A for ; Wed, 17 Jul 2019 15:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cV1qWpaHI3FV for ; Wed, 17 Jul 2019 15:04:53 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F291200E7 for ; Wed, 17 Jul 2019 15:04:52 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HM4pgn007638; Wed, 17 Jul 2019 18:04:51 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6HM4pgn007638 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563401091; bh=ypn69h3RjFcp1h/nuDGcqsgTq7CsNHcTTfCeqzH4j0w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=hqdbX8Mz1NQsDXPbUhgy2TBUpOYM1G+XgUSankXwhThedjhZLGS7GAhJ9Rp2hCnp6 I4IEz8pvxp5qDzKz8zAl0NxSMfsJBBPXB63UMzdKngR40J+2a7AV3jrU4f+dnZe3ef kwgbhEHh+mT/P1NIGJ0eK/or+CmVfOy8KUUUoHpI= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HM4oum046837; Wed, 17 Jul 2019 18:04:50 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 18:04:50 -0400 From: Roman Danyliw To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgA09hCAAAXZ8EA= Date: Wed, 17 Jul 2019 22:04:49 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33D784Amarchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 22:04:56 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33D784Amarchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTkgNDozNSBQTQ0KVG86 IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcnMtMDINCg0KVGhhbmsgeW91LCBSb21hbiwgZm9yIHRoZSByZXZpZXcuIFNvbWUgcmVw bGllcyBhcmUgaW5saW5lIGJlbG93LiBJJ2xsIGFpbSB0byBwdXNoIG91dCBhIC0wMyBhZGRyZXNz aW5nIHRoaXMgc3R1ZmYgc29tZXRpbWUgbm90IHRvbyBsb25nIGFmdGVyIHRoZSBJLUQgc3VibWlz c2lvbiBlbWJhcmdvIGlzIGxpZnRlZCBuZXh0IHdlZWsuDQoNCg0KT24gVHVlLCBKdWwgMTYsIDIw MTkgYXQgNToyMyBQTSBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0 Lm9yZz4+IHdyb3RlOg0KSGkhDQoNClRoZSBmb2xsb3dpbmcgaXMgbXkgQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMi4gIFRoZSBkb2N1bWVudCBpcyBp biBnb29kIHNoYXBlLg0KDQpUaGF0J3MgYWx3YXlzIG5pY2UgdG8gaGVhciA6LSkNCg0KDQooMSkg U2VjdGlvbiAyLiBQZXIgIlRoZSBwYXJhbWV0ZXIgY2FuIGNhcnJ5IHRoZSBsb2NhdGlvbiBvZiBh IHByb3RlY3RlZCByZXNvdXJjZSwgdHlwaWNhbGx5IGFzIGFuIGh0dHBzIFVSTCwgb3IgYSBtb3Jl IGFic3RyYWN0IGlkZW50aWZpZXIiLCBpcyB0aGlzICJhYnN0cmFjdCBpZGVudGlmaWVyIiBzdGls bCBhbiBhYnNvbHV0ZSBVUkkgcGVyIFNlY3Rpb24gNC4zIG9mIFJGQzM5ODY/DQoNCkFic29sdXRl bHkgKHNlZSB3aGF0IEkgZGlkIHRoZXJlPyBzaWdoLi4uKS4gU3ludGFjdGljYWxseSBpdCdzIGFu IGFic29sdXRlIFVSSS4gU2VtYW50aWNhbGx5LCB3aGlsZSBpdCBtaWdodCBiZSBhbiBhY3R1YWwg bmV0d29yayBhZGRyZXNzYWJsZSBsb2NhdGlvbiBpZGVudGlmaWVkIGJ5IGFuIEhUVFBTIFVSTCwg aXQgbWlnaHQgYWxzbyBiZSBhIFVSTiBvciBzb21ldGhpbmcgdGhhdCBtb3JlIGFic3RyYWN0bHkg aW5kaWNhdGVzIGEgcmVzb3VyY2Ugb3IgZ3JvdXBpbmcgb2YgcmVzb3VyY2VzLiBCdXQgaXRzIGZv cm1hdCBpcyBhbiBhYnNvbHV0ZSBVUkkgcmVnYXJkbGVzcy4NCg0KSSdtIG5vdCBzdXJlIHdoYXQs IGlmIGFueXRoaW5nLCBjYW4gYmUgYWRkZWQgb3IgY2hhbmdlZCBoZXJlIHRvIGhlbHAgY2xhcmlm eS4gQnV0IEknbSBoYXBweSB0byBlbnRlcnRhaW4gc3VnZ2VzdGlvbnMsIGlmIHlvdSd2ZSBnb3Qg ZW0gYW5kL29yIHRoaW5rIHNvbWV0aGluZyBpcyBuZWVkZWQuDQoNCltSb21hbl0gVW5kZXJzdG9v ZC4gIENvbmN1ciB0aGVyZSBpcyBub3RoaW5nIHRvIGRvIGhlcmUuDQoNCg0KKDIpIFNlY3Rpb24g Mi4yLiAgaW4gdGhlIHNlbnRlbmNlICJUbyB0aGUgZXh0ZW50IHBvc3NpYmxlLCB3aGVuIGlzc3Vp bmcgYWNjZXNzIHRva2VucywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBhZGFwdCB0 aGUgc2NvcGUgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgdmFs dWUgdGhlIHJlc3BlY3RpdmUgcmVzb3VyY2UgaXMgYWJsZSB0byBwcm9jZXNzIGFuZCBuZWVkcyB0 byBrbm93IjoNCg0KLS0gIGlzIHRoaXMgbGFuZ3VhZ2Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBpcyBtb2RpZnlpbmcgdGhlIHNjb3BlIHZhbHVlIGJhc2VkIG9uIHRo ZSByZXNvdXJjZSBpdCBzZWVzPyAgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgImFkYXB0 IiBtZWFucywgZXNwZWNpYWxseSBpbiByZWxhdGlvbiB0byB0aGUgaW1wcm92ZWQgc2VjdXJpdHkg YW5kIHByaXZhY3kgdGhlIHN1YnNlcXVlbnQgc2VudGVuY2Ugc3VnZ2VzdHMuDQoNClBlcmhhcHMg ImFkYXB0IiB3YXNuJ3QgdGhlIGJlc3QgY2hvaWNlIG9mIHdvcmQgYnV0IGl0J3MgbWVhbnQgdG8g c2F5IHRoYXQgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2l0aCBzdWZmaWNpZW50IHVuZGVyc3Rh bmRpbmcgb2Ygd2hhdCBzY29wZXMgYXJlIGFwcGxpY2FibGUgdG8gd2hhdCByZXNvdXJjZXMgKHdo aWNoIHdvbid0IGFsd2F5cyBiZSB0aGUgY2FzZSBvciBldmVuIHBvc3NpYmxlIGJ1dCBzb21ldGlt ZXMpIGNvdWxkIGxpbWl0IHRoZSBzY29wZSBhc3NvY2lhdGVkIHdpdGggYW4gYWNjZXNzIHRva2Vu IChkb3duc2NvcGluZyByZWFsbHkpIHRvIG9ubHkgdGhlIHNjb3BlIHRoYXQgaXMgYXBwbGljYWJs ZSB0byB0aGUgcmVzb3VyY2UuDQoNClNvbWUgb2YgdGhlIGV4YW1wbGVzIChmaWd1cmVzIDIgLSA2 KSBhdHRlbXB0IHRvIHNob3csIGFtb25nIG90aGVyIHRoaW5ncywgYSBoeXBvdGhldGljYWwgY2Fz ZSBvZiBob3cgdGhpcyBtaWdodCBnbyBkb3duLg0KDQpJbiBGaWd1cmUgMiB0aGUgaW5pdGlhbCBh dXRob3JpemF0aW9uIHJlcXVlc3QgdGhhdCdzIGFwcHJvdmVkIGhhcyBzY29wZSBvZiBjYWxlbmRh ciAmIGNvbnRhY3RzIGFuZCByZXNvdXJjZXMgaHR0cHM6Ly9jb250YWN0cy5leGFtcGxlLmNvbS8g JiBodHRwczovL2NhbC5leGFtcGxlLmNvbS8NCg0KQSBzdWJzZXF1ZW50IGFjY2VzcyB0b2tlbiBy ZXF1ZXN0IChGaWd1cmUgMykgaGFzIHJlc291cmNlIGh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyBh bmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2NvcGUgKEZpZ3VyZSA0KSBpcyAiYWRhcHRlZCIg dG8gdGhhdCByZXNvdXJjZSB0byBiZSBvbmx5IGNhbGVuZGFyDQoNCkFub3RoZXIgc3Vic2VxdWVu dCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCAoRmlndXJlIDUpIGhhcyByZXNvdXJjZSBodHRwczovL2Nv bnRhY3RzLmV4YW1wbGUuY29tLyBhbmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2NvcGUgKEZp Z3VyZSA2KSBpcyBkb3duc2NvcGVkIGJhc2VkIG9uIHRoYXQgcmVzb3VyY2UgdG8gYmUgb25seSBj b250YWN0cw0KDQpXb3VsZCBpdCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZCBpZiB0aGUgd29yZCAi ZG93bnNjb3BlIiB3YXMgdXNlZCByYXRoZXIgdGhhbiAiYWRhcHQiPw0KDQpbUm9tYW5dIFVzaW5n IOKAnGRvd25zY29wZeKAnSBkb2VzIHdvcmsgZm9yIG1lLiAgSXQgY2FwdHVyZXMgdGhhdCB0aGUg c2VydmVyIGlzIGdvaW5nIHRvIHJlZHVjZSB0aGUgc2NvcGUgKGFuZCBjZXJ0YWlubHkgbm90IGV4 cGFuZCBpdCkuDQoNCg0KLS0gKERlcGVuZGluZyBvbiB0aGUgYWJvdmUpIElzIHRoZXJlIGEgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbiBoZXJlIGZvciB0aGUgc2VydmVyIHJlbGF0aXZlIHRvIGNvbmZp ZGVudGlhbCBzY29wZSB2YWx1ZXMgYW5kIGhvdyB0aGV5IG1pZ2h0IGJlIG1vZGlmaWVkPw0KDQpJ J20gbm90IHN1cmUsIHRvIGJlIGhvbmVzdC4gRG93bnNjb3BwaW5nIHdoZW4gcG9zc2libGUgYW5k IHRvIHRoZSBleHRlbnQgcG9zc2libGUgaXMgdXN1YWxseSBhIGdvb2QgaWRlYSAobGVhc3QgcHJp dmlsZWdlIGFuZCBhbGwgdGhhdCkgYnV0IEkgdGhpbmsgbWF5YmUgSSdtIG1pc3NpbmcgeW91ciBw b2ludC9xdWVzdGlvbi4NCg0KW1JvbWFuXSBZZXMsIGxlYXN0IHByaXZpbGVnZSB3YXMgcGFydCBv ZiBpdCBhbmQgSSB0aGluayB0aGUgdGV4dCBhYm92ZSBnZXRzIGF0IGl0LiAgSG93ZXZlciwgdGhl IG90aGVyIHBhcnQgaXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBuZXh0IHNlbnRlbmNlIGlu IHRoZSBwYXJhZ3JhcGgsIOKAnFRoaXMgZnVydGhlciBpbXByb3ZlcyBwcml2YWN5IGFzIHNjb3Bl IHZhbHVlcyBnaXZlIGFuIGluZGljYXRpb24gb2Ygd2hhdCBzZXJ2aWNlcyB0aGUgcmVzb3VyY2Ug b3duZXIgdXNlcyBhbmQgaXQgaW1wcm92ZXMgc2VjdXJpdHkgYXMgc2NvcGUgdmFsdWVzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBkYXRh4oCdLiAgSWYgdGhlIGluaXRpYWwgcmVxdWVzdCB3YXMg bm90aW9uYWxseSBhIHNjb3BlIG9mIOKAnGFsbCB0aGUgaG91c2VzIG9uIHRoZSBibG9ja+KAnSwg YnV0IHRoZSBzZXJ2ZXIga25ldyB0aGF0IHRoaXMgcmVxdWVzdCB3YXMgdG9vIGJyb2FkIGFuZCBk b3duLXNjb3BlZCB0byDigJxvbmx5IHRoZSBjb3JuZXIgaG91c2XigJ0sIHdvdWxkbuKAmXQgdGhp cyBhY3R1YWxseSBiZSB3b3JzZSBmb3IgcHJpdmFjeT8gIEkgYWxzbyBkb27igJl0IGZvbGxvdyBo b3cgcmVkdWNpbmcgdGhlIHNjb3BlIGltcGFjdHMgY29uZmlkZW50aWFsIGRhdGEuDQoNCg0KKDMp IEVkaXRvcmlhbA0KKiogU2VjdGlvbiAxIGFuZCAyLjEuICBNdWx0aXBsZSBUeXBvLiAgcy90aGUg dGhlL3RoZS9nDQoNCkFwcGFyZW50bHkgSSdtIGZvbmQgb2YgdGhlIGRvdWJsZSAidGhlIiBhbmQg aGF2ZSBhIGhhcmQgdGltZSBzcG90dGluZyBpdCBteXNlbGYuIEkgdGhpbmsgdGhpcyBpcyB0aGUg c2Vjb25kIHJldmlldyBpbiBhcyBtYW55IHdlZWtzIHRoYXQgeW91J3ZlIGNhdWdodCBhIGZldyBv ZiB0aG9zZS4gV2lsbCBmaXguDQoNCg0KKiogU2VjdGlvbiAyLiAgRWRpdG9yaWFsLiBzL3Jlc291 cmNlIGF0IHdoaWNoL3Jlc291cmNlIHRvIHdoaWNoLw0KDQpPa2F5Lg0KDQoNCioqIFNlY3Rpb24g Mi4gIEVkaXRvcmlhbC4NCnMvIEFuZCBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZm9ybSB0aGUgY2xp ZW50IHRoYXQgaXQgaGFzIHJlcXVlc3RlZCBhbiBpbnZhbGlkIGNvbWJpbmF0aW9uIG9mIHJlc291 cmNlIGFuZCBzY29wZS4vDQogICAgICAgIEl0IGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mb3JtIHRo ZSBjbGllbnQgdGhhdCBpdCBoYXMgcmVxdWVzdGVkIGFuIGludmFsaWQgY29tYmluYXRpb24gb2Yg cmVzb3VyY2UgYW5kIHNjb3BlLi8NCg0KWXVwLg0KDQoNCioqIFNlY3Rpb24gMi4xLiBNdWx0aXBs ZSBUeXBvLiBzL2FuIGFuL2FuL2cNCg0KQWdhaW4gd2l0aCB0aGUgZG91YmxlIHdvcmRzLiBTaWdo LiBBIGRvdWJsZSBkb3VibGUgZXZlbi4NCg0KDQoNCioqIFNlY3Rpb24gMi4yLiAgRWRpdG9yaWFs LiBzL3Rva2VuIHJlcXVlc3QgYW5kIHJlc3BvbnNlL3Rva2VuIHJlcXVlc3QgKEZpZ3VyZSAzKSBh bmQgcmVzcG9uc2UgKEZpZ3VyZSA0KS8NCg0KTWFrZXMgc2Vuc2UuDQoNCg0KKiogU2VjdGlvbiAz LiAgVHlwby4gIHMvYSBpbnZhbGlkL2FuIGludmFsaWQvDQoNCk9mIGNvdXJzZS4NCg0KDQoqKiBT ZWN0aW9uIDMuICBNaXNzaW5nIHdvcmRzLiAgIkEgYmVhcmVyIHRva2VuIHRoYXQgaGFzIG11bHRp cGxlIGludGVuZGVkIHJlY2lwaWVudHMgKGF1ZGllbmNlcykgY2FuIGJlIHVzZWQgYnkgYW55IG9u ZSBvZiB0aG9zZSByZWNpcGllbnRzIGF0IGFueSBvdGhlci4iICBJcyBpdCBwcm90ZWN0ZWQgcmVz b3VyY2U/DQoNCldlbGwsIHRob3NlIGFyZSBhbGwgdGhlIHdvcmRzIHRoYXQgSSdkIGludGVuZGVk IHRvIGJlIHRoZXJlIDovIEJ1dCBpdCBkb2VzIHJlYWQgYSBsaXR0bGUgY3VydGx5LiBIb3cgYWJv dXQgdGhlIGZvbGxvd2luZyBpbnN0ZWFkPw0KDQoiQSBiZWFyZXIgdG9rZW4gdGhhdCBoYXMgbXVs dGlwbGUgaW50ZW5kZWQgcmVjaXBpZW50cyAoYXVkaWVuY2VzKSBpbmRpY2F0aW5nIHRoYXQgdGhl IHRva2VuIGlzIHZhbGlkIGF0IG1vcmUgdGhhbiBvbmUgcHJvdGVjdGVkIHJlc291cmNlIGNhbiBi ZSB1c2VkIGJ5IGFueSBvbmUgb2YgdGhvc2UgcHJvdGVjdGVkIHJlc291cmNlcyB0byBhY2Nlc3Mg YW55IG9mIHRoZSBvdGhlciBwcm90ZWN0ZWQgcmVzb3VyY2VzLiINCg0KW1JvbWFuXSBUaGFua3Mg Zm9yIGZpeGluZyBhbGwgb2YgdGhlc2UuDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBk ZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21w dXRlci4gVGhhbmsgeW91Lg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33D784Amarchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IaSBCcmlhbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAxNywgMjAxOSA0OjM1IFBNPGJyPg0K PGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBB RCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rIHlvdSwgUm9tYW4sIGZvciB0aGUgcmV2aWV3LiBTb21lIHJlcGxpZXMgYXJlIGlu bGluZSBiZWxvdy4gSSdsbCBhaW0gdG8gcHVzaCBvdXQgYSAtMDMgYWRkcmVzc2luZyB0aGlzIHN0 dWZmIHNvbWV0aW1lIG5vdCB0b28gbG9uZyBhZnRlciB0aGUgSS1EIHN1Ym1pc3Npb24gZW1iYXJn byBpcyBsaWZ0ZWQgbmV4dCB3ZWVrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDE2LCAyMDE5IGF0IDU6MjMg UE0gUm9tYW4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkhPGJyPg0KPGJyPg0KVGhl IGZvbGxvd2luZyBpcyBteSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLTAyLiZuYnNwOyBUaGUgZG9jdW1lbnQgaXMgaW4gZ29vZCBzaGFwZS48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YXQncyBhbHdheXMgbmljZSB0byBoZWFyIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQooMSkgU2VjdGlvbiAyLiBQZXIg JnF1b3Q7VGhlIHBhcmFtZXRlciBjYW4gY2FycnkgdGhlIGxvY2F0aW9uIG9mIGEgcHJvdGVjdGVk IHJlc291cmNlLCB0eXBpY2FsbHkgYXMgYW4gaHR0cHMgVVJMLCBvciBhIG1vcmUgYWJzdHJhY3Qg aWRlbnRpZmllciZxdW90OywgaXMgdGhpcyAmcXVvdDthYnN0cmFjdCBpZGVudGlmaWVyJnF1b3Q7 IHN0aWxsIGFuIGFic29sdXRlIFVSSSBwZXIgU2VjdGlvbiA0LjMgb2YgUkZDMzk4Nj88bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFi c29sdXRlbHkgKHNlZSB3aGF0IEkgZGlkIHRoZXJlPyBzaWdoLi4uKS4gU3ludGFjdGljYWxseSBp dCdzIGFuIGFic29sdXRlIFVSSS4gU2VtYW50aWNhbGx5LCB3aGlsZSBpdCBtaWdodCBiZSBhbiBh Y3R1YWwgbmV0d29yayBhZGRyZXNzYWJsZSBsb2NhdGlvbiBpZGVudGlmaWVkIGJ5IGFuIEhUVFBT IFVSTCwgaXQgbWlnaHQgYWxzbyBiZSBhIFVSTiBvciBzb21ldGhpbmcgdGhhdCBtb3JlIGFic3Ry YWN0bHkNCiBpbmRpY2F0ZXMgYSByZXNvdXJjZSBvciBncm91cGluZyBvZiByZXNvdXJjZXMuIEJ1 dCBpdHMgZm9ybWF0IGlzIGFuIGFic29sdXRlIFVSSSByZWdhcmRsZXNzLg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3VyZSB3 aGF0LCBpZiBhbnl0aGluZywgY2FuIGJlIGFkZGVkIG9yIGNoYW5nZWQgaGVyZSB0byBoZWxwIGNs YXJpZnkuIEJ1dCBJJ20gaGFwcHkgdG8gZW50ZXJ0YWluIHN1Z2dlc3Rpb25zLCBpZiB5b3UndmUg Z290IGVtIGFuZC9vciB0aGluayBzb21ldGhpbmcgaXMgbmVlZGVkLiZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5bUm9tYW5dIFVuZGVyc3Rvb2QuJm5ic3A7IENvbmN1ciB0aGVyZSBp cyBub3RoaW5nIHRvIGRvIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCigyKSBTZWN0aW9uIDIuMi4mbmJzcDsgaW4gdGhlIHNlbnRlbmNlICZxdW90O1RvIHRoZSBl eHRlbnQgcG9zc2libGUsIHdoZW4gaXNzdWluZyBhY2Nlc3MgdG9rZW5zLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgc2hvdWxkIGFkYXB0IHRoZSBzY29wZSB2YWx1ZSBhc3NvY2lhdGVkIHdpdGgg YW4gYWNjZXNzIHRva2VuIHRvIHRoZSB2YWx1ZSB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSBpcyBh YmxlIHRvIHByb2Nlc3MgYW5kIG5lZWRzIHRvIGtub3cmcXVvdDs6PGJyPg0KPGJyPg0KLS0mbmJz cDsgaXMgdGhpcyBsYW5ndWFnZSBzdWdnZXN0aW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGlzIG1vZGlmeWluZyB0aGUgc2NvcGUgdmFsdWUgYmFzZWQgb24gdGhlIHJlc291cmNlIGl0 IHNlZXM/Jm5ic3A7IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0ICZxdW90O2FkYXB0JnF1 b3Q7IG1lYW5zLCBlc3BlY2lhbGx5IGluIHJlbGF0aW9uIHRvIHRoZSBpbXByb3ZlZCBzZWN1cml0 eSBhbmQgcHJpdmFjeSB0aGUgc3Vic2VxdWVudCBzZW50ZW5jZSBzdWdnZXN0cy48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhh cHMgJnF1b3Q7YWRhcHQmcXVvdDsgd2Fzbid0IHRoZSBiZXN0IGNob2ljZSBvZiB3b3JkIGJ1dCBp dCdzIG1lYW50IHRvIHNheSB0aGF0IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggc3VmZmlj aWVudCB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgc2NvcGVzIGFyZSBhcHBsaWNhYmxlIHRvIHdoYXQg cmVzb3VyY2VzICh3aGljaCB3b24ndCBhbHdheXMgYmUgdGhlIGNhc2Ugb3IgZXZlbiBwb3NzaWJs ZSBidXQgc29tZXRpbWVzKQ0KIGNvdWxkIGxpbWl0IHRoZSBzY29wZSBhc3NvY2lhdGVkIHdpdGgg YW4gYWNjZXNzIHRva2VuIChkb3duc2NvcGluZyByZWFsbHkpIHRvIG9ubHkgdGhlIHNjb3BlIHRo YXQgaXMgYXBwbGljYWJsZSB0byB0aGUgcmVzb3VyY2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBvZiB0aGUgZXhhbXBs ZXMgKGZpZ3VyZXMgMiAtIDYpIGF0dGVtcHQgdG8gc2hvdywgYW1vbmcgb3RoZXIgdGhpbmdzLCBh IGh5cG90aGV0aWNhbCBjYXNlIG9mIGhvdyB0aGlzIG1pZ2h0IGdvIGRvd24uDQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gRmlndXJlIDIg dGhlIGluaXRpYWwgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRoYXQncyBhcHByb3ZlZCBoYXMgc2Nv cGUgb2YgY2FsZW5kYXIgJmFtcDsgY29udGFjdHMgYW5kIHJlc291cmNlcw0KPGEgaHJlZj0iaHR0 cHM6Ly9jb250YWN0cy5leGFtcGxlLmNvbS8iPmh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20v PC9hPiAmYW1wOyA8YSBocmVmPSJodHRwczovL2NhbC5leGFtcGxlLmNvbS8iPg0KaHR0cHM6Ly9j YWwuZXhhbXBsZS5jb20vPC9hPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QSBzdWJzZXF1ZW50IGFjY2VzcyB0b2tlbiByZXF1ZXN0IChGaWd1 cmUgMykgaGFzIHJlc291cmNlIDxhIGhyZWY9Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyI+DQpo dHRwczovL2NhbC5leGFtcGxlLmNvbS88L2E+IGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBz Y29wZSAoRmlndXJlIDQpIGlzICZxdW90O2FkYXB0ZWQmcXVvdDsgdG8gdGhhdCByZXNvdXJjZSB0 byBiZSBvbmx5IGNhbGVuZGFyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm90aGVyIHN1YnNlcXVlbnQgYWNjZXNzIHRva2VuIHJl cXVlc3QgKEZpZ3VyZSA1KSBoYXMgcmVzb3VyY2UNCjxhIGhyZWY9Imh0dHBzOi8vY29udGFjdHMu ZXhhbXBsZS5jb20vIj5odHRwczovL2NvbnRhY3RzLmV4YW1wbGUuY29tLzwvYT4gYW5kIHRoZSBp c3N1ZWQgYWNjZXNzIHRva2VuIHNjb3BlIChGaWd1cmUgNikgaXMgZG93bnNjb3BlZCBiYXNlZCBv biB0aGF0IHJlc291cmNlIHRvIGJlIG9ubHkgY29udGFjdHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgaXQgYmUgZWFzaWVyIHRvIHVu ZGVyc3RhbmQgaWYgdGhlIHdvcmQgJnF1b3Q7ZG93bnNjb3BlJnF1b3Q7IHdhcyB1c2VkIHJhdGhl ciB0aGFuICZxdW90O2FkYXB0JnF1b3Q7Pw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPltSb21hbl0gVXNpbmcg4oCcZG93bnNjb3Bl4oCdIGRvZXMgd29yayBmb3IgbWUuJm5i c3A7IEl0IGNhcHR1cmVzIHRoYXQgdGhlIHNlcnZlciBpcyBnb2luZyB0byByZWR1Y2UgdGhlIHNj b3BlIChhbmQgY2VydGFpbmx5IG5vdCBleHBhbmQgaXQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLSAoRGVwZW5kaW5nIG9uIHRoZSBhYm92ZSkgSXMgdGhlcmUgYSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIGhlcmUgZm9yIHRoZSBzZXJ2ZXIgcmVsYXRpdmUgdG8gY29uZmlkZW50aWFsIHNjb3Bl IHZhbHVlcyBhbmQgaG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUs IHRvIGJlIGhvbmVzdC4gRG93bnNjb3BwaW5nIHdoZW4gcG9zc2libGUgYW5kIHRvIHRoZSBleHRl bnQgcG9zc2libGUgaXMgdXN1YWxseSBhIGdvb2QgaWRlYSAobGVhc3QgcHJpdmlsZWdlIGFuZCBh bGwgdGhhdCkgYnV0IEkgdGhpbmsgbWF5YmUgSSdtIG1pc3NpbmcgeW91ciBwb2ludC9xdWVzdGlv bi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjE1cHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUm9tYW5dIFllcywgbGVhc3QgcHJpdmlsZWdlIHdhcyBw YXJ0IG9mIGl0IGFuZCBJIHRoaW5rIHRoZSB0ZXh0IGFib3ZlIGdldHMgYXQgaXQuJm5ic3A7IEhv d2V2ZXIsIHRoZSBvdGhlciBwYXJ0IGlzIHRoZSByZWxhdGlvbnNoaXAgd2l0aA0KIHRoZSBuZXh0 IHNlbnRlbmNlIGluIHRoZSBwYXJhZ3JhcGgsIOKAnFRoaXMgZnVydGhlciBpbXByb3ZlcyBwcml2 YWN5IGFzIHNjb3BlIHZhbHVlcyBnaXZlIGFuIGluZGljYXRpb24gb2Ygd2hhdCBzZXJ2aWNlcyB0 aGUgcmVzb3VyY2Ugb3duZXIgdXNlcyBhbmQgaXQgaW1wcm92ZXMgc2VjdXJpdHkgYXMgc2NvcGUg dmFsdWVzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBkYXRh4oCdLiZuYnNwOyBJZiB0aGUgaW5p dGlhbCByZXF1ZXN0IHdhcyBub3Rpb25hbGx5IGENCiBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNl cyBvbiB0aGUgYmxvY2vigJ0sIGJ1dCB0aGUgc2VydmVyIGtuZXcgdGhhdCB0aGlzIHJlcXVlc3Qg d2FzIHRvbyBicm9hZCBhbmQgZG93bi1zY29wZWQgdG8g4oCcb25seSB0aGUgY29ybmVyIGhvdXNl 4oCdLCB3b3VsZG7igJl0IHRoaXMgYWN0dWFsbHkgYmUgd29yc2UgZm9yIHByaXZhY3k/Jm5ic3A7 IEkgYWxzbyBkb27igJl0IGZvbGxvdyBob3cgcmVkdWNpbmcgdGhlIHNjb3BlIGltcGFjdHMgY29u ZmlkZW50aWFsIGRhdGEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQooMykgRWRpdG9yaWFsPGJyPg0KKiogU2Vj dGlvbiAxIGFuZCAyLjEuJm5ic3A7IE11bHRpcGxlIFR5cG8uJm5ic3A7IHMvdGhlIHRoZS90aGUv ZzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXBwYXJlbnRseSBJJ20gZm9uZCBvZiB0aGUgZG91YmxlICZxdW90O3RoZSZxdW90OyBh bmQgaGF2ZSBhIGhhcmQgdGltZSBzcG90dGluZyBpdCBteXNlbGYuIEkgdGhpbmsgdGhpcyBpcyB0 aGUgc2Vjb25kIHJldmlldyBpbiBhcyBtYW55IHdlZWtzIHRoYXQgeW91J3ZlIGNhdWdodCBhIGZl dyBvZiB0aG9zZS4gV2lsbCBmaXguDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKiogU2VjdGlvbiAyLiZuYnNwOyBFZGl0 b3JpYWwuIHMvcmVzb3VyY2UgYXQgd2hpY2gvcmVzb3VyY2UgdG8gd2hpY2gvPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pa2F5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQoqKiBTZWN0aW9uIDIuJm5ic3A7IEVkaXRvcmlhbC4mbmJzcDsgPGJyPg0Kcy8gQW5k IGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgdGhhdCBpdCBoYXMgcmVxdWVz dGVkIGFuIGludmFsaWQgY29tYmluYXRpb24gb2YgcmVzb3VyY2UgYW5kIHNjb3BlLi88YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgY2FuIGFsc28gYmUg dXNlZCB0byBpbmZvcm0gdGhlIGNsaWVudCB0aGF0IGl0IGhhcyByZXF1ZXN0ZWQgYW4gaW52YWxp ZCBjb21iaW5hdGlvbiBvZiByZXNvdXJjZSBhbmQgc2NvcGUuLzxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WXVwLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQoq KiBTZWN0aW9uIDIuMS4gTXVsdGlwbGUgVHlwby4gcy9hbiBhbi9hbi9nPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiB3aXRo IHRoZSBkb3VibGUgd29yZHMuIFNpZ2guIEEgZG91YmxlIGRvdWJsZSBldmVuLiZuYnNwOyA8bzpw Pg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCioqIFNlY3Rpb24gMi4yLiZuYnNwOyBFZGl0b3JpYWwuIHMvdG9rZW4gcmVxdWVz dCBhbmQgcmVzcG9uc2UvdG9rZW4gcmVxdWVzdCAoRmlndXJlIDMpIGFuZCByZXNwb25zZSAoRmln dXJlIDQpLzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TWFrZXMgc2Vuc2UuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqIFNlY3Rpb24gMy4mbmJzcDsgVHlwby4m bmJzcDsgcy9hIGludmFsaWQvYW4gaW52YWxpZC88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJzZS4gPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCioq IFNlY3Rpb24gMy4mbmJzcDsgTWlzc2luZyB3b3Jkcy4mbmJzcDsgJnF1b3Q7QSBiZWFyZXIgdG9r ZW4gdGhhdCBoYXMgbXVsdGlwbGUgaW50ZW5kZWQgcmVjaXBpZW50cyAoYXVkaWVuY2VzKSBjYW4g YmUgdXNlZCBieSBhbnkgb25lIG9mIHRob3NlIHJlY2lwaWVudHMgYXQgYW55IG90aGVyLiZxdW90 OyZuYnNwOyBJcyBpdCBwcm90ZWN0ZWQgcmVzb3VyY2U/PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsLCB0aG9zZSBhcmUgYWxs IHRoZSB3b3JkcyB0aGF0IEknZCBpbnRlbmRlZCB0byBiZSB0aGVyZSA6LyBCdXQgaXQgZG9lcyBy ZWFkIGEgbGl0dGxlIGN1cnRseS4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgaW5zdGVhZD8NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVv dDtBIGJlYXJlciB0b2tlbiB0aGF0IGhhcyBtdWx0aXBsZSBpbnRlbmRlZCByZWNpcGllbnRzIChh dWRpZW5jZXMpIGluZGljYXRpbmcgdGhhdCB0aGUgdG9rZW4gaXMgdmFsaWQgYXQgbW9yZSB0aGFu IG9uZSBwcm90ZWN0ZWQgcmVzb3VyY2UgY2FuIGJlIHVzZWQgYnkgYW55IG9uZSBvZiB0aG9zZSBw cm90ZWN0ZWQgcmVzb3VyY2VzIHRvIGFjY2VzcyBhbnkgb2YgdGhlIG90aGVyIHByb3RlY3RlZCBy ZXNvdXJjZXMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21h bl0gVGhhbmtzIGZvciBmaXhpbmcgYWxsIG9mIHRoZXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow aW4iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9z cGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33D784Amarchand_-- From nobody Wed Jul 17 15:31: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 67F031205D2 for ; Wed, 17 Jul 2019 15:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pblOYSfA-wR for ; Wed, 17 Jul 2019 15:31:29 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78DB1205CC for ; Wed, 17 Jul 2019 15:31:28 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id d17so25062476qtj.8 for ; Wed, 17 Jul 2019 15:31:28 -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=ey0ZaUWLgh3/5HgKpf3yYykW6mhRteiI9byKTPxKc3M=; b=LF138w2lwQB+vpxDq2YxUshtEGAW6Ukm3YCb+d7dG/tmUC7FvKgVdlm810HBGClcqH f2yi3wqti+F7Xfz5wuYQB1FzfFOJ2cPe4XqcgMRYOmAhLhsQA8GMj9m9fAJJ0JDKRbfJ 8Y9fjUfIkfb/agbji7DtKKO7jJyQzZqjs9+QI= 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=ey0ZaUWLgh3/5HgKpf3yYykW6mhRteiI9byKTPxKc3M=; b=SPTUz+TI2VUDhjVL14eS2I4W+dAJGgKt9pKjHT5BwYYYRdpLofPazq7hfZsXnkllVW /qKd6nLConK0zHfM2cyvDAKvkV710yqh/M0wdk/31+8LIkvk0UqGMQMsL1ef1Is5ZVtr y2wMJ8vZKEzKw4jyYbK0MTd9UYe1nESyfNgrNdGEuSrQkVG2xwRvgK8gJfJwPoCsQMZM 3KLyLyzdqFKIwir/TWIJJeUk3LAnwM6neL4XIzfPI25Oqh8hM6j1JuI8FMi9ZBunNPg0 L44cvHrQM7ggbyo5pVBzyA2Py//ma5SHD/0kHXnHWys6a4UC5ApstIZF1Zzv4Su3gclr 58Ow== X-Gm-Message-State: APjAAAXDSNvbsU7CQ7LgB7w/WkaS4iC4GJxDCURSUE4bYCheedZ6oHix vyplo0y3y3wwgFCcgNfLGwvVOTxMk8GAjdreNJFGPanylta4PX6XUXhFB/PacTkG8NlnuOEqRae XLFTa7yexPWbxgA== X-Google-Smtp-Source: APXvYqzt0zs45/p7PlKDgt1BzsDHUbrGJ95TUJGN39uC/UrI3epddfNMdr7UwDarwiUElsOkT9w8dher5d2Z0CAaN2o= X-Received: by 2002:ac8:c0e:: with SMTP id k14mr29404995qti.72.1563402687881; Wed, 17 Jul 2019 15:31:27 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> From: Brian Campbell Date: Wed, 17 Jul 2019 16:31:01 -0600 Message-ID: To: Roman Danyliw Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000da3fbf058de80d22" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 22:31:37 -0000 --000000000000da3fbf058de80d22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, as you surmised, there is some history behind this. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-resource-indicators by a good long time (years) and with the hope and expectation that draft-ietf-oauth-token-exchange would move to RFC, I've avoided having a reference in it to a draft much earlier along in the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd history too in that an initial call for adoption around the Buenos Aires meeting kinda fizzled out and it was left for dead until being unexpected resurrected around Montreal last year due to renewed interest and other factors I'm still not sure I understand. You are correct that draft-ietf-oauth-token-exchange defines "resource" for token exchange. However the registry itself doesn't have that level of granularity. It has authorization request, authorization response, token request, and token response as the possible locations for parameter usage. A token exchange request is a particular kind of token request so draft-ietf-oauth-token-exchange registers "resource" for the token request location. The IANA section was written before draft-ietf-oauth-resource-indicators even existed. And leaving the registration in draft-ietf-oauth-token-exchange seemed like the right thing to do to even after draft-ietf-oauth-resource-indicators came along. But I'm not sure, to be honest. Also FWIW a temporary registration entry for it is already in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pa= rameters draft-ietf-oauth-resource-indicators defines "resource" for use at the authorization endpoint (which token exchange does not) so that's the impetus behind having the registration request there include authorization request in the location. draft-ietf-oauth-resource-indicators also has "resource" for use at the token endpoint using the same semantics as in draft-ietf-oauth-token-exchange but in a way that is applicable to all types of token requests to the the token endpoint and not only token exchange requests. That's where the idea of updating the registry came from - it's not a name collision and it's not a different definition - it's just a more generalized usage. I hope this makes some sense and hasn't muddied the waters more. On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw wrote: > Hi! > > I forgot one more thing about this draft after re-reading > draft-ietf-oauth-token-exchange. > > Per the IANA action in Section 4.1, I need help understanding on the > thinking to resolve this TODO: > > o Parameter usage location: authorization request, token request > [[TODO: draft-ietf-oauth-token-exchange will have already > registered this for 'token request' and this draft has a more > generalized usage and needs to somehow either update that > registration or do a partial registration and reference]] > o Change controller: IESG > o Specification document(s): [[ this specification ]] > > My read of draft-ietf-oauth-token-exchange it that it defines 'resource' > for 'token exchange'. This draft (draft-ietf-oauth-resource-indicators) > has guidance on 'resource' for 'authorization request' but also additiona= l > guidance for 'token request'. Is the token guidance request stated here > applicable to draft-ietf-oauth-token-exchange too (i.e., is the text > effectively saying oauth-resource-indicators updates oauth-token-exhange)= ? > I ask because these drafts don't reference each other. > > Correct me because there is likely a history, but it seems the TODO is > that there is a dependency to resolve and a need to coming up with a way = to > signal in the registry which draft should be read for what usage location= . > Could draft-ietf-oauth-resource-indicators officially register 'resource'= ; > and instead of draft-ietf-oauth-token-exchange including the text definin= g > 'resource' in Section 2.1, it would make a normative reference to Section= 2 > of draft-ietf-oauth-resource-indicators? > > Roman > > > -----Original Message----- > > From: Roman Danyliw > > Sent: Tuesday, July 16, 2019 7:23 PM > > To: oauth@ietf.org > > Subject: AD Review: draft-ietf-oauth-resource-indicators-02 > > > > Hi! > > > > The following is my AD review of draft-ietf-oauth-resource-indicators-0= 2. > > The document is in good shape. > > > > (1) Section 2. Per "The parameter can carry the location of a protected > > resource, typically as an https URL, or a more abstract identifier", is > this > > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? > > > > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access > > tokens, the authorization server should adapt the scope value associate= d > > with an access token to the value the respective resource is able to > process > > and needs to know": > > > > -- is this language suggesting that the authorization server is > modifying the > > scope value based on the resource it sees? I'm trying to understand wh= at > > "adapt" means, especially in relation to the improved security and > privacy the > > subsequent sentence suggests. > > > > -- (Depending on the above) Is there a security consideration here for > the > > server relative to confidential scope values and how they might be > modified? > > > > (3) Editorial > > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > > > > ** Section 2. Editorial. s/resource at which/resource to which/ > > > > ** Section 2. Editorial. > > s/ And can also be used to inform the client that it has requested an > invalid > > combination of resource and scope./ It can also be used to inform the > client > > that it has requested an invalid combination of resource and scope./ > > > > ** Section 2.1. Multiple Typo. s/an an/an/g > > > > ** Section 2.2. Editorial. s/token request and response/token request > > (Figure 3) and response (Figure 4)/ > > > > ** Section 3. Typo. s/a invalid/an invalid/ > > > > ** Section 3. Missing words. "A bearer token that has multiple intend= ed > > recipients (audiences) can be used by any one of those recipients at an= y > > other." Is it protected resource? > > _______________________________________________ > 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._ --000000000000da3fbf058de80d22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, as you surmised, there is some history behind t= his. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-re= source-indicators by a good long time (years) and with the hope and expecta= tion that draft-ietf-oauth-token-exchange would move to RFC, I've avoid= ed having a reference in it to a draft much earlier along in the whole proc= ess. draft-ietf-oauth-resource-indicators has a bit of an odd history too i= n that an initial call for adoption around the Buenos Aires meeting kinda f= izzled out and it was left for dead until being unexpected resurrected arou= nd Montreal last year due to renewed interest and other factors I'm sti= ll not sure I understand.=C2=A0

You are correct th= at draft-ietf-oauth-token-exchange defines "resource" for token e= xchange. However the registry itself doesn't have that level of granula= rity. It has authorization request, authorization response, token request, = and token response as the possible locations for parameter usage. A token e= xchange request is a particular kind of token request so draft-ietf-oauth-t= oken-exchange registers "resource" for the token request location= . The IANA section was written before draft-ietf-oauth-resource-indicators = even existed. And leaving the registration in draft-ietf-oauth-token-exchan= ge seemed like the right thing to do to even after draft-ietf-oauth-resourc= e-indicators came along. But I'm not sure, to be honest. Also FWIW a te= mporary registration entry for it is already in https://www.iana.org/assignments/oauth-parameters/oauth-paramet= ers.xhtml#parameters

draft-ietf-oauth-resource= -indicators defines "resource" for use at the authorization endp= oint (which token exchange does not) so that's the impetus behind havin= g the registration request there include authorization request in the locat= ion. draft-ietf-oauth-resource-indicators also has "resource" fo= r use at the token endpoint using the same semantics as in draft-ietf-oauth= -token-exchange but in a way that is applicable to all types of token reque= sts to the the token endpoint and not only token exchange requests. That= 9;s where the idea of updating the registry came from - it's not a name= collision and it's not a different definition - it's just a more g= eneralized usage.

I hope this makes some sense and= hasn't muddied the waters more.



On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw <rdd@cert.org> wrote:
Hi!

I forgot one more thing about this draft after re-reading draft-ietf-oauth-= token-exchange.

Per the IANA action in Section 4.1, I need help understanding on the thinki= ng to resolve this TODO:

=C2=A0 =C2=A0o=C2=A0 Parameter usage location: authorization request, token= request
=C2=A0 =C2=A0 =C2=A0 [[TODO: draft-ietf-oauth-token-exchange will have alre= ady
=C2=A0 =C2=A0 =C2=A0 registered this for 'token request' and this d= raft has a more
=C2=A0 =C2=A0 =C2=A0 generalized usage and needs to somehow either update t= hat
=C2=A0 =C2=A0 =C2=A0 registration or do a partial registration and referenc= e]]
=C2=A0 =C2=A0o=C2=A0 Change controller: IESG
=C2=A0 =C2=A0o=C2=A0 Specification document(s): [[ this specification ]]
My read of draft-ietf-oauth-token-exchange it that it defines 'resource= ' for 'token exchange'.=C2=A0 This draft (draft-ietf-oauth-reso= urce-indicators) has guidance on 'resource' for 'authorization = request' but also additional guidance for 'token request'.=C2= =A0 Is the token guidance request stated here applicable to draft-ietf-oaut= h-token-exchange too (i.e., is the text effectively saying oauth-resource-i= ndicators updates oauth-token-exhange)?=C2=A0 I ask because these drafts do= n't reference each other.

Correct me because there is likely a history, but it seems the TODO is that= there is a dependency to resolve and a need to coming up with a way to sig= nal in the registry which draft should be read for what usage location.=C2= =A0 Could draft-ietf-oauth-resource-indicators officially register 'res= ource'; and instead of draft-ietf-oauth-token-exchange including the te= xt defining 'resource' in Section 2.1, it would make a normative re= ference to Section 2 of draft-ietf-oauth-resource-indicators?

Roman

> -----Original Message-----
> From: Roman Danyliw
> Sent: Tuesday, July 16, 2019 7:23 PM
> To: oauth@ietf.org=
> Subject: AD Review: draft-ietf-oauth-resource-indicators-02
>
> Hi!
>
> The following is my AD review of draft-ietf-oauth-resource-indicators-= 02.
> The document is in good shape.
>
> (1) Section 2. Per "The parameter can carry the location of a pro= tected
> resource, typically as an https URL, or a more abstract identifier&quo= t;, is this
> "abstract identifier" still an absolute URI per Section 4.3 = of RFC3986?
>
> (2) Section 2.2.=C2=A0 in the sentence "To the extent possible, w= hen issuing access
> tokens, the authorization server should adapt the scope value associat= ed
> with an access token to the value the respective resource is able to p= rocess
> and needs to know":
>
> --=C2=A0 is this language suggesting that the authorization server is = modifying the
> scope value based on the resource it sees?=C2=A0 I'm trying to und= erstand what
> "adapt" means, especially in relation to the improved securi= ty and privacy the
> subsequent sentence suggests.
>
> -- (Depending on the above) Is there a security consideration here for= the
> server relative to confidential scope values and how they might be mod= ified?
>
> (3) Editorial
> ** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g
>
> ** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/<= br> >
> ** Section 2.=C2=A0 Editorial.
> s/ And can also be used to inform the client that it has requested an = invalid
> combination of resource and scope./ It can also be used to inform the = client
> that it has requested an invalid combination of resource and scope./ >
> ** Section 2.1. Multiple Typo. s/an an/an/g
>
> ** Section 2.2.=C2=A0 Editorial. s/token request and response/token re= quest
> (Figure 3) and response (Figure 4)/
>
> ** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/
>
> ** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has= multiple intended
> recipients (audiences) can be used by any one of those recipients at a= ny
> other."=C2=A0 Is it protected resource?

_______________________________________________
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. --000000000000da3fbf058de80d22-- From nobody Wed Jul 17 15:32: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 A387C120168 for ; Wed, 17 Jul 2019 15:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 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, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3PFpnmzrt44 for ; Wed, 17 Jul 2019 15:32:09 -0700 (PDT) Received: from sonic312-26.consmr.mail.ir2.yahoo.com (sonic312-26.consmr.mail.ir2.yahoo.com [77.238.178.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908651200EB for ; Wed, 17 Jul 2019 15:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1563402724; bh=n4jcsjWcCmzNW2w0GEmDhKEZ0ULHQEpQuWzAQoQgCEc=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Fg3hZzICNcpejZuvzTlfeNes8YcnYF9CbY+bkkoO5kYElZfEfhht4/KHyXM1XvehNPE50iWyCWuvODzH4yTnMAzojJg/GPtsvaHGceP4yg9iu2sYHjL/wN+RpWaKwTqBLB4oq8/inLVGBH8vylsnq+QRV4MAYjrPlY7x75FeBhbRge4LmJamDeXCRD28YNuUCuqTJvgK+yKcATk6Fz/KEWrzLMWgrk+oyKvewIGQMMBQIf4eGbrZvcrU+/qs4DJhgXbJWPK4I2On2M1uk2pP2uDDY7k0yW6lOrMnc6tgqIPvpubFlyIxBmBPTdQEQ0MXdpdSl/PpiWtA6qheduoRag== X-YMail-OSG: vSdor0IVM1mj0YPSpYAHkGWOL5rEkEuUrvYXVPwXuw6xUf7lCUzhdiebsk9I8YH YCfajordckrg4B5wc2Cxk85DSNzupprnEt6sqBjhiYoxB4h2oXWBvESWRwxs3hE6itqb8vaTCndO u0kJt0UCpsMfK7RjtrJkCYXB6w3dNZQGGGdG70gAHjylKtUrIvfCuAwnW2sm_ea0AZrrbP9p2frW yRyP90Hjuw2YYGUWQyjliqKPGlpQu7pw8RwlGeSguQXekh_YYb6SYSF8HiszJxwIwTS1n75SPqp_ 0yM1I6oOir1gj8lVVa0nuKuEjxBtncDuMorer2B6R5B07c0QQbO982d14r3NB_5KkRge_VSOtMlj 0psctvCf4zXbrjiISFhrjA0G8NGGpkuHCNd1K4cXqfBIQXcxjjbLE7oXPvlQCMQO6SMGdUnuSH1m R7g90YI66Cj5KB4yHIcFkMQ9Gpjv34uLQj4bIyHzcZQ23oAOiycgn6wBaT4VQFrFw21ZJhYXDIS_ RIdHB1h_VQa4JILVEPEDdAWf3n2eSuLelpf1KKd9yyCVt11y64LghUITuGbtF3960MtFsIqfkaRV sxQ6QQOg.n9pbo3FCNzdtYbb_VRbbur7igNc8Qtoi2nGyOtDcjnl5E29EZsKcXW7a.asVxxcEJjn XYcA.w15jALyDPupfLmU52AFLd7V6dr6dgO648Cdg5r0UFPItMBC1QOy2QC_3P2toOBGoVy8JXiK XoKn7_lYT_AfoUmu2RMTWyenXQenWAaTlyJsSQRwdLeso_.DLLJI88P3jXrIXmoWsp9BltLkB14B 2dK04ryz_OX69dQPOHij0S9Ehep.oXv16vtOwFnPlqmRZFaWfmPGAhXHyMf5sxTeT1nUnev6LgWp a0vzqz_ETMJPmq3aElpv_saKDAudOurAAC6p.zKNZTIES1j80hC8Aj_JohFzcjn6TSf7Uy2nb9hd XunFn8iUqTCFqPKvF5UZ.TvB7o4sZMAWv6aRKYGdKBD.h1bonDuBLSuDc.dnbi4w_i.QpEB5fuM1 MZFO7Pt62UR7hFn1s_lmjeh08FQABNcGvEt1h.CL5JZbIVAxNgwq_Z15h_IRlkp488KUzWztfQIr T3FrNVNHX3cAeUR5klUqeVLBHsZkUCfyUsojgtt.6oNNQzSw3SFt4S00vkILxFsBiuWRiVn0bY4S _eGYWavzGksZy25bR4TEVbBe7nT_jlHpRx2y.h3RlwOYK_2Kp1IFYL.xD9K2sw0AmDoCBeqW2onu m8yh7XNq9o1mXqAfveDfXrBRjrvVZAp4zxr5sQPHiSg9bvwtRfpCIx.s- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ir2.yahoo.com with HTTP; Wed, 17 Jul 2019 22:32:04 +0000 Received: by smtp424.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ffaf1640168c4d8f86deca0044ed4c43; Wed, 17 Jul 2019 22:32:01 +0000 (UTC) X-YMail-OSG: 8q18xeQVM1k7X5v5uY_QvvZ.viw_f4GP.Wlqtp1izNJHDBdGjFrXHAG.pDTImIq LH3QbKeCMsmnxWFWz10UKph.W88icEcYb0d4RICEs4JIAi9l8BbhH8E8ONFUB3qCdDhuSBE62ACr HJ_mO211Hmbv7SKCzGvGgwoCySsjsy24xkyBRhgRQnqP.0jMVvf7wEII3FhwvZVixn.CSSCYmBwl Zfm5RQDbfFiMvbnMkaFOpRn2stiRPCd1fEDTY3fIT0ehcJLRTNMUqlJ.Wr5qj3vdhmxyyTFhK7LY gxXTby8A89BOFnNOP8RJtLeN6BsTCnZ.oq_HxDjjNhmbZI7TseF.fnTv1UuZ4tZfTWnDqDu6F2UD K7sNDBNYWFwKn7eOXcS8eEbR9zZVr3fdGDjLqoC0bxdV4N8onO4ZGn6g_u1DVXbGC.8c4nxXI_Km sF43oeuZhHaN_hBzY9hfN.PmdqR4FcS.luqHJWs4c_lwmrFkQZ2k1k2aJGN22rEU7TodscrzGZyQ OpfT9RQApugfAufoMZ1BQ4JwaenM_w4APchnqpTQfMCklJRj9dfacYevSAEUL86vHLdL09ftrqBK hx08ryP.SXgu9K8xf5yzIHXN2JerQUWkt0EiYVREVJg1g_6ookvyxjMaSTpqnqbXLtg1ERIOU2y2 1GbejMTYYCnMtzf0T0.TLUz6F6Kox6yvx1FzTfNniVk8WpFrRoYvovMyKKaGeWYqWaqfCLZSDkH6 xCf49ljaF_PqtRvhvbpQOoR0SvdDMFa2w.blsLj.naFVU1TZc5IqZRCW5IwlflH1xhyK9NROlNOn c7.ybpA7Ms2Y.weEK1wJRAsQSOpZnbUvuAiIk3I1CalnoxW8DU29YIhpX8jmsgQRBV.ws5wg3XlV WRR_MR48iN6sANrFtPGijtOUZGKYDZcwavehrr74luJyyNsqJ7C93BaMD99M2Qc23W8UXgUz.UlI 95_g4VEeTU_fjVutTS4BDnqKJ1RMEvMezIOwB4NgSSxyF9kbuStnyzRB9rLzsYgsFuoTfWCdvLJa u5NENjW4puX.UFNECMs9Zm2ZyGRNa3AkczrRAIymMc3mfs1qsxmBH9.iUQdxJsUVMswLq9ev1xxB SYJHHrtdzxrY1qEoPHwH6cl3SDBf1YnNz8smvjpc._aXFiMUiNxDtrMpujNo3B8nkHe3EOoiNtIl keYq0UkDJwZLF6oQ1MxJKsP8l.JU9YcPEOjxkIP_K6KFNUDJ_29UDpb3PuHNoE_DF89DoVgOJN1Q BC2FN3aYjXjTUBA0nkikfXlE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Wed, 17 Jul 2019 22:32:00 +0000 Date: Wed, 17 Jul 2019 22:31:59 +0000 (UTC) From: Rafal Reply-To: "alfabeta69@yahoo.com" To: "oauth@ietf.org" , "oauth-request@ietf.org" , "oauth@ietf.org" Message-ID: <29018055.4070624.1563402719512@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4070623_696090853.1563402719504" X-Mailer: WebService/1.1.13991 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/5.40.2; Android/7.0; NRD90M; A5A_INFINI; TCL; 5086D; 5.24; 1352x720; ) Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 129, Issue 23 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2019 22:32:14 -0000 ------=_Part_4070623_696090853.1563402719504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Heartblit@yahoo.com,rafal.rogala@aol.com, rogalarafal69@gmail.com, rogalara= fal96@gmail.com,24piotrpawel22@gmail.com, heartblit@heartblit.org,aidis_add= ict@outlook.be, atomic_flow@hotmail.com,microsheart@outlook.com,rafalrogala= @rafal.rogala.com,rogalik1000@interia.pl Sent from Yahoo Mail on Android=20 =20 On Thu, 18 Jul 2019 at 0:05, oauth-request@ietf.org wrote: Send OAuth mailing list submissions to =C2=A0=C2=A0=C2=A0 oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 oauth-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: =C2=A0 1. Re: AD Review: draft-ietf-oauth-resource-indicators-02 =C2=A0 =C2=A0 =C2=A0 (Brian Campbell) =C2=A0 2. Re: AD Review: draft-ietf-oauth-resource-indicators-02 =C2=A0 =C2=A0 =C2=A0 (Roman Danyliw) =C2=A0 3. Re: AD Review: draft-ietf-oauth-resource-indicators-02 =C2=A0 =C2=A0 =C2=A0 (Roman Danyliw) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Jul 2019 14:35:17 -0600 From: Brian Campbell To: Roman Danyliw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review: =C2=A0=C2=A0=C2=A0 draft-ietf-oauth-resource-indicators-02 Message-ID: =C2=A0=C2=A0=C2=A0 Content-Type: text/plain; charset=3D"utf-8" Thank you, Roman, for the review. Some replies are inline below. I'll aim to push out a -03 addressing this stuff sometime not too long after the I-D submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw wrote: > Hi! > > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. > That's always nice to hear :-) > > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is > this "abstract identifier" still an absolute URI per Section 4.3 of RFC39= 86? > Absolutely (see what I did there? sigh...). Syntactically it's an absolute URI. Semantically, while it might be an actual network addressable location identified by an HTTPS URL, it might also be a URN or something that more abstractly indicates a resource or grouping of resources. But its format is an absolute URI regardless. I'm not sure what, if anything, can be added or changed here to help clarify. But I'm happy to entertain suggestions, if you've got em and/or think something is needed. > (2) Section 2.2.=C2=A0 in the sentence "To the extent possible, when issu= ing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > --=C2=A0 is this language suggesting that the authorization server is mod= ifying > the scope value based on the resource it sees?=C2=A0 I'm trying to unders= tand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > Perhaps "adapt" wasn't the best choice of word but it's meant to say that an authorization server with sufficient understanding of what scopes are applicable to what resources (which won't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really) to only the scope that is applicable to the resource. Some of the examples (figures 2 - 6) attempt to show, among other things, a hypothetical case of how this might go down. In Figure 2 the initial authorization request that's approved has scope of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/ A subsequent access token request (Figure 3) has resource https://cal.example.com/ and the issued access token scope (Figure 4) is "adapted" to that resource to be only calendar Another subsequent access token request (Figure 5) has resource https://contacts.example.com/ and the issued access token scope (Figure 6) is downscoped based on that resource to be only contacts Would it be easier to understand if the word "downscope" was used rather than "adapt"? > > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? > I'm not sure, to be honest. Downscopping when possible and to the extent possible is usually a good idea (least privilege and all that) but I think maybe I'm missing your point/question. > > (3) Editorial > ** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g > Apparently I'm fond of the double "the" and have a hard time spotting it myself. I think this is the second review in as many weeks that you've caught a few of those. Will fix. > > ** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/ > Okay. > > ** Section 2.=C2=A0 Editorial. > s/ And can also be used to inform the client that it has requested an > invalid combination of resource and scope./ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 It can also be used to inform the client that = it has requested an > invalid combination of resource and scope./ > Yup. > > ** Section 2.1. Multiple Typo. s/an an/an/g > Again with the double words. Sigh. A double double even. > ** Section 2.2.=C2=A0 Editorial. s/token request and response/token reque= st > (Figure 3) and response (Figure 4)/ > Makes sense. > ** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/ > Of course. > > ** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has multipl= e intended > recipients (audiences) can be used by any one of those recipients at any > other."=C2=A0 Is it protected resource? > Well, those are all the words that I'd intended to be there :/ But it does read a little curtly. How about the following instead? "A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources." --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.? If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Wed, 17 Jul 2019 21:13:07 +0000 From: Roman Danyliw To: "'oauth@ietf.org'" Subject: Re: [OAUTH-WG] AD Review: =C2=A0=C2=A0=C2=A0 draft-ietf-oauth-resource-indicators-02 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> Content-Type: text/plain; charset=3D"us-ascii" Hi! I forgot one more thing about this draft after re-reading draft-ietf-oauth-= token-exchange. Per the IANA action in Section 4.1, I need help understanding on the thinki= ng to resolve this TODO: =C2=A0 o=C2=A0 Parameter usage location: authorization request, token reque= st =C2=A0 =C2=A0 =C2=A0 [[TODO: draft-ietf-oauth-token-exchange will have alre= ady =C2=A0 =C2=A0 =C2=A0 registered this for 'token request' and this draft has= a more =C2=A0 =C2=A0 =C2=A0 generalized usage and needs to somehow either update t= hat =C2=A0 =C2=A0 =C2=A0 registration or do a partial registration and referenc= e]] =C2=A0 o=C2=A0 Change controller: IESG =C2=A0 o=C2=A0 Specification document(s): [[ this specification ]] My read of draft-ietf-oauth-token-exchange it that it defines 'resource' fo= r 'token exchange'.=C2=A0 This draft (draft-ietf-oauth-resource-indicators)= has guidance on 'resource' for 'authorization request' but also additional= guidance for 'token request'.=C2=A0 Is the token guidance request stated h= ere applicable to draft-ietf-oauth-token-exchange too (i.e., is the text ef= fectively saying oauth-resource-indicators updates oauth-token-exhange)?=C2= =A0 I ask because these drafts don't reference each other. Correct me because there is likely a history, but it seems the TODO is that= there is a dependency to resolve and a need to coming up with a way to sig= nal in the registry which draft should be read for what usage location.=C2= =A0 Could draft-ietf-oauth-resource-indicators officially register 'resourc= e'; and instead of draft-ietf-oauth-token-exchange including the text defin= ing 'resource' in Section 2.1, it would make a normative reference to Secti= on 2 of draft-ietf-oauth-resource-indicators? Roman > -----Original Message----- > From: Roman Danyliw > Sent: Tuesday, July 16, 2019 7:23 PM > To: oauth@ietf.org > Subject: AD Review: draft-ietf-oauth-resource-indicators-02 >=20 > Hi! >=20 > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. >=20 > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is t= his > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? >=20 > (2) Section 2.2.=C2=A0 in the sentence "To the extent possible, when issu= ing access > tokens, the authorization server should adapt the scope value associated > with an access token to the value the respective resource is able to proc= ess > and needs to know": >=20 > --=C2=A0 is this language suggesting that the authorization server is mod= ifying the > scope value based on the resource it sees?=C2=A0 I'm trying to understand= what > "adapt" means, especially in relation to the improved security and privac= y the > subsequent sentence suggests. >=20 > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? >=20 > (3) Editorial > ** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g >=20 > ** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/ >=20 > ** Section 2.=C2=A0 Editorial. > s/ And can also be used to inform the client that it has requested an inv= alid > combination of resource and scope./ It can also be used to inform the cli= ent > that it has requested an invalid combination of resource and scope./ >=20 > ** Section 2.1. Multiple Typo. s/an an/an/g >=20 > ** Section 2.2.=C2=A0 Editorial. s/token request and response/token reque= st > (Figure 3) and response (Figure 4)/ >=20 > ** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/ >=20 > ** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has multipl= e intended > recipients (audiences) can be used by any one of those recipients at any > other."=C2=A0 Is it protected resource? ------------------------------ Message: 3 Date: Wed, 17 Jul 2019 22:04:49 +0000 From: Roman Danyliw To: Brian Campbell Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD Review: =C2=A0=C2=A0=C2=A0 draft-ietf-oauth-resource-indicators-02 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> Content-Type: text/plain; charset=3D"utf-8" Hi Brian! From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Wednesday, July 17, 2019 4:35 PM To: Roman Danyliw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thank you, Roman, for the review. Some replies are inline below. I'll aim t= o push out a -03 addressing this stuff sometime not too long after the I-D = submission embargo is lifted next week. On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw > wrote: Hi! The following is my AD review of draft-ietf-oauth-resource-indicators-02.= =C2=A0 The document is in good shape. That's always nice to hear :-) (1) Section 2. Per "The parameter can carry the location of a protected res= ource, typically as an https URL, or a more abstract identifier", is this "= abstract identifier" still an absolute URI per Section 4.3 of RFC3986? Absolutely (see what I did there? sigh...). Syntactically it's an absolute = URI. Semantically, while it might be an actual network addressable location= identified by an HTTPS URL, it might also be a URN or something that more = abstractly indicates a resource or grouping of resources. But its format is= an absolute URI regardless. I'm not sure what, if anything, can be added or changed here to help clarif= y. But I'm happy to entertain suggestions, if you've got em and/or think so= mething is needed. [Roman] Understood.=C2=A0 Concur there is nothing to do here. (2) Section 2.2.=C2=A0 in the sentence "To the extent possible, when issuin= g access tokens, the authorization server should adapt the scope value asso= ciated with an access token to the value the respective resource is able to= process and needs to know": --=C2=A0 is this language suggesting that the authorization server is modif= ying the scope value based on the resource it sees?=C2=A0 I'm trying to und= erstand what "adapt" means, especially in relation to the improved security= and privacy the subsequent sentence suggests. Perhaps "adapt" wasn't the best choice of word but it's meant to say that a= n authorization server with sufficient understanding of what scopes are app= licable to what resources (which won't always be the case or even possible = but sometimes) could limit the scope associated with an access token (downs= coping really) to only the scope that is applicable to the resource. Some of the examples (figures 2 - 6) attempt to show, among other things, a= hypothetical case of how this might go down. In Figure 2 the initial authorization request that's approved has scope of = calendar & contacts and resources https://contacts.example.com/ & https://c= al.example.com/ A subsequent access token request (Figure 3) has resource https://cal.examp= le.com/ and the issued access token scope (Figure 4) is "adapted" to that r= esource to be only calendar Another subsequent access token request (Figure 5) has resource https://con= tacts.example.com/ and the issued access token scope (Figure 6) is downscop= ed based on that resource to be only contacts Would it be easier to understand if the word "downscope" was used rather th= an "adapt"? [Roman] Using ?downscope? does work for me.=C2=A0 It captures that the serv= er is going to reduce the scope (and certainly not expand it). -- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ? I'm not sure, to be honest. Downscopping when possible and to the extent po= ssible is usually a good idea (least privilege and all that) but I think ma= ybe I'm missing your point/question. [Roman] Yes, least privilege was part of it and I think the text above gets= at it.=C2=A0 However, the other part is the relationship with the next sen= tence in the paragraph, ?This further improves privacy as scope values give= an indication of what services the resource owner uses and it improves sec= urity as scope values may contain confidential data?.=C2=A0 If the initial = request was notionally a scope of ?all the houses on the block?, but the se= rver knew that this request was too broad and down-scoped to ?only the corn= er house?, wouldn?t this actually be worse for privacy?=C2=A0 I also don?t = follow how reducing the scope impacts confidential data. (3) Editorial ** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g Apparently I'm fond of the double "the" and have a hard time spotting it my= self. I think this is the second review in as many weeks that you've caught= a few of those. Will fix. ** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/ Okay. ** Section 2.=C2=A0 Editorial. s/ And can also be used to inform the client that it has requested an inval= id combination of resource and scope./ =C2=A0 =C2=A0 =C2=A0 =C2=A0 It can also be used to inform the client that i= t has requested an invalid combination of resource and scope./ Yup. ** Section 2.1. Multiple Typo. s/an an/an/g Again with the double words. Sigh. A double double even. ** Section 2.2.=C2=A0 Editorial. s/token request and response/token request= (Figure 3) and response (Figure 4)/ Makes sense. ** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/ Of course. ** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has multiple = intended recipients (audiences) can be used by any one of those recipients = at any other."=C2=A0 Is it protected resource? Well, those are all the words that I'd intended to be there :/ But it does = read a little curtly. How about the following instead? "A bearer token that has multiple intended recipients (audiences) indicatin= g that the token is valid at more than one protected resource can be used b= y any one of those protected resources to access any of the other protected= resources." [Roman] Thanks for fixing all of these. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited.=C2=A0 If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 129, Issue 23 ************************************** =20 ------=_Part_4070623_696090853.1563402719504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Heartblit@yahoo.com,rafal.rogala@aol.com, rogalarafal69@gmail.com, rogalara= fal96@gmail.com,24piotrpawel22@gmail.com, heartblit@heartblit.org,aidis_add= ict@outlook.be, atomic_flow@hotmail.com,microsheart@outlook.com,rafalrogala= @rafal.rogala.com,rogalik1000@interia.pl


On Thu, 18 Jul 2019 at 0:05, oauth-request@ietf.org
<oauth-request@ietf.org> wrote:
=
Send OAuth mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit=
or, via email, send a message w= ith subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subje= ct line so it is more specific
than "Re: Contents= of OAuth digest..."

<= br>
Today's Topics:

  1. Re: AD Review: draft-ietf-oauth-resource-ind= icators-02
      (Brian Campbell)<= br>
  2. Re: AD Review: draft-ietf-oauth-resour= ce-indicators-02
      (Roman Dany= liw)
  3. Re: AD Review: draft-ietf-oauth-r= esource-indicators-02
      (Roman= Danyliw)


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

Message: 1<= br>
Date: Wed, 17 Jul 2019 14:35:17 -0600
From: Brian Campbell <bcampbell@pingiden= tity.com>
To: Roman Danyliw <rdd@cert.org><= br>
Subject: Re: [OAUTH-WG] AD Review:
    draft-ietf-oauth-resource-indicators-02
Message-ID:
    <CA+= k3eCRS2HKDUWkHQzwoMVauUK7UBadw_pWdF6cXh0+BSZTbBA@mail.gmail.com>

submission embargo is lifted next week.
<= /div>


On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw <rdd@cert.org> wrote:

> Hi!
>
> The following is my AD review of = draft-ietf-oauth-resource-indicators-02.
> The= document is in good shape.
>

That's always nice to hear :-)


&g= t;
> (1) Section 2. Per "The parameter can car= ry the location of a protected
> resource, typ= ically as an https URL, or a more abstract identifier", is
> this "abstract identifier" still an absolute URI per Section= 4.3 of RFC3986?
>
<= br>
Absolutely (see what I did there? sigh...). Synta= ctically it's an absolute
URI. Semantically, whil= e it might be an actual network addressable location
identified by an HTTPS URL, it might also be a URN or something that mo= re
abstractly indicates a resource or grouping of= resources. But its format is
an absolute URI reg= ardless.

I'm not sure = what, if anything, can be added or changed here to help
clarify. But I'm happy to entertain suggestions, if you've got em = and/or
think something is needed.



=
> (2) Section 2.2.  in the sentence "To the extent= possible, when issuing
> access tokens, the a= uthorization server should adapt the scope value
= > associated with an access token to the value the respective resource i= s
> able to process and needs to know":
>
> --  is this la= nguage suggesting that the authorization server is modifying
> the scope value based on the resource it sees?  I'm t= rying to understand
> what "adapt" means, espe= cially in relation to the improved security and
&= gt; privacy the subsequent sentence suggests.
>= ;

Perhaps "adapt" wasn= 't the best choice of word but it's meant to say that
an authorization server with sufficient understanding of what scopes a= re
applicable to what resources (which won't alwa= ys be the case or even
possible but sometimes) co= uld limit the scope associated with an access
tok= en (downscoping really) to only the scope that is applicable to the
resource.

Some of the examples (figures 2 - 6) attempt to show, among other = things, a
hypothetical case of how this might go = down.

In Figure 2 the = initial authorization request that's approved has scope of
calendar & contacts and resources https://contacts.example.com/ &

A subsequent access token request (Figure 3) has resource
https://cal.example.com/ and the issued access token scope (Figure 4)= is
"adapted" to that resource to be only calenda= r

Another subsequent a= ccess token request (Figure 5) has resource
https://contacts.ex= ample.com/ and the issued access token scope (Figure 6)
is downscoped based on that resource to be only contacts

Would it be easier to underst= and if the word "downscope" was used rather
than = "adapt"?



>
>= ; -- (Depending on the above) Is there a security consideration here for th= e
> server relative to confidential scope valu= es and how they might be modified?
>
=

I'm not sure, to be honest. Dow= nscopping when possible and to the extent
possibl= e is usually a good idea (least privilege and all that) but I think
maybe I'm missing your point/question.



>
> (3) Editorial
<= div dir=3D"ltr">> ** Section 1 and 2.1.  Multiple Typo.  s/the= the/the/g
>

Apparently I'm fond of the double "the" and have a hard= time spotting it
myself. I think this is the sec= ond review in as many weeks that you've
caught a = few of those. Will fix.


>
> ** Section= 2.  Editorial. s/resource at which/resource to which/
>

Okay.<= br>


>
> ** Section 2.  Editorial.
=
> s/ And can also be used to inform the client th= at it has requested an
> invalid combination o= f resource and scope./
>      &= nbsp; It can also be used to inform the client that it has requested an
> invalid combination of resource and scope./
>

Yup.


>
> ** Section 2.1. Mult= iple Typo. s/an an/an/g
>

Again with the double words. Sigh. A doubl= e double even.



> ** Section 2.2.  E= ditorial. s/token request and response/token request
> (Figure 3) and response (Figure 4)/
>=

Makes sense.


> ** Section 3.  Typo.  s/a invalid/an= invalid/
>

Of course.


>
> ** = Section 3.  Missing words.  "A bearer token that has multiple int= ended
> recipients (audiences) can be used by = any one of those recipients at any
> other."&n= bsp; Is it protected resource?
>

Well, those are all the words that = I'd intended to be there :/ But it does
read a li= ttle curtly. How about the following instead?
"A bearer token that has multiple intended recipien= ts (audiences)
indicating that the token is valid= at more than one protected resource can
be used = by any one of those protected resources to access any of the other
protected resources."

--
_CONFIDENTIALITY NOTICE: Th= is email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use, <= br>
distribution or disclosure by others is strictly = prohibited.? If you have
received this communica= tion in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
---= ----------- next part --------------
An HTML atta= chment was scrubbed...

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

Message: 2
Date: Wed, 17 Jul 2019 21:13:07 +0000
Fr= om: Roman Danyliw <rdd@cert.org>
Subject: Re: [OAUTH-WG] A= D Review:
    draft-ietf-oauth-res= ource-indicators-02
Content-Ty= pe: text/plain; charset=3D"us-ascii"

Hi!

I f= orgot one more thing about this draft after re-reading draft-ietf-oauth-tok= en-exchange.

Per the I= ANA action in Section 4.1, I need help understanding on the thinking to res= olve this TODO:

 = o  Parameter usage location: authorization request, token request
      [[TODO: draft-ietf-oauth-token= -exchange will have already
      = registered this for 'token request' and this draft has a more
      generalized usage and needs to somehow ei= ther update that
      registratio= n or do a partial registration and reference]]
&n= bsp; o  Change controller: IESG
  o&n= bsp; Specification document(s): [[ this specification ]]

My read of draft-ietf-oauth-token-excha= nge it that it defines 'resource' for 'token exchange'.  This draft (d= raft-ietf-oauth-resource-indicators) has guidance on 'resource' for 'author= ization request' but also additional guidance for 'token request'.  Is= the token guidance request stated here applicable to draft-ietf-oauth-toke= n-exchange too (i.e., is the text effectively saying oauth-resource-indicat= ors updates oauth-token-exhange)?  I ask because these drafts don't re= ference each other.

Co= rrect me because there is likely a history, but it seems the TODO is that t= here is a dependency to resolve and a need to coming up with a way to signa= l in the registry which draft should be read for what usage location. = Could draft-ietf-oauth-resource-indicators officially register 'resource';= and instead of draft-ietf-oauth-token-exchange including the text defining= 'resource' in Section 2.1, it would make a normative reference to Section = 2 of draft-ietf-oauth-resource-indicators?

Roman

> -----Original Message-----
> From: R= oman Danyliw
> Sent: Tuesday, July 16, 2019 7:= 23 PM
> Subject: AD Review: draft-ietf-oauth-resource-indicators-02
>
> Hi!
>
> The following is my AD rev= iew of draft-ietf-oauth-resource-indicators-02.
&= gt; The document is in good shape.
>
> (1) Section 2. Per "The parameter can carry the loca= tion of a protected
> resource, typically as a= n https URL, or a more abstract identifier", is this
> "abstract identifier" still an absolute URI per Section 4.3 of RFC= 3986?
>
> (2) Se= ction 2.2.  in the sentence "To the extent possible, when issuing acce= ss
> tokens, the authorization server should a= dapt the scope value associated
> with an acce= ss token to the value the respective resource is able to process
<= div dir=3D"ltr">> and needs to know":
>
> --  is this language suggesting that the = authorization server is modifying the
> scope = value based on the resource it sees?  I'm trying to understand what
> "adapt" means, especially in relation to the i= mproved security and privacy the
> subsequent = sentence suggests.
>
> -- (Depending on the above) Is there a security consideration here f= or the
> server relative to confidential scope= values and how they might be modified?
>
=
> (3) Editorial
> **= Section 1 and 2.1.  Multiple Typo.  s/the the/the/g
>
> ** Section 2.  Edit= orial. s/resource at which/resource to which/
>= ;
> ** Section 2.  Editorial.
<= div dir=3D"ltr">> s/ And can also be used to inform the client that it h= as requested an invalid
> combination of resou= rce and scope./ It can also be used to inform the client
> that it has requested an invalid combination of resource and = scope./
>
> ** S= ection 2.1. Multiple Typo. s/an an/an/g
>
=
> ** Section 2.2.  Editorial. s/token reques= t and response/token request
> (Figure 3) and = response (Figure 4)/
>
> ** Section 3.  Typo.  s/a invalid/an invalid/
<= div dir=3D"ltr">>
> ** Section 3.  Mi= ssing words.  "A bearer token that has multiple intended
> recipients (audiences) can be used by any one of those re= cipients at any
> other."  Is it protecte= d resource?


=

------------------------------<= br>

Message: 3
Date: Wed, 17 Jul 2019 22:04:49 +0000
From: Roman Danyliw <rdd@cert.org>
To: Brian C= ampbell <bcampbell@pingidentity.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD Review:
 &nbs= p;  draft-ietf-oauth-resource-indicators-02
= Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand>
Content-Type: text/plain; charset=3D"utf-8"

Hi Brian!

From: Brian Campbell [mailto:= bcampbell@pingidentity.com]
Sent: Wednesday, = July 17, 2019 4:35 PM
To: Roman Danyliw <rdd@cert.org= >
Su= bject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Thank you, Roman, for th= e review. Some replies are inline below. I'll aim to push out a -03 address= ing this stuff sometime not too long after the I-D submission embargo is li= fted next week.


On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>> wrote:
Hi!

The following is my AD review of d= raft-ietf-oauth-resource-indicators-02.  The document is in good shape= .

That's always nice t= o hear :-)


<= div dir=3D"ltr">(1) Section 2. Per "The parameter can carry the location of= a protected resource, typically as an https URL, or a more abstract identi= fier", is this "abstract identifier" still an absolute URI per Section 4.3 = of RFC3986?

Absolutely= (see what I did there? sigh...). Syntactically it's an absolute URI. Seman= tically, while it might be an actual network addressable location identifie= d by an HTTPS URL, it might also be a URN or something that more abstractly= indicates a resource or grouping of resources. But its format is an absolu= te URI regardless.

I'm= not sure what, if anything, can be added or changed here to help clarify. = But I'm happy to entertain suggestions, if you've got em and/or think somet= hing is needed.

[Roman= ] Understood.  Concur there is nothing to do here.


(2) Section = 2.2.  in the sentence "To the extent possible, when issuing access tok= ens, the authorization server should adapt the scope value associated with = an access token to the value the respective resource is able to process and= needs to know":

--&nb= sp; is this language suggesting that the authorization server is modifying = the scope value based on the resource it sees?  I'm trying to understa= nd what "adapt" means, especially in relation to the improved security and = privacy the subsequent sentence suggests.

Perhaps "adapt" wasn't the best choice of word but it's= meant to say that an authorization server with sufficient understanding of= what scopes are applicable to what resources (which won't always be the ca= se or even possible but sometimes) could limit the scope associated with an= access token (downscoping really) to only the scope that is applicable to = the resource.

Some of = the examples (figures 2 - 6) attempt to show, among other things, a hypothe= tical case of how this might go down.

<= div dir=3D"ltr">In Figure 2 the initial authorization request that's approv= ed has scope of calendar & contacts and resources https://contacts.example.com/ &= amp; https://cal.exa= mple.com/

A subseq= uent access token request (Figure 3) has resource https://cal.example.com/ and the issued = access token scope (Figure 4) is "adapted" to that resource to be only cale= ndar

Another subsequen= t access token request (Figure 5) has resource https://contacts.example.com/ and the = issued access token scope (Figure 6) is downscoped based on that resource t= o be only contacts

Wou= ld it be easier to understand if the word "downscope" was used rather than = "adapt"?

[Roman] Using= ?downscope? does work for me.  It captures that the server is going t= o reduce the scope (and certainly not expand it).


-- (Depending on the= above) Is there a security consideration here for the server relative to c= onfidential scope values and how they might be modified?

I'm not sure, to be honest. Downscoppin= g when possible and to the extent possible is usually a good idea (least pr= ivilege and all that) but I think maybe I'm missing your point/question.

[Roman] Yes, least privi= lege was part of it and I think the text above gets at it.  However, t= he other part is the relationship with the next sentence in the paragraph, = ?This further improves privacy as scope values give an indication of what s= ervices the resource owner uses and it improves security as scope values ma= y contain confidential data?.  If the initial request was notionally a= scope of ?all the houses on the block?, but the server knew that this requ= est was too broad and down-scoped to ?only the corner house?, wouldn?t this= actually be worse for privacy?  I also don?t follow how reducing the = scope impacts confidential data.


(3) Editorial
** Section 1 and 2.1.  Multiple Typo.  s/the the/the/g

Apparently I'm fond of the do= uble "the" and have a hard time spotting it myself. I think this is the sec= ond review in as many weeks that you've caught a few of those. Will fix.


** Section 2.  Editorial. s/resource at which/resource to which/

Okay.


** Section 2= .  Editorial.
s/ And can also be used to inf= orm the client that it has requested an invalid combination of resource and= scope./
        It can also = be used to inform the client that it has requested an invalid combination o= f resource and scope./

Yup.


** Section 2.1. Multiple Typo. s/an an/an/g

Again with the double words. Sigh. A doubl= e double even.



** Section 2.2.  Editor= ial. s/token request and response/token request (Figure 3) and response (Fi= gure 4)/

Makes sense.<= br>


** Section 3.  Typo.  s/a invalid/an invalid/

Of course.


** Section 3.  = Missing words.  "A bearer token that has multiple intended recipients = (audiences) can be used by any one of those recipients at any other." = Is it protected resource?

Well, those are all the words that I'd intended to be there :/ But it = does read a little curtly. How about the following instead?

"A bearer token that has multiple int= ended recipients (audiences) indicating that the token is valid at more tha= n one protected resource can be used by any one of those protected resource= s to access any of the other protected resources."

[Roman] Thanks for fixing all of these.


C= ONFIDENTIALITY NOTICE: This email may contain confidential and privileged m= aterial for the sole use of the intended recipient(s). Any review, use, dis= tribution or disclosure by others is strictly prohibited.  If you have= received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you.
-------------- next part ---------= -----
An HTML attachment was scrubbed...

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 129, Issue 23
*= *************************************
------=_Part_4070623_696090853.1563402719504-- From nobody Wed Jul 17 16:49: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 6B31A120170 for ; Wed, 17 Jul 2019 16:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 G_bVxLsoYPl9 for ; Wed, 17 Jul 2019 16:49:55 -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 251C3120173 for ; Wed, 17 Jul 2019 16:49:54 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HNnrQF025899; Wed, 17 Jul 2019 19:49:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6HNnrQF025899 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563407394; bh=CBPwLjyzl9PTh0EP//JLy+Dwm2zPrCO08jr0u5JCmMg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=J1PoyDiaK7SA2Pdnwm7kU41OUJX4Zu9JcdHx9pbSJTqqT54bvf2ECTykLIl4pwUKe lTER3Z48SAawXz65Q0BJeipSBL65lDIx6k2v/BjQfEH9Pp3B+TiPjpNzVVle6lTlbi iGuj5JCxbutjNTeoXOyPYG/X0v98BMDxPMhIhEjs= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6HNnoha021868; Wed, 17 Jul 2019 19:49:50 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 19:49:50 -0400 From: Roman Danyliw To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgAs5qCAAAwaLYAABpg1EA== Date: Wed, 17 Jul 2019 23:49:49 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D7BC9@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33D7BC9marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 23:49:59 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33D7BC9marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNClRoYW5rcyBmb3IgdGhpcyBiYWNrZ3JvdW5kIGFuZCBleHBsYW5hdGlvbi4g IFRoZXJlIHdhcyBoaXN0b3J5IGhlcmUgSSBkaWRu4oCZdCBrbm93Lg0KDQpXaXRoIHRoZSBiZW5l Zml0IG9mIHRoaXMgdGhyZWFkIGFuZCBwcml2YXRlIGV4Y2hhbmdlcywgdGhlIGtleSB0YWtlYXdh eXMgZm9yIG1lIGFyZToNCg0KKiogdGhlIGRlZmluaXRpb24gb2YgJ3Jlc291cmNlJyBmb3IgJ3Rv a2VuIGV4Y2hhbmdlJyBpcyBpZGVudGljYWwgaW4gYm90aCBkcmFmdHMgKGRyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9yIGFuZCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl KQ0KDQoqKiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgaGFzIGFkZGl0aW9u YWwg4oCcdXNlc+KAnSBvZiByZXNvdXJjZSBub3QgZ2VybWFuZSB0byBkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcg0KDQoqKiB0aGUgZGVzaXJlZCBlbmRzLXN0YXRlIGFmdGVyIHRo ZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb25zIG9mIGJvdGggZHJhZnRzIHdlcmUgcHJvY2Vz cywgdGhlIE9hdXRoIHJlZ2lzdHJ5IHdvdWxkIGxvb2sgYXMgZm9sbG93czoNCi0gbmFtZSA9IHJl c291cmNlDQotIHBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbiA9IGF1dGhvcml6YXRpb24gcmVxdWVz dCwgdG9rZW4gcmVxdWVzdA0KLSBjaGFuZ2UgY29udHJvbGxlciA9IElFVEYNCi0gcmVmZXJlbmNl ID0gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3INCg0KSXMgdGhhdCByaWdodD8N Cg0KSWYgdGhlIGFib3ZlIGlzIGNvcnJlY3QsIHdvdWxkIHRoZSBmb2xsb3dpbmcgd2F5IGFoZWFk IHdvcms6DQoNCioqIGZvciBkcmFmdC1pZXRmLW9hdXRoLXRva2VuIGV4Y2hhbmdlOiBOb3RoaW5n DQoNCioqIGZvciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcg0KDQpQZXIgU2Vj dGlvbiA0LjE6DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIHRoZSBmb2xsb3dpbmcg dmFsdWUgaW4gdGhlIElBTkEgIk9BdXRoDQogICBQYXJhbWV0ZXJzIiByZWdpc3RyeSBbSUFOQS5P QXV0aC5QYXJhbWV0ZXJzXSBlc3RhYmxpc2hlZCBieQ0KICAgW1JGQzY3NDldLg0KDQogICBvICBQ YXJhbWV0ZXIgbmFtZTogcmVzb3VyY2UNCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjog YXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0DQogICBvICBDaGFuZ2UgY29udHJv bGxlcjogSUVTRw0KICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBzcGVj aWZpY2F0aW9uIF1dDQoNClBlciBTZWN0aW9uIDQuMg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIHVw ZGF0ZXMgdGhlIGZvbGxvd2luZyBlcnJvciBpbiB0aGUgSUFOQSAiT0F1dGgNCiAgIEV4dGVuc2lv bnMgRXJyb3IgUmVnaXN0cnkiIFtJQU5BLk9BdXRoLlBhcmFtZXRlcnNdIGVzdGFibGlzaGVkIGJ5 DQogICBbUkZDNjc0OV0uDQoNCiAgIG8gIEVycm9yIG5hbWU6IGludmFsaWRfdGFyZ2V0DQogICBv ICBFcnJvciB1c2FnZSBsb2NhdGlvbjogaW1wbGljaXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2UsIHRv a2VuIGVycm9yDQogICAgICByZXNwb25zZQ0KICAgbyAgUmVsYXRlZCBwcm90b2NvbCBleHRlbnNp b246IHJlc291cmNlIHBhcmFtZXRlcg0KICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFU0cNCiAg IG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBdXQ0K DQpSb21hbg0KDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTkgNjozMSBQTQ0KVG86 IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcnMtMDINCg0KWWVhaCwgYXMgeW91IHN1cm1pc2VkLCB0aGVyZSBpcyBzb21lIGhpc3Rv cnkgYmVoaW5kIHRoaXMuIEJhc2ljYWxseSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl IHByZWRhdGVzIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBieSBhIGdvb2Qg bG9uZyB0aW1lICh5ZWFycykgYW5kIHdpdGggdGhlIGhvcGUgYW5kIGV4cGVjdGF0aW9uIHRoYXQg ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSB3b3VsZCBtb3ZlIHRvIFJGQywgSSd2ZSBh dm9pZGVkIGhhdmluZyBhIHJlZmVyZW5jZSBpbiBpdCB0byBhIGRyYWZ0IG11Y2ggZWFybGllciBh bG9uZyBpbiB0aGUgd2hvbGUgcHJvY2Vzcy4gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzIGhhcyBhIGJpdCBvZiBhbiBvZGQgaGlzdG9yeSB0b28gaW4gdGhhdCBhbiBpbml0aWFs IGNhbGwgZm9yIGFkb3B0aW9uIGFyb3VuZCB0aGUgQnVlbm9zIEFpcmVzIG1lZXRpbmcga2luZGEg Zml6emxlZCBvdXQgYW5kIGl0IHdhcyBsZWZ0IGZvciBkZWFkIHVudGlsIGJlaW5nIHVuZXhwZWN0 ZWQgcmVzdXJyZWN0ZWQgYXJvdW5kIE1vbnRyZWFsIGxhc3QgeWVhciBkdWUgdG8gcmVuZXdlZCBp bnRlcmVzdCBhbmQgb3RoZXIgZmFjdG9ycyBJJ20gc3RpbGwgbm90IHN1cmUgSSB1bmRlcnN0YW5k Lg0KDQpZb3UgYXJlIGNvcnJlY3QgdGhhdCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl IGRlZmluZXMgInJlc291cmNlIiBmb3IgdG9rZW4gZXhjaGFuZ2UuIEhvd2V2ZXIgdGhlIHJlZ2lz dHJ5IGl0c2VsZiBkb2Vzbid0IGhhdmUgdGhhdCBsZXZlbCBvZiBncmFudWxhcml0eS4gSXQgaGFz IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4gcmVx dWVzdCwgYW5kIHRva2VuIHJlc3BvbnNlIGFzIHRoZSBwb3NzaWJsZSBsb2NhdGlvbnMgZm9yIHBh cmFtZXRlciB1c2FnZS4gQSB0b2tlbiBleGNoYW5nZSByZXF1ZXN0IGlzIGEgcGFydGljdWxhciBr aW5kIG9mIHRva2VuIHJlcXVlc3Qgc28gZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBy ZWdpc3RlcnMgInJlc291cmNlIiBmb3IgdGhlIHRva2VuIHJlcXVlc3QgbG9jYXRpb24uIFRoZSBJ QU5BIHNlY3Rpb24gd2FzIHdyaXR0ZW4gYmVmb3JlIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycyBldmVuIGV4aXN0ZWQuIEFuZCBsZWF2aW5nIHRoZSByZWdpc3RyYXRpb24gaW4g ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBzZWVtZWQgbGlrZSB0aGUgcmlnaHQgdGhp bmcgdG8gZG8gdG8gZXZlbiBhZnRlciBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRv cnMgY2FtZSBhbG9uZy4gQnV0IEknbSBub3Qgc3VyZSwgdG8gYmUgaG9uZXN0LiBBbHNvIEZXSVcg YSB0ZW1wb3JhcnkgcmVnaXN0cmF0aW9uIGVudHJ5IGZvciBpdCBpcyBhbHJlYWR5IGluIGh0dHBz Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1l dGVycy54aHRtbCNwYXJhbWV0ZXJzDQoNCmRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9ycyBkZWZpbmVzICJyZXNvdXJjZSIgZm9yIHVzZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCAod2hpY2ggdG9rZW4gZXhjaGFuZ2UgZG9lcyBub3QpIHNvIHRoYXQncyB0aGUgaW1wZXR1 cyBiZWhpbmQgaGF2aW5nIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCB0aGVyZSBpbmNsdWRlIGF1 dGhvcml6YXRpb24gcmVxdWVzdCBpbiB0aGUgbG9jYXRpb24uIGRyYWZ0LWlldGYtb2F1dGgtcmVz b3VyY2UtaW5kaWNhdG9ycyBhbHNvIGhhcyAicmVzb3VyY2UiIGZvciB1c2UgYXQgdGhlIHRva2Vu IGVuZHBvaW50IHVzaW5nIHRoZSBzYW1lIHNlbWFudGljcyBhcyBpbiBkcmFmdC1pZXRmLW9hdXRo LXRva2VuLWV4Y2hhbmdlIGJ1dCBpbiBhIHdheSB0aGF0IGlzIGFwcGxpY2FibGUgdG8gYWxsIHR5 cGVzIG9mIHRva2VuIHJlcXVlc3RzIHRvIHRoZSB0aGUgdG9rZW4gZW5kcG9pbnQgYW5kIG5vdCBv bmx5IHRva2VuIGV4Y2hhbmdlIHJlcXVlc3RzLiBUaGF0J3Mgd2hlcmUgdGhlIGlkZWEgb2YgdXBk YXRpbmcgdGhlIHJlZ2lzdHJ5IGNhbWUgZnJvbSAtIGl0J3Mgbm90IGEgbmFtZSBjb2xsaXNpb24g YW5kIGl0J3Mgbm90IGEgZGlmZmVyZW50IGRlZmluaXRpb24gLSBpdCdzIGp1c3QgYSBtb3JlIGdl bmVyYWxpemVkIHVzYWdlLg0KDQpJIGhvcGUgdGhpcyBtYWtlcyBzb21lIHNlbnNlIGFuZCBoYXNu J3QgbXVkZGllZCB0aGUgd2F0ZXJzIG1vcmUuDQoNCg0KDQpPbiBXZWQsIEp1bCAxNywgMjAxOSBh dCAzOjEzIFBNIFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3Jn Pj4gd3JvdGU6DQpIaSENCg0KSSBmb3Jnb3Qgb25lIG1vcmUgdGhpbmcgYWJvdXQgdGhpcyBkcmFm dCBhZnRlciByZS1yZWFkaW5nIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UuDQoNClBl ciB0aGUgSUFOQSBhY3Rpb24gaW4gU2VjdGlvbiA0LjEsIEkgbmVlZCBoZWxwIHVuZGVyc3RhbmRp bmcgb24gdGhlIHRoaW5raW5nIHRvIHJlc29sdmUgdGhpcyBUT0RPOg0KDQogICBvICBQYXJhbWV0 ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdA0K ICAgICAgW1tUT0RPOiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHdpbGwgaGF2ZSBh bHJlYWR5DQogICAgICByZWdpc3RlcmVkIHRoaXMgZm9yICd0b2tlbiByZXF1ZXN0JyBhbmQgdGhp cyBkcmFmdCBoYXMgYSBtb3JlDQogICAgICBnZW5lcmFsaXplZCB1c2FnZSBhbmQgbmVlZHMgdG8g c29tZWhvdyBlaXRoZXIgdXBkYXRlIHRoYXQNCiAgICAgIHJlZ2lzdHJhdGlvbiBvciBkbyBhIHBh cnRpYWwgcmVnaXN0cmF0aW9uIGFuZCByZWZlcmVuY2VdXQ0KICAgbyAgQ2hhbmdlIGNvbnRyb2xs ZXI6IElFU0cNCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgc3BlY2lm aWNhdGlvbiBdXQ0KDQpNeSByZWFkIG9mIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2Ug aXQgdGhhdCBpdCBkZWZpbmVzICdyZXNvdXJjZScgZm9yICd0b2tlbiBleGNoYW5nZScuICBUaGlz IGRyYWZ0IChkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMpIGhhcyBndWlkYW5j ZSBvbiAncmVzb3VyY2UnIGZvciAnYXV0aG9yaXphdGlvbiByZXF1ZXN0JyBidXQgYWxzbyBhZGRp dGlvbmFsIGd1aWRhbmNlIGZvciAndG9rZW4gcmVxdWVzdCcuICBJcyB0aGUgdG9rZW4gZ3VpZGFu Y2UgcmVxdWVzdCBzdGF0ZWQgaGVyZSBhcHBsaWNhYmxlIHRvIGRyYWZ0LWlldGYtb2F1dGgtdG9r ZW4tZXhjaGFuZ2UgdG9vIChpLmUuLCBpcyB0aGUgdGV4dCBlZmZlY3RpdmVseSBzYXlpbmcgb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyB1cGRhdGVzIG9hdXRoLXRva2VuLWV4aGFuZ2UpPyAgSSBh c2sgYmVjYXVzZSB0aGVzZSBkcmFmdHMgZG9uJ3QgcmVmZXJlbmNlIGVhY2ggb3RoZXIuDQoNCkNv cnJlY3QgbWUgYmVjYXVzZSB0aGVyZSBpcyBsaWtlbHkgYSBoaXN0b3J5LCBidXQgaXQgc2VlbXMg dGhlIFRPRE8gaXMgdGhhdCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgdG8gcmVzb2x2ZSBhbmQgYSBu ZWVkIHRvIGNvbWluZyB1cCB3aXRoIGEgd2F5IHRvIHNpZ25hbCBpbiB0aGUgcmVnaXN0cnkgd2hp Y2ggZHJhZnQgc2hvdWxkIGJlIHJlYWQgZm9yIHdoYXQgdXNhZ2UgbG9jYXRpb24uICBDb3VsZCBk cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgb2ZmaWNpYWxseSByZWdpc3RlciAn cmVzb3VyY2UnOyBhbmQgaW5zdGVhZCBvZiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl IGluY2x1ZGluZyB0aGUgdGV4dCBkZWZpbmluZyAncmVzb3VyY2UnIGluIFNlY3Rpb24gMi4xLCBp dCB3b3VsZCBtYWtlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBTZWN0aW9uIDIgb2YgZHJhZnQt aWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzPw0KDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbWFuIERhbnlsaXcNCj4gU2VudDogVHVlc2RheSwg SnVseSAxNiwgMjAxOSA3OjIzIFBNDQo+IFRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyDQo+DQo+IEhpIQ0KPg0KPiBUaGUgZm9sbG93aW5nIGlzIG15IEFEIHJl dmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDIuDQo+IFRoZSBk b2N1bWVudCBpcyBpbiBnb29kIHNoYXBlLg0KPg0KPiAoMSkgU2VjdGlvbiAyLiBQZXIgIlRoZSBw YXJhbWV0ZXIgY2FuIGNhcnJ5IHRoZSBsb2NhdGlvbiBvZiBhIHByb3RlY3RlZA0KPiByZXNvdXJj ZSwgdHlwaWNhbGx5IGFzIGFuIGh0dHBzIFVSTCwgb3IgYSBtb3JlIGFic3RyYWN0IGlkZW50aWZp ZXIiLCBpcyB0aGlzDQo+ICJhYnN0cmFjdCBpZGVudGlmaWVyIiBzdGlsbCBhbiBhYnNvbHV0ZSBV UkkgcGVyIFNlY3Rpb24gNC4zIG9mIFJGQzM5ODY/DQo+DQo+ICgyKSBTZWN0aW9uIDIuMi4gIGlu IHRoZSBzZW50ZW5jZSAiVG8gdGhlIGV4dGVudCBwb3NzaWJsZSwgd2hlbiBpc3N1aW5nIGFjY2Vz cw0KPiB0b2tlbnMsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgYWRhcHQgdGhlIHNj b3BlIHZhbHVlIGFzc29jaWF0ZWQNCj4gd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHZhbHVl IHRoZSByZXNwZWN0aXZlIHJlc291cmNlIGlzIGFibGUgdG8gcHJvY2Vzcw0KPiBhbmQgbmVlZHMg dG8ga25vdyI6DQo+DQo+IC0tICBpcyB0aGlzIGxhbmd1YWdlIHN1Z2dlc3RpbmcgdGhhdCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgbW9kaWZ5aW5nIHRoZQ0KPiBzY29wZSB2YWx1ZSBiYXNl ZCBvbiB0aGUgcmVzb3VyY2UgaXQgc2Vlcz8gIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0 DQo+ICJhZGFwdCIgbWVhbnMsIGVzcGVjaWFsbHkgaW4gcmVsYXRpb24gdG8gdGhlIGltcHJvdmVk IHNlY3VyaXR5IGFuZCBwcml2YWN5IHRoZQ0KPiBzdWJzZXF1ZW50IHNlbnRlbmNlIHN1Z2dlc3Rz Lg0KPg0KPiAtLSAoRGVwZW5kaW5nIG9uIHRoZSBhYm92ZSkgSXMgdGhlcmUgYSBzZWN1cml0eSBj b25zaWRlcmF0aW9uIGhlcmUgZm9yIHRoZQ0KPiBzZXJ2ZXIgcmVsYXRpdmUgdG8gY29uZmlkZW50 aWFsIHNjb3BlIHZhbHVlcyBhbmQgaG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/DQo+DQo+ICgz KSBFZGl0b3JpYWwNCj4gKiogU2VjdGlvbiAxIGFuZCAyLjEuICBNdWx0aXBsZSBUeXBvLiAgcy90 aGUgdGhlL3RoZS9nDQo+DQo+ICoqIFNlY3Rpb24gMi4gIEVkaXRvcmlhbC4gcy9yZXNvdXJjZSBh dCB3aGljaC9yZXNvdXJjZSB0byB3aGljaC8NCj4NCj4gKiogU2VjdGlvbiAyLiAgRWRpdG9yaWFs Lg0KPiBzLyBBbmQgY2FuIGFsc28gYmUgdXNlZCB0byBpbmZvcm0gdGhlIGNsaWVudCB0aGF0IGl0 IGhhcyByZXF1ZXN0ZWQgYW4gaW52YWxpZA0KPiBjb21iaW5hdGlvbiBvZiByZXNvdXJjZSBhbmQg c2NvcGUuLyBJdCBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZm9ybSB0aGUgY2xpZW50DQo+IHRoYXQg aXQgaGFzIHJlcXVlc3RlZCBhbiBpbnZhbGlkIGNvbWJpbmF0aW9uIG9mIHJlc291cmNlIGFuZCBz Y29wZS4vDQo+DQo+ICoqIFNlY3Rpb24gMi4xLiBNdWx0aXBsZSBUeXBvLiBzL2FuIGFuL2FuL2cN Cj4NCj4gKiogU2VjdGlvbiAyLjIuICBFZGl0b3JpYWwuIHMvdG9rZW4gcmVxdWVzdCBhbmQgcmVz cG9uc2UvdG9rZW4gcmVxdWVzdA0KPiAoRmlndXJlIDMpIGFuZCByZXNwb25zZSAoRmlndXJlIDQp Lw0KPg0KPiAqKiBTZWN0aW9uIDMuICBUeXBvLiAgcy9hIGludmFsaWQvYW4gaW52YWxpZC8NCj4N Cj4gKiogU2VjdGlvbiAzLiAgTWlzc2luZyB3b3Jkcy4gICJBIGJlYXJlciB0b2tlbiB0aGF0IGhh cyBtdWx0aXBsZSBpbnRlbmRlZA0KPiByZWNpcGllbnRzIChhdWRpZW5jZXMpIGNhbiBiZSB1c2Vk IGJ5IGFueSBvbmUgb2YgdGhvc2UgcmVjaXBpZW50cyBhdCBhbnkNCj4gb3RoZXIuIiAgSXMgaXQg cHJvdGVjdGVkIHJlc291cmNlPw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBh bnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_359EC4B99E040048A7131E0F4E113AFC01B33D7BC9marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQnJpYW4hPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoaXMgYmFja2dyb3Vu ZCBhbmQgZXhwbGFuYXRpb24uJm5ic3A7IFRoZXJlIHdhcyBoaXN0b3J5IGhlcmUgSSBkaWRu4oCZ dCBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCB0 aGUgYmVuZWZpdCBvZiB0aGlzIHRocmVhZCBhbmQgcHJpdmF0ZSBleGNoYW5nZXMsIHRoZSBrZXkg dGFrZWF3YXlzIGZvciBtZSBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4qKiB0aGUgZGVmaW5pdGlvbiBvZiAncmVzb3VyY2UnIGZvciAndG9rZW4gZXhjaGFu Z2UnIGlzIGlkZW50aWNhbCBpbiBib3RoIGRyYWZ0cyAoZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3IgYW5kIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4qKiBkcmFmdC1pZXRmLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMgaGFzIGFkZGl0aW9uYWwg4oCcdXNlc+KAnSBvZiByZXNvdXJjZSBu b3QgZ2VybWFuZSB0byBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KiogdGhlIGRlc2lyZWQgZW5kcy1z dGF0ZSBhZnRlciB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBvZiBib3RoIGRyYWZ0 cyB3ZXJlIHByb2Nlc3MsIHRoZSBPYXV0aCByZWdpc3RyeSB3b3VsZCBsb29rIGFzIGZvbGxvd3M6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPi0gbmFtZSA9IHJlc291cmNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0g cGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uID08L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+YXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPi0gY2hhbmdlIGNvbnRyb2xsZXIgPSBJRVRGPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0gcmVm ZXJlbmNlID0gZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPklzIHRoYXQgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JZiB0aGUgYWJvdmUgaXMgY29ycmVjdCwgd291bGQgdGhlIGZvbGxvd2luZyB3YXkgYWhl YWQgd29yazo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPioqIGZv ciBkcmFmdC1pZXRmLW9hdXRoLXRva2VuIGV4Y2hhbmdlOiBOb3RoaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4qKiBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3INCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UGVyIFNlY3Rpb24gNC4xOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIHRoZSBmb2xsb3dp bmcgdmFsdWUgaW4gdGhlIElBTkEgJnF1b3Q7T0F1dGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IFBhcmFtZXRlcnMmcXVvdDsgcmVnaXN0cnkgW0lBTkEuT0F1dGguUGFyYW1ldGVyc10g ZXN0YWJsaXNoZWQgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFtSRkM2NzQ5XS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBv Jm5ic3A7IFBhcmFtZXRlciBuYW1lOiByZXNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgbyZuYnNwOyBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVx dWVzdCwgdG9rZW4gcmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbyZuYnNw OyBDaGFuZ2UgY29udHJvbGxlcjogSUVTRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg byZuYnNwOyBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIHNwZWNpZmljYXRpb24g XV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlciBTZWN0aW9u IDQuMg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgc3BlY2lmaWNh dGlvbiB1cGRhdGVzIHRoZSBmb2xsb3dpbmcgZXJyb3IgaW4gdGhlIElBTkEgJnF1b3Q7T0F1dGg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkm cXVvdDsgW0lBTkEuT0F1dGguUGFyYW1ldGVyc10gZXN0YWJsaXNoZWQgYnk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IFtSRkM2NzQ5XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEVycm9yIG5hbWU6IGludmFsaWRf dGFyZ2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEVycm9yIHVzYWdl IGxvY2F0aW9uOiBpbXBsaWNpdCBncmFudCBlcnJvciByZXNwb25zZSwgdG9rZW4gZXJyb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFJlbGF0ZWQgcHJvdG9jb2wgZXh0 ZW5zaW9uOiByZXNvdXJjZSBwYXJhbWV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IG8mbmJzcDsgQ2hhbmdlIGNvbnRyb2xsZXI6IElFU0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBzcGVjaWZp Y2F0aW9uIF1dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21h bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDY6MzEg UE08YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDs8YnI+ DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FV VEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAy PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ZZWFoLCBhcyB5b3Ugc3VybWlzZWQsIHRoZXJlIGlzIHNvbWUgaGlzdG9yeSBiZWhpbmQg dGhpcy4gQmFzaWNhbGx5IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgcHJlZGF0ZXMg ZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIGJ5IGEgZ29vZCBsb25nIHRpbWUg KHllYXJzKSBhbmQgd2l0aCB0aGUgaG9wZSBhbmQgZXhwZWN0YXRpb24gdGhhdCBkcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlDQogd291bGQgbW92ZSB0byBSRkMsIEkndmUgYXZvaWRlZCBo YXZpbmcgYSByZWZlcmVuY2UgaW4gaXQgdG8gYSBkcmFmdCBtdWNoIGVhcmxpZXIgYWxvbmcgaW4g dGhlIHdob2xlIHByb2Nlc3MuIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyBo YXMgYSBiaXQgb2YgYW4gb2RkIGhpc3RvcnkgdG9vIGluIHRoYXQgYW4gaW5pdGlhbCBjYWxsIGZv ciBhZG9wdGlvbiBhcm91bmQgdGhlIEJ1ZW5vcyBBaXJlcyBtZWV0aW5nIGtpbmRhIGZpenpsZWQN CiBvdXQgYW5kIGl0IHdhcyBsZWZ0IGZvciBkZWFkIHVudGlsIGJlaW5nIHVuZXhwZWN0ZWQgcmVz dXJyZWN0ZWQgYXJvdW5kIE1vbnRyZWFsIGxhc3QgeWVhciBkdWUgdG8gcmVuZXdlZCBpbnRlcmVz dCBhbmQgb3RoZXIgZmFjdG9ycyBJJ20gc3RpbGwgbm90IHN1cmUgSSB1bmRlcnN0YW5kLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z b3UgYXJlIGNvcnJlY3QgdGhhdCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGRlZmlu ZXMgJnF1b3Q7cmVzb3VyY2UmcXVvdDsgZm9yIHRva2VuIGV4Y2hhbmdlLiBIb3dldmVyIHRoZSBy ZWdpc3RyeSBpdHNlbGYgZG9lc24ndCBoYXZlIHRoYXQgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIEl0 IGhhcyBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2Vu IHJlcXVlc3QsIGFuZCB0b2tlbg0KIHJlc3BvbnNlIGFzIHRoZSBwb3NzaWJsZSBsb2NhdGlvbnMg Zm9yIHBhcmFtZXRlciB1c2FnZS4gQSB0b2tlbiBleGNoYW5nZSByZXF1ZXN0IGlzIGEgcGFydGlj dWxhciBraW5kIG9mIHRva2VuIHJlcXVlc3Qgc28gZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZSByZWdpc3RlcnMgJnF1b3Q7cmVzb3VyY2UmcXVvdDsgZm9yIHRoZSB0b2tlbiByZXF1ZXN0 IGxvY2F0aW9uLiBUaGUgSUFOQSBzZWN0aW9uIHdhcyB3cml0dGVuIGJlZm9yZSBkcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMNCiBldmVuIGV4aXN0ZWQuIEFuZCBsZWF2aW5nIHRo ZSByZWdpc3RyYXRpb24gaW4gZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBzZWVtZWQg bGlrZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gdG8gZXZlbiBhZnRlciBkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnMgY2FtZSBhbG9uZy4gQnV0IEknbSBub3Qgc3VyZSwgdG8gYmUg aG9uZXN0LiBBbHNvIEZXSVcgYSB0ZW1wb3JhcnkgcmVnaXN0cmF0aW9uIGVudHJ5IGZvciBpdCBp cw0KIGFscmVhZHkgaW4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv b2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhodG1sI3BhcmFtZXRlcnMiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFt ZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCNwYXJhbWV0ZXJzPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnMgZGVmaW5lcyAmcXVvdDtyZXNvdXJjZSZxdW90OyBmb3IgdXNl IGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50ICh3aGljaCB0b2tlbiBleGNoYW5nZSBkb2Vz IG5vdCkgc28gdGhhdCdzIHRoZSBpbXBldHVzIGJlaGluZCBoYXZpbmcgdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0IHRoZXJlIGluY2x1ZGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGluIHRoZSBsb2Nh dGlvbi4NCiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgYWxzbyBoYXMgJnF1 b3Q7cmVzb3VyY2UmcXVvdDsgZm9yIHVzZSBhdCB0aGUgdG9rZW4gZW5kcG9pbnQgdXNpbmcgdGhl IHNhbWUgc2VtYW50aWNzIGFzIGluIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgYnV0 IGluIGEgd2F5IHRoYXQgaXMgYXBwbGljYWJsZSB0byBhbGwgdHlwZXMgb2YgdG9rZW4gcmVxdWVz dHMgdG8gdGhlIHRoZSB0b2tlbiBlbmRwb2ludCBhbmQgbm90IG9ubHkgdG9rZW4NCiBleGNoYW5n ZSByZXF1ZXN0cy4gVGhhdCdzIHdoZXJlIHRoZSBpZGVhIG9mIHVwZGF0aW5nIHRoZSByZWdpc3Ry eSBjYW1lIGZyb20gLSBpdCdzIG5vdCBhIG5hbWUgY29sbGlzaW9uIGFuZCBpdCdzIG5vdCBhIGRp ZmZlcmVudCBkZWZpbml0aW9uIC0gaXQncyBqdXN0IGEgbW9yZSBnZW5lcmFsaXplZCB1c2FnZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo b3BlIHRoaXMgbWFrZXMgc29tZSBzZW5zZSBhbmQgaGFzbid0IG11ZGRpZWQgdGhlIHdhdGVycyBt b3JlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEp1bCAxNywgMjAxOSBhdCAzOjEzIFBNIFJvbWFuIERhbnlsaXcgJmx0 OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj5yZGRAY2VydC5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpITxicj4NCjxicj4NCkkgZm9yZ290IG9uZSBtb3JlIHRoaW5n IGFib3V0IHRoaXMgZHJhZnQgYWZ0ZXIgcmUtcmVhZGluZyBkcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWV4Y2hhbmdlLjxicj4NCjxicj4NClBlciB0aGUgSUFOQSBhY3Rpb24gaW4gU2VjdGlvbiA0LjEs IEkgbmVlZCBoZWxwIHVuZGVyc3RhbmRpbmcgb24gdGhlIHRoaW5raW5nIHRvIHJlc29sdmUgdGhp cyBUT0RPOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvJm5ic3A7IFBhcmFtZXRlciB1c2FnZSBs b2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgW1tUT0RPOiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHdp bGwgaGF2ZSBhbHJlYWR5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVnaXN0ZXJlZCB0aGlz IGZvciAndG9rZW4gcmVxdWVzdCcgYW5kIHRoaXMgZHJhZnQgaGFzIGEgbW9yZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGdlbmVyYWxpemVkIHVzYWdlIGFuZCBuZWVkcyB0byBzb21laG93IGVp dGhlciB1cGRhdGUgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZ2lzdHJhdGlvbiBv ciBkbyBhIHBhcnRpYWwgcmVnaXN0cmF0aW9uIGFuZCByZWZlcmVuY2VdXTxicj4NCiZuYnNwOyAm bmJzcDtvJm5ic3A7IENoYW5nZSBjb250cm9sbGVyOiBJRVNHPGJyPg0KJm5ic3A7ICZuYnNwO28m bmJzcDsgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBzcGVjaWZpY2F0aW9uIF1d PGJyPg0KPGJyPg0KTXkgcmVhZCBvZiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGl0 IHRoYXQgaXQgZGVmaW5lcyAncmVzb3VyY2UnIGZvciAndG9rZW4gZXhjaGFuZ2UnLiZuYnNwOyBU aGlzIGRyYWZ0IChkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMpIGhhcyBndWlk YW5jZSBvbiAncmVzb3VyY2UnIGZvciAnYXV0aG9yaXphdGlvbiByZXF1ZXN0JyBidXQgYWxzbyBh ZGRpdGlvbmFsIGd1aWRhbmNlIGZvciAndG9rZW4gcmVxdWVzdCcuJm5ic3A7IElzIHRoZQ0KIHRv a2VuIGd1aWRhbmNlIHJlcXVlc3Qgc3RhdGVkIGhlcmUgYXBwbGljYWJsZSB0byBkcmFmdC1pZXRm LW9hdXRoLXRva2VuLWV4Y2hhbmdlIHRvbyAoaS5lLiwgaXMgdGhlIHRleHQgZWZmZWN0aXZlbHkg c2F5aW5nIG9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgdXBkYXRlcyBvYXV0aC10b2tlbi1leGhh bmdlKT8mbmJzcDsgSSBhc2sgYmVjYXVzZSB0aGVzZSBkcmFmdHMgZG9uJ3QgcmVmZXJlbmNlIGVh Y2ggb3RoZXIuPGJyPg0KPGJyPg0KQ29ycmVjdCBtZSBiZWNhdXNlIHRoZXJlIGlzIGxpa2VseSBh IGhpc3RvcnksIGJ1dCBpdCBzZWVtcyB0aGUgVE9ETyBpcyB0aGF0IHRoZXJlIGlzIGEgZGVwZW5k ZW5jeSB0byByZXNvbHZlIGFuZCBhIG5lZWQgdG8gY29taW5nIHVwIHdpdGggYSB3YXkgdG8gc2ln bmFsIGluIHRoZSByZWdpc3RyeSB3aGljaCBkcmFmdCBzaG91bGQgYmUgcmVhZCBmb3Igd2hhdCB1 c2FnZSBsb2NhdGlvbi4mbmJzcDsgQ291bGQgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzDQogb2ZmaWNpYWxseSByZWdpc3RlciAncmVzb3VyY2UnOyBhbmQgaW5zdGVhZCBvZiBk cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGluY2x1ZGluZyB0aGUgdGV4dCBkZWZpbmlu ZyAncmVzb3VyY2UnIGluIFNlY3Rpb24gMi4xLCBpdCB3b3VsZCBtYWtlIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSB0byBTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0 b3JzPzxicj4NCjxicj4NClJvbWFuPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsgRnJvbTogUm9tYW4gRGFueWxpdzxicj4NCiZndDsgU2VudDogVHVl c2RheSwgSnVseSAxNiwgMjAxOSA3OjIzIFBNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyBTdWJqZWN0OiBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9ycy0wMjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSE8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhl IGZvbGxvd2luZyBpcyBteSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1p bmRpY2F0b3JzLTAyLjxicj4NCiZndDsgVGhlIGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICgxKSBTZWN0aW9uIDIuIFBlciAmcXVvdDtUaGUgcGFyYW1ldGVy IGNhbiBjYXJyeSB0aGUgbG9jYXRpb24gb2YgYSBwcm90ZWN0ZWQ8YnI+DQomZ3Q7IHJlc291cmNl LCB0eXBpY2FsbHkgYXMgYW4gaHR0cHMgVVJMLCBvciBhIG1vcmUgYWJzdHJhY3QgaWRlbnRpZmll ciZxdW90OywgaXMgdGhpczxicj4NCiZndDsgJnF1b3Q7YWJzdHJhY3QgaWRlbnRpZmllciZxdW90 OyBzdGlsbCBhbiBhYnNvbHV0ZSBVUkkgcGVyIFNlY3Rpb24gNC4zIG9mIFJGQzM5ODY/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICgyKSBTZWN0aW9uIDIuMi4mbmJzcDsgaW4gdGhlIHNlbnRlbmNlICZx dW90O1RvIHRoZSBleHRlbnQgcG9zc2libGUsIHdoZW4gaXNzdWluZyBhY2Nlc3M8YnI+DQomZ3Q7 IHRva2VucywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBhZGFwdCB0aGUgc2NvcGUg dmFsdWUgYXNzb2NpYXRlZDxicj4NCiZndDsgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHZh bHVlIHRoZSByZXNwZWN0aXZlIHJlc291cmNlIGlzIGFibGUgdG8gcHJvY2Vzczxicj4NCiZndDsg YW5kIG5lZWRzIHRvIGtub3cmcXVvdDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tJm5ic3A7IGlz IHRoaXMgbGFuZ3VhZ2Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBp cyBtb2RpZnlpbmcgdGhlPGJyPg0KJmd0OyBzY29wZSB2YWx1ZSBiYXNlZCBvbiB0aGUgcmVzb3Vy Y2UgaXQgc2Vlcz8mbmJzcDsgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQ8YnI+DQomZ3Q7 ICZxdW90O2FkYXB0JnF1b3Q7IG1lYW5zLCBlc3BlY2lhbGx5IGluIHJlbGF0aW9uIHRvIHRoZSBp bXByb3ZlZCBzZWN1cml0eSBhbmQgcHJpdmFjeSB0aGU8YnI+DQomZ3Q7IHN1YnNlcXVlbnQgc2Vu dGVuY2Ugc3VnZ2VzdHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIChEZXBlbmRpbmcgb24gdGhl IGFib3ZlKSBJcyB0aGVyZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gaGVyZSBmb3IgdGhlPGJy Pg0KJmd0OyBzZXJ2ZXIgcmVsYXRpdmUgdG8gY29uZmlkZW50aWFsIHNjb3BlIHZhbHVlcyBhbmQg aG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICgzKSBFZGl0 b3JpYWw8YnI+DQomZ3Q7ICoqIFNlY3Rpb24gMSBhbmQgMi4xLiZuYnNwOyBNdWx0aXBsZSBUeXBv LiZuYnNwOyBzL3RoZSB0aGUvdGhlL2c8YnI+DQomZ3Q7IDxicj4NCiZndDsgKiogU2VjdGlvbiAy LiZuYnNwOyBFZGl0b3JpYWwuIHMvcmVzb3VyY2UgYXQgd2hpY2gvcmVzb3VyY2UgdG8gd2hpY2gv PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICoqIFNlY3Rpb24gMi4mbmJzcDsgRWRpdG9yaWFsLjxicj4N CiZndDsgcy8gQW5kIGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgdGhhdCBp dCBoYXMgcmVxdWVzdGVkIGFuIGludmFsaWQ8YnI+DQomZ3Q7IGNvbWJpbmF0aW9uIG9mIHJlc291 cmNlIGFuZCBzY29wZS4vIEl0IGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQ8 YnI+DQomZ3Q7IHRoYXQgaXQgaGFzIHJlcXVlc3RlZCBhbiBpbnZhbGlkIGNvbWJpbmF0aW9uIG9m IHJlc291cmNlIGFuZCBzY29wZS4vPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICoqIFNlY3Rpb24gMi4x LiBNdWx0aXBsZSBUeXBvLiBzL2FuIGFuL2FuL2c8YnI+DQomZ3Q7IDxicj4NCiZndDsgKiogU2Vj dGlvbiAyLjIuJm5ic3A7IEVkaXRvcmlhbC4gcy90b2tlbiByZXF1ZXN0IGFuZCByZXNwb25zZS90 b2tlbiByZXF1ZXN0PGJyPg0KJmd0OyAoRmlndXJlIDMpIGFuZCByZXNwb25zZSAoRmlndXJlIDQp Lzxicj4NCiZndDsgPGJyPg0KJmd0OyAqKiBTZWN0aW9uIDMuJm5ic3A7IFR5cG8uJm5ic3A7IHMv YSBpbnZhbGlkL2FuIGludmFsaWQvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICoqIFNlY3Rpb24gMy4m bmJzcDsgTWlzc2luZyB3b3Jkcy4mbmJzcDsgJnF1b3Q7QSBiZWFyZXIgdG9rZW4gdGhhdCBoYXMg bXVsdGlwbGUgaW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lwaWVudHMgKGF1ZGllbmNlcykgY2FuIGJl IHVzZWQgYnkgYW55IG9uZSBvZiB0aG9zZSByZWNpcGllbnRzIGF0IGFueTxicj4NCiZndDsgb3Ro ZXIuJnF1b3Q7Jm5ic3A7IElzIGl0IHByb3RlY3RlZCByZXNvdXJjZT88YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33D7BC9marchand_-- From nobody Thu Jul 18 14:06:18 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 24A96120047; Thu, 18 Jul 2019 14:06:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-oauth-token-exchange@ietf.org, Hannes Tschofenig , Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2019 14:06:10 -0700 Archived-At: Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 21:06:10 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-token-exchange-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have comments below, a couple of which might have been DISCUSS except that there have been enough eyes on this and enough DISCUSSes already, and I trust the authors and responsible AD to do the right thing. So I’ve divided the comments between “higher importance†and “purely editorialâ€. Of higher importance: — Section 1.1 — Given the extensive discussion of impersonation here, what strikes me as missing is pointing out that impersonation here is still controlled, that “A is B†but only to the extent that’s allowed by the token. First, it might be limited by number of instances (one transaction only), by time of day (only for 10 minutes), and by scope (in regard to B’s address book, but not B’s email). Second, there is accountability: audit information still shows that the token authorized acting as B. Is that not worth clarifying? — Section 8.2 — RFC 8174 needs to be normative, along with 2119. — Section 2.2.2 — If the authorization server is unwilling or unable to issue a token for all the target services indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. I always trip when I read “all†in a context like this. I think you mean “anyâ€, because you have “a tokenâ€. You could arguably make it “tokens†and leave “allâ€, but I think changing to “any†is clearer: NEW If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response and no tokens are returned. END The danger with “all†is having a reader interpret the error as only occurring when the server fails *all* services, and thinking that failing one out of three still constitutes success. I have seen this be an issue often (not with OAuth, but in general). If you want to be absolutely clear you could even add to the end, “A request is successful only when all requested tokens are issued.†— Section 5 — In addition, both delegation and impersonation introduce unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is a concern. The use of the "scope" claim is suggested to mitigate potential for such abuse, as it restricts the contexts in which the delegated rights can be exercised. I’m ambivalent here: is it worth also mentioning limiting the time a token is valid and possibly make it a one-time-use token? Or is it that that’s adequately covered in the other references and shouldn’t be repeated here? Also, is it worth referring (not copying) here to the advice in section 2.1 about the importance of authentication? — Section 6 — Should “TLS†here have a citation and normative reference? ===== Purely editorial: — Section 1 — An OAuth resource server, for example, might assume the role of the client during token exchange in order to trade an access token, which it received in a protected resource request, for a new token that is appropriate to include in a call to a backend service. A suggestion: I think this would work better using a restrictive clause, rather than a non-restrictive one. NEW An OAuth resource server, for example, might assume the role of the client during token exchange in order to trade an access token that it received in a protected resource request for a new token that is appropriate to include in a call to a backend service. END The scope of this specification is limited to the definition of a basic request and response protocol for an STS-style token exchange There should be hyphens in “request-and-reaponse protocol†(compound modifier). — Sections 4.1 and 4.4 — Section 4.1 says this: Consequently, non- identity claims (e.g., "exp", "nbf", and "aud") are not meaningful when used within an "act" claim, and therefore must not be used. Section 4.4 says this: Consequently, claims such as "exp", "nbf", and "aud" are not meaningful when used within a "may_act" claim, and therefore should not be used. I agree that neither of these should be BCP 14 key words, but I still think that being consistent is important, and I urge you to make them the same: both “must not be used†or both “should not be used†(or perhaps both “are not usedâ€). (I did not review the appendices.) From nobody Thu Jul 18 14:13: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 9A7EF120071; Thu, 18 Jul 2019 14:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keqpyChFKtAM; Thu, 18 Jul 2019 14:13:11 -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 12020120047; Thu, 18 Jul 2019 14:13:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6ILD1PP018457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jul 2019 17:13:04 -0400 Date: Thu, 18 Jul 2019 16:13:01 -0500 From: Benjamin Kaduk To: Barry Leiba Cc: The IESG , Hannes Tschofenig , oauth@ietf.org, rifaat.ietf@gmail.com, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Message-ID: <20190718211300.GK83144@kduck.mit.edu> References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 21:13:14 -0000 Just on one point... On Thu, Jul 18, 2019 at 02:06:10PM -0700, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have comments below, a couple of which might have been DISCUSS except that > there have been enough eyes on this and enough DISCUSSes already, and I trust > the authors and responsible AD to do the right thing. So I’ve divided the > comments between “higher importance†and “purely editorialâ€. > > Of higher importance: > > — Section 1.1 — > Given the extensive discussion of impersonation here, what strikes me as > missing is pointing out that impersonation here is still controlled, that “A is > B†but only to the extent that’s allowed by the token. First, it might be > limited by number of instances (one transaction only), by time of day (only for > 10 minutes), and by scope (in regard to B’s address book, but not B’s email). > Second, there is accountability: audit information still shows that the token > authorized acting as B. Is that not worth clarifying? > > — Section 8.2 — > RFC 8174 needs to be normative, along with 2119. > > — Section 2.2.2 — > > If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response. > > I always trip when I read “all†in a context like this. I think you mean > “anyâ€, because you have “a tokenâ€. You could arguably make it “tokens†and > leave “allâ€, but I think changing to “any†is clearer: > > NEW > If the authorization server is unwilling or unable to issue a token > for any target service indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response and no tokens are returned. > END > > The danger with “all†is having a reader interpret the error as only occurring > when the server fails *all* services, and thinking that failing one out of > three still constitutes success. I have seen this be an issue often (not with > OAuth, but in general). If you want to be absolutely clear you could even add > to the end, “A request is successful only when all requested tokens are issued.†I think I was reading this as "if the server can't fulfil the exact request as given, it returns an error and says "try again slightly differently". -Ben > — Section 5 — > > In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scope" claim is suggested to mitigate potential for such abuse, > as it restricts the contexts in which the delegated rights can be > exercised. > > I’m ambivalent here: is it worth also mentioning limiting the time a token is > valid and possibly make it a one-time-use token? Or is it that that’s > adequately covered in the other references and shouldn’t be repeated here? > > Also, is it worth referring (not copying) here to the advice in section 2.1 > about the importance of authentication? > > — Section 6 — > Should “TLS†here have a citation and normative reference? > > ===== > > Purely editorial: > > — Section 1 — > > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token, which it received in a protected resource request, for > a new token that is appropriate to include in a call to a backend > service. > > A suggestion: I think this would work better using a restrictive clause, rather > than a non-restrictive one. > > NEW > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token that it received in a protected resource request for > a new token that is appropriate to include in a call to a backend > service. > END > > The scope of this specification is limited to the definition of a > basic request and response protocol for an STS-style token exchange > > There should be hyphens in “request-and-reaponse protocol†(compound modifier). > > — Sections 4.1 and 4.4 — > > Section 4.1 says this: > Consequently, non- > identity claims (e.g., "exp", "nbf", and "aud") are not meaningful > when used within an "act" claim, and therefore must not be used. > > Section 4.4 says this: > Consequently, > claims such as "exp", "nbf", and "aud" are not meaningful when used > within a "may_act" claim, and therefore should not be used. > > I agree that neither of these should be BCP 14 key words, but I still think > that being consistent is important, and I urge you to make them the same: both > “must not be used†or both “should not be used†(or perhaps both “are not > usedâ€). > > (I did not review the appendices.) > > From nobody Thu Jul 18 14:16: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 1DF7A120047; Thu, 18 Jul 2019 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCKDhFAtqARU; Thu, 18 Jul 2019 14:15:59 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147331200C4; Thu, 18 Jul 2019 14:15:59 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id j5so49813067ioj.8; Thu, 18 Jul 2019 14:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Z7Oo312DlGb+Y4QJEoN7o8SQLLXPFDu/a35NMnP0n4=; b=ZatwGp2cPpx9B59+ke6t2K4h9Dsw4t0BvBtfNZ7hzAaibfCHqNW16QY2KzvEzNq79V IyXKsE6akCBTcXYWcXWqOJd8bGCONxuZlmZPv9RBoytGudnhK7vttYYNn6dCFKSwmagI Ush9IoUqSsRz+flnA1MwAA7IZrUZACurgqBHHJ7/9oXyg8vuNf1oaENREqrDYQ8KT41H HAy6qVjuC9kwACttyeubN/fayH+Q2HeU9WMnmo0eYHBU/16AIuXBqH9iga1wK0eYpAgk 6YcGN5c5hskWV+S0nTyv/Zy1AoUd8GpPLICBbIlbdZCnUmJoaqKQgzo+L6EJI8NbY4Yz VDIg== X-Gm-Message-State: APjAAAXW0GlOM/skBsqjDgEgWjyss9BCKf2Jy1IH0sdWZhbsSl1FpYVC cMsbRkvH5UUVpP7HGckJVczTzqRS780t7UMff54= X-Google-Smtp-Source: APXvYqyJWDRr/GaqwBOKY5tj3DWsapSe/tSMT1owiKkrIXa/u5ZQ5sgpTsIovJkAXdTpbHL/Yi2ZnsLU++fDdkNK4Os= X-Received: by 2002:a6b:fb0f:: with SMTP id h15mr46014163iog.266.1563484558192; Thu, 18 Jul 2019 14:15:58 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> <20190718211300.GK83144@kduck.mit.edu> In-Reply-To: <20190718211300.GK83144@kduck.mit.edu> From: Barry Leiba Date: Thu, 18 Jul 2019 17:15:47 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , Hannes Tschofenig , oauth WG , Rifaat Shekh-Yusef , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 21:16:00 -0000 > I think I was reading this as "if the server can't fulfil the exact request > as given, it returns an error and says "try again slightly differently". Yes, I'm sure that's what's meant. I'm asking that that be clarified, because I have seen problems in implementation of other specifications when that wasn't crystal clear. Barry From nobody Thu Jul 18 17:11:34 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 EB0FB12011D for ; Thu, 18 Jul 2019 17:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=xmlgrrl-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 AkAx_6Vtrwy6 for ; Thu, 18 Jul 2019 17:11:23 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799AC12011A for ; Thu, 18 Jul 2019 17:11:21 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id z23so2640278ote.13 for ; Thu, 18 Jul 2019 17:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xmlgrrl-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQnPU8twK07nX4SQk7KlHQgf2XzwRpQZbjsXwKev/IY=; b=oTeLuGsZV7qyGT144RxAIC5dvvFLoDtwUXK6Y5dLHDRzQpBYfUeXx8HChjZOPh8uom wCKwyR0qG9qntVM44xrT8U11kc4lTraMMVQwTQDvLZkRhXELGN3i0kfFNp62r8qGha1y D8z+qEulmPOcbA0KKT4YmSjkLf/1uOqfrig6tFhv34pZRqewUJXaRTCZbuayvpRPTOx4 3UU6kqcqfwuFGSs8g8J48NT/MUpacbWd2jxmYGgJ+f+puv4RW26x7FywoJYUH8BiN/v9 AxC6I44CSCBZa4pbMTD4I9FeUfKNU8WzHGm6NVtPTPhNgyD8ipVq6tXtIfl2aykll271 M/hA== 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=CQnPU8twK07nX4SQk7KlHQgf2XzwRpQZbjsXwKev/IY=; b=bSrXwXnlg4hdoDbDqHWa+8zqvu5+TyNILGm+kPMUkg13WqzMUGvYhS0l1fzKmPW00U nlUD6hgQ1ic0f++6Ury7aljOacCq+Sa8i/UQfJMuBtvzIpNa9YybjNwMwwgbVamK+QYB r+7LWZVerOj2NNhH/43dv6phYCaWr/4LpNUwcb8wyk4hLcMvpCB2UYmvcSBd8Iay85Ym ht0qbKAeZBNieetl6uZOW7uCqKGbRyjPNytJ6kDR1Bpux1frPv8x9YeqbPkXRPc2ZPrh GdfmtW/hZxAYLTC5S2oZLoqCCS6+cHhOUSQ8Ps3qYiG2jUALG9584pNPc5gohos6K+Bs OZ3w== X-Gm-Message-State: APjAAAWJYqWWA8z0oQWR1D4485PoAtRmF18OdrdBhbJDRophghRh2cD/ INVM5AU4bQkMuSw5IlnEbwk= X-Google-Smtp-Source: APXvYqz0YMwZ7VgA+WUyuOmLsZGF7t7Mw83ykcrqnpfpwPJX4xwi3te7lBoUGNIoM5LkbEID+902Cw== X-Received: by 2002:a05:6830:164e:: with SMTP id h14mr19953617otr.186.1563495080762; Thu, 18 Jul 2019 17:11:20 -0700 (PDT) Received: from [192.168.168.118] ([47.188.75.171]) by smtp.gmail.com with ESMTPSA id k24sm8991616oic.29.2019.07.18.17.11.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 17:11:20 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-046D78E1-C507-4A0E-9A54-B70FDA67FA2D Mime-Version: 1.0 (1.0) From: Eve Maler X-Mailer: iPad Mail (16F203) In-Reply-To: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2019 19:11:19 -0500 Cc: The IESG , oauth@ietf.org, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> To: Barry Leiba Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 00:11:26 -0000 --Apple-Mail-046D78E1-C507-4A0E-9A54-B70FDA67FA2D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding your =E2=80=9Chigher importance=E2=80=9D comment on Section 1.1 ab= out the impersonation semantic below: Eve Maler (sent from my iPad) | cell +1 425 345 6756 > On Jul 18, 2019, at 4:06 PM, Barry Leiba via Datatracker wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I have comments below, a couple of which might have been DISCUSS except th= at > there have been enough eyes on this and enough DISCUSSes already, and I tr= ust > the authors and responsible AD to do the right thing. So I=E2=80=99ve div= ided the > comments between =E2=80=9Chigher importance=E2=80=9D and =E2=80=9Cpurely e= ditorial=E2=80=9D. >=20 > Of higher importance: >=20 > =E2=80=94 Section 1.1 =E2=80=94 > Given the extensive discussion of impersonation here, what strikes me as > missing is pointing out that impersonation here is still controlled, that =E2= =80=9CA is > B=E2=80=9D but only to the extent that=E2=80=99s allowed by the token. Fi= rst, it might be > limited by number of instances (one transaction only), by time of day (onl= y for > 10 minutes), and by scope (in regard to B=E2=80=99s address book, but not B= =E2=80=99s email).=20 > Second, there is accountability: audit information still shows that the to= ken > authorized acting as B. Is that not worth clarifying? I=E2=80=99ve always been troubled by the same thing. A and B are, in fact, d= istinguishable (contra =E2=80=9CA ... is indistinguishable from B in that co= ntext=E2=80=9D). What i think is meant by impersonation is that A acts in B=E2= =80=99s identity context while using the access it has been delegated, rathe= r than its own context =E2=80=94 whatever the extent of this access, great o= r small. >=20 > =E2=80=94 Section 8.2 =E2=80=94 > RFC 8174 needs to be normative, along with 2119. >=20 > =E2=80=94 Section 2.2.2 =E2=80=94 >=20 > If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response. >=20 > I always trip when I read =E2=80=9Call=E2=80=9D in a context like this. I= think you mean > =E2=80=9Cany=E2=80=9D, because you have =E2=80=9Ca token=E2=80=9D. You co= uld arguably make it =E2=80=9Ctokens=E2=80=9D and > leave =E2=80=9Call=E2=80=9D, but I think changing to =E2=80=9Cany=E2=80=9D= is clearer: >=20 > NEW > If the authorization server is unwilling or unable to issue a token > for any target service indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response and no tokens are returned. > END >=20 > The danger with =E2=80=9Call=E2=80=9D is having a reader interpret the err= or as only occurring > when the server fails *all* services, and thinking that failing one out of= > three still constitutes success. I have seen this be an issue often (not w= ith > OAuth, but in general). If you want to be absolutely clear you could even= add > to the end, =E2=80=9CA request is successful only when all requested token= s are issued.=E2=80=9D >=20 > =E2=80=94 Section 5 =E2=80=94 >=20 > In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scope" claim is suggested to mitigate potential for such abuse, > as it restricts the contexts in which the delegated rights can be > exercised. >=20 > I=E2=80=99m ambivalent here: is it worth also mentioning limiting the time= a token is > valid and possibly make it a one-time-use token? Or is it that that=E2=80= =99s > adequately covered in the other references and shouldn=E2=80=99t be repeat= ed here? >=20 > Also, is it worth referring (not copying) here to the advice in section 2.= 1 > about the importance of authentication? >=20 > =E2=80=94 Section 6 =E2=80=94 > Should =E2=80=9CTLS=E2=80=9D here have a citation and normative reference?= >=20 > =3D=3D=3D=3D=3D >=20 > Purely editorial: >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token, which it received in a protected resource request, for > a new token that is appropriate to include in a call to a backend > service. >=20 > A suggestion: I think this would work better using a restrictive clause, r= ather > than a non-restrictive one. >=20 > NEW > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token that it received in a protected resource request for > a new token that is appropriate to include in a call to a backend > service. > END >=20 > The scope of this specification is limited to the definition of a > basic request and response protocol for an STS-style token exchange >=20 > There should be hyphens in =E2=80=9Crequest-and-reaponse protocol=E2=80=9D= (compound modifier). >=20 > =E2=80=94 Sections 4.1 and 4.4 =E2=80=94 >=20 > Section 4.1 says this: > Consequently, non- > identity claims (e.g., "exp", "nbf", and "aud") are not meaningful > when used within an "act" claim, and therefore must not be used. >=20 > Section 4.4 says this: > Consequently, > claims such as "exp", "nbf", and "aud" are not meaningful when used > within a "may_act" claim, and therefore should not be used. >=20 > I agree that neither of these should be BCP 14 key words, but I still thin= k > that being consistent is important, and I urge you to make them the same: b= oth > =E2=80=9Cmust not be used=E2=80=9D or both =E2=80=9Cshould not be used=E2=80= =9D (or perhaps both =E2=80=9Care not > used=E2=80=9D). >=20 > (I did not review the appendices.) >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-046D78E1-C507-4A0E-9A54-B70FDA67FA2D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding your =E2=80=9Chigher importance=E2=80=9D comment on S= ection 1.1 about the impersonation semantic below:

Eve Ma= ler (sent from my iPad) | cell += 1 425 345 6756

On Jul 18, 2019, at 4:= 06 PM, Barry Leiba via Datatracker <n= oreply@ietf.org> wrote:

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-token-exchange-18: No Objection

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


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

=
The document, along with other ballot positions, can b= e found here:
https://datatracker.ietf.org/doc/draft-ietf-= oauth-token-exchange/


=
-----------------------------------------------------------= -----------
COMMENT:
-----------------------= -----------------------------------------------

<= span>I have comments below, a couple of which might have been DISCUSS except= that
there have been enough eyes on this and enough DISCUSS= es already, and I trust
the authors and responsible AD to do= the right thing.  So I=E2=80=99ve divided the
comments= between =E2=80=9Chigher importance=E2=80=9D and =E2=80=9Cpurely editorial=E2= =80=9D.

Of higher importance:

=E2=80=94 Section 1.1 =E2=80=94
Given th= e extensive discussion of impersonation here, what strikes me as
<= span>missing is pointing out that impersonation here is still controlled, th= at =E2=80=9CA is
B=E2=80=9D but only to the extent that=E2=80= =99s allowed by the token.  First, it might be
limited b= y number of instances (one transaction only), by time of day (only for
10 minutes), and by scope (in regard to B=E2=80=99s address book,= but not B=E2=80=99s email).
Second, there is accountabilit= y: audit information still shows that the token
authorized a= cting as B.  Is that not worth clarifying?

I=E2=80=99ve always been troubled by the same thing. A and B are, in fact= , distinguishable (contra =E2=80=9CA ... is indistinguishable from B in that= context=E2=80=9D). What i think is meant by impersonation is that A acts in= B=E2=80=99s identity context while using the access it has been delegated, r= ather than its own context =E2=80=94 whatever the extent of this access, gre= at or small.


=E2=80=94 Section 8.2 =E2=80=94
RFC 8174 n= eeds to be normative, along with 2119.

=E2=80= =94 Section 2.2.2 =E2=80=94

  If= the authorization server is unwilling or unable to issue a token
=   for all the target services indicated by the "resource" o= r "audience"
  parameters, the "invalid_target" e= rror code SHOULD be used in the
  error response.=

I always trip when I read =E2=80=9Call=E2=80= =9D in a context like this.  I think you mean
=E2=80=9C= any=E2=80=9D, because you have =E2=80=9Ca token=E2=80=9D.  You could ar= guably make it =E2=80=9Ctokens=E2=80=9D and
leave =E2=80=9Ca= ll=E2=80=9D, but I think changing to =E2=80=9Cany=E2=80=9D is clearer:

NEW
  If the authoriz= ation server is unwilling or unable to issue a token
 =  for any target service indicated by the "resource" or "audience"
  parameters, the "invalid_target" error code SHOULD b= e used in the
  error response and no tokens are r= eturned.
END

The danger wit= h =E2=80=9Call=E2=80=9D is having a reader interpret the error as only occur= ring
when the server fails *all* services, and thinking that= failing one out of
three still constitutes success.  I= have seen this be an issue often (not with
OAuth, but in ge= neral).  If you want to be absolutely clear you could even addto the end, =E2=80=9CA request is successful only when all requested= tokens are issued.=E2=80=9D

=E2=80=94 Sect= ion 5 =E2=80=94

  In addition, b= oth delegation and impersonation introduce unique
 &nb= sp;security issues.  Any time one principal is delegated the rights of<= /span>
  another principal, the potential for abuse is a= concern.  The use of
  the "scope" claim is= suggested to mitigate potential for such abuse,
 &nbs= p;as it restricts the contexts in which the delegated rights can be   exercised.

I=E2=80=99m= ambivalent here: is it worth also mentioning limiting the time a token is
valid and possibly make it a one-time-use token?  Or is i= t that that=E2=80=99s
adequately covered in the other refere= nces and shouldn=E2=80=99t be repeated here?

Also, is it worth referring (not copying) here to the advice in section 2.= 1
about the importance of authentication?

=E2=80=94 Section 6 =E2=80=94
Should =E2=80=9C= TLS=E2=80=9D here have a citation and normative reference?
<= /span>
=3D=3D=3D=3D=3D

Purely edit= orial:

=E2=80=94 Section 1 =E2=80=94=

  An OAuth resource server, for exampl= e, might assume
  the role of the client during t= oken exchange in order to trade an
  access token= , which it received in a protected resource request, for
&n= bsp; a new token that is appropriate to include in a call to a backend<= /span>
  service.

A sug= gestion: I think this would work better using a restrictive clause, rather
than a non-restrictive one.

= NEW
  An OAuth resource server, for example, migh= t assume
  the role of the client during token ex= change in order to trade an
  access token that i= t received in a protected resource request for
  = a new token that is appropriate to include in a call to a backend
=   service.
END

<= span>   The scope of this specification is limited to the definiti= on of a
  basic request and response protocol for= an STS-style token exchange

There should b= e hyphens in =E2=80=9Crequest-and-reaponse protocol=E2=80=9D (compound modif= ier).

=E2=80=94 Sections 4.1 and 4.4 =E2=80= =94

Section 4.1 says this:
=   Consequently, non-
  identity claims= (e.g., "exp", "nbf", and "aud") are not meaningful
 &= nbsp;when used within an "act" claim, and therefore must not be used.=

Section 4.4 says this:
 &nb= sp;Consequently,
  claims such as "exp", "nbf", a= nd "aud" are not meaningful when used
  within a "= may_act" claim, and therefore should not be used.
I agree that neither of these should be BCP 14 key words, but I still= think
that being consistent is important, and I urge you to= make them the same: both
=E2=80=9Cmust not be used=E2=80=9D= or both =E2=80=9Cshould not be used=E2=80=9D (or perhaps both =E2=80=9Care n= ot
used=E2=80=9D).

(I did n= ot review the appendices.)


_______________________________________________
OAuth maili= ng list
OAuth@ietf.org=
htt= ps://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-046D78E1-C507-4A0E-9A54-B70FDA67FA2D-- From nobody Fri Jul 19 04:40: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 04D251201D1 for ; Fri, 19 Jul 2019 04:39: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, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 qDQDSW6DuzFq for ; Fri, 19 Jul 2019 04:39:54 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE9012001E for ; Fri, 19 Jul 2019 04:39:54 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id j5so53527833ioj.8 for ; Fri, 19 Jul 2019 04:39:54 -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=VY4hziMhKc9+vhluJ2NOBmW5T1cqut92v1CLgT/pqc4=; b=C9q4gOPKmaj5xGSG5OqV8uE0Wp9RYj7fgAtrBypf/yAp6bZzDjmzu5mM+PPlvPzX7I AEmpJdTLCZfGolJoFpSuvB7sO1MEMq7En4glHOr1si7lqt8LvOoW2xwezbcRAXpIWk3m 2KDX0DL7zID3iIeQAPPqswEAGv2J93DVj18nA= 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=VY4hziMhKc9+vhluJ2NOBmW5T1cqut92v1CLgT/pqc4=; b=fVNEDqr0CpSR8vKDtc5dVr8XgOrq1xHXfwFSjiT6VAjo/6axmivcou9c0HNJ2isN9t oBnShPkJv0zGmyCZJQzg5zfcaEpqhip5tXIW+ct6kpXOfVVl9sP34VQJQnsGxTqAalG2 WFAwBTIhYyWl0UKHf6xvcrXyMkchq1SjotqCowYDgOdmk91pD2aBge+pbXWNstJkh6Ba P81WPEW3Z/h5wuKzR2leTCFlTf/Hz85NuYvFTDtX8B2FxG39zOPfevufwFAXFrpcJrqb wynibgsghXEHoslZDhLvnT1NHYYZ00gADOsVP5XKhxcVesLiPuXMhcTGwZ2ZNF87QUdC ft6w== X-Gm-Message-State: APjAAAWZ5LfDqPxFWz9tpx6JgDw3Z4wvaPnNbcFqZsKR4rXibaY3jgWT jjIi8GZgSVvmdsshPOzCX9HsgrE+GImqmwj9BkTCgh4ZoibsowUWaZtacjTNjPhd1d5+H5ygqk7 WU9FcXS7hlzzazQ== X-Google-Smtp-Source: APXvYqwhzEhoqZB9Gc3Tdv7RE4dnkY5jiNdviO8OW68GFTvl001tpCf9c6ZI+FiRMPvwETtAjESr2vcPKRFhfEW61U8= X-Received: by 2002:a6b:fd10:: with SMTP id c16mr46338119ioi.217.1563536393550; Fri, 19 Jul 2019 04:39:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 19 Jul 2019 05:39:27 -0600 Message-ID: To: Mike Jones Cc: "Richard Backman, Annabelle" , Dick Hardt , Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="00000000000054f4a4058e072feb" Archived-At: Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 19 Jul 2019 11:40:01 -0000 --00000000000054f4a4058e072feb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd also be interested. On Wed, Jul 17, 2019 at 12:47 PM Mike Jones wrote: > I=E2=80=99d be interested in hearing that presentation =E2=80=93 particul= arly the > =E2=80=9Clessons=E2=80=9D part. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Richard Backman, > Annabelle > *Sent:* Wednesday, July 17, 2019 11:28 AM > *To:* Dick Hardt ; Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda > > > > I=E2=80=99m coming in late to this party, but I=E2=80=99ve been asked by = a few people > about how AWS handles request signing and our experiences with it. Given > the renewed interest in HTTP request signing and the ongoing work on DPoP= , > is this something the working group would be interested in hearing about > during one of the sessions? I could put together a quick 5-10 minute > overview of AWS SigV4 signing and some of the lessons that went into its > design. > > > > Thoughts? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Wednesday, July 10, 2019 at 3:20 PM > *To: *Rifaat Shekh-Yusef > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda > > > > +1 > > > > I like it! :) > > > > On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > Here is our draft agenda for the two sessions we have planned for Montrea= l: > > https://datatracker.ietf.org/meeting/105/materials/agenda-105-oauth-00 > > > > > > Please, take a look and let us know if you have any comments. > > > > Regards, > > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=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._ --00000000000054f4a4058e072feb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd also be interested.

=


On Wed, Jul 17, 2019 at 12:47 PM Mike Jones <Michael.Jon= es=3D40microsoft.com@dmar= c.ietf.org> wrote:

I=E2=80=99d be in= terested in hearing that presentation =E2=80=93 particularly the =E2=80=9Cl= essons=E2=80=9D part.

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

=C2=A0<= /u>

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Richard Backman, Annabelle
Sent: Wednesday, July 17, 2019 11:28 AM
To: Dick Hardt <dick.hardt@gmail.com>; Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>=
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda<= /p>

=C2=A0

I=E2=80=99m coming in late to this party, but I=E2= =80=99ve been asked by a few people about how AWS handles request signing a= nd our experiences with it. Given the renewed interest in HTTP request sign= ing and the ongoing work on DPoP, is this something the working group would be interested in hearing about during one of the s= essions? I could put together a quick 5-10 minute overview of AWS SigV4 sig= ning and some of the lessons that went into its design.

=C2=A0

Thoughts?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Wednesday, July 10, 2019 at 3:20 PM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda<= /span>

=C2=A0

+1=C2=A0

=C2=A0

I like it! :)

=C2=A0

On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

Here is our draft agenda for the two sessions we hav= e planned for Montreal:

=C2=A0

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

=C2=A0

Regards,

=C2=A0Rifaat & Hannes

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
htt= ps://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. --00000000000054f4a4058e072feb-- From nobody Fri Jul 19 04:50: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 9D12C12017C for ; Fri, 19 Jul 2019 04:50: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_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 C-PpDn529b2M for ; Fri, 19 Jul 2019 04:50:53 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA531120019 for ; Fri, 19 Jul 2019 04:50:53 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id k8so57834778iot.1 for ; Fri, 19 Jul 2019 04:50:53 -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=to73FhRZbFGdQ0TnnIMbib/dhKtnklP6Lfq1wY6zp78=; b=id6ZfoyStjVOeHjpk0qyK9t1jyrBkKveC6thGIbaIwK50Y0f3a6uO1edBChlS5b+dk tK6l1pbWGFvsANyiT/vnxeM8E8QXZdTHRZc46zo7WwCu39L9PfiVpodjcAVQc/wvI70X g4J7isdsXK482t8jqHiQDqksd6QiDRiG3etxMSIIHsSkKonU5y1EvMxwkzQcwSzZgtbm rJixkzXs0WAyMuKld6kV14Rmb/TC579sXJtUUurdGwvCJTh6AkpFC/ET8j/qviEGzukg JcaraDjGXOmtavVsumM09RVOnhtbzw/OZ5sL+470bCKXxzxTntUbgYzJE4jimseslMRr Tkug== 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=to73FhRZbFGdQ0TnnIMbib/dhKtnklP6Lfq1wY6zp78=; b=H7U0j8bXvvU2HDfMecIAQI0ypfOX2shHY8KsOTSD5jEHh4NOxTlfU6sJhkJ0B/5NSq s66PBWPn/KrvKxQJ68lRoAgXUDaaAOP8UcxMYO7x7OZ+Yl6lae9ya4SulDOHjXB9ks7e So3prAEEmOzFIPAq8j3bAMgCIRImLCeAkyDx+Uf1FaaW/TUtRfgshHQDTBIRUa3FWCgP Xxk9lT3OTS0kvXhZrbRkIBlCbZX+rp8Y7O2FUohLs9MA7RIcYRvMUUWArraYAaa0LDjb ot2F5JsJXNJJulCdIj1AwXXbNwBbtTdC+wAQYonwLVYbjB7DSSdBTZijFEXzX5eDhhiC ecYQ== X-Gm-Message-State: APjAAAX9/TUnTGq+KO8YwMkeKSNLII2BL0b42GnkAoSY/5XHkNYYb3pR nyyNpkzfs7AgIgN28C78OOE3x2Z/yK1XhHcMfLE= X-Google-Smtp-Source: APXvYqz8wp2Drf9BBv/A6a+wjBX2YriNvkDLj+SUq6IcfEj7/u15TV7w/eJg24lvx2bm93qqRmqXkj9xS4fObwsagns= X-Received: by 2002:a05:6638:3d2:: with SMTP id r18mr55079412jaq.13.1563537052966; Fri, 19 Jul 2019 04:50:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Fri, 19 Jul 2019 07:50:41 -0400 Message-ID: To: "Richard Backman, Annabelle" Cc: Dick Hardt , oauth Content-Type: multipart/alternative; boundary="000000000000a2a5d8058e0756fb" Archived-At: Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda X-BeenThere: oauth@ietf.org X-Mailman-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, 19 Jul 2019 11:50:56 -0000 --000000000000a2a5d8058e0756fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Annabelle, Go ahead and prepare slides to cover this topic, and I will try to squeeze it in. Regards, Rifaat On Wed, Jul 17, 2019 at 2:28 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > I=E2=80=99m coming in late to this party, but I=E2=80=99ve been asked by = a few people > about how AWS handles request signing and our experiences with it. Given > the renewed interest in HTTP request signing and the ongoing work on DPoP= , > is this something the working group would be interested in hearing about > during one of the sessions? I could put together a quick 5-10 minute > overview of AWS SigV4 signing and some of the lessons that went into its > design. > > > > Thoughts? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Wednesday, July 10, 2019 at 3:20 PM > *To: *Rifaat Shekh-Yusef > *Cc: *oauth > *Subject: *Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda > > > > +1 > > > > I like it! :) > > > > On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > Here is our draft agenda for the two sessions we have planned for Montrea= l: > > https://datatracker.ietf.org/meeting/105/materials/agenda-105-oauth-00 > > > > Please, take a look and let us know if you have any comments. > > > > Regards, > > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000a2a5d8058e0756fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Annabelle,

Go ahead and prepare slides = to cover this topic, and I will try to squeeze it in.

<= div>Regards,
=C2=A0Rifaat


On Wed, Jul 17, 201= 9 at 2:28 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m coming in late to this party, but I=E2= =80=99ve been asked by a few people about how AWS handles request signing a= nd our experiences with it. Given the renewed interest in HTTP request sign= ing and the ongoing work on DPoP, is this something the working group would be interested in hearing about during one of the s= essions? I could put together a quick 5-10 minute overview of AWS SigV4 sig= ning and some of the lessons that went into its design.

=C2=A0

Thoughts?

=C2=A0

--=C2=A0

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Wednesday, July 10, 2019 at 3:20 PM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda<= /span>

=C2=A0

+1=C2=A0

=C2=A0

I like it! :)

=C2=A0

On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

Here is our draft agenda for the two sessions we hav= e planned for Montreal:

=C2=A0

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

=C2=A0

Regards,

=C2=A0Rifaat & Hannes

=C2=A0

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

--000000000000a2a5d8058e0756fb-- From nobody Fri Jul 19 07:13: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 E23FF1202B4 for ; Fri, 19 Jul 2019 07:13:23 -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 vdaTxWqVMRlp for ; Fri, 19 Jul 2019 07:13:21 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DF71202BE for ; Fri, 19 Jul 2019 07:13:20 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id e20so28352738iob.9 for ; Fri, 19 Jul 2019 07:13:20 -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=c2gemOuO6cwrplFyUKWHKkSwK72cV4Su3njI0wtIPQU=; b=CkCuDRknVTFvqCQqt2rmJVcl7dF011I/YDO5FR2cT14I+pLkuMd6SR/tHK6Gh9cUvI 4mZfIRRosP+Kpss9ZzsAvPWt1TcpcGLR7QJUX4PtOURHK9HnqlnVjEUE0xyBrVuPznYG uUzC+exZnWoFMnGLP36VIwIDDoLBDaa2oPAGY= 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=c2gemOuO6cwrplFyUKWHKkSwK72cV4Su3njI0wtIPQU=; b=oWOanpqTuJ4iJM9/m5wD3o9It/FQz4Y5jRkxIiOjCA7X0IBbReBf2TqwSd6rnQ9L4V WOrZDVtRyz1I4mu2/1mlqFTi4DFaYSlPWg/KHe+aVOjU0iqbXNyGXgdUSzWSLtg+Tke9 xAUwzHZu4NwwpZbQBNJ0+bqRoF7liFY4EO/tMs8zLpJF/M3+VTNfAiT7OogG6H77vshb NFm84jgLKNKDKFcUjZHagH7APfQyPia3/FM0UaURCHFtFNsNw14uW7+621vRlU4EfM2W VkCQpJ93/CA2KO1dCFoQijVwTFE+Oq6TQ5EDzEetguMZERx+dnxlfglLo1sh2cLWu2Ez aB9Q== X-Gm-Message-State: APjAAAVnbWW8Q8m8hrrTkzncG0IHxAnsmzS4Gl5wFbk+uhMobZJsCZfm qpJ0Hvr8vCJlnZjP63cgnIcGVFDWuX5Tj/x5kBYZhnNnF+xewwjd7J8tghgHvm8XHFfGPWnbA0g xwgxJ/InkOfYBfA== X-Google-Smtp-Source: APXvYqyNOrQlP+zdlalrGfXHYit1GHpNQ9gpjQ513p1BuR+11QDBvRBpxYETC+gEPmVX6iAqwLRqob3SEEp1vG7gTng= X-Received: by 2002:a5d:87c6:: with SMTP id q6mr27807156ios.115.1563545599975; Fri, 19 Jul 2019 07:13:19 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> In-Reply-To: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 19 Jul 2019 08:12:53 -0600 Message-ID: To: Barry Leiba Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000013b9b7058e095424" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 14:13:28 -0000 --00000000000013b9b7058e095424 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Barry, thanks for the review, ballot position and comments. Please see inline below for my replies to the latter. On Thu, Jul 18, 2019 at 3:06 PM Barry Leiba via Datatracker < noreply@ietf.org> wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have comments below, a couple of which might have been DISCUSS except > that > there have been enough eyes on this and enough DISCUSSes already, and I > trust > the authors and responsible AD to do the right thing. I always endeavor to do the right thing. > So I=E2=80=99ve divided the > comments between =E2=80=9Chigher importance=E2=80=9D and =E2=80=9Cpurely = editorial=E2=80=9D. > > Of higher importance: > > =E2=80=94 Section 1.1 =E2=80=94 > Given the extensive discussion of impersonation here, what strikes me as > missing is pointing out that impersonation here is still controlled, that > =E2=80=9CA is > B=E2=80=9D but only to the extent that=E2=80=99s allowed by the token. F= irst, it might be > limited by number of instances (one transaction only), by time of day > (only for > 10 minutes), and by scope (in regard to B=E2=80=99s address book, but not= B=E2=80=99s > email). > Second, there is accountability: audit information still shows that the > token > authorized acting as B. Is that not worth clarifying? > My initial response was going to be "sure, I'll add some bits in sec 1.1 along those lines to clarify that." However, as I look again at that section for good opportunities to make such additions, I feel like it is already said that impersonation is controlled. Notably there are these bits of text: "or for A to be granted a *limited access credential *to C but that continues to identify B as the authorized entity ("impersonation")." "When principal A impersonates principal B, A is given all the rights that B has *within some defined rights context*" So I think it already says that and I'm gonna have to flip it back and ask if you have concrete suggestions for changes or additions that would say it more clearly or more to your liking? > > =E2=80=94 Section 8.2 =E2=80=94 > RFC 8174 needs to be normative, along with 2119. > Of course. Not sure how those got separated in the first place but I'll move 8174 to normative. > =E2=80=94 Section 2.2.2 =E2=80=94 > > If the authorization server is unwilling or unable to issue a token > for all the target services indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response. > > I always trip when I read =E2=80=9Call=E2=80=9D in a context like this. = I think you mean > =E2=80=9Cany=E2=80=9D, because you have =E2=80=9Ca token=E2=80=9D. You c= ould arguably make it =E2=80=9Ctokens=E2=80=9D and > leave =E2=80=9Call=E2=80=9D, but I think changing to =E2=80=9Cany=E2=80= =9D is clearer: > > NEW > If the authorization server is unwilling or unable to issue a token > for any target service indicated by the "resource" or "audience" > parameters, the "invalid_target" error code SHOULD be used in the > error response and no tokens are returned. > END > > The danger with =E2=80=9Call=E2=80=9D is having a reader interpret the er= ror as only > occurring > when the server fails *all* services, and thinking that failing one out o= f > three still constitutes success. I have seen this be an issue often (not > with > OAuth, but in general). If you want to be absolutely clear you could eve= n > add > to the end, =E2=80=9CA request is successful only when all requested toke= ns are > issued.=E2=80=9D > Will change to try and avoid that potential trip-up. > > =E2=80=94 Section 5 =E2=80=94 > > In addition, both delegation and impersonation introduce unique > security issues. Any time one principal is delegated the rights of > another principal, the potential for abuse is a concern. The use of > the "scope" claim is suggested to mitigate potential for such abuse, > as it restricts the contexts in which the delegated rights can be > exercised. > > I=E2=80=99m ambivalent here: is it worth also mentioning limiting the tim= e a token > is > valid and possibly make it a one-time-use token? Or is it that that=E2= =80=99s > adequately covered in the other references and shouldn=E2=80=99t be repea= ted here? > > Also, is it worth referring (not copying) here to the advice in section 2= .1 > about the importance of authentication? > > =E2=80=94 Section 6 =E2=80=94 > Should =E2=80=9CTLS=E2=80=9D here have a citation and normative reference= ? > I didn't include an explicit reference here because TLS is transitively referenced by other normative references (including 6749 of which this whole thing is an extension) and TLS is pretty widely recognized even without citation. Or maybe it was just an oversight when I added that particular text. I'm happy to add a citation here but it does raise the question of what the most appropriate way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination thereof? > > =3D=3D=3D=3D=3D > > Purely editorial: > > =E2=80=94 Section 1 =E2=80=94 > > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token, which it received in a protected resource request, for > a new token that is appropriate to include in a call to a backend > service. > > A suggestion: I think this would work better using a restrictive clause, > rather > than a non-restrictive one. > > NEW > An OAuth resource server, for example, might assume > the role of the client during token exchange in order to trade an > access token that it received in a protected resource request for > a new token that is appropriate to include in a call to a backend > service. > END > Will take the suggestion. > The scope of this specification is limited to the definition of a > basic request and response protocol for an STS-style token exchange > > There should be hyphens in =E2=80=9Crequest-and-reaponse protocol=E2=80= =9D (compound > modifier). > Okay, request-and-response it will be. > > =E2=80=94 Sections 4.1 and 4.4 =E2=80=94 > > Section 4.1 says this: > Consequently, non- > identity claims (e.g., "exp", "nbf", and "aud") are not meaningful > when used within an "act" claim, and therefore must not be used. > > Section 4.4 says this: > Consequently, > claims such as "exp", "nbf", and "aud" are not meaningful when used > within a "may_act" claim, and therefore should not be used. > > I agree that neither of these should be BCP 14 key words, but I still thi= nk > that being consistent is important, and I urge you to make them the same: > both > =E2=80=9Cmust not be used=E2=80=9D or both =E2=80=9Cshould not be used=E2= =80=9D (or perhaps both =E2=80=9Care not > used=E2=80=9D). > Makes sense, I'll make them the same. And I think I'll go with =E2=80=9Car= e not used". --=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._ --00000000000013b9b7058e095424 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barry, thanks for the review, ballot position and comments= . Please see inline below for my replies to the latter.


On Thu, Jul 18, 2019 at 3:06 PM Barry Leiba via Datatracker &l= t;noreply@ietf.org> wrote:
Barry Leiba has enter= ed the following ballot position for
draft-ietf-oauth-token-exchange-18: No Objection

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-oauth-token-exchange/



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

I have comments below, a couple of which might have been DISCUSS except tha= t
there have been enough eyes on this and enough DISCUSSes already, and I tru= st
the authors and responsible AD to do the right thing.

=
I always endeavor to do the right thing.

=C2=A0
=C2=A0= So I=E2=80=99ve divided the
comments between =E2=80=9Chigher importance=E2=80=9D and =E2=80=9Cpurely ed= itorial=E2=80=9D.

Of higher importance:

=E2=80=94 Section 1.1 =E2=80=94
Given the extensive discussion of impersonation here, what strikes me as missing is pointing out that impersonation here is still controlled, that = =E2=80=9CA is
B=E2=80=9D but only to the extent that=E2=80=99s allowed by the token.=C2= =A0 First, it might be
limited by number of instances (one transaction only), by time of day (only= for
10 minutes), and by scope (in regard to B=E2=80=99s address book, but not B= =E2=80=99s email).
Second, there is accountability: audit information still shows that the tok= en
authorized acting as B.=C2=A0 Is that not worth clarifying?

My initial response was going to be "sure, I'= ll add some bits in sec 1.1 along those lines to clarify that." Howeve= r, as I look again at that section for good opportunities to make such addi= tions, I feel like it is already said that impersonation is controlled. No= tably there are these bits of text:

"or = for A to
=C2=A0 =C2=A0be granted a limited access credential to C= but that continues to
=C2=A0 =C2=A0identify B as the authorized entity = ("impersonation")."

"When prin= cipal A impersonates principal B, A is given all the rights
=C2=A0 =C2= =A0that B has within some defined rights context"
So I think it already says that and I'm gonna have to flip = it back and ask if you have concrete suggestions for changes or additions t= hat would say it more clearly or more to your liking?


=C2=A0

=E2=80=94 Section 8.2 =E2=80=94
RFC 8174 needs to be normative, along with 2119.

<= /div>
Of course. Not sure how those got separated in the first place bu= t I'll move 8174 to normative.
=C2=A0


=E2=80=94 Section 2.2.2 =E2=80=94

=C2=A0 =C2=A0If the authorization server is unwilling or unable to issue a = token
=C2=A0 =C2=A0for all the target services indicated by the "resource&qu= ot; or "audience"
=C2=A0 =C2=A0parameters, the "invalid_target" error code SHOULD b= e used in the
=C2=A0 =C2=A0error response.

I always trip when I read =E2=80=9Call=E2=80=9D in a context like this.=C2= =A0 I think you mean
=E2=80=9Cany=E2=80=9D, because you have =E2=80=9Ca token=E2=80=9D.=C2=A0 Yo= u could arguably make it =E2=80=9Ctokens=E2=80=9D and
leave =E2=80=9Call=E2=80=9D, but I think changing to =E2=80=9Cany=E2=80=9D = is clearer:

NEW
=C2=A0 =C2=A0If the authorization server is unwilling or unable to issue a = token
=C2=A0 =C2=A0for any target service indicated by the "resource" o= r "audience"
=C2=A0 =C2=A0parameters, the "invalid_target" error code SHOULD b= e used in the
=C2=A0 =C2=A0error response and no tokens are returned.
END

The danger with =E2=80=9Call=E2=80=9D is having a reader interpret the erro= r as only occurring
when the server fails *all* services, and thinking that failing one out of<= br> three still constitutes success.=C2=A0 I have seen this be an issue often (= not with
OAuth, but in general).=C2=A0 If you want to be absolutely clear you could = even add
to the end, =E2=80=9CA request is successful only when all requested tokens= are issued.=E2=80=9D

Will change to tr= y and avoid that potential trip-up.


=C2=A0

=E2=80=94 Section 5 =E2=80=94

=C2=A0 =C2=A0In addition, both delegation and impersonation introduce uniqu= e
=C2=A0 =C2=A0security issues.=C2=A0 Any time one principal is delegated the= rights of
=C2=A0 =C2=A0another principal, the potential for abuse is a concern.=C2=A0= The use of
=C2=A0 =C2=A0the "scope" claim is suggested to mitigate potential= for such abuse,
=C2=A0 =C2=A0as it restricts the contexts in which the delegated rights can= be
=C2=A0 =C2=A0exercised.

I=E2=80=99m ambivalent here: is it worth also mentioning limiting the time = a token is
valid and possibly make it a one-time-use token?=C2=A0 Or is it that that= =E2=80=99s
adequately covered in the other references and shouldn=E2=80=99t be repeate= d here?

Also, is it worth referring (not copying) here to the advice in section 2.1=
about the importance of authentication?

=E2=80=94 Section 6 =E2=80=94
Should =E2=80=9CTLS=E2=80=9D here have a citation and normative reference?<= br>

I didn't include an explicit refere= nce here because TLS is transitively referenced by other normative referenc= es (including 6749 of which this whole thing is an extension) and TLS is pr= etty widely recognized even without citation.

Or maybe it was just an oversight when I added that particular text.
<= /div>

I'm happy to add a citation here but it does r= aise the question of what the most appropriate way to cite TLS is right now= - 1.3, 1.2, or the BCP or some combination thereof?

=C2=A0

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

Purely editorial:

=E2=80=94 Section 1 =E2=80=94

=C2=A0 =C2=A0An OAuth resource server, for example, might assume
=C2=A0 =C2=A0the role of the client during token exchange in order to trade= an
=C2=A0 =C2=A0access token, which it received in a protected resource reques= t, for
=C2=A0 =C2=A0a new token that is appropriate to include in a call to a back= end
=C2=A0 =C2=A0service.

A suggestion: I think this would work better using a restrictive clause, ra= ther
than a non-restrictive one.

NEW
=C2=A0 =C2=A0An OAuth resource server, for example, might assume
=C2=A0 =C2=A0the role of the client during token exchange in order to trade= an
=C2=A0 =C2=A0access token that it received in a protected resource request = for
=C2=A0 =C2=A0a new token that is appropriate to include in a call to a back= end
=C2=A0 =C2=A0service.
END

=C2=A0Will take the suggestion.
=


=C2=A0
=C2=A0 =C2=A0The scope of this specification is limited to the definition o= f a
=C2=A0 =C2=A0basic request and response protocol for an STS-style token exc= hange

There should be hyphens in =E2=80=9Crequest-and-reaponse protocol=E2=80=9D = (compound modifier).

Okay, request-and-= response it will be.

=C2=A0

=E2=80=94 Sections 4.1 and 4.4 =E2=80=94

Section 4.1 says this:
=C2=A0 =C2=A0Consequently, non-
=C2=A0 =C2=A0identity claims (e.g., "exp", "nbf", and &= quot;aud") are not meaningful
=C2=A0 =C2=A0when used within an "act" claim, and therefore must = not be used.

Section 4.4 says this:
=C2=A0 =C2=A0Consequently,
=C2=A0 =C2=A0claims such as "exp", "nbf", and "aud= " are not meaningful when used
=C2=A0 =C2=A0within a "may_act" claim, and therefore should not b= e used.

I agree that neither of these should be BCP 14 key words, but I still think=
that being consistent is important, and I urge you to make them the same: b= oth
=E2=80=9Cmust not be used=E2=80=9D or both =E2=80=9Cshould not be used=E2= =80=9D (or perhaps both =E2=80=9Care not
used=E2=80=9D).

Makes sense, I'll m= ake them the same.=C2=A0 And I think I'll go with =E2=80=9Care not used= ".

<= 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. --00000000000013b9b7058e095424-- From nobody Fri Jul 19 07:32: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 4193F1202D0; Fri, 19 Jul 2019 07:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fp4e5F6-Hvc; Fri, 19 Jul 2019 07:31:57 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31258120289; Fri, 19 Jul 2019 07:31:57 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id m24so58872626ioo.2; Fri, 19 Jul 2019 07:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sAlO20ULKee8qYglrJCf1YyiGj9d+7VuUQWiKenkgAE=; b=B24YbnGCBxugBCEkTGGcEPtkKW2YJLGH8NS4QiUPz9yGZ0klTL96vu4yqGR9ATqBXd HKMk945SppWq24JuXWMzmArF934Gy8sF5+EURIgEY1QIgoddlRWRIqxSB1iV1fJozjU1 GoJSo33wmviRNm2rAl601AIFsBZI4BRNl2Twb5/8xZbeLB+OBaXO3xeV8J4aF6RzUYgL ++ke6JIG5yFpjGDt22CRj2GYo6cFSQC1ijdNQTdXT1yrxUDbZQ+2vK8QoIZ+VbMVfrfe y60INBegY25joZJh1Tb1RTGtSuKT+124L65II7Bt943e47uAx+pIURpe4sUiNaq1YLFI JP0A== X-Gm-Message-State: APjAAAWb5gHQxnYdS20sctqw8ldrv8gUYUc05UEVAkbK6SSeUEfSbFl3 BI6ghuAfP/KYybfKF7HUUx3wIiegmR2w8lSvffNw+JQr X-Google-Smtp-Source: APXvYqxTCoi7KYZO86lxtyyW+UtsnAZYiSxRZEcTObSQRg8GKxHYj2y4q2na+pyXaDBx0x8LI+yqs3KmrvpYeJwjefg= X-Received: by 2002:a5d:9613:: with SMTP id w19mr12123527iol.140.1563546716075; Fri, 19 Jul 2019 07:31:56 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 19 Jul 2019 10:31:44 -0400 Message-ID: To: Brian Campbell Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 14:31:58 -0000 >> and I trust the authors and responsible AD to do the right thing. > > I always endeavor to do the right thing. You do; hence, the trust. :-) And thanks for the quick responses. >> =E2=80=94 Section 1.1 =E2=80=94 >> Given the extensive discussion of impersonation here, what strikes me as >> missing is pointing out that impersonation here is still controlled, tha= t =E2=80=9CA is >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the token. = First, it might be >> limited by number of instances (one transaction only), by time of day (o= nly for >> 10 minutes), and by scope (in regard to B=E2=80=99s address book, but no= t B=E2=80=99s email). >> Second, there is accountability: audit information still shows that the = token >> authorized acting as B. Is that not worth clarifying? > > My initial response was going to be "sure, I'll add some bits in sec 1.1 = along those lines to clarify > that." However, as I look again at that section for good opportunities to= make such additions, I feel > like it is already said that impersonation is controlled. ... > So I think it already says that and I'm gonna have to flip it back and as= k if you have concrete > suggestions for changes or additions that would say it more clearly or mo= re to your liking? It is mentioned, true, and that might be enough. But given that Eve also replied that she would like more here, let me suggest something, the use of which is entirely optional -- take it, don't take it, modify it, riff on it, ignore it completely, as you think best. What do you think about changing the last sentence of the paragraph?: "For all intents and purposes, when A is impersonating B, A is B within the rights context authorized by the token, which could be limited in scope or time, or by a one-time-use restriction." >> =E2=80=94 Section 6 =E2=80=94 >> Should =E2=80=9CTLS=E2=80=9D here have a citation and normative referenc= e? > > I didn't include an explicit reference here because TLS is transitively r= eferenced by other > normative references (including 6749 of which this whole thing is an exte= nsion) and TLS > is pretty widely recognized even without citation. ... > I'm happy to add a citation here but it does raise the question of what t= he most appropriate > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination t= hereof? I wondered the same thing, and you're also right that it might not need a reference in this document. I only even flagged it because it's the subject of a MUST. I'll leave it to the Sec ADs (who obviously didn't flag it themselves, so maybe they agree that it's not necessary). Barry From nobody Fri Jul 19 09:06: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 5644B1207DF for ; Fri, 19 Jul 2019 09:06: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_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 3YRxbABKhhxS for ; Fri, 19 Jul 2019 09:06:24 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7117712069B for ; Fri, 19 Jul 2019 09:06:24 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id j6so27179458ioa.5 for ; Fri, 19 Jul 2019 09:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eFocbs5JNBuNZM7ebaaPs2VuJbmp45tNyKML9IglWxo=; b=YisI1MWUHKcG0bZf96nQXbGn5M+QydPmaK01VaipHGogPE87e9kbpwEYuCLRwFFb5t 7mU4Vvwd32s73PlN99upIVjU6ayb6MAu/qF04PFcstJqj9ELGiatdmjc7syrZnKFDI86 IV15pOzLGm5ZGdzwzqZS0HuK/rP1EifpyAeS8= 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=eFocbs5JNBuNZM7ebaaPs2VuJbmp45tNyKML9IglWxo=; b=W+a04owV3zg4mnaNxed0ijmB+FTtxmPsdUvqTKee4zaQGCYpBqc9xknftD73D42+jb ZUdY+/PBs5ffR5q0kkWo3pYCS7YBQcFkj6cW1TtrqCXkFShfpMwow1amm+rfZaxXYAJ/ iheQ6bJCjUsuFNHiQIMw228VSeVl9rZbsCsU4jzxX1DFCMfY+9a27/f662NE9uURhr4N uvCCRJTcUgNuyCxHcCoAp660MwAtPqZAUjc5UjfWQRK47S5f0CfwBt3UjFDCgWj3Qk7/ 6H8cYhUlmpNSF+wknPUmE2mOdCABZMiEdeVka2jJAJbjWMVNKGfQXgeaS77OMgGdE/dT 3zvA== X-Gm-Message-State: APjAAAWq+tUm/UbdFZSQiwNONeeYCsVg1mKbqTXZqReTavZhtEYwJccr ni6asBNFtPsKiSdOfK8z+YcpybuqPnSYn4aQ5KDvugFCeo/aTyws0k6DIc2iCHtE+UdrRNTMnMa 2tVGWp3tmlKuuvw== X-Google-Smtp-Source: APXvYqx2gfSQKe0kJskc3A6ayCJvbEecUpOUQkd5kDm4QTUK6Todm/EUa+hd5yHqCQm3Skeg50jBRSEVk3Cftd/0BNg= X-Received: by 2002:a02:a595:: with SMTP id b21mr2154866jam.28.1563552383610; Fri, 19 Jul 2019 09:06:23 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> In-Reply-To: From: Brian Campbell Date: Fri, 19 Jul 2019 10:05:57 -0600 Message-ID: To: Barry Leiba Cc: The IESG , oauth , draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000069d44d058e0ae891" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 16:06:27 -0000 --00000000000069d44d058e0ae891 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote= : > >> and I trust the authors and responsible AD to do the right thing. > > > > I always endeavor to do the right thing. > > You do; hence, the trust. :-) > I do appreciate that, thank you. > And thanks for the quick responses. > I try. To varying degrees of success. > > >> =E2=80=94 Section 1.1 =E2=80=94 > >> Given the extensive discussion of impersonation here, what strikes me = as > >> missing is pointing out that impersonation here is still controlled, > that =E2=80=9CA is > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the token.= First, it might > be > >> limited by number of instances (one transaction only), by time of day > (only for > >> 10 minutes), and by scope (in regard to B=E2=80=99s address book, but = not B=E2=80=99s > email). > >> Second, there is accountability: audit information still shows that th= e > token > >> authorized acting as B. Is that not worth clarifying? > > > > My initial response was going to be "sure, I'll add some bits in sec 1.= 1 > along those lines to clarify > > that." However, as I look again at that section for good opportunities > to make such additions, I feel > > like it is already said that impersonation is controlled. > ... > > So I think it already says that and I'm gonna have to flip it back and > ask if you have concrete > > suggestions for changes or additions that would say it more clearly or > more to your liking? > > It is mentioned, true, and that might be enough. But given that Eve > also replied that she would like more here, let me suggest something, > the use of which is entirely optional -- take it, don't take it, > modify it, riff on it, ignore it completely, as you think best. What > do you think about changing the last sentence of the paragraph?: "For > all intents and purposes, when A is impersonating B, A is B within the > rights context authorized by the token, which could be limited in > scope or time, or by a one-time-use restriction." > Sure, I think that or some slight modification thereof can work just fine. I'll do that and get it and the rest of these changes published when the I-D submission embargo is lifted for Montreal. > > >> =E2=80=94 Section 6 =E2=80=94 > >> Should =E2=80=9CTLS=E2=80=9D here have a citation and normative refere= nce? > > > > I didn't include an explicit reference here because TLS is transitively > referenced by other > > normative references (including 6749 of which this whole thing is an > extension) and TLS > > is pretty widely recognized even without citation. > ... > > I'm happy to add a citation here but it does raise the question of what > the most appropriate > > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination > thereof? > > I wondered the same thing, and you're also right that it might not > need a reference in this document. I only even flagged it because > it's the subject of a MUST. I'll leave it to the Sec ADs (who > obviously didn't flag it themselves, so maybe they agree that it's not > necessary). > I'm gonna just leave it as-is then, unless I hear otherwise from the Sec ADs. --=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._ --00000000000069d44d058e0ae891 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 19, 2019 at 8:31 AM Barry= Leiba <barryleiba@computer.o= rg> wrote:
And thanks for the quick responses.

I t= ry. To varying degrees of success.
=C2=A0

>> =E2=80=94 Section 1.1 =E2=80=94
>> Given the extensive discussion of impersonation here, what strikes= me as
>> missing is pointing out that impersonation here is still controlle= d, that =E2=80=9CA is
>> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the to= ken.=C2=A0 First, it might be
>> limited by number of instances (one transaction only), by time of = day (only for
>> 10 minutes), and by scope (in regard to B=E2=80=99s address book, = but not B=E2=80=99s email).
>> Second, there is accountability: audit information still shows tha= t the token
>> authorized acting as B.=C2=A0 Is that not worth clarifying?
>
> My initial response was going to be "sure, I'll add some bits= in sec 1.1 along those lines to clarify
> that." However, as I look again at that section for good opportun= ities to make such additions, I feel
> like it is already said that impersonation is controlled.
...
> So I think it already says that and I'm gonna have to flip it back= and ask if you have concrete
> suggestions for changes or additions that would say it more clearly or= more to your liking?

It is mentioned, true, and that might be enough.=C2=A0 But given that Eve also replied that she would like more here, let me suggest something,
the use of which is entirely optional -- take it, don't take it,
modify it, riff on it, ignore it completely, as you think best.=C2=A0 What<= br> do you think about changing the last sentence of the paragraph?: "For<= br> all intents and purposes, when A is impersonating B, A is B within the
rights context authorized by the token, which could be limited in
scope or time, or by a one-time-use restriction."

Sure, I think that or some slight modification thereof can = work just fine. I'll do that and get it and the rest of these changes p= ublished when the I-D submission embargo is lifted for Montreal.
=

=C2=A0

>> =E2=80=94 Section 6 =E2=80=94
>> Should =E2=80=9CTLS=E2=80=9D here have a citation and normative re= ference?
>
> I didn't include an explicit reference here because TLS is transit= ively referenced by other
> normative references (including 6749 of which this whole thing is an e= xtension) and TLS
> is pretty widely recognized even without citation.
...
> I'm happy to add a citation here but it does raise the question of= what the most appropriate
> way to cite TLS is right now - 1.3, 1.2, or the BCP or some combinatio= n thereof?

I wondered the same thing, and you're also right that it might not
need a reference in this document.=C2=A0 I only even flagged it because
it's the subject of a MUST.=C2=A0 I'll leave it to the Sec ADs (who=
obviously didn't flag it themselves, so maybe they agree that it's = not
necessary).

I'm gonna just leave it= as-is then, unless I hear otherwise from the Sec ADs.

<= 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. --00000000000069d44d058e0ae891-- From nobody Fri Jul 19 11:02: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 54936120159 for ; Fri, 19 Jul 2019 11:02:57 -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 Fux4ZYEwXvQx for ; Fri, 19 Jul 2019 11:02:53 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1D6120104 for ; Fri, 19 Jul 2019 11:02:53 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id g20so60169966ioc.12 for ; Fri, 19 Jul 2019 11:02:53 -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=Ae9oe8j2Vb2ByBDp6TFMsTp4IPoDy5g027Or5Il2wtk=; b=RVsX3t5avXoximeMdo9KJQy5XQe3eCIf080NQUhTq3DfEIJQEFLezm6tt9t6FDJoLI 6bhDXsbu4rRgchaNFZ146JYWx09oF1rQy1RYJzf8yUWmDIOkrCjXXdwvy2pfh9WA6RLM Y4uulQ3q/aBgVCyJAPT7Y2RV66hs0qr3M5W2o= 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=Ae9oe8j2Vb2ByBDp6TFMsTp4IPoDy5g027Or5Il2wtk=; b=c4V17odCCKEg2texrH1As0IwFy+sQSR4z5GdurNZ+ho+5T/3WN2uI+9fnzLfCjQrdv qScT19pHSROim5INn2xjyiJU+eRWz9oJ/BNcyeAapNHCjL2nCWRJLFxsTEifhT3OaVWZ uDpef08CRaITZBK0GIENtDhYH2Y94Q4u3xc/LCaQhXLVVGfTZn1mq4k2ZCz7rHtwGQCt Su87nJPGBY6655otCO6ssD8rvdztIE4wuFPgCqoaUk2nS/9B9hMBRNRe7znZOwrsod6e JJVFpkYrr4ftiDFGPIUZ2nGjsCAF3z3pPD/sBw9NU7PhMw9F6lrgESt3TKnUf6zB8AhN 2fAA== X-Gm-Message-State: APjAAAUuLldpECIYQ/2qnown9+J3MNfsy6ZWCmgSR8XWanD5TqHKqVlu YRp43hG71FhqiA2iYxTG5XLSiJnkicpo/BcHTrVVGsiD/buXUjp5UxqRn4N4cSbWPk7JY0SjtWF vJZVdor81idRNp3I35IQ= X-Google-Smtp-Source: APXvYqxZ/ZmN4eV5Wi/U/P5XXPGvwv6GZgusGWNQ/JfK3Jt0IkxiEd8YazgSaHCo5Xr70kfR5JIhoRo0eZ9gLVzH5Is= X-Received: by 2002:a05:6638:201:: with SMTP id e1mr55898714jaq.45.1563559372630; Fri, 19 Jul 2019 11:02:52 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D7BC9@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D7BC9@marchand> From: Brian Campbell Date: Fri, 19 Jul 2019 12:02:26 -0600 Message-ID: To: Roman Danyliw Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fdca05058e0c880e" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 18:02:57 -0000 --000000000000fdca05058e0c880e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Roman, I'm attempting to bring this thread and our private exchanges together (sorry again that it ended up that way) and make sure we are on the same page about the path forward before I start down that path. Yes, your assessment below is correct. And yes I think the changes you proposed to IANA section 4 of draft-ietf-oauth-resource-indicators follow from that and make sense. However, draft-ietf-oauth-token-exchange should also be changed to take on a short sentence in its text about the resource parameter to mention draft-ietf-oauth-resource-indicators and include an informational reference to it. Please confirm that or correct me and I'll proceed with the changes. On Wed, Jul 17, 2019 at 5:49 PM Roman Danyliw wrote: > Hi Brian! > > > > Thanks for this background and explanation. There was history here I > didn=E2=80=99t know. > > > > With the benefit of this thread and private exchanges, the key takeaways > for me are: > > > > ** the definition of 'resource' for 'token exchange' is identical in both > drafts (draft-ietf-oauth-resource-indicator and > draft-ietf-oauth-token-exchange) > > > > ** draft-ietf-oauth-resource-indicators has additional =E2=80=9Cuses=E2= =80=9D of resource > not germane to draft-ietf-oauth-resource-indicator > > > > ** the desired ends-state after the IANA considerations sections of both > drafts were process, the Oauth registry would look as follows: > > - name =3D resource > > - parameter usage location =3D authorization request, token request > > - change controller =3D IETF > > - reference =3D draft-ietf-oauth-resource-indicator > > > > Is that right? > > > > If the above is correct, would the following way ahead work: > > > > ** for draft-ietf-oauth-token exchange: Nothing > > > > ** for draft-ietf-oauth-resource-indicator > > > > Per Section 4.1: > > > > This specification updates the following value in the IANA "OAuth > > Parameters" registry [IANA.OAuth.Parameters] established by > > [RFC6749]. > > > > o Parameter name: resource > > o Parameter usage location: authorization request, token request > > o Change controller: IESG > > o Specification document(s): [[ this specification ]] > > > > Per Section 4.2 > > This specification updates the following error in the IANA "OAuth > > Extensions Error Registry" [IANA.OAuth.Parameters] established by > > [RFC6749]. > > > > o Error name: invalid_target > > o Error usage location: implicit grant error response, token error > > response > > o Related protocol extension: resource parameter > > o Change controller: IESG > > o Specification document(s): [[ this specification ]] > > > > Roman > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, July 17, 2019 6:31 PM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > Yeah, as you surmised, there is some history behind this. Basically > draft-ietf-oauth-token-exchange predates > draft-ietf-oauth-resource-indicators by a good long time (years) and with > the hope and expectation that draft-ietf-oauth-token-exchange would move = to > RFC, I've avoided having a reference in it to a draft much earlier along = in > the whole process. draft-ietf-oauth-resource-indicators has a bit of an o= dd > history too in that an initial call for adoption around the Buenos Aires > meeting kinda fizzled out and it was left for dead until being unexpected > resurrected around Montreal last year due to renewed interest and other > factors I'm still not sure I understand. > > > > You are correct that draft-ietf-oauth-token-exchange defines "resource" > for token exchange. However the registry itself doesn't have that level o= f > granularity. It has authorization request, authorization response, token > request, and token response as the possible locations for parameter usage= . > A token exchange request is a particular kind of token request so > draft-ietf-oauth-token-exchange registers "resource" for the token reques= t > location. The IANA section was written before > draft-ietf-oauth-resource-indicators even existed. And leaving the > registration in draft-ietf-oauth-token-exchange seemed like the right thi= ng > to do to even after draft-ietf-oauth-resource-indicators came along. But > I'm not sure, to be honest. Also FWIW a temporary registration entry for = it > is already in > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= parameters > > > > draft-ietf-oauth-resource-indicators defines "resource" for use at the > authorization endpoint (which token exchange does not) so that's the > impetus behind having the registration request there include authorizatio= n > request in the location. draft-ietf-oauth-resource-indicators also has > "resource" for use at the token endpoint using the same semantics as in > draft-ietf-oauth-token-exchange but in a way that is applicable to all > types of token requests to the the token endpoint and not only token > exchange requests. That's where the idea of updating the registry came fr= om > - it's not a name collision and it's not a different definition - it's ju= st > a more generalized usage. > > > > I hope this makes some sense and hasn't muddied the waters more. > > > > > > > > On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw wrote: > > Hi! > > I forgot one more thing about this draft after re-reading > draft-ietf-oauth-token-exchange. > > Per the IANA action in Section 4.1, I need help understanding on the > thinking to resolve this TODO: > > o Parameter usage location: authorization request, token request > [[TODO: draft-ietf-oauth-token-exchange will have already > registered this for 'token request' and this draft has a more > generalized usage and needs to somehow either update that > registration or do a partial registration and reference]] > o Change controller: IESG > o Specification document(s): [[ this specification ]] > > My read of draft-ietf-oauth-token-exchange it that it defines 'resource' > for 'token exchange'. This draft (draft-ietf-oauth-resource-indicators) > has guidance on 'resource' for 'authorization request' but also additiona= l > guidance for 'token request'. Is the token guidance request stated here > applicable to draft-ietf-oauth-token-exchange too (i.e., is the text > effectively saying oauth-resource-indicators updates oauth-token-exhange)= ? > I ask because these drafts don't reference each other. > > Correct me because there is likely a history, but it seems the TODO is > that there is a dependency to resolve and a need to coming up with a way = to > signal in the registry which draft should be read for what usage location= . > Could draft-ietf-oauth-resource-indicators officially register 'resource'= ; > and instead of draft-ietf-oauth-token-exchange including the text definin= g > 'resource' in Section 2.1, it would make a normative reference to Section= 2 > of draft-ietf-oauth-resource-indicators? > > Roman > > > -----Original Message----- > > From: Roman Danyliw > > Sent: Tuesday, July 16, 2019 7:23 PM > > To: oauth@ietf.org > > Subject: AD Review: draft-ietf-oauth-resource-indicators-02 > > > > Hi! > > > > The following is my AD review of draft-ietf-oauth-resource-indicators-0= 2. > > The document is in good shape. > > > > (1) Section 2. Per "The parameter can carry the location of a protected > > resource, typically as an https URL, or a more abstract identifier", is > this > > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986? > > > > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access > > tokens, the authorization server should adapt the scope value associate= d > > with an access token to the value the respective resource is able to > process > > and needs to know": > > > > -- is this language suggesting that the authorization server is > modifying the > > scope value based on the resource it sees? I'm trying to understand wh= at > > "adapt" means, especially in relation to the improved security and > privacy the > > subsequent sentence suggests. > > > > -- (Depending on the above) Is there a security consideration here for > the > > server relative to confidential scope values and how they might be > modified? > > > > (3) Editorial > > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > > > > ** Section 2. Editorial. s/resource at which/resource to which/ > > > > ** Section 2. Editorial. > > s/ And can also be used to inform the client that it has requested an > invalid > > combination of resource and scope./ It can also be used to inform the > client > > that it has requested an invalid combination of resource and scope./ > > > > ** Section 2.1. Multiple Typo. s/an an/an/g > > > > ** Section 2.2. Editorial. s/token request and response/token request > > (Figure 3) and response (Figure 4)/ > > > > ** Section 3. Typo. s/a invalid/an invalid/ > > > > ** Section 3. Missing words. "A bearer token that has multiple intend= ed > > recipients (audiences) can be used by any one of those recipients at an= y > > other." Is it protected resource? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=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._ --000000000000fdca05058e0c880e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roman,

I'm attemp= ting to bring this thread and our private exchanges together (sorry again t= hat it ended up that way) and make sure we are on the same page about the p= ath forward before I start down that path.

Ye= s, your assessment below is correct. And yes I think the changes you propos= ed to IANA section 4 of draft-ietf-oauth-resource-indicators follow from th= at and make sense.

However, draft-ietf-oauth-= token-exchange should also be changed to take on a short sentence in its te= xt about the resource parameter to mention draft-ietf-oauth-resource-indica= tors and include an informational reference to it.

Please confirm that or correct me and I'll proceed with the changes. <= br>



On Wed, Jul 17, 2019 at 5:49 PM Roma= n Danyliw <rdd@cert.or= g> wrote:

Hi Brian!

=C2=A0

Thanks for this background and e= xplanation.=C2=A0 There was history here I didn=E2=80=99t know.

=C2=A0

With the benefit of this thread = and private exchanges, the key takeaways for me are:

=C2=A0

** the definition of 'resour= ce' for 'token exchange' is identical in both drafts (draft-iet= f-oauth-resource-indicator and draft-ietf-oauth-token-exchange)

=C2=A0

** draft-ietf-oauth-resource-ind= icators has additional =E2=80=9Cuses=E2=80=9D of resource not germane to dr= aft-ietf-oauth-resource-indicator

=C2=A0

** the desired ends-state after = the IANA considerations sections of both drafts were process, the Oauth reg= istry would look as follows:

- name =3D resource

- parameter usage location =3D authorization request, token request

- change controller =3D IETF<= /u>

- reference =3D draft-ietf-oauth= -resource-indicator

=C2=A0

Is that right?

=C2=A0

If the above is correct, would t= he following way ahead work:

=C2=A0

** for draft-ietf-oauth-token ex= change: Nothing

=C2=A0

** for draft-ietf-oauth-resource= -indicator

=C2=A0

Per Section 4.1:

=C2=A0

=C2=A0=C2=A0 This specification = updates the following value in the IANA "OAuth

=C2=A0=C2=A0 Parameters" re= gistry [IANA.OAuth.Parameters] established by

=C2=A0=C2=A0 [RFC6749].

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Parameter n= ame: resource

=C2=A0=C2=A0 o=C2=A0 Parameter u= sage location: authorization request, token request

=C2=A0=C2=A0 o=C2=A0 Change cont= roller: IESG

=C2=A0=C2=A0 o=C2=A0 Specificati= on document(s): [[ this specification ]]

=C2=A0

Per Section 4.2

=C2=A0=C2=A0=C2=A0This specifica= tion updates the following error in the IANA "OAuth

=C2=A0=C2=A0 Extensions Error Re= gistry" [IANA.OAuth.Parameters] established by

=C2=A0=C2=A0 [RFC6749].

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Error name:= invalid_target

=C2=A0=C2=A0 o=C2=A0 Error usage= location: implicit grant error response, token error<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 r= esponse

=C2=A0=C2=A0 o=C2=A0 Related pro= tocol extension: resource parameter

=C2=A0=C2=A0 o=C2=A0 Change cont= roller: IESG

=C2=A0=C2=A0 o=C2=A0 Specificati= on document(s): [[ this specification ]]

=C2=A0

Roman

=C2=A0

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Wednesday, July 17, 2019 6:31 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

Yeah, as you surmised, there is some history behind = this. Basically draft-ietf-oauth-token-exchange predates draft-ietf-oauth-r= esource-indicators by a good long time (years) and with the hope and expect= ation that draft-ietf-oauth-token-exchange would move to RFC, I've avoided having a reference in it to a draft mu= ch earlier along in the whole process. draft-ietf-oauth-resource-indicators= has a bit of an odd history too in that an initial call for adoption aroun= d the Buenos Aires meeting kinda fizzled out and it was left for dead until being unexpected resurrected around Mon= treal last year due to renewed interest and other factors I'm still not= sure I understand.=C2=A0

=C2=A0

You are correct that draft-ietf-oauth-token-exchange= defines "resource" for token exchange. However the registry itse= lf doesn't have that level of granularity. It has authorization request= , authorization response, token request, and token response as the possible locations for parameter usage. A token exchange r= equest is a particular kind of token request so draft-ietf-oauth-token-exch= ange registers "resource" for the token request location. The IAN= A section was written before draft-ietf-oauth-resource-indicators even existed. And leaving the registration in draft-ietf-oauth-token-excha= nge seemed like the right thing to do to even after draft-ietf-oauth-resour= ce-indicators came along. But I'm not sure, to be honest. Also FWIW a t= emporary registration entry for it is already in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pa= rameters

=C2=A0

draft-ietf-oauth-resource-indicators defines "r= esource" for use at the authorization endpoint (which token exchange d= oes not) so that's the impetus behind having the registration request t= here include authorization request in the location. draft-ietf-oauth-resource-indicators also has "resource" for use= at the token endpoint using the same semantics as in draft-ietf-oauth-toke= n-exchange but in a way that is applicable to all types of token requests t= o the the token endpoint and not only token exchange requests. That's where the idea of updating the registry came= from - it's not a name collision and it's not a different definiti= on - it's just a more generalized usage.

=C2=A0

I hope this makes some sense and hasn't muddied = the waters more.

=C2=A0

=C2=A0

=C2=A0

On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw <rdd@cert.org> wrote:=

Hi!

I forgot one more thing about this draft after re-reading draft-ietf-oauth-= token-exchange.

Per the IANA action in Section 4.1, I need help understanding on the thinki= ng to resolve this TODO:

=C2=A0 =C2=A0o=C2=A0 Parameter usage location: authorization request, token= request
=C2=A0 =C2=A0 =C2=A0 [[TODO: draft-ietf-oauth-token-exchange will have alre= ady
=C2=A0 =C2=A0 =C2=A0 registered this for 'token request' and this d= raft has a more
=C2=A0 =C2=A0 =C2=A0 generalized usage and needs to somehow either update t= hat
=C2=A0 =C2=A0 =C2=A0 registration or do a partial registration and referenc= e]]
=C2=A0 =C2=A0o=C2=A0 Change controller: IESG
=C2=A0 =C2=A0o=C2=A0 Specification document(s): [[ this specification ]]
My read of draft-ietf-oauth-token-exchange it that it defines 'resource= ' for 'token exchange'.=C2=A0 This draft (draft-ietf-oauth-reso= urce-indicators) has guidance on 'resource' for 'authorization = request' but also additional guidance for 'token request'.=C2= =A0 Is the token guidance request stated here applicable to draft-ietf-oauth-token-ex= change too (i.e., is the text effectively saying oauth-resource-indicators = updates oauth-token-exhange)?=C2=A0 I ask because these drafts don't re= ference each other.

Correct me because there is likely a history, but it seems the TODO is that= there is a dependency to resolve and a need to coming up with a way to sig= nal in the registry which draft should be read for what usage location.=C2= =A0 Could draft-ietf-oauth-resource-indicators officially register 'resource'; and instead of draft-ietf-oauth-to= ken-exchange including the text defining 'resource' in Section 2.1,= it would make a normative reference to Section 2 of draft-ietf-oauth-resou= rce-indicators?

Roman

> -----Original Message-----
> From: Roman Danyliw
> Sent: Tuesday, July 16, 2019 7:23 PM
> To: oauth@ietf.org=
> Subject: AD Review: draft-ietf-oauth-resource-indicators-02
>
> Hi!
>
> The following is my AD review of draft-ietf-oauth-resource-indicators-= 02.
> The document is in good shape.
>
> (1) Section 2. Per "The parameter can carry the location of a pro= tected
> resource, typically as an https URL, or a more abstract identifier&quo= t;, is this
> "abstract identifier" still an absolute URI per Section 4.3 = of RFC3986?
>
> (2) Section 2.2.=C2=A0 in the sentence "To the extent possible, w= hen issuing access
> tokens, the authorization server should adapt the scope value associat= ed
> with an access token to the value the respective resource is able to p= rocess
> and needs to know":
>
> --=C2=A0 is this language suggesting that the authorization server is = modifying the
> scope value based on the resource it sees?=C2=A0 I'm trying to und= erstand what
> "adapt" means, especially in relation to the improved securi= ty and privacy the
> subsequent sentence suggests.
>
> -- (Depending on the above) Is there a security consideration here for= the
> server relative to confidential scope values and how they might be mod= ified?
>
> (3) Editorial
> ** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g
>
> ** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/<= br> >
> ** Section 2.=C2=A0 Editorial.
> s/ And can also be used to inform the client that it has requested an = invalid
> combination of resource and scope./ It can also be used to inform the = client
> that it has requested an invalid combination of resource and scope./ >
> ** Section 2.1. Multiple Typo. s/an an/an/g
>
> ** Section 2.2.=C2=A0 Editorial. s/token request and response/token re= quest
> (Figure 3) and response (Figure 4)/
>
> ** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an invalid/
>
> ** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has= multiple intended
> recipients (audiences) can be used by any one of those recipients at a= ny
> other."=C2=A0 Is it protected resource?

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


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000fdca05058e0c880e-- From nobody Fri Jul 19 16:50: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 50B171200E6 for ; Fri, 19 Jul 2019 16:50: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_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 NxYLRQn1MdXq for ; Fri, 19 Jul 2019 16:50:10 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E990F120033 for ; Fri, 19 Jul 2019 16:50:09 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h6so61902147iom.7 for ; Fri, 19 Jul 2019 16:50:09 -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; bh=kHX7JHcX/wjB8hjTfUMxTrLaPTNka6wC4v45CpwlBKc=; b=JccImfMXqhePuQbcr3PaTIWX6S/f5O/pt1+FGCXwVzRtxMC1gGwD5n1AFfu9GYrD4J k1HhWWI34gj/byQDLXmfdQRrQAnY2mo1y1cxY+L7Tx7lE1XJg/cvPajR5waARoQNdnzd QGQtRaF/w15WUMpdR+VXxHp+dSHruft/qEpz7o+Sr/OxBDG5OJgs4RBeSF3cARSPfPrC gjT/dTA9Jjm2091RHZcvTnPqHE4n9bTPYmh7yZsx/P3f2KxDAlCoY+I/DdrFQ0GXgWMm K/Pc7zFj3tZBB18Ngyl0cz9P7dluiuLQMyMVO75algJNtjqHY8PRVcA/melKiGtn05Ce XCHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kHX7JHcX/wjB8hjTfUMxTrLaPTNka6wC4v45CpwlBKc=; b=QoI/Wn/ULpAArvrTE3mZEHetkKbJQR2EOuUU/PxspoaYluEeclhtlX7GMh/YE60Zq8 uHedFjQoXyzRxsc40MCpVFUWpeEEuE+MsXWFMtCwc84l9GoSHPxJPAYmqBTmfeJxWBCw /dxdJdoUlhMcTWGatebyH1vU9pd5WdwxzCah1GxZDbC/792YB79Iv5W+bOCmGsA8g8V9 Yl7WwTdGuEA50k/Zksm2TBva3mz3LrRtCsjfNVzWYxCH5x0OEPX71SDOOuUGHY398WsN 0ZCeAkgl4RAu1XBtyqsPeXQZFhrIaBrrlLom7R3zZrMS6yR05wXyW/4gVW0WviBKZCJN bwkw== X-Gm-Message-State: APjAAAWDRZUq7FrexC8rs/ShLdfAL9aLosaNc2bOiQ6m0X9/H6gbc8vq coBgvWnXn9YGHhMrESKvfZXsk1XZ X-Google-Smtp-Source: APXvYqwl4M20tLDkm7MwfRWZ8MxA/ZYKAq4udtVDYrjpjiQn5LCRakG9I0CpEAc+JbPm+waj+cvuFA== X-Received: by 2002:a6b:da01:: with SMTP id x1mr26980388iob.216.1563580208817; Fri, 19 Jul 2019 16:50:08 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id i4sm46278844iog.31.2019.07.19.16.50.07 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 16:50:07 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id f4so61944114ioh.6 for ; Fri, 19 Jul 2019 16:50:07 -0700 (PDT) X-Received: by 2002:a6b:f816:: with SMTP id o22mr25985342ioh.166.1563580207343; Fri, 19 Jul 2019 16:50:07 -0700 (PDT) MIME-Version: 1.0 References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> In-Reply-To: <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> From: Aaron Parecki Date: Fri, 19 Jul 2019 18:49:38 -0500 X-Gmail-Original-Message-ID: Message-ID: To: George Fletcher , OAuth WG Content-Type: multipart/alternative; boundary="000000000000d62e3e058e11624d" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 23:50:13 -0000 --000000000000d62e3e058e11624d Content-Type: text/plain; charset="UTF-8" So what I'm hearing in this thread is essentially that: 1) depending on how it's implemented, using a refresh token in a SPA can provide security benefits over using only access tokens 2) it is still "dangerous" to allow refresh tokens to be used without client authentication 3) if there is a way to do some sort of dynamic client registration or proof of possession, then using a refresh token would in fact be more secure Since these points are in conflict with each other, and depend on things currently in flux, it seems like the best thing to do at this time is to remove the guidance on refresh tokens in browser-based apps. Maybe leaving the mention of rotating the refresh token on every use, but I'm inclined to remove the "SHOULD NOT issue refresh tokens" statement in order to leave room for DPoP or similar in the future. Sound reasonable? ---- Aaron Parecki aaronparecki.com @aaronpk On Thu, Jul 11, 2019 at 2:52 PM George Fletcher wrote: > You are correct that client authentication is not required for public > clients (which doesn't preclude the use of refresh_tokens) but from my > perspective it weakens the security because anyone with the refresh_token > is able to get new access_tokens without any additional proof. > > Now if the SPA performs some sort of Dynamic Client Registration or DPoP > then I think it's a completely different scenario and it doesn't bother me > as much for their to be refresh_tokens in the browser. This of course is > just my perspective:) > > On 7/10/19 7:56 PM, Aaron Parecki wrote: > > 2. To use a refresh token at the /token endpoint, client authentication is >> required. This is where it gets difficult for default SPAs because they are >> public clients and the only mechanism to authenticate them is the client_id >> which is itself public. For me, this is the real risk of exposing the >> refresh_token in the browser.?? > > > RFC6749 says "If the client type is confidential or??the client was issued > client credentials,??the client MUST authenticate..." which I take to mean > that refresh tokens could be used without a client_secret, both for native > an javascript apps. > > This discussion of offline vs online refresh tokens is interesting, but I > worry that we may be narrowing our focus here too much. > > There's a use where JavaScript apps may be able to take advantage of > offline access, which is around Service Workers. This allows a website to > install some code from a website which can continue to run in the > background, though sometimes only while triggered from external events. One > useful example of this is a syncing daemon, where a push notification can > be sent from a web server to a Service Worker, which could cause that code > in the browser to need to make a request to an API, which then may need to > be able to get a new access token, which is effectively offline access. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > >> I'll just add a couple more thoughts around refresh_tokens. >> >> 1. I agree with David that refresh_tokens are valuable in an "online" >> scenario and should be used there. >> >> 2. To use a refresh token at the /token endpoint, client authentication >> is required. This is where it gets difficult for default SPAs because they >> are public clients and the only mechanism to authenticate them is the >> client_id which is itself public. For me, this is the real risk of exposing >> the refresh_token in the browser. >> >> 3. If the AS supports rotation of refresh_tokens and an attacker steals >> one and uses it, then the SPA will get an error on it's next attempt >> because it's refresh_token will now be invalid. If the refresh_tokens are >> bound to the user's authentication session, then the user can logout to >> lockout the attacker. However, that is a lot of "ifs" and still provides >> the attacker with time to leverage access via the compromised refresh_token. >> >> In principle, I agree with the recommendation that SPAs shouldn't have >> refresh_tokens in the browser. If it's not possible to easily refresh the >> access token via a hidden iframe (becoming more difficult with all the >> browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a >> simple server component such that the backend for the SPA can use >> authorization_code flow and protect a client_secret. >> >> Thanks, >> George >> >> On 7/8/19 11:17 PM, David Waite wrote: >> >> >> On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: >> Re 8. Refresh Tokens >> >> ???? "For public clients, the risk of a leaked refresh token is much >> ?? ??greater than leaked access tokens, since an attacker can potentially >> ?? ??continue using the stolen refresh token to obtain new access without >> ?? ??being detectable by the authorization server.?? " >> >> (first, note the typo "stoken".) >> >> Is it always "higher risk"??? I could even argue that leakage of a >> refresh token is lower risk. As a bearer document, a leaked access token >> allows access to resources until it expires.?? A leaked refresh token, to >> be useful,?? requires an exchange with the AS, and the AS would have the >> opportunity to check whether the refresh token is still valid (has not been >> revoked).?? (of course revocation might NOT have happened, but then again, >> it might have.) >> >> >> I agree (with caveats, of course). >> >> Access tokens and refresh tokens may or may not be attached (by policy) >> to an authentication session lifetime. It is far easier to picture refresh >> tokens which are not attached to an authentication session (sometimes >> called ???offline??? access) being inappropriate for a browser-based app, >> which is nearly always a client that the resource owner is interacting with. >> >> Variants that may want offline tokens are less easy to imagine - perhaps >> browser extensions? >> >> I believe the language currently there is due to AS implementations >> predominantly treating refresh tokens as being for offline access, and >> access token lifetime being short enough to not outlast an authentication >> session. >> >> Furthermore, since the access token is transmitted to other servers, the >> risk of exposure is greater, due to possible vulnerabilities in those >> called systems (e.g., logs).?? Isn't this the reason that we have refresh >> tokens? Don't refresh tokens exist because access tokens should have short >> TTL, because they are widely distributed? >> >> >> Yes. Once you acknowledge the existence of ???online??? refresh tokens, >> they become a strong security component: >> >> - Refresh tokens let you shorten the access token lifetime >> - A shorter access token lifetime lets you have centralized policy to >> invalidate access without needing to resort to token >> introspection/revocation >> - Token refresh can theoretically be used to represent other policy >> changes by both the client (creating tokens targeting a new resource server >> or with reduced scopes) and server (changing entitlements and >> attributes/claims embedded within a structured token) >> - Refresh tokens can be one-time-use, as recommenced by the security BCP. >> A exfiltrated refresh token will result in either the attacker or the user >> losing access on the next refresh, and a double refresh is a detectable >> security event by the AS. >> >> "Additionally, browser-based applications provide many attack vectors by >> which a refresh token can be leaked." >> >> The risks of leaking a refresh token from the browser are identical to >> the risks of leaking an access token, right??? This sentence could be >> changed to "... by which *a token* can be leaked." >> >> A refresh token is "higher risk" because its TTL is usually greater than >> the access token's TTL.?? But if our advice here leads to people using >> longer-lived access tokens (because of the problems with getting a new >> access token without involving the user), then the advice will be counter >> productive.???? The longer life gives more time for the usefulness of a >> browser-side theft, and more time for the usefulness of a server-side >> theft.?? >> >> Which scenario is safer? >> >> A) using an access token with a 10 minute TTL, accompanied by a refresh >> token with a 1 hour TTL >> B) using an access token with a 1 hour TTL, and no refresh token.?? >> >> >> >> Given tokens that track authentication lifetime, it is hard to make a >> case that refresh tokens which last for the authentication session are a >> greater security risk than opaque access tokens (requiring token >> introspection) that will last the same time.?? >> >> Typically an AS (or OP) would issue a structured access token with a >> lifetime expected to expire before the authentication session, with new >> tokens issued via requests made in an embedded, iframe (hidden, >> prompt=none). There may be benefits here of user cookies (or perhaps >> managed-device information) against an authorization endpoint being used to >> make decisions that could not be made by a refresh against the token >> endpoint.?? >> >> I???d be interested in hearing how strong of an implementation issue this >> might be for deployments - I could see a non-security argument that the BCP >> should only have one recommended approach here, and that there are >> deployments needing the iframe approach. >> >> -DW >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf..org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --000000000000d62e3e058e11624d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So what I'm hearing in this thread is essentially that= :

1) depending on how it's implemented, using a refr= esh token in a SPA can provide security benefits over using only access tok= ens
2) it is still "dangerous" to allow refresh tokens = to be used without client authentication
3) if there is a way to = do some sort of dynamic client registration or proof of possession, then us= ing a refresh token would in fact be more secure

S= ince these points are in conflict with each other, and depend on things cur= rently in flux, it seems like the best thing to do at this time is to remov= e the guidance on refresh tokens in browser-based apps. Maybe leaving the m= ention of rotating the refresh token on every use, but I'm inclined to = remove the "SHOULD NOT issue refresh tokens" statement in order t= o leave room for DPoP or similar in the future.

So= und reasonable?

----
Aaron= Parecki



On= Thu, Jul 11, 2019 at 2:52 PM George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP then I think it's a completely different scenario and it doesn't bother me as much for their to be refresh_tokens in the browser. This of course is just my perspective:)

On 7/10/19 7= :56 PM, Aaron Parecki wrote:
=20
2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.??

RFC6749 says "If the client type is confidential or??= the client was issued client credentials,??the client MUST authenticate..." which I take to mean that refresh token= s could be used without a client_secret, both for native an javascript apps.

This discussion of offline vs online refresh tokens is interesting, but I worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be able to tak= e advantage of offline access, which is around Service Workers. This allows a website to install some code from a website which can continue to run in the background, though sometimes only while triggered from external events. One useful example of this is a syncing daemon, where a push notification can be sent from a web server to a Service Worker, which could cause that code in the browser to need to make a request to an API, which then may need to be able to get a new access token, which is effectively offline access.

----
Aaron Parecki



On Tue, Jul 9, 2019 at 9:16 A= M George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token= will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout t= o lockout the attacker. However, that is a lot of "ifs&quo= t; and still provides the attacker with time to leverage access via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's= not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com&g= t; wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could = even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perhaps browser extensions?

I believe the language currently there is due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

"Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a token can be leaked."

A refresh token is "higher risk" becau= se its TTL is usually greater than the access token's TTL.?? But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??

Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=3Dnone). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??

I???d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW


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

--000000000000d62e3e058e11624d-- From nobody Fri Jul 19 17:03:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC4120041 for ; Fri, 19 Jul 2019 17:03:22 -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 0Iunw_5mG1-9 for ; Fri, 19 Jul 2019 17:03:20 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A3B120033 for ; Fri, 19 Jul 2019 17:03:20 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id e20so31616762iob.9 for ; Fri, 19 Jul 2019 17:03:20 -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=G4UvqKHWA6R7nJUCDolGMqFns+FYH0Z5wdUbHcBuL6s=; b=q9srlFMXetAkNbYPfnC6v4ZYYnVNccFqkOXyMsTla+jnTHYO77rPGwx52B4mr0wavl eYh9eTLU6zpZ8ZL00HLlnQKzrLTunEtSqsKO04VVDJnsz+xHCjkbzJZHo3FLcnQ7brLT yRw+sWFtScw54RM/Q7ozo1LUNv1F6h3GCjcUaasNvYyoTQC4oSkXP9C1Q0xthoCK4XNs LIpVbEYtVXZu81Ty2ZZ41PiThsyL3KEex+na4uroZ5zYciZJIbS/Bn+oCmjSQXQ1D5gE 1A4jOothP9qJe33cjJo1IUB0mwOE2bHA4rjja7jf+NjIFj75kXmUC1bDJ6CcjTJx3zBq iW4Q== 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=G4UvqKHWA6R7nJUCDolGMqFns+FYH0Z5wdUbHcBuL6s=; b=PMlit2EEt1tgvYT+jkuoWcYbZw1yqt7rdRmXHE0Z+DnMFlxcAD7akv3TlBw5fngeQr Z8mMZEdMzhhG5HihijlZh+0bR1kG5S8RgchEudhznHnZRB1B+ovypDR0h3+eLPhNwKjU 4un/rRfvSvJ7zXmpyToTTxteFGU1fw19S7lS12Bo4xqM+3OLCjEBX6Zxq+J2SWUgM3T8 ct0BgMS72QOiKpLaV9c7iKX8rupcclI5Vxb2nPtAOUszvdFJva+ZmcZaFt1tAiEqOt+3 oGfOyGm0NZb/XgJOHTUbPZtklNl0QPEyKnP8RxtP4e14650ZgPNaOVbmqz/OxtvrEk80 +AVA== X-Gm-Message-State: APjAAAWPsQEIcQ/t0bqm7+Fx4f55xdCVAxPRxs4yS3+AiS/FHrcTkPJ3 vUPPAK+Vi5e/a7T/cB/qY3QD95DO X-Google-Smtp-Source: APXvYqzDVAowGuF0gsDpdXaKTMAGmvfNvIt6MOYcMMlGLUF52BdIRiWDp9+S/G8tS7AyPc6uLowgcQ== X-Received: by 2002:a6b:ba88:: with SMTP id k130mr49747905iof.212.1563580998868; Fri, 19 Jul 2019 17:03:18 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com. [209.85.166.44]) by smtp.gmail.com with ESMTPSA id r5sm29504787iom.42.2019.07.19.17.03.17 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 17:03:17 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id k20so61939067ios.10 for ; Fri, 19 Jul 2019 17:03:17 -0700 (PDT) X-Received: by 2002:a5e:db0a:: with SMTP id q10mr35579587iop.168.1563580997656; Fri, 19 Jul 2019 17:03:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Fri, 19 Jul 2019 19:02:49 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f16999058e119169" Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jul 2019 00:03:22 -0000 --000000000000f16999058e119169 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I'm looking forward to the discussion on this on Tuesday! I wanted to add my thoughts on a potential addition to this draft, specifically around returning some minimal user information in the transaction response. The summary of the suggestion is to return a new "user" key along with the access token that contains the user ID and userinfo endpoint, such as: { "access_token": { "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type": "bearer" }, "user": { "id": "5035678642", "userinfo": "https://authorization-server.com/user/5035678642" } } A more detailed analysis of the specific proposal and motivation behind this is available on my blog: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz Thanks! ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jul 9, 2019 at 2:48 PM Justin Richer wrote: > I have requested time to present Transactional Authorization (the XYZ > project) at the Montreal meeting in a couple weeks. Ahead of that, I=E2= =80=99ve > uploaded a new version of the spec: > > https://tools.ietf.org/html/draft-richer-transactional-authz-02 > > Additionally, I=E2=80=99ve updated the writeup and examples on https://oa= uth.xyz/ > > I plan to be in Montreal for the whole week, and I=E2=80=99ve requested f= rom the > chairs that I present during the Tuesday session due to limited > availability of some key WG members on Friday. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000f16999058e119169 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all, I'm looking forward to the discussion on this = on Tuesday!

I wanted to add my thoughts on a potential a= ddition to this draft, specifically around returning some minimal user info= rmation in the transaction response.

The summary o= f the suggestion is to return a new "user" key along with the acc= ess token that contains the user ID and userinfo endpoint, such as:

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0=C2=A0=C2=A0 "access= _token": {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "value": &quo= t;UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0 "type": "bearer"
=C2=A0 =C2=A0=C2=A0=C2= =A0 },
=C2=A0 =C2=A0=C2=A0=C2=A0 "user": {
=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0 "id": "5035678642",
=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0 "userinfo": "https://authorization-server.com/user/503= 5678642"
=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0 =C2=A0=C2=A0}

A more detailed analysis of the specific proposal and = motivation behind this is available on my blog:

htt= ps://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

Thanks!

----
Aaron Parecki



On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jricher@mit.edu> wrote:
I have requested time to present Transactional Authorization (the XYZ proje= ct) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve = uploaded a new version of the spec:


Additionally, I=E2=80=99ve updated the writeup and examples on https://oauth.xyz/=C2=A0

I plan to be in Montreal for the whole week, and I=E2=80=99ve requeste= d from the chairs that I present during the Tuesday session due to limited = availability of some key WG members on Friday.=C2=A0

=E2=80=94 Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f16999058e119169-- From nobody Fri Jul 19 17:17: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 C281C12007C for ; Fri, 19 Jul 2019 17:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 042opbiJn_wn for ; Fri, 19 Jul 2019 17:17:36 -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 7FF63120041 for ; Fri, 19 Jul 2019 17:17:36 -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 x6K0HZhr011234; Fri, 19 Jul 2019 20:17:35 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6K0HZhr011234 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563581855; bh=CHeidjhaVKlRqkFkjBNR7rIQsjsKbmVrYBMjoRG/pXs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=fbugiJTmfTFcXj6NENrP2CPrvUhHFXhwN+x/WzG4GDakZKUGI77lOmgTz6Z966vQ+ C6uAGuD0+vIPgpodIDFORtTUNEzo/f7zG73GteXNrusiiq9Y6sq2mXqpmJwY2O8wBo lzfZlwc/oL9BMZCHxGlFoYk430EL9Xd8WTISV/Bw= 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 x6K0HZKK007604; Fri, 19 Jul 2019 20:17:35 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 20:17:34 -0400 From: Roman Danyliw To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgAs5qCAAAwaLYAABpg1EABUm60AAASSfWA= Date: Sat, 20 Jul 2019 00:17:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DBDE8@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D76EF@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D7BC9@marchand> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33DBDE8marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 00:17:40 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33DBDE8marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMTksIDIwMTkgMjowMiBQTQ0KVG86IFJv bWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMtMDINCg0KVGhhbmtzIFJvbWFuLA0KDQpJJ20gYXR0ZW1wdGluZyB0byBicmluZyB0aGlz IHRocmVhZCBhbmQgb3VyIHByaXZhdGUgZXhjaGFuZ2VzIHRvZ2V0aGVyIChzb3JyeSBhZ2FpbiB0 aGF0IGl0IGVuZGVkIHVwIHRoYXQgd2F5KSBhbmQgbWFrZSBzdXJlIHdlIGFyZSBvbiB0aGUgc2Ft ZSBwYWdlIGFib3V0IHRoZSBwYXRoIGZvcndhcmQgYmVmb3JlIEkgc3RhcnQgZG93biB0aGF0IHBh dGguDQoNClllcywgeW91ciBhc3Nlc3NtZW50IGJlbG93IGlzIGNvcnJlY3QuIEFuZCB5ZXMgSSB0 aGluayB0aGUgY2hhbmdlcyB5b3UgcHJvcG9zZWQgdG8gSUFOQSBzZWN0aW9uIDQgb2YgZHJhZnQt aWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIGZvbGxvdyBmcm9tIHRoYXQgYW5kIG1ha2Ug c2Vuc2UuDQoNCltSb21hbl0gIE9rLg0KDQpIb3dldmVyLCBkcmFmdC1pZXRmLW9hdXRoLXRva2Vu LWV4Y2hhbmdlIHNob3VsZCBhbHNvIGJlIGNoYW5nZWQgdG8gdGFrZSBvbiBhIHNob3J0IHNlbnRl bmNlIGluIGl0cyB0ZXh0IGFib3V0IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgdG8gbWVudGlvbiBk cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgYW5kIGluY2x1ZGUgYW4gaW5mb3Jt YXRpb25hbCByZWZlcmVuY2UgdG8gaXQuDQoNCltSb21hbl0gQ29ycmVjdC4NCg0KUGxlYXNlIGNv bmZpcm0gdGhhdCBvciBjb3JyZWN0IG1lIGFuZCBJJ2xsIHByb2NlZWQgd2l0aCB0aGUgY2hhbmdl cy4NCg0KVGhhbmtzIGZvciB0aGUgaXRlcmF0aW9uIGFuZCBleHBsYW5hdGlvbnMhDQoNClJvbWFu DQoNCg0KT24gV2VkLCBKdWwgMTcsIDIwMTkgYXQgNTo0OSBQTSBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+IHdyb3RlOg0KSGkgQnJpYW4hDQoNClRoYW5r cyBmb3IgdGhpcyBiYWNrZ3JvdW5kIGFuZCBleHBsYW5hdGlvbi4gIFRoZXJlIHdhcyBoaXN0b3J5 IGhlcmUgSSBkaWRu4oCZdCBrbm93Lg0KDQpXaXRoIHRoZSBiZW5lZml0IG9mIHRoaXMgdGhyZWFk IGFuZCBwcml2YXRlIGV4Y2hhbmdlcywgdGhlIGtleSB0YWtlYXdheXMgZm9yIG1lIGFyZToNCg0K KiogdGhlIGRlZmluaXRpb24gb2YgJ3Jlc291cmNlJyBmb3IgJ3Rva2VuIGV4Y2hhbmdlJyBpcyBp ZGVudGljYWwgaW4gYm90aCBkcmFmdHMgKGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9yIGFuZCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlKQ0KDQoqKiBkcmFmdC1pZXRm LW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgaGFzIGFkZGl0aW9uYWwg4oCcdXNlc+KAnSBvZiBy ZXNvdXJjZSBub3QgZ2VybWFuZSB0byBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRv cg0KDQoqKiB0aGUgZGVzaXJlZCBlbmRzLXN0YXRlIGFmdGVyIHRoZSBJQU5BIGNvbnNpZGVyYXRp b25zIHNlY3Rpb25zIG9mIGJvdGggZHJhZnRzIHdlcmUgcHJvY2VzcywgdGhlIE9hdXRoIHJlZ2lz dHJ5IHdvdWxkIGxvb2sgYXMgZm9sbG93czoNCi0gbmFtZSA9IHJlc291cmNlDQotIHBhcmFtZXRl ciB1c2FnZSBsb2NhdGlvbiA9IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdA0K LSBjaGFuZ2UgY29udHJvbGxlciA9IElFVEYNCi0gcmVmZXJlbmNlID0gZHJhZnQtaWV0Zi1vYXV0 aC1yZXNvdXJjZS1pbmRpY2F0b3INCg0KSXMgdGhhdCByaWdodD8NCg0KSWYgdGhlIGFib3ZlIGlz IGNvcnJlY3QsIHdvdWxkIHRoZSBmb2xsb3dpbmcgd2F5IGFoZWFkIHdvcms6DQoNCioqIGZvciBk cmFmdC1pZXRmLW9hdXRoLXRva2VuIGV4Y2hhbmdlOiBOb3RoaW5nDQoNCioqIGZvciBkcmFmdC1p ZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcg0KDQpQZXIgU2VjdGlvbiA0LjE6DQoNCiAgIFRo aXMgc3BlY2lmaWNhdGlvbiB1cGRhdGVzIHRoZSBmb2xsb3dpbmcgdmFsdWUgaW4gdGhlIElBTkEg Ik9BdXRoDQogICBQYXJhbWV0ZXJzIiByZWdpc3RyeSBbSUFOQS5PQXV0aC5QYXJhbWV0ZXJzXSBl c3RhYmxpc2hlZCBieQ0KICAgW1JGQzY3NDldLg0KDQogICBvICBQYXJhbWV0ZXIgbmFtZTogcmVz b3VyY2UNCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1 ZXN0LCB0b2tlbiByZXF1ZXN0DQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVTRw0KICAgbyAg U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBzcGVjaWZpY2F0aW9uIF1dDQoNClBl ciBTZWN0aW9uIDQuMg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgdGhlIGZvbGxvd2lu ZyBlcnJvciBpbiB0aGUgSUFOQSAiT0F1dGgNCiAgIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnki IFtJQU5BLk9BdXRoLlBhcmFtZXRlcnNdIGVzdGFibGlzaGVkIGJ5DQogICBbUkZDNjc0OV0uDQoN CiAgIG8gIEVycm9yIG5hbWU6IGludmFsaWRfdGFyZ2V0DQogICBvICBFcnJvciB1c2FnZSBsb2Nh dGlvbjogaW1wbGljaXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2UsIHRva2VuIGVycm9yDQogICAgICBy ZXNwb25zZQ0KICAgbyAgUmVsYXRlZCBwcm90b2NvbCBleHRlbnNpb246IHJlc291cmNlIHBhcmFt ZXRlcg0KICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFU0cNCiAgIG8gIFNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6IFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBdXQ0KDQpSb21hbg0KDQoNCkZyb206 IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNywg MjAxOSA2OjMxIFBNDQpUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRA Y2VydC5vcmc+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyDQoNClllYWgsIGFzIHlvdSBzdXJtaXNlZCwgdGhlcmUgaXMgc29tZSBo aXN0b3J5IGJlaGluZCB0aGlzLiBCYXNpY2FsbHkgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZSBwcmVkYXRlcyBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgYnkgYSBn b29kIGxvbmcgdGltZSAoeWVhcnMpIGFuZCB3aXRoIHRoZSBob3BlIGFuZCBleHBlY3RhdGlvbiB0 aGF0IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2Ugd291bGQgbW92ZSB0byBSRkMsIEkn dmUgYXZvaWRlZCBoYXZpbmcgYSByZWZlcmVuY2UgaW4gaXQgdG8gYSBkcmFmdCBtdWNoIGVhcmxp ZXIgYWxvbmcgaW4gdGhlIHdob2xlIHByb2Nlc3MuIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycyBoYXMgYSBiaXQgb2YgYW4gb2RkIGhpc3RvcnkgdG9vIGluIHRoYXQgYW4gaW5p dGlhbCBjYWxsIGZvciBhZG9wdGlvbiBhcm91bmQgdGhlIEJ1ZW5vcyBBaXJlcyBtZWV0aW5nIGtp bmRhIGZpenpsZWQgb3V0IGFuZCBpdCB3YXMgbGVmdCBmb3IgZGVhZCB1bnRpbCBiZWluZyB1bmV4 cGVjdGVkIHJlc3VycmVjdGVkIGFyb3VuZCBNb250cmVhbCBsYXN0IHllYXIgZHVlIHRvIHJlbmV3 ZWQgaW50ZXJlc3QgYW5kIG90aGVyIGZhY3RvcnMgSSdtIHN0aWxsIG5vdCBzdXJlIEkgdW5kZXJz dGFuZC4NCg0KWW91IGFyZSBjb3JyZWN0IHRoYXQgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZSBkZWZpbmVzICJyZXNvdXJjZSIgZm9yIHRva2VuIGV4Y2hhbmdlLiBIb3dldmVyIHRoZSBy ZWdpc3RyeSBpdHNlbGYgZG9lc24ndCBoYXZlIHRoYXQgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIEl0 IGhhcyBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2Vu IHJlcXVlc3QsIGFuZCB0b2tlbiByZXNwb25zZSBhcyB0aGUgcG9zc2libGUgbG9jYXRpb25zIGZv ciBwYXJhbWV0ZXIgdXNhZ2UuIEEgdG9rZW4gZXhjaGFuZ2UgcmVxdWVzdCBpcyBhIHBhcnRpY3Vs YXIga2luZCBvZiB0b2tlbiByZXF1ZXN0IHNvIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFu Z2UgcmVnaXN0ZXJzICJyZXNvdXJjZSIgZm9yIHRoZSB0b2tlbiByZXF1ZXN0IGxvY2F0aW9uLiBU aGUgSUFOQSBzZWN0aW9uIHdhcyB3cml0dGVuIGJlZm9yZSBkcmFmdC1pZXRmLW9hdXRoLXJlc291 cmNlLWluZGljYXRvcnMgZXZlbiBleGlzdGVkLiBBbmQgbGVhdmluZyB0aGUgcmVnaXN0cmF0aW9u IGluIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2Ugc2VlbWVkIGxpa2UgdGhlIHJpZ2h0 IHRoaW5nIHRvIGRvIHRvIGV2ZW4gYWZ0ZXIgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzIGNhbWUgYWxvbmcuIEJ1dCBJJ20gbm90IHN1cmUsIHRvIGJlIGhvbmVzdC4gQWxzbyBG V0lXIGEgdGVtcG9yYXJ5IHJlZ2lzdHJhdGlvbiBlbnRyeSBmb3IgaXQgaXMgYWxyZWFkeSBpbiBo dHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBh cmFtZXRlcnMueGh0bWwjcGFyYW1ldGVycw0KDQpkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcnMgZGVmaW5lcyAicmVzb3VyY2UiIGZvciB1c2UgYXQgdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQgKHdoaWNoIHRva2VuIGV4Y2hhbmdlIGRvZXMgbm90KSBzbyB0aGF0J3MgdGhlIGlt cGV0dXMgYmVoaW5kIGhhdmluZyB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgdGhlcmUgaW5jbHVk ZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW4gdGhlIGxvY2F0aW9uLiBkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnMgYWxzbyBoYXMgInJlc291cmNlIiBmb3IgdXNlIGF0IHRoZSB0 b2tlbiBlbmRwb2ludCB1c2luZyB0aGUgc2FtZSBzZW1hbnRpY3MgYXMgaW4gZHJhZnQtaWV0Zi1v YXV0aC10b2tlbi1leGNoYW5nZSBidXQgaW4gYSB3YXkgdGhhdCBpcyBhcHBsaWNhYmxlIHRvIGFs bCB0eXBlcyBvZiB0b2tlbiByZXF1ZXN0cyB0byB0aGUgdGhlIHRva2VuIGVuZHBvaW50IGFuZCBu b3Qgb25seSB0b2tlbiBleGNoYW5nZSByZXF1ZXN0cy4gVGhhdCdzIHdoZXJlIHRoZSBpZGVhIG9m IHVwZGF0aW5nIHRoZSByZWdpc3RyeSBjYW1lIGZyb20gLSBpdCdzIG5vdCBhIG5hbWUgY29sbGlz aW9uIGFuZCBpdCdzIG5vdCBhIGRpZmZlcmVudCBkZWZpbml0aW9uIC0gaXQncyBqdXN0IGEgbW9y ZSBnZW5lcmFsaXplZCB1c2FnZS4NCg0KSSBob3BlIHRoaXMgbWFrZXMgc29tZSBzZW5zZSBhbmQg aGFzbid0IG11ZGRpZWQgdGhlIHdhdGVycyBtb3JlLg0KDQoNCg0KT24gV2VkLCBKdWwgMTcsIDIw MTkgYXQgMzoxMyBQTSBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0 Lm9yZz4+IHdyb3RlOg0KSGkhDQoNCkkgZm9yZ290IG9uZSBtb3JlIHRoaW5nIGFib3V0IHRoaXMg ZHJhZnQgYWZ0ZXIgcmUtcmVhZGluZyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLg0K DQpQZXIgdGhlIElBTkEgYWN0aW9uIGluIFNlY3Rpb24gNC4xLCBJIG5lZWQgaGVscCB1bmRlcnN0 YW5kaW5nIG9uIHRoZSB0aGlua2luZyB0byByZXNvbHZlIHRoaXMgVE9ETzoNCg0KICAgbyAgUGFy YW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIHRva2VuIHJlcXVl c3QNCiAgICAgIFtbVE9ETzogZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSB3aWxsIGhh dmUgYWxyZWFkeQ0KICAgICAgcmVnaXN0ZXJlZCB0aGlzIGZvciAndG9rZW4gcmVxdWVzdCcgYW5k IHRoaXMgZHJhZnQgaGFzIGEgbW9yZQ0KICAgICAgZ2VuZXJhbGl6ZWQgdXNhZ2UgYW5kIG5lZWRz IHRvIHNvbWVob3cgZWl0aGVyIHVwZGF0ZSB0aGF0DQogICAgICByZWdpc3RyYXRpb24gb3IgZG8g YSBwYXJ0aWFsIHJlZ2lzdHJhdGlvbiBhbmQgcmVmZXJlbmNlXV0NCiAgIG8gIENoYW5nZSBjb250 cm9sbGVyOiBJRVNHDQogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIHNw ZWNpZmljYXRpb24gXV0NCg0KTXkgcmVhZCBvZiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hh bmdlIGl0IHRoYXQgaXQgZGVmaW5lcyAncmVzb3VyY2UnIGZvciAndG9rZW4gZXhjaGFuZ2UnLiAg VGhpcyBkcmFmdCAoZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzKSBoYXMgZ3Vp ZGFuY2Ugb24gJ3Jlc291cmNlJyBmb3IgJ2F1dGhvcml6YXRpb24gcmVxdWVzdCcgYnV0IGFsc28g YWRkaXRpb25hbCBndWlkYW5jZSBmb3IgJ3Rva2VuIHJlcXVlc3QnLiAgSXMgdGhlIHRva2VuIGd1 aWRhbmNlIHJlcXVlc3Qgc3RhdGVkIGhlcmUgYXBwbGljYWJsZSB0byBkcmFmdC1pZXRmLW9hdXRo LXRva2VuLWV4Y2hhbmdlIHRvbyAoaS5lLiwgaXMgdGhlIHRleHQgZWZmZWN0aXZlbHkgc2F5aW5n IG9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgdXBkYXRlcyBvYXV0aC10b2tlbi1leGhhbmdlKT8g IEkgYXNrIGJlY2F1c2UgdGhlc2UgZHJhZnRzIGRvbid0IHJlZmVyZW5jZSBlYWNoIG90aGVyLg0K DQpDb3JyZWN0IG1lIGJlY2F1c2UgdGhlcmUgaXMgbGlrZWx5IGEgaGlzdG9yeSwgYnV0IGl0IHNl ZW1zIHRoZSBUT0RPIGlzIHRoYXQgdGhlcmUgaXMgYSBkZXBlbmRlbmN5IHRvIHJlc29sdmUgYW5k IGEgbmVlZCB0byBjb21pbmcgdXAgd2l0aCBhIHdheSB0byBzaWduYWwgaW4gdGhlIHJlZ2lzdHJ5 IHdoaWNoIGRyYWZ0IHNob3VsZCBiZSByZWFkIGZvciB3aGF0IHVzYWdlIGxvY2F0aW9uLiAgQ291 bGQgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIG9mZmljaWFsbHkgcmVnaXN0 ZXIgJ3Jlc291cmNlJzsgYW5kIGluc3RlYWQgb2YgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNo YW5nZSBpbmNsdWRpbmcgdGhlIHRleHQgZGVmaW5pbmcgJ3Jlc291cmNlJyBpbiBTZWN0aW9uIDIu MSwgaXQgd291bGQgbWFrZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gU2VjdGlvbiAyIG9mIGRy YWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycz8NCg0KUm9tYW4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb21hbiBEYW55bGl3DQo+IFNlbnQ6IFR1ZXNk YXksIEp1bHkgMTYsIDIwMTkgNzoyMyBQTQ0KPiBUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoQGlldGYub3JnPg0KPiBTdWJqZWN0OiBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVz b3VyY2UtaW5kaWNhdG9ycy0wMg0KPg0KPiBIaSENCj4NCj4gVGhlIGZvbGxvd2luZyBpcyBteSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyLg0KPiBU aGUgZG9jdW1lbnQgaXMgaW4gZ29vZCBzaGFwZS4NCj4NCj4gKDEpIFNlY3Rpb24gMi4gUGVyICJU aGUgcGFyYW1ldGVyIGNhbiBjYXJyeSB0aGUgbG9jYXRpb24gb2YgYSBwcm90ZWN0ZWQNCj4gcmVz b3VyY2UsIHR5cGljYWxseSBhcyBhbiBodHRwcyBVUkwsIG9yIGEgbW9yZSBhYnN0cmFjdCBpZGVu dGlmaWVyIiwgaXMgdGhpcw0KPiAiYWJzdHJhY3QgaWRlbnRpZmllciIgc3RpbGwgYW4gYWJzb2x1 dGUgVVJJIHBlciBTZWN0aW9uIDQuMyBvZiBSRkMzOTg2Pw0KPg0KPiAoMikgU2VjdGlvbiAyLjIu ICBpbiB0aGUgc2VudGVuY2UgIlRvIHRoZSBleHRlbnQgcG9zc2libGUsIHdoZW4gaXNzdWluZyBh Y2Nlc3MNCj4gdG9rZW5zLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGFkYXB0IHRo ZSBzY29wZSB2YWx1ZSBhc3NvY2lhdGVkDQo+IHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIHRoZSB2 YWx1ZSB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSBpcyBhYmxlIHRvIHByb2Nlc3MNCj4gYW5kIG5l ZWRzIHRvIGtub3ciOg0KPg0KPiAtLSAgaXMgdGhpcyBsYW5ndWFnZSBzdWdnZXN0aW5nIHRoYXQg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIG1vZGlmeWluZyB0aGUNCj4gc2NvcGUgdmFsdWUg YmFzZWQgb24gdGhlIHJlc291cmNlIGl0IHNlZXM/ICBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQg d2hhdA0KPiAiYWRhcHQiIG1lYW5zLCBlc3BlY2lhbGx5IGluIHJlbGF0aW9uIHRvIHRoZSBpbXBy b3ZlZCBzZWN1cml0eSBhbmQgcHJpdmFjeSB0aGUNCj4gc3Vic2VxdWVudCBzZW50ZW5jZSBzdWdn ZXN0cy4NCj4NCj4gLS0gKERlcGVuZGluZyBvbiB0aGUgYWJvdmUpIElzIHRoZXJlIGEgc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBoZXJlIGZvciB0aGUNCj4gc2VydmVyIHJlbGF0aXZlIHRvIGNvbmZp ZGVudGlhbCBzY29wZSB2YWx1ZXMgYW5kIGhvdyB0aGV5IG1pZ2h0IGJlIG1vZGlmaWVkPw0KPg0K PiAoMykgRWRpdG9yaWFsDQo+ICoqIFNlY3Rpb24gMSBhbmQgMi4xLiAgTXVsdGlwbGUgVHlwby4g IHMvdGhlIHRoZS90aGUvZw0KPg0KPiAqKiBTZWN0aW9uIDIuICBFZGl0b3JpYWwuIHMvcmVzb3Vy Y2UgYXQgd2hpY2gvcmVzb3VyY2UgdG8gd2hpY2gvDQo+DQo+ICoqIFNlY3Rpb24gMi4gIEVkaXRv cmlhbC4NCj4gcy8gQW5kIGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBjbGllbnQgdGhh dCBpdCBoYXMgcmVxdWVzdGVkIGFuIGludmFsaWQNCj4gY29tYmluYXRpb24gb2YgcmVzb3VyY2Ug YW5kIHNjb3BlLi8gSXQgY2FuIGFsc28gYmUgdXNlZCB0byBpbmZvcm0gdGhlIGNsaWVudA0KPiB0 aGF0IGl0IGhhcyByZXF1ZXN0ZWQgYW4gaW52YWxpZCBjb21iaW5hdGlvbiBvZiByZXNvdXJjZSBh bmQgc2NvcGUuLw0KPg0KPiAqKiBTZWN0aW9uIDIuMS4gTXVsdGlwbGUgVHlwby4gcy9hbiBhbi9h bi9nDQo+DQo+ICoqIFNlY3Rpb24gMi4yLiAgRWRpdG9yaWFsLiBzL3Rva2VuIHJlcXVlc3QgYW5k IHJlc3BvbnNlL3Rva2VuIHJlcXVlc3QNCj4gKEZpZ3VyZSAzKSBhbmQgcmVzcG9uc2UgKEZpZ3Vy ZSA0KS8NCj4NCj4gKiogU2VjdGlvbiAzLiAgVHlwby4gIHMvYSBpbnZhbGlkL2FuIGludmFsaWQv DQo+DQo+ICoqIFNlY3Rpb24gMy4gIE1pc3Npbmcgd29yZHMuICAiQSBiZWFyZXIgdG9rZW4gdGhh dCBoYXMgbXVsdGlwbGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50cyAoYXVkaWVuY2VzKSBjYW4gYmUg dXNlZCBieSBhbnkgb25lIG9mIHRob3NlIHJlY2lwaWVudHMgYXQgYW55DQo+IG90aGVyLiIgIElz IGl0IHByb3RlY3RlZCByZXNvdXJjZT8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQoN CkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmls ZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg== --_000_359EC4B99E040048A7131E0F4E113AFC01B33DBDE8marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBb bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgSnVseSAxOSwgMjAxOSAyOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3 ICZsdDtyZGRAY2VydC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFJvbWFuLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gYXR0ZW1wdGluZyB0 byBicmluZyB0aGlzIHRocmVhZCBhbmQgb3VyIHByaXZhdGUgZXhjaGFuZ2VzIHRvZ2V0aGVyIChz b3JyeSBhZ2FpbiB0aGF0IGl0IGVuZGVkIHVwIHRoYXQgd2F5KSBhbmQgbWFrZSBzdXJlIHdlIGFy ZSBvbiB0aGUgc2FtZSBwYWdlIGFib3V0IHRoZSBwYXRoIGZvcndhcmQgYmVmb3JlIEkgc3RhcnQg ZG93biB0aGF0IHBhdGguDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCB5b3VyIGFzc2Vzc21lbnQgYmVsb3cgaXMgY29ycmVjdC4gQW5k IHllcyBJIHRoaW5rIHRoZSBjaGFuZ2VzIHlvdSBwcm9wb3NlZCB0byBJQU5BIHNlY3Rpb24gNCBv ZiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgZm9sbG93IGZyb20gdGhhdCBh bmQgbWFrZSBzZW5zZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5bUm9tYW5dJm5ic3A7IE9rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dl dmVyLCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHNob3VsZCBhbHNvIGJlIGNoYW5n ZWQgdG8gdGFrZSBvbiBhIHNob3J0IHNlbnRlbmNlIGluIGl0cyB0ZXh0IGFib3V0IHRoZSByZXNv dXJjZSBwYXJhbWV0ZXIgdG8gbWVudGlvbiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMgYW5kIGluY2x1ZGUgYW4gaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgdG8gaXQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21hbl0gQ29ycmVj dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGNvbmZpcm0gdGhhdCBvciBjb3Jy ZWN0IG1lIGFuZCBJJ2xsIHByb2NlZWQgd2l0aCB0aGUgY2hhbmdlcy4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBpdGVyYXRp b24gYW5kIGV4cGxhbmF0aW9ucyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlJvbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDE3LCAyMDE5IGF0IDU6NDkgUE0gUm9tYW4g RGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoaXMgYmFja2dyb3VuZCBhbmQgZXhwbGFu YXRpb24uJm5ic3A7IFRoZXJlIHdhcyBoaXN0b3J5IGhlcmUgSSBkaWRu4oCZdCBrbm93Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpdGggdGhlIGJlbmVm aXQgb2YgdGhpcyB0aHJlYWQgYW5kIHByaXZhdGUgZXhjaGFuZ2VzLCB0aGUga2V5IHRha2Vhd2F5 cyBmb3IgbWUgYXJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPioqIHRoZSBkZWZpbml0aW9uIG9mICdyZXNvdXJjZScgZm9yICd0b2tlbiBleGNoYW5nZScg aXMgaWRlbnRpY2FsIGluIGJvdGggZHJhZnRzIChkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWlu ZGljYXRvcg0KIGFuZCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlKTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPioqIGRyYWZ0LWlldGYtb2F1dGgt cmVzb3VyY2UtaW5kaWNhdG9ycyBoYXMgYWRkaXRpb25hbCDigJx1c2Vz4oCdIG9mIHJlc291cmNl IG5vdCBnZXJtYW5lIHRvIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9yPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KiogdGhlIGRlc2lyZWQg ZW5kcy1zdGF0ZSBhZnRlciB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBvZiBib3Ro IGRyYWZ0cyB3ZXJlIHByb2Nlc3MsIHRoZSBPYXV0aA0KIHJlZ2lzdHJ5IHdvdWxkIGxvb2sgYXMg Zm9sbG93czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tIG5hbWUgPSByZXNvdXJjZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPi0gcGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uID08L3NwYW4+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+LSBjaGFuZ2UgY29udHJvbGxlciA9IElFVEY8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4tIHJlZmVyZW5jZSA9IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1l PSJtXy01MjgwMTYyNjU3MzQxMDA2MzgwX21fLTYwNzU1ODk4Njg2MzQ0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklzIHRoYXQg cmlnaHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYg dGhlIGFib3ZlIGlzIGNvcnJlY3QsIHdvdWxkIHRoZSBmb2xsb3dpbmcgd2F5IGFoZWFkIHdvcms6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KiogZm9yIGRy YWZ0LWlldGYtb2F1dGgtdG9rZW4gZXhjaGFuZ2U6IE5vdGhpbmc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4qKiBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3INCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlBlciBTZWN0aW9uIDQuMTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgdGhl IGZvbGxvd2luZyB2YWx1ZSBpbiB0aGUgSUFOQSAmcXVvdDtPQXV0aDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBQYXJhbWV0ZXJzJnF1b3Q7IHJlZ2lzdHJ5IFtJQU5BLk9BdXRoLlBh cmFtZXRlcnNdIGVzdGFibGlzaGVkIGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IFtSRkM2NzQ5XS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBQYXJhbWV0ZXIgbmFtZTogcmVzb3VyY2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBvJm5ic3A7IENoYW5nZSBjb250cm9sbGVyOiBJRVNHPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTog W1sgdGhpcyBzcGVjaWZpY2F0aW9uIF1dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UGVyIFNlY3Rpb24gNC4yDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gdXBkYXRlcyB0aGUgZm9sbG93aW5nIGVy cm9yIGluIHRoZSBJQU5BICZxdW90O09BdXRoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkmcXVvdDsgW0lBTkEuT0F1dGguUGFyYW1ldGVy c10gZXN0YWJsaXNoZWQgYnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgW1JGQzY3 NDldLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBvJm5ic3A7IEVycm9yIG5hbWU6IGludmFsaWRfdGFyZ2V0PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgRXJyb3IgdXNhZ2UgbG9jYXRpb246IGltcGxpY2l0 IGdyYW50IGVycm9yIHJlc3BvbnNlLCB0b2tlbiBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBvJm5ic3A7IFJlbGF0ZWQgcHJvdG9jb2wgZXh0ZW5zaW9uOiByZXNvdXJj ZSBwYXJhbWV0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBDaGFu Z2UgY29udHJvbGxlcjogSUVTRzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvJm5i c3A7IFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBdXTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvbWFuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1j b2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJp YW4gQ2FtcGJlbGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDY6MzEgUE08YnI+DQo8 Yj5Ubzo8L2I+IFJvbWFuIERhbnlsaXcgJmx0OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmci IHRhcmdldD0iX2JsYW5rIj5yZGRAY2VydC5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVhaCwgYXMgeW91 IHN1cm1pc2VkLCB0aGVyZSBpcyBzb21lIGhpc3RvcnkgYmVoaW5kIHRoaXMuIEJhc2ljYWxseSBk cmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHByZWRhdGVzIGRyYWZ0LWlldGYtb2F1dGgt cmVzb3VyY2UtaW5kaWNhdG9ycyBieSBhIGdvb2QgbG9uZyB0aW1lICh5ZWFycykgYW5kDQogd2l0 aCB0aGUgaG9wZSBhbmQgZXhwZWN0YXRpb24gdGhhdCBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4 Y2hhbmdlIHdvdWxkIG1vdmUgdG8gUkZDLCBJJ3ZlIGF2b2lkZWQgaGF2aW5nIGEgcmVmZXJlbmNl IGluIGl0IHRvIGEgZHJhZnQgbXVjaCBlYXJsaWVyIGFsb25nIGluIHRoZSB3aG9sZSBwcm9jZXNz LiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMgaGFzIGEgYml0IG9mIGFuIG9k ZCBoaXN0b3J5IHRvbyBpbiB0aGF0IGFuDQogaW5pdGlhbCBjYWxsIGZvciBhZG9wdGlvbiBhcm91 bmQgdGhlIEJ1ZW5vcyBBaXJlcyBtZWV0aW5nIGtpbmRhIGZpenpsZWQgb3V0IGFuZCBpdCB3YXMg bGVmdCBmb3IgZGVhZCB1bnRpbCBiZWluZyB1bmV4cGVjdGVkIHJlc3VycmVjdGVkIGFyb3VuZCBN b250cmVhbCBsYXN0IHllYXIgZHVlIHRvIHJlbmV3ZWQgaW50ZXJlc3QgYW5kIG90aGVyIGZhY3Rv cnMgSSdtIHN0aWxsIG5vdCBzdXJlIEkgdW5kZXJzdGFuZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBhcmUgY29ycmVj dCB0aGF0IGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UgZGVmaW5lcyAmcXVvdDtyZXNv dXJjZSZxdW90OyBmb3IgdG9rZW4gZXhjaGFuZ2UuIEhvd2V2ZXIgdGhlIHJlZ2lzdHJ5IGl0c2Vs ZiBkb2Vzbid0IGhhdmUgdGhhdCBsZXZlbCBvZiBncmFudWxhcml0eS4gSXQgaGFzIGF1dGhvcml6 YXRpb24NCiByZXF1ZXN0LCBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXF1ZXN0LCBh bmQgdG9rZW4gcmVzcG9uc2UgYXMgdGhlIHBvc3NpYmxlIGxvY2F0aW9ucyBmb3IgcGFyYW1ldGVy IHVzYWdlLiBBIHRva2VuIGV4Y2hhbmdlIHJlcXVlc3QgaXMgYSBwYXJ0aWN1bGFyIGtpbmQgb2Yg dG9rZW4gcmVxdWVzdCBzbyBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHJlZ2lzdGVy cyAmcXVvdDtyZXNvdXJjZSZxdW90OyBmb3IgdGhlIHRva2VuIHJlcXVlc3QgbG9jYXRpb24uDQog VGhlIElBTkEgc2VjdGlvbiB3YXMgd3JpdHRlbiBiZWZvcmUgZHJhZnQtaWV0Zi1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3JzIGV2ZW4gZXhpc3RlZC4gQW5kIGxlYXZpbmcgdGhlIHJlZ2lzdHJhdGlv biBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIHNlZW1lZCBsaWtlIHRoZSByaWdo dCB0aGluZyB0byBkbyB0byBldmVuIGFmdGVyIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5k aWNhdG9ycyBjYW1lIGFsb25nLiBCdXQgSSdtDQogbm90IHN1cmUsIHRvIGJlIGhvbmVzdC4gQWxz byBGV0lXIGEgdGVtcG9yYXJ5IHJlZ2lzdHJhdGlvbiBlbnRyeSBmb3IgaXQgaXMgYWxyZWFkeSBp bg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1l dGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhodG1sI3BhcmFtZXRlcnMiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgt cGFyYW1ldGVycy54aHRtbCNwYXJhbWV0ZXJzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzIGRlZmluZXMgJnF1b3Q7cmVzb3VyY2UmcXVvdDsgZm9yIHVzZSBhdCB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCAod2hpY2ggdG9rZW4gZXhjaGFuZ2UgZG9lcyBub3QpIHNv IHRoYXQncyB0aGUgaW1wZXR1cyBiZWhpbmQgaGF2aW5nIHRoZSByZWdpc3RyYXRpb24NCiByZXF1 ZXN0IHRoZXJlIGluY2x1ZGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGluIHRoZSBsb2NhdGlvbi4g ZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIGFsc28gaGFzICZxdW90O3Jlc291 cmNlJnF1b3Q7IGZvciB1c2UgYXQgdGhlIHRva2VuIGVuZHBvaW50IHVzaW5nIHRoZSBzYW1lIHNl bWFudGljcyBhcyBpbiBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlIGJ1dCBpbiBhIHdh eSB0aGF0IGlzIGFwcGxpY2FibGUgdG8gYWxsIHR5cGVzDQogb2YgdG9rZW4gcmVxdWVzdHMgdG8g dGhlIHRoZSB0b2tlbiBlbmRwb2ludCBhbmQgbm90IG9ubHkgdG9rZW4gZXhjaGFuZ2UgcmVxdWVz dHMuIFRoYXQncyB3aGVyZSB0aGUgaWRlYSBvZiB1cGRhdGluZyB0aGUgcmVnaXN0cnkgY2FtZSBm cm9tIC0gaXQncyBub3QgYSBuYW1lIGNvbGxpc2lvbiBhbmQgaXQncyBub3QgYSBkaWZmZXJlbnQg ZGVmaW5pdGlvbiAtIGl0J3MganVzdCBhIG1vcmUgZ2VuZXJhbGl6ZWQgdXNhZ2UuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhvcGUg dGhpcyBtYWtlcyBzb21lIHNlbnNlIGFuZCBoYXNuJ3QgbXVkZGllZCB0aGUgd2F0ZXJzIG1vcmUu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gV2VkLCBKdWwgMTcsIDIwMTkgYXQgMzoxMyBQTSBSb21hbiBEYW55bGl3 ICZsdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNl cnQub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJl bnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSE8YnI+DQo8YnI+DQpJIGZvcmdvdCBvbmUgbW9yZSB0aGlu ZyBhYm91dCB0aGlzIGRyYWZ0IGFmdGVyIHJlLXJlYWRpbmcgZHJhZnQtaWV0Zi1vYXV0aC10b2tl bi1leGNoYW5nZS48YnI+DQo8YnI+DQpQZXIgdGhlIElBTkEgYWN0aW9uIGluIFNlY3Rpb24gNC4x LCBJIG5lZWQgaGVscCB1bmRlcnN0YW5kaW5nIG9uIHRoZSB0aGlua2luZyB0byByZXNvbHZlIHRo aXMgVE9ETzo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyBQYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7IFtbVE9ETzogZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSB3 aWxsIGhhdmUgYWxyZWFkeTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZ2lzdGVyZWQgdGhp cyBmb3IgJ3Rva2VuIHJlcXVlc3QnIGFuZCB0aGlzIGRyYWZ0IGhhcyBhIG1vcmU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBnZW5lcmFsaXplZCB1c2FnZSBhbmQgbmVlZHMgdG8gc29tZWhvdyBl aXRoZXIgdXBkYXRlIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyByZWdpc3RyYXRpb24g b3IgZG8gYSBwYXJ0aWFsIHJlZ2lzdHJhdGlvbiBhbmQgcmVmZXJlbmNlXV08YnI+DQombmJzcDsg Jm5ic3A7byZuYnNwOyBDaGFuZ2UgY29udHJvbGxlcjogSUVTRzxicj4NCiZuYnNwOyAmbmJzcDtv Jm5ic3A7IFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgc3BlY2lmaWNhdGlvbiBd XTxicj4NCjxicj4NCk15IHJlYWQgb2YgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBp dCB0aGF0IGl0IGRlZmluZXMgJ3Jlc291cmNlJyBmb3IgJ3Rva2VuIGV4Y2hhbmdlJy4mbmJzcDsg VGhpcyBkcmFmdCAoZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzKSBoYXMgZ3Vp ZGFuY2Ugb24gJ3Jlc291cmNlJyBmb3IgJ2F1dGhvcml6YXRpb24gcmVxdWVzdCcgYnV0IGFsc28g YWRkaXRpb25hbCBndWlkYW5jZSBmb3IgJ3Rva2VuIHJlcXVlc3QnLiZuYnNwOyBJcyB0aGUNCiB0 b2tlbiBndWlkYW5jZSByZXF1ZXN0IHN0YXRlZCBoZXJlIGFwcGxpY2FibGUgdG8gZHJhZnQtaWV0 Zi1vYXV0aC10b2tlbi1leGNoYW5nZSB0b28gKGkuZS4sIGlzIHRoZSB0ZXh0IGVmZmVjdGl2ZWx5 IHNheWluZyBvYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzIHVwZGF0ZXMgb2F1dGgtdG9rZW4tZXho YW5nZSk/Jm5ic3A7IEkgYXNrIGJlY2F1c2UgdGhlc2UgZHJhZnRzIGRvbid0IHJlZmVyZW5jZSBl YWNoIG90aGVyLjxicj4NCjxicj4NCkNvcnJlY3QgbWUgYmVjYXVzZSB0aGVyZSBpcyBsaWtlbHkg YSBoaXN0b3J5LCBidXQgaXQgc2VlbXMgdGhlIFRPRE8gaXMgdGhhdCB0aGVyZSBpcyBhIGRlcGVu ZGVuY3kgdG8gcmVzb2x2ZSBhbmQgYSBuZWVkIHRvIGNvbWluZyB1cCB3aXRoIGEgd2F5IHRvIHNp Z25hbCBpbiB0aGUgcmVnaXN0cnkgd2hpY2ggZHJhZnQgc2hvdWxkIGJlIHJlYWQgZm9yIHdoYXQg dXNhZ2UgbG9jYXRpb24uJm5ic3A7IENvdWxkIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5k aWNhdG9ycw0KIG9mZmljaWFsbHkgcmVnaXN0ZXIgJ3Jlc291cmNlJzsgYW5kIGluc3RlYWQgb2Yg ZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSBpbmNsdWRpbmcgdGhlIHRleHQgZGVmaW5p bmcgJ3Jlc291cmNlJyBpbiBTZWN0aW9uIDIuMSwgaXQgd291bGQgbWFrZSBhIG5vcm1hdGl2ZSBy ZWZlcmVuY2UgdG8gU2VjdGlvbiAyIG9mIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9ycz88YnI+DQo8YnI+DQpSb21hbjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFJvbWFuIERhbnlsaXc8YnI+DQomZ3Q7IFNlbnQ6IFR1 ZXNkYXksIEp1bHkgMTYsIDIwMTkgNzoyMyBQTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0 bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMtMDI8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo ZSBmb2xsb3dpbmcgaXMgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMi48YnI+DQomZ3Q7IFRoZSBkb2N1bWVudCBpcyBpbiBnb29kIHNoYXBlLjxi cj4NCiZndDsgPGJyPg0KJmd0OyAoMSkgU2VjdGlvbiAyLiBQZXIgJnF1b3Q7VGhlIHBhcmFtZXRl ciBjYW4gY2FycnkgdGhlIGxvY2F0aW9uIG9mIGEgcHJvdGVjdGVkPGJyPg0KJmd0OyByZXNvdXJj ZSwgdHlwaWNhbGx5IGFzIGFuIGh0dHBzIFVSTCwgb3IgYSBtb3JlIGFic3RyYWN0IGlkZW50aWZp ZXImcXVvdDssIGlzIHRoaXM8YnI+DQomZ3Q7ICZxdW90O2Fic3RyYWN0IGlkZW50aWZpZXImcXVv dDsgc3RpbGwgYW4gYWJzb2x1dGUgVVJJIHBlciBTZWN0aW9uIDQuMyBvZiBSRkMzOTg2Pzxicj4N CiZndDsgPGJyPg0KJmd0OyAoMikgU2VjdGlvbiAyLjIuJm5ic3A7IGluIHRoZSBzZW50ZW5jZSAm cXVvdDtUbyB0aGUgZXh0ZW50IHBvc3NpYmxlLCB3aGVuIGlzc3VpbmcgYWNjZXNzPGJyPg0KJmd0 OyB0b2tlbnMsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgYWRhcHQgdGhlIHNjb3Bl IHZhbHVlIGFzc29jaWF0ZWQ8YnI+DQomZ3Q7IHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIHRoZSB2 YWx1ZSB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSBpcyBhYmxlIHRvIHByb2Nlc3M8YnI+DQomZ3Q7 IGFuZCBuZWVkcyB0byBrbm93JnF1b3Q7Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSZuYnNwOyBp cyB0aGlzIGxhbmd1YWdlIHN1Z2dlc3RpbmcgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg aXMgbW9kaWZ5aW5nIHRoZTxicj4NCiZndDsgc2NvcGUgdmFsdWUgYmFzZWQgb24gdGhlIHJlc291 cmNlIGl0IHNlZXM/Jm5ic3A7IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0PGJyPg0KJmd0 OyAmcXVvdDthZGFwdCZxdW90OyBtZWFucywgZXNwZWNpYWxseSBpbiByZWxhdGlvbiB0byB0aGUg aW1wcm92ZWQgc2VjdXJpdHkgYW5kIHByaXZhY3kgdGhlPGJyPg0KJmd0OyBzdWJzZXF1ZW50IHNl bnRlbmNlIHN1Z2dlc3RzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSAoRGVwZW5kaW5nIG9uIHRo ZSBhYm92ZSkgSXMgdGhlcmUgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGhlcmUgZm9yIHRoZTxi cj4NCiZndDsgc2VydmVyIHJlbGF0aXZlIHRvIGNvbmZpZGVudGlhbCBzY29wZSB2YWx1ZXMgYW5k IGhvdyB0aGV5IG1pZ2h0IGJlIG1vZGlmaWVkPzxicj4NCiZndDsgPGJyPg0KJmd0OyAoMykgRWRp dG9yaWFsPGJyPg0KJmd0OyAqKiBTZWN0aW9uIDEgYW5kIDIuMS4mbmJzcDsgTXVsdGlwbGUgVHlw by4mbmJzcDsgcy90aGUgdGhlL3RoZS9nPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICoqIFNlY3Rpb24g Mi4mbmJzcDsgRWRpdG9yaWFsLiBzL3Jlc291cmNlIGF0IHdoaWNoL3Jlc291cmNlIHRvIHdoaWNo Lzxicj4NCiZndDsgPGJyPg0KJmd0OyAqKiBTZWN0aW9uIDIuJm5ic3A7IEVkaXRvcmlhbC48YnI+ DQomZ3Q7IHMvIEFuZCBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZm9ybSB0aGUgY2xpZW50IHRoYXQg aXQgaGFzIHJlcXVlc3RlZCBhbiBpbnZhbGlkPGJyPg0KJmd0OyBjb21iaW5hdGlvbiBvZiByZXNv dXJjZSBhbmQgc2NvcGUuLyBJdCBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZm9ybSB0aGUgY2xpZW50 PGJyPg0KJmd0OyB0aGF0IGl0IGhhcyByZXF1ZXN0ZWQgYW4gaW52YWxpZCBjb21iaW5hdGlvbiBv ZiByZXNvdXJjZSBhbmQgc2NvcGUuLzxicj4NCiZndDsgPGJyPg0KJmd0OyAqKiBTZWN0aW9uIDIu MS4gTXVsdGlwbGUgVHlwby4gcy9hbiBhbi9hbi9nPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICoqIFNl Y3Rpb24gMi4yLiZuYnNwOyBFZGl0b3JpYWwuIHMvdG9rZW4gcmVxdWVzdCBhbmQgcmVzcG9uc2Uv dG9rZW4gcmVxdWVzdDxicj4NCiZndDsgKEZpZ3VyZSAzKSBhbmQgcmVzcG9uc2UgKEZpZ3VyZSA0 KS88YnI+DQomZ3Q7IDxicj4NCiZndDsgKiogU2VjdGlvbiAzLiZuYnNwOyBUeXBvLiZuYnNwOyBz L2EgaW52YWxpZC9hbiBpbnZhbGlkLzxicj4NCiZndDsgPGJyPg0KJmd0OyAqKiBTZWN0aW9uIDMu Jm5ic3A7IE1pc3Npbmcgd29yZHMuJm5ic3A7ICZxdW90O0EgYmVhcmVyIHRva2VuIHRoYXQgaGFz IG11bHRpcGxlIGludGVuZGVkPGJyPg0KJmd0OyByZWNpcGllbnRzIChhdWRpZW5jZXMpIGNhbiBi ZSB1c2VkIGJ5IGFueSBvbmUgb2YgdGhvc2UgcmVjaXBpZW50cyBhdCBhbnk8YnI+DQomZ3Q7IG90 aGVyLiZxdW90OyZuYnNwOyBJcyBpdCBwcm90ZWN0ZWQgcmVzb3VyY2U/PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0 aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7 IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r IHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRp b24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1l c3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsg eW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_359EC4B99E040048A7131E0F4E113AFC01B33DBDE8marchand_-- From nobody Fri Jul 19 17:33: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 75E84120041 for ; Fri, 19 Jul 2019 17:33: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqvJafm1s9Je for ; Fri, 19 Jul 2019 17:33:09 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8D04A120033 for ; Fri, 19 Jul 2019 17:33:09 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:f404:d45:ece6:a64d] (unknown [IPv6:2601:282:202:b210:f404:d45:ece6:a64d]) by alkaline-solutions.com (Postfix) with ESMTPSA id B766C315C9; Sat, 20 Jul 2019 00:33:08 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FE71FAFB-0356-461E-9AE7-C917DA36D45D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) Date: Fri, 19 Jul 2019 18:33:08 -0600 In-Reply-To: Cc: George Fletcher , OAuth WG To: Aaron Parecki References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 00:33:14 -0000 --Apple-Mail=_FE71FAFB-0356-461E-9AE7-C917DA36D45D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I believe that access tokens and any refresh token policy should be = guided by the user authentication process and session lifetime policy of = the AS. There=E2=80=99s a case to be made that whether someone gets access to my = access token directly or a refresh token that allows someone to grant a = new access token, they have still gotten access to protected resources. The case could be made that refresh tokens however are made more = powerful by dynamic features: - requesting an access token with additional scopes - requesting an access token targeting a new audience/resource (via = either scopes-as-resources, or directly with resource indicators) However, the client has already been granted these scopes or resource = access in this theoretical case, so I could just as easily attempt to = gather such an access token through the authorization endpoint and code = exchange. So as general points of guidance, how about: - Refresh tokens serve the same purpose as in general OAuth - For applications which represent access as part of a user session, = access and refresh tokens lifetimes and policy should mirror that = session. - Specifically, an AS should not grant =E2=80=9Coffline=E2=80=9D refresh = tokens meant to provide access for an unfixed/extended period of time, = as the resource owner may expect other users of the browser would not = get access to protected resources - It is recommended that an AS requires refresh tokens grants to be = authenticated to a client instance, be it via a unique client identity = through DCR, or ephemerally through a proof-of-possession mechanism = (token binding, mtls, dpop) - Other security BCP stuff should apply. -DW > On Jul 19, 2019, at 5:49 PM, Aaron Parecki wrote: >=20 > So what I'm hearing in this thread is essentially that: >=20 > 1) depending on how it's implemented, using a refresh token in a SPA = can provide security benefits over using only access tokens > 2) it is still "dangerous" to allow refresh tokens to be used without = client authentication > 3) if there is a way to do some sort of dynamic client registration or = proof of possession, then using a refresh token would in fact be more = secure >=20 > Since these points are in conflict with each other, and depend on = things currently in flux, it seems like the best thing to do at this = time is to remove the guidance on refresh tokens in browser-based apps. = Maybe leaving the mention of rotating the refresh token on every use, = but I'm inclined to remove the "SHOULD NOT issue refresh tokens" = statement in order to leave room for DPoP or similar in the future. >=20 > Sound reasonable? >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 >=20 >=20 > On Thu, Jul 11, 2019 at 2:52 PM George Fletcher > wrote: > You are correct that client authentication is not required for public = clients (which doesn't preclude the use of refresh_tokens) but from my = perspective it weakens the security because anyone with the = refresh_token is able to get new access_tokens without any additional = proof. >=20 > Now if the SPA performs some sort of Dynamic Client Registration or = DPoP then I think it's a completely different scenario and it doesn't = bother me as much for their to be refresh_tokens in the browser. This of = course is just my perspective:) >=20 > On 7/10/19 7:56 PM, Aaron Parecki wrote: >> 2. To use a refresh token at the /token endpoint, client = authentication is required. This is where it gets difficult for default = SPAs because they are public clients and the only mechanism to = authenticate them is the client_id which is itself public. For me, this = is the real risk of exposing the refresh_token in the browser.?? >>=20 >> RFC6749 says "If the client type is confidential or??the client was = issued client credentials,??the client MUST authenticate..." which I = take to mean that refresh tokens could be used without a client_secret, = both for native an javascript apps. >>=20 >> This discussion of offline vs online refresh tokens is interesting, = but I worry that we may be narrowing our focus here too much. >>=20 >> There's a use where JavaScript apps may be able to take advantage of = offline access, which is around Service Workers. This allows a website = to install some code from a website which can continue to run in the = background, though sometimes only while triggered from external events. = One useful example of this is a syncing daemon, where a push = notification can be sent from a web server to a Service Worker, which = could cause that code in the browser to need to make a request to an = API, which then may need to be able to get a new access token, which is = effectively offline access. >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >>=20 >>=20 >> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher = > = wrote: >> I'll just add a couple more thoughts around refresh_tokens. >>=20 >> 1. I agree with David that refresh_tokens are valuable in an "online" = scenario and should be used there. >>=20 >> 2. To use a refresh token at the /token endpoint, client = authentication is required. This is where it gets difficult for default = SPAs because they are public clients and the only mechanism to = authenticate them is the client_id which is itself public. For me, this = is the real risk of exposing the refresh_token in the browser.=20 >>=20 >> 3. If the AS supports rotation of refresh_tokens and an attacker = steals one and uses it, then the SPA will get an error on it's next = attempt because it's refresh_token will now be invalid. If the = refresh_tokens are bound to the user's authentication session, then the = user can logout to lockout the attacker. However, that is a lot of "ifs" = and still provides the attacker with time to leverage access via the = compromised refresh_token. >>=20 >> In principle, I agree with the recommendation that SPAs shouldn't = have refresh_tokens in the browser. If it's not possible to easily = refresh the access token via a hidden iframe (becoming more difficult = with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd = recommend to use a simple server component such that the backend for the = SPA can use authorization_code flow and protect a client_secret. >>=20 >> Thanks, >> George >>=20 >> On 7/8/19 11:17 PM, David Waite wrote: >>>=20 >>>> On Jul 8, 2019, at 7:10 PM, Leo Tohill > wrote: >>>> Re 8. Refresh Tokens >>>>=20 >>>> ???? "For public clients, the risk of a leaked refresh token is = much >>>> ?? ??greater than leaked access tokens, since an attacker can = potentially >>>> ?? ??continue using the stolen refresh token to obtain new access = without >>>> ?? ??being detectable by the authorization server.?? " >>>>=20 >>>> (first, note the typo "stoken".) >>>>=20 >>>> Is it always "higher risk"??? I could even argue that leakage of a = refresh token is lower risk. As a bearer document, a leaked access token = allows access to resources until it expires.?? A leaked refresh token, = to be useful,?? requires an exchange with the AS, and the AS would have = the opportunity to check whether the refresh token is still valid (has = not been revoked).?? (of course revocation might NOT have happened, but = then again, it might have.)=20 >>>=20 >>> I agree (with caveats, of course). >>>=20 >>> Access tokens and refresh tokens may or may not be attached (by = policy) to an authentication session lifetime. It is far easier to = picture refresh tokens which are not attached to an authentication = session (sometimes called ???offline??? access) being inappropriate for = a browser-based app, which is nearly always a client that the resource = owner is interacting with. >>>=20 >>> Variants that may want offline tokens are less easy to imagine - = perhaps browser extensions? >>>=20 >>> I believe the language currently there is due to AS implementations = predominantly treating refresh tokens as being for offline access, and = access token lifetime being short enough to not outlast an = authentication session. >>>=20 >>>> Furthermore, since the access token is transmitted to other = servers, the risk of exposure is greater, due to possible = vulnerabilities in those called systems (e.g., logs).?? Isn't this the = reason that we have refresh tokens? Don't refresh tokens exist because = access tokens should have short TTL, because they are widely = distributed? >>>=20 >>> Yes. Once you acknowledge the existence of ???online??? refresh = tokens, they become a strong security component: >>>=20 >>> - Refresh tokens let you shorten the access token lifetime >>> - A shorter access token lifetime lets you have centralized policy = to invalidate access without needing to resort to token = introspection/revocation >>> - Token refresh can theoretically be used to represent other policy = changes by both the client (creating tokens targeting a new resource = server or with reduced scopes) and server (changing entitlements and = attributes/claims embedded within a structured token) >>> - Refresh tokens can be one-time-use, as recommenced by the security = BCP. A exfiltrated refresh token will result in either the attacker or = the user losing access on the next refresh, and a double refresh is a = detectable security event by the AS. >>>=20 >>>> "Additionally, browser-based applications provide many attack = vectors by which a refresh token can be leaked." >>>>=20 >>>> The risks of leaking a refresh token from the browser are identical = to the risks of leaking an access token, right??? This sentence could be = changed to "... by which a token can be leaked." >>>>=20 >>>> A refresh token is "higher risk" because its TTL is usually greater = than the access token's TTL.?? But if our advice here leads to people = using longer-lived access tokens (because of the problems with getting a = new access token without involving the user), then the advice will be = counter productive.???? The longer life gives more time for the = usefulness of a browser-side theft, and more time for the usefulness of = a server-side theft.??=20 >>>>=20 >>>> Which scenario is safer? >>>> A) using an access token with a 10 minute TTL, accompanied by a = refresh token with a 1 hour TTL >>>> B) using an access token with a 1 hour TTL, and no refresh token.?? >>>=20 >>>=20 >>> Given tokens that track authentication lifetime, it is hard to make = a case that refresh tokens which last for the authentication session are = a greater security risk than opaque access tokens (requiring token = introspection) that will last the same time.?? >>>=20 >>> Typically an AS (or OP) would issue a structured access token with a = lifetime expected to expire before the authentication session, with new = tokens issued via requests made in an embedded, iframe (hidden, = prompt=3Dnone). There may be benefits here of user cookies (or perhaps = managed-device information) against an authorization endpoint being used = to make decisions that could not be made by a refresh against the token = endpoint.?? >>>=20 >>> I???d be interested in hearing how strong of an implementation issue = this might be for deployments - I could see a non-security argument that = the BCP should only have one recommended approach here, and that there = are deployments needing the iframe approach. >>>=20 >>> -DW >>>=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 >> _______________________________________________ >> 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=_FE71FAFB-0356-461E-9AE7-C917DA36D45D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = believe that access tokens and any refresh token policy should be guided = by the user authentication process and session lifetime policy of the = AS.

There=E2=80=99s = a case to be made that whether someone gets access to my access token = directly or a refresh token that allows someone to grant a new access = token, they have still gotten access to protected resources.

The case could be made = that refresh tokens however are made more powerful by dynamic = features:
- requesting an access token with = additional scopes
- requesting an access token = targeting a new audience/resource (via either scopes-as-resources, or = directly with resource indicators)

However, the client has already been granted these = scopes or resource access in this theoretical case, so I could just as = easily attempt to gather such an access token through the authorization = endpoint and code exchange.

So as = general points of guidance, how about:
- Refresh tokens serve = the same purpose as in general OAuth
- For applications which = represent access as part of a user session, access and refresh tokens = lifetimes and policy should mirror that session.
- = Specifically, an AS should not grant =E2=80=9Coffline=E2=80=9D refresh = tokens meant to provide access for an unfixed/extended period of time, = as the resource owner may expect other users of the browser would not = get access to protected resources
- It is recommended that an = AS requires refresh tokens grants to be authenticated to a client = instance, be it via a unique client identity through DCR, or ephemerally = through a proof-of-possession mechanism (token binding, mtls, = dpop)
- Other security BCP stuff should apply.

-DW

On Jul 19, 2019, at 5:49 PM, = Aaron Parecki <aaron@parecki.com> wrote:

So what I'm hearing in this thread is essentially that:

1) depending on how it's = implemented, using a refresh token in a SPA can provide security = benefits over using only access tokens
2) it is = still "dangerous" to allow refresh tokens to be used without client = authentication
3) if there is a way to do some sort = of dynamic client registration or proof of possession, then using a = refresh token would in fact be more secure

Since these points are in conflict with = each other, and depend on things currently in flux, it seems like the = best thing to do at this time is to remove the guidance on refresh = tokens in browser-based apps. Maybe leaving the mention of rotating the = refresh token on every use, but I'm inclined to remove the "SHOULD NOT = issue refresh tokens" statement in order to leave room for DPoP or = similar in the future.

Sound reasonable?

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Thu, Jul 11, 2019 at 2:52 PM George Fletcher = <gffletch@aol.com> wrote:
=20 =20 =20
You are = correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP then I think it's a completely different scenario and it doesn't bother me as much for their to be refresh_tokens in the browser. This of course is just my perspective:)

On = 7/10/19 7:56 PM, Aaron Parecki wrote:
=20
2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.??

RFC6749 says "If the client type is = confidential or??the client was issued client credentials,??the client MUST authenticate..." which I take to mean that refresh tokens could be used without a client_secret, both for native an javascript apps.

This discussion of offline vs online refresh = tokens is interesting, but I worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be = able to take advantage of offline access, which is around Service Workers. This allows a website to install some code from a website which can continue to run in the background, though sometimes only while triggered from external events. One useful example of this is a syncing daemon, where a push notification can be sent from a web server to a Service Worker, which could cause that code in the browser to need to make a request to an API, which then may need to be able to get a new access token, which is effectively offline access.

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Tue, Jul 9, 2019 at = 9:16 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I'll just add a couple more = thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill = <leotohill@gmail.com> wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo = "stoken".)

Is it always "higher risk"??? I = could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or = may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are = less easy to imagine - perhaps browser extensions?

I believe the language currently there is = due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

Furthermore, since the access = token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security = component:

- Refresh tokens let you shorten the = access token lifetime
- A shorter access token lifetime lets you = have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used = to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured = token)
- Refresh tokens can be one-time-use, as = recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

"Additionally, browser-based = applications provide many attack vectors by which a refresh token can be leaked."

The risks of leaking a refresh = token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a = token can be leaked."

A refresh token is "higher risk" = because its TTL is usually greater than the access token's TTL.?? But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 = minute TTL, accompanied by a refresh token with a 1 hour = TTL
B) using an access token with a 1 hour = TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??

Typically an AS (or OP) would issue a = structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=3Dnone). There may be benefits here of user = cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??

I???d be interested in hearing how strong = of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW


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

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

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

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

= --Apple-Mail=_FE71FAFB-0356-461E-9AE7-C917DA36D45D-- From nobody Fri Jul 19 19:58: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 0B46F1200E7 for ; Fri, 19 Jul 2019 19:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 p9k2O4-3gonU for ; Fri, 19 Jul 2019 19:57:57 -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 4C74A12004C for ; Fri, 19 Jul 2019 19:57:57 -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 x6K2vqaZ015504; Fri, 19 Jul 2019 22:57:52 -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; Fri, 19 Jul 2019 22:57:27 -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; Fri, 19 Jul 2019 22:57:52 -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; Fri, 19 Jul 2019 22:57:52 -0400 From: Justin Richer To: Aaron Parecki CC: George Fletcher , OAuth WG Thread-Topic: [OAUTH-WG] Refresh tokens Thread-Index: AQHVNfuXFIkYsJ2wmUK9eSM1H1G6R6bB4NCAgADZVwCAAhL9gIABTiSAgAzVDwCAADSXAA== Date: Sat, 20 Jul 2019 02:57:52 +0000 Message-ID: References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> 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_D676DDDE20FE40048E3F124A560A1C20mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 02:58:01 -0000 --_000_D676DDDE20FE40048E3F124A560A1C20mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdCBjYW4gYmUgYXMgc2ltcGxlIGFzOg0KDQpTSE9VTEQgTk9UIHVzZSByZWZyZXNo IHRva2VucyB3aXRob3V0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBrZXkgcHJvb2Ygb2Ygc29t ZSBraW5kLg0KDQpJbiBvdGhlciB3b3Jkcywgbm8gYmVhcmVyIHJlZnJlc2ggdG9rZW5zLg0KDQri gJQgSnVzdGluDQoNCk9uIEp1bCAxOSwgMjAxOSwgYXQgNzo0OSBQTSwgQWFyb24gUGFyZWNraSA8 YWFyb25AcGFyZWNraS5jb208bWFpbHRvOmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6DQoNClNv IHdoYXQgSSdtIGhlYXJpbmcgaW4gdGhpcyB0aHJlYWQgaXMgZXNzZW50aWFsbHkgdGhhdDoNCg0K MSkgZGVwZW5kaW5nIG9uIGhvdyBpdCdzIGltcGxlbWVudGVkLCB1c2luZyBhIHJlZnJlc2ggdG9r ZW4gaW4gYSBTUEEgY2FuIHByb3ZpZGUgc2VjdXJpdHkgYmVuZWZpdHMgb3ZlciB1c2luZyBvbmx5 IGFjY2VzcyB0b2tlbnMNCjIpIGl0IGlzIHN0aWxsICJkYW5nZXJvdXMiIHRvIGFsbG93IHJlZnJl c2ggdG9rZW5zIHRvIGJlIHVzZWQgd2l0aG91dCBjbGllbnQgYXV0aGVudGljYXRpb24NCjMpIGlm IHRoZXJlIGlzIGEgd2F5IHRvIGRvIHNvbWUgc29ydCBvZiBkeW5hbWljIGNsaWVudCByZWdpc3Ry YXRpb24gb3IgcHJvb2Ygb2YgcG9zc2Vzc2lvbiwgdGhlbiB1c2luZyBhIHJlZnJlc2ggdG9rZW4g d291bGQgaW4gZmFjdCBiZSBtb3JlIHNlY3VyZQ0KDQpTaW5jZSB0aGVzZSBwb2ludHMgYXJlIGlu IGNvbmZsaWN0IHdpdGggZWFjaCBvdGhlciwgYW5kIGRlcGVuZCBvbiB0aGluZ3MgY3VycmVudGx5 IGluIGZsdXgsIGl0IHNlZW1zIGxpa2UgdGhlIGJlc3QgdGhpbmcgdG8gZG8gYXQgdGhpcyB0aW1l IGlzIHRvIHJlbW92ZSB0aGUgZ3VpZGFuY2Ugb24gcmVmcmVzaCB0b2tlbnMgaW4gYnJvd3Nlci1i YXNlZCBhcHBzLiBNYXliZSBsZWF2aW5nIHRoZSBtZW50aW9uIG9mIHJvdGF0aW5nIHRoZSByZWZy ZXNoIHRva2VuIG9uIGV2ZXJ5IHVzZSwgYnV0IEknbSBpbmNsaW5lZCB0byByZW1vdmUgdGhlICJT SE9VTEQgTk9UIGlzc3VlIHJlZnJlc2ggdG9rZW5zIiBzdGF0ZW1lbnQgaW4gb3JkZXIgdG8gbGVh dmUgcm9vbSBmb3IgRFBvUCBvciBzaW1pbGFyIGluIHRoZSBmdXR1cmUuDQoNClNvdW5kIHJlYXNv bmFibGU/DQoNCi0tLS0NCkFhcm9uIFBhcmVja2kNCmFhcm9ucGFyZWNraS5jb208aHR0cDovL2Fh cm9ucGFyZWNraS5jb20vPg0KQGFhcm9ucGs8aHR0cDovL3R3aXR0ZXIuY29tL2Fhcm9ucGs+DQoN Cg0KDQpPbiBUaHUsIEp1bCAxMSwgMjAxOSBhdCAyOjUyIFBNIEdlb3JnZSBGbGV0Y2hlciA8Z2Zm bGV0Y2hAYW9sLmNvbTxtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+IHdyb3RlOg0KWW91IGFyZSBj b3JyZWN0IHRoYXQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCByZXF1aXJlZCBmb3IgcHVi bGljIGNsaWVudHMgKHdoaWNoIGRvZXNuJ3QgcHJlY2x1ZGUgdGhlIHVzZSBvZiByZWZyZXNoX3Rv a2VucykgYnV0IGZyb20gbXkgcGVyc3BlY3RpdmUgaXQgd2Vha2VucyB0aGUgc2VjdXJpdHkgYmVj YXVzZSBhbnlvbmUgd2l0aCB0aGUgcmVmcmVzaF90b2tlbiBpcyBhYmxlIHRvIGdldCBuZXcgYWNj ZXNzX3Rva2VucyB3aXRob3V0IGFueSBhZGRpdGlvbmFsIHByb29mLg0KDQpOb3cgaWYgdGhlIFNQ QSBwZXJmb3JtcyBzb21lIHNvcnQgb2YgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIG9yIERQ b1AgdGhlbiBJIHRoaW5rIGl0J3MgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzY2VuYXJpbyBhbmQg aXQgZG9lc24ndCBib3RoZXIgbWUgYXMgbXVjaCBmb3IgdGhlaXIgdG8gYmUgcmVmcmVzaF90b2tl bnMgaW4gdGhlIGJyb3dzZXIuIFRoaXMgb2YgY291cnNlIGlzIGp1c3QgbXkgcGVyc3BlY3RpdmU6 KQ0KDQpPbiA3LzEwLzE5IDc6NTYgUE0sIEFhcm9uIFBhcmVja2kgd3JvdGU6DQoyLiBUbyB1c2Ug YSByZWZyZXNoIHRva2VuIGF0IHRoZSAvdG9rZW4gZW5kcG9pbnQsIGNsaWVudCBhdXRoZW50aWNh dGlvbiBpcyByZXF1aXJlZC4gVGhpcyBpcyB3aGVyZSBpdCBnZXRzIGRpZmZpY3VsdCBmb3IgZGVm YXVsdCBTUEFzIGJlY2F1c2UgdGhleSBhcmUgcHVibGljIGNsaWVudHMgYW5kIHRoZSBvbmx5IG1l Y2hhbmlzbSB0byBhdXRoZW50aWNhdGUgdGhlbSBpcyB0aGUgY2xpZW50X2lkIHdoaWNoIGlzIGl0 c2VsZiBwdWJsaWMuIEZvciBtZSwgdGhpcyBpcyB0aGUgcmVhbCByaXNrIG9mIGV4cG9zaW5nIHRo ZSByZWZyZXNoX3Rva2VuIGluIHRoZSBicm93c2VyLj8/DQoNClJGQzY3NDkgc2F5cyAiSWYgdGhl IGNsaWVudCB0eXBlIGlzIGNvbmZpZGVudGlhbCBvcj8/dGhlIGNsaWVudCB3YXMgaXNzdWVkIGNs aWVudCBjcmVkZW50aWFscyw/P3RoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUuLi4iIHdoaWNo IEkgdGFrZSB0byBtZWFuIHRoYXQgcmVmcmVzaCB0b2tlbnMgY291bGQgYmUgdXNlZCB3aXRob3V0 IGEgY2xpZW50X3NlY3JldCwgYm90aCBmb3IgbmF0aXZlIGFuIGphdmFzY3JpcHQgYXBwcy4NCg0K VGhpcyBkaXNjdXNzaW9uIG9mIG9mZmxpbmUgdnMgb25saW5lIHJlZnJlc2ggdG9rZW5zIGlzIGlu dGVyZXN0aW5nLCBidXQgSSB3b3JyeSB0aGF0IHdlIG1heSBiZSBuYXJyb3dpbmcgb3VyIGZvY3Vz IGhlcmUgdG9vIG11Y2guDQoNClRoZXJlJ3MgYSB1c2Ugd2hlcmUgSmF2YVNjcmlwdCBhcHBzIG1h eSBiZSBhYmxlIHRvIHRha2UgYWR2YW50YWdlIG9mIG9mZmxpbmUgYWNjZXNzLCB3aGljaCBpcyBh cm91bmQgU2VydmljZSBXb3JrZXJzLiBUaGlzIGFsbG93cyBhIHdlYnNpdGUgdG8gaW5zdGFsbCBz b21lIGNvZGUgZnJvbSBhIHdlYnNpdGUgd2hpY2ggY2FuIGNvbnRpbnVlIHRvIHJ1biBpbiB0aGUg YmFja2dyb3VuZCwgdGhvdWdoIHNvbWV0aW1lcyBvbmx5IHdoaWxlIHRyaWdnZXJlZCBmcm9tIGV4 dGVybmFsIGV2ZW50cy4gT25lIHVzZWZ1bCBleGFtcGxlIG9mIHRoaXMgaXMgYSBzeW5jaW5nIGRh ZW1vbiwgd2hlcmUgYSBwdXNoIG5vdGlmaWNhdGlvbiBjYW4gYmUgc2VudCBmcm9tIGEgd2ViIHNl cnZlciB0byBhIFNlcnZpY2UgV29ya2VyLCB3aGljaCBjb3VsZCBjYXVzZSB0aGF0IGNvZGUgaW4g dGhlIGJyb3dzZXIgdG8gbmVlZCB0byBtYWtlIGEgcmVxdWVzdCB0byBhbiBBUEksIHdoaWNoIHRo ZW4gbWF5IG5lZWQgdG8gYmUgYWJsZSB0byBnZXQgYSBuZXcgYWNjZXNzIHRva2VuLCB3aGljaCBp cyBlZmZlY3RpdmVseSBvZmZsaW5lIGFjY2Vzcy4NCg0KLS0tLQ0KQWFyb24gUGFyZWNraQ0KYWFy b25wYXJlY2tpLmNvbTxodHRwOi8vYWFyb25wYXJlY2tpLmNvbS8+DQpAYWFyb25wazxodHRwOi8v dHdpdHRlci5jb20vYWFyb25waz4NCg0KDQoNCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgOToxNiBB TSBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJJ2xsIGp1c3QgYWRkIGEgY291 cGxlIG1vcmUgdGhvdWdodHMgYXJvdW5kIHJlZnJlc2hfdG9rZW5zLg0KDQoxLiBJIGFncmVlIHdp dGggRGF2aWQgdGhhdCByZWZyZXNoX3Rva2VucyBhcmUgdmFsdWFibGUgaW4gYW4gIm9ubGluZSIg c2NlbmFyaW8gYW5kIHNob3VsZCBiZSB1c2VkIHRoZXJlLg0KDQoyLiBUbyB1c2UgYSByZWZyZXNo IHRva2VuIGF0IHRoZSAvdG9rZW4gZW5kcG9pbnQsIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBy ZXF1aXJlZC4gVGhpcyBpcyB3aGVyZSBpdCBnZXRzIGRpZmZpY3VsdCBmb3IgZGVmYXVsdCBTUEFz IGJlY2F1c2UgdGhleSBhcmUgcHVibGljIGNsaWVudHMgYW5kIHRoZSBvbmx5IG1lY2hhbmlzbSB0 byBhdXRoZW50aWNhdGUgdGhlbSBpcyB0aGUgY2xpZW50X2lkIHdoaWNoIGlzIGl0c2VsZiBwdWJs aWMuIEZvciBtZSwgdGhpcyBpcyB0aGUgcmVhbCByaXNrIG9mIGV4cG9zaW5nIHRoZSByZWZyZXNo X3Rva2VuIGluIHRoZSBicm93c2VyLg0KDQozLiBJZiB0aGUgQVMgc3VwcG9ydHMgcm90YXRpb24g b2YgcmVmcmVzaF90b2tlbnMgYW5kIGFuIGF0dGFja2VyIHN0ZWFscyBvbmUgYW5kIHVzZXMgaXQs IHRoZW4gdGhlIFNQQSB3aWxsIGdldCBhbiBlcnJvciBvbiBpdCdzIG5leHQgYXR0ZW1wdCBiZWNh dXNlIGl0J3MgcmVmcmVzaF90b2tlbiB3aWxsIG5vdyBiZSBpbnZhbGlkLiBJZiB0aGUgcmVmcmVz aF90b2tlbnMgYXJlIGJvdW5kIHRvIHRoZSB1c2VyJ3MgYXV0aGVudGljYXRpb24gc2Vzc2lvbiwg dGhlbiB0aGUgdXNlciBjYW4gbG9nb3V0IHRvIGxvY2tvdXQgdGhlIGF0dGFja2VyLiBIb3dldmVy LCB0aGF0IGlzIGEgbG90IG9mICJpZnMiIGFuZCBzdGlsbCBwcm92aWRlcyB0aGUgYXR0YWNrZXIg d2l0aCB0aW1lIHRvIGxldmVyYWdlIGFjY2VzcyB2aWEgdGhlIGNvbXByb21pc2VkIHJlZnJlc2hf dG9rZW4uDQoNCkluIHByaW5jaXBsZSwgSSBhZ3JlZSB3aXRoIHRoZSByZWNvbW1lbmRhdGlvbiB0 aGF0IFNQQXMgc2hvdWxkbid0IGhhdmUgcmVmcmVzaF90b2tlbnMgaW4gdGhlIGJyb3dzZXIuIElm IGl0J3Mgbm90IHBvc3NpYmxlIHRvIGVhc2lseSByZWZyZXNoIHRoZSBhY2Nlc3MgdG9rZW4gdmlh IGEgaGlkZGVuIGlmcmFtZSAoYmVjb21pbmcgbW9yZSBkaWZmaWN1bHQgd2l0aCBhbGwgdGhlIGJy b3dzZXIvcHJpdmFjeSBjb29raWUgY2hhbmdlcy4gZS5nLiBJVFAyLlgpIHRoZW4gSSdkIHJlY29t bWVuZCB0byB1c2UgYSBzaW1wbGUgc2VydmVyIGNvbXBvbmVudCBzdWNoIHRoYXQgdGhlIGJhY2tl bmQgZm9yIHRoZSBTUEEgY2FuIHVzZSBhdXRob3JpemF0aW9uX2NvZGUgZmxvdyBhbmQgcHJvdGVj dCBhIGNsaWVudF9zZWNyZXQuDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiA3LzgvMTkgMTE6MTcg UE0sIERhdmlkIFdhaXRlIHdyb3RlOg0KDQpPbiBKdWwgOCwgMjAxOSwgYXQgNzoxMCBQTSwgTGVv IFRvaGlsbCA8bGVvdG9oaWxsQGdtYWlsLmNvbTxtYWlsdG86bGVvdG9oaWxsQGdtYWlsLmNvbT4+ IHdyb3RlOg0KUmUgOC4gUmVmcmVzaCBUb2tlbnMNCg0KPz8/PyAiRm9yIHB1YmxpYyBjbGllbnRz LCB0aGUgcmlzayBvZiBhIGxlYWtlZCByZWZyZXNoIHRva2VuIGlzIG11Y2gNCj8/ID8/Z3JlYXRl ciB0aGFuIGxlYWtlZCBhY2Nlc3MgdG9rZW5zLCBzaW5jZSBhbiBhdHRhY2tlciBjYW4gcG90ZW50 aWFsbHkNCj8/ID8/Y29udGludWUgdXNpbmcgdGhlIHN0b2xlbiByZWZyZXNoIHRva2VuIHRvIG9i dGFpbiBuZXcgYWNjZXNzIHdpdGhvdXQNCj8/ID8/YmVpbmcgZGV0ZWN0YWJsZSBieSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuPz8gIg0KDQooZmlyc3QsIG5vdGUgdGhlIHR5cG8gInN0b2tlbiIu KQ0KDQpJcyBpdCBhbHdheXMgImhpZ2hlciByaXNrIj8/PyBJIGNvdWxkIGV2ZW4gYXJndWUgdGhh dCBsZWFrYWdlIG9mIGEgcmVmcmVzaCB0b2tlbiBpcyBsb3dlciByaXNrLiBBcyBhIGJlYXJlciBk b2N1bWVudCwgYSBsZWFrZWQgYWNjZXNzIHRva2VuIGFsbG93cyBhY2Nlc3MgdG8gcmVzb3VyY2Vz IHVudGlsIGl0IGV4cGlyZXMuPz8gQSBsZWFrZWQgcmVmcmVzaCB0b2tlbiwgdG8gYmUgdXNlZnVs LD8/IHJlcXVpcmVzIGFuIGV4Y2hhbmdlIHdpdGggdGhlIEFTLCBhbmQgdGhlIEFTIHdvdWxkIGhh dmUgdGhlIG9wcG9ydHVuaXR5IHRvIGNoZWNrIHdoZXRoZXIgdGhlIHJlZnJlc2ggdG9rZW4gaXMg c3RpbGwgdmFsaWQgKGhhcyBub3QgYmVlbiByZXZva2VkKS4/PyAob2YgY291cnNlIHJldm9jYXRp b24gbWlnaHQgTk9UIGhhdmUgaGFwcGVuZWQsIGJ1dCB0aGVuIGFnYWluLCBpdCBtaWdodCBoYXZl LikNCg0KSSBhZ3JlZSAod2l0aCBjYXZlYXRzLCBvZiBjb3Vyc2UpLg0KDQpBY2Nlc3MgdG9rZW5z IGFuZCByZWZyZXNoIHRva2VucyBtYXkgb3IgbWF5IG5vdCBiZSBhdHRhY2hlZCAoYnkgcG9saWN5 KSB0byBhbiBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIGxpZmV0aW1lLiBJdCBpcyBmYXIgZWFzaWVy IHRvIHBpY3R1cmUgcmVmcmVzaCB0b2tlbnMgd2hpY2ggYXJlIG5vdCBhdHRhY2hlZCB0byBhbiBh dXRoZW50aWNhdGlvbiBzZXNzaW9uIChzb21ldGltZXMgY2FsbGVkID8/P29mZmxpbmU/Pz8gYWNj ZXNzKSBiZWluZyBpbmFwcHJvcHJpYXRlIGZvciBhIGJyb3dzZXItYmFzZWQgYXBwLCB3aGljaCBp cyBuZWFybHkgYWx3YXlzIGEgY2xpZW50IHRoYXQgdGhlIHJlc291cmNlIG93bmVyIGlzIGludGVy YWN0aW5nIHdpdGguDQoNClZhcmlhbnRzIHRoYXQgbWF5IHdhbnQgb2ZmbGluZSB0b2tlbnMgYXJl IGxlc3MgZWFzeSB0byBpbWFnaW5lIC0gcGVyaGFwcyBicm93c2VyIGV4dGVuc2lvbnM/DQoNCkkg YmVsaWV2ZSB0aGUgbGFuZ3VhZ2UgY3VycmVudGx5IHRoZXJlIGlzIGR1ZSB0byBBUyBpbXBsZW1l bnRhdGlvbnMgcHJlZG9taW5hbnRseSB0cmVhdGluZyByZWZyZXNoIHRva2VucyBhcyBiZWluZyBm b3Igb2ZmbGluZSBhY2Nlc3MsIGFuZCBhY2Nlc3MgdG9rZW4gbGlmZXRpbWUgYmVpbmcgc2hvcnQg ZW5vdWdoIHRvIG5vdCBvdXRsYXN0IGFuIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24uDQoNCkZ1cnRo ZXJtb3JlLCBzaW5jZSB0aGUgYWNjZXNzIHRva2VuIGlzIHRyYW5zbWl0dGVkIHRvIG90aGVyIHNl cnZlcnMsIHRoZSByaXNrIG9mIGV4cG9zdXJlIGlzIGdyZWF0ZXIsIGR1ZSB0byBwb3NzaWJsZSB2 dWxuZXJhYmlsaXRpZXMgaW4gdGhvc2UgY2FsbGVkIHN5c3RlbXMgKGUuZy4sIGxvZ3MpLj8/IElz bid0IHRoaXMgdGhlIHJlYXNvbiB0aGF0IHdlIGhhdmUgcmVmcmVzaCB0b2tlbnM/IERvbid0IHJl ZnJlc2ggdG9rZW5zIGV4aXN0IGJlY2F1c2UgYWNjZXNzIHRva2VucyBzaG91bGQgaGF2ZSBzaG9y dCBUVEwsIGJlY2F1c2UgdGhleSBhcmUgd2lkZWx5IGRpc3RyaWJ1dGVkPw0KDQpZZXMuIE9uY2Ug eW91IGFja25vd2xlZGdlIHRoZSBleGlzdGVuY2Ugb2YgPz8/b25saW5lPz8/IHJlZnJlc2ggdG9r ZW5zLCB0aGV5IGJlY29tZSBhIHN0cm9uZyBzZWN1cml0eSBjb21wb25lbnQ6DQoNCi0gUmVmcmVz aCB0b2tlbnMgbGV0IHlvdSBzaG9ydGVuIHRoZSBhY2Nlc3MgdG9rZW4gbGlmZXRpbWUNCi0gQSBz aG9ydGVyIGFjY2VzcyB0b2tlbiBsaWZldGltZSBsZXRzIHlvdSBoYXZlIGNlbnRyYWxpemVkIHBv bGljeSB0byBpbnZhbGlkYXRlIGFjY2VzcyB3aXRob3V0IG5lZWRpbmcgdG8gcmVzb3J0IHRvIHRv a2VuIGludHJvc3BlY3Rpb24vcmV2b2NhdGlvbg0KLSBUb2tlbiByZWZyZXNoIGNhbiB0aGVvcmV0 aWNhbGx5IGJlIHVzZWQgdG8gcmVwcmVzZW50IG90aGVyIHBvbGljeSBjaGFuZ2VzIGJ5IGJvdGgg dGhlIGNsaWVudCAoY3JlYXRpbmcgdG9rZW5zIHRhcmdldGluZyBhIG5ldyByZXNvdXJjZSBzZXJ2 ZXIgb3Igd2l0aCByZWR1Y2VkIHNjb3BlcykgYW5kIHNlcnZlciAoY2hhbmdpbmcgZW50aXRsZW1l bnRzIGFuZCBhdHRyaWJ1dGVzL2NsYWltcyBlbWJlZGRlZCB3aXRoaW4gYSBzdHJ1Y3R1cmVkIHRv a2VuKQ0KLSBSZWZyZXNoIHRva2VucyBjYW4gYmUgb25lLXRpbWUtdXNlLCBhcyByZWNvbW1lbmNl ZCBieSB0aGUgc2VjdXJpdHkgQkNQLiBBIGV4ZmlsdHJhdGVkIHJlZnJlc2ggdG9rZW4gd2lsbCBy ZXN1bHQgaW4gZWl0aGVyIHRoZSBhdHRhY2tlciBvciB0aGUgdXNlciBsb3NpbmcgYWNjZXNzIG9u IHRoZSBuZXh0IHJlZnJlc2gsIGFuZCBhIGRvdWJsZSByZWZyZXNoIGlzIGEgZGV0ZWN0YWJsZSBz ZWN1cml0eSBldmVudCBieSB0aGUgQVMuDQoNCiJBZGRpdGlvbmFsbHksIGJyb3dzZXItYmFzZWQg YXBwbGljYXRpb25zIHByb3ZpZGUgbWFueSBhdHRhY2sgdmVjdG9ycyBieSB3aGljaCBhIHJlZnJl c2ggdG9rZW4gY2FuIGJlIGxlYWtlZC4iDQoNClRoZSByaXNrcyBvZiBsZWFraW5nIGEgcmVmcmVz aCB0b2tlbiBmcm9tIHRoZSBicm93c2VyIGFyZSBpZGVudGljYWwgdG8gdGhlIHJpc2tzIG9mIGxl YWtpbmcgYW4gYWNjZXNzIHRva2VuLCByaWdodD8/PyBUaGlzIHNlbnRlbmNlIGNvdWxkIGJlIGNo YW5nZWQgdG8gIi4uLiBieSB3aGljaCBhIHRva2VuIGNhbiBiZSBsZWFrZWQuIg0KDQpBIHJlZnJl c2ggdG9rZW4gaXMgImhpZ2hlciByaXNrIiBiZWNhdXNlIGl0cyBUVEwgaXMgdXN1YWxseSBncmVh dGVyIHRoYW4gdGhlIGFjY2VzcyB0b2tlbidzIFRUTC4/PyBCdXQgaWYgb3VyIGFkdmljZSBoZXJl IGxlYWRzIHRvIHBlb3BsZSB1c2luZyBsb25nZXItbGl2ZWQgYWNjZXNzIHRva2VucyAoYmVjYXVz ZSBvZiB0aGUgcHJvYmxlbXMgd2l0aCBnZXR0aW5nIGEgbmV3IGFjY2VzcyB0b2tlbiB3aXRob3V0 IGludm9sdmluZyB0aGUgdXNlciksIHRoZW4gdGhlIGFkdmljZSB3aWxsIGJlIGNvdW50ZXIgcHJv ZHVjdGl2ZS4/Pz8/IFRoZSBsb25nZXIgbGlmZSBnaXZlcyBtb3JlIHRpbWUgZm9yIHRoZSB1c2Vm dWxuZXNzIG9mIGEgYnJvd3Nlci1zaWRlIHRoZWZ0LCBhbmQgbW9yZSB0aW1lIGZvciB0aGUgdXNl ZnVsbmVzcyBvZiBhIHNlcnZlci1zaWRlIHRoZWZ0Lj8/DQoNCldoaWNoIHNjZW5hcmlvIGlzIHNh ZmVyPw0KQSkgdXNpbmcgYW4gYWNjZXNzIHRva2VuIHdpdGggYSAxMCBtaW51dGUgVFRMLCBhY2Nv bXBhbmllZCBieSBhIHJlZnJlc2ggdG9rZW4gd2l0aCBhIDEgaG91ciBUVEwNCkIpIHVzaW5nIGFu IGFjY2VzcyB0b2tlbiB3aXRoIGEgMSBob3VyIFRUTCwgYW5kIG5vIHJlZnJlc2ggdG9rZW4uPz8N Cg0KDQpHaXZlbiB0b2tlbnMgdGhhdCB0cmFjayBhdXRoZW50aWNhdGlvbiBsaWZldGltZSwgaXQg aXMgaGFyZCB0byBtYWtlIGEgY2FzZSB0aGF0IHJlZnJlc2ggdG9rZW5zIHdoaWNoIGxhc3QgZm9y IHRoZSBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIGFyZSBhIGdyZWF0ZXIgc2VjdXJpdHkgcmlzayB0 aGFuIG9wYXF1ZSBhY2Nlc3MgdG9rZW5zIChyZXF1aXJpbmcgdG9rZW4gaW50cm9zcGVjdGlvbikg dGhhdCB3aWxsIGxhc3QgdGhlIHNhbWUgdGltZS4/Pw0KDQpUeXBpY2FsbHkgYW4gQVMgKG9yIE9Q KSB3b3VsZCBpc3N1ZSBhIHN0cnVjdHVyZWQgYWNjZXNzIHRva2VuIHdpdGggYSBsaWZldGltZSBl eHBlY3RlZCB0byBleHBpcmUgYmVmb3JlIHRoZSBhdXRoZW50aWNhdGlvbiBzZXNzaW9uLCB3aXRo IG5ldyB0b2tlbnMgaXNzdWVkIHZpYSByZXF1ZXN0cyBtYWRlIGluIGFuIGVtYmVkZGVkLCBpZnJh bWUgKGhpZGRlbiwgcHJvbXB0PW5vbmUpLiBUaGVyZSBtYXkgYmUgYmVuZWZpdHMgaGVyZSBvZiB1 c2VyIGNvb2tpZXMgKG9yIHBlcmhhcHMgbWFuYWdlZC1kZXZpY2UgaW5mb3JtYXRpb24pIGFnYWlu c3QgYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBiZWluZyB1c2VkIHRvIG1ha2UgZGVjaXNpb25z IHRoYXQgY291bGQgbm90IGJlIG1hZGUgYnkgYSByZWZyZXNoIGFnYWluc3QgdGhlIHRva2VuIGVu ZHBvaW50Lj8/DQoNCkk/Pz9kIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyBob3cgc3Ryb25nIG9m IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIHRoaXMgbWlnaHQgYmUgZm9yIGRlcGxveW1lbnRzIC0g SSBjb3VsZCBzZWUgYSBub24tc2VjdXJpdHkgYXJndW1lbnQgdGhhdCB0aGUgQkNQIHNob3VsZCBv bmx5IGhhdmUgb25lIHJlY29tbWVuZGVkIGFwcHJvYWNoIGhlcmUsIGFuZCB0aGF0IHRoZXJlIGFy ZSBkZXBsb3ltZW50cyBuZWVkaW5nIHRoZSBpZnJhbWUgYXBwcm9hY2guDQoNCi1EVw0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_D676DDDE20FE40048E3F124A560A1C20mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <01D49DD73CA1D44DACA0CA17410366C3@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgdGhpbmsgaXQgY2FuIGJlIGFzIHNpbXBsZSBh czoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PlNIT1VMRCBOT1QgdXNlIHJlZnJlc2ggdG9rZW5zIHdpdGhvdXQgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIG9yIGtleSBwcm9vZiBvZiBzb21lIGtpbmQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBvdGhlciB3b3Jkcywgbm8g YmVhcmVyIHJlZnJlc2ggdG9rZW5zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBKdWwgMTksIDIwMTksIGF0IDc6NDkgUE0sIEFhcm9uIFBhcmVja2kgJmx0 OzxhIGhyZWY9Im1haWx0bzphYXJvbkBwYXJlY2tpLmNvbSIgY2xhc3M9IiI+YWFyb25AcGFyZWNr aS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+U28gd2hh dCBJJ20gaGVhcmluZyBpbiB0aGlzIHRocmVhZCBpcyBlc3NlbnRpYWxseSB0aGF0Og0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MSkgZGVwZW5kaW5n IG9uIGhvdyBpdCdzIGltcGxlbWVudGVkLCB1c2luZyBhIHJlZnJlc2ggdG9rZW4gaW4gYSBTUEEg Y2FuIHByb3ZpZGUgc2VjdXJpdHkgYmVuZWZpdHMgb3ZlciB1c2luZyBvbmx5IGFjY2VzcyB0b2tl bnM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MikgaXQgaXMgc3RpbGwgJnF1b3Q7ZGFuZ2Vyb3VzJnF1 b3Q7IHRvIGFsbG93IHJlZnJlc2ggdG9rZW5zIHRvIGJlIHVzZWQgd2l0aG91dCBjbGllbnQgYXV0 aGVudGljYXRpb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MykgaWYgdGhlcmUgaXMgYSB3YXkgdG8g ZG8gc29tZSBzb3J0IG9mIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBvciBwcm9vZiBvZiBw b3NzZXNzaW9uLCB0aGVuIHVzaW5nIGEgcmVmcmVzaCB0b2tlbiB3b3VsZCBpbiBmYWN0IGJlIG1v cmUgc2VjdXJlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5TaW5jZSB0aGVzZSBwb2ludHMgYXJlIGluIGNvbmZsaWN0IHdpdGggZWFjaCBv dGhlciwgYW5kIGRlcGVuZCBvbiB0aGluZ3MgY3VycmVudGx5IGluIGZsdXgsIGl0IHNlZW1zIGxp a2UgdGhlIGJlc3QgdGhpbmcgdG8gZG8gYXQgdGhpcyB0aW1lIGlzIHRvIHJlbW92ZSB0aGUgZ3Vp ZGFuY2Ugb24gcmVmcmVzaCB0b2tlbnMgaW4gYnJvd3Nlci1iYXNlZCBhcHBzLiBNYXliZSBsZWF2 aW5nIHRoZSBtZW50aW9uIG9mIHJvdGF0aW5nDQogdGhlIHJlZnJlc2ggdG9rZW4gb24gZXZlcnkg dXNlLCBidXQgSSdtIGluY2xpbmVkIHRvIHJlbW92ZSB0aGUgJnF1b3Q7U0hPVUxEIE5PVCBpc3N1 ZSByZWZyZXNoIHRva2VucyZxdW90OyBzdGF0ZW1lbnQgaW4gb3JkZXIgdG8gbGVhdmUgcm9vbSBm b3IgRFBvUCBvciBzaW1pbGFyIGluIHRoZSBmdXR1cmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Tb3VuZCByZWFzb25hYmxlPzxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiIGRhdGEtc21h cnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRpdiBjbGFzcz0iIj4tLS0tPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkFhcm9uIFBhcmVja2k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cDovL2Fhcm9ucGFyZWNraS5jb20vIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YWFyb25wYXJl Y2tpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIu Y29tL2Fhcm9ucGsiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5AYWFyb25wazwvYT48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9u IFRodSwgSnVsIDExLCAyMDE5IGF0IDI6NTIgUE0gR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBocmVm PSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSIgY2xhc3M9IiI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4m Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBz b2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBiZ2NvbG9yPSIj RkZGRkZGIiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlm IiBjbGFzcz0iIj5Zb3UgYXJlIGNvcnJlY3QgdGhhdCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg bm90IHJlcXVpcmVkIGZvciBwdWJsaWMgY2xpZW50cyAod2hpY2ggZG9lc24ndCBwcmVjbHVkZSB0 aGUgdXNlIG9mIHJlZnJlc2hfdG9rZW5zKSBidXQgZnJvbSBteSBwZXJzcGVjdGl2ZSBpdCB3ZWFr ZW5zIHRoZSBzZWN1cml0eQ0KIGJlY2F1c2UgYW55b25lIHdpdGggdGhlIHJlZnJlc2hfdG9rZW4g aXMgYWJsZSB0byBnZXQgbmV3IGFjY2Vzc190b2tlbnMgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBw cm9vZi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3cgaWYgdGhlIFNQQSBwZXJmb3Jt cyBzb21lIHNvcnQgb2YgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIG9yIERQb1AgdGhlbiBJ IHRoaW5rIGl0J3MgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzY2VuYXJpbyBhbmQgaXQgZG9lc24n dCBib3RoZXIgbWUgYXMgbXVjaCBmb3IgdGhlaXIgdG8gYmUgcmVmcmVzaF90b2tlbnMgaW4gdGhl IGJyb3dzZXIuIFRoaXMgb2YgY291cnNlIGlzIGp1c3QgbXkgcGVyc3BlY3RpdmU6KTxiciBjbGFz cz0iIj4NCjwvZm9udD48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbC1tXy00NjQ2MjU3 MDM0MjYzNDA0NzQybW96LWNpdGUtcHJlZml4Ij5PbiA3LzEwLzE5IDc6NTYgUE0sIEFhcm9uIFBh cmVja2kgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbCxzYW5zLXNlcmlmIiBjbGFzcz0iIj4yLiBU byB1c2UgYSByZWZyZXNoIHRva2VuIGF0IHRoZSAvdG9rZW4gZW5kcG9pbnQsIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpcyByZXF1aXJlZC4gVGhpcyBpcyB3aGVyZSBpdCBnZXRzIGRpZmZpY3VsdCBm b3IgZGVmYXVsdCBTUEFzIGJlY2F1c2UgdGhleSBhcmUgcHVibGljIGNsaWVudHMgYW5kIHRoZSBv bmx5IG1lY2hhbmlzbSB0byBhdXRoZW50aWNhdGUNCiB0aGVtIGlzIHRoZSBjbGllbnRfaWQgd2hp Y2ggaXMgaXRzZWxmIHB1YmxpYy4gRm9yIG1lLCB0aGlzIGlzIHRoZSByZWFsIHJpc2sgb2YgZXhw b3NpbmcgdGhlIHJlZnJlc2hfdG9rZW4gaW4gdGhlIGJyb3dzZXIuPz88L3NwYW4+PC9ibG9ja3F1 b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbC1tXy00NjQ2 MjU3MDM0MjYzNDA0NzQyZ21haWxfc2lnbmF0dXJlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJGQzY3NDkgc2F5cyAmcXVvdDtJZiB0aGUgY2xp ZW50IHR5cGUgaXMgY29uZmlkZW50aWFsIG9yPz90aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50 IGNyZWRlbnRpYWxzLD8/dGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZS4uLiZxdW90OyB3aGlj aCBJIHRha2UgdG8gbWVhbiB0aGF0IHJlZnJlc2ggdG9rZW5zIGNvdWxkIGJlIHVzZWQgd2l0aG91 dCBhIGNsaWVudF9zZWNyZXQsIGJvdGggZm9yIG5hdGl2ZSBhbiBqYXZhc2NyaXB0IGFwcHMuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aGlzIGRpc2N1c3Npb24gb2Ygb2ZmbGluZSB2cyBvbmxpbmUgcmVmcmVzaCB0b2tlbnMgaXMgaW50 ZXJlc3RpbmcsIGJ1dCBJIHdvcnJ5IHRoYXQgd2UgbWF5IGJlIG5hcnJvd2luZyBvdXIgZm9jdXMg aGVyZSB0b28gbXVjaC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlRoZXJlJ3MgYSB1c2Ugd2hlcmUgSmF2YVNjcmlwdCBhcHBzIG1heSBi ZSBhYmxlIHRvIHRha2UgYWR2YW50YWdlIG9mIG9mZmxpbmUgYWNjZXNzLCB3aGljaCBpcyBhcm91 bmQgU2VydmljZSBXb3JrZXJzLiBUaGlzIGFsbG93cyBhIHdlYnNpdGUgdG8gaW5zdGFsbCBzb21l IGNvZGUgZnJvbSBhIHdlYnNpdGUgd2hpY2ggY2FuIGNvbnRpbnVlIHRvIHJ1biBpbiB0aGUgYmFj a2dyb3VuZCwgdGhvdWdoIHNvbWV0aW1lcyBvbmx5DQogd2hpbGUgdHJpZ2dlcmVkIGZyb20gZXh0 ZXJuYWwgZXZlbnRzLiBPbmUgdXNlZnVsIGV4YW1wbGUgb2YgdGhpcyBpcyBhIHN5bmNpbmcgZGFl bW9uLCB3aGVyZSBhIHB1c2ggbm90aWZpY2F0aW9uIGNhbiBiZSBzZW50IGZyb20gYSB3ZWIgc2Vy dmVyIHRvIGEgU2VydmljZSBXb3JrZXIsIHdoaWNoIGNvdWxkIGNhdXNlIHRoYXQgY29kZSBpbiB0 aGUgYnJvd3NlciB0byBuZWVkIHRvIG1ha2UgYSByZXF1ZXN0IHRvIGFuIEFQSSwgd2hpY2ggdGhl biBtYXkNCiBuZWVkIHRvIGJlIGFibGUgdG8gZ2V0IGEgbmV3IGFjY2VzcyB0b2tlbiwgd2hpY2gg aXMgZWZmZWN0aXZlbHkgb2ZmbGluZSBhY2Nlc3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tLS0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkFhcm9uIFBhcmVja2k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL2Fhcm9u cGFyZWNraS5jb20vIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YWFyb25wYXJlY2tpLmNvbTwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIuY29tL2Fhcm9u cGsiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5AYWFyb25wazwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVHVlLCBKdWwgOSwgMjAxOSBhdCA5OjE2 IEFNIEdlb3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2g9PGEgaHJlZj0ibWFpbHRvOjQwYW9sLmNv bUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQwYW9sLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2Jv cmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFy aWFsLA0KICAgICAgICAgICAgICBzYW5zLXNlcmlmIiBjbGFzcz0iIj5JJ2xsIGp1c3QgYWRkIGEg Y291cGxlIG1vcmUgdGhvdWdodHMgYXJvdW5kIHJlZnJlc2hfdG9rZW5zLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjEuIEkgYWdyZWUgd2l0aCBEYXZpZCB0aGF0IHJlZnJlc2hfdG9rZW5z IGFyZSB2YWx1YWJsZSBpbiBhbiAmcXVvdDtvbmxpbmUmcXVvdDsgc2NlbmFyaW8gYW5kIHNob3Vs ZCBiZSB1c2VkIHRoZXJlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjIuIFRvIHVzZSBh IHJlZnJlc2ggdG9rZW4gYXQgdGhlIC90b2tlbiBlbmRwb2ludCwgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGlzIHJlcXVpcmVkLiBUaGlzIGlzIHdoZXJlIGl0IGdldHMgZGlmZmljdWx0IGZvciBkZWZh dWx0IFNQQXMgYmVjYXVzZSB0aGV5IGFyZSBwdWJsaWMgY2xpZW50cyBhbmQgdGhlIG9ubHkgbWVj aGFuaXNtIHRvIGF1dGhlbnRpY2F0ZSB0aGVtIGlzIHRoZSBjbGllbnRfaWQgd2hpY2ggaXMgaXRz ZWxmIHB1YmxpYy4gRm9yIG1lLA0KIHRoaXMgaXMgdGhlIHJlYWwgcmlzayBvZiBleHBvc2luZyB0 aGUgcmVmcmVzaF90b2tlbiBpbiB0aGUgYnJvd3Nlci4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KMy4gSWYgdGhlIEFTIHN1cHBvcnRzIHJvdGF0aW9uIG9mIHJlZnJlc2hfdG9rZW5zIGFu ZCBhbiBhdHRhY2tlciBzdGVhbHMgb25lIGFuZCB1c2VzIGl0LCB0aGVuIHRoZSBTUEEgd2lsbCBn ZXQgYW4gZXJyb3Igb24gaXQncyBuZXh0IGF0dGVtcHQgYmVjYXVzZSBpdCdzIHJlZnJlc2hfdG9r ZW4gd2lsbCBub3cgYmUgaW52YWxpZC4gSWYgdGhlIHJlZnJlc2hfdG9rZW5zIGFyZSBib3VuZCB0 byB0aGUgdXNlcidzIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24sDQogdGhlbiB0aGUgdXNlciBjYW4g bG9nb3V0IHRvIGxvY2tvdXQgdGhlIGF0dGFja2VyLiBIb3dldmVyLCB0aGF0IGlzIGEgbG90IG9m ICZxdW90O2lmcyZxdW90OyBhbmQgc3RpbGwgcHJvdmlkZXMgdGhlIGF0dGFja2VyIHdpdGggdGlt ZSB0byBsZXZlcmFnZSBhY2Nlc3MgdmlhIHRoZSBjb21wcm9taXNlZCByZWZyZXNoX3Rva2VuLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIHByaW5jaXBsZSwgSSBhZ3JlZSB3aXRoIHRo ZSByZWNvbW1lbmRhdGlvbiB0aGF0IFNQQXMgc2hvdWxkbid0IGhhdmUgcmVmcmVzaF90b2tlbnMg aW4gdGhlIGJyb3dzZXIuIElmIGl0J3Mgbm90IHBvc3NpYmxlIHRvIGVhc2lseSByZWZyZXNoIHRo ZSBhY2Nlc3MgdG9rZW4gdmlhIGEgaGlkZGVuIGlmcmFtZSAoYmVjb21pbmcgbW9yZSBkaWZmaWN1 bHQgd2l0aCBhbGwgdGhlIGJyb3dzZXIvcHJpdmFjeSBjb29raWUgY2hhbmdlcy4gZS5nLiBJVFAy LlgpDQogdGhlbiBJJ2QgcmVjb21tZW5kIHRvIHVzZSBhIHNpbXBsZSBzZXJ2ZXIgY29tcG9uZW50 IHN1Y2ggdGhhdCB0aGUgYmFja2VuZCBmb3IgdGhlIFNQQSBjYW4gdXNlIGF1dGhvcml6YXRpb25f Y29kZSBmbG93IGFuZCBwcm90ZWN0IGEgY2xpZW50X3NlY3JldC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KR2VvcmdlPGJyIGNsYXNzPSIiPg0KPC9m b250PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsLW1fLTQ2NDYyNTcwMzQyNjM0MDQ3 NDJnbWFpbC1tXy00MDMzNjM5MDM1NTA1MzA5OTYzbW96LWNpdGUtcHJlZml4Ij4NCk9uIDcvOC8x OSAxMToxNyBQTSwgRGF2aWQgV2FpdGUgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1 bCA4LCAyMDE5LCBhdCA3OjEwIFBNLCBMZW8gVG9oaWxsICZsdDs8YSBocmVmPSJtYWlsdG86bGVv dG9oaWxsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmxlb3RvaGlsbEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+UmUgOC4gUmVmcmVzaCBUb2tlbnM8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo/Pz8/ICZxdW90O0ZvciBwdWJsaWMgY2xpZW50cywgdGhlIHJp c2sgb2YgYSBsZWFrZWQgcmVmcmVzaCB0b2tlbiBpcyBtdWNoPGJyIGNsYXNzPSIiPg0KPz8gPz9n cmVhdGVyIHRoYW4gbGVha2VkIGFjY2VzcyB0b2tlbnMsIHNpbmNlIGFuIGF0dGFja2VyIGNhbiBw b3RlbnRpYWxseTxiciBjbGFzcz0iIj4NCj8/ID8/Y29udGludWUgdXNpbmcgdGhlIHN0b2xlbiBy ZWZyZXNoIHRva2VuIHRvIG9idGFpbiBuZXcgYWNjZXNzIHdpdGhvdXQ8YnIgY2xhc3M9IiI+DQo/ PyA/P2JlaW5nIGRldGVjdGFibGUgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLj8/ICZxdW90 OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+KGZpcnN0LCBub3RlIHRoZSB0eXBvICZxdW90O3N0b2tlbiZxdW90Oy4pPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JcyBpdCBhbHdh eXMgJnF1b3Q7aGlnaGVyIHJpc2smcXVvdDs/Pz8gSSBjb3VsZCBldmVuIGFyZ3VlIHRoYXQgbGVh a2FnZSBvZiBhIHJlZnJlc2ggdG9rZW4gaXMgbG93ZXIgcmlzay4gQXMgYSBiZWFyZXIgZG9jdW1l bnQsIGEgbGVha2VkIGFjY2VzcyB0b2tlbiBhbGxvd3MgYWNjZXNzIHRvIHJlc291cmNlcyB1bnRp bCBpdCBleHBpcmVzLj8/IEEgbGVha2VkIHJlZnJlc2ggdG9rZW4sIHRvIGJlIHVzZWZ1bCw/PyBy ZXF1aXJlcyBhbiBleGNoYW5nZQ0KIHdpdGggdGhlIEFTLCBhbmQgdGhlIEFTIHdvdWxkIGhhdmUg dGhlIG9wcG9ydHVuaXR5IHRvIGNoZWNrIHdoZXRoZXIgdGhlIHJlZnJlc2ggdG9rZW4gaXMgc3Rp bGwgdmFsaWQgKGhhcyBub3QgYmVlbiByZXZva2VkKS4/PyAob2YgY291cnNlIHJldm9jYXRpb24g bWlnaHQgTk9UIGhhdmUgaGFwcGVuZWQsIGJ1dCB0aGVuIGFnYWluLCBpdCBtaWdodCBoYXZlLikN CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJIGFncmVlICh3aXRoIGNhdmVhdHMs IG9mIGNvdXJzZSkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BY2Nlc3MgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyBtYXkgb3IgbWF5 IG5vdCBiZSBhdHRhY2hlZCAoYnkgcG9saWN5KSB0byBhbiBhdXRoZW50aWNhdGlvbiBzZXNzaW9u IGxpZmV0aW1lLiBJdCBpcyBmYXIgZWFzaWVyIHRvIHBpY3R1cmUgcmVmcmVzaCB0b2tlbnMgd2hp Y2ggYXJlIG5vdCBhdHRhY2hlZCB0byBhbiBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIChzb21ldGlt ZXMgY2FsbGVkID8/P29mZmxpbmU/Pz8gYWNjZXNzKQ0KIGJlaW5nIGluYXBwcm9wcmlhdGUgZm9y IGEgYnJvd3Nlci1iYXNlZCBhcHAsIHdoaWNoIGlzIG5lYXJseSBhbHdheXMgYSBjbGllbnQgdGhh dCB0aGUgcmVzb3VyY2Ugb3duZXIgaXMgaW50ZXJhY3Rpbmcgd2l0aC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlZhcmlhbnRzIHRoYXQg bWF5IHdhbnQgb2ZmbGluZSB0b2tlbnMgYXJlIGxlc3MgZWFzeSB0byBpbWFnaW5lIC0gcGVyaGFw cyBicm93c2VyIGV4dGVuc2lvbnM/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGJlbGlldmUgdGhlIGxhbmd1YWdlIGN1cnJlbnRseSB0 aGVyZSBpcyBkdWUgdG8gQVMgaW1wbGVtZW50YXRpb25zIHByZWRvbWluYW50bHkgdHJlYXRpbmcg cmVmcmVzaCB0b2tlbnMgYXMgYmVpbmcgZm9yIG9mZmxpbmUgYWNjZXNzLCBhbmQgYWNjZXNzIHRv a2VuIGxpZmV0aW1lIGJlaW5nIHNob3J0IGVub3VnaCB0byBub3Qgb3V0bGFzdCBhbiBhdXRoZW50 aWNhdGlvbiBzZXNzaW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+RnVy dGhlcm1vcmUsIHNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdHJhbnNtaXR0ZWQgdG8gb3RoZXIg c2VydmVycywgdGhlIHJpc2sgb2YgZXhwb3N1cmUgaXMgZ3JlYXRlciwgZHVlIHRvIHBvc3NpYmxl IHZ1bG5lcmFiaWxpdGllcyBpbiB0aG9zZSBjYWxsZWQgc3lzdGVtcyAoZS5nLiwgbG9ncykuPz8g SXNuJ3QgdGhpcyB0aGUgcmVhc29uIHRoYXQgd2UgaGF2ZSByZWZyZXNoIHRva2Vucz8gRG9uJ3Qg cmVmcmVzaCB0b2tlbnMNCiBleGlzdCBiZWNhdXNlIGFjY2VzcyB0b2tlbnMgc2hvdWxkIGhhdmUg c2hvcnQgVFRMLCBiZWNhdXNlIHRoZXkgYXJlIHdpZGVseSBkaXN0cmlidXRlZD88YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KWWVzLiBPbmNlIHlvdSBhY2tub3dsZWRnZSB0aGUgZXhp c3RlbmNlIG9mID8/P29ubGluZT8/PyByZWZyZXNoIHRva2VucywgdGhleSBiZWNvbWUgYSBzdHJv bmcgc2VjdXJpdHkgY29tcG9uZW50OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBSZWZyZXNoIHRva2VucyBsZXQgeW91IHNob3J0ZW4g dGhlIGFjY2VzcyB0b2tlbiBsaWZldGltZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIEEgc2hvcnRl ciBhY2Nlc3MgdG9rZW4gbGlmZXRpbWUgbGV0cyB5b3UgaGF2ZSBjZW50cmFsaXplZCBwb2xpY3kg dG8gaW52YWxpZGF0ZSBhY2Nlc3Mgd2l0aG91dCBuZWVkaW5nIHRvIHJlc29ydCB0byB0b2tlbiBp bnRyb3NwZWN0aW9uL3Jldm9jYXRpb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBUb2tlbiByZWZy ZXNoIGNhbiB0aGVvcmV0aWNhbGx5IGJlIHVzZWQgdG8gcmVwcmVzZW50IG90aGVyIHBvbGljeSBj aGFuZ2VzIGJ5IGJvdGggdGhlIGNsaWVudCAoY3JlYXRpbmcgdG9rZW5zIHRhcmdldGluZyBhIG5l dyByZXNvdXJjZSBzZXJ2ZXIgb3Igd2l0aCByZWR1Y2VkIHNjb3BlcykgYW5kIHNlcnZlciAoY2hh bmdpbmcgZW50aXRsZW1lbnRzIGFuZCBhdHRyaWJ1dGVzL2NsYWltcyBlbWJlZGRlZCB3aXRoaW4g YSBzdHJ1Y3R1cmVkDQogdG9rZW4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gUmVmcmVzaCB0b2tl bnMgY2FuIGJlIG9uZS10aW1lLXVzZSwgYXMgcmVjb21tZW5jZWQgYnkgdGhlIHNlY3VyaXR5IEJD UC4gQSBleGZpbHRyYXRlZCByZWZyZXNoIHRva2VuIHdpbGwgcmVzdWx0IGluIGVpdGhlciB0aGUg YXR0YWNrZXIgb3IgdGhlIHVzZXIgbG9zaW5nIGFjY2VzcyBvbiB0aGUgbmV4dCByZWZyZXNoLCBh bmQgYSBkb3VibGUgcmVmcmVzaCBpcyBhIGRldGVjdGFibGUgc2VjdXJpdHkgZXZlbnQgYnkgdGhl DQogQVMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mcXVvdDtBZGRpdGlv bmFsbHksIGJyb3dzZXItYmFzZWQgYXBwbGljYXRpb25zIHByb3ZpZGUgbWFueSBhdHRhY2sgdmVj dG9ycyBieSB3aGljaCBhIHJlZnJlc2ggdG9rZW4gY2FuIGJlIGxlYWtlZC4mcXVvdDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBy aXNrcyBvZiBsZWFraW5nIGEgcmVmcmVzaCB0b2tlbiBmcm9tIHRoZSBicm93c2VyIGFyZSBpZGVu dGljYWwgdG8gdGhlIHJpc2tzIG9mIGxlYWtpbmcgYW4gYWNjZXNzIHRva2VuLCByaWdodD8/PyBU aGlzIHNlbnRlbmNlIGNvdWxkIGJlIGNoYW5nZWQgdG8gJnF1b3Q7Li4uIGJ5IHdoaWNoDQo8aSBj bGFzcz0iIj5hIHRva2VuPC9pPiBjYW4gYmUgbGVha2VkLiZxdW90OzxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ QSByZWZyZXNoIHRva2VuIGlzICZxdW90O2hpZ2hlciByaXNrJnF1b3Q7IGJlY2F1c2UgaXRzIFRU TCBpcyB1c3VhbGx5IGdyZWF0ZXIgdGhhbiB0aGUgYWNjZXNzIHRva2VuJ3MgVFRMLj8/IEJ1dCBp ZiBvdXIgYWR2aWNlIGhlcmUgbGVhZHMgdG8gcGVvcGxlIHVzaW5nIGxvbmdlci1saXZlZCBhY2Nl c3MgdG9rZW5zIChiZWNhdXNlIG9mIHRoZSBwcm9ibGVtcyB3aXRoIGdldHRpbmcgYSBuZXcgYWNj ZXNzIHRva2VuIHdpdGhvdXQgaW52b2x2aW5nDQogdGhlIHVzZXIpLCB0aGVuIHRoZSBhZHZpY2Ug d2lsbCBiZSBjb3VudGVyIHByb2R1Y3RpdmUuPz8/PyBUaGUgbG9uZ2VyIGxpZmUgZ2l2ZXMgbW9y ZSB0aW1lIGZvciB0aGUgdXNlZnVsbmVzcyBvZiBhIGJyb3dzZXItc2lkZSB0aGVmdCwgYW5kIG1v cmUgdGltZSBmb3IgdGhlIHVzZWZ1bG5lc3Mgb2YgYSBzZXJ2ZXItc2lkZSB0aGVmdC4/Pw0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5XaGljaCBzY2VuYXJpbyBpcyBzYWZlcj88L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+QSkgdXNpbmcgYW4gYWNjZXNzIHRva2VuIHdpdGggYSAxMCBtaW51dGUgVFRM LCBhY2NvbXBhbmllZCBieSBhIHJlZnJlc2ggdG9rZW4gd2l0aCBhIDEgaG91ciBUVEw8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+QikgdXNpbmcgYW4gYWNjZXNzIHRva2VuIHdpdGggYSAxIGhvdXIgVFRM LCBhbmQgbm8gcmVmcmVzaCB0b2tlbi4/PzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpHaXZlbiB0b2tlbnMgdGhhdCB0cmFjayBhdXRoZW50aWNh dGlvbiBsaWZldGltZSwgaXQgaXMgaGFyZCB0byBtYWtlIGEgY2FzZSB0aGF0IHJlZnJlc2ggdG9r ZW5zIHdoaWNoIGxhc3QgZm9yIHRoZSBhdXRoZW50aWNhdGlvbiBzZXNzaW9uIGFyZSBhIGdyZWF0 ZXIgc2VjdXJpdHkgcmlzayB0aGFuIG9wYXF1ZSBhY2Nlc3MgdG9rZW5zIChyZXF1aXJpbmcgdG9r ZW4gaW50cm9zcGVjdGlvbikgdGhhdCB3aWxsIGxhc3QgdGhlIHNhbWUgdGltZS4/PzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VHlwaWNh bGx5IGFuIEFTIChvciBPUCkgd291bGQgaXNzdWUgYSBzdHJ1Y3R1cmVkIGFjY2VzcyB0b2tlbiB3 aXRoIGEgbGlmZXRpbWUgZXhwZWN0ZWQgdG8gZXhwaXJlIGJlZm9yZSB0aGUgYXV0aGVudGljYXRp b24gc2Vzc2lvbiwgd2l0aCBuZXcgdG9rZW5zIGlzc3VlZCB2aWEgcmVxdWVzdHMgbWFkZSBpbiBh biBlbWJlZGRlZCwgaWZyYW1lIChoaWRkZW4sIHByb21wdD1ub25lKS4gVGhlcmUgbWF5IGJlIGJl bmVmaXRzIGhlcmUNCiBvZiB1c2VyIGNvb2tpZXMgKG9yIHBlcmhhcHMgbWFuYWdlZC1kZXZpY2Ug aW5mb3JtYXRpb24pIGFnYWluc3QgYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBiZWluZyB1c2Vk IHRvIG1ha2UgZGVjaXNpb25zIHRoYXQgY291bGQgbm90IGJlIG1hZGUgYnkgYSByZWZyZXNoIGFn YWluc3QgdGhlIHRva2VuIGVuZHBvaW50Lj8/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JPz8/ZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJp bmcgaG93IHN0cm9uZyBvZiBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSB0aGlzIG1pZ2h0IGJlIGZv ciBkZXBsb3ltZW50cyAtIEkgY291bGQgc2VlIGEgbm9uLXNlY3VyaXR5IGFyZ3VtZW50IHRoYXQg dGhlIEJDUCBzaG91bGQgb25seSBoYXZlIG9uZSByZWNvbW1lbmRlZCBhcHByb2FjaCBoZXJlLCBh bmQgdGhhdCB0aGVyZSBhcmUgZGVwbG95bWVudHMgbmVlZGluZyB0aGUgaWZyYW1lDQogYXBwcm9h Y2guPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tRFc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8ZmllbGRzZXQgY2xhc3M9ImdtYWlsLW1fLTQ2NDYyNTcwMzQyNjM0MDQ3NDJn bWFpbC1tXy00MDMzNjM5MDM1NTA1MzA5OTYzbWltZUF0dGFjaG1lbnRIZWFkZXIiPg0KPC9maWVs ZHNldD4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fLTQ2NDYyNTcwMzQyNjM0MDQ3NDJnbWFpbC1tXy00 MDMzNjM5MDM1NTA1MzA5OTYzbW96LXF1b3RlLXByZSI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Imdt YWlsLW1fLTQ2NDYyNTcwMzQyNjM0MDQ3NDJnbWFpbC1tXy00MDMzNjM5MDM1NTA1MzA5OTYzbW96 LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJnbWFpbC1tXy00NjQ2MjU3 MDM0MjYzNDA0NzQyZ21haWwtbV8tNDAzMzYzOTAzNTUwNTMwOTk2M21vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxmaWVsZHNldCBjbGFzcz0iZ21h aWwtbV8tNDY0NjI1NzAzNDI2MzQwNDc0Mm1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0 Pg0KPHByZSBjbGFzcz0iZ21haWwtbV8tNDY0NjI1NzAzNDI2MzQwNDc0Mm1vei1xdW90ZS1wcmUi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBt YWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJnbWFpbC1tXy00NjQ2MjU3MDM0MjYzNDA0NzQybW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJnbWFpbC1tXy00NjQ2MjU3MDM0 MjYzNDA0NzQybW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi4ub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRo IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D676DDDE20FE40048E3F124A560A1C20mitedu_-- From nobody Fri Jul 19 23:09: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 B8875120A9F for ; Fri, 19 Jul 2019 23:09:43 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 na3YCBIOmv3C for ; Fri, 19 Jul 2019 23:09:40 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB94D120100 for ; Fri, 19 Jul 2019 23:09:39 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id p13so34130567wru.10 for ; Fri, 19 Jul 2019 23:09:39 -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=aNMIvZ6TQdHgE2K2oWdbDZymbOgacYEpENJRX+A+LCQ=; b=H6DvneXfBY3XhR13ddX0FilSJ0kyS1bjy3FtjPVm5qXTWVSQMnebya8lYiFiQNyU43 IiOoNwgYy3cEVq8P0S5JmiXIbojHTtz3LQgQUq5DXKVCET/u/kbOjMeOOBCRZ5nxV3xx WGsX3R1A1JbnCpgRBqW71BB3jqb7A1v72sJhE= 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=aNMIvZ6TQdHgE2K2oWdbDZymbOgacYEpENJRX+A+LCQ=; b=m5N5JxliNdhWg+DzssSyO6uJih8cnoFGDYYZq2L/7DL5whlpvHxvcy2mBWeJnQKrKr hIGAbkymGoPG5CInARevNxoAVbeg2ih4ALj6QHip4f8RhCaYECZ5j31EDzlfzIPKi0BA njYOfLiejOvs+XQg7Xmhf8m8ppjxRuezGIjXPrddUaG6L3yWQZ9tiOIsI413WAkg8LqI sSEqYjckid2S74auFW89iupBX9IjbYWfR6b0sfmp+YyiQKmLCQB94/AeSGNUp69LvTGU r/5TCjB3e/uJTswhkoSlNy2YZkLcpsMLvmjNLsifj4hqU+KQ2UFagDxXyUgrpTGkSH5G EO3g== X-Gm-Message-State: APjAAAWSNl0h5esS4MFPbdUTM7vu9K7Mgrd3e7wyUiiLsKiK90G+EuxF ogKf9XN2q9fdbg4xFVeWDYb/Tw== X-Google-Smtp-Source: APXvYqyX2AGrz35JCQhRNTssArZaP1BD6YGrQcLegJj9WEhuAr1jm0vxJm2VQSNBkZta8lAOWM0ILg== X-Received: by 2002:adf:b612:: with SMTP id f18mr49303200wre.97.1563602977991; Fri, 19 Jul 2019 23:09:37 -0700 (PDT) Received: from [192.168.1.65] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id a67sm31103367wmh.40.2019.07.19.23.09.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 23:09:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-ECCE19F6-E094-46EC-80D8-C3F6ABBEDE04 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Sat, 20 Jul 2019 07:09:36 +0100 Cc: Aaron Parecki , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> To: Justin Richer Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 06:09:47 -0000 --Apple-Mail-ECCE19F6-E094-46EC-80D8-C3F6ABBEDE04 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Can somebody spell out why refresh tokens require more protection than acces= s tokens? What threat are we worried about? The security benefits and risks of refresh tokens seem to be consistently em= phasised, yet nobody seems to ever spell out exactly what they are.=20 The main benefit is allowing timely revocation without the RS having to call= a token introspection endpoint. That=E2=80=99s primarily an architectural d= ecision rather than a security one.=20 =E2=80=94 Neil > On 20 Jul 2019, at 03:57, Justin Richer wrote: >=20 > I think it can be as simple as: >=20 > SHOULD NOT use refresh tokens without client authentication or key proof o= f some kind.=20 >=20 > In other words, no bearer refresh tokens. >=20 > =E2=80=94 Justin >=20 >> On Jul 19, 2019, at 7:49 PM, Aaron Parecki wrote: >>=20 >> So what I'm hearing in this thread is essentially that: >>=20 >> 1) depending on how it's implemented, using a refresh token in a SPA can p= rovide security benefits over using only access tokens >> 2) it is still "dangerous" to allow refresh tokens to be used without cli= ent authentication >> 3) if there is a way to do some sort of dynamic client registration or pr= oof of possession, then using a refresh token would in fact be more secure >>=20 >> Since these points are in conflict with each other, and depend on things c= urrently in flux, it seems like the best thing to do at this time is to remo= ve the guidance on refresh tokens in browser-based apps. Maybe leaving the m= ention of rotating the refresh token on every use, but I'm inclined to remov= e the "SHOULD NOT issue refresh tokens" statement in order to leave room for= DPoP or similar in the future. >>=20 >> Sound reasonable? >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >>=20 >>=20 >>> On Thu, Jul 11, 2019 at 2:52 PM George Fletcher wrote= : >>> You are correct that client authentication is not required for public cl= ients (which doesn't preclude the use of refresh_tokens) but from my perspec= tive it weakens the security because anyone with the refresh_token is able t= o get new access_tokens without any additional proof. >>>=20 >>> Now if the SPA performs some sort of Dynamic Client Registration or DPoP= then I think it's a completely different scenario and it doesn't bother me a= s much for their to be refresh_tokens in the browser. This of course is just= my perspective:) >>>=20 >>>> On 7/10/19 7:56 PM, Aaron Parecki wrote: >>>>> 2. To use a refresh token at the /token endpoint, client authenticatio= n is required. This is where it gets difficult for default SPAs because they= are public clients and the only mechanism to authenticate them is the clien= t_id which is itself public. For me, this is the real risk of exposing the r= efresh_token in the browser.?? >>>>=20 >>>> RFC6749 says "If the client type is confidential or??the client was iss= ued client credentials,??the client MUST authenticate..." which I take to me= an that refresh tokens could be used without a client_secret, both for nativ= e an javascript apps. >>>>=20 >>>> This discussion of offline vs online refresh tokens is interesting, but= I worry that we may be narrowing our focus here too much. >>>>=20 >>>> There's a use where JavaScript apps may be able to take advantage of of= fline access, which is around Service Workers. This allows a website to inst= all some code from a website which can continue to run in the background, th= ough sometimes only while triggered from external events. One useful example= of this is a syncing daemon, where a push notification can be sent from a w= eb server to a Service Worker, which could cause that code in the browser to= need to make a request to an API, which then may need to be able to get a n= ew access token, which is effectively offline access. >>>>=20 >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>>=20 >>>>=20 >>>>=20 >>>>> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher wrote: >>>>> I'll just add a couple more thoughts around refresh_tokens. >>>>>=20 >>>>> 1. I agree with David that refresh_tokens are valuable in an "online" s= cenario and should be used there. >>>>>=20 >>>>> 2. To use a refresh token at the /token endpoint, client authenticatio= n is required. This is where it gets difficult for default SPAs because they= are public clients and the only mechanism to authenticate them is the clien= t_id which is itself public. For me, this is the real risk of exposing the r= efresh_token in the browser.=20 >>>>>=20 >>>>> 3. If the AS supports rotation of refresh_tokens and an attacker steal= s one and uses it, then the SPA will get an error on it's next attempt becau= se it's refresh_token will now be invalid. If the refresh_tokens are bound t= o the user's authentication session, then the user can logout to lockout the= attacker. However, that is a lot of "ifs" and still provides the attacker w= ith time to leverage access via the compromised refresh_token. >>>>>=20 >>>>> In principle, I agree with the recommendation that SPAs shouldn't have= refresh_tokens in the browser. If it's not possible to easily refresh the a= ccess token via a hidden iframe (becoming more difficult with all the browse= r/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple s= erver component such that the backend for the SPA can use authorization_code= flow and protect a client_secret. >>>>>=20 >>>>> Thanks, >>>>> George >>>>>=20 >>>>>> On 7/8/19 11:17 PM, David Waite wrote: >>>>>>=20 >>>>>>> On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: >>>>>>> Re 8. Refresh Tokens >>>>>>>=20 >>>>>>> ???? "For public clients, the risk of a leaked refresh token is much= >>>>>>> ?? ??greater than leaked access tokens, since an attacker can potent= ially >>>>>>> ?? ??continue using the stolen refresh token to obtain new access wi= thout >>>>>>> ?? ??being detectable by the authorization server.?? " >>>>>>>=20 >>>>>>> (first, note the typo "stoken".) >>>>>>>=20 >>>>>>> Is it always "higher risk"??? I could even argue that leakage of a r= efresh token is lower risk. As a bearer document, a leaked access token allo= ws access to resources until it expires.?? A leaked refresh token, to be use= ful,?? requires an exchange with the AS, and the AS would have the opportuni= ty to check whether the refresh token is still valid (has not been revoked).= ?? (of course revocation might NOT have happened, but then again, it might h= ave.)=20 >>>>>>=20 >>>>>> I agree (with caveats, of course). >>>>>>=20 >>>>>> Access tokens and refresh tokens may or may not be attached (by polic= y) to an authentication session lifetime. It is far easier to picture refres= h tokens which are not attached to an authentication session (sometimes call= ed ???offline??? access) being inappropriate for a browser-based app, which i= s nearly always a client that the resource owner is interacting with. >>>>>>=20 >>>>>> Variants that may want offline tokens are less easy to imagine - perh= aps browser extensions? >>>>>>=20 >>>>>> I believe the language currently there is due to AS implementations p= redominantly treating refresh tokens as being for offline access, and access= token lifetime being short enough to not outlast an authentication session.= >>>>>>=20 >>>>>>> Furthermore, since the access token is transmitted to other servers,= the risk of exposure is greater, due to possible vulnerabilities in those c= alled systems (e.g., logs).?? Isn't this the reason that we have refresh tok= ens? Don't refresh tokens exist because access tokens should have short TTL,= because they are widely distributed? >>>>>>=20 >>>>>> Yes. Once you acknowledge the existence of ???online??? refresh token= s, they become a strong security component: >>>>>>=20 >>>>>> - Refresh tokens let you shorten the access token lifetime >>>>>> - A shorter access token lifetime lets you have centralized policy to= invalidate access without needing to resort to token introspection/revocati= on >>>>>> - Token refresh can theoretically be used to represent other policy c= hanges by both the client (creating tokens targeting a new resource server o= r with reduced scopes) and server (changing entitlements and attributes/clai= ms embedded within a structured token) >>>>>> - Refresh tokens can be one-time-use, as recommenced by the security B= CP. A exfiltrated refresh token will result in either the attacker or the us= er losing access on the next refresh, and a double refresh is a detectable s= ecurity event by the AS. >>>>>>=20 >>>>>>> "Additionally, browser-based applications provide many attack vector= s by which a refresh token can be leaked." >>>>>>>=20 >>>>>>> The risks of leaking a refresh token from the browser are identical t= o the risks of leaking an access token, right??? This sentence could be chan= ged to "... by which a token can be leaked." >>>>>>>=20 >>>>>>> A refresh token is "higher risk" because its TTL is usually greater t= han the access token's TTL.?? But if our advice here leads to people using l= onger-lived access tokens (because of the problems with getting a new access= token without involving the user), then the advice will be counter producti= ve.???? The longer life gives more time for the usefulness of a browser-side= theft, and more time for the usefulness of a server-side theft.??=20 >>>>>>>=20 >>>>>>> Which scenario is safer? >>>>>>> A) using an access token with a 10 minute TTL, accompanied by a refr= esh token with a 1 hour TTL >>>>>>> B) using an access token with a 1 hour TTL, and no refresh token.?? >>>>>>=20 >>>>>>=20 >>>>>> Given tokens that track authentication lifetime, it is hard to make a= case that refresh tokens which last for the authentication session are a gr= eater security risk than opaque access tokens (requiring token introspection= ) that will last the same time.?? >>>>>>=20 >>>>>> Typically an AS (or OP) would issue a structured access token with a l= ifetime expected to expire before the authentication session, with new token= s issued via requests made in an embedded, iframe (hidden, prompt=3Dnone). T= here may be benefits here of user cookies (or perhaps managed-device informa= tion) against an authorization endpoint being used to make decisions that co= uld not be made by a refresh against the token endpoint.?? >>>>>>=20 >>>>>> I???d be interested in hearing how strong of an implementation issue t= his might be for deployments - I could see a non-security argument that the B= CP should only have one recommended approach here, and that there are deploy= ments needing the iframe approach. >>>>>>=20 >>>>>> -DW >>>>>>=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 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf..org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-ECCE19F6-E094-46EC-80D8-C3F6ABBEDE04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Can= somebody spell out why refresh tokens require more protection than access t= okens? What threat are we worried about?

The security benefits and risks of refresh tokens seem to be c= onsistently emphasised, yet nobody seems to ever spell out exactly what they= are. 

The main benefi= t is allowing timely revocation without the RS having to call a token intros= pection endpoint. That=E2=80=99s primarily an architectural decision rather t= han a security one. 

=E2= =80=94 Neil

On 20 Jul 2019,= at 03:57, Justin Richer <jricher@mit.= edu> wrote:

I think it can be as simple as:

SHOULD NOT use refresh tokens without client authentication or key proof= of some kind. 

In other words, no bearer refresh tokens.

=E2=80=94 Justin

On Jul 19, 2019, at 7:49 PM, Aaron Parecki <aaron@parecki.com> wrote:

So what I'm hearing in this thread is essentiall= y that:

1) depending on how it's implemented, using a refresh token i= n a SPA can provide security benefits over using only access tokens
2) it is still "dangerous" to allow refresh tokens to be use= d without client authentication
3) if there is a way to do some sort of dynamic client regis= tration or proof of possession, then using a refresh token would in fact be m= ore secure

Since these points are in conflict with each other, and depe= nd on things currently in flux, it seems like the best thing to do at this t= ime is to remove the guidance on refresh tokens in browser-based apps. Maybe= leaving the mention of rotating the refresh token on every use, but I'm inclined to remove the "SHOULD NOT i= ssue refresh tokens" statement in order to leave room for DPoP or similar in= the future.

Sound reasonable?

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Thu, Jul 11, 2019 at 2:52 PM George= Fletcher <gffletch@aol.co= m> wrote:
You are correct that client authentication is not required fo= r public clients (which doesn't preclude the use of refresh_tokens) but from= my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens with= out any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP the= n I think it's a completely different scenario and it doesn't bother me as m= uch for their to be refresh_tokens in the browser. This of course is just my= perspective:)

On 7/10/19 7:56 P= M, Aaron Parecki wrote:
2. To use a= refresh token at the /token endpoint, client authentication is required. Th= is is where it gets difficult for default SPAs because they are public clien= ts and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk= of exposing the refresh_token in the browser.??

RFC6749 says "If the client type is confidential or??the cli= ent was issued client credentials,??the client MUST authenticate..." which I= take to mean that refresh tokens could be used without a client_secret, bot= h for native an javascript apps.

This discussion of offline vs online refresh tokens is inter= esting, but I worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be able to take adva= ntage of offline access, which is around Service Workers. This allows a webs= ite to install some code from a website which can continue to run in the bac= kground, though sometimes only while triggered from external events. One useful example of this is a synci= ng daemon, where a push notification can be sent from a web server to a Serv= ice Worker, which could cause that code in the browser to need to make a req= uest to an API, which then may need to be able to get a new access token, which is effectively offline acc= ess.

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Tue, Jul 9, 2019 at 9:16 AM George = Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I'll just add a couple more thoughts ar= ound refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" scenar= io and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is r= equired. This is where it gets difficult for default SPAs because they are p= ublic clients and the only mechanism to authenticate them is the client_id w= hich is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one a= nd uses it, then the SPA will get an error on it's next attempt because it's= refresh_token will now be invalid. If the refresh_tokens are bound to the u= ser's authentication session, then the user can logout to lockout the attacker. However, that is a lot of= "ifs" and still provides the attacker with time to leverage access via the c= ompromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have refre= sh_tokens in the browser. If it's not possible to easily refresh the access t= oken via a hidden iframe (becoming more difficult with all the browser/priva= cy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend f= or the SPA can use authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com&g= t; wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially ?? ??continue using the stolen refresh token to obtain new access without ?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakag= e of a refresh token is lower risk. As a bearer document, a leaked access to= ken allows access to resources until it expires.?? A leaked refresh token, t= o be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the ref= resh token is still valid (has not been revoked).?? (of course revocation mi= ght NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (= by policy) to an authentication session lifetime. It is far easier to pictur= e refresh tokens which are not attached to an authentication session (someti= mes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a clien= t that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagi= ne - perhaps browser extensions?

I believe the language currently there is due to AS implemen= tations predominantly treating refresh tokens as being for offline access, a= nd access token lifetime being short enough to not outlast an authentication= session.

Furthermore, since the access token is transmitted to other s= ervers, the risk of exposure is greater, due to possible vulnerabilities in t= hose called systems (e.g., logs).?? Isn't this the reason that we have refre= sh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely d= istributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, they= become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized p= olicy to invalidate access without needing to resort to token introspection/= revocation
- Token refresh can theoretically be used to represent other= policy changes by both the client (creating tokens targeting a new resource= server or with reduced scopes) and server (changing entitlements and attrib= utes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the s= ecurity BCP. A exfiltrated refresh token will result in either the attacker o= r the user losing access on the next refresh, and a double refresh is a dete= ctable security event by the AS.

"Additionally, browser-based applications provide many attac= k vectors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are id= entical to the risks of leaking an access token, right??? This sentence coul= d be changed to "... by which a token can be leaked."

A refresh token is "higher risk" because its TTL is usually g= reater than the access token's TTL.?? But if our advice here leads to people= using longer-lived access tokens (because of the problems with getting a ne= w access token without involving the user), then the advice will be counter productive.???? The longer life g= ives more time for the usefulness of a browser-side theft, and more time for= the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied b= y a refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh t= oken.??


Given tokens that track authentication lifetime, it is hard to make a case t= hat refresh tokens which last for the authentication session are a greater s= ecurity risk than opaque access tokens (requiring token introspection) that w= ill last the same time.??

Typically an AS (or OP) would issue a structured access toke= n with a lifetime expected to expire before the authentication session, with= new tokens issued via requests made in an embedded, iframe (hidden, prompt=3D= none). There may be benefits here of user cookies (or perhaps managed-device information) against an authoriz= ation endpoint being used to make decisions that could not be made by a refr= esh against the token endpoint.??

I???d be interested in hearing how strong of an implementati= on issue this might be for deployments - I could see a non-security argument= that the BCP should only have one recommended approach here, and that there= are deployments needing the iframe approach.

-DW


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

_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D""> 

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

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

________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-ECCE19F6-E094-46EC-80D8-C3F6ABBEDE04-- From nobody Fri Jul 19 23:41: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 1676E1204AB for ; Fri, 19 Jul 2019 23:41:52 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pvLe3GEUVfMC for ; Fri, 19 Jul 2019 23:41:49 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CA8120043 for ; Fri, 19 Jul 2019 23:41:49 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id x4so34172243wrt.6 for ; Fri, 19 Jul 2019 23:41:49 -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=oChL7lCjw31cGLyyUuU8o9HriH/oipkyEUx42wLxTR8=; b=SVxhG39GwuHnYaqkwAASTRz1iAn8ijaA/d6qUydr8aVJ5aoyuyvx696sjAljYg1ISL IFwUg9yKaTmdDrPj3p+WTLb/CCnAnXiUOQOuNzQggNyAuRarNwg5Aznpm6hroAITStZ7 3Rf534xXQCezjsAUMmwhDoutE5jTIaFvdyePw= 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=oChL7lCjw31cGLyyUuU8o9HriH/oipkyEUx42wLxTR8=; b=RsWf5hoQouSmTauwRYmb+e+kVdapFKVwPDp+hpYjQcOYgem5ivENwj8YkNQ9BPUHAi a0iT9VW1Gi17mnDhrEHaSAPVtXArmHqghb4NEw2Zkyc2dfRJbWQegKAeqH3iujz5u5X2 zvkEMjGZVunNqqh5qHO9CCHnm2IOqwj2d3REkFLnop59nPnZkwpLR6SMrHovkm21evJG 6lrCGubijgpnwgrDNm4C7JqimiKMY+DZzzZ10DCU8vR0T3dv0dTOuMG9snOHnccaq7AB YJBiMSoVPN/pc0JCe9LvYMz5pjBFX3RggvTGeO+uU6bPanwLHIRbVOx80DcQHpepQBzF cM8w== X-Gm-Message-State: APjAAAXPpMmsriww1gacORkRPSyitIbClcZrsaLHSrxIP4vVa32IfyPU 8Ne1JMOZ9V/9h7gx3YbcvKxWRw== X-Google-Smtp-Source: APXvYqxmSSnq5CQORXXSzEA9ooZgGLjnvmXQ/3qpnCLegYrggiAXe7DQQ8Y50vpbeVSY6kXnp8VeNg== X-Received: by 2002:adf:f246:: with SMTP id b6mr32807356wrp.92.1563604907622; Fri, 19 Jul 2019 23:41:47 -0700 (PDT) Received: from [192.168.1.65] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id v65sm34031691wme.31.2019.07.19.23.41.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 23:41:46 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Sat, 20 Jul 2019 07:41:46 +0100 Cc: Justin Richer , oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Aaron Parecki Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jul 2019 06:41:52 -0000 --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we=E2=80=99re going to redesign OAuth, one improvement would be to allow a= client to request different access tokens for different resource servers in= a single request. That should include issuing a different access token for t= he userinfo endpoint vs other RSes.=20 One of the weaknesses of combined OAuth + OIDC use now is that if you reques= t OIDC scopes and scopes for another resource in the same request then you i= nadvertently give those other RSes access to the user=E2=80=99s profile.=20 =E2=80=94 Neil > On 20 Jul 2019, at 01:02, Aaron Parecki wrote: >=20 > Hi all, I'm looking forward to the discussion on this on Tuesday! >=20 > I wanted to add my thoughts on a potential addition to this draft, specifi= cally around returning some minimal user information in the transaction resp= onse. >=20 > The summary of the suggestion is to return a new "user" key along with the= access token that contains the user ID and userinfo endpoint, such as: >=20 > { > "access_token": { > "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type": "bearer" > }, > "user": { > "id": "5035678642", > "userinfo": "https://authorization-server.com/user/5035678642" > } > } >=20 > A more detailed analysis of the specific proposal and motivation behind th= is is available on my blog: >=20 > https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz >=20 > Thanks! >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 >=20 >=20 >> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer wrote: >> I have requested time to present Transactional Authorization (the XYZ pro= ject) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve= uploaded a new version of the spec: >>=20 >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 >>=20 >> Additionally, I=E2=80=99ve updated the writeup and examples on https://oa= uth.xyz/=20 >>=20 >> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested f= rom the chairs that I present during the Tuesday session due to limited avai= lability of some key WG members on Friday.=20 >>=20 >> =E2=80=94 Justin >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If w= e=E2=80=99re going to redesign OAuth, one improvement would be to allow a cl= ient to request different access tokens for different resource servers in a s= ingle request. That should include issuing a different access token for the u= serinfo endpoint vs other RSes. 

One of the weaknesses of combined OAuth + OIDC use now is that if= you request OIDC scopes and scopes for another resource in the same request= then you inadvertently give those other RSes access to the user=E2=80=99s p= rofile. 

=E2=80=94 Nei= l

On 20 Jul 2019, at 01:02, Aaron Parecki <aaron@parecki.com> wrote:

Hi all, I'm l= ooking forward to the discussion on this on Tuesday!

I wa= nted to add my thoughts on a potential addition to this draft, specifically a= round returning some minimal user information in the transaction response.

The summary of the suggestion is to return a new "us= er" key along with the access token that contains the user ID and userinfo e= ndpoint, such as:

    {
   &= nbsp;  "access_token": {
        "value": "= UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
      &nbs= p; "type": "bearer"
      },
    &n= bsp; "user": {
        "id": "5035678642",
&n= bsp;       "userinfo": "https://authorization-server.com/user/503567864= 2"
      }
    }

A more detailed analysis of the specific proposal and motivation be= hind this is available on my blog:


Thanks!

----
Aaron Pareck= i



On Tue, Jul 9,= 2019 at 2:48 PM Justin Richer <jriche= r@mit.edu> wrote:
I have requested time to present Transactional Authorization (the XYZ projec= t) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve up= loaded a new version of the spec:


Additionally, I=E2=80=99ve updated the writeup and examples on https://oauth.xyz/ 

I plan to be in Montreal for the whole week, and I=E2=80=99ve requested= from the chairs that I present during the Tuesday session due to limited av= ailability of some key WG members on Friday. 

=E2=80=94 Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54-- From nobody Sat Jul 20 11:38: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 0C8C41200A3 for ; Sat, 20 Jul 2019 11:38:46 -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 mgLdLZxiZrIg for ; Sat, 20 Jul 2019 11:38:41 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0: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 BA17412006E for ; Sat, 20 Jul 2019 11:38:41 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id n9so9603718pgc.1 for ; Sat, 20 Jul 2019 11:38:41 -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=LGeyuu5Qjh03Wi2pUQUiuO2t+4AZvrZ0gbTLJJmtpiw=; b=nTsIsMnrkRKPAHrP/FVjUHrH7RmooyNleZgUzHJqMX1CQwB3idSe4EuS7afOtMTzPc lC9dJgP4uPdRpEMHJdHnbEouS/t+FoJQL6KnQ8Tcrhq5ysPj/FtKWAnhoyIPRnxpCQRU saqa+NdVYWEjK8izfwfmrV/nPcAot3XchsZzNbQnnoL+eBDyJL5M+gQ842dRE0t8rEqj aASMPMIVdR0gPik4h4EZRAvF7k+vOBtXSWHL5Tv+5rT69YOOLgcdZMvl1wbfZihsG18R 6ewZocrDLrToIsdxPEYPB3s5BO0E/6akbOIEGtBpMbeINULY0ymOHf9IWmrGiFxRJ1a4 8EOw== 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=LGeyuu5Qjh03Wi2pUQUiuO2t+4AZvrZ0gbTLJJmtpiw=; b=JLuu8SEi9k41WEL9RrYpz/p7H7w/jekNasX9ebTdVbzCcWUag2/N6doVVX2IhkByMf g87h1VRDhAIm5J3onfo4/WtRdIhvONe5Q7TQIyGO6n4tL7vrjmTAqxdh4nGQim1PvGF6 3r5q/x/fzCvZ4Ep/4CfaXfq7VYpYaenoB5Y0Ves7bpQtD03IfnYK39KFZg4YdyU0judW LmR9IDjMYkbyQkXzFjlHDyJCJU8PUxRIbscd31VCsgxxijgkNG6ImST5v2qrRXMgPAXT JgV118dmfD7oc8FA5vbVIlNMagAusjgILe3Ru0/tg34r1i7EJu8o+CngDY87bvXWmX1K kj8w== X-Gm-Message-State: APjAAAXhp7GRCGxRmNVOAUBnwyCMcR/kexZUCQcCVQTLQ93nMYdkfJop g9hdp/OXwViEorp5N4HaUFgNTxVMngREhmm+C6s= X-Google-Smtp-Source: APXvYqzD6UqoNJ4+ySdt4/ddA9vN3/Iuf9EOUtPrb/YDoJaa9t42LxkPTHL0h99y2QEVD7q6ekMB7UX3AeAq2BdfdPc= X-Received: by 2002:a63:101b:: with SMTP id f27mr58896662pgl.291.1563647920705; Sat, 20 Jul 2019 11:38:40 -0700 (PDT) MIME-Version: 1.0 References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> In-Reply-To: <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> From: Leo Tohill Date: Sat, 20 Jul 2019 14:38:30 -0400 Message-ID: To: Neil Madden Cc: Justin Richer , OAuth WG Content-Type: multipart/alternative; boundary="000000000000de178a058e212601" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 18:38:46 -0000 --000000000000de178a058e212601 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Access tokens and refresh tokens, stored browser-side, are equally vulnerable to theft, because the storage options are identical. We are more concerned about the theft of the refresh token, because it (commonly) has a longer usable lifetime than the access token. Still , its a matter of degree. Since we accept the risk of access token theft, why can't we accept the risk of refresh token theft? We ameliorate the access token risk by using short lifetimes, but there is no standard for that value: it is situational. Why doesn't the same reasoning apply to refresh tokens? This reasoning assumes that refresh tokens also have a limited lifetime. I am unsure that this is always the case. When one uses a refresh token to acquire a new access token, AND that operation issues a new refresh token, does the new refresh token get a new lifetime? If so, then a refresh token can be used to retain access infinitely (or until it is revoked server-side). In this scenario, the risks associated with browser-side storage of refresh token are much higher. In summary, I'd say that IF the lifetime of a refresh token can be limited, then refresh tokens pose identical risk as access tokens, and so the same considerations apply. without providing specific values. Why can't we do the same for refresh tokens? On Sat, Jul 20, 2019 at 2:10 AM Neil Madden wrote: > Can somebody spell out why refresh tokens require more protection than > access tokens? What threat are we worried about? > > The security benefits and risks of refresh tokens seem to be consistently > emphasised, yet nobody seems to ever spell out exactly what they are. > > The main benefit is allowing timely revocation without the RS having to > call a token introspection endpoint. That=E2=80=99s primarily an architec= tural > decision rather than a security one. > > =E2=80=94 Neil > > On 20 Jul 2019, at 03:57, Justin Richer wrote: > > I think it can be as simple as: > > SHOULD NOT use refresh tokens without client authentication or key proof > of some kind. > > In other words, no bearer refresh tokens. > > =E2=80=94 Justin > > On Jul 19, 2019, at 7:49 PM, Aaron Parecki wrote: > > So what I'm hearing in this thread is essentially that: > > 1) depending on how it's implemented, using a refresh token in a SPA can > provide security benefits over using only access tokens > 2) it is still "dangerous" to allow refresh tokens to be used without > client authentication > 3) if there is a way to do some sort of dynamic client registration or > proof of possession, then using a refresh token would in fact be more sec= ure > > Since these points are in conflict with each other, and depend on things > currently in flux, it seems like the best thing to do at this time is to > remove the guidance on refresh tokens in browser-based apps. Maybe leavin= g > the mention of rotating the refresh token on every use, but I'm inclined = to > remove the "SHOULD NOT issue refresh tokens" statement in order to leave > room for DPoP or similar in the future. > > Sound reasonable? > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Thu, Jul 11, 2019 at 2:52 PM George Fletcher wrote: > >> You are correct that client authentication is not required for public >> clients (which doesn't preclude the use of refresh_tokens) but from my >> perspective it weakens the security because anyone with the refresh_toke= n >> is able to get new access_tokens without any additional proof. >> >> Now if the SPA performs some sort of Dynamic Client Registration or DPoP >> then I think it's a completely different scenario and it doesn't bother = me >> as much for their to be refresh_tokens in the browser. This of course is >> just my perspective:) >> >> On 7/10/19 7:56 PM, Aaron Parecki wrote: >> >> 2. To use a refresh token at the /token endpoint, client authentication >>> is required. This is where it gets difficult for default SPAs because t= hey >>> are public clients and the only mechanism to authenticate them is the >>> client_id which is itself public. For me, this is the real risk of expo= sing >>> the refresh_token in the browser.?? >> >> >> RFC6749 says "If the client type is confidential or??the client was >> issued client credentials,??the client MUST authenticate..." which I tak= e >> to mean that refresh tokens could be used without a client_secret, both = for >> native an javascript apps. >> >> This discussion of offline vs online refresh tokens is interesting, but = I >> worry that we may be narrowing our focus here too much. >> >> There's a use where JavaScript apps may be able to take advantage of >> offline access, which is around Service Workers. This allows a website t= o >> install some code from a website which can continue to run in the >> background, though sometimes only while triggered from external events. = One >> useful example of this is a syncing daemon, where a push notification ca= n >> be sent from a web server to a Service Worker, which could cause that co= de >> in the browser to need to make a request to an API, which then may need = to >> be able to get a new access token, which is effectively offline access. >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> >> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >>> I'll just add a couple more thoughts around refresh_tokens. >>> >>> 1. I agree with David that refresh_tokens are valuable in an "online" >>> scenario and should be used there. >>> >>> 2. To use a refresh token at the /token endpoint, client authentication >>> is required. This is where it gets difficult for default SPAs because t= hey >>> are public clients and the only mechanism to authenticate them is the >>> client_id which is itself public. For me, this is the real risk of expo= sing >>> the refresh_token in the browser. >>> >>> 3. If the AS supports rotation of refresh_tokens and an attacker steals >>> one and uses it, then the SPA will get an error on it's next attempt >>> because it's refresh_token will now be invalid. If the refresh_tokens a= re >>> bound to the user's authentication session, then the user can logout to >>> lockout the attacker. However, that is a lot of "ifs" and still provide= s >>> the attacker with time to leverage access via the compromised refresh_t= oken. >>> >>> In principle, I agree with the recommendation that SPAs shouldn't have >>> refresh_tokens in the browser. If it's not possible to easily refresh t= he >>> access token via a hidden iframe (becoming more difficult with all the >>> browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use = a >>> simple server component such that the backend for the SPA can use >>> authorization_code flow and protect a client_secret. >>> >>> Thanks, >>> George >>> >>> On 7/8/19 11:17 PM, David Waite wrote: >>> >>> >>> On Jul 8, 2019, at 7:10 PM, Leo Tohill wrote: >>> Re 8. Refresh Tokens >>> >>> ???? "For public clients, the risk of a leaked refresh token is much >>> ?? ??greater than leaked access tokens, since an attacker can potential= ly >>> ?? ??continue using the stolen refresh token to obtain new access witho= ut >>> ?? ??being detectable by the authorization server.?? " >>> >>> (first, note the typo "stoken".) >>> >>> Is it always "higher risk"??? I could even argue that leakage of a >>> refresh token is lower risk. As a bearer document, a leaked access toke= n >>> allows access to resources until it expires.?? A leaked refresh token, = to >>> be useful,?? requires an exchange with the AS, and the AS would have th= e >>> opportunity to check whether the refresh token is still valid (has not = been >>> revoked).?? (of course revocation might NOT have happened, but then aga= in, >>> it might have.) >>> >>> >>> I agree (with caveats, of course). >>> >>> Access tokens and refresh tokens may or may not be attached (by policy) >>> to an authentication session lifetime. It is far easier to picture refr= esh >>> tokens which are not attached to an authentication session (sometimes >>> called ???offline??? access) being inappropriate for a browser-based ap= p, >>> which is nearly always a client that the resource owner is interacting = with. >>> >>> Variants that may want offline tokens are less easy to imagine - perhap= s >>> browser extensions? >>> >>> I believe the language currently there is due to AS implementations >>> predominantly treating refresh tokens as being for offline access, and >>> access token lifetime being short enough to not outlast an authenticati= on >>> session. >>> >>> Furthermore, since the access token is transmitted to other servers, th= e >>> risk of exposure is greater, due to possible vulnerabilities in those >>> called systems (e.g., logs).?? Isn't this the reason that we have refre= sh >>> tokens? Don't refresh tokens exist because access tokens should have sh= ort >>> TTL, because they are widely distributed? >>> >>> >>> Yes. Once you acknowledge the existence of ???online??? refresh tokens, >>> they become a strong security component: >>> >>> - Refresh tokens let you shorten the access token lifetime >>> - A shorter access token lifetime lets you have centralized policy to >>> invalidate access without needing to resort to token >>> introspection/revocation >>> - Token refresh can theoretically be used to represent other policy >>> changes by both the client (creating tokens targeting a new resource se= rver >>> or with reduced scopes) and server (changing entitlements and >>> attributes/claims embedded within a structured token) >>> - Refresh tokens can be one-time-use, as recommenced by the security >>> BCP. A exfiltrated refresh token will result in either the attacker or = the >>> user losing access on the next refresh, and a double refresh is a >>> detectable security event by the AS. >>> >>> "Additionally, browser-based applications provide many attack vectors b= y >>> which a refresh token can be leaked." >>> >>> The risks of leaking a refresh token from the browser are identical to >>> the risks of leaking an access token, right??? This sentence could be >>> changed to "... by which *a token* can be leaked." >>> >>> A refresh token is "higher risk" because its TTL is usually greater tha= n >>> the access token's TTL.?? But if our advice here leads to people using >>> longer-lived access tokens (because of the problems with getting a new >>> access token without involving the user), then the advice will be count= er >>> productive.???? The longer life gives more time for the usefulness of a >>> browser-side theft, and more time for the usefulness of a server-side >>> theft.?? >>> >>> Which scenario is safer? >>> >>> A) using an access token with a 10 minute TTL, accompanied by a refresh >>> token with a 1 hour TTL >>> B) using an access token with a 1 hour TTL, and no refresh token.?? >>> >>> >>> >>> Given tokens that track authentication lifetime, it is hard to make a >>> case that refresh tokens which last for the authentication session are = a >>> greater security risk than opaque access tokens (requiring token >>> introspection) that will last the same time.?? >>> >>> Typically an AS (or OP) would issue a structured access token with a >>> lifetime expected to expire before the authentication session, with new >>> tokens issued via requests made in an embedded, iframe (hidden, >>> prompt=3Dnone). There may be benefits here of user cookies (or perhaps >>> managed-device information) against an authorization endpoint being use= d to >>> make decisions that could not be made by a refresh against the token >>> endpoint.?? >>> >>> I???d be interested in hearing how strong of an implementation issue >>> this might be for deployments - I could see a non-security argument tha= t >>> the BCP should only have one recommended approach here, and that there = are >>> deployments needing the iframe approach. >>> >>> -DW >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf..org/mailman/listinfo/= oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf..org/mailman/listinfo/o= auth >> >> >> _______________________________________________ > 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 > --000000000000de178a058e212601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Access tokens and refresh tokens, stored browser-side= , are equally vulnerable to theft, because the storage options are identica= l.

We are more concerned about the theft of t= he refresh token, because it (commonly) has a longer usable lifetime than t= he access token.

Still , its a matter of degr= ee. Since we accept the risk of access token theft,=C2=A0 why can't we = accept the risk of refresh token theft?=C2=A0 We ameliorate the access toke= n risk by using short lifetimes, but there is no standard for that value: i= t is situational.=C2=A0 Why doesn't the same reasoning apply to refresh= tokens?

This reasoning assumes that refresh = tokens also have a limited lifetime.=C2=A0 I am unsure that this is always = the case.=C2=A0 When one uses a refresh token to acquire a new access token= , AND that operation issues a new refresh token, does the new refresh token= get a new lifetime?=C2=A0 If so, then a refresh token can be used to retai= n access infinitely (or until it is revoked server-side).=C2=A0 In this sce= nario, the risks associated with browser-side storage of refresh token are = much higher.

In summary, I'd say that IF = the lifetime of a refresh token can be limited, then refresh tokens pose id= entical risk as access tokens, and so the same considerations apply.








without providing spe= cific values.=C2=A0 Why can't we do the same for refresh tokens?
<= div>


On Sat, Jul 20, 2019 at 2:10 AM Neil Madden &= lt;neil.madden@forgerock.com> wrote:
Can somebody spell = out why refresh tokens require more protection than access tokens? What thr= eat are we worried about?

= The security benefits and risks of refresh tokens seem to be consistently e= mphasised, yet nobody seems to ever spell out exactly what they are.=C2=A0<= /div>

The main benefit is allowi= ng timely revocation without the RS having to call a token introspection en= dpoint. That=E2=80=99s primarily an architectural decision rather than a se= curity one.=C2=A0

=E2=80= =94 Neil

=
I think it can be as simple as:

SHOULD NOT use refresh tokens without client aut= hentication or key proof of some kind.=C2=A0

In other words, no bearer refresh tokens.

=E2=80=94 Justin

On Jul 19, 2019, at 7:49 PM, Aaron Parecki <aaron@parecki.com> wrote:

So what I'm hearing in this thread is essentially that= :

1) depending on how it's implemented, using a refresh token in a S= PA can provide security benefits over using only access tokens
2) it is still "dangerous" to allow refresh tokens to be use= d without client authentication
3) if there is a way to do some sort of dynamic client registration or= proof of possession, then using a refresh token would in fact be more secu= re

Since these points are in conflict with each other, and depend on thin= gs currently in flux, it seems like the best thing to do at this time is to= remove the guidance on refresh tokens in browser-based apps. Maybe leaving= the mention of rotating the refresh token on every use, but I'm inclined to remove the "S= HOULD NOT issue refresh tokens" statement in order to leave room for D= PoP or similar in the future.

Sound reasonable?

----
Aaron Parecki
@aaronpk<= /div>



On Thu, Jul 11, 2019 at 2:52 PM Georg= e Fletcher <gfflet= ch@aol.com> wrote:
You ar= e correct that client authentication is not required for public clients (wh= ich doesn't preclude the use of refresh_tokens) but from my perspective= it weakens the security because anyone with the refresh_token is able to get new access_tokens wit= hout any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP th= en I think it's a completely different scenario and it doesn't both= er me as much for their to be refresh_tokens in the browser. This of course= is just my perspective:)

On 7/10/19 7:56 PM, Aaron Parecki wrote:
2. To use a refresh = token at the /token endpoint, client authentication is required. This is wh= ere it gets difficult for default SPAs because they are public clients and = the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real ris= k of exposing the refresh_token in the browser.??

RFC6749 says "If the client type is confidential or??the client w= as issued client credentials,??the client MUST authenticate..." which = I take to mean that refresh tokens could be used without a client_secret, b= oth for native an javascript apps.

This discussion of offline vs online refresh tokens is interesting, bu= t I worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be able to take advantage = of offline access, which is around Service Workers. This allows a website t= o install some code from a website which can continue to run in the backgro= und, though sometimes only while triggered from external events. One useful example of this is a sync= ing daemon, where a push notification can be sent from a web server to a Se= rvice Worker, which could cause that code in the browser to need to make a = request to an API, which then may need to be able to get a new access token, which is effectively offline ac= cess.

----
Aaron Parecki
@aaronpk<= /div>



On Tue, Jul 9, 2019 at 9:16 AM George= Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
I'll just add a couple more thoughts around r= efresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online&q= uot; scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication is = required. This is where it gets difficult for default SPAs because they are= public clients and the only mechanism to authenticate them is the client_i= d which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals one= and uses it, then the SPA will get an error on it's next attempt becau= se it's refresh_token will now be invalid. If the refresh_tokens are bo= und to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot o= f "ifs" and still provides the attacker with time to leverage acc= ess via the compromised refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have = refresh_tokens in the browser. If it's not possible to easily refresh t= he access token via a hidden iframe (becoming more difficult with all the b= rowser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the back= end for the SPA can use authorization_code flow and protect a client_secret= .

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:

On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotohill@gmail.com> wrote:
Re 8. Refresh Tokens

???? "For public clients, the risk of a leaked refresh token is much ?? ??greater than leaked access tokens, since an attacker can potentially ?? ??continue using the stolen refresh token to obtain new access without ?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakag= e of a refresh token is lower risk. As a bearer document, a leaked access t= oken allows access to resources until it expires.?? A leaked refresh token,= to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the re= fresh token is still valid (has not been revoked).?? (of course revocation = might NOT have happened, but then again, it might have.)

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy= ) to an authentication session lifetime. It is far easier to picture refres= h tokens which are not attached to an authentication session (sometimes cal= led ???offline??? access) being inappropriate for a browser-based app, which is nearly always a clie= nt that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perha= ps browser extensions?

I believe the language currently there is due to AS implementations pr= edominantly treating refresh tokens as being for offline access, and access= token lifetime being short enough to not outlast an authentication session= .

Furthermore, since the access token is transmitted to other servers, t= he risk of exposure is greater, due to possible vulnerabilities in those ca= lled systems (e.g., logs).?? Isn't this the reason that we have refresh= tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely= distributed?

Yes. Once you acknowledge the existence of ???online??? refresh tokens, the= y become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to = invalidate access without needing to resort to token introspection/revocati= on
- Token refresh can theoretically be used to represent other policy ch= anges by both the client (creating tokens targeting a new resource server o= r with reduced scopes) and server (changing entitlements and attributes/cla= ims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security B= CP. A exfiltrated refresh token will result in either the attacker or the u= ser losing access on the next refresh, and a double refresh is a detectable= security event by the AS.

"Additionally, browser-based applications provide many attack vec= tors by which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to= the risks of leaking an access token, right??? This sentence could be chan= ged to "... by which a token can be leaked."

A refresh token is "higher risk" because its TTL is usually = greater than the access token's TTL.?? But if our advice here leads to = people using longer-lived access tokens (because of the problems with getti= ng a new access token without involving the user), then the advice will be counter productive.???? The longer life= gives more time for the usefulness of a browser-side theft, and more time = for the usefulness of a server-side theft.??

Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a refres= h token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.??


Given tokens that track authentication lifetime, it is hard to make a case = that refresh tokens which last for the authentication session are a greater= security risk than opaque access tokens (requiring token introspection) th= at will last the same time.??

Typically an AS (or OP) would issue a structured access token with a l= ifetime expected to expire before the authentication session, with new toke= ns issued via requests made in an embedded, iframe (hidden, prompt=3Dnone).= There may be benefits here of user cookies (or perhaps managed-device information) against an authori= zation endpoint being used to make decisions that could not be made by a re= fresh against the token endpoint.??

I???d be interested in hearing how strong of an implementation issue t= his might be for deployments - I could see a non-security argument that the= BCP should only have one recommended approach here, and that there are dep= loyments needing the iframe approach.

-DW


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

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

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

_______________________________________________
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
--000000000000de178a058e212601-- From nobody Sat Jul 20 11:54:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716F512006E for ; Sat, 20 Jul 2019 11:54:21 -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 OR0ez0DJYEX6 for ; Sat, 20 Jul 2019 11:54:19 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0898E12001B for ; Sat, 20 Jul 2019 11:54:19 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:14de:93d:33e2:e55f] (unknown [IPv6:2601:282:202:b210:14de:93d:33e2:e55f]) by alkaline-solutions.com (Postfix) with ESMTPSA id C72133167F; Sat, 20 Jul 2019 18:54:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\)) From: David Waite In-Reply-To: Date: Sat, 20 Jul 2019 12:54:17 -0600 Cc: Neil Madden , OAuth WG Content-Transfer-Encoding: quoted-printable Message-Id: <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> To: Leo Tohill X-Mailer: Apple Mail (2.3566.0.1) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 18:54:21 -0000 > On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: >=20 > Access tokens and refresh tokens, stored browser-side, are equally = vulnerable to theft, because the storage options are identical.=20 >=20 > We are more concerned about the theft of the refresh token, because it = (commonly) has a longer usable lifetime than the access token.=20 >=20 > Still , its a matter of degree. Since we accept the risk of access = token theft, why can't we accept the risk of refresh token theft? We = ameliorate the access token risk by using short lifetimes, but there is = no standard for that value: it is situational. Why doesn't the same = reasoning apply to refresh tokens?=20 >=20 > This reasoning assumes that refresh tokens also have a limited = lifetime. I am unsure that this is always the case. When one uses a = refresh token to acquire a new access token, AND that operation issues a = new refresh token, does the new refresh token get a new lifetime? If = so, then a refresh token can be used to retain access infinitely (or = until it is revoked server-side). In this scenario, the risks = associated with browser-side storage of refresh token are much higher.=20= >=20 > In summary, I'd say that IF the lifetime of a refresh token can be = limited, then refresh tokens pose identical risk as access tokens, and = so the same considerations apply.=20 Agreed I think there is an unwritten framework for evaluating the security of = all tokens, regardless of type. For example: access tokens are shared = with resources, so their security protections in the Security BCP = including limiting replay against other resources, and optionally = against new requests against the same resource. Because it is complex and unwritten, it is hard to do a true evaluation. = My impression was always that refresh tokens were more =E2=80=98risky=E2=80= =99 for public clients because =E2=80=9Coffline=E2=80=9D refresh tokens = may be good for an indeterminate period of time, and because lack of = credentials means theft of the token is sufficient. In addition, a public client which does not use its refresh token in an = =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a = considerable period of time, and the operational model of public clients = usually puts detection of local token theft in the hand of the end user = and client software, not an administrator or organizational security = staff. But those concerns are mostly mitigated if the OP can set policy to = control refresh token usage in concert with the authentication session. -DW= From nobody Sat Jul 20 12:45: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 6B39A120048 for ; Sat, 20 Jul 2019 12:45:33 -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 w23VFZFvivaC for ; Sat, 20 Jul 2019 12:45:30 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C305A12001E for ; Sat, 20 Jul 2019 12:45:30 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id f5so7034198pgu.5 for ; Sat, 20 Jul 2019 12:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7k+/r+7rFXE4OynhmRGp3ur4YeHSC6DgXR02LXMknHo=; b=NwdS7a1LFco+ScAicNZcwhi94a0NGXGN47/fX4p1iUFLmTs5KzZErG9f/xkgj007Mb ooW9T9wK5VZOQ/f9uk0Pf1P/pncH7fIyn/Gk9ACMQaZN15iSIzN1AmVW7bZMFR8S9mJr PUwCo8tJbT5E1Bg93tYwfSWJOSiV8kLdvjNSM2BuOnXPecUP+kvFijKcGmB9T2/N19v6 hE4nCTqvZHeQxh9ZsnuhkRuuudfMOyEnBjOv+fSNdU966noV0DgYZ+ZOettjR+csM24O 93i0pK8GWQ7ZSxl1lFdihBhXNL0WlV6tiEndBoQUsEJDdv6bhWHFZRcwplQgS5kYn7LP W3zQ== 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=7k+/r+7rFXE4OynhmRGp3ur4YeHSC6DgXR02LXMknHo=; b=W2FGCeVZSIFgXP/7Tm3uZYSuWjbLpp4PgY2bNRf5yUEtMZ/eCpV92ep2iLzwDJk9qK g/WKHwUh/DvyktquGdbZWLwxfCStJ9mMmqty9KmHEJ8ZwBWbJsdsD27gnAJGLCVXfHmR iLkfD7YqLgJh+wNUYY7mk3B1xOpvV2hw6P5kk4KwaT7SiPSdFq0psouGbm4QC3H+cZhA mNNP8SvPp1eRZ4NLTVo4+GBWZPQPU7mRS8rJooiOiCxdofK2zl1p+yDxyzykNsBLlhUm xgsZw5Lk/i0DVOOKzoWa1ohPuIxX5z+jAc60qdn0MMhHh1m3TVJ9pUooROIrZ8xn7GVE fbPA== X-Gm-Message-State: APjAAAVp7UQQ1WgwA37ha1biMpFfF3R+IWt0aj4tKsvsUO2oaYFisL68 2FqVQZqZWqJzHFPIXPdwNVQBkV1k09AkF59O7+4= X-Google-Smtp-Source: APXvYqwVrGrVhLPGNnqXImjQdOBh3i7VWrUbtfADcVxE3eSLrBuj9C1/JB0FHCw9/inpocU51CaD9/ddGUkPwd/Ehlk= X-Received: by 2002:a17:90a:a116:: with SMTP id s22mr65485977pjp.47.1563651929904; Sat, 20 Jul 2019 12:45:29 -0700 (PDT) MIME-Version: 1.0 References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> In-Reply-To: <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> From: Leo Tohill Date: Sat, 20 Jul 2019 15:45:20 -0400 Message-ID: To: David Waite Cc: Neil Madden , OAuth WG Content-Type: multipart/alternative; boundary="000000000000d59b04058e221533" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 19:45:34 -0000 --000000000000d59b04058e221533 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did some looking around regarding the lifetime of refresh tokens in various OP services. Auth0 ,and google do not appear to support a limited lifetime on refresh tokens. AWS supports a lifetime, but with day granularity (minimum 1 day). It does not issue a new refresh token when one is redeemed. IdentityServer allows a choice of behavior on refresh token expiration time. It can have a absolute expiration time, or use a sliding window. I couldn't find anything in oauth or openid specs regarding refresh token lifetime. I'm thinking that our language might say that "if the OP supports refresh token (absolute) lifetime, refresh tokens may be used (in the browser), but should (must?) specify a expiration time." On Sat, Jul 20, 2019 at 2:54 PM David Waite wrote: > > > > On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: > > > > Access tokens and refresh tokens, stored browser-side, are equally > vulnerable to theft, because the storage options are identical. > > > > We are more concerned about the theft of the refresh token, because it > (commonly) has a longer usable lifetime than the access token. > > > > Still , its a matter of degree. Since we accept the risk of access toke= n > theft, why can't we accept the risk of refresh token theft? We ameliora= te > the access token risk by using short lifetimes, but there is no standard > for that value: it is situational. Why doesn't the same reasoning apply = to > refresh tokens? > > > > This reasoning assumes that refresh tokens also have a limited > lifetime. I am unsure that this is always the case. When one uses a > refresh token to acquire a new access token, AND that operation issues a > new refresh token, does the new refresh token get a new lifetime? If so, > then a refresh token can be used to retain access infinitely (or until it > is revoked server-side). In this scenario, the risks associated with > browser-side storage of refresh token are much higher. > > > > In summary, I'd say that IF the lifetime of a refresh token can be > limited, then refresh tokens pose identical risk as access tokens, and so > the same considerations apply. > > Agreed > > I think there is an unwritten framework for evaluating the security of al= l > tokens, regardless of type. For example: access tokens are shared with > resources, so their security protections in the Security BCP including > limiting replay against other resources, and optionally against new > requests against the same resource. > > Because it is complex and unwritten, it is hard to do a true evaluation. > My impression was always that refresh tokens were more =E2=80=98risky=E2= =80=99 for public > clients because =E2=80=9Coffline=E2=80=9D refresh tokens may be good for = an indeterminate > period of time, and because lack of credentials means theft of the token = is > sufficient. > > In addition, a public client which does not use its refresh token in an > =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a consid= erable period of > time, and the operational model of public clients usually puts detection = of > local token theft in the hand of the end user and client software, not an > administrator or organizational security staff. > > But those concerns are mostly mitigated if the OP can set policy to > control refresh token usage in concert with the authentication session. > > -DW --000000000000d59b04058e221533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did some looking around regarding the lifetime of r= efresh tokens in various OP services.

Auth0,and=20 google do not appear to support a limi= ted lifetime on refresh tokens.
AWS supports a lifetime, but with day gra= nularity (minimum 1 day).=C2=A0 It does not issue a new refresh token when = one is redeemed.
IdentityServer allows a choice of behavior on ref= resh token expiration time.=C2=A0 It can have a absolute expiration time, o= r use a sliding window.

I couldn't find anything in oauth or openid s= pecs regarding refresh token lifetime.

I'm thinking = that our language might say that "if the OP supports refresh token (ab= solute) lifetime, refresh tokens may be used (in the browser), but should (= must?) specify a expiration time."


=



On Sat, Jul 20, 2019 at 2:54 PM David Waite &= lt;david@= alkaline-solutions.com> wrote:


> On Jul 20, 2019, at 12:38 PM, Leo Tohill <leotohill@gmail.com> wrote:
>
> Access tokens and refresh tokens, stored browser-side, are equally vul= nerable to theft, because the storage options are identical.
>
> We are more concerned about the theft of the refresh token, because it= (commonly) has a longer usable lifetime than the access token.
>
> Still , its a matter of degree. Since we accept the risk of access tok= en theft,=C2=A0 why can't we accept the risk of refresh token theft?=C2= =A0 We ameliorate the access token risk by using short lifetimes, but there= is no standard for that value: it is situational.=C2=A0 Why doesn't th= e same reasoning apply to refresh tokens?
>
> This reasoning assumes that refresh tokens also have a limited lifetim= e.=C2=A0 I am unsure that this is always the case.=C2=A0 When one uses a re= fresh token to acquire a new access token, AND that operation issues a new = refresh token, does the new refresh token get a new lifetime?=C2=A0 If so, = then a refresh token can be used to retain access infinitely (or until it i= s revoked server-side).=C2=A0 In this scenario, the risks associated with b= rowser-side storage of refresh token are much higher.
>
> In summary, I'd say that IF the lifetime of a refresh token can be= limited, then refresh tokens pose identical risk as access tokens, and so = the same considerations apply.

Agreed

I think there is an unwritten framework for evaluating the security of all = tokens, regardless of type. For example: access tokens are shared with reso= urces, so their security protections in the Security BCP including limiting= replay against other resources, and optionally against new requests agains= t the same resource.

Because it is complex and unwritten, it is hard to do a true evaluation. My= impression was always that refresh tokens were more =E2=80=98risky=E2=80= =99 for public clients because =E2=80=9Coffline=E2=80=9D refresh tokens may= be good for an indeterminate period of time, and because lack of credentia= ls means theft of the token is sufficient.

In addition, a public client which does not use its refresh token in an =E2= =80=9Coffline=E2=80=9D manner may have theft go unnoticed for a considerabl= e period of time, and the operational model of public clients usually puts = detection of local token theft in the hand of the end user and client softw= are, not an administrator or organizational security staff.

But those concerns are mostly mitigated if the OP can set policy to control= refresh token usage in concert with the authentication session.

-DW
--000000000000d59b04058e221533-- From nobody Sat Jul 20 21:25: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 C59E712006A; Sat, 20 Jul 2019 21:24:58 -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_HELO_NONE=0.001, SPF_PASS=-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 8OLiGUxGajFG; Sat, 20 Jul 2019 21:24:57 -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 72BF41200EF; Sat, 20 Jul 2019 21:24:57 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6L4OowU028794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jul 2019 00:24:53 -0400 Date: Sat, 20 Jul 2019 23:24:50 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: Barry Leiba , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Message-ID: <20190721042450.GW23137@kduck.mit.edu> References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> 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] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 04:24:59 -0000 On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote: > > > >> — Section 6 — > > >> Should “TLS†here have a citation and normative reference? > > > > > > I didn't include an explicit reference here because TLS is transitively > > referenced by other > > > normative references (including 6749 of which this whole thing is an > > extension) and TLS > > > is pretty widely recognized even without citation. > > ... > > > I'm happy to add a citation here but it does raise the question of what > > the most appropriate > > > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination > > thereof? > > > > I wondered the same thing, and you're also right that it might not > > need a reference in this document. I only even flagged it because > > it's the subject of a MUST. I'll leave it to the Sec ADs (who > > obviously didn't flag it themselves, so maybe they agree that it's not > > necessary). > > > > I'm gonna just leave it as-is then, unless I hear otherwise from the Sec > ADs. I'll throw it out there that "TLS" is marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt ... -Ben From nobody Sat Jul 20 21:28: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 B1D261200F5; Sat, 20 Jul 2019 21:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 zjffAVZPY9iW; Sat, 20 Jul 2019 21:28:49 -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 BB43C1200EF; Sat, 20 Jul 2019 21:28:48 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6L4SgG4029680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Jul 2019 00:28:44 -0400 Date: Sat, 20 Jul 2019 23:28:41 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: Barry Leiba , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Message-ID: <20190721042841.GX23137@kduck.mit.edu> References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> 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] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 04:28:50 -0000 On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote: > > > > > >> — Section 1.1 — > > >> Given the extensive discussion of impersonation here, what strikes me as > > >> missing is pointing out that impersonation here is still controlled, > > that “A is > > >> B†but only to the extent that’s allowed by the token. First, it might > > be > > >> limited by number of instances (one transaction only), by time of day > > (only for > > >> 10 minutes), and by scope (in regard to B’s address book, but not B’s > > email). > > >> Second, there is accountability: audit information still shows that the > > token > > >> authorized acting as B. Is that not worth clarifying? > > > > > > My initial response was going to be "sure, I'll add some bits in sec 1.1 > > along those lines to clarify > > > that." However, as I look again at that section for good opportunities > > to make such additions, I feel > > > like it is already said that impersonation is controlled. > > ... > > > So I think it already says that and I'm gonna have to flip it back and > > ask if you have concrete > > > suggestions for changes or additions that would say it more clearly or > > more to your liking? > > > > It is mentioned, true, and that might be enough. But given that Eve > > also replied that she would like more here, let me suggest something, > > the use of which is entirely optional -- take it, don't take it, > > modify it, riff on it, ignore it completely, as you think best. What > > do you think about changing the last sentence of the paragraph?: "For > > all intents and purposes, when A is impersonating B, A is B within the > > rights context authorized by the token, which could be limited in > > scope or time, or by a one-time-use restriction." > > > > Sure, I think that or some slight modification thereof can work just fine. > I'll do that and get it and the rest of these changes published when the > I-D submission embargo is lifted for Montreal. My brain is apparntly storming and not sleeping. Another option for consideration, is to have two sentences: For all intents and purposes, when A is impersonating B, A is B within the rights context authorized by the token. A's ability to impersonate B could be limited in scope or time, or even with a one-time-use restriction, whether via the contents of the token or an out-of-band mechanism. -Ben From nobody Sun Jul 21 05:15: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 62EFA12011E for ; Sun, 21 Jul 2019 05:15: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY5Y3JCJBoJO for ; Sun, 21 Jul 2019 05:15:03 -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 33D05120120 for ; Sun, 21 Jul 2019 05:14:59 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id g20so67909444ioc.12 for ; Sun, 21 Jul 2019 05:14:59 -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=ggi3uneTqRu/8pfYBLqPPA40G3tWWckq/4oWEkKPoxc=; b=nnNF9xp0ig5kBxQ6NxKCLpnHQ3QV/DFTJ8EPI6BZxLnnqWnmDoNWi4+A+5IBom26vj eJindXUfOqbLZf/rgbeXdL57wsPuwHUfCCbYyIviIriYTSUs7Vir9ba5/fgB/IRV4v6m r1qn8ZSUQnjm99F4IV650ffM4UjxeIfmKS78k= 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=ggi3uneTqRu/8pfYBLqPPA40G3tWWckq/4oWEkKPoxc=; b=JQE6mg68REB3ZiJGHHtqLAQFoTxvxIqzL7lgC5GR4qdqQq0EffFmQ7f0oiPV0co8M9 qI8RAByg5dnzF0vWW6nDMsxY0d2V3kEzErOJoWfX1uGAy2RQOuC+Yu06wG+7aEJLc1Ky 3cOu+YVHN7Xi8TbeS5LKN/GBvNRGUpNy/WpXqo9/ja0ZkdB+fMfd1mutefZv/ewtRMlX d5ELOZz3Pt+YHc4uOlCQABnj/oKmHc4Dg+J+ZZXn9BKA3flkdcOwQ0m+2SGfbGbVONkW A9axJHfOZsL4J2Cye0FhXsL4eBgYTOurpLwHQbJMfEXLjHNArVSkWCpJb/jB3Vo3lDuT SEGg== X-Gm-Message-State: APjAAAWaKQ5q/JNR+oeEdbtk4e/ppG36LzxgjqxlnYBWpXru4eMhGmeb z1+gRQp/X9egleGenlWBffYE8Tg0u3u0PPY91w3yBjrFG7wxUCRVuaV1S7QBpEyWv2lsicI2Bd1 l9qjdA5Z+cDb+ww== X-Google-Smtp-Source: APXvYqzMdke6wPZtoqvoDW/TsV1MdVzqTlFwn0XburffzaShwYbq6H9IkQ+mdC4phwaVqd1PcSwghW+/Y+B9dwq5C6E= X-Received: by 2002:a02:3b62:: with SMTP id i34mr69061215jaf.91.1563711298368; Sun, 21 Jul 2019 05:14:58 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> <20190721042841.GX23137@kduck.mit.edu> In-Reply-To: <20190721042841.GX23137@kduck.mit.edu> From: Brian Campbell Date: Sun, 21 Jul 2019 06:14:32 -0600 Message-ID: To: Benjamin Kaduk Cc: Barry Leiba , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000078925e058e2fe8c0" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 12:15:04 -0000 --00000000000078925e058e2fe8c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That works for me. On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote: > On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba > wrote: > > > > > > > > >> =E2=80=94 Section 1.1 =E2=80=94 > > > >> Given the extensive discussion of impersonation here, what strikes > me as > > > >> missing is pointing out that impersonation here is still controlle= d, > > > that =E2=80=9CA is > > > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the to= ken. First, it > might > > > be > > > >> limited by number of instances (one transaction only), by time of > day > > > (only for > > > >> 10 minutes), and by scope (in regard to B=E2=80=99s address book, = but not > B=E2=80=99s > > > email). > > > >> Second, there is accountability: audit information still shows tha= t > the > > > token > > > >> authorized acting as B. Is that not worth clarifying? > > > > > > > > My initial response was going to be "sure, I'll add some bits in se= c > 1.1 > > > along those lines to clarify > > > > that." However, as I look again at that section for good > opportunities > > > to make such additions, I feel > > > > like it is already said that impersonation is controlled. > > > ... > > > > So I think it already says that and I'm gonna have to flip it back > and > > > ask if you have concrete > > > > suggestions for changes or additions that would say it more clearly > or > > > more to your liking? > > > > > > It is mentioned, true, and that might be enough. But given that Eve > > > also replied that she would like more here, let me suggest something, > > > the use of which is entirely optional -- take it, don't take it, > > > modify it, riff on it, ignore it completely, as you think best. What > > > do you think about changing the last sentence of the paragraph?: "For > > > all intents and purposes, when A is impersonating B, A is B within th= e > > > rights context authorized by the token, which could be limited in > > > scope or time, or by a one-time-use restriction." > > > > > > > Sure, I think that or some slight modification thereof can work just > fine. > > I'll do that and get it and the rest of these changes published when th= e > > I-D submission embargo is lifted for Montreal. > > My brain is apparntly storming and not sleeping. Another option for > consideration, is to have two sentences: > > For all intents and purposes, when A is impersonating B, A is B within th= e > rights context authorized by the token. A's ability to impersonate B cou= ld > be limited in scope or time, or even with a one-time-use restriction, > whether via the contents of the token or an out-of-band mechanism. > > -Ben > --=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._ --00000000000078925e058e2fe8c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me.

On Sat, Jul 20, 2019 at 10:28 PM Be= njamin Kaduk <kaduk@mit.edu> wro= te:
On Fri, Jul = 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba <barryleiba@computer.org> wrot= e:
>
> >
> > >> =E2=80=94 Section 1.1 =E2=80=94
> > >> Given the extensive discussion of impersonation here, wh= at strikes me as
> > >> missing is pointing out that impersonation here is still= controlled,
> > that =E2=80=9CA is
> > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed= by the token.=C2=A0 First, it might
> > be
> > >> limited by number of instances (one transaction only), b= y time of day
> > (only for
> > >> 10 minutes), and by scope (in regard to B=E2=80=99s addr= ess book, but not B=E2=80=99s
> > email).
> > >> Second, there is accountability: audit information still= shows that the
> > token
> > >> authorized acting as B.=C2=A0 Is that not worth clarifyi= ng?
> > >
> > > My initial response was going to be "sure, I'll add= some bits in sec 1.1
> > along those lines to clarify
> > > that." However, as I look again at that section for goo= d opportunities
> > to make such additions, I feel
> > > like it is already said that impersonation is controlled. > > ...
> > > So I think it already says that and I'm gonna have to fl= ip it back and
> > ask if you have concrete
> > > suggestions for changes or additions that would say it more = clearly or
> > more to your liking?
> >
> > It is mentioned, true, and that might be enough.=C2=A0 But given = that Eve
> > also replied that she would like more here, let me suggest someth= ing,
> > the use of which is entirely optional -- take it, don't take = it,
> > modify it, riff on it, ignore it completely, as you think best.= =C2=A0 What
> > do you think about changing the last sentence of the paragraph?: = "For
> > all intents and purposes, when A is impersonating B, A is B withi= n the
> > rights context authorized by the token, which could be limited in=
> > scope or time, or by a one-time-use restriction."
> >
>
> Sure, I think that or some slight modification thereof can work just f= ine.
> I'll do that and get it and the rest of these changes published wh= en the
> I-D submission embargo is lifted for Montreal.

My brain is apparntly storming and not sleeping.=C2=A0 Another option for consideration, is to have two sentences:

For all intents and purposes, when A is impersonating B, A is B within the<= br> rights context authorized by the token.=C2=A0 A's ability to impersonat= e B could
be limited in scope or time, or even with a one-time-use restriction,
whether via the contents of the token or an out-of-band mechanism.

-Ben

<= 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. --00000000000078925e058e2fe8c0-- From nobody Sun Jul 21 05:39:56 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 EF6C2120020; Sun, 21 Jul 2019 05:39:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156371278689.20517.1386590917282737864@ietfa.amsl.com> Date: Sun, 21 Jul 2019 05:39:46 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 12:39:47 -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 : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-03.txt Pages : 13 Date : 2019-07-21 Abstract: An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-03 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 21 05:55:33 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 53B821200B1; Sun, 21 Jul 2019 05:55:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156371372426.20589.10365011724092335159@ietfa.amsl.com> Date: Sun, 21 Jul 2019 05:55:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 12:55:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Author : Vittorio Bertocci Filename : draft-ietf-oauth-access-token-jwt-01.txt Pages : 15 Date : 2019-07-20 Abstract: This specification defines a profile for issuing OAuth2 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 21 07:44: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 00EAF12004E for ; Sun, 21 Jul 2019 07:44:47 -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 39YCaGaKgUJg for ; Sun, 21 Jul 2019 07:44:45 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4EC120019 for ; Sun, 21 Jul 2019 07:44:45 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id a27so26789154qkk.5 for ; Sun, 21 Jul 2019 07:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=oSxcZAiOLJtL1qHYbJ+FRP8tGrZtVawr09yK2WNfWAc=; b=H2OXrGM0vpY09xI27Qe3rCJHzXg1NxJma9Z+PV+tOPOczxqMa69H4kMDBX5fmuZHsb N5GQRZZUkYQvX6AQle/Hf9b7dgPsSUhOnOtB7lh8ZJMwV5tHEf2yeCbxXkYhRjOP9lUS IzLxtTRGOu+6/mTd0kg7tPP1cjccaVk7gHupjt5jZpWgyJR+zzpwfpAJen3w9nskU7EE TvP2IhkKc7HrTNArcJ9B0jYstmmEs+3lMOmkCEitnl3yDMn2exTm8Z8zL76yK99fir1w 9NhBIzxW7IgfZne1nDrNnB8WZT2wYaVRibrzObSpOh6w8AwZ2KVu4DJrMnfEosFbjcEv R+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=oSxcZAiOLJtL1qHYbJ+FRP8tGrZtVawr09yK2WNfWAc=; b=go6wuaPK7NAzvOqKYod3kLM/vYWVbhODhYm0mQ0CqvAQV5vW0J/CJCuTP3uT85HRXS E4lv2Aalnq9RY6CF9XS2iiVKVhJ0mckOPnDil2x60700MTiMwV2xP5CUTZqClaYN/DIq tueLXlQzWf9NMFQ28ePeKVOEnGEH9ufsoZMhlfVuLTvY5awUFdywikN3vy3aX6c7jFlf MFUnoOJ98YmNv3h7ryH0bQuot3RPUxiTXWUgbtSUrrrQIoietnaroZfHjZLSSHvqVZvD 32S6D45vq3HmXWE2WKcDDb/fcL48kuY+/q3rawQr9X+2p3XkNKhBgj8D90w6b9npQN1x pyCg== X-Gm-Message-State: APjAAAXQUUfrW/0PtIeM+SnkkVe/rtujxw1g2jNrWU8ay8rq8dy6LUN+ v51ojNqSCr2T6Bwfmbm4dCk= X-Google-Smtp-Source: APXvYqxwQUCxtayxkT0S+66VR9r2J77ECEobEyUoE4Cv8596F4PXvBbI2kmmdJOqMAZkwEmHejZcNA== X-Received: by 2002:a37:6248:: with SMTP id w69mr43494227qkb.225.1563720284721; Sun, 21 Jul 2019 07:44:44 -0700 (PDT) Received: from [10.0.1.3] (pool-74-103-207-160.prvdri.ftas.verizon.net. [74.103.207.160]) by smtp.gmail.com with ESMTPSA id y6sm15535966qki.67.2019.07.21.07.44.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 07:44:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_566376.316854503312" MIME-Version: 1.0 Date: Sun, 21 Jul 2019 10:44:40 -0400 Message-ID: <170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com> From: "Brock Allen" To: "Leo Tohill" , "David Waite" Cc: "" In-Reply-To: References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> User-Agent: Mailbird/2.6.1.0 X-Mailbird-ID: 170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 14:44:47 -0000 ------=_NextPart_566376.316854503312 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=C2=A0IdentityServer allows a choice of behavior on refresh token expirati= on time. It can have a absolute expiration time, or use a sliding window. FWIW, in addition, those can be used together -- sliding & absolute. Finall= y,=C2=A0refresh tokens can be re-use or one-time use only. These are all pe= r-client settings. -Brock ------=_NextPart_566376.316854503312 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A > = ;IdentityServer allows a choice of behavior= on refresh token expiration time. It can have a absolute expiration time,= or use a sliding window.

FWIW, in addition, those ca= n be used together -- sliding & absolute. Finally, refresh tokens can be re-use or on= e-time use only. These are all per-client settings.

-Brock

<= /div>
=0A =0A =
------=_NextPart_566376.316854503312-- From nobody Sun Jul 21 08:40:59 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 DF9FF120019; Sun, 21 Jul 2019 08:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156372364983.20572.5957709559535531609@ietfa.amsl.com> Date: Sun, 21 Jul 2019 08:40:49 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-19.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 15:40:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-19.txt Pages : 36 Date : 2019-07-21 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 21 08:43:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7412004D for ; Sun, 21 Jul 2019 08:43: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWWXJgkT7b6d for ; Sun, 21 Jul 2019 08:43:48 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E66D120075 for ; Sun, 21 Jul 2019 08:43:46 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id m24so68616116ioo.2 for ; Sun, 21 Jul 2019 08:43:46 -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=grZPRrHWrBJMdJI0vvTGFuzgv5aQ5nvcycgXluT3Zpo=; b=eM+aLcYXOez5vHsaOuIMaXymrk+7ytdD9gfThOHiO7qkEYzAakHSZPx3xdTfjQNHaZ XT/I5KwMO1l5XH00Mv49q6cK3hFv2Igc+vk1kYOvLUbNfloJ1hXf6IV7tPs1kpqHjmZI As10s+5RmS5yMS4GVclaS3I36KBz11R3t6LVU= 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=grZPRrHWrBJMdJI0vvTGFuzgv5aQ5nvcycgXluT3Zpo=; b=ppX1u8BT9wZz/KbmSi6MFzGfKJYd0XkBYhF1NTL4Es+ALCvrT/Kh+YXcsz7OLyesQu pIoTfl7HcfUQMhdT/lk6r7tLBwufdseYPl3N3/buJ7Jr/Y0c0NhhZMlyZFYvEDugwgHm I50pNdSKvVgQHR1gNP60NPUaJ2VJ3G3Z16CR10unVmecU8LaEop+3Vt9Aduo+dqPwhoB jsff77g8sf52p0/eE4K16NYiT3BVh61DKRxH8VT/xzh4FZgsPyeEePKvH/eIeEVRLHmF s8NwnrzbAgIJS0LglYEVzeHEWrPsaZ5gqw63iyr2FzT3KpgDT4OWKmUly94X1YEcxBaD q4xQ== X-Gm-Message-State: APjAAAUm2eLyfX4cGw9v9UcedpoyxLIRwqX4lVYkrct90bYIs4Rtlvtj 7wxENvUacIY3t58xvm6Ba5xYXAt1b9A1PtaJ3D8LOUZQ+ZHQFpSVTd/7Xpd35+yQCOhnji92J1v 2IBuafFPfllWADw== X-Google-Smtp-Source: APXvYqz4SHrF0xXxUHOzOoh53iuGVLq2/JhzQsL+e6LUDPHp9ifnPGElNNfMsoAenxx6hfSwgWA90N/5t/X3YkiaTJw= X-Received: by 2002:a6b:621a:: with SMTP id f26mr53361716iog.127.1563723825265; Sun, 21 Jul 2019 08:43:45 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> <20190721042841.GX23137@kduck.mit.edu> In-Reply-To: From: Brian Campbell Date: Sun, 21 Jul 2019 09:43:19 -0600 Message-ID: To: Benjamin Kaduk Cc: Barry Leiba , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000021dd59058e32d396" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 15:43:51 -0000 --00000000000021dd59058e32d396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 has been published with the updates discussed in this thread. On Sun, Jul 21, 2019 at 6:14 AM Brian Campbell wrote: > That works for me. > > On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote: > >> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: >> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba >> wrote: >> > >> > > >> > > >> =E2=80=94 Section 1.1 =E2=80=94 >> > > >> Given the extensive discussion of impersonation here, what strike= s >> me as >> > > >> missing is pointing out that impersonation here is still >> controlled, >> > > that =E2=80=9CA is >> > > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the t= oken. First, it >> might >> > > be >> > > >> limited by number of instances (one transaction only), by time of >> day >> > > (only for >> > > >> 10 minutes), and by scope (in regard to B=E2=80=99s address book,= but not >> B=E2=80=99s >> > > email). >> > > >> Second, there is accountability: audit information still shows >> that the >> > > token >> > > >> authorized acting as B. Is that not worth clarifying? >> > > > >> > > > My initial response was going to be "sure, I'll add some bits in >> sec 1.1 >> > > along those lines to clarify >> > > > that." However, as I look again at that section for good >> opportunities >> > > to make such additions, I feel >> > > > like it is already said that impersonation is controlled. >> > > ... >> > > > So I think it already says that and I'm gonna have to flip it back >> and >> > > ask if you have concrete >> > > > suggestions for changes or additions that would say it more clearl= y >> or >> > > more to your liking? >> > > >> > > It is mentioned, true, and that might be enough. But given that Eve >> > > also replied that she would like more here, let me suggest something= , >> > > the use of which is entirely optional -- take it, don't take it, >> > > modify it, riff on it, ignore it completely, as you think best. Wha= t >> > > do you think about changing the last sentence of the paragraph?: "Fo= r >> > > all intents and purposes, when A is impersonating B, A is B within t= he >> > > rights context authorized by the token, which could be limited in >> > > scope or time, or by a one-time-use restriction." >> > > >> > >> > Sure, I think that or some slight modification thereof can work just >> fine. >> > I'll do that and get it and the rest of these changes published when t= he >> > I-D submission embargo is lifted for Montreal. >> >> My brain is apparntly storming and not sleeping. Another option for >> consideration, is to have two sentences: >> >> For all intents and purposes, when A is impersonating B, A is B within t= he >> rights context authorized by the token. A's ability to impersonate B >> could >> be limited in scope or time, or even with a one-time-use restriction, >> whether via the contents of the token or an out-of-band mechanism. >> >> -Ben >> > --=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._ --00000000000021dd59058e32d396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.or= g/html/draft-ietf-oauth-token-exchange-19 has been published with the u= pdates discussed in this thread.

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jul 21, 2019 at 6:14 AM Brian = Campbell <bcampbell@pingid= entity.com> wrote:
That works for me.

On Sat, Jul 20, 2019 at = 10:28 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell w= rote:
> On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba <barryleiba@computer.org> wrot= e:
>
> >
> > >> =E2=80=94 Section 1.1 =E2=80=94
> > >> Given the extensive discussion of impersonation here, wh= at strikes me as
> > >> missing is pointing out that impersonation here is still= controlled,
> > that =E2=80=9CA is
> > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed= by the token.=C2=A0 First, it might
> > be
> > >> limited by number of instances (one transaction only), b= y time of day
> > (only for
> > >> 10 minutes), and by scope (in regard to B=E2=80=99s addr= ess book, but not B=E2=80=99s
> > email).
> > >> Second, there is accountability: audit information still= shows that the
> > token
> > >> authorized acting as B.=C2=A0 Is that not worth clarifyi= ng?
> > >
> > > My initial response was going to be "sure, I'll add= some bits in sec 1.1
> > along those lines to clarify
> > > that." However, as I look again at that section for goo= d opportunities
> > to make such additions, I feel
> > > like it is already said that impersonation is controlled. > > ...
> > > So I think it already says that and I'm gonna have to fl= ip it back and
> > ask if you have concrete
> > > suggestions for changes or additions that would say it more = clearly or
> > more to your liking?
> >
> > It is mentioned, true, and that might be enough.=C2=A0 But given = that Eve
> > also replied that she would like more here, let me suggest someth= ing,
> > the use of which is entirely optional -- take it, don't take = it,
> > modify it, riff on it, ignore it completely, as you think best.= =C2=A0 What
> > do you think about changing the last sentence of the paragraph?: = "For
> > all intents and purposes, when A is impersonating B, A is B withi= n the
> > rights context authorized by the token, which could be limited in=
> > scope or time, or by a one-time-use restriction."
> >
>
> Sure, I think that or some slight modification thereof can work just f= ine.
> I'll do that and get it and the rest of these changes published wh= en the
> I-D submission embargo is lifted for Montreal.

My brain is apparntly storming and not sleeping.=C2=A0 Another option for consideration, is to have two sentences:

For all intents and purposes, when A is impersonating B, A is B within the<= br> rights context authorized by the token.=C2=A0 A's ability to impersonat= e B could
be limited in scope or time, or even with a one-time-use restriction,
whether via the contents of the token or an out-of-band mechanism.

-Ben

<= 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. --00000000000021dd59058e32d396-- From nobody Sun Jul 21 09:31: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 D56C712018D; Sun, 21 Jul 2019 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGiu3OU3Nofp; Sun, 21 Jul 2019 09:31:17 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8391201A2; Sun, 21 Jul 2019 09:31:16 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id o9so68800655iom.3; Sun, 21 Jul 2019 09:31:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2PEhxwoTHW43d2v40FNbr2GieGDzzUBBOlFjVEbECqA=; b=qsV+popzGG74ofBCPBYm/4yoz/iDf+9Qc/CvLwYDUcM6GIWC3oVxJ74IdJ4oPr3ZTt OQb+VSiQWDz6izk13O29oFbhgmMBQGhZ29oPdn/7a9pB0JY275f6I5kb/80qMnWfwYrm Wz6f9B6q7nB9gxZxtv0soJyIjo4fYPyeFZU10vakZ+lOrVKO/HNLtDCj0SjTTyXZUvps y6y4rYkcrVQy2v7pi1M9+WMeqkq9FXB2MS6xusa7he+TF3rIiNnT7i+yKcij9q2CqLWd EPZOLGSI/1xodCAXTkiR1TrU/Riwn7VN/F7gcNFc7Giqz0IPHUdX+ybk66qbB2fbnOpv AG4g== X-Gm-Message-State: APjAAAVyfakDyHqU5OLy3+vUBI9yMOK3dVM8K0Eq6rgvAu+hS/jMQ5jB 9SbK1epU+SRbTf8sBxiG+FcXgI926VMSxICNIFg= X-Google-Smtp-Source: APXvYqwCBAS3MaUL5HBM+VNG0/klo+F7ufDZOW3VoI6UPHvQgXM+GToR8TxBrjviiwOFxkV61FchYV1oX+ygnxOy0xs= X-Received: by 2002:a5d:9613:: with SMTP id w19mr23367361iol.140.1563726675920; Sun, 21 Jul 2019 09:31:15 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> <20190721042841.GX23137@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Sun, 21 Jul 2019 12:31:04 -0400 Message-ID: To: Brian Campbell Cc: Benjamin Kaduk , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 16:31:25 -0000 Thanks, Brian! Barry On Sun, Jul 21, 2019 at 11:43 AM Brian Campbell wrote: > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 has been p= ublished with the updates discussed in this thread. > > On Sun, Jul 21, 2019 at 6:14 AM Brian Campbell wrote: >> >> That works for me. >> >> On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote: >>> >>> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: >>> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba = wrote: >>> > >>> > > >>> > > >> =E2=80=94 Section 1.1 =E2=80=94 >>> > > >> Given the extensive discussion of impersonation here, what strik= es me as >>> > > >> missing is pointing out that impersonation here is still control= led, >>> > > that =E2=80=9CA is >>> > > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by the = token. First, it might >>> > > be >>> > > >> limited by number of instances (one transaction only), by time o= f day >>> > > (only for >>> > > >> 10 minutes), and by scope (in regard to B=E2=80=99s address book= , but not B=E2=80=99s >>> > > email). >>> > > >> Second, there is accountability: audit information still shows t= hat the >>> > > token >>> > > >> authorized acting as B. Is that not worth clarifying? >>> > > > >>> > > > My initial response was going to be "sure, I'll add some bits in = sec 1.1 >>> > > along those lines to clarify >>> > > > that." However, as I look again at that section for good opportun= ities >>> > > to make such additions, I feel >>> > > > like it is already said that impersonation is controlled. >>> > > ... >>> > > > So I think it already says that and I'm gonna have to flip it bac= k and >>> > > ask if you have concrete >>> > > > suggestions for changes or additions that would say it more clear= ly or >>> > > more to your liking? >>> > > >>> > > It is mentioned, true, and that might be enough. But given that Ev= e >>> > > also replied that she would like more here, let me suggest somethin= g, >>> > > the use of which is entirely optional -- take it, don't take it, >>> > > modify it, riff on it, ignore it completely, as you think best. Wh= at >>> > > do you think about changing the last sentence of the paragraph?: "F= or >>> > > all intents and purposes, when A is impersonating B, A is B within = the >>> > > rights context authorized by the token, which could be limited in >>> > > scope or time, or by a one-time-use restriction." >>> > > >>> > >>> > Sure, I think that or some slight modification thereof can work just = fine. >>> > I'll do that and get it and the rest of these changes published when = the >>> > I-D submission embargo is lifted for Montreal. >>> >>> My brain is apparntly storming and not sleeping. Another option for >>> consideration, is to have two sentences: >>> >>> For all intents and purposes, when A is impersonating B, A is B within = the >>> rights context authorized by the token. A's ability to impersonate B c= ould >>> be limited in scope or time, or even with a one-time-use restriction, >>> whether via the contents of the token or an out-of-band mechanism. >>> >>> -Ben > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. From nobody Sun Jul 21 09:53: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 EEF97120162 for ; Sun, 21 Jul 2019 09:53:19 -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 vMM5vswq-fah for ; Sun, 21 Jul 2019 09:53:16 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2D2120155 for ; Sun, 21 Jul 2019 09:53:16 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id s7so68699536iob.11 for ; Sun, 21 Jul 2019 09:53:16 -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=Nm+PwnGPvAZfJJqo6E9XZT8uwLvV+byRkLKS0GL7GBc=; b=YGVaqSuzwTjULq5bL8z0ZfDf2MAoIV5mULHk1Ik7mpBlFbkqXvvovSCJW9vz9HGVas 4ZVNEgxB7PbOhd92M9kFRvIJLnQCgkAPjphbXelEhfBz7QFPre6E7yZhdrAwPb5WLGUS CmIG7UHszvbXZeuFBqwyPBBPPAIQMJEnTBChk= 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=Nm+PwnGPvAZfJJqo6E9XZT8uwLvV+byRkLKS0GL7GBc=; b=j+uIVGpkOQNYhvEHFLfYF80JhrVVKtN88PnNgsFSi6Llhe3NgLt4LCPikv0KHSjVQU Q+ajl8FjbUIBdoDLXTaZASYuQJ2WJTnPZoMJr2apAA70wA93i5qizSkbE72uqMD93Zpo V0nqBmX300Ch0MfPsf9H6l0qm74kaKeUaaQw4yCsP2jOACJbfJOeXgU/r6IjztY5kVVZ zxYULtBccKFpg866GVIOjmg1PgvWO2wiZP985RYRK04ctreHQBMQxG9IBQRvr93YDc9o ALPLcTnwDxzMqxVvCA13juH0z8qpqdco4XEx09Gf8yaPv8oDPaIxnKvv34dW4GC790GC hbHQ== X-Gm-Message-State: APjAAAUm6T6xfI2wwkwe0hirzBM+XwdwJ/OZd4IMhIgoSzp4Rf7i+JuJ 4aigDo2QQnYigYLZ8+bE7cwUpGscPbFizBZqcm0pk04H9OVrIOxFv/Osgtq5KQQCTEKgtuMiU8w PO5uS1cxu7vLBzA== X-Google-Smtp-Source: APXvYqyxleT0yPzPB1AvQPpGVqS2xnp2J0jw8+PzZLAP3bG12B2wMC6vwFVPhq0azIZEfKuSrJyExofGoCW4yajJPX8= X-Received: by 2002:a02:3b62:: with SMTP id i34mr70266269jaf.91.1563727995228; Sun, 21 Jul 2019 09:53:15 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> From: Brian Campbell Date: Sun, 21 Jul 2019 10:50:32 -0600 Message-ID: To: Roman Danyliw Cc: oauth Content-Type: multipart/alternative; boundary="000000000000ae6ce3058e33cbe1" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 16:53:20 -0000 --000000000000ae6ce3058e33cbe1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doh, I got distracted with the registration question and lost track of this fork of the thread. I'll need to do a -04 also (after maybe some more discussion too) before I pass the ball back to the AD. On Wed, Jul 17, 2019, 4:04 PM Roman Danyliw wrote: > Hi Brian! > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, July 17, 2019 4:35 PM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > Thank you, Roman, for the review. Some replies are inline below. I'll aim > to push out a -03 addressing this stuff sometime not too long after the I= -D > submission embargo is lifted next week. > > > > > > On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw wrote: > > Hi! > > The following is my AD review of draft-ietf-oauth-resource-indicators-02. > The document is in good shape. > > > > That's always nice to hear :-) > > > > > (1) Section 2. Per "The parameter can carry the location of a protected > resource, typically as an https URL, or a more abstract identifier", is > this "abstract identifier" still an absolute URI per Section 4.3 of RFC39= 86? > > > > Absolutely (see what I did there? sigh...). Syntactically it's an absolut= e > URI. Semantically, while it might be an actual network addressable locati= on > identified by an HTTPS URL, it might also be a URN or something that more > abstractly indicates a resource or grouping of resources. But its format = is > an absolute URI regardless. > > > > I'm not sure what, if anything, can be added or changed here to help > clarify. But I'm happy to entertain suggestions, if you've got em and/or > think something is needed. > > > > [Roman] Understood. Concur there is nothing to do here. > > > > > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > -- is this language suggesting that the authorization server is modifyin= g > the scope value based on the resource it sees? I'm trying to understand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > > > > Perhaps "adapt" wasn't the best choice of word but it's meant to say that > an authorization server with sufficient understanding of what scopes are > applicable to what resources (which won't always be the case or even > possible but sometimes) could limit the scope associated with an access > token (downscoping really) to only the scope that is applicable to the > resource. > > > > Some of the examples (figures 2 - 6) attempt to show, among other things, > a hypothetical case of how this might go down. > > > > In Figure 2 the initial authorization request that's approved has scope o= f > calendar & contacts and resources https://contacts.example.com/ & > https://cal.example.com/ > > > > A subsequent access token request (Figure 3) has resource > https://cal.example.com/ and the issued access token scope (Figure 4) is > "adapted" to that resource to be only calendar > > > > Another subsequent access token request (Figure 5) has resource > https://contacts.example.com/ and the issued access token scope (Figure > 6) is downscoped based on that resource to be only contacts > > > > Would it be easier to understand if the word "downscope" was used rather > than "adapt"? > > > > [Roman] Using =E2=80=9Cdownscope=E2=80=9D does work for me. It captures = that the server > is going to reduce the scope (and certainly not expand it). > > > > > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? > > > > I'm not sure, to be honest. Downscopping when possible and to the extent > possible is usually a good idea (least privilege and all that) but I thin= k > maybe I'm missing your point/question. > > > > [Roman] Yes, least privilege was part of it and I think the text above > gets at it. However, the other part is the relationship with the next > sentence in the paragraph, =E2=80=9CThis further improves privacy as scop= e values > give an indication of what services the resource owner uses and it improv= es > security as scope values may contain confidential data=E2=80=9D. If the = initial > request was notionally a scope of =E2=80=9Call the houses on the block=E2= =80=9D, but the > server knew that this request was too broad and down-scoped to =E2=80=9Co= nly the > corner house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privac= y? I also don=E2=80=99t > follow how reducing the scope impacts confidential data. > > > > > (3) Editorial > ** Section 1 and 2.1. Multiple Typo. s/the the/the/g > > > > Apparently I'm fond of the double "the" and have a hard time spotting it > myself. I think this is the second review in as many weeks that you've > caught a few of those. Will fix. > > > > > ** Section 2. Editorial. s/resource at which/resource to which/ > > > > Okay. > > > > > ** Section 2. Editorial. > s/ And can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > It can also be used to inform the client that it has requested an > invalid combination of resource and scope./ > > > > Yup. > > > > > ** Section 2.1. Multiple Typo. s/an an/an/g > > > > Again with the double words. Sigh. A double double even. > > > > > > > ** Section 2.2. Editorial. s/token request and response/token request > (Figure 3) and response (Figure 4)/ > > > > Makes sense. > > > > > > ** Section 3. Typo. s/a invalid/an invalid/ > > > > Of course. > > > > > ** Section 3. Missing words. "A bearer token that has multiple intended > recipients (audiences) can be used by any one of those recipients at any > other." Is it protected resource? > > > > Well, those are all the words that I'd intended to be there :/ But it doe= s > read a little curtly. How about the following instead? > > > > "A bearer token that has multiple intended recipients (audiences) > indicating that the token is valid at more than one protected resource ca= n > be used by any one of those protected resources to access any of the othe= r > protected resources." > > > > [Roman] Thanks for fixing all of these. > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=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._ --000000000000ae6ce3058e33cbe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doh, I got distracted with the registration question and = lost track of this fork of the thread. I'll need to do a -04 also (afte= r maybe some more discussion too) before I pass the ball back to the AD.
On = Wed, Jul 17, 2019, 4:04 PM Roman Danyliw <rdd@cert.org> wrote:

Hi Brian!

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Wednesday, July 17, 2019 4:35 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

Thank you, Roman, for the review. Some replies are i= nline below. I'll aim to push out a -03 addressing this stuff sometime = not too long after the I-D submission embargo is lifted next week.=C2=A0=

=C2=A0

=C2=A0

On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw <rdd@cert= .org> wrote:

Hi!

The following is my AD review of draft-ietf-oauth-resource-indicators-02.= =C2=A0 The document is in good shape.

=C2=A0

That's always nice to hear :-)

=C2=A0


(1) Section 2. Per "The parameter can carry the location of a protecte= d resource, typically as an https URL, or a more abstract identifier",= is this "abstract identifier" still an absolute URI per Section = 4.3 of RFC3986?

=C2=A0

Absolutely (see what I did there? sigh...). Syntacti= cally it's an absolute URI. Semantically, while it might be an actual n= etwork addressable location identified by an HTTPS URL, it might also be a = URN or something that more abstractly indicates a resource or grouping of resources. But its format is an absolu= te URI regardless.

=C2=A0

I'm not sure what, if anything, can be added or = changed here to help clarify. But I'm happy to entertain suggestions, i= f you've got em and/or think something is needed.=C2=A0

=C2=A0

[Roman] Understood.=C2= =A0 Concur there is nothing to do here.

=C2=A0


(2) Section 2.2.=C2=A0 in the sentence "To the extent possible, when i= ssuing access tokens, the authorization server should adapt the scope value= associated with an access token to the value the respective resource is ab= le to process and needs to know":

--=C2=A0 is this language suggesting that the authorization server is modif= ying the scope value based on the resource it sees?=C2=A0 I'm trying to= understand what "adapt" means, especially in relation to the imp= roved security and privacy the subsequent sentence suggests.<= /p>

=C2=A0

Perhaps "adapt" wasn't the best choice= of word but it's meant to say that an authorization server with suffic= ient understanding of what scopes are applicable to what resources (which w= on't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really)= to only the scope that is applicable to the resource.=C2=A0

=C2=A0

Some of the examples (figures 2 - 6) attempt to show= , among other things, a hypothetical case of how this might go down.

=C2=A0

In Figure 2 the initial authorization request that&#= 39;s approved has scope of calendar & contacts and resources https://contacts.example.com/ & https://cal.example.com/

=C2=A0

A subsequent access token request (Figure 3) has res= ource https://cal.example.com/ and the issued access token scope (Figure 4) i= s "adapted" to that resource to be only calendar

=C2=A0

Another subsequent access token request (Figure 5) h= as resource https://contacts.example.com/ and the issued access token scope (Fi= gure 6) is downscoped based on that resource to be only contacts<= /u>

=C2=A0

Would it be easier to understand if the word "d= ownscope" was used rather than "adapt"?

=C2=A0

[Roman] Using =E2=80=9Cdownscope=E2= =80=9D does work for me.=C2=A0 It captures that the server is going to redu= ce the scope (and certainly not expand it).

=C2=A0


-- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ?

=C2=A0

I'm not sure, to be honest. Downscopping when po= ssible and to the extent possible is usually a good idea (least privilege a= nd all that) but I think maybe I'm missing your point/question.

=C2=A0

[Roman] = Yes, least privilege was part of it and I think the text above gets at it.= =C2=A0 However, the other part is the relationship with the next sentence in the paragraph, =E2=80=9CThis further improves privacy= as scope values give an indication of what services the resource owner use= s and it improves security as scope values may contain confidential data=E2= =80=9D.=C2=A0 If the initial request was notionally a scope of =E2=80=9Call the houses on the block=E2=80=9D, but the server kne= w that this request was too broad and down-scoped to =E2=80=9Conly the corn= er house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privacy?=C2= =A0 I also don=E2=80=99t follow how reducing the scope impacts confidential= data.

=C2=A0


(3) Editorial
** Section 1 and 2.1.=C2=A0 Multiple Typo.=C2=A0 s/the the/the/g<= /u>

=C2=A0

Apparently I'm fond of the double "the"= ; and have a hard time spotting it myself. I think this is the second revie= w in as many weeks that you've caught a few of those. Will fix.

=C2=A0


** Section 2.=C2=A0 Editorial. s/resource at which/resource to which/

=C2=A0

Okay.

=C2=A0


** Section 2.=C2=A0 Editorial.=C2=A0
s/ And can also be used to inform the client that it has requested an inval= id combination of resource and scope./
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It can also be used to inform th= e client that it has requested an invalid combination of resource and scope= ./

=C2=A0

Yup.

=C2=A0


** Section 2.1. Multiple Typo. s/an an/an/g

=C2=A0

Again with the double words. Sigh. A double double e= ven.=C2=A0

=C2=A0

=C2=A0


** Section 2.2.=C2=A0 Editorial. s/token request and response/token request= (Figure 3) and response (Figure 4)/

=C2=A0

Makes sense.

=C2=A0

=C2=A0

** Section 3.=C2=A0 Typo.=C2=A0 s/a invalid/an inval= id/

=C2=A0

Of course.

=C2=A0


** Section 3.=C2=A0 Missing words.=C2=A0 "A bearer token that has mult= iple intended recipients (audiences) can be used by any one of those recipi= ents at any other."=C2=A0 Is it protected resource?

=C2=A0

Well, those are all the words that I'd intended = to be there :/ But it does read a little curtly. How about the following in= stead?

=C2=A0

"A bearer token that has multiple intended reci= pients (audiences) indicating that the token is valid at more than one prot= ected resource can be used by any one of those protected resources to acces= s any of the other protected resources."

=C2=A0

[Roman] Thanks for fixing all of thes= e.

=C2=A0


CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ae6ce3058e33cbe1-- From nobody Sun Jul 21 10:45: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 627CE12015F for ; Sun, 21 Jul 2019 10:44: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=unavailable 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 e4SkBTdfCiHg for ; Sun, 21 Jul 2019 10:44:49 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A05120154 for ; Sun, 21 Jul 2019 10:44:46 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id n9so37078188wru.0 for ; Sun, 21 Jul 2019 10:44:46 -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=WJspW9LICVAGK8+WsSuJezeneARxDVfrH81b/UUKdvA=; b=z8qFZC+yjs1GQLOBq7i0F1ctPvVj+2xSTL7uBHQ8MX0fCF1pRFGw9p/798uC+ZKmeR ZiGLlopfmYBxDGRTKrH+RICYpPdXyrubIX7T3I/BKS1fCkMUplS66ktmGlIzITGzlSrg 2mWUIKTal5hYyCILJ0FH3ve9o7bGResa0WaKzRro7oqpKjpTpyioj2rpPYLBWO5cxN0j MTf4UiPY8xQ6DvgjUUndoBEnT/b5sRgAR+9XibTt1BfnFnA148IX6G2UsODXPBiE9RGK bIT8ddnN2pT25V/Ak1xbZV8LLDz/id9SdrhJDmcLQxzPa7Opbk076bTKpOwTUQOsHhtX hxRg== 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=WJspW9LICVAGK8+WsSuJezeneARxDVfrH81b/UUKdvA=; b=Ciww/SdMj+V9PepD2s8ciBfSbPGsTVht/ztAd75rAD8FgrKKlJd4ZQLhSaRD47rMbd Wq4MV3v6RaIKbDF9EUzFys7yAFXLSIwhGgXgaeKrZMWkaPYRuQNcUJkXmraphSkTGXdb lnuJmm1XOXqdTfdOtmxGbU+uyq4YmtLQb5z/DtoSvwRwR3Y91Rgsa9LyYNaM59wigfyb SHzAOJj6gm5VOtXFFj0XVUzVhvLws3YSdezR7jYqdZndln0MwlVm4VLRYlBM8OcP5+hH HP4jplAshVQxrN6NzGd0ppN7q3Zg3dygw6qq8gwYdwyQNXcZyrAmsops7CwIEiQM3U4R zygg== X-Gm-Message-State: APjAAAVm48R/68idFZYdr/X/cQiREN+U0SzGozcBin2UwRIwcCiv9jWa tk2Y4NAyZkw4xPZtl42dzfa16AaPt7YBBOvHJF1ZSg== X-Google-Smtp-Source: APXvYqyIyLCAflw5axwwtp/TM9GnXi+27lBLMl7ehSKD651z5RG5qr/cFXqmTv/rN2FX4Jb7b6/1sq/jpbUs0LuuaH0= X-Received: by 2002:adf:e883:: with SMTP id d3mr72647534wrm.330.1563731084064; Sun, 21 Jul 2019 10:44:44 -0700 (PDT) MIME-Version: 1.0 References: <156348397007.8464.8217832087905511031.idtracker@ietfa.amsl.com> <20190721042841.GX23137@kduck.mit.edu> In-Reply-To: From: John Bradley Date: Sun, 21 Jul 2019 13:18:35 -0400 Message-ID: To: Barry Leiba Cc: Brian Campbell , Benjamin Kaduk , oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-token-exchange@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000ca4fd0058e3483e2" Archived-At: Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 17:44:51 -0000 --000000000000ca4fd0058e3483e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks On Sun, Jul 21, 2019, 12:31 PM Barry Leiba wrote: > Thanks, Brian! > > Barry > > On Sun, Jul 21, 2019 at 11:43 AM Brian Campbell > wrote: > > > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 has been > published with the updates discussed in this thread. > > > > On Sun, Jul 21, 2019 at 6:14 AM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> > >> That works for me. > >> > >> On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk wrote: > >>> > >>> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > >>> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba > wrote: > >>> > > >>> > > > >>> > > >> =E2=80=94 Section 1.1 =E2=80=94 > >>> > > >> Given the extensive discussion of impersonation here, what > strikes me as > >>> > > >> missing is pointing out that impersonation here is still > controlled, > >>> > > that =E2=80=9CA is > >>> > > >> B=E2=80=9D but only to the extent that=E2=80=99s allowed by th= e token. First, > it might > >>> > > be > >>> > > >> limited by number of instances (one transaction only), by time > of day > >>> > > (only for > >>> > > >> 10 minutes), and by scope (in regard to B=E2=80=99s address bo= ok, but > not B=E2=80=99s > >>> > > email). > >>> > > >> Second, there is accountability: audit information still shows > that the > >>> > > token > >>> > > >> authorized acting as B. Is that not worth clarifying? > >>> > > > > >>> > > > My initial response was going to be "sure, I'll add some bits i= n > sec 1.1 > >>> > > along those lines to clarify > >>> > > > that." However, as I look again at that section for good > opportunities > >>> > > to make such additions, I feel > >>> > > > like it is already said that impersonation is controlled. > >>> > > ... > >>> > > > So I think it already says that and I'm gonna have to flip it > back and > >>> > > ask if you have concrete > >>> > > > suggestions for changes or additions that would say it more > clearly or > >>> > > more to your liking? > >>> > > > >>> > > It is mentioned, true, and that might be enough. But given that > Eve > >>> > > also replied that she would like more here, let me suggest > something, > >>> > > the use of which is entirely optional -- take it, don't take it, > >>> > > modify it, riff on it, ignore it completely, as you think best. > What > >>> > > do you think about changing the last sentence of the paragraph?: > "For > >>> > > all intents and purposes, when A is impersonating B, A is B withi= n > the > >>> > > rights context authorized by the token, which could be limited in > >>> > > scope or time, or by a one-time-use restriction." > >>> > > > >>> > > >>> > Sure, I think that or some slight modification thereof can work jus= t > fine. > >>> > I'll do that and get it and the rest of these changes published whe= n > the > >>> > I-D submission embargo is lifted for Montreal. > >>> > >>> My brain is apparntly storming and not sleeping. Another option for > >>> consideration, is to have two sentences: > >>> > >>> For all intents and purposes, when A is impersonating B, A is B withi= n > the > >>> rights context authorized by the token. A's ability to impersonate B > could > >>> be limited in scope or time, or even with a one-time-use restriction, > >>> whether via the contents of the token or an out-of-band mechanism. > >>> > >>> -Ben > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > --000000000000ca4fd0058e3483e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks

On Sun, Jul 21, 2019, 12:31 PM Barry Leiba <barryleiba@computer.org> wrot= e:
Thanks, Brian!

Barry

On Sun, Jul 21, 2019 at 11:43 AM Brian Campbell
<bcampbell@pingidentity.com> wrote:
>
> https://tools.ietf.org= /html/draft-ietf-oauth-token-exchange-19 has been published with the up= dates discussed in this thread.
>
> On Sun, Jul 21, 2019 at 6:14 AM Brian Campbell <bcampbell@p= ingidentity.com> wrote:
>>
>> That works for me.
>>
>> On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk <kaduk@mit.edu&g= t; wrote:
>>>
>>> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote= :
>>> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba <ba= rryleiba@computer.org> wrote:
>>> >
>>> > >
>>> > > >> =E2=80=94 Section 1.1 =E2=80=94
>>> > > >> Given the extensive discussion of impersona= tion here, what strikes me as
>>> > > >> missing is pointing out that impersonation = here is still controlled,
>>> > > that =E2=80=9CA is
>>> > > >> B=E2=80=9D but only to the extent that=E2= =80=99s allowed by the token.=C2=A0 First, it might
>>> > > be
>>> > > >> limited by number of instances (one transac= tion only), by time of day
>>> > > (only for
>>> > > >> 10 minutes), and by scope (in regard to B= =E2=80=99s address book, but not B=E2=80=99s
>>> > > email).
>>> > > >> Second, there is accountability: audit info= rmation still shows that the
>>> > > token
>>> > > >> authorized acting as B.=C2=A0 Is that not w= orth clarifying?
>>> > > >
>>> > > > My initial response was going to be "sure,= I'll add some bits in sec 1.1
>>> > > along those lines to clarify
>>> > > > that." However, as I look again at that se= ction for good opportunities
>>> > > to make such additions, I feel
>>> > > > like it is already said that impersonation is c= ontrolled.
>>> > > ...
>>> > > > So I think it already says that and I'm gon= na have to flip it back and
>>> > > ask if you have concrete
>>> > > > suggestions for changes or additions that would= say it more clearly or
>>> > > more to your liking?
>>> > >
>>> > > It is mentioned, true, and that might be enough.=C2= =A0 But given that Eve
>>> > > also replied that she would like more here, let me s= uggest something,
>>> > > the use of which is entirely optional -- take it, do= n't take it,
>>> > > modify it, riff on it, ignore it completely, as you = think best.=C2=A0 What
>>> > > do you think about changing the last sentence of the= paragraph?: "For
>>> > > all intents and purposes, when A is impersonating B,= A is B within the
>>> > > rights context authorized by the token, which could = be limited in
>>> > > scope or time, or by a one-time-use restriction.&quo= t;
>>> > >
>>> >
>>> > Sure, I think that or some slight modification thereof ca= n work just fine.
>>> > I'll do that and get it and the rest of these changes= published when the
>>> > I-D submission embargo is lifted for Montreal.
>>>
>>> My brain is apparntly storming and not sleeping.=C2=A0 Another= option for
>>> consideration, is to have two sentences:
>>>
>>> For all intents and purposes, when A is impersonating B, A is = B within the
>>> rights context authorized by the token.=C2=A0 A's ability = to impersonate B could
>>> be limited in scope or time, or even with a one-time-use restr= iction,
>>> whether via the contents of the token or an out-of-band mechan= ism.
>>>
>>> -Ben
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.
--000000000000ca4fd0058e3483e2-- From nobody Sun Jul 21 14:22: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 36C33120147 for ; Sun, 21 Jul 2019 14:22:35 -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 mQK0A0TrRCPd for ; Sun, 21 Jul 2019 14:22:32 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A20120098 for ; Sun, 21 Jul 2019 14:22:32 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id p197so25112762lfa.2 for ; Sun, 21 Jul 2019 14:22:32 -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=GtVzogqn8sc1eEqARXBQLIDQL0iVNrHpxNv/0qvWCuM=; b=se8ppmB2kkYkzz9BxDeIk9B+yPvUOmqrIp7wUAY3yM5XIkKVQCx6Jh/cz5Mm+J0RBq xutx6A+1F21pclmei/mS73pq3+n9aQWpef7Pe+oYSmzBI22Hr+mcq5vi4R73jDfbl8W1 nSYH/I0lWc2FP4iCB2ilz/0OcSUZoN41hCQtItZzs3dNI+7ExnXyaWvlpC5Hs0qLunKJ PHFVpWi3w6SOLYhGXxUnfSCSGMKhWOJQn5qe79/lpC53oiEn6TshMFsk4p+eCwjgok0U Aqosa6Si8rABDdjTlmNVnALE3jx0aolcfVMvJppqHFpCtlmcRR1LesFT6/AZpHRpHKfN QeBQ== 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=GtVzogqn8sc1eEqARXBQLIDQL0iVNrHpxNv/0qvWCuM=; b=izO9pr7zQuwjruJ/2ioORZ06W32/a9iLAutuD5/MG/mNbfbBOMnn38mq5o6p5Bl6I3 kiFEPH5rC890R9sN6/gbe/JIDXQegV6LkHcjsf2MeTW4ExzbWqK/H/cvvX+2T4EzEeg7 a3OR5+50Wm7QJoFxl0BeGu3KgkIDU0btQHqF7myLv1F0DN0/axOVoKSlGzleuovILIGT /k+lU6KphdcvA8u0Bxk/rif1Y2tQOV0n8B2Rv38JBfV4lXVhVRq9ZlpGuqPWG6OiD9wc ngWyc8onNc1LPB4ROVgAzMlK1K30X8A1yFQ2zRIuRxqcQBWOA1HmaXpX4il1968urEOU WDNw== X-Gm-Message-State: APjAAAVme6TDv8lMIqQ0gwDO8Gt7sKgVtMnVswoSTjd4UR3uf12qGGI3 g8cyWwHfRiWPCQLi0RwAY5jaI6gjrdHdmucBpD7y+HfE X-Google-Smtp-Source: APXvYqw4if3s8pA9NNUh995Uv3Mk0Cke/VttiCc1LHqSnDivCfAXH5rtFvJMg3bM4jTYu4PV1T/l+q135/pdnopNQNY= X-Received: by 2002:ac2:546a:: with SMTP id e10mr30604368lfn.75.1563744150500; Sun, 21 Jul 2019 14:22:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 21 Jul 2019 14:22:19 -0700 Message-ID: To: Neil Madden Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="0000000000009c39e8058e378e44" Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2019 21:22:35 -0000 --0000000000009c39e8058e378e44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, I agree that an access token that is usable across resources is problematic. How are you thinking multiple access tokens would be returned? Why do you think the request needs to return multiple tokens rather than making a separate request for each token? That would seem to simplify the request and response as context would only need to provided for the one access token. On Fri, Jul 19, 2019 at 11:42 PM Neil Madden wrote: > If we=E2=80=99re going to redesign OAuth, one improvement would be to all= ow a > client to request different access tokens for different resource servers = in > a single request. That should include issuing a different access token fo= r > the userinfo endpoint vs other RSes. > > One of the weaknesses of combined OAuth + OIDC use now is that if you > request OIDC scopes and scopes for another resource in the same request > then you inadvertently give those other RSes access to the user=E2=80=99s= profile. > > =E2=80=94 Neil > > On 20 Jul 2019, at 01:02, Aaron Parecki wrote: > > Hi all, I'm looking forward to the discussion on this on Tuesday! > > I wanted to add my thoughts on a potential addition to this draft, > specifically around returning some minimal user information in the > transaction response. > > The summary of the suggestion is to return a new "user" key along with th= e > access token that contains the user ID and userinfo endpoint, such as: > > { > "access_token": { > "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type": "bearer" > }, > "user": { > "id": "5035678642", > "userinfo": "https://authorization-server.com/user/5035678642" > } > } > > A more detailed analysis of the specific proposal and motivation behind > this is available on my blog: > > https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz > > Thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Tue, Jul 9, 2019 at 2:48 PM Justin Richer wrote: > >> I have requested time to present Transactional Authorization (the XYZ >> project) at the Montreal meeting in a couple weeks. Ahead of that, I=E2= =80=99ve >> uploaded a new version of the spec: >> >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 >> >> Additionally, I=E2=80=99ve updated the writeup and examples on https://o= auth.xyz/ >> >> >> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested = from the >> chairs that I present during the Tuesday session due to limited >> availability of some key WG members on Friday. >> >> =E2=80=94 Justin >> >> _______________________________________________ >> 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 > --0000000000009c39e8058e378e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil, I agree that an access token that is usable acros= s resources is problematic.

How are you thinking multipl= e access tokens would be returned?

Why do you thin= k the request needs to return multiple tokens rather than making a separate= request for each token? That would seem to simplify the request and respon= se as context would only need to provided for the one access token.



On Fri, Jul 19, 2019 at 11:42 PM Neil Madden = <neil.madden@forgerock.com<= /a>> wrote:
<= div dir=3D"auto">
If we=E2=80=99re g= oing to redesign OAuth, one improvement would be to allow a client to reque= st different access tokens for different resource servers in a single reque= st. That should include issuing a different access token for the userinfo e= ndpoint vs other RSes.=C2=A0

One of the weaknesses of combined OAuth + OIDC use now is that if you re= quest OIDC scopes and scopes for another resource in the same request then = you inadvertently give those other RSes access to the user=E2=80=99s profil= e.=C2=A0

=E2=80=94 Neil
Hi all, I'm looking forward to the discussion on this on Tuesday!
I wanted to add my thoughts on a potential addition to th= is draft, specifically around returning some minimal user information in th= e transaction response.

The summary of the suggest= ion is to return a new "user" key along with the access token tha= t contains the user ID and userinfo endpoint, such as:

=
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0=C2=A0=C2=A0 "access_token":= {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "value": "UM1P9PMHKUR= 64TB8N6BW7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 &q= uot;type": "bearer"
=C2=A0 =C2=A0=C2=A0=C2=A0 },
=C2= =A0 =C2=A0=C2=A0=C2=A0 "user": {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0 "id": "5035678642",
=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0 "userinfo": "https://authorization-server.com/use= r/5035678642"
=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0 =C2=A0=C2= =A0}

A more detailed analysis of the specific propos= al and motivation behind this is available on my blog:

=

Thanks!

----
Aaron Parecki



On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jricher@mit.edu> = wrote:
I have requested time to present Transactional Authorization (the XYZ proje= ct) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve = uploaded a new version of the spec:


Additionally, I=E2=80=99ve updated the writeup and examples on https://oauth.xyz/=C2=A0

I plan to be in Montreal for the whole week, and I=E2=80=99ve requeste= d from the chairs that I present during the Tuesday session due to limited = availability of some key WG members on Friday.=C2=A0

=E2=80=94 Justin

_______________________________________________
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
--0000000000009c39e8058e378e44-- From nobody Sun Jul 21 14:28: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 954D612014B for ; Sun, 21 Jul 2019 14:28:01 -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 j21shpFuTY0A for ; Sun, 21 Jul 2019 14:27:59 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D373120098 for ; Sun, 21 Jul 2019 14:27:59 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v18so35504216ljh.6 for ; Sun, 21 Jul 2019 14:27:59 -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=5gXj49UyR+xWgB++1xgsgoWyKzYSakEGGSMFl7Y4R28=; b=DtLE6tEUiZyENReRxahl+Zr16KulBGR8mw3rGpol5apmOrVCCkr26ykaEztTTHSHNa i5xW5krav3buv47V4CGlaN9Aq5fNJmoe7jbY5VqdspUav09OugP1tRxWhRp8QGKP0HaO D5PgINieqadu+VttBSwAgy+JVi8BekXk5t8S0RlRN8LKh5sp95MOSc2fdOPkHKpT9ZTA 6SFBzYGnwLH+DMB81IjqhFQwcRU5+IVAIGsut5JYX8oQsQxc+BHd79wXh1cM5j6UC2Ka 8r7+Io+OzRoYYsmY7Hbi9zl7GU7FYrWE2+u3V0jGgc/QkjOXEzTQT9zTbPlV5uzrYdaw JXKQ== 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=5gXj49UyR+xWgB++1xgsgoWyKzYSakEGGSMFl7Y4R28=; b=dgfhVNlBLfj/qIr/XKZY+N4X9nLq0VWDSBHxEkmtc8/Cq5d9tub5GnHLCPPZ7SMkNe bNGeugeQE8m2wFsf5MO/ORqDm2Ozyjd1y4O1VZnQBxYk3LsqkQFhaEPjxfWelWkLJgB7 1UOr/Ve7+OYfRb1gNCcz6UERTi71i44q7AdveFs4V5H0kTWT1hyIq066wjXl+Bxwh/tQ jCDVyYD5Fuv7aTV1XqwpIr6MOvaoTTJuzZGUFb95SEI/wbUjQlLFvhndI13CC4GrUW+n gubSVlBpJiVq0CRDk02NS7nvpd2idrKgoBUNh27ne/LkPcvbsfrrPduJcRbB7EHYE6PQ yGPw== X-Gm-Message-State: APjAAAWeWkeuCjDxnxVAm2/fq/N4wEBtx2eCFlGoyXdUVYRYFbYdglm7 DuGNuAZ+w9GXNrWWRqXG/BvwjrPkLPK1tyZdlTU= X-Google-Smtp-Source: APXvYqymftpSuzHAeFx1hi/vjQJb4SsAinecf8E5xgfG0MoT6+8MBxMUnwscrR49fVBGpANHghbBmoN+MOM/8XnNk1Y= X-Received: by 2002:a2e:8195:: with SMTP id e21mr32765063ljg.62.1563744477388; Sun, 21 Jul 2019 14:27:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 21 Jul 2019 14:27:46 -0700 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="0000000000001824d3058e37a298" Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 21 Jul 2019 21:28:02 -0000 --0000000000001824d3058e37a298 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Justin A few use cases that highlight how the world is different now than it was when OAuth 2.0 was developed would help participants understand why changes are needed, and also provide a reference for comparing and contrasting different approaches. One of my first comments is why the client is starting off making calls to the AS. There are times when the AS is not known for a given resource. Why not allow starting at resource? On Tue, Jul 9, 2019 at 12:48 PM Justin Richer wrote: > I have requested time to present Transactional Authorization (the XYZ > project) at the Montreal meeting in a couple weeks. Ahead of that, I=E2= =80=99ve > uploaded a new version of the spec: > > https://tools.ietf.org/html/draft-richer-transactional-authz-02 > > Additionally, I=E2=80=99ve updated the writeup and examples on https://oa= uth.xyz/ > > I plan to be in Montreal for the whole week, and I=E2=80=99ve requested f= rom the > chairs that I present during the Tuesday session due to limited > availability of some key WG members on Friday. > > =E2=80=94 Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000001824d3058e37a298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Justin

A few use cases that highlig= ht how the world is different now than it was when OAuth 2.0 was developed = would help participants understand why changes are needed, and also provide= a reference for comparing and contrasting different approaches.
=
One of my first comments is why the client is starting off m= aking calls to the AS. There are times when the AS is not known for a given= resource. Why not allow starting at resource?

On Tue, = Jul 9, 2019 at 12:48 PM Justin Richer <jricher@mit.edu> wrote:
I have requested time to present Transactional Authorization (the XYZ proje= ct) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve = uploaded a new version of the spec:


Additionally, I=E2=80=99ve updated the writeup and examples on https://oauth.xyz/=C2=A0

I plan to be in Montreal for the whole week, and I=E2=80=99ve requeste= d from the chairs that I present during the Tuesday session due to limited = availability of some key WG members on Friday.=C2=A0

=E2=80=94 Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000001824d3058e37a298-- From nobody Sun Jul 21 15:13:29 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 EAB4D12001E; Sun, 21 Jul 2019 15:13:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, The IESG , Rifaat Shekh-Yusef , draft-ietf-oauth-token-exchange@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156374720089.8834.14673424227290960945.idtracker@ietfa.amsl.com> Date: Sun, 21 Jul 2019 15:13:20 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Token Exchange' to Proposed Standard (draft-ietf-oauth-token-exchange-19.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 22:13:21 -0000 The IESG has approved the following document: - 'OAuth 2.0 Token Exchange' (draft-ietf-oauth-token-exchange-19.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ Technical Summary: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The specification extends the scope of the Authorization Server (AS) to act as an STS to allow the AS to exchange one token for another. The working group thinks that this is a useful Standards Track document. Working Group Summary: The WG document is the result of the merge of two individual documents that tried to address this issue of token exchange: draft-jones-oauth-token-exchange and draft- campbell-oauth-sts. The scope of the first few revisions of the document was limited, and there was a long discussion of addressing a Token Chaining use case: https://mailarchive.ietf.org/arch/msg/oauth/pQRiMz0NjwcAG9Jazm8Aex40UX8/?qid=e6b492516cfa24bebbf8996009413d62 The WG document was extended to address the Token Chaining use case. The individual and WG documents were reviewed by a large number of participants, with lively and long discussions on the mailing list and during the WG meetings. One participant, Denis (denis.ietf@free.fr), raised some privacy & security concerns with the WG document, which was not shared by the rest of the group. Denis was encouraged by the group to write a draft on the subject to allow for a better and clear understanding of his concerns, or discuss the security issues in the context of the OAuth Security Topics document. Document Quality: The document has been implemented by Salesforce, Microsoft, Box, Indigo IAM, Unity IdM, and partial implementation by RedHat. https://medium.com/box-developer-blog/introducing-token-exchange-for-box-platform-3dcf7ab891b8 https://indigo-dc.gitbooks.io/iam/content/doc/user-guide/oauth_token_exchange.html http://www.unity-idm.eu/documentation/unity-2.1.0/manual.html#_token_exchange http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Roman Danyliw. From nobody Sun Jul 21 15:53: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 CEA541200C7 for ; Sun, 21 Jul 2019 15:53:19 -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=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 M-6SyPZZqfIu for ; Sun, 21 Jul 2019 15:53:17 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCA912001E for ; Sun, 21 Jul 2019 15:53:16 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LMrGVK018744; Sun, 21 Jul 2019 18:53:16 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6LMrGVK018744 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563749596; bh=SrXR4bTPVqK68QHko1/MAnf2lB5Klmpn+JO99ztOZmk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UzE2BIdUmo+NDEdfg/m+I1QANyGpzqsKwX670diPCmIVGF8kGTtKUT8b33KzlRmxt rN1EC9BNvbVX+OGKuyYCXY2FZQpOfjuBrlh42B8lAAD+teywxuCZVBKNP1ncoZu9j2 XqfMpjNyrsHs/wQ7zFzjdW6Otijsyqe3r8dDm0VE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6LMrBff031066; Sun, 21 Jul 2019 18:53:12 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Sun, 21 Jul 2019 18:53:11 -0400 From: Roman Danyliw To: "'Brian Campbell'" CC: "'oauth@ietf.org'" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgA09hCAAAXZ8EAAv6ecgA== Date: Sun, 21 Jul 2019 22:53:10 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33DEA6Cmarchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 22:53:20 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33DEA6Cmarchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZSBpbiAtMDMuICBUaGUgaXRlbSBiZWxv dyBpcyB0aGUgb25seSB0aGluZyB0aGF0IHJlbWFpbnMgb3V0c3RhbmRpbmcuDQoNClRoYW5rcywN ClJvbWFuDQoNCg0KRnJvbTogUm9tYW4gRGFueWxpdw0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3 LCAyMDE5IDY6MDUgUE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb20+DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEFEIFJl dmlldzogZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNCg0KRnJvbTog QnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAxNywgMjAxOSA0OjM1IFBNDQpUbzogUm9tYW4gRGFueWxpdyA8cmRk QGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJh ZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNCltzbmlwXQ0KDQooMikgU2Vj dGlvbiAyLjIuICBpbiB0aGUgc2VudGVuY2UgIlRvIHRoZSBleHRlbnQgcG9zc2libGUsIHdoZW4g aXNzdWluZyBhY2Nlc3MgdG9rZW5zLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGFk YXB0IHRoZSBzY29wZSB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggYW4gYWNjZXNzIHRva2VuIHRvIHRo ZSB2YWx1ZSB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSBpcyBhYmxlIHRvIHByb2Nlc3MgYW5kIG5l ZWRzIHRvIGtub3ciOg0KDQotLSAgaXMgdGhpcyBsYW5ndWFnZSBzdWdnZXN0aW5nIHRoYXQgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGlzIG1vZGlmeWluZyB0aGUgc2NvcGUgdmFsdWUgYmFzZWQg b24gdGhlIHJlc291cmNlIGl0IHNlZXM/ICBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCAi YWRhcHQiIG1lYW5zLCBlc3BlY2lhbGx5IGluIHJlbGF0aW9uIHRvIHRoZSBpbXByb3ZlZCBzZWN1 cml0eSBhbmQgcHJpdmFjeSB0aGUgc3Vic2VxdWVudCBzZW50ZW5jZSBzdWdnZXN0cy4NCg0KUGVy aGFwcyAiYWRhcHQiIHdhc24ndCB0aGUgYmVzdCBjaG9pY2Ugb2Ygd29yZCBidXQgaXQncyBtZWFu dCB0byBzYXkgdGhhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRoIHN1ZmZpY2llbnQgdW5k ZXJzdGFuZGluZyBvZiB3aGF0IHNjb3BlcyBhcmUgYXBwbGljYWJsZSB0byB3aGF0IHJlc291cmNl cyAod2hpY2ggd29uJ3QgYWx3YXlzIGJlIHRoZSBjYXNlIG9yIGV2ZW4gcG9zc2libGUgYnV0IHNv bWV0aW1lcykgY291bGQgbGltaXQgdGhlIHNjb3BlIGFzc29jaWF0ZWQgd2l0aCBhbiBhY2Nlc3Mg dG9rZW4gKGRvd25zY29waW5nIHJlYWxseSkgdG8gb25seSB0aGUgc2NvcGUgdGhhdCBpcyBhcHBs aWNhYmxlIHRvIHRoZSByZXNvdXJjZS4NCg0KU29tZSBvZiB0aGUgZXhhbXBsZXMgKGZpZ3VyZXMg MiAtIDYpIGF0dGVtcHQgdG8gc2hvdywgYW1vbmcgb3RoZXIgdGhpbmdzLCBhIGh5cG90aGV0aWNh bCBjYXNlIG9mIGhvdyB0aGlzIG1pZ2h0IGdvIGRvd24uDQoNCkluIEZpZ3VyZSAyIHRoZSBpbml0 aWFsIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0aGF0J3MgYXBwcm92ZWQgaGFzIHNjb3BlIG9mIGNh bGVuZGFyICYgY29udGFjdHMgYW5kIHJlc291cmNlcyBodHRwczovL2NvbnRhY3RzLmV4YW1wbGUu Y29tLyAmIGh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLw0KDQpBIHN1YnNlcXVlbnQgYWNjZXNzIHRv a2VuIHJlcXVlc3QgKEZpZ3VyZSAzKSBoYXMgcmVzb3VyY2UgaHR0cHM6Ly9jYWwuZXhhbXBsZS5j b20vIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBzY29wZSAoRmlndXJlIDQpIGlzICJhZGFw dGVkIiB0byB0aGF0IHJlc291cmNlIHRvIGJlIG9ubHkgY2FsZW5kYXINCg0KQW5vdGhlciBzdWJz ZXF1ZW50IGFjY2VzcyB0b2tlbiByZXF1ZXN0IChGaWd1cmUgNSkgaGFzIHJlc291cmNlIGh0dHBz Oi8vY29udGFjdHMuZXhhbXBsZS5jb20vIGFuZCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBzY29w ZSAoRmlndXJlIDYpIGlzIGRvd25zY29wZWQgYmFzZWQgb24gdGhhdCByZXNvdXJjZSB0byBiZSBv bmx5IGNvbnRhY3RzDQoNCldvdWxkIGl0IGJlIGVhc2llciB0byB1bmRlcnN0YW5kIGlmIHRoZSB3 b3JkICJkb3duc2NvcGUiIHdhcyB1c2VkIHJhdGhlciB0aGFuICJhZGFwdCI/DQoNCltSb21hbl0g VXNpbmcg4oCcZG93bnNjb3Bl4oCdIGRvZXMgd29yayBmb3IgbWUuICBJdCBjYXB0dXJlcyB0aGF0 IHRoZSBzZXJ2ZXIgaXMgZ29pbmcgdG8gcmVkdWNlIHRoZSBzY29wZSAoYW5kIGNlcnRhaW5seSBu b3QgZXhwYW5kIGl0KS4NCg0KDQotLSAoRGVwZW5kaW5nIG9uIHRoZSBhYm92ZSkgSXMgdGhlcmUg YSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGhlcmUgZm9yIHRoZSBzZXJ2ZXIgcmVsYXRpdmUgdG8g Y29uZmlkZW50aWFsIHNjb3BlIHZhbHVlcyBhbmQgaG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/ DQoNCkknbSBub3Qgc3VyZSwgdG8gYmUgaG9uZXN0LiBEb3duc2NvcHBpbmcgd2hlbiBwb3NzaWJs ZSBhbmQgdG8gdGhlIGV4dGVudCBwb3NzaWJsZSBpcyB1c3VhbGx5IGEgZ29vZCBpZGVhIChsZWFz dCBwcml2aWxlZ2UgYW5kIGFsbCB0aGF0KSBidXQgSSB0aGluayBtYXliZSBJJ20gbWlzc2luZyB5 b3VyIHBvaW50L3F1ZXN0aW9uLg0KDQpbUm9tYW5dIFllcywgbGVhc3QgcHJpdmlsZWdlIHdhcyBw YXJ0IG9mIGl0IGFuZCBJIHRoaW5rIHRoZSB0ZXh0IGFib3ZlIGdldHMgYXQgaXQuICBIb3dldmVy LCB0aGUgb3RoZXIgcGFydCBpcyB0aGUgcmVsYXRpb25zaGlwIHdpdGggdGhlIG5leHQgc2VudGVu Y2UgaW4gdGhlIHBhcmFncmFwaCwg4oCcVGhpcyBmdXJ0aGVyIGltcHJvdmVzIHByaXZhY3kgYXMg c2NvcGUgdmFsdWVzIGdpdmUgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IHNlcnZpY2VzIHRoZSByZXNv dXJjZSBvd25lciB1c2VzIGFuZCBpdCBpbXByb3ZlcyBzZWN1cml0eSBhcyBzY29wZSB2YWx1ZXMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGRhdGHigJ0uICBJZiB0aGUgaW5pdGlhbCByZXF1ZXN0 IHdhcyBub3Rpb25hbGx5IGEgc2NvcGUgb2Yg4oCcYWxsIHRoZSBob3VzZXMgb24gdGhlIGJsb2Nr 4oCdLCBidXQgdGhlIHNlcnZlciBrbmV3IHRoYXQgdGhpcyByZXF1ZXN0IHdhcyB0b28gYnJvYWQg YW5kIGRvd24tc2NvcGVkIHRvIOKAnG9ubHkgdGhlIGNvcm5lciBob3VzZeKAnSwgd291bGRu4oCZ dCB0aGlzIGFjdHVhbGx5IGJlIHdvcnNlIGZvciBwcml2YWN5PyAgSSBhbHNvIGRvbuKAmXQgZm9s bG93IGhvdyByZWR1Y2luZyB0aGUgc2NvcGUgaW1wYWN0cyBjb25maWRlbnRpYWwgZGF0YS4NCg0K DQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B33DEA6Cmarchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBCcmlhbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyBmb3IgdGhlIHVwZGF0ZSBpbiAtMDMuJm5ic3A7IFRoZSBpdGVtIGJlbG93IGlzIHRoZSBv bmx5IHRoaW5nIHRoYXQgcmVtYWlucyBvdXRzdGFuZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9tYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gUm9tYW4gRGFueWxpdw0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAx NywgMjAxOSA2OjA1IFBNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYt b2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxs IFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPm1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKdWx5IDE3LCAyMDE5IDQ6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIERhbnlsaXcgJmx0 OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmciPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0 LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltzbmlwXTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KDIpIFNlY3Rpb24gMi4yLiZuYnNwOyBpbiB0aGUgc2VudGVuY2UgJnF1b3Q7VG8gdGhlIGV4 dGVudCBwb3NzaWJsZSwgd2hlbiBpc3N1aW5nIGFjY2VzcyB0b2tlbnMsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBzaG91bGQgYWRhcHQgdGhlIHNjb3BlIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCBh biBhY2Nlc3MgdG9rZW4gdG8gdGhlIHZhbHVlIHRoZSByZXNwZWN0aXZlIHJlc291cmNlIGlzIGFi bGUgdG8gcHJvY2VzcyBhbmQgbmVlZHMNCiB0byBrbm93JnF1b3Q7Ojxicj4NCjxicj4NCi0tJm5i c3A7IGlzIHRoaXMgbGFuZ3VhZ2Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBpcyBtb2RpZnlpbmcgdGhlIHNjb3BlIHZhbHVlIGJhc2VkIG9uIHRoZSByZXNvdXJjZSBp dCBzZWVzPyZuYnNwOyBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCAmcXVvdDthZGFwdCZx dW90OyBtZWFucywgZXNwZWNpYWxseSBpbiByZWxhdGlvbiB0byB0aGUgaW1wcm92ZWQgc2VjdXJp dHkgYW5kIHByaXZhY3kgdGhlIHN1YnNlcXVlbnQgc2VudGVuY2Ugc3VnZ2VzdHMuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJo YXBzICZxdW90O2FkYXB0JnF1b3Q7IHdhc24ndCB0aGUgYmVzdCBjaG9pY2Ugb2Ygd29yZCBidXQg aXQncyBtZWFudCB0byBzYXkgdGhhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRoIHN1ZmZp Y2llbnQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IHNjb3BlcyBhcmUgYXBwbGljYWJsZSB0byB3aGF0 IHJlc291cmNlcyAod2hpY2ggd29uJ3QgYWx3YXlzIGJlIHRoZSBjYXNlIG9yIGV2ZW4gcG9zc2li bGUgYnV0IHNvbWV0aW1lcykNCiBjb3VsZCBsaW1pdCB0aGUgc2NvcGUgYXNzb2NpYXRlZCB3aXRo IGFuIGFjY2VzcyB0b2tlbiAoZG93bnNjb3BpbmcgcmVhbGx5KSB0byBvbmx5IHRoZSBzY29wZSB0 aGF0IGlzIGFwcGxpY2FibGUgdG8gdGhlIHJlc291cmNlLiZuYnNwOw0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgb2YgdGhlIGV4YW1w bGVzIChmaWd1cmVzIDIgLSA2KSBhdHRlbXB0IHRvIHNob3csIGFtb25nIG90aGVyIHRoaW5ncywg YSBoeXBvdGhldGljYWwgY2FzZSBvZiBob3cgdGhpcyBtaWdodCBnbyBkb3duLg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIEZpZ3VyZSAy IHRoZSBpbml0aWFsIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0aGF0J3MgYXBwcm92ZWQgaGFzIHNj b3BlIG9mIGNhbGVuZGFyICZhbXA7IGNvbnRhY3RzIGFuZCByZXNvdXJjZXMNCjxhIGhyZWY9Imh0 dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIj5odHRwczovL2NvbnRhY3RzLmV4YW1wbGUuY29t LzwvYT4gJmFtcDsgPGEgaHJlZj0iaHR0cHM6Ly9jYWwuZXhhbXBsZS5jb20vIj4NCmh0dHBzOi8v Y2FsLmV4YW1wbGUuY29tLzwvYT4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkEgc3Vic2VxdWVudCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCAoRmln dXJlIDMpIGhhcyByZXNvdXJjZSA8YSBocmVmPSJodHRwczovL2NhbC5leGFtcGxlLmNvbS8iPg0K aHR0cHM6Ly9jYWwuZXhhbXBsZS5jb20vPC9hPiBhbmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4g c2NvcGUgKEZpZ3VyZSA0KSBpcyAmcXVvdDthZGFwdGVkJnF1b3Q7IHRvIHRoYXQgcmVzb3VyY2Ug dG8gYmUgb25seSBjYWxlbmRhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBzdWJzZXF1ZW50IGFjY2VzcyB0b2tlbiBy ZXF1ZXN0IChGaWd1cmUgNSkgaGFzIHJlc291cmNlDQo8YSBocmVmPSJodHRwczovL2NvbnRhY3Rz LmV4YW1wbGUuY29tLyI+aHR0cHM6Ly9jb250YWN0cy5leGFtcGxlLmNvbS88L2E+IGFuZCB0aGUg aXNzdWVkIGFjY2VzcyB0b2tlbiBzY29wZSAoRmlndXJlIDYpIGlzIGRvd25zY29wZWQgYmFzZWQg b24gdGhhdCByZXNvdXJjZSB0byBiZSBvbmx5IGNvbnRhY3RzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIGl0IGJlIGVhc2llciB0byB1 bmRlcnN0YW5kIGlmIHRoZSB3b3JkICZxdW90O2Rvd25zY29wZSZxdW90OyB3YXMgdXNlZCByYXRo ZXIgdGhhbiAmcXVvdDthZGFwdCZxdW90Oz8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5bUm9tYW5dIFVzaW5nIOKAnGRvd25zY29wZeKAnSBkb2VzIHdvcmsgZm9yIG1lLiZu YnNwOyBJdCBjYXB0dXJlcyB0aGF0IHRoZSBzZXJ2ZXIgaXMgZ29pbmcgdG8gcmVkdWNlIHRoZSBz Y29wZSAoYW5kIGNlcnRhaW5seSBub3QgZXhwYW5kIGl0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tIChEZXBlbmRpbmcgb24g dGhlIGFib3ZlKSBJcyB0aGVyZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gaGVyZSBmb3IgdGhl IHNlcnZlciByZWxhdGl2ZSB0byBjb25maWRlbnRpYWwgc2NvcGUgdmFsdWVzIGFuZCBob3cgdGhl eSBtaWdodCBiZSBtb2RpZmllZD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3VyZSwgdG8gYmUgaG9uZXN0LiBEb3du c2NvcHBpbmcgd2hlbiBwb3NzaWJsZSBhbmQgdG8gdGhlIGV4dGVudCBwb3NzaWJsZSBpcyB1c3Vh bGx5IGEgZ29vZCBpZGVhIChsZWFzdCBwcml2aWxlZ2UgYW5kIGFsbCB0aGF0KSBidXQgSSB0aGlu ayBtYXliZSBJJ20gbWlzc2luZyB5b3VyIHBvaW50L3F1ZXN0aW9uLg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltSb21hbl0gWWVzLCBsZWFzdCBwcml2aWxlZ2Ugd2FzIHBhcnQgb2YgaXQgYW5kIEkgdGhp bmsgdGhlIHRleHQgYWJvdmUgZ2V0cyBhdCBpdC4mbmJzcDsgSG93ZXZlciwgdGhlIG90aGVyIHBh cnQgaXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoDQogdGhlIG5leHQgc2VudGVuY2UgaW4gdGhlIHBh cmFncmFwaCwg4oCcVGhpcyBmdXJ0aGVyIGltcHJvdmVzIHByaXZhY3kgYXMgc2NvcGUgdmFsdWVz IGdpdmUgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IHNlcnZpY2VzIHRoZSByZXNvdXJjZSBvd25lciB1 c2VzIGFuZCBpdCBpbXByb3ZlcyBzZWN1cml0eSBhcyBzY29wZSB2YWx1ZXMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGRhdGHigJ0uJm5ic3A7IElmIHRoZSBpbml0aWFsIHJlcXVlc3Qgd2FzIG5v dGlvbmFsbHkgYQ0KIHNjb3BlIG9mIOKAnGFsbCB0aGUgaG91c2VzIG9uIHRoZSBibG9ja+KAnSwg YnV0IHRoZSBzZXJ2ZXIga25ldyB0aGF0IHRoaXMgcmVxdWVzdCB3YXMgdG9vIGJyb2FkIGFuZCBk b3duLXNjb3BlZCB0byDigJxvbmx5IHRoZSBjb3JuZXIgaG91c2XigJ0sIHdvdWxkbuKAmXQgdGhp cyBhY3R1YWxseSBiZSB3b3JzZSBmb3IgcHJpdmFjeT8mbmJzcDsgSSBhbHNvIGRvbuKAmXQgZm9s bG93IGhvdyByZWR1Y2luZyB0aGUgc2NvcGUgaW1wYWN0cyBjb25maWRlbnRpYWwgZGF0YS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B33DEA6Cmarchand_-- From nobody Sun Jul 21 19:22: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 199B3120096 for ; Sun, 21 Jul 2019 19:22:27 -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 LLAQbT9i9Qw1 for ; Sun, 21 Jul 2019 19:22:26 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D9912003F for ; Sun, 21 Jul 2019 19:22:25 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id w24so18439202plp.2 for ; Sun, 21 Jul 2019 19:22:25 -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=oiJl3PasdkXtlQrTNplXhNcqXo502D5uQ/wDoYq0/dY=; b=fv+l5M1Ek1UjU4zEcOSyKRiAubjdfiXrs0u76MsEoeqrFQTc2WLr0mgzXARo+3SICa HLv9jfcplmAGQtoHRoCBB3SJZDMJg8mWsAifrUU170m07Fl2+ieq4gDfkpu9/O7pZWGg E4EaHVpdLGYu0/jN6c4S8MmxUtPJOsrTooyADW+vFr40OWgXt8To18VIWLcuHh9+etrj wn7WGnQlzuYd68+kGMCUPrVYTZgojigFNqKcp8/Rq9K6brWSmumrPO6ecwr0qA/4iTVe dIc4enySQ+Kva+HL2S6Dkb2AxPUqdeDejcjC4VbpnMjTaGNpuUgDeSts/vmUjTfCmneF bJ4A== 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=oiJl3PasdkXtlQrTNplXhNcqXo502D5uQ/wDoYq0/dY=; b=MdSJlZERoRkZtnP6oBR1vUhCGfCJfyltv6CoGmr/0+mc3+ac33l0XpfT+BMHPx68xs 9RWEJrInyb63wFvdCIBAsm3OsJWCKPsmcqt+FnKZry8AKHUOV21PpBjCsxUXj2dxgfqB ImRa9Oirj8shdvuEed2fprd0UxOFT8Ez52oGOqKxIiqKAQSe+7E5R12cFanB+wF8+/Y+ P0pBFj3mQ2kPH03yH6Oiac5vwnsaqpW+Y+I6W1aj+w/DqYu1wSXrklpPXDxpWGMAG2U5 FVK7YfdwfQGDfp66PYYNO0B9H6SJ+KFA6KpujHfRudtQw5x+32XFw2zspr3Y5TLNLPZC jYkQ== X-Gm-Message-State: APjAAAWIwRQYyqSbAEKOim/XSNhOVTRwGUw75BkG76Q6T0pE/wILebIK QsmxvklsOWR9G+tjK51JPsFEDucjJBk3ZeTTSLnkF1y46go= X-Google-Smtp-Source: APXvYqwjOME93EKwh1fzc4MDPUoEknqcQpCS1CB06p0NJLQRw7GQ/i+r1iga1RL/a88wLWOdWue1ManXccjMiBpEhqE= X-Received: by 2002:a17:902:4401:: with SMTP id k1mr49068451pld.193.1563762145088; Sun, 21 Jul 2019 19:22:25 -0700 (PDT) MIME-Version: 1.0 From: Leo Tohill Date: Sun, 21 Jul 2019 22:22:16 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000002bd7f5058e3bbfab" Archived-At: Subject: [OAUTH-WG] not using oauth for this architecture in oauth for 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, 22 Jul 2019 02:22:27 -0000 --0000000000002bd7f5058e3bbfab Content-Type: text/plain; charset="UTF-8" The advice for the architectural pattern "JavaScript served from a common domain as the resource server" reads: "For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the domain of the API (resource server), it may be a better decision to avoid using OAuth entirely, and instead use session authentication to communicate directly with the API." I can agree that session authentication could be best here, but how was the user authenticated in order to create the trusted session? Wouldn't that/shouldn't that still use an oauth flow to collect credentials? We need to be clear on the distinction between browser based apps that hold the token(s) in the browser space, vs. those that don't. I agree that with this "common domain" architecture, the tokens should not be held in the browser, but it doesn't follow that oauth should not be used at all. Leo --0000000000002bd7f5058e3bbfab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The advice for the architectural pattern "JavaSc= ript served from a common domain as the resource server"=C2=A0 reads:<= br>

"For simple system architectures, such as= when the JavaScript application is served
from a domain that can share = cookies with the domain of the API (resource server), it
may be a better= decision to avoid using OAuth entirely, and instead use session
authent= ication to communicate directly with the API."

I can agree that session authentication could be best here, but how was t= he user authenticated in order to create the trusted session?=C2=A0 Wouldn&= #39;t that/shouldn't that still use an oauth flow to collect credential= s?

We need to be clear on the distinction between = browser based apps that hold the token(s) in the browser space, vs. those t= hat don't.=C2=A0 I agree that with this
"common domain" a= rchitecture, the tokens should not be held in the browser, but it doesn'= ;t follow that oauth should not be used at all.

Leo


--0000000000002bd7f5058e3bbfab-- From nobody Sun Jul 21 19:22: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 49B111201B7 for ; Sun, 21 Jul 2019 19:22:44 -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 RuN8scfb3eK9 for ; Sun, 21 Jul 2019 19:22:42 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A41612013F for ; Sun, 21 Jul 2019 19:22:42 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id f5so8074751pgu.5 for ; Sun, 21 Jul 2019 19:22:42 -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=iGetok8ctiKf12/L+m9L/4O8NIon1qMpr4wdhZYtoW8=; b=qaEjwM5KdPs/dv0A2qKzI6/hqkl8ZsiWVl0AdoWc9pc33SNs9/EEzeJWz5/JXD05Ay AIxPMCA4ZFJTaHPZt6YkNG6uivh/UOyghAP7n6RCBpFpP1FcBLuE8YUdUYayBJrE2STw aOuL7+4H/OYT0D74yEnSjd5lcVKPpc8BJiaYALN4Cn1TbJAIx2nHnqp5tw3jg0salplE 6c/vqdlAg8s1TM5sKnzNjkM2mLL7TpuhN6BZEauVeSwIU+Xqt7OowXoF8FMbSOOpNEnL hVBsjYFQaWVvs2pfZgjGs3CpaKpbyRfoipBZ0axm/87hc909W4OBsF7yYbJGDhZ/tk7O UCfA== 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=iGetok8ctiKf12/L+m9L/4O8NIon1qMpr4wdhZYtoW8=; b=XDtWoJS097KG39cG2PSnsyzvAesE26YwNi87IFLsKtYALB1vd82S3YjbeGySZc9lJi WJnS+DJyqKbcp+IiLhk78LmxwuiDFk8UjSeYMXBc873oYOdzsGnnLNnPBRZvJl4qlsJ2 ugmbLOCf7wjyfs5iYMJXoZh4h/AxUVoKZm8Vj+Yez0fQ3oe4Kb1jRQpd17Q1W5+Kfdts JJlP5ckZ+MQK12pqki87suTKCX661NutA7dTFEjVS31nIzYmeeNpBh8h3jnBKWYC9Q6e XXwdrEIqDVyp4bZkyiRzlLsKgwt7rUJtBzqDiCKy4amX/LqY6qzwHAgaCDgbRATI4ebD tDMQ== X-Gm-Message-State: APjAAAVkPGSLgBF6fcut2T4qgc/xBSCUxvQzgjmO9IFh4DJtRRaa+s3x QTLHCDb0n4y0REY3Py1VnAohg5KXUgnXzzVHp1w= X-Google-Smtp-Source: APXvYqx96uIaG8uSdafB+mpUReoEfex1Iq5Q170Jd2r9YVyoIUHMGLDYrRCoMa0tUFEEqhX8+haZe7RZDeXZmsATCV4= X-Received: by 2002:a63:1d4:: with SMTP id 203mr51718955pgb.441.1563762161774; Sun, 21 Jul 2019 19:22:41 -0700 (PDT) MIME-Version: 1.0 References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> <170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com> In-Reply-To: <170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com> From: Leo Tohill Date: Sun, 21 Jul 2019 22:22:32 -0400 Message-ID: To: Brock Allen Cc: David Waite , OAuth WG Content-Type: multipart/alternative; boundary="0000000000002a73ed058e3bc083" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 02:22:50 -0000 --0000000000002a73ed058e3bc083 Content-Type: text/plain; charset="UTF-8" I left out Okta (how could I?) - it supports a refresh token expiration, but I couldn't find doc on the details. On Sun, Jul 21, 2019 at 10:44 AM Brock Allen wrote: > > IdentityServer allows a choice of behavior on refresh token expiration > time. It can have a absolute expiration time, or use a sliding window. > > FWIW, in addition, those can be used together -- sliding & absolute. > Finally, refresh tokens can be re-use or one-time use only. These are all > per-client settings. > > -Brock > > --0000000000002a73ed058e3bc083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I left out Okta (how could I?)= =C2=A0 - it supports a refresh token expiration, but I couldn't find do= c on the details.=C2=A0


On Sun, Jul 21, 2019 at 10= :44 AM Brock Allen <brockallen@gmail.com> wrote:
=20 =20 =20 =20 =20 >=C2=A0IdentityServer allows a choice of behavior on refresh token expiratio= n time. It can have a absolute expiration time, or use a sliding window.

FWIW, in addition, those can be used together -- slidin= g & absolute. Finally,=C2=A0refresh tokens can be re-use or one-time use only. These are all= per-client settings.

= -Brock

=20
--0000000000002a73ed058e3bc083-- From nobody Sun Jul 21 23:14: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 8059012013F for ; Sun, 21 Jul 2019 23:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 5OuVbX2otUzh for ; Sun, 21 Jul 2019 23:14:37 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8279812013C for ; Sun, 21 Jul 2019 23:14:35 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id t8so27776139qkt.1 for ; Sun, 21 Jul 2019 23:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=cookQ3nQI17uH2eyNeW09E1Dh48DqAomDRYwZzuVBBw=; b=uo0ObeCyfjXHeYYv7zl2oDrPIRAGTth8/dOnOxJxk6PsWvHkY6TGy0kS2yndhjZ8w1 xyQHRLqdKJe7XmvxPxx/3SDQp2vxlVCpasqw+DU2ATjE6U3d67sryjl9ysEnH/oxOkDy DPbLautl9diLalSK8wwqxZy2r1vVCCHMFY5i9UNylT1Afs9/mcnx3+eAHCbq3eYy5/xa jTWXNu08hf0V1n2/3DE68mkI28xQK6YIwY8oWCV5aYm8CAgucMtX8uWq3stBzZkLCa2I WGXBdAGtaRVUnfQdTfbZNHdOkhUit9zbSXNLiFnJMdHgfF+3IZZQe2SYzx9wM8ha0Ypl WhrQ== 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:date:message-id:subject:to; bh=cookQ3nQI17uH2eyNeW09E1Dh48DqAomDRYwZzuVBBw=; b=KqN8/jdxShGv74mlphQvm/3xtCHwH8phxhlzxjO5ytadufhvZaK648dcHMgghkVlEK B8vNhuIa0NciP9vkPuO6QEZKi45L32sSEi5gDBJ/G06VMwU7rLSZxC/2TC5b2TDJ8v3Y lYa3SnrrAe4D2j4ho8ZEYEjgUZhwOewl+Hcsh9CJz3nSGcgOzvYatU7howWqh2AELmO5 UySHOQ2xwwdd4xNNCxBP3zauP0286qOMIw1oP65/XCmI8uvxjC7OblA0SYmIv1wr2blJ DCzJM/V2AcHTJP76a/gl7/HlbeduVAiukvgDvADedweGTkpqVB7ir6D2KJA/6lG/Jauq 2myQ== X-Gm-Message-State: APjAAAW+4jcJG5sh+rgB+4tJ/t95jP5XeaYPqsnDpLGLUNH+wf/lMkTy nl1imHx0hsAh0XXx4Lsugvmhx3UR71KDl4W8LIf3M8c= X-Google-Smtp-Source: APXvYqz60+kyqLXOIr/+GYp94X196y5+hZ1kIKjoNNu++/OICRdsGWlJKpNfkdd5zejsgeQ+hZIwKdOyMVi45e+ysYc= X-Received: by 2002:a37:a6cf:: with SMTP id p198mr44143894qke.259.1563776074150; Sun, 21 Jul 2019 23:14:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jul 2019 23:14:33 -0700 From: Dominick Baier MIME-Version: 1.0 Date: Sun, 21 Jul 2019 23:14:33 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000688ac5058e3efd63" Archived-At: Subject: [OAUTH-WG] Feedback on OAuth for 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, 22 Jul 2019 06:14:40 -0000 --000000000000688ac5058e3efd63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Just read the spec - good to see the progress. Some feedback: I am yet undecided if I like the categorisation of the =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitely want to distinguish between applications only accessing same-site back-end services and =E2=80=9Cothers= =E2=80=9D. Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic applicatio= n server=E2=80=9D should be handled differently - they are deployment details and should not decide on the application security architecture. Also not sure how realistic it is to deploy a typical applications solely from e.g. a CDN. But I don=E2=80=99= t have the right answer wrt to categories right now. 6.1. Apps Served from a Common Domain as the Resource Server > OAuth and OpenID Connect provide very little benefit in this deployment scenario, so it is recommended to reconsider whether you need OAuth or OpenID Connect at all in this case. I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access. Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading. 6.2. Apps Served from a Dynamic Application Server I have a .NET sample for that https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore= 21/BFF And a blog post https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit= h-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ 9.7 . Content-Security Policy A browser-based application that wishes to use either long-lived refresh tokens or privileged scopes SHOULD restrict its JavaScript execution to a set of statically hosted scripts via a Content Security Policy ([CSP2 ]) or similar mechanism. I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled. Thanks for doing this work! =E2=80=94=E2=80=94=E2=80=94 Dominick --000000000000688ac5058e3efd63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hey,= =C2=A0

<= /div>
Just read th= e spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisat= ion of the =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitel= y want to distinguish between applications only accessing same-site back-en= d services and =E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic appli= cation server" and =E2=80=9Cstatic application server=E2=80=9D should = be handled differently - they are deployment details and should not decide = on the application security architecture. Also not sure how realistic it is= to deploy a typical applications solely from e.g. a CDN. But I don=E2=80= =99t have the right answer wrt to categories right now.

6.1.=C2=A0 Apps Served from a Common Domain as the Resource Server

> OAuth = and OpenID Connect provide very little benefit in this
=C2=A0 =C2=A0deployment scenario, so it is recommended to recons= ider whether you
=C2=A0 =C2=A0need OAuth or = OpenID Connect at all in this case.

I think you are mixing authentication and API a= ccess here. Depending on application scenario it makes a lot of sense to us= e OIDC - but rely on the resulting session to control API access.=C2=A0
Unless you want to dive into the details here, = I suggest you remove the mention of OIDC because it is misleading.


6.2.=C2=A0 Apps Served from a Dynamic Application Serve= r

I have= a .NET sample for that=C2=A0

https://github.com/leastprivilege/= AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
And a blog post

9.7.  Content-Security Policy


   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.


I would rath= er say that ANY JS app should use CSP to lock down the browser features to = a minimal attack surface. In addition, if refresh or access tokens are invo= lved - further settings like disabling inline scripting (unsafe inline) and= eval should be disabled.

Thanks for doing this work!
=
=E2=80=94=E2=80=94=E2=80=94
Dominick=
--000000000000688ac5058e3efd63-- From nobody Mon Jul 22 03:37:20 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5EB120220; Mon, 22 Jul 2019 03:37:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156379183910.28037.6475823714043210375@ietfa.amsl.com> Date: Mon, 22 Jul 2019 03:37:19 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 10:37:19 -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-04.txt Pages : 16 Date : 2019-07-22 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 03:38: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 8AFC3120220 for ; Mon, 22 Jul 2019 03:38:30 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crfCGi-GNJ9n for ; Mon, 22 Jul 2019 03:38:28 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.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 F33C512026D for ; Mon, 22 Jul 2019 03:38:25 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpVi3-000859-DQ for oauth@ietf.org; Mon, 22 Jul 2019 12:38:23 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_44A03585-90B6-429E-8088-93C4E90EBE89"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 12:38:22 +0200 References: <156379183910.28037.6475823714043210375@ietfa.amsl.com> To: IETF oauth WG In-Reply-To: <156379183910.28037.6475823714043210375@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 10:38:30 -0000 --Apple-Mail=_44A03585-90B6-429E-8088-93C4E90EBE89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii HI all,=20 this revision incorporates changes based on the AD's feedback.=20 kind regards, Torsten. =20 > On 22. Jul 2019, at 12:37, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : JWT Response for OAuth Token Introspection > Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename : = draft-ietf-oauth-jwt-introspection-response-04.txt > Pages : 16 > Date : 2019-07-22 >=20 > Abstract: > This draft proposes an additional JSON Web Token (JWT) based = response > for OAuth 2.0 Token Introspection. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon= se/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04= > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-r= esponse-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-res= ponse-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_44A03585-90B6-429E-8088-93C4E90EBE89 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 Fw0xOTA3MjIxMDM4MjJaMC8GCSqGSIb3DQEJBDEiBCCa8Dxt7C+V8x3MUOn0GEvrDw2+8nQdxt3G +tDYZF8t8zCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBALuj3Yre3xL0APjXPjxp+O9++SrUyVBTpXXnShY0q5kJ5UtUpUeBOByBbhoC rWnhsY5HCQwdQVYzqaQKxj6rA6Mj2g6Vc0uuNpXH+IppU+1dEyzJZzXudDXlNiNASgOLVx4rpdjJ WTFdYIGy+1bPIJv+te/PxkmOVGpJ2d9UIS4S7QeOVL5FLM4IDhMflNbWCl3C4Xmmitv4n3Zae52Z fD22kDT0ObveIAFhvfADVpo8VJoJktVQBDCMt9cRf3Yk1V0JHsEHcQ4nZ9GdDTxMPplPt2lyPfU7 esEecNUnwGHm6V47XrZ1iJynnvIOfS0g6UomVBGB8deaeU7SleYGwYkAAAAAAAA= --Apple-Mail=_44A03585-90B6-429E-8088-93C4E90EBE89-- From nobody Mon Jul 22 03:58: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 651C612024A for ; Mon, 22 Jul 2019 03:58:38 -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 p-lNzBF0yvx2 for ; Mon, 22 Jul 2019 03:58:35 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 9EBA01200C1 for ; Mon, 22 Jul 2019 03:58:35 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpW1X-0003jK-HC; Mon, 22 Jul 2019 12:58:31 +0200 From: Torsten Lodderstedt Message-Id: <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_ABC88CAA-E528-4E35-835E-60720787403B"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 12:58:30 +0200 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> Cc: "oauth@ietf.org" To: Roman Danyliw References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 10:58:39 -0000 --Apple-Mail=_ABC88CAA-E528-4E35-835E-60720787403B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roman,=20 thanks a lot for your review feedback. I just published a new revision of the draft incorporating changes based = on your comments. =20 = https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04= > On 17. Jul 2019, at 18:17, Roman Danyliw wrote: >=20 > Hi! >=20 > The following is my AD review of = draft-ietf-oauth-jwt-introspection-response-03.=20 >=20 > (1) Section 4. Per introspection_encrypted_response_alg, how is = either signing or encryption being requested? Is it by also including = an introspection_signed_response_alg? If that's the case, it is worth = explicitly saying. The response is always signed. The resource server may decide to = additionally turn on encryption.=20 Section 3 states =E2=80=9CDepending on the specific resource server = policy the JWT is either signed, or signed and encrypted. =E2=80=9C >=20 > (2) Section 4. Per introspection_encrypted_response_enc, I'm having = trouble deconflicting these two sentences: >=20 > [1] If "introspection_encrypted_response_alg" is specified, the = default for this value is A128CBC-HS256. =20 >=20 > [2] When "introspection_encrypted_response_enc" is included, = "introspection_encrypted_response_alg" MUST also be provided >=20 > Sentence [2] explicitly states that = "introspection_encrypted_response_alg" is required. However, the first = sentence seems more tentative by saying that "if = introspection_encrypted_response_enc" is present. introspection_encrypted_response_enc is optional but must not be = specified without introspection_encrypted_response_alg I changed the text to better get this across:=20 introspection_encrypted_response_alg OPTIONAL. JWE algorithm (alg value) as defined in JWA for encrypting = introspection responses. If this is specified, the response will be = encrypted using JWE and the configured algorithm. The default, if = omitted, is that no encryption is performed. If both signing and = encryption are requested, the response will be signed then encrypted, = with the result being a Nested JWT, as defined in JWT. introspection_encrypted_response_enc OPTIONAL. JWE algorithm (enc value) as defined in JWA for authenticated = encryption of introspection responses. The default, if omitted, is = A128CBC-HS256. Note: This parameter MUST NOT be specified without = setting introspection_encrypted_response_alg.=20 >=20 > (3) I want to talk through the personally identifiable information = being specified as new introspection fields per Section 8.3 (e.g., name, = birthday) being exposed. I was looking to ensure that it would always = be encrypted in transit (and that only authorized clients could get it). = I read that in Section 3, "[d]epending on the specific resource server = policy the JWT is either signed, or signed and encrypted" and that per = Section 4 that "[t]he authorization server determines what algorithm to = employ to secure the JWT for a particular introspection response." = Section 6.2 explicitly notes the threat of token data leakage (a more = general case of my concern so thanks for that text). [RFC7662], Section = 4 notes only that "the server MUST support Transport Layer Security = (TLS) 1.2", but "support" is different than "the server MUST _use_ TLS". = Therefore, it seems like there could be a case where the server could = return an introspection response in the clear (e.g., no TLS, = introspection_sig > ned_response_alg). Am I missing something? =20 >=20 > My bias is to say something on the order of "TLS MUST be used=E2=80=9D. Section 6.2. now starts with =E2=80=9CThe authorization server MUST use = Transport Layer Security (TLS) 1.2 (or higher) in order to prevent token = data leakage." >=20 > (4) I also want to talk through an unscrupulous protected resource = trying to harvest introspection meta-data. I was looking for guidance = related to the authorization of the introspection transactions. I = found: >=20 > Section 2.2 of [RFC7662] says important things like "For instance, an = authorization server MAY limit which scopes from a given token are = returned for each protected resource to prevent a protected resource = from learning more about the larger network than is necessary for its = operation." >=20 > Section 4 of [RFC7662] says "If left unprotected and un-throttled, the = introspection endpoint could present a means for an attacker to poll a = series of possible token values, fishing for a valid token. To prevent = this, the authorization server MUST require authentication of = protected resources that need to access the introspection endpoint and = SHOULD require protected resources to be specifically authorized to call = the introspection endpoint." >=20 > Section 6.2 of this draft provides guidance on defending against = unauthenticated clients. >=20 > How does the authorization server restrict a protected resource that = _can_ authenticate to it from getting meta-data is shouldn't have access = to? Something on the order of "the authorization server to determine what a given protected resource is allowed = to see=E2=80=9D. I added Section 6.3, which states =E2=80=9CThe authorisation server = determines the token data a resource server is allowed to see based on = the resource server=E2=80=99s client_id and suitable token data, e.g. = the scope value." >=20 > (5) Editorial Nits >=20 > ** Section 3. Per "This JWT MAY furthermore contain all other claims = described in Section 2.2. of [RFC7662] and beyond (e.g. as defined in = [OpenID.Core])", would it be more timeless to say the fields specified = in "OAuth Token Introspection Response" registry? >=20 This text pre-dated the addition of the IANA registry section. Thanks = for spotting the inconsistency.=20 I modified the text as you suggested. > ** Section 4. The first sentence of each parameters descriptions = don't parse -- for example with introspection_signed_response_alg: "JWS = [RFC7515] 'alg' algorithm JWA [RFC7518] REQUIRED", fully expanded that's = "JSON Web Signature (JWS) [RFC7515] "alg" algorithm JSON Web Algorithms = (JWA) [RFC7518] REQUIRED ...". The same is true for the write-ups in = Section 5. modfied text >=20 > ** Section 4. Editorial. Per "introspection_encrypted_response_enc": > s/REQUIRED for encrypting introspection responses/ > REQUIRED for authenticated encryption of introspection responses/ >=20 done kind regards, Torsten. =20 > Regards, > Roman >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_ABC88CAA-E528-4E35-835E-60720787403B 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 Fw0xOTA3MjIxMDU4MzFaMC8GCSqGSIb3DQEJBDEiBCD9YIORFHN2a/Fsf+VS+g7d5cVyqx6QKFUK 77iZC+aRIzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAHJhQ6VVWQwDRAW3DllHCnMeOHj8/GaGh2wf2dSNPRCOJIjU/xEUttmVtrED JXxwSu+H3cLsdhJvBKP72BwuiNjNNNOd0UUnhP8KfyUXUncY54v6tAyy990Q4LJYp343Lucq9Bu/ M8QQdlagx/r9ZCH+nvO960XC2Vz6mf97VQBqxUqJinw7sjlzJGESYKPSDxi/QzOfLv8pwRSpregd YATE1DMBqPG82iWk8EbE9Aqdj45PUcZtGwtIdBT9iXPnyp371Y/T/ghHLuYefr7/SegWV9qWV9al ac6uLQgCGq73o5Z1RyeL5JMZNJNM3oxYMvES5z2hi0o6avBoBlS0OTMAAAAAAAA= --Apple-Mail=_ABC88CAA-E528-4E35-835E-60720787403B-- From nobody Mon Jul 22 04:03: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 4991612015A for ; Mon, 22 Jul 2019 04:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67sV0lOMMoe4 for ; Mon, 22 Jul 2019 04:03:40 -0700 (PDT) Received: from sonic311-23.consmr.mail.ne1.yahoo.com (sonic311-23.consmr.mail.ne1.yahoo.com [66.163.188.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A702120255 for ; Mon, 22 Jul 2019 04:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1563793419; bh=hYFzv2jgwAhyh5eXUt2sC2Q4s3lMVksfr3Z6WAT6HMk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=U3UjKLhsXQfrCSm6m3nNuJoPXkfVvvgz9Qj1RSElblOQDMTyyCR0xyKAeYzPZu8WXCU4rWBrwIZGQi3NjdU1+Hc7uerhtky9tcuKAwAxyXcTROYGYvyOmbLCyRM0ZeA0MMMIkP6CF/em9Qgs9Hutt1LjvXfthji4vO+aoKThgw+m+cS1jqDbxQdh+S8k/aYorNBl4FMt1v5w4f7dnwSdUxiOF2RhE+biHCOB/5TOQHi4LyHCPAkje220FGtYMQUrdIrnci2gheJ4xCdNOZ5j3FUT7HBnJgXUmpkl9zDpzX0lOdlwuiZsQS/vCYtOuCo4DT8eCOg6ZNjPFRTsbQo8dQ== X-YMail-OSG: 0oyZwowVM1kZyHIlJW4oru5jyxgPwIlifLoezW1nORwuOV6zaeJBIIXy33pt0g3 J3v6CKEQPOUHqPXLGMvd35tinXaBTGTI89EvH5CpR2z9GPjOqg.imDm.VJcBihZ2hF3_YL22xAuw iNAHrUpSMGaAUvczuK_g.c8DqEhYUE5VkzfngoeXHvXsNgE4DKVj1VoOvkXwsuGsllaldRXgV347 v5SYCaHFtv1z2.aWztveen_ssLmUzXMgoAg5E7ItPMFirgY7tb1PjJZXmLtBLTjK5ic4uJAWMVnK fbDEKXbhb6GoUFbCn8IWSx02mJPPGEjk1E786LQvZqEx5TWFggeZo4c8VMyQN.jO.77XrI4A8erp LBUwLcHLkamniKcTIlPVZtyoGwaDl5w1E1ZrWMLw1X.jh6ph4hqEO.tXU_tl2Xv.TzuC5SHzPAIL AR5pDoE2_zIE30hkoP9BwOBrheEdKe1HiN0nnwBieo4lil_hVBx2Z3xshhQysZp4aZmHPrZKFgMu VgNFN5m4.1esknpZshUK7ZnSBmKB3lOsjJVfjqY.ghskFCVURZM0h9mUCGA8mrbFLRvnD_pZxKvO Q725EhxOTKxecE0ktDFaQJoYtQ38fUSEqT36m.I5Br5KSZWRIQCVlfpLc1AjCNBbNPSNqcne._6h BVeCwi3VAaqPnN2cG1yJCQBawqWMtXnTZpx_BKWtToKcbFVcw_JS_NLV1Yugd6PtdOuKJa5e1kbK BWDpfVgfHAIcRbBclrT_wL9GEdhfpq62.7r2yjmKHAQmFjwI1797vBUsKaOGcz5mB0PoTTgwYMGl jcF3Tc5Xq7nsadaTy5eVbn27Dn3XB9TAmvZHCPPJavYRzSNmx18Ah2LIXGJ2NloB61Oqh5zKsgPO zUycnRQaoAXzM5z5GO4X6oTAkno.1kprS.YKHr0vzNMJ8xwLhAxgtNgnEuB1FjaT2vtUhxMQOJGV ZBxdgF_69u8AGY57N4dVUyuPjQ.RrujdNHdbvTiTEsrIw5WjWaHqkafyjMlHUjIyThDeDs3yYfUr UO3i8.3WF7TwyrNvKS4C1PIGg7XLjFQjTll01IJxKjdiNCAfQU.vs8jw6f7Cipb.xmNpnLckRfcZ Y1wyzGxPemjYzTPFMhNMavQIhetKYk.Cc5BkNbg3u8rEFbZt5txJvTrO7KUTKYtUCUTVd4tcCXYp PDrcqCSCQjOeXE4gAOVKJAVTnY7JJyWK5nYc2Y0urqbSG7Ipw4vpx472r8Zy9QTAguF_xYHbJAu6 o4LbvqxWxfvOrrb.kX.1.uL9Gda7j7uSd Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 Jul 2019 11:03:39 +0000 Date: Mon, 22 Jul 2019 11:03:34 +0000 (UTC) From: Tomek Stojecki To: Leo Tohill , David Waite , Brock Allen Cc: oauth@ietf.org Message-ID: <1459948558.729107.1563793414827@mail.yahoo.com> In-Reply-To: <170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com> References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> <170d4112-fc89-4f6b-8f10-126baf62a193@getmailbird.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:03:46 -0000 >=C2=A0FWIW, in addition, those can be used together -- sliding & absolute.= =C2=A0 Azure AD does both at this point. They used to do 90 days absolute, now it = is a sliding, 72 hours by default I believe.=C2=A0 Good discussion overall, would this be a good summary for the type of a cli= ent the spec is for: SHOULD NOT use refresh tokens unless the token endpoint mirrors user authen= tication or the OP supports expiration, rotation and revocation of refresh = tokens On Sunday, July 21, 2019, 04:45:07 PM GMT+2, Brock Allen wrote:=C2=A0 >=C2=A0IdentityServer allows a choice of behavior on refresh token expirati= on time. It can have a absolute expiration time, or use a sliding window. FWIW, in addition, those can be used together -- sliding & absolute. Finall= y,=C2=A0refresh tokens can be re-use or one-time use only. These are all pe= r-client settings. -Brock _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 22 04:59: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 A9CE9120265 for ; Mon, 22 Jul 2019 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JneV1p3MGuRF for ; Mon, 22 Jul 2019 04:59:19 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D704120256 for ; Mon, 22 Jul 2019 04:59:19 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id a15so34861778wmj.5 for ; Mon, 22 Jul 2019 04:59:19 -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=74ww72g7dktt1IU6jtuCC6SdpQPmx2/V071qDZpiGYw=; b=Zk7rlgV9MNkXWMfI+Cxkbt3RQ64fIXBg6aoyMyvQhVp4zRLgZ3p8I7yXBIQqT8U71B 9xYQNW3d3Nf3paggepsMPUcr2Jj8IX1PrI1vCtiWyIHDrWS9uwV/ChsvHgS242Oot8av 7K6cNtZf3nPXYrar7X4esg+jy6qqigEvZV2qk= 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=74ww72g7dktt1IU6jtuCC6SdpQPmx2/V071qDZpiGYw=; b=SdzGhkLQIIhXOJ5kUxvFzpA9lbROivC/LFoN2HAkh23iIA3aPsPuXKFnMmMVbBf6Je Xx52Xe6Y9oIz18vqtAlfw3K8EoUTKFkZoSsCe3NZZMhzdvwiChu8aK6ZuOQC2lgXb169 RhovH/nlWzVcYBbEkrrHMc6SodxrDUOtg5LUK1qpKXHu7fzhb4h0L9UIjK0axdmlMRpS 8ulKz7Wfo8bkpyG2dYF95tfV5x6vIK692lSVxrL8Q8rcyRpsW/UfWThV7v8E9FJicYIk WGDyeduriqcWYTV+LDaaK2ZYdesmPZMw+W3pMi1n2fu4+6sSQzFAkla5+Tvfb+iPfcww GEsg== X-Gm-Message-State: APjAAAXwfbuVnrmF+NPvBJHUK8EsOpg43DwGYCtQ36P+OIWOtIqSV8Sz CLwRQTGNWpDzaopUkxuW1B0X1g== X-Google-Smtp-Source: APXvYqyl3PtJkbL17Ye0Xuhsp09sfZG69X7Zd88dkQv+yA6PmRMjQzLOTzUXfyG+EoLU+LDRvlz8jA== X-Received: by 2002:a7b:c149:: with SMTP id z9mr65797898wmi.0.1563796757506; Mon, 22 Jul 2019 04:59:17 -0700 (PDT) Received: from [192.168.1.64] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id n8sm30588467wro.89.2019.07.22.04.59.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 04:59:16 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 12:59:13 +0100 In-Reply-To: <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> Cc: Leo Tohill , OAuth WG To: David Waite References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:59:23 -0000 --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you both for your replies, my responses are below: On 20 Jul 2019, at 19:54, David Waite = wrote: >=20 >> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: >>=20 >> Access tokens and refresh tokens, stored browser-side, are equally = vulnerable to theft, because the storage options are identical.=20 >>=20 >> We are more concerned about the theft of the refresh token, because = it (commonly) has a longer usable lifetime than the access token.=20 >>=20 >> Still , its a matter of degree. Since we accept the risk of access = token theft, why can't we accept the risk of refresh token theft? We = ameliorate the access token risk by using short lifetimes, but there is = no standard for that value: it is situational. Why doesn't the same = reasoning apply to refresh tokens?=20 >>=20 >> This reasoning assumes that refresh tokens also have a limited = lifetime. I am unsure that this is always the case. When one uses a = refresh token to acquire a new access token, AND that operation issues a = new refresh token, does the new refresh token get a new lifetime? If = so, then a refresh token can be used to retain access infinitely (or = until it is revoked server-side). In this scenario, the risks = associated with browser-side storage of refresh token are much higher.=20= >>=20 >> In summary, I'd say that IF the lifetime of a refresh token can be = limited, then refresh tokens pose identical risk as access tokens, and = so the same considerations apply.=20 >=20 > Agreed >=20 > I think there is an unwritten framework for evaluating the security of = all tokens, regardless of type. For example: access tokens are shared = with resources, so their security protections in the Security BCP = including limiting replay against other resources, and optionally = against new requests against the same resource. >=20 > Because it is complex and unwritten, it is hard to do a true = evaluation. My impression was always that refresh tokens were more = =E2=80=98risky=E2=80=99 for public clients because =E2=80=9Coffline=E2=80=9D= refresh tokens may be good for an indeterminate period of time, and = because lack of credentials means theft of the token is sufficient. Access tokens (without PoP) are also usable without credentials, so this = is not a reason why refresh tokens are more risky. =46rom the responses, = it appears that token lifetime is the primary concern - access tokens = usually have a limited lifespan but refresh tokens are unlimited. But = there are very few threats that are eliminated by short token lifetimes. = For example, when somebody goes for a coffee leaving their computer or = phone unlocked. But even in these cases you are normally concerned with = idle-timeouts rather than overall token lifetime. The token should = become invalid after 3 minutes of inactivity, for example. > In addition, a public client which does not use its refresh token in = an =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a = considerable period of time, and the operational model of public clients = usually puts detection of local token theft in the hand of the end user = and client software, not an administrator or organizational security = staff. Given that a refresh token has to be used at the AS, isn't the situation = here *better* for refresh tokens? Every time an attacker uses a stolen = refresh token you get a nice ping against your centralised token = endpoint, giving you a great opportunity to run contextual checks to = decide if something looks fishy.=20 >=20 > But those concerns are mostly mitigated if the OP can set policy to = control refresh token usage in concert with the authentication session. I'm not sure that OAuth should tie itself to a concept of authentication = session. Would it be better to say that all tokens issued to = browser-based clients should have a short idle timeout? There's also a privacy aspect to linking refresh tokens to a user's = authentication session, as it gives the 3rd-party client a way to detect = when you are/are not logged into Facebook or whatever. That may be = desirable in some cases, but not necessarily always.=20 -- Neil= --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you both for your replies, my responses are = below:

On 20 Jul 2019, at = 19:54, David Waite <david@alkaline-solutions.com> wrote:

On = Jul 20, 2019, at 12:38 PM, Leo Tohill <leotohill@gmail.com>= wrote:

Access tokens and refresh tokens, = stored browser-side, are equally vulnerable to theft, because the = storage options are identical. 

We are more concerned about the theft of the refresh token, = because it (commonly) has a longer usable lifetime than the access = token. 

Still , its a matter of degree. Since we = accept the risk of access token theft,  why can't we accept the = risk of refresh token theft?  We ameliorate the access token risk = by using short lifetimes, but there is no standard for that value: it is = situational.  Why doesn't the same reasoning apply to refresh = tokens? 

This reasoning assumes that refresh tokens = also have a limited lifetime.  I am unsure that this is always the = case.  When one uses a refresh token to acquire a new access token, = AND that operation issues a new refresh token, does the new refresh = token get a new lifetime?  If so, then a refresh token can be used = to retain access infinitely (or until it is revoked server-side). =  In this scenario, the risks associated with browser-side storage = of refresh token are much higher. 

In summary, I'd say that IF the lifetime of a refresh token = can be limited, then refresh tokens pose identical risk as access = tokens, and so the same considerations apply. 

Agreed

I think there is an unwritten framework for evaluating the = security of all tokens, regardless of type. For example: access tokens = are shared with resources, so their security protections in the Security = BCP including limiting replay against other resources, and optionally = against new requests against the same resource.

Because it is = complex and unwritten, it is hard to do a true evaluation. My impression = was always that refresh tokens were more =E2=80=98risky=E2=80=99 for = public clients because =E2=80=9Coffline=E2=80=9D refresh tokens may be = good for an indeterminate period of time, and because lack of = credentials means theft of the token is sufficient.

Access= tokens (without PoP) are also usable without credentials, so this is = not a reason why refresh tokens are more risky. =46rom the responses, it = appears that token lifetime is the primary concern - access tokens = usually have a limited lifespan but refresh tokens are unlimited. But = there are very few threats that are eliminated by short token lifetimes. = For example, when somebody goes for a coffee leaving their computer or = phone unlocked. But even in these cases you are normally concerned with = idle-timeouts rather than overall token lifetime. The token should = become invalid after 3 minutes of inactivity, for example.

In addition, = a public client which does not use its refresh token in an =E2=80=9Cofflin= e=E2=80=9D manner may have theft go unnoticed for a considerable period = of time, and the operational model of public clients usually puts = detection of local token theft in the hand of the end user and client = software, not an administrator or organizational security = staff.

Given = that a refresh token has to be used at the AS, isn't the situation here = *better* for refresh tokens? Every time an attacker uses a stolen = refresh token you get a nice ping against your centralised token = endpoint, giving you a great opportunity to run contextual checks to = decide if something looks fishy. 


But those concerns are mostly mitigated if the OP can set = policy to control refresh token usage in concert with the authentication = session.

I'm not sure = that OAuth should tie itself to a concept of authentication session. = Would it be better to say that all tokens issued to browser-based = clients should have a short idle timeout?

There's also a privacy aspect to linking refresh = tokens to a user's authentication session, as it gives the 3rd-party = client a way to detect when you are/are not logged into Facebook or = whatever. That may be desirable in some cases, but not necessarily = always. 

-- = Neil
= --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995-- From nobody Mon Jul 22 05:12: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 07E2A120270 for ; Mon, 22 Jul 2019 05:12:42 -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 HbQ01STYNdSl for ; Mon, 22 Jul 2019 05:12:39 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.111]) (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 45C9912009C for ; Mon, 22 Jul 2019 05:12:39 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpXBE-0004ZL-3U; Mon, 22 Jul 2019 14:12:36 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_214C7338-30B2-4B47-B3BB-DE220F5C778E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 14:12:35 +0200 In-Reply-To: Cc: David Waite , OAuth WG To: Neil Madden References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:12:42 -0000 --Apple-Mail=_214C7338-30B2-4B47-B3BB-DE220F5C778E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Neil, > On 22. Jul 2019, at 13:59, Neil Madden = wrote: >=20 >> In addition, a public client which does not use its refresh token in = an =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a = considerable period of time, and the operational model of public clients = usually puts detection of local token theft in the hand of the end user = and client software, not an administrator or organizational security = staff. >=20 > Given that a refresh token has to be used at the AS, isn't the = situation here *better* for refresh tokens? Every time an attacker uses = a stolen refresh token you get a nice ping against your centralised = token endpoint, giving you a great opportunity to run contextual checks = to decide if something looks fishy.=20 I agree with your assessment.=20 That why the Security BCP = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= .12) requires authorisation servers to detect refresh token replay. Even = if the refresh token cannot be sender constraint, one-time refresh = tokens (or refresh token rotation) is a viable option when used in = combination with conditional revocation of the active refresh token if = something looks fishy. kind regards, Torsten.=20= --Apple-Mail=_214C7338-30B2-4B47-B3BB-DE220F5C778E 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 Fw0xOTA3MjIxMjEyMzVaMC8GCSqGSIb3DQEJBDEiBCAUFrcq1DsfbGyijEXDnhF4ybD8la8HyJcL 87FzBX4SyjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAMT/uoqNjItuTGLF8dU7ZyPbUC6pzx+DPdhEMpzsDpyTYZUicuS3bkOEbbUC fAyy3E8hKRiQfnvRs6Wsapa0Q2sGq9eqbOKfXNH8WtTFnYo7dBb0ZazZlAcj5JxKz5uNjZHEuTc3 /Wxe7MGou5AeTXPfhIse/O2tYe/OuZ9amqWTSiMjRnybhyxmTjcsvy080Jprs0Z6ozaBZ+kO1ydn 7O5fm9/bzerezYr1ZUCbv0YHBzFhKNO30t87XNRp9xYLEF6p+SJAxed47yIpwTyW7FjXTsvCCLtL hj1Mn8tq3j3rrY31qFUTtooJBrRPfb6hfyP8VtWXt3m9G0/x9ijS+5sAAAAAAAA= --Apple-Mail=_214C7338-30B2-4B47-B3BB-DE220F5C778E-- From nobody Mon Jul 22 05:30: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 522DF1202E6 for ; Mon, 22 Jul 2019 05:30:47 -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 1HHy8S71KWxS for ; Mon, 22 Jul 2019 05:30:45 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.99]) (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 3739E1202D0 for ; Mon, 22 Jul 2019 05:30:45 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpXSk-0008Uv-0c; Mon, 22 Jul 2019 14:30:42 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1DB472DA-F38C-4898-BC77-61CE7B3D53F5"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 14:30:41 +0200 In-Reply-To: <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com> Cc: OAuth WG , David Waite To: David Sautter References: <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 12:30:52 -0000 --Apple-Mail=_1DB472DA-F38C-4898-BC77-61CE7B3D53F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David,=20 > On 12. Jun 2019, at 04:01, David Waite = wrote: >=20 > To prevent exfiltration, the options are limited.=20 > - Token Binding will work, but only currently has support in Edge. > - Mutual TLS will work, but has a poor experience unless you are = deploying alongside group policy. > - DPoP was written specifically for the browser use case (such as = letting you use WebCrypto for non-exportable tokens). It is an early = draft but has some initial implementations already. If you use a backend to relay or orchestrate your micro service = interactions, mTLS (with self-signed certs) is the easiest choice from = my perspective.=20 kind regards, Torsten.=20 --Apple-Mail=_1DB472DA-F38C-4898-BC77-61CE7B3D53F5 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 Fw0xOTA3MjIxMjMwNDFaMC8GCSqGSIb3DQEJBDEiBCC2M2Qm6v+3rcNja1Qt/F+x5/oUnYmzcHXf hm+desHtSTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAEL7PhqDe38T7vsU8+kweYeTztOzezhOlnlimw9xBX9xMF9pa8RSWBFHy9jc kydPV3sKJS3hk5tNhNtWeFPaiXCuBvOcn3H87LqxUKgM+g1L1GeB/3qu2RrUFJJ+9boHhXFfcycm ZNO2OlHbVvoj5tuAhmTd3+gReJK7M39YNGMKn8Id1jFA9DcyYMh9aGHwU0r1EAZbkHqw7VDUkeNK LjmJQhqgdLR0hhS70knQmk9EXWCqwxO/10vhoDWpzZEBzPjcedP52Xs7FDK87OCOUiRei5EH9Xk/ VdBR1n1ELJmY9oheIwJ+psCgc71co3ZSQTXXPQlHvr34O1PeqcLtm+oAAAAAAAA= --Apple-Mail=_1DB472DA-F38C-4898-BC77-61CE7B3D53F5-- From nobody Mon Jul 22 05:36: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 E9FA412001A for ; Mon, 22 Jul 2019 05:36:48 -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 ryiOGfYyxeDH for ; Mon, 22 Jul 2019 05:36:47 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (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 16768120043 for ; Mon, 22 Jul 2019 05:36:47 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpXYa-0002Y2-4l; Mon, 22 Jul 2019 14:36:44 +0200 From: Torsten Lodderstedt Message-Id: <6E258D5A-4919-463F-9826-020F80DC2392@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_1DB10293-4469-4E41-B559-15977D4F27EF"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 14:36:43 +0200 In-Reply-To: Cc: "oauth@ietf.org" To: James Howe References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Query on RFC 7009 X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 12:36:49 -0000 --Apple-Mail=_1DB10293-4469-4E41-B559-15977D4F27EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi James,=20 > On 11. Jun 2019, at 17:53, James Howe wrote: >=20 > Unless I'm mistaken, RFC 7009 doesn't specify the error response when = the request is from a different client to the issuer. >=20 > Section 2.1: >> If this validation fails, the request is refused and the client is = informed >> of the error by the authorization server as described below. >=20 > The only relevant description below I can see is in Section 2.2.1: >> The error presentation conforms to the definition in Section 5.2 of = [RFC6749]. >=20 > However none of the error codes there seem to be applicable. > unauthorized_client appears to be the closest, although there is no = grant type involved. >> The authenticated client is not authorized to use this authorization = grant type. >=20 > What is the intention here? Since RFC 6749 does not utilise HTTPS status code 403 (which would be = appropriate), the AS should respond with unauthorized_client as you = suggested. kind regards, Torsten.=20 >=20 > ---- > James Howe > Senior IT Developer > Department of Engineering > University of Cambridge > +44 1223 748536 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1DB10293-4469-4E41-B559-15977D4F27EF 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 Fw0xOTA3MjIxMjM2NDNaMC8GCSqGSIb3DQEJBDEiBCC32ogmvNjbnsIbpinl8I2R+XOW79OPWlod /R0Qr5QmzzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAJSfsLpI7HmTGenz4wCxHksCIIebHHT/FXFK1xWeiXcbYxjFqmzvpu/+XtIy DnKNAtGC0j7OiTz2/9c3C7dlf1ye1omrVweJ4TuwifnzI75AQVeSFA0T7pTzGVEpNa+0zbp1IL32 eJsHs7Tnsn3miV+ArcHFB6DBRx0p4aDu1yXK+af/rH4TevZrr4EzcpzG1Wku3LVNneJkOxhPKqJ2 WJaOpyxUIPZi53+LqGYcaypKpmgEDmjloJyWnAtDjyQj+HnEYjXPhp+ejysw1muWEPGyBwrvcmU2 6W8sm3+2+N+2VfhxbK8Mnlk7fdRXswq3KEnPUoo98uDtiU3xPOEmDQ8AAAAAAAA= --Apple-Mail=_1DB10293-4469-4E41-B559-15977D4F27EF-- From nobody Mon Jul 22 05:37: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 07C8F120043 for ; Mon, 22 Jul 2019 05:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oZgJAywriJs for ; Mon, 22 Jul 2019 05:37:43 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEFE12001A for ; Mon, 22 Jul 2019 05:37:43 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id j5so69334743ioj.8 for ; Mon, 22 Jul 2019 05:37:43 -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=UTdXiLjJKAEZgPC7I5O30J24mmZrVWdclJZlnsHlPJI=; b=PlupWsneDQ6qUs1YYvYwpRzYvxRv9ZeNoWk455daAXVNQLevC5OOt9SHFaeQdNn85F 7gU6I1ExHudhhtsUet7tQi52//VRFMLO2UUxqpys90PZMqt7oaRvqilodFwh5m9dS36z 950NINUspe9gKm8HrToB7PpuUcVHMJhDNZECM= 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=UTdXiLjJKAEZgPC7I5O30J24mmZrVWdclJZlnsHlPJI=; b=B3m0x2QACEASfp4h36g/A+LoRzlSz9cbANHpKV7NGOiS2dWD5BRgYalvtaJl1Sj+R/ 0Op2SK9MQ1LfBwFeTIkvEHW+WL7YedawbFk8/BIniygJiB2mp7MidzsD0Iye6j+I0NZh Ub31RyV7bgeKLjIKKLSqvH4IXHkH1dFWwIIMio6sa58dqtG3a1dM6d9/6AjbDFzr26sF px6PN1knPdfnaJ1AA2+WKtYlUcDldX/BGLjtZkp+CRSL0c3QukNy6VuoKTMr46TIPX1T qIudKRVyvqljXoK69Y/h+0PgSWYPoiYQSPLx2Oj05t/Tw8Pd/H6d4HUALUcO9KsvU8fq mQTg== X-Gm-Message-State: APjAAAXnjV1K6L6H9XBf5wNQDV49swFrJ3GNmshWsuqXdoWFcZPvcJ4B ilMBVomh6qq9UMlEH72L0OjiTquxhtea2ghYOf0NK/tJ4UfAdngwF0wlT8xbIMV9qQOMuqpLthL xQsS33ziGD6trEoDvDio= X-Google-Smtp-Source: APXvYqw1Zm6+vswfN7oK2Z3qwjQWAoRWfEAriOVv02WfpuewGyk45PFBbKamO+alR6PtqGxsjNLOWRONt8E/TNH51b8= X-Received: by 2002:a5d:87c6:: with SMTP id q6mr43146767ios.115.1563799062721; Mon, 22 Jul 2019 05:37:42 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> From: Brian Campbell Date: Mon, 22 Jul 2019 06:37:16 -0600 Message-ID: To: Roman Danyliw Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a25388058e445795" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:37:46 -0000 --000000000000a25388058e445795 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, sorry about that. I realized this yesterday and as tried to write quickly from from my phone just before my flight took off for Montreal , I'd gotten distracted with the question of what to do with the registrations and lost track of this fork of the thread. There are indeed a couple of outstanding bits that need to be addressed in a -04. I'll change adapt to downscope. Regarding your unanswered questions from below - partially quoted here for reference: 'If the initial request was notionally a scope of =E2=80=9Call the houses o= n the block=E2=80=9D, but the server knew that this request was too broad and dow= n-scoped to =E2=80=9Conly the corner house=E2=80=9D, wouldn=E2=80=99t this actually = be worse for privacy?' -> the idea there is privacy in terms of limiting what one service potentially leans about other services the user is using. In the houses on the block case you mentioned, the downscoping prevents the corner house from learning that the user also accesses the other houses on the block. 'I also don=E2=80=99t follow how reducing the scope impacts confidential da= ta.' -> to be honest, this particular text came as a suggestion from another WG member on review of an earlier version of the document. So I struggle a bit to defend/explain it but I think the idea is that in some cases a scope value itself might contain sensitive data like an account number or transaction identifier (e.g. something like "acct:123456789" or "tx:987654321"). This is somewhat uncommon in practice today but does happen in some situations. The same principal of limiting the scopes revealed across different services applies here too but with arguably worse consequences due to the sensitive data within the scope value. It's the same concept though and I think the mention of confidential data and scope here in the document is more likely cause confusion than it is to help anything. As such, I'm proposing to change that sentence as follows to remove the confidential bit and somewhat better describe the cross-service scope revealing issue. "This further improves privacy as scope values give an indication of what services the resource owner uses and downscoping a token to only that which is needed for a particular service can limit the extent to which such information is revealed across different services." On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw wrote: > Hi Brian! > > > > Thanks for the update in -03. The item below is the only thing that > remains outstanding. > > > > Thanks, > > Roman > > > > > > *From:* Roman Danyliw > *Sent:* Wednesday, July 17, 2019 6:05 PM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* RE: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Wednesday, July 17, 2019 4:35 PM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > [snip] > > > > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > -- is this language suggesting that the authorization server is modifyin= g > the scope value based on the resource it sees? I'm trying to understand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > > > > Perhaps "adapt" wasn't the best choice of word but it's meant to say that > an authorization server with sufficient understanding of what scopes are > applicable to what resources (which won't always be the case or even > possible but sometimes) could limit the scope associated with an access > token (downscoping really) to only the scope that is applicable to the > resource. > > > > Some of the examples (figures 2 - 6) attempt to show, among other things, > a hypothetical case of how this might go down. > > > > In Figure 2 the initial authorization request that's approved has scope o= f > calendar & contacts and resources https://contacts.example.com/ & > https://cal.example.com/ > > > > A subsequent access token request (Figure 3) has resource > https://cal.example.com/ and the issued access token scope (Figure 4) is > "adapted" to that resource to be only calendar > > > > Another subsequent access token request (Figure 5) has resource > https://contacts.example.com/ and the issued access token scope (Figure > 6) is downscoped based on that resource to be only contacts > > > > Would it be easier to understand if the word "downscope" was used rather > than "adapt"? > > > > [Roman] Using =E2=80=9Cdownscope=E2=80=9D does work for me. It captures = that the server > is going to reduce the scope (and certainly not expand it). > > > > > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? > > > > I'm not sure, to be honest. Downscopping when possible and to the extent > possible is usually a good idea (least privilege and all that) but I thin= k > maybe I'm missing your point/question. > > > > [Roman] Yes, least privilege was part of it and I think the text above > gets at it. However, the other part is the relationship with the next > sentence in the paragraph, =E2=80=9CThis further improves privacy as scop= e values > give an indication of what services the resource owner uses and it improv= es > security as scope values may contain confidential data=E2=80=9D. If the = initial > request was notionally a scope of =E2=80=9Call the houses on the block=E2= =80=9D, but the > server knew that this request was too broad and down-scoped to =E2=80=9Co= nly the > corner house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privac= y? I also don=E2=80=99t > follow how reducing the scope impacts confidential data. > > > > > --=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._ --000000000000a25388058e445795 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, sorry about that. I realized th= is yesterday and as tried to write quickly from = from my phone just before my flight took off for Montreal, I'd gott= en distracted with the question of what to do with the registrations and lo= st track of this fork of the thread.=C2=A0 There are indeed a couple of out= standing bits that need to be addressed in a -04.

I'll change adapt to downscope.

Regarding your unanswered questions from below - pa= rtially quoted here for reference:

'If the initial request was notionally a scope of =E2=80= =9Call the houses on the block=E2=80=9D, but the server knew that this requ= est was too broad and down-scoped to =E2=80=9Conly the corner house=E2=80= =9D, wouldn=E2=80=99t this actually be worse for privacy?' -> the id= ea there is privacy in terms of limiting what one service potentially leans= about other services the user is using. In the houses on the block case yo= u mentioned, the downscoping prevents the corner house from learning that t= he user also accesses the other houses on the block.

'I also do= n=E2=80=99t follow how reducing the scope impacts confidential data.' -= > to be honest, this particular text came as a suggestion from another W= G member on review of an earlier version of the document. So I struggle a b= it to defend/explain it but I think the idea is that in some cases a scope = value itself might contain sensitive data like an account number or transac= tion identifier (e.g. something like "acct:123456789" or "tx= :987654321"). This is somewhat uncommon in practice today but does hap= pen in some situations. The same principal of limiting the scopes revealed = across different services applies here too but with arguably worse conseque= nces due to the sensitive data within the scope value. It's the same co= ncept though and I think the mention of confidential data and scope here in= the document is more likely cause confusion than it is to help anything. A= s such, I'm proposing to change that sentence as follows to remove the = confidential bit and somewhat better describe the cross-service scope revea= ling issue.

=C2=A0 = =C2=A0 =C2=A0 "This further improves privacy as scope values give an i= ndication of what services the resource
=C2=A0 =C2=A0 =C2=A0 owner uses = and downscoping a token to only that which is needed for a particular servi= ce can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 limit the = extent to which such information is revealed across different services.&quo= t;


On Sun, Jul 21, 2019 at 4:= 53 PM Roman Danyliw <r= dd@cert.org> wrote:

Hi Brian!

=C2=A0

Thanks for the update in -03.=C2= =A0 The item below is the only thing that remains outstanding.

=C2=A0

Thanks,

Roman

=C2=A0

=C2=A0

From: Roman Danyliw
Sent: Wednesday, July 17, 2019 6:05 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth@ietf.o= rg
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Wednesday, July 17, 2019 4:35 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

[snip]

=C2=A0

(2) Section 2.2.=C2=A0 in the sentence "To the = extent possible, when issuing access tokens, the authorization server shoul= d adapt the scope value associated with an access token to the value the re= spective resource is able to process and needs to know":

--=C2=A0 is this language suggesting that the authorization server is modif= ying the scope value based on the resource it sees?=C2=A0 I'm trying to= understand what "adapt" means, especially in relation to the imp= roved security and privacy the subsequent sentence suggests.<= /p>

=C2=A0

Perhaps "adapt" wasn't the best choice= of word but it's meant to say that an authorization server with suffic= ient understanding of what scopes are applicable to what resources (which w= on't always be the case or even possible but sometimes) could limit the scope associated with an access token (downscoping really)= to only the scope that is applicable to the resource.=C2=A0

=C2=A0

Some of the examples (figures 2 - 6) attempt to show= , among other things, a hypothetical case of how this might go down.

=C2=A0

In Figure 2 the initial authorization request that&#= 39;s approved has scope of calendar & contacts and resources https://contact= s.example.com/ & https://cal.example.com/

=C2=A0

A subsequent access token request (Figure 3) has res= ource https://cal.example.com/ and the issued access token scope (Figure 4) i= s "adapted" to that resource to be only calendar

=C2=A0

Another subsequent access token request (Figure 5) h= as resource https://contact= s.example.com/ and the issued access token scope (Figure 6) is downscop= ed based on that resource to be only contacts

=C2=A0

Would it be easier to understand if the word "d= ownscope" was used rather than "adapt"?

=C2=A0

[Roman] Using =E2=80=9Cdownscope= =E2=80=9D does work for me.=C2=A0 It captures that the server is going to r= educe the scope (and certainly not expand it).

=C2=A0


-- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ?

=C2=A0

I'm not sure, to be honest. Downscopping when po= ssible and to the extent possible is usually a good idea (least privilege a= nd all that) but I think maybe I'm missing your point/question.

=C2=A0

[Ro= man] Yes, least privilege was part of it and I think the text above gets at= it.=C2=A0 However, the other part is the relationship with the next sentence in the paragraph, =E2=80=9CThis further improves privacy= as scope values give an indication of what services the resource owner use= s and it improves security as scope values may contain confidential data=E2= =80=9D.=C2=A0 If the initial request was notionally a scope of =E2=80=9Call the houses on the block=E2=80=9D, but the server kne= w that this request was too broad and down-scoped to =E2=80=9Conly the corn= er house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privacy?=C2= =A0 I also don=E2=80=99t follow how reducing the scope impacts confidential= data.

=C2=A0

=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. --000000000000a25388058e445795-- From nobody Mon Jul 22 06:11: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 2CE4B12011D for ; Mon, 22 Jul 2019 06:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4caSsYVFRurX for ; Mon, 22 Jul 2019 06:11:34 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B556120116 for ; Mon, 22 Jul 2019 06:11:33 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6MDBXwT024242; Mon, 22 Jul 2019 09:11:33 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6MDBXwT024242 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563801093; bh=YMW5gA5pdBjjKoeI/TT1JgI1+WXaw1BGZPhJ9OUpMe0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WfRmoU1tBXSW7tdnTehKjHBBkmfIZCgSwOkACikiahpOVYJg1j+ydPCFzTs9AoFPz 3RR1RYB3iUjF1X3OO+B3p/JVto+wZa873GZgDTTHJ/3/Np4hHKIiQGHaZXFOjnynHS 2JiYqIxxwqD4YwdNVE7Ow8ooKefNKQ05o2FRdutA= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6MDBVIR032753; Mon, 22 Jul 2019 09:11:31 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 09:11:30 -0400 From: Roman Danyliw To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgA09hCAAAXZ8EAAv6ecgAAlQasAAAc72BA= Date: Mon, 22 Jul 2019 13:11:29 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DFA23@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33DFA23marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:11:37 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFA23marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTkgODozNyBBTQ0KVG86IFJv bWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGlj YXRvcnMtMDINCg0KWWVzLCBzb3JyeSBhYm91dCB0aGF0LiBJIHJlYWxpemVkIHRoaXMgeWVzdGVy ZGF5IGFuZCBhcyB0cmllZCB0byB3cml0ZSBxdWlja2x5IGZyb20gZnJvbSBteSBwaG9uZSBqdXN0 IGJlZm9yZSBteSBmbGlnaHQgdG9vayBvZmYgZm9yIE1vbnRyZWFsPGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvMnNzM2hEYTB4UFF4YVdpVzZ0eGo5Vy12cHFvPiwg SSdkIGdvdHRlbiBkaXN0cmFjdGVkIHdpdGggdGhlIHF1ZXN0aW9uIG9mIHdoYXQgdG8gZG8gd2l0 aCB0aGUgcmVnaXN0cmF0aW9ucyBhbmQgbG9zdCB0cmFjayBvZiB0aGlzIGZvcmsgb2YgdGhlIHRo cmVhZC4gIFRoZXJlIGFyZSBpbmRlZWQgYSBjb3VwbGUgb2Ygb3V0c3RhbmRpbmcgYml0cyB0aGF0 IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGluIGEgLTA0Lg0KDQpJJ2xsIGNoYW5nZSBhZGFwdCB0byBk b3duc2NvcGUuDQoNClJlZ2FyZGluZyB5b3VyIHVuYW5zd2VyZWQgcXVlc3Rpb25zIGZyb20gYmVs b3cgLSBwYXJ0aWFsbHkgcXVvdGVkIGhlcmUgZm9yIHJlZmVyZW5jZToNCg0KJ0lmIHRoZSBpbml0 aWFsIHJlcXVlc3Qgd2FzIG5vdGlvbmFsbHkgYSBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNlcyBv biB0aGUgYmxvY2vigJ0sIGJ1dCB0aGUgc2VydmVyIGtuZXcgdGhhdCB0aGlzIHJlcXVlc3Qgd2Fz IHRvbyBicm9hZCBhbmQgZG93bi1zY29wZWQgdG8g4oCcb25seSB0aGUgY29ybmVyIGhvdXNl4oCd LCB3b3VsZG7igJl0IHRoaXMgYWN0dWFsbHkgYmUgd29yc2UgZm9yIHByaXZhY3k/JyAtPiB0aGUg aWRlYSB0aGVyZSBpcyBwcml2YWN5IGluIHRlcm1zIG9mIGxpbWl0aW5nIHdoYXQgb25lIHNlcnZp Y2UgcG90ZW50aWFsbHkgbGVhbnMgYWJvdXQgb3RoZXIgc2VydmljZXMgdGhlIHVzZXIgaXMgdXNp bmcuIEluIHRoZSBob3VzZXMgb24gdGhlIGJsb2NrIGNhc2UgeW91IG1lbnRpb25lZCwgdGhlIGRv d25zY29waW5nIHByZXZlbnRzIHRoZSBjb3JuZXIgaG91c2UgZnJvbSBsZWFybmluZyB0aGF0IHRo ZSB1c2VyIGFsc28gYWNjZXNzZXMgdGhlIG90aGVyIGhvdXNlcyBvbiB0aGUgYmxvY2suDQoNCidJ IGFsc28gZG9u4oCZdCBmb2xsb3cgaG93IHJlZHVjaW5nIHRoZSBzY29wZSBpbXBhY3RzIGNvbmZp ZGVudGlhbCBkYXRhLicgLT4gdG8gYmUgaG9uZXN0LCB0aGlzIHBhcnRpY3VsYXIgdGV4dCBjYW1l IGFzIGEgc3VnZ2VzdGlvbiBmcm9tIGFub3RoZXIgV0cgbWVtYmVyIG9uIHJldmlldyBvZiBhbiBl YXJsaWVyIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiBTbyBJIHN0cnVnZ2xlIGEgYml0IHRvIGRl ZmVuZC9leHBsYWluIGl0IGJ1dCBJIHRoaW5rIHRoZSBpZGVhIGlzIHRoYXQgaW4gc29tZSBjYXNl cyBhIHNjb3BlIHZhbHVlIGl0c2VsZiBtaWdodCBjb250YWluIHNlbnNpdGl2ZSBkYXRhIGxpa2Ug YW4gYWNjb3VudCBudW1iZXIgb3IgdHJhbnNhY3Rpb24gaWRlbnRpZmllciAoZS5nLiBzb21ldGhp bmcgbGlrZSAiYWNjdDoxMjM0NTY3ODkiIG9yICJ0eDo5ODc2NTQzMjEiKS4gVGhpcyBpcyBzb21l d2hhdCB1bmNvbW1vbiBpbiBwcmFjdGljZSB0b2RheSBidXQgZG9lcyBoYXBwZW4gaW4gc29tZSBz aXR1YXRpb25zLiBUaGUgc2FtZSBwcmluY2lwYWwgb2YgbGltaXRpbmcgdGhlIHNjb3BlcyByZXZl YWxlZCBhY3Jvc3MgZGlmZmVyZW50IHNlcnZpY2VzIGFwcGxpZXMgaGVyZSB0b28gYnV0IHdpdGgg YXJndWFibHkgd29yc2UgY29uc2VxdWVuY2VzIGR1ZSB0byB0aGUgc2Vuc2l0aXZlIGRhdGEgd2l0 aGluIHRoZSBzY29wZSB2YWx1ZS4gSXQncyB0aGUgc2FtZSBjb25jZXB0IHRob3VnaCBhbmQgSSB0 aGluayB0aGUgbWVudGlvbiBvZiBjb25maWRlbnRpYWwgZGF0YSBhbmQgc2NvcGUgaGVyZSBpbiB0 aGUgZG9jdW1lbnQgaXMgbW9yZSBsaWtlbHkgY2F1c2UgY29uZnVzaW9uIHRoYW4gaXQgaXMgdG8g aGVscCBhbnl0aGluZy4gQXMgc3VjaCwgSSdtIHByb3Bvc2luZyB0byBjaGFuZ2UgdGhhdCBzZW50 ZW5jZSBhcyBmb2xsb3dzIHRvIHJlbW92ZSB0aGUgY29uZmlkZW50aWFsIGJpdCBhbmQgc29tZXdo YXQgYmV0dGVyIGRlc2NyaWJlIHRoZSBjcm9zcy1zZXJ2aWNlIHNjb3BlIHJldmVhbGluZyBpc3N1 ZS4NCg0KICAgICAgIlRoaXMgZnVydGhlciBpbXByb3ZlcyBwcml2YWN5IGFzIHNjb3BlIHZhbHVl cyBnaXZlIGFuIGluZGljYXRpb24gb2Ygd2hhdCBzZXJ2aWNlcyB0aGUgcmVzb3VyY2UNCiAgICAg IG93bmVyIHVzZXMgYW5kIGRvd25zY29waW5nIGEgdG9rZW4gdG8gb25seSB0aGF0IHdoaWNoIGlz IG5lZWRlZCBmb3IgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgY2FuDQogICAgICBsaW1pdCB0aGUgZXh0 ZW50IHRvIHdoaWNoIHN1Y2ggaW5mb3JtYXRpb24gaXMgcmV2ZWFsZWQgYWNyb3NzIGRpZmZlcmVu dCBzZXJ2aWNlcy4iDQoNCltSb21hbl0gIFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uIHJlbGF0 aXZlIHRvIG15IGFuYWxvZ3kuICBJIGFncmVlIHRoYXQgdGhlIHByb3Bvc2VkIHRleHQgYWJvdmUg aXMgYSBsb3QgY2xlYXJlciBhbmQgaXQgYWRkcmVzc2VzIG15IGNvbmNlcm4uDQoNClJvbWFuDQoN Cg0KT24gU3VuLCBKdWwgMjEsIDIwMTkgYXQgNDo1MyBQTSBSb21hbiBEYW55bGl3IDxyZGRAY2Vy dC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+IHdyb3RlOg0KSGkgQnJpYW4hDQoNClRoYW5rcyBm b3IgdGhlIHVwZGF0ZSBpbiAtMDMuICBUaGUgaXRlbSBiZWxvdyBpcyB0aGUgb25seSB0aGluZyB0 aGF0IHJlbWFpbnMgb3V0c3RhbmRpbmcuDQoNClRoYW5rcywNClJvbWFuDQoNCg0KRnJvbTogUm9t YW4gRGFueWxpdw0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDY6MDUgUE0NClRvOiBC cmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPj4NCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMg0KDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTcs IDIwMTkgNDozNSBQTQ0KVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRk QGNlcnQub3JnPj4NCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycy0wMg0KDQpbc25pcF0NCg0KKDIpIFNlY3Rpb24gMi4yLiAgaW4gdGhlIHNl bnRlbmNlICJUbyB0aGUgZXh0ZW50IHBvc3NpYmxlLCB3aGVuIGlzc3VpbmcgYWNjZXNzIHRva2Vu cywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBhZGFwdCB0aGUgc2NvcGUgdmFsdWUg YXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgdmFsdWUgdGhlIHJlc3BlY3Rp dmUgcmVzb3VyY2UgaXMgYWJsZSB0byBwcm9jZXNzIGFuZCBuZWVkcyB0byBrbm93IjoNCg0KLS0g IGlzIHRoaXMgbGFuZ3VhZ2Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpcyBtb2RpZnlpbmcgdGhlIHNjb3BlIHZhbHVlIGJhc2VkIG9uIHRoZSByZXNvdXJjZSBpdCBz ZWVzPyAgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgImFkYXB0IiBtZWFucywgZXNwZWNp YWxseSBpbiByZWxhdGlvbiB0byB0aGUgaW1wcm92ZWQgc2VjdXJpdHkgYW5kIHByaXZhY3kgdGhl IHN1YnNlcXVlbnQgc2VudGVuY2Ugc3VnZ2VzdHMuDQoNClBlcmhhcHMgImFkYXB0IiB3YXNuJ3Qg dGhlIGJlc3QgY2hvaWNlIG9mIHdvcmQgYnV0IGl0J3MgbWVhbnQgdG8gc2F5IHRoYXQgYW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgd2l0aCBzdWZmaWNpZW50IHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBz Y29wZXMgYXJlIGFwcGxpY2FibGUgdG8gd2hhdCByZXNvdXJjZXMgKHdoaWNoIHdvbid0IGFsd2F5 cyBiZSB0aGUgY2FzZSBvciBldmVuIHBvc3NpYmxlIGJ1dCBzb21ldGltZXMpIGNvdWxkIGxpbWl0 IHRoZSBzY29wZSBhc3NvY2lhdGVkIHdpdGggYW4gYWNjZXNzIHRva2VuIChkb3duc2NvcGluZyBy ZWFsbHkpIHRvIG9ubHkgdGhlIHNjb3BlIHRoYXQgaXMgYXBwbGljYWJsZSB0byB0aGUgcmVzb3Vy Y2UuDQoNClNvbWUgb2YgdGhlIGV4YW1wbGVzIChmaWd1cmVzIDIgLSA2KSBhdHRlbXB0IHRvIHNo b3csIGFtb25nIG90aGVyIHRoaW5ncywgYSBoeXBvdGhldGljYWwgY2FzZSBvZiBob3cgdGhpcyBt aWdodCBnbyBkb3duLg0KDQpJbiBGaWd1cmUgMiB0aGUgaW5pdGlhbCBhdXRob3JpemF0aW9uIHJl cXVlc3QgdGhhdCdzIGFwcHJvdmVkIGhhcyBzY29wZSBvZiBjYWxlbmRhciAmIGNvbnRhY3RzIGFu ZCByZXNvdXJjZXMgaHR0cHM6Ly9jb250YWN0cy5leGFtcGxlLmNvbS8gJiBodHRwczovL2NhbC5l eGFtcGxlLmNvbS8NCg0KQSBzdWJzZXF1ZW50IGFjY2VzcyB0b2tlbiByZXF1ZXN0IChGaWd1cmUg MykgaGFzIHJlc291cmNlIGh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyBhbmQgdGhlIGlzc3VlZCBh Y2Nlc3MgdG9rZW4gc2NvcGUgKEZpZ3VyZSA0KSBpcyAiYWRhcHRlZCIgdG8gdGhhdCByZXNvdXJj ZSB0byBiZSBvbmx5IGNhbGVuZGFyDQoNCkFub3RoZXIgc3Vic2VxdWVudCBhY2Nlc3MgdG9rZW4g cmVxdWVzdCAoRmlndXJlIDUpIGhhcyByZXNvdXJjZSBodHRwczovL2NvbnRhY3RzLmV4YW1wbGUu Y29tLyBhbmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2NvcGUgKEZpZ3VyZSA2KSBpcyBkb3du c2NvcGVkIGJhc2VkIG9uIHRoYXQgcmVzb3VyY2UgdG8gYmUgb25seSBjb250YWN0cw0KDQpXb3Vs ZCBpdCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZCBpZiB0aGUgd29yZCAiZG93bnNjb3BlIiB3YXMg dXNlZCByYXRoZXIgdGhhbiAiYWRhcHQiPw0KDQpbUm9tYW5dIFVzaW5nIOKAnGRvd25zY29wZeKA nSBkb2VzIHdvcmsgZm9yIG1lLiAgSXQgY2FwdHVyZXMgdGhhdCB0aGUgc2VydmVyIGlzIGdvaW5n IHRvIHJlZHVjZSB0aGUgc2NvcGUgKGFuZCBjZXJ0YWlubHkgbm90IGV4cGFuZCBpdCkuDQoNCg0K LS0gKERlcGVuZGluZyBvbiB0aGUgYWJvdmUpIElzIHRoZXJlIGEgc2VjdXJpdHkgY29uc2lkZXJh dGlvbiBoZXJlIGZvciB0aGUgc2VydmVyIHJlbGF0aXZlIHRvIGNvbmZpZGVudGlhbCBzY29wZSB2 YWx1ZXMgYW5kIGhvdyB0aGV5IG1pZ2h0IGJlIG1vZGlmaWVkPw0KDQpJJ20gbm90IHN1cmUsIHRv IGJlIGhvbmVzdC4gRG93bnNjb3BwaW5nIHdoZW4gcG9zc2libGUgYW5kIHRvIHRoZSBleHRlbnQg cG9zc2libGUgaXMgdXN1YWxseSBhIGdvb2QgaWRlYSAobGVhc3QgcHJpdmlsZWdlIGFuZCBhbGwg dGhhdCkgYnV0IEkgdGhpbmsgbWF5YmUgSSdtIG1pc3NpbmcgeW91ciBwb2ludC9xdWVzdGlvbi4N Cg0KW1JvbWFuXSBZZXMsIGxlYXN0IHByaXZpbGVnZSB3YXMgcGFydCBvZiBpdCBhbmQgSSB0aGlu ayB0aGUgdGV4dCBhYm92ZSBnZXRzIGF0IGl0LiAgSG93ZXZlciwgdGhlIG90aGVyIHBhcnQgaXMg dGhlIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBuZXh0IHNlbnRlbmNlIGluIHRoZSBwYXJhZ3JhcGgs IOKAnFRoaXMgZnVydGhlciBpbXByb3ZlcyBwcml2YWN5IGFzIHNjb3BlIHZhbHVlcyBnaXZlIGFu IGluZGljYXRpb24gb2Ygd2hhdCBzZXJ2aWNlcyB0aGUgcmVzb3VyY2Ugb3duZXIgdXNlcyBhbmQg aXQgaW1wcm92ZXMgc2VjdXJpdHkgYXMgc2NvcGUgdmFsdWVzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBkYXRh4oCdLiAgSWYgdGhlIGluaXRpYWwgcmVxdWVzdCB3YXMgbm90aW9uYWxseSBhIHNj b3BlIG9mIOKAnGFsbCB0aGUgaG91c2VzIG9uIHRoZSBibG9ja+KAnSwgYnV0IHRoZSBzZXJ2ZXIg a25ldyB0aGF0IHRoaXMgcmVxdWVzdCB3YXMgdG9vIGJyb2FkIGFuZCBkb3duLXNjb3BlZCB0byDi gJxvbmx5IHRoZSBjb3JuZXIgaG91c2XigJ0sIHdvdWxkbuKAmXQgdGhpcyBhY3R1YWxseSBiZSB3 b3JzZSBmb3IgcHJpdmFjeT8gIEkgYWxzbyBkb27igJl0IGZvbGxvdyBob3cgcmVkdWNpbmcgdGhl IHNjb3BlIGltcGFjdHMgY29uZmlkZW50aWFsIGRhdGEuDQoNCg0KDQpDT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdl ZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyku IEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFA23marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBb bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSnVseSAyMiwgMjAxOSA4OjM3IEFNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3 ICZsdDtyZGRAY2VydC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1 dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgc29ycnkgYWJvdXQgdGhh dC4gSSByZWFsaXplZCB0aGlzIHllc3RlcmRheSBhbmQgYXMgPGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC8yc3MzaERhMHhQUXhhV2lXNnR4ajlXLXZw cW8iIHRhcmdldD0iX2JsYW5rIj4NCnRyaWVkIHRvIHdyaXRlIHF1aWNrbHkgZnJvbSBmcm9tIG15 IHBob25lIGp1c3QgYmVmb3JlIG15IGZsaWdodCB0b29rIG9mZiBmb3IgTW9udHJlYWw8L2E+LCBJ J2QgZ290dGVuIGRpc3RyYWN0ZWQgd2l0aCB0aGUgcXVlc3Rpb24gb2Ygd2hhdCB0byBkbyB3aXRo IHRoZSByZWdpc3RyYXRpb25zIGFuZCBsb3N0IHRyYWNrIG9mIHRoaXMgZm9yayBvZiB0aGUgdGhy ZWFkLiZuYnNwOyBUaGVyZSBhcmUgaW5kZWVkIGEgY291cGxlIG9mIG91dHN0YW5kaW5nIGJpdHMN CiB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGluIGEgLTA0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgY2hhbmdlIGFk YXB0IHRvIGRvd25zY29wZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NClJlZ2FyZGluZyB5b3VyIHVuYW5zd2VyZWQgcXVlc3Rpb25zIGZy b20gYmVsb3cgLSBwYXJ0aWFsbHkgcXVvdGVkIGhlcmUgZm9yIHJlZmVyZW5jZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+J0lmIHRoZSBpbml0 aWFsIHJlcXVlc3Qgd2FzIG5vdGlvbmFsbHkgYSBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNlcyBv biB0aGUgYmxvY2vigJ0sIGJ1dCB0aGUgc2VydmVyIGtuZXcgdGhhdCB0aGlzIHJlcXVlc3Qgd2Fz IHRvbyBicm9hZCBhbmQgZG93bi1zY29wZWQgdG8g4oCcb25seSB0aGUgY29ybmVyIGhvdXNl4oCd LCB3b3VsZG7igJl0IHRoaXMgYWN0dWFsbHkgYmUgd29yc2UgZm9yIHByaXZhY3k/JyAtJmd0OyB0 aGUgaWRlYSB0aGVyZQ0KIGlzIHByaXZhY3kgaW4gdGVybXMgb2YgbGltaXRpbmcgd2hhdCBvbmUg c2VydmljZSBwb3RlbnRpYWxseSBsZWFucyBhYm91dCBvdGhlciBzZXJ2aWNlcyB0aGUgdXNlciBp cyB1c2luZy4gSW4gdGhlIGhvdXNlcyBvbiB0aGUgYmxvY2sgY2FzZSB5b3UgbWVudGlvbmVkLCB0 aGUgZG93bnNjb3BpbmcgcHJldmVudHMgdGhlIGNvcm5lciBob3VzZSBmcm9tIGxlYXJuaW5nIHRo YXQgdGhlIHVzZXIgYWxzbyBhY2Nlc3NlcyB0aGUgb3RoZXIgaG91c2VzIG9uDQogdGhlIGJsb2Nr LiA8YnI+DQo8YnI+DQonSSBhbHNvIGRvbuKAmXQgZm9sbG93IGhvdyByZWR1Y2luZyB0aGUgc2Nv cGUgaW1wYWN0cyBjb25maWRlbnRpYWwgZGF0YS4nIC0mZ3Q7IHRvIGJlIGhvbmVzdCwgdGhpcyBw YXJ0aWN1bGFyIHRleHQgY2FtZSBhcyBhIHN1Z2dlc3Rpb24gZnJvbSBhbm90aGVyIFdHIG1lbWJl ciBvbiByZXZpZXcgb2YgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4gU28gSSBz dHJ1Z2dsZSBhIGJpdCB0byBkZWZlbmQvZXhwbGFpbiBpdCBidXQgSSB0aGluayB0aGUNCiBpZGVh IGlzIHRoYXQgaW4gc29tZSBjYXNlcyBhIHNjb3BlIHZhbHVlIGl0c2VsZiBtaWdodCBjb250YWlu IHNlbnNpdGl2ZSBkYXRhIGxpa2UgYW4gYWNjb3VudCBudW1iZXIgb3IgdHJhbnNhY3Rpb24gaWRl bnRpZmllciAoZS5nLiBzb21ldGhpbmcgbGlrZSAmcXVvdDthY2N0OjEyMzQ1Njc4OSZxdW90OyBv ciAmcXVvdDt0eDo5ODc2NTQzMjEmcXVvdDspLiBUaGlzIGlzIHNvbWV3aGF0IHVuY29tbW9uIGlu IHByYWN0aWNlIHRvZGF5IGJ1dCBkb2VzIGhhcHBlbiBpbiBzb21lIHNpdHVhdGlvbnMuDQogVGhl IHNhbWUgcHJpbmNpcGFsIG9mIGxpbWl0aW5nIHRoZSBzY29wZXMgcmV2ZWFsZWQgYWNyb3NzIGRp ZmZlcmVudCBzZXJ2aWNlcyBhcHBsaWVzIGhlcmUgdG9vIGJ1dCB3aXRoIGFyZ3VhYmx5IHdvcnNl IGNvbnNlcXVlbmNlcyBkdWUgdG8gdGhlIHNlbnNpdGl2ZSBkYXRhIHdpdGhpbiB0aGUgc2NvcGUg dmFsdWUuIEl0J3MgdGhlIHNhbWUgY29uY2VwdCB0aG91Z2ggYW5kIEkgdGhpbmsgdGhlIG1lbnRp b24gb2YgY29uZmlkZW50aWFsIGRhdGEgYW5kDQogc2NvcGUgaGVyZSBpbiB0aGUgZG9jdW1lbnQg aXMgbW9yZSBsaWtlbHkgY2F1c2UgY29uZnVzaW9uIHRoYW4gaXQgaXMgdG8gaGVscCBhbnl0aGlu Zy4gQXMgc3VjaCwgSSdtIHByb3Bvc2luZyB0byBjaGFuZ2UgdGhhdCBzZW50ZW5jZSBhcyBmb2xs b3dzIHRvIHJlbW92ZSB0aGUgY29uZmlkZW50aWFsIGJpdCBhbmQgc29tZXdoYXQgYmV0dGVyIGRl c2NyaWJlIHRoZSBjcm9zcy1zZXJ2aWNlIHNjb3BlIHJldmVhbGluZyBpc3N1ZS4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmcXVvdDtUaGlzIGZ1cnRoZXIgaW1wcm92ZXMgcHJpdmFjeSBhcyBzY29wZSB2 YWx1ZXMgZ2l2ZSBhbiBpbmRpY2F0aW9uIG9mIHdoYXQgc2VydmljZXMgdGhlIHJlc291cmNlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3duZXIgdXNlcyBhbmQgZG93bnNjb3BpbmcgYSB0b2tl biB0byBvbmx5IHRoYXQgd2hpY2ggaXMgbmVlZGVkIGZvciBhIHBhcnRpY3VsYXIgc2VydmljZSBj YW4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbWl0IHRoZSBleHRlbnQgdG8gd2hpY2gg c3VjaCBpbmZvcm1hdGlvbiBpcyByZXZlYWxlZCBhY3Jvc3MgZGlmZmVyZW50IHNlcnZpY2VzLiZx dW90Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUm9tYW5dJm5i c3A7IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uIHJlbGF0aXZlIHRvIG15IGFuYWxvZ3kuJm5i c3A7IEkgYWdyZWUgdGhhdCB0aGUgcHJvcG9zZWQgdGV4dCBhYm92ZSBpcyBhIGxvdCBjbGVhcmVy IGFuZCBpdCBhZGRyZXNzZXMgbXkgY29uY2Vybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlJvbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3Vu LCBKdWwgMjEsIDIwMTkgYXQgNDo1MyBQTSBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVmPSJtYWls dG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJy aWFuITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyBmb3IgdGhlIHVwZGF0ZSBpbiAtMDMuJm5ic3A7IFRoZSBpdGVtIGJlbG93IGlzIHRoZSBvbmx5 IHRoaW5nIHRoYXQgcmVtYWlucyBvdXRzdGFuZGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9tYW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTQyNzAyMjY1NTE4NTIwMzY4ODlfbV81OTQ5NTg5 MzQ3MTY2OTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xv cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJl bnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuIERhbnlsaXcNCjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTkgNjowNSBQTTxicj4NCjxiPlRvOjwvYj4g QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRI LVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVu dGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAxNywgMjAxOSA0 OjM1IFBNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVmPSJtYWlsdG86 cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBB RCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bc25p cF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJn YigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oMikgU2VjdGlvbiAyLjIu Jm5ic3A7IGluIHRoZSBzZW50ZW5jZSAmcXVvdDtUbyB0aGUgZXh0ZW50IHBvc3NpYmxlLCB3aGVu IGlzc3VpbmcgYWNjZXNzIHRva2VucywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBh ZGFwdCB0aGUgc2NvcGUgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiB0byB0 aGUNCiB2YWx1ZSB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSBpcyBhYmxlIHRvIHByb2Nlc3MgYW5k IG5lZWRzIHRvIGtub3cmcXVvdDs6PGJyPg0KPGJyPg0KLS0mbmJzcDsgaXMgdGhpcyBsYW5ndWFn ZSBzdWdnZXN0aW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIG1vZGlmeWluZyB0 aGUgc2NvcGUgdmFsdWUgYmFzZWQgb24gdGhlIHJlc291cmNlIGl0IHNlZXM/Jm5ic3A7IEknbSB0 cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0ICZxdW90O2FkYXB0JnF1b3Q7IG1lYW5zLCBlc3BlY2lh bGx5IGluIHJlbGF0aW9uIHRvIHRoZSBpbXByb3ZlZCBzZWN1cml0eSBhbmQgcHJpdmFjeSB0aGUg c3Vic2VxdWVudCBzZW50ZW5jZSBzdWdnZXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QZXJoYXBzICZxdW90O2FkYXB0 JnF1b3Q7IHdhc24ndCB0aGUgYmVzdCBjaG9pY2Ugb2Ygd29yZCBidXQgaXQncyBtZWFudCB0byBz YXkgdGhhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRoIHN1ZmZpY2llbnQgdW5kZXJzdGFu ZGluZyBvZiB3aGF0IHNjb3BlcyBhcmUgYXBwbGljYWJsZSB0byB3aGF0IHJlc291cmNlcyAod2hp Y2gNCiB3b24ndCBhbHdheXMgYmUgdGhlIGNhc2Ugb3IgZXZlbiBwb3NzaWJsZSBidXQgc29tZXRp bWVzKSBjb3VsZCBsaW1pdCB0aGUgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tl biAoZG93bnNjb3BpbmcgcmVhbGx5KSB0byBvbmx5IHRoZSBzY29wZSB0aGF0IGlzIGFwcGxpY2Fi bGUgdG8gdGhlIHJlc291cmNlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb21lIG9mIHRoZSBleGFtcGxlcyAoZmlndXJl cyAyIC0gNikgYXR0ZW1wdCB0byBzaG93LCBhbW9uZyBvdGhlciB0aGluZ3MsIGEgaHlwb3RoZXRp Y2FsIGNhc2Ugb2YgaG93IHRoaXMgbWlnaHQgZ28gZG93bi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gRmlndXJlIDIgdGhlIGlu aXRpYWwgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRoYXQncyBhcHByb3ZlZCBoYXMgc2NvcGUgb2Yg Y2FsZW5kYXIgJmFtcDsgY29udGFjdHMgYW5kIHJlc291cmNlcw0KPGEgaHJlZj0iaHR0cHM6Ly9j b250YWN0cy5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvbnRhY3RzLmV4 YW1wbGUuY29tLzwvYT4gJmFtcDsNCjxhIGhyZWY9Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLzwvYT4gPG86cD4NCjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgc3Vic2Vx dWVudCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCAoRmlndXJlIDMpIGhhcyByZXNvdXJjZQ0KPGEgaHJl Zj0iaHR0cHM6Ly9jYWwuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jYWwu ZXhhbXBsZS5jb20vPC9hPiBhbmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2NvcGUgKEZpZ3Vy ZSA0KSBpcyAmcXVvdDthZGFwdGVkJnF1b3Q7IHRvIHRoYXQgcmVzb3VyY2UgdG8gYmUgb25seSBj YWxlbmRhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFub3RoZXIgc3Vic2VxdWVudCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCAo RmlndXJlIDUpIGhhcyByZXNvdXJjZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jb250YWN0cy5leGFtcGxl LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvbnRhY3RzLmV4YW1wbGUuY29tLzwvYT4g YW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3BlIChGaWd1cmUgNikgaXMgZG93bnNjb3Bl ZCBiYXNlZCBvbiB0aGF0IHJlc291cmNlIHRvIGJlIG9ubHkgY29udGFjdHM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvdWxkIGl0IGJl IGVhc2llciB0byB1bmRlcnN0YW5kIGlmIHRoZSB3b3JkICZxdW90O2Rvd25zY29wZSZxdW90OyB3 YXMgdXNlZCByYXRoZXIgdGhhbiAmcXVvdDthZGFwdCZxdW90Oz8NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSBVc2luZyDigJxkb3duc2NvcGXigJ0gZG9l cyB3b3JrIGZvciBtZS4mbmJzcDsgSXQgY2FwdHVyZXMgdGhhdCB0aGUgc2VydmVyIGlzIGdvaW5n IHRvIHJlZHVjZSB0aGUgc2NvcGUNCiAoYW5kIGNlcnRhaW5seSBub3QgZXhwYW5kIGl0KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQotLSAoRGVwZW5kaW5nIG9uIHRoZSBhYm92ZSkgSXMgdGhlcmUg YSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGhlcmUgZm9yIHRoZSBzZXJ2ZXIgcmVsYXRpdmUgdG8g Y29uZmlkZW50aWFsIHNjb3BlIHZhbHVlcyBhbmQgaG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSdtIG5vdCBzdXJlLCB0byBiZSBob25lc3QuIERvd25zY29wcGluZyB3aGVuIHBv c3NpYmxlIGFuZCB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIGlzIHVzdWFsbHkgYSBnb29kIGlkZWEg KGxlYXN0IHByaXZpbGVnZSBhbmQgYWxsIHRoYXQpIGJ1dCBJIHRoaW5rIG1heWJlIEknbSBtaXNz aW5nIHlvdXIgcG9pbnQvcXVlc3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDo1LjE1cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21hbl0gWWVzLCBs ZWFzdCBwcml2aWxlZ2Ugd2FzIHBhcnQgb2YgaXQgYW5kIEkgdGhpbmsgdGhlIHRleHQgYWJvdmUg Z2V0cyBhdCBpdC4mbmJzcDsgSG93ZXZlciwgdGhlIG90aGVyIHBhcnQgaXMgdGhlIHJlbGF0aW9u c2hpcCB3aXRoIHRoZSBuZXh0IHNlbnRlbmNlIGluIHRoZSBwYXJhZ3JhcGgsIOKAnFRoaXMgZnVy dGhlcg0KIGltcHJvdmVzIHByaXZhY3kgYXMgc2NvcGUgdmFsdWVzIGdpdmUgYW4gaW5kaWNhdGlv biBvZiB3aGF0IHNlcnZpY2VzIHRoZSByZXNvdXJjZSBvd25lciB1c2VzIGFuZCBpdCBpbXByb3Zl cyBzZWN1cml0eSBhcyBzY29wZSB2YWx1ZXMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGRhdGHi gJ0uJm5ic3A7IElmIHRoZSBpbml0aWFsIHJlcXVlc3Qgd2FzIG5vdGlvbmFsbHkgYSBzY29wZSBv ZiDigJxhbGwgdGhlIGhvdXNlcyBvbiB0aGUgYmxvY2vigJ0sIGJ1dCB0aGUgc2VydmVyDQoga25l dyB0aGF0IHRoaXMgcmVxdWVzdCB3YXMgdG9vIGJyb2FkIGFuZCBkb3duLXNjb3BlZCB0byDigJxv bmx5IHRoZSBjb3JuZXIgaG91c2XigJ0sIHdvdWxkbuKAmXQgdGhpcyBhY3R1YWxseSBiZSB3b3Jz ZSBmb3IgcHJpdmFjeT8mbmJzcDsgSSBhbHNvIGRvbuKAmXQgZm9sbG93IGhvdyByZWR1Y2luZyB0 aGUgc2NvcGUgaW1wYWN0cyBjb25maWRlbnRpYWwgZGF0YS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNP TkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9z dXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFA23marchand_-- From nobody Mon Jul 22 06:30: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 83C5B120291 for ; Mon, 22 Jul 2019 06:30:49 -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 OSDI2oROrRrR for ; Mon, 22 Jul 2019 06:30:46 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAEE120286 for ; Mon, 22 Jul 2019 06:30:46 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpYOo-0007wt-J9; Mon, 22 Jul 2019 15:30:42 +0200 From: Torsten Lodderstedt Message-Id: <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_7E7AD628-0AF1-4EEA-9F2C-C8358004B51B"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 15:30:41 +0200 In-Reply-To: Cc: OAuth WG To: Aaron Parecki References: X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:30:50 -0000 --Apple-Mail=_7E7AD628-0AF1-4EEA-9F2C-C8358004B51B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Aaron,=20 thanks for your continued work on the topic.=20 Here are some general remarks on the current revision:=20 1) This BCP should not be limited to public clients. Your BCP itself = already describes an architecture where the OAuth client is a backend = that may be a confidential client (see section 6.2 for an example). The = text of the BCP generally seems to be inconsistent regarding oauth = client types. I suggest to remove the second part of the first paragraph of the = abstract (=E2=80=9Cand should not be issued a client secret when = registered.") and other statements limiting the BCP to public clients.=20= 2) Regarding architectures: I think this BCP should focus on = recommendations for securely implementing OAuth in the different = potential architecture. I don=E2=80=99t think we should get into the = business of recommending and assessing other solutions (e.g. section = 6.1.). Just to give you an example: Section 6.1. states=20 "OAuth and OpenID Connect provide very little benefit in this deployment = scenario, so it is recommended to reconsider whether you need OAuth or = OpenID Connect at all in this case.=E2=80=9D Really? What experiences is this statement based on? In my experience, = sharing the same domain =3D=3D host name tells you nothing about the = overall architecture of a certain deployment. There may be several = reasons why OAuth could be good choice in such a scenario, e.g. security = considerations (since your common domain is just a proxy server = encapsulating a whole universe of systems) or even modularity as an = architecture principle.=20 I suggest to remove section 6.1. and to rephrase the second paragraph of = the abstract. 3) The naming in section 6 focus on the ways the JS could be served. I = personally think the more important aspect is the architecture of the = overall application.=20 I suggest the following changes:=20 - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend - 6.3. Apps Served from a Static Web Server -> SPA without backend=20 Note: even an SPA with a backend could use a static web server to serve = the JS code. 4) I don=E2=80=99t understand why your BCP distinguishes 1st and 3rd = party apps. Neither the Native apps BCP nor security BCP do so and need = to. 5) Section 9.8 seems to duplicate portions of the Security BCP (while = not giving the complete threat model) - what is the benefit of = duplicating this text? 6) I think the BCP would benefit from a refactoring. One idea would be = to first state the problem with implicit and give general = recommendations (PKCE and so on). The latter part could get into details = of access and refresh token protection in the context of different SPA = architectures (mTLS, CORS for CSRF prevention, =E2=80=A6). kind regards, Torsten.=20 > On 9. Jul 2019, at 01:03, Aaron Parecki wrote: >=20 > Hi all, >=20 > I've just uploaded a new version of oauth-browser-based-apps in = preparation for the meeting in Montreal.=20 >=20 > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 >=20 > This draft incorporates much of the feedback I've received over the = last couple months, as well as what we discussed at the last meeting in = Prague. >=20 > The primary change is a significant rewrite and addition of Section 6 = to highlight the two common deployment patterns, a SPA with and without = a dynamic backend.=20 >=20 > Please have a look and let me know what you think. I have a slot in = the agenda for Montreal to present on this as well. >=20 > Thanks! >=20 > ---- > Aaron Parecki > aaronparecki.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7E7AD628-0AF1-4EEA-9F2C-C8358004B51B 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 Fw0xOTA3MjIxMzMwNDJaMC8GCSqGSIb3DQEJBDEiBCA9ts5HEIbPYxAhE7+2p0KeLn6yS6BuujUL KylZOCnbtzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAMyX0Xq64aXd35UhfyNQJEJ6AHO1Im3pts7zRYrtrlq+iNC5xXJM04jJo4tJ BGhCfhPW5D1qC6ioERcpXSwD+kGZIS4McgFyaasDx+/bJjI9xlhGw2DL99lZUhZWj/oqTw+JXa4P nKBCaXrDFCcqlf7mixQNd917CXeaHsXPGJ0zQdwTIAFlfz0w8nAEKZkl7SZEqYSe4yNu6IAyAvoc j2qqPWYNl+OZv610ClGjYcqJ39CzSr2KSv4InE1K1zUsaSg+O2jIl4K4uUipS99FcHqCEFsvJNad 4UXsr4vXEy+jlfetgmP1i2YAzHZ8Pysf5JL6HR5eKUrtaXnf7AGuKecAAAAAAAA= --Apple-Mail=_7E7AD628-0AF1-4EEA-9F2C-C8358004B51B-- From nobody Mon Jul 22 06:41: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 1F1BF1202B8 for ; Mon, 22 Jul 2019 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XNhRxBDEjzCH for ; Mon, 22 Jul 2019 06:41:46 -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 056E5120121 for ; Mon, 22 Jul 2019 06:41:46 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id h19so28819074wme.0 for ; Mon, 22 Jul 2019 06:41:45 -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=01Uim3GuuaAzBWPDJbRwN6tiCLJOMiQbpiMGiUaEX/A=; b=Z4MdVCV6ei360dF1NsUFuSGo0SHrXZsQyLK+zMa8xWTWoJipwIuIn6gOzdsRjX1r/H iKy9icJdOcNrjYI8ZrPNBRtmlM8h2Vfcds81mQtGfYOXPmTs+OKZKTpAQpFB+IF8SVnU nmHuHGF0n+eoUJHTqARvXiWo5mCwaEX2Pu2XU= 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=01Uim3GuuaAzBWPDJbRwN6tiCLJOMiQbpiMGiUaEX/A=; b=QShyyjZQ5IOcDnu0IBPhqzHh5BTudKVtDpFAxwFWtMImZXpx4rCH7Q0cDYIJrNp4Bi kdKTpDcNohvbN3OG2JjWfc4ubMvA7MlylUL0Ug3KdiYD4QgDsgLrAU4iJIc4N6vczC9K qXTnHw9IXMry9L1seGvn8LTOkQDolTJjinrjW/YEva6xffiVY+nUJTtPuMu5LAU9YVmm 1dxjVvxC7U4H08/pSTGurmMQuKECyCFnoMBJpsRrCZzLDhbP4lE1qdhYQIojkIrZyXig gN6iTMLIpMSe7XEZWxbWmEjQwooqAWv87q5OuUVmjXgMkrbjFR0oQcePdjUJcZkkdGgN dPhw== X-Gm-Message-State: APjAAAX4svMQIY28V88S4l39QNa3pl/WO78VCiMDL8iWeNIPPC1M4PHD qhytT7ChWT+cR1Slx/T97BncRw== X-Google-Smtp-Source: APXvYqx765GuylfW5HtFICdmLxcqG7K5S1K4LpuNYWh7oNzWJdWqibjqh5vXhPfP8L0hoFTEpjuzcA== X-Received: by 2002:a1c:c545:: with SMTP id v66mr65493712wmf.51.1563802904395; Mon, 22 Jul 2019 06:41:44 -0700 (PDT) Received: from [192.168.1.64] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id f3sm23642206wrt.56.2019.07.22.06.41.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:41:43 -0700 (PDT) From: Neil Madden Message-Id: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 14:41:41 +0100 In-Reply-To: Cc: Aaron Parecki , oauth To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 13:41:52 -0000 --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jul 2019, at 22:22, Dick Hardt wrote: >=20 > Hi Neil, I agree that an access token that is usable across resources = is problematic. >=20 > How are you thinking multiple access tokens would be returned? Well there are lots of possible ways, e.g.: { "tokens": [ { "resource": "https://res1", "access_token": "..." },=20 { "resource": "res2", ...}, ... ] } I'm not particularly wedded to any format. > Why do you think the request needs to return multiple tokens rather = than making a separate request for each token? That would seem to = simplify the request and response as context would only need to provided = for the one access token. Note that in Aaron's proposal we have a "user" section on (presumably) = every access token response, which indicates a userinfo endpoint that = itself needs an access token. So either the same access token is used to = access that userinfo endpoint (which means that the RS can also access = the userinfo endpoint), or else we already need to return a second = access token in the same request, e.g.: { "access_token": { "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type": "bearer" }, "user": { "id": "5035678642", "userinfo": "https://authorization-server.com/user/5035678642 = ", "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk" } } >=20 >=20 >=20 > On Fri, Jul 19, 2019 at 11:42 PM Neil Madden = > wrote: > If we=E2=80=99re going to redesign OAuth, one improvement would be to = allow a client to request different access tokens for different resource = servers in a single request. That should include issuing a different = access token for the userinfo endpoint vs other RSes.=20 >=20 > One of the weaknesses of combined OAuth + OIDC use now is that if you = request OIDC scopes and scopes for another resource in the same request = then you inadvertently give those other RSes access to the user=E2=80=99s = profile.=20 >=20 > =E2=80=94 Neil >=20 > On 20 Jul 2019, at 01:02, Aaron Parecki > wrote: >=20 >> Hi all, I'm looking forward to the discussion on this on Tuesday! >>=20 >> I wanted to add my thoughts on a potential addition to this draft, = specifically around returning some minimal user information in the = transaction response. >>=20 >> The summary of the suggestion is to return a new "user" key along = with the access token that contains the user ID and userinfo endpoint, = such as: >>=20 >> { >> "access_token": { >> "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type": "bearer" >> }, >> "user": { >> "id": "5035678642", >> "userinfo": "https://authorization-server.com/user/5035678642 = " >> } >> } >>=20 >> A more detailed analysis of the specific proposal and motivation = behind this is available on my blog: >>=20 >> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz = >>=20 >> Thanks! >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >>=20 >>=20 >> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer > wrote: >> I have requested time to present Transactional Authorization (the XYZ = project) at the Montreal meeting in a couple weeks. Ahead of that, = I=E2=80=99ve uploaded a new version of the spec: >>=20 >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 = >>=20 >> Additionally, I=E2=80=99ve updated the writeup and examples on = https://oauth.xyz/ =20 >>=20 >> I plan to be in Montreal for the whole week, and I=E2=80=99ve = requested from the chairs that I present during the Tuesday session due = to limited availability of some key WG members on Friday.=20 >>=20 >> =E2=80=94 Justin >>=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 = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 21 Jul 2019, at 22:22, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Neil, I agree that an access token that is usable across = resources is problematic.

How are you thinking multiple access tokens would be = returned?

Well there are lots of possible ways, = e.g.:

{
"tokens": = [
    { "resource": "https://res1", "access_token": "..." = }, 
    { "resource": "res2", ...}, = ...
]
}

I'm not = particularly wedded to any format.

Why do you think the request = needs to return multiple tokens rather than making a separate request = for each token? That would seem to simplify the request and response as = context would only need to provided for the one access = token.

Note = that in Aaron's proposal we have a "user" section on (presumably) every = access token response, which indicates a userinfo endpoint that itself = needs an access token. So either the same access token is used to access = that userinfo endpoint (which means that the RS can also access the = userinfo endpoint), or else we already need to return a second access = token in the same request, e.g.:

{
  =     "access_token": {
        "value": = "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =       "type": "bearer"
      },
      "user": {
  =       "id": "5035678642",
  =       "userinfo": "https://authorization-server.com/user/5035678642",
        = "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
      }
    }




On Fri, Jul 19, 2019 at 11:42 PM Neil = Madden <neil.madden@forgerock.com> wrote:
If we=E2=80=99re = going to redesign OAuth, one improvement would be to allow a client to = request different access tokens for different resource servers in a = single request. That should include issuing a different access token for = the userinfo endpoint vs other RSes. 

One of the = weaknesses of combined OAuth + OIDC use now is that if you request OIDC = scopes and scopes for another resource in the same request then you = inadvertently give those other RSes access to the user=E2=80=99s = profile. 

=E2=80=94 Neil
On 20 Jul 2019, at 01:02, Aaron Parecki <aaron@parecki.com> wrote:

Hi all, I'm looking forward to = the discussion on this on Tuesday!

I wanted to add my thoughts on a = potential addition to this draft, specifically around returning some = minimal user information in the transaction response.

The summary of the = suggestion is to return a new "user" key along with the access token = that contains the user ID and userinfo endpoint, such as:

    {
      "access_token": {
        "value": = "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =       "type": "bearer"
  =     },
      "user": = {
        "id": "5035678642",
        "userinfo": "https://authorization-server.com/user/5035678642"
      }
  =   }

A more detailed analysis of the specific proposal and = motivation behind this is available on my blog:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jricher@mit.edu> wrote:
I have requested time to present Transactional Authorization (the XYZ = project) at the Montreal meeting in a couple weeks. Ahead of that, = I=E2=80=99ve uploaded a new version of the spec:

https://tools.ietf.org/html/draft-richer-transactional-authz-02=

Additionally, I=E2=80=99ve updated the writeup and = examples on https://oauth.xyz/ 

I plan to be in Montreal for the whole week, and I=E2=80=99= ve requested from the chairs that I present during the Tuesday session = due to limited availability of some key WG members on = Friday. 

=E2=80=94 Justin

_______________________________________________
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

= --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C-- From nobody Mon Jul 22 06:43:08 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 395D512029A; Mon, 22 Jul 2019 06:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <156380297513.28029.385356513299449196@ietfa.amsl.com> Date: Mon, 22 Jul 2019 06:42:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:43:01 -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 : Resource Indicators for OAuth 2.0 Authors : Brian Campbell John Bradley Hannes Tschofenig Filename : draft-ietf-oauth-resource-indicators-04.txt Pages : 13 Date : 2019-07-22 Abstract: An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 06:47: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 969B31201E2 for ; Mon, 22 Jul 2019 06:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJjOoQIiykTW for ; Mon, 22 Jul 2019 06:47:26 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFF112029E for ; Mon, 22 Jul 2019 06:47:26 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k8so74061716iot.1 for ; Mon, 22 Jul 2019 06:47:26 -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=1rrm6kzQz6NVKg5rloXURSdGTgxm7kpT5NNQQZL2nLo=; b=HehFZw+af4lUN9YrcJLXVGtM4UDoVdXv7DUHuBbZZeV3VmXD8rZl7uxaTGPjoo+t4Z 06/WPBuKbUrNnU1LtDVrZ0LgTf65n44CAYhQPRkh2rYkxZFClVutDBClIaYUXEu0/oYo FzRa3Hb6NTa17x06ZCq/D8SUHRMbwrSdMbHZo= 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=1rrm6kzQz6NVKg5rloXURSdGTgxm7kpT5NNQQZL2nLo=; b=qrP2lyXoDepxzyokR8QaBSecyloSWDQYeefuXqSEq6gwSU+U6e3QDcy9UskWQkWI9T i4dZUzpE/yHkq8WibnR467Kt9EE7qqTxFr9nHdIq+e8usowNp4GEF/FSRqmqOvyXbvZH vTdpdpC/Ca4u0FRLHEevYR3ugxchz7qlqGK0D+ppVZCm9lHQbzhBuvAONhXUqxgN3rBJ mJgpcES91SNZwve9g9gx56Y7VC+6zi86tExTeg9diuSbP1C7WARuz/jSYMxddCNSMt4p zNljhKDScWHcgdg6ljki+najsHTvyRA2fx1IKdDToCtwHuvUK444x/f77Ff325vHCFVE CAjA== X-Gm-Message-State: APjAAAWO1PtRokeMpj45QkBykd0YcNXeKtt5e+3NKEtisrpPvWh6+DUn dqCuBzqwhJl3GBcxXFTm/jhVRaut5rg2n3+++uWJEWW7zoHtBEH925hYq9iCYNSZs8lfHGxDdju PfhJo5OB9tv8eKEERjXngCQ== X-Google-Smtp-Source: APXvYqwJIG+dEyhXi3dYRJD5ejWOMYsz4lZNj+wJ+sR8z7sZ0M0LR13jPOgwEIIHgfVAeKgKZQP3GLl53cCt1c6et7k= X-Received: by 2002:a5d:87c6:: with SMTP id q6mr43488023ios.115.1563803245794; Mon, 22 Jul 2019 06:47:25 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DFA23@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33DFA23@marchand> From: Brian Campbell Date: Mon, 22 Jul 2019 07:46:59 -0600 Message-ID: To: Roman Danyliw Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6f2ab058e455030" Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:47:38 -0000 --000000000000f6f2ab058e455030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks again for sticking with me through this one with and associated registry updates with token exchange as well as my temporarily overlooking some needed changes. -04 is now up and this time I think I've actually addressed all your comments. On Mon, Jul 22, 2019 at 7:11 AM Roman Danyliw wrote: > Hi Brian! > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, July 22, 2019 8:37 AM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > Yes, sorry about that. I realized this yesterday and as tried to write > quickly from from my phone just before my flight took off for Montreal > = , > I'd gotten distracted with the question of what to do with the > registrations and lost track of this fork of the thread. There are indee= d > a couple of outstanding bits that need to be addressed in a -04. > > > > I'll change adapt to downscope. > > > Regarding your unanswered questions from below - partially quoted here fo= r > reference: > > > > 'If the initial request was notionally a scope of =E2=80=9Call the houses= on the > block=E2=80=9D, but the server knew that this request was too broad and d= own-scoped > to =E2=80=9Conly the corner house=E2=80=9D, wouldn=E2=80=99t this actuall= y be worse for privacy?' > -> the idea there is privacy in terms of limiting what one service > potentially leans about other services the user is using. In the houses o= n > the block case you mentioned, the downscoping prevents the corner house > from learning that the user also accesses the other houses on the block. > > 'I also don=E2=80=99t follow how reducing the scope impacts confidential = data.' -> > to be honest, this particular text came as a suggestion from another WG > member on review of an earlier version of the document. So I struggle a b= it > to defend/explain it but I think the idea is that in some cases a scope > value itself might contain sensitive data like an account number or > transaction identifier (e.g. something like "acct:123456789" or > "tx:987654321"). This is somewhat uncommon in practice today but does > happen in some situations. The same principal of limiting the scopes > revealed across different services applies here too but with arguably wor= se > consequences due to the sensitive data within the scope value. It's the > same concept though and I think the mention of confidential data and scop= e > here in the document is more likely cause confusion than it is to help > anything. As such, I'm proposing to change that sentence as follows to > remove the confidential bit and somewhat better describe the cross-servic= e > scope revealing issue. > > > > "This further improves privacy as scope values give an indication o= f > what services the resource > owner uses and downscoping a token to only that which is needed for > a particular service can > > limit the extent to which such information is revealed across > different services." > > > > [Roman] Thanks for the explanation relative to my analogy. I agree that > the proposed text above is a lot clearer and it addresses my concern. > > > > Roman > > > > > > On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw wrote: > > Hi Brian! > > > > Thanks for the update in -03. The item below is the only thing that > remains outstanding. > > > > Thanks, > > Roman > > > > > > *From:* Roman Danyliw > *Sent:* Wednesday, July 17, 2019 6:05 PM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* RE: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Wednesday, July 17, 2019 4:35 PM > *To:* Roman Danyliw > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD Review: > draft-ietf-oauth-resource-indicators-02 > > > > [snip] > > > > (2) Section 2.2. in the sentence "To the extent possible, when issuing > access tokens, the authorization server should adapt the scope value > associated with an access token to the value the respective resource is > able to process and needs to know": > > -- is this language suggesting that the authorization server is modifyin= g > the scope value based on the resource it sees? I'm trying to understand > what "adapt" means, especially in relation to the improved security and > privacy the subsequent sentence suggests. > > > > Perhaps "adapt" wasn't the best choice of word but it's meant to say that > an authorization server with sufficient understanding of what scopes are > applicable to what resources (which won't always be the case or even > possible but sometimes) could limit the scope associated with an access > token (downscoping really) to only the scope that is applicable to the > resource. > > > > Some of the examples (figures 2 - 6) attempt to show, among other things, > a hypothetical case of how this might go down. > > > > In Figure 2 the initial authorization request that's approved has scope o= f > calendar & contacts and resources https://contacts.example.com/ & > https://cal.example.com/ > > > > A subsequent access token request (Figure 3) has resource > https://cal.example.com/ and the issued access token scope (Figure 4) is > "adapted" to that resource to be only calendar > > > > Another subsequent access token request (Figure 5) has resource > https://contacts.example.com/ and the issued access token scope (Figure > 6) is downscoped based on that resource to be only contacts > > > > Would it be easier to understand if the word "downscope" was used rather > than "adapt"? > > > > [Roman] Using =E2=80=9Cdownscope=E2=80=9D does work for me. It captures = that the server > is going to reduce the scope (and certainly not expand it). > > > > > -- (Depending on the above) Is there a security consideration here for th= e > server relative to confidential scope values and how they might be modifi= ed? > > > > I'm not sure, to be honest. Downscopping when possible and to the extent > possible is usually a good idea (least privilege and all that) but I thin= k > maybe I'm missing your point/question. > > > > [Roman] Yes, least privilege was part of it and I think the text above > gets at it. However, the other part is the relationship with the next > sentence in the paragraph, =E2=80=9CThis further improves privacy as scop= e values > give an indication of what services the resource owner uses and it improv= es > security as scope values may contain confidential data=E2=80=9D. If the = initial > request was notionally a scope of =E2=80=9Call the houses on the block=E2= =80=9D, but the > server knew that this request was too broad and down-scoped to =E2=80=9Co= nly the > corner house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privac= y? I also don=E2=80=99t > follow how reducing the scope impacts confidential data. > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=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._ --000000000000f6f2ab058e455030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Thanks again for sticking with me th= rough this one with and associated registry updates with token exchange as = well as my temporarily overlooking some needed changes.

-04 is now up and this time I think I've actually addres= sed all your comments.



On Mon, Jul = 22, 2019 at 7:11 AM Roman Danyliw <rdd@c= ert.org> wrote:

Hi Brian!

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Monday, July 22, 2019 8:37 AM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

Yes, sorry about that. I realized this yesterday and= as tried to write quickly from from my phone just before my flight took off fo= r Montreal, I'd gotten distracted with the question of what to do w= ith the registrations and lost track of this fork of the thread.=C2=A0 Ther= e are indeed a couple of outstanding bits that need to be addressed in a -04.

=C2=A0

I'll change adapt to downscope.


Regarding your unanswered questions from below - partially quoted here for = reference:

=C2=A0

'If the initial request was notionally a scope o= f =E2=80=9Call the houses on the block=E2=80=9D, but the server knew that t= his request was too broad and down-scoped to =E2=80=9Conly the corner house= =E2=80=9D, wouldn=E2=80=99t this actually be worse for privacy?' -> = the idea there is privacy in terms of limiting what one service potentially leans about o= ther services the user is using. In the houses on the block case you mentio= ned, the downscoping prevents the corner house from learning that the user = also accesses the other houses on the block.

'I also don=E2=80=99t follow how reducing the scope impacts confidentia= l data.' -> to be honest, this particular text came as a suggestion = from another WG member on review of an earlier version of the document. So = I struggle a bit to defend/explain it but I think the idea is that in some cases a scope value itself might contain sensitive da= ta like an account number or transaction identifier (e.g. something like &q= uot;acct:123456789" or "tx:987654321"). This is somewhat unc= ommon in practice today but does happen in some situations. The same principal of limiting the scopes revealed across different servic= es applies here too but with arguably worse consequences due to the sensiti= ve data within the scope value. It's the same concept though and I thin= k the mention of confidential data and scope here in the document is more likely cause confusion than it is to he= lp anything. As such, I'm proposing to change that sentence as follows = to remove the confidential bit and somewhat better describe the cross-servi= ce scope revealing issue.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 "This further improves pri= vacy as scope values give an indication of what services the resource
=C2=A0 =C2=A0 =C2=A0 owner uses and downscoping a token to only that which = is needed for a particular service can

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 limit the extent to w= hich such information is revealed across different services."

=C2=A0

[Roman]=C2=A0 Thanks for the exp= lanation relative to my analogy.=C2=A0 I agree that the proposed text above= is a lot clearer and it addresses my concern.

=C2=A0

Roman

=C2=A0

=C2=A0

On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw <rdd@cert.org> wrote:=

Hi Brian!

=C2=A0

Thanks for the update in -03.=C2= =A0 The item below is the only thing that remains outstanding.

=C2=A0

Thanks,

Roman

=C2=A0

=C2=A0<= /p>

From: Roman Danyliw
Sent: Wednesday, July 17, 2019 6:05 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth@ietf.o= rg
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Wednesday, July 17, 2019 4:35 PM
To: Roman Danyliw <rdd@cert.org>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicat= ors-02

=C2=A0

[snip]

=C2=A0

(2) Section 2.2.=C2=A0 in the sentence "To the = extent possible, when issuing access tokens, the authorization server shoul= d adapt the scope value associated with an access token to the value the respective resource is able to process and needs to know":<= br>
--=C2=A0 is this language suggesting that the authorization server is modif= ying the scope value based on the resource it sees?=C2=A0 I'm trying to= understand what "adapt" means, especially in relation to the imp= roved security and privacy the subsequent sentence suggests.<= /p>

=C2=A0

Perhaps "adapt" wasn't the best choice= of word but it's meant to say that an authorization server with suffic= ient understanding of what scopes are applicable to what resources (which won't always be the case or even possible but sometimes) could limit t= he scope associated with an access token (downscoping really) to only the s= cope that is applicable to the resource.=C2=A0

=C2=A0

Some of the examples (figures 2 - 6) attempt to show= , among other things, a hypothetical case of how this might go down.

=C2=A0

In Figure 2 the initial authorization request that&#= 39;s approved has scope of calendar & contacts and resources https://contact= s.example.com/ & https://cal.example.= com/

=C2=A0

A subsequent access token request (Figure 3) has res= ource https://cal.example.= com/ and the issued access token scope (Figure 4) is "adapted"= ; to that resource to be only calendar

=C2=A0

Another subsequent access token request (Figure 5) h= as resource https://contact= s.example.com/ and the issued access token scope (Figure 6) is downscop= ed based on that resource to be only contacts

=C2=A0

Would it be easier to understand if the word "d= ownscope" was used rather than "adapt"?

=C2=A0

[Roman] Using =E2=80=9Cdownscope= =E2=80=9D does work for me.=C2=A0 It captures that the server is going to r= educe the scope (and certainly not expand it).

=C2=A0


-- (Depending on the above) Is there a security consideration here for the = server relative to confidential scope values and how they might be modified= ?

=C2=A0

I'm not sure, to be honest. Downscopping when po= ssible and to the extent possible is usually a good idea (least privilege a= nd all that) but I think maybe I'm missing your point/question.

=C2=A0

[Roman] Yes, least privilege was part of it and I think= the text above gets at it.=C2=A0 However, the other part is the relationsh= ip with the next sentence in the paragraph, =E2=80=9CThis further improves privacy as scope values give an indication of what services the r= esource owner uses and it improves security as scope values may contain con= fidential data=E2=80=9D.=C2=A0 If the initial request was notionally a scop= e of =E2=80=9Call the houses on the block=E2=80=9D, but the server knew that this request was too broad and down-scoped to =E2=80=9Conly the = corner house=E2=80=9D, wouldn=E2=80=99t this actually be worse for privacy?= =C2=A0 I also don=E2=80=99t follow how reducing the scope impacts confident= ial data.

=C2=A0

=C2=A0


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000f6f2ab058e455030-- From nobody Mon Jul 22 06: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 0658F120121 for ; Mon, 22 Jul 2019 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 N5jVstuAYBVg for ; Mon, 22 Jul 2019 06:50:37 -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 D6CA01200B5 for ; Mon, 22 Jul 2019 06:50:36 -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 x6MDoZG3003578; Mon, 22 Jul 2019 09:50:35 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6MDoZG3003578 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563803435; bh=reSce4njrNnsVTAnKqk+8QDA5+w5VNpmYFKeZCde26o=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MbsUp9GPwpynqlNXgPCKVNW4GN3k8CHPrm4sey8I9d0aHjheba8SduArq8ZOdwkaZ PCRb59Wk7rGK3CiUII4/GhCVnYVaN1/coLbmJ3uqs3TAP2TTkpPAdwkJzimAFV5abd xOXoH1kPskeOoc/bpOQaO8U624pmV2xQmFJofm9I= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6MDoVJM005631; Mon, 22 Jul 2019 09:50:31 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 09:50:30 -0400 From: Roman Danyliw To: Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfgA09hCAAAXZ8EAAv6ecgAAlQasAAAc72BD//9mbgIAAQkvA Date: Mon, 22 Jul 2019 13:50:30 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33DFE5E@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33D784A@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DEA6C@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33DFA23@marchand> In-Reply-To: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33DFE5Emarchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:50:40 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFE5Emarchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4hDQoNClRoZSAtMDQgdmVyc2lvbiBhZGRyZXNzZXMgbXkgcmVtYWluaW5nIGNvbmNl cm5lZC4gIFRoYW5rcyBmb3IgdGhpcyB1cGRhdGUuICBJ4oCZdmUgYWR2YW5jZWQgdGhlIGRvY3Vt ZW50IHRvIElFVEYgTEMuDQoNClJvbWFuDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMjIsIDIwMTkg OTo0NyBBTQ0KVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBvYXV0aEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRo LXJlc291cmNlLWluZGljYXRvcnMtMDINCg0KSGkgUm9tYW4sDQpUaGFua3MgYWdhaW4gZm9yIHN0 aWNraW5nIHdpdGggbWUgdGhyb3VnaCB0aGlzIG9uZSB3aXRoIGFuZCBhc3NvY2lhdGVkIHJlZ2lz dHJ5IHVwZGF0ZXMgd2l0aCB0b2tlbiBleGNoYW5nZSBhcyB3ZWxsIGFzIG15IHRlbXBvcmFyaWx5 IG92ZXJsb29raW5nIHNvbWUgbmVlZGVkIGNoYW5nZXMuDQoNCi0wNCBpcyBub3cgdXA8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9y cy0wND4gYW5kIHRoaXMgdGltZSBJIHRoaW5rIEkndmUgYWN0dWFsbHkgYWRkcmVzc2VkIGFsbCB5 b3VyIGNvbW1lbnRzLg0KDQoNCg0KT24gTW9uLCBKdWwgMjIsIDIwMTkgYXQgNzoxMSBBTSBSb21h biBEYW55bGl3IDxyZGRAY2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+IHdyb3RlOg0KSGkg QnJpYW4hDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPl0NClNlbnQ6IE1vbmRh eSwgSnVseSAyMiwgMjAxOSA4OjM3IEFNDQpUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3Jn PG1haWx0bzpyZGRAY2VydC5vcmc+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEFEIFJldmlldzogZHJhZnQtaWV0Zi1v YXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNClllcywgc29ycnkgYWJvdXQgdGhhdC4gSSBy ZWFsaXplZCB0aGlzIHllc3RlcmRheSBhbmQgYXMgdHJpZWQgdG8gd3JpdGUgcXVpY2tseSBmcm9t IGZyb20gbXkgcGhvbmUganVzdCBiZWZvcmUgbXkgZmxpZ2h0IHRvb2sgb2ZmIGZvciBNb250cmVh bDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoLzJzczNoRGEweFBR eGFXaVc2dHhqOVctdnBxbz4sIEknZCBnb3R0ZW4gZGlzdHJhY3RlZCB3aXRoIHRoZSBxdWVzdGlv biBvZiB3aGF0IHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJhdGlvbnMgYW5kIGxvc3QgdHJhY2sgb2Yg dGhpcyBmb3JrIG9mIHRoZSB0aHJlYWQuICBUaGVyZSBhcmUgaW5kZWVkIGEgY291cGxlIG9mIG91 dHN0YW5kaW5nIGJpdHMgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiBhIC0wNC4NCg0KSSds bCBjaGFuZ2UgYWRhcHQgdG8gZG93bnNjb3BlLg0KDQpSZWdhcmRpbmcgeW91ciB1bmFuc3dlcmVk IHF1ZXN0aW9ucyBmcm9tIGJlbG93IC0gcGFydGlhbGx5IHF1b3RlZCBoZXJlIGZvciByZWZlcmVu Y2U6DQoNCidJZiB0aGUgaW5pdGlhbCByZXF1ZXN0IHdhcyBub3Rpb25hbGx5IGEgc2NvcGUgb2Yg 4oCcYWxsIHRoZSBob3VzZXMgb24gdGhlIGJsb2Nr4oCdLCBidXQgdGhlIHNlcnZlciBrbmV3IHRo YXQgdGhpcyByZXF1ZXN0IHdhcyB0b28gYnJvYWQgYW5kIGRvd24tc2NvcGVkIHRvIOKAnG9ubHkg dGhlIGNvcm5lciBob3VzZeKAnSwgd291bGRu4oCZdCB0aGlzIGFjdHVhbGx5IGJlIHdvcnNlIGZv ciBwcml2YWN5PycgLT4gdGhlIGlkZWEgdGhlcmUgaXMgcHJpdmFjeSBpbiB0ZXJtcyBvZiBsaW1p dGluZyB3aGF0IG9uZSBzZXJ2aWNlIHBvdGVudGlhbGx5IGxlYW5zIGFib3V0IG90aGVyIHNlcnZp Y2VzIHRoZSB1c2VyIGlzIHVzaW5nLiBJbiB0aGUgaG91c2VzIG9uIHRoZSBibG9jayBjYXNlIHlv dSBtZW50aW9uZWQsIHRoZSBkb3duc2NvcGluZyBwcmV2ZW50cyB0aGUgY29ybmVyIGhvdXNlIGZy b20gbGVhcm5pbmcgdGhhdCB0aGUgdXNlciBhbHNvIGFjY2Vzc2VzIHRoZSBvdGhlciBob3VzZXMg b24gdGhlIGJsb2NrLg0KDQonSSBhbHNvIGRvbuKAmXQgZm9sbG93IGhvdyByZWR1Y2luZyB0aGUg c2NvcGUgaW1wYWN0cyBjb25maWRlbnRpYWwgZGF0YS4nIC0+IHRvIGJlIGhvbmVzdCwgdGhpcyBw YXJ0aWN1bGFyIHRleHQgY2FtZSBhcyBhIHN1Z2dlc3Rpb24gZnJvbSBhbm90aGVyIFdHIG1lbWJl ciBvbiByZXZpZXcgb2YgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4gU28gSSBz dHJ1Z2dsZSBhIGJpdCB0byBkZWZlbmQvZXhwbGFpbiBpdCBidXQgSSB0aGluayB0aGUgaWRlYSBp cyB0aGF0IGluIHNvbWUgY2FzZXMgYSBzY29wZSB2YWx1ZSBpdHNlbGYgbWlnaHQgY29udGFpbiBz ZW5zaXRpdmUgZGF0YSBsaWtlIGFuIGFjY291bnQgbnVtYmVyIG9yIHRyYW5zYWN0aW9uIGlkZW50 aWZpZXIgKGUuZy4gc29tZXRoaW5nIGxpa2UgImFjY3Q6MTIzNDU2Nzg5IiBvciAidHg6OTg3NjU0 MzIxIikuIFRoaXMgaXMgc29tZXdoYXQgdW5jb21tb24gaW4gcHJhY3RpY2UgdG9kYXkgYnV0IGRv ZXMgaGFwcGVuIGluIHNvbWUgc2l0dWF0aW9ucy4gVGhlIHNhbWUgcHJpbmNpcGFsIG9mIGxpbWl0 aW5nIHRoZSBzY29wZXMgcmV2ZWFsZWQgYWNyb3NzIGRpZmZlcmVudCBzZXJ2aWNlcyBhcHBsaWVz IGhlcmUgdG9vIGJ1dCB3aXRoIGFyZ3VhYmx5IHdvcnNlIGNvbnNlcXVlbmNlcyBkdWUgdG8gdGhl IHNlbnNpdGl2ZSBkYXRhIHdpdGhpbiB0aGUgc2NvcGUgdmFsdWUuIEl0J3MgdGhlIHNhbWUgY29u Y2VwdCB0aG91Z2ggYW5kIEkgdGhpbmsgdGhlIG1lbnRpb24gb2YgY29uZmlkZW50aWFsIGRhdGEg YW5kIHNjb3BlIGhlcmUgaW4gdGhlIGRvY3VtZW50IGlzIG1vcmUgbGlrZWx5IGNhdXNlIGNvbmZ1 c2lvbiB0aGFuIGl0IGlzIHRvIGhlbHAgYW55dGhpbmcuIEFzIHN1Y2gsIEknbSBwcm9wb3Npbmcg dG8gY2hhbmdlIHRoYXQgc2VudGVuY2UgYXMgZm9sbG93cyB0byByZW1vdmUgdGhlIGNvbmZpZGVu dGlhbCBiaXQgYW5kIHNvbWV3aGF0IGJldHRlciBkZXNjcmliZSB0aGUgY3Jvc3Mtc2VydmljZSBz Y29wZSByZXZlYWxpbmcgaXNzdWUuDQoNCiAgICAgICJUaGlzIGZ1cnRoZXIgaW1wcm92ZXMgcHJp dmFjeSBhcyBzY29wZSB2YWx1ZXMgZ2l2ZSBhbiBpbmRpY2F0aW9uIG9mIHdoYXQgc2VydmljZXMg dGhlIHJlc291cmNlDQogICAgICBvd25lciB1c2VzIGFuZCBkb3duc2NvcGluZyBhIHRva2VuIHRv IG9ubHkgdGhhdCB3aGljaCBpcyBuZWVkZWQgZm9yIGEgcGFydGljdWxhciBzZXJ2aWNlIGNhbg0K ICAgICAgbGltaXQgdGhlIGV4dGVudCB0byB3aGljaCBzdWNoIGluZm9ybWF0aW9uIGlzIHJldmVh bGVkIGFjcm9zcyBkaWZmZXJlbnQgc2VydmljZXMuIg0KDQpbUm9tYW5dICBUaGFua3MgZm9yIHRo ZSBleHBsYW5hdGlvbiByZWxhdGl2ZSB0byBteSBhbmFsb2d5LiAgSSBhZ3JlZSB0aGF0IHRoZSBw cm9wb3NlZCB0ZXh0IGFib3ZlIGlzIGEgbG90IGNsZWFyZXIgYW5kIGl0IGFkZHJlc3NlcyBteSBj b25jZXJuLg0KDQpSb21hbg0KDQoNCk9uIFN1biwgSnVsIDIxLCAyMDE5IGF0IDQ6NTMgUE0gUm9t YW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+PiB3cm90ZToNCkhp IEJyaWFuIQ0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGUgaW4gLTAzLiAgVGhlIGl0ZW0gYmVsb3cg aXMgdGhlIG9ubHkgdGhpbmcgdGhhdCByZW1haW5zIG91dHN0YW5kaW5nLg0KDQpUaGFua3MsDQpS b21hbg0KDQoNCkZyb206IFJvbWFuIERhbnlsaXcNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNywg MjAxOSA2OjA1IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQpDYzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gQUQgUmV2 aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDINCg0KDQpGcm9tOiBC cmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDQ6MzUgUE0NClRvOiBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFm dC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDINCg0KW3NuaXBdDQoNCigyKSBTZWN0 aW9uIDIuMi4gIGluIHRoZSBzZW50ZW5jZSAiVG8gdGhlIGV4dGVudCBwb3NzaWJsZSwgd2hlbiBp c3N1aW5nIGFjY2VzcyB0b2tlbnMsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgYWRh cHQgdGhlIHNjb3BlIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhl IHZhbHVlIHRoZSByZXNwZWN0aXZlIHJlc291cmNlIGlzIGFibGUgdG8gcHJvY2VzcyBhbmQgbmVl ZHMgdG8ga25vdyI6DQoNCi0tICBpcyB0aGlzIGxhbmd1YWdlIHN1Z2dlc3RpbmcgdGhhdCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgbW9kaWZ5aW5nIHRoZSBzY29wZSB2YWx1ZSBiYXNlZCBv biB0aGUgcmVzb3VyY2UgaXQgc2Vlcz8gIEknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0ICJh ZGFwdCIgbWVhbnMsIGVzcGVjaWFsbHkgaW4gcmVsYXRpb24gdG8gdGhlIGltcHJvdmVkIHNlY3Vy aXR5IGFuZCBwcml2YWN5IHRoZSBzdWJzZXF1ZW50IHNlbnRlbmNlIHN1Z2dlc3RzLg0KDQpQZXJo YXBzICJhZGFwdCIgd2Fzbid0IHRoZSBiZXN0IGNob2ljZSBvZiB3b3JkIGJ1dCBpdCdzIG1lYW50 IHRvIHNheSB0aGF0IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHdpdGggc3VmZmljaWVudCB1bmRl cnN0YW5kaW5nIG9mIHdoYXQgc2NvcGVzIGFyZSBhcHBsaWNhYmxlIHRvIHdoYXQgcmVzb3VyY2Vz ICh3aGljaCB3b24ndCBhbHdheXMgYmUgdGhlIGNhc2Ugb3IgZXZlbiBwb3NzaWJsZSBidXQgc29t ZXRpbWVzKSBjb3VsZCBsaW1pdCB0aGUgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0 b2tlbiAoZG93bnNjb3BpbmcgcmVhbGx5KSB0byBvbmx5IHRoZSBzY29wZSB0aGF0IGlzIGFwcGxp Y2FibGUgdG8gdGhlIHJlc291cmNlLg0KDQpTb21lIG9mIHRoZSBleGFtcGxlcyAoZmlndXJlcyAy IC0gNikgYXR0ZW1wdCB0byBzaG93LCBhbW9uZyBvdGhlciB0aGluZ3MsIGEgaHlwb3RoZXRpY2Fs IGNhc2Ugb2YgaG93IHRoaXMgbWlnaHQgZ28gZG93bi4NCg0KSW4gRmlndXJlIDIgdGhlIGluaXRp YWwgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRoYXQncyBhcHByb3ZlZCBoYXMgc2NvcGUgb2YgY2Fs ZW5kYXIgJiBjb250YWN0cyBhbmQgcmVzb3VyY2VzIGh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5j b20vICYgaHR0cHM6Ly9jYWwuZXhhbXBsZS5jb20vDQoNCkEgc3Vic2VxdWVudCBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCAoRmlndXJlIDMpIGhhcyByZXNvdXJjZSBodHRwczovL2NhbC5leGFtcGxlLmNv bS8gYW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3BlIChGaWd1cmUgNCkgaXMgImFkYXB0 ZWQiIHRvIHRoYXQgcmVzb3VyY2UgdG8gYmUgb25seSBjYWxlbmRhcg0KDQpBbm90aGVyIHN1YnNl cXVlbnQgYWNjZXNzIHRva2VuIHJlcXVlc3QgKEZpZ3VyZSA1KSBoYXMgcmVzb3VyY2UgaHR0cHM6 Ly9jb250YWN0cy5leGFtcGxlLmNvbS8gYW5kIHRoZSBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3Bl IChGaWd1cmUgNikgaXMgZG93bnNjb3BlZCBiYXNlZCBvbiB0aGF0IHJlc291cmNlIHRvIGJlIG9u bHkgY29udGFjdHMNCg0KV291bGQgaXQgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQgaWYgdGhlIHdv cmQgImRvd25zY29wZSIgd2FzIHVzZWQgcmF0aGVyIHRoYW4gImFkYXB0Ij8NCg0KW1JvbWFuXSBV c2luZyDigJxkb3duc2NvcGXigJ0gZG9lcyB3b3JrIGZvciBtZS4gIEl0IGNhcHR1cmVzIHRoYXQg dGhlIHNlcnZlciBpcyBnb2luZyB0byByZWR1Y2UgdGhlIHNjb3BlIChhbmQgY2VydGFpbmx5IG5v dCBleHBhbmQgaXQpLg0KDQoNCi0tIChEZXBlbmRpbmcgb24gdGhlIGFib3ZlKSBJcyB0aGVyZSBh IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gaGVyZSBmb3IgdGhlIHNlcnZlciByZWxhdGl2ZSB0byBj b25maWRlbnRpYWwgc2NvcGUgdmFsdWVzIGFuZCBob3cgdGhleSBtaWdodCBiZSBtb2RpZmllZD8N Cg0KSSdtIG5vdCBzdXJlLCB0byBiZSBob25lc3QuIERvd25zY29wcGluZyB3aGVuIHBvc3NpYmxl IGFuZCB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIGlzIHVzdWFsbHkgYSBnb29kIGlkZWEgKGxlYXN0 IHByaXZpbGVnZSBhbmQgYWxsIHRoYXQpIGJ1dCBJIHRoaW5rIG1heWJlIEknbSBtaXNzaW5nIHlv dXIgcG9pbnQvcXVlc3Rpb24uDQoNCltSb21hbl0gWWVzLCBsZWFzdCBwcml2aWxlZ2Ugd2FzIHBh cnQgb2YgaXQgYW5kIEkgdGhpbmsgdGhlIHRleHQgYWJvdmUgZ2V0cyBhdCBpdC4gIEhvd2V2ZXIs IHRoZSBvdGhlciBwYXJ0IGlzIHRoZSByZWxhdGlvbnNoaXAgd2l0aCB0aGUgbmV4dCBzZW50ZW5j ZSBpbiB0aGUgcGFyYWdyYXBoLCDigJxUaGlzIGZ1cnRoZXIgaW1wcm92ZXMgcHJpdmFjeSBhcyBz Y29wZSB2YWx1ZXMgZ2l2ZSBhbiBpbmRpY2F0aW9uIG9mIHdoYXQgc2VydmljZXMgdGhlIHJlc291 cmNlIG93bmVyIHVzZXMgYW5kIGl0IGltcHJvdmVzIHNlY3VyaXR5IGFzIHNjb3BlIHZhbHVlcyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgZGF0YeKAnS4gIElmIHRoZSBpbml0aWFsIHJlcXVlc3Qg d2FzIG5vdGlvbmFsbHkgYSBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNlcyBvbiB0aGUgYmxvY2vi gJ0sIGJ1dCB0aGUgc2VydmVyIGtuZXcgdGhhdCB0aGlzIHJlcXVlc3Qgd2FzIHRvbyBicm9hZCBh bmQgZG93bi1zY29wZWQgdG8g4oCcb25seSB0aGUgY29ybmVyIGhvdXNl4oCdLCB3b3VsZG7igJl0 IHRoaXMgYWN0dWFsbHkgYmUgd29yc2UgZm9yIHByaXZhY3k/ICBJIGFsc28gZG9u4oCZdCBmb2xs b3cgaG93IHJlZHVjaW5nIHRoZSBzY29wZSBpbXBhY3RzIGNvbmZpZGVudGlhbCBkYXRhLg0KDQoN Cg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNj bG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0KDQpDT05GSURF TlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQg cHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkg b3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNo bWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFE5Emarchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSAtMDQgdmVyc2lv biBhZGRyZXNzZXMgbXkgcmVtYWluaW5nIGNvbmNlcm5lZC4mbmJzcDsgVGhhbmtzIGZvciB0aGlz IHVwZGF0ZS4mbmJzcDsgSeKAmXZlIGFkdmFuY2VkIHRoZSBkb2N1bWVudCB0byBJRVRGIExDLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9tYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVs eSAyMiwgMjAxOSA5OjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDtyZGRA Y2VydC5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIFJvbWFuLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBhZ2FpbiBmb3Ig c3RpY2tpbmcgd2l0aCBtZSB0aHJvdWdoIHRoaXMgb25lIHdpdGggYW5kIGFzc29jaWF0ZWQgcmVn aXN0cnkgdXBkYXRlcyB3aXRoIHRva2VuIGV4Y2hhbmdlIGFzIHdlbGwgYXMgbXkgdGVtcG9yYXJp bHkgb3Zlcmxvb2tpbmcgc29tZSBuZWVkZWQgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wNCI+LTA0 IGlzIG5vdyB1cDwvYT4gYW5kIHRoaXMgdGltZSBJIHRoaW5rIEkndmUgYWN0dWFsbHkgYWRkcmVz c2VkIGFsbCB5b3VyIGNvbW1lbnRzLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyMiwgMjAxOSBhdCA3OjExIEFN IFJvbWFuIERhbnlsaXcgJmx0OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmciPnJkZEBjZXJ0 Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5IaSBCcmlhbiE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIG5hbWU9Im1fNDgwNzg3OTQ2NDA0NDIwODAzMF9fTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93 dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50 Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAy MiwgMjAxOSA4OjM3IEFNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVm PSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5ZZXMsIHNvcnJ5IGFib3V0IHRoYXQuIEkgcmVhbGl6ZWQgdGhpcyB5 ZXN0ZXJkYXkgYW5kIGFzDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL29hdXRoLzJzczNoRGEweFBReGFXaVc2dHhqOVctdnBxbyIgdGFyZ2V0PSJfYmxhbmsi Pg0KdHJpZWQgdG8gd3JpdGUgcXVpY2tseSBmcm9tIGZyb20gbXkgcGhvbmUganVzdCBiZWZvcmUg bXkgZmxpZ2h0IHRvb2sgb2ZmIGZvciBNb250cmVhbDwvYT4sIEknZCBnb3R0ZW4gZGlzdHJhY3Rl ZCB3aXRoIHRoZSBxdWVzdGlvbiBvZiB3aGF0IHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJhdGlvbnMg YW5kIGxvc3QgdHJhY2sgb2YgdGhpcyBmb3JrIG9mIHRoZSB0aHJlYWQuJm5ic3A7IFRoZXJlIGFy ZSBpbmRlZWQgYSBjb3VwbGUgb2Ygb3V0c3RhbmRpbmcgYml0cw0KIHRoYXQgbmVlZCB0byBiZSBh ZGRyZXNzZWQgaW4gYSAtMDQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbGwgY2hhbmdlIGFkYXB0IHRvIGRvd25zY29w ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGJyPg0KUmVnYXJkaW5nIHlvdXIgdW5hbnN3ZXJlZCBxdWVzdGlvbnMgZnJvbSBiZWxvdyAtIHBh cnRpYWxseSBxdW90ZWQgaGVyZSBmb3IgcmVmZXJlbmNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+J0lmIHRoZSBpbml0aWFsIHJlcXVl c3Qgd2FzIG5vdGlvbmFsbHkgYSBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNlcyBvbiB0aGUgYmxv Y2vigJ0sIGJ1dCB0aGUgc2VydmVyIGtuZXcgdGhhdCB0aGlzIHJlcXVlc3Qgd2FzIHRvbyBicm9h ZCBhbmQgZG93bi1zY29wZWQgdG8g4oCcb25seSB0aGUgY29ybmVyIGhvdXNl4oCdLA0KIHdvdWxk buKAmXQgdGhpcyBhY3R1YWxseSBiZSB3b3JzZSBmb3IgcHJpdmFjeT8nIC0mZ3Q7IHRoZSBpZGVh IHRoZXJlIGlzIHByaXZhY3kgaW4gdGVybXMgb2YgbGltaXRpbmcgd2hhdCBvbmUgc2VydmljZSBw b3RlbnRpYWxseSBsZWFucyBhYm91dCBvdGhlciBzZXJ2aWNlcyB0aGUgdXNlciBpcyB1c2luZy4g SW4gdGhlIGhvdXNlcyBvbiB0aGUgYmxvY2sgY2FzZSB5b3UgbWVudGlvbmVkLCB0aGUgZG93bnNj b3BpbmcgcHJldmVudHMgdGhlIGNvcm5lciBob3VzZQ0KIGZyb20gbGVhcm5pbmcgdGhhdCB0aGUg dXNlciBhbHNvIGFjY2Vzc2VzIHRoZSBvdGhlciBob3VzZXMgb24gdGhlIGJsb2NrLiA8YnI+DQo8 YnI+DQonSSBhbHNvIGRvbuKAmXQgZm9sbG93IGhvdyByZWR1Y2luZyB0aGUgc2NvcGUgaW1wYWN0 cyBjb25maWRlbnRpYWwgZGF0YS4nIC0mZ3Q7IHRvIGJlIGhvbmVzdCwgdGhpcyBwYXJ0aWN1bGFy IHRleHQgY2FtZSBhcyBhIHN1Z2dlc3Rpb24gZnJvbSBhbm90aGVyIFdHIG1lbWJlciBvbiByZXZp ZXcgb2YgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4gU28gSSBzdHJ1Z2dsZSBh IGJpdCB0byBkZWZlbmQvZXhwbGFpbiBpdCBidXQgSSB0aGluayB0aGUNCiBpZGVhIGlzIHRoYXQg aW4gc29tZSBjYXNlcyBhIHNjb3BlIHZhbHVlIGl0c2VsZiBtaWdodCBjb250YWluIHNlbnNpdGl2 ZSBkYXRhIGxpa2UgYW4gYWNjb3VudCBudW1iZXIgb3IgdHJhbnNhY3Rpb24gaWRlbnRpZmllciAo ZS5nLiBzb21ldGhpbmcgbGlrZSAmcXVvdDthY2N0OjEyMzQ1Njc4OSZxdW90OyBvciAmcXVvdDt0 eDo5ODc2NTQzMjEmcXVvdDspLiBUaGlzIGlzIHNvbWV3aGF0IHVuY29tbW9uIGluIHByYWN0aWNl IHRvZGF5IGJ1dCBkb2VzIGhhcHBlbiBpbiBzb21lIHNpdHVhdGlvbnMuDQogVGhlIHNhbWUgcHJp bmNpcGFsIG9mIGxpbWl0aW5nIHRoZSBzY29wZXMgcmV2ZWFsZWQgYWNyb3NzIGRpZmZlcmVudCBz ZXJ2aWNlcyBhcHBsaWVzIGhlcmUgdG9vIGJ1dCB3aXRoIGFyZ3VhYmx5IHdvcnNlIGNvbnNlcXVl bmNlcyBkdWUgdG8gdGhlIHNlbnNpdGl2ZSBkYXRhIHdpdGhpbiB0aGUgc2NvcGUgdmFsdWUuIEl0 J3MgdGhlIHNhbWUgY29uY2VwdCB0aG91Z2ggYW5kIEkgdGhpbmsgdGhlIG1lbnRpb24gb2YgY29u ZmlkZW50aWFsIGRhdGEgYW5kDQogc2NvcGUgaGVyZSBpbiB0aGUgZG9jdW1lbnQgaXMgbW9yZSBs aWtlbHkgY2F1c2UgY29uZnVzaW9uIHRoYW4gaXQgaXMgdG8gaGVscCBhbnl0aGluZy4gQXMgc3Vj aCwgSSdtIHByb3Bvc2luZyB0byBjaGFuZ2UgdGhhdCBzZW50ZW5jZSBhcyBmb2xsb3dzIHRvIHJl bW92ZSB0aGUgY29uZmlkZW50aWFsIGJpdCBhbmQgc29tZXdoYXQgYmV0dGVyIGRlc2NyaWJlIHRo ZSBjcm9zcy1zZXJ2aWNlIHNjb3BlIHJldmVhbGluZyBpc3N1ZS4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJnF1b3Q7VGhpcyBmdXJ0aGVyIGltcHJvdmVzIHByaXZhY3kgYXMgc2NvcGUgdmFsdWVz IGdpdmUgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IHNlcnZpY2VzIHRoZSByZXNvdXJjZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IG93bmVyIHVzZXMgYW5kIGRvd25zY29waW5nIGEgdG9rZW4gdG8g b25seSB0aGF0IHdoaWNoIGlzIG5lZWRlZCBmb3IgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgY2FuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbWl0IHRoZSBleHRlbnQgdG8gd2hpY2ggc3Vj aCBpbmZvcm1hdGlvbiBpcyByZXZlYWxlZCBhY3Jvc3MgZGlmZmVyZW50IHNlcnZpY2VzLiZxdW90 Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSZu YnNwOyBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbiByZWxhdGl2ZSB0byBteSBhbmFsb2d5LiZu YnNwOyBJIGFncmVlIHRoYXQgdGhlIHByb3Bvc2VkIHRleHQgYWJvdmUgaXMNCiBhIGxvdCBjbGVh cmVyIGFuZCBpdCBhZGRyZXNzZXMgbXkgY29uY2Vybi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFN1biwgSnVsIDIxLCAyMDE5IGF0IDQ6NTMgUE0gUm9tYW4gRGFueWxpdyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJkZEBjZXJ0Lm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgQnJpYW4hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzIGZvciB0aGUgdXBkYXRlIGluIC0wMy4mbmJzcDsgVGhlIGl0ZW0gYmVsb3cgaXMg dGhlIG9ubHkgdGhpbmcgdGhhdCByZW1haW5zIG91dHN0YW5kaW5nLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Sb21hbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV80ODA3ODc5NDY0MDQ0MjA4MDMwX21f LTQyNzAyMjY1NTE4NTIwMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7Ym9y ZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGJsdWUiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBEYW55bGl3DQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDY6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFu IENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20i IHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10g QUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47 Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENh bXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAxNywgMjAxOSA0OjM1IFBNPGJyPg0KPGI+VG86 PC9iPiBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWll dGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bc25pcF08L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4oMikgU2VjdGlvbiAyLjIuJm5ic3A7IGluIHRoZSBzZW50 ZW5jZSAmcXVvdDtUbyB0aGUgZXh0ZW50IHBvc3NpYmxlLCB3aGVuIGlzc3VpbmcgYWNjZXNzIHRv a2VucywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBhZGFwdCB0aGUgc2NvcGUgdmFs dWUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUNCiB2YWx1ZSB0aGUgcmVz cGVjdGl2ZSByZXNvdXJjZSBpcyBhYmxlIHRvIHByb2Nlc3MgYW5kIG5lZWRzIHRvIGtub3cmcXVv dDs6PGJyPg0KPGJyPg0KLS0mbmJzcDsgaXMgdGhpcyBsYW5ndWFnZSBzdWdnZXN0aW5nIHRoYXQg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIG1vZGlmeWluZyB0aGUgc2NvcGUgdmFsdWUgYmFz ZWQgb24gdGhlIHJlc291cmNlIGl0IHNlZXM/Jm5ic3A7IEknbSB0cnlpbmcgdG8gdW5kZXJzdGFu ZCB3aGF0ICZxdW90O2FkYXB0JnF1b3Q7IG1lYW5zLCBlc3BlY2lhbGx5IGluIHJlbGF0aW9uIHRv IHRoZSBpbXByb3ZlZCBzZWN1cml0eSBhbmQgcHJpdmFjeSB0aGUgc3Vic2VxdWVudCBzZW50ZW5j ZSBzdWdnZXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5QZXJoYXBzICZxdW90O2FkYXB0JnF1b3Q7IHdhc24ndCB0aGUg YmVzdCBjaG9pY2Ugb2Ygd29yZCBidXQgaXQncyBtZWFudCB0byBzYXkgdGhhdCBhbiBhdXRob3Jp emF0aW9uIHNlcnZlciB3aXRoIHN1ZmZpY2llbnQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IHNjb3Bl cyBhcmUgYXBwbGljYWJsZSB0byB3aGF0IHJlc291cmNlcyAod2hpY2gNCiB3b24ndCBhbHdheXMg YmUgdGhlIGNhc2Ugb3IgZXZlbiBwb3NzaWJsZSBidXQgc29tZXRpbWVzKSBjb3VsZCBsaW1pdCB0 aGUgc2NvcGUgYXNzb2NpYXRlZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiAoZG93bnNjb3BpbmcgcmVh bGx5KSB0byBvbmx5IHRoZSBzY29wZSB0aGF0IGlzIGFwcGxpY2FibGUgdG8gdGhlIHJlc291cmNl LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Tb21lIG9mIHRoZSBleGFtcGxlcyAoZmlndXJlcyAyIC0gNikgYXR0ZW1wdCB0 byBzaG93LCBhbW9uZyBvdGhlciB0aGluZ3MsIGEgaHlwb3RoZXRpY2FsIGNhc2Ugb2YgaG93IHRo aXMgbWlnaHQgZ28gZG93bi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gRmlndXJlIDIgdGhlIGluaXRpYWwgYXV0aG9yaXphdGlv biByZXF1ZXN0IHRoYXQncyBhcHByb3ZlZCBoYXMgc2NvcGUgb2YgY2FsZW5kYXIgJmFtcDsgY29u dGFjdHMgYW5kIHJlc291cmNlcw0KPGEgaHJlZj0iaHR0cHM6Ly9jb250YWN0cy5leGFtcGxlLmNv bS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NvbnRhY3RzLmV4YW1wbGUuY29tLzwvYT4gJmFt cDsNCjxhIGhyZWY9Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vY2FsLmV4YW1wbGUuY29tLzwvYT4gPG86cD4NCjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgc3Vic2VxdWVudCBhY2Nlc3MgdG9rZW4g cmVxdWVzdCAoRmlndXJlIDMpIGhhcyByZXNvdXJjZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jYWwuZXhh bXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jYWwuZXhhbXBsZS5jb20vPC9hPiBh bmQgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2NvcGUgKEZpZ3VyZSA0KSBpcyAmcXVvdDthZGFw dGVkJnF1b3Q7IHRvIHRoYXQgcmVzb3VyY2UgdG8gYmUgb25seSBjYWxlbmRhcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFu b3RoZXIgc3Vic2VxdWVudCBhY2Nlc3MgdG9rZW4gcmVxdWVzdCAoRmlndXJlIDUpIGhhcyByZXNv dXJjZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jb250YWN0cy5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2NvbnRhY3RzLmV4YW1wbGUuY29tLzwvYT4gYW5kIHRoZSBpc3N1ZWQgYWNj ZXNzIHRva2VuIHNjb3BlIChGaWd1cmUgNikgaXMgZG93bnNjb3BlZCBiYXNlZCBvbiB0aGF0IHJl c291cmNlIHRvIGJlIG9ubHkgY29udGFjdHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvdWxkIGl0IGJlIGVhc2llciB0byB1bmRlcnN0 YW5kIGlmIHRoZSB3b3JkICZxdW90O2Rvd25zY29wZSZxdW90OyB3YXMgdXNlZCByYXRoZXIgdGhh biAmcXVvdDthZGFwdCZxdW90Oz8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W1JvbWFuXSBVc2luZyDigJxkb3duc2NvcGXigJ0gZG9lcyB3b3JrIGZvciBtZS4mbmJz cDsgSXQgY2FwdHVyZXMgdGhhdCB0aGUgc2VydmVyIGlzIGdvaW5nIHRvIHJlZHVjZSB0aGUgc2Nv cGUNCiAoYW5kIGNlcnRhaW5seSBub3QgZXhwYW5kIGl0KS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3Vy cmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+ DQotLSAoRGVwZW5kaW5nIG9uIHRoZSBhYm92ZSkgSXMgdGhlcmUgYSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIGhlcmUgZm9yIHRoZSBzZXJ2ZXIgcmVsYXRpdmUgdG8gY29uZmlkZW50aWFsIHNjb3Bl IHZhbHVlcyBhbmQgaG93IHRoZXkgbWlnaHQgYmUgbW9kaWZpZWQ/PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBz dXJlLCB0byBiZSBob25lc3QuIERvd25zY29wcGluZyB3aGVuIHBvc3NpYmxlIGFuZCB0byB0aGUg ZXh0ZW50IHBvc3NpYmxlIGlzIHVzdWFsbHkgYSBnb29kIGlkZWEgKGxlYXN0IHByaXZpbGVnZSBh bmQgYWxsIHRoYXQpIGJ1dCBJIHRoaW5rIG1heWJlIEknbSBtaXNzaW5nIHlvdXIgcG9pbnQvcXVl c3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo1LjE1cHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21hbl0gWWVzLCBsZWFzdCBwcml2aWxlZ2Ugd2Fz IHBhcnQgb2YgaXQgYW5kIEkgdGhpbmsgdGhlIHRleHQgYWJvdmUgZ2V0cyBhdCBpdC4mbmJzcDsg SG93ZXZlciwgdGhlIG90aGVyIHBhcnQgaXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBuZXh0 IHNlbnRlbmNlIGluIHRoZSBwYXJhZ3JhcGgsIOKAnFRoaXMgZnVydGhlcg0KIGltcHJvdmVzIHBy aXZhY3kgYXMgc2NvcGUgdmFsdWVzIGdpdmUgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IHNlcnZpY2Vz IHRoZSByZXNvdXJjZSBvd25lciB1c2VzIGFuZCBpdCBpbXByb3ZlcyBzZWN1cml0eSBhcyBzY29w ZSB2YWx1ZXMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGRhdGHigJ0uJm5ic3A7IElmIHRoZSBp bml0aWFsIHJlcXVlc3Qgd2FzIG5vdGlvbmFsbHkgYSBzY29wZSBvZiDigJxhbGwgdGhlIGhvdXNl cyBvbiB0aGUgYmxvY2vigJ0sIGJ1dCB0aGUgc2VydmVyDQoga25ldyB0aGF0IHRoaXMgcmVxdWVz dCB3YXMgdG9vIGJyb2FkIGFuZCBkb3duLXNjb3BlZCB0byDigJxvbmx5IHRoZSBjb3JuZXIgaG91 c2XigJ0sIHdvdWxkbuKAmXQgdGhpcyBhY3R1YWxseSBiZSB3b3JzZSBmb3IgcHJpdmFjeT8mbmJz cDsgSSBhbHNvIGRvbuKAmXQgZm9sbG93IGhvdyByZWR1Y2luZyB0aGUgc2NvcGUgaW1wYWN0cyBj b25maWRlbnRpYWwgZGF0YS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9y ZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+Q09ORklERU5USUFMSVRZIE5P VElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQg bWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0K IEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50 cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1 NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNPTkZJREVOVElB TElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2 aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B33DFE5Emarchand_-- From nobody Mon Jul 22 06:55: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 010741202CD for ; Mon, 22 Jul 2019 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001, SPF_HELO_NONE=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 mLyByDbqZI8n for ; Mon, 22 Jul 2019 06:54:56 -0700 (PDT) Received: from outgoing.selfhost.de (outgoing.selfhost.de [82.98.87.70]) (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 4AE61120282 for ; Mon, 22 Jul 2019 06:54:56 -0700 (PDT) Received: (qmail 4428 invoked from network); 22 Jul 2019 13:54:52 -0000 Received: from unknown (HELO ?172.28.23.85?) (postmaster@davidsautter.de@80.246.32.28) by mailout.selfhost.de with ESMTPA; 22 Jul 2019 13:54:52 -0000 Date: Mon, 22 Jul 2019 15:54:51 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <503669B0-8DCD-4811-8B69-0CE0F4E0D8B0@alkaline-solutions.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----B0SEU07GJ2Y1FQDWV34AFLF3WGX78W" Content-Transfer-Encoding: 7bit To: Torsten Lodderstedt CC: OAuth WG ,David Waite From: David Sautter Message-ID: <7900405B-FAF8-4210-B349-C5DA4D8D8E59@web.de> Archived-At: Subject: Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 13:55:02 -0000 ------B0SEU07GJ2Y1FQDWV34AFLF3WGX78W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thorsten, do you mean that for service2service communication or for the frontend to = backend communication? How would that process look like in a nutshell? Thanks! David Am 22=2E Juli 2019 14:30:41 MESZ schrieb Torsten Lodderstedt : >Hi David,=20 > >> On 12=2E Jun 2019, at 04:01, David Waite >wrote: >>=20 >> To prevent exfiltration, the options are limited=2E=20 >> - Token Binding will work, but only currently has support in Edge=2E >> - Mutual TLS will work, but has a poor experience unless you are >deploying alongside group policy=2E >> - DPoP was written specifically for the browser use case (such as >letting you use WebCrypto for non-exportable tokens)=2E It is an early >draft but has some initial implementations already=2E > >If you use a backend to relay or orchestrate your micro service >interactions, mTLS (with self-signed certs) is the easiest choice from >my perspective=2E=20 > >kind regards, >Torsten=2E=20 --=20 Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet= =2E ------B0SEU07GJ2Y1FQDWV34AFLF3WGX78W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thorsten,

do you mean that for service2s= ervice communication or for the frontend to backend communication?

H= ow would that process look like in a nutshell?

Thanks!
David
<= br>

Am 22=2E Juli 2019 14:30:41 MESZ schr= ieb Torsten Lodderstedt <torsten@lodderstedt=2Enet>:
Hi David, 

On 12=2E Jun 2019, at 04:01, David Waite <david@alkaline-=
solutions=2Ecom> wrote:

To prevent exfiltration, the options are =
limited=2E 
- Token Binding will work, but only currently has support in=
 Edge=2E
- Mutual TLS will work, but has a poor experience unless you ar=
e deploying alongside group policy=2E
- DPoP was written specifically fo=
r the browser use case (such as letting you use WebCrypto for non-exportabl=
e tokens)=2E It is an early draft but has some initial implementations alre=
ady=2E

If you use a backend to relay or orchestrate you=
r micro service interactions, mTLS (with self-signed certs) is the easiest =
choice from my perspective=2E 

kind regards,
Torsten=2E 

<=
/pre>

--
Diese Nachricht wurde von meinem Android= -Ger=C3=A4t mit K-9 Mail gesendet=2E ------B0SEU07GJ2Y1FQDWV34AFLF3WGX78W-- From nobody Mon Jul 22 06:57:22 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9800D120121; Mon, 22 Jul 2019 06:57:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: rdd@cert.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156380384055.28054.12739997236507886590.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2019 06:57:20 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (Resource Indicators for OAuth 2.0) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:57:21 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Resource Indicators for OAuth 2.0' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 22 07:01: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 076111202CC for ; Mon, 22 Jul 2019 07:01: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 GKFBbN3JRKdd for ; Mon, 22 Jul 2019 07:01:42 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.105]) (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 4960512030D for ; Mon, 22 Jul 2019 07:01:42 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpYsl-0008Ki-Aq; Mon, 22 Jul 2019 16:01:39 +0200 From: Torsten Lodderstedt Message-Id: <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_DC8AE25C-7AE7-44C8-8DBD-48E73737D552"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 16:01:38 +0200 In-Reply-To: <156371372426.20589.10365011724092335159@ietfa.amsl.com> Cc: OAuth WG To: Vittorio Bertocci References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:01:49 -0000 --Apple-Mail=_DC8AE25C-7AE7-44C8-8DBD-48E73737D552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vittorio, thanks for contributing this specification. It fills a further gap in = the OAuth universe :-) Here are my comments: - 2.2.1 there are other sources for identity claims, e.g. = https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html.=20= I recommend to open the clause "Any additional attributes whose semantic is well described by the attributes description found in section 5.1 of [ OpenID.Core] SHOULD be codified in JWT access tokens via the corresponding claim names in that section of the OpenID Connect specification. The same holds for attributes defined in [RFC7662]." by adding=20 "and other identity related specifications.=E2=80=9D=20 Alternatively, the draft could also refer to the IANA =E2=80=9COAuth = Token Introspection Response=E2=80=9D registry as source for JWT claims. - 2.2.2.=20 "If an authorization request includes a scope parameter, the corresponding issued JWT access token MUST include a scope claim as defined in section 4.2 of [TokenExchange]." Why do you establish such a strong link between the scope in the = authorization request and the access token? I=E2=80=99m aware of = implementations that map scope values to audience values and therefore = do not carry the scope value to the resource server. I suggest to soften = this requirement and make it a recommendation.=20 - 5.=20 "The JWT access token data layout described here is very similar to the = one of the id_token as defined by [OpenID.Core]. Without the explicit typing required in this profile, in line with the = recommendations in [JWT.BestPractices] there would be the risk of attackers using JWT access tokens in lieu of id_tokens." I like this practice but it is not established yet in the OpenID Connect = universe. This means any OIDC RP will process an access token because it = will just ignore the type header.=20 draft-ietf-oauth-jwt-introspection-response therefore gives = recommendation on how to use iss and aud claim to prevent JWT abuse = (https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-0= 4#section-6.1).=20 Mapping this pattern to JWTs as access token requires that there must = not be the same aud value for a resource server and any other JWT = consumer, e.g. an OpenID Connect RP.=20 kind regards, Torsten.=20 > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : JSON Web Token (JWT) Profile for OAuth 2.0 = Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-01.txt > Pages : 15 > Date : 2019-07-20 >=20 > Abstract: > This specification defines a profile for issuing OAuth2 access = tokens > in JSON web token (JWT) format. Authorization servers and resource > servers from different vendors can leverage this profile to issue = and > consume access tokens in interoperable manner. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DC8AE25C-7AE7-44C8-8DBD-48E73737D552 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 Fw0xOTA3MjIxNDAxMzhaMC8GCSqGSIb3DQEJBDEiBCBSkt8O1Kz+13YAzEuVM3oyztBq+U5ZsdIR 6inPQNliFzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAI7l0UEnqYSzdGENWyQFIeiBqPSaQiu5MgG2L3VV9aKklLv4fAE0N+8t4hau ggT1MCWrJamnKW87rj9gbWtN0nLuEKKIj6qHTmVk1+r0dDXiebiMJAuCq5nYQoGthd116kCy3SP9 pHJaMLqdGOOkI4COftnxjyVKdcUgvj1k+9yqD011yF2nD2a+BzljRQkLYugNSgE5lgFinKewXN7s fVrRELhc6EJZMiLmtryS9vv94R7bhHihYU1TypYODurouXKT928uK7Y81qEyybSfi0b0GzgImTqT KdfcXIqqIvldBshP9BGBRnaNjNDD+vxYI3w12KEsy9IGVp5J7DcNhJ8AAAAAAAA= --Apple-Mail=_DC8AE25C-7AE7-44C8-8DBD-48E73737D552-- From nobody Mon Jul 22 08:13: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 803E91201D3 for ; Mon, 22 Jul 2019 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gCmquk7xfOcM for ; Mon, 22 Jul 2019 08:13:22 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450: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 32666120289 for ; Mon, 22 Jul 2019 08:13:22 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id v85so26882511lfa.6 for ; Mon, 22 Jul 2019 08:13: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:reply-to:from:date:message-id :subject:to:cc; bh=omq7/GwbYYPDQIT+jQFnMPD7RwWDRVAb/75NudqeDSg=; b=VCcuNVx/h2kAA3eTSwoYruAuM/rUp1Dt36jUmUMgWr/vsZF8Zodl/ldbmII/w2cpES wlsUy2qwi5WakzN7COPniKDKGhl40dRyS0d/8IhHUl2IYlr7rX9bH7vb1oLU3K1WHt8f V9IVrtRpLrYqfg2Yl8ieCxly0K75LrtpSNZMcrITYbVve1mDjx2NlOVmnmbnhYFxfgeJ C/uQUAmv1TzLjq5L6dcwcqOftXY2Yv+eoqein2vzydLo9pmkxCda5Zm2N5qALEebtPIA IC2zdGZ+mK1Lmp4+++Yi+sdlGIzBfvp1VIsHVXOMtSufgrWIsailzSJguYHkdMV/h8fE Fnow== 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:reply-to :from:date:message-id:subject:to:cc; bh=omq7/GwbYYPDQIT+jQFnMPD7RwWDRVAb/75NudqeDSg=; b=qG4pbAgXKTiD3NwFmYuj5265HFyDDWLwsRCERfl4rhRrozyN8hPvRBLkpu8dcwVWqt 9SjUiJNfzkS2iE2S3BZp1axGPFkDyc9MUymYcuZq4tu8FupqKxcsygA2zxZpFgd5Mg6P fUOFZDkfp9EtNJLar5yERIk+vPE6ILiZipVnwNAlQJngJrhJmZluxUVJ52GNGKQQFpjP O+KN9cADu6KZXmr1nf/p6WNWxza3PYz3PgeNeCRnAnWQ43n8aTmhp5DDOFLdSNMIURug Vc1kEO77mUgmyrom3lgXjTLuNmjtESi7xugEb5bc9jfQfdfldeXYQAuufp0nAQB6QgGp 2O3g== X-Gm-Message-State: APjAAAU+aoE5+ANbddCWtwmo4KFw7Q2NFWurmfwLyXwkPAuQPRcBgxE4 RIyHv/ZTPU/uBiZc7AI3ACKzNnRAmap4InqncIYToXnoD8OtNQ== X-Google-Smtp-Source: APXvYqyx4xCuCctYYXUAA/tE3R0Uvq6U3KVvciRHkPFXSrS6b3l1Ti+XHlN2uAjXCilremgRNR79BCFE1ExeBXLgdEw= X-Received: by 2002:ac2:5c1d:: with SMTP id r29mr29526078lfp.72.1563808400221; Mon, 22 Jul 2019 08:13:20 -0700 (PDT) MIME-Version: 1.0 References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> In-Reply-To: <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Mon, 22 Jul 2019 08:13:11 -0700 Message-ID: To: Torsten Lodderstedt Cc: OAuth WG Content-Type: multipart/alternative; boundary="000000000000313a00058e46847f" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:13:26 -0000 --000000000000313a00058e46847f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Torsten for the prompt review and insightful comments! 2.2.1 - excellent point. I added the suggested language. 2.2.2 - interesting. I did think of cases similar to profile in OIDC, where the effect of the request is influencing the layout of the resulting idtoken, but concluded that it didn't apply as is for access tokens. Given that you have direct knowledge of such cases in the wild, I am happy to relax the MUST into a SHOULD. 5. - this is going to be problematic in the wild. For example, in the azure AD world a registered application can play both the role of an API and a client; and requests for tokens targeting the app can use any identifier assigned to the app. That means that although idtokens will only be issued if the request identifies the client via clientID, access tokens requests for it will be honored (and reflected in aud) both in the case the resource parameter contains the clientID or the API URI of the target application. In fact I suspect that the most recent version of the service uses the clientID as preferred identifier, if not the only one. Mike/Tony can confirm or deny. As a compromise, we could add language in the spec that recommends the use of a unique audience when viable, as an extra measure in case the typ value isn't honored. WDYT? On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt wrote: > Hi Vittorio, > > thanks for contributing this specification. It fills a further gap in the > OAuth universe :-) > > Here are my comments: > > - 2.2.1 there are other sources for identity claims, e.g. > https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. > > I recommend to open the clause > > "Any additional attributes whose semantic is well described by the > attributes description found in section 5.1 of [ > OpenID.Core] SHOULD > be codified in JWT access tokens via the corresponding claim names in > that section of the OpenID Connect specification. The same holds for > attributes defined in [RFC7662]." > > by adding > > "and other identity related specifications.=E2=80=9D > > Alternatively, the draft could also refer to the IANA =E2=80=9COAuth Toke= n > Introspection Response=E2=80=9D registry as source for JWT claims. > > - 2.2.2. > > "If an authorization request includes a scope parameter, the > corresponding issued JWT access token MUST include a scope claim as > defined in section 4.2 of [TokenExchange]." > > Why do you establish such a strong link between the scope in the > authorization request and the access token? I=E2=80=99m aware of implemen= tations > that map scope values to audience values and therefore do not carry the > scope value to the resource server. I suggest to soften this requirement > and make it a recommendation. > > - 5. > > "The JWT access token data layout described here is very similar to the > one of the id_token as defined by [OpenID.Core]. Without the > explicit typing required in this profile, in line with the > recommendations in [JWT.BestPractices] there would be the risk of > attackers using JWT access tokens in lieu of id_tokens." > > I like this practice but it is not established yet in the OpenID Connect > universe. This means any OIDC RP will process an access token because it > will just ignore the type header. > > draft-ietf-oauth-jwt-introspection-response therefore gives recommendatio= n > on how to use iss and aud claim to prevent JWT abuse ( > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-0= 4#section-6.1). > > > Mapping this pattern to JWTs as access token requires that there must not > be the same aud value for a resource server and any other JWT consumer, > e.g. an OpenID Connect RP. > > kind regards, > Torsten. > > > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > > Author : Vittorio Bertocci > > Filename : draft-ietf-oauth-access-token-jwt-01.txt > > Pages : 15 > > Date : 2019-07-20 > > > > Abstract: > > This specification defines a profile for issuing OAuth2 access tokens > > in JSON web token (JWT) format. Authorization servers and resource > > servers from different vendors can leverage this profile to issue and > > consume access tokens in interoperable manner. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 1 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-0= 1 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000313a00058e46847f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Torsten for the prompt review and insightful com= ments!

2.2.1 - excellent point. I added the suggested la= nguage.

2.2.2 - interesting. I did think of cases = similar to profile in OIDC, where the effect of the request is influencing = the layout of the resulting idtoken, but concluded that it didn't apply= as is for access tokens. Given that you have direct knowledge of such case= s in the wild, I am happy to relax the MUST into a SHOULD.

5. - this is going to be problematic in the wild. For example, in = the azure AD world a registered application can play both the role of an AP= I and a client; and requests for tokens targeting the app can use any ident= ifier assigned to the app. That means that although idtokens will only be i= ssued if the request identifies the client via clientID, access tokens requ= ests for it will be honored (and reflected in aud) both in the case the res= ource parameter contains the clientID or the API URI of the target applicat= ion. In fact I suspect that the most recent version of the service uses the= clientID as preferred identifier, if not the only one. Mike/Tony can confi= rm or deny.
As a compromise, we could add language in the spec th= at recommends the use of a unique audience when viable, as an extra measure= in case the typ value isn't honored. WDYT?
=C2=A0

On Mo= n, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Vittorio,

thanks for contributing this specification. It fills a further gap in the O= Auth universe :-)

Here are my comments:

- 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4-identi= ty-assurance-1_0.html.

I recommend to open the clause

"Any additional attributes whose semantic is well described by the
=C2=A0 =C2=A0attributes description found in section 5.1 of [
OpenID.Core] SHOULD
=C2=A0 =C2=A0be codified in JWT access tokens via the corresponding claim n= ames in
=C2=A0 =C2=A0that section of the OpenID Connect specification.=C2=A0 The sa= me holds for
=C2=A0 =C2=A0attributes defined in [RFC7662]."

by adding

"and other identity related specifications.=E2=80=9D

Alternatively, the draft could also refer to the IANA =E2=80=9COAuth Token = Introspection Response=E2=80=9D registry as source for JWT claims.

- 2.2.2.

"If an authorization request includes a scope parameter, the
=C2=A0 =C2=A0corresponding issued JWT access token MUST include a scope cla= im as
=C2=A0 =C2=A0defined in section 4.2 of [TokenExchange]."

Why do you establish such a strong link between the scope in the authorizat= ion request and the access token? I=E2=80=99m aware of implementations that= map scope values to audience values and therefore do not carry the scope v= alue to the resource server. I suggest to soften this requirement and make = it a recommendation.

- 5.

"The JWT access token data layout described here is very similar to th= e one of the id_token as defined by [OpenID.Core].=C2=A0 Without the
=C2=A0 =C2=A0explicit typing required in this profile, in line with the rec= ommendations in [JWT.BestPractices] there would be the risk of
=C2=A0 =C2=A0attackers using JWT access tokens in lieu of id_tokens."<= br>
I like this practice but it is not established yet in the OpenID Connect un= iverse. This means any OIDC RP will process an access token because it will= just ignore the type header.

draft-ietf-oauth-jwt-introspection-response therefore gives recommendation = on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf.org/html/draft-i= etf-oauth-jwt-introspection-response-04#section-6.1).

Mapping this pattern to JWTs as access token requires that there must not b= e the same aud value for a resource server and any other JWT consumer, e.g.= an OpenID Connect RP.

kind regards,
Torsten.

> On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Vittorio Bertocci
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-access-token-jwt-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 15
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-07-20
>
> Abstract:
>=C2=A0 =C2=A0This specification defines a profile for issuing OAuth2 ac= cess tokens
>=C2=A0 =C2=A0in JSON web token (JWT) format.=C2=A0 Authorization server= s and resource
>=C2=A0 =C2=A0servers from different vendors can leverage this profile t= o issue and
>=C2=A0 =C2=A0consume access tokens in interoperable manner.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org= /doc/draft-ietf-oauth-access-token-jwt/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/dra= ft-ietf-oauth-access-token-jwt-01
> https://datatracker.i= etf.org/doc/html/draft-ietf-oauth-access-token-jwt-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--000000000000313a00058e46847f-- From nobody Mon Jul 22 08:44:04 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9559012012B for ; Mon, 22 Jul 2019 08:44:02 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbu2hcgtMgg4 for ; Mon, 22 Jul 2019 08:43:59 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9E120274 for ; Mon, 22 Jul 2019 08:43:58 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 52C6117EA40 for ; Tue, 23 Jul 2019 00:43:58 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id AB4C74E0046 for ; Tue, 23 Jul 2019 00:43:57 +0900 (JST) Received: from nriea03.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id x6MFhvbF005640 for ; Tue, 23 Jul 2019 00:43:57 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp with ESMTP id x6MFhvbf005639 for ; Tue, 23 Jul 2019 00:43:57 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6MFhvhA027658; Tue, 23 Jul 2019 00:43:57 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id x6MFhvtZ027657; Tue, 23 Jul 2019 00:43:57 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6MFhvBQ027654 for ; Tue, 23 Jul 2019 00:43:57 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 00:43:56 +0900 Received: from JPN01-TY1-obe.outbound.protection.outlook.com (104.47.93.58) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 00:43:56 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yi5CnTGAdv35YME86Ux/M9ygFtrbjvU/QOta91LEq1G5kTiNN0NGkd2iP+7KQFVK8XCb8zahbM379z1gLE0r6twtNjwzXi33z3mliqLQvLukinRvwpZutIVuQoOyrfXRNCEWGv1anYg5k+uiiUtoUYYsd0AsjNk22J+z85OomtIEdiDQpfNTeEzn9mHIt4VBrKrqvKkCCS5frexCbsFD8oMtFAIVzcFD9ngITn+yEv+DgOZnt1T7QKByupVqGG7F9SwfC+BxREa0LebLyqW27Mr1NQR6MwA+2zrdtePi62YP+41zHARDTMwDSLaAOZquuLiW2LFkthleabQtvM83ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gL85SbT6YT1eDs/X93+vUnhg4Xt6hNkQ0l2ju8230R0=; b=OA3ao4MqvN6RTYbyqIqhoZODXd/xTHc/zXcRoHAb0tgG5kKbqMRINSSKu+bEGZJEkfLp6z4v6RjpTCYTWq4UvgbSXCL/nrreCNP7JPRzkXRUoK4LZDX2XgxPoGLsB12zStBqyYN/ZxzIuADYdN2qFfWUbEJhLxS6aYPrdkEVp91Si2H0r+NOjB1SCZp1gYJYSokMRLgsq69O8Av/twu9lALEckZqRwzMRFk+7z0BT+yVVEMvwmi25DYxClomdkUfp8XaTd/u/XBJCRb1uJ5pxXWVkpbLEUfJrJH21c5XMUm5TeUsimioX8nW7irnG2PEghSTZWKhf3dk/MNq0y8tCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cu.nri.co.jp;dmarc=pass action=none header.from=cu.nri.co.jp;dkim=pass header.d=cu.nri.co.jp;arc=none Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com (20.179.173.206) by TYAPR01MB4846.jpnprd01.prod.outlook.com (20.179.175.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 15:43:54 +0000 Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33]) by TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33%6]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 15:43:54 +0000 From: n-sakimura To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-sakimura-oauth-jpop-05.txt Thread-Index: AQHVQKLAjsj5R0mIlU2SGe09YIZ+SqbWxqnY Date: Mon, 22 Jul 2019 15:43:54 +0000 Message-ID: References: <156380957934.28033.10711098988810240869.idtracker@ietfa.amsl.com> In-Reply-To: <156380957934.28033.10711098988810240869.idtracker@ietfa.amsl.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [2605:b100:fc48:2866:e01f:db9d:389:8d9a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86c235c2-8ef1-4f1f-7367-08d70ebb66f8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:TYAPR01MB4846; x-ms-traffictypediagnostic: TYAPR01MB4846: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(366004)(39850400004)(396003)(199004)(189003)(316002)(7736002)(74316002)(6436002)(2501003)(2906002)(256004)(5640700003)(6506007)(229853002)(86362001)(102836004)(76176011)(966005)(15650500001)(2351001)(6916009)(486006)(186003)(99286004)(478600001)(476003)(7696005)(25786009)(33656002)(11346002)(446003)(14444005)(66574012)(6116002)(46003)(8676002)(66446008)(46636005)(55016002)(606006)(64756008)(14454004)(66476007)(8936002)(52536014)(81166006)(76116006)(81156014)(66556008)(66946007)(1730700003)(5660300002)(91956017)(53936002)(236005)(68736007)(54896002)(71200400001)(71190400001)(9686003)(6306002)(2473003); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB4846; H:TYAPR01MB4413.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: orPEOqKvoJpaifum9QlkHXZUCdQYgj9oLc7nJqZx6Eq0c/Jo4UCgpWWWR8aAlRgceft0NeISrB0DdT/6QVn6qqz0k6Iax+e+bJFaXe+L6QSN/37W9vyJVACjB9TuDnkKN6cil6VzSKeZPiC0n6g43PPpS3R5ZVeu7H73vFC+Z5ALSeqHdUDK5k+UschFZEszk9Ezc0C22TDGvEd1nbkrpVBfho/JbGEwlOXaM1CvFRErfFeTUdeQ1cgNa5u8EHEqWHHeEYbcsreu6Om6DrbjnGnM44VEmtk2TgeWUYaI4vn1JrGRTZIA9miMZ6bA94AdW1vnipNrjJPFgBx8byLtItUDK+XL1D7OyS6CPIXhDTt7s6l+C/LhokkXyhX50K4xGIhLAGAyGWtpRLqG18Abj0T9nwAzjzuZza09/G+3/z8= Content-Type: multipart/alternative; boundary="_000_TYAPR01MB44139F4ED38AB66D9F1FA9EAF9C40TYAPR01MB4413jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 86c235c2-8ef1-4f1f-7367-08d70ebb66f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 15:43:54.4696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n-sakimura@cu.nri.co.jp X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4846 X-OrganizationHeadersPreserved: TYAPR01MB4846.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-jpop-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:44:03 -0000 --_000_TYAPR01MB44139F4ED38AB66D9F1FA9EAF9C40TYAPR01MB4413jpnp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Just refreshed the JPOP draft as it may be pertinent to both DPOP and acces= s token JWT discussion. Nat Sakimura Nomura Research Institute PLEASE READ=1B$B!'=1B(BThis e-mail is confidential and intended for the nam= ed recipient only. If you are not an intended recipient, please notify the = sender and delete this e-mail. ________________________________ =1B$B:9=3DP?M=1B(B: internet-drafts@ietf.org =1B$BAw?.F|;~=1B(B: =1B$B7nMKF|=1B(B, 7=1B$B7n=1B(B 22, 2019 11:33 =1B$B8aA= 0=1B(B =1B$B08@h=1B(B: Nat Sakimura; Kepeng Li; John Bradley =1B$B7oL>=1B(B: New Version Notification for draft-sakimura-oauth-jpop-05.t= xt A new version of I-D, draft-sakimura-oauth-jpop-05.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-jpop Revision: 05 Title: The OAuth 2.0 Authorization Framework: JWT Pop Token Usage Document date: 2019-07-22 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-sakimura-oauth-j= pop-05.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-jpop/ Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-= jpop Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-jp= op-05 Abstract: This specification describes how to use JWT POP (Jpop) tokens that were obtained through [POPKD] in HTTP requests to access OAuth 2.0 protected resources. Only the party in possession of the corresponding cryptographic key for the Jpop token can use it to get access to the associated resources unlike in the case of the bearer token described in [RFC6750] where any party in posession of the access token can access the resource. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_TYAPR01MB44139F4ED38AB66D9F1FA9EAF9C40TYAPR01MB4413jpnp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Just refreshed the JPOP draft as it may be p= ertinent to both DPOP and access token JWT discussion. 

Nat Sakimura 
Nomura Research Institute

PLEASE READ=1B$B!'=1B(BThis e-mail is confid= ential and intended for the named recipient only. If you are not an intende= d recipient, please notify the sender and delete this e-mail.
=1B$B:9=3DP?M= =1B(B: internet-drafts@ietf.org <internet-drafts@ietf.org>
=1B$BAw?.F|;~=1B(B: =1B$B7nMKF|=1B(B, 7=1B$B7n=1B(B 22, 2019 11:33 = =1B$B8aA0=1B(B
=1B$B08@h=1B(B: Nat Sakimura; Kepeng Li; John Bradley
=1B$B7oL>=1B(B: New Version Notification for draft-sakimura-oauth-jp= op-05.txt
 

A new version of I-D, draft-sakimura-oauth-jpop-05.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:           draft-sak= imura-oauth-jpop
Revision:       05
Title:          The OAuth 2.0 = Authorization Framework: JWT Pop Token Usage
Document date:  2019-07-22
Group:          Individual Sub= mission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-sakimura-oauth-jpop-05.txt Status:         https://datatracker.ietf.org/doc/draft-sakimura-oauth-jpop/
Htmlized:       https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-jpop-05

Abstract:
   This specification describes how to use JWT POP (Jpop) tokens = that
   were obtained through [POPKD] in HTTP requests to access OAuth= 2.0
   protected resources.  Only the party in possession of the=
   corresponding cryptographic key for the Jpop token can use it = to get
   access to the associated resources unlike in the case of the b= earer
   token described in [RFC6750] where any party in posession of t= he
   access token can access the resource.


            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


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

The IETF Secretariat

--_000_TYAPR01MB44139F4ED38AB66D9F1FA9EAF9C40TYAPR01MB4413jpnp_-- From nobody Mon Jul 22 09:21: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 BA641120052 for ; Mon, 22 Jul 2019 09:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dECcWnt9vqwV for ; Mon, 22 Jul 2019 09:21:49 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778AD1202A1 for ; Mon, 22 Jul 2019 09:21:49 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id p13so40027779wru.10 for ; Mon, 22 Jul 2019 09:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mgx+3mhuT+Op/ccTzkc4BAECArn6lpWOZcw26xdRsiM=; b=A5BTikihyxK6eykGz0iOUxq9OfjwusI5LH1p/qQDyVlE+bRqH0SLDJHYYwKKoTJ9oE TGlAxBVD5lVv5ciSqR1Npx2OMn9DpqZCelVi8sDwAhsi2PEP6NIqqnxx23n6KPnbVBGQ BruZO0ulMLkZQuITyLbkBZzoCwunCTYmHDXT7P78+1FFGmMYJFElmT9rTSpk0zoY5KOI LycmQUxIS0kHgYCyLfbuKcafUF8wp0sge5aVzgdzpjPNqvt+pu1nYFefmSl56v9WV+3S FHHEY6ksLsc10BVeh6d9tR5K6gqhfEqGriNUIGdEEqW6qBSp2yN34Sd/1hx3lWkSxHJQ CF7A== 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=mgx+3mhuT+Op/ccTzkc4BAECArn6lpWOZcw26xdRsiM=; b=SHvqRCP/my48cCfUZnry7YTNsXdp9E/Pt96oBi8KZeFkEdtePF3oj1Xy7d14Rmurdb wbMMUm8RPraTbYhPbVBj/nzZW4EnpJODFNwRyAvOmm8mOfDC1KH5QJOTiYfY12To/7Tj jeZm4Yhi4NIjf78C+OO3UGKtrL65wjnnl2LWl0mIAajap5PZ4fsXDJlXqMv1+yxmSfDl iz1BaGEeEjlGmMsxOk2BUeLnkyMzCfKnT2m7MFz2xp1z0U3bp2dM48IfefR9hPxMz4Xk oRljGASP4qCVE874TaK1caWA7llPnMX+GAUYg54o52qG9a9oW3k/Q6nIPIx+GJ0hKsQX piFA== X-Gm-Message-State: APjAAAUrLx2I3pOp+MZ7EnoUHfewr0WiH2miNkn1jj/9BufV2V2k8zWG 89jiMCHKaBHO56kOCOhvKt3016i2EU2AkRlC38U= X-Google-Smtp-Source: APXvYqwWwAurZRwX+c5dQc8pi5d7dCSzxL/OmptQvArOvjR41fDPJbNZbjSWuy9ikMOGZLezbGXe7DASrz99xLvmXME= X-Received: by 2002:adf:a341:: with SMTP id d1mr27766501wrb.260.1563812507454; Mon, 22 Jul 2019 09:21:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Mon, 22 Jul 2019 12:21:37 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 16:21:52 -0000 +1 Also, if it were to include user identification in the protocol, I would like to have the spec at least cover the following: 0. User 1. External Identity Provider 2. Resources that covers the functionality of PEP. 3. Authorization Server that act as PDP for Resources. 4. Internal Identity Server within the resource domain. 5. Client APP component 6. Client Server component In addition, it would be good to delineate the resource owner (an entity that has administrative rights over the set of resources) and the end user who is in the protocol flow. That actually asks for the following additional entities: 7. Resource Administrator 8. PAP/PIP It is probably a good idea to state the security target as well. Re: Starting from Resource. Yes. I agree that this is a valid use case. At the same time, there can be cases where the concrete resource endpoint is not known before the user authorization. So, the protocol needs to be able to start both ways, I guess. Cheers, Nat Sakimura On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt wrote: > > Hey Justin > > A few use cases that highlight how the world is different now than it was= when OAuth 2.0 was developed would help participants understand why change= s are needed, and also provide a reference for comparing and contrasting di= fferent approaches. > > One of my first comments is why the client is starting off making calls t= o the AS. There are times when the AS is not known for a given resource. Wh= y not allow starting at resource? > > > On Tue, Jul 9, 2019 at 12:48 PM Justin Richer wrote: >> >> I have requested time to present Transactional Authorization (the XYZ pr= oject) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99= ve uploaded a new version of the spec: >> >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 >> >> Additionally, I=E2=80=99ve updated the writeup and examples on https://o= auth.xyz/ >> >> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested = from the chairs that I present during the Tuesday session due to limited av= ailability of some key WG members on Friday. >> >> =E2=80=94 Justin >> >> _______________________________________________ >> 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From nobody Mon Jul 22 09: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 29559120179 for ; Mon, 22 Jul 2019 09:25:39 -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 dZlQRzmRFFlA for ; Mon, 22 Jul 2019 09:25:36 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1B4120168 for ; Mon, 22 Jul 2019 09:25:36 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id s4so15561149uad.7 for ; Mon, 22 Jul 2019 09:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:in-reply-to:references :user-agent; bh=cpzAHThI8n/KL9E6BemiwbcZv4GBN/+3uijGgs9bxy4=; b=Fe6IVMvIB6hfYPZ9ARFyrd7IwiaTZsZXOC4vlt/gskBTNc2PAtWnPY7Y1dHhL8u48s SVPBAGgJG5h89pvQ9wRB5xGROWbQQRxjMlute33OAkKQTFd6AggFqTAWXj6fYHjvkrVK rLMMYDcEhg9+/x+GC3IeJ6/bEgMKr6S25sh7AxzS/D46NNMNUO3jT1kl1b01tzzQerjp Hny9vhERCo/p4jNAbWzP4tmkHxoxkAt/L1UcwYVLtxQsyj6XJL+kFpgj9qsOPfQwqAWE 3Yf9Y/2FcoRl0PFer4BsS3cf4JPFZIoyxkqe2UHwLxVJLYLhqwDeUJhvM2ECCF1ny7A7 ZsYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :in-reply-to:references:user-agent; bh=cpzAHThI8n/KL9E6BemiwbcZv4GBN/+3uijGgs9bxy4=; b=WYtAGVAM+vmN1r2ihEeAB1FbHU1hWkhyst13yvbIeYu6oFBsQBzqjVWxKNcOSdem+X k1XmDL8Yk1ZO6bnFMaCHAmB5Bx5l68dP28ZDhsFlPrOQpV0WgMzpaL4iZw5O4JDDok5E 9MjlgzMSvR4C1aLnYXn36dusrwwY0GeGJla5j6KU3B+EkZ5+PQuKkLIkDVBxu4wejHQ6 dQ3Ryr34mn/XgG0x9SEvHLcHpZkz9Vov4NtAFuIJn2GjHXcLUIxo2SuPyv00Tyunkfgn pDjZbAzDtiFbyoAWpG/Ab8ykxpv3/cV0jX7ysFCZdY5btOvUJO3gRBxIGRGtu/uNCtB2 2mBg== X-Gm-Message-State: APjAAAXzX3x6Jsm9NLOXRHiTK24T35cEk5mBE3nMpMiw41HvkgeD2A47 x2X0DqwRUwm73hQPM2m3i8M= X-Google-Smtp-Source: APXvYqwnGfQxNcsj1dE7pqrqs/IpceRVOBVPUFAkON3rhz/prEan2m7VYa3lX4DYd92uUYhxinAxDQ== X-Received: by 2002:ab0:5ea6:: with SMTP id y38mr43255978uag.40.1563812735251; Mon, 22 Jul 2019 09:25:35 -0700 (PDT) Received: from [10.0.1.3] (pool-74-103-207-160.prvdri.ftas.verizon.net. [74.103.207.160]) by smtp.gmail.com with ESMTPSA id v5sm44155510vsi.24.2019.07.22.09.25.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 09:25:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_23523404.149303177364" MIME-Version: 1.0 Date: Mon, 22 Jul 2019 12:25:32 -0400 Message-ID: <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com> From: "Brock Allen" To: "Leo Tohill" , "" In-Reply-To: References: User-Agent: Mailbird/2.6.1.0 X-Mailbird-ID: 67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com Archived-At: Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for 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, 22 Jul 2019 16:25:39 -0000 ------=_NextPart_23523404.149303177364 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think the implication is that the server-side would use something like OI= DC to the token server in order to establish the identity of the user. The = difference is that this would be driven from the server-side piece of the a= pplication, as any other normal server-side client would. The result would = then simply be a cookie-based authentication session in the client, and any= JS code would leverage the http only, same-site cookie for Ajax calls.=C2= =A0 -Brock On 7/21/2019 10:22:38 PM, Leo Tohill wrote: The advice for the architectural pattern "JavaScript served from a common d= omain as the resource server"=C2=A0 reads: "For simple system architectures, such as when the JavaScript application i= s served from a domain that can share cookies with the domain of the API (resource s= erver), it may be a better decision to avoid using OAuth entirely, and instead use ses= sion authentication to communicate directly with the API." I can agree that session authentication could be best here, but how was the= user authenticated in order to create the trusted session?=C2=A0 Wouldn't = that/shouldn't that still use an oauth flow to collect credentials? We need to be clear on the distinction between browser based apps that hold= the token(s) in the browser space, vs. those that don't.=C2=A0 I agree tha= t with this "common domain" architecture, the tokens should not be held in the browser,= but it doesn't follow that oauth should not be used at all. Leo _______________________________________________ OAuth mailing list OAuth@ie= tf.org https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_23523404.149303177364 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A= =0A = =0A =0A = =0A I think t= he implication is that the server-side would use something like OIDC to the= token server in order to establish the identity of the user. The differenc= e is that this would be driven from the server-side piece of the applicatio= n, as any other normal server-side client would. The result would then simp= ly be a cookie-based authentication session in the client, and any JS code = would leverage the http only, same-site cookie for Ajax calls. 
-Brock

=0A =

On 7/21/2019 1= 0:22:38 PM, Leo Tohill <leotohill@gmail.com> wrote:

The advice fo= r the architectural pattern "JavaScript served from a common domain as the = resource server"  reads:

"For simple syst= em architectures, such as when the JavaScript application is served
from= a domain that can share cookies with the domain of the API (resource serve= r), it
may be a better decision to avoid using OAuth entirely, and inste= ad use session
authentication to communicate directly with the API."

I can agree that session authentication could be best= here, but how was the user authenticated in order to create the trusted se= ssion?  Wouldn't that/shouldn't that still use an oauth flow to collec= t credentials?

We need to be clear on the distinct= ion between browser based apps that hold the token(s) in the browser space,= vs. those that don't.  I agree that with this
"common domain" arc= hitecture, the tokens should not be held in the browser, but it doesn't fol= low that oauth should not be used at all.

Leo=


=0A__________________________= _____________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.i= etf.org/mailman/listinfo/oauth=0A
=0A = =0A
------=_NextPart_23523404.149303177364-- From nobody Mon Jul 22 09:26: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 6AE21120052 for ; Mon, 22 Jul 2019 09:26:04 -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 Z0T3KiL35epc for ; Mon, 22 Jul 2019 09:26:01 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) (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 2D9D0120284 for ; Mon, 22 Jul 2019 09:26:01 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpb8Q-0000r8-AB; Mon, 22 Jul 2019 18:25:58 +0200 From: Torsten Lodderstedt Message-Id: <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_7B555A2A-9E3D-4DBF-A3AB-F2049B13F058"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 18:25:57 +0200 In-Reply-To: Cc: OAuth WG To: Vittorio Bertocci References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 16:26:04 -0000 --Apple-Mail=_7B555A2A-9E3D-4DBF-A3AB-F2049B13F058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22. Jul 2019, at 17:13, Vittorio Bertocci = wrote: >=20 > Thank you Torsten for the prompt review and insightful comments! >=20 > 2.2.1 - excellent point. I added the suggested language. >=20 > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, = where the effect of the request is influencing the layout of the = resulting idtoken, but concluded that it didn't apply as is for access = tokens. Given that you have direct knowledge of such cases in the wild, = I am happy to relax the MUST into a SHOULD. >=20 > 5. - this is going to be problematic in the wild. For example, in the = azure AD world a registered application can play both the role of an API = and a client; and requests for tokens targeting the app can use any = identifier assigned to the app. That means that although idtokens will = only be issued if the request identifies the client via clientID, access = tokens requests for it will be honored (and reflected in aud) both in = the case the resource parameter contains the clientID or the API URI of = the target application. Interesting and (in my opinion) reasonable. Out of the top of my head I = don=E2=80=99t see how this has a negative security impact since the = recipient is always the same service.=20 > In fact I suspect that the most recent version of the service uses the = clientID as preferred identifier, if not the only one. Mike/Tony can = confirm or deny. > As a compromise, we could add language in the spec that recommends the = use of a unique audience when viable, as an extra measure in case the = typ value isn't honored. WDYT? Having a unique audiences at least for different services is key. In fact, I=E2=80=99m concerned about JWT confusion in OIDC RPs in the = wild that do generally not honor the type (as long as we do not update = OIDC Core to require this and it is being adopted). I think since your = draft requires both, iss and aud to be present, this threat is being = dealt with. Additionally stating that unique audiences shall be used for = different services should be ok. > =20 >=20 > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt = wrote: > Hi Vittorio, >=20 > thanks for contributing this specification. It fills a further gap in = the OAuth universe :-) >=20 > Here are my comments: >=20 > - 2.2.1 there are other sources for identity claims, e.g. = https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html.=20= >=20 > I recommend to open the clause >=20 > "Any additional attributes whose semantic is well described by the > attributes description found in section 5.1 of [ > OpenID.Core] SHOULD > be codified in JWT access tokens via the corresponding claim names = in > that section of the OpenID Connect specification. The same holds = for > attributes defined in [RFC7662]." >=20 > by adding=20 >=20 > "and other identity related specifications.=E2=80=9D=20 >=20 > Alternatively, the draft could also refer to the IANA =E2=80=9COAuth = Token Introspection Response=E2=80=9D registry as source for JWT claims. >=20 > - 2.2.2.=20 >=20 > "If an authorization request includes a scope parameter, the > corresponding issued JWT access token MUST include a scope claim as > defined in section 4.2 of [TokenExchange]." >=20 > Why do you establish such a strong link between the scope in the = authorization request and the access token? I=E2=80=99m aware of = implementations that map scope values to audience values and therefore = do not carry the scope value to the resource server. I suggest to soften = this requirement and make it a recommendation.=20 >=20 > - 5.=20 >=20 > "The JWT access token data layout described here is very similar to = the one of the id_token as defined by [OpenID.Core]. Without the > explicit typing required in this profile, in line with the = recommendations in [JWT.BestPractices] there would be the risk of > attackers using JWT access tokens in lieu of id_tokens." >=20 > I like this practice but it is not established yet in the OpenID = Connect universe. This means any OIDC RP will process an access token = because it will just ignore the type header.=20 >=20 > draft-ietf-oauth-jwt-introspection-response therefore gives = recommendation on how to use iss and aud claim to prevent JWT abuse = (https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-0= 4#section-6.1).=20 >=20 > Mapping this pattern to JWTs as access token requires that there must = not be the same aud value for a resource server and any other JWT = consumer, e.g. an OpenID Connect RP.=20 >=20 > kind regards, > Torsten.=20 >=20 > > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Web Authorization Protocol WG of = the IETF. > >=20 > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 = Access Tokens > > Author : Vittorio Bertocci > > Filename : draft-ietf-oauth-access-token-jwt-01.txt > > Pages : 15 > > Date : 2019-07-20 > >=20 > > Abstract: > > This specification defines a profile for issuing OAuth2 access = tokens > > in JSON web token (JWT) format. Authorization servers and = resource > > servers from different vendors can leverage this profile to issue = and > > consume access tokens in interoperable manner. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01= > >=20 > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of = submission > > until the htmlized version and diff are available at tools.ietf.org. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_7B555A2A-9E3D-4DBF-A3AB-F2049B13F058 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 Fw0xOTA3MjIxNjI1NTdaMC8GCSqGSIb3DQEJBDEiBCDlmpwF8NP0HKqMj0a+yK1V1JwaPzbDXaVy K3rE5CcwWTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG SIb3DQEBAQUABIIBAJPzfCLShnck35vMoHoIUG60eL9y0a9Bqjq63gBbdV4b/LufIaiqq+lvWWTa 3fkH6FH3ZRTSQGCp6ymoeqrwwvgosGF2xd+IrmCdecL2LuTOrTdG7uD3/CDFgif/jrIflHTy/ZUj jU2fJptUDwc1qUOI81p0hJIAmGQgk7N1gh8TIW/aWnfzgM2z8ef3XwPO/rpz2FuxEX/EfI33aWqf MGNrkNb+PUkgtZ25XQKU6Pnz37YyidLMF9hD7D0R/5Cot3x+E2o+nM8JKXVpYxrqV2NeAgOm2dh8 aCjDWmXfTa7Ik6Ms7jEXl0F2v417vh9B7RBynsr18KQjelNmhF1bGAIAAAAAAAA= --Apple-Mail=_7B555A2A-9E3D-4DBF-A3AB-F2049B13F058-- From nobody Mon Jul 22 10:09: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 7A4361202F7 for ; Mon, 22 Jul 2019 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sikKZ2PWwozs for ; Mon, 22 Jul 2019 10:09:08 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37AB120288 for ; Mon, 22 Jul 2019 10:09:07 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id x22so34297105qtp.12 for ; Mon, 22 Jul 2019 10:09:07 -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=iqktNLGICu1y+HWZcSJ+Oit4VfP7fSm4VtSh7yWtxmw=; b=CcGBcJAlObltxLoLHvJXRYccCR1nQFmvVRIaDhr7p/Idv7jWf832GuEYr4X78CyRGV 8j8IVt85Gz3Qt9Dt8txeGE8MwHwS2NrnMyLxKqZ99O4mFrIlzqkZo94yIChkRA5B6wt5 s5jk8J8DNeRctLpcoEpvzJzJ+Jd3pJ02Taz6UB53rCjSPnUIaD1Lv3IB/zxfBaIYHPab 4eUJxOdZSQe3X7EcJ2HOnTGomRgVeMh1Pu29rsjw9ucTyBZIR/aHL4ybj72C4Zx5sNng WH9xgNfrtSJh5qZMTBV/J0wlYquNoGaCy9scJKaTxM0BsJvereKVMqyc5lX7pKs9HOMz Edsg== 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=iqktNLGICu1y+HWZcSJ+Oit4VfP7fSm4VtSh7yWtxmw=; b=fodH2cuNi55Dm0sz9q5Xg0/NSb3GKHhWCduXqtwgi/gQwthWul/OxFy/fw37Q8+gKy 6STGFYGpcSZEFCEDn/AeUQ+gy6Jauaiyi5g1/F/gh6KbBy1ykf2da4wVGhL4r/3r2dNx 3qno+/LdgMiPURE6ulSXyaz8Rlw+VnaOHqxbqylIGUZevBmzhyFWwMpgHjxpk+kcb1u0 yDuAlH92FOihhUOhrNZ6MC9XSm0mTZgArBAm8mD87UHaAwuVG1x/xQTGxawZYuGABtok teUOoZyKLLD7GPRDwAMEsZQsP4Bda2eWkaVP6rQmaPorvUQXeC1dkwQY//OhsiDpOeVO wB/Q== X-Gm-Message-State: APjAAAX12ghlkSa04ehsz90uJaNtql73UEkwmf3/XQ/Mw9o1FY1zbR+a 6dQ9mc+j+HRr+6wyzVdcAbb4vNjpnIoxUt+g95IxCQ== X-Google-Smtp-Source: APXvYqzJwjdbgykMZUYTrSv5WAVaNkCTom1Onu6HbLFTatWCEnTuTuIzEXFqMs5lPKjg3q95BnKzVhOqw5zC/e8fmV4= X-Received: by 2002:ad4:4a92:: with SMTP id h18mr51376499qvx.235.1563815345050; Mon, 22 Jul 2019 10:09:05 -0700 (PDT) MIME-Version: 1.0 References: <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com> In-Reply-To: <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com> From: Hans Zandbelt Date: Mon, 22 Jul 2019 19:08:52 +0200 Message-ID: To: Brock Allen Cc: Leo Tohill , oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000022e97f058e4822f7" Archived-At: Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for 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, 22 Jul 2019 17:09:16 -0000 --00000000000022e97f058e4822f7 Content-Type: text/plain; charset="UTF-8" +1, as discussed before Hans. On Mon, Jul 22, 2019, 18:25 Brock Allen wrote: > I think the implication is that the server-side would use something like > OIDC to the token server in order to establish the identity of the user. > The difference is that this would be driven from the server-side piece of > the application, as any other normal server-side client would. The result > would then simply be a cookie-based authentication session in the client, > and any JS code would leverage the http only, same-site cookie for Ajax > calls. > > -Brock > > On 7/21/2019 10:22:38 PM, Leo Tohill wrote: > The advice for the architectural pattern "JavaScript served from a common > domain as the resource server" reads: > > "For simple system architectures, such as when the JavaScript application > is served > from a domain that can share cookies with the domain of the API (resource > server), it > may be a better decision to avoid using OAuth entirely, and instead use > session > authentication to communicate directly with the API." > > I can agree that session authentication could be best here, but how was > the user authenticated in order to create the trusted session? Wouldn't > that/shouldn't that still use an oauth flow to collect credentials? > > We need to be clear on the distinction between browser based apps that > hold the token(s) in the browser space, vs. those that don't. I agree that > with this > "common domain" architecture, the tokens should not be held in the > browser, but it doesn't follow that oauth should not be used at all. > > Leo > > > _______________________________________________ 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 > --00000000000022e97f058e4822f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1, as discussed before

Hans.

On Mon, Jul 22, 2019, 18:25 Brock Allen <brockallen@gmail.com> wrote:
=20 =20 =20 =20 =20 I think the implication is that the= server-side would use something like OIDC to the token server in order to = establish the identity of the user. The difference is that this would be dr= iven from the server-side piece of the application, as any other normal ser= ver-side client would. The result would then simply be a cookie-based authe= ntication session in the client, and any JS code would leverage the http on= ly, same-site cookie for Ajax calls.=C2=A0

-Brock

On 7/21/= 2019 10:22:38 PM, Leo Tohill <leotohill@gmail.com> wrote:

Th= e advice for the architectural pattern "JavaScript served from a commo= n domain as the resource server"=C2=A0 reads:

=
"For simple system architectures, such as when the JavaScript app= lication is served
from a domain that can share cookies with the domain = of the API (resource server), it
may be a better decision to avoid using= OAuth entirely, and instead use session
authentication to communicate d= irectly with the API."

I can agree that sessi= on authentication could be best here, but how was the user authenticated in= order to create the trusted session?=C2=A0 Wouldn't that/shouldn't= that still use an oauth flow to collect credentials?

<= div>We need to be clear on the distinction between browser based apps that = hold the token(s) in the browser space, vs. those that don't.=C2=A0 I a= gree that with this
"common domain" architecture, the tokens = should not be held in the browser, but it doesn't follow that oauth sho= uld not be used at all.

Leo

_______________________________________________ OAuth mailing list OAut= h@ietf.org https://www.ietf.org/mailman/listinfo/oauth
=20
_______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000022e97f058e4822f7-- From nobody Mon Jul 22 11:37: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 018A8120125 for ; Mon, 22 Jul 2019 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrVj0hGNEAHN for ; Mon, 22 Jul 2019 11:36:59 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08770120122 for ; Mon, 22 Jul 2019 11:36:58 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id f4so76179608ioh.6 for ; Mon, 22 Jul 2019 11:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=mcJBp9rIgyo6umSsStGW3KsUnj095EMpzJO9B1G4O34=; b=pVy3wZ0LTHcvP6Oz7EOBYc9lT3FnM0F0iXRHwbLppZ37++llui00hQ0wDu6Dr5E1X0 5CoQ98EagpYByWmkDuRQPzs7ayCDP8ZtHg4usOi5/4bcGTsZrKXW6Zhwwdg9HcJU9mwS X/GJVXzoFTNcF4UKFZbWTRWzaq4frVynu+kwg= 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=mcJBp9rIgyo6umSsStGW3KsUnj095EMpzJO9B1G4O34=; b=UPfvsYTujArLUdpTwKOTNRl+mReCczllW2ZML+ws3dbbgcUYYrlIVEExij0gdiBpZc cAv58Nx4UfFdnV121vcPJnqMOEcB7WGGaFr+Z29VmyY7ysb8P5zwifxz6ChLhkaJWB3S qktermkxQcNrml0R+r7JDnY+sVEGo9yOd1qCF1RRPvOpWUvtA5+cLnJu3V8raS0UBwgg +cEw2sEoeoR8HvRbLIl2mzmr5R1PG5E9HJXA8grb3mK0IUnkQS/jC6uxk2uy964Idx3L SQldmHUdyjXUfD5ZgR4cGqjXHgZ8uJxRC27qxwgIrRJhdJmYpcFTJdcTADAEd49zoSpb mjpw== X-Gm-Message-State: APjAAAVoQ+9bhf7KzvITrAcwExywp5UIrGUmMOTqtz46P3EjJ5dZq/0W 6CoOwvGYo5kc1AhlFOsN9ZjEoQq2iVkM+Cnf2B4cAmH5dzPsK9eDcVqbOOxlhriDU3LLQ8QguMD F+YFbkGnvarXPjVU0Oz+wUg== X-Google-Smtp-Source: APXvYqyHlu7qUp8tjpcGT+G55fbBvt/fxsqzDCEL1yM7uypQCRqJXmhq7mOkPvm3bFDRH52LpZ3s4SUjkyYIbV3MaNo= X-Received: by 2002:a6b:621a:: with SMTP id f26mr58997639iog.127.1563820617867; Mon, 22 Jul 2019 11:36:57 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 22 Jul 2019 12:36:32 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000006bbca9058e495c0e" Archived-At: Subject: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 18:37:01 -0000 --0000000000006bbca9058e495c0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8= .1.2 talks about binding to and checking against the fingerprint of the public key from the client certificate. However, https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a hash of the whole certificate rather than of just the public key. --=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._ --0000000000006bbca9058e495c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#secti= on-4.8.1.2 talks about binding to and checking against the fingerprint = of the public key from the client certificate. However, https://tools.ietf.org/html/d= raft-ietf-oauth-mtls-15 uses a hash of the whole certificate rather tha= n of just the public key.

<= 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. --0000000000006bbca9058e495c0e-- From nobody Mon Jul 22 12:33: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 97CA212004E for ; Mon, 22 Jul 2019 12:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YbheD-cw2NDo for ; Mon, 22 Jul 2019 12:33:08 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B2012012E for ; Mon, 22 Jul 2019 12:33:07 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t28so38729399lje.9 for ; Mon, 22 Jul 2019 12:33:07 -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=a21M2uSSBfcuiPmj3WX4KTS7GagdO42IY/b6bagaMas=; b=pdLAhyaMmz1FNxOc7z9D0XHd8sHV//BM4O7xW3KYDyHYPJDvG6IrC7A6tmhBcyHOkP feNCoz0dE+7mpUlfW38VZSgB0M6NF8nJZ1+Q1KC2Uvjd7HLBt3fgC5zR+5Iel0bwe0Uh MKlYrQ1ADA/Oti8y6oAZ/kr3km4QXNYYSjkOujsglh6wFbeysdyE1LcbIdZgjrhwXQV8 wZfpctvACARBQJSdfljMMKfnwz2SnO5r6HCq5fEwu8fVwpkXTgL8U9g1GJjKIoSbGk6F 8jK4UScaG9RgqHjTHz6H+vCROJT1nxFWtOaFn1ZXWS49Mv9obXln+dvZoRlpA+hNaUqj 3MaQ== 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=a21M2uSSBfcuiPmj3WX4KTS7GagdO42IY/b6bagaMas=; b=aDfTWe01FGXU67qGBhWc1iqcAg/MKwTgDAKmSy+E88x8K1kzZKq9OcDopKFBQohHUh 7tIa+owK84n401BTN6x/jatAZ+6h/dyFuXc41VGG7VesNKZrRjqdtGeo1ICjJVfSE24+ V9r8h5ao3z/jUO7ImJbJjzGDERpmyVovVJRSOYpIrjQAtPbEnzThR6mnzKR9uyMG2aVm oRQnLBz4ecHQ5k8pEc19cV58+cfPJIaIK8dwtn6Ae8GcWtX7kxhP68baKDJciBLuOM4M fhx7XxFKRFXJm7rDX5ydOGWhbHQYFjpJerRvbFSjXyEWwBdvuVhpgRRs5/N3pXLRGyrq epzw== X-Gm-Message-State: APjAAAXFH5Z5YwyJcTHKQOk5z/dZp4eTo6ZyRMf781BOZFFupkDJTOPm zqZ0DMB7Ll1+Gcp/Wa+3mACXM26L0DS3Uuf4AWwLKxEiLMF5MDtC X-Google-Smtp-Source: APXvYqwAmbesGrA6v8SHUTB4RlIMZthMkm4Pt5OQ12SRAZa4ja9CAQzsg8TcKheXOAdudy93ZNYvmwwxRGv/L7FcXrI= X-Received: by 2002:a2e:2d12:: with SMTP id t18mr20166151ljt.175.1563823985908; Mon, 22 Jul 2019 12:33:05 -0700 (PDT) MIME-Version: 1.0 References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net> In-Reply-To: <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net> From: Vittorio Bertocci Date: Mon, 22 Jul 2019 12:32:56 -0700 Message-ID: To: Torsten Lodderstedt Cc: OAuth WG Content-Type: multipart/alternative; boundary="0000000000002bf513058e4a252d" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 19:33:12 -0000 --0000000000002bf513058e4a252d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Additionally stating that unique audiences shall be used for different services should be ok. Fair! I'll add language to that effect in section 5 and update the draft before Friday. thanks! V. On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt wrote: > > > > On 22. Jul 2019, at 17:13, Vittorio Bertocci < > vittorio.bertocci@auth0.com> wrote: > > > > Thank you Torsten for the prompt review and insightful comments! > > > > 2.2.1 - excellent point. I added the suggested language. > > > > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, > where the effect of the request is influencing the layout of the resultin= g > idtoken, but concluded that it didn't apply as is for access tokens. Give= n > that you have direct knowledge of such cases in the wild, I am happy to > relax the MUST into a SHOULD. > > > > 5. - this is going to be problematic in the wild. For example, in the > azure AD world a registered application can play both the role of an API > and a client; and requests for tokens targeting the app can use any > identifier assigned to the app. That means that although idtokens will on= ly > be issued if the request identifies the client via clientID, access token= s > requests for it will be honored (and reflected in aud) both in the case t= he > resource parameter contains the clientID or the API URI of the target > application. > > Interesting and (in my opinion) reasonable. Out of the top of my head I > don=E2=80=99t see how this has a negative security impact since the recip= ient is > always the same service. > > > In fact I suspect that the most recent version of the service uses the > clientID as preferred identifier, if not the only one. Mike/Tony can > confirm or deny. > > As a compromise, we could add language in the spec that recommends the > use of a unique audience when viable, as an extra measure in case the typ > value isn't honored. WDYT? > > Having a unique audiences at least for different services is key. > > In fact, I=E2=80=99m concerned about JWT confusion in OIDC RPs in the wil= d that do > generally not honor the type (as long as we do not update OIDC Core to > require this and it is being adopted). I think since your draft requires > both, iss and aud to be present, this threat is being dealt with. > Additionally stating that unique audiences shall be used for different > services should be ok. > > > > > > > > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi Vittorio, > > > > thanks for contributing this specification. It fills a further gap in > the OAuth universe :-) > > > > Here are my comments: > > > > - 2.2.1 there are other sources for identity claims, e.g. > https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. > > > > I recommend to open the clause > > > > "Any additional attributes whose semantic is well described by the > > attributes description found in section 5.1 of [ > > OpenID.Core] SHOULD > > be codified in JWT access tokens via the corresponding claim names i= n > > that section of the OpenID Connect specification. The same holds fo= r > > attributes defined in [RFC7662]." > > > > by adding > > > > "and other identity related specifications.=E2=80=9D > > > > Alternatively, the draft could also refer to the IANA =E2=80=9COAuth To= ken > Introspection Response=E2=80=9D registry as source for JWT claims. > > > > - 2.2.2. > > > > "If an authorization request includes a scope parameter, the > > corresponding issued JWT access token MUST include a scope claim as > > defined in section 4.2 of [TokenExchange]." > > > > Why do you establish such a strong link between the scope in the > authorization request and the access token? I=E2=80=99m aware of implemen= tations > that map scope values to audience values and therefore do not carry the > scope value to the resource server. I suggest to soften this requirement > and make it a recommendation. > > > > - 5. > > > > "The JWT access token data layout described here is very similar to the > one of the id_token as defined by [OpenID.Core]. Without the > > explicit typing required in this profile, in line with the > recommendations in [JWT.BestPractices] there would be the risk of > > attackers using JWT access tokens in lieu of id_tokens." > > > > I like this practice but it is not established yet in the OpenID Connec= t > universe. This means any OIDC RP will process an access token because it > will just ignore the type header. > > > > draft-ietf-oauth-jwt-introspection-response therefore gives > recommendation on how to use iss and aud claim to prevent JWT abuse ( > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-0= 4#section-6.1). > > > > > Mapping this pattern to JWTs as access token requires that there must > not be the same aud value for a resource server and any other JWT consume= r, > e.g. an OpenID Connect RP. > > > > kind regards, > > Torsten. > > > > > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > > > Author : Vittorio Bertocci > > > Filename : draft-ietf-oauth-access-token-jwt-01.txt > > > Pages : 15 > > > Date : 2019-07-20 > > > > > > Abstract: > > > This specification defines a profile for issuing OAuth2 access toke= ns > > > in JSON web token (JWT) format. Authorization servers and resource > > > servers from different vendors can leverage this profile to issue a= nd > > > consume access tokens in interoperable manner. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0= 1 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt= -01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > --0000000000002bf513058e4a252d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Additionally stating that unique audiences shall= be used for different services should be ok.
Fair! I'll add langu= age to that effect in section 5 and update the draft before Friday.
tha= nks!
V.=C2=A0

On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodde= rstedt <torsten@lodderstedt.n= et> wrote:
vittorio.bertocci@auth0.com= > wrote:
>
> Thank you Torsten for the prompt review and insightful comments!
>
> 2.2.1 - excellent point. I added the suggested language.
>
> 2.2.2 - interesting. I did think of cases similar to profile in OIDC, = where the effect of the request is influencing the layout of the resulting = idtoken, but concluded that it didn't apply as is for access tokens. Gi= ven that you have direct knowledge of such cases in the wild, I am happy to= relax the MUST into a SHOULD.
>
> 5. - this is going to be problematic in the wild. For example, in the = azure AD world a registered application can play both the role of an API an= d a client; and requests for tokens targeting the app can use any identifie= r assigned to the app. That means that although idtokens will only be issue= d if the request identifies the client via clientID, access tokens requests= for it will be honored (and reflected in aud) both in the case the resourc= e parameter contains the clientID or the API URI of the target application.=

Interesting and (in my opinion) reasonable. Out of the top of my head I don= =E2=80=99t see how this has a negative security impact since the recipient = is always the same service.

> In fact I suspect that the most recent version of the service uses the= clientID as preferred identifier, if not the only one. Mike/Tony can confi= rm or deny.
> As a compromise, we could add language in the spec that recommends the= use of a unique audience when viable, as an extra measure in case the typ = value isn't honored. WDYT?

Having a unique audiences at least for different services is key.

In fact, I=E2=80=99m concerned about JWT confusion in OIDC RPs in the wild = that do generally not honor the type (as long as we do not update OIDC Core= to require this and it is being adopted). I think since your draft require= s both, iss and aud to be present, this threat is being dealt with. Additio= nally stating that unique audiences shall be used for different services sh= ould be ok.


>=C2=A0
>
> On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
> Hi Vittorio,
>
> thanks for contributing this specification. It fills a further gap in = the OAuth universe :-)
>
> Here are my comments:
>
> - 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4= -identity-assurance-1_0.html.
>
> I recommend to open the clause
>
> "Any additional attributes whose semantic is well described by th= e
>=C2=A0 =C2=A0 attributes description found in section 5.1 of [
> OpenID.Core] SHOULD
>=C2=A0 =C2=A0 be codified in JWT access tokens via the corresponding cl= aim names in
>=C2=A0 =C2=A0 that section of the OpenID Connect specification.=C2=A0 T= he same holds for
>=C2=A0 =C2=A0 attributes defined in [RFC7662]."
>
> by adding
>
> "and other identity related specifications.=E2=80=9D
>
> Alternatively, the draft could also refer to the IANA =E2=80=9COAuth T= oken Introspection Response=E2=80=9D registry as source for JWT claims.
>
> - 2.2.2.
>
> "If an authorization request includes a scope parameter, the
>=C2=A0 =C2=A0 corresponding issued JWT access token MUST include a scop= e claim as
>=C2=A0 =C2=A0 defined in section 4.2 of [TokenExchange]."
>
> Why do you establish such a strong link between the scope in the autho= rization request and the access token? I=E2=80=99m aware of implementations= that map scope values to audience values and therefore do not carry the sc= ope value to the resource server. I suggest to soften this requirement and = make it a recommendation.
>
> - 5.
>
> "The JWT access token data layout described here is very similar = to the one of the id_token as defined by [OpenID.Core].=C2=A0 Without the >=C2=A0 =C2=A0 explicit typing required in this profile, in line with th= e recommendations in [JWT.BestPractices] there would be the risk of
>=C2=A0 =C2=A0 attackers using JWT access tokens in lieu of id_tokens.&q= uot;
>
> I like this practice but it is not established yet in the OpenID Conne= ct universe. This means any OIDC RP will process an access token because it= will just ignore the type header.
>
> draft-ietf-oauth-jwt-introspection-response therefore gives recommenda= tion on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf.org/html/dr= aft-ietf-oauth-jwt-introspection-response-04#section-6.1).
>
> Mapping this pattern to JWTs as access token requires that there must = not be the same aud value for a resource server and any other JWT consumer,= e.g. an OpenID Connect RP.
>
> kind regards,
> Torsten.
>
> > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > This draft is a work item of the Web Authorization Protocol WG of= the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Vittorio Bertocci
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : d= raft-ietf-oauth-access-token-jwt-01.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 15
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : 2019-07-20
> >
> > Abstract:
> >=C2=A0 =C2=A0This specification defines a profile for issuing OAut= h2 access tokens
> >=C2=A0 =C2=A0in JSON web token (JWT) format.=C2=A0 Authorization s= ervers and resource
> >=C2=A0 =C2=A0servers from different vendors can leverage this prof= ile to issue and
> >=C2=A0 =C2=A0consume access tokens in interoperable manner.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.iet= f.org/doc/draft-ietf-oauth-access-token-jwt/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/htm= l/draft-ietf-oauth-access-token-jwt-01
> > https://datatrac= ker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01
> >
> >
> > Please note that it may take a couple of minutes from the time of= submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>

--0000000000002bf513058e4a252d-- From nobody Mon Jul 22 13:44: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 A238F1200FD for ; Mon, 22 Jul 2019 13:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 KHz0KrQXZf2R for ; Mon, 22 Jul 2019 13:44:47 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9D61200A3 for ; Mon, 22 Jul 2019 13:44:47 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id a15so36444008wmj.5 for ; Mon, 22 Jul 2019 13:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CYDQK0hdte5qk1aynrJdhS+lUybMgXqMGCOhyyiO/Ic=; b=W7Hjj7/q1n9gh/r1K0lRLfpFA6dOieSoiwLpFtPwrcCP6WNQrmMDWTFAGmpIdOwqnm 5YQF1vfiKWtrSaEs3bTi9CwgdMD0l0j6eHAyfUlt7vE+n8SPtlk3VxdR6OZ+VFsMIHOM 0lMS1CiJTcqYcjpAL18KTpTdtDFKpRsfV90G6aT4ogWcKXCEW/5g/IadBfHzodNv87Ix ksN77I2pFx3C1mcrBAndZJlN8zfMttxa3fEaCP8cA+Tqm6KZFX1cGICgi//SoAI3I0Xj t0XIi77nUGFnfP6VVeFnrQ36uxgtPZ5U0t/wcB6inEDrfA3a+QxHLnEUh0Wc2W1+HW4g D/7g== 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=CYDQK0hdte5qk1aynrJdhS+lUybMgXqMGCOhyyiO/Ic=; b=B3YBUShufv8JyHHjgOw3kZJFf8ZKU4xqdlCA4ULCF6XEk67JKzkZ8NAYRspbhYKmiT s/D/Cr/F0JmOw5gNHOcnWBMeIW2h49bjVGtY+jvoinHEUZzN/419YlsxxLCXFYStZVd8 4/CPzttP2yCIOlteboHOQJBABs2TWCXERKDcaa0geDORrt6JWpOxuyzksSInE7LRH2pR nM3owSpVq3Z8nd+/snGk/vIgxHDytM0NzjHH7hIhBXef40e2tN7ANIxGqhCVu6P/Dd7L U10MmuyyD/ZIijM6/mIdsr4cdFED6J4iqG6GtlJKwi3QWyAs2hGpTSEZBO3YE7SDdC0w WX3A== X-Gm-Message-State: APjAAAXlCRE5WDVNzEYGnzFztHoUg4CVNHd43xYLzXNsfGpGiT314kms aXJ9RbOTjFGRfpHBP5ToJWFp/4Ihw8gUXSoFXO4s5nCL X-Google-Smtp-Source: APXvYqyNXDi5nd3sRVbk3tfYokbT6k6I+rprTFYu5ZkCWt6h3rZKpAiDZBi0zGY71mzwPNyCYjsyUrnafay49ipc1TI= X-Received: by 2002:a1c:b707:: with SMTP id h7mr63983132wmf.45.1563828284429; Mon, 22 Jul 2019 13:44:44 -0700 (PDT) MIME-Version: 1.0 From: Mike Booth Date: Mon, 22 Jul 2019 13:44:32 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006220d0058e4b254b" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 20:44:49 -0000 --0000000000006220d0058e4b254b Content-Type: text/plain; charset="UTF-8" --0000000000006220d0058e4b254b Content-Type: text/html; charset="UTF-8"
--0000000000006220d0058e4b254b-- From nobody Mon Jul 22 14:46: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 0C08B1200B8 for ; Mon, 22 Jul 2019 14:46:35 -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 uX8_1VTQDfCg for ; Mon, 22 Jul 2019 14:46:32 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223841200B6 for ; Mon, 22 Jul 2019 14:46:32 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id b29so20531073lfq.1 for ; Mon, 22 Jul 2019 14:46:32 -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=ho2Fnu9EaXFdQ94b8Hn+NLR1dQ6LIb6YPviowWxH0G4=; b=cjNQQez8JB6m6ls80nh8vNDfh69qU4FycJnBcgk/0flgqb5nVnuumP9kv8uLpKS2o0 iy3QPdwNYVQnIH6X/R/lDERB6/eePAB1owfcXCknEv2ovl/AtDi2uzB5CcYArxICGYkz kjtxIAKY07jZV+duMM0Qu4abzwJF4ejYv+4qKBUigh7rhw+Zwnu+TaEF/C4GubAlHY0+ IlLejJRmFcSgnlhNkKauOdUNe3OXtQe0DDL7GcqgwZrLUfzxm9M91aTRFnHSGaLas4mm OXZ8QWhN3Cd+1x70on4ZSmce1iUGWGUftsCCjXUkUicBXBTOuHz9Vq1lkfMoJ8MyIReg k+YA== 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=ho2Fnu9EaXFdQ94b8Hn+NLR1dQ6LIb6YPviowWxH0G4=; b=AUkE9zvc4KlVds41fAXXpcsqZ7mib8sse+wh9hBOwgogmDhtMgS4ZIXxcpvb7UnKEe hwSe7xMRzb0xm+QAVvPBP4uJW6rYbLj+thG6wBXrlo4R/jga9LAgg/8yfYOsMkJFXyXH ijGpZIXhwLjQAMyeg+T02r7BKJ3wnCVRj87NpBL41BgyNn5zkB3XfRODKqkqmBji1di/ eQ2CBN7uUpNNBm4a7tiR9eJIsgxxSOp10OuJPsc7zCRVxx5oCGthXHFOmmwKR1kRITFt c9kN/EqGPwGz2RPIM1WNno0BQHvU+V8r1NycU58foSnrG/fQ1ybIiwGcaZYk1VuYtM+F fckg== X-Gm-Message-State: APjAAAUjrSTdVKq77cjhAl/q4aygBz3IvQApJWnZfyMZGyOV/t1072aG K3w3owGt4yQjoe1fcWuety65aWNC8ptiMyTMoG4= X-Google-Smtp-Source: APXvYqzaqugvwY8LLQFmf7qULIZXzJMxwU2mOWAebj2vocHd/zxPYZBFHnvee2lAWRm8wo4vdLjrFM+1lsO/ERn2WpA= X-Received: by 2002:ac2:546a:: with SMTP id e10mr33651854lfn.75.1563831990256; Mon, 22 Jul 2019 14:46:30 -0700 (PDT) MIME-Version: 1.0 References: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> In-Reply-To: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> From: Dick Hardt Date: Mon, 22 Jul 2019 17:46:19 -0400 Message-ID: To: Neil Madden Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="000000000000448906058e4c02e5" Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 22 Jul 2019 21:46:35 -0000 --000000000000448906058e4c02e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil I see that you are looking at how to modify Justin's proposal, and I'm looking at what are the requirements. Ignoring the specifics, is there a reason why multiple tokens need to be returned in the same request? On Mon, Jul 22, 2019 at 9:41 AM Neil Madden wrote: > > On 21 Jul 2019, at 22:22, Dick Hardt wrote: > > Hi Neil, I agree that an access token that is usable across resources is > problematic. > > How are you thinking multiple access tokens would be returned? > > > Well there are lots of possible ways, e.g.: > > { > "tokens": [ > { "resource": "https://res1", "access_token": "..." }, > { "resource": "res2", ...}, ... > ] > } > > I'm not particularly wedded to any format. > > Why do you think the request needs to return multiple tokens rather than > making a separate request for each token? That would seem to simplify the > request and response as context would only need to provided for the one > access token. > > > Note that in Aaron's proposal we have a "user" section on (presumably) > every access token response, which indicates a userinfo endpoint that > itself needs an access token. So either the same access token is used to > access that userinfo endpoint (which means that the RS can also access th= e > userinfo endpoint), or else we already need to return a second access tok= en > in the same request, e.g.: > > { > "access_token": { > "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type": "bearer" > }, > "user": { > "id": "5035678642", > "userinfo": "https://authorization-server.com/user/5035678642", > "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk" > } > } > > > > > On Fri, Jul 19, 2019 at 11:42 PM Neil Madden > wrote: > >> If we=E2=80=99re going to redesign OAuth, one improvement would be to al= low a >> client to request different access tokens for different resource servers= in >> a single request. That should include issuing a different access token f= or >> the userinfo endpoint vs other RSes. >> >> One of the weaknesses of combined OAuth + OIDC use now is that if you >> request OIDC scopes and scopes for another resource in the same request >> then you inadvertently give those other RSes access to the user=E2=80=99= s profile. >> >> =E2=80=94 Neil >> >> On 20 Jul 2019, at 01:02, Aaron Parecki wrote: >> >> Hi all, I'm looking forward to the discussion on this on Tuesday! >> >> I wanted to add my thoughts on a potential addition to this draft, >> specifically around returning some minimal user information in the >> transaction response. >> >> The summary of the suggestion is to return a new "user" key along with >> the access token that contains the user ID and userinfo endpoint, such a= s: >> >> { >> "access_token": { >> "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type": "bearer" >> }, >> "user": { >> "id": "5035678642", >> "userinfo": "https://authorization-server.com/user/5035678642" >> } >> } >> >> A more detailed analysis of the specific proposal and motivation behind >> this is available on my blog: >> >> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz >> >> Thanks! >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> >> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer wrote: >> >>> I have requested time to present Transactional Authorization (the XYZ >>> project) at the Montreal meeting in a couple weeks. Ahead of that, I=E2= =80=99ve >>> uploaded a new version of the spec: >>> >>> https://tools.ietf.org/html/draft-richer-transactional-authz-02 >>> >>> Additionally, I=E2=80=99ve updated the writeup and examples on >>> https://oauth.xyz/ >>> >>> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested= from the >>> chairs that I present during the Tuesday session due to limited >>> availability of some key WG members on Friday. >>> >>> =E2=80=94 Justin >>> >>> _______________________________________________ >>> 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 >> > > --000000000000448906058e4c02e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil

I see that you are looking at h= ow to modify Justin's proposal, and I'm looking at what are the req= uirements.

Ignoring the specifics, is there a reas= on why multiple tokens need to be returned in the same request?
<= br>

On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <neil.madden@forgerock.com> wrote:

On 21 Jul 2019, = at 22:22, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Neil, I a= gree that an access token that is usable across resources is problematic.
How are you thinking multiple access tokens would be retu= rned?

Well there are lots= of possible ways, e.g.:

{
"tokens&= quot;: [
=C2=A0 =C2=A0 { "resource": "https://res1", "access_token&q= uot;: "..." },=C2=A0
=C2=A0 =C2=A0 { "resource&quo= t;: "res2", ...}, ...
]
}

I'm not particularly wedded to any format.

Why do you think the req= uest needs to return multiple tokens rather than making a separate request = for each token? That would seem to simplify the request and response as con= text would only need to provided for the one access token.

Note that in Aaron's proposal we have= a "user" section on (presumably) every access token response, wh= ich indicates a userinfo endpoint that itself needs an access token. So eit= her the same access token is used to access that userinfo endpoint (which m= eans that the RS can also access the userinfo endpoint), or else we already= need to return a second access token in the same request, e.g.:
=
{
= =C2=A0 =C2=A0=C2=A0=C2=A0 "access_token": {
=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0 "value": "UM1P9PMHKUR64TB8N6BW7OZB= 8CDFONP219RP1LT0",
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "= ;type": "bearer"
=C2=A0 =C2=A0=C2=A0=C2=A0 },
=C2=A0 =C2=A0=C2=A0=C2=A0 "user": {
= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "id": "5035678642",
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "userinfo": "https://authorization-server.co= m/user/5035678642",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo_at": "b0D= l3KsXXOGc7tWfFLZYv7G5bXk"
=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0 =C2=A0=C2=A0}




On Fri, Jul 19, 2019 at 11:42 PM= Neil Madden <neil.madden@forgerock.com> wrote:
If we=E2=80=99re going to redesign OAuth, one improvement woul= d be to allow a client to request different access tokens for different res= ource servers in a single request. That should include issuing a different = access token for the userinfo endpoint vs other RSes.=C2=A0

One of the weaknesses of combined OAuth= + OIDC use now is that if you request OIDC scopes and scopes for another r= esource in the same request then you inadvertently give those other RSes ac= cess to the user=E2=80=99s profile.=C2=A0

<= div dir=3D"ltr">=E2=80=94 Neil

On 20 Jul 2019, at= 01:02, Aaron Parecki <aaron@parecki.com> wrote:

Hi all, I'm looking forward to the= discussion on this on Tuesday!

I wanted to add my thoug= hts on a potential addition to this draft, specifically around returning so= me minimal user information in the transaction response.

The summary of the suggestion is to return a new "user" ke= y along with the access token that contains the user ID and userinfo endpoi= nt, such as:

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0=C2= =A0=C2=A0 "access_token": {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 &= quot;value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "type": "bearer"
= =C2=A0 =C2=A0=C2=A0=C2=A0 },
=C2=A0 =C2=A0=C2=A0=C2=A0 "user":= {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "id": "5035678642&quo= t;,
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "userinfo": "htt= ps://authorization-server.com/user/5035678642"
=C2=A0 =C2=A0=C2= =A0=C2=A0 }
=C2=A0 =C2=A0=C2=A0}

A more detailed = analysis of the specific proposal and motivation behind this is available o= n my blog:


Th= anks!

----
=
Aaron Parecki



On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jricher@mit.edu> wrote:
=
I have requested time to present Transactional Authorization (the XYZ proje= ct) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve = uploaded a new version of the spec:


Additionally, I=E2=80=99ve updated the writeup and examples on https://oauth.xyz/=C2=A0

I plan to be in Montreal for the whole week, and I=E2=80=99ve requeste= d from the chairs that I present during the Tuesday session due to limited = availability of some key WG members on Friday.=C2=A0

=E2=80=94 Justin

_______________________________________________
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

--000000000000448906058e4c02e5-- From nobody Mon Jul 22 17:51: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 E51801200CD for ; Mon, 22 Jul 2019 17:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 CBaYhIZ5qEAv for ; Mon, 22 Jul 2019 17:51:08 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B598120045 for ; Mon, 22 Jul 2019 17:51:08 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0p7ks025616; Mon, 22 Jul 2019 20:51:07 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6N0p7ks025616 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563843067; bh=UVZvgSr2pFhxdBRoX34GDkKN6wkncW1g339xQ5G+Bn0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=posPnzMFaDLoH3+HozS7/ZXxgLkM0C5n6fTa7JXNfDntR8IXZVSrpnj4MLl4W1v4I 39wMHe8c2dceCtRkJY7HUiWGGBQxvrKA0CoBd5Oc6OrvX0VURpkRRsVyf0mRyF1oY/ 3vM10UwyBYI6nymCdk1IvFtK5ce7D7Vu4Ubvp+r4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0p4HA016900; Mon, 22 Jul 2019 20:51:04 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 20:51:03 -0400 From: Roman Danyliw To: Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03 Thread-Index: AdU8um9EYRsZS/zUTimSMgl/pofXXQD431IAABQoH3A= Date: Tue, 23 Jul 2019 00:51:03 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> In-Reply-To: <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Jul 2019 00:51:11 -0000 SGkgVG9yc3RlbiENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb3Jz dGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo+IFNlbnQ6 IE1vbmRheSwgSnVseSAyMiwgMjAxOSA2OjU5IEFNDQo+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRA Y2VydC5vcmc+DQo+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdH XSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tDQo+IHJlc3Bv bnNlLTAzDQo+IA0KPiBIaSBSb21hbiwNCj4gDQo+IHRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZp ZXcgZmVlZGJhY2suDQo+IA0KPiBJIGp1c3QgcHVibGlzaGVkIGEgbmV3IHJldmlzaW9uIG9mIHRo ZSBkcmFmdCBpbmNvcnBvcmF0aW5nIGNoYW5nZXMgYmFzZWQgb24NCj4geW91ciBjb21tZW50cy4N Cj4gDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1p bnRyb3NwZWN0aW9uLXJlc3BvbnNlLTA0DQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4gSSBoYXZl IG9uZSByZWZpbmVtZW50IGJlbG93IGJhc2VkIG9uIHRoZSBuZXcgbGFuZ3VhZ2UgYXJvdW5kIFRM Uy4gIERldGFpbHMgYXJlIGlubGluZSAuLi4NCg0KPiA+IE9uIDE3LiBKdWwgMjAxOSwgYXQgMTg6 MTcsIFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4gd3JvdGU6DQo+ID4NCj4gPiBIaSENCj4g Pg0KPiA+IFRoZSBmb2xsb3dpbmcgaXMgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgt and0LWludHJvc3BlY3Rpb24tDQo+IHJlc3BvbnNlLTAzLg0KPiA+DQo+ID4gKDEpIFNlY3Rpb24g NC4gIFBlciBpbnRyb3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGcsIGhvdyBpcyBlaXRo ZXINCj4gc2lnbmluZyBvciBlbmNyeXB0aW9uIGJlaW5nIHJlcXVlc3RlZD8gIElzIGl0IGJ5IGFs c28gaW5jbHVkaW5nIGFuDQo+IGludHJvc3BlY3Rpb25fc2lnbmVkX3Jlc3BvbnNlX2FsZz8gIElm IHRoYXQncyB0aGUgY2FzZSwgaXQgaXMgd29ydGggZXhwbGljaXRseQ0KPiBzYXlpbmcuDQo+IA0K PiBUaGUgcmVzcG9uc2UgaXMgYWx3YXlzIHNpZ25lZC4gVGhlIHJlc291cmNlIHNlcnZlciBtYXkg ZGVjaWRlIHRvDQo+IGFkZGl0aW9uYWxseSB0dXJuIG9uIGVuY3J5cHRpb24uDQo+IA0KPiBTZWN0 aW9uIDMgc3RhdGVzIOKAnERlcGVuZGluZyBvbiB0aGUgc3BlY2lmaWMgcmVzb3VyY2Ugc2VydmVy IHBvbGljeSB0aGUgSldUIGlzDQo+IGVpdGhlciBzaWduZWQsIG9yIHNpZ25lZCBhbmQgZW5jcnlw dGVkLiDigJwNCg0KV2l0aCB0aGUgbmV3IGxhbmd1YWdlIHlvdSBhZGRlZCBmb3IgaXRlbSAjMiwg SSBub3cgdW5kZXJzdGFuZC4gIFRoYW5rcyBmb3IgY2xlYXJpbmcgaXQgdXAuDQoNCj4gPiAoMikg U2VjdGlvbiA0LiAgUGVyIGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2VuYywgSSdt IGhhdmluZw0KPiB0cm91YmxlIGRlY29uZmxpY3RpbmcgdGhlc2UgdHdvIHNlbnRlbmNlczoNCj4g Pg0KPiA+IFsxXSBJZiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnIiBpcyBz cGVjaWZpZWQsIHRoZSBkZWZhdWx0IGZvcg0KPiB0aGlzIHZhbHVlIGlzIEExMjhDQkMtSFMyNTYu DQo+ID4NCj4gPiBbMl0gV2hlbiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfZW5j IiBpcyBpbmNsdWRlZCwNCj4gImludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZyIg TVVTVCBhbHNvIGJlIHByb3ZpZGVkDQo+ID4NCj4gPiBTZW50ZW5jZSBbMl0gZXhwbGljaXRseSBz dGF0ZXMgdGhhdCAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnIg0KPiBpcyBy ZXF1aXJlZC4gIEhvd2V2ZXIsIHRoZSBmaXJzdCBzZW50ZW5jZSBzZWVtcyBtb3JlIHRlbnRhdGl2 ZSBieSBzYXlpbmcgdGhhdA0KPiAiaWYgaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2Vf ZW5jIiBpcyBwcmVzZW50Lg0KPiANCj4gaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2Vf ZW5jIGlzIG9wdGlvbmFsIGJ1dCBtdXN0IG5vdCBiZQ0KPiBzcGVjaWZpZWQgd2l0aG91dCBpbnRy b3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGcNCj4gDQo+IEkgY2hhbmdlZCB0aGUgdGV4 dCB0byBiZXR0ZXIgZ2V0IHRoaXMgYWNyb3NzOg0KPiANCj4gaW50cm9zcGVjdGlvbl9lbmNyeXB0 ZWRfcmVzcG9uc2VfYWxnDQo+IE9QVElPTkFMLiBKV0UgYWxnb3JpdGhtIChhbGcgdmFsdWUpIGFz IGRlZmluZWQgaW4gSldBIGZvciBlbmNyeXB0aW5nDQo+IGludHJvc3BlY3Rpb24gcmVzcG9uc2Vz LiBJZiB0aGlzIGlzIHNwZWNpZmllZCwgdGhlIHJlc3BvbnNlIHdpbGwgYmUgZW5jcnlwdGVkDQo+ IHVzaW5nIEpXRSBhbmQgdGhlIGNvbmZpZ3VyZWQgYWxnb3JpdGhtLiBUaGUgZGVmYXVsdCwgaWYg b21pdHRlZCwgaXMgdGhhdCBubw0KPiBlbmNyeXB0aW9uIGlzIHBlcmZvcm1lZC4gSWYgYm90aCBz aWduaW5nIGFuZCBlbmNyeXB0aW9uIGFyZSByZXF1ZXN0ZWQsIHRoZQ0KPiByZXNwb25zZSB3aWxs IGJlIHNpZ25lZCB0aGVuIGVuY3J5cHRlZCwgd2l0aCB0aGUgcmVzdWx0IGJlaW5nIGEgTmVzdGVk IEpXVCwNCj4gYXMgZGVmaW5lZCBpbiBKV1QuDQo+IA0KPiBpbnRyb3NwZWN0aW9uX2VuY3J5cHRl ZF9yZXNwb25zZV9lbmMNCj4gT1BUSU9OQUwuIEpXRSBhbGdvcml0aG0gKGVuYyB2YWx1ZSkgYXMg ZGVmaW5lZCBpbiBKV0EgZm9yIGF1dGhlbnRpY2F0ZWQNCj4gZW5jcnlwdGlvbiBvZiBpbnRyb3Nw ZWN0aW9uIHJlc3BvbnNlcy4gVGhlIGRlZmF1bHQsIGlmIG9taXR0ZWQsIGlzIEExMjhDQkMtDQo+ IEhTMjU2LiBOb3RlOiBUaGlzIHBhcmFtZXRlciBNVVNUIE5PVCBiZSBzcGVjaWZpZWQgd2l0aG91 dCBzZXR0aW5nDQo+IGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZy4NCg0KVGhh bmtzIGZvciB0aGlzIG5ldyB0ZXh0LiAgSXQgaXMgY2xlYXJlci4NCg0KIA0KPiA+DQo+ID4gKDMp IEkgd2FudCB0byB0YWxrIHRocm91Z2ggdGhlIHBlcnNvbmFsbHkgaWRlbnRpZmlhYmxlIGluZm9y bWF0aW9uIGJlaW5nDQo+IHNwZWNpZmllZCBhcyBuZXcgaW50cm9zcGVjdGlvbiBmaWVsZHMgcGVy IFNlY3Rpb24gOC4zIChlLmcuLCBuYW1lLCBiaXJ0aGRheSkNCj4gYmVpbmcgZXhwb3NlZC4gIEkg d2FzIGxvb2tpbmcgdG8gZW5zdXJlIHRoYXQgaXQgd291bGQgYWx3YXlzIGJlIGVuY3J5cHRlZCBp bg0KPiB0cmFuc2l0IChhbmQgdGhhdCBvbmx5IGF1dGhvcml6ZWQgY2xpZW50cyBjb3VsZCBnZXQg aXQpLiAgSSByZWFkIHRoYXQgaW4gU2VjdGlvbg0KPiAzLCAiW2RdZXBlbmRpbmcgb24gdGhlIHNw ZWNpZmljIHJlc291cmNlIHNlcnZlciBwb2xpY3kgdGhlIEpXVCBpcyBlaXRoZXINCj4gc2lnbmVk LCBvciBzaWduZWQgYW5kIGVuY3J5cHRlZCIgYW5kIHRoYXQgcGVyIFNlY3Rpb24gNCB0aGF0ICJb dF1oZQ0KPiBhdXRob3JpemF0aW9uIHNlcnZlciBkZXRlcm1pbmVzIHdoYXQgYWxnb3JpdGhtIHRv IGVtcGxveSB0byBzZWN1cmUgdGhlDQo+IEpXVCBmb3IgYSBwYXJ0aWN1bGFyIGludHJvc3BlY3Rp b24gcmVzcG9uc2UuIiAgU2VjdGlvbiA2LjIgZXhwbGljaXRseSBub3RlcyB0aGUNCj4gdGhyZWF0 IG9mIHRva2VuIGRhdGEgbGVha2FnZSAoYSBtb3JlIGdlbmVyYWwgY2FzZSBvZiBteSBjb25jZXJu IHNvIHRoYW5rcw0KPiBmb3IgdGhhdCB0ZXh0KS4gW1JGQzc2NjJdLCBTZWN0aW9uIDQgbm90ZXMg b25seSB0aGF0ICJ0aGUgc2VydmVyIE1VU1Qgc3VwcG9ydA0KPiBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgKFRMUykgMS4yIiwgYnV0ICJzdXBwb3J0IiBpcyBkaWZmZXJlbnQgdGhhbiAidGhlDQo+ IHNlcnZlciBNVVNUIF91c2VfIFRMUyIuIFRoZXJlZm9yZSwgaXQgc2VlbXMgbGlrZSB0aGVyZSBj b3VsZCBiZSBhIGNhc2Ugd2hlcmUNCj4gdGhlIHNlcnZlciBjb3VsZCByZXR1cm4gYW4gaW50cm9z cGVjdGlvbiByZXNwb25zZSBpbiB0aGUgY2xlYXIgKGUuZy4sIG5vIFRMUywNCj4gaW50cm9zcGVj dGlvbl9zaWcNCj4gPiBuZWRfcmVzcG9uc2VfYWxnKS4gIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/ DQo+ID4NCj4gPiBNeSBiaWFzIGlzIHRvIHNheSBzb21ldGhpbmcgb24gdGhlIG9yZGVyIG9mICJU TFMgTVVTVCBiZSB1c2Vk4oCdLg0KPiANCj4gU2VjdGlvbiA2LjIuIG5vdyBzdGFydHMgd2l0aCDi gJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB1c2UgVHJhbnNwb3J0DQo+IExheWVyIFNl Y3VyaXR5IChUTFMpIDEuMiAob3IgaGlnaGVyKSBpbiBvcmRlciB0byBwcmV2ZW50IHRva2VuIGRh dGEgbGVha2FnZS4iDQoNCldvcmtzIGZvciBtZSB0byB3YXMgdXNlIFRMUy4gIEknZCByZWNvbW1l bmQgYSBzdGF0ZW1lbnQgdGhhdCBwcm92aWRlcyBtb3JlIGd1aWRhbmNlICJUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVCB1c2UgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIDEuMiAo b3IgaGlnaGVyKSBwZXIgUkZDNzUyNSBpbiBvcmRlciB0byBwcmV2ZW50IHRva2VuIGRhdGEgbGVh a2FnZS4iDQoNCj4gPiAoNCkgSSBhbHNvIHdhbnQgdG8gdGFsayB0aHJvdWdoIGFuIHVuc2NydXB1 bG91cyBwcm90ZWN0ZWQgcmVzb3VyY2UgdHJ5aW5nIHRvDQo+IGhhcnZlc3QgaW50cm9zcGVjdGlv biBtZXRhLWRhdGEuICBJIHdhcyBsb29raW5nIGZvciBndWlkYW5jZSByZWxhdGVkIHRvIHRoZQ0K PiBhdXRob3JpemF0aW9uIG9mIHRoZSBpbnRyb3NwZWN0aW9uIHRyYW5zYWN0aW9ucy4gIEkgZm91 bmQ6DQo+ID4NCj4gPiBTZWN0aW9uIDIuMiBvZiBbUkZDNzY2Ml0gc2F5cyBpbXBvcnRhbnQgdGhp bmdzIGxpa2UgIkZvciBpbnN0YW5jZSwgYW4NCj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGxp bWl0IHdoaWNoIHNjb3BlcyBmcm9tIGEgZ2l2ZW4gdG9rZW4gYXJlDQo+IHJldHVybmVkIGZvciBl YWNoIHByb3RlY3RlZCByZXNvdXJjZSB0byBwcmV2ZW50IGEgcHJvdGVjdGVkIHJlc291cmNlIGZy b20NCj4gbGVhcm5pbmcgbW9yZSBhYm91dCB0aGUgbGFyZ2VyIG5ldHdvcmsgdGhhbiBpcyBuZWNl c3NhcnkgZm9yIGl0cyBvcGVyYXRpb24uIg0KPiA+DQo+ID4gU2VjdGlvbiA0IG9mIFtSRkM3NjYy XSBzYXlzICJJZiBsZWZ0IHVucHJvdGVjdGVkIGFuZCB1bi10aHJvdHRsZWQsIHRoZQ0KPiBpbnRy b3NwZWN0aW9uIGVuZHBvaW50IGNvdWxkIHByZXNlbnQgYSBtZWFucyBmb3IgYW4gYXR0YWNrZXIg dG8gcG9sbCBhIHNlcmllcw0KPiBvZiBwb3NzaWJsZSB0b2tlbiB2YWx1ZXMsIGZpc2hpbmcgZm9y IGEgdmFsaWQgdG9rZW4uICBUbyBwcmV2ZW50IHRoaXMsIHRoZQ0KPiBhdXRob3JpemF0aW9uIHNl cnZlciBNVVNUIHJlcXVpcmUgYXV0aGVudGljYXRpb24gb2YgcHJvdGVjdGVkIHJlc291cmNlcw0K PiB0aGF0IG5lZWQgdG8gYWNjZXNzIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGFuZCBTSE9V TEQgcmVxdWlyZQ0KPiBwcm90ZWN0ZWQgcmVzb3VyY2VzIHRvIGJlIHNwZWNpZmljYWxseSBhdXRo b3JpemVkIHRvIGNhbGwgdGhlICBpbnRyb3NwZWN0aW9uDQo+IGVuZHBvaW50LiINCj4gPg0KPiA+ IFNlY3Rpb24gNi4yIG9mIHRoaXMgZHJhZnQgcHJvdmlkZXMgZ3VpZGFuY2Ugb24gZGVmZW5kaW5n IGFnYWluc3QNCj4gdW5hdXRoZW50aWNhdGVkIGNsaWVudHMuDQo+ID4NCj4gPiBIb3cgZG9lcyB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzdHJpY3QgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgdGhh dCBfY2FuXw0KPiBhdXRoZW50aWNhdGUgdG8gaXQgZnJvbSBnZXR0aW5nIG1ldGEtZGF0YSBpcyBz aG91bGRuJ3QgaGF2ZSBhY2Nlc3MgdG8/DQo+IFNvbWV0aGluZyBvbiB0aGUgb3JkZXIgb2YgInRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciA8dXNlcyB0aGUgZm9sbG93aW5nDQo+IGRhdGE+IHRvIGRl dGVybWluZSB3aGF0IGEgZ2l2ZW4gcHJvdGVjdGVkIHJlc291cmNlIGlzIGFsbG93ZWQgdG8gc2Vl 4oCdLg0KPiANCj4gSSBhZGRlZCBTZWN0aW9uIDYuMywgd2hpY2ggc3RhdGVzIOKAnFRoZSBhdXRo b3Jpc2F0aW9uIHNlcnZlciBkZXRlcm1pbmVzIHRoZQ0KPiB0b2tlbiBkYXRhIGEgcmVzb3VyY2Ug c2VydmVyIGlzIGFsbG93ZWQgdG8gc2VlIGJhc2VkIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXLigJlz DQo+IGNsaWVudF9pZCBhbmQgc3VpdGFibGUgdG9rZW4gZGF0YSwgZS5nLiB0aGUgc2NvcGUgdmFs dWUuIg0KDQpHcmVhdC4gVGhhbmtzIGZvciB0aGUgY2xhcml0eS4NCg0KPiA+DQo+ID4gKDUpIEVk aXRvcmlhbCBOaXRzDQo+ID4NCj4gPiAqKiBTZWN0aW9uIDMuICBQZXIgIlRoaXMgSldUIE1BWSBm dXJ0aGVybW9yZSBjb250YWluIGFsbCBvdGhlciBjbGFpbXMNCj4gZGVzY3JpYmVkIGluIFNlY3Rp b24gMi4yLiBvZiBbUkZDNzY2Ml0gYW5kIGJleW9uZCAoZS5nLiBhcyBkZWZpbmVkIGluDQo+IFtP cGVuSUQuQ29yZV0pIiwgd291bGQgaXQgYmUgbW9yZSB0aW1lbGVzcyB0byBzYXkgdGhlIGZpZWxk cyBzcGVjaWZpZWQgaW4NCj4gIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24gUmVzcG9uc2UiIHJl Z2lzdHJ5Pw0KPiA+DQo+IA0KPiBUaGlzIHRleHQgcHJlLWRhdGVkIHRoZSBhZGRpdGlvbiBvZiB0 aGUgSUFOQSByZWdpc3RyeSBzZWN0aW9uLiBUaGFua3MgZm9yDQo+IHNwb3R0aW5nIHRoZSBpbmNv bnNpc3RlbmN5Lg0KPiANCj4gSSBtb2RpZmllZCB0aGUgdGV4dCBhcyB5b3Ugc3VnZ2VzdGVkLg0K PiANCj4gPiAqKiBTZWN0aW9uIDQuICBUaGUgZmlyc3Qgc2VudGVuY2Ugb2YgZWFjaCBwYXJhbWV0 ZXJzIGRlc2NyaXB0aW9ucyBkb24ndA0KPiBwYXJzZSAtLSBmb3IgZXhhbXBsZSB3aXRoIGludHJv c3BlY3Rpb25fc2lnbmVkX3Jlc3BvbnNlX2FsZzogIkpXUw0KPiBbUkZDNzUxNV0gJ2FsZycgYWxn b3JpdGhtIEpXQSBbUkZDNzUxOF0gUkVRVUlSRUQiLCBmdWxseSBleHBhbmRlZCB0aGF0J3MNCj4g IkpTT04gV2ViIFNpZ25hdHVyZSAoSldTKSBbUkZDNzUxNV0gImFsZyIgYWxnb3JpdGhtIEpTT04g V2ViIEFsZ29yaXRobXMNCj4gKEpXQSkgW1JGQzc1MThdIFJFUVVJUkVEIC4uLiIuICBUaGUgc2Ft ZSBpcyB0cnVlIGZvciB0aGUgd3JpdGUtdXBzIGluIFNlY3Rpb24NCj4gNS4NCj4gDQo+IG1vZGZp ZWQgdGV4dA0KPiANCj4gPg0KPiA+ICoqIFNlY3Rpb24gNC4gIEVkaXRvcmlhbC4gIFBlciAiaW50 cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfZW5jIjoNCj4gPiBzL1JFUVVJUkVEIGZvciBl bmNyeXB0aW5nIGludHJvc3BlY3Rpb24gcmVzcG9uc2VzLw0KPiA+IFJFUVVJUkVEIGZvciBhdXRo ZW50aWNhdGVkIGVuY3J5cHRpb24gb2YgaW50cm9zcGVjdGlvbiByZXNwb25zZXMvDQo+ID4NCj4g DQo+IGRvbmUNCg0KVGhhbmtzIGZvciBhbGwgb2YgdGhlIGFib3ZlLg0KDQpSZWdhcmRzLA0KUm9t YW4NCg0KPiBraW5kIHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+IA0KPiANCj4gPiBSZWdhcmRzLA0K PiA+IFJvbWFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= From nobody Mon Jul 22 17:56: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 7005812008F for ; Mon, 22 Jul 2019 17:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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=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 S-2Z0hGovTMa for ; Mon, 22 Jul 2019 17:56:13 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4810120045 for ; Mon, 22 Jul 2019 17:56:13 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0uC8H026055; Mon, 22 Jul 2019 20:56:12 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6N0uC8H026055 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563843372; bh=Hj+qXa1PzQ4RmOZddv3+S7G09Nr740W55Oi6pNwLf6I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=pP0cS/1bBAEIoMMW38h6q8ScTWs5MGR0Vm/gNUcIYB10kk3iKGVyIDJOaQYt8PUU2 ZwidpGuBlIxUllqSeBNAHXdJudHMtsgSiEm17+bRt0IDuzlJmiP813efrXxwVbc182 3mkACBFJ+hd+0Uf4Q7+fY3ZTck3Lme++jFmuHNCQ= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6N0u8XC017987; Mon, 22 Jul 2019 20:56:08 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 20:56:07 -0400 From: Roman Danyliw To: Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03 Thread-Index: AdU8um9EYRsZS/zUTimSMgl/pofXXQD431IAABQoH3AAAKFZMA== Date: Tue, 23 Jul 2019 00:56:07 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Jul 2019 00:56:18 -0000 SGkgVG9yc3RlbiENCg0KU2VwYXJhdGVseSBmcm9tIHRoZSBiZWxvdywgaWRuaXRzIGlzIHRyb3Vi bGVkIGJ5IHRoZSBsYWNrIG9mIGFuIFJGQzIxMTkgc2VjdGlvbiBhbmQgdGhlIHByZXNlbmNlIG9y IGFic2VuY2Ugb2Ygc29tZSByZWZlcmVuY2UgZGVzcGl0ZSBjaXRhdGlvbjoNCg0KPT1bIHNuaXAg XT09DQoNCk1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICA9PSBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayB0aGUgcmVjb21tZW5kZWQgUkZDIDIxMTkg Ym9pbGVycGxhdGUsIGV2ZW4gaWYNCiAgICAgaXQgYXBwZWFycyB0byB1c2UgUkZDIDIxMTkga2V5 d29yZHMuIA0KDQogICAgIChUaGUgZG9jdW1lbnQgZG9lcyBzZWVtIHRvIGhhdmUgdGhlIHJlZmVy ZW5jZSB0byBSRkMgMjExOSB3aGljaCB0aGUNCiAgICAgSUQtQ2hlY2tsaXN0IHJlcXVpcmVzKS4N Cg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6IFByb3Bvc2VkIFN0 YW5kYXJkDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICAoU2VlIFJGQ3MgMzk2NyBhbmQg NDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMNCiAg ICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpDQoNCiAgPT0gTWlzc2luZyBS ZWZlcmVuY2U6ICdSRkM1MzIyJyBpcyBtZW50aW9uZWQgb24gbGluZSA0NzEsIGJ1dCBub3QgZGVm aW5lZA0KDQogID09IE1pc3NpbmcgUmVmZXJlbmNlOiAnUkZDMzk2NicgaXMgbWVudGlvbmVkIG9u IGxpbmUgNTM3LCBidXQgbm90IGRlZmluZWQNCg0KICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JG QzQ2MjcnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDU2MiwgYnV0IG5vdCBkZWZpbmVkDQoNCiAgKiog T2Jzb2xldGUgdW5kZWZpbmVkIHJlZmVyZW5jZTogUkZDIDQ2MjcgKE9ic29sZXRlZCBieSBSRkMg NzE1OSkNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMjExOScgaXMgZGVmaW5lZCBvbiBs aW5lIDYwNiwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhl IHRleHQNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMjI0NicgaXMgZGVmaW5lZCBvbiBs aW5lIDYxMSwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhl IHRleHQNCg0KICA9PSBPdXRkYXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTA2KSBl eGlzdHMgb2YNCiAgICAgZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTA0DQoNCiAgPT0gT3V0ZGF0 ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNpb24gKC0xMykgZXhpc3RzIG9mDQogICAgIGRyYWZ0 LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTExDQoNCiAgKiogT2Jzb2xldGUgbm9ybWF0aXZl IHJlZmVyZW5jZTogUkZDIDIyNDYgKE9ic29sZXRlZCBieSBSRkMgNDM0NikNCj09WyBzbmlwIF09 PQ0KDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9BdXRo IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIERhbnls aXcNCj4gU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDE5IDg6NTEgUE0NCj4gVG86IFRvcnN0ZW4g TG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KPiBDYzogb2F1dGhAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRo LWp3dC1pbnRyb3NwZWN0aW9uLQ0KPiByZXNwb25zZS0wMw0KPiANCj4gSGkgVG9yc3RlbiENCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBUb3JzdGVuIExvZGRl cnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo+ID4gU2VudDogTW9uZGF5 LCBKdWx5IDIyLCAyMDE5IDY6NTkgQU0NCj4gPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQu b3JnPg0KPiA+IENjOiBvYXV0aEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEFEIFJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi0NCj4gPiByZXNw b25zZS0wMw0KPiA+DQo+ID4gSGkgUm9tYW4sDQo+ID4NCj4gPiB0aGFua3MgYSBsb3QgZm9yIHlv dXIgcmV2aWV3IGZlZWRiYWNrLg0KPiA+DQo+ID4gSSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyByZXZp c2lvbiBvZiB0aGUgZHJhZnQgaW5jb3Jwb3JhdGluZyBjaGFuZ2VzDQo+ID4gYmFzZWQgb24geW91 ciBjb21tZW50cy4NCj4gPg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnMNCj4gPiBlLTA0DQo+IA0KPiBUaGFu a3MgZm9yIHRoZSB1cGRhdGUuIEkgaGF2ZSBvbmUgcmVmaW5lbWVudCBiZWxvdyBiYXNlZCBvbiB0 aGUgbmV3DQo+IGxhbmd1YWdlIGFyb3VuZCBUTFMuICBEZXRhaWxzIGFyZSBpbmxpbmUgLi4uDQo+ IA0KPiA+ID4gT24gMTcuIEp1bCAyMDE5LCBhdCAxODoxNywgUm9tYW4gRGFueWxpdyA8cmRkQGNl cnQub3JnPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBIaSENCj4gPiA+DQo+ID4gPiBUaGUgZm9sbG93 aW5nIGlzIG15IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9u LQ0KPiA+IHJlc3BvbnNlLTAzLg0KPiA+ID4NCj4gPiA+ICgxKSBTZWN0aW9uIDQuICBQZXIgaW50 cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnLCBob3cgaXMNCj4gPiA+IGVpdGhlcg0K PiA+IHNpZ25pbmcgb3IgZW5jcnlwdGlvbiBiZWluZyByZXF1ZXN0ZWQ/ICBJcyBpdCBieSBhbHNv IGluY2x1ZGluZyBhbg0KPiA+IGludHJvc3BlY3Rpb25fc2lnbmVkX3Jlc3BvbnNlX2FsZz8gIElm IHRoYXQncyB0aGUgY2FzZSwgaXQgaXMgd29ydGgNCj4gPiBleHBsaWNpdGx5IHNheWluZy4NCj4g Pg0KPiA+IFRoZSByZXNwb25zZSBpcyBhbHdheXMgc2lnbmVkLiBUaGUgcmVzb3VyY2Ugc2VydmVy IG1heSBkZWNpZGUgdG8NCj4gPiBhZGRpdGlvbmFsbHkgdHVybiBvbiBlbmNyeXB0aW9uLg0KPiA+ DQo+ID4gU2VjdGlvbiAzIHN0YXRlcyDigJxEZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljIHJlc291 cmNlIHNlcnZlciBwb2xpY3kgdGhlDQo+ID4gSldUIGlzIGVpdGhlciBzaWduZWQsIG9yIHNpZ25l ZCBhbmQgZW5jcnlwdGVkLiDigJwNCj4gDQo+IFdpdGggdGhlIG5ldyBsYW5ndWFnZSB5b3UgYWRk ZWQgZm9yIGl0ZW0gIzIsIEkgbm93IHVuZGVyc3RhbmQuICBUaGFua3MgZm9yDQo+IGNsZWFyaW5n IGl0IHVwLg0KPiANCj4gPiA+ICgyKSBTZWN0aW9uIDQuICBQZXIgaW50cm9zcGVjdGlvbl9lbmNy eXB0ZWRfcmVzcG9uc2VfZW5jLCBJJ20gaGF2aW5nDQo+ID4gdHJvdWJsZSBkZWNvbmZsaWN0aW5n IHRoZXNlIHR3byBzZW50ZW5jZXM6DQo+ID4gPg0KPiA+ID4gWzFdIElmICJpbnRyb3NwZWN0aW9u X2VuY3J5cHRlZF9yZXNwb25zZV9hbGciIGlzIHNwZWNpZmllZCwgdGhlDQo+ID4gPiBkZWZhdWx0 IGZvcg0KPiA+IHRoaXMgdmFsdWUgaXMgQTEyOENCQy1IUzI1Ni4NCj4gPiA+DQo+ID4gPiBbMl0g V2hlbiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfZW5jIiBpcyBpbmNsdWRlZCwN Cj4gPiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnIiBNVVNUIGFsc28gYmUg cHJvdmlkZWQNCj4gPiA+DQo+ID4gPiBTZW50ZW5jZSBbMl0gZXhwbGljaXRseSBzdGF0ZXMgdGhh dA0KPiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnIg0KPiA+IGlzIHJlcXVp cmVkLiAgSG93ZXZlciwgdGhlIGZpcnN0IHNlbnRlbmNlIHNlZW1zIG1vcmUgdGVudGF0aXZlIGJ5 DQo+ID4gc2F5aW5nIHRoYXQgImlmIGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2Vu YyIgaXMgcHJlc2VudC4NCj4gPg0KPiA+IGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNl X2VuYyBpcyBvcHRpb25hbCBidXQgbXVzdCBub3QgYmUNCj4gPiBzcGVjaWZpZWQgd2l0aG91dCBp bnRyb3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGcNCj4gPg0KPiA+IEkgY2hhbmdlZCB0 aGUgdGV4dCB0byBiZXR0ZXIgZ2V0IHRoaXMgYWNyb3NzOg0KPiA+DQo+ID4gaW50cm9zcGVjdGlv bl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnDQo+ID4gT1BUSU9OQUwuIEpXRSBhbGdvcml0aG0gKGFs ZyB2YWx1ZSkgYXMgZGVmaW5lZCBpbiBKV0EgZm9yIGVuY3J5cHRpbmcNCj4gPiBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlcy4gSWYgdGhpcyBpcyBzcGVjaWZpZWQsIHRoZSByZXNwb25zZSB3aWxsIGJl DQo+ID4gZW5jcnlwdGVkIHVzaW5nIEpXRSBhbmQgdGhlIGNvbmZpZ3VyZWQgYWxnb3JpdGhtLiBU aGUgZGVmYXVsdCwgaWYNCj4gPiBvbWl0dGVkLCBpcyB0aGF0IG5vIGVuY3J5cHRpb24gaXMgcGVy Zm9ybWVkLiBJZiBib3RoIHNpZ25pbmcgYW5kDQo+ID4gZW5jcnlwdGlvbiBhcmUgcmVxdWVzdGVk LCB0aGUgcmVzcG9uc2Ugd2lsbCBiZSBzaWduZWQgdGhlbiBlbmNyeXB0ZWQsDQo+ID4gd2l0aCB0 aGUgcmVzdWx0IGJlaW5nIGEgTmVzdGVkIEpXVCwgYXMgZGVmaW5lZCBpbiBKV1QuDQo+ID4NCj4g PiBpbnRyb3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9lbmMNCj4gPiBPUFRJT05BTC4gSldF IGFsZ29yaXRobSAoZW5jIHZhbHVlKSBhcyBkZWZpbmVkIGluIEpXQSBmb3INCj4gPiBhdXRoZW50 aWNhdGVkIGVuY3J5cHRpb24gb2YgaW50cm9zcGVjdGlvbiByZXNwb25zZXMuIFRoZSBkZWZhdWx0 LCBpZg0KPiA+IG9taXR0ZWQsIGlzIEExMjhDQkMtIEhTMjU2LiBOb3RlOiBUaGlzIHBhcmFtZXRl ciBNVVNUIE5PVCBiZSBzcGVjaWZpZWQNCj4gPiB3aXRob3V0IHNldHRpbmcgaW50cm9zcGVjdGlv bl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnLg0KPiANCj4gVGhhbmtzIGZvciB0aGlzIG5ldyB0ZXh0 LiAgSXQgaXMgY2xlYXJlci4NCj4gDQo+IA0KPiA+ID4NCj4gPiA+ICgzKSBJIHdhbnQgdG8gdGFs ayB0aHJvdWdoIHRoZSBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbg0KPiA+ID4g YmVpbmcNCj4gPiBzcGVjaWZpZWQgYXMgbmV3IGludHJvc3BlY3Rpb24gZmllbGRzIHBlciBTZWN0 aW9uIDguMyAoZS5nLiwgbmFtZSwNCj4gPiBiaXJ0aGRheSkgYmVpbmcgZXhwb3NlZC4gIEkgd2Fz IGxvb2tpbmcgdG8gZW5zdXJlIHRoYXQgaXQgd291bGQgYWx3YXlzDQo+ID4gYmUgZW5jcnlwdGVk IGluIHRyYW5zaXQgKGFuZCB0aGF0IG9ubHkgYXV0aG9yaXplZCBjbGllbnRzIGNvdWxkIGdldA0K PiA+IGl0KS4gIEkgcmVhZCB0aGF0IGluIFNlY3Rpb24gMywgIltkXWVwZW5kaW5nIG9uIHRoZSBz cGVjaWZpYyByZXNvdXJjZQ0KPiA+IHNlcnZlciBwb2xpY3kgdGhlIEpXVCBpcyBlaXRoZXIgc2ln bmVkLCBvciBzaWduZWQgYW5kIGVuY3J5cHRlZCIgYW5kDQo+ID4gdGhhdCBwZXIgU2VjdGlvbiA0 IHRoYXQgIlt0XWhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRldGVybWluZXMgd2hhdA0KPiA+IGFs Z29yaXRobSB0byBlbXBsb3kgdG8gc2VjdXJlIHRoZSBKV1QgZm9yIGEgcGFydGljdWxhciBpbnRy b3NwZWN0aW9uDQo+ID4gcmVzcG9uc2UuIiAgU2VjdGlvbiA2LjIgZXhwbGljaXRseSBub3RlcyB0 aGUgdGhyZWF0IG9mIHRva2VuIGRhdGENCj4gPiBsZWFrYWdlIChhIG1vcmUgZ2VuZXJhbCBjYXNl IG9mIG15IGNvbmNlcm4gc28gdGhhbmtzIGZvciB0aGF0IHRleHQpLg0KPiA+IFtSRkM3NjYyXSwg U2VjdGlvbiA0IG5vdGVzIG9ubHkgdGhhdCAidGhlIHNlcnZlciBNVVNUIHN1cHBvcnQNCj4gPiBU cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgMS4yIiwgYnV0ICJzdXBwb3J0IiBpcyBkaWZm ZXJlbnQgdGhhbg0KPiA+ICJ0aGUgc2VydmVyIE1VU1QgX3VzZV8gVExTIi4gVGhlcmVmb3JlLCBp dCBzZWVtcyBsaWtlIHRoZXJlIGNvdWxkIGJlIGENCj4gPiBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIg Y291bGQgcmV0dXJuIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgaW4gdGhlDQo+ID4gY2xlYXIg KGUuZy4sIG5vIFRMUywgaW50cm9zcGVjdGlvbl9zaWcNCj4gPiA+IG5lZF9yZXNwb25zZV9hbGcp LiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPiA+DQo+ID4gPiBNeSBiaWFzIGlzIHRvIHNh eSBzb21ldGhpbmcgb24gdGhlIG9yZGVyIG9mICJUTFMgTVVTVCBiZSB1c2Vk4oCdLg0KPiA+DQo+ ID4gU2VjdGlvbiA2LjIuIG5vdyBzdGFydHMgd2l0aCDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVCB1c2UNCj4gPiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgMS4yIChvciBo aWdoZXIpIGluIG9yZGVyIHRvIHByZXZlbnQgdG9rZW4gZGF0YQ0KPiBsZWFrYWdlLiINCj4gDQo+ IFdvcmtzIGZvciBtZSB0byB3YXMgdXNlIFRMUy4gIEknZCByZWNvbW1lbmQgYSBzdGF0ZW1lbnQg dGhhdCBwcm92aWRlcw0KPiBtb3JlIGd1aWRhbmNlICJUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCB1c2UgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5DQo+IChUTFMpIDEuMiAob3IgaGlnaGVy KSBwZXIgUkZDNzUyNSBpbiBvcmRlciB0byBwcmV2ZW50IHRva2VuIGRhdGEgbGVha2FnZS4iDQo+ IA0KPiA+ID4gKDQpIEkgYWxzbyB3YW50IHRvIHRhbGsgdGhyb3VnaCBhbiB1bnNjcnVwdWxvdXMg cHJvdGVjdGVkIHJlc291cmNlDQo+ID4gPiB0cnlpbmcgdG8NCj4gPiBoYXJ2ZXN0IGludHJvc3Bl Y3Rpb24gbWV0YS1kYXRhLiAgSSB3YXMgbG9va2luZyBmb3IgZ3VpZGFuY2UgcmVsYXRlZA0KPiA+ IHRvIHRoZSBhdXRob3JpemF0aW9uIG9mIHRoZSBpbnRyb3NwZWN0aW9uIHRyYW5zYWN0aW9ucy4g IEkgZm91bmQ6DQo+ID4gPg0KPiA+ID4gU2VjdGlvbiAyLjIgb2YgW1JGQzc2NjJdIHNheXMgaW1w b3J0YW50IHRoaW5ncyBsaWtlICJGb3IgaW5zdGFuY2UsDQo+ID4gPiBhbg0KPiA+IGF1dGhvcml6 YXRpb24gc2VydmVyIE1BWSBsaW1pdCB3aGljaCBzY29wZXMgZnJvbSBhIGdpdmVuIHRva2VuIGFy ZQ0KPiA+IHJldHVybmVkIGZvciBlYWNoIHByb3RlY3RlZCByZXNvdXJjZSB0byBwcmV2ZW50IGEg cHJvdGVjdGVkIHJlc291cmNlDQo+ID4gZnJvbSBsZWFybmluZyBtb3JlIGFib3V0IHRoZSBsYXJn ZXIgbmV0d29yayB0aGFuIGlzIG5lY2Vzc2FyeSBmb3IgaXRzDQo+IG9wZXJhdGlvbi4iDQo+ID4g Pg0KPiA+ID4gU2VjdGlvbiA0IG9mIFtSRkM3NjYyXSBzYXlzICJJZiBsZWZ0IHVucHJvdGVjdGVk IGFuZCB1bi10aHJvdHRsZWQsDQo+ID4gPiB0aGUNCj4gPiBpbnRyb3NwZWN0aW9uIGVuZHBvaW50 IGNvdWxkIHByZXNlbnQgYSBtZWFucyBmb3IgYW4gYXR0YWNrZXIgdG8gcG9sbCBhDQo+ID4gc2Vy aWVzIG9mIHBvc3NpYmxlIHRva2VuIHZhbHVlcywgZmlzaGluZyBmb3IgYSB2YWxpZCB0b2tlbi4g IFRvDQo+ID4gcHJldmVudCB0aGlzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1 aXJlIGF1dGhlbnRpY2F0aW9uIG9mDQo+ID4gcHJvdGVjdGVkIHJlc291cmNlcyB0aGF0IG5lZWQg dG8gYWNjZXNzIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGFuZA0KPiA+IFNIT1VMRCByZXF1 aXJlIHByb3RlY3RlZCByZXNvdXJjZXMgdG8gYmUgc3BlY2lmaWNhbGx5IGF1dGhvcml6ZWQgdG8N Cj4gPiBjYWxsIHRoZSAgaW50cm9zcGVjdGlvbiBlbmRwb2ludC4iDQo+ID4gPg0KPiA+ID4gU2Vj dGlvbiA2LjIgb2YgdGhpcyBkcmFmdCBwcm92aWRlcyBndWlkYW5jZSBvbiBkZWZlbmRpbmcgYWdh aW5zdA0KPiA+IHVuYXV0aGVudGljYXRlZCBjbGllbnRzLg0KPiA+ID4NCj4gPiA+IEhvdyBkb2Vz IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXN0cmljdCBhIHByb3RlY3RlZCByZXNvdXJjZSB0 aGF0DQo+ID4gPiBfY2FuXw0KPiA+IGF1dGhlbnRpY2F0ZSB0byBpdCBmcm9tIGdldHRpbmcgbWV0 YS1kYXRhIGlzIHNob3VsZG4ndCBoYXZlIGFjY2VzcyB0bz8NCj4gPiBTb21ldGhpbmcgb24gdGhl IG9yZGVyIG9mICJ0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgPHVzZXMgdGhlDQo+ID4gZm9sbG93 aW5nDQo+ID4gZGF0YT4gdG8gZGV0ZXJtaW5lIHdoYXQgYSBnaXZlbiBwcm90ZWN0ZWQgcmVzb3Vy Y2UgaXMgYWxsb3dlZCB0byBzZWXigJ0uDQo+ID4NCj4gPiBJIGFkZGVkIFNlY3Rpb24gNi4zLCB3 aGljaCBzdGF0ZXMg4oCcVGhlIGF1dGhvcmlzYXRpb24gc2VydmVyIGRldGVybWluZXMNCj4gPiB0 aGUgdG9rZW4gZGF0YSBhIHJlc291cmNlIHNlcnZlciBpcyBhbGxvd2VkIHRvIHNlZSBiYXNlZCBv biB0aGUNCj4gPiByZXNvdXJjZSBzZXJ2ZXLigJlzIGNsaWVudF9pZCBhbmQgc3VpdGFibGUgdG9r ZW4gZGF0YSwgZS5nLiB0aGUgc2NvcGUgdmFsdWUuIg0KPiANCj4gR3JlYXQuIFRoYW5rcyBmb3Ig dGhlIGNsYXJpdHkuDQo+IA0KPiA+ID4NCj4gPiA+ICg1KSBFZGl0b3JpYWwgTml0cw0KPiA+ID4N Cj4gPiA+ICoqIFNlY3Rpb24gMy4gIFBlciAiVGhpcyBKV1QgTUFZIGZ1cnRoZXJtb3JlIGNvbnRh aW4gYWxsIG90aGVyDQo+ID4gPiBjbGFpbXMNCj4gPiBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjIu IG9mIFtSRkM3NjYyXSBhbmQgYmV5b25kIChlLmcuIGFzIGRlZmluZWQgaW4NCj4gPiBbT3BlbklE LkNvcmVdKSIsIHdvdWxkIGl0IGJlIG1vcmUgdGltZWxlc3MgdG8gc2F5IHRoZSBmaWVsZHMgc3Bl Y2lmaWVkDQo+ID4gaW4gIk9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24gUmVzcG9uc2UiIHJlZ2lz dHJ5Pw0KPiA+ID4NCj4gPg0KPiA+IFRoaXMgdGV4dCBwcmUtZGF0ZWQgdGhlIGFkZGl0aW9uIG9m IHRoZSBJQU5BIHJlZ2lzdHJ5IHNlY3Rpb24uIFRoYW5rcw0KPiA+IGZvciBzcG90dGluZyB0aGUg aW5jb25zaXN0ZW5jeS4NCj4gPg0KPiA+IEkgbW9kaWZpZWQgdGhlIHRleHQgYXMgeW91IHN1Z2dl c3RlZC4NCj4gPg0KPiA+ID4gKiogU2VjdGlvbiA0LiAgVGhlIGZpcnN0IHNlbnRlbmNlIG9mIGVh Y2ggcGFyYW1ldGVycyBkZXNjcmlwdGlvbnMNCj4gPiA+IGRvbid0DQo+ID4gcGFyc2UgLS0gZm9y IGV4YW1wbGUgd2l0aCBpbnRyb3NwZWN0aW9uX3NpZ25lZF9yZXNwb25zZV9hbGc6ICJKV1MNCj4g PiBbUkZDNzUxNV0gJ2FsZycgYWxnb3JpdGhtIEpXQSBbUkZDNzUxOF0gUkVRVUlSRUQiLCBmdWxs eSBleHBhbmRlZA0KPiA+IHRoYXQncyAiSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIFtSRkM3NTE1 XSAiYWxnIiBhbGdvcml0aG0gSlNPTiBXZWINCj4gPiBBbGdvcml0aG1zDQo+ID4gKEpXQSkgW1JG Qzc1MThdIFJFUVVJUkVEIC4uLiIuICBUaGUgc2FtZSBpcyB0cnVlIGZvciB0aGUgd3JpdGUtdXBz IGluDQo+ID4gU2VjdGlvbiA1Lg0KPiA+DQo+ID4gbW9kZmllZCB0ZXh0DQo+ID4NCj4gPiA+DQo+ ID4gPiAqKiBTZWN0aW9uIDQuICBFZGl0b3JpYWwuICBQZXIgImludHJvc3BlY3Rpb25fZW5jcnlw dGVkX3Jlc3BvbnNlX2VuYyI6DQo+ID4gPiBzL1JFUVVJUkVEIGZvciBlbmNyeXB0aW5nIGludHJv c3BlY3Rpb24gcmVzcG9uc2VzLyBSRVFVSVJFRCBmb3INCj4gPiA+IGF1dGhlbnRpY2F0ZWQgZW5j cnlwdGlvbiBvZiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlcy8NCj4gPiA+DQo+ID4NCj4gPiBkb25l DQo+IA0KPiBUaGFua3MgZm9yIGFsbCBvZiB0aGUgYWJvdmUuDQo+IA0KPiBSZWdhcmRzLA0KPiBS b21hbg0KPiANCj4gPiBraW5kIHJlZ2FyZHMsDQo+ID4gVG9yc3Rlbi4NCj4gPg0KPiA+DQo+ID4g PiBSZWdhcmRzLA0KPiA+ID4gUm9tYW4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From nobody Mon Jul 22 21:14: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 6D0A912006B for ; Mon, 22 Jul 2019 21:14:49 -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 pr3_kqh701GU for ; Mon, 22 Jul 2019 21:14:47 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0: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 64D91120018 for ; Mon, 22 Jul 2019 21:14:47 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id c73so18413961pfb.13 for ; Mon, 22 Jul 2019 21:14:47 -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=8aXGdgqbmGuBTyVLdR8gtJ3cr+8Qs+CquUil3BByvuw=; b=jgsz6wHqTN914molscY97BxhZEvkg5z8fqYIOBZ+nXh0gMnlPBXLJ5Ev+U89IBhLbM A2CUxKJeBobIkC14Ma0MWO3tIOT4cF4M6kSWj/ZdhTomgGVRR9b0mYGTfnj5ztgcTvNk FUxW0OwuauA5xuWuFwSy36qeb7otuD0gduuatMxzfUvtyZo5sVK+RavGD63eE37SC+f8 pMS08OWbXPIHY1qETBC49BaWpcNVTaO3X80oiU2Dgh5xQOAIyE7QfIdUY5xChC1exzov N9SpYORAVtH30Eiyt91INiCfZS/IJWApcqFHMyj3w5iDd3t0OWLXEuBoz3N0DdueV+4h zKwQ== 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=8aXGdgqbmGuBTyVLdR8gtJ3cr+8Qs+CquUil3BByvuw=; b=lGv1nE1wq3E4Lzt4m4Tko96Q6pbgf9t5UV2GvbYXP3sWc/XUzljDBSwAIPZGre9Sf8 mAC8ajvn9TwdE3TWxsIwhf+OuzcaHFIQQzRWeukVbTnvvaS2JL67QWj0IzBsNVYpYDnB gFKpoCLzy7tjBgwg7Wq2w0tY6+4Xky5YSdLZRzbwPFguVI/+v4M6meHEZ5H9FTXTgQe/ tv+ixWR89PIs0Rtg1No9Dlqt2S1+/upZk2EAgr9NsiIFvUDEDcM/Q/Ix5q6g9sSOHlrW L5fsN1UxZ+sbsJzWpIzeWf0DG2fQVQsg5owA5zSe8a37dAxdUwSzsvIFLzSkLqC5QHGZ Ixhw== X-Gm-Message-State: APjAAAW08PrKeTN7u9dChi6E2j9u65Zin5TGano84xetEWhuyXEGVM86 I5Vbo74iguy3OW0M1AR8aIVDgZDxWFcqpgjFHjs= X-Google-Smtp-Source: APXvYqwSEzNVRSZkvgGKJKImXF04vO4EhD2sGTS+AYrJeruCQPbH5bVqr++glYcOaWpzBVG0kBgZaX83yMN3LJ6rGcQ= X-Received: by 2002:a63:1d4:: with SMTP id 203mr57243521pgb.441.1563855286660; Mon, 22 Jul 2019 21:14:46 -0700 (PDT) MIME-Version: 1.0 References: <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com> In-Reply-To: From: Leo Tohill Date: Tue, 23 Jul 2019 00:14:35 -0400 Message-ID: To: Hans Zandbelt Cc: Brock Allen , OAuth WG Content-Type: multipart/alternative; boundary="000000000000d7730d058e516e3c" Archived-At: Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for 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: Tue, 23 Jul 2019 04:14:49 -0000 --000000000000d7730d058e516e3c Content-Type: text/plain; charset="UTF-8" I didn't see the earlier discussion (do you have a date or title?) so apologies if I'm bringing up something that's been resolved. But I still think that it's really confusing to say "it may be a better decision to avoid using OAuth entirely" if the application will still be using Oauth/OIDC (which will, of course, involve a browser flow). orsten@lodderstedt.net has raised the same (or similar?) objection in a parallel thread. I suggest we continue the conversation there. - Leo On Mon, Jul 22, 2019 at 1:09 PM Hans Zandbelt wrote: > +1, as discussed before > > Hans. > > On Mon, Jul 22, 2019, 18:25 Brock Allen wrote: > >> I think the implication is that the server-side would use something like >> OIDC to the token server in order to establish the identity of the user. >> The difference is that this would be driven from the server-side piece of >> the application, as any other normal server-side client would. The result >> would then simply be a cookie-based authentication session in the client, >> and any JS code would leverage the http only, same-site cookie for Ajax >> calls. >> >> -Brock >> >> On 7/21/2019 10:22:38 PM, Leo Tohill wrote: >> The advice for the architectural pattern "JavaScript served from a common >> domain as the resource server" reads: >> >> "For simple system architectures, such as when the JavaScript application >> is served >> from a domain that can share cookies with the domain of the API (resource >> server), it >> may be a better decision to avoid using OAuth entirely, and instead use >> session >> authentication to communicate directly with the API." >> >> I can agree that session authentication could be best here, but how was >> the user authenticated in order to create the trusted session? Wouldn't >> that/shouldn't that still use an oauth flow to collect credentials? >> >> We need to be clear on the distinction between browser based apps that >> hold the token(s) in the browser space, vs. those that don't. I agree that >> with this >> "common domain" architecture, the tokens should not be held in the >> browser, but it doesn't follow that oauth should not be used at all. >> >> Leo >> >> >> _______________________________________________ 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 >> > --000000000000d7730d058e516e3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't see the earlier discussion (do you have a dat= e or title?) so apologies if I'm bringing up something that's been = resolved.=C2=A0 But I still think that it's really confusing to say &qu= ot;it
may be a better decision to avoid using OAuth entirely"= =C2=A0 if the application will still be using Oauth/OIDC (which will, of co= urse, involve a browser flow).

orsten@lodderstedt.net=C2=A0 has rai= sed the same (or similar?) objection in a parallel thread.=C2=A0 I suggest = we continue the conversation there.

- Leo
=


On Mon, Jul 22, 2019 at 1:09 PM Hans Zandbelt <hans.zandbelt@z= martzone.eu> wrote:
+1, as discussed before

<= /div>
Hans.

On Mon, Jul 22, 2019, 18:25 Brock Allen &= lt;brockallen@gma= il.com> wrote:
=20 =20 =20 =20 =20 I think the implication is that the= server-side would use something like OIDC to the token server in order to = establish the identity of the user. The difference is that this would be dr= iven from the server-side piece of the application, as any other normal ser= ver-side client would. The result would then simply be a cookie-based authe= ntication session in the client, and any JS code would leverage the http on= ly, same-site cookie for Ajax calls.=C2=A0

-Brock

On 7/21/2019 10:22:38 PM, Leo Tohill <leotohill@gmail.com> wrot= e:

The advice for the architectural pattern "JavaScript served fro= m a common domain as the resource server"=C2=A0 reads:
<= br>
"For simple system architectures, such as when the JavaS= cript application is served
from a domain that can share cookies with th= e domain of the API (resource server), it
may be a better decision to av= oid using OAuth entirely, and instead use session
authentication to comm= unicate directly with the API."

I can agree t= hat session authentication could be best here, but how was the user authent= icated in order to create the trusted session?=C2=A0 Wouldn't that/shou= ldn't that still use an oauth flow to collect credentials?
We need to be clear on the distinction between browser based a= pps that hold the token(s) in the browser space, vs. those that don't.= =C2=A0 I agree that with this
"common domain" architecture, t= he tokens should not be held in the browser, but it doesn't follow that= oauth should not be used at all.

Leo


_______________________________________________ OAuth mailing list OAut= h@ietf.org https://www.ietf.org/mailman/listinfo/oauth
=20
_______________________= ________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d7730d058e516e3c-- From nobody Mon Jul 22 21:25: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 EAA4112003E for ; Mon, 22 Jul 2019 21:25:04 -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 9BMV-a3Ys0Gn for ; Mon, 22 Jul 2019 21:25:02 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0: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 6ACFD120018 for ; Mon, 22 Jul 2019 21:25:02 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id c73so18425904pfb.13 for ; Mon, 22 Jul 2019 21:25:02 -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=XRobZwR4x6H53kWSHrHLMYdTuPHopzWo8mEZv3ArGhc=; b=E9K+mK4K9KPoQbNITKbq/+ccqgRY/4GgVMZAkd/yokgf7QkSt13lvQdRY3TklYYIGd WsoSQSbBJTjfuxG/3xxUlrlZ9LMDGocUoDUmbyvXwhLlRBLi1eLL9ELlKrxf+SypvTRa 7IrHk/n1m/NPe9Y6Ty6nTguTHJl51FNtBiryOeK1I7XRffdcIgVNZRvggD7v/ZYQWWq9 ib8NbEWnhCaLMl2WPq9uPeUDuxWwWnxnnqSPq/cSzUErkEhaGyB5p92I84KlIoaO+ExS jTk0fpaB817yBOts6IdAHPdq7h/FmeT+JIgXIkINY1zGFA1YIuOXwPntXh5O5cFsRn6q SVyA== 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=XRobZwR4x6H53kWSHrHLMYdTuPHopzWo8mEZv3ArGhc=; b=D11G6GIxdHSGK979+cN6cx9E4FyO5xVnrGX6xNAFbMGLu7vum6AYpvtMORdV84Rf/V NqKWU1Uhc9cpnfm5tc4OB4UIbfTcfs7c4+jnBhj9OsFdhbpPwkBaPwp1z3Ov0aKiBTy8 h6RlfCI9EjP/dorwIhg9fi2qd55wNlo4Zdug7Yjq/Rtdf5yr8RdDktbAr/DQvr4Q8CZo aj6kSOepjbziv4VtWHQSuv2qHgIzTeFCkkxyLADyK2pfXftVzrpw+PcdCZCijyatxrO0 9UecyY+mGKZ69KSpBAMs0LE0ebOqtF2SKFU1pHO9W25cuhM5+W7xhnVT9SxDj0gn82eV Spqw== X-Gm-Message-State: APjAAAU9q+0fTV9JOE5HhrM9z13jM2+AwY9if2pR5WsDagTI/2NbHHVx TZq1z1HimwEOFfcWw8o4ry/LANYdR+f3/yeYFv9SQw0r X-Google-Smtp-Source: APXvYqxprlIlVkZMGkE/KsgusIhnhkEeR+z3S7IuPZ8WQ1Nx804mIYCCncyxwxv+eKIsKaCcxPBrPaMnNJsvVXCzgsE= X-Received: by 2002:a17:90a:338b:: with SMTP id n11mr79343322pjb.21.1563855901699; Mon, 22 Jul 2019 21:25:01 -0700 (PDT) MIME-Version: 1.0 References: <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net> In-Reply-To: <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net> From: Leo Tohill Date: Tue, 23 Jul 2019 00:24:50 -0400 Message-ID: To: Torsten Lodderstedt Cc: Aaron Parecki , OAuth WG Content-Type: multipart/alternative; boundary="000000000000803595058e519336" Archived-At: Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 04:25:05 -0000 --000000000000803595058e519336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that there's a problem regarding the scope of this BCP . Or at least, I'm confused. Is this BCP supposed to be all about the architecture where the browser holds the token(s)? If so, then a) let's just put that out front and center: that's the context of this BCP. That's what's meant by "browser-based application." b) It really IS limited to public clients. c) 6.2 simply doesn't belong: it is describing a different architecture. If, on the other hand, 6.2 is to be retained, it needs to be rephrased from saying the OAuth is not the right solution. Oauth can/will still be used, but the token(s) will be used server side, not client/browser side. - Leo On Mon, Jul 22, 2019 at 9:31 AM Torsten Lodderstedt wrote: > Hi Aaron, > > thanks for your continued work on the topic. > > Here are some general remarks on the current revision: > > 1) This BCP should not be limited to public clients. Your BCP itself > already describes an architecture where the OAuth client is a backend tha= t > may be a confidential client (see section 6.2 for an example). The text o= f > the BCP generally seems to be inconsistent regarding oauth client types. > > I suggest to remove the second part of the first paragraph of the abstrac= t > (=E2=80=9Cand should not be issued a client secret when registered.") and= other > statements limiting the BCP to public clients. > > 2) Regarding architectures: I think this BCP should focus on > recommendations for securely implementing OAuth in the different potentia= l > architecture. I don=E2=80=99t think we should get into the business of re= commending > and assessing other solutions (e.g. section 6.1.). Just to give you an > example: Section 6.1. states > > "OAuth and OpenID Connect provide very little benefit in this deployment > scenario, so it is recommended to reconsider whether you need OAuth or > OpenID Connect at all in this case.=E2=80=9D > > Really? What experiences is this statement based on? In my experience, > sharing the same domain =3D=3D host name tells you nothing about the over= all > architecture of a certain deployment. There may be several reasons why > OAuth could be good choice in such a scenario, e.g. security consideratio= ns > (since your common domain is just a proxy server encapsulating a whole > universe of systems) or even modularity as an architecture principle. > > I suggest to remove section 6.1. and to rephrase the second paragraph of > the abstract. > > 3) The naming in section 6 focus on the ways the JS could be served. I > personally think the more important aspect is the architecture of the > overall application. > > I suggest the following changes: > - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend > - 6.3. Apps Served from a Static Web Server -> SPA without backend > > Note: even an SPA with a backend could use a static web server to serve > the JS code. > > 4) I don=E2=80=99t understand why your BCP distinguishes 1st and 3rd part= y apps. > Neither the Native apps BCP nor security BCP do so and need to. > > 5) Section 9.8 seems to duplicate portions of the Security BCP (while not > giving the complete threat model) - what is the benefit of duplicating th= is > text? > > 6) I think the BCP would benefit from a refactoring. One idea would be to > first state the problem with implicit and give general recommendations > (PKCE and so on). The latter part could get into details of access and > refresh token protection in the context of different SPA architectures > (mTLS, CORS for CSRF prevention, =E2=80=A6). > > kind regards, > Torsten. > > > On 9. Jul 2019, at 01:03, Aaron Parecki wrote: > > > > Hi all, > > > > I've just uploaded a new version of oauth-browser-based-apps in > preparation for the meeting in Montreal. > > > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 > > > > This draft incorporates much of the feedback I've received over the las= t > couple months, as well as what we discussed at the last meeting in Prague= . > > > > The primary change is a significant rewrite and addition of Section 6 t= o > highlight the two common deployment patterns, a SPA with and without a > dynamic backend. > > > > Please have a look and let me know what you think. I have a slot in the > agenda for Montreal to present on this as well. > > > > Thanks! > > > > ---- > > Aaron Parecki > > aaronparecki.com > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000803595058e519336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree that there's a problem reg= arding the scope of this BCP . =C2=A0 Or at least, I'm confused.=C2=A0 =

Is this BCP supposed to be all about the arch= itecture where the browser holds the token(s)? =C2=A0
If so,= then
=C2=A0
a) let's just put that out front and center: = that's the context of this BCP. That's what's meant by "br= owser-based application."
b) It really IS limited to public = clients.
c) 6.2 simply doesn't belong: it is describing = a different architecture.

If, on the other ha= nd, 6.2 is to be retained, it needs to be rephrased from saying the OAuth i= s not the right solution. Oauth can/will still be used, but the token(s) wi= ll be used server side, not client/browser side.

<= br>
- Leo




On Mon, Jul = 22, 2019 at 9:31 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Aaron,

thanks for your continued work on the topic.

Here are some general remarks on the current revision:

1) This BCP should not be limited to public clients. Your BCP itself alread= y describes an architecture where the OAuth client is a backend that may be= a confidential client (see section 6.2 for an example). The text of the BC= P generally seems to be inconsistent regarding oauth client types.

I suggest to remove the second part of the first paragraph of the abstract = (=E2=80=9Cand should not be issued a client secret when registered.") = and other statements limiting the BCP to public clients.

2) Regarding architectures: I think this BCP should focus on recommendation= s for securely implementing OAuth in the different potential architecture. = I don=E2=80=99t think we should get into the business of recommending and a= ssessing other solutions (e.g. section 6.1.). Just to give you an example: = Section 6.1. states

"OAuth and OpenID Connect provide very little benefit in this deployme= nt scenario, so it is recommended to reconsider whether you need OAuth or O= penID Connect at all in this case.=E2=80=9D

Really? What experiences is this statement based on? In my experience, shar= ing the same domain =3D=3D host name tells you nothing about the overall ar= chitecture of a certain deployment. There may be several reasons why OAuth = could be good choice in such a scenario, e.g. security considerations (sinc= e your common domain is just a proxy server encapsulating a whole universe = of systems) or even modularity as an architecture principle.

I suggest to remove section 6.1. and to rephrase the second paragraph of th= e abstract.

3) The naming in section 6 focus on the ways the JS could be served. I pers= onally think the more important aspect is the architecture of the overall a= pplication.

I suggest the following changes:
- 6.2. Apps Served from a Dynamic Application Server -> SPA with backend=
- 6.3. Apps Served from a Static Web Server -> SPA without backend

Note: even an SPA with a backend could use a static web server to serve the= JS code.

4) I don=E2=80=99t understand why your BCP distinguishes 1st and 3rd party = apps. Neither the Native apps BCP nor security BCP do so and need to.

5) Section 9.8 seems to duplicate portions of the Security BCP (while not g= iving the complete threat model) - what is the benefit of duplicating this = text?

6) I think the BCP would benefit from a refactoring. One idea would be to f= irst state the problem with implicit and give general recommendations (PKCE= and so on). The latter part could get into details of access and refresh t= oken protection in the context of different SPA architectures (mTLS, CORS f= or CSRF prevention, =E2=80=A6).

kind regards,
Torsten.

> On 9. Jul 2019, at 01:03, Aaron Parecki <aaron@parecki.com> wrote:
>
> Hi all,
>
> I've just uploaded a new version of oauth-browser-based-apps in pr= eparation for the meeting in Montreal.
>
> https://tools.ietf.org/html/d= raft-ietf-oauth-browser-based-apps-02
>
> This draft incorporates much of the feedback I've received over th= e last couple months, as well as what we discussed at the last meeting in P= rague.
>
> The primary change is a significant rewrite and addition of Section 6 = to highlight the two common deployment patterns, a SPA with and without a d= ynamic backend.
>
> Please have a look and let me know what you think. I have a slot in th= e agenda for Montreal to present on this as well.
>
> Thanks!
>
> ----
> Aaron Parecki
> aaronparecki.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000803595058e519336-- From nobody Mon Jul 22 22:03: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 48F4C12004F for ; Mon, 22 Jul 2019 22:03:07 -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 E3VdrVdIdYgm for ; Mon, 22 Jul 2019 22:03:03 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (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 29056120033 for ; Mon, 22 Jul 2019 22:03:03 -0700 (PDT) Received: from [84.158.229.114] (helo=[192.168.71.102]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpmx1-0007jH-Pk; Tue, 23 Jul 2019 07:02:59 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-97277A7E-D7CC-4E45-9E5F-DA0B075714AD; 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: Tue, 23 Jul 2019 07:02:58 +0200 Cc: OAuth WG Content-Transfer-Encoding: 7bit Message-Id: References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net> To: Vittorio Bertocci X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 05:03:07 -0000 --Apple-Mail-97277A7E-D7CC-4E45-9E5F-DA0B075714AD Content-Type: multipart/alternative; boundary=Apple-Mail-1A559231-DF04-4111-A133-B993064D0EA2 Content-Transfer-Encoding: 7bit --Apple-Mail-1A559231-DF04-4111-A133-B993064D0EA2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable thanks=20 > Am 22.07.2019 um 21:32 schrieb Vittorio Bertocci : >=20 > > Additionally stating that unique audiences shall be used for different s= ervices should be ok. > Fair! I'll add language to that effect in section 5 and update the draft b= efore Friday. > thanks! > V.=20 >=20 >> On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt wrote: >>=20 >>=20 >> > On 22. Jul 2019, at 17:13, Vittorio Bertocci wrote: >> >=20 >> > Thank you Torsten for the prompt review and insightful comments! >> >=20 >> > 2.2.1 - excellent point. I added the suggested language. >> >=20 >> > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, w= here the effect of the request is influencing the layout of the resulting id= token, but concluded that it didn't apply as is for access tokens. Given tha= t you have direct knowledge of such cases in the wild, I am happy to relax t= he MUST into a SHOULD. >> >=20 >> > 5. - this is going to be problematic in the wild. For example, in the a= zure AD world a registered application can play both the role of an API and a= client; and requests for tokens targeting the app can use any identifier as= signed to the app. That means that although idtokens will only be issued if t= he request identifies the client via clientID, access tokens requests for it= will be honored (and reflected in aud) both in the case the resource parame= ter contains the clientID or the API URI of the target application. >>=20 >> Interesting and (in my opinion) reasonable. Out of the top of my head I d= on=E2=80=99t see how this has a negative security impact since the recipient= is always the same service.=20 >>=20 >> > In fact I suspect that the most recent version of the service uses the c= lientID as preferred identifier, if not the only one. Mike/Tony can confirm o= r deny. >> > As a compromise, we could add language in the spec that recommends the u= se of a unique audience when viable, as an extra measure in case the typ val= ue isn't honored. WDYT? >>=20 >> Having a unique audiences at least for different services is key. >>=20 >> In fact, I=E2=80=99m concerned about JWT confusion in OIDC RPs in the wil= d that do generally not honor the type (as long as we do not update OIDC Cor= e to require this and it is being adopted). I think since your draft require= s both, iss and aud to be present, this threat is being dealt with. Addition= ally stating that unique audiences shall be used for different services shou= ld be ok. >>=20 >>=20 >> > =20 >> >=20 >> > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt wrote: >> > Hi Vittorio, >> >=20 >> > thanks for contributing this specification. It fills a further gap in t= he OAuth universe :-) >> >=20 >> > Here are my comments: >> >=20 >> > - 2.2.1 there are other sources for identity claims, e.g. https://openi= d.net/specs/openid-connect-4-identity-assurance-1_0.html.=20 >> >=20 >> > I recommend to open the clause >> >=20 >> > "Any additional attributes whose semantic is well described by the >> > attributes description found in section 5.1 of [ >> > OpenID.Core] SHOULD >> > be codified in JWT access tokens via the corresponding claim names i= n >> > that section of the OpenID Connect specification. The same holds fo= r >> > attributes defined in [RFC7662]." >> >=20 >> > by adding=20 >> >=20 >> > "and other identity related specifications.=E2=80=9D=20 >> >=20 >> > Alternatively, the draft could also refer to the IANA =E2=80=9COAuth To= ken Introspection Response=E2=80=9D registry as source for JWT claims. >> >=20 >> > - 2.2.2.=20 >> >=20 >> > "If an authorization request includes a scope parameter, the >> > corresponding issued JWT access token MUST include a scope claim as >> > defined in section 4.2 of [TokenExchange]." >> >=20 >> > Why do you establish such a strong link between the scope in the author= ization request and the access token? I=E2=80=99m aware of implementations t= hat map scope values to audience values and therefore do not carry the scope= value to the resource server. I suggest to soften this requirement and make= it a recommendation.=20 >> >=20 >> > - 5.=20 >> >=20 >> > "The JWT access token data layout described here is very similar to the= one of the id_token as defined by [OpenID.Core]. Without the >> > explicit typing required in this profile, in line with the recommend= ations in [JWT.BestPractices] there would be the risk of >> > attackers using JWT access tokens in lieu of id_tokens." >> >=20 >> > I like this practice but it is not established yet in the OpenID Connec= t universe. This means any OIDC RP will process an access token because it w= ill just ignore the type header.=20 >> >=20 >> > draft-ietf-oauth-jwt-introspection-response therefore gives recommendat= ion on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf= .org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1).=20 >> >=20 >> > Mapping this pattern to JWTs as access token requires that there must n= ot be the same aud value for a resource server and any other JWT consumer, e= .g. an OpenID Connect RP.=20 >> >=20 >> > kind regards, >> > Torsten.=20 >> >=20 >> > > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: >> > >=20 >> > >=20 >> > > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >> > > This draft is a work item of the Web Authorization Protocol WG of the= IETF. >> > >=20 >> > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 A= ccess Tokens >> > > Author : Vittorio Bertocci >> > > Filename : draft-ietf-oauth-access-token-jwt-01.txt >> > > Pages : 15 >> > > Date : 2019-07-20 >> > >=20 >> > > Abstract: >> > > This specification defines a profile for issuing OAuth2 access toke= ns >> > > in JSON web token (JWT) format. Authorization servers and resource= >> > > servers from different vendors can leverage this profile to issue a= nd >> > > consume access tokens in interoperable manner. >> > >=20 >> > >=20 >> > > The IETF datatracker status page for this draft is: >> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ >> > >=20 >> > > There are also htmlized versions available at: >> > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 >> > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-j= wt-01 >> > >=20 >> > > A diff from the previous version is available at: >> > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt= -01 >> > >=20 >> > >=20 >> > > Please note that it may take a couple of minutes from the time of sub= mission >> > > until the htmlized version and diff are available at tools.ietf.org. >> > >=20 >> > > Internet-Drafts are also available by anonymous FTP at: >> > > ftp://ftp.ietf.org/internet-drafts/ >> > >=20 >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> >=20 >>=20 --Apple-Mail-1A559231-DF04-4111-A133-B993064D0EA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
tha= nks 

Am 22.07.2019 um 21:32 schrieb Vittorio B= ertocci <Vittorio@auth0.com>= :

<= div>> Additionally stating that unique audiences shall be used for differ= ent services should be ok.
Fair! I'll add language to that effect in se= ction 5 and update the draft before Friday.
thanks!
V. 

On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


> On 22. Jul 2019, at 17:13, Vittorio Bertocci <vittorio.bertocci@auth0.com&g= t; wrote:
>
> Thank you Torsten for the prompt review and insightful comments!
>
> 2.2.1 - excellent point. I added the suggested language.
>
> 2.2.2 - interesting. I did think of cases similar to profile in OIDC, w= here the effect of the request is influencing the layout of the resulting id= token, but concluded that it didn't apply as is for access tokens. Given tha= t you have direct knowledge of such cases in the wild, I am happy to relax t= he MUST into a SHOULD.
>
> 5. - this is going to be problematic in the wild. For example, in the a= zure AD world a registered application can play both the role of an API and a= client; and requests for tokens targeting the app can use any identifier as= signed to the app. That means that although idtokens will only be issued if t= he request identifies the client via clientID, access tokens requests for it= will be honored (and reflected in aud) both in the case the resource parame= ter contains the clientID or the API URI of the target application.

Interesting and (in my opinion) reasonable. Out of the top of my head I don=E2= =80=99t see how this has a negative security impact since the recipient is a= lways the same service.

> In fact I suspect that the most recent version of the service uses the c= lientID as preferred identifier, if not the only one. Mike/Tony can confirm o= r deny.
> As a compromise, we could add language in the spec that recommends the u= se of a unique audience when viable, as an extra measure in case the typ val= ue isn't honored. WDYT?

Having a unique audiences at least for different services is key.

In fact, I=E2=80=99m concerned about JWT confusion in OIDC RPs in the wild t= hat do generally not honor the type (as long as we do not update OIDC Core t= o require this and it is being adopted). I think since your draft requires b= oth, iss and aud to be present, this threat is being dealt with. Additionall= y stating that unique audiences shall be used for different services should b= e ok.


> 
>
> On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
> Hi Vittorio,
>
> thanks for contributing this specification. It fills a further gap in t= he OAuth universe :-)
>
> Here are my comments:
>
> - 2.2.1 there are other sources for identity claims, e.g. https://openid.net/specs/openid-connect-4-iden= tity-assurance-1_0.html.
>
> I recommend to open the clause
>
> "Any additional attributes whose semantic is well described by the
>    attributes description found in section 5.1 of [
> OpenID.Core] SHOULD
>    be codified in JWT access tokens via the corresponding cla= im names in
>    that section of the OpenID Connect specification.  Th= e same holds for
>    attributes defined in [RFC7662]."
>
> by adding
>
> "and other identity related specifications.=E2=80=9D
>
> Alternatively, the draft could also refer to the IANA =E2=80=9COAuth To= ken Introspection Response=E2=80=9D registry as source for JWT claims.
>
> - 2.2.2.
>
> "If an authorization request includes a scope parameter, the
>    corresponding issued JWT access token MUST include a scope= claim as
>    defined in section 4.2 of [TokenExchange]."
>
> Why do you establish such a strong link between the scope in the author= ization request and the access token? I=E2=80=99m aware of implementations t= hat map scope values to audience values and therefore do not carry the scope= value to the resource server. I suggest to soften this requirement and make= it a recommendation.
>
> - 5.
>
> "The JWT access token data layout described here is very similar to the= one of the id_token as defined by [OpenID.Core].  Without the
>    explicit typing required in this profile, in line with the= recommendations in [JWT.BestPractices] there would be the risk of
>    attackers using JWT access tokens in lieu of id_tokens." >
> I like this practice but it is not established yet in the OpenID Connec= t universe. This means any OIDC RP will process an access token because it w= ill just ignore the type header.
>
> draft-ietf-oauth-jwt-introspection-response therefore gives recommendat= ion on how to use iss and aud claim to prevent JWT abuse (https://tools.ietf.org/html/draft-= ietf-oauth-jwt-introspection-response-04#section-6.1).
>
> Mapping this pattern to JWTs as access token requires that there must n= ot be the same aud value for a resource server and any other JWT consumer, e= .g. an OpenID Connect RP.
>
> kind regards,
> Torsten.
>
> > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts= directories.
> > This draft is a work item of the Web Authorization Protocol WG of t= he IETF.
> >
> >        Title         =  : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
> >        Author         = ; : Vittorio Bertocci
> >       Filename        : dr= aft-ietf-oauth-access-token-jwt-01.txt
> >       Pages          &= nbsp;: 15
> >       Date          &= nbsp; : 2019-07-20
> >
> > Abstract:
> >   This specification defines a profile for issuing OAuth= 2 access tokens
> >   in JSON web token (JWT) format.  Authorization se= rvers and resource
> >   servers from different vendors can leverage this profi= le to issue and
> >   consume access tokens in interoperable manner.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.= org/doc/draft-ietf-oauth-access-token-jwt/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/= draft-ietf-oauth-access-token-jwt-01
> > https://datatracke= r.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01
> >
> >
> > Please note that it may take a couple of minutes from the time of s= ubmission
> > until the htmlized version and diff are available at tools.ietf.org= .
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org=
> > https://www.ietf.org/mailman/listinfo/oauth >

= --Apple-Mail-1A559231-DF04-4111-A133-B993064D0EA2-- --Apple-Mail-97277A7E-D7CC-4E45-9E5F-DA0B075714AD 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzIzMDUwMjU4WjAvBgkqhkiG9w0BCQQxIgQg aajiTgXGoS2qwD8c2B85BK9U35s5Vuwf+3llwhlkB/EwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0 MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAGSvUbVG9SBUj28K IX161yAye89TOPytIlFBwpP5MvTVVIBCDmZrp6Xyz6RGMM6PZzYQdPjaEw1iNnjSU4MLpi2cUCEc 8ZA2FTOsJqo0JSmkvKwuo5n3t3hAGxriLgBiiiGf/swB3G2njIk5ni1Pu6F9wIz26ArAhJtC9LT7 P16ehzDxbUSPcJbMsywc8OTVdEe+d4SyGBG9LG9TGF55xoRPv61741Znz+wtQesX4m5Ef71JZNdD mKtbiGGWl3x03tSL4OItbftBtUgfLRgVlHL8Jj+vvPnev3GwUs8sjZ177/3v18XtFs6oJJTp4IdW KA+ue4SFGzLt1QUTh/DzoeUAAAAAAAA= --Apple-Mail-97277A7E-D7CC-4E45-9E5F-DA0B075714AD-- From nobody Tue Jul 23 00:28: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 DBC9312004C for ; Tue, 23 Jul 2019 00:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 P6IA8zKN3_yi for ; Tue, 23 Jul 2019 00:28:22 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93D41200D6 for ; Tue, 23 Jul 2019 00:28:21 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id a15so40948523qtn.7 for ; Tue, 23 Jul 2019 00:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ofZeLA9X0xwQHASgLZJzP97tmG22PsUprRrzIdRgjEU=; b=JWHnb79sL7KsdrTGdOYCK3BKKO94j/XWD65hQ+txT+etTa6uLO+ULaEQIgw8TmCawu SKlIPHJxlxMj2VVzq52/9kmRirAWaeLRhD+yJqYp8+qlsffTDXnVD/tMKNoykG/EmRTF FkawAVjbWgkjVRd7AAr1NviWppShzaRSYUufdOKs5zKCP4noCAo/mH2E6Bci4jmdvsCG uHg+B09jR2kLAo/PJ2wuwQOodtUJkRXBUuyKzuFAEwCEIEasUj/Jk1lSE83Oapfpob5n fpBpguVO1A37gvoWG9ZRkpx7ke0gLnrf2sEvCBtzBJwfobaOZh0a8YNVY9QDeN3//QYP fNSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ofZeLA9X0xwQHASgLZJzP97tmG22PsUprRrzIdRgjEU=; b=WCR4SDCt3gbso9XrwpIPNyOrQSbM28ndDWKoaGw20f1s4N2NiVRSyx6HvmQzDytCwy JIsGBzJu7o2GebUziuYb5elQz3OMzjR0OLhLGEkLYvxXbenjoPaDY1yZnRCyU0IK20CF pr0s3+NQOkvT320v4SB+99BDcqLkPctMmf7daQ8dGCxfvoeg2SD3ETZ91UOe1WFQdzL1 FIBOerV76h75+4ndKDka6c7XS9Sk0yD7KPadGu1bXOS8PO1cMkvKHYzU0qNvQlEavq/i YVm9l6V6XAz3Jvx8766m8Bgj31jWJV1KpssvJI+X9BTBiL2pLaHOAFF83kTYrwXY6eeS UJuw== X-Gm-Message-State: APjAAAWQ41B8gXHTSlcY6DwRHXKdtEVcnMohZozLTJcYD4kbQsf7JB2t /WywJpNECWwMbmlnIyGlBVjJTbpkqsf6e9YNzvaAy/4= X-Google-Smtp-Source: APXvYqwgYFkjecL51UYjW/4VKhVqvi7EyYdGHdBgBBVh7s8p8TiSaHW5JZUBSmOgvOynOg0R1fD1aRCOzaCSIQ1ERS8= X-Received: by 2002:aed:36c5:: with SMTP id f63mr53435654qtb.239.1563866900421; Tue, 23 Jul 2019 00:28:20 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jul 2019 00:28:19 -0700 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 23 Jul 2019 00:28:19 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="0000000000001373b5058e54232f" Archived-At: Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Tue, 23 Jul 2019 07:28:24 -0000 --0000000000001373b5058e54232f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forgot one more thing In 7.1 Browser-based apps MUST use the OAuth 2.0 "state" parameter to protect themselves against Cross-Site Request Forgery and authorization code swap attacks and MUST use a unique value for each authorization request, and MUST verify the returned state in the authorization response matches the original state the app created. Isn=E2=80=99t state optional when PKCE is used? thanks =E2=80=94=E2=80=94=E2=80=94 Dominick On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) wrote: Hey, Just read the spec - good to see the progress. Some feedback: I am yet undecided if I like the categorisation of the =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitely want to distinguish between applications only accessing same-site back-end services and =E2=80=9Cothers= =E2=80=9D. Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic applicatio= n server=E2=80=9D should be handled differently - they are deployment details and should not decide on the application security architecture. Also not sure how realistic it is to deploy a typical applications solely from e.g. a CDN. But I don=E2=80=99= t have the right answer wrt to categories right now. 6.1. Apps Served from a Common Domain as the Resource Server > OAuth and OpenID Connect provide very little benefit in this deployment scenario, so it is recommended to reconsider whether you need OAuth or OpenID Connect at all in this case. I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access. Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading. 6.2. Apps Served from a Dynamic Application Server I have a .NET sample for that https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore= 21/BFF And a blog post https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit= h-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ 9.7 . Content-Security Policy A browser-based application that wishes to use either long-lived refresh tokens or privileged scopes SHOULD restrict its JavaScript execution to a set of statically hosted scripts via a Content Security Policy ([CSP2 ]) or similar mechanism. I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled. Thanks for doing this work! =E2=80=94=E2=80=94=E2=80=94 Dominick --0000000000001373b5058e54232f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Forg= ot one more thing

I= n 7.1

Browser-based apps = MUST use the OAuth 2.0 "state" parameter to
=C2=A0 =C2=A0protect themselves against Cross-Site Request Forger= y and
=C2=A0 =C2=A0authorization code swap a= ttacks and MUST use a unique value for each
= =C2=A0 =C2=A0authorization request, and MUST verify the returned state in t= he
=C2=A0 =C2=A0authorization response match= es the original state the app created.

<= /div>
Isn=E2=80=99t state optional when PKCE is us= ed?

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

On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) wrote:

Hey,=C2=A0

Just read the spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisation of the =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitely want to distinguish between applications only accessing same-site back-end services and =E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic application server&q= uot; and =E2=80=9Cstatic application server=E2=80=9D should be handled differently - they are deployment details and should not decide on the application security architecture. Also not sure how realistic it is to deploy a typical applications solely from e.g. a CDN. But I don=E2=80=99t have the right answer wrt to categories right now.

6.1.=C2=A0 Apps Served from a Common Domain as the Resource Server

> OAuth and OpenID Connect provide very little benefit in this
=C2=A0 =C2=A0deployment scenario, so it is recommended to reconsider whether you
=C2=A0 =C2=A0need OAuth or OpenID Connect at all in this case.

I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access.=C2=A0
Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading.


6.2.=C2=A0 Apps Served from a Dynamic Application Server

I have a .NET sample for that=C2=A0

And a blog post





9.7. Content-Security Policy=



   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.


=



=




I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if
refresh or access tokens are involved - further settings like
disabling inline scripting (unsafe inline) and eval should be
disabled.











Thanks
for doing this work!






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


Dominick










--0000000000001373b5058e54232f--


From nobody Tue Jul 23 00:44: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 04A411200F1 for ; Tue, 23 Jul 2019 00:44:43 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EZ-BKWbjzbGX for ; Tue, 23 Jul 2019 00:44:40 -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 0339112010D for ; Tue, 23 Jul 2019 00:44:39 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id z1so41983882wru.13 for ; Tue, 23 Jul 2019 00:44:39 -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=gtUoSPvACpd6G16ZRBPRgwcNP3wLjRjlriRdNFRFykU=; b=hlhCx7hR8zGLx8o3AHYkdSWZPPuHrevQ/5RoKiKetbBHi3kQlHMnHLMXu4+a+SwGWo dzE/ft03pSVFuaWIOsCoGqjsq0Y/Wi7fffzRZ9OsT6l8hpVjmx/NMSn6ENv1mJuxg9sd D5d62xw3k+xLoEfm2aexXHuXa+S3puHTw/77I=
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=gtUoSPvACpd6G16ZRBPRgwcNP3wLjRjlriRdNFRFykU=; b=BkZMLCQD2iGvS6knuBhP7TYOMROQHWiwiXlcwaIksy+Z6oyDgDOkuKZaoCg6IFe8+7 a1oXJFVj0sP3KGAJhncyLKgSt8scIIVmh663zerCfjdwJbRYMXGYLIDQZki4N8AMhESy WDu6YLS/kXmggs81lrCtZ1AEHoVdBJnrh0CV9J/EHGk/TGI29nK35+J3uZLYL7AO8Zr9 4uRraOzbXz38zBrsySTQ09wtVQcwUKg8AAmz4CPVcxNG7/f17SsGDbVwXhB884FPPNqr 0IVKILfagL0NA50pWir9zps1jeBVP4boatMp8nnUhnehTIpcv9DCEzrFYvRLvi1LKiDh OFCw==
X-Gm-Message-State: APjAAAVytSE0N8OULd6h45PtxT6t+OGI4hdx6D5SJDJuzQexQ2+1SVkp ukqT1zmzi9fIbSydAheFzF6PwgvO/5GqGewApzpQngZZJrQW3eCoF+AjcPz1yZDaqS4kmR7ghM/ Z+uiDeqEUE6r+5nUmsvmRiHe9F1jR3s1OR6Ks2XjHsBfGRIexVKGUIs+6HmCGgtub8A==
X-Google-Smtp-Source: APXvYqzGr/cfaaEY0My9/BG74iLQsBmgsRy1JeSFC+h9UEYM4d4rO6gqBPeDzmCyV6f8lqNo/mk4lA==
X-Received: by 2002:a05:6000:1186:: with SMTP id g6mr68581353wrx.17.1563867878045;  Tue, 23 Jul 2019 00:44:38 -0700 (PDT)
Received: from [192.168.1.65] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id n14sm76238973wra.75.2019.07.23.00.44.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 00:44:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-1F2A2D9B-2516-4236-9042-95AA4846B83F
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: 
Date: Tue, 23 Jul 2019 08:44:36 +0100
Cc: OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  
To: Dominick Baier 
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Tue, 23 Jul 2019 07:44:43 -0000

--Apple-Mail-1F2A2D9B-2516-4236-9042-95AA4846B83F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Technically it could be optional, but it means that a CSRF attempt will only=
 be detected by the AS not by the client. If we consider the possibility of a=
 malicious AS, then this could allow Login CSRF attacks against the client. T=
he client would also have to be sure that the AS actually implements PKCE. S=
o I think it=E2=80=99s safer to leave the recommendation as-is.=20

> On 23 Jul 2019, at 08:28, Dominick Baier  wrote=
:
>=20
> Forgot one more thing
>=20
> In 7.1
>=20
> Browser-based apps MUST use the OAuth 2.0 "state" parameter to
>    protect themselves against Cross-Site Request Forgery and
>    authorization code swap attacks and MUST use a unique value for each
>    authorization request, and MUST verify the returned state in the
>    authorization response matches the original state the app created.
>=20
> Isn=E2=80=99t state optional when PKCE is used?
>=20
> thanks
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
>=20
>> On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) w=
rote:
>>=20
>> Hey,=20
>>=20
>> Just read the spec - good to see the progress. Some feedback:
>>=20
>> I am yet undecided if I like the categorisation of the =E2=80=9CApplicati=
on Architecture Patterns=E2=80=9D. I definitely want to distinguish between a=
pplications only accessing same-site back-end services and =E2=80=9Cothers=E2=
=80=9D. Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic=
 application server=E2=80=9D should be handled differently - they are deploy=
ment details and should not decide on the application security architecture.=
 Also not sure how realistic it is to deploy a typical applications solely f=
rom e.g. a CDN. But I don=E2=80=99t have the right answer wrt to categories r=
ight now.
>>=20
>> 6.1.  Apps Served from a Common Domain as the Resource Server
>>=20
>> > OAuth and OpenID Connect provide very little benefit in this
>>    deployment scenario, so it is recommended to reconsider whether you
>>    need OAuth or OpenID Connect at all in this case.
>>=20
>> I think you are mixing authentication and API access here. Depending on a=
pplication scenario it makes a lot of sense to use OIDC - but rely on the re=
sulting session to control API access.=20
>> Unless you want to dive into the details here, I suggest you remove the m=
ention of OIDC because it is misleading.
>>=20
>>=20
>> 6.2.  Apps Served from a Dynamic Application Server
>>=20
>> I have a .NET sample for that=20
>>=20
>> https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetco=
re21/BFF
>> And a blog post
>> https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-w=
ith-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>>=20
>> 9.7. Content-Security Policy
>>    A browser-based application that wishes to use either long-lived
>>    refresh tokens or privileged scopes SHOULD restrict its JavaScript
>>    execution to a set of statically hosted scripts via a Content
>>    Security Policy ([CSP2]) or similar mechanism.
>>=20
>>=20
>> I would rather say that ANY JS app should use CSP to lock down the browse=
r features to a minimal attack surface. In addition, if refresh or access to=
kens are involved - further settings like disabling inline scripting (unsafe=
 inline) and eval should be disabled.
>>=20
>> Thanks for doing this work!
>>=20
>> =E2=80=94=E2=80=94=E2=80=94
>> Dominick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-1F2A2D9B-2516-4236-9042-95AA4846B83F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Tec=
hnically it could be optional, but it means that a CSRF attempt will only be=
 detected by the AS not by the client. If we consider the possibility of a m=
alicious AS, then this could allow Login CSRF attacks against the client. Th=
e client would also have to be sure that the AS actually implements PKCE. So=
 I think it=E2=80=99s safer to leave the recommendation as-is. 

On 23 Jul 2019, at 08:28, Dominick Baier <dbaier@leastprivilege.com> wrote:
Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site Req=
uest Forgery and
   authorization c=
ode swap attacks and MUST use a unique value for each
   authorization request, and MUST verify the returned st=
ate in the
   authorization respons=
e matches the original state the app created.

Isn=E2=80=99t state optional when PKCE i=
s used?
 

thanks
 
=E2=80=94=E2=80=94=E2=80=94
Dominick
 
On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) wrote:
 










Hey, 






Just read
the spec - good to see the progress. Some feedback:






I am yet
undecided if I like the categorisation of the =E2=80=9CApplication
Architecture Patterns=E2=80=9D. I definitely want to distinguish between
applications only accessing same-site back-end services and
=E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic application server" a=
nd =E2=80=9Cstatic
application server=E2=80=9D should be handled differently - they are
deployment details and should not decide on the application
security architecture. Also not sure how realistic it is to deploy
a typical applications solely from e.g. a CDN. But I don=E2=80=99t have the
right answer wrt to categories right now.






6.1.  Apps Served from a Common
Domain as the Resource Server





> OAuth and OpenID Connect provide
very little benefit in this


   deployment scenario, so it
is recommended to reconsider whether you


   need OAuth or OpenID Connect
at all in this case.





I think you are mixing authentication and
API access here. Depending on application scenario it makes a lot
of sense to use OIDC - but rely on the resulting session to control
API access. 


Unless you want to dive into the details
here, I suggest you remove the mention of OIDC because it is
misleading.








6.2.  Apps Served from a Dynamic
Application Server





I have a .NET sample for that 






And a blog post












9.7. Content-Security Policy


   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.







I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if
refresh or access tokens are involved - further settings like
disabling inline scripting (unsafe inline) and eval should be
disabled.











Thanks
for doing this work!






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


Dominick










________=
_______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.=
ietf.org/mailman/listinfo/oauth
=

--Apple-Mail-1F2A2D9B-2516-4236-9042-95AA4846B83F--


From nobody Tue Jul 23 01:08: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 D9E24120133 for ; Tue, 23 Jul 2019 01:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmhofRy4UqFH for ; Tue, 23 Jul 2019 01:08:45 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FB6120132 for ; Tue, 23 Jul 2019 01:08:45 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id x4so42059848wrt.6 for ; Tue, 23 Jul 2019 01:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZV0T3QMP0wk50SBtySMkG54EPdmaUWO2fRfFDQ1Oyfg=; b=rtDBUfAEbQiqvC+iQ3RP5Nl/haazo/KCRkgOzzto8VxU1raX2stPnSTM1hXwUgovAn VIHmHRsfb3C2E0DOdf7FWJXaxhV4UCRq6KiTalM6YyhwV9D+92L4d6U0O+lBEDVuHABh KcCbc0IDIKz14gC4cpZfSclpFYbpQZAOanTQ5dYTE3rbAwE+zG8VIkEa5Xl5s2bbtf6s uTtJtXZcmRlXvjfuSQlgxFmFNrSMMByMrVyPCbObp9HZqHjIsSBlYq4YBDk5qoUu81t+ SIw68Rtp6xl8tByRQwmky1rMAxS/n+4qQI5GaI4b/mcF3iCZnyfg3LAFnhAwctgKMRnw LlPw==
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=ZV0T3QMP0wk50SBtySMkG54EPdmaUWO2fRfFDQ1Oyfg=; b=kYhEK9qQb7cfTPKLx7TK+YynWX/cYhwGPAaF8291MH4B5Kt4zbPvny6RCBbb6qcwa4 bXT7GzjaM897Yu3/fK30rNICo44P/Xd+rZIci3qxkoNrktCKz67riHW0t7dJSF5hzrq2 B0cXCUCBHyuJiW2hxm3yrHqHMBTmimYtmUawmBWfoUoZsPmqRtyKguypsoOzj5GeLPSd 0pYtgL21RPg4C7NXAF6UWarAUwT+wJQvF+p/v7tfJGqi90joa4YNcyrTjM9En6uvYTzE 3cd0wO98f1u0veV/IJZV7slsDaWMrYbpROg7l6o0RBXllGOgxXvJuHrBqzgclh2uiwxF z7kQ==
X-Gm-Message-State: APjAAAWjjcHs6tAyccXyKcKACD3G4f5WCO6i2QE/xpsfsMottG4sQrii GwmDrypGh9EXui4leBsuF31mp5NfyA==
X-Google-Smtp-Source: APXvYqyJDZNFuGNhIs8mvmz4Imp0WaEa2SJcS7k1KczEGiRrB8+HpWg8/h9f5JftrZKUJdBjRCg18w==
X-Received: by 2002:a5d:438e:: with SMTP id i14mr76205340wrq.122.1563869323437;  Tue, 23 Jul 2019 01:08:43 -0700 (PDT)
Received: from [192.168.1.110] (ip-37-188-255-15.eurotel.cz. [37.188.255.15]) by smtp.gmail.com with ESMTPSA id y16sm85721299wrg.85.2019.07.23.01.08.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 01:08:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7E1B1DE9-7E2B-4A4F-B9D8-2F34F92A0B92
Mime-Version: 1.0 (1.0)
From: Filip Skokan 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: 
Date: Tue, 23 Jul 2019 10:08:41 +0200
Cc: Dominick Baier , OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: <7AB72379-075B-411D-B149-3759F16B001A@gmail.com>
References:   
To: Neil Madden 
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Tue, 23 Jul 2019 08:08:49 -0000

--Apple-Mail-7E1B1DE9-7E2B-4A4F-B9D8-2F34F92A0B92
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Wouldn=E2=80=99t that contradict the security topics BCP?

Odesl=C3=A1no z iPhonu

23. 7. 2019 v 9:44, Neil Madden :

> Technically it could be optional, but it means that a CSRF attempt will on=
ly be detected by the AS not by the client. If we consider the possibility o=
f a malicious AS, then this could allow Login CSRF attacks against the clien=
t. The client would also have to be sure that the AS actually implements PKC=
E. So I think it=E2=80=99s safer to leave the recommendation as-is.=20
>=20
>> On 23 Jul 2019, at 08:28, Dominick Baier  wrot=
e:
>>=20
>> Forgot one more thing
>>=20
>> In 7.1
>>=20
>> Browser-based apps MUST use the OAuth 2.0 "state" parameter to
>>    protect themselves against Cross-Site Request Forgery and
>>    authorization code swap attacks and MUST use a unique value for each
>>    authorization request, and MUST verify the returned state in the
>>    authorization response matches the original state the app created.
>>=20
>> Isn=E2=80=99t state optional when PKCE is used?
>>=20
>> thanks
>> =E2=80=94=E2=80=94=E2=80=94
>> Dominick
>>=20
>>> On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com)=
 wrote:
>>>=20
>>> Hey,=20
>>>=20
>>> Just read the spec - good to see the progress. Some feedback:
>>>=20
>>> I am yet undecided if I like the categorisation of the =E2=80=9CApplicat=
ion Architecture Patterns=E2=80=9D. I definitely want to distinguish between=
 applications only accessing same-site back-end services and =E2=80=9Cothers=
=E2=80=9D. Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Csta=
tic application server=E2=80=9D should be handled differently - they are dep=
loyment details and should not decide on the application security architectu=
re. Also not sure how realistic it is to deploy a typical applications solel=
y from e.g. a CDN. But I don=E2=80=99t have the right answer wrt to categori=
es right now.
>>>=20
>>> 6.1.  Apps Served from a Common Domain as the Resource Server
>>>=20
>>> > OAuth and OpenID Connect provide very little benefit in this
>>>    deployment scenario, so it is recommended to reconsider whether you
>>>    need OAuth or OpenID Connect at all in this case.
>>>=20
>>> I think you are mixing authentication and API access here. Depending on a=
pplication scenario it makes a lot of sense to use OIDC - but rely on the re=
sulting session to control API access.=20
>>> Unless you want to dive into the details here, I suggest you remove the m=
ention of OIDC because it is misleading.
>>>=20
>>>=20
>>> 6.2.  Apps Served from a Dynamic Application Server
>>>=20
>>> I have a .NET sample for that=20
>>>=20
>>> https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetc=
ore21/BFF
>>> And a blog post
>>> https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-=
with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>>>=20
>>> 9.7. Content-Security Policy
>>>    A browser-based application that wishes to use either long-lived
>>>    refresh tokens or privileged scopes SHOULD restrict its JavaScript
>>>    execution to a set of statically hosted scripts via a Content
>>>    Security Policy ([CSP2]) or similar mechanism.
>>>=20
>>>=20
>>> I would rather say that ANY JS app should use CSP to lock down the brows=
er features to a minimal attack surface. In addition, if refresh or access t=
okens are involved - further settings like disabling inline scripting (unsaf=
e inline) and eval should be disabled.
>>>=20
>>> Thanks for doing this work!
>>>=20
>>> =E2=80=94=E2=80=94=E2=80=94
>>> Dominick
>> _______________________________________________
>> 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-7E1B1DE9-7E2B-4A4F-B9D8-2F34F92A0B92
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Wouldn=E2=80=99t that contradict the securi=
ty topics BCP?

Odesl=C3=A1=
no z iPhonu

23. 7. 2019 v 9:44, Neil Mad=
den <neil.madden@forgerock.c=
om>:

Technically it could be optional, but it means t=
hat a CSRF attempt will only be detected by the AS not by the client. If we c=
onsider the possibility of a malicious AS, then this could allow Login CSRF a=
ttacks against the client. The client would also have to be sure that the AS=
 actually implements PKCE. So I think it=E2=80=99s safer to leave the recomm=
endation as-is. 

On 23 Jul 2019, at 08:28, Do=
minick Baier <dbaier@leastpr=
ivilege.com> wrote:

Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "st=
ate" parameter to
   protect themse=
lves against Cross-Site Request Forgery and
&=
nbsp;  authorization code swap attacks and MUST use a unique value for e=
ach
   authorization request, and M=
UST verify the returned state in the
  &=
nbsp;authorization response matches the original state the app created.

Isn=E2=80=99t=
 state optional when PKCE is used?
 

thanks
 =E2=80=94=E2=80=94=E2=80=94
Dominick
 
On 22. July 2019 at 08:14:33, Dominick Baie=
r (dbaier@leastprivilege.com) wrote:
 
<=
/div>










Hey, 






Just read
the spec - good to see the progress. Some feedback:






I am yet
undecided if I like the categorisation of the =E2=80=9CApplication
Architecture Patterns=E2=80=9D. I definitely want to distinguish between
applications only accessing same-site back-end services and
=E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic application server" a=
nd =E2=80=9Cstatic
application server=E2=80=9D should be handled differently - they are
deployment details and should not decide on the application
security architecture. Also not sure how realistic it is to deploy
a typical applications solely from e.g. a CDN. But I don=E2=80=99t have the
right answer wrt to categories right now.






6.1.  Apps Served from a Common
Domain as the Resource Server





> OAuth and OpenID Connect provide
very little benefit in this


   deployment scenario, so it
is recommended to reconsider whether you


   need OAuth or OpenID Connect
at all in this case.





I think you are mixing authentication and
API access here. Depending on application scenario it makes a lot
of sense to use OIDC - but rely on the resulting session to control
API access. 


Unless you want to dive into the details
here, I suggest you remove the mention of OIDC because it is
misleading.








6.2.  Apps Served from a Dynamic
Application Server





I have a .NET sample for that 






And a blog post












9.7. Content-Security Policy


   A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.







I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if
refresh or access tokens are involved - further settings like
disabling inline scripting (unsafe inline) and eval should be
disabled.











Thanks
for doing this work!






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


Dominick










________=
_______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.=
ietf.org/mailman/listinfo/oauth
___________________=
____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-7E1B1DE9-7E2B-4A4F-B9D8-2F34F92A0B92--


From nobody Tue Jul 23 01:31: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 498D1120104 for ; Tue, 23 Jul 2019 01:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 378JSaiQYGmH for ; Tue, 23 Jul 2019 01:31:28 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBAB12007A for ; Tue, 23 Jul 2019 01:31:28 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id w17so41065154qto.10 for ; Tue, 23 Jul 2019 01:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uj5OBPDzQJ6+tx+qZZoqTGCO69eviTLhGLv6DNa3/88=; b=B5wKHAp0dVq7wLALApZWVeg7GAJB/0cOImQwF3LzN1MCJxDb5k2wxEWfDY1P3GKZHn AyoUGeY1bITYpFtkvZLrXnBI7uYYUcMLMTc3E5uXIwzJpsitwvxit98LyaRyDV6J1xe4 244newneXgu30gFG5CohaWsSvs/DePbOw4dvqdhi46DHm/DsvAj1RKsJHBK6nNTf3aXz KNe6QYv+GaGCatrI41vlWS9bTlgTtvB+hAnWwOxwCFRlcnz0HMIf1zY/3PuDUQFn/Oko MIPdBxy9Yb/U8qBqlWFDOV8oaQ+jWLAIj099Ur5E1GGIUao0BZixyXvHP42UgwdXVVnh p14g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uj5OBPDzQJ6+tx+qZZoqTGCO69eviTLhGLv6DNa3/88=; b=l47VXptHiyvCj/MW8rZiMcn6wNkvO3d4FfvilEqL5660RsuRg1oyTMe5bpcHzkgSat Mu5O0oALJeSEWNn3itaV/1DTeluQfhB4z2Lad1vz3zGUx9QKWCjfNuKJGwFRyZZNJOFP e5ts2Lkb+v7DZYRBsmoOG+WnZRfWIWcb2uAOM+XFMKfbqV1IbGtJOyfboTM3PDCG9fIk lkNdh58OdWMpLieFwTx3+b/WBGG9ceCumEwmAWbNUUYwRqSIDQpXKzXQ3J5w12oeuJTE +KwUN4nt9oYKrh4yadyk/ofGPen0HaEB3ZmHJEZKfbk4W+UuF5z/pEGd1aTndu0LS3gv lNQA==
X-Gm-Message-State: APjAAAW8GWEB11Lv/LKT483IuOsN7ENLcXp55rfL4zZemW5pgBjO6mNi BqSohIc6qFm0at3M78pCP0uCTM/o6kOjNwuGTA==
X-Google-Smtp-Source: APXvYqxZ3Fh+Qfnb+CHLKTH7RvbTZbJjpEtgGxojoHedF0SuWGaBseBr46B7/xbJxBe1KYiLbULOSDaKXqeji2EPMYM=
X-Received: by 2002:a0c:b192:: with SMTP id v18mr53585537qvd.90.1563870687492;  Tue, 23 Jul 2019 01:31:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jul 2019 01:31:27 -0700
From: Dominick Baier 
In-Reply-To: <7AB72379-075B-411D-B149-3759F16B001A@gmail.com>
References:    <7AB72379-075B-411D-B149-3759F16B001A@gmail.com>
MIME-Version: 1.0
Date: Tue, 23 Jul 2019 01:31:27 -0700
Message-ID: 
To: Neil Madden , Filip Skokan 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000cd8ddb058e550443"
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Tue, 23 Jul 2019 08:31:31 -0000

--000000000000cd8ddb058e550443
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes it would.

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

On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com) wrote:

Wouldn=E2=80=99t that contradict the security topics BCP?

Odesl=C3=A1no z iPhonu

23. 7. 2019 v 9:44, Neil Madden :

Technically it could be optional, but it means that a CSRF attempt will
only be detected by the AS not by the client. If we consider the
possibility of a malicious AS, then this could allow Login CSRF attacks
against the client. The client would also have to be sure that the AS
actually implements PKCE. So I think it=E2=80=99s safer to leave the recomm=
endation
as-is.

On 23 Jul 2019, at 08:28, Dominick Baier  wrote:

Forgot one more thing

In 7.1

Browser-based apps MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site Request Forgery and
   authorization code swap attacks and MUST use a unique value for each
   authorization request, and MUST verify the returned state in the
   authorization response matches the original state the app created.

Isn=E2=80=99t state optional when PKCE is used?

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

On 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com)
wrote:

Hey,

Just read the spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisation of the =E2=80=9CApplication
Architecture Patterns=E2=80=9D. I definitely want to distinguish between
applications only accessing same-site back-end services and =E2=80=9Cothers=
=E2=80=9D. Not
sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic applicatio=
n server=E2=80=9D should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don=E2=80=99=
t have
the right answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource Server

> OAuth and OpenID Connect provide very little benefit in this
   deployment scenario, so it is recommended to reconsider whether you
   need OAuth or OpenID Connect at all in this case.

I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.


6.2.  Apps Served from a Dynamic Application Server

I have a .NET sample for that

https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore=
21/BFF
And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit=
h-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7
.
Content-Security Policy

A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2
])
or similar mechanism.



I would rather say that ANY JS app should use CSP to lock down the browser
features to a minimal attack surface. In addition, if refresh or access
tokens are involved - further settings like disabling inline scripting
(unsafe inline) and eval should be disabled.

Thanks for doing this work!

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

_______________________________________________
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

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

=

Yes =
it would.
 
 
=E2=80=94=E2=80=94=E2=
=80=94
Dominick
 
On 23. July 201=
9 at 10:08:43, Filip Skokan (panva.ip=
@gmail.com) wrote:
 







Wouldn=E2=80=99t that contradict the security topics BCP?




Odesl=C3=A1no z=C2=A0iPhonu



23. 7. 2019 v=C2=A09:44, Neil Madden <neil.madden@forgerock.com>:












Technically it could be optional, but it means that
a CSRF attempt will only be detected by the AS not by the client.
If we consider the possibility of a malicious AS, then this could
allow Login CSRF attacks against the client. The client would also
have to be sure that the AS actually implements PKCE. So I think
it=E2=80=99s safer to leave the recommendation as-is.=C2=A0




On 23 Jul 2019, at 08:28, Dominick Baier <dbaier@leastprivilege.com>
wrote:









Forgot one
more thing






In
7.1








Browser-based apps MUST use the OAuth 2.0
"state" parameter to


=C2=A0 =C2=A0protect themselves against
Cross-Site Request Forgery and


=C2=A0 =C2=A0authorization code swap
attacks and MUST use a unique value for each


=C2=A0 =C2=A0authorization request, and
MUST verify the returned state in the


=C2=A0 =C2=A0authorization response matches
the original state the app created.





Isn=E2=80=99t state optional when PKCE is
used?






thanks


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

Dominick






On 22. July 2019 at 08:14:33, Dominick Baier
(dbaier@leastprivilege.com=
)
wrote:









Hey,=C2=A0






Just
read the spec - good to see the progress. Some
feedback:






I am
yet undecided if I like the categorisation of the =E2=80=9CApplication
Architecture Patterns=E2=80=9D. I definitely want to distinguish between
applications only accessing same-site back-end services and
=E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic application server&q=
uot; and =E2=80=9Cstatic
application server=E2=80=9D should be handled differently - they are
deployment details and should not decide on the application
security architecture. Also not sure how realistic it is to deploy
a typical applications solely from e.g. a CDN. But I don=E2=80=99t have the
right answer wrt to categories right now.






6.1.=C2=A0 Apps Served from a Common
Domain as the Resource Server





> OAuth and OpenID Connect provide
very little benefit in this


=C2=A0 =C2=A0deployment scenario, so
it is recommended to reconsider whether you


=C2=A0 =C2=A0need OAuth or OpenID
Connect at all in this case.





I think you are mixing authentication
and API access here. Depending on application scenario it makes a
lot of sense to use OIDC - but rely on the resulting session to
control API access.=C2=A0


Unless you want to dive into the
details here, I suggest you remove the mention of OIDC because it
is misleading.








6.2.=C2=A0 Apps Served from a Dynamic
Application Server





I have a .NET sample for
that=C2=A0






And a blog post











9.7.
Content-Security Policy


A browser-based application that wishes to use either long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.


=



=



I
would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if
refresh or access tokens are involved - further settings like
disabling inline scripting (unsafe inline) and eval should be
disabled.












Thanks
for doing this work!





=E2=80=94=E2=80=94=E2=80=94<=
/span>

Dominick



















_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.i=
etf.org/mailman/listinfo/oauth













_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.i=
etf.org/mailman/listinfo/oauth










--000000000000cd8ddb058e550443--


From nobody Tue Jul 23 02: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 422BD12018F for ; Tue, 23 Jul 2019 02:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 1YI2qANHq4LA for ; Tue, 23 Jul 2019 02:46:25 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D56F120194 for ; Tue, 23 Jul 2019 02:46:24 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id g17so42447242wrr.5 for ; Tue, 23 Jul 2019 02:46:24 -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=DHJYxCFuu3n9fe6kwRnnj9SigenkqykKJSEm+exJYlc=; b=dz5VvUtfj4JZ/oIXDBvGEFrnVMdtekRPRxaw2n7Wq1UguiwJos5ZyogB18O9o0nc7u GvnOAXbIyHZ7RP3R3sMzyPxqLoeLVxUdRJSCdWd9NQdCasAcuqyiM2lPV/aDX1zlAUrJ xPczr9SIf5sxNhBsaiQbVHLv30Qs3xh3fOUIU=
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=DHJYxCFuu3n9fe6kwRnnj9SigenkqykKJSEm+exJYlc=; b=OAxmAIqsMLa9sLojk6IXRaoG5LETwyiWBcP2sUBbmyDKF2HgZA839rWV4eKtqXTl/2 sFxPS8AUit7FDJIZbi7uq1yobQRA1P87STQ5G9RF+SwyHSvLFZYY5vyluvY1BEiJA+F7 yqgRYMdqcmltITMCQ1PnlFOWg8MIiNCvnkvKowY6SX1UPivrhJ3cia1GrVlPxh4DFpvJ 2+fG10oBoo4wLwE91qQupOpVLAWfbXuaardVHXc/IVwmkU/jINVapPB3FvjrHWkJkY1p haMIL/QawwUuyB9Yj5bXoe/ExLKAlS6CrRee5HoqhoycW8xmRyZP0DE1HyhByPxGvzk+ eIMw==
X-Gm-Message-State: APjAAAU9SZyAZdJpIfkFuQCfbio4P5T01VGx2LI0zcPAs+qBRFIryMS2 l/AiWlOPoF9Kx1cn6BOxp17Oxg==
X-Google-Smtp-Source: APXvYqyhhJbITIP3ui14/5FNTiQJ/pSYYMXO8roxpvVUKu0AbH4OUL5B2FV7VueCRNNOMhWQDTd1JA==
X-Received: by 2002:a5d:4e06:: with SMTP id p6mr37689988wrt.336.1563875183007;  Tue, 23 Jul 2019 02:46:23 -0700 (PDT)
Received: from [192.168.2.140] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id p14sm34459800wrx.17.2019.07.23.02.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 02:46:22 -0700 (PDT)
From: Neil Madden 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 10:46:19 +0100
In-Reply-To: 
Cc: Filip Skokan , OAuth WG 
To: Dominick Baier 
References:    <7AB72379-075B-411D-B149-3759F16B001A@gmail.com> 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Tue, 23 Jul 2019 09:46:28 -0000

--Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Not sure I follow - the current OAuth security topics BCP allows for =
using either state or PKCE for detecting CSRF =
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4=
.7.1 =
), with some caveats for when state is preferred.

I think I prefer the current wording in the browser-based draft, which =
provides a much clearer unambiguous recommendation.

-- Neil

> On 23 Jul 2019, at 09:31, Dominick Baier  =
wrote:
>=20
> Yes it would.
>=20
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
>=20
> On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com =
) wrote:
>=20
>> Wouldn=E2=80=99t that contradict the security topics BCP?
>>=20
>> Odesl=C3=A1no z iPhonu
>>=20
>> 23. 7. 2019 v 9:44, Neil Madden >:
>>=20
>>> Technically it could be optional, but it means that a CSRF attempt =
will only be detected by the AS not by the client. If we consider the =
possibility of a malicious AS, then this could allow Login CSRF attacks =
against the client. The client would also have to be sure that the AS =
actually implements PKCE. So I think it=E2=80=99s safer to leave the =
recommendation as-is.=20
>>>=20
>>> On 23 Jul 2019, at 08:28, Dominick Baier > wrote:
>>>=20
>>>> Forgot one more thing
>>>>=20
>>>> In 7.1
>>>>=20
>>>> Browser-based apps MUST use the OAuth 2.0 "state" parameter to
>>>>    protect themselves against Cross-Site Request Forgery and
>>>>    authorization code swap attacks and MUST use a unique value for =
each
>>>>    authorization request, and MUST verify the returned state in the
>>>>    authorization response matches the original state the app =
created.
>>>>=20
>>>> Isn=E2=80=99t state optional when PKCE is used?
>>>>=20
>>>> thanks
>>>> =E2=80=94=E2=80=94=E2=80=94
>>>> Dominick
>>>>=20
>>>> On 22. July 2019 at 08:14:33, Dominick Baier =
(dbaier@leastprivilege.com ) wrote:
>>>>=20
>>>>> Hey,=20
>>>>>=20
>>>>> Just read the spec - good to see the progress. Some feedback:
>>>>>=20
>>>>> I am yet undecided if I like the categorisation of the =
=E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitely want =
to distinguish between applications only accessing same-site back-end =
services and =E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic =
application server" and =E2=80=9Cstatic application server=E2=80=9D =
should be handled differently - they are deployment details and should =
not decide on the application security architecture. Also not sure how =
realistic it is to deploy a typical applications solely from e.g. a CDN. =
But I don=E2=80=99t have the right answer wrt to categories right now.
>>>>>=20
>>>>> 6.1.  Apps Served from a Common Domain as the Resource Server
>>>>>=20
>>>>> > OAuth and OpenID Connect provide very little benefit in this
>>>>>    deployment scenario, so it is recommended to reconsider whether =
you
>>>>>    need OAuth or OpenID Connect at all in this case.
>>>>>=20
>>>>> I think you are mixing authentication and API access here. =
Depending on application scenario it makes a lot of sense to use OIDC - =
but rely on the resulting session to control API access.=20
>>>>> Unless you want to dive into the details here, I suggest you =
remove the mention of OIDC because it is misleading.
>>>>>=20
>>>>>=20
>>>>> 6.2.  Apps Served from a Dynamic Application Server
>>>>>=20
>>>>> I have a .NET sample for that=20
>>>>>=20
>>>>> =
https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcor=
e21/BFF =

>>>>> And a blog post
>>>>> =
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wi=
th-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ =

>>>>>=20
>>>>> 9.7 =
. Content-Security Policy
>>>>> A browser-based application that wishes to use either long-lived
>>>>>    refresh tokens or privileged scopes SHOULD restrict its =
JavaScript
>>>>>    execution to a set of statically hosted scripts via a Content
>>>>>    Security Policy ([CSP2 =
]) or similar mechanism.
>>>>>=20
>>>>>=20
>>>>> I would rather say that ANY JS app should use CSP to lock down the =
browser features to a minimal attack surface. In addition, if refresh or =
access tokens are involved - further settings like disabling inline =
scripting (unsafe inline) and eval should be disabled.
>>>>>=20
>>>>> Thanks for doing this work!
>>>>>=20
>>>>> =E2=80=94=E2=80=94=E2=80=94
>>>>> Dominick
>>>> _______________________________________________
>>>> 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=_0EBCC58E-0223-496B-8DF6-0C7C878526CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Not =
sure I follow - the current OAuth security topics BCP allows for using =
either state or PKCE for detecting CSRF (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13=
#section-4.7.1), with some caveats for when state is preferred.

I think I prefer the =
current wording in the browser-based draft, which provides a much =
clearer unambiguous recommendation.

-- Neil

On 23 Jul 2019, at 09:31, Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes it would.

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

On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com) =
wrote:
Wouldn=E2=80=99t that contradict the =
security topics BCP?

Odesl=C3=A1no z iPhonu

23. 7. 2019 v 9:44, Neil Madden <neil.madden@forgerock.com>:

Technically it could be optional, but it means that a CSRF =
attempt will only be detected by the AS not by the client. If we =
consider the possibility of a malicious AS, then this could allow Login =
CSRF attacks against the client. The client would also have to be sure =
that the AS actually implements PKCE. So I think it=E2=80=99s safer to =
leave the recommendation as-is. 
On 23 Jul 2019, at 08:28, Dominick Baier <dbaier@leastprivilege.com> wrote:

Forgot one more thing

In =
7.1

Browser-based apps =
MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site =
Request Forgery and
  =
 authorization code swap attacks and MUST use a unique value for =
each
  =
 authorization request, and MUST verify the returned state in =
the
  =
 authorization response matches the original state the app =
created.

Isn=E2=80=99t =
state optional when PKCE is used?

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

On =
22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) wrote:
Hey, 

Just read the spec - good =
to see the progress. Some feedback:

I am yet undecided if I =
like the categorisation of the =E2=80=9CApplication Architecture =
Patterns=E2=80=9D. I definitely want to distinguish between applications =
only accessing same-site back-end services and =E2=80=9Cothers=E2=80=9D. =
Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic =
application server=E2=80=9D should be handled differently - they are =
deployment details and should not decide on the application security =
architecture. Also not sure how realistic it is to deploy a typical =
applications solely from e.g. a CDN. But I don=E2=80=99t have the right =
answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource =
Server

> OAuth and OpenID Connect provide very =
little benefit in this
   deployment scenario, so it is =
recommended to reconsider whether you
   need OAuth or OpenID =
Connect at all in this case.

I think you are =
mixing authentication and API access here. Depending on application =
scenario it makes a lot of sense to use OIDC - but rely on the resulting =
session to control API access. 
Unless you want to dive into the =
details here, I suggest you remove the mention of OIDC because it is =
misleading.


6.2.  Apps =
Served from a Dynamic Application Server

I have a .NET sample =
for that 

And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-sec=
ure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7. Content-Security Policy
A browser-based application that wishes to use either =
long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.


I would rather say that ANY =
JS app should use CSP to lock down the browser features to a minimal =
attack surface. In addition, if refresh or access tokens are involved - =
further settings like disabling inline scripting (unsafe inline) and =
eval should be disabled.

Thanks for doing this work!

=E2=80=94=E2=80=94=E2=80=94
Dominick
_______________________________________________
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=_0EBCC58E-0223-496B-8DF6-0C7C878526CB--


From nobody Tue Jul 23 03:10: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 DA61D12019F for ; Tue, 23 Jul 2019 03:10: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, 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 J7hj4xFqSB08 for ; Tue, 23 Jul 2019 03:10:17 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0462912018C for ; Tue, 23 Jul 2019 03:10:16 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id p17so42485480wrf.11 for ; Tue, 23 Jul 2019 03:10:16 -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=pkk1d9dhftwkPQgT1jXmfl15KNTiCZ3aW1nB0e4PaZ8=; b=VO4QFAPi1TlTFzqNsdSSPwn+oNRPXoolBpt/8KLL5N/7gmX5sL+SBKXDyOjdIXoj/X 2uxiQjEs8fppExpxNzcgibvEAKh4GWZOsj725Ip2PEl6bgNDYNtdrL/Dkndv+Mla2whN BZgRszZovSSmyfxMHpFlLw+CEKOra1otghrno=
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=pkk1d9dhftwkPQgT1jXmfl15KNTiCZ3aW1nB0e4PaZ8=; b=j5Bh0N5FteaMrEG28ewdG1ATui5/dM70kocdpVIcmk7p1180As5QJ38/Jp4DiV0P8d tMtM0xPnAHjfb0R9lWsovxHVXY5xqCoQDa0TpERS8JGVaK7Vv64uT4mnb0AJee6yk8p0 e4LyF3JE3ICpZovdDhQqFvU0u6PVSfYm205ufqTc676dsCdZkDUKcVxBQgFPFXZbZEXY V+MLce+K97ltcmvn3fSn0+x5BPUaNsuGJbxUF39Uw4f5DJ0MCQZQ1R1huqU6HR3d022v EQG73f1ym59MQpLRRRJwNT1sC2A2ty4bOpJZhHYvzXIcnVCcmo9aePPg1hmAvKXWGcPm o9GQ==
X-Gm-Message-State: APjAAAV67ZF7LjAuVMHIVFpB4uMCUdk6G4MJoxZn8lgi9p8G9J5WMK+Q +Wcdb2JV9LynjyjncK72pVHJew==
X-Google-Smtp-Source: APXvYqxAyys14vvY4+mZQ7BYZozRdzt1LbcSUPVT3ClncjA1jQAgt5G5onRmdSp+mUTQpFmORMFtyA==
X-Received: by 2002:adf:f046:: with SMTP id t6mr2808280wro.307.1563876615183;  Tue, 23 Jul 2019 03:10:15 -0700 (PDT)
Received: from [192.168.2.140] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id s25sm32171829wmc.21.2019.07.23.03.10.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 03:10:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Neil Madden 
In-Reply-To: 
Date: Tue, 23 Jul 2019 11:10:11 +0100
Cc: Aaron Parecki , oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F6A8E4E-3574-4666-A561-D67D5D0B2EA9@forgerock.com>
References:     <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> 
To: Dick Hardt 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 10:10:19 -0000

If we follow the principle of least authority then a token should be =
scoped as narrowly as possible to a particular resource =
server/resource/time period/transaction. The security topics BCP has =
already gone quite far down this path in its recommendations: =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.=
3 . Least privilege naturally leads to clients needing more tokens, so =
we should make obtaining (and using) multiple tokens as frictionless as =
possible.

For an example of this, see the work done by my colleagues to simplify =
juggling multiple access tokens for different resource servers - =
https://www.npmjs.com/package/appauthhelper . The library allows the =
developer to specify which scopes are used for which RS:

    resourceServers: {
        "https://login.example.com/oauth2/userinfo": "profile",
        "https://rs.example.com/": "rs_custom_scope"
    },

The library then takes care of making multiple requests to get =
appropriately-scoped access tokens and then attaching them to =
appropriate requests. But the more resource servers you need to access, =
the more tokens you need and the more requests you have to make. There =
is therefore currently a "tax" on least privilege use of access tokens =
as it is all on the client to juggle these requests, giving an incentive =
for clients to instead request Big Tokens that grant lots of authority =
in a single request/response.

-- Neil


> On 22 Jul 2019, at 22:46, Dick Hardt  wrote:
>=20
> Hi Neil
>=20
> I see that you are looking at how to modify Justin's proposal, and I'm =
looking at what are the requirements.
>=20
> Ignoring the specifics, is there a reason why multiple tokens need to =
be returned in the same request?
>=20
>=20
> On Mon, Jul 22, 2019 at 9:41 AM Neil Madden =
 wrote:
>=20
>> On 21 Jul 2019, at 22:22, Dick Hardt  wrote:
>>=20
>> Hi Neil, I agree that an access token that is usable across resources =
is problematic.
>>=20
>> How are you thinking multiple access tokens would be returned?
>=20
> Well there are lots of possible ways, e.g.:
>=20
> {
> "tokens": [
>     { "resource": "https://res1", "access_token": "..." },=20
>     { "resource": "res2", ...}, ...
> ]
> }
>=20
> I'm not particularly wedded to any format.
>=20
>> Why do you think the request needs to return multiple tokens rather =
than making a separate request for each token? That would seem to =
simplify the request and response as context would only need to provided =
for the one access token.
>=20
> Note that in Aaron's proposal we have a "user" section on (presumably) =
every access token response, which indicates a userinfo endpoint that =
itself needs an access token. So either the same access token is used to =
access that userinfo endpoint (which means that the RS can also access =
the userinfo endpoint), or else we already need to return a second =
access token in the same request, e.g.:
>=20
> {
>       "access_token": {
>         "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>         "type": "bearer"
>       },
>       "user": {
>         "id": "5035678642",
>         "userinfo": =
"https://authorization-server.com/user/5035678642",
>         "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
>       }
>     }


From nobody Tue Jul 23 04:19: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 2B8681201DC for ; Tue, 23 Jul 2019 04:19: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, 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=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 QvN6QNj_jCCH for ; Tue, 23 Jul 2019 04:19:27 -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 4F2791201D2 for ; Tue, 23 Jul 2019 04:19:27 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id j6so5816994ioa.5 for ; Tue, 23 Jul 2019 04:19:27 -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=PogWNJ1LBlI5qELoxk+KFULMO/k0xZYwzrVfGMQ55m0=; b=EZMN/jw0Mc/0Ykxw+U+IzjNfm4LgssBRvxIQmERrlIAW7EdFyu3MnqVlizwLs2mfxO +62opcJZORhmHDwGKE+2r0eK9kqs5AHwjbF4gqCWy4zz5uraWsT2fVGRCc5GP1Tx1WV8 MKcj/ZdtJM1fv+e9eHrbwtaBeBsB0jMUyBS+DFYhXPV2+qAA6g5arUXB9bZ7pymyasdH Lb9uA4RtVHONwV13cHrqGoK0bERkZqS5Mn+PoF/0lZyQld41i4XEBSI7dUsS6c0FYv1d 9/hTPGY3EHL4du48rj201/U2PVPZsSgZnxEIBYqFRZWw1uzTHCgA+M+fRn4CPMIYCfbw 206A==
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=PogWNJ1LBlI5qELoxk+KFULMO/k0xZYwzrVfGMQ55m0=; b=KVq84DUI08llPJKObRJ+wmt79c23yzeZk3VmVa+D3IISSb8PJdNvrdmn2Tbqh5cf5O p/3BteM36OQ8yGemBUd2HcLmwYJeKH5/xbfld55E3GZ8sCDmX48A3MnFwOzBiPTVM0my 8LFOHR+l69xGHiV0rOPYYxvSN2toLroW/F3rELzsTxG+feZAHruYnLq/poE6RzG41txn sbttO/rdT4NwH/w4jI4IFOdb0d1/PW7bVQ7qjUNyZP9pPwD24AwVxenednL6yIgqwEYv i7BvQ+mwOplSHsY2SK9RKTglLphhvPntbWX7/bErhqJE0bdqZim2z6FbwhnphOSVFXRx 9qMQ==
X-Gm-Message-State: APjAAAXLQ7tpq+b96GQlQWDHpcjg7oP+7oC8d3ktnK8UvFoWlpekQ9+5 gZP6PrfvVtLa8yUatzXqLMONlksx+TM=
X-Google-Smtp-Source: APXvYqyQHWVNVKUyJo2cNM9tRolbf+NogvO+c+Ealng7dH0GNz7D0H9d5dpz7B2oXo6DA789dYbLsA==
X-Received: by 2002:a02:ac09:: with SMTP id a9mr82083975jao.48.1563880766457;  Tue, 23 Jul 2019 04:19:26 -0700 (PDT)
Received: from [172.16.137.148] ([207.115.96.130]) by smtp.gmail.com with ESMTPSA id n7sm32425280ioo.79.2019.07.23.04.19.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 04:19:25 -0700 (PDT)
To: oauth@ietf.org
References: 
From: Daniel Fett 
Message-ID: <095d6849-38c4-6f02-2a1a-4c16255c498c@yes.com>
Date: Tue, 23 Jul 2019 13:19:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------487F48423A88CFB15D843753"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 11:19:29 -0000

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

Thanks Brian, I committed a fix for this.

-Daniel

Am 22.07.19 um 20:36 schrieb Brian Campbell:
> The description of I-D.ietf-oauth-mtls in
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8.1.2
> 
> talks about binding to and checking against the fingerprint of the
> public key from the client certificate. However,
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a hash of
> the whole certificate rather than of just the public key.
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited..  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------487F48423A88CFB15D843753
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Brian, I committed a fix for
      this.

    


    

    
-Daniel

    

    


    

    
Am 22.07.19 um 20:36 schrieb Brian
      Campbell:

    

    

      
      

        
The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8.1.2
          talks about binding to and checking against the fingerprint of
          the public key from the client certificate. However, https://tools.ietf.org/html/draft-ietf-oauth-mtls-15
          uses a hash of the whole certificate rather than of just the
          public key. 

        

      

      

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

      

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


    

    


    

  


--------------487F48423A88CFB15D843753--


From nobody Tue Jul 23 05:00: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 85FF0120221 for ; Tue, 23 Jul 2019 05:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 wpk-g2AgruK8 for ; Tue, 23 Jul 2019 05:00:52 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70D120125 for ; Tue, 23 Jul 2019 05:00:52 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id n4so42956713wrs.3 for ; Tue, 23 Jul 2019 05:00:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=SvsKzQWZa/yEscdz4l9b9LWIuYWGmU8TGa5yfNM6kB4=; b=EaW+R+A1fe9TIhH5k3SOfv/DzbjSXzjjOAvI1xi0G/JIL2bvgrFb7x94MAAJ5FNtaf MLVhXuK8qta9jayldLboNK48aPYARD337UwCNwna0FC+JIY7900wPemFpjoV1P3vgSF6 t8U/KRJR+5mu7UZfbMEyWfm2gGjkYReCGjeQhKP07UHb5EfRdnC2Jqt1aevKGdiXja5e qgm5gdfXkAeDnyDY31NoB2Z3+j/F1YXyzFVgoWLrySlFnGphNLSjNK3wWKXevT1n/UQE OvrmHS6xn3Gy1EGHSLmBi6EkVjr6PkMHKHtchgLhr11yBw5XQuDHaRM7uERjUEjBBGs7 KIeg==
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=SvsKzQWZa/yEscdz4l9b9LWIuYWGmU8TGa5yfNM6kB4=; b=c/uDvCpyURtJz5gmUkF+HkxfBau/5YazFhcQLnf6rdr70LqSQnpv0bqJGXFx31uz6L AymAWQWOf8f9Ft2U5CofGqsw444zAXc4YrcxDqV+MNkFLTVqlu5r2Piw6jZb5FnBIjla IWwXQsSw++ZF93iZdOIcjYjBfCRZYXPSaLrZMcPvvRUi4pe7Qzirtg6rVz9MECrUoISy hxPMahfydUEc9Dov6w2WgGHS3oWD3I9xZPG8nKsaEZ4idAj1ooNHD1Rol4aJTizmjEWA wXxKx+KJpUy2cAe9XhccN2VZGPcDLLAIGTN6hFcjbx1qL0j1/WULLTgFNRSnfQq6wJVM GE4Q==
X-Gm-Message-State: APjAAAV2lqB81gFlClqGK6v+Qap70708gL0fJBg3zxbIcB4i4Fco91Q2 VsQww4ArMxSaWp9phv4RzKqklrOajgFqOtzfm/FWQgVIxmiZfA==
X-Google-Smtp-Source: APXvYqyxRSFLu3mJiMrk+SRnjubAM9oPbgFPi33fKJKOFYelkdLgoYZXFRf4VWXqVGiq+SBi1wWxeIQg3QEZr6ALEQ4=
X-Received: by 2002:adf:a341:: with SMTP id d1mr33215214wrb.260.1563883250084;  Tue, 23 Jul 2019 05:00:50 -0700 (PDT)
MIME-Version: 1.0
From: Nat Sakimura 
Date: Tue, 23 Jul 2019 08:00:40 -0400
Message-ID: 
To: oauth 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [OAUTH-WG] Implicit grant and sender constrained token/JPOP/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, 23 Jul 2019 12:00:55 -0000

A while ago, when implicit was almost entirely banned in the Security
BCP, I raised voice that the ban should be constrained and the text
was modified accordingly.

At the time, I probably did not express myself well enough so here is
a bit of explanation on what I was thinking about the sender
constraining the token.

1. Assumption: The client is a confidential client on a web server.
2. The Client registration is done either through the Developer portal
at the AuthZ server or through RFC7591 in which jwks_uri is given.
3. When the client asks for the access token through implicit grant,
the AS mints the client_id constrained access token or key constrained
access token as in [JPOP] draft and send it back to the client.
4. The client exercises the token against the resource as in [JPOP].

Client ID based JPOP access token works better when the client keys
are being refreshed quicker than the expiry of the access token.

In the case of DPOP, the key is being specified during the token
request, as I understand, so it does not work with implicit grant.

When it comes to using the token, the [JPOP] draft only signs over a
server created nonce (which can be tied to the URI and the method that
the client was trying to access) while [DPOP] signs over client
created nonce `jti` together with methods, uri, etc.

[JPOP] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05
[DPOP] https://tools.ietf.org/html/draft-fett-oauth-dpop-02

my 2c.

Cheers,

Nat Sakimura

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


From nobody Tue Jul 23 06:45: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 B7130120298 for ; Tue, 23 Jul 2019 06:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMVhTZNSpnWO for ; Tue, 23 Jul 2019 06:45:34 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801D01202B3 for ; Tue, 23 Jul 2019 06:45:34 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k8so81950048iot.1 for ; Tue, 23 Jul 2019 06:45:34 -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=6vp6fOOkCFIILZY3oFlfKSlyxa3b+u7GYJw9GUa8Ba8=; b=LAziYnk/FH3lhp8vnBRGCcC3WGncWB7ZVOa3U/6FAqtLLCIuLKPCO48DlloH+iTqiJ 1hwm1pZc4V9vTgv1BzJT1NfSTwBq4/U1o0HomQU5vlVgl9QIklLcJZqOTGOFh91/f3s2 4QQL+0xw30W8CRP4Ix6Eqwr/vKu1EFzPX7vEU=
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=6vp6fOOkCFIILZY3oFlfKSlyxa3b+u7GYJw9GUa8Ba8=; b=gIo0MO6fOijo9sHeJ0foJuxTwLhrleORFdxQNu8YTa272zAnAAMU36nMlHtN0mpBoR /wCDXJvZxQqmDIpokT5YFS7zu+EBi6lDJWSTZWEnuMjLNow1+muvyZ0+sBV6p0SgCBLe EbL4RAyDGIyrMhrvCLIAL6lsn7ImSutN7TPLtajjmM4vu7b0HubSuNdHqgZwNTK4hPKV uMl4Zl3fowlUy6Dizv0YErRfSY02PdWfn5IPLyqckUQn3LGDMF/j73Pf5MTOa4DHN55f CK2Elf7yJU1brCJz5TXKI3pIZP60lu4FVrnAEc7g0vLVj3IoH0lQl29yhxoaFVuhyTvj T02Q==
X-Gm-Message-State: APjAAAUblXRIy4f6KCLcPQYe+Fvct8k8I07WDPqQKzkDoU4/aGB3Jo9R XU4e9Pnsry7sySQScpOgARlE1+YCUA7RDow9U5TCm9pDlgwj6YX964972zua3bR6gK0o+TQegmY bLb9pr0X4Xep/iQ==
X-Google-Smtp-Source: APXvYqzmXRO/Tq1QakMZJ+uFeoDivH2eGjb5wyxipCwtjkrr36S2PT2BY8Y4WcHnCwvQe3SHGlc0KWZD3E5okpgMiPY=
X-Received: by 2002:a6b:621a:: with SMTP id f26mr63156855iog.127.1563889533676;  Tue, 23 Jul 2019 06:45:33 -0700 (PDT)
MIME-Version: 1.0
References:  <095d6849-38c4-6f02-2a1a-4c16255c498c@yes.com>
In-Reply-To: <095d6849-38c4-6f02-2a1a-4c16255c498c@yes.com>
From: Brian Campbell 
Date: Tue, 23 Jul 2019 07:45:07 -0600
Message-ID: 
To: Daniel Fett 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000001f9033058e5968c1"
Archived-At: 
Subject: Re: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 13:45:48 -0000

--0000000000001f9033058e5968c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One more thing I just noticed is that RFC8418 is used as a reference in a
few places that I suspect should be RFC8414.

https://tools.ietf.org/html/rfc8418 : Use of the Elliptic Curve
Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)

https://tools.ietf.org/html/rfc8414 : OAuth 2.0 Authorization Server
Metadata


On Tue, Jul 23, 2019 at 5:19 AM Daniel Fett  wrote:

> Thanks Brian, I committed a fix for this.
>
> -Daniel
>
> Am 22.07.19 um 20:36 schrieb Brian Campbell:
>
> The description of I-D.ietf-oauth-mtls in
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4=
.8.1.2
> 
> talks about binding to and checking against the fingerprint of the public
> key from the client certificate. However,
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a hash of the
> whole certificate rather than of just the public key.
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing 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._

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


One more thing I just noticed is that RFC8418 is used=
 as a reference in a few places that I suspect should be RFC8414.

https://tools.ietf.org/html/rfc8418 : Use of the Elliptic Curve =
Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptogr=
aphic Message Syntax (CMS)

https://tools.ietf.org/html/rfc8=
414 : OAuth 2.0 Authorization Server Metadata


On Tue, Jul 23, =
2019 at 5:19 AM Daniel Fett <danielf+oauth@yes.com> wrote:

 =20
   =20
 =20
  

    
Thanks Brian, I committed a fix for
      this.

    


    

    
-Daniel

    

    


    

    
Am 22.07.19 um 20:36 schrieb Brian
      Campbell:

    

    

     =20
      

        
The description of I-D.ietf-oauth-mtls in https://tools.ietf.org/html/draft-ietf-oauth-security-topic=
s-13#section-4.8.1.2
          talks about binding to and checking against the fingerprint of
          the public key from the client certificate. However, http=
s://tools.ietf.org/html/draft-ietf-oauth-mtls-15
          uses a hash of the whole certificate rather than of just the
          public key. 

        

      

      

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

      

      
_______________________________________________
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.
--0000000000001f9033058e5968c1--


From nobody Tue Jul 23 11:48:37 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0EB120860 for ; Tue, 23 Jul 2019 11:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP8VzkR51zT8 for ; Tue, 23 Jul 2019 11:48:22 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2334E120850 for ; Tue, 23 Jul 2019 11:48:22 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id e20so53705827iob.9 for ; Tue, 23 Jul 2019 11:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FCpZTRamuSte1A0NKJ4MCKzmuvj5VeewlgVL4eJVD8M=; b=Sqccc4QmlpK+KlQYoSCiAx5gt+LvI47SMlAUSnCgtGjmI79oFf+Q+doMuKobJjbX5V pUjsy+yRPc7et9VtskvSQk/oyB1ebZz975GHutoismsB2Qk3ju3gjlhPtg2JWQbkchDg Fi2PNnZpGgjbgmTEbMhMEOdcRR8u7es9UjYyA=
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=FCpZTRamuSte1A0NKJ4MCKzmuvj5VeewlgVL4eJVD8M=; b=kFUDb1AgOJU8zIxhmYSQebGfQaLNxWAifHTvQ0IY9CJuoP/SzVQ2ti4xdUQ921EC6l 509mRkMAPYhfw8ujU0/ZgATZk9BAB+wfLIsVbwuC8o4Oftm1PI6JZ2qgllSC8pyyAomP pntVe3jst5eyazDyVEid0DdQ2DLSjTQPLbCfBccan5NX6xMF+eBeMFmnP/g81rLBFW3V EDpS/0qBhkMoCPGz9sqEXI12pROjBFpSWJ4XPRVJDuhp+fTftYPzhyNFh9ne2M+ELLQ5 SH/q1y/RKTnKM+Zs62g9PYzrKbR4dWcvf2N7By2PIvbOJdCFbfe/9TOxBJtze8q7l2IM 2wbA==
X-Gm-Message-State: APjAAAX3MTiMYemNNEy8rzFtjkv8YGr+2w0HLLN8xJ2Dp+gh+JupS5so qIqQnJAJDuMnMt7ZcSCOJA371GWhGaKhuBk3CTNQgigOnmfmLS/lZW8WJx+Hx8YMsi1SCPRE/YF u73uIpnVEb7KaNOjiW58V8A==
X-Google-Smtp-Source: APXvYqwLOssCAtvuN/OJM3xRumFlHf7WLnz3v6w80RyeC3D6Yqk+G0C0ICFpDTQZ4SXBZk3l2mAG6BYSzIEjbl5daMY=
X-Received: by 2002:a02:a07:: with SMTP id 7mr81896607jaw.65.1563907701224; Tue, 23 Jul 2019 11:48:21 -0700 (PDT)
MIME-Version: 1.0
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>
In-Reply-To: <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>
From: Brian Campbell 
Date: Tue, 23 Jul 2019 12:47:54 -0600
Message-ID: 
To: Torsten Lodderstedt 
Cc: Aaron Parecki , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000fe5205058e5da2ae"
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jul 2019 18:48:35 -0000

--000000000000fe5205058e5da2ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt 
wrote:

>
> 2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potentia=
l
> architecture. I don=E2=80=99t think we should get into the business of re=
commending
> and assessing other solutions (e.g. section 6.1.). Just to give you an
> example: Section 6.1. states
>
> "OAuth and OpenID Connect provide very little benefit in this deployment
> scenario, so it is recommended to reconsider whether you need OAuth or
> OpenID Connect at all in this case.=E2=80=9D
>
> Really? What experiences is this statement based on? In my experience,
> sharing the same domain =3D=3D host name tells you nothing about the over=
all
> architecture of a certain deployment. There may be several reasons why
> OAuth could be good choice in such a scenario, e.g. security consideratio=
ns
> (since your common domain is just a proxy server encapsulating a whole
> universe of systems) or even modularity as an architecture principle.
>
> I suggest to remove section c. and to rephrase the second paragraph of th=
e
> abstract.
>

I believe the experiences that the statement is based on are the
predominant practice over the course of much of the history of the web of
using a cookie to maintain an authenticated HTTP session in web
applications. When the script of the browser-based application is served
from a domain that can share cookies with the domain of the API, then
cookies can still be used to authorize requests (even if those requests are
API calls rather than full page HTTP request/response). And I do believe
that's likely a better decision in a lot of such cases.

That authenticated HTTP session may be establish from a username/password
form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID
Connect flow. Or even SAML for that matter. But the the requests after that
are authorized by the cookie.

I think there's a tendency to assume because SPA style apps make API calls,
they simply must use OAuth. Because API implies OAuth in the minds of many
(which is a sign of its success). But OAuth isn't necessarily the only
thing that can be used for API authorization. Cookies work too. I
think/hope that's what Section 6.1. is getting at - providing some
potential guidance that OAuth might not necessarily be the right choice in
those cases where a common domain allows for a cookie. Perhaps the text in
that section could be phased in a different or better way, but I think its
useful to have some mention of in this document.

Although taking out "and OpenID Connect" from the sentence quoted above
might be more appropriate and alleviate some confusion.

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

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




=

On Mon, Jul 22, 2019 at 7:31 AM Torst=
en Lodderstedt <torsten@lodde=
rstedt.net> wrote:


2) Regarding architectures: I think this BCP should focus on recommendation=
s for securely implementing OAuth in the different potential architecture. =
I don=E2=80=99t think we should get into the business of recommending and a=
ssessing other solutions (e.g. section 6.1.). Just to give you an example: =
Section 6.1. states 



"OAuth and OpenID Connect provide very little benefit in this deployme=
nt scenario, so it is recommended to reconsider whether you need OAuth or O=
penID Connect at all in this case.=E2=80=9D



Really? What experiences is this statement based on? In my experience, shar=
ing the same domain =3D=3D host name tells you nothing about the overall ar=
chitecture of a certain deployment. There may be several reasons why OAuth =
could be good choice in such a scenario, e.g. security considerations (sinc=
e your common domain is just a proxy server encapsulating a whole universe =
of systems) or even modularity as an architecture principle. 



I suggest to remove section c. and to rephrase the second paragraph of the =
abstract.

I believe the experiences tha=
t the statement is based on are the predominant practice over the course of=
 much of the history of the web of using a cookie to maintain an authentica=
ted HTTP session in web applications. When the script of the browser-based =
application is served from a domain that can share cookies with the domain =
of the API, then cookies can still be used to authorize requests (even if t=
hose requests are API calls rather than full page HTTP request/response). A=
nd I do believe that's likely a better decision in a lot of such cases.=
 

That authenticated HTTP session may be estab=
lish from a username/password form submission, FIDO/WebAuthn, or whatever.=
=C2=A0 Even as a result of an OpenID Connect flow. Or even SAML for that ma=
tter. But the the requests after that are authorized by the cookie. 

I think there's a tendency to assume because SPA=
 style apps make API calls, they simply must use OAuth. Because API implies=
 OAuth in the minds of many (which is a sign of its success). But OAuth isn=
't necessarily the only thing that can be used for API authorization. C=
ookies work too. I think/hope that's what Section 6.1. is getting at - =
providing some potential guidance that OAuth might not necessarily be the r=
ight choice in those cases where a common domain allows for a cookie. Perha=
ps the text in that section could be phased in a different or better way, b=
ut I think its useful to have some mention of in this document. 
<=
div>
Although taking out "and OpenID Connect" from =
the sentence quoted above might be more appropriate and alleviate some conf=
usion. 








<=
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.
--000000000000fe5205058e5da2ae--


From nobody Tue Jul 23 14:02:38 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 45C48120159; Tue, 23 Jul 2019 14:02:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <156391575723.27846.15582344803601946055@ietfa.amsl.com>
Date: Tue, 23 Jul 2019 14:02:37 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-05.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, 23 Jul 2019 21:02:37 -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-05.txt
	Pages           : 17
	Date            : 2019-07-23

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-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-05


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

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


From nobody Tue Jul 23 14:06: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 365381209B9 for ; Tue, 23 Jul 2019 14:06:14 -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 ea82XN302tWz for ; Tue, 23 Jul 2019 14:06:10 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) (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 5CC8C1209B2 for ; Tue, 23 Jul 2019 14:06:09 -0700 (PDT)
Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hq1z3-0002WE-41; Tue, 23 Jul 2019 23:06:05 +0200
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_98F76ADD-84A0-418D-85E0-31450F99FCFB"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 23:06:04 +0200
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand>
Cc: "oauth@ietf.org" , Vladimir Dzhuvinov 
To: Roman Danyliw 
References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand>
X-Mailer: Apple Mail (2.3445.104.11)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 21:06:23 -0000

--Apple-Mail=_98F76ADD-84A0-418D-85E0-31450F99FCFB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Roman,=20

the latest revision -05 should address all points you raised.

=
https://www.ietf.org/id/draft-ietf-oauth-jwt-introspection-response-05.txt=


kind regards,=20
Torsten.=20

> On 23. Jul 2019, at 02:56, Roman Danyliw  wrote:
>=20
> Hi Torsten!
>=20
> Separately from the below, idnits is troubled by the lack of an =
RFC2119 section and the presence or absence of some reference despite =
citation:
>=20
> =3D=3D[ snip ]=3D=3D
>=20
> Miscellaneous warnings:
>  =
--------------------------------------------------------------------------=
--
>=20
>  =3D=3D The document seems to lack the recommended RFC 2119 =
boilerplate, even if
>     it appears to use RFC 2119 keywords.=20
>=20
>     (The document does seem to have the reference to RFC 2119 which =
the
>     ID-Checklist requires).
>=20
>  Checking references for intended status: Proposed Standard
>  =
--------------------------------------------------------------------------=
--
>=20
>     (See RFCs 3967 and 4897 for information about using normative =
references
>     to lower-maturity documents in RFCs)
>=20
>  =3D=3D Missing Reference: 'RFC5322' is mentioned on line 471, but not =
defined
>=20
>  =3D=3D Missing Reference: 'RFC3966' is mentioned on line 537, but not =
defined
>=20
>  =3D=3D Missing Reference: 'RFC4627' is mentioned on line 562, but not =
defined
>=20
>  ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7159)
>=20
>  =3D=3D Unused Reference: 'RFC2119' is defined on line 606, but no =
explicit
>     reference was found in the text
>=20
>  =3D=3D Unused Reference: 'RFC2246' is defined on line 611, but no =
explicit
>     reference was found in the text
>=20
>  =3D=3D Outdated reference: A later version (-06) exists of
>     draft-ietf-oauth-jwt-bcp-04
>=20
>  =3D=3D Outdated reference: A later version (-13) exists of
>     draft-ietf-oauth-security-topics-11
>=20
>  ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
> =3D=3D[ snip ]=3D=3D
>=20
> Roman
>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Roman =
Danyliw
>> Sent: Monday, July 22, 2019 8:51 PM
>> To: Torsten Lodderstedt 
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD Review: =
draft-ietf-oauth-jwt-introspection-
>> response-03
>>=20
>> Hi Torsten!
>>=20
>>> -----Original Message-----
>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>>> Sent: Monday, July 22, 2019 6:59 AM
>>> To: Roman Danyliw 
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD Review: =
draft-ietf-oauth-jwt-introspection-
>>> response-03
>>>=20
>>> Hi Roman,
>>>=20
>>> thanks a lot for your review feedback.
>>>=20
>>> I just published a new revision of the draft incorporating changes
>>> based on your comments.
>>>=20
>>> =
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-respons
>>> e-04
>>=20
>> Thanks for the update. I have one refinement below based on the new
>> language around TLS.  Details are inline ...
>>=20
>>>> On 17. Jul 2019, at 18:17, Roman Danyliw  wrote:
>>>>=20
>>>> Hi!
>>>>=20
>>>> The following is my AD review of =
draft-ietf-oauth-jwt-introspection-
>>> response-03.
>>>>=20
>>>> (1) Section 4.  Per introspection_encrypted_response_alg, how is
>>>> either
>>> signing or encryption being requested?  Is it by also including an
>>> introspection_signed_response_alg?  If that's the case, it is worth
>>> explicitly saying.
>>>=20
>>> The response is always signed. The resource server may decide to
>>> additionally turn on encryption.
>>>=20
>>> Section 3 states =E2=80=9CDepending on the specific resource server =
policy the
>>> JWT is either signed, or signed and encrypted. =E2=80=9C
>>=20
>> With the new language you added for item #2, I now understand.  =
Thanks for
>> clearing it up.
>>=20
>>>> (2) Section 4.  Per introspection_encrypted_response_enc, I'm =
having
>>> trouble deconflicting these two sentences:
>>>>=20
>>>> [1] If "introspection_encrypted_response_alg" is specified, the
>>>> default for
>>> this value is A128CBC-HS256.
>>>>=20
>>>> [2] When "introspection_encrypted_response_enc" is included,
>>> "introspection_encrypted_response_alg" MUST also be provided
>>>>=20
>>>> Sentence [2] explicitly states that
>> "introspection_encrypted_response_alg"
>>> is required.  However, the first sentence seems more tentative by
>>> saying that "if introspection_encrypted_response_enc" is present.
>>>=20
>>> introspection_encrypted_response_enc is optional but must not be
>>> specified without introspection_encrypted_response_alg
>>>=20
>>> I changed the text to better get this across:
>>>=20
>>> introspection_encrypted_response_alg
>>> OPTIONAL. JWE algorithm (alg value) as defined in JWA for encrypting
>>> introspection responses. If this is specified, the response will be
>>> encrypted using JWE and the configured algorithm. The default, if
>>> omitted, is that no encryption is performed. If both signing and
>>> encryption are requested, the response will be signed then =
encrypted,
>>> with the result being a Nested JWT, as defined in JWT.
>>>=20
>>> introspection_encrypted_response_enc
>>> OPTIONAL. JWE algorithm (enc value) as defined in JWA for
>>> authenticated encryption of introspection responses. The default, if
>>> omitted, is A128CBC- HS256. Note: This parameter MUST NOT be =
specified
>>> without setting introspection_encrypted_response_alg.
>>=20
>> Thanks for this new text.  It is clearer.
>>=20
>>=20
>>>>=20
>>>> (3) I want to talk through the personally identifiable information
>>>> being
>>> specified as new introspection fields per Section 8.3 (e.g., name,
>>> birthday) being exposed.  I was looking to ensure that it would =
always
>>> be encrypted in transit (and that only authorized clients could get
>>> it).  I read that in Section 3, "[d]epending on the specific =
resource
>>> server policy the JWT is either signed, or signed and encrypted" and
>>> that per Section 4 that "[t]he authorization server determines what
>>> algorithm to employ to secure the JWT for a particular introspection
>>> response."  Section 6.2 explicitly notes the threat of token data
>>> leakage (a more general case of my concern so thanks for that text).
>>> [RFC7662], Section 4 notes only that "the server MUST support
>>> Transport Layer Security (TLS) 1.2", but "support" is different than
>>> "the server MUST _use_ TLS". Therefore, it seems like there could be =
a
>>> case where the server could return an introspection response in the
>>> clear (e.g., no TLS, introspection_sig
>>>> ned_response_alg).  Am I missing something?
>>>>=20
>>>> My bias is to say something on the order of "TLS MUST be used=E2=80=9D=
.
>>>=20
>>> Section 6.2. now starts with =E2=80=9CThe authorization server MUST =
use
>>> Transport Layer Security (TLS) 1.2 (or higher) in order to prevent =
token data
>> leakage."
>>=20
>> Works for me to was use TLS.  I'd recommend a statement that provides
>> more guidance "The authorization server MUST use Transport Layer =
Security
>> (TLS) 1.2 (or higher) per RFC7525 in order to prevent token data =
leakage."
>>=20
>>>> (4) I also want to talk through an unscrupulous protected resource
>>>> trying to
>>> harvest introspection meta-data.  I was looking for guidance related
>>> to the authorization of the introspection transactions.  I found:
>>>>=20
>>>> Section 2.2 of [RFC7662] says important things like "For instance,
>>>> an
>>> authorization server MAY limit which scopes from a given token are
>>> returned for each protected resource to prevent a protected resource
>>> from learning more about the larger network than is necessary for =
its
>> operation."
>>>>=20
>>>> Section 4 of [RFC7662] says "If left unprotected and un-throttled,
>>>> the
>>> introspection endpoint could present a means for an attacker to poll =
a
>>> series of possible token values, fishing for a valid token.  To
>>> prevent this, the authorization server MUST require authentication =
of
>>> protected resources that need to access the introspection endpoint =
and
>>> SHOULD require protected resources to be specifically authorized to
>>> call the  introspection endpoint."
>>>>=20
>>>> Section 6.2 of this draft provides guidance on defending against
>>> unauthenticated clients.
>>>>=20
>>>> How does the authorization server restrict a protected resource =
that
>>>> _can_
>>> authenticate to it from getting meta-data is shouldn't have access =
to?
>>> Something on the order of "the authorization server >> following
>>> data> to determine what a given protected resource is allowed to =
see=E2=80=9D.
>>>=20
>>> I added Section 6.3, which states =E2=80=9CThe authorisation server =
determines
>>> the token data a resource server is allowed to see based on the
>>> resource server=E2=80=99s client_id and suitable token data, e.g. =
the scope value."
>>=20
>> Great. Thanks for the clarity.
>>=20
>>>>=20
>>>> (5) Editorial Nits
>>>>=20
>>>> ** Section 3.  Per "This JWT MAY furthermore contain all other
>>>> claims
>>> described in Section 2.2. of [RFC7662] and beyond (e.g. as defined =
in
>>> [OpenID.Core])", would it be more timeless to say the fields =
specified
>>> in "OAuth Token Introspection Response" registry?
>>>>=20
>>>=20
>>> This text pre-dated the addition of the IANA registry section. =
Thanks
>>> for spotting the inconsistency.
>>>=20
>>> I modified the text as you suggested.
>>>=20
>>>> ** Section 4.  The first sentence of each parameters descriptions
>>>> don't
>>> parse -- for example with introspection_signed_response_alg: "JWS
>>> [RFC7515] 'alg' algorithm JWA [RFC7518] REQUIRED", fully expanded
>>> that's "JSON Web Signature (JWS) [RFC7515] "alg" algorithm JSON Web
>>> Algorithms
>>> (JWA) [RFC7518] REQUIRED ...".  The same is true for the write-ups =
in
>>> Section 5.
>>>=20
>>> modfied text
>>>=20
>>>>=20
>>>> ** Section 4.  Editorial.  Per =
"introspection_encrypted_response_enc":
>>>> s/REQUIRED for encrypting introspection responses/ REQUIRED for
>>>> authenticated encryption of introspection responses/
>>>>=20
>>>=20
>>> done
>>=20
>> Thanks for all of the above.
>>=20
>> Regards,
>> Roman
>>=20
>>> kind regards,
>>> Torsten.
>>>=20
>>>=20
>>>> Regards,
>>>> Roman
>>>>=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=_98F76ADD-84A0-418D-85E0-31450F99FCFB
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
Fw0xOTA3MjMyMTA2MDRaMC8GCSqGSIb3DQEJBDEiBCAVcRtvFt3+Smsjhma/SMLK2ZjWoZwPQKM2
QX18NWSjIDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBAIJb7gFra4TDRpOxLmIBNwHpVT8xL86Ukpjr5kTSlguzbThQ8Y+IkWa+AdBW
+N3OXcXTbw3OYigT3rgPUYJVZ5ZzCB5UnRmz09ZWwGa4q4dxbSslT5vF16IGLpofnwJaS6DI6tC0
5pYCacNBl8bnSZctR68BF7NpomD52nmBMcjJm50MPcJztBAC2rLFg2tFAifgz1ZjdV24OtXnQCc1
V60tBk0GrseUQIcxSE+5otP7Vk2h7n1HA+xMfDjlQh2f7Igq50GkL26pGVHmVZvUlDE9/Agb5PUv
omZbm0V8Pgeb/TCqccRSPn9JMieTCNWblPOq4N/V6HHMAela+5h9kbAAAAAAAAA=
--Apple-Mail=_98F76ADD-84A0-418D-85E0-31450F99FCFB--


From nobody Tue Jul 23 14:33:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936F01209D0 for ; Tue, 23 Jul 2019 14:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 t5kXrtU7aY8Y for ; Tue, 23 Jul 2019 14:33:10 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57DB120956 for ; Tue, 23 Jul 2019 14:33:10 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id e20so54682193iob.9 for ; Tue, 23 Jul 2019 14:33:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=FToaN9LYe4JdBDk3MOFziKXXQaBTDjGv7LwH3HQYiOM=; b=dr8YzC/z2oXMSp6ztxo+PKTnhPnrC1jvCjvKhmWFH4NbK9zoTvL6cINgfx/klWu4Fh 8G4XJiODzqgjO9GKcUTMS9tr372uAASIctxSQPiw74a8yePviluq4IoWUP2eOFrN7MAM kdzUTHErAjyjKneN3Q9PfpCyDA6vCDFSiAOYYWuCmRPT+KNU1rUwhB2sBv9i160b7e59 JlZk5qHctKa57W9IUtxgo108MGZ9n/vNMIvOLIzTwC1JXNTx/PNh9Dky92jXOG7hqWjb jAsdH56q+65qOTyDvJTa19xFr2DjbiAxiz8oTu57NWL3afC5dfRXHXneAeIs7zNCj1c0 samA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=FToaN9LYe4JdBDk3MOFziKXXQaBTDjGv7LwH3HQYiOM=; b=LzKTHmLngOPxMnIVlw2g40AEGwxNA2tE0XOKv8YlO4WJUK5XEUmTwcxrQoW4XZcxVr 2bsjuCBf5ZXpVr5EawakPvXadLJGw/L6j0/3saOIbjXjBT8dItr9IjJ2sddctpLYA8Mm o2e7SXE14G+kfwqEfSyTiCv9wHJrrRZcM/VPL1/qKj18ck8HPXxEmUbCy5SCo1zVEEeQ gow0i5E+1He6Q1j7YnEgOxZ1eXxgmAu2+iytZBTu75RNXFY9hcw9zsB7UHGqdeaUaIVq bkZf276BIM3eckyjrjbLyMhrU7MEPFocEytfDCNFoVO2BiJqzPpi4q4q1Il9KKdmji+8 JWMg==
X-Gm-Message-State: APjAAAXRQ5P9MwhcUUz1n5hdh5EL4HR4zJz52usI1ivhO3a9DurduZp8 bFGGoKgA9JsdhLPwchBBaUSHUxBCF2w=
X-Google-Smtp-Source: APXvYqwpGeO/XA+Zw690CTe6PlFQAX7CxEAXBInirpyEIygIanUEVEGxsaP8UsB2OwItYuBSsG3voQ==
X-Received: by 2002:a5d:96cc:: with SMTP id r12mr56885518iol.99.1563917589855;  Tue, 23 Jul 2019 14:33:09 -0700 (PDT)
Received: from [172.16.137.148] ([207.115.96.130]) by smtp.gmail.com with ESMTPSA id j25sm57316655ioj.67.2019.07.23.14.33.09 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 14:33:09 -0700 (PDT)
To: oauth 
From: Daniel Fett 
Message-ID: 
Date: Tue, 23 Jul 2019 23:33:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1A8EB9D0464AD04C07651B7A"
Content-Language: de-DE
Archived-At: 
Subject: [OAUTH-WG] IETF105 Side meeting: PKCE Chosen Challenge attack and potential mitigations
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 21:33:22 -0000

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

Hi all,

Since there was interest to discuss the PKCE Chosen Challenge attack and
potential mitigations like IVAR in more detail, I reserved the room
*"Centre Ville" at 8:30 am on Thursday* for a side meeting on this topic.

Slides describing the attack:
https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-oauth-security-topics-00

IVAR draft: https://datatracker.ietf.org/doc/draft-fett-oauth-ivar/

Hope to see you there!

-Daniel


--------------1A8EB9D0464AD04C07651B7A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hi all,

    
Since there was interest to discuss the PKCE Chosen Challenge
      attack and potential mitigations like IVAR in more detail, I
      reserved the room "Centre Ville" at 8:30 am on Thursday
      for a side meeting on this topic.

    
Slides describing the attack:
https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-oauth-security-topics-00

    

    
IVAR draft: https://datatracker.ietf.org/doc/draft-fett-oauth-ivar/

    
Hope to see you there!

    
-Daniel

    

  


--------------1A8EB9D0464AD04C07651B7A--


From nobody Tue Jul 23 15:02: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 4C14F1209C6 for ; Tue, 23 Jul 2019 15:02:25 -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=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 lAKQcyOI6LcU for ; Tue, 23 Jul 2019 15:02:22 -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 039391209DD for ; Tue, 23 Jul 2019 15:02:21 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6NM2IUs003761; Tue, 23 Jul 2019 18:02:19 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6NM2IUs003761
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563919339; bh=vHpCcEIlqdHHutPJkzt0S1niMLAQHJzUNPRKtzqufd0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=L/jchqS8frnMCrMmrmWAhDax5n8R0seJCIER3GyOqS+0GODJWLMumN+Vn8FFxOfCI 5ral6DxkENxG1bBy0WZC1aHX0daA5Y8h1ELs2V4/DCd16lxNCiBtl1LzwXpTQslVG1 2f/rSq7zRRZIHhjJNlSO5SrvFQaXutA32q/fxiG0=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6NM2Hhi026503; Tue, 23 Jul 2019 18:02:17 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 18:02:16 -0400
From: Roman Danyliw 
To: Torsten Lodderstedt 
CC: "oauth@ietf.org" , Vladimir Dzhuvinov 
Thread-Topic: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
Thread-Index: AdU8um9EYRsZS/zUTimSMgl/pofXXQD431IAABQoH3AAAKFZMAAyuTQAAAaH8iA=
Date: Tue, 23 Jul 2019 22:02:16 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33E2C1D@marchand>
References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand> 
In-Reply-To: 
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 22:02:37 -0000

SGkgVG9yc3RlbiENCg0KVGhhbmsgeW91IGZvciB0aGlzIHVwZGF0ZS4gIEl0IGRvZXMgYWRkcmVz
cyBteSBrZXkgaXNzdWVzLg0KDQpXaXRoIHRoZSBJRVRGIExDIGZlZWRiYWNrIGNhbiB5b3UgcGxl
YXNlIGFkZHJlc3MgdGhpcyBpZG5pdCBpbnRyb2R1Y2VkIGluIHRoaXMgdXBkYXRlOg0KDQogICoq
IE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA3MTU5IChPYnNvbGV0ZWQgYnkgUkZD
IDgyNTkpDQoNClRoYW5rcywNClJvbWFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gRnJvbTogVG9yc3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu
bmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDIzLCAyMDE5IDU6MDYgUE0NCj4gVG86IFJvbWFu
IERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCj4gQ2M6IG9hdXRoQGlldGYub3JnOyBWbGFkaW1pciBE
emh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPg0KPiBTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tDQo+IHJl
c3BvbnNlLTAzDQo+IA0KPiBIaSBSb21hbiwNCj4gDQo+IHRoZSBsYXRlc3QgcmV2aXNpb24gLTA1
IHNob3VsZCBhZGRyZXNzIGFsbCBwb2ludHMgeW91IHJhaXNlZC4NCj4gDQo+IGh0dHBzOi8vd3d3
LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2Ut
MDUudHh0DQo+IA0KPiBraW5kIHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+IA0KPiA+IE9uIDIzLiBK
dWwgMjAxOSwgYXQgMDI6NTYsIFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4gd3JvdGU6DQo+
ID4NCj4gPiBIaSBUb3JzdGVuIQ0KPiA+DQo+ID4gU2VwYXJhdGVseSBmcm9tIHRoZSBiZWxvdywg
aWRuaXRzIGlzIHRyb3VibGVkIGJ5IHRoZSBsYWNrIG9mIGFuIFJGQzIxMTkNCj4gc2VjdGlvbiBh
bmQgdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2Ygc29tZSByZWZlcmVuY2UgZGVzcGl0ZSBjaXRh
dGlvbjoNCj4gPg0KPiA+ID09WyBzbmlwIF09PQ0KPiA+DQo+ID4gTWlzY2VsbGFuZW91cyB3YXJu
aW5nczoNCj4gPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gID09IFRoZSBkb2N1bWVu
dCBzZWVtcyB0byBsYWNrIHRoZSByZWNvbW1lbmRlZCBSRkMgMjExOSBib2lsZXJwbGF0ZSwNCj4g
ZXZlbiBpZg0KPiA+ICAgICBpdCBhcHBlYXJzIHRvIHVzZSBSRkMgMjExOSBrZXl3b3Jkcy4NCj4g
Pg0KPiA+ICAgICAoVGhlIGRvY3VtZW50IGRvZXMgc2VlbSB0byBoYXZlIHRoZSByZWZlcmVuY2Ug
dG8gUkZDIDIxMTkgd2hpY2ggdGhlDQo+ID4gICAgIElELUNoZWNrbGlzdCByZXF1aXJlcykuDQo+
ID4NCj4gPiAgQ2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3Nl
ZCBTdGFuZGFyZA0KPiA+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiAgICAgKFNlZSBS
RkNzIDM5NjcgYW5kIDQ4OTcgZm9yIGluZm9ybWF0aW9uIGFib3V0IHVzaW5nIG5vcm1hdGl2ZQ0K
PiByZWZlcmVuY2VzDQo+ID4gICAgIHRvIGxvd2VyLW1hdHVyaXR5IGRvY3VtZW50cyBpbiBSRkNz
KQ0KPiA+DQo+ID4gID09IE1pc3NpbmcgUmVmZXJlbmNlOiAnUkZDNTMyMicgaXMgbWVudGlvbmVk
IG9uIGxpbmUgNDcxLCBidXQgbm90IGRlZmluZWQNCj4gPg0KPiA+ICA9PSBNaXNzaW5nIFJlZmVy
ZW5jZTogJ1JGQzM5NjYnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDUzNywgYnV0IG5vdCBkZWZpbmVk
DQo+ID4NCj4gPiAgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkM0NjI3JyBpcyBtZW50aW9uZWQg
b24gbGluZSA1NjIsIGJ1dCBub3QgZGVmaW5lZA0KPiA+DQo+ID4gICoqIE9ic29sZXRlIHVuZGVm
aW5lZCByZWZlcmVuY2U6IFJGQyA0NjI3IChPYnNvbGV0ZWQgYnkgUkZDIDcxNTkpDQo+ID4NCj4g
PiAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzIxMTknIGlzIGRlZmluZWQgb24gbGluZSA2MDYs
IGJ1dCBubyBleHBsaWNpdA0KPiA+ICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0
DQo+ID4NCj4gPiAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzIyNDYnIGlzIGRlZmluZWQgb24g
bGluZSA2MTEsIGJ1dCBubyBleHBsaWNpdA0KPiA+ICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGlu
IHRoZSB0ZXh0DQo+ID4NCj4gPiAgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNp
b24gKC0wNikgZXhpc3RzIG9mDQo+ID4gICAgIGRyYWZ0LWlldGYtb2F1dGgtand0LWJjcC0wNA0K
PiA+DQo+ID4gID09IE91dGRhdGVkIHJlZmVyZW5jZTogQSBsYXRlciB2ZXJzaW9uICgtMTMpIGV4
aXN0cyBvZg0KPiA+ICAgICBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMQ0KPiA+
DQo+ID4gICoqIE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyAyMjQ2IChPYnNvbGV0
ZWQgYnkgUkZDIDQzNDYpDQo+ID4gPT1bIHNuaXAgXT09DQo+ID4NCj4gPiBSb21hbg0KPiA+DQo+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE9BdXRoIFttYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuDQo+IERhbnlsaXcNCj4g
Pj4gU2VudDogTW9uZGF5LCBKdWx5IDIyLCAyMDE5IDg6NTEgUE0NCj4gPj4gVG86IFRvcnN0ZW4g
TG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KPiA+PiBDYzogb2F1dGhAaWV0
Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3OiBkcmFmdC1pZXRm
LW9hdXRoLWp3dC1pbnRyb3NwZWN0aW9uLQ0KPiA+PiByZXNwb25zZS0wMw0KPiA+Pg0KPiA+PiBI
aSBUb3JzdGVuIQ0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+
IEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l
dF0NCj4gPj4+IFNlbnQ6IE1vbmRheSwgSnVseSAyMiwgMjAxOSA2OjU5IEFNDQo+ID4+PiBUbzog
Um9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KPiA+Pj4gQ2M6IG9hdXRoQGlldGYub3JnDQo+
ID4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgt
and0LWludHJvc3BlY3Rpb24tDQo+ID4+PiByZXNwb25zZS0wMw0KPiA+Pj4NCj4gPj4+IEhpIFJv
bWFuLA0KPiA+Pj4NCj4gPj4+IHRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgZmVlZGJhY2su
DQo+ID4+Pg0KPiA+Pj4gSSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJh
ZnQgaW5jb3Jwb3JhdGluZyBjaGFuZ2VzDQo+ID4+PiBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzLg0K
PiA+Pj4NCj4gPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo
LWp3dC1pbnRyb3NwZWN0aW9uLXJlc3BvbnMNCj4gPj4+IGUtMDQNCj4gPj4NCj4gPj4gVGhhbmtz
IGZvciB0aGUgdXBkYXRlLiBJIGhhdmUgb25lIHJlZmluZW1lbnQgYmVsb3cgYmFzZWQgb24gdGhl
IG5ldw0KPiA+PiBsYW5ndWFnZSBhcm91bmQgVExTLiAgRGV0YWlscyBhcmUgaW5saW5lIC4uLg0K
PiA+Pg0KPiA+Pj4+IE9uIDE3LiBKdWwgMjAxOSwgYXQgMTg6MTcsIFJvbWFuIERhbnlsaXcgPHJk
ZEBjZXJ0Lm9yZz4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBIaSENCj4gPj4+Pg0KPiA+Pj4+IFRo
ZSBmb2xsb3dpbmcgaXMgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtand0LWludHJv
c3BlY3Rpb24tDQo+ID4+PiByZXNwb25zZS0wMy4NCj4gPj4+Pg0KPiA+Pj4+ICgxKSBTZWN0aW9u
IDQuICBQZXIgaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfYWxnLCBob3cgaXMNCj4g
Pj4+PiBlaXRoZXINCj4gPj4+IHNpZ25pbmcgb3IgZW5jcnlwdGlvbiBiZWluZyByZXF1ZXN0ZWQ/
ICBJcyBpdCBieSBhbHNvIGluY2x1ZGluZyBhbg0KPiA+Pj4gaW50cm9zcGVjdGlvbl9zaWduZWRf
cmVzcG9uc2VfYWxnPyAgSWYgdGhhdCdzIHRoZSBjYXNlLCBpdCBpcyB3b3J0aA0KPiA+Pj4gZXhw
bGljaXRseSBzYXlpbmcuDQo+ID4+Pg0KPiA+Pj4gVGhlIHJlc3BvbnNlIGlzIGFsd2F5cyBzaWdu
ZWQuIFRoZSByZXNvdXJjZSBzZXJ2ZXIgbWF5IGRlY2lkZSB0bw0KPiA+Pj4gYWRkaXRpb25hbGx5
IHR1cm4gb24gZW5jcnlwdGlvbi4NCj4gPj4+DQo+ID4+PiBTZWN0aW9uIDMgc3RhdGVzIOKAnERl
cGVuZGluZyBvbiB0aGUgc3BlY2lmaWMgcmVzb3VyY2Ugc2VydmVyIHBvbGljeSB0aGUNCj4gPj4+
IEpXVCBpcyBlaXRoZXIgc2lnbmVkLCBvciBzaWduZWQgYW5kIGVuY3J5cHRlZC4g4oCcDQo+ID4+
DQo+ID4+IFdpdGggdGhlIG5ldyBsYW5ndWFnZSB5b3UgYWRkZWQgZm9yIGl0ZW0gIzIsIEkgbm93
IHVuZGVyc3RhbmQuICBUaGFua3MNCj4gZm9yDQo+ID4+IGNsZWFyaW5nIGl0IHVwLg0KPiA+Pg0K
PiA+Pj4+ICgyKSBTZWN0aW9uIDQuICBQZXIgaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9u
c2VfZW5jLCBJJ20gaGF2aW5nDQo+ID4+PiB0cm91YmxlIGRlY29uZmxpY3RpbmcgdGhlc2UgdHdv
IHNlbnRlbmNlczoNCj4gPj4+Pg0KPiA+Pj4+IFsxXSBJZiAiaW50cm9zcGVjdGlvbl9lbmNyeXB0
ZWRfcmVzcG9uc2VfYWxnIiBpcyBzcGVjaWZpZWQsIHRoZQ0KPiA+Pj4+IGRlZmF1bHQgZm9yDQo+
ID4+PiB0aGlzIHZhbHVlIGlzIEExMjhDQkMtSFMyNTYuDQo+ID4+Pj4NCj4gPj4+PiBbMl0gV2hl
biAiaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfZW5jIiBpcyBpbmNsdWRlZCwNCj4g
Pj4+ICJpbnRyb3NwZWN0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGciIE1VU1QgYWxzbyBiZSBw
cm92aWRlZA0KPiA+Pj4+DQo+ID4+Pj4gU2VudGVuY2UgWzJdIGV4cGxpY2l0bHkgc3RhdGVzIHRo
YXQNCj4gPj4gImludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZyINCj4gPj4+IGlz
IHJlcXVpcmVkLiAgSG93ZXZlciwgdGhlIGZpcnN0IHNlbnRlbmNlIHNlZW1zIG1vcmUgdGVudGF0
aXZlIGJ5DQo+ID4+PiBzYXlpbmcgdGhhdCAiaWYgaW50cm9zcGVjdGlvbl9lbmNyeXB0ZWRfcmVz
cG9uc2VfZW5jIiBpcyBwcmVzZW50Lg0KPiA+Pj4NCj4gPj4+IGludHJvc3BlY3Rpb25fZW5jcnlw
dGVkX3Jlc3BvbnNlX2VuYyBpcyBvcHRpb25hbCBidXQgbXVzdCBub3QgYmUNCj4gPj4+IHNwZWNp
ZmllZCB3aXRob3V0IGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZw0KPiA+Pj4N
Cj4gPj4+IEkgY2hhbmdlZCB0aGUgdGV4dCB0byBiZXR0ZXIgZ2V0IHRoaXMgYWNyb3NzOg0KPiA+
Pj4NCj4gPj4+IGludHJvc3BlY3Rpb25fZW5jcnlwdGVkX3Jlc3BvbnNlX2FsZw0KPiA+Pj4gT1BU
SU9OQUwuIEpXRSBhbGdvcml0aG0gKGFsZyB2YWx1ZSkgYXMgZGVmaW5lZCBpbiBKV0EgZm9yIGVu
Y3J5cHRpbmcNCj4gPj4+IGludHJvc3BlY3Rpb24gcmVzcG9uc2VzLiBJZiB0aGlzIGlzIHNwZWNp
ZmllZCwgdGhlIHJlc3BvbnNlIHdpbGwgYmUNCj4gPj4+IGVuY3J5cHRlZCB1c2luZyBKV0UgYW5k
IHRoZSBjb25maWd1cmVkIGFsZ29yaXRobS4gVGhlIGRlZmF1bHQsIGlmDQo+ID4+PiBvbWl0dGVk
LCBpcyB0aGF0IG5vIGVuY3J5cHRpb24gaXMgcGVyZm9ybWVkLiBJZiBib3RoIHNpZ25pbmcgYW5k
DQo+ID4+PiBlbmNyeXB0aW9uIGFyZSByZXF1ZXN0ZWQsIHRoZSByZXNwb25zZSB3aWxsIGJlIHNp
Z25lZCB0aGVuIGVuY3J5cHRlZCwNCj4gPj4+IHdpdGggdGhlIHJlc3VsdCBiZWluZyBhIE5lc3Rl
ZCBKV1QsIGFzIGRlZmluZWQgaW4gSldULg0KPiA+Pj4NCj4gPj4+IGludHJvc3BlY3Rpb25fZW5j
cnlwdGVkX3Jlc3BvbnNlX2VuYw0KPiA+Pj4gT1BUSU9OQUwuIEpXRSBhbGdvcml0aG0gKGVuYyB2
YWx1ZSkgYXMgZGVmaW5lZCBpbiBKV0EgZm9yDQo+ID4+PiBhdXRoZW50aWNhdGVkIGVuY3J5cHRp
b24gb2YgaW50cm9zcGVjdGlvbiByZXNwb25zZXMuIFRoZSBkZWZhdWx0LCBpZg0KPiA+Pj4gb21p
dHRlZCwgaXMgQTEyOENCQy0gSFMyNTYuIE5vdGU6IFRoaXMgcGFyYW1ldGVyIE1VU1QgTk9UIGJl
DQo+IHNwZWNpZmllZA0KPiA+Pj4gd2l0aG91dCBzZXR0aW5nIGludHJvc3BlY3Rpb25fZW5jcnlw
dGVkX3Jlc3BvbnNlX2FsZy4NCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB0aGlzIG5ldyB0ZXh0LiAg
SXQgaXMgY2xlYXJlci4NCj4gPj4NCj4gPj4NCj4gPj4+Pg0KPiA+Pj4+ICgzKSBJIHdhbnQgdG8g
dGFsayB0aHJvdWdoIHRoZSBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbg0KPiA+
Pj4+IGJlaW5nDQo+ID4+PiBzcGVjaWZpZWQgYXMgbmV3IGludHJvc3BlY3Rpb24gZmllbGRzIHBl
ciBTZWN0aW9uIDguMyAoZS5nLiwgbmFtZSwNCj4gPj4+IGJpcnRoZGF5KSBiZWluZyBleHBvc2Vk
LiAgSSB3YXMgbG9va2luZyB0byBlbnN1cmUgdGhhdCBpdCB3b3VsZCBhbHdheXMNCj4gPj4+IGJl
IGVuY3J5cHRlZCBpbiB0cmFuc2l0IChhbmQgdGhhdCBvbmx5IGF1dGhvcml6ZWQgY2xpZW50cyBj
b3VsZCBnZXQNCj4gPj4+IGl0KS4gIEkgcmVhZCB0aGF0IGluIFNlY3Rpb24gMywgIltkXWVwZW5k
aW5nIG9uIHRoZSBzcGVjaWZpYyByZXNvdXJjZQ0KPiA+Pj4gc2VydmVyIHBvbGljeSB0aGUgSldU
IGlzIGVpdGhlciBzaWduZWQsIG9yIHNpZ25lZCBhbmQgZW5jcnlwdGVkIiBhbmQNCj4gPj4+IHRo
YXQgcGVyIFNlY3Rpb24gNCB0aGF0ICJbdF1oZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZXRlcm1p
bmVzIHdoYXQNCj4gPj4+IGFsZ29yaXRobSB0byBlbXBsb3kgdG8gc2VjdXJlIHRoZSBKV1QgZm9y
IGEgcGFydGljdWxhciBpbnRyb3NwZWN0aW9uDQo+ID4+PiByZXNwb25zZS4iICBTZWN0aW9uIDYu
MiBleHBsaWNpdGx5IG5vdGVzIHRoZSB0aHJlYXQgb2YgdG9rZW4gZGF0YQ0KPiA+Pj4gbGVha2Fn
ZSAoYSBtb3JlIGdlbmVyYWwgY2FzZSBvZiBteSBjb25jZXJuIHNvIHRoYW5rcyBmb3IgdGhhdCB0
ZXh0KS4NCj4gPj4+IFtSRkM3NjYyXSwgU2VjdGlvbiA0IG5vdGVzIG9ubHkgdGhhdCAidGhlIHNl
cnZlciBNVVNUIHN1cHBvcnQNCj4gPj4+IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSAx
LjIiLCBidXQgInN1cHBvcnQiIGlzIGRpZmZlcmVudCB0aGFuDQo+ID4+PiAidGhlIHNlcnZlciBN
VVNUIF91c2VfIFRMUyIuIFRoZXJlZm9yZSwgaXQgc2VlbXMgbGlrZSB0aGVyZSBjb3VsZCBiZSBh
DQo+ID4+PiBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgY291bGQgcmV0dXJuIGFuIGludHJvc3BlY3Rp
b24gcmVzcG9uc2UgaW4gdGhlDQo+ID4+PiBjbGVhciAoZS5nLiwgbm8gVExTLCBpbnRyb3NwZWN0
aW9uX3NpZw0KPiA+Pj4+IG5lZF9yZXNwb25zZV9hbGcpLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGlu
Zz8NCj4gPj4+Pg0KPiA+Pj4+IE15IGJpYXMgaXMgdG8gc2F5IHNvbWV0aGluZyBvbiB0aGUgb3Jk
ZXIgb2YgIlRMUyBNVVNUIGJlIHVzZWTigJ0uDQo+ID4+Pg0KPiA+Pj4gU2VjdGlvbiA2LjIuIG5v
dyBzdGFydHMgd2l0aCDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB1c2UNCj4gPj4+
IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSAxLjIgKG9yIGhpZ2hlcikgaW4gb3JkZXIg
dG8gcHJldmVudCB0b2tlbg0KPiBkYXRhDQo+ID4+IGxlYWthZ2UuIg0KPiA+Pg0KPiA+PiBXb3Jr
cyBmb3IgbWUgdG8gd2FzIHVzZSBUTFMuICBJJ2QgcmVjb21tZW5kIGEgc3RhdGVtZW50IHRoYXQg
cHJvdmlkZXMNCj4gPj4gbW9yZSBndWlkYW5jZSAiVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1V
U1QgdXNlIFRyYW5zcG9ydCBMYXllcg0KPiBTZWN1cml0eQ0KPiA+PiAoVExTKSAxLjIgKG9yIGhp
Z2hlcikgcGVyIFJGQzc1MjUgaW4gb3JkZXIgdG8gcHJldmVudCB0b2tlbiBkYXRhIGxlYWthZ2Uu
Ig0KPiA+Pg0KPiA+Pj4+ICg0KSBJIGFsc28gd2FudCB0byB0YWxrIHRocm91Z2ggYW4gdW5zY3J1
cHVsb3VzIHByb3RlY3RlZCByZXNvdXJjZQ0KPiA+Pj4+IHRyeWluZyB0bw0KPiA+Pj4gaGFydmVz
dCBpbnRyb3NwZWN0aW9uIG1ldGEtZGF0YS4gIEkgd2FzIGxvb2tpbmcgZm9yIGd1aWRhbmNlIHJl
bGF0ZWQNCj4gPj4+IHRvIHRoZSBhdXRob3JpemF0aW9uIG9mIHRoZSBpbnRyb3NwZWN0aW9uIHRy
YW5zYWN0aW9ucy4gIEkgZm91bmQ6DQo+ID4+Pj4NCj4gPj4+PiBTZWN0aW9uIDIuMiBvZiBbUkZD
NzY2Ml0gc2F5cyBpbXBvcnRhbnQgdGhpbmdzIGxpa2UgIkZvciBpbnN0YW5jZSwNCj4gPj4+PiBh
bg0KPiA+Pj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGxpbWl0IHdoaWNoIHNjb3BlcyBmcm9t
IGEgZ2l2ZW4gdG9rZW4gYXJlDQo+ID4+PiByZXR1cm5lZCBmb3IgZWFjaCBwcm90ZWN0ZWQgcmVz
b3VyY2UgdG8gcHJldmVudCBhIHByb3RlY3RlZCByZXNvdXJjZQ0KPiA+Pj4gZnJvbSBsZWFybmlu
ZyBtb3JlIGFib3V0IHRoZSBsYXJnZXIgbmV0d29yayB0aGFuIGlzIG5lY2Vzc2FyeSBmb3IgaXRz
DQo+ID4+IG9wZXJhdGlvbi4iDQo+ID4+Pj4NCj4gPj4+PiBTZWN0aW9uIDQgb2YgW1JGQzc2NjJd
IHNheXMgIklmIGxlZnQgdW5wcm90ZWN0ZWQgYW5kIHVuLXRocm90dGxlZCwNCj4gPj4+PiB0aGUN
Cj4gPj4+IGludHJvc3BlY3Rpb24gZW5kcG9pbnQgY291bGQgcHJlc2VudCBhIG1lYW5zIGZvciBh
biBhdHRhY2tlciB0byBwb2xsIGENCj4gPj4+IHNlcmllcyBvZiBwb3NzaWJsZSB0b2tlbiB2YWx1
ZXMsIGZpc2hpbmcgZm9yIGEgdmFsaWQgdG9rZW4uICBUbw0KPiA+Pj4gcHJldmVudCB0aGlzLCB0
aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIG9mDQo+
ID4+PiBwcm90ZWN0ZWQgcmVzb3VyY2VzIHRoYXQgbmVlZCB0byBhY2Nlc3MgdGhlIGludHJvc3Bl
Y3Rpb24gZW5kcG9pbnQgYW5kDQo+ID4+PiBTSE9VTEQgcmVxdWlyZSBwcm90ZWN0ZWQgcmVzb3Vy
Y2VzIHRvIGJlIHNwZWNpZmljYWxseSBhdXRob3JpemVkIHRvDQo+ID4+PiBjYWxsIHRoZSAgaW50
cm9zcGVjdGlvbiBlbmRwb2ludC4iDQo+ID4+Pj4NCj4gPj4+PiBTZWN0aW9uIDYuMiBvZiB0aGlz
IGRyYWZ0IHByb3ZpZGVzIGd1aWRhbmNlIG9uIGRlZmVuZGluZyBhZ2FpbnN0DQo+ID4+PiB1bmF1
dGhlbnRpY2F0ZWQgY2xpZW50cy4NCj4gPj4+Pg0KPiA+Pj4+IEhvdyBkb2VzIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciByZXN0cmljdCBhIHByb3RlY3RlZCByZXNvdXJjZSB0aGF0DQo+ID4+Pj4g
X2Nhbl8NCj4gPj4+IGF1dGhlbnRpY2F0ZSB0byBpdCBmcm9tIGdldHRpbmcgbWV0YS1kYXRhIGlz
IHNob3VsZG4ndCBoYXZlIGFjY2VzcyB0bz8NCj4gPj4+IFNvbWV0aGluZyBvbiB0aGUgb3JkZXIg
b2YgInRoZSBhdXRob3JpemF0aW9uIHNlcnZlciA8dXNlcyB0aGUNCj4gPj4+IGZvbGxvd2luZw0K
PiA+Pj4gZGF0YT4gdG8gZGV0ZXJtaW5lIHdoYXQgYSBnaXZlbiBwcm90ZWN0ZWQgcmVzb3VyY2Ug
aXMgYWxsb3dlZCB0byBzZWXigJ0uDQo+ID4+Pg0KPiA+Pj4gSSBhZGRlZCBTZWN0aW9uIDYuMywg
d2hpY2ggc3RhdGVzIOKAnFRoZSBhdXRob3Jpc2F0aW9uIHNlcnZlciBkZXRlcm1pbmVzDQo+ID4+
PiB0aGUgdG9rZW4gZGF0YSBhIHJlc291cmNlIHNlcnZlciBpcyBhbGxvd2VkIHRvIHNlZSBiYXNl
ZCBvbiB0aGUNCj4gPj4+IHJlc291cmNlIHNlcnZlcuKAmXMgY2xpZW50X2lkIGFuZCBzdWl0YWJs
ZSB0b2tlbiBkYXRhLCBlLmcuIHRoZSBzY29wZQ0KPiB2YWx1ZS4iDQo+ID4+DQo+ID4+IEdyZWF0
LiBUaGFua3MgZm9yIHRoZSBjbGFyaXR5Lg0KPiA+Pg0KPiA+Pj4+DQo+ID4+Pj4gKDUpIEVkaXRv
cmlhbCBOaXRzDQo+ID4+Pj4NCj4gPj4+PiAqKiBTZWN0aW9uIDMuICBQZXIgIlRoaXMgSldUIE1B
WSBmdXJ0aGVybW9yZSBjb250YWluIGFsbCBvdGhlcg0KPiA+Pj4+IGNsYWltcw0KPiA+Pj4gZGVz
Y3JpYmVkIGluIFNlY3Rpb24gMi4yLiBvZiBbUkZDNzY2Ml0gYW5kIGJleW9uZCAoZS5nLiBhcyBk
ZWZpbmVkIGluDQo+ID4+PiBbT3BlbklELkNvcmVdKSIsIHdvdWxkIGl0IGJlIG1vcmUgdGltZWxl
c3MgdG8gc2F5IHRoZSBmaWVsZHMgc3BlY2lmaWVkDQo+ID4+PiBpbiAiT0F1dGggVG9rZW4gSW50
cm9zcGVjdGlvbiBSZXNwb25zZSIgcmVnaXN0cnk/DQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiBUaGlz
IHRleHQgcHJlLWRhdGVkIHRoZSBhZGRpdGlvbiBvZiB0aGUgSUFOQSByZWdpc3RyeSBzZWN0aW9u
LiBUaGFua3MNCj4gPj4+IGZvciBzcG90dGluZyB0aGUgaW5jb25zaXN0ZW5jeS4NCj4gPj4+DQo+
ID4+PiBJIG1vZGlmaWVkIHRoZSB0ZXh0IGFzIHlvdSBzdWdnZXN0ZWQuDQo+ID4+Pg0KPiA+Pj4+
ICoqIFNlY3Rpb24gNC4gIFRoZSBmaXJzdCBzZW50ZW5jZSBvZiBlYWNoIHBhcmFtZXRlcnMgZGVz
Y3JpcHRpb25zDQo+ID4+Pj4gZG9uJ3QNCj4gPj4+IHBhcnNlIC0tIGZvciBleGFtcGxlIHdpdGgg
aW50cm9zcGVjdGlvbl9zaWduZWRfcmVzcG9uc2VfYWxnOiAiSldTDQo+ID4+PiBbUkZDNzUxNV0g
J2FsZycgYWxnb3JpdGhtIEpXQSBbUkZDNzUxOF0gUkVRVUlSRUQiLCBmdWxseSBleHBhbmRlZA0K
PiA+Pj4gdGhhdCdzICJKU09OIFdlYiBTaWduYXR1cmUgKEpXUykgW1JGQzc1MTVdICJhbGciIGFs
Z29yaXRobSBKU09OIFdlYg0KPiA+Pj4gQWxnb3JpdGhtcw0KPiA+Pj4gKEpXQSkgW1JGQzc1MThd
IFJFUVVJUkVEIC4uLiIuICBUaGUgc2FtZSBpcyB0cnVlIGZvciB0aGUgd3JpdGUtdXBzIGluDQo+
ID4+PiBTZWN0aW9uIDUuDQo+ID4+Pg0KPiA+Pj4gbW9kZmllZCB0ZXh0DQo+ID4+Pg0KPiA+Pj4+
DQo+ID4+Pj4gKiogU2VjdGlvbiA0LiAgRWRpdG9yaWFsLiAgUGVyICJpbnRyb3NwZWN0aW9uX2Vu
Y3J5cHRlZF9yZXNwb25zZV9lbmMiOg0KPiA+Pj4+IHMvUkVRVUlSRUQgZm9yIGVuY3J5cHRpbmcg
aW50cm9zcGVjdGlvbiByZXNwb25zZXMvIFJFUVVJUkVEIGZvcg0KPiA+Pj4+IGF1dGhlbnRpY2F0
ZWQgZW5jcnlwdGlvbiBvZiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlcy8NCj4gPj4+Pg0KPiA+Pj4N
Cj4gPj4+IGRvbmUNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciBhbGwgb2YgdGhlIGFib3ZlLg0KPiA+
Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBSb21hbg0KPiA+Pg0KPiA+Pj4ga2luZCByZWdhcmRzLA0K
PiA+Pj4gVG9yc3Rlbi4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4gUm9t
YW4NCj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4+Pj4gT0F1dGhAaWV0Zi5v
cmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+
ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZw0KPiA+PiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==


From nobody Tue Jul 23 15:03: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 BA46F1209C1 for ; Tue, 23 Jul 2019 15:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Tj_aPzivAs6X for ; Tue, 23 Jul 2019 15:03:05 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C331209C2 for ; Tue, 23 Jul 2019 15:03:05 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id d24so42508843ljg.8 for ; Tue, 23 Jul 2019 15:03:04 -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=UeITJNAqd5daB8B76ElFAweJ/J6LmhslcJ2P3fvVRSk=; b=NfXvRgaG+LVvPbCfgjqCTOdCYycfw3+rpSXjJI98hukHlTq/3e3P0NdCoZWSv/eQue 30xNxa52BXhJNpoX0xulhAuNhMnNntePJdtgQaUmL3Nu3QcM2gyVTilMXeUeMHLis057 28cPaqttWLQnD4xnUjuWGNJsQvI9Mhwpxf5p7+F75u0Gjt7yY+T8UGAXqIsR/N+AAE3e q4gbeslFXd92DIOP+Fw0X7L/qRswvAMJ4jTZPUlKVRqqGA5NgwWt5maM/FsXwtv35ftK JyOSZ9W0D1jHQu6Pfd4fMuS529CHADJ0mS2Wnom8cZNr4zyJrXwToijh11Wtt4vVk4Hm maew==
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=UeITJNAqd5daB8B76ElFAweJ/J6LmhslcJ2P3fvVRSk=; b=LKAoUqwtaVYRqFqlxlEQdg4JYo0XluRm25c9py0y+O6SY/XwvYuVKxq4bXYh1Pob6b bMf0+cvMkDJl1hIZr3Bqb4LtPABHVQBIaOz9sohXFNM7+ustdPI18wjEIELxmDRGgMsM MLF1AZQRME/6s/XXU5Gv/FgSspPtvePkiSY/95RjvCvFLRpjqqO4Emevshe2NTPES+/Q h8X+USUB+YpCKqbWIWptMTEzbihx4sa4gdS11t2ong7FM/nVcKfdzvpPpp2bBmBmUY4d qspTwuPZ+iw0t77Vd4EYJ0rIYYewNhfB0smdAkVwhtRhWn1o1VhurZ+YF6qG7NDtOeKd 62lA==
X-Gm-Message-State: APjAAAXQUxQDhYFosAUoN5xQJlev9pQZIe22onH7L+t09CKZu0gRmg/W I0lpL/Uh6hJQlhwsfbtCzPTNwtJpz8y2GGVz32G5MsBx0Tg=
X-Google-Smtp-Source: APXvYqyBirduzeLihDCaghG4lpJVPcoWNJwc3Z3Xm9VqLFoVPnuV75SJiBDQW3NrMRm8jQT/YtjkEVe/3hSO/qUlZGg=
X-Received: by 2002:a2e:9158:: with SMTP id q24mr41292580ljg.119.1563919382807;  Tue, 23 Jul 2019 15:03:02 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Tue, 23 Jul 2019 18:02:50 -0400
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004509bb058e605b63"
Archived-At: 
Subject: [OAUTH-WG] Dinner tonight (Tuesday)?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 22:03:16 -0000

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

Anyone not going to the social that wants to get dinner?

--0000000000004509bb058e605b63
Content-Type: text/html; charset="UTF-8"


Anyone not going to the social that wants to get dinner?


--0000000000004509bb058e605b63--


From nobody Tue Jul 23 15:15:58 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5371209AA for ; Tue, 23 Jul 2019 15:15:46 -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 5nisjxl3f_s0 for ; Tue, 23 Jul 2019 15:15:43 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC631202DB for ; Tue, 23 Jul 2019 15:15:43 -0700 (PDT)
Received: from [84.158.229.114] (helo=[192.168.71.102]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hq34N-0006x7-DE; Wed, 24 Jul 2019 00:15:39 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-5F629A00-3BB5-4029-BED1-C54B6847AE90; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E2C1D@marchand>
Date: Wed, 24 Jul 2019 00:15:38 +0200
Cc: "oauth@ietf.org" , Vladimir Dzhuvinov 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <359EC4B99E040048A7131E0F4E113AFC01B33D7447@marchand> <271A13CC-5B12-4318-8F3D-9E3ACA6D903E@lodderstedt.net> <359EC4B99E040048A7131E0F4E113AFC01B33E1621@marchand> <359EC4B99E040048A7131E0F4E113AFC01B33E1631@marchand>  <359EC4B99E040048A7131E0F4E113AFC01B33E2C1D@marchand>
To: Roman Danyliw 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03
X-BeenThere: oauth@ietf.org
X-Mailman-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, 23 Jul 2019 22:15:57 -0000

--Apple-Mail-5F629A00-3BB5-4029-BED1-C54B6847AE90
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



> Am 24.07.2019 um 00:02 schrieb Roman Danyliw :
>=20
> With the IETF LC feedback can you please address this idnit introduced in t=
his update:

sure=

--Apple-Mail-5F629A00-3BB5-4029-BED1-C54B6847AE90
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
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzIzMjIxNTM4WjAvBgkqhkiG9w0BCQQxIgQg
PcSI+OIB50j5X/+MoX9ad4i0L67htbRcW8wDVd4Sx1cwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBABP6ycYx9xoO1wgo
Oc7zLY2RXXtbZvIFoda2Eis5bFl+QzH0Oj2wZQ4+remvgINx6DWp9zlXyfWoFBlcu1+KlFokAld4
VoneiAg/ioA5l8DnPuKgThgKjB6OkN5M6bY+1KBQcO1LZSEhx4vpH90yuX6yuq1D17eXxynaNeyf
HeVs35O5ZA0RYfa0SAsYIB26H6woKpyGHoqHA/K97BPxmzxq5l0LKDlViDW0WoaOzvGLQwxQ+q/u
g681kDAT4vXV+wQ1LthF2Ga533v6kaeYWVyIndoTL8QFJ1Y4d/JNHx4evogTv3CFEQ1xZlOAMlbz
07zplNJxVvz/zSmoz6YB70sAAAAAAAA=

--Apple-Mail-5F629A00-3BB5-4029-BED1-C54B6847AE90--


From nobody Tue Jul 23 15:42:42 2019
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AB120915; Tue, 23 Jul 2019 15:42:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <156392176100.27987.15275513935099912613@ietfa.amsl.com>
Date: Tue, 23 Jul 2019 15:42:41 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-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, 23 Jul 2019 22:42:41 -0000

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

        Title           : Reciprocal OAuth
        Author          : Dick Hardt
	Filename        : draft-ietf-oauth-reciprocal-03.txt
	Pages           : 7
	Date            : 2019-07-23

Abstract:
   There are times when a user has a pair of protected resources that
   would like to request access to each other.  While OAuth flows
   typically enable the user to grant a client access to a protected
   resource, granting the inverse access requires an additional flow.
   Reciprocal OAuth enables a more seamless experience for the user to
   grant access to a pair of protected resources.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-reciprocal-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 Tue Jul 23 19:13:58 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1806120026 for ; Tue, 23 Jul 2019 19:13:55 -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, SPF_PASS=-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 c9_loEQ-k8jA for ; Tue, 23 Jul 2019 19:13:53 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id DE0FD1209C3 for ; Tue, 23 Jul 2019 19:13:52 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:c84:db81:3715:c5de] (unknown [IPv6:2601:282:202:b210:c84:db81:3715:c5de]) by alkaline-solutions.com (Postfix) with ESMTPSA id 8C20B31686; Wed, 24 Jul 2019 02:13:51 +0000 (UTC)
From: David Waite 
Message-Id: <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_097CDDAD-8950-4C3A-BA6F-561DA3F7618A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\))
Date: Tue, 23 Jul 2019 20:13:50 -0600
In-Reply-To: 
Cc: Torsten Lodderstedt , OAuth WG 
To: Brian Campbell 
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net> 
X-Mailer: Apple Mail (2.3566.0.1)
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 02:13:56 -0000

--Apple-Mail=_097CDDAD-8950-4C3A-BA6F-561DA3F7618A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 23, 2019, at 12:47 PM, Brian Campbell =
 wrote:
>=20
>=20
>=20
> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt =
> wrote:
>=20
> 2) Regarding architectures: I think this BCP should focus on =
recommendations for securely implementing OAuth in the different =
potential architecture. I don=E2=80=99t think we should get into the =
business of recommending and assessing other solutions (e.g. section =
6.1.). Just to give you an example: Section 6.1. states=20
>=20
> "OAuth and OpenID Connect provide very little benefit in this =
deployment scenario, so it is recommended to reconsider whether you need =
OAuth or OpenID Connect at all in this case.=E2=80=9D
>=20
> Really? What experiences is this statement based on? In my experience, =
sharing the same domain =3D=3D host name tells you nothing about the =
overall architecture of a certain deployment. There may be several =
reasons why OAuth could be good choice in such a scenario, e.g. security =
considerations (since your common domain is just a proxy server =
encapsulating a whole universe of systems) or even modularity as an =
architecture principle.=20
>=20
> I suggest to remove section c. and to rephrase the second paragraph of =
the abstract.
>=20
> I believe the experiences that the statement is based on are the =
predominant practice over the course of much of the history of the web =
of using a cookie to maintain an authenticated HTTP session in web =
applications. When the script of the browser-based application is served =
from a domain that can share cookies with the domain of the API, then =
cookies can still be used to authorize requests (even if those requests =
are API calls rather than full page HTTP request/response). And I do =
believe that's likely a better decision in a lot of such cases.=20
>=20
> That authenticated HTTP session may be establish from a =
username/password form submission, FIDO/WebAuthn, or whatever.  Even as =
a result of an OpenID Connect flow. Or even SAML for that matter. But =
the the requests after that are authorized by the cookie.=20
>=20
> I think there's a tendency to assume because SPA style apps make API =
calls, they simply must use OAuth. Because API implies OAuth in the =
minds of many (which is a sign of its success). But OAuth isn't =
necessarily the only thing that can be used for API authorization. =
Cookies work too. I think/hope that's what Section 6.1. is getting at - =
providing some potential guidance that OAuth might not necessarily be =
the right choice in those cases where a common domain allows for a =
cookie. Perhaps the text in that section could be phased in a different =
or better way, but I think its useful to have some mention of in this =
document.=20
>=20
> Although taking out "and OpenID Connect" from the sentence quoted =
above might be more appropriate and alleviate some confusion.=20
>=20

Perhaps it should be turned into a stated document assumption (that the =
reader has decided to use OAuth) rather than guidance later in the =
document (that OAuth may not be the best fit)

There is AFAIK no set of security considerations or best practices we =
can point to for =E2=80=9Cuse some non-standardized system for acquiring =
and using cookies=E2=80=9D or even =E2=80=9Chere=E2=80=99s a standard =
for acquiring and using cookies=E2=80=9D. Omitting some of the moving =
pieces of OAuth might alleviate some security concerns, but also =
resurrect some other security issues. The most immediate example that =
comes to mind: using a HttpOnly cookie-as-token instead of an access =
token may mean that you can=E2=80=99t have injected scripts exfiltrate =
the token, but applying the access token was also a mitigation against =
browser CSRF for your APIs.

-DW=

--Apple-Mail=_097CDDAD-8950-4C3A-BA6F-561DA3F7618A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Jul 23, 2019, at 12:47 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:



On Mon, Jul 22, 2019 at 7:31 AM Torsten =
Lodderstedt <torsten@lodderstedt.net> wrote:


2) Regarding architectures: I think this BCP should focus on =
recommendations for securely implementing OAuth in the different =
potential architecture. I don=E2=80=99t think we should get into the =
business of recommending and assessing other solutions (e.g. section =
6.1.). Just to give you an example: Section 6.1. states 



"OAuth and OpenID Connect provide very little benefit in this deployment =
scenario, so it is recommended to reconsider whether you need OAuth or =
OpenID Connect at all in this case.=E2=80=9D



Really? What experiences is this statement based on? In my experience, =
sharing the same domain =3D=3D host name tells you nothing about the =
overall architecture of a certain deployment. There may be several =
reasons why OAuth could be good choice in such a scenario, e.g. security =
considerations (since your common domain is just a proxy server =
encapsulating a whole universe of systems) or even modularity as an =
architecture principle. 



I suggest to remove section c. and to rephrase the second paragraph of =
the abstract.

I believe the experiences that the =
statement is based on are the predominant practice over the course of =
much of the history of the web of using a cookie to maintain an =
authenticated HTTP session in web applications. When the script of the =
browser-based application is served from a domain that can share cookies =
with the domain of the API, then cookies can still be used to authorize =
requests (even if those requests are API calls rather than full page =
HTTP request/response). And I do believe that's likely a better decision =
in a lot of such cases. 

That authenticated HTTP session may be =
establish from a username/password form submission, FIDO/WebAuthn, or =
whatever.  Even as a result of an OpenID Connect flow. Or even SAML =
for that matter. But the the requests after that are authorized by the =
cookie. 

I think there's a tendency to assume because SPA style apps =
make API calls, they simply must use OAuth. Because API implies OAuth in =
the minds of many (which is a sign of its success). But OAuth isn't =
necessarily the only thing that can be used for API authorization. =
Cookies work too. I think/hope that's what Section 6.1. is getting at - =
providing some potential guidance that OAuth might not necessarily be =
the right choice in those cases where a common domain allows for a =
cookie. Perhaps the text in that section could be phased in a different =
or better way, but I think its useful to have some mention of in this =
document. 

Although taking out "and OpenID Connect" from the sentence =
quoted above might be more appropriate and alleviate some confusion. 


Perhaps it should be turned into a stated document =
assumption (that the reader has decided to use OAuth) rather than =
guidance later in the document (that OAuth may not be the best =
fit)

There is AFAIK no set of =
security considerations or best practices we can point to for =E2=80=9Cuse=
 some non-standardized system for acquiring and using cookies=E2=80=9D =
or even =E2=80=9Chere=E2=80=99s a standard for acquiring and using =
cookies=E2=80=9D. Omitting some of the moving pieces of OAuth might =
alleviate some security concerns, but also resurrect some other security =
issues. The most immediate example that comes to mind: using a HttpOnly =
cookie-as-token instead of an access token may mean that you can=E2=80=99t=
 have injected scripts exfiltrate the token, but applying the access =
token was also a mitigation against browser CSRF for your =
APIs.

-DW
=

--Apple-Mail=_097CDDAD-8950-4C3A-BA6F-561DA3F7618A--


From nobody Wed Jul 24 00:50: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 3CAF112034A for ; Wed, 24 Jul 2019 00:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LPGu_Cd_QG7 for ; Wed, 24 Jul 2019 00:50:12 -0700 (PDT)
Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94611200D6 for ; Wed, 24 Jul 2019 00:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1563954612; bh=xZJExtcgu7zK55NoJVdIk0kmyV/x4mK9Wk5e2/uHASs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=EiMOL/20hOfFg9RLd60DHnjFIRxSJFdB6e/3vBAjT4ZZy0/kSp1zIwFvjBTqIFVqlKLfNYfsqGDHciHIpok4DV6RLMjfqseBXVLp+JZ3Es/r/9XXi8gMfMSAMuowSUmRX33JOCMNwLW1/l7O8FwDR1tfS6HmTkdlg22DhajWFcxFpptMzVFw16NcmiF1ZWHk3fD2FVBSanIaq80qrcbJlUjW1axlDPRfmmHmirkUNptiN2u4+uRWSwZvQZKg/iCIeNfnwG3XEvQMYC29rPsG20UPv37u76/zw6dcDvivwvSaVJJUth9EESYlN16qtCpYn+JOfGmfbAXXIWSHM16RdQ==
X-YMail-OSG: FX1z1pMVM1mjGZNX13aNVRyipu_pT3dW5PENpHJlFfQzufvSoRex_4_0bNPXxB1 zBR0hyo4kKO0g4xAWuPQU8WQyjhrYVa9QVH1hPYJsK_yuT658Ns3VYcS5QmBjjfIORGQyU.CO4bb fE7gJsv6P9GOTWcoW3i5rtkY4KUDUqkJC96zqJnd8pdBKUFj5CB5l_D3qN7KfMtpR6VLOdWoKT55 3sWF4kVIffP9vh4yBUMjB.JKHjVfBMblp9tbRTDg3J6cSBg6ad8q6vf5l2q_6PKV48axQDSYTGTi 1oKracDXsyL4fFB1_GB0ymuAQGFMhZJE61oC3lUjMgikQ6VpIpyUcFjyA5EAFB5OmXZYHKWKCVDQ Rhy_qOIbxADc7HWSqDwLTDfpXB2kI4FhPv9W2O1D0CoC7KY2ouVv3I39_oFAhHSl7cEh_x.j1DOM 7SGz2cHrQILBXDGRohlYYDu706.9cj.lVY4URtm4jEkwOqdax7mH5Q1za3Ad0FSncH09Xxaj8D8t LgNa3.e4bgHbOF8mA7xfEhl4ZUZrtwAG3aYhwgGB2_9r3StCDsQYK4ghERWbFIn5oRXbuQXtIVzC qPiEUcWdV4Y5C_qAIiC_BzxcO_X6FPecpbUrg4t9Q7SsK5dvglkpOBlm0SGI5hAUs5Jm1oSj73Bx n4nWY9uJB5GWJBkcisAOMyzcqIUw.RIkZ2mixUfUG9ooe3.7Rw4kkOhlXF7GWubkGBteQTv.iulL B8TynhLejBTh_dQjw5t1ujRBWJQrcFQeEVBo_PL3unxLjl0a60VI3UU.XZCNQK3GV_R8XlrJrum_ _FLzwGWxlTmu3O9DOD9i8K0Lav1TswnNL1whpX8Xrv6fllWqIwdE7ry1BCBanlf9H2Iiygg8SXM2 dmGxyDjMw2q0gyCPI6pHKcz3HeUZNXmV7MImlW_Uvn85gjbdE8ANvxuHhr6_EsVyHMP8JunMkVDh 4JRxcr.K7MUVPnOFUnjF0iDipgEJKY3bwtmTznK8cBR7h1qJj4X8X2ioi7QodNFN6F85KoBwXtSP B1LY5CVXXw5FKx8HyqvQ89AuFPHDX9_tnPnV.Eg_kxjfIJ0X5fz.ycDhIMFv99ZAC5ekPAXzczyz dYExo58Fs6wVQW5pgROoieu.DTTtHxz.LtdSbqkyKCunTC0ROhFFWLC6FFhj3yy_8ZFLZA.OsCKk 9KUdRvRSDPtaKQJ0MTUBmR1JhByTV7MpGRnWWdADSIRC3XBeiUPO2F4J1F9O9xAO5ILZRqjkPa5N nd4r4WP5WSHEs5H.C7R9w7mpebg0JYZfpWPY0GA_guj0-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 24 Jul 2019 07:50:12 +0000
Date: Wed, 24 Jul 2019 07:50:10 +0000 (UTC)
From: Tomek Stojecki 
To: Brian Campbell ,  David Waite 
Cc: OAuth WG 
Message-ID: <1903519861.188545.1563954610968@mail.yahoo.com>
In-Reply-To: <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com>
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>  <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 07:50:15 -0000

I agree that 6.1 takes too broad of a swipe, but I'd say with same-site coo=
kies and (sadly) without token-binding, the suggestion to use cookie based =
session following oauth/oidc auth is a good one and should be incorporated =
perhaps in 6.2?

Leo sums it up well here:
> We need to be clear on the distinction between browser based apps that ho=
ld the token(s) in the browser space, vs. those that don't.=C2=A0 I agree t=
hat with this "common domain" architecture, the tokens should not be held i=
n the browser, but it doesn't follow that oauth should not be used at all.=
=C2=A0=C2=A0

Finally and sorry if this is off-topic, why isn't this discussion taking pl=
ace in github? Aaron has uploaded the document there. This medium, while go=
od for some things, seems to have a lot of shortcomings for this sort of di=
scussion and review.=C2=A0

Thanks,
Tomek


On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite  wrote:=20







> On Jul 23, 2019, at 12:47 PM, Brian Campbell  wrote:
>=20
>=20
>=20
> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt  wrote:
>>=20
>> 2) Regarding architectures: I think this BCP should focus on recommendat=
ions for securely implementing OAuth in the different potential architectur=
e. I don=E2=80=99t think we should get into the business of recommending an=
d assessing other solutions (e.g. section 6.1.). Just to give you an exampl=
e: Section 6.1. states=20
>>=20
>> "OAuth and OpenID Connect provide very little benefit in this deployment=
 scenario, so it is recommended to reconsider whether you need OAuth or Ope=
nID Connect at all in this case.=E2=80=9D
>>=20
>> Really? What experiences is this statement based on? In my experience, s=
haring the same domain =3D=3D host name tells you nothing about the overall=
 architecture of a certain deployment. There may be several reasons why OAu=
th could be good choice in such a scenario, e.g. security considerations (s=
ince your common domain is just a proxy server encapsulating a whole univer=
se of systems) or even modularity as an architecture principle.=20
>>=20
>> I suggest to remove section c. and to rephrase the second paragraph of t=
he abstract.
>=20
> I believe the experiences that the statement is based on are the predomin=
ant practice over the course of much of the history of the web of using a c=
ookie to maintain an authenticated HTTP session in web applications. When t=
he script of the browser-based application is served from a domain that can=
 share cookies with the domain of the API, then cookies can still be used t=
o authorize requests (even if those requests are API calls rather than full=
 page HTTP request/response). And I do believe that's likely a better decis=
ion in a lot of such cases.=20
>=20
> That authenticated HTTP session may be establish from a username/password=
 form submission, FIDO/WebAuthn, or whatever.=C2=A0 Even as a result of an =
OpenID Connect flow. Or even SAML for that matter. But the the requests aft=
er that are authorized by the cookie.=20
>=20
> I think there's a tendency to assume because SPA style apps make API call=
s, they simply must use OAuth. Because API implies OAuth in the minds of ma=
ny (which is a sign of its success). But OAuth isn't necessarily the only t=
hing that can be used for API authorization. Cookies work too. I think/hope=
 that's what Section 6.1. is getting at - providing some potential guidance=
 that OAuth might not necessarily be the right choice in those cases where =
a common domain allows for a cookie. Perhaps the text in that section could=
 be phased in a different or better way, but I think its useful to have som=
e mention of in this document.=20
>=20
> Although taking out "and OpenID Connect" from the sentence quoted above m=
ight be more appropriate and alleviate some confusion.=20
>=20
>=20

Perhaps it should be turned into a stated document assumption (that the rea=
der has decided to use OAuth) rather than guidance later in the document (t=
hat OAuth may not be the best fit)

There is AFAIK no set of security considerations or best practices we can p=
oint to for =E2=80=9Cuse some non-standardized system for acquiring and usi=
ng cookies=E2=80=9D or even =E2=80=9Chere=E2=80=99s a standard for acquirin=
g and using cookies=E2=80=9D. Omitting some of the moving pieces of OAuth m=
ight alleviate some security concerns, but also resurrect some other securi=
ty issues. The most immediate example that comes to mind: using a HttpOnly =
cookie-as-token instead of an access token may mean that you can=E2=80=99t =
have injected scripts exfiltrate the token, but applying the access token w=
as also a mitigation against browser CSRF for your APIs.

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


From nobody Wed Jul 24 04:18:21 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 55DDB12002E; Wed, 24 Jul 2019 04:18:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
CC: rdd@cert.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwt-introspection-response@ietf.org
Content-Transfer-Encoding: 7bit
Reply-To: ietf@ietf.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <156396709926.14570.11646068107032268956.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jul 2019 04:18:19 -0700
Archived-At: 
Subject: [OAUTH-WG] Last Call:  (JWT Response for OAuth Token Introspection) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 11:18:20 -0000

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWT Response for OAuth Token
Introspection'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Wed Jul 24 05:43: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 74BCE120148 for ; Wed, 24 Jul 2019 05:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtLMsNhCf7pB for ; Wed, 24 Jul 2019 05:43:03 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5F71200EC for ; Wed, 24 Jul 2019 05:43:00 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id i10so89166573iol.13 for ; Wed, 24 Jul 2019 05:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=IQTitivJFbbK2H1Zpe8vfAXHD2I3zgCXgr3q3MiYtZY=; b=FdDa6J9i9hVFOrgL8IzDK7st9eNTYj+G1/xhWhp5QkZx2GyUR86joVBPkYGA0WtrAg mMuYA9x0y91VgCrNAGyloENsSJX+XMpbgmFbIu2hv/gOrAGed1RFaj6q3KFXK5lJFZ2e K6jacSW+rwl0HjvXJQwUm6y/XhWo5QgZXIb0I=
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=IQTitivJFbbK2H1Zpe8vfAXHD2I3zgCXgr3q3MiYtZY=; b=qwekuOPpyDvi+sXXyOoebEsetDNtNST9fIBJGJFoiAp+9zw1VY9YutywaZKfXiJddI qrhGFFX0tZxw/Q8rSrFX4Vm+Kg6VZsdPhFhQH25k63sn3gIkYa30dR16zHOSbIweeBql YSms5rgMKDmh5NQ1HXaTqiB/xbZ9bnwzkh+YQzzQwD7auCT55JXE/YO69bIXr8fFcK5u RyoCMMR1VrDmZ4M9oOrKUyhJ58eEfwGIiaaHIfPLfeANYg2TGZ9awozaoPhqc1w1o2mQ kqGGtIlZf4DO0HFLcDXB3AlI9tIAncq50EnmaUDEfrcgz6rWDDUqWvDlbM40o56Wxwhg Qa3g==
X-Gm-Message-State: APjAAAX1X8xB6E1KZw3RX6+4G+NnyjXbeDTBk1tHXg/nGVxRnpTlUrLv BfpGOK0zzYSsL94Hb86ziG1izGAOh1YMjkzH9Loj4URv1lXlzx8xvg9bR61E9m/rmKaKOkbr/yP Q+xYvnz9I9w81rdFMQEUD7A==
X-Google-Smtp-Source: APXvYqyf/YBsVTlhwXYq1gQjIMTDD3SJ9IxrXOCHciWQDSpDwYOzB19xbsz4S596wqR8nYpBRQ9I12WNLNLzR01UwGA=
X-Received: by 2002:a02:a07:: with SMTP id 7mr86295926jaw.65.1563972179056; Wed, 24 Jul 2019 05:42:59 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell 
Date: Wed, 24 Jul 2019 06:42:33 -0600
Message-ID: 
To: oauth , oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002bf8c7058e6ca6fb"
Archived-At: 
Subject: [OAUTH-WG] oauth-jwsreq & parameter registration
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 12:43:05 -0000

--0000000000002bf8c7058e6ca6fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In the WG meeting yesterday I mentioned that I thought there might have had
been some action already taken with respect to "JWT Secured Authorization
Request (JAR)" and the potential name conflicts between authorization
parameters and JWT claims.

I tracked down this ticket in the OpenID Connect WG
https://bitbucket.org/openid/connect/issues/1019/core-iana-consideration,
which touches on the issue but it doesn't look like any action has actually
been taken.

I do think that what is mentioned in the ticket (effectively registering
some core "meta" JWT claims as authorization request parameters) is
pragmatic and sufficient.

As one data point, as far as I know, "aud" is the only name where we've
actually encountered this particular name collision problem.

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

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


In the WG meeting yesterday I mentioned that I though=
t there might have had been some action already taken with respect to "=
;JWT Secured Authorization Request (JAR)" and the potential name confl=
icts between authorization parameters and JWT claims. 

 I tracked down this ticket in the OpenID Connect WG https://bitbucket.org/openid/connect/issues/1019/core-iana-c=
onsideration, which touches on the issue but it doesn't look like a=
ny action has actually been taken. 

I do think=
 that what is mentioned in the ticket (effectively registering some core &q=
uot;meta" JWT claims as authorization request parameters) is pragmatic=
 and sufficient. 

As one data point, as far as=
 I know, "aud" is the only name where we've actually encounte=
red this particular name collision problem. 

 =
=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.
--0000000000002bf8c7058e6ca6fb--


From nobody Wed Jul 24 06:20: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 8FC9C12034E for ; Wed, 24 Jul 2019 06:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 duaOSlrpSura for ; Wed, 24 Jul 2019 06:20:23 -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 4EFF71201E0 for ; Wed, 24 Jul 2019 06:20:23 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x6ODLiKT029452; Wed, 24 Jul 2019 09:21:45 -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, 24 Jul 2019 09:20:02 -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, 24 Jul 2019 09:20:18 -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, 24 Jul 2019 09:20:18 -0400
From: Justin Richer 
To: Dick Hardt 
CC: oauth 
Thread-Topic: [OAUTH-WG] Transaction Authorization
Thread-Index: AQHVNo8uPlHZsW3ub0m+zkQfIAjEo6bV7DYAgAQuwYA=
Date: Wed, 24 Jul 2019 13:20:18 +0000
Message-ID: <9D257804-01E0-4132-A9E2-298BB4E271D9@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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_9D25780401E04132A9E2298BB4E271D9mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 13:20:30 -0000

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

SSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gZXhwb3VuZCBvbiB0aGUgbmV3IHVzZSBjYXNlcyB0aGF0
IHRoaXMgYXBwcm9hY2ggZW5hYmxlcywgYW5kIEnigJlsbCBzZW5kIHRoZW0gb3V0IGhlcmUgYW5k
IGFkZCB0aGVtIHRvIHRoZSBzaXRlIGFzIEkgZ2V0IHRoZW0gd3JpdHRlbiBkb3duLg0KDQpUbyB5
b3VyIHNwZWNpZmljIGlkZWE6IE15IHRoaW5raW5nIGhlcmUgd2FzIHRoYXQgd2UgY2FuIGxldmVy
YWdlIHRoZSB0cmFuc2FjdGlvbiBtb2RlbCB0byBtYWtlIHRoaXMgd29yayBpbiBhIGNvbnNpc3Rl
bnQgZmFzaGlvbi4gVGhpcyBpcyBub3RlZCBpbiB0aGUgc3BlYyBhbmQgd2Vic2l0ZSwgYnV0IHRv
IGV4cGFuZCBoZXJlOg0KDQoxKSBDbGllbnQgZ29lcyB0byB0aGUgUlMgYW5kIHRyaWVzIGEgcmVx
dWVzdCwgd2l0aCBubyB0b2tlbiBvciB3aXRoIGluc3VmZmljaWVudCB0b2tlbi4NCjIpIFJTIGdv
ZXMgdG8gdGhlIEFTIGFuZCBzYXlzIOKAnGhleSBzb21lb25lIHdhbnRzIGEgdGhpbmcgYnV0IGNh
buKAmXQgZ2V0IGl0LCBoZXJl4oCZcyBhIHJlc291cmNlIG9iamVjdCB0aGF0IGRlc2NyaWJlcyB3
aGF0IHdvdWxkIGJlIHN1ZmZpY2llbnQgYWNjZXNzIHRvIG1ha2UgdGhhdCB3b3Jr4oCdIC4uIHRo
aXMgcmVxdWVzdCBoYXMgc29tZSBzaWduYWwgaW4gaXQgdGhhdCB0ZWxscyB0aGUgQVMgdGhhdCBp
dOKAmXMgbm90IGEgY2xpZW50IGFza2luZyBmb3IgYSB0b2tlbiwgbWF5YmUgc2V0IHRoZSDigJxj
bGllbnTigJ0gZmllbGQgdG8g4oCcZmFsc2XigJ0gb3Igc29tZXRoaW5nPyBJ4oCZbSBub3Qgc3Vy
ZSBob3cgYmVzdCB0byBzaWduYWwgdGhhdCB5ZXQuDQozKSBBUyByZXR1cm5zIGEgcmVzb3VyY2Vf
aGFuZGxlIGZvciB0aGUgcmVxdWVzdGVkIHJlc291cmNlIHNldC4gVGhpcyBjYW4gYmUgcmFuZG9t
IGFuZCBkeW5hbWljYWxseSBnZW5lcmF0ZWQsIGRvZXNu4oCZdCBoYXZlIHRvIGJlIGh1bWFuIHJl
YWRhYmxlLg0KNCkgUlMgcmV0dXJucyB0aGUgcmVzb3VyY2UgaGFuZGxlIGFuZCBhIHBvaW50ZXIg
dG8gdGhlIEFT4oCZcyB0cmFuc2FjdGlvbiBlbmRwb2ludCB0byB0aGUgY2xpZW50IGluIGEgV1dX
LUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIgdGhhdCB3ZeKAmWQgZGVmaW5lLCBidXQgd291
bGQgbG9vayBzdXNwaWNpb3VzbHkgbGlrZSBVTUEy4oCZcyByZXNwb25zZSBoZWFkZXIgd2l0aCBz
aW1pbGFyIGluZm9ybWF0aW9uLg0KNSkgQ2xpZW50IG1ha2VzIGl0cyBub3JtYWwgWFlaIHJlcXVl
c3QgdG8gdGhlIEFTIGJ1dCBpbmNsdWRlcyB0aGUgcmVzb3VyY2VfaGFuZGxlIGl0IGdvdCBiYWNr
IGZyb20gKDQpLg0KDQrigJQgSnVzdGluDQoNCk9uIEp1bCAyMSwgMjAxOSwgYXQgNToyNyBQTSwg
RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu
Y29tPj4gd3JvdGU6DQoNCkhleSBKdXN0aW4NCg0KQSBmZXcgdXNlIGNhc2VzIHRoYXQgaGlnaGxp
Z2h0IGhvdyB0aGUgd29ybGQgaXMgZGlmZmVyZW50IG5vdyB0aGFuIGl0IHdhcyB3aGVuIE9BdXRo
IDIuMCB3YXMgZGV2ZWxvcGVkIHdvdWxkIGhlbHAgcGFydGljaXBhbnRzIHVuZGVyc3RhbmQgd2h5
IGNoYW5nZXMgYXJlIG5lZWRlZCwgYW5kIGFsc28gcHJvdmlkZSBhIHJlZmVyZW5jZSBmb3IgY29t
cGFyaW5nIGFuZCBjb250cmFzdGluZyBkaWZmZXJlbnQgYXBwcm9hY2hlcy4NCg0KT25lIG9mIG15
IGZpcnN0IGNvbW1lbnRzIGlzIHdoeSB0aGUgY2xpZW50IGlzIHN0YXJ0aW5nIG9mZiBtYWtpbmcg
Y2FsbHMgdG8gdGhlIEFTLiBUaGVyZSBhcmUgdGltZXMgd2hlbiB0aGUgQVMgaXMgbm90IGtub3du
IGZvciBhIGdpdmVuIHJlc291cmNlLiBXaHkgbm90IGFsbG93IHN0YXJ0aW5nIGF0IHJlc291cmNl
Pw0KDQoNCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMTI6NDggUE0gSnVzdGluIFJpY2hlciA8anJp
Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkkgaGF2ZSByZXF1
ZXN0ZWQgdGltZSB0byBwcmVzZW50IFRyYW5zYWN0aW9uYWwgQXV0aG9yaXphdGlvbiAodGhlIFhZ
WiBwcm9qZWN0KSBhdCB0aGUgTW9udHJlYWwgbWVldGluZyBpbiBhIGNvdXBsZSB3ZWVrcy4gQWhl
YWQgb2YgdGhhdCwgSeKAmXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIHNwZWM6DQoN
Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1h
dXRoei0wMg0KDQpBZGRpdGlvbmFsbHksIEnigJl2ZSB1cGRhdGVkIHRoZSB3cml0ZXVwIGFuZCBl
eGFtcGxlcyBvbiBodHRwczovL29hdXRoLnh5ei8NCg0KSSBwbGFuIHRvIGJlIGluIE1vbnRyZWFs
IGZvciB0aGUgd2hvbGUgd2VlaywgYW5kIEnigJl2ZSByZXF1ZXN0ZWQgZnJvbSB0aGUgY2hhaXJz
IHRoYXQgSSBwcmVzZW50IGR1cmluZyB0aGUgVHVlc2RheSBzZXNzaW9uIGR1ZSB0byBsaW1pdGVk
IGF2YWlsYWJpbGl0eSBvZiBzb21lIGtleSBXRyBtZW1iZXJzIG9uIEZyaWRheS4NCg0K4oCUIEp1
c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

--_000_9D25780401E04132A9E2298BB4E271D9mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <7E6C9F6703BF8245ACED4CD3B50C2DD2@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIGV4cG91
bmQgb24gdGhlIG5ldyB1c2UgY2FzZXMgdGhhdCB0aGlzIGFwcHJvYWNoIGVuYWJsZXMsIGFuZCBJ
4oCZbGwgc2VuZCB0aGVtIG91dCBoZXJlIGFuZCBhZGQgdGhlbSB0byB0aGUgc2l0ZSBhcyBJIGdl
dCB0aGVtIHdyaXR0ZW4gZG93bi4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPlRvIHlvdXIgc3BlY2lmaWMgaWRlYTogTXkgdGhpbmtpbmcgaGVyZSB3
YXMgdGhhdCB3ZSBjYW4gbGV2ZXJhZ2UgdGhlIHRyYW5zYWN0aW9uIG1vZGVsIHRvIG1ha2UgdGhp
cyB3b3JrIGluIGEgY29uc2lzdGVudCBmYXNoaW9uLiBUaGlzIGlzIG5vdGVkIGluIHRoZSBzcGVj
IGFuZCB3ZWJzaXRlLCBidXQgdG8gZXhwYW5kIGhlcmU6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xKSBDbGllbnQgZ29lcyB0byB0aGUgUlMgYW5k
IHRyaWVzIGEgcmVxdWVzdCwgd2l0aCBubyB0b2tlbiBvciB3aXRoIGluc3VmZmljaWVudCB0b2tl
bi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MikgUlMgZ29lcyB0byB0aGUgQVMgYW5kIHNheXMg4oCc
aGV5IHNvbWVvbmUgd2FudHMgYSB0aGluZyBidXQgY2Fu4oCZdCBnZXQgaXQsIGhlcmXigJlzIGEg
cmVzb3VyY2Ugb2JqZWN0IHRoYXQgZGVzY3JpYmVzIHdoYXQgd291bGQgYmUgc3VmZmljaWVudCBh
Y2Nlc3MgdG8gbWFrZSB0aGF0IHdvcmvigJ0gLi4gdGhpcyByZXF1ZXN0IGhhcyBzb21lIHNpZ25h
bCBpbiBpdCB0aGF0IHRlbGxzIHRoZSBBUyB0aGF0IGl04oCZcyBub3QgYSBjbGllbnQNCiBhc2tp
bmcgZm9yIGEgdG9rZW4sIG1heWJlIHNldCB0aGUg4oCcY2xpZW504oCdIGZpZWxkIHRvIOKAnGZh
bHNl4oCdIG9yIHNvbWV0aGluZz8gSeKAmW0gbm90IHN1cmUgaG93IGJlc3QgdG8gc2lnbmFsIHRo
YXQgeWV0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zKSBBUyByZXR1cm5zIGEgcmVzb3VyY2VfaGFu
ZGxlIGZvciB0aGUgcmVxdWVzdGVkIHJlc291cmNlIHNldC4gVGhpcyBjYW4gYmUgcmFuZG9tIGFu
ZCBkeW5hbWljYWxseSBnZW5lcmF0ZWQsIGRvZXNu4oCZdCBoYXZlIHRvIGJlIGh1bWFuIHJlYWRh
YmxlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj40KSBSUyByZXR1cm5zIHRoZSByZXNvdXJj
ZSBoYW5kbGUgYW5kIGEgcG9pbnRlciB0byB0aGUgQVPigJlzIHRyYW5zYWN0aW9uIGVuZHBvaW50
IHRvIHRoZSBjbGllbnQgaW4gYSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciB0aGF0
IHdl4oCZZCBkZWZpbmUsIGJ1dCB3b3VsZCBsb29rIHN1c3BpY2lvdXNseSBsaWtlIFVNQTLigJlz
IHJlc3BvbnNlIGhlYWRlciB3aXRoIHNpbWlsYXIgaW5mb3JtYXRpb24uPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjUpIENsaWVudCBtYWtlcyBpdHMgbm9ybWFsIFhZWiByZXF1ZXN0IHRvIHRoZSBBUyBi
dXQgaW5jbHVkZXMgdGhlIHJlc291cmNlX2hhbmRsZSBpdCBnb3QgYmFjayBmcm9tICg0KS48L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0
bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7
Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDIxLCAyMDE5
LCBhdCA1OjI3IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBn
bWFpbC5jb20iIGNsYXNzPSIiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9k
aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhleSBKdXN0aW4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkEgZmV3IHVzZSBjYXNlcyB0aGF0IGhp
Z2hsaWdodCBob3cgdGhlIHdvcmxkIGlzIGRpZmZlcmVudCBub3cgdGhhbiBpdCB3YXMgd2hlbiBP
QXV0aCAyLjAgd2FzIGRldmVsb3BlZCB3b3VsZCBoZWxwIHBhcnRpY2lwYW50cyB1bmRlcnN0YW5k
IHdoeSBjaGFuZ2VzIGFyZSBuZWVkZWQsIGFuZCBhbHNvIHByb3ZpZGUgYSByZWZlcmVuY2UgZm9y
IGNvbXBhcmluZyBhbmQgY29udHJhc3RpbmcgZGlmZmVyZW50IGFwcHJvYWNoZXMuPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PbmUgb2Yg
bXkgZmlyc3QgY29tbWVudHMgaXMgd2h5IHRoZSBjbGllbnQgaXMgc3RhcnRpbmcgb2ZmIG1ha2lu
ZyBjYWxscyB0byB0aGUgQVMuIFRoZXJlIGFyZSB0aW1lcyB3aGVuIHRoZSBBUyBpcyBub3Qga25v
d24gZm9yIGEgZ2l2ZW4gcmVzb3VyY2UuIFdoeSBub3QgYWxsb3cgc3RhcnRpbmcgYXQgcmVzb3Vy
Y2U/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8
YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBj
bGFzcz0iZ21haWxfYXR0ciI+T24gVHVlLCBKdWwgOSwgMjAxOSBhdCAxMjo0OCBQTSBKdXN0aW4g
UmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBjbGFzcz0iIj5qcmlj
aGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti
b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4N
CjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj5JIGhhdmUg
cmVxdWVzdGVkIHRpbWUgdG8gcHJlc2VudCBUcmFuc2FjdGlvbmFsIEF1dGhvcml6YXRpb24gKHRo
ZSBYWVogcHJvamVjdCkgYXQgdGhlIE1vbnRyZWFsIG1lZXRpbmcgaW4gYSBjb3VwbGUgd2Vla3Mu
IEFoZWFkIG9mIHRoYXQsIEnigJl2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBzcGVj
Og0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlv
bmFsLWF1dGh6LTAyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTAyPC9hPjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWRkaXRp
b25hbGx5LCBJ4oCZdmUgdXBkYXRlZCB0aGUgd3JpdGV1cCBhbmQgZXhhbXBsZXMgb24gPGEgaHJl
Zj0iaHR0cHM6Ly9vYXV0aC54eXovIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczov
L29hdXRoLnh5ei88L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHBsYW4gdG8gYmUgaW4gTW9udHJlYWwgZm9yIHRoZSB3
aG9sZSB3ZWVrLCBhbmQgSeKAmXZlIHJlcXVlc3RlZCBmcm9tIHRoZSBjaGFpcnMgdGhhdCBJIHBy
ZXNlbnQgZHVyaW5nIHRoZSBUdWVzZGF5IHNlc3Npb24gZHVlIHRvIGxpbWl0ZWQgYXZhaWxhYmls
aXR5IG9mIHNvbWUga2V5IFdHIG1lbWJlcnMgb24gRnJpZGF5LiZuYnNwOzwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRl
eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+
DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJy
ZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_9D25780401E04132A9E2298BB4E271D9mitedu_--


From nobody Wed Jul 24 06:46: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 0D3B31200E3 for ; Wed, 24 Jul 2019 06:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 j6zZGp1N6S4Q for ; Wed, 24 Jul 2019 06:46:16 -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 9CB901200BA for ; Wed, 24 Jul 2019 06:46:16 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x6ODkGvq023781; Wed, 24 Jul 2019 09:46:45 -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; Wed, 24 Jul 2019 09:44:54 -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, 24 Jul 2019 09:45: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, 24 Jul 2019 09:45:30 -0400
From: Justin Richer 
To: Neil Madden 
CC: Dick Hardt , oauth 
Thread-Topic: [OAUTH-WG] Transaction Authorization
Thread-Index: AQHVNo8uPlHZsW3ub0m+zkQfIAjEo6bS8t6AgABveACAAohagIABEaKAgACHaICAAM/VgIABzn4A
Date: Wed, 24 Jul 2019 13:45:30 +0000
Message-ID: 
References:     <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com>  <3F6A8E4E-3574-4666-A561-D67D5D0B2EA9@forgerock.com>
In-Reply-To: <3F6A8E4E-3574-4666-A561-D67D5D0B2EA9@forgerock.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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_A4DAC4DCE3AC43F8B951E6AC2C523C95mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 13:46:22 -0000

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

SSBnZXQgdGhlIGRlc2lyZSB0byBoYXZlIG11bHRpcGxlIHRva2VucywgYnV0IHRoZSByZWFsIGNv
c3QgaXMgdGhlIGV4cGxvc2lvbiBpbiBjb21wbGV4aXR5IGZvciBldmVyeSBwYXJ0eSBpbiB0aGUg
c3lzdGVtLiBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSBpZiB5b3UgYWxsb3cgdGhlIGNsaWVudCB0
byBzcGVjaWZ5IGEgbW9yZSBmaW5lLWdyYWluZWQgYW5kIHN0cnVjdHVyZWQgcmVzb3VyY2UgdGFy
Z2V0IHRoYW4gYSBzY29wZSBzdHJpbmcsIGJ1dCBldmVuIHdpdGggYSBzY29wZSBpdOKAmXMgcmVh
bGx5IGNvbW1vbiB0byBoYXZlIGEgc2V0IG9mIGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzIHRo
YXQgcmVzcG9uZCB0byB0aGUgc2FtZSBzY29wZS4gVGhlIGJpZ2dlc3QgYnVyZGVuIGlzIG9uIHRo
ZSBjbGllbnQgd2hpY2ggbm93IGhhcyB0byBtYXAgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgZnJv
bSB0aGUgc2FtZSByZXF1ZXN0IHRvIGRpZmZlcmVudCByZXNvdXJjZSB0YXJnZXRzLCBzb21lIG9m
IHdoaWNoIGl0IG1pZ2h0IGJlIGRpc2NvdmVyaW5nIGF0IHJ1bnRpbWUuIEFuZCB0aGVuIHlvdSBo
YXZlIHRvIGZpZ3VyZSBvdXQgd2hhdCB0byBkbyBhdCB0aGUgQVMgaWYgdGhlIHVzZXIgb25seSBh
cHByb3ZlcyBvbmUgcmVzb3VyY2UsIG9yIGV2ZW4gd29yc2UsIG9uZSBzY29wZSB0aGF0IGNvdmVy
cyBtdWx0aXBsZSByZXNvdXJjZXMuIFlvdSBuZWVkIHRvIGhhdmUgdmVyeSBjbGVhciBsb2dpYyBv
ZiBob3cgeW91IHNlcGFyYXRlIHRoZXNlIGludG8gZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMsIGFu
ZCBob3cgeW91IHNpZ25hbCB0aGF0IHRvIHRoZSBjbGllbnQuIEFuZCB0aGVuIHRoZXJl4oCZcyB0
aGUgcXVlc3Rpb24gb2YgcmVmcmVzaGluZyB0aGluZ3Mgb25jZSB0b2tlbnMgZXhwaXJlIChiZWNh
dXNlIG9mIGNvdXJzZSB0aGV5IGNvdWxkIGhhdmUgZGlmZmVyZW50IGxpZmV0aW1lcykg4oCUIGlu
IE9BdXRoIHRoYXQgaW1wbGllcyBtdWx0aXBsZSByZWZyZXNoIHRva2VucywgaW4gWFlaIHRoYXQg
aW1wbGllcyBtdWx0aXBsZSB0cmFuc2FjdGlvbiBoYW5kbGVzLiBJ4oCZbSBub3Qgc3VyZSB0aGlz
IGNvbXBsZXhpdHkgaW4gdGhlIGdlbmVyYWwgY2FzZSBpcyB3b3J0aCBpdCB0byBzb2x2ZSB0aGlz
IHNwZWNpZmljIGlzc3VlLCB3aGljaCBzZWVtcyBsaWtlIGEgYml0IG9mIGFuIGVkZ2UgY29uZGl0
aW9uIHRvIG1lLiBJIHJlYWxseSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBtYWtlIHNpbXBsZSBj
bGllbnRzIHBheSB0aGlzIGNvbXBsZXhpdHkgY29zdCBpZiB0aGV5IGRvbuKAmXQgaGF2ZSB0by4N
Cg0KWFlaIGRvZXMgbWFrZSBhc2tpbmcgZm9yIHNldmVyYWwgZGlmZmVyZW50IGFjY2VzcyB0b2tl
bnMgaW4gbXVsdGlwbGUgcmVxdWVzdHMgcG90ZW50aWFsbHkgZWFzaWVyIHRocm91Z2ggdXNlIG9m
IHRoZSDigJx1c2VyX2hhbmRsZeKAnSBjb25zdHJ1Y3QgKGltcG9ydGVkIGZyb20gdGhlIFBDVCBj
b25jZXB0IGluIFVNQTIpLiBUaGlzIGxldHMgeW91IHNheSB0aGF0IHlvdSBhcyB0aGUgY2xpZW50
IGFyZSBzYXlpbmcgaXTigJlzIHRoZSBzYW1lIHVzZXIgYW5kIHRoZSBzYW1lIGNsaWVudCBmb3Ig
YSBkaWZmZXJlbnQgcmVzb3VyY2Ugc2V0LCBhbmQgdGhhdCBtaWdodCBiZSBlbm91Z2ggZm9yIHRo
ZSBBUyB0byBqdXN0IGxldCB5b3UgaGF2ZSBhIHRva2VuIHdpdGggdGhlIGZpcnN0IGNhbGwgdG8g
aXQgYW5kIG5vdCBoYXZlIHRvIGdldCB0aGUgdXNlciBpbnZvbHZlZCBhZ2Fpbi4gQnV0IHRoaXMg
ZG9lc27igJl0IHJlYWxseSBoZWxwIGlmIHlvdSBuZWVkIHRvIGFzayB0aGUgdXNlciBjb25zZW50
IGEgYnVuY2ggb2YgdGltZXMsIHdoaWNoIHNlZW1zIHRvIGJlIHdoYXQgcGVvcGxlIGFyZSByZWFs
bHkgYWZ0ZXIgc29sdmluZyB3aGVuIHRoZXkgdGFsayBhYm91dCBnZXR0aW5nIG11bHRpcGxlIGFj
Y2VzcyB0b2tlbnMuIFRoZSBwcm9ibGVtIGlzbuKAmXQgYXNraW5nIHRoZSBBUywgdGhlIHByb2Js
ZW0gaXMgYXNraW5nIHRoZSB1c2VyLCBhbmQgd2XigJlkIHJlYWxseSBsaWtlIHRvIGJvdGhlciB0
aGVtIG9uY2UgYW5kIG9ubHkgb25jZS4NCg0KU28gbWF5YmUgdGhlIHF1ZXN0aW9uIGlzbuKAmXQg
c28gbXVjaCBhYm91dCBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLCBidXQgYWN0dWFsbHkgYWJvdXQg
bXVsdGlwbGUgc2ltdWx0YW5lb3VzIHRyYW5zYWN0aW9ucyBpbiBhIHNpbmdsZSByZXF1ZXN0LiBC
ZWNhdXNlIGlmIHlvdeKAmXJlIGRvaW5nIHRoYXQsIHlvdSBoYXZlIGEga2luZCBvZiBuYXR1cmFs
IHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcmVxdWVzdHMgKGVhY2ggd291bGQgZ2V0IGl0cyBvd24g
dHJhbnNhY3Rpb24ga2V5cyBhbmQgdG9rZW5zKSwgYnV0IHlvdSBjb3VsZCBjb21iaW5lIHRoZSBp
bnRlcmFjdGlvbiBwb3J0aW9uIHdoZW4gaXTigJlzIG5lZWRlZCBhbmQgb25seSBib3RoZXIgdGhl
IHVzZXIgb25jZSBmb3IgbXVsdGlwbGUgdGhpbmdzLg0KDQrigJQgSnVzdGluDQoNCk9uIEp1bCAy
MywgMjAxOSwgYXQgNjoxMCBBTSwgTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5j
b208bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNCg0KSWYgd2UgZm9s
bG93IHRoZSBwcmluY2lwbGUgb2YgbGVhc3QgYXV0aG9yaXR5IHRoZW4gYSB0b2tlbiBzaG91bGQg
YmUgc2NvcGVkIGFzIG5hcnJvd2x5IGFzIHBvc3NpYmxlIHRvIGEgcGFydGljdWxhciByZXNvdXJj
ZSBzZXJ2ZXIvcmVzb3VyY2UvdGltZSBwZXJpb2QvdHJhbnNhY3Rpb24uIFRoZSBzZWN1cml0eSB0
b3BpY3MgQkNQIGhhcyBhbHJlYWR5IGdvbmUgcXVpdGUgZmFyIGRvd24gdGhpcyBwYXRoIGluIGl0
cyByZWNvbW1lbmRhdGlvbnM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMyNzZWN0aW9uLTMuMyAuIExlYXN0IHByaXZpbGVnZSBu
YXR1cmFsbHkgbGVhZHMgdG8gY2xpZW50cyBuZWVkaW5nIG1vcmUgdG9rZW5zLCBzbyB3ZSBzaG91
bGQgbWFrZSBvYnRhaW5pbmcgKGFuZCB1c2luZykgbXVsdGlwbGUgdG9rZW5zIGFzIGZyaWN0aW9u
bGVzcyBhcyBwb3NzaWJsZS4NCg0KRm9yIGFuIGV4YW1wbGUgb2YgdGhpcywgc2VlIHRoZSB3b3Jr
IGRvbmUgYnkgbXkgY29sbGVhZ3VlcyB0byBzaW1wbGlmeSBqdWdnbGluZyBtdWx0aXBsZSBhY2Nl
c3MgdG9rZW5zIGZvciBkaWZmZXJlbnQgcmVzb3VyY2Ugc2VydmVycyAtIGh0dHBzOi8vd3d3Lm5w
bWpzLmNvbS9wYWNrYWdlL2FwcGF1dGhoZWxwZXIgLiBUaGUgbGlicmFyeSBhbGxvd3MgdGhlIGRl
dmVsb3BlciB0byBzcGVjaWZ5IHdoaWNoIHNjb3BlcyBhcmUgdXNlZCBmb3Igd2hpY2ggUlM6DQoN
CiAgIHJlc291cmNlU2VydmVyczogew0KICAgICAgICJodHRwczovL2xvZ2luLmV4YW1wbGUuY29t
L29hdXRoMi91c2VyaW5mbyI6ICJwcm9maWxlIiwNCiAgICAgICAiaHR0cHM6Ly9ycy5leGFtcGxl
LmNvbS8iOiAicnNfY3VzdG9tX3Njb3BlIg0KICAgfSwNCg0KVGhlIGxpYnJhcnkgdGhlbiB0YWtl
cyBjYXJlIG9mIG1ha2luZyBtdWx0aXBsZSByZXF1ZXN0cyB0byBnZXQgYXBwcm9wcmlhdGVseS1z
Y29wZWQgYWNjZXNzIHRva2VucyBhbmQgdGhlbiBhdHRhY2hpbmcgdGhlbSB0byBhcHByb3ByaWF0
ZSByZXF1ZXN0cy4gQnV0IHRoZSBtb3JlIHJlc291cmNlIHNlcnZlcnMgeW91IG5lZWQgdG8gYWNj
ZXNzLCB0aGUgbW9yZSB0b2tlbnMgeW91IG5lZWQgYW5kIHRoZSBtb3JlIHJlcXVlc3RzIHlvdSBo
YXZlIHRvIG1ha2UuIFRoZXJlIGlzIHRoZXJlZm9yZSBjdXJyZW50bHkgYSAidGF4IiBvbiBsZWFz
dCBwcml2aWxlZ2UgdXNlIG9mIGFjY2VzcyB0b2tlbnMgYXMgaXQgaXMgYWxsIG9uIHRoZSBjbGll
bnQgdG8ganVnZ2xlIHRoZXNlIHJlcXVlc3RzLCBnaXZpbmcgYW4gaW5jZW50aXZlIGZvciBjbGll
bnRzIHRvIGluc3RlYWQgcmVxdWVzdCBCaWcgVG9rZW5zIHRoYXQgZ3JhbnQgbG90cyBvZiBhdXRo
b3JpdHkgaW4gYSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZS4NCg0KLS0gTmVpbA0KDQoNCk9uIDIy
IEp1bCAyMDE5LCBhdCAyMjo0NiwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp
bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIE5laWwNCg0KSSBzZWUgdGhh
dCB5b3UgYXJlIGxvb2tpbmcgYXQgaG93IHRvIG1vZGlmeSBKdXN0aW4ncyBwcm9wb3NhbCwgYW5k
IEknbSBsb29raW5nIGF0IHdoYXQgYXJlIHRoZSByZXF1aXJlbWVudHMuDQoNCklnbm9yaW5nIHRo
ZSBzcGVjaWZpY3MsIGlzIHRoZXJlIGEgcmVhc29uIHdoeSBtdWx0aXBsZSB0b2tlbnMgbmVlZCB0
byBiZSByZXR1cm5lZCBpbiB0aGUgc2FtZSByZXF1ZXN0Pw0KDQoNCk9uIE1vbiwgSnVsIDIyLCAy
MDE5IGF0IDk6NDEgQU0gTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208bWFp
bHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNCg0KT24gMjEgSnVsIDIwMTks
IGF0IDIyOjIyLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o
YXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgTmVpbCwgSSBhZ3JlZSB0aGF0IGFuIGFjY2Vz
cyB0b2tlbiB0aGF0IGlzIHVzYWJsZSBhY3Jvc3MgcmVzb3VyY2VzIGlzIHByb2JsZW1hdGljLg0K
DQpIb3cgYXJlIHlvdSB0aGlua2luZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIHdvdWxkIGJlIHJl
dHVybmVkPw0KDQpXZWxsIHRoZXJlIGFyZSBsb3RzIG9mIHBvc3NpYmxlIHdheXMsIGUuZy46DQoN
CnsNCiJ0b2tlbnMiOiBbDQogICB7ICJyZXNvdXJjZSI6ICJodHRwczovL3JlczEiLCAiYWNjZXNz
X3Rva2VuIjogIi4uLiIgfSwNCiAgIHsgInJlc291cmNlIjogInJlczIiLCAuLi59LCAuLi4NCl0N
Cn0NCg0KSSdtIG5vdCBwYXJ0aWN1bGFybHkgd2VkZGVkIHRvIGFueSBmb3JtYXQuDQoNCldoeSBk
byB5b3UgdGhpbmsgdGhlIHJlcXVlc3QgbmVlZHMgdG8gcmV0dXJuIG11bHRpcGxlIHRva2VucyBy
YXRoZXIgdGhhbiBtYWtpbmcgYSBzZXBhcmF0ZSByZXF1ZXN0IGZvciBlYWNoIHRva2VuPyBUaGF0
IHdvdWxkIHNlZW0gdG8gc2ltcGxpZnkgdGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlIGFzIGNvbnRl
eHQgd291bGQgb25seSBuZWVkIHRvIHByb3ZpZGVkIGZvciB0aGUgb25lIGFjY2VzcyB0b2tlbi4N
Cg0KTm90ZSB0aGF0IGluIEFhcm9uJ3MgcHJvcG9zYWwgd2UgaGF2ZSBhICJ1c2VyIiBzZWN0aW9u
IG9uIChwcmVzdW1hYmx5KSBldmVyeSBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UsIHdoaWNoIGluZGlj
YXRlcyBhIHVzZXJpbmZvIGVuZHBvaW50IHRoYXQgaXRzZWxmIG5lZWRzIGFuIGFjY2VzcyB0b2tl
bi4gU28gZWl0aGVyIHRoZSBzYW1lIGFjY2VzcyB0b2tlbiBpcyB1c2VkIHRvIGFjY2VzcyB0aGF0
IHVzZXJpbmZvIGVuZHBvaW50ICh3aGljaCBtZWFucyB0aGF0IHRoZSBSUyBjYW4gYWxzbyBhY2Nl
c3MgdGhlIHVzZXJpbmZvIGVuZHBvaW50KSwgb3IgZWxzZSB3ZSBhbHJlYWR5IG5lZWQgdG8gcmV0
dXJuIGEgc2Vjb25kIGFjY2VzcyB0b2tlbiBpbiB0aGUgc2FtZSByZXF1ZXN0LCBlLmcuOg0KDQp7
DQogICAgICJhY2Nlc3NfdG9rZW4iOiB7DQogICAgICAgInZhbHVlIjogIlVNMVA5UE1IS1VSNjRU
QjhONkJXN09aQjhDREZPTlAyMTlSUDFMVDAiLA0KICAgICAgICJ0eXBlIjogImJlYXJlciINCiAg
ICAgfSwNCiAgICAgInVzZXIiOiB7DQogICAgICAgImlkIjogIjUwMzU2Nzg2NDIiLA0KICAgICAg
ICJ1c2VyaW5mbyI6ICJodHRwczovL2F1dGhvcml6YXRpb24tc2VydmVyLmNvbS91c2VyLzUwMzU2
Nzg2NDIiLA0KICAgICAgICJ1c2VyaW5mb19hdCI6ICJiMERsM0tzWFhPR2M3dFdmRkxaWXY3RzVi
WGsiDQogICAgIH0NCiAgIH0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgZ2V0IHRoZSBkZXNpcmUgdG8gaGF2ZSBtdWx0
aXBsZSB0b2tlbnMsIGJ1dCB0aGUgcmVhbCBjb3N0IGlzIHRoZSBleHBsb3Npb24gaW4gY29tcGxl
eGl0eSBmb3IgZXZlcnkgcGFydHkgaW4gdGhlIHN5c3RlbS4gVGhpcyBpcyBlc3BlY2lhbGx5IHRy
dWUgaWYgeW91IGFsbG93IHRoZSBjbGllbnQgdG8gc3BlY2lmeSBhIG1vcmUgZmluZS1ncmFpbmVk
IGFuZCBzdHJ1Y3R1cmVkIHJlc291cmNlIHRhcmdldCB0aGFuIGEgc2NvcGUgc3RyaW5nLCBidXQN
CiBldmVuIHdpdGggYSBzY29wZSBpdOKAmXMgcmVhbGx5IGNvbW1vbiB0byBoYXZlIGEgc2V0IG9m
IGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzIHRoYXQgcmVzcG9uZCB0byB0aGUgc2FtZSBzY29w
ZS4gVGhlIGJpZ2dlc3QgYnVyZGVuIGlzIG9uIHRoZSBjbGllbnQgd2hpY2ggbm93IGhhcyB0byBt
YXAgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgZnJvbSB0aGUgc2FtZSByZXF1ZXN0IHRvIGRpZmZl
cmVudCByZXNvdXJjZSB0YXJnZXRzLCBzb21lIG9mIHdoaWNoDQogaXQgbWlnaHQgYmUgZGlzY292
ZXJpbmcgYXQgcnVudGltZS4gQW5kIHRoZW4geW91IGhhdmUgdG8gZmlndXJlIG91dCB3aGF0IHRv
IGRvIGF0IHRoZSBBUyBpZiB0aGUgdXNlciBvbmx5IGFwcHJvdmVzIG9uZSByZXNvdXJjZSwgb3Ig
ZXZlbiB3b3JzZSwgb25lIHNjb3BlIHRoYXQgY292ZXJzIG11bHRpcGxlIHJlc291cmNlcy4gWW91
IG5lZWQgdG8gaGF2ZSB2ZXJ5IGNsZWFyIGxvZ2ljIG9mIGhvdyB5b3Ugc2VwYXJhdGUgdGhlc2Ug
aW50byBkaWZmZXJlbnQNCiBhY2Nlc3MgdG9rZW5zLCBhbmQgaG93IHlvdSBzaWduYWwgdGhhdCB0
byB0aGUgY2xpZW50LiBBbmQgdGhlbiB0aGVyZeKAmXMgdGhlIHF1ZXN0aW9uIG9mIHJlZnJlc2hp
bmcgdGhpbmdzIG9uY2UgdG9rZW5zIGV4cGlyZSAoYmVjYXVzZSBvZiBjb3Vyc2UgdGhleSBjb3Vs
ZCBoYXZlIGRpZmZlcmVudCBsaWZldGltZXMpIOKAlCBpbiBPQXV0aCB0aGF0IGltcGxpZXMgbXVs
dGlwbGUgcmVmcmVzaCB0b2tlbnMsIGluIFhZWiB0aGF0IGltcGxpZXMgbXVsdGlwbGUNCiB0cmFu
c2FjdGlvbiBoYW5kbGVzLiBJ4oCZbSBub3Qgc3VyZSB0aGlzIGNvbXBsZXhpdHkgaW4gdGhlIGdl
bmVyYWwgY2FzZSBpcyB3b3J0aCBpdCB0byBzb2x2ZSB0aGlzIHNwZWNpZmljIGlzc3VlLCB3aGlj
aCBzZWVtcyBsaWtlIGEgYml0IG9mIGFuIGVkZ2UgY29uZGl0aW9uIHRvIG1lLiBJIHJlYWxseSBk
b27igJl0IHRoaW5rIHdlIHNob3VsZCBtYWtlIHNpbXBsZSBjbGllbnRzIHBheSB0aGlzIGNvbXBs
ZXhpdHkgY29zdCBpZiB0aGV5IGRvbuKAmXQgaGF2ZQ0KIHRvLg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WFlaIGRvZXMgbWFrZSBhc2tpbmcgZm9y
IHNldmVyYWwgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgaW4gbXVsdGlwbGUgcmVxdWVzdHMgcG90
ZW50aWFsbHkgZWFzaWVyIHRocm91Z2ggdXNlIG9mIHRoZSDigJx1c2VyX2hhbmRsZeKAnSBjb25z
dHJ1Y3QgKGltcG9ydGVkIGZyb20gdGhlIFBDVCBjb25jZXB0IGluIFVNQTIpLiBUaGlzIGxldHMg
eW91IHNheSB0aGF0IHlvdSBhcyB0aGUgY2xpZW50IGFyZSBzYXlpbmcgaXTigJlzIHRoZSBzYW1l
DQogdXNlciBhbmQgdGhlIHNhbWUgY2xpZW50IGZvciBhIGRpZmZlcmVudCByZXNvdXJjZSBzZXQs
IGFuZCB0aGF0IG1pZ2h0IGJlIGVub3VnaCBmb3IgdGhlIEFTIHRvIGp1c3QgbGV0IHlvdSBoYXZl
IGEgdG9rZW4gd2l0aCB0aGUgZmlyc3QgY2FsbCB0byBpdCBhbmQgbm90IGhhdmUgdG8gZ2V0IHRo
ZSB1c2VyIGludm9sdmVkIGFnYWluLiBCdXQgdGhpcyBkb2VzbuKAmXQgcmVhbGx5IGhlbHAgaWYg
eW91IG5lZWQgdG8gYXNrIHRoZSB1c2VyIGNvbnNlbnQNCiBhIGJ1bmNoIG9mIHRpbWVzLCB3aGlj
aCBzZWVtcyB0byBiZSB3aGF0IHBlb3BsZSBhcmUgcmVhbGx5IGFmdGVyIHNvbHZpbmcgd2hlbiB0
aGV5IHRhbGsgYWJvdXQgZ2V0dGluZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLiBUaGUgcHJvYmxl
bSBpc27igJl0IGFza2luZyB0aGUgQVMsIHRoZSBwcm9ibGVtIGlzIGFza2luZyB0aGUgdXNlciwg
YW5kIHdl4oCZZCByZWFsbHkgbGlrZSB0byBib3RoZXIgdGhlbSBvbmNlIGFuZCBvbmx5IG9uY2Uu
Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj5TbyBtYXliZSB0aGUgcXVlc3Rpb24gaXNu4oCZdCBzbyBtdWNoIGFib3V0IG11bHRp
cGxlIGFjY2VzcyB0b2tlbnMsIGJ1dCBhY3R1YWxseSBhYm91dCBtdWx0aXBsZSBzaW11bHRhbmVv
dXMgdHJhbnNhY3Rpb25zIGluIGEgc2luZ2xlIHJlcXVlc3QuIEJlY2F1c2UgaWYgeW914oCZcmUg
ZG9pbmcgdGhhdCwgeW91IGhhdmUgYSBraW5kIG9mIG5hdHVyYWwgc2VwYXJhdGlvbiBiZXR3ZWVu
IHRoZSByZXF1ZXN0cyAoZWFjaCB3b3VsZCBnZXQNCiBpdHMgb3duIHRyYW5zYWN0aW9uIGtleXMg
YW5kIHRva2VucyksIGJ1dCB5b3UgY291bGQgY29tYmluZSB0aGUgaW50ZXJhY3Rpb24gcG9ydGlv
biB3aGVuIGl04oCZcyBuZWVkZWQgYW5kIG9ubHkgYm90aGVyIHRoZSB1c2VyIG9uY2UgZm9yIG11
bHRpcGxlIHRoaW5ncy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRp
dj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+T24gSnVsIDIzLCAyMDE5LCBhdCA2OjEwIEFNLCBOZWlsIE1hZGRlbiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20iIGNsYXNzPSIiPm5laWwubWFk
ZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt
aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JZiB3
ZSBmb2xsb3cgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBhdXRob3JpdHkgdGhlbiBhIHRva2VuIHNo
b3VsZCBiZSBzY29wZWQgYXMgbmFycm93bHkgYXMgcG9zc2libGUgdG8gYSBwYXJ0aWN1bGFyIHJl
c291cmNlIHNlcnZlci9yZXNvdXJjZS90aW1lIHBlcmlvZC90cmFuc2FjdGlvbi4gVGhlIHNlY3Vy
aXR5IHRvcGljcyBCQ1AgaGFzIGFscmVhZHkgZ29uZSBxdWl0ZSBmYXIgZG93biB0aGlzIHBhdGgg
aW4gaXRzIHJlY29tbWVuZGF0aW9uczoNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMyNzZWN0aW9uLTMuMyIgY2xh
c3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1
cml0eS10b3BpY3MtMTMjc2VjdGlvbi0zLjM8L2E+IC4gTGVhc3QgcHJpdmlsZWdlIG5hdHVyYWxs
eSBsZWFkcyB0byBjbGllbnRzIG5lZWRpbmcgbW9yZSB0b2tlbnMsIHNvIHdlIHNob3VsZCBtYWtl
IG9idGFpbmluZyAoYW5kIHVzaW5nKSBtdWx0aXBsZSB0b2tlbnMgYXMgZnJpY3Rpb25sZXNzIGFz
IHBvc3NpYmxlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkZvciBhbiBleGFtcGxlIG9m
IHRoaXMsIHNlZSB0aGUgd29yayBkb25lIGJ5IG15IGNvbGxlYWd1ZXMgdG8gc2ltcGxpZnkganVn
Z2xpbmcgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBmb3IgZGlmZmVyZW50IHJlc291cmNlIHNlcnZl
cnMgLQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cubnBtanMuY29tL3BhY2thZ2UvYXBwYXV0aGhlbHBl
ciIgY2xhc3M9IiI+aHR0cHM6Ly93d3cubnBtanMuY29tL3BhY2thZ2UvYXBwYXV0aGhlbHBlcjwv
YT4gLiBUaGUgbGlicmFyeSBhbGxvd3MgdGhlIGRldmVsb3BlciB0byBzcGVjaWZ5IHdoaWNoIHNj
b3BlcyBhcmUgdXNlZCBmb3Igd2hpY2ggUlM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVzb3VyY2VTZXJ2ZXJzOiB7PGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cHM6
Ly9sb2dpbi5leGFtcGxlLmNvbS9vYXV0aDIvdXNlcmluZm8iIGNsYXNzPSIiPmh0dHBzOi8vbG9n
aW4uZXhhbXBsZS5jb20vb2F1dGgyL3VzZXJpbmZvPC9hPiZxdW90OzogJnF1b3Q7cHJvZmlsZSZx
dW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmcXVvdDs8YSBocmVmPSJodHRwczovL3JzLmV4YW1wbGUuY29tLyIgY2xhc3M9IiI+aHR0
cHM6Ly9ycy5leGFtcGxlLmNvbS88L2E+JnF1b3Q7OiAmcXVvdDtyc19jdXN0b21fc2NvcGUmcXVv
dDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt9LDxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NClRoZSBsaWJyYXJ5IHRoZW4gdGFrZXMgY2FyZSBvZiBtYWtpbmcgbXVsdGlwbGUg
cmVxdWVzdHMgdG8gZ2V0IGFwcHJvcHJpYXRlbHktc2NvcGVkIGFjY2VzcyB0b2tlbnMgYW5kIHRo
ZW4gYXR0YWNoaW5nIHRoZW0gdG8gYXBwcm9wcmlhdGUgcmVxdWVzdHMuIEJ1dCB0aGUgbW9yZSBy
ZXNvdXJjZSBzZXJ2ZXJzIHlvdSBuZWVkIHRvIGFjY2VzcywgdGhlIG1vcmUgdG9rZW5zIHlvdSBu
ZWVkIGFuZCB0aGUgbW9yZSByZXF1ZXN0cyB5b3UgaGF2ZSB0byBtYWtlLg0KIFRoZXJlIGlzIHRo
ZXJlZm9yZSBjdXJyZW50bHkgYSAmcXVvdDt0YXgmcXVvdDsgb24gbGVhc3QgcHJpdmlsZWdlIHVz
ZSBvZiBhY2Nlc3MgdG9rZW5zIGFzIGl0IGlzIGFsbCBvbiB0aGUgY2xpZW50IHRvIGp1Z2dsZSB0
aGVzZSByZXF1ZXN0cywgZ2l2aW5nIGFuIGluY2VudGl2ZSBmb3IgY2xpZW50cyB0byBpbnN0ZWFk
IHJlcXVlc3QgQmlnIFRva2VucyB0aGF0IGdyYW50IGxvdHMgb2YgYXV0aG9yaXR5IGluIGEgc2lu
Z2xlIHJlcXVlc3QvcmVzcG9uc2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gTmVp
bDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIDIyIEp1bCAyMDE5LCBhdCAyMjo0NiwgRGljayBIYXJk
dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiBjbGFzcz0iIj5kaWNr
LmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCkhpIE5laWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHNlZSB0aGF0IHlvdSBh
cmUgbG9va2luZyBhdCBob3cgdG8gbW9kaWZ5IEp1c3RpbidzIHByb3Bvc2FsLCBhbmQgSSdtIGxv
b2tpbmcgYXQgd2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpJZ25vcmluZyB0aGUgc3BlY2lmaWNzLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgbXVs
dGlwbGUgdG9rZW5zIG5lZWQgdG8gYmUgcmV0dXJuZWQgaW4gdGhlIHNhbWUgcmVxdWVzdD88YnIg
Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBNb24sIEp1bCAyMiwg
MjAxOSBhdCA5OjQxIEFNIE5laWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRk
ZW5AZm9yZ2Vyb2NrLmNvbSIgY2xhc3M9IiI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPk9uIDIxIEp1bCAyMDE5LCBhdCAyMjoyMiwgRGljayBIYXJkdCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiBjbGFzcz0iIj5kaWNrLmhhcmR0
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhp
IE5laWwsIEkgYWdyZWUgdGhhdCBhbiBhY2Nlc3MgdG9rZW4gdGhhdCBpcyB1c2FibGUgYWNyb3Nz
IHJlc291cmNlcyBpcyBwcm9ibGVtYXRpYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpI
b3cgYXJlIHlvdSB0aGlua2luZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIHdvdWxkIGJlIHJldHVy
bmVkPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCldlbGwgdGhl
cmUgYXJlIGxvdHMgb2YgcG9zc2libGUgd2F5cywgZS5nLjo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQp7PGJyIGNsYXNzPSIiPg0KJnF1b3Q7dG9rZW5zJnF1b3Q7OiBbPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7eyAmcXVvdDtyZXNvdXJjZSZxdW90OzogJnF1b3Q7PGEgaHJl
Zj0iaHR0cHM6Ly9yZXMxIiBjbGFzcz0iIj5odHRwczovL3JlczE8L2E+JnF1b3Q7LCAmcXVvdDth
Y2Nlc3NfdG9rZW4mcXVvdDs6ICZxdW90Oy4uLiZxdW90OyB9LA0KPGJyIGNsYXNzPSIiPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7eyAmcXVvdDtyZXNvdXJjZSZxdW90OzogJnF1b3Q7cmVzMiZxdW90Oywg
Li4ufSwgLi4uPGJyIGNsYXNzPSIiPg0KXTxiciBjbGFzcz0iIj4NCn08YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpJJ20gbm90IHBhcnRpY3VsYXJseSB3ZWRkZWQgdG8gYW55IGZvcm1hdC48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz
cz0iIj5XaHkgZG8geW91IHRoaW5rIHRoZSByZXF1ZXN0IG5lZWRzIHRvIHJldHVybiBtdWx0aXBs
ZSB0b2tlbnMgcmF0aGVyIHRoYW4gbWFraW5nIGEgc2VwYXJhdGUgcmVxdWVzdCBmb3IgZWFjaCB0
b2tlbj8gVGhhdCB3b3VsZCBzZWVtIHRvIHNpbXBsaWZ5IHRoZSByZXF1ZXN0IGFuZCByZXNwb25z
ZSBhcyBjb250ZXh0IHdvdWxkIG9ubHkgbmVlZCB0byBwcm92aWRlZCBmb3IgdGhlIG9uZSBhY2Nl
c3MNCiB0b2tlbi48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpO
b3RlIHRoYXQgaW4gQWFyb24ncyBwcm9wb3NhbCB3ZSBoYXZlIGEgJnF1b3Q7dXNlciZxdW90OyBz
ZWN0aW9uIG9uIChwcmVzdW1hYmx5KSBldmVyeSBhY2Nlc3MgdG9rZW4gcmVzcG9uc2UsIHdoaWNo
IGluZGljYXRlcyBhIHVzZXJpbmZvIGVuZHBvaW50IHRoYXQgaXRzZWxmIG5lZWRzIGFuIGFjY2Vz
cyB0b2tlbi4gU28gZWl0aGVyIHRoZSBzYW1lIGFjY2VzcyB0b2tlbiBpcyB1c2VkIHRvIGFjY2Vz
cyB0aGF0IHVzZXJpbmZvIGVuZHBvaW50ICh3aGljaCBtZWFucw0KIHRoYXQgdGhlIFJTIGNhbiBh
bHNvIGFjY2VzcyB0aGUgdXNlcmluZm8gZW5kcG9pbnQpLCBvciBlbHNlIHdlIGFscmVhZHkgbmVl
ZCB0byByZXR1cm4gYSBzZWNvbmQgYWNjZXNzIHRva2VuIGluIHRoZSBzYW1lIHJlcXVlc3QsIGUu
Zy46PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KezxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2FjY2Vzc190b2tlbiZxdW90OzogezxiciBjbGFz
cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O3Zh
bHVlJnF1b3Q7OiAmcXVvdDtVTTFQOVBNSEtVUjY0VEI4TjZCVzdPWkI4Q0RGT05QMjE5UlAxTFQw
JnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZxdW90O3R5cGUmcXVvdDs6ICZxdW90O2JlYXJlciZxdW90OzxiciBjbGFzcz0iIj4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO30sPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7dXNlciZxdW90OzogezxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2lkJnF1b3Q7OiAm
cXVvdDs1MDM1Njc4NjQyJnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O3VzZXJpbmZvJnF1b3Q7OiAmcXVvdDs8YSBocmVm
PSJodHRwczovL2F1dGhvcml6YXRpb24tc2VydmVyLmNvbS91c2VyLzUwMzU2Nzg2NDIiIGNsYXNz
PSIiPmh0dHBzOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tL3VzZXIvNTAzNTY3ODY0MjwvYT4m
cXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7JnF1b3Q7dXNlcmluZm9fYXQmcXVvdDs6ICZxdW90O2IwRGwzS3NYWE9HYzd0V2ZGTFpZ
djdHNWJYayZxdW90OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O308YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt9PGJyIGNsYXNzPSIiPg0KPC9ibG9j
a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9
IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYu
b3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A4DAC4DCE3AC43F8B951E6AC2C523C95mitedu_--


From nobody Wed Jul 24 07:00: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 678B1120088 for ; Wed, 24 Jul 2019 07:00:15 -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=ubisecure.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbSWVa9wHsjz for ; Wed, 24 Jul 2019 07:00:12 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5478512006F for ; Wed, 24 Jul 2019 07:00:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hTuSO/t4YqlpaYbX6Pr4QExw/s98xMbPFL0MG6glLxd5Kuiv6mORzrzo/+dyIzHtGFC/djZ8iCZ/NDpJCnt2k+uUSgUK2aOebxS2uAkYagkTTqIAXJwdo2GMY7GKjh0FJdBY/MFAKzHfIcvvnh4jcEYmoZRJEWLONU53qG677u9DAzbIL4btmjPfosVD+Cy3t/dkLRotscnnULIeLLReOklrJWZcf3rSHXfb+NCSv2tuKYRAJvesgVEpuOtiFGNloCFZ1mdLcWbAdX8Xmu2tLfmdaiHG7Wx1S4TUG6UpypkOViSfuOpc0luD0YwX+0pPlXA1uPpvx9/rCl2+1wDLrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zeDDrRMSKwipvHTJ2Krs/rP+/dEBb2dAroQQBbwisUM=; b=bxbJ0xIhXpta0/FHwEIVDwhz6IEivgRVByEcnbQmcl6oaThr6KE+r5mg92C2isMpzBx40VsfJfI6+2c7vHVTHwd5DxVLfdjN+WIRl1kbJM2+2dLLo5d56Fr0W9PJr3LnIgXy35GBuB79GbKyQoYtZzroBQKYCswsqh1ff+zj7GBvlBALhIyiy2uOpzu3DzyvCN/ODU+yAvgdZ85e9J1QaL0opqO02nw/fHipSGlTvQ/q63jrOtbJz92E+2ao3c/R0GQQV4PaNAt+qm3hACNyT7G5+nvjAX5BvSkNetW6FuiArmJN/4gPyzw5nL1RZnCiuEarGyJgcpyWLY1/9qxqvg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ubisecure.com;dmarc=pass action=none header.from=ubisecure.com;dkim=pass header.d=ubisecure.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubisecure.onmicrosoft.com; s=selector2-ubisecure-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zeDDrRMSKwipvHTJ2Krs/rP+/dEBb2dAroQQBbwisUM=; b=NR3gC69K0RiXme9Ws1VKo/j+L1HHcz1EDMrKJ+ysiTFiC2rDtO72rem1UwFESxLLGUPJShWjNnam2CcTJkMX4r1dKcvce8K2i5tt0TkIgPJGxsOJJ8qTYv1mjAv8+ctxu9OLbWlc+z0QXXwYRWpP4E9Nu0ZP7dBSZOoEXH2M94I=
Received: from HE1PR05MB4713.eurprd05.prod.outlook.com (20.176.164.14) by HE1PR05MB4522.eurprd05.prod.outlook.com (20.176.163.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Wed, 24 Jul 2019 14:00:09 +0000
Received: from HE1PR05MB4713.eurprd05.prod.outlook.com ([fe80::30b1:6957:654:6a3f]) by HE1PR05MB4713.eurprd05.prod.outlook.com ([fe80::30b1:6957:654:6a3f%7]) with mapi id 15.20.2094.013; Wed, 24 Jul 2019 14:00:09 +0000
From: Petteri Stenius 
To: "oauth@ietf.org" , Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
Thread-Index: AQHVP8O1aR003BiBLUSq4eEKB3WORqbZzhjg
Date: Wed, 24 Jul 2019 14:00:04 +0000
Message-ID: 
References: <156371372426.20589.10365011724092335159@ietfa.amsl.com>
In-Reply-To: <156371372426.20589.10365011724092335159@ietfa.amsl.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=Petteri.Stenius@ubisecure.com; 
x-originating-ip: [195.197.205.34]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: daa2c45b-280a-4574-5dcf-08d7103f3d31
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR05MB4522; 
x-ms-traffictypediagnostic: HE1PR05MB4522:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(396003)(39840400004)(366004)(13464003)(189003)(199004)(68736007)(186003)(6666004)(76176011)(26005)(8936002)(71200400001)(7696005)(6506007)(102836004)(81156014)(81166006)(71190400001)(8676002)(14444005)(25786009)(11346002)(2906002)(316002)(446003)(99286004)(256004)(86362001)(6116002)(476003)(305945005)(3846002)(74316002)(7736002)(66574012)(229853002)(52536014)(486006)(2501003)(5660300002)(66066001)(66446008)(33656002)(66556008)(66476007)(64756008)(66946007)(76116006)(6306002)(9686003)(508600001)(110136005)(14454004)(966005)(6436002)(55016002)(6246003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB4522; H:HE1PR05MB4713.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ubisecure.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: PzXF+etqwgsZ7UhM5yeHkFQ4CnQGaP4bLccHR3mfpN14BuKbp31ypmUc9PuDXiVWybVDL9kfl+FJQq7Uhpb/BA53eO76FfJX1NQzGDq75FmePbmWfE7CS+spNfND6Kt+C4Vxl3urt7JEq/UwILUz/XOioehBHsJgeG2CLQ3FdbFyKuktm1Qzl6NwMpDiksFGKX9Zdnu2Z/WgGUksDuE+EYiCdrO2iEl/xuVHBdKc7fQjIkRY4UgoE2J/D2kuaeQXiZMCV5v/9ZRJGBMPKefS8Hb2WB2bt/P+lGIgrdAHBPFDYyWmCj8hSRKpeHB/bfTB7zsIeQ55gUijeyyHb1S5GXjQOt2RhFCUG2uPNtdA6pKPtbUGV7F2gS2WlHmPd2RBgK1CBoRY2Fpmx/k1mP6Fz6UKjZd44eoB6AiphmU5Zn0=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ubisecure.com
X-MS-Exchange-CrossTenant-Network-Message-Id: daa2c45b-280a-4574-5dcf-08d7103f3d31
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 14:00:04.1272 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: feaa1139-6ffc-4422-9c7b-980ad003c1a7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Petteri.Stenius@ubisecure.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB4522
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 14:00:16 -0000

Hi Vittorio,

Thanks for working on this. I think this will be valuable. I have a couple =
of comments.

About relationship of this draft with token exchange, introspection and rev=
ocation:

Should there be a distinct Token Type Identifier defined for JWT Access Tok=
en, to enable exchange of reference type access token and value type access=
 token? I'm thinking of a use case where I want authorization code flow to =
return an opaque reference token and I want my backend services to exchange=
 this into a value token, to avoid further introspection on the backend sid=
e.

Introspection (and userinfo) with JWT Access Token should work as expected.=
 If a JWT Access Token is revoked then introspection response should become=
 negative. Is it reasonable to add text that advises the resource server to=
 invoke introspection if it wants to make sure the token has not been revok=
ed?


Thanks,
Petteri


-----Original Message-----
From: OAuth  On Behalf Of internet-drafts@ietf.org
Sent: sunnuntai 21. hein=E4kuuta 2019 15.55
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt


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

        Title           : JSON Web Token (JWT) Profile for OAuth 2.0 Access=
 Tokens
        Author          : Vittorio Bertocci
	Filename        : draft-ietf-oauth-access-token-jwt-01.txt
	Pages           : 15
	Date            : 2019-07-20

Abstract:
   This specification defines a profile for issuing OAuth2 access tokens
   in JSON web token (JWT) format.  Authorization servers and resource
   servers from different vendors can leverage this profile to issue and
   consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01


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

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

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


From nobody Wed Jul 24 07:12: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 2697E120300 for ; Wed, 24 Jul 2019 07:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 4E2xZpvYeMgO for ; Wed, 24 Jul 2019 07:12:43 -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 73A0A120131 for ; Wed, 24 Jul 2019 07:12:43 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x6OECsgd025888; Wed, 24 Jul 2019 10:13:13 -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; Wed, 24 Jul 2019 10:11: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; Wed, 24 Jul 2019 10:12:12 -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, 24 Jul 2019 10:12:12 -0400
From: Justin Richer 
To: Nat Sakimura 
CC: Dick Hardt , oauth 
Thread-Topic: [OAUTH-WG] Transaction Authorization
Thread-Index: AQHVNo8uPlHZsW3ub0m+zkQfIAjEo6bV7DYAgAE8y4CAAwCBAA==
Date: Wed, 24 Jul 2019 14:12:12 +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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_EABD1584153B47758A5FD6D55A6B5795mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 14:12:51 -0000

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

SeKAmW0gZGVmaW5pdGVseSBpbiBmYXZvciBvZiBzZXBhcmF0aW5nIHRoZSDigJxwZXJzb24gdXNp
bmcgdGhlIGNsaWVudCBzb2Z0d2FyZeKAnSBmcm9tIHRoZSDigJxwZXJzb24gbWFraW5nIHRoZSBh
dXRob3JpemF0aW9uIGRlY2lzaW9u4oCdIGFuZCBhbGxvd2luZyB0aGVtIHRvIGJlIHRoZSBzYW1l
IHBlcnNvbiB3aXRob3V0IGNoYW5naW5nIHRoZSBwcm90b2NvbC4gVU1BIGhhcyB0aGF0IHNlcGFy
YXRpb24sIGJ1dCBkb2VzbuKAmXQgaGFuZGxlIHRoZSBjb2xsYXBzZWQgY2FzZSB2ZXJ5IHdlbGwg
aW4gbXkgb3BpbmlvbiAoaW4gc3BpdGUgb2YgYmVzdCBlZmZvcnRzIHRvIGFsbG93IGl0KS4gT0F1
dGggYXNzdW1lcyB0aGV54oCZcmUgYWx3YXlzIHRoZSBzYW1lIGJ1dCBjYW4gYmUgdHdlYWtlZCB0
byBtYWtlIHRoZW0gZGlmZmVyZW50IHNvbWV0aW1lcyAobGlrZSBDSUJB4oCZcyBjYWxsIGNlbnRl
ciB1c2UgY2FzZSksIGJ1dCBpdOKAmXMgbm90IHJlYWxseSBzZXQgdXAgZm9yIHRoYXQuDQoNCkkg
dGhpbmsgd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byBnZXQgdGhpcyByaWdodCBpbiBYWVogYmVj
YXVzZSB3ZSBoYXZlIGEgbW9yZSBmbGV4aWJsZSB3YXkgb2YgZGVmaW5pbmcg4oCcaG93IEkgY2Fu
IGludGVyYWN0IHdpdGggYSB1c2Vy4oCdIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sLCBhcyB3ZWxs
IGFzIOKAnGFueXRoaW5nIEkga25vdyBhYm91dCB0aGUgdXNlciBhbHJlYWR54oCdIGZvciB0aGUg
Y2xpZW50IHRvIHB1c2ggaW4uIFRoaXMgY291bGQgYmUgdXNlZCBhcyBhIHNpZ25hbCB0byB0aGUg
QVMgdGhhdCB0aGUgZW5kIHVzZXIgYW5kIHJlc291cmNlIG93bmVyIGFyZSBkaWZmZXJlbnQgcGFy
dGllcyBhbmQgaXQgc2hvdWxkIGdvIGJ1ZyBzb21lb25lIHRocm91Z2ggYW4gYXN5bmNocm9ub3Vz
IGNoYW5uZWwgZm9yIGFwcHJvdmFsLg0KDQpBcyBmb3IgdGhlIHJlc3Qgb2YgTmF04oCZcyBsaXN0
IGJlbG93LCB0aGF04oCZcyBhIGhlZnR5IGZlYXR1cmUgc2V0LiBJZiB3ZSBwaWNrIHVwIHRoaXMg
d29yaywgSSB0aGluayBhIGZldyBvZiB0aGVzZSBtaWdodCBmaXQgYmV0dGVyIGludG8gYSBjb21w
YW5pb24gc3BlYywgYnV0IHRoZXkgYXJlIGFsbCBkZWZpbml0ZWx5IHdvcnRoIGRpc2N1c3Npbmcu
IEkgd291bGQgcGVyc29uYWxseSByYXRoZXIgYnJpbmcgYWxsIHRoZSBwaWVjZXMgdG9nZXRoZXIg
YW5kIGZpZ3VyZSBvdXQgaG93IHRvIHNsaWNlIHRoZW0gYXBhcnQgdGhhbiBoYXZlIHNvbWV0aGlu
ZyBpbmNvbXBsZXRlIHRoYXQgbmVlZHMgdG8gYmUgYm9sdGVkIG9uIHRvIGZvciBhbnlvbmUgdG8g
dXNlIGl0Lg0KDQrigJQgSnVzdGluDQoNCk9uIEp1bCAyMiwgMjAxOSwgYXQgMTI6MjEgUE0sIE5h
dCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+
PiB3cm90ZToNCg0KKzENCg0KQWxzbywgaWYgaXQgd2VyZSB0byBpbmNsdWRlIHVzZXIgaWRlbnRp
ZmljYXRpb24gaW4gdGhlIHByb3RvY29sLCBJDQp3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIHNwZWMg
YXQgbGVhc3QgY292ZXIgdGhlIGZvbGxvd2luZzoNCg0KMC4gVXNlcg0KMS4gRXh0ZXJuYWwgSWRl
bnRpdHkgUHJvdmlkZXINCjIuIFJlc291cmNlcyB0aGF0IGNvdmVycyB0aGUgZnVuY3Rpb25hbGl0
eSBvZiBQRVAuDQozLiBBdXRob3JpemF0aW9uIFNlcnZlciB0aGF0IGFjdCBhcyBQRFAgZm9yICBS
ZXNvdXJjZXMuDQo0LiBJbnRlcm5hbCBJZGVudGl0eSBTZXJ2ZXIgd2l0aGluIHRoZSByZXNvdXJj
ZSBkb21haW4uDQo1LiBDbGllbnQgQVBQIGNvbXBvbmVudA0KNi4gQ2xpZW50IFNlcnZlciBjb21w
b25lbnQNCg0KSW4gYWRkaXRpb24sIGl0IHdvdWxkIGJlIGdvb2QgdG8gZGVsaW5lYXRlIHRoZSBy
ZXNvdXJjZSBvd25lciAoYW4NCmVudGl0eSB0aGF0IGhhcyBhZG1pbmlzdHJhdGl2ZSByaWdodHMg
b3ZlciB0aGUgc2V0IG9mIHJlc291cmNlcykgYW5kDQp0aGUgZW5kIHVzZXIgd2hvIGlzIGluIHRo
ZSBwcm90b2NvbCBmbG93Lg0KDQpUaGF0IGFjdHVhbGx5IGFza3MgZm9yIHRoZSBmb2xsb3dpbmcg
YWRkaXRpb25hbCBlbnRpdGllczoNCg0KNy4gUmVzb3VyY2UgQWRtaW5pc3RyYXRvcg0KOC4gUEFQ
L1BJUA0KDQpJdCBpcyBwcm9iYWJseSBhIGdvb2QgaWRlYSB0byBzdGF0ZSB0aGUgc2VjdXJpdHkg
dGFyZ2V0IGFzIHdlbGwuDQoNClJlOiBTdGFydGluZyBmcm9tIFJlc291cmNlLg0KDQpZZXMuIEkg
YWdyZWUgdGhhdCB0aGlzIGlzIGEgdmFsaWQgdXNlIGNhc2UuIEF0IHRoZSBzYW1lIHRpbWUsIHRo
ZXJlDQpjYW4gYmUgY2FzZXMgd2hlcmUgdGhlIGNvbmNyZXRlIHJlc291cmNlIGVuZHBvaW50IGlz
IG5vdCBrbm93biBiZWZvcmUNCnRoZSB1c2VyIGF1dGhvcml6YXRpb24uIFNvLCB0aGUgcHJvdG9j
b2wgbmVlZHMgdG8gYmUgYWJsZSB0byBzdGFydA0KYm90aCB3YXlzLCBJIGd1ZXNzLg0KDQpDaGVl
cnMsDQoNCk5hdCBTYWtpbXVyYQ0KDQoNCk9uIFN1biwgSnVsIDIxLCAyMDE5IGF0IDU6MjggUE0g
RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu
Y29tPj4gd3JvdGU6DQoNCkhleSBKdXN0aW4NCg0KQSBmZXcgdXNlIGNhc2VzIHRoYXQgaGlnaGxp
Z2h0IGhvdyB0aGUgd29ybGQgaXMgZGlmZmVyZW50IG5vdyB0aGFuIGl0IHdhcyB3aGVuIE9BdXRo
IDIuMCB3YXMgZGV2ZWxvcGVkIHdvdWxkIGhlbHAgcGFydGljaXBhbnRzIHVuZGVyc3RhbmQgd2h5
IGNoYW5nZXMgYXJlIG5lZWRlZCwgYW5kIGFsc28gcHJvdmlkZSBhIHJlZmVyZW5jZSBmb3IgY29t
cGFyaW5nIGFuZCBjb250cmFzdGluZyBkaWZmZXJlbnQgYXBwcm9hY2hlcy4NCg0KT25lIG9mIG15
IGZpcnN0IGNvbW1lbnRzIGlzIHdoeSB0aGUgY2xpZW50IGlzIHN0YXJ0aW5nIG9mZiBtYWtpbmcg
Y2FsbHMgdG8gdGhlIEFTLiBUaGVyZSBhcmUgdGltZXMgd2hlbiB0aGUgQVMgaXMgbm90IGtub3du
IGZvciBhIGdpdmVuIHJlc291cmNlLiBXaHkgbm90IGFsbG93IHN0YXJ0aW5nIGF0IHJlc291cmNl
Pw0KDQoNCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMTI6NDggUE0gSnVzdGluIFJpY2hlciA8anJp
Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KSSBoYXZlIHJl
cXVlc3RlZCB0aW1lIHRvIHByZXNlbnQgVHJhbnNhY3Rpb25hbCBBdXRob3JpemF0aW9uICh0aGUg
WFlaIHByb2plY3QpIGF0IHRoZSBNb250cmVhbCBtZWV0aW5nIGluIGEgY291cGxlIHdlZWtzLiBB
aGVhZCBvZiB0aGF0LCBJ4oCZdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgc3BlYzoN
Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFs
LWF1dGh6LTAyDQoNCkFkZGl0aW9uYWxseSwgSeKAmXZlIHVwZGF0ZWQgdGhlIHdyaXRldXAgYW5k
IGV4YW1wbGVzIG9uIGh0dHBzOi8vb2F1dGgueHl6Lw0KDQpJIHBsYW4gdG8gYmUgaW4gTW9udHJl
YWwgZm9yIHRoZSB3aG9sZSB3ZWVrLCBhbmQgSeKAmXZlIHJlcXVlc3RlZCBmcm9tIHRoZSBjaGFp
cnMgdGhhdCBJIHByZXNlbnQgZHVyaW5nIHRoZSBUdWVzZGF5IHNlc3Npb24gZHVlIHRvIGxpbWl0
ZWQgYXZhaWxhYmlsaXR5IG9mIHNvbWUga2V5IFdHIG1lbWJlcnMgb24gRnJpZGF5Lg0KDQrigJQg
SnVzdGluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h
aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklE
IEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJltIGRlZmluaXRlbHkgaW4gZmF2b3Igb2Yg
c2VwYXJhdGluZyB0aGUg4oCccGVyc29uIHVzaW5nIHRoZSBjbGllbnQgc29mdHdhcmXigJ0gZnJv
bSB0aGUg4oCccGVyc29uIG1ha2luZyB0aGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbuKAnSBhbmQg
YWxsb3dpbmcgdGhlbSB0byBiZSB0aGUgc2FtZSBwZXJzb24gd2l0aG91dCBjaGFuZ2luZyB0aGUg
cHJvdG9jb2wuIFVNQSBoYXMgdGhhdCBzZXBhcmF0aW9uLCBidXQgZG9lc27igJl0IGhhbmRsZSB0
aGUgY29sbGFwc2VkDQogY2FzZSB2ZXJ5IHdlbGwgaW4gbXkgb3BpbmlvbiAoaW4gc3BpdGUgb2Yg
YmVzdCBlZmZvcnRzIHRvIGFsbG93IGl0KS4gT0F1dGggYXNzdW1lcyB0aGV54oCZcmUgYWx3YXlz
IHRoZSBzYW1lIGJ1dCBjYW4gYmUgdHdlYWtlZCB0byBtYWtlIHRoZW0gZGlmZmVyZW50IHNvbWV0
aW1lcyAobGlrZSBDSUJB4oCZcyBjYWxsIGNlbnRlciB1c2UgY2FzZSksIGJ1dCBpdOKAmXMgbm90
IHJlYWxseSBzZXQgdXAgZm9yIHRoYXQuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHdlIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZ2V0
IHRoaXMgcmlnaHQgaW4gWFlaIGJlY2F1c2Ugd2UgaGF2ZSBhIG1vcmUgZmxleGlibGUgd2F5IG9m
IGRlZmluaW5nIOKAnGhvdyBJIGNhbiBpbnRlcmFjdCB3aXRoIGEgdXNlcuKAnSBhcyBwYXJ0IG9m
IHRoZSBwcm90b2NvbCwgYXMgd2VsbCBhcyDigJxhbnl0aGluZyBJIGtub3cgYWJvdXQgdGhlIHVz
ZXIgYWxyZWFkeeKAnSBmb3IgdGhlIGNsaWVudCB0byBwdXNoIGluLiBUaGlzDQogY291bGQgYmUg
dXNlZCBhcyBhIHNpZ25hbCB0byB0aGUgQVMgdGhhdCB0aGUgZW5kIHVzZXIgYW5kIHJlc291cmNl
IG93bmVyIGFyZSBkaWZmZXJlbnQgcGFydGllcyBhbmQgaXQgc2hvdWxkIGdvIGJ1ZyBzb21lb25l
IHRocm91Z2ggYW4gYXN5bmNocm9ub3VzIGNoYW5uZWwgZm9yIGFwcHJvdmFsLjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgZm9yIHRo
ZSByZXN0IG9mIE5hdOKAmXMgbGlzdCBiZWxvdywgdGhhdOKAmXMgYSBoZWZ0eSBmZWF0dXJlIHNl
dC4gSWYgd2UgcGljayB1cCB0aGlzIHdvcmssIEkgdGhpbmsgYSBmZXcgb2YgdGhlc2UgbWlnaHQg
Zml0IGJldHRlciBpbnRvIGEgY29tcGFuaW9uIHNwZWMsIGJ1dCB0aGV5IGFyZSBhbGwgZGVmaW5p
dGVseSB3b3J0aCBkaXNjdXNzaW5nLiBJIHdvdWxkIHBlcnNvbmFsbHkgcmF0aGVyIGJyaW5nIGFs
bCB0aGUgcGllY2VzDQogdG9nZXRoZXIgYW5kIGZpZ3VyZSBvdXQgaG93IHRvIHNsaWNlIHRoZW0g
YXBhcnQgdGhhbiBoYXZlIHNvbWV0aGluZyBpbmNvbXBsZXRlIHRoYXQgbmVlZHMgdG8gYmUgYm9s
dGVkIG9uIHRvIGZvciBhbnlvbmUgdG8gdXNlIGl0LjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv
cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48
L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDIyLCAyMDE5LCBhdCAxMjoyMSBQTSwg
TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiBjbGFz
cz0iIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i
QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i
Ij4mIzQzOzE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbHNvLCBpZiBpdCB3ZXJlIHRv
IGluY2x1ZGUgdXNlciBpZGVudGlmaWNhdGlvbiBpbiB0aGUgcHJvdG9jb2wsIEk8YnIgY2xhc3M9
IiI+DQp3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIHNwZWMgYXQgbGVhc3QgY292ZXIgdGhlIGZvbGxv
d2luZzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQowLiBVc2VyPGJyIGNsYXNzPSIiPg0K
MS4gRXh0ZXJuYWwgSWRlbnRpdHkgUHJvdmlkZXI8YnIgY2xhc3M9IiI+DQoyLiBSZXNvdXJjZXMg
dGhhdCBjb3ZlcnMgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgUEVQLjxiciBjbGFzcz0iIj4NCjMuIEF1
dGhvcml6YXRpb24gU2VydmVyIHRoYXQgYWN0IGFzIFBEUCBmb3IgJm5ic3A7UmVzb3VyY2VzLjxi
ciBjbGFzcz0iIj4NCjQuIEludGVybmFsIElkZW50aXR5IFNlcnZlciB3aXRoaW4gdGhlIHJlc291
cmNlIGRvbWFpbi48YnIgY2xhc3M9IiI+DQo1LiBDbGllbnQgQVBQIGNvbXBvbmVudDxiciBjbGFz
cz0iIj4NCjYuIENsaWVudCBTZXJ2ZXIgY29tcG9uZW50PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KSW4gYWRkaXRpb24sIGl0IHdvdWxkIGJlIGdvb2QgdG8gZGVsaW5lYXRlIHRoZSByZXNv
dXJjZSBvd25lciAoYW48YnIgY2xhc3M9IiI+DQplbnRpdHkgdGhhdCBoYXMgYWRtaW5pc3RyYXRp
dmUgcmlnaHRzIG92ZXIgdGhlIHNldCBvZiByZXNvdXJjZXMpIGFuZDxiciBjbGFzcz0iIj4NCnRo
ZSBlbmQgdXNlciB3aG8gaXMgaW4gdGhlIHByb3RvY29sIGZsb3cuPGJyIGNsYXNzPSIiPg0KPGJy
IGNsYXNzPSIiPg0KVGhhdCBhY3R1YWxseSBhc2tzIGZvciB0aGUgZm9sbG93aW5nIGFkZGl0aW9u
YWwgZW50aXRpZXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KNy4gUmVzb3VyY2UgQWRt
aW5pc3RyYXRvcjxiciBjbGFzcz0iIj4NCjguIFBBUC9QSVA8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpJdCBpcyBwcm9iYWJseSBhIGdvb2QgaWRlYSB0byBzdGF0ZSB0aGUgc2VjdXJpdHkg
dGFyZ2V0IGFzIHdlbGwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmU6IFN0YXJ0aW5n
IGZyb20gUmVzb3VyY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWWVzLiBJIGFncmVl
IHRoYXQgdGhpcyBpcyBhIHZhbGlkIHVzZSBjYXNlLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGVyZTxi
ciBjbGFzcz0iIj4NCmNhbiBiZSBjYXNlcyB3aGVyZSB0aGUgY29uY3JldGUgcmVzb3VyY2UgZW5k
cG9pbnQgaXMgbm90IGtub3duIGJlZm9yZTxiciBjbGFzcz0iIj4NCnRoZSB1c2VyIGF1dGhvcml6
YXRpb24uIFNvLCB0aGUgcHJvdG9jb2wgbmVlZHMgdG8gYmUgYWJsZSB0byBzdGFydDxiciBjbGFz
cz0iIj4NCmJvdGggd2F5cywgSSBndWVzcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpD
aGVlcnMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmF0IFNha2ltdXJhPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gU3VuLCBKdWwgMjEsIDIwMTkg
YXQgNToyOCBQTSBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFp
bC5jb20iIGNsYXNzPSIiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNs
YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
SGV5IEp1c3RpbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgZmV3IHVzZSBjYXNlcyB0
aGF0IGhpZ2hsaWdodCBob3cgdGhlIHdvcmxkIGlzIGRpZmZlcmVudCBub3cgdGhhbiBpdCB3YXMg
d2hlbiBPQXV0aCAyLjAgd2FzIGRldmVsb3BlZCB3b3VsZCBoZWxwIHBhcnRpY2lwYW50cyB1bmRl
cnN0YW5kIHdoeSBjaGFuZ2VzIGFyZSBuZWVkZWQsIGFuZCBhbHNvIHByb3ZpZGUgYSByZWZlcmVu
Y2UgZm9yIGNvbXBhcmluZyBhbmQgY29udHJhc3RpbmcgZGlmZmVyZW50IGFwcHJvYWNoZXMuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT25lIG9mIG15IGZpcnN0IGNvbW1lbnRzIGlzIHdo
eSB0aGUgY2xpZW50IGlzIHN0YXJ0aW5nIG9mZiBtYWtpbmcgY2FsbHMgdG8gdGhlIEFTLiBUaGVy
ZSBhcmUgdGltZXMgd2hlbiB0aGUgQVMgaXMgbm90IGtub3duIGZvciBhIGdpdmVuIHJlc291cmNl
LiBXaHkgbm90IGFsbG93IHN0YXJ0aW5nIGF0IHJlc291cmNlPzxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMTI6NDggUE0g
SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgY2xhc3M9
IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KSSBoYXZlIHJlcXVlc3RlZCB0
aW1lIHRvIHByZXNlbnQgVHJhbnNhY3Rpb25hbCBBdXRob3JpemF0aW9uICh0aGUgWFlaIHByb2pl
Y3QpIGF0IHRoZSBNb250cmVhbCBtZWV0aW5nIGluIGEgY291cGxlIHdlZWtzLiBBaGVhZCBvZiB0
aGF0LCBJ4oCZdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgc3BlYzo8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDIiIGNsYXNzPSIiPmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wMjwvYT48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBZGRpdGlvbmFsbHksIEnigJl2ZSB1cGRhdGVk
IHRoZSB3cml0ZXVwIGFuZCBleGFtcGxlcyBvbiBodHRwczovL29hdXRoLnh5ei88YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHBsYW4gdG8gYmUgaW4gTW9udHJlYWwgZm9yIHRoZSB3aG9s
ZSB3ZWVrLCBhbmQgSeKAmXZlIHJlcXVlc3RlZCBmcm9tIHRoZSBjaGFpcnMgdGhhdCBJIHByZXNl
bnQgZHVyaW5nIHRoZSBUdWVzZGF5IHNlc3Npb24gZHVlIHRvIGxpbWl0ZWQgYXZhaWxhYmlsaXR5
IG9mIHNvbWUga2V5IFdHIG1lbWJlcnMgb24gRnJpZGF5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCuKAlCBKdXN0aW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCk9BdXRo
IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCk9BdXRoQGlldGYub3JnPGJyIGNsYXNzPSIiPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj4N
CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KTmF0IFNh
a2ltdXJhICg9bmF0KTxiciBjbGFzcz0iIj4NCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi
ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgY2xhc3M9IiI+
aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxiciBjbGFzcz0iIj4NCkBfbmF0X2VuPGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_EABD1584153B47758A5FD6D55A6B5795mitedu_--


From nobody Wed Jul 24 07:19: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 6A54C120019 for ; Wed, 24 Jul 2019 07:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 JLOYqSYzET_Y for ; Wed, 24 Jul 2019 07:19:26 -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 8181F120020 for ; Wed, 24 Jul 2019 07:19:26 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x6OEKiuV000982; Wed, 24 Jul 2019 10:20:47 -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, 24 Jul 2019 10:18:17 -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, 24 Jul 2019 10:18:53 -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, 24 Jul 2019 10:18:53 -0400
From: Justin Richer 
To: Leo Tohill 
CC: Hans Zandbelt , OAuth WG 
Thread-Topic: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.
Thread-Index: AQHVQDRSV6p1ICg+2UCIEh4jp0SA+qbXFs8AgAAMHACAALn/gIACOyyA
Date: Wed, 24 Jul 2019 14:18:53 +0000
Message-ID: <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
References:  <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com>  
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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_9D24AEB398584D7899DEC8F4FC9296AEmitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for 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, 24 Jul 2019 14:19:30 -0000

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

SXQgd291bGQgcGVyaGFwcyAgYmUgYmV0dGVyIHRvIHBocmFzZSBpdCBhcyDigJxkb27igJl0IHVz
ZSBPQXV0aCBpbiB0aGUgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbiBkaXJlY3RseeKAnSBpbnN0ZWFk
IG9mIOKAnG5vdCBlbnRpcmVseeKAnS4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBKdWwgMjMsIDIwMTks
IGF0IDEyOjE0IEFNLCBMZW8gVG9oaWxsIDxsZW90b2hpbGxAZ21haWwuY29tPG1haWx0bzpsZW90
b2hpbGxAZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgZGlkbid0IHNlZSB0aGUgZWFybGllciBkaXNj
dXNzaW9uIChkbyB5b3UgaGF2ZSBhIGRhdGUgb3IgdGl0bGU/KSBzbyBhcG9sb2dpZXMgaWYgSSdt
IGJyaW5naW5nIHVwIHNvbWV0aGluZyB0aGF0J3MgYmVlbiByZXNvbHZlZC4gIEJ1dCBJIHN0aWxs
IHRoaW5rIHRoYXQgaXQncyByZWFsbHkgY29uZnVzaW5nIHRvIHNheSAiaXQNCm1heSBiZSBhIGJl
dHRlciBkZWNpc2lvbiB0byBhdm9pZCB1c2luZyBPQXV0aCBlbnRpcmVseSIgIGlmIHRoZSBhcHBs
aWNhdGlvbiB3aWxsIHN0aWxsIGJlIHVzaW5nIE9hdXRoL09JREMgKHdoaWNoIHdpbGwsIG9mIGNv
dXJzZSwgaW52b2x2ZSBhIGJyb3dzZXIgZmxvdykuDQoNCm9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8
bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiAgaGFzIHJhaXNlZCB0aGUgc2FtZSAob3Ig
c2ltaWxhcj8pIG9iamVjdGlvbiBpbiBhIHBhcmFsbGVsIHRocmVhZC4gIEkgc3VnZ2VzdCB3ZSBj
b250aW51ZSB0aGUgY29udmVyc2F0aW9uIHRoZXJlLg0KDQotIExlbw0KDQoNCk9uIE1vbiwgSnVs
IDIyLCAyMDE5IGF0IDE6MDkgUE0gSGFucyBaYW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpv
bmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pj4gd3JvdGU6DQorMSwgYXMg
ZGlzY3Vzc2VkIGJlZm9yZQ0KDQpIYW5zLg0KDQpPbiBNb24sIEp1bCAyMiwgMjAxOSwgMTg6MjUg
QnJvY2sgQWxsZW4gPGJyb2NrYWxsZW5AZ21haWwuY29tPG1haWx0bzpicm9ja2FsbGVuQGdtYWls
LmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGUgaW1wbGljYXRpb24gaXMgdGhhdCB0aGUgc2VydmVy
LXNpZGUgd291bGQgdXNlIHNvbWV0aGluZyBsaWtlIE9JREMgdG8gdGhlIHRva2VuIHNlcnZlciBp
biBvcmRlciB0byBlc3RhYmxpc2ggdGhlIGlkZW50aXR5IG9mIHRoZSB1c2VyLiBUaGUgZGlmZmVy
ZW5jZSBpcyB0aGF0IHRoaXMgd291bGQgYmUgZHJpdmVuIGZyb20gdGhlIHNlcnZlci1zaWRlIHBp
ZWNlIG9mIHRoZSBhcHBsaWNhdGlvbiwgYXMgYW55IG90aGVyIG5vcm1hbCBzZXJ2ZXItc2lkZSBj
bGllbnQgd291bGQuIFRoZSByZXN1bHQgd291bGQgdGhlbiBzaW1wbHkgYmUgYSBjb29raWUtYmFz
ZWQgYXV0aGVudGljYXRpb24gc2Vzc2lvbiBpbiB0aGUgY2xpZW50LCBhbmQgYW55IEpTIGNvZGUg
d291bGQgbGV2ZXJhZ2UgdGhlIGh0dHAgb25seSwgc2FtZS1zaXRlIGNvb2tpZSBmb3IgQWpheCBj
YWxscy4NCg0KLUJyb2NrDQoNCg0KT24gNy8yMS8yMDE5IDEwOjIyOjM4IFBNLCBMZW8gVG9oaWxs
IDxsZW90b2hpbGxAZ21haWwuY29tPG1haWx0bzpsZW90b2hpbGxAZ21haWwuLmNvbT4+IHdyb3Rl
Og0KDQpUaGUgYWR2aWNlIGZvciB0aGUgYXJjaGl0ZWN0dXJhbCBwYXR0ZXJuICJKYXZhU2NyaXB0
IHNlcnZlZCBmcm9tIGEgY29tbW9uIGRvbWFpbiBhcyB0aGUgcmVzb3VyY2Ugc2VydmVyIiAgcmVh
ZHM6DQoNCiJGb3Igc2ltcGxlIHN5c3RlbSBhcmNoaXRlY3R1cmVzLCBzdWNoIGFzIHdoZW4gdGhl
IEphdmFTY3JpcHQgYXBwbGljYXRpb24gaXMgc2VydmVkDQpmcm9tIGEgZG9tYWluIHRoYXQgY2Fu
IHNoYXJlIGNvb2tpZXMgd2l0aCB0aGUgZG9tYWluIG9mIHRoZSBBUEkgKHJlc291cmNlIHNlcnZl
ciksIGl0DQptYXkgYmUgYSBiZXR0ZXIgZGVjaXNpb24gdG8gYXZvaWQgdXNpbmcgT0F1dGggZW50
aXJlbHksIGFuZCBpbnN0ZWFkIHVzZSBzZXNzaW9uDQphdXRoZW50aWNhdGlvbiB0byBjb21tdW5p
Y2F0ZSBkaXJlY3RseSB3aXRoIHRoZSBBUEkuIg0KDQpJIGNhbiBhZ3JlZSB0aGF0IHNlc3Npb24g
YXV0aGVudGljYXRpb24gY291bGQgYmUgYmVzdCBoZXJlLCBidXQgaG93IHdhcyB0aGUgdXNlciBh
dXRoZW50aWNhdGVkIGluIG9yZGVyIHRvIGNyZWF0ZSB0aGUgdHJ1c3RlZCBzZXNzaW9uPyAgV291
bGRuJ3QgdGhhdC9zaG91bGRuJ3QgdGhhdCBzdGlsbCB1c2UgYW4gb2F1dGggZmxvdyB0byBjb2xs
ZWN0IGNyZWRlbnRpYWxzPw0KDQpXZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHRoZSBkaXN0aW5jdGlv
biBiZXR3ZWVuIGJyb3dzZXIgYmFzZWQgYXBwcyB0aGF0IGhvbGQgdGhlIHRva2VuKHMpIGluIHRo
ZSBicm93c2VyIHNwYWNlLCB2cy4gdGhvc2UgdGhhdCBkb24ndC4gIEkgYWdyZWUgdGhhdCB3aXRo
IHRoaXMNCiJjb21tb24gZG9tYWluIiBhcmNoaXRlY3R1cmUsIHRoZSB0b2tlbnMgc2hvdWxkIG5v
dCBiZSBoZWxkIGluIHRoZSBicm93c2VyLCBidXQgaXQgZG9lc24ndCBmb2xsb3cgdGhhdCBvYXV0
aCBzaG91bGQgbm90IGJlIHVzZWQgYXQgYWxsLg0KDQpMZW8NCg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBPQXV0aCBtYWlsaW5nIGxpc3QgT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg
bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkl0IHdvdWxkIHBlcmhhcHMgJm5ic3A7YmUgYmV0
dGVyIHRvIHBocmFzZSBpdCBhcyDigJxkb27igJl0IHVzZSBPQXV0aCBpbiB0aGUgSmF2YVNjcmlw
dCBhcHBsaWNhdGlvbiBkaXJlY3RseeKAnSBpbnN0ZWFkIG9mIOKAnG5vdCBlbnRpcmVseeKAnS4m
bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp
ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog
YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDIzLCAy
MDE5LCBhdCAxMjoxNCBBTSwgTGVvIFRvaGlsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlb3RvaGls
bEBnbWFpbC5jb20iIGNsYXNzPSIiPmxlb3RvaGlsbEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8
L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz
PSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SSBkaWRuJ3Qgc2VlIHRoZSBlYXJsaWVyIGRp
c2N1c3Npb24gKGRvIHlvdSBoYXZlIGEgZGF0ZSBvciB0aXRsZT8pIHNvIGFwb2xvZ2llcyBpZiBJ
J20gYnJpbmdpbmcgdXAgc29tZXRoaW5nIHRoYXQncyBiZWVuIHJlc29sdmVkLiZuYnNwOyBCdXQg
SSBzdGlsbCB0aGluayB0aGF0IGl0J3MgcmVhbGx5IGNvbmZ1c2luZyB0byBzYXkgJnF1b3Q7aXQ8
YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPm1heSBiZSBhIGJldHRlciBkZWNpc2lvbiB0byBh
dm9pZCB1c2luZyBPQXV0aCBlbnRpcmVseSZxdW90OyZuYnNwOyBpZiB0aGUgYXBwbGljYXRpb24g
d2lsbCBzdGlsbCBiZSB1c2luZyBPYXV0aC9PSURDICh3aGljaCB3aWxsLCBvZiBjb3Vyc2UsIGlu
dm9sdmUgYSBicm93c2VyIGZsb3cpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl
ZHQubmV0IiBjbGFzcz0iZ21haWwtYXNVbUZiIGdtYWlsLUFMMThjZSBnbWFpbC1ZaDFuSWIiIHRh
cmdldD0iX2JsYW5rIj5vcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiZuYnNwOyBoYXMgcmFpc2Vk
IHRoZSBzYW1lIChvciBzaW1pbGFyPykgb2JqZWN0aW9uIGluIGEgcGFyYWxsZWwgdGhyZWFkLiZu
YnNwOyBJIHN1Z2dlc3Qgd2UgY29udGludWUgdGhlIGNvbnZlcnNhdGlvbiB0aGVyZS4NCjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+LSBMZW88YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt
YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIEp1
bCAyMiwgMjAxOSBhdCAxOjA5IFBNIEhhbnMgWmFuZGJlbHQgJmx0OzxhIGhyZWY9Im1haWx0bzpo
YW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmhhbnMu
emFuZGJlbHRAem1hcnR6b25lLmV1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw
cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s
ZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+JiM0MzsxLCBhcyBkaXNjdXNzZWQg
YmVmb3JlDQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+SGFucy48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi
Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWls
X2F0dHIiPk9uIE1vbiwgSnVsIDIyLCAyMDE5LCAxODoyNSBCcm9jayBBbGxlbiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmJyb2NrYWxsZW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+
YnJvY2thbGxlbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw
eCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl
ZnQ6MWV4Ij4NCjxkaXYgaWQ9ImdtYWlsLW1fLTI3NzUzMzk3MDQwNTM3NTMzNDhnbWFpbC1tXzcw
MTUyNDc1ODQwNzQ2ODA0ODZtXy03MzQ3MjMyNTgzMjAwODI3NTkwX19NYWlsYmlyZFN0eWxlQ29u
dGVudCIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0x1Y2lkYSBD
b25zb2xlJnF1b3Q7OyIgY2xhc3M9IiI+DQpJIHRoaW5rIHRoZSBpbXBsaWNhdGlvbiBpcyB0aGF0
IHRoZSBzZXJ2ZXItc2lkZSB3b3VsZCB1c2Ugc29tZXRoaW5nIGxpa2UgT0lEQyB0byB0aGUgdG9r
ZW4gc2VydmVyIGluIG9yZGVyIHRvIGVzdGFibGlzaCB0aGUgaWRlbnRpdHkgb2YgdGhlIHVzZXIu
IFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhpcyB3b3VsZCBiZSBkcml2ZW4gZnJvbSB0aGUgc2Vy
dmVyLXNpZGUgcGllY2Ugb2YgdGhlIGFwcGxpY2F0aW9uLCBhcyBhbnkgb3RoZXIgbm9ybWFsDQog
c2VydmVyLXNpZGUgY2xpZW50IHdvdWxkLiBUaGUgcmVzdWx0IHdvdWxkIHRoZW4gc2ltcGx5IGJl
IGEgY29va2llLWJhc2VkIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24gaW4gdGhlIGNsaWVudCwgYW5k
IGFueSBKUyBjb2RlIHdvdWxkIGxldmVyYWdlIHRoZSBodHRwIG9ubHksIHNhbWUtc2l0ZSBjb29r
aWUgZm9yIEFqYXggY2FsbHMuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMHB0O2xpbmUtaGVpZ2h0OjEuNSIgY2xhc3M9IiI+LUJyb2NrPC9zcGFuPjwvZGl2Pg0KPGRp
diBjbGFzcz0iZ21haWwtbV8tMjc3NTMzOTcwNDA1Mzc1MzM0OGdtYWlsLW1fNzAxNTI0NzU4NDA3
NDY4MDQ4Nm1fLTczNDcyMzI1ODMyMDA4Mjc1OTBtYl9zaWciPg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsLW1fLTI3
NzUzMzk3MDQwNTM3NTMzNDhnbWFpbC1tXzcwMTUyNDc1ODQwNzQ2ODA0ODZtXy03MzQ3MjMyNTgz
MjAwODI3NTkwaGlzdG9yeV9jb250YWluZXIiIHR5cGU9ImNpdGUiIHN0eWxlPSJib3JkZXItbGVm
dC1zdHlsZTpzb2xpZDtib3JkZXItd2lkdGg6MXB4O21hcmdpbi10b3A6MjBweDttYXJnaW4tbGVm
dDowcHg7cGFkZGluZy1sZWZ0OjEwcHgiPg0KPHAgc3R5bGU9ImNvbG9yOnJnYigxNzAsMTcwLDE3
MCk7bWFyZ2luLXRvcDoxMHB4IiBjbGFzcz0iIj5PbiA3LzIxLzIwMTkgMTA6MjI6MzggUE0sIExl
byBUb2hpbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpsZW90b2hpbGxAZ21haWwuLmNvbSIgcmVsPSJu
b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bGVvdG9oaWxsQGdtYWlsLmNvbTwv
YT4mZ3Q7IHdyb3RlOjwvcD4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLEhlbHZldGlj
YSxzYW5zLXNlcmlmIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj
bGFzcz0iIj5UaGUgYWR2aWNlIGZvciB0aGUgYXJjaGl0ZWN0dXJhbCBwYXR0ZXJuICZxdW90O0ph
dmFTY3JpcHQgc2VydmVkIGZyb20gYSBjb21tb24gZG9tYWluIGFzIHRoZSByZXNvdXJjZSBzZXJ2
ZXImcXVvdDsmbmJzcDsgcmVhZHM6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mcXVvdDtGb3Igc2ltcGxlIHN5
c3RlbSBhcmNoaXRlY3R1cmVzLCBzdWNoIGFzIHdoZW4gdGhlIEphdmFTY3JpcHQgYXBwbGljYXRp
b24gaXMgc2VydmVkPGJyIGNsYXNzPSIiPg0KZnJvbSBhIGRvbWFpbiB0aGF0IGNhbiBzaGFyZSBj
b29raWVzIHdpdGggdGhlIGRvbWFpbiBvZiB0aGUgQVBJIChyZXNvdXJjZSBzZXJ2ZXIpLCBpdDxi
ciBjbGFzcz0iIj4NCm1heSBiZSBhIGJldHRlciBkZWNpc2lvbiB0byBhdm9pZCB1c2luZyBPQXV0
aCBlbnRpcmVseSwgYW5kIGluc3RlYWQgdXNlIHNlc3Npb248YnIgY2xhc3M9IiI+DQphdXRoZW50
aWNhdGlvbiB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIHRoZSBBUEkuJnF1b3Q7PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGNh
biBhZ3JlZSB0aGF0IHNlc3Npb24gYXV0aGVudGljYXRpb24gY291bGQgYmUgYmVzdCBoZXJlLCBi
dXQgaG93IHdhcyB0aGUgdXNlciBhdXRoZW50aWNhdGVkIGluIG9yZGVyIHRvIGNyZWF0ZSB0aGUg
dHJ1c3RlZCBzZXNzaW9uPyZuYnNwOyBXb3VsZG4ndCB0aGF0L3Nob3VsZG4ndCB0aGF0IHN0aWxs
IHVzZSBhbiBvYXV0aCBmbG93IHRvIGNvbGxlY3QgY3JlZGVudGlhbHM/PC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBuZWVkIHRvIGJl
IGNsZWFyIG9uIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGJyb3dzZXIgYmFzZWQgYXBwcyB0aGF0
IGhvbGQgdGhlIHRva2VuKHMpIGluIHRoZSBicm93c2VyIHNwYWNlLCB2cy4gdGhvc2UgdGhhdCBk
b24ndC4mbmJzcDsgSSBhZ3JlZSB0aGF0IHdpdGggdGhpcw0KPGJyIGNsYXNzPSIiPg0KJnF1b3Q7
Y29tbW9uIGRvbWFpbiZxdW90OyBhcmNoaXRlY3R1cmUsIHRoZSB0b2tlbnMgc2hvdWxkIG5vdCBi
ZSBoZWxkIGluIHRoZSBicm93c2VyLCBidXQgaXQgZG9lc24ndCBmb2xsb3cgdGhhdCBvYXV0aCBz
aG91bGQgbm90IGJlIHVzZWQgYXQgYWxsLg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5MZW88YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBPQXV0aCBtYWlsaW5nIGxpc3QgPGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBj
bGFzcz0iIj4NCk9BdXRoQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r
IiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8
L2E+IDwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBy
ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwv
YT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs
YXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_9D24AEB398584D7899DEC8F4FC9296AEmitedu_--


From nobody Wed Jul 24 08:19: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 EEC4A1202BE for ; Wed, 24 Jul 2019 08:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 XGcUPpa19SOU for ; Wed, 24 Jul 2019 08:19:00 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE7C120371 for ; Wed, 24 Jul 2019 08:18:58 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id r15so15242770lfm.11 for ; Wed, 24 Jul 2019 08:18:58 -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=Ljkdhx+uI6syLGXMMWROvzUedbboDqhsBBkcI4id/nU=; b=A6DzQfi20rlPpVX4rKK3PkIU3iHHOj4axYDUwPYuKcw+3IuJ2n6eQ8K8pETSmlQ5PG Qij5DNSdrAGDzU5etplqV4UBbVBuBeKGJ2uySM2ucRjDhfJaVv22RTgOSFoUhcYx9ca8 OYG99nEi+K9a0pTdicWHKI26nqKTzgCafCI2u/EXnTLddvCOCCKsoWwoxyexYCFRccdE dNGS1sy2+nJ6HQ5WJBKwpLAQobjkdxWnX54+V57JsX3Lspm1R0h/W8yjZmJOBknq6w6a Lp4RuWCYXg2jJBDEOgdkAHBiD8Aw6gbKW9vWesCE+/qlSU1nczqEZEEAkIcvE2hV9mVX OBHg==
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=Ljkdhx+uI6syLGXMMWROvzUedbboDqhsBBkcI4id/nU=; b=AjFhki47Cj9nPFK2GZ9h3Born6z3FoGCyCTJQvwc7F7DeZX09TPYobB4iBaZ9SpGjX 1b4iA/kzCcwljOgQ0l+4qOzdbCygzDo7ErMa80DLr6ZXNsrpL0ZhejPz6Ieq5ncuMdwm NSASLb84gX6eUci50tvK91dt4jvnjmMVd/8u+VNiNFYAhk5LRNcyWrzL0NHVFKHbco20 aEBAKmQ87ocwwW71N1tIO2dGML2rOyBmny6nyvhFBw7mNwkx9PTSGK8HEpJzm5Ceijtp nicOrYFDUioujTTbXA167DZmckr6+31JDZhoLcHN6fAs1DSjpiIkqMP1ZCfm1eP8DVp6 br4Q==
X-Gm-Message-State: APjAAAVoy8+SA+i0vrSnaQZMx434yl1C4ATh1z7oXtppCAYnSlQWSukW 6Q4ej5BMkToqHBb+mOhb9P5zQJ0iNyRRIRcTN+p0lpYUapPdxQ==
X-Google-Smtp-Source: APXvYqz/tQrTEW0Lk2y2B/rY85FhfV8f1xKRTUwJlMKJHfzFaowT1knVNSs2NHxO7t+QPAfjJdQVYYKI1ao54gD65ss=
X-Received: by 2002:a19:80c4:: with SMTP id b187mr37128570lfd.122.1563981536740;  Wed, 24 Jul 2019 08:18:56 -0700 (PDT)
MIME-Version: 1.0
References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> 
In-Reply-To: 
From: Vittorio Bertocci 
Date: Wed, 24 Jul 2019 08:18:46 -0700
Message-ID: 
To: Petteri Stenius 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000eedbb1058e6ed342"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 15:19:05 -0000

--000000000000eedbb1058e6ed342
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Petteri,
thanks for your comments!
Re: indicator in resource indicator
One of the big goals of the profile is to promote interoperability, but
ultimately the choice of what style should be used to represent ATs falls
on each AS. In my experience most AS instances choose one style (opaque or
JWT) and stick with that rather than offering a choice, hence although I
see how adding an explicit reference to the desired style would make the
client feel empowered on the matter, in practice it would not make much of
a difference. The client can find out from the AS documentation what
particular choice that AS made.
A further consideration: the AT style is largely a matter between the AS
and the RS, given that it is the latter that needs to worry about how to
validate incoming ATs- hence the requestor (the client) should't probably
have much say about the matter. What if the API only knows how to validate
JWT ATs but the client selects opaque?

On introspection: let me think a bit more about it. One of the reasons for
which various AS instances issue AT as JWT is to avoid
implementing/exposing an introspection endpoint. The consideration about
revocation is valid IMO, but I am not sure if imposing use of introspection
would fly in practice.

thanks
V.


On Wed, Jul 24, 2019 at 7:00 AM Petteri Stenius <
Petteri.Stenius@ubisecure.com> wrote:

> Hi Vittorio,
>
> Thanks for working on this. I think this will be valuable. I have a coupl=
e
> of comments.
>
> About relationship of this draft with token exchange, introspection and
> revocation:
>
> Should there be a distinct Token Type Identifier defined for JWT Access
> Token, to enable exchange of reference type access token and value type
> access token? I'm thinking of a use case where I want authorization code
> flow to return an opaque reference token and I want my backend services t=
o
> exchange this into a value token, to avoid further introspection on the
> backend side.
>
> Introspection (and userinfo) with JWT Access Token should work as
> expected. If a JWT Access Token is revoked then introspection response
> should become negative. Is it reasonable to add text that advises the
> resource server to invoke introspection if it wants to make sure the toke=
n
> has not been revoked?
>
>
> Thanks,
> Petteri
>
>
> -----Original Message-----
> From: OAuth  On Behalf Of internet-drafts@ietf.or=
g
> Sent: sunnuntai 21. hein=C3=A4kuuta 2019 15.55
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
>
>
> 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 IET=
F.
>
>         Title           : JSON Web Token (JWT) Profile for OAuth 2.0
> Access Tokens
>         Author          : Vittorio Bertocci
>         Filename        : draft-ietf-oauth-access-token-jwt-01.txt
>         Pages           : 15
>         Date            : 2019-07-20
>
> Abstract:
>    This specification defines a profile for issuing OAuth2 access tokens
>    in JSON web token (JWT) format.  Authorization servers and resource
>    servers from different vendors can leverage this profile to issue and
>    consume access tokens in interoperable manner.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-0=
1
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-access-token-jwt-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Hi Petteri,
thanks for your comments!
Re: in=
dicator in resource indicator
One of the big goals of the profile=
 is to promote interoperability, but ultimately the choice of what style sh=
ould be used to represent ATs falls on each AS. In my experience most AS in=
stances choose one style (opaque or JWT) and stick with that rather than of=
fering a choice, hence although I see how adding an explicit reference to t=
he desired style would make the client feel empowered on the matter, in pra=
ctice it would not make much of a difference. The client can find out from =
the AS documentation what particular choice that AS made.
A furth=
er consideration: the AT style is largely a matter between the AS and the R=
S, given that it is the latter that needs to worry about how to validate in=
coming ATs- hence the requestor (the client) should't probably have muc=
h say about the matter. What if the API only knows how to validate JWT ATs =
but the client selects opaque?

On introspection: l=
et me think a bit more about it. One of the reasons for which various AS in=
stances issue AT as JWT is to avoid implementing/exposing an introspection =
endpoint. The consideration about revocation is valid IMO, but I am not sur=
e if imposing use of introspection would fly in practice.

thanks
V.=C2=A0


On Wed, Jul 24, 2019=
 at 7:00 AM Petteri Stenius <Petteri.Stenius@ubisecure.com> wrote:
Hi Vittorio,



Thanks for working on this. I think this will be valuable. I have a couple =
of comments.



About relationship of this draft with token exchange, introspection and rev=
ocation:



Should there be a distinct Token Type Identifier defined for JWT Access Tok=
en, to enable exchange of reference type access token and value type access=
 token? I'm thinking of a use case where I want authorization code flow=
 to return an opaque reference token and I want my backend services to exch=
ange this into a value token, to avoid further introspection on the backend=
 side.



Introspection (and userinfo) with JWT Access Token should work as expected.=
 If a JWT Access Token is revoked then introspection response should become=
 negative. Is it reasonable to add text that advises the resource server to=
 invoke introspection if it wants to make sure the token has not been revok=
ed?





Thanks,

Petteri





-----Original Message-----

From: OAuth <oauth-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org

Sent: sunnuntai 21. hein=C3=A4kuuta 2019 15.55

To: i-d-announce=
@ietf.org

Cc: oauth@ietf.org<=
br>
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol WG of the IETF.=




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vitt=
orio Bertocci

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-access-token-jwt-01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 15

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2019-07-20



Abstract:

=C2=A0 =C2=A0This specification defines a profile for issuing OAuth2 access=
 tokens

=C2=A0 =C2=A0in JSON web token (JWT) format.=C2=A0 Authorization servers an=
d resource

=C2=A0 =C2=A0servers from different vendors can leverage this profile to is=
sue and

=C2=A0 =C2=A0consume access tokens in interoperable manner.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/=
draft-ietf-oauth-access-token-jwt/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ie=
tf-oauth-access-token-jwt-01

https://datatracker.ietf.o=
rg/doc/html/draft-ietf-oauth-access-token-jwt-01



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff=
?url2=3Ddraft-ietf-oauth-access-token-jwt-01





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000eedbb1058e6ed342--


From nobody Wed Jul 24 08:32:58 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40188120383 for ; Wed, 24 Jul 2019 08:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbKSYHStFWgl for ; Wed, 24 Jul 2019 08:32:55 -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 A886112037A for ; Wed, 24 Jul 2019 08:32:54 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id b17so32288480lff.7 for ; Wed, 24 Jul 2019 08:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=KCIg+3CuX7FWMh5QVh5b8rh7axEEulnxrJfCDJZCllg=; b=qcnB9mv1M5ky2HALWcofvfzONQ3yfY4qTOwAGBY4lhhtlxDDyapdQVkM59RDtUOB0L 51GpowZ291DxZShkp36SovzARRw03d/g/5pV38Nvkyj9xWfizgNhCLwXQpODP44m2QqO sg9IqfnF+YU9sqViXf8Q07KxukytF8DjoB/KFDVkIOXtnqU3JEw/9o96R/O8tw3qi2IN AZemqtOiX5H4w2kpFRcShKl5RdemD02Yq43vahT1Bmlwmbns8bSfE+6orLrYSFKBpSdg ZyKkAQ59wq+4Ucc7eLbTGUiSVHkN6FWHTF8Fz1YiI0wgfAT6yrNvseCiGqWo0GmvQPNe Kzhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=KCIg+3CuX7FWMh5QVh5b8rh7axEEulnxrJfCDJZCllg=; b=GLH9n9Zi0y/VtWVPfrhP6B5lm1MS19G8MfRxo6wX4J75YW5/iMd+WELL2eRlLCCk7x nDobFM4XGPKBkS3IIcS7gmTVu9EUsZZGFVNnymPIkK9nfJphjZJEaSPQSDMpS1xxcgcS 8lqdsTNxbc6Q9GIXx/w9km+oSVeU0AwesS2q6vV6vIalq2nQe2d3pTdgFGe5Gf3RbTcx zO+dgJVlSJdDu71IVrO13Hf0UMJ1oGb2SDuTDO6YNKfYs/iurO3MeUgbv9wAzmZG5VJs bg0bGHNuEjm52fIjiFTjn3YXIvUL/vhQem6rHcOLwuigb/3luVAEdZOvFJs+mvY63twx xSaA==
X-Gm-Message-State: APjAAAXxFLWq5MvnJfnGLrkTf38ZJJLAH7wK2EGMNDzwiOq5tuXLuRoC veqrnpXU9FAEfrwU9ZNGuqTwTp2oI2W40iaERA5VraeCYpBa3bJF
X-Google-Smtp-Source: APXvYqyR+vYqnSp62xl+Yo5seZXW8QMyiH+Vc8TqEV+Kemy6id2u5KaMudlkygoGp/tncIrapfPnOC15ziDQIQWWakQ=
X-Received: by 2002:a19:c887:: with SMTP id y129mr39150971lff.73.1563982372310;  Wed, 24 Jul 2019 08:32:52 -0700 (PDT)
MIME-Version: 1.0
Reply-To: Vittorio@auth0.com
From: Vittorio Bertocci 
Date: Wed, 24 Jul 2019 08:32:42 -0700
Message-ID: 
To: IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000bcaed5058e6f057f"
Archived-At: 
Subject: [OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 15:32:57 -0000

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

During Daniel's security BCP presentation yesterday, I commented that
although I support deprecating ROPG, I also believe we should acknowledge
scenarios where U/P use is unavoidable and give clear actionable guidance
to developers.
Daniel observed that not every scenario is prone to be addressed via
OAuth2, and invited me to suggest some language to add to
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.4
clarifying
that.
Here's the proposed language:

Please note: there are scenarios, such as legacy script languages, apps
> using connections strings and similar, where the direct use of username and
> password is required to maintain backward compatibility. Addressing those
> scenarios is outside of the scope of the OAuth2 authorization framework.


As a side note: I worry a bit that giving explicit license to people to
ignore OAuth2 for that particular scenario might provide a bit of slippery
slope/broken window effect where developers won't use standard solutions in
other scenarios as well. At the same time, if we don;t want to tackle that
particular class of scenarios, I think it's fair of us to be explicit about
it.

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


During Daniel's security BCP presentation yesterday, I=
 commented that although I support deprecating ROPG, I also believe we shou=
ld acknowledge scenarios where U/P use is unavoidable and give clear action=
able guidance to developers.
Daniel observed that not every scenario is=
 prone to be addressed via OAuth2, and invited me to suggest some language =
to add to=C2=A0https://tools.ietf.org/html/draft-ietf-oauth-se=
curity-topics-13#section-3.4=C2=A0clarifying that.
Here's=
 the proposed language:

Please note: there are scenarios, such as legacy script =
languages, apps using connections strings and similar, where the direct use=
 of username and password is required to maintain backward compatibility. A=
ddressing those scenarios is outside of the scope of the OAuth2 authorizati=
on framework.

As a side note: I worry a bit=
 that giving explicit license to people to ignore OAuth2 for that particula=
r scenario might provide a bit of slippery slope/broken window effect where=
 developers won't use standard solutions in other scenarios as well. At=
 the same time, if we don;t want to tackle that particular class of scenari=
os, I think it's fair of us to be explicit about it.


--000000000000bcaed5058e6f057f--


From nobody Wed Jul 24 09:19:36 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 D1C87120043; Wed, 24 Jul 2019 09:19:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <156398517481.14555.3606019477379797998@ietfa.amsl.com>
Date: Wed, 24 Jul 2019 09:19:34 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-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: Wed, 24 Jul 2019 16:19:35 -0000

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

        Title           : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
        Author          : Vittorio Bertocci
	Filename        : draft-ietf-oauth-access-token-jwt-02.txt
	Pages           : 16
	Date            : 2019-07-24

Abstract:
   This specification defines a profile for issuing OAuth2 access tokens
   in JSON web token (JWT) format.  Authorization servers and resource
   servers from different vendors can leverage this profile to issue and
   consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-02
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-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 Wed Jul 24 11:52: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 90B3312034D for ; Wed, 24 Jul 2019 11:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boLETFwkkTTX for ; Wed, 24 Jul 2019 11:52:20 -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 D5B0A120141 for ; Wed, 24 Jul 2019 11:52:19 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id s3so42731814wms.2 for ; Wed, 24 Jul 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:content-transfer-encoding; bh=TzGh9XWQQ8hjuyZLwqbmpgVygU6XCmI4sj7ILxl2KvA=; b=WUPD4NO2yX44DTHq6K9e63sK56jefsnblqCjD5Kk6trqWR8WiMVADWwWsp3jUALc34 LZOqsdxNu3sqeBqJqmrj6enMIry9fBNhw3yaZfVbAZc8OynHgvS5OCqA/F6iUYVs/G36 OgiS0KE8vin3hWKzSWC0W3xDn1OS56j5D/KTcgM6dxdJ2+o8hiu0Djd6Qge0sYeDFmIe rix/KGJcjoznRUZH+oVh7at8LrqKZ1U73fKxpLmOGcKWTPrqpYH96w1rLMUSv2jVVqVF rVmJswYwV6mMf2uqiu0L5RI/q420LEYX/g9MEB1aKpd5H8jPaDkVl3kSLzslAIsyq3uM +rNg==
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=TzGh9XWQQ8hjuyZLwqbmpgVygU6XCmI4sj7ILxl2KvA=; b=mYkTeEydGuaYZVS5vPMT1LGyKAUch3CECADytM6VeUge8mhPO4DvRV1gDA0e4K0RuK DOsk/VJgggrJdVZhpL94UKP/HtttPBJZAbgDLhmlQPbqNiyog1JPzohEgXWJHXkcpaR4 wJZYQNHwk32vLCMWhfp92Y/J9YzK/PqyYQGb1BVQgdvFQPNiQZgJoXSSDoolFqN0jhRi teezbKZ5K4uG+LxQ4clOqRvvNQEtrZB1rwk55cQ3BDESYGDENExncBN3YzriR0HM+XK8 3g/TjQ3CgZUb9qF5FgYfRQZTIZi9Pa9Mn+/Ond628bgORvoWtzk0cDFXEeC0q+JktWbY Tmww==
X-Gm-Message-State: APjAAAWee0cn+vtUwEjg0ZWqpPFF7i2LEDzJaLqKdD8wi0Y/4Xz/M5y9 SyhCChH+hDkic0TCwwrx8QG9ZwqoP5DSV3jgEzA=
X-Google-Smtp-Source: APXvYqwaSVbr383ji5H7ljEOwC2daS4MHz151nuBnTDZJy0uPD12hdIsL5Hbt2j4LAVVM5mDB/+dRvqFYXhftlf1Ngg=
X-Received: by 2002:a1c:1a4c:: with SMTP id a73mr14091999wma.109.1563994337772;  Wed, 24 Jul 2019 11:52:17 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 24 Jul 2019 14:52:06 -0400
Message-ID: 
To: Vittorio@auth0.com
Cc: IETF oauth WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 18:52:23 -0000

As the time was running out, I did not make any comment but I actually
had two comments on this topic.

1) I agree with Vittorio that pushing people away from OAuth is a
slippery slope. Having said that, I have no good solution either. At
least, I feel that ROPC is not the right solution anyways.

2) ROPC is a good flow for migrating a password storing app to OAuth
as depicted in https://youtu.be/zuVuhl_Axbs . So, completely denying
it is a touch too much. It should very narrowly constrain its
applicability.

Cheers,

Nat

On Wed, Jul 24, 2019 at 11:33 AM Vittorio Bertocci
 wrote:
>
> During Daniel's security BCP presentation yesterday, I commented that alt=
hough I support deprecating ROPG, I also believe we should acknowledge scen=
arios where U/P use is unavoidable and give clear actionable guidance to de=
velopers.
> Daniel observed that not every scenario is prone to be addressed via OAut=
h2, and invited me to suggest some language to add to https://tools.ietf.or=
g/html/draft-ietf-oauth-security-topics-13#section-3.4 clarifying that.
> Here's the proposed language:
>
>> Please note: there are scenarios, such as legacy script languages, apps =
using connections strings and similar, where the direct use of username and=
 password is required to maintain backward compatibility. Addressing those =
scenarios is outside of the scope of the OAuth2 authorization framework.
>
>
> As a side note: I worry a bit that giving explicit license to people to i=
gnore OAuth2 for that particular scenario might provide a bit of slippery s=
lope/broken window effect where developers won't use standard solutions in =
other scenarios as well. At the same time, if we don;t want to tackle that =
particular class of scenarios, I think it's fair of us to be explicit about=
 it.
> _______________________________________________
> 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 Wed Jul 24 12:59:45 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798DF120640 for ; Wed, 24 Jul 2019 12:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxMV9zSkDRLO for ; Wed, 24 Jul 2019 12:59:33 -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 1625C12066B for ; Wed, 24 Jul 2019 12:59:33 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id s7so92100942iob.11 for ; Wed, 24 Jul 2019 12:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=PEzLPm550VNupfpvHGYW2LV3sZen8KQCewSlwmP3JTU=; b=hEpzWf+iekC3nG/IZfE8OeDgoEVxiThpJ2KiO8MSeNR6PAniYDG5VViX0SK+eLaSwv SHbGryGRwjCsaHqas3Fkh59qrrvpW9eUrnBpCzpcebuyaplMeOwFulswJS5djDvxCzME sA9/8ts4oadeFVIoRDI75WY7U6RSVCp5HYU1I=
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=PEzLPm550VNupfpvHGYW2LV3sZen8KQCewSlwmP3JTU=; b=Cn4/k3+MSYxQxVZUSqCL2317fvttdkSmJmg/HC+hSqruSAqVYQXcdvdmsfBgjLVE2C YCu2Kp7iNtbK9Rk/kq6Px0Ha9L7wcvso4KB4azEt/4CLX9K/WJ1/GNEmfwmSkP77vEMJ Pj10g9ahyE0ykP8H8OkHTfDANCWk/9l3cUJrAVUkFUWT4K/KyC5FxCoRr430zbZC0uEk PAIZh1qFnxj0FGL1eO2OTdag2Q921k+hG+zlujy9CNpZR92PwE/XgyquwoUZ0OJQB2su XNj2Q8lA/7ejaK7hTSNuVjsVYv97d/Gp2e3Kcafz6U+6laAuqIOWe7hRNs2vrqyXvgGA 3XLg==
X-Gm-Message-State: APjAAAVPWM+9ShcGr5esnTRgIBPKu64g5CYhJ2YdUjr9dnUgKaa1Gffb OQrBTE21fVeeYnE3OdnY21AAmoLO8X1TAcUrfcwu3djWyDWsACzruZ/yuFDKFSysl35g6HtS8T6 oKHGEAgxYRE2YTTfcPM9+rA==
X-Google-Smtp-Source: APXvYqyoHNPnWyDZ7lJ6fjuZTo7WNDhKhM3uNSw/c4XAQf95c/qkmwrQDZ5HCteZrgzba6UMB5fd0a43zJbUYWB3URw=
X-Received: by 2002:a6b:621a:: with SMTP id f26mr70003330iog.127.1563998371926;  Wed, 24 Jul 2019 12:59:31 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell 
Date: Wed, 24 Jul 2019 13:59:05 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000637483058e72bf18"
Archived-At: 
Subject: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 19:59:44 -0000

--000000000000637483058e72bf18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2.1.  Header

>    NOTE: there were discussions about adding a reference to
>    authenticated encyption methods as well, but there's no internet
>    draft specifying interoperable public key methods at this time
>
Well, Neil did write this up a while back
https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01 which is
certainly interesting and I wonder if it's something that this group (or
some other group?) should look at working on. But it is only an individual
draft (with all the authority that brings to bear
) and thus I do
agree that it isn't appropriate or useful for this document to reference.

However JWE RFC7516 and more JWA RFC7518 do have authenticated encryption
with symmetric keys that, IMHO, can work very nicely in some cases for JWT
access tokens by providing both integrity protection and confidentiality.
And the size and performance benefits thereof can be sufficiently useful so
as to justify the need to do an out-of-band exchange of the symmetric key.

Also encyption should be encryption.


2.1.  Header

>    The typ header parameter for a JWT access token MUST be at+jwt.  See
>    the security considerations section for details on the importance of
>    preventing JWT access tokens to be interpreted as id_tokens.

5.  Security Considerations

>    The JWT access token data layout described here is very similar to
>    the one of the id_token as defined by [OpenID.Core].  Without the
>    explicit typing required in this profile, in line with the
>    recommendations in [JWT.BestPractices] there would be the risk of
>    attackers using JWT access tokens in lieu of id_tokens.

Connect doesn't say anything about checking the "typ" header of id tokens
so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT
access tokens being used as id tokens. It can prevent misuse in the other
direction. But this document probably shouldn't overstate what typing the
JWT can accomplish.

BTW, there's been some discussion and agreement that the requirement around
'nonce' in ID Tokens delivered via the front channel (the only time connect
is subject to that kind of token swapping) is sufficient to protect against
JWT access tokens (and other types of JWTs) to be interpreted as id_tokens.
So I think the risk is acceptable but just think the text in the draft
shouldn't make claims which are untrue.


2.2.2.  Authorization Claims:

>    If an authorization request includes a scope parameter, the
>    corresponding issued JWT access token
>
  MUST in -01/SHOULD in -02 include a scope claim
>
as defined in
>
I think you want to say here that the scope claim in the token has to
correlate to the scope which was approved. Not necessarily what what
requested. The authorization request might ask for scope of a+b+c, for
example, while the user only approves b. Or any other variation on things
where what was asked for isn't what was gotten.


3.  Requesting a JWT Access Token

>    If it receives a request for an access token containing more than one
>    resource parameter, an authorization server issuing JWT access tokens
>    MUST reject the request and fail with invalid_request as described in
>    section 4.1.2.1 of [RFC6749].
>
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an
"invalid_target" error code that is intended for this kind of thing. So
that should probably be allowed. If not suggested. Probably not required
though.

4.  Validating JWT Access Tokens

>       If encryption was negotiated with the
>        authorization server at registration time and the incoming JWT
>        access token is not encrypted, the resource server SHOULD reject
>        it.
>
I personally think the SHOULD is too strong here because it puts the onus
on the resource server to know about (via some config option or something)
and enforce on every transaction a setup/policy thing that the AS is
responsible for which isn't about the integrity of the authorization data
in the token. A MAY or even removing the list item would be preferred.

4.  Validating JWT Access Tokens

>      The JWT access token MUST be
>        rejected if aud does not list the resource indicator of the
>        current resource server as a valid audience, or if it contains
>        additional audiences that are not known aliases of the resource
>        indicator of the current resource server.
>
5.  Security Considerations

>    This profile explicitly forbids the use of multi value aud claim when
>    the individual values refer to different resources, as that would
>    introduce confusion about what scopes apply to which resource-
>    possibly opening up avenues for elevation of delegated privileges
>    attacks.  Alternative techniques to prevent scope confusion include
>    "scope stuffing", imposing to every individual scope string to
>    include a reference to the resource they are meant to be applied to,
>    but its application is problematic (scope opacity violations, size
>    inflation, more error conditions become possible when the combination
>    of requested scopes and resource indicators is invalid) and the
>    observed frequency of the scenario doesn't warrant complicating the
>    more common cases.
>
I do think I see the simplification you're aiming at with this stuff but
I'd like to offer the perspective of how this is likely more complicated
for standards based JWT library implementations. The semantics of aud in
RFC 7519 basically say that the recipient has to identify with at least one
of the aud values. It's effectively a big OR. While the text in this draft
changes that semantic to say that the recipient has to identify with at
every one of the aud values. Effectively making it a big AND. Normal JWT
libraries will need nonstandard one-off functionality or adaptations to get
this right.


 4.  Validating JWT Access Tokens

>       The resource server MUST validate the signature of all incoming
>        JWT access token according to [RFC7515] using the algorithm
>        specified in the JWT alg Header Parameter.  The resource server
>        MUST use the keys provided by the authorization server.
>
I think it'd be worthwhile to explicitly disallow the use of the "none"
algorithm here. I think/suspect that it is implied already. But at least
some of the JWT hate out there seems to stem from or focus on statements
like this one and conclude that words like "MUST validate ... according to
[the] algorithm specified in the JWT alg Header Parameter" means that to be
spec compliant one has to accept "alg":"none" as valid. That's more of a
logical leap than I think is reasonable but I'd like to avoid it anyway if
possible. And it's not a bad thing to remind folks not to accept "none"
here.

7.2.  Claims Registration

>     claims in the JSON Web TOken (JWT) IANA
>
Little 'o' in TOken -> Token


7.2.1.  Registry Contents
|   Specification Document(s): section 4.1.2 of [RFC7643]
Ultimately this is what will show up in the "References" column in the
registry https://www.iana.org/assignments/jwt/jwt.xhtml and thus I'd
suggest that it also include something like "Section 2.2.2.1 of [[this
specification]]" there too so someone who starts from the registry has the
link to and context of this document. A link directly to SCIM alone from
the JSON Web Token Claims registry might be rather confusing.
For the folks that will have to review and act on these registrations at
some point, it might be nice to give em a little better
grouping/formatting. I'm thinking along the lines of what is done here
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-18#section-7.4.=
1,
which you can corice xml2rfc into doing with  and=
  as in the src at
https://github.com/oauth-token-exchange/spec/blob/master/draft-ietf-oauth-t=
oken-exchange.xml#L1191

Appendix A.  Acknowledgements

>     Brian Campbell (PingIdentity)
>
My corporate overloads will be happier if you put a space between Ping and
Identity.

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

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



2.1.=C2=A0 Header
=C2=A0=C2=A0 NOTE: there were discussions abou=
t adding a reference to
=C2=A0 =C2=A0authenticated encyption methods as =
well, but there's no internet
=C2=A0 =C2=A0draft specifying interope=
rable public key methods at this time
Well, Neil did=
 write this up a while back https://tools.ietf.org/html/draft-=
madden-jose-ecdh-1pu-01 which is certainly interesting and I wonder if =
it's something that this group (or some other group?) should look at wo=
rking on. But it is only an individual draft (with all the author=
ity that brings to bear) and thus I do agree that it isn't appropri=
ate or useful for this document to reference. 

However JWE RFC7516 and more JWA RFC7518 do have authenticated encryption =
with symmetric keys that, IMHO, can work very nicely in some cases for JWT =
access tokens by providing both integrity protection and confidentiality. A=
nd the size and performance benefits thereof can be sufficiently useful so =
as to justify the need to do an out-of-band exchange of the symmetric key.=
=C2=A0 

Also encyption should be encryption. <=
br>


2.1.=C2=A0 Header
=C2=A0 =C2=A0The typ header parameter f=
or a JWT access token MUST be at+jwt.=C2=A0 See
=C2=A0 =C2=A0the securit=
y considerations section for details on the importance of
=C2=A0 =C2=A0p=
reventing JWT access tokens to be interpreted as id_tokens.=C2=A0
5.=C2=A0 Security Considerations
=C2=A0 =C2=A0The JWT access token data layout described =
here is very similar to
=C2=A0 =C2=A0the one of the id_token as defined =
by [OpenID.Core].=C2=A0 Without the
=C2=A0 =C2=A0explicit typing require=
d in this profile, in line with the
=C2=A0 =C2=A0recommendations in [JWT=
.BestPractices] there would be the risk of
=C2=A0 =C2=A0attackers using =
JWT access tokens in lieu of id_tokens.
Connect doesn'=
t say anything about checking the "typ" header of id tokens so ty=
ping ATs with "at+jwt" doesn't actually do anything to preven=
t  JWT access tokens being used as id tokens. It can prevent misuse in the =
other direction. But this document probably shouldn't overstate what ty=
ping the JWT can accomplish.
=C2=A0
BTW, there'=
s been some discussion and agreement that the requirement around 'nonce=
' in ID Tokens delivered via the front channel (the only time connect i=
s subject to that kind of token swapping) is sufficient to protect against =
JWT access tokens (and other types of JWTs) to be interpreted as id_tokens.=
 So I think the risk is acceptable but just think the text in the draft sho=
uldn't make claims which are untrue. 
=C2=A0
<=
br>
2.2.2.=C2=A0 Authorization Claims:
=C2=A0=C2=A0 If an authorization request =
includes a scope parameter, the
=C2=A0 =C2=A0corresponding issued JWT ac=
cess token 
=C2=A0 MUST in -01/SHOULD in -02 include a scope claim 
=

a=
s defined in 
I think you want to say here that =
the scope claim in the token has to correlate to the scope which was approv=
ed. Not necessarily what what requested. The authorization request might as=
k for scope of a+b+c, for example, while the user only approves b. Or any o=
ther variation on things where what was asked for isn't what was gotten=
. 


3.=C2=A0 Requesting a JWT Access Token<=
/div>
=C2=A0=C2=A0 If=
 it receives a request for an access token containing more than one
=C2=
=A0 =C2=A0resource parameter, an authorization server issuing JWT access to=
kens
=C2=A0 =C2=A0MUST reject the request and fail with invalid_request =
as described in
=C2=A0 =C2=A0section 4.1.2.1 of [RFC6749]. 
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicato=
rs has an "invalid_target" error code that is intended for th=
is kind of thing. So that should probably be allowed. If not suggested. Pro=
bably not required though. 

4.=C2=A0 Validatin=
g JWT Access Tokens
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If encryption was negotiated with the=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server at registration time and =
the incoming JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0access token is not encrypte=
d, the resource server SHOULD reject
=C2=A0 =C2=A0 =C2=A0 =C2=A0it.
I personally think the SHOULD is too strong here because=
 it puts the onus on the  resource server to know about (via some config op=
tion or something) and enforce on every transaction a setup/policy thing th=
at the AS is responsible for which isn't about the integrity of the aut=
horization data in the token. A MAY or even removing the list item would be=
 preferred. 

4.=C2=A0 Validating JWT Access To=
kens
=C2=A0=C2=
=A0=C2=A0=C2=A0 The JWT access token MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
rejected if aud does not list the resource indicator of the
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0current resource server as a valid audience, or if it cont=
ains
=C2=A0 =C2=A0 =C2=A0 =C2=A0additional audiences that are not known =
aliases of the resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicator of the curr=
ent resource server.
5.=C2=A0 Security Consideration=
s
=C2=A0 =C2=A0=
This profile explicitly forbids the use of multi value aud claim when
=
=C2=A0 =C2=A0the individual values refer to different resources, as that wo=
uld
=C2=A0 =C2=A0introduce confusion about what scopes apply to which re=
source-
=C2=A0 =C2=A0possibly opening up avenues for elevation of delega=
ted privileges
=C2=A0 =C2=A0attacks.=C2=A0 Alternative techniques to pre=
vent scope confusion include
=C2=A0 =C2=A0"scope stuffing", im=
posing to every individual scope string to
=C2=A0 =C2=A0include a refere=
nce to the resource they are meant to be applied to,
=C2=A0 =C2=A0but it=
s application is problematic (scope opacity violations, size
=C2=A0 =C2=
=A0inflation, more error conditions become possible when the combination=C2=A0 =C2=A0of requested scopes and resource indicators is invalid) and t=
he
=C2=A0 =C2=A0observed frequency of the scenario doesn't warrant c=
omplicating the
=C2=A0 =C2=A0more common cases. 
<=
div>I do think I see the simplification you're aiming at with this stuf=
f but I'd like to offer the perspective of how this is likely more comp=
licated for standards based JWT library implementations. The semantics of a=
ud in RFC 7519 basically say that the recipient has to identify with at lea=
st one of the aud values. It's effectively a big OR. While the text in =
this draft changes that semantic to say  that the recipient has to identify=
 with at every one of the aud values. Effectively making it a big AND. Norm=
al JWT libraries will need nonstandard one-off functionality or adaptations=
 to get this right.=C2=A0 


=C2=
=A04.=C2=A0 Validating JWT Access Tokens
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The resource serve=
r MUST validate the signature of all incoming
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0JWT access token according to [RFC7515] using the algorithm
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0specified in the JWT alg Header Parameter.=C2=A0 The re=
source server
=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST use the keys provided by t=
he authorization server. 
I think it'd be wo=
rthwhile to explicitly disallow the use of the "none" algorithm h=
ere. I think/suspect that it is implied already. But at least some of the J=
WT hate out there seems to stem from or focus on statements like this one a=
nd conclude that words like "MUST validate ... according to [the] algo=
rithm specified in the JWT alg Header Parameter" means that to be spec=
 compliant one has to accept "alg":"none" as valid. Tha=
t's more of a logical leap than I think is reasonable but I'd like =
to avoid it anyway if possible. And it's not a bad thing to remind folk=
s not to accept "none" here. 
=C2=A0
7.2.=
=C2=A0 Claims Registration
=C2=A0=C2=A0=C2=A0 claims in the JSON Web TOken (JWT) IANA
Little 'o' in TOken -> Token


7.2.1.=C2=A0 Registry Contents 
|=C2=A0=C2=A0 Specif=
ication Document(s): section 4.1.2 of [RFC7643]
Ultimately this i=
s what will show up in the "References" column in the registry https://www.iana.o=
rg/assignments/jwt/jwt.xhtml and thus I'd suggest that it also incl=
ude something like "Section 2.2.2.1 of [[this specification]]" th=
ere too so someone who starts from the registry has the link to and context=
 of this document. A link directly to SCIM alone from the JSON Web Token Cl=
aims registry might be rather confusing. 
For the folks that =
will have to review and act on these registrations at some point, it might =
be nice to give em a little better grouping/formatting. I'm thinking al=
ong the lines of what is done here https://=
tools.ietf.org/html/draft-ietf-oauth-token-exchange-18#section-7.4.1, w=
hich you can corice xml2rfc into doing with <?rfc subcompact=3D"yes=
"?> and <?rfc subcompact=3D"no"?> as in the src at https://github.com/oauth-token-exchange/spec/blob/master/draft-ietf-oa=
uth-token-exchange.xml#L1191 

Appendix A.=
=C2=A0 Acknowledgements
=C2=A0=C2=A0=C2=A0 Brian Campbell (PingIdentity)
My corporate overloads will be happier if you put a space between Pin=
g and Identity.
=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.
--000000000000637483058e72bf18--


From nobody Wed Jul 24 13:15: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 8DE4C1205FE for ; Wed, 24 Jul 2019 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5Yea5UeliVP8 for ; Wed, 24 Jul 2019 13:15:01 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550911205F8 for ; Wed, 24 Jul 2019 13:15:01 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s7so92195466iob.11 for ; Wed, 24 Jul 2019 13:15:01 -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=ekwIdtny8wQRn+oEhlxXawPmpHdX8ig9PsEjOd7RLsQ=; b=Gkex64EGerZHRSJtO1HFARpUGNwMlw7mC67/9z4w7XhOQaS1TPOlUzIy3p+BSSA391 u2Pe0mfHWdgRyRYyuQxgaFeN+xureBAIPbu7iGC0Ef9JfyHa7OJVyiVArEtjiOcqDwp2 xPs/xC6L/euAwSXjnqK0E1s8eZe/fw7MNqHnAT3G4OOA7jLF4W7I0+kpcMbRrWxGDJmf kJyAXWhVHtsWIgh2MazfJlp5UQyELM4BfIakkLoxi70TofzI9Qs/51y6QVKlET22ldWi IozzcG8erQw1T+r7BuiY5sTq7Ps4ioKgM73UZIArH1M5vGM/gk7h8lFPsl0MIn1rzBQP Iedw==
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=ekwIdtny8wQRn+oEhlxXawPmpHdX8ig9PsEjOd7RLsQ=; b=VqZJ9//lCOqipZJrflqEiqSa+WfJDc2BH80nCPcJbw7Z56hgky4vckFDT5lr26yU6u 46vQ/Te2EuFQt1VAs+Z3Q8CBRAZuJN80ezsFCzo6cK/Cp7Ge6UWpUJefdZS08z3Flokt g57PPV5a85Ew226SJN1+DeMMZYUDbwz61iAv/qk0KHwrYFNZJF1q6MkLYZFKoZPcyZ+U YycU4qh5iKowlPmjxP5ih8OYrjLJ/oRDolfZeFJbJSP4aM+xRYwnCOQqu5qp8r/zEhZm bInxOW2qJmqtDypKgSZ1+TUIUYe4fyRc+4dfUYGXAfbq7bLfvOrlJeNjIYAPt6gwQoAP 1cDw==
X-Gm-Message-State: APjAAAUuhs2FaeEUhLfwd2XBjShB8fhvR7GkRh7xbmRIA2IMythbS3PR iVXkrnl9vv84k+0nePELqyJJIgSRP9wSmw==
X-Google-Smtp-Source: APXvYqwWFD83aIpGtNzOObj6Ci2NGJSSyRZknJIUukXErhTyjaZRLvMfi8O3txGQif+NSyvORZJVLQ==
X-Received: by 2002:a05:6638:303:: with SMTP id w3mr32816234jap.103.1563999300192;  Wed, 24 Jul 2019 13:15:00 -0700 (PDT)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id e84sm56908965iof.39.2019.07.24.13.14.59 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
Received: by mail-io1-f54.google.com with SMTP id g20so92297821ioc.12 for ; Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
X-Received: by 2002:a6b:6e01:: with SMTP id d1mr6177884ioh.156.1563999299241;  Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
MIME-Version: 1.0
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>  <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com> <1903519861.188545.1563954610968@mail.yahoo.com>
In-Reply-To: <1903519861.188545.1563954610968@mail.yahoo.com>
From: Aaron Parecki 
Date: Wed, 24 Jul 2019 16:13:55 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Tomek Stojecki 
Cc: Brian Campbell ,  David Waite , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000a90f29058e72f611"
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 20:15:08 -0000

--000000000000a90f29058e72f611
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

*whew* this is a lot of feedback. I will try to address all of these points
in this thread.

On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt 
wrote:

1) This BCP should not be limited to public clients. Your BCP itself
> already describes an architecture where the OAuth client is a backend tha=
t
> may be a confidential client (see section 6.2 for an example). The text o=
f
> the BCP generally seems to be inconsistent regarding oauth client types.
> I suggest to remove the second part of the first paragraph of the abstrac=
t
> (=E2=80=9Cand should not be issued a client secret when registered.") and=
 other
> statements limiting the BCP to public clients.


Agreed, this was a holdover from before I added the section that describes
the confidential client architecture option. I've updated this accordingly.

2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potentia=
l
> architecture. I don=E2=80=99t think we should get into the business of re=
commending
> and assessing other solutions (e.g. section 6.1.).


This section was originally added from a discussion on the list, I believe
it was actually Torsten's suggestion:
https://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The
section was later modified and expanded based on feedback from the meeting
in Prague.

Although taking out "and OpenID Connect" from the sentence quoted above
> might be more appropriate and alleviate some confusion.


I will remove this, since this document is supposed to be focusing on OAuth
anyway.

3) The naming in section 6 focus on the ways the JS could be served. I
> personally think the more important aspect is the architecture of the
> overall application.



I suggest the following changes:
> - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend
> - 6.3. Apps Served from a Static Web Server -> SPA without backend


I agree, but I'd like to continue to avoid using the term "SPA," so I'll
expand it out to "JavaScript Applications with a Backend".

4) I don=E2=80=99t understand why your BCP distinguishes 1st and 3rd party =
apps.
> Neither the Native apps BCP nor security BCP do so and need to.


This was part of the original brainstorming of the document at IIW in
October, because many of us were worried about people deploying "creative"
solutions in first-party app situations such as iframes or using the
password grant. The intent was to be explicit about using the OAuth
authorization code flow rather than password or an iframe solution even for
first-party apps.

5) Section 9.8 seems to duplicate portions of the Security BCP (while not
> giving the complete threat model) - what is the benefit of duplicating th=
is
> text?


The intent here is to explicitly point out the issues with returning access
tokens in the front channel, in a way that is easy to find if someone is
looking for "what's wrong with using the implicit flow". I'd be happy to
shorten these to summaries and link out to the security BCP for the
details, but I do think it's valuable to have these called out in this
document.

6) I think the BCP would benefit from a refactoring. One idea would be to
> first state the problem with implicit and give general recommendations
> (PKCE and so on). The latter part could get into details of access and
> refresh token protection in the context of different SPA architectures
> (mTLS, CORS for CSRF prevention, =E2=80=A6).


One reason I didn't want to go with this approach is it kind of reinforces
the assumption that implicit flow =3D=3D browser apps. Instead of defining =
the
BCP in terms of what *not* to do, I wanted to start with the
recommendations for what you *should* do when building a browser-based app,
and eventually get to describing why not to use the implicit flow.

On Tue, Jul 23, 2019 at 12:25 AM Leo Tohill  wrote:

Is this BCP supposed to be all about the architecture where the browser
> holds the token(s)?


I believe that was the original intent, but then we wanted to call out the
case that you can actually have a SPA where the tokens don't live in the
browser and that may be a better choice for you.

On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki  wrote:

Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, whil=
e
> good for some things, seems to have a lot of shortcomings for this sort o=
f
> discussion and review.


I would *love* to have this discussion on GitHub with individual GitHub
issues for each conversation thread, since it would be much easier to keep
track of when a particular conversation has been resolved. But my
understanding is that only the mailing list is the "official" or "on the
record" medium, so discussion has to happen here.

The changes mentioned here are now pushed to my GitHub version.

----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki  wrote:

> I agree that 6.1 takes too broad of a swipe, but I'd say with same-site
> cookies and (sadly) without token-binding, the suggestion to use cookie
> based session following oauth/oidc auth is a good one and should be
> incorporated perhaps in 6.2?
>
> Leo sums it up well here:
> > We need to be clear on the distinction between browser based apps that
> hold the token(s) in the browser space, vs. those that don't.  I agree th=
at
> with this "common domain" architecture, the tokens should not be held in
> the browser, but it doesn't follow that oauth should not be used at all.
>
> Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, whil=
e
> good for some things, seems to have a lot of shortcomings for this sort o=
f
> discussion and review.
>
> Thanks,
> Tomek
>
>
> On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite <
> david@alkaline-solutions.com> wrote:
>
>
>
>
>
>
>
> > On Jul 23, 2019, at 12:47 PM, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
> >
> >
> >
> > On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> >>
> >> 2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potentia=
l
> architecture. I don=E2=80=99t think we should get into the business of re=
commending
> and assessing other solutions (e.g. section 6.1.). Just to give you an
> example: Section 6.1. states
> >>
> >> "OAuth and OpenID Connect provide very little benefit in this
> deployment scenario, so it is recommended to reconsider whether you need
> OAuth or OpenID Connect at all in this case.=E2=80=9D
> >>
> >> Really? What experiences is this statement based on? In my experience,
> sharing the same domain =3D=3D host name tells you nothing about the over=
all
> architecture of a certain deployment. There may be several reasons why
> OAuth could be good choice in such a scenario, e.g. security consideratio=
ns
> (since your common domain is just a proxy server encapsulating a whole
> universe of systems) or even modularity as an architecture principle.
> >>
> >> I suggest to remove section c. and to rephrase the second paragraph of
> the abstract.
> >
> > I believe the experiences that the statement is based on are the
> predominant practice over the course of much of the history of the web of
> using a cookie to maintain an authenticated HTTP session in web
> applications. When the script of the browser-based application is served
> from a domain that can share cookies with the domain of the API, then
> cookies can still be used to authorize requests (even if those requests a=
re
> API calls rather than full page HTTP request/response). And I do believe
> that's likely a better decision in a lot of such cases.
> >
> > That authenticated HTTP session may be establish from a
> username/password form submission, FIDO/WebAuthn, or whatever.  Even as a
> result of an OpenID Connect flow. Or even SAML for that matter. But the t=
he
> requests after that are authorized by the cookie.
> >
> > I think there's a tendency to assume because SPA style apps make API
> calls, they simply must use OAuth. Because API implies OAuth in the minds
> of many (which is a sign of its success). But OAuth isn't necessarily the
> only thing that can be used for API authorization. Cookies work too. I
> think/hope that's what Section 6.1. is getting at - providing some
> potential guidance that OAuth might not necessarily be the right choice i=
n
> those cases where a common domain allows for a cookie. Perhaps the text i=
n
> that section could be phased in a different or better way, but I think it=
s
> useful to have some mention of in this document.
> >
> > Although taking out "and OpenID Connect" from the sentence quoted above
> might be more appropriate and alleviate some confusion.
> >
> >
>
> Perhaps it should be turned into a stated document assumption (that the
> reader has decided to use OAuth) rather than guidance later in the docume=
nt
> (that OAuth may not be the best fit)
>
> There is AFAIK no set of security considerations or best practices we can
> point to for =E2=80=9Cuse some non-standardized system for acquiring and =
using
> cookies=E2=80=9D or even =E2=80=9Chere=E2=80=99s a standard for acquiring=
 and using cookies=E2=80=9D.
> Omitting some of the moving pieces of OAuth might alleviate some security
> concerns, but also resurrect some other security issues. The most immedia=
te
> example that comes to mind: using a HttpOnly cookie-as-token instead of a=
n
> access token may mean that you can=E2=80=99t have injected scripts exfilt=
rate the
> token, but applying the access token was also a mitigation against browse=
r
> CSRF for your APIs.
>
> -DW
> _______________________________________________
> 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
>

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


*whew* this is a lot of feedback. I =
will try to address all of these points in this thread.
=C2=A0
On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<=
/div>

1) Th=
is BCP should not be limited to public clients. Your BCP itself already des=
cribes an architecture where the OAuth client is a backend that may be a co=
nfidential client (see section 6.2 for an example). The text of the BCP gen=
erally seems to be inconsistent regarding oauth client types.
I suggest =
to remove the second part of the first paragraph of the abstract (=E2=80=9C=
and should not be issued a client secret when registered.") and other =
statements limiting the BCP to public clients.=C2=A0

<=
/div>
Agreed, this was a holdover from before I added the section that =
describes the confidential client architecture option. I've updated thi=
s accordingly.

2) Regarding architectures: I think this BCP should focus on rec=
ommendations for securely implementing OAuth in the different potential arc=
hitecture. I don=E2=80=99t think we should get into the business of recomme=
nding and assessing other solutions (e.g. section 6.1.).
<=
br>
This section was originally added from a discussion on the li=
st, I believe it was actually Torsten's suggestion:=C2=A0https=
://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q=C2=
=A0The section was later modified and expanded based on feedback from the m=
eeting in Prague.

Although taking out "and OpenID Connect" from the se=
ntence quoted above might be more appropriate and alleviate some confusion.=


I will remove this, since this document is=
 supposed to be focusing on OAuth anyway.

3) The naming in section 6 focus on th=
e ways the JS could be served. I personally think the more important aspect=
 is the architecture of the overall application.
=C2=A0
I suggest the following changes:=C2=A0
- 6=
.2. Apps Served from a Dynamic Application Server -> SPA with backend- 6.3. Apps Served from a Static Web Server -> SPA without backend=C2=
=A0

I agree, but I'd like to continue t=
o avoid using the term "SPA," so I'll expand it out to "=
JavaScript Applications with a Backend".

4) I don=E2=80=99t understand why =
your BCP distinguishes 1st and 3rd party apps. Neither the Native apps BCP =
nor security BCP do so and need to.

This wa=
s part of the original brainstorming of the document at IIW in October, bec=
ause many of us were worried about people deploying "creative" so=
lutions in first-party app situations such as iframes or using the password=
 grant. The intent was to be explicit about using the OAuth authorization c=
ode flow rather than password or an iframe solution even for first-party ap=
ps.

5=
) Section 9.8 seems to duplicate portions of the Security BCP (while not gi=
ving the complete threat model) - what is the benefit of duplicating this t=
ext?

The intent here is to explicitly point=
 out the issues with returning access tokens in the front channel, in a way=
 that is easy to find if someone is looking for "what's wrong with=
 using the implicit flow". I'd be happy to shorten these to summar=
ies and link out to the security BCP for the details, but I do think it'=
;s valuable to have these called out in this document.

=

6) I think the BCP would =
benefit from a refactoring. One idea would be to first state the problem wi=
th implicit and give general recommendations (PKCE and so on). The latter p=
art could get into details of access and refresh token protection in the co=
ntext of different SPA architectures (mTLS, CORS for CSRF prevention, =E2=
=80=A6).

One reason I didn't want to go=
 with this approach is it kind of reinforces the assumption that implicit f=
low =3D=3D browser apps. Instead of defining the BCP in terms of what *not*=
 to do, I wanted to start with the recommendations for what you *should* do=
 when building a browser-based app, and eventually get to describing why no=
t to use the implicit flow.

On Tue, Jul 23, 2019 a=
t 12:25 AM Leo Tohill <leotohill@=
gmail.com> wrote:

Is this BCP supposed to be all about the architectu=
re where the browser holds the token(s)?

I =
believe that was the original intent, but then we wanted to call out the ca=
se that you can actually have a SPA where the tokens don't live in the =
browser and that may be a better choice for you.

O=
n Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki <tstojecki=3D40yahoo.com@dmarc.ietf.org> wrote:<=
br>

F=
inally and sorry if this is off-topic, why isn't this discussion taking=
 place in github? Aaron has uploaded the document there. This medium, while=
 good for some things, seems to have a lot of shortcomings for this sort of=
 discussion and review.

I would *love* to h=
ave this discussion on GitHub with individual GitHub issues for each conver=
sation thread, since it would be much easier to keep track of when a partic=
ular conversation has been resolved. But my understanding is that only the =
mailing list is the "official" or "on the record" mediu=
m, so discussion has to happen here.

T=
he changes mentioned here are now pushed to my GitHub version.

----
Aaron Parecki
=




On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojec=
ki <tstojecki=3D40yahoo.co=
m@dmarc.ietf.org> wrote:
I agree that 6.1 takes too broad of a swipe, but I'd sa=
y with same-site cookies and (sadly) without token-binding, the suggestion =
to use cookie based session following oauth/oidc auth is a good one and sho=
uld be incorporated perhaps in 6.2?



Leo sums it up well here:

> We need to be clear on the distinction between browser based apps that=
 hold the token(s) in the browser space, vs. those that don't.=C2=A0 I =
agree that with this "common domain" architecture, the tokens sho=
uld not be held in the browser, but it doesn't follow that oauth should=
 not be used at all.=C2=A0=C2=A0



Finally and sorry if this is off-topic, why isn't this discussion takin=
g place in github? Aaron has uploaded the document there. This medium, whil=
e good for some things, seems to have a lot of shortcomings for this sort o=
f discussion and review.=C2=A0



Thanks,

Tomek





On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite <david@alkaline-solut=
ions.com> wrote: 















> On Jul 23, 2019, at 12:47 PM, Brian Campbell <bcampbell=3D40pingident=
ity.com@dmarc.ietf.org> wrote:

> 

> 

> 

> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <torsten@lodderstedt.net&=
gt; wrote:

>> 

>> 2) Regarding architectures: I think this BCP should focus on recom=
mendations for securely implementing OAuth in the different potential archi=
tecture. I don=E2=80=99t think we should get into the business of recommend=
ing and assessing other solutions (e.g. section 6.1.). Just to give you an =
example: Section 6.1. states 

>> 

>> "OAuth and OpenID Connect provide very little benefit in this=
 deployment scenario, so it is recommended to reconsider whether you need O=
Auth or OpenID Connect at all in this case.=E2=80=9D

>> 

>> Really? What experiences is this statement based on? In my experie=
nce, sharing the same domain =3D=3D host name tells you nothing about the o=
verall architecture of a certain deployment. There may be several reasons w=
hy OAuth could be good choice in such a scenario, e.g. security considerati=
ons (since your common domain is just a proxy server encapsulating a whole =
universe of systems) or even modularity as an architecture principle. 

>> 

>> I suggest to remove section c. and to rephrase the second paragrap=
h of the abstract.

> 

> I believe the experiences that the statement is based on are the predo=
minant practice over the course of much of the history of the web of using =
a cookie to maintain an authenticated HTTP session in web applications. Whe=
n the script of the browser-based application is served from a domain that =
can share cookies with the domain of the API, then cookies can still be use=
d to authorize requests (even if those requests are API calls rather than f=
ull page HTTP request/response). And I do believe that's likely a bette=
r decision in a lot of such cases. 

> 

> That authenticated HTTP session may be establish from a username/passw=
ord form submission, FIDO/WebAuthn, or whatever.=C2=A0 Even as a result of =
an OpenID Connect flow. Or even SAML for that matter. But the the requests =
after that are authorized by the cookie. 

> 

> I think there's a tendency to assume because SPA style apps make A=
PI calls, they simply must use OAuth. Because API implies OAuth in the mind=
s of many (which is a sign of its success). But OAuth isn't necessarily=
 the only thing that can be used for API authorization. Cookies work too. I=
 think/hope that's what Section 6.1. is getting at - providing some pot=
ential guidance that OAuth might not necessarily be the right choice in tho=
se cases where a common domain allows for a cookie. Perhaps the text in tha=
t section could be phased in a different or better way, but I think its use=
ful to have some mention of in this document. 

> 

> Although taking out "and OpenID Connect" from the sentence q=
uoted above might be more appropriate and alleviate some confusion. 

> 

> 



Perhaps it should be turned into a stated document assumption (that the rea=
der has decided to use OAuth) rather than guidance later in the document (t=
hat OAuth may not be the best fit)



There is AFAIK no set of security considerations or best practices we can p=
oint to for =E2=80=9Cuse some non-standardized system for acquiring and usi=
ng cookies=E2=80=9D or even =E2=80=9Chere=E2=80=99s a standard for acquirin=
g and using cookies=E2=80=9D. Omitting some of the moving pieces of OAuth m=
ight alleviate some security concerns, but also resurrect some other securi=
ty issues. The most immediate example that comes to mind: using a HttpOnly =
cookie-as-token instead of an access token may mean that you can=E2=80=99t =
have injected scripts exfiltrate the token, but applying the access token w=
as also a mitigation against browser CSRF for your APIs.



-DW

_______________________________________________

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




--000000000000a90f29058e72f611--


From nobody Wed Jul 24 14:04: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 1EB081205CD for ; Wed, 24 Jul 2019 14:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyhWuL6a47b8 for ; Wed, 24 Jul 2019 14:04:20 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F84120285 for ; Wed, 24 Jul 2019 14:04:20 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id h6so6048819iom.7 for ; Wed, 24 Jul 2019 14:04:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DTr1PXo99HRzy1hmihvw98vMF/uKCL2Gi3zt7p8L2Jo=; b=dUVOcTXtgUSg2OLQCovlqF3DrRQyJ3EK8V9AH/YgVnvKp6+pmEzo+NC/e37QprAyNB 8yIAJv7x6A/eOtoozx0HY0OvG4lB3mvpdNCbyDRKoIspup8HgxJ34JIxvDh9nH+Tyg3j PFPMwm0erHJ9ro7rzygj1FXJWR+5xcjliZDSVniCnwl0RFulmynUG/GtYVsQ8UuhHINX W295wLVuQs/FNAfJy7ObsRUTlwlVpQWk0Dc7ZUtrWugEsk3CWfcDQtFO8BzXW0UV+7x+ OVCmV0uzC/t+BpcvZfhnbBD7sWGsE5RJgx9tDtlNVZhorgzC+2teg+ps/UwZJG9i9B0u HTfA==
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=DTr1PXo99HRzy1hmihvw98vMF/uKCL2Gi3zt7p8L2Jo=; b=FfszP4oZuVQfpS0j273KBjrRzplDjUugXmGFGxQ0wyGjZIrHtDANFzjYpqy+VHtbM6 IrqCA+Pt9bOmex3f/XcD2+lO+NEgGLqhBSK/Mn5CQBtduuYTIADznBJ+uz4n5xL0WX2u yEk76FZRuh61a4LjyGEpMXUAEiJL26WF2nfdUUOQJ9nosMMzsFvDRGbr7ShOJ6j4a8cF 9zbvAHklMtmTIAvctT+jFgWvKqyhHOcQ2ajj1s7wdFBhaYvPCPe3wB3Q6Wg0hDwir7nb Tey1G0ODLvkV5qQH/4aWEG1H8/ORVapp0ehp/DEx5+/Ck3nQ9BRDzMtyBEo7YONrRyWC yi8Q==
X-Gm-Message-State: APjAAAVB9wd5vouKGBkos/+UCY44j9+LapXlHR3YmpM0OdepXl/02Q80 lf2gceoNvR6boQnGpH0ihJdnLaWjWa7X1A==
X-Google-Smtp-Source: APXvYqyj3y4fKrRbJ8sZvadhobXTN8Po6qFQfQIGz3B75EFyHtyl8tN8ogRndOYTtEdh9Bnsc4VuQg==
X-Received: by 2002:a5d:87da:: with SMTP id q26mr69567084ios.193.1564002259478;  Wed, 24 Jul 2019 14:04:19 -0700 (PDT)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id c17sm35549004ioo.82.2019.07.24.14.04.18 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 14:04:18 -0700 (PDT)
Received: by mail-io1-f54.google.com with SMTP id f4so92628767ioh.6 for ; Wed, 24 Jul 2019 14:04:18 -0700 (PDT)
X-Received: by 2002:a5d:80c3:: with SMTP id h3mr70651554ior.167.1564002258709;  Wed, 24 Jul 2019 14:04:18 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 24 Jul 2019 17:03:14 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dominick Baier 
Cc: OAuth WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 24 Jul 2019 21:04:23 -0000

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:

> I think you are mixing authentication and API access here. Depending on a=
pplication scenario it makes a lot of sense to use OIDC - but rely on the r=
esulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the m=
ention of OIDC because it is misleading.

I agree, I removed the mention of OIDC.

> I would rather say that ANY JS app should use CSP to lock down the browse=
r features to a minimal attack surface. In addition, if refresh or access t=
okens are involved - further settings like disabling inline scripting (unsa=
fe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:
>
> Hey,
>
> Just read the spec - good to see the progress. Some feedback:
>
> I am yet undecided if I like the categorisation of the =E2=80=9CApplicati=
on Architecture Patterns=E2=80=9D. I definitely want to distinguish between=
 applications only accessing same-site back-end services and =E2=80=9Cother=
s=E2=80=9D. Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cs=
tatic application server=E2=80=9D should be handled differently - they are =
deployment details and should not decide on the application security archit=
ecture. Also not sure how realistic it is to deploy a typical applications =
solely from e.g. a CDN. But I don=E2=80=99t have the right answer wrt to ca=
tegories right now.
>
> 6.1.  Apps Served from a Common Domain as the Resource Server
>
> > OAuth and OpenID Connect provide very little benefit in this
>    deployment scenario, so it is recommended to reconsider whether you
>    need OAuth or OpenID Connect at all in this case.
>
> I think you are mixing authentication and API access here. Depending on a=
pplication scenario it makes a lot of sense to use OIDC - but rely on the r=
esulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the m=
ention of OIDC because it is misleading.
>
>
> 6.2.  Apps Served from a Dynamic Application Server
>
> I have a .NET sample for that
>
> https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetco=
re21/BFF
> And a blog post
> https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-w=
ith-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>
> 9.7.  Content-Security Policy
>
>    A browser-based application that wishes to use either long-lived
>    refresh tokens or privileged scopes SHOULD restrict its JavaScript
>    execution to a set of statically hosted scripts via a Content
>    Security Policy ([CSP2]) or similar mechanism.
>
>
>
> I would rather say that ANY JS app should use CSP to lock down the browse=
r features to a minimal attack surface. In addition, if refresh or access t=
okens are involved - further settings like disabling inline scripting (unsa=
fe inline) and eval should be disabled.
>
> Thanks for doing this work!
>
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Jul 24 14:30:45 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 C915A12029D; Wed, 24 Jul 2019 14:30:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <156400383672.14498.1168900276430538935@ietfa.amsl.com>
Date: Wed, 24 Jul 2019 14:30:36 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 21:30:37 -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           : Resource Indicators for OAuth 2.0
        Authors         : Brian Campbell
                          John Bradley
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-resource-indicators-05.txt
	Pages           : 13
	Date            : 2019-07-24

Abstract:
   An extension to the OAuth 2.0 Authorization Framework defining
   request parameters that enable a client to explicitly signal to an
   authorization server about the identity of the protected resource(s)
   to which it is requesting access.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-05


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

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


From nobody Wed Jul 24 14:44: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 B4F1D120159 for ; Wed, 24 Jul 2019 14:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7yHxhD-YvLX0 for ; Wed, 24 Jul 2019 14:44:07 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82B01202EC for ; Wed, 24 Jul 2019 14:44:06 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id k8so92877716iot.1 for ; Wed, 24 Jul 2019 14:44:06 -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=Bb96RIuM/BB+bJJKPD9Ik4BjkppOoYwTNwI8T0gnbxw=; b=j17g7TCDhIhfsre3TjEwgo6PlHnki2gYaZV5qIOVOd0m12GkBHHLM7dIFo1aFAKghr Y4s11d8zVteaqblsxURGpg8qh7Oq6f/SPuppF8wQrBNt0xXFBfcK9YIpVdoOBC9hSNGo WoTcNX5ME3BR34CjEv98pyr6F1UOY8wldvPT9Sgs56BNYwO7r3eidzl+OSZOERWnFYJl DY9l9Gz81EYUjzwv1ic1MbXrUKKlhGKNLX9G2dsDlmTmkwVGA3V2LVjb/bnwk/GQDa0N 6uaYbfepGAvdPnfgrGtkmLi1Lbkuf8SLSRbnXoE8Akoz0xW8oJHst1XYmNLQmzRDlhJU yodQ==
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=Bb96RIuM/BB+bJJKPD9Ik4BjkppOoYwTNwI8T0gnbxw=; b=nfRtJht3IvP55Bw6mxa30PPzK4R5w3ggWX993gMfM3XeCC/Eo9TcoE/uAA0/5vCTr3 yJfN21al9l7B9EjbAcFIqXdTXB7lC7kJ1EOBTVLM8lmWgvjCf9H4lMBAoajEH+lZMM0y kejQskN2yt4CfKDITa1XtZtvgMpnSN9BAgJaVq2hfsNAtSBphdqzZNMbTN8cXYJaIfuA bVJAdrID31cYbRRFKEu3hgjDC4yDbZDiy0Z56kljrpORDPKOldjgacSwp4/EYY7NJizZ 37riTLJL7mtmssW35qTxSXDye2U6D66O96visrncAUknIW71/+e1LBgiMqJgENigQufy j2TA==
X-Gm-Message-State: APjAAAUTYU+cM7PGMPCkWm5dA8un9nxtK8cmNQuT/LkB1rWVfKe3CSVt z4I8pqWh9+kCV8JRTh7lg++Crar0gNj7/Q==
X-Google-Smtp-Source: APXvYqzvKb6v/tWCZ4wfQttUeVqQni7YczkrJOoKjp52tJCwX5LemgDohA92v2rGiO12UugqOz8/Kw==
X-Received: by 2002:a6b:b756:: with SMTP id h83mr47783657iof.147.1564004645932;  Wed, 24 Jul 2019 14:44:05 -0700 (PDT)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id r24sm34405635ioc.76.2019.07.24.14.44.04 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 14:44:05 -0700 (PDT)
Received: by mail-io1-f42.google.com with SMTP id e20so62423895iob.9 for ; Wed, 24 Jul 2019 14:44:04 -0700 (PDT)
X-Received: by 2002:a5d:80c3:: with SMTP id h3mr70818467ior.167.1564004644761;  Wed, 24 Jul 2019 14:44:04 -0700 (PDT)
MIME-Version: 1.0
References:  <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com>   <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
In-Reply-To: <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
From: Aaron Parecki 
Date: Wed, 24 Jul 2019 17:43:00 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Justin Richer 
Cc: Leo Tohill , OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000047368d058e7435f1"
Archived-At: 
Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for 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, 24 Jul 2019 21:44:10 -0000

--00000000000047368d058e7435f1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There are two primary aspects of OAuth that are undesirable in this
situation:

1) Using a redirect-based OAuth flow to obtain an access token adds
unnecessary attack vectors to the application (see all the redirect-based
attacks in the Security BCP)
2) Storing the access token somewhere accessible to JavaScript is
unnecessary since the JS doesn't need access to it if it can share a cookie
domain with the API (RS)

These are the main points I am trying to get across in this section, so
I've expanded that section to mention these points more explicitly. I've
rephrased the whole section, added a reference to potentially using the
"SPA with backend" option in the following section, but there is still the
lingering case of:

If your JavaScript application has no backend, but still shares a domain
> with the resource server, then it may be best to avoid using OAuth entire=
ly.


Is it worth pursuing this to try to find an OAuth-based solution for this
particular architecture? (The app, AS and RS share a common domain, and
there is no backend other than the RS.) Something like a cookie-based OAuth
flow?

----
Aaron Parecki
aaronparecki.com
@aaronpk


----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Wed, Jul 24, 2019 at 10:19 AM Justin Richer  wrote:

> It would perhaps  be better to phrase it as =E2=80=9Cdon=E2=80=99t use OA=
uth in the
> JavaScript application directly=E2=80=9D instead of =E2=80=9Cnot entirely=
=E2=80=9D.
>
> =E2=80=94 Justin
>
> On Jul 23, 2019, at 12:14 AM, Leo Tohill  wrote:
>
> I didn't see the earlier discussion (do you have a date or title?) so
> apologies if I'm bringing up something that's been resolved.  But I still
> think that it's really confusing to say "it
> may be a better decision to avoid using OAuth entirely"  if the
> application will still be using Oauth/OIDC (which will, of course, involv=
e
> a browser flow).
>
> orsten@lodderstedt.net   has raised the same (or
> similar?) objection in a parallel thread.  I suggest we continue the
> conversation there.
>
> - Leo
>
>
> On Mon, Jul 22, 2019 at 1:09 PM Hans Zandbelt 
> wrote:
>
>> +1, as discussed before
>>
>> Hans.
>>
>> On Mon, Jul 22, 2019, 18:25 Brock Allen  wrote:
>>
>>> I think the implication is that the server-side would use something lik=
e
>>> OIDC to the token server in order to establish the identity of the user=
.
>>> The difference is that this would be driven from the server-side piece =
of
>>> the application, as any other normal server-side client would. The resu=
lt
>>> would then simply be a cookie-based authentication session in the clien=
t,
>>> and any JS code would leverage the http only, same-site cookie for Ajax
>>> calls.
>>>
>>> -Brock
>>>
>>> On 7/21/2019 10:22:38 PM, Leo Tohill >> > wrote:
>>> The advice for the architectural pattern "JavaScript served from a
>>> common domain as the resource server"  reads:
>>>
>>> "For simple system architectures, such as when the JavaScript
>>> application is served
>>> from a domain that can share cookies with the domain of the API
>>> (resource server), it
>>> may be a better decision to avoid using OAuth entirely, and instead use
>>> session
>>> authentication to communicate directly with the API."
>>>
>>> I can agree that session authentication could be best here, but how was
>>> the user authenticated in order to create the trusted session?  Wouldn'=
t
>>> that/shouldn't that still use an oauth flow to collect credentials?
>>>
>>> We need to be clear on the distinction between browser based apps that
>>> hold the token(s) in the browser space, vs. those that don't.  I agree =
that
>>> with this
>>> "common domain" architecture, the tokens should not be held in the
>>> browser, but it doesn't follow that oauth should not be used at all.
>>>
>>> Leo
>>>
>>>
>>> _______________________________________________ OAuth mailing list
>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


There are two primary aspects of OAuth that are undesirabl=
e in this situation:

1) Using a redirect-based OAuth flow to obtain =
an access token adds unnecessary attack vectors to the application (see all=
 the redirect-based attacks in the Security BCP)
2) Storing the access t=
oken somewhere accessible to JavaScript is unnecessary since the JS doesn&#=
39;t need access to it if it can share a cookie domain with the API (RS)
These are the main points I am trying to get across in this section, s=
o I've expanded that section to mention these points more explicitly. I=
've rephrased the whole section, added a reference to potentially using=
 the "SPA with backend" option in the following section, but ther=
e is still the lingering case of:

If your JavaScript application has no backend, but still sh=
ares a domain with the resource server, then it may be best to avoid using =
OAuth entirely.

Is it worth pursuing this to try=
 to find an OAuth-based solution for this particular architecture? (The app=
, AS and RS share a common domain, and there is no backend other than the R=
S.) Something like a cookie-based OAuth flow?

----
Aaron Parecki<=
br>aaronparecki.com
@aaronpk
=


----
Aaron Parecki



On Wed, Jul 24, 2019 at 10:19 AM Justin Richer <jricher@mit.edu> wrote:






It would perhaps =C2=A0be better to phrase it as =E2=80=9Cdon=E2=80=99t use=
 OAuth in the JavaScript application directly=E2=80=9D instead of =E2=80=9C=
not entirely=E2=80=9D.=C2=A0







=E2=80=94 Justin









On Jul 23, 2019, at 12:14 AM, Leo Tohill <leotohill@gmail.com> wrote:






I didn't see the earlier discussion (do you have a dat=
e or title?) so apologies if I'm bringing up something that's been =
resolved.=C2=A0 But I still think that it's really confusing to say &qu=
ot;it


may be a better decision to avoid using OAuth entirely"=C2=A0 if =
the application will still be using Oauth/OIDC (which will, of course, invo=
lve a browser flow).







orsten@lodderstedt.net=
=C2=A0 has raised the same (or similar?) objection in a parallel thread.=C2=
=A0 I suggest we continue the conversation there.










- Leo















On Mon, Jul 22, 2019 at 1:09 PM Hans =
Zandbelt <hans.zandbelt@zmartzone.eu> wrote:






+1, as discussed before






Hans.








On Mon, Jul 22, 2019, 18:25 Brock All=
en <brockallen=
@gmail.com> wrote:







I think the implication is that the server-side would use something like OI=
DC to the token server in order to establish the identity of the user. The =
difference is that this would be driven from the server-side piece of the a=
pplication, as any other normal
 server-side client would. The result would then simply be a cookie-based a=
uthentication session in the client, and any JS code would leverage the htt=
p only, same-site cookie for Ajax calls.=C2=A0








-Brock













On 7/21/2019 10:22:38 P=
M, Leo Tohill <leotohill@gmail.com> wrote:






The advice for the architectural pattern "JavaScript served from =
a common domain as the resource server"=C2=A0 reads:









"For simple system architectures, such as when the JavaScript app=
lication is served

from a domain that can share cookies with the domain of the API (resource s=
erver), it

may be a better decision to avoid using OAuth entirely, and instead use ses=
sion

authentication to communicate directly with the API."







I can agree that session authentication could be best here, but how wa=
s the user authenticated in order to create the trusted session?=C2=A0 Woul=
dn't that/shouldn't that still use an oauth flow to collect credent=
ials?







We need to be clear on the distinction between browser based apps that=
 hold the token(s) in the browser space, vs. those that don't.=C2=A0 I =
agree that with this


"common domain" architecture, the tokens should not be held in th=
e browser, but it doesn't follow that oauth should not be used at all.










Leo















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







_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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









_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth














_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000047368d058e7435f1--


From nobody Wed Jul 24 14:46:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803AC120448 for ; Wed, 24 Jul 2019 14:46: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, 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=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 7f11-YqUTYrh for ; Wed, 24 Jul 2019 14:46:13 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D800120159 for ; Wed, 24 Jul 2019 14:46:10 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id x25so46007545ljh.2 for ; Wed, 24 Jul 2019 14:46: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=LsBerXTAQs8wakr4TiSgkdxLH+08d2cM/wykw8XPzyc=; b=ZDeoJ82bmvOWLyQczrE60fBSq2rEnjphU5ywlz3+Tv+uVnKEpwgt9WROhR+RUC3+xF tAIi3EjuwVx941l/gMa1Zjdq8n5QEF0D1M5bRDU8jjn468cLz2MPY4izW5yG4CWYLWFd hFUBbiWr7E8HLI29cBDAHN2uHEDGLOLiumiGbhEh4DsuCvekciVOv/pSTyRHnjJAkl83 0YNftK5QyVFVARWdeCtkvp5oj/Dg8mVJNGh2hyaoyJX1VnwToLKYY+pnuusw2eMRXY2Z B7gFCbO/hxO3f6fkjsa+vG0Sx0vS3i3FIOfv9yuOHI5O9O9l0R1Sy6GICjD65Lw7Jac5 8csA==
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=LsBerXTAQs8wakr4TiSgkdxLH+08d2cM/wykw8XPzyc=; b=NKv8PR7BQJ59S43Swp3izi9/Y3vYmYjX8L6jG/q1dq4WOACdBLayU9bKuUL5OMeK4F cR5S7wGtJvD73/k+OlSbX/2MWAS49nkdzD2HqbLf4lSlZsCoj2wNpxoj1VAbvbYrns67 RPZvacRMJWQzpSHaVitkJ3Rf8G24l3Zb5hM/VQJM8k1rP0e5eZ0HHVjzFPir6Y2J0BAU TAtjae8SCP4NNWdtkDNhMe5oaCaOGKrHVEJRT7pn5KblVopWnNkagp83/71ozY5TdN06 K5KCAkgopNv7ntThmbiAvTvkr2NlQWTSoMQwCiwQxUkdiVzLqIF7uYUkKttyDkVvPkgW leRw==
X-Gm-Message-State: APjAAAVBUaMSrTNhBeJjGIymAJBucLbUvq9H4r+rF1NRhCLvZd+6qElP kkmFJshx3eDPUT3t9L6OIkwKWfwIakaOtyqPiAHpXQ==
X-Google-Smtp-Source: APXvYqz6Qm0CerecJBLWJcTfhP4+JwH4zjXgv9aE+b9Iz9YKahSXOVFgMPpsAyL2mpTlq7tcgju+KF+lozmQquurVjQ=
X-Received: by 2002:a2e:9ad1:: with SMTP id p17mr44374749ljj.34.1564004768018;  Wed, 24 Jul 2019 14:46:08 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Vittorio Bertocci 
Date: Wed, 24 Jul 2019 14:45:56 -0700
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000a009f5058e743ce4"
Archived-At: 
Subject: Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 21:46:20 -0000

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

Thank you Brian for the thorough and insightful review!

Comments:

> On authenticated encryption.
I did chat with Neil about his draft, but as you mention I didn't reference
it given that it hasn't bee picked up (yet?).
On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My
rationale is that this profile attempts to capture current practices or
practices that are close enough to the capabilities of existing systems to
have a reasonable chance of being adopted. None of the products/services
surveyed used authenticated encryption, and the requirement to acquire a
symmetric key out of band throws  a big wrench in the otherwise clear-cut
process of preparing your RS to handle JWT ATs. I will bring the matter up
as open issue on Friday, and if the consensus will be to include symmetric
authenticated encryption I'll do that; but my personal preference would be
to preserve the simplicity of a concrete,
nothing-of-substance-left-as-exercise-to-the-reader solution that can be
achieved when the key material can be advertised via metadata.
Typo fixed.


>Connect doesn't say anything about checking the "typ" header of id tokens
[..] this document probably shouldn't overstate what typing the JWT can
accomplish.  [..]  'nonce' in ID Tokens delivered via the front channel
[..] to be interpreted as id_tokens.

This is a very fair point, the current language is misleading. I rephrased
to position the header typing as a hint.
About the nonce mitigation you mention. Do you think this means that I
should explicitly forbid the presence of a "nonce" claim in JWT ATs?


>I think you want to say here that the scope claim in the token has to
correlate to the scope which was approved. Not necessarily what what
requested. The authorization request might ask for scope of a+b+c, for
example, while the user only approves b. Or any other variation on things
where what was asked for isn't what was gotten..

Here I am trying not to get into the details of what's inside the scope
claim, more requesting that if "scope" was in the request, the issued token
should express a delegation and a symptom of that should be the presence of
the scope claim. Paradoxically that scope claim might be empty if the user
only consented to scopes that have effect on the presence of other claims
in the token (say a functional equivalent of profile). Yes, it does sound
odd, but that's a side effect of the prohibition of sending id_tokens to
API that creates the requirement to create functional equivalents.


> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an
"invalid_target" error code that is intended for this kind of thing. So
that should probably be allowed. If not suggested. Probably not required
though.

Wonderful, that is a better fit- love it. I added it as possible
alternative to "invalid_request".


>I personally think the SHOULD is too strong here because it puts the onus
on the resource server to know about (via some config option or something)
and enforce on every transaction a setup/policy thing that the AS is
responsible for which isn't about the integrity of the authorization data
in the token. A MAY or even removing the list item would be preferred.

I borrowed this language straight from the OpenID Connect validation steps
for idtokens. Given that JWT ATs can carry identity info, the requirement
seemed appropriate... also, I think it is reasonable to expect the resource
server to know about its own registration- just like it must know about the
expected aud value and what key should be used to decrypt messages, it
should know whether encryption was requested or not. In fact, the fact that
such option was selected at registration time is likely the reflection of a
policy of the RS itself, something the RS itself would want to ensure has
been respected. WDYT?


>multi value audiences

I see the issue. I definitely don't want to redefine the semantic of aud,
but I also would like to be as crisp as possible on the audience-scope
correlation and prevent scopes from being misinterpreted as applying to the
wrong resource. The aud validation will likely happen in some middleware in
front of the API, but authorization checks might happen in the body of the
API itself when the actual access is being attempted, and having an OR list
in the aud claim might lead to false positives. RSes correctly written
should not suffer from this issue (the authorization logic should receive
only the value from the aud collection that is an actual match) but I have
seen enough sloppy implementations to be skeptical about this.
As a result, I would be inclined to  take out the sentence "or if it
contains additional audiences that are not known aliases of the resource
indicator of the current resource server", effectively restricting to
single value aud and eliminating this issue.


>I think it'd be worthwhile to explicitly disallow the use of the "none"
algorithm here.

Good point. I am all for doing everything we can to defuse that FUD. I
added language that explicitly disallow RS to accept JWTs with "alg":"none"


>Little 'o' in TOken -> Token
fixed


> A link directly to SCIM alone from the JSON Web Token Claims registry
might be rather confusing.

Added a reference as you suggested in all the entries. I am always confused
by forward references whenever the syntax requires the use of an RFC number
that isn't available, but the [[]] trick is a good one.
I didn't follow the "subcompact" considerations, I'll bug you offline for
clarifications. Thx in advance


>Pingidentity

Fixed! Sorry for not having done in 01, I think you mentioned this already.

On Wed, Jul 24, 2019 at 12:59 PM Brian Campbell  wrote:

>
> 2.1.  Header
>
>>    NOTE: there were discussions about adding a reference to
>>    authenticated encyption methods as well, but there's no internet
>>    draft specifying interoperable public key methods at this time
>>
> Well, Neil did write this up a while back
> https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01 which is
> certainly interesting and I wonder if it's something that this group (or
> some other group?) should look at working on. But it is only an individual
> draft (with all the authority that brings to bear
> ) and thus I do
> agree that it isn't appropriate or useful for this document to reference.
>
> However JWE RFC7516 and more JWA RFC7518 do have authenticated encryption
> with symmetric keys that, IMHO, can work very nicely in some cases for JWT
> access tokens by providing both integrity protection and confidentiality.
> And the size and performance benefits thereof can be sufficiently useful so
> as to justify the need to do an out-of-band exchange of the symmetric key.
>
> Also encyption should be encryption.
>
>
> 2.1.  Header
>
>>    The typ header parameter for a JWT access token MUST be at+jwt.  See
>>    the security considerations section for details on the importance of
>>    preventing JWT access tokens to be interpreted as id_tokens.
>
> 5.  Security Considerations
>
>>    The JWT access token data layout described here is very similar to
>>    the one of the id_token as defined by [OpenID.Core].  Without the
>>    explicit typing required in this profile, in line with the
>>    recommendations in [JWT..BestPractices] there would be the risk of
>>    attackers using JWT access tokens in lieu of id_tokens.
>
> Connect doesn't say anything about checking the "typ" header of id tokens
> so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT
> access tokens being used as id tokens. It can prevent misuse in the other
> direction. But this document probably shouldn't overstate what typing the
> JWT can accomplish.
>
> BTW, there's been some discussion and agreement that the requirement
> around 'nonce' in ID Tokens delivered via the front channel (the only time
> connect is subject to that kind of token swapping) is sufficient to protect
> against JWT access tokens (and other types of JWTs) to be interpreted as
> id_tokens. So I think the risk is acceptable but just think the text in the
> draft shouldn't make claims which are untrue.
>
>
> 2.2.2.  Authorization Claims:
>
>>    If an authorization request includes a scope parameter, the
>>    corresponding issued JWT access token
>>
>   MUST in -01/SHOULD in -02 include a scope claim
>>
> as defined in
>>
> I think you want to say here that the scope claim in the token has to
> correlate to the scope which was approved. Not necessarily what what
> requested. The authorization request might ask for scope of a+b+c, for
> example, while the user only approves b. Or any other variation on things
> where what was asked for isn't what was gotten..
>
>
> 3.  Requesting a JWT Access Token
>
>>    If it receives a request for an access token containing more than one
>>    resource parameter, an authorization server issuing JWT access tokens
>>    MUST reject the request and fail with invalid_request as described in
>>    section 4.1.2.1 of [RFC6749].
>>
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an
> "invalid_target" error code that is intended for this kind of thing. So
> that should probably be allowed. If not suggested. Probably not required
> though.
>
> 4.  Validating JWT Access Tokens
>
>>       If encryption was negotiated with the
>>        authorization server at registration time and the incoming JWT
>>        access token is not encrypted, the resource server SHOULD reject
>>        it.
>>
> I personally think the SHOULD is too strong here because it puts the onus
> on the resource server to know about (via some config option or something)
> and enforce on every transaction a setup/policy thing that the AS is
> responsible for which isn't about the integrity of the authorization data
> in the token. A MAY or even removing the list item would be preferred.
>
> 4.  Validating JWT Access Tokens
>
>>      The JWT access token MUST be
>>        rejected if aud does not list the resource indicator of the
>>        current resource server as a valid audience, or if it contains
>>        additional audiences that are not known aliases of the resource
>>        indicator of the current resource server.
>>
> 5.  Security Considerations
>
>>    This profile explicitly forbids the use of multi value aud claim when
>>    the individual values refer to different resources, as that would
>>    introduce confusion about what scopes apply to which resource-
>>    possibly opening up avenues for elevation of delegated privileges
>>    attacks.  Alternative techniques to prevent scope confusion include
>>    "scope stuffing", imposing to every individual scope string to
>>    include a reference to the resource they are meant to be applied to,
>>    but its application is problematic (scope opacity violations, size
>>    inflation, more error conditions become possible when the combination
>>    of requested scopes and resource indicators is invalid) and the
>>    observed frequency of the scenario doesn't warrant complicating the
>>    more common cases.
>>
> I do think I see the simplification you're aiming at with this stuff but
> I'd like to offer the perspective of how this is likely more complicated
> for standards based JWT library implementations. The semantics of aud in
> RFC 7519 basically say that the recipient has to identify with at least one
> of the aud values. It's effectively a big OR. While the text in this draft
> changes that semantic to say that the recipient has to identify with at
> every one of the aud values. Effectively making it a big AND. Normal JWT
> libraries will need nonstandard one-off functionality or adaptations to get
> this right.
>
>
>  4.  Validating JWT Access Tokens
>
>>       The resource server MUST validate the signature of all incoming
>>        JWT access token according to [RFC7515] using the algorithm
>>        specified in the JWT alg Header Parameter.  The resource server
>>        MUST use the keys provided by the authorization server.
>>
> I think it'd be worthwhile to explicitly disallow the use of the "none"
> algorithm here. I think/suspect that it is implied already. But at least
> some of the JWT hate out there seems to stem from or focus on statements
> like this one and conclude that words like "MUST validate ... according to
> [the] algorithm specified in the JWT alg Header Parameter" means that to be
> spec compliant one has to accept "alg":"none" as valid. That's more of a
> logical leap than I think is reasonable but I'd like to avoid it anyway if
> possible. And it's not a bad thing to remind folks not to accept "none"
> here.
>
> 7.2.  Claims Registration
>
>>     claims in the JSON Web TOken (JWT) IANA
>>
> Little 'o' in TOken -> Token
>
>
> 7.2.1.  Registry Contents
> |   Specification Document(s): section 4.1.2 of [RFC7643]
> Ultimately this is what will show up in the "References" column in the
> registry https://www.iana.org/assignments/jwt/jwt.xhtml and thus I'd
> suggest that it also include something like "Section 2.2.2.1 of [[this
> specification]]" there too so someone who starts from the registry has the
> link to and context of this document. A link directly to SCIM alone from
> the JSON Web Token Claims registry might be rather confusing.
> For the folks that will have to review and act on these registrations at
> some point, it might be nice to give em a little better
> grouping/formatting. I'm thinking along the lines of what is done here
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-18#section-7.4.1,
> which you can corice xml2rfc into doing with  and  rfc subcompact="no"?> as in the src at
> https://github.com/oauth-token-exchange/spec/blob/master/draft-ietf-oauth-token-exchange.xml#L1191
>
> Appendix A.  Acknowledgements
>
>>     Brian Campbell (PingIdentity)
>>
> My corporate overloads will be happier if you put a space between Ping and
> Identity.
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Thank you Brian for the thorough and insightful review!
Comments:

> On authenticated encrypt=
ion.
I did chat with Neil about his draft, but as you mention I d=
idn't reference it given that it hasn't bee picked up (yet?).
=

On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My ra=
tionale is that this profile attempts to capture current practices or pract=
ices that are close enough to the capabilities of existing systems to have =
a reasonable chance of being adopted. None of the products/services surveye=
d used authenticated encryption, and the requirement to acquire a symmetric=
 key out of band throws=C2=A0 a big wrench in the otherwise clear-cut proce=
ss of preparing your RS to handle JWT ATs. I will bring the matter up as op=
en issue on Friday, and if the consensus will be to include symmetric authe=
nticated encryption I'll do that; but my personal preference would be t=
o preserve the simplicity of a concrete, nothing-of-substance-left-as-exerc=
ise-to-the-reader solution that can be achieved when the key material can b=
e advertised via metadata.
Typo fixed.

<=
br>
>Connect doesn't say anything about checking the "=
;typ" header of id tokens [..] this document probably shouldn't ov=
erstate what typing the JWT can accomplish.=C2=A0 [..]=C2=A0 'nonce'=
; in ID Tokens delivered via the front channel [..] to be interpreted as id=
_tokens.=C2=A0

This is a very fair point, the curr=
ent language is misleading. I rephrased to position the header typing as a =
hint.
About the nonce mitigation you mention. Do you think this m=
eans that I should explicitly forbid the presence of a "nonce" cl=
aim in JWT ATs?


>I think you wan=
t to say here that the scope claim in the token has to correlate to the sco=
pe which was approved. Not necessarily what what requested. The authorizati=
on request might ask for scope of a+b+c, for example, while the user only a=
pproves b. Or any other variation on things where what was asked for isn=
9;t what was gotten..=C2=A0

Here I am trying not t=
o get into the details of what's inside the scope claim, more requestin=
g that if "scope" was in the request, the issued token should exp=
ress a delegation and a symptom of that should be the presence of the scope=
 claim. Paradoxically that scope claim might be empty if the user only cons=
ented to scopes that have effect on the presence of other claims in the tok=
en (say a functional equivalent of profile). Yes, it does sound odd, but th=
at's a side effect of the prohibition of sending id_tokens to API that =
creates the requirement to create functional equivalents.


>=C2=A0https://tools.ietf.org=
/html/draft-ietf-oauth-resource-indicators=C2=A0has an "invalid_ta=
rget" error code that is intended for this kind of thing. So that shou=
ld probably be allowed. If not suggested. Probably not required though.=C2=
=A0

Wonderful, that is a better fit- love it. I ad=
ded it as possible alternative to "invalid_request".

>I personally think the SHOULD is too strong=
 here because it puts the onus on the resource server to know about (via so=
me config option or something) and enforce on every transaction a setup/pol=
icy thing that the AS is responsible for which isn't about the integrit=
y of the authorization data in the token. A MAY or even removing the list i=
tem would be preferred.=C2=A0

I borrowed this lang=
uage straight from the OpenID Connect validation steps for idtokens. Given =
that JWT ATs can carry identity info, the requirement seemed appropriate...=
 also, I think it is reasonable to expect the resource server to know about=
 its own registration- just like it must know about the expected aud value =
and what key should be used to decrypt messages, it should know whether enc=
ryption was requested or not. In fact, the fact that such option was select=
ed at registration time is likely the reflection of a policy of the RS itse=
lf, something the RS itself would want to ensure has been respected. WDYT?<=
/div>


>multi value audiences

I see the issue. I definitely don't want to redefine th=
e semantic of aud, but I also would like to be as crisp as possible on the =
audience-scope correlation and prevent scopes from being misinterpreted as =
applying to the wrong resource. The aud validation will likely happen in so=
me middleware in front of the API, but authorization checks might happen in=
 the body of the API itself when the actual access is being attempted, and =
having an OR list in the aud claim might lead to false positives. RSes corr=
ectly written should not suffer from this issue (the authorization logic sh=
ould receive only the value from the aud collection that is an actual match=
) but I have seen enough sloppy implementations to be skeptical about this.=
=C2=A0
As a result, I would be inclined to=C2=A0 take out the sen=
tence "or if it contains additional audiences that are not known alias=
es of the resource indicator of the current resource server", effectiv=
ely restricting to single value aud and eliminating this issue.


>I think it'd be worthwhile to expl=
icitly disallow the use of the "none" algorithm here.
<=
br>
Good point. I am all for doing everything we can to defuse th=
at FUD. I added language that explicitly disallow RS to accept JWTs with &q=
uot;alg":"none"


>=
Little 'o' in TOken -> Token
fixed


> A link directly to SCIM alone from the JSON Web T=
oken Claims registry might be rather confusing.=C2=A0

<=
div>Added a reference as you suggested in all the entries. I am always conf=
used by forward references whenever the syntax requires the use of an RFC n=
umber that isn't available, but the [[]] trick is a good one.
I didn't follow the "subcompact" considerations, I'll bu=
g you offline for clarifications. Thx in advance

<=
br>
>Ping<blank>identity

Fixed!=
 Sorry for not having done in 01, I think you mentioned this already.
=


On Wed, Jul 24, 2019 at 12:59 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ie=
tf.org> wrote:

2.1.=C2=A0 Header
=C2=A0=C2=A0 NOTE: there were discussion=
s about adding a reference to
=C2=A0 =C2=A0authenticated encyption metho=
ds as well, but there's no internet
=C2=A0 =C2=A0draft specifying in=
teroperable public key methods at this time
Well, Ne=
il did write this up a while back https://tools.ietf.org/html/=
draft-madden-jose-ecdh-1pu-01 which is certainly interesting and I wond=
er if it's something that this group (or some other group?) should look=
 at working on. But it is only an individual draft (with all the=
 authority that brings to bear) and thus I do agree that it isn't a=
ppropriate or useful for this document to reference. 

However JWE RFC7516 and more JWA RFC7518 do have authenticated encr=
yption with symmetric keys that, IMHO, can work very nicely in some cases f=
or JWT access tokens by providing both integrity protection and confidentia=
lity. And the size and performance benefits thereof can be sufficiently use=
ful so as to justify the need to do an out-of-band exchange of the symmetri=
c key.=C2=A0 

Also encyption should be encrypt=
ion. 


2.1.=C2=A0 Header
=C2=A0 =C2=A0The typ header param=
eter for a JWT access token MUST be at+jwt.=C2=A0 See
=C2=A0 =C2=A0the s=
ecurity considerations section for details on the importance of
=C2=A0 =
=C2=A0preventing JWT access tokens to be interpreted as id_tokens.=C2=A0
5.=C2=A0 Security Considerations
=C2=A0 =C2=A0The JWT access token data layout des=
cribed here is very similar to
=C2=A0 =C2=A0the one of the id_token as d=
efined by [OpenID.Core].=C2=A0 Without the
=C2=A0 =C2=A0explicit typing =
required in this profile, in line with the
=C2=A0 =C2=A0recommendations =
in [JWT..BestPractices] there would be the risk of
=C2=A0 =C2=A0attacker=
s using JWT access tokens in lieu of id_tokens.
Connect do=
esn't say anything about checking the "typ" header of id toke=
ns so typing ATs with "at+jwt" doesn't actually do anything t=
o prevent  JWT access tokens being used as id tokens. It can prevent misuse=
 in the other direction. But this document probably shouldn't overstate=
 what typing the JWT can accomplish.
=C2=A0
BTW, th=
ere's been some discussion and agreement that the requirement around &#=
39;nonce' in ID Tokens delivered via the front channel (the only time c=
onnect is subject to that kind of token swapping) is sufficient to protect =
against JWT access tokens (and other types of JWTs) to be interpreted as id=
_tokens. So I think the risk is acceptable but just think the text in the d=
raft shouldn't make claims which are untrue. 
=C2=A0

2.2.2.=C2=A0 Authorization Claims:
=C2=A0=C2=A0 If an authorization =
request includes a scope parameter, the
=C2=A0 =C2=A0corresponding issue=
d JWT access token 
=C2=A0 MUST in -01/SHOULD in -02 include a scope clai=
m 
=

as defined in 
I think you want to say here=
 that the scope claim in the token has to correlate to the scope which was =
approved. Not necessarily what what requested. The authorization request mi=
ght ask for scope of a+b+c, for example, while the user only approves b. Or=
 any other variation on things where what was asked for isn't what was =
gotten.. 


3.=C2=A0 Requesting a JWT Access=
 Token
=C2=A0=
=C2=A0 If it receives a request for an access token containing more than on=
e
=C2=A0 =C2=A0resource parameter, an authorization server issuing JWT a=
ccess tokens
=C2=A0 =C2=A0MUST reject the request and fail with invalid_=
request as described in
=C2=A0 =C2=A0section 4.1.2.1 of [RFC6749]. 
https://tools.ietf.org/html/draft-ie=
tf-oauth-resource-indicators has an "invalid_target" error co=
de that is intended for this kind of thing. So that should probably be allo=
wed. If not suggested. Probably not required though. 

4.=C2=A0 Validating JWT Access Tokens
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If encryption=
 was negotiated with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server=
 at registration time and the incoming JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0ac=
cess token is not encrypted, the resource server SHOULD reject
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0it.
I personally think the SHOUL=
D is too strong here because it puts the onus on the  resource server to kn=
ow about (via some config option or something) and enforce on every transac=
tion a setup/policy thing that the AS is responsible for which isn't ab=
out the integrity of the authorization data in the token. A MAY or even rem=
oving the list item would be preferred. 

4.=C2=
=A0 Validating JWT Access Tokens
=C2=A0=C2=A0=C2=A0=C2=A0 The JWT access token MUST be
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0rejected if aud does not list the resource indic=
ator of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0current resource server as a vali=
d audience, or if it contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0additional audi=
ences that are not known aliases of the resource
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0indicator of the current resource server.
5.=
=C2=A0 Security Considerations
=C2=A0 =C2=A0This profile explicitly forbids the use of mul=
ti value aud claim when
=C2=A0 =C2=A0the individual values refer to diff=
erent resources, as that would
=C2=A0 =C2=A0introduce confusion about wh=
at scopes apply to which resource-
=C2=A0 =C2=A0possibly opening up aven=
ues for elevation of delegated privileges
=C2=A0 =C2=A0attacks.=C2=A0 Al=
ternative techniques to prevent scope confusion include
=C2=A0 =C2=A0&qu=
ot;scope stuffing", imposing to every individual scope string to
=
=C2=A0 =C2=A0include a reference to the resource they are meant to be appli=
ed to,
=C2=A0 =C2=A0but its application is problematic (scope opacity vi=
olations, size
=C2=A0 =C2=A0inflation, more error conditions become poss=
ible when the combination
=C2=A0 =C2=A0of requested scopes and resource =
indicators is invalid) and the
=C2=A0 =C2=A0observed frequency of the sc=
enario doesn't warrant complicating the
=C2=A0 =C2=A0more common cas=
es. 
I do think I see the simplification you'=
;re aiming at with this stuff but I'd like to offer the perspective of =
how this is likely more complicated for standards based JWT library impleme=
ntations. The semantics of aud in RFC 7519 basically say that the recipient=
 has to identify with at least one of the aud values. It's effectively =
a big OR. While the text in this draft changes that semantic to say  that t=
he recipient has to identify with at every one of the aud values. Effective=
ly making it a big AND. Normal JWT libraries will need nonstandard one-off =
functionality or adaptations to get this right.=C2=A0 


=C2=A04.=C2=A0 Validating JWT Access Tokens
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 The resource server MUST validate the signature of all incoming=C2=A0 =C2=A0 =C2=A0 =C2=A0JWT access token according to [RFC7515] using =
the algorithm
=C2=A0 =C2=A0 =C2=A0 =C2=A0specified in the JWT alg Header=
 Parameter.=C2=A0 The resource server
=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST us=
e the keys provided by the authorization server. 
I think it'd be worthwhile to explicitly disallow the use of the &quo=
t;none" algorithm here. I think/suspect that it is implied already. Bu=
t at least some of the JWT hate out there seems to stem from or focus on st=
atements like this one and conclude that words like "MUST validate ...=
 according to [the] algorithm specified in the JWT alg Header Parameter&quo=
t; means that to be spec compliant one has to accept "alg":"=
none" as valid. That's more of a logical leap than I think is reas=
onable but I'd like to avoid it anyway if possible. And it's not a =
bad thing to remind folks not to accept "none" here. 
=C2=A0
7.2.=C2=A0 Claims Registration
=C2=A0=C2=A0=C2=A0 claims in the JSON=
 Web TOken (JWT) IANA
Little 'o' in TOken -&=
gt; Token


7.2.1.=C2=A0 Registry Contents 
|=C2=A0=C2=A0 Specification Document(s): section 4.1.2 of [RFC7643]
For the folks that will have to review and act on =
these registrations at some point, it might be nice to give em a little bet=
ter grouping/formatting. I'm thinking along the lines of what is done h=
ere https://tools.ietf.org/html/draft-ietf-=
oauth-token-exchange-18#section-7.4.1, which you can corice xml2rfc int=
o doing with <?rfc subcompact=3D"yes"?> and <?rfc subcompact=3D"no"?> as in the src at https://github.com/oauth-token-excha=
nge/spec/blob/master/draft-ietf-oauth-token-exchange.xml#L1191 

Appendix A.=C2=A0 Acknowledgements
=C2=A0=C2=A0=C2=A0 Brian Campbell=
 (PingIdentity)
My corporate overloads will be happi=
er if you put a space between Ping and Identity.
=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 th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000a009f5058e743ce4--


From nobody Wed Jul 24 15:31:45 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236281202DB for ; Wed, 24 Jul 2019 15:31:44 -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,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne5Cjlo1R1Eu for ; Wed, 24 Jul 2019 15:31:42 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650127.outbound.protection.outlook.com [40.107.65.127]) (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 ED891120110 for ; Wed, 24 Jul 2019 15:31:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=na8mRtQMoCXTzKcfOc8+bRVIQyraoORFfoQrvcugxBa0QNoDLjpvAAPYi3Rgr8YTi06ftDM+rFlhJwj4EgDewN7VX8PS32EdCLIZtpwDln2+2xjnrtIpR7He2N9Q+hS85drVfneiBhvt1wik/3G5jWmHMkj1oMf4rD9et9dnnBKQJtI7fezvtFpEV/zQft188LnC63+vVjVp0xm1daQ1ZTKXPYPw+j0kvIGe3xU3aL9b4KMJEoKzb+EmOySEleLcrE/057jjabmXYymSXQVp4kseXNZPmsRDA+0b2D50adNsCCech0T4taXSsAc2lU0skmyo62TazvwZaYtEw0pKNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=32rIqPJWqWwK6OebJ44MRhPRZIxyLQfqmesCwATV+Yk=; b=SFKn/CQn6XLCL8HtpFkogSMj0a+w0nG8f+UeMXZKkjItEI2h+Szf/GNhIHy6sdVWXtg8JgtI549B/uMTeZHz9p1Ht48bgFA0iDUbupld9YquIQRzwuh665lV6C97D0K/t+tIqAiZ90C4kWatXf9SD23kSlvEPjThCmWr3ylAJjJ7Ze6tLot3Nn9a8TGXcpBwblWzI2shL9LBkX43B0e9b/0eCKl0bYsHMhJPiXQGP4XTDhGBYcWkPIQKBDzeFo2j8AGeapzZKA/5S+M6QRWABWu28GO81BM5pU09bYB5/M2mwkFfI8EbOtIF0vpdxYuk7J78N+VD7Gt0J2T6W7GoJg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=32rIqPJWqWwK6OebJ44MRhPRZIxyLQfqmesCwATV+Yk=; b=HQQ954/HXhRjdKuf7HwJAW9+Ro/FVVHQ5iHzTKHkKDCbyBMUzIMU/4p488ATA6x5+j7HjTHuvgAol8y7LxBaThqfHJVLPt3nIyamk+KQu0AQExTsH6YXWqYD5PuadsrPUiPbHnzIALUWD/wSCtYCbGGNfDE21UldXbAZEyFIhU8=
Received: from BN8PR00MB0563.namprd00.prod.outlook.com (20.179.72.150) by BN8PR00MB0563.namprd00.prod.outlook.com (20.179.72.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2155.0; Wed, 24 Jul 2019 22:31:39 +0000
Received: from BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::f495:15b0:ea9b:c849]) by BN8PR00MB0563.namprd00.prod.outlook.com ([fe80::f495:15b0:ea9b:c849%3]) with mapi id 15.20.2155.000; Wed, 24 Jul 2019 22:31:39 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Token Exchange specification sent to the RFC Editor
Thread-Index: AdVCb0wPW2/jZcYXRLmLqTIhr37xIg==
Date: Wed, 24 Jul 2019 22:31:39 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=37d66ff3-eb93-4bf8-b186-0000c3b6ad56; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-24T22:29:41Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [31.133.158.62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e203a0ad-b17d-4baf-5a61-08d71086b21d
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:BN8PR00MB0563; 
x-ms-traffictypediagnostic: BN8PR00MB0563:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(396003)(39860400002)(346002)(136003)(376002)(209900001)(189003)(199004)(2351001)(478600001)(76116006)(66556008)(71200400001)(10290500003)(66476007)(66946007)(71190400001)(64756008)(66446008)(55016002)(6306002)(54896002)(9686003)(236005)(2906002)(5640700003)(6436002)(25786009)(53936002)(86362001)(8936002)(7696005)(66066001)(99286004)(81166006)(81156014)(1730700003)(8676002)(2501003)(102836004)(22452003)(6116002)(14444005)(256004)(966005)(790700001)(53376002)(3846002)(558084003)(316002)(68736007)(14454004)(74316002)(7736002)(6506007)(26005)(186003)(8990500004)(52536014)(5660300002)(486006)(606006)(476003)(10090500001)(33656002)(6916009)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR00MB0563; H:BN8PR00MB0563.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: S5CSEqsd6Wr8BvzSDiyFFOBla63oOFd2Bu8lAmR16s5G6IFJOwjIGGizwgWZrWfsUoP1pCXZlcrLP9etBLRZSYH2XzzdZl7BASiQFzMCzXT5WNs2hhoXXi39JNoS3Mx0BMV/aRJ0I3Ku8NxZbgyXgatML9VcgWBs70ZabycWhFKacPxEZnRXI6eqAEn1WDbnNivCypA91OHYbbaKv5T5j2mR4n4G9d8hVTSuVz6MCmN8WgbE/OFAvhzcOfatYBcJf8+fpnKthkxnQS+z2jiDUwiIYLam6aFHGBCEOe26ds+7iyhBj79Yp3CPJnBzQrvhjKdK9X36UgtVagjKEGGlysN48+9RcVTev3uWRuV9xsP5y/iGBH40gL+HoSrt/3JR4C4p8nQVaQThMxI08zdBDKDCUP4rjQAX0Byp54PSUUI=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR00MB0563CF9ADDC178C97DF89FF1F5C60BN8PR00MB0563namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e203a0ad-b17d-4baf-5a61-08d71086b21d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 22:31:39.3452 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eIOxDMuJCvhlsT3aUsUGIYZKMQYqimSlIImBcXmulpe4po8c0T1xidZuiHlU1AvtRz2UAfHyoKgAVxb698TkVw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR00MB0563
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.0 Token Exchange specification sent to the RFC Editor
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 22:31:44 -0000

--_000_BN8PR00MB0563CF9ADDC178C97DF89FF1F5C60BN8PR00MB0563namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I just made a blog post about the Token Exchange spec progressing to the RF=
C Editor queue.  Congratulations all!

See http://self-issued.info/?p=3D1992 and https://twitter.com/selfissued fo=
r the post.

                                                       Cheers,
                                                       -- Mike


--_000_BN8PR00MB0563CF9ADDC178C97DF89FF1F5C60BN8PR00MB0563namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I just made a blog post about the Token Exchange spe=
c progressing to the RFC Editor queue.  Congratulations all!


 


See ht=
tp://self-issued.info/?p=3D1992 and
https://twitter.com/selfissued for the post.


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        Cheers,


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


 






--_000_BN8PR00MB0563CF9ADDC178C97DF89FF1F5C60BN8PR00MB0563namp_--


From nobody Wed Jul 24 16:13: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 219981202C7 for ; Wed, 24 Jul 2019 16:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 X5Ey9xPuLVFl for ; Wed, 24 Jul 2019 16:13:27 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A60512006E for ; Wed, 24 Jul 2019 16:13:27 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id h6so6652413iom.7 for ; Wed, 24 Jul 2019 16:13:27 -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=TAKb3K0I4pCubN+qZ97GDgealobZaDmoX8Na0MkNEK4=; b=KXVbtcRiQPk981Nm3dBF+XF6TrBQSKWvgsyQWsRS+BIazzFjq96vfcVWDoMAAjIpi8 21V08pn/GcG4pqNRoQ+ktv0lecbo0XU4c1qlSvrFUltDMSW9Wpq5FNgxMSc1N6Hk1Z3f //2UiHexe3rfggQtnDk5PRl8djq1yzzCwHtQnzgZeQGPwNIQtxWWGGOQn0dwLlfzK9q4 5Gs7mx21m8KatofJHMhCDWdSaNSTqv06daQvRYWeeYfk3J1IFQOabesB6iSpxfSMVu83 0P+mDxfRnFctQlVXDX3WpIL2v6MB1lyA9EkkvpIJ9vkOgDjeJnb53QDk3Zfib9rWq8Hz HLpg==
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=TAKb3K0I4pCubN+qZ97GDgealobZaDmoX8Na0MkNEK4=; b=d4dtCYmAn1XCZOe6haQQyClm9BCr5KN5z5/xfRo2coX4CTkUHXVUhRpEsCeTsfQzX6 wlBtlyC/HC1IOPZL3hFyH+6zGIuuldpnk+hl9jVNdg8eDjOfm1EhwQB753yM801+PgHv SU04sYeCo9ue0X8Da5Pcg0GfEKxkwYQcHeBDRpu58d2Gp9rbYnQd7T+++6qj9LGhzJ9m qOj9hL06/MwAGemGJ5dIH5oStwztqYyCo2tPUMNt8LDXNt3HTrBGrO5/TnN4ZWr0Eiws oJz81WGI24wzeksJaQMhH2Fp0WKpgR36TYEKHag5wZdQ7ykUtHl+660sVqpqpA8Js2v1 cLNw==
X-Gm-Message-State: APjAAAVu/KmmuKVI+J8s+9ivVdeFWmRF1YP3oWGABFm3VUh9hivsfOPr WJGjNVhHRhjRmRYo14Es2QkSrk04igZEUg==
X-Google-Smtp-Source: APXvYqzwHqDl4wGqjE2KBNmkH6nZwwupslMADcj4U9bFg4kESHpz/ZyqIPcPkalBxRfUNozqFn0Mug==
X-Received: by 2002:a6b:6e01:: with SMTP id d1mr6832795ioh.156.1564010006151;  Wed, 24 Jul 2019 16:13:26 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id s10sm112928797iod.46.2019.07.24.16.13.25 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 16:13:25 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id j6so18052919ioa.5 for ; Wed, 24 Jul 2019 16:13:25 -0700 (PDT)
X-Received: by 2002:a6b:f816:: with SMTP id o22mr54120969ioh.166.1564010005064;  Wed, 24 Jul 2019 16:13:25 -0700 (PDT)
MIME-Version: 1.0
References:   <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com>  <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com>   <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com>  <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com>  
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 24 Jul 2019 19:12:20 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Torsten Lodderstedt 
Cc: Neil Madden , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000c6f42f058e7574d3"
Archived-At: 
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 23:13:29 -0000

--000000000000c6f42f058e7574d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ok thanks for the input here everyone. I'm not seeing much of a consensus,
but these are all excellent points and I've collected them for discussion
during the meeting on Friday.

----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Mon, Jul 22, 2019 at 8:12 AM Torsten Lodderstedt 
wrote:

> Hi Neil,
>
> > On 22. Jul 2019, at 13:59, Neil Madden 
> wrote:
> >
> >> In addition, a public client which does not use its refresh token in a=
n
> =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a consid=
erable period of
> time, and the operational model of public clients usually puts detection =
of
> local token theft in the hand of the end user and client software, not an
> administrator or organizational security staff.
> >
> > Given that a refresh token has to be used at the AS, isn't the situatio=
n
> here *better* for refresh tokens? Every time an attacker uses a stolen
> refresh token you get a nice ping against your centralised token endpoint=
,
> giving you a great opportunity to run contextual checks to decide if
> something looks fishy.
>
> I agree with your assessment.
>
> That why the Security BCP (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4=
..12)
> requires authorisation servers to detect refresh token replay. Even if th=
e
> refresh token cannot be sender constraint, one-time refresh tokens (or
> refresh token rotation) is a viable option when used in combination with
> conditional revocation of the active refresh token if something looks fis=
hy.
>
> kind regards,
> Torsten. _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Ok thanks for the input here everyone. I'm not seeing =
much of a consensus, but these are all excellent points and I've collec=
ted them for discussion during the meeting on Friday.
On Mon, Jul 22, 2019 at 8:12 AM Torsten Loddersted=
t <torsten@lodderstedt.net> wrote:
Hi =
Neil,



> On 22. Jul 2019, at 13:59, Neil Madden <neil.madden@forgerock.com> wrote=
:

> 

>> In addition, a public client which does not use its refresh token =
in an =E2=80=9Coffline=E2=80=9D manner may have theft go unnoticed for a co=
nsiderable period of time, and the operational model of public clients usua=
lly puts detection of local token theft in the hand of the end user and cli=
ent software, not an administrator or organizational security staff.

> 

> Given that a refresh token has to be used at the AS, isn't the sit=
uation here *better* for refresh tokens? Every time an attacker uses a stol=
en refresh token you get a nice ping against your centralised token endpoin=
t, giving you a great opportunity to run contextual checks to decide if som=
ething looks fishy. 



I agree with your assessment. 



That why the Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section=
-4..12) requires authorisation servers to detect refresh token replay. =
Even if the refresh token cannot be sender constraint, one-time refresh tok=
ens (or refresh token rotation) is a viable option when used in combination=
 with conditional revocation of the active refresh token if something looks=
 fishy.



kind regards,

Torsten. _______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000c6f42f058e7574d3--


From nobody Wed Jul 24 16:16: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 BAA1412006E; Wed, 24 Jul 2019 16:16:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <156401017666.14534.9422325088242867919@ietfa.amsl.com>
Date: Wed, 24 Jul 2019 16:16:16 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-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: Wed, 24 Jul 2019 23:16:17 -0000

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

        Title           : OAuth 2.0 for Browser-Based Apps
        Authors         : Aaron Parecki
                          David Waite
	Filename        : draft-ietf-oauth-browser-based-apps-03.txt
	Pages           : 18
	Date            : 2019-07-24

Abstract:
   This specification details the security considerations that must be
   taken into account when developing browser-based applications, as
   well as best practices for how they can securely implement OAuth 2.0.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-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 Wed Jul 24 16:19: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 9DEBD12006E for ; Wed, 24 Jul 2019 16:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtkqdz95cUSP for ; Wed, 24 Jul 2019 16:19:39 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA27512027B for ; Wed, 24 Jul 2019 16:19:39 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id h6so6676062iom.7 for ; Wed, 24 Jul 2019 16:19:39 -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; bh=pIpWlkYRMUgGbMq/DNlRxcAmIgrKhJyK/Sl3NdEH8PA=; b=uL9O+hrvpxgG9/xCMZpOV90zi3hEzbskUHo89CA0R/P53A6mofnPqlAu74E2QOeKQt WF4W6fxdzKRsIkaVQuPCmv5lbs7NDipzhswGKtlal7BPY7WQylBB9c/W/e6pBksL1t7R 71a8mewgV1pRvsrlmP/9ydCKiGfmMVpkjT6TJWQPwMoQir9w+xzd128Wigf380t1JiU1 3FdDG+tOqd2vgdlgrv4zMrH2BeZLQtby0iPoytPuwhyeOdxxelsnuiF+bPKBz+VY8Rsp ETewbxdrlv36RY/VdhPX4TtFEz6s9Pag23eckZ62y46T+YzpajjRsI/gdwWJVeBOrHEN 72dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pIpWlkYRMUgGbMq/DNlRxcAmIgrKhJyK/Sl3NdEH8PA=; b=taFxywjoYTgbDC4BAa462s5UrwiEAf0vXD7AzIY/V9IL9keA0z0anhZhSve+j+HmnH 9KMQ2i9E8UERSxT8f2sTYwNqkyxEoBUKzqUAK/4km1ip7/VwjlcGWBg5w62+aAnC+ld9 tZhKB+II6OA/bzR677ALyVITq3V+F9aIGp7+Y6P/x20LO8nKbQQnFfJ90OLBbZG2JpPB +annDsQ2pI7qEAKWE3LUEH3C0nag8rjGxSfVtx7qJTiSSNtl57U40GP6oPu9XP95r03k auiSZmbZioKGNZ56eZDx4ciNA/Wiwn/GvbnW3lJ/qAY8v2XbaXyrlLpBUVZfutGcm60Y uDeQ==
X-Gm-Message-State: APjAAAWxiHlNruH4NP1jBgoXRdrNWWinHyQHCR2QEHbJ8VpFHxHatIlt GQtMtp5xqqitTzu6KEm41YM9cDmYVoTlIA==
X-Google-Smtp-Source: APXvYqzusR/so+N0xOCDw2cHAYoJKEx25PcfHrdzIOvvhRJjm/cJJVsbBI/k0YDdZjeVCydgvcocOw==
X-Received: by 2002:a6b:bc42:: with SMTP id m63mr64034190iof.189.1564010378699;  Wed, 24 Jul 2019 16:19:38 -0700 (PDT)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id m4sm42225231iok.68.2019.07.24.16.19.38 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 16:19:38 -0700 (PDT)
Received: by mail-io1-f54.google.com with SMTP id m24so93283754ioo.2 for ; Wed, 24 Jul 2019 16:19:38 -0700 (PDT)
X-Received: by 2002:a02:a07:: with SMTP id 7mr89191971jaw.65.1564010378155; Wed, 24 Jul 2019 16:19:38 -0700 (PDT)
MIME-Version: 1.0
References: <156401017666.14534.9422325088242867919@ietfa.amsl.com>
In-Reply-To: <156401017666.14534.9422325088242867919@ietfa.amsl.com>
From: Aaron Parecki 
Date: Wed, 24 Jul 2019 19:18:34 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: OAuth WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 23:19:41 -0000

Hi all, thanks for the latest round of feedback. I've incorporated
these suggestions into the latest draft, -03. Here's a summary of the
changes since -02:

* Updated the historic note about the fragment URL clarifying that the
Session History API means browsers can use the unmodified
authorization code flow
* Rephrased "Authorization Code Flow" intro paragraph to better lead
into the next two sections
* Softened "is likely a better decision to avoid using OAuth entirely"
to "it may be..." for common-domain deployments
* Updated abstract to not be limited to public clients, since the
later sections talk about confidential clients
* Removed references to avoiding OpenID Connect for same-domain architectures
* Updated headers to better describe architectures (Apps Served from a
Static Web Server -> JavaScript Applications without a Backend)
* Expanded "same-domain architecture" section to better explain the
problems that OAuth has in this scenario
* Referenced Security BCP in implicit flow attacks where possible
* Minor typo corrections

I have a few open questions on this still based on discussion on the
list that there was not a clear consensus on, so I've prepared those
points to talk about during the session on Friday.

----
Aaron Parecki
aaronparecki.com
@aaronpk

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Wed, Jul 24, 2019 at 7:17 PM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : OAuth 2.0 for Browser-Based Apps
>         Authors         : Aaron Parecki
>                           David Waite
>         Filename        : draft-ietf-oauth-browser-based-apps-03.txt
>         Pages           : 18
>         Date            : 2019-07-24
>
> Abstract:
>    This specification details the security considerations that must be
>    taken into account when developing browser-based applications, as
>    well as best practices for how they can securely implement OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-03
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Jul 24 16:41:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6A1203B8 for ; Wed, 24 Jul 2019 16:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCPxfQtw3MCs for ; Wed, 24 Jul 2019 16:41:20 -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 161681202E2 for ; Wed, 24 Jul 2019 16:41:19 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x6ONgh6B006555 for ; Wed, 24 Jul 2019 19:42:43 -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, 24 Jul 2019 19:40:41 -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, 24 Jul 2019 19:41:18 -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, 24 Jul 2019 19:41:18 -0400
From: Justin Richer 
To: OAuth WG 
Thread-Topic: IETF Meetup for XYZ
Thread-Index: AQHVQnlKDZTt7zXeQUGZS8tDLb2KIA==
Date: Wed, 24 Jul 2019 23:41:18 +0000
Message-ID: <17577284-59F6-42E6-B226-9A6DF3E7DE23@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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_1757728459F642E6B2269A6DF3E7DE23mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] IETF Meetup for XYZ
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2019 23:41:22 -0000

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

SGkgYWxsLA0KDQpJIHdhcyB0YWxraW5nIHdpdGggSGFubmVzLCBhbmQgd2XigJlkIGxpa2UgdG8g
cHJvcG9zZSBhIGRpbm5lciBtZWV0dXAgdG9tb3Jyb3cgKFRodXJzZGF5KSBmb3IgYW55b25lIHdo
byB3YW50cyB0byBkaXNjdXNzIFhZWiBpbiBtb3JlIGRldGFpbCB3aGlsZSB3ZeKAmXJlIGhlcmUg
aW4gTW9udHJlYWwuIFdl4oCZbGwgbWVldCByaWdodCBhZnRlciB0aGUgQUNFIHdvcmtpbmcgZ3Jv
dXAgc2Vzc2lvbiBhbmQgZmluZCBhIHBsYWNlIG5lYXJieSwgc28gdGhhdCBzb21lIG9mIHVzIGNh
biBnZXQgYmFjayBpbiB0aW1lIGZvciB0aGUgbGlnaHRuaW5nIHRhbGtzIGluIHRoZSBldmVuaW5n
Lg0KDQpJZiB5b3XigJlyZSBpbnRlcmVzdGVkLCBlaXRoZXIgY29tZSBmaW5kIHVzIHRvbW9ycm93
IG9yIGxldCB1cyBrbm93IHNvbWUgb3RoZXIgd2F5Lg0K4oCUIEp1c3Rpbg0KDQo=

--_000_1757728459F642E6B2269A6DF3E7DE23mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <84C1F27476BB1E4E96DAFEFFD6A9F678@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd2FzIHRhbGtpbmcgd2l0aCBIYW5uZXMs
IGFuZCB3ZeKAmWQgbGlrZSB0byBwcm9wb3NlIGEgZGlubmVyIG1lZXR1cCB0b21vcnJvdyAoVGh1
cnNkYXkpIGZvciBhbnlvbmUgd2hvIHdhbnRzIHRvIGRpc2N1c3MgWFlaIGluIG1vcmUgZGV0YWls
IHdoaWxlIHdl4oCZcmUgaGVyZSBpbiBNb250cmVhbC4gV2XigJlsbCBtZWV0IHJpZ2h0IGFmdGVy
IHRoZSBBQ0Ugd29ya2luZyBncm91cCBzZXNzaW9uIGFuZCBmaW5kIGEgcGxhY2UgbmVhcmJ5LA0K
IHNvIHRoYXQgc29tZSBvZiB1cyBjYW4gZ2V0IGJhY2sgaW4gdGltZSBmb3IgdGhlIGxpZ2h0bmlu
ZyB0YWxrcyBpbiB0aGUgZXZlbmluZy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHlvdeKAmXJlIGludGVyZXN0ZWQsIGVpdGhlciBj
b21lIGZpbmQgdXMgdG9tb3Jyb3cgb3IgbGV0IHVzIGtub3cgc29tZSBvdGhlciB3YXkuPGJyIGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh
dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwv
ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1757728459F642E6B2269A6DF3E7DE23mitedu_--


From nobody Wed Jul 24 23:28: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 4F7CC1202B0 for ; Wed, 24 Jul 2019 23:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 FYdcHuM1zvGc for ; Wed, 24 Jul 2019 23:28:30 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C560512028C for ; Wed, 24 Jul 2019 23:28:29 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id s145so35633650qke.7 for ; Wed, 24 Jul 2019 23:28:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Do5kH8AI6yOxTvnmCSO2K5sHVYRbynIZIVNKMAffd8g=; b=kY3vVpZJPIZ+xvUHhGEnoVbgpz9qEghVAK+Ild90vYj6mzcEO+fDUc41HtdCXT2VyJ YJF6aIOhbt/LUr6SlAPn9ettcPuESGZlZE6Uyw35GePgWzOdAfs5KavSfdAsDxVpV2v1 XzU6hCuXy4ObBamNxremH/L5Ja1hfcP005ElxiBsIIn1MnuE+E5JuceoM6Ij6bbjjSoT RI0klSFEOPoKdgfw7z/u5xVzrZv7EL/JUR0au7hd2VHhE6UfK19HgJ0KA0QSu8mOg8XY puXKEaDFvZxCRBhwwHNqoSpvhWMWqmOHM/Ix64oD873kKec24flXXxeg/S/tVM4ljeJt ioZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Do5kH8AI6yOxTvnmCSO2K5sHVYRbynIZIVNKMAffd8g=; b=g2b8jb3AdQ1WnwD0VYRQiV75EsdyG+b/Jn5T9Oe1H5+DWKKwzuJzqlsyZRiHM+6+TY 5TVn6ZCardldg5C5lm/ReoyeERmOn1EX3o00cB3bKTASDUJnw1IYASNVNwR3GqmJ90I1 FcmNzs4VFxLPbuLHN+azVrVC2AcYFFCCxU1kXtMXL6sD9UeKvJhV/d1C5lOGFXyDqAuX 7gHP1CuEkTUGjtCbMFV486FDyAPa21KzAy7mWSgxcVOHSr2pP1krGk9OZOepSng5oFsR R0E4N1pE1UnrCpvWSFZnxccL32TMoOnidchHbgMv3h4mMrV+5uOzBSPyHfwvKXehFebU oyqg==
X-Gm-Message-State: APjAAAWjQBQznoyi5iDYMkqoPdcTOrvfHT/xoaj7PM/vjsEzUeiMoF0n qjI6ABISovy5CcU4aY43pbKx+vjMTWgn8zxFVg==
X-Google-Smtp-Source: APXvYqxio/2RJpETvPj9hosWWC1gmhWplCytD5ISPiwibsmUU+AMP7dc2ythQt0nMXe1VXewV+GrQ7OsaiEbVrUSfvs=
X-Received: by 2002:a37:a292:: with SMTP id l140mr56510033qke.496.1564036108588;  Wed, 24 Jul 2019 23:28:28 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jul 2019 23:28:27 -0700
From: Dominick Baier 
In-Reply-To: 
References:  
MIME-Version: 1.0
Date: Wed, 24 Jul 2019 23:28:27 -0700
Message-ID: 
To: Aaron Parecki 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000ab4274058e7b887d"
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 06:28:33 -0000

--000000000000ab4274058e7b887d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

To clarify.

Using CSP is a general best practice for every JS app.

Once tokens are stored in the browser you want to specifically focus on
injection attacks (XSS) - disabling inline scripting is key to that.

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

On 24. July 2019 at 23:04:20, Aaron Parecki (aaron@parecki.com) wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:

> I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.

I agree, I removed the mention of OIDC.

> I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if refresh or
access tokens are involved - further settings like disabling inline
scripting (unsafe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
 wrote:
>
> Hey,
>
> Just read the spec - good to see the progress. Some feedback:
>
> I am yet undecided if I like the categorisation of the =E2=80=9CApplicati=
on
Architecture Patterns=E2=80=9D. I definitely want to distinguish between
applications only accessing same-site back-end services and =E2=80=9Cothers=
=E2=80=9D. Not
sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic applicatio=
n server=E2=80=9D should
be handled differently - they are deployment details and should not decide
on the application security architecture. Also not sure how realistic it is
to deploy a typical applications solely from e.g. a CDN. But I don=E2=80=99=
t have
the right answer wrt to categories right now.
>
> 6.1. Apps Served from a Common Domain as the Resource Server
>
> > OAuth and OpenID Connect provide very little benefit in this
> deployment scenario, so it is recommended to reconsider whether you
> need OAuth or OpenID Connect at all in this case.
>
> I think you are mixing authentication and API access here. Depending on
application scenario it makes a lot of sense to use OIDC - but rely on the
resulting session to control API access.
> Unless you want to dive into the details here, I suggest you remove the
mention of OIDC because it is misleading.
>
>
> 6.2. Apps Served from a Dynamic Application Server
>
> I have a .NET sample for that
>
>
https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore=
21/BFF
> And a blog post
>
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit=
h-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
>
> 9.7. Content-Security Policy
>
> A browser-based application that wishes to use either long-lived
> refresh tokens or privileged scopes SHOULD restrict its JavaScript
> execution to a set of statically hosted scripts via a Content
> Security Policy ([CSP2]) or similar mechanism.
>
>
>
> I would rather say that ANY JS app should use CSP to lock down the
browser features to a minimal attack surface. In addition, if refresh or
access tokens are involved - further settings like disabling inline
scripting (unsafe inline) and eval should be disabled.
>
> Thanks for doing this work!
>
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

=

To c=
larify.

=

Using CSP i=
s a general best practice for every JS app.

Once tokens are stored in the browser you want to =
specifically focus on injection attacks (XSS) - disabling inline scripting =
is key to that.
 
 
=E2=80=94=E2=80=
=94=E2=80=94
Dominick
 
On 24. Ju=
ly 2019 at 23:04:20, Aaron Parecki (aa=
ron@parecki.com) wrote:
 
On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier

<dbaier@leastprivilege.=
com> wrote:



> I think you are mixing authentication and API access here. Dependi=
ng on application scenario it makes a lot of sense to use OIDC - but rely o=
n the resulting session to control API access.

> Unless you want to dive into the details here, I suggest you remov=
e the mention of OIDC because it is misleading.



I agree, I removed the mention of OIDC.



> I would rather say that ANY JS app should use CSP to lock down the=
 browser features to a minimal attack surface. In addition, if refresh or a=
ccess tokens are involved - further settings like disabling inline scriptin=
g (unsafe inline) and eval should be disabled.



I'm not sure what to do with this suggestion. It feels like a blank=
et

recommendation of enabling CSP will likely be ignored since it's to=
o

broad, and recommending disabling inline scripts is overreaching

unless backed up by a specific threat it's protecting against. Did =
you

have a particular threat in mind?



----

Aaron Parecki

aaronparecki.com

@aaronpk







On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier

<dbaier@leastprivilege.=
com> wrote:

>

> Hey,

>

> Just read the spec - good to see the progress. Some feedback:

>

> I am yet undecided if I like the categorisation of the =E2=80=9CAp=
plication Architecture Patterns=E2=80=9D. I definitely want to distinguish =
between applications only accessing same-site back-end services and =E2=80=
=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic application server" a=
nd =E2=80=9Cstatic application server=E2=80=9D should be handled differentl=
y - they are deployment details and should not decide on the application se=
curity architecture. Also not sure how realistic it is to deploy a typical =
applications solely from e.g. a CDN. But I don=E2=80=99t have the right ans=
wer wrt to categories right now.

>

> 6.1.  Apps Served from a Common Domain as the Resource Server

>

> > OAuth and OpenID Connect provide very little benefit in this

>    deployment scenario, so it is recommended to reconsider whether=
 you

>    need OAuth or OpenID Connect at all in this case.

>

> I think you are mixing authentication and API access here. Dependi=
ng on application scenario it makes a lot of sense to use OIDC - but rely o=
n the resulting session to control API access.

> Unless you want to dive into the details here, I suggest you remov=
e the mention of OIDC because it is misleading.

>

>

> 6.2.  Apps Served from a Dynamic Application Server

>

> I have a .NET sample for that

>

> https://github.com/leastprivilege/AspNetCoreSec=
uritySamples/tree/aspnetcore21/BFF

> And a blog post

> =
https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit=
h-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

>

> 9.7.  Content-Security Policy

>

>    A browser-based application that wishes to use either long-live=
d

>    refresh tokens or privileged scopes SHOULD restrict its JavaScr=
ipt

>    execution to a set of statically hosted scripts via a Content

>    Security Policy ([CSP2]) or similar mechanism.

>

>

>

> I would rather say that ANY JS app should use CSP to lock down the=
 browser features to a minimal attack surface. In addition, if refresh or a=
ccess tokens are involved - further settings like disabling inline scriptin=
g (unsafe inline) and eval should be disabled.

>

> Thanks for doing this work!

>

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

> Dominick

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://ww=
w.ietf.org/mailman/listinfo/oauth



--000000000000ab4274058e7b887d--


From nobody Thu Jul 25 01:05: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 D0885120332 for ; Thu, 25 Jul 2019 01:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou0YZ72vATV3 for ; Thu, 25 Jul 2019 01:04:57 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id D704F1202DF for ; Thu, 25 Jul 2019 01:04:57 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:ec9d:ea62:7def:e5ff] (unknown [IPv6:2601:282:202:b210:ec9d:ea62:7def:e5ff]) by alkaline-solutions.com (Postfix) with ESMTPSA id AECE231625; Thu, 25 Jul 2019 08:04:56 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3566.0.1\))
From: David Waite 
In-Reply-To: 
Date: Thu, 25 Jul 2019 02:04:56 -0600
Cc: Dominick Baier , OAuth WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Aaron Parecki 
X-Mailer: Apple Mail (2.3566.0.1)
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 08:05:00 -0000

> On Jul 24, 2019, at 3:03 PM, Aaron Parecki  wrote:
>=20
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
>  wrote:
>=20


>> I would rather say that ANY JS app should use CSP to lock down the =
browser features to a minimal attack surface. In addition, if refresh or =
access tokens are involved - further settings like disabling inline =
scripting (unsafe inline) and eval should be disabled.
>=20
> I'm not sure what to do with this suggestion. It feels like a blanket
> recommendation of enabling CSP will likely be ignored since it's too
> broad, and recommending disabling inline scripts is overreaching
> unless backed up by a specific threat it's protecting against. Did you
> have a particular threat in mind?

I would say that browser applications should take measures to harden =
their applications again code injection and arbitrary code execution. =
Examples include eliminating inline script (and limiting embeddable =
objects as much as possible) via CSP, and versioning third party =
resources via techniques like subresource integrity.  Mechanisms such as =
augmenting the codebase to make sure all appropriate user input, data =
storage, and output properly sanitize data may be used - although they =
may be more expensive to implement and audit.

The AS should likewise take into account an application=E2=80=99s =
overall security posture when deciding appropriate policies around =
delegated authorization scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. =
But it is (theoretically) possible to accomplish the same with =
brute-force sanitization, which has been made simpler with framework =
support. It is still ultimately the AS job to decide which clients have =
which capabilities.

-DW=


From nobody Thu Jul 25 04:45: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 27784120020 for ; Thu, 25 Jul 2019 04:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 R231PIflZIs3 for ; Thu, 25 Jul 2019 04:45:02 -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 918D4120019 for ; Thu, 25 Jul 2019 04:45:02 -0700 (PDT)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x6PBj6Pp025569; Thu, 25 Jul 2019 07:45:11 -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; Thu, 25 Jul 2019 07:44:15 -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; Thu, 25 Jul 2019 07:44:55 -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; Thu, 25 Jul 2019 07:44:55 -0400
From: Justin Richer 
To: David Waite 
CC: Aaron Parecki , OAuth WG 
Thread-Topic: [OAUTH-WG] Feedback on OAuth for browser-based Apps
Thread-Index: AQHVQFTCWkkZA5TKMEWuwVFaVw4YoabaiM8AgAC44ACAAD13gA==
Date: Thu, 25 Jul 2019 11:44:55 +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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_DC16FB0632A84CF9999FFB9F58E67B99mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 11:45:05 -0000

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

VGhpcyByYWlzZXMgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gdGhhdCBJIGRvbuKAmXQgdGhpbmsg
d2XigJl2ZSBhZGRyZXNzZWQgeWV0OiBob3cgdG8gYXBwcm9wcmlhdGVseSB2YXJ5IHRva2VuIGxp
ZmV0aW1lcyBhbmQgYWNjZXNzIGZvciBkaWZmZXJlbnQgY2xpZW50cy4NCg0KUHJldmlvdXNseSwg
YW4gQVMgY291bGQgc2VlIHRoYXQgYSBjbGllbnQgd2FzIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93
IGFuZCBkZWNpZGUgdG8gbGltaXQgdG9rZW4gbGlmZXRpbWVzIG9yIHNjb3BlcyBiYXNlZCBvbiB0
aGF0IGFsb25lLiBTaW1pbGFybHksIEkga25vdyBvZiBhdCBsZWFzdCBzb21lIEFTIGltcGxlbWVu
dGF0aW9ucyB0aGF0IGxldCB5b3UgbGltaXQgd2hhdCBzY29wZXMgeW91IGFsbG93IHVuZGVyIHRo
ZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQuIFRoZSBrZXkgaXNzdWUgaXMgdGhhdCBpZiBhbGwg
eW91ciBjbGllbnRzIGFyZSB1c2luZyB0aGUgYXV0aCBjb2RlIGZsb3cgKHdoaWNoIEkgYWdyZWUg
dGhleSBzaG91bGQpLCB0aGVuIGhvdyBkb2VzIGFuIEFTIHRlbGwgdGhlIGRpZmZlcmVuY2UgaW4g
Y2FwYWJpbGl0aWVzIGJldHdlZW4gaW5jb21pbmcgY2xpZW50cz8NCg0KT2J2aW91c2x5IGl0IGNh
biBkbyBpdCBvbiBhIHBlci1jbGllbnQgYmFzaXMgc3RpbGwsIGJ1dCBub3cgYW4gQVMgaXMgZ29p
bmcgdG8gaGF2ZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQgdGhlIGFwcCBpdHNlbGYuIFBlcmhh
cHMgd2UgZmluYWxseSBuZWVkIGEgZmV3IG1vcmUgZW50cmllcyBpbiB0aGUg4oCcYXBwbGljYXRp
b25fdHlwZeKAnSBtZXRhZGF0YSBwYXJhbWV0ZXIgZnJvbSBPSURD4oCZcyBleHRlbnNpb24gUkZD
NzU5MSBiZXlvbmQg4oCcbmF0aXZl4oCdIGFuZCDigJx3ZWLigJ0/IEJ1dCB3ZSBhdCBsZWFzdCBw
cm9iYWJseSB3YW50IHRvIHBvaW50IG91dCB0byBBUyBpbXBsZW1lbnRvcnMgdGhhdCB0aGlzIGlz
IHNvbWV0aGluZyB0aGV5IHdhbnQgdG8gY29uc2lkZXIgdHJhY2tpbmcgaW4gdGhlaXIgZGF0YSBt
b2RlbCBmb3IgY2xpZW50cy4NCg0K4oCUIEp1c3Rpbg0KDQpPbiBKdWwgMjUsIDIwMTksIGF0IDQ6
MDQgQU0sIERhdmlkIFdhaXRlIDxkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPG1haWx0bzpk
YXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPj4gd3JvdGU6DQoNCg0KDQoNCk9uIEp1bCAyNCwg
MjAxOSwgYXQgMzowMyBQTSwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb208bWFpbHRv
OmFhcm9uQHBhcmVja2kuY29tPj4gd3JvdGU6DQoNCk9uIE1vbiwgSnVsIDIyLCAyMDE5IGF0IDI6
MTQgQU0gRG9taW5pY2sgQmFpZXINCjxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpk
YmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQoNCjxzbmlwPg0KDQpJIHdvdWxkIHJh
dGhlciBzYXkgdGhhdCBBTlkgSlMgYXBwIHNob3VsZCB1c2UgQ1NQIHRvIGxvY2sgZG93biB0aGUg
YnJvd3NlciBmZWF0dXJlcyB0byBhIG1pbmltYWwgYXR0YWNrIHN1cmZhY2UuIEluIGFkZGl0aW9u
LCBpZiByZWZyZXNoIG9yIGFjY2VzcyB0b2tlbnMgYXJlIGludm9sdmVkIC0gZnVydGhlciBzZXR0
aW5ncyBsaWtlIGRpc2FibGluZyBpbmxpbmUgc2NyaXB0aW5nICh1bnNhZmUgaW5saW5lKSBhbmQg
ZXZhbCBzaG91bGQgYmUgZGlzYWJsZWQuDQoNCkknbSBub3Qgc3VyZSB3aGF0IHRvIGRvIHdpdGgg
dGhpcyBzdWdnZXN0aW9uLiBJdCBmZWVscyBsaWtlIGEgYmxhbmtldA0KcmVjb21tZW5kYXRpb24g
b2YgZW5hYmxpbmcgQ1NQIHdpbGwgbGlrZWx5IGJlIGlnbm9yZWQgc2luY2UgaXQncyB0b28NCmJy
b2FkLCBhbmQgcmVjb21tZW5kaW5nIGRpc2FibGluZyBpbmxpbmUgc2NyaXB0cyBpcyBvdmVycmVh
Y2hpbmcNCnVubGVzcyBiYWNrZWQgdXAgYnkgYSBzcGVjaWZpYyB0aHJlYXQgaXQncyBwcm90ZWN0
aW5nIGFnYWluc3QuIERpZCB5b3UNCmhhdmUgYSBwYXJ0aWN1bGFyIHRocmVhdCBpbiBtaW5kPw0K
DQpJIHdvdWxkIHNheSB0aGF0IGJyb3dzZXIgYXBwbGljYXRpb25zIHNob3VsZCB0YWtlIG1lYXN1
cmVzIHRvIGhhcmRlbiB0aGVpciBhcHBsaWNhdGlvbnMgYWdhaW4gY29kZSBpbmplY3Rpb24gYW5k
IGFyYml0cmFyeSBjb2RlIGV4ZWN1dGlvbi4gRXhhbXBsZXMgaW5jbHVkZSBlbGltaW5hdGluZyBp
bmxpbmUgc2NyaXB0IChhbmQgbGltaXRpbmcgZW1iZWRkYWJsZSBvYmplY3RzIGFzIG11Y2ggYXMg
cG9zc2libGUpIHZpYSBDU1AsIGFuZCB2ZXJzaW9uaW5nIHRoaXJkIHBhcnR5IHJlc291cmNlcyB2
aWEgdGVjaG5pcXVlcyBsaWtlIHN1YnJlc291cmNlIGludGVncml0eS4gIE1lY2hhbmlzbXMgc3Vj
aCBhcyBhdWdtZW50aW5nIHRoZSBjb2RlYmFzZSB0byBtYWtlIHN1cmUgYWxsIGFwcHJvcHJpYXRl
IHVzZXIgaW5wdXQsIGRhdGEgc3RvcmFnZSwgYW5kIG91dHB1dCBwcm9wZXJseSBzYW5pdGl6ZSBk
YXRhIG1heSBiZSB1c2VkIC0gYWx0aG91Z2ggdGhleSBtYXkgYmUgbW9yZSBleHBlbnNpdmUgdG8g
aW1wbGVtZW50IGFuZCBhdWRpdC4NCg0KVGhlIEFTIHNob3VsZCBsaWtld2lzZSB0YWtlIGludG8g
YWNjb3VudCBhbiBhcHBsaWNhdGlvbuKAmXMgb3ZlcmFsbCBzZWN1cml0eSBwb3N0dXJlIHdoZW4g
ZGVjaWRpbmcgYXBwcm9wcmlhdGUgcG9saWNpZXMgYXJvdW5kIGRlbGVnYXRlZCBhdXRob3JpemF0
aW9uIHNjb3BlcyBhbmQgdG9rZW4gbGlmZXRpbWVzLg0KDQpCZXN0IGN1cnJlbnQgcHJhY3RpY2Vz
IGluY2x1ZGUgdHVybmluZyB0aGUgc2NyZXdzIHRpZ2h0bHkgYXJvdW5kIENTUC4gQnV0IGl0IGlz
ICh0aGVvcmV0aWNhbGx5KSBwb3NzaWJsZSB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIHdpdGggYnJ1
dGUtZm9yY2Ugc2FuaXRpemF0aW9uLCB3aGljaCBoYXMgYmVlbiBtYWRlIHNpbXBsZXIgd2l0aCBm
cmFtZXdvcmsgc3VwcG9ydC4gSXQgaXMgc3RpbGwgdWx0aW1hdGVseSB0aGUgQVMgam9iIHRvIGRl
Y2lkZSB3aGljaCBjbGllbnRzIGhhdmUgd2hpY2ggY2FwYWJpbGl0aWVzLg0KDQotRFcNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoaXMgcmFpc2VzIGFuIGludGVyZXN0aW5nIHF1
ZXN0aW9uIHRoYXQgSSBkb27igJl0IHRoaW5rIHdl4oCZdmUgYWRkcmVzc2VkIHlldDogaG93IHRv
IGFwcHJvcHJpYXRlbHkgdmFyeSB0b2tlbiBsaWZldGltZXMgYW5kIGFjY2VzcyBmb3IgZGlmZmVy
ZW50IGNsaWVudHMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj5QcmV2aW91c2x5LCBhbiBBUyBjb3VsZCBzZWUgdGhhdCBhIGNsaWVudCB3YXMgdXNp
bmcgdGhlIGltcGxpY2l0IGZsb3cgYW5kIGRlY2lkZSB0byBsaW1pdCB0b2tlbiBsaWZldGltZXMg
b3Igc2NvcGVzIGJhc2VkIG9uIHRoYXQgYWxvbmUuIFNpbWlsYXJseSwgSSBrbm93IG9mIGF0IGxl
YXN0IHNvbWUgQVMgaW1wbGVtZW50YXRpb25zIHRoYXQgbGV0IHlvdSBsaW1pdCB3aGF0IHNjb3Bl
cyB5b3UgYWxsb3cgdW5kZXIgdGhlIGNsaWVudA0KIGNyZWRlbnRpYWxzIGdyYW50LiBUaGUga2V5
IGlzc3VlIGlzIHRoYXQgaWYgYWxsIHlvdXIgY2xpZW50cyBhcmUgdXNpbmcgdGhlIGF1dGggY29k
ZSBmbG93ICh3aGljaCBJIGFncmVlIHRoZXkgc2hvdWxkKSwgdGhlbiBob3cgZG9lcyBhbiBBUyB0
ZWxsIHRoZSBkaWZmZXJlbmNlIGluIGNhcGFiaWxpdGllcyBiZXR3ZWVuIGluY29taW5nIGNsaWVu
dHM/Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj5PYnZpb3VzbHkgaXQgY2FuIGRvIGl0IG9uIGEgcGVyLWNsaWVudCBiYXNpcyBz
dGlsbCwgYnV0IG5vdyBhbiBBUyBpcyBnb2luZyB0byBoYXZlIHRvIGtub3cgYSBiaXQgbW9yZSBh
Ym91dCB0aGUgYXBwIGl0c2VsZi4gUGVyaGFwcyB3ZSBmaW5hbGx5IG5lZWQgYSBmZXcgbW9yZSBl
bnRyaWVzIGluIHRoZSDigJxhcHBsaWNhdGlvbl90eXBl4oCdIG1ldGFkYXRhIHBhcmFtZXRlciBm
cm9tIE9JREPigJlzIGV4dGVuc2lvbiBSRkM3NTkxIGJleW9uZA0KIOKAnG5hdGl2ZeKAnSBhbmQg
4oCcd2Vi4oCdPyBCdXQgd2UgYXQgbGVhc3QgcHJvYmFibHkgd2FudCB0byBwb2ludCBvdXQgdG8g
QVMgaW1wbGVtZW50b3JzIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgdGhleSB3YW50IHRvIGNvbnNp
ZGVyIHRyYWNraW5nIGluIHRoZWlyIGRhdGEgbW9kZWwgZm9yIGNsaWVudHMuPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K
PGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq
dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg
MjUsIDIwMTksIGF0IDQ6MDQgQU0sIERhdmlkIFdhaXRlICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2
aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSIgY2xhc3M9IiI+ZGF2aWRAYWxrYWxpbmUtc29sdXRp
b25zLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n
ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs
YXNzPSIiPk9uIEp1bCAyNCwgMjAxOSwgYXQgMzowMyBQTSwgQWFyb24gUGFyZWNraSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29tIiBjbGFzcz0iIj5hYXJvbkBwYXJlY2tpLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIE1vbiwgSnVs
IDIyLCAyMDE5IGF0IDI6MTQgQU0gRG9taW5pY2sgQmFpZXI8YnIgY2xhc3M9IiI+DQombHQ7PGEg
aHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIGNsYXNzPSIiPmRiYWllckBs
ZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQo8L2Jsb2NrcXVvdGU+DQombHQ7c25pcCZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPkkgd291bGQgcmF0aGVyIHNheSB0aGF0IEFOWSBKUyBhcHAgc2hvdWxk
IHVzZSBDU1AgdG8gbG9jayBkb3duIHRoZSBicm93c2VyIGZlYXR1cmVzIHRvIGEgbWluaW1hbCBh
dHRhY2sgc3VyZmFjZS4gSW4gYWRkaXRpb24sIGlmIHJlZnJlc2ggb3IgYWNjZXNzIHRva2VucyBh
cmUgaW52b2x2ZWQgLSBmdXJ0aGVyIHNldHRpbmdzIGxpa2UgZGlzYWJsaW5nIGlubGluZSBzY3Jp
cHRpbmcgKHVuc2FmZQ0KIGlubGluZSkgYW5kIGV2YWwgc2hvdWxkIGJlIGRpc2FibGVkLjxiciBj
bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkknbSBub3Qgc3VyZSB3aGF0
IHRvIGRvIHdpdGggdGhpcyBzdWdnZXN0aW9uLiBJdCBmZWVscyBsaWtlIGEgYmxhbmtldDxiciBj
bGFzcz0iIj4NCnJlY29tbWVuZGF0aW9uIG9mIGVuYWJsaW5nIENTUCB3aWxsIGxpa2VseSBiZSBp
Z25vcmVkIHNpbmNlIGl0J3MgdG9vPGJyIGNsYXNzPSIiPg0KYnJvYWQsIGFuZCByZWNvbW1lbmRp
bmcgZGlzYWJsaW5nIGlubGluZSBzY3JpcHRzIGlzIG92ZXJyZWFjaGluZzxiciBjbGFzcz0iIj4N
CnVubGVzcyBiYWNrZWQgdXAgYnkgYSBzcGVjaWZpYyB0aHJlYXQgaXQncyBwcm90ZWN0aW5nIGFn
YWluc3QuIERpZCB5b3U8YnIgY2xhc3M9IiI+DQpoYXZlIGEgcGFydGljdWxhciB0aHJlYXQgaW4g
bWluZD88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIHdvdWxk
IHNheSB0aGF0IGJyb3dzZXIgYXBwbGljYXRpb25zIHNob3VsZCB0YWtlIG1lYXN1cmVzIHRvIGhh
cmRlbiB0aGVpciBhcHBsaWNhdGlvbnMgYWdhaW4gY29kZSBpbmplY3Rpb24gYW5kIGFyYml0cmFy
eSBjb2RlIGV4ZWN1dGlvbi4gRXhhbXBsZXMgaW5jbHVkZSBlbGltaW5hdGluZyBpbmxpbmUgc2Ny
aXB0IChhbmQgbGltaXRpbmcgZW1iZWRkYWJsZSBvYmplY3RzIGFzIG11Y2ggYXMgcG9zc2libGUp
IHZpYSBDU1AsIGFuZCB2ZXJzaW9uaW5nDQogdGhpcmQgcGFydHkgcmVzb3VyY2VzIHZpYSB0ZWNo
bmlxdWVzIGxpa2Ugc3VicmVzb3VyY2UgaW50ZWdyaXR5LiAmbmJzcDtNZWNoYW5pc21zIHN1Y2gg
YXMgYXVnbWVudGluZyB0aGUgY29kZWJhc2UgdG8gbWFrZSBzdXJlIGFsbCBhcHByb3ByaWF0ZSB1
c2VyIGlucHV0LCBkYXRhIHN0b3JhZ2UsIGFuZCBvdXRwdXQgcHJvcGVybHkgc2FuaXRpemUgZGF0
YSBtYXkgYmUgdXNlZCAtIGFsdGhvdWdoIHRoZXkgbWF5IGJlIG1vcmUgZXhwZW5zaXZlIHRvIGlt
cGxlbWVudA0KIGFuZCBhdWRpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgQVMg
c2hvdWxkIGxpa2V3aXNlIHRha2UgaW50byBhY2NvdW50IGFuIGFwcGxpY2F0aW9u4oCZcyBvdmVy
YWxsIHNlY3VyaXR5IHBvc3R1cmUgd2hlbiBkZWNpZGluZyBhcHByb3ByaWF0ZSBwb2xpY2llcyBh
cm91bmQgZGVsZWdhdGVkIGF1dGhvcml6YXRpb24gc2NvcGVzIGFuZCB0b2tlbiBsaWZldGltZXMu
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVzdCBjdXJyZW50IHByYWN0aWNlcyBpbmNs
dWRlIHR1cm5pbmcgdGhlIHNjcmV3cyB0aWdodGx5IGFyb3VuZCBDU1AuIEJ1dCBpdCBpcyAodGhl
b3JldGljYWxseSkgcG9zc2libGUgdG8gYWNjb21wbGlzaCB0aGUgc2FtZSB3aXRoIGJydXRlLWZv
cmNlIHNhbml0aXphdGlvbiwgd2hpY2ggaGFzIGJlZW4gbWFkZSBzaW1wbGVyIHdpdGggZnJhbWV3
b3JrIHN1cHBvcnQuIEl0IGlzIHN0aWxsIHVsdGltYXRlbHkgdGhlIEFTIGpvYiB0byBkZWNpZGUg
d2hpY2gNCiBjbGllbnRzIGhhdmUgd2hpY2ggY2FwYWJpbGl0aWVzLjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCi1EVzxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_DC16FB0632A84CF9999FFB9F58E67B99mitedu_--


From nobody Thu Jul 25 05:11:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB33120163 for ; Thu, 25 Jul 2019 05:11:21 -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 dJNznhbXUcql for ; Thu, 25 Jul 2019 05:11:19 -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 DEFB11201EF for ; Thu, 25 Jul 2019 05:11:18 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id s7so5272388oth.7 for ; Thu, 25 Jul 2019 05:11:18 -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=JcJN8+4hy8GsDenDz9f+Fi+3uhmbpEKzsXmThyWUufo=; b=J2o9A4c6E3SjYc8HEIlQQ6IDy1rQrKyl750YaxJIM9g6QHgF3C//qiTKzgQIvjrw7j E7+uAtR/yNAVO/546Waj8KpGJQsPiH5PjPghnGwkBxMrXwdxhivGTTPEUGxNXIrTQef/ NS6NlwM6sAf7rU+FJHhLrn5JzVek+AwVbm+1IcaZ9i9pWIuoH4YY5eBcDSsIrmxDtUOs VAq2+WQu5bmOME7gKYQ+uTytdm+mpo7IujX77hw043FIyEdrzzTiC5AE+1fDgLtE6r2E ChHMyJkH5Vo7z2ODxLWV2zJZPARKfC5kUYCXA/D2YnfG3zY21lKjxEF34u3QN9wP9fSP 5Dsw==
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=JcJN8+4hy8GsDenDz9f+Fi+3uhmbpEKzsXmThyWUufo=; b=GtAxq+rSBaBKtoP7Ui//ATn7qpkf+BsO8eAUp0YHBiYNIa/D6k/PeHPdPlRmWC+iZv GGIpJQeEUwNy/iXJx7FY6fu2McibZrL1BzLD54cwop39A2cGj/iFBKYk1tv1YaDcQiRD 2qkBCsVytsbUAJJok5erO/8mp520ELbi3N07Xo5K4X+husRvx2rriI8VTuIisrJiLjrB GmSTzY8T49y7vCFzGNCRnSzzGN1DUimPL1l6ReFVJmpuoHmB+AW9s25Bf+kUCFw2Tgd8 IYkPTXDow72W6pVYYsaTvfzR1exkwy1SbP6gA6tN9AnijE+QphfDoJDjKaw41+mMlkS7 4iOA==
X-Gm-Message-State: APjAAAVKbSLB2af7kCkd826HEBqd1d6uE/jvsSBQp1U6szXmLO6CLO5d TrWMm5WdWMcJHMbORQsIpGeXjiADjpV+jMk3fA==
X-Google-Smtp-Source: APXvYqwG2BRRiB89mcRBX0dMiNlcEHxs9m55Ps6BYPvLagUagQrlVpgeThMT2ZrT37m+lgILzdNfb2psBWC8W1lpTzc=
X-Received: by 2002:a9d:65da:: with SMTP id z26mr54290184oth.257.1564056678192;  Thu, 25 Jul 2019 05:11:18 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Filip Skokan 
Date: Thu, 25 Jul 2019 14:11:06 +0200
Message-ID: 
To: Justin Richer 
Cc: David Waite , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000b65aca058e805202"
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 12:11:22 -0000

--000000000000b65aca058e805202
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Obviously it can do it on a per-client basis still, but now an AS is goin=
g
> to have to know a bit more about the app itself. Perhaps we finally need =
a
> few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata param=
eter from OIDC=E2=80=99s
> extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=
=9D? But we at least probably want
> to point out to AS implementors that this is something they want to
> consider tracking in their data model for clients.
>

I would very much like to see that. native/web possibly in combination with
token_endpoint_auth_method and the client being DCR or "static" is far from
being enough to make a policy decision.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 13:45, Justin Richer  wrote:

> This raises an interesting question that I don=E2=80=99t think we=E2=80=
=99ve addressed
> yet: how to appropriately vary token lifetimes and access for different
> clients.
>
> Previously, an AS could see that a client was using the implicit flow and
> decide to limit token lifetimes or scopes based on that alone. Similarly,=
 I
> know of at least some AS implementations that let you limit what scopes y=
ou
> allow under the client credentials grant. The key issue is that if all yo=
ur
> clients are using the auth code flow (which I agree they should), then ho=
w
> does an AS tell the difference in capabilities between incoming clients?
>
> Obviously it can do it on a per-client basis still, but now an AS is goin=
g
> to have to know a bit more about the app itself. Perhaps we finally need =
a
> few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata param=
eter from OIDC=E2=80=99s
> extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=
=9D? But we at least probably want
> to point out to AS implementors that this is something they want to
> consider tracking in their data model for clients.
>
> =E2=80=94 Justin
>
> On Jul 25, 2019, at 4:04 AM, David Waite 
> wrote:
>
>
>
>
> On Jul 24, 2019, at 3:03 PM, Aaron Parecki  wrote:
>
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
>  wrote:
>
> 
>
> I would rather say that ANY JS app should use CSP to lock down the browse=
r
> features to a minimal attack surface. In addition, if refresh or access
> tokens are involved - further settings like disabling inline scripting
> (unsafe inline) and eval should be disabled.
>
>
> I'm not sure what to do with this suggestion. It feels like a blanket
> recommendation of enabling CSP will likely be ignored since it's too
> broad, and recommending disabling inline scripts is overreaching
> unless backed up by a specific threat it's protecting against. Did you
> have a particular threat in mind?
>
>
> I would say that browser applications should take measures to harden thei=
r
> applications again code injection and arbitrary code execution. Examples
> include eliminating inline script (and limiting embeddable objects as muc=
h
> as possible) via CSP, and versioning third party resources via techniques
> like subresource integrity.  Mechanisms such as augmenting the codebase t=
o
> make sure all appropriate user input, data storage, and output properly
> sanitize data may be used - although they may be more expensive to
> implement and audit.
>
> The AS should likewise take into account an application=E2=80=99s overall=
 security
> posture when deciding appropriate policies around delegated authorization
> scopes and token lifetimes.
>
> Best current practices include turning the screws tightly around CSP. But
> it is (theoretically) possible to accomplish the same with brute-force
> sanitization, which has been made simpler with framework support. It is
> still ultimately the AS job to decide which clients have which capabiliti=
es.
>
> -DW
> _______________________________________________
> 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
>

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


Obviously it can do it on a per-client basis still,=
 but now an AS is going to have to know a bit more about the app itself. Pe=
rhaps we finally need a few more entries in the =E2=80=9Capplication_type=
=E2=80=9D metadata parameter from OIDC=E2=80=99s extension RFC7591 beyond =
=E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we at least probabl=
y want to point out to AS implementors that this is something they want to =
consider tracking in their data model for clients.
<=
br>
I would very much like to see that. native/web possibly in co=
mbination with token_endpoint_auth_method and the client being DCR or "=
;static" is far from being enough to make a policy decision.

S pozdravem,
Filip Skokan


On=
 Thu, 25 Jul 2019 at 13:45, Justin Richer <jricher@mit.edu> wrote:






This raises an interesting question that I don=E2=80=99t think we=E2=80=99v=
e addressed yet: how to appropriately vary token lifetimes and access for d=
ifferent clients.






Previously, an AS could see that a client was using the implicit flow =
and decide to limit token lifetimes or scopes based on that alone. Similarl=
y, I know of at least some AS implementations that let you limit what scope=
s you allow under the client
 credentials grant. The key issue is that if all your clients are using the=
 auth code flow (which I agree they should), then how does an AS tell the d=
ifference in capabilities between incoming clients?=C2=A0







Obviously it can do it on a per-client basis still, but now an AS is g=
oing to have to know a bit more about the app itself. Perhaps we finally ne=
ed a few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata pa=
rameter from OIDC=E2=80=99s extension RFC7591 beyond
 =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we at least probab=
ly want to point out to AS implementors that this is something they want to=
 consider tracking in their data model for clients.










=E2=80=94 Justin









On Jul 25, 2019, at 4:04 AM, David Waite <david@alkaline-solutions.com&g=
t; wrote:













On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aaron@parecki.com&=
gt; wrote:



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier

<dbaier@l=
eastprivilege.com> wrote:





<snip>






I would rather say that ANY JS app should use CSP=
 to lock down the browser features to a minimal attack surface. In addition=
, if refresh or access tokens are involved - further settings like disablin=
g inline scripting (unsafe
 inline) and eval should be disabled.





I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching

unless backed up by a specific threat it's protecting against. Did you<=
br>
have a particular threat in mind?





I would say that browser applications should take measures to harden their =
applications again code injection and arbitrary code execution. Examples in=
clude eliminating inline script (and limiting embeddable objects as much as=
 possible) via CSP, and versioning
 third party resources via techniques like subresource integrity.=C2=A0 Mec=
hanisms such as augmenting the codebase to make sure all appropriate user i=
nput, data storage, and output properly sanitize data may be used - althoug=
h they may be more expensive to implement
 and audit.



The AS should likewise take into account an application=E2=80=99s overall s=
ecurity posture when deciding appropriate policies around delegated authori=
zation scopes and token lifetimes.



Best current practices include turning the screws tightly around CSP. But i=
t is (theoretically) possible to accomplish the same with brute-force sanit=
ization, which has been made simpler with framework support. It is still ul=
timately the AS job to decide which
 clients have which capabilities.



-DW

_______________________________________________

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




--000000000000b65aca058e805202--


From nobody Thu Jul 25 09:05: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 26A131202C6 for ; Thu, 25 Jul 2019 09:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrZ34iBPLCIo for ; Thu, 25 Jul 2019 09:05:50 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1E21202B7 for ; Thu, 25 Jul 2019 09:05:49 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id g20so98341180ioc.12 for ; Thu, 25 Jul 2019 09:05: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:content-transfer-encoding; bh=B3kWYAk6HyzRpM71zYKhcclnZ7qpn8OTZAczYlTUW3Q=; b=XImO35Y6Zu/7ke5dA7xOmg2ucO3i9lVLTnGmy/JV4LyksBSG/JZ2xsm0gYV5welRH6 VmM/bZLnw17nHGs26QSTlVwHi0ZKAsT01uhSOE7yYmDpxfhlWhGfI058tXCwmijrc4R3 Vr7ryXYpg7XpyoDjpmgALg5/zF6AIuf0xPff1xSG3apZcmgoq8ZHRULpXA/g3JXVXj6w NSfwiLTruKX4kS/Wr27bZ3G2v7lAcZyTKE6wbiH+zYSddzQbjCQsaiqP298rsu3YNnR9 vcdmSvwFCJQOlXvsL4RFzkwJ6DXXWibMdEzei2Cdq3jwOPvrRJtnoilNpo4PwJX4QDC9 6Hgw==
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=B3kWYAk6HyzRpM71zYKhcclnZ7qpn8OTZAczYlTUW3Q=; b=C/dpcPAqGli7/wVutO65LraQTp9JRs7cztmqHQteGsjwkWdywLQt6fOkcbt20HCfY2 GHoNSLIYketb7TVXFbHzdB1pVgyWUNOVR9dX5/4doIGOrgHCOthxza0m442A67bMoRLS hgwZphlyQLmsFHsX98Xc1YbK3fFfzPTZJccAjr5twSIDUwe/BMI7WdiOae9tpWWQ37dk CXGaDAHjDQ0ZmAD3PZ1pKz03DsNVDC+Ztnldo45OCzcmgPQStyp4L7fLQZex7DxMa+lt FvdVeZmxALvw8gmGp4B3SeSemCOh7sAHvBF0E4kW0X+5FyuDXlGyg2lsmFZAuD1UEhg0 rGGA==
X-Gm-Message-State: APjAAAUru2omTME9hj6joMoCu08ECHxy/S9qlLbdapld7eBJ73TccEpR XpclJJrbQxMd8RxSittZb7VfNW3FpaTgog==
X-Google-Smtp-Source: APXvYqzoco/X2RP6MGBAe6yKycTXnGClYoz1GSn70C9Zel/DBFcEg6PQScWeCdlliocznL9lOCAInw==
X-Received: by 2002:a6b:7b07:: with SMTP id l7mr13335151iop.225.1564070748774;  Thu, 25 Jul 2019 09:05:48 -0700 (PDT)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id 20sm53179218iog.62.2019.07.25.09.05.47 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 09:05:47 -0700 (PDT)
Received: by mail-io1-f45.google.com with SMTP id e20so67976037iob.9 for ; Thu, 25 Jul 2019 09:05:47 -0700 (PDT)
X-Received: by 2002:a6b:f816:: with SMTP id o22mr57975334ioh.166.1564070747648;  Thu, 25 Jul 2019 09:05:47 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Aaron Parecki 
Date: Thu, 25 Jul 2019 12:04:31 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: oauth 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 16:05:54 -0000

Some notes and minor corrections:

> Abstract

"OAuth2" should be "OAuth 2.0"

> 1. Introduction

"many important scenario" should be "scenarios"
"OAuth2" should be "OAuth 2.0"

> 2.1. Header
> ... use of asymmetric algorithms is RECOMMENDED

Has anyone implemented or does anyone have plans to implement
symmetric algorithms here? Fewer options is generally better and will
lead to better library support and interoperability, so I'd love to
see this require asymmetric algorithms if possible.

> 2.2.1. Identity Claims
> Commercial authorization servers will...

"Commercial" seems like an odd distinction here, since that doesn't
really describe anything about the architecture, and there could be
cases of non-commercial authorization servers with this same feature.
How about "External or standalone authorization servers..."?

> 3. Requesting a JWT Access Token
> GET /as/authorization.oauth2?response_type=3Dtoken

should be response_type=3Dcode because the description below then says
"Once redeemed, the code obtained from the request above..."

> 4. Validating JWT Access Tokens

There are several instances of "Openid connect" which should be
"OpenID Connect".

"OAuth2 bearer token usage" should be "OAuth 2.0 Bearer Token Usage"
and cite RFC6750.

> If the JWT access token is encrypted...

This is the first mention of the possibility of an encrypted JWT. I
was under the impression this spec is limited to unencrypted JWTs, not
also encompassing rfc7516 JWE. If the intent is to also allow JWEs,
this should be specified much higher up in the document as well.

"...JWT access token according..." should be "access tokens"

"represented by the exp Claim" no need to capitalize "claim"

> 6. Privacy Considerations
> the authorization server should take explicit steps to prevent it as desc=
ribed above.

What steps exactly are described above? The only thing I see is using
opaque tokens. Is that the intent? If so, probably better to just say
"should use opaque tokens" instead. Or this could refer to the steps
described later in this section, in which case should say "below".

> Possible measure include
should be "measures"

This may also read better as a bullet list, but not sure if you want
to take up that much space.

----
Aaron Parecki
aaronparecki.com
@aaronpk


On Wed, Jul 24, 2019 at 5:46 PM Vittorio Bertocci
 wrote:
>
> Thank you Brian for the thorough and insightful review!
>
> Comments:
>
> > On authenticated encryption.
> I did chat with Neil about his draft, but as you mention I didn't referen=
ce it given that it hasn't bee picked up (yet?).
> On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My ratio=
nale is that this profile attempts to capture current practices or practice=
s that are close enough to the capabilities of existing systems to have a r=
easonable chance of being adopted. None of the products/services surveyed u=
sed authenticated encryption, and the requirement to acquire a symmetric ke=
y out of band throws  a big wrench in the otherwise clear-cut process of pr=
eparing your RS to handle JWT ATs. I will bring the matter up as open issue=
 on Friday, and if the consensus will be to include symmetric authenticated=
 encryption I'll do that; but my personal preference would be to preserve t=
he simplicity of a concrete, nothing-of-substance-left-as-exercise-to-the-r=
eader solution that can be achieved when the key material can be advertised=
 via metadata.
> Typo fixed.
>
>
> >Connect doesn't say anything about checking the "typ" header of id token=
s [..] this document probably shouldn't overstate what typing the JWT can a=
ccomplish.  [..]  'nonce' in ID Tokens delivered via the front channel [..]=
 to be interpreted as id_tokens.
>
> This is a very fair point, the current language is misleading. I rephrase=
d to position the header typing as a hint.
> About the nonce mitigation you mention. Do you think this means that I sh=
ould explicitly forbid the presence of a "nonce" claim in JWT ATs?
>
>
> >I think you want to say here that the scope claim in the token has to co=
rrelate to the scope which was approved. Not necessarily what what requeste=
d. The authorization request might ask for scope of a+b+c, for example, whi=
le the user only approves b. Or any other variation on things where what wa=
s asked for isn't what was gotten..
>
> Here I am trying not to get into the details of what's inside the scope c=
laim, more requesting that if "scope" was in the request, the issued token =
should express a delegation and a symptom of that should be the presence of=
 the scope claim. Paradoxically that scope claim might be empty if the user=
 only consented to scopes that have effect on the presence of other claims =
in the token (say a functional equivalent of profile). Yes, it does sound o=
dd, but that's a side effect of the prohibition of sending id_tokens to API=
 that creates the requirement to create functional equivalents.
>
>
> > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an=
 "invalid_target" error code that is intended for this kind of thing. So th=
at should probably be allowed. If not suggested. Probably not required thou=
gh.
>
> Wonderful, that is a better fit- love it. I added it as possible alternat=
ive to "invalid_request".
>
>
> >I personally think the SHOULD is too strong here because it puts the onu=
s on the resource server to know about (via some config option or something=
) and enforce on every transaction a setup/policy thing that the AS is resp=
onsible for which isn't about the integrity of the authorization data in th=
e token. A MAY or even removing the list item would be preferred.
>
> I borrowed this language straight from the OpenID Connect validation step=
s for idtokens. Given that JWT ATs can carry identity info, the requirement=
 seemed appropriate... also, I think it is reasonable to expect the resourc=
e server to know about its own registration- just like it must know about t=
he expected aud value and what key should be used to decrypt messages, it s=
hould know whether encryption was requested or not. In fact, the fact that =
such option was selected at registration time is likely the reflection of a=
 policy of the RS itself, something the RS itself would want to ensure has =
been respected. WDYT?
>
>
> >multi value audiences
>
> I see the issue. I definitely don't want to redefine the semantic of aud,=
 but I also would like to be as crisp as possible on the audience-scope cor=
relation and prevent scopes from being misinterpreted as applying to the wr=
ong resource. The aud validation will likely happen in some middleware in f=
ront of the API, but authorization checks might happen in the body of the A=
PI itself when the actual access is being attempted, and having an OR list =
in the aud claim might lead to false positives. RSes correctly written shou=
ld not suffer from this issue (the authorization logic should receive only =
the value from the aud collection that is an actual match) but I have seen =
enough sloppy implementations to be skeptical about this.
> As a result, I would be inclined to  take out the sentence "or if it cont=
ains additional audiences that are not known aliases of the resource indica=
tor of the current resource server", effectively restricting to single valu=
e aud and eliminating this issue.
>
>
> >I think it'd be worthwhile to explicitly disallow the use of the "none" =
algorithm here.
>
> Good point. I am all for doing everything we can to defuse that FUD. I ad=
ded language that explicitly disallow RS to accept JWTs with "alg":"none"
>
>
> >Little 'o' in TOken -> Token
> fixed
>
>
> > A link directly to SCIM alone from the JSON Web Token Claims registry m=
ight be rather confusing.
>
> Added a reference as you suggested in all the entries. I am always confus=
ed by forward references whenever the syntax requires the use of an RFC num=
ber that isn't available, but the [[]] trick is a good one.
> I didn't follow the "subcompact" considerations, I'll bug you offline for=
 clarifications. Thx in advance
>
>
> >Pingidentity
>
> Fixed! Sorry for not having done in 01, I think you mentioned this alread=
y.
>
> On Wed, Jul 24, 2019 at 12:59 PM Brian Campbell  wrote:
>>
>>
>> 2.1.  Header
>>>
>>>    NOTE: there were discussions about adding a reference to
>>>    authenticated encyption methods as well, but there's no internet
>>>    draft specifying interoperable public key methods at this time
>>
>> Well, Neil did write this up a while back https://tools.ietf.org/html/dr=
aft-madden-jose-ecdh-1pu-01 which is certainly interesting and I wonder if =
it's something that this group (or some other group?) should look at workin=
g on. But it is only an individual draft (with all the authority that bring=
s to bear) and thus I do agree that it isn't appropriate or useful for this=
 document to reference.
>>
>> However JWE RFC7516 and more JWA RFC7518 do have authenticated encryptio=
n with symmetric keys that, IMHO, can work very nicely in some cases for JW=
T access tokens by providing both integrity protection and confidentiality.=
 And the size and performance benefits thereof can be sufficiently useful s=
o as to justify the need to do an out-of-band exchange of the symmetric key=
.
>>
>> Also encyption should be encryption.
>>
>>
>> 2.1.  Header
>>>
>>>    The typ header parameter for a JWT access token MUST be at+jwt.  See
>>>    the security considerations section for details on the importance of
>>>    preventing JWT access tokens to be interpreted as id_tokens.
>>
>> 5.  Security Considerations
>>>
>>>    The JWT access token data layout described here is very similar to
>>>    the one of the id_token as defined by [OpenID.Core].  Without the
>>>    explicit typing required in this profile, in line with the
>>>    recommendations in [JWT..BestPractices] there would be the risk of
>>>    attackers using JWT access tokens in lieu of id_tokens.
>>
>> Connect doesn't say anything about checking the "typ" header of id token=
s so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT a=
ccess tokens being used as id tokens. It can prevent misuse in the other di=
rection. But this document probably shouldn't overstate what typing the JWT=
 can accomplish.
>>
>> BTW, there's been some discussion and agreement that the requirement aro=
und 'nonce' in ID Tokens delivered via the front channel (the only time con=
nect is subject to that kind of token swapping) is sufficient to protect ag=
ainst JWT access tokens (and other types of JWTs) to be interpreted as id_t=
okens. So I think the risk is acceptable but just think the text in the dra=
ft shouldn't make claims which are untrue.
>>
>>
>> 2.2.2.  Authorization Claims:
>>>
>>>    If an authorization request includes a scope parameter, the
>>>    corresponding issued JWT access token
>>>
>>>   MUST in -01/SHOULD in -02 include a scope claim
>>>
>>> as defined in
>>
>> I think you want to say here that the scope claim in the token has to co=
rrelate to the scope which was approved. Not necessarily what what requeste=
d. The authorization request might ask for scope of a+b+c, for example, whi=
le the user only approves b. Or any other variation on things where what wa=
s asked for isn't what was gotten..
>>
>>
>> 3.  Requesting a JWT Access Token
>>>
>>>    If it receives a request for an access token containing more than on=
e
>>>    resource parameter, an authorization server issuing JWT access token=
s
>>>    MUST reject the request and fail with invalid_request as described i=
n
>>>    section 4.1.2.1 of [RFC6749].
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an =
"invalid_target" error code that is intended for this kind of thing. So tha=
t should probably be allowed. If not suggested. Probably not required thoug=
h.
>>
>> 4.  Validating JWT Access Tokens
>>>
>>>       If encryption was negotiated with the
>>>        authorization server at registration time and the incoming JWT
>>>        access token is not encrypted, the resource server SHOULD reject
>>>        it.
>>
>> I personally think the SHOULD is too strong here because it puts the onu=
s on the resource server to know about (via some config option or something=
) and enforce on every transaction a setup/policy thing that the AS is resp=
onsible for which isn't about the integrity of the authorization data in th=
e token. A MAY or even removing the list item would be preferred.
>>
>> 4.  Validating JWT Access Tokens
>>>
>>>      The JWT access token MUST be
>>>        rejected if aud does not list the resource indicator of the
>>>        current resource server as a valid audience, or if it contains
>>>        additional audiences that are not known aliases of the resource
>>>        indicator of the current resource server.
>>
>> 5.  Security Considerations
>>>
>>>    This profile explicitly forbids the use of multi value aud claim whe=
n
>>>    the individual values refer to different resources, as that would
>>>    introduce confusion about what scopes apply to which resource-
>>>    possibly opening up avenues for elevation of delegated privileges
>>>    attacks.  Alternative techniques to prevent scope confusion include
>>>    "scope stuffing", imposing to every individual scope string to
>>>    include a reference to the resource they are meant to be applied to,
>>>    but its application is problematic (scope opacity violations, size
>>>    inflation, more error conditions become possible when the combinatio=
n
>>>    of requested scopes and resource indicators is invalid) and the
>>>    observed frequency of the scenario doesn't warrant complicating the
>>>    more common cases.
>>
>> I do think I see the simplification you're aiming at with this stuff but=
 I'd like to offer the perspective of how this is likely more complicated f=
or standards based JWT library implementations. The semantics of aud in RFC=
 7519 basically say that the recipient has to identify with at least one of=
 the aud values. It's effectively a big OR. While the text in this draft ch=
anges that semantic to say that the recipient has to identify with at every=
 one of the aud values. Effectively making it a big AND. Normal JWT librari=
es will need nonstandard one-off functionality or adaptations to get this r=
ight.
>>
>>
>>  4.  Validating JWT Access Tokens
>>>
>>>       The resource server MUST validate the signature of all incoming
>>>        JWT access token according to [RFC7515] using the algorithm
>>>        specified in the JWT alg Header Parameter.  The resource server
>>>        MUST use the keys provided by the authorization server.
>>
>> I think it'd be worthwhile to explicitly disallow the use of the "none" =
algorithm here. I think/suspect that it is implied already. But at least so=
me of the JWT hate out there seems to stem from or focus on statements like=
 this one and conclude that words like "MUST validate ... according to [the=
] algorithm specified in the JWT alg Header Parameter" means that to be spe=
c compliant one has to accept "alg":"none" as valid. That's more of a logic=
al leap than I think is reasonable but I'd like to avoid it anyway if possi=
ble. And it's not a bad thing to remind folks not to accept "none" here.
>>
>> 7.2.  Claims Registration
>>>
>>>     claims in the JSON Web TOken (JWT) IANA
>>
>> Little 'o' in TOken -> Token
>>
>>
>> 7.2.1.  Registry Contents
>> |   Specification Document(s): section 4.1.2 of [RFC7643]
>> Ultimately this is what will show up in the "References" column in the r=
egistry https://www.iana.org/assignments/jwt/jwt.xhtml and thus I'd suggest=
 that it also include something like "Section 2.2.2.1 of [[this specificati=
on]]" there too so someone who starts from the registry has the link to and=
 context of this document. A link directly to SCIM alone from the JSON Web =
Token Claims registry might be rather confusing.
>> For the folks that will have to review and act on these registrations at=
 some point, it might be nice to give em a little better grouping/formattin=
g. I'm thinking along the lines of what is done here https://tools.ietf.org=
/html/draft-ietf-oauth-token-exchange-18#section-7.4.1, which you can coric=
e xml2rfc into doing with  and  as in the src at https://github.com/oauth-token-exchange/spec/blo=
b/master/draft-ietf-oauth-token-exchange.xml#L1191
>>
>> Appendix A.  Acknowledgements
>>>
>>>     Brian Campbell (PingIdentity)
>>
>> My corporate overloads will be happier if you put a space between Ping a=
nd Identity.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg=
ed material for the sole use of the intended recipient(s). Any review, use,=
 distribution or disclosure by others is strictly prohibited...  If you hav=
e received this communication in error, please notify the sender immediatel=
y by e-mail and delete the message and any file attachments from your compu=
ter. Thank you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 25 09:50: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 18678120125 for ; Thu, 25 Jul 2019 09:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 BNMVtBtV-9Po for ; Thu, 25 Jul 2019 09:50:47 -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 3997C1200CD for ; Thu, 25 Jul 2019 09:50:46 -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 x6PGoiDX031172; Thu, 25 Jul 2019 12:50:44 -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; Thu, 25 Jul 2019 12:49:29 -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; Thu, 25 Jul 2019 12:50:10 -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; Thu, 25 Jul 2019 12:50:10 -0400
From: Justin Richer 
To: Filip Skokan 
CC: David Waite , OAuth WG 
Thread-Topic: [OAUTH-WG] Feedback on OAuth for browser-based Apps
Thread-Index: AQHVQFTCWkkZA5TKMEWuwVFaVw4YoabaiM8AgAC44ACAAD13gIAAB1AAgABN+QA=
Date: Thu, 25 Jul 2019 16:50:10 +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: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_F3AC370DFB694FD88466D52CDADD17F6mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 16:50:50 -0000

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

SSBhbHNvIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCwgYnV0IGEgcHJvYmxlbSBpcyB0aGF0IHRo
aW5ncyBsaWtlIOKAnGFwcGxpY2F0aW9uIHR5cGXigJ0gYXJlIHVzdWFsbHkgYSBzdGFuZCBpbiBm
b3IgYSB3aG9sZSBidW5jaCBvZiBkaWZmZXJlbnQgYXR0cmlidXRlcyB0aGF0IHdlIGFjdHVhbGx5
IGNhcmUgYWJvdXQuIFRoYXTigJlzIHdoYXQgaGFwcGVuZWQgd2l0aCB3ZWIvbmF0aXZlIGFuZCB3
aHksIHRvIG15IGtub3dsZWRnZSwgbm9ib2R5IHJlYWxseSB1c2VzIHRob3NlIGluIGxpZXUgb2Yg
dGhpbmdzIGxpa2UgcHVibGljL2NvbmZpZGVudGlhbCBhbmQgcmVkaXJlY3QgVVJJIGxvY2F0aW9u
cyBpbnN0ZWFkIGZvciBwb2xpY3kgZGVjaXNpb25zLiBJZiB3ZSBkbyBlbnVtZXJhdGUgdGhlc2Us
IHdlIHdvdWxkIGFsc28gbmVlZCB0byBlbnVtZXJhdGUgYWxsIG9mIHRoZSB0aGluZ3MgaXQgbWVh
bnMuDQoNCkkgdHJpZWQgdG8gc2h5IGF3YXkgZnJvbSDigJxhcHBsaWNhdGlvbiB0eXBl4oCdIHN0
eWxlIHN3aXRjaGVzIGluIFhZWuKAmXMgc3RyYXcgbWFuLCBhbmQgaW5zdGVhZCBvcHQgZm9yIHJl
Y2lwZXMgb2YgYXBwbHlpbmcgdGhlIGRpZmZlcmVudCBvcHRpb25zIHRvIGRpZmZlcmVudCBraW5k
cyBvZiBjbGllbnRzLiBJIGRvbuKAmXQga25vdyBob3cgbG9uZyB0aGF0IHdpbGwgaG9sZCB1cCB0
aG91Z2guDQoNCuKAlCBKdXN0aW4NCg0KT24gSnVsIDI1LCAyMDE5LCBhdCA4OjExIEFNLCBGaWxp
cCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNvbTxtYWlsdG86cGFudmEuaXBAZ21haWwuY29tPj4g
d3JvdGU6DQoNCk9idmlvdXNseSBpdCBjYW4gZG8gaXQgb24gYSBwZXItY2xpZW50IGJhc2lzIHN0
aWxsLCBidXQgbm93IGFuIEFTIGlzIGdvaW5nIHRvIGhhdmUgdG8ga25vdyBhIGJpdCBtb3JlIGFi
b3V0IHRoZSBhcHAgaXRzZWxmLiBQZXJoYXBzIHdlIGZpbmFsbHkgbmVlZCBhIGZldyBtb3JlIGVu
dHJpZXMgaW4gdGhlIOKAnGFwcGxpY2F0aW9uX3R5cGXigJ0gbWV0YWRhdGEgcGFyYW1ldGVyIGZy
b20gT0lEQ+KAmXMgZXh0ZW5zaW9uIFJGQzc1OTEgYmV5b25kIOKAnG5hdGl2ZeKAnSBhbmQg4oCc
d2Vi4oCdPyBCdXQgd2UgYXQgbGVhc3QgcHJvYmFibHkgd2FudCB0byBwb2ludCBvdXQgdG8gQVMg
aW1wbGVtZW50b3JzIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgdGhleSB3YW50IHRvIGNvbnNpZGVy
IHRyYWNraW5nIGluIHRoZWlyIGRhdGEgbW9kZWwgZm9yIGNsaWVudHMuDQoNCkkgd291bGQgdmVy
eSBtdWNoIGxpa2UgdG8gc2VlIHRoYXQuIG5hdGl2ZS93ZWIgcG9zc2libHkgaW4gY29tYmluYXRp
b24gd2l0aCB0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZCBhbmQgdGhlIGNsaWVudCBiZWluZyBE
Q1Igb3IgInN0YXRpYyIgaXMgZmFyIGZyb20gYmVpbmcgZW5vdWdoIHRvIG1ha2UgYSBwb2xpY3kg
ZGVjaXNpb24uDQoNClMgcG96ZHJhdmVtLA0KRmlsaXAgU2tva2FuDQoNCg0KT24gVGh1LCAyNSBK
dWwgMjAxOSBhdCAxMzo0NSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpq
cmljaGVyQG1pdC5lZHU+PiB3cm90ZToNClRoaXMgcmFpc2VzIGFuIGludGVyZXN0aW5nIHF1ZXN0
aW9uIHRoYXQgSSBkb27igJl0IHRoaW5rIHdl4oCZdmUgYWRkcmVzc2VkIHlldDogaG93IHRvIGFw
cHJvcHJpYXRlbHkgdmFyeSB0b2tlbiBsaWZldGltZXMgYW5kIGFjY2VzcyBmb3IgZGlmZmVyZW50
IGNsaWVudHMuDQoNClByZXZpb3VzbHksIGFuIEFTIGNvdWxkIHNlZSB0aGF0IGEgY2xpZW50IHdh
cyB1c2luZyB0aGUgaW1wbGljaXQgZmxvdyBhbmQgZGVjaWRlIHRvIGxpbWl0IHRva2VuIGxpZmV0
aW1lcyBvciBzY29wZXMgYmFzZWQgb24gdGhhdCBhbG9uZS4gU2ltaWxhcmx5LCBJIGtub3cgb2Yg
YXQgbGVhc3Qgc29tZSBBUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBsZXQgeW91IGxpbWl0IHdoYXQg
c2NvcGVzIHlvdSBhbGxvdyB1bmRlciB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50LiBUaGUg
a2V5IGlzc3VlIGlzIHRoYXQgaWYgYWxsIHlvdXIgY2xpZW50cyBhcmUgdXNpbmcgdGhlIGF1dGgg
Y29kZSBmbG93ICh3aGljaCBJIGFncmVlIHRoZXkgc2hvdWxkKSwgdGhlbiBob3cgZG9lcyBhbiBB
UyB0ZWxsIHRoZSBkaWZmZXJlbmNlIGluIGNhcGFiaWxpdGllcyBiZXR3ZWVuIGluY29taW5nIGNs
aWVudHM/DQoNCk9idmlvdXNseSBpdCBjYW4gZG8gaXQgb24gYSBwZXItY2xpZW50IGJhc2lzIHN0
aWxsLCBidXQgbm93IGFuIEFTIGlzIGdvaW5nIHRvIGhhdmUgdG8ga25vdyBhIGJpdCBtb3JlIGFi
b3V0IHRoZSBhcHAgaXRzZWxmLiBQZXJoYXBzIHdlIGZpbmFsbHkgbmVlZCBhIGZldyBtb3JlIGVu
dHJpZXMgaW4gdGhlIOKAnGFwcGxpY2F0aW9uX3R5cGXigJ0gbWV0YWRhdGEgcGFyYW1ldGVyIGZy
b20gT0lEQ+KAmXMgZXh0ZW5zaW9uIFJGQzc1OTEgYmV5b25kIOKAnG5hdGl2ZeKAnSBhbmQg4oCc
d2Vi4oCdPyBCdXQgd2UgYXQgbGVhc3QgcHJvYmFibHkgd2FudCB0byBwb2ludCBvdXQgdG8gQVMg
aW1wbGVtZW50b3JzIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgdGhleSB3YW50IHRvIGNvbnNpZGVy
IHRyYWNraW5nIGluIHRoZWlyIGRhdGEgbW9kZWwgZm9yIGNsaWVudHMuDQoNCuKAlCBKdXN0aW4N
Cg0KT24gSnVsIDI1LCAyMDE5LCBhdCA0OjA0IEFNLCBEYXZpZCBXYWl0ZSA8ZGF2aWRAYWxrYWxp
bmUtc29sdXRpb25zLmNvbTxtYWlsdG86ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbT4+IHdy
b3RlOg0KDQoNCg0KDQpPbiBKdWwgMjQsIDIwMTksIGF0IDM6MDMgUE0sIEFhcm9uIFBhcmVja2kg
PGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KDQpP
biBNb24sIEp1bCAyMiwgMjAxOSBhdCAyOjE0IEFNIERvbWluaWNrIEJhaWVyDQo8ZGJhaWVyQGxl
YXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3Rl
Og0KDQo8c25pcD4NCg0KSSB3b3VsZCByYXRoZXIgc2F5IHRoYXQgQU5ZIEpTIGFwcCBzaG91bGQg
dXNlIENTUCB0byBsb2NrIGRvd24gdGhlIGJyb3dzZXIgZmVhdHVyZXMgdG8gYSBtaW5pbWFsIGF0
dGFjayBzdXJmYWNlLiBJbiBhZGRpdGlvbiwgaWYgcmVmcmVzaCBvciBhY2Nlc3MgdG9rZW5zIGFy
ZSBpbnZvbHZlZCAtIGZ1cnRoZXIgc2V0dGluZ3MgbGlrZSBkaXNhYmxpbmcgaW5saW5lIHNjcmlw
dGluZyAodW5zYWZlIGlubGluZSkgYW5kIGV2YWwgc2hvdWxkIGJlIGRpc2FibGVkLg0KDQpJJ20g
bm90IHN1cmUgd2hhdCB0byBkbyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi4gSXQgZmVlbHMgbGlrZSBh
IGJsYW5rZXQNCnJlY29tbWVuZGF0aW9uIG9mIGVuYWJsaW5nIENTUCB3aWxsIGxpa2VseSBiZSBp
Z25vcmVkIHNpbmNlIGl0J3MgdG9vDQpicm9hZCwgYW5kIHJlY29tbWVuZGluZyBkaXNhYmxpbmcg
aW5saW5lIHNjcmlwdHMgaXMgb3ZlcnJlYWNoaW5nDQp1bmxlc3MgYmFja2VkIHVwIGJ5IGEgc3Bl
Y2lmaWMgdGhyZWF0IGl0J3MgcHJvdGVjdGluZyBhZ2FpbnN0LiBEaWQgeW91DQpoYXZlIGEgcGFy
dGljdWxhciB0aHJlYXQgaW4gbWluZD8NCg0KSSB3b3VsZCBzYXkgdGhhdCBicm93c2VyIGFwcGxp
Y2F0aW9ucyBzaG91bGQgdGFrZSBtZWFzdXJlcyB0byBoYXJkZW4gdGhlaXIgYXBwbGljYXRpb25z
IGFnYWluIGNvZGUgaW5qZWN0aW9uIGFuZCBhcmJpdHJhcnkgY29kZSBleGVjdXRpb24uIEV4YW1w
bGVzIGluY2x1ZGUgZWxpbWluYXRpbmcgaW5saW5lIHNjcmlwdCAoYW5kIGxpbWl0aW5nIGVtYmVk
ZGFibGUgb2JqZWN0cyBhcyBtdWNoIGFzIHBvc3NpYmxlKSB2aWEgQ1NQLCBhbmQgdmVyc2lvbmlu
ZyB0aGlyZCBwYXJ0eSByZXNvdXJjZXMgdmlhIHRlY2huaXF1ZXMgbGlrZSBzdWJyZXNvdXJjZSBp
bnRlZ3JpdHkuICBNZWNoYW5pc21zIHN1Y2ggYXMgYXVnbWVudGluZyB0aGUgY29kZWJhc2UgdG8g
bWFrZSBzdXJlIGFsbCBhcHByb3ByaWF0ZSB1c2VyIGlucHV0LCBkYXRhIHN0b3JhZ2UsIGFuZCBv
dXRwdXQgcHJvcGVybHkgc2FuaXRpemUgZGF0YSBtYXkgYmUgdXNlZCAtIGFsdGhvdWdoIHRoZXkg
bWF5IGJlIG1vcmUgZXhwZW5zaXZlIHRvIGltcGxlbWVudCBhbmQgYXVkaXQuDQoNClRoZSBBUyBz
aG91bGQgbGlrZXdpc2UgdGFrZSBpbnRvIGFjY291bnQgYW4gYXBwbGljYXRpb27igJlzIG92ZXJh
bGwgc2VjdXJpdHkgcG9zdHVyZSB3aGVuIGRlY2lkaW5nIGFwcHJvcHJpYXRlIHBvbGljaWVzIGFy
b3VuZCBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbiBzY29wZXMgYW5kIHRva2VuIGxpZmV0aW1lcy4N
Cg0KQmVzdCBjdXJyZW50IHByYWN0aWNlcyBpbmNsdWRlIHR1cm5pbmcgdGhlIHNjcmV3cyB0aWdo
dGx5IGFyb3VuZCBDU1AuIEJ1dCBpdCBpcyAodGhlb3JldGljYWxseSkgcG9zc2libGUgdG8gYWNj
b21wbGlzaCB0aGUgc2FtZSB3aXRoIGJydXRlLWZvcmNlIHNhbml0aXphdGlvbiwgd2hpY2ggaGFz
IGJlZW4gbWFkZSBzaW1wbGVyIHdpdGggZnJhbWV3b3JrIHN1cHBvcnQuIEl0IGlzIHN0aWxsIHVs
dGltYXRlbHkgdGhlIEFTIGpvYiB0byBkZWNpZGUgd2hpY2ggY2xpZW50cyBoYXZlIHdoaWNoIGNh
cGFiaWxpdGllcy4NCg0KLURXDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_F3AC370DFB694FD88466D52CDADD17F6mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <0745936976CD354EB8B6ABD85232BF23@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWxzbyB0aGluayBpdCB3b3VsZCBiZSB1c2Vm
dWwsIGJ1dCBhIHByb2JsZW0gaXMgdGhhdCB0aGluZ3MgbGlrZSDigJxhcHBsaWNhdGlvbiB0eXBl
4oCdIGFyZSB1c3VhbGx5IGEgc3RhbmQgaW4gZm9yIGEgd2hvbGUgYnVuY2ggb2YgZGlmZmVyZW50
IGF0dHJpYnV0ZXMgdGhhdCB3ZSBhY3R1YWxseSBjYXJlIGFib3V0LiBUaGF04oCZcyB3aGF0IGhh
cHBlbmVkIHdpdGggd2ViL25hdGl2ZSBhbmQgd2h5LCB0byBteSBrbm93bGVkZ2UsIG5vYm9keSBy
ZWFsbHkNCiB1c2VzIHRob3NlIGluIGxpZXUgb2YgdGhpbmdzIGxpa2UgcHVibGljL2NvbmZpZGVu
dGlhbCBhbmQgcmVkaXJlY3QgVVJJIGxvY2F0aW9ucyBpbnN0ZWFkIGZvciBwb2xpY3kgZGVjaXNp
b25zLiBJZiB3ZSBkbyBlbnVtZXJhdGUgdGhlc2UsIHdlIHdvdWxkIGFsc28gbmVlZCB0byBlbnVt
ZXJhdGUgYWxsIG9mIHRoZSB0aGluZ3MgaXQgbWVhbnMuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRyaWVkIHRvIHNoeSBhd2F5IGZy
b20g4oCcYXBwbGljYXRpb24gdHlwZeKAnSBzdHlsZSBzd2l0Y2hlcyBpbiBYWVrigJlzIHN0cmF3
IG1hbiwgYW5kIGluc3RlYWQgb3B0IGZvciByZWNpcGVzIG9mIGFwcGx5aW5nIHRoZSBkaWZmZXJl
bnQgb3B0aW9ucyB0byBkaWZmZXJlbnQga2luZHMgb2YgY2xpZW50cy4gSSBkb27igJl0IGtub3cg
aG93IGxvbmcgdGhhdCB3aWxsIGhvbGQgdXAgdGhvdWdoLjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNv
bG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt
Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0
aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDI1LCAyMDE5LCBhdCA4OjExIEFN
LCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20iIGNs
YXNzPSIiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz
PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i
bHRyIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h
cmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQs
MjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IiIgY2xhc3M9IiI+T2J2aW91c2x5
IGl0IGNhbiBkbyBpdCBvbiBhIHBlci1jbGllbnQgYmFzaXMgc3RpbGwsIGJ1dCBub3cgYW4gQVMg
aXMgZ29pbmcgdG8gaGF2ZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQgdGhlIGFwcCBpdHNlbGYu
IFBlcmhhcHMgd2UgZmluYWxseSBuZWVkIGEgZmV3IG1vcmUgZW50cmllcyBpbiB0aGUg4oCcYXBw
bGljYXRpb25fdHlwZeKAnSBtZXRhZGF0YSBwYXJhbWV0ZXIgZnJvbSBPSURD4oCZcyBleHRlbnNp
b24NCiBSRkM3NTkxIGJleW9uZCDigJxuYXRpdmXigJ0gYW5kIOKAnHdlYuKAnT8gQnV0IHdlIGF0
IGxlYXN0IHByb2JhYmx5IHdhbnQgdG8gcG9pbnQgb3V0IHRvIEFTIGltcGxlbWVudG9ycyB0aGF0
IHRoaXMgaXMgc29tZXRoaW5nIHRoZXkgd2FudCB0byBjb25zaWRlciB0cmFja2luZyBpbiB0aGVp
ciBkYXRhIG1vZGVsIGZvciBjbGllbnRzLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFz
cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB3b3VsZCB2ZXJ5IG11
Y2ggbGlrZSB0byBzZWUgdGhhdC4gbmF0aXZlL3dlYiBwb3NzaWJseSBpbiBjb21iaW5hdGlvbiB3
aXRoIHRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIGFuZCB0aGUgY2xpZW50IGJlaW5nIERDUiBv
ciAmcXVvdDtzdGF0aWMmcXVvdDsgaXMgZmFyIGZyb20gYmVpbmcgZW5vdWdoIHRvIG1ha2UgYSBw
b2xpY3kgZGVjaXNpb24uPC9kaXY+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFy
dG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+UyBwb3pkcmF2ZW0sPGJyIGNsYXNzPSIiPg0KPGIgY2xh
c3M9IiI+RmlsaXAgU2tva2FuPC9iPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp
dj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJs
dHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIDI1IEp1bCAyMDE5IGF0IDEzOjQ1LCBKdXN0
aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBjbGFzcz0iIj5q
cmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhl
eDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4
Ij4NCjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj5UaGlz
IHJhaXNlcyBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiB0aGF0IEkgZG9u4oCZdCB0aGluayB3ZeKA
mXZlIGFkZHJlc3NlZCB5ZXQ6IGhvdyB0byBhcHByb3ByaWF0ZWx5IHZhcnkgdG9rZW4gbGlmZXRp
bWVzIGFuZCBhY2Nlc3MgZm9yIGRpZmZlcmVudCBjbGllbnRzLg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UHJldmlvdXNseSwgYW4gQVMgY291bGQg
c2VlIHRoYXQgYSBjbGllbnQgd2FzIHVzaW5nIHRoZSBpbXBsaWNpdCBmbG93IGFuZCBkZWNpZGUg
dG8gbGltaXQgdG9rZW4gbGlmZXRpbWVzIG9yIHNjb3BlcyBiYXNlZCBvbiB0aGF0IGFsb25lLiBT
aW1pbGFybHksIEkga25vdyBvZiBhdCBsZWFzdCBzb21lIEFTIGltcGxlbWVudGF0aW9ucyB0aGF0
IGxldCB5b3UgbGltaXQgd2hhdCBzY29wZXMgeW91IGFsbG93IHVuZGVyIHRoZSBjbGllbnQNCiBj
cmVkZW50aWFscyBncmFudC4gVGhlIGtleSBpc3N1ZSBpcyB0aGF0IGlmIGFsbCB5b3VyIGNsaWVu
dHMgYXJlIHVzaW5nIHRoZSBhdXRoIGNvZGUgZmxvdyAod2hpY2ggSSBhZ3JlZSB0aGV5IHNob3Vs
ZCksIHRoZW4gaG93IGRvZXMgYW4gQVMgdGVsbCB0aGUgZGlmZmVyZW5jZSBpbiBjYXBhYmlsaXRp
ZXMgYmV0d2VlbiBpbmNvbWluZyBjbGllbnRzPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T2J2aW91c2x5IGl0IGNhbiBkbyBp
dCBvbiBhIHBlci1jbGllbnQgYmFzaXMgc3RpbGwsIGJ1dCBub3cgYW4gQVMgaXMgZ29pbmcgdG8g
aGF2ZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQgdGhlIGFwcCBpdHNlbGYuIFBlcmhhcHMgd2Ug
ZmluYWxseSBuZWVkIGEgZmV3IG1vcmUgZW50cmllcyBpbiB0aGUg4oCcYXBwbGljYXRpb25fdHlw
ZeKAnSBtZXRhZGF0YSBwYXJhbWV0ZXIgZnJvbSBPSURD4oCZcyBleHRlbnNpb24gUkZDNzU5MSBi
ZXlvbmQNCiDigJxuYXRpdmXigJ0gYW5kIOKAnHdlYuKAnT8gQnV0IHdlIGF0IGxlYXN0IHByb2Jh
Ymx5IHdhbnQgdG8gcG9pbnQgb3V0IHRvIEFTIGltcGxlbWVudG9ycyB0aGF0IHRoaXMgaXMgc29t
ZXRoaW5nIHRoZXkgd2FudCB0byBjb25zaWRlciB0cmFja2luZyBpbiB0aGVpciBkYXRhIG1vZGVs
IGZvciBjbGllbnRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+T24gSnVsIDI1LCAyMDE5LCBhdCA0OjA0IEFNLCBEYXZpZCBXYWl0ZSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb20iIHRhcmdldD0iX2JsYW5r
IiBjbGFzcz0iIj5kYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPC9hPiZndDsgd3JvdGU6PC9k
aXY+DQo8YnIgY2xhc3M9ImdtYWlsLW1fLTgzNDc1MjAzMTU1NzIzNzM0OTZBcHBsZS1pbnRlcmNo
YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
IGNsYXNzPSIiPk9uIEp1bCAyNCwgMjAxOSwgYXQgMzowMyBQTSwgQWFyb24gUGFyZWNraSAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9
IiI+YWFyb25AcGFyZWNraS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpPbiBNb24sIEp1bCAyMiwgMjAxOSBhdCAyOjE0IEFNIERvbWluaWNrIEJhaWVyPGJy
IGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t
IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCiZs
dDtzbmlwJmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SSB3b3Vs
ZCByYXRoZXIgc2F5IHRoYXQgQU5ZIEpTIGFwcCBzaG91bGQgdXNlIENTUCB0byBsb2NrIGRvd24g
dGhlIGJyb3dzZXIgZmVhdHVyZXMgdG8gYSBtaW5pbWFsIGF0dGFjayBzdXJmYWNlLiBJbiBhZGRp
dGlvbiwgaWYgcmVmcmVzaCBvciBhY2Nlc3MgdG9rZW5zIGFyZSBpbnZvbHZlZCAtIGZ1cnRoZXIg
c2V0dGluZ3MgbGlrZSBkaXNhYmxpbmcgaW5saW5lIHNjcmlwdGluZyAodW5zYWZlDQogaW5saW5l
KSBhbmQgZXZhbCBzaG91bGQgYmUgZGlzYWJsZWQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl
Pg0KPGJyIGNsYXNzPSIiPg0KSSdtIG5vdCBzdXJlIHdoYXQgdG8gZG8gd2l0aCB0aGlzIHN1Z2dl
c3Rpb24uIEl0IGZlZWxzIGxpa2UgYSBibGFua2V0PGJyIGNsYXNzPSIiPg0KcmVjb21tZW5kYXRp
b24gb2YgZW5hYmxpbmcgQ1NQIHdpbGwgbGlrZWx5IGJlIGlnbm9yZWQgc2luY2UgaXQncyB0b288
YnIgY2xhc3M9IiI+DQpicm9hZCwgYW5kIHJlY29tbWVuZGluZyBkaXNhYmxpbmcgaW5saW5lIHNj
cmlwdHMgaXMgb3ZlcnJlYWNoaW5nPGJyIGNsYXNzPSIiPg0KdW5sZXNzIGJhY2tlZCB1cCBieSBh
IHNwZWNpZmljIHRocmVhdCBpdCdzIHByb3RlY3RpbmcgYWdhaW5zdC4gRGlkIHlvdTxiciBjbGFz
cz0iIj4NCmhhdmUgYSBwYXJ0aWN1bGFyIHRocmVhdCBpbiBtaW5kPzxiciBjbGFzcz0iIj4NCjwv
YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgd291bGQgc2F5IHRoYXQgYnJvd3NlciBhcHBs
aWNhdGlvbnMgc2hvdWxkIHRha2UgbWVhc3VyZXMgdG8gaGFyZGVuIHRoZWlyIGFwcGxpY2F0aW9u
cyBhZ2FpbiBjb2RlIGluamVjdGlvbiBhbmQgYXJiaXRyYXJ5IGNvZGUgZXhlY3V0aW9uLiBFeGFt
cGxlcyBpbmNsdWRlIGVsaW1pbmF0aW5nIGlubGluZSBzY3JpcHQgKGFuZCBsaW1pdGluZyBlbWJl
ZGRhYmxlIG9iamVjdHMgYXMgbXVjaCBhcyBwb3NzaWJsZSkgdmlhIENTUCwgYW5kIHZlcnNpb25p
bmcNCiB0aGlyZCBwYXJ0eSByZXNvdXJjZXMgdmlhIHRlY2huaXF1ZXMgbGlrZSBzdWJyZXNvdXJj
ZSBpbnRlZ3JpdHkuJm5ic3A7IE1lY2hhbmlzbXMgc3VjaCBhcyBhdWdtZW50aW5nIHRoZSBjb2Rl
YmFzZSB0byBtYWtlIHN1cmUgYWxsIGFwcHJvcHJpYXRlIHVzZXIgaW5wdXQsIGRhdGEgc3RvcmFn
ZSwgYW5kIG91dHB1dCBwcm9wZXJseSBzYW5pdGl6ZSBkYXRhIG1heSBiZSB1c2VkIC0gYWx0aG91
Z2ggdGhleSBtYXkgYmUgbW9yZSBleHBlbnNpdmUgdG8gaW1wbGVtZW50DQogYW5kIGF1ZGl0Ljxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBBUyBzaG91bGQgbGlrZXdpc2UgdGFrZSBp
bnRvIGFjY291bnQgYW4gYXBwbGljYXRpb27igJlzIG92ZXJhbGwgc2VjdXJpdHkgcG9zdHVyZSB3
aGVuIGRlY2lkaW5nIGFwcHJvcHJpYXRlIHBvbGljaWVzIGFyb3VuZCBkZWxlZ2F0ZWQgYXV0aG9y
aXphdGlvbiBzY29wZXMgYW5kIHRva2VuIGxpZmV0aW1lcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpCZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGluY2x1ZGUgdHVybmluZyB0aGUgc2NyZXdz
IHRpZ2h0bHkgYXJvdW5kIENTUC4gQnV0IGl0IGlzICh0aGVvcmV0aWNhbGx5KSBwb3NzaWJsZSB0
byBhY2NvbXBsaXNoIHRoZSBzYW1lIHdpdGggYnJ1dGUtZm9yY2Ugc2FuaXRpemF0aW9uLCB3aGlj
aCBoYXMgYmVlbiBtYWRlIHNpbXBsZXIgd2l0aCBmcmFtZXdvcmsgc3VwcG9ydC4gSXQgaXMgc3Rp
bGwgdWx0aW1hdGVseSB0aGUgQVMgam9iIHRvIGRlY2lkZSB3aGljaA0KIGNsaWVudHMgaGF2ZSB3
aGljaCBjYXBhYmlsaXRpZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLURXPGJyIGNs
YXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRm
Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxiciBjbGFzcz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRo
QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_F3AC370DFB694FD88466D52CDADD17F6mitedu_--


From nobody Thu Jul 25 10:57: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 CF1E912018A for ; Thu, 25 Jul 2019 10:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCm93-iIRArs for ; Thu, 25 Jul 2019 10:57:22 -0700 (PDT)
Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AB1120183 for ; Thu, 25 Jul 2019 10:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=aLf5vUDEj8vowT2Ma57+CBlcBQRmV+mgjI5pz9LcK0U=;  b=W/wCL26RKO8fmpbv3/mn3EeSHQCdURJwdbA2Ng4KT2i/9oozHU0I5HKPhIWJtf0CLDS/ZNLPcZquLvMZT9whr9KZVey8tnu7sGxneYe710kc+vnKr1vYH19LeDxQ4jDDNWsBkjWkP9TyfGRzOJBi+uBoO7MGAcXZWODUqE+2yl0=;
Received: by smtp49.i.mail.ru with esmtpa (envelope-from ) id 1hqhzQ-0001Lx-8U for OAuth@ietf.org; Thu, 25 Jul 2019 20:57:16 +0300
To: OAuth@ietf.org
From: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Message-ID: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru>
Date: Thu, 25 Jul 2019 20:57:15 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results: smtp49.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 689590B63E0A4B015A78504BD2AC294173B0C787F0EA2BA1BF5CD33FC2D754D2659108408DFACAD3E0987D2BEF3AB90E
X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7B198AA70935470D0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637695C86F4341D7D1D8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC58B8FFCA48A21AB86BB211BC80723F012BEA67288B58D17A389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0A3E989B1926288338941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C3E478A468B35FE767117882F4460429728AD0CFFFB425014E40A5AABA2AD371193AA81AA40904B5D9A18204E546F3947C3E2C50380ACA2941BA3038C0950A5D36C8A9BA7A39EFB766F5D81C698A659EA73AA81AA40904B5D98AA50765F7900637E7B8A58B8C55070EEC76A7562686271EBE1D6DAAD8F14AE1089D37D7C0E48F6C8AA50765F790063702CA68E78BD0E2C3C53DF2FDDED51211089D37D7C0E48F6C5571747095F342E857739F23D657EF2B6825BDBE14D8E7024847893F9AA87235E5BFE6E7EFDEDCD789D4C264860C145E
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D420BE4B2E1075E45822DAF15015123C9598A2A4A1A9C1144CCA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: 
Subject: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 17:57:25 -0000

In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it 
is stated that an error is to be returned when the object request is 
invalid. These errors are "invalid_request_uri" and 
"invalid_request_object".

However, to which redirect URI redirect in the following cases:
* the request object is invalid (eg. invalid signature), should we still 
use client_id/redirect_uri of the invalid request object?
* the request URI could not be reached
* the request object is encrypted and cannot be decrypted (bad key)

Would it be acceptable to use the "client_id" and "redirect_uri" request 
query parameters in such a case? Although it contradicts the current 
specification which states that they shall not be used, and it would 
defeat confidentiality when using encryption.

Another option is not redirecting and displaying the error message on 
the AS, like when the client_id is unknown for instance.

Also I don't get the example in 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2 :

      https://server.example.com/authorize?
        response_type=code%20id_token
        &client_id=s6BhdRkqt3
        &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
        %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
        &state=af0ifjsldkj

in regards to the following statement in 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :

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

My understanding is that "response_type", "client_id" and "state" will 
be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add 
them to the example?

Maybe I've missed something?

Regards,

-- 
Tangui


From nobody Thu Jul 25 11:14: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 5FA591201EC for ; Thu, 25 Jul 2019 11:14:41 -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 woJhLsJ7OH3M for ; Thu, 25 Jul 2019 11:14:39 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5FF1201C6 for ; Thu, 25 Jul 2019 11:14:39 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id q20so52552004otl.0 for ; Thu, 25 Jul 2019 11:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v38Yx0/WT4aCOWJvP8HIKWMnrH+jSSDxU2qEJoedoX4=; b=MJejAS5671v+LSPv/nagxCp3u0mgUFTR7hmL0fyYaPlf0tIrd8ygdeK8fCZnSWgct4 snj361OgVgzn5PWw6lK5TUH8ba2Ok+/6p1zis9ihZM+FV8WpFGi+GpAqrlVXH51o6Vu2 pehaqlEC5PCO3hAuKrRJccCZcDou8k3Joa2R89CWuruQI8qNFlmcMeWTar8imd9OhOOT 2vl2PaH6VsmgDpYPmNpGV04VnYOsa12NwlHwEbR5oQw9q//fxTxVTIe23RuZzAywXxBm iCbyDVCv93kZWzx0c4n12QUF0ZryG6u3Taw9LjXaAZ0RsPHTfBCBTM1Y3biU2XSALyUa ETSg==
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=v38Yx0/WT4aCOWJvP8HIKWMnrH+jSSDxU2qEJoedoX4=; b=pQe+7nu8Tdyox0ZoMt37lm0eibsWmzn9o0tGpNv2qjqyuR4BV8qNeHqMUnFWlEhdnD 2uBEWcapYF0PGpibVYdhPgvgIIomuKIU/fA5j9N8I6Jh6K82JE9097LNWHAwv6N77DnB 3tPYlrbsyfdpYWPTsU3kPxpQNFR3XJALLFuFaO2e0rnrVrEwD3epLa+6k7xQr5GSJB8j O+Fb5OcAX5NODTUzCZlebIKzeK11L9EDwDkorYfhQlyn2YdnC66fu9l949+bkSgztl0A 6+BksEARP5bNoy1PsvukMuMO2tmMUTsTVINmX+kNf3TGMyMLuWFTQdJfi2NJ13D+eEqN oI6g==
X-Gm-Message-State: APjAAAVVSmID9RQPleioNXX7bdxYvK09BEJFbWV3iJ3HZtMmtQtlw9mo rBgLrVYnyPJjPcSDZhuOOuPOJHyjnGGEoJ9Iw1UVRRdy4w==
X-Google-Smtp-Source: APXvYqy8Hg/d3wTD+MPxc6SXHJTVwwxxfm7ojHnivitcYLO94OFlOkBbvmxhrnKZpYQJ1TYxclRZ6rfc8nggNJ/t5rg=
X-Received: by 2002:a9d:7a4e:: with SMTP id z14mr39721728otm.258.1564078478722;  Thu, 25 Jul 2019 11:14:38 -0700 (PDT)
MIME-Version: 1.0
References: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru>
In-Reply-To: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru>
From: Filip Skokan 
Date: Thu, 25 Jul 2019 20:14:25 +0200
Message-ID: 
To: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000200aa8058e856644"
Archived-At: 
Subject: Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 18:14:49 -0000

--000000000000200aa8058e856644
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

See my reply inline.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 19:57, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =
=D0=9F=D0=B5=D0=BD=D1=81  wrote:

> In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
> is stated that an error is to be returned when the object request is
> invalid. These errors are "invalid_request_uri" and
> "invalid_request_object".
>
> However, to which redirect URI redirect in the following cases:
> * the request object is invalid (eg. invalid signature), should we still
> use client_id/redirect_uri of the invalid request object?

* the request URI could not be reached
> * the request object is encrypted and cannot be decrypted (bad key)
>

FS: if the client_id & redirect_uri combination is valid (the uri is valid
for that client) - yes, its fine to use those (dtto state). this applies to
all three


>
> Would it be acceptable to use the "client_id" and "redirect_uri" request
> query parameters in such a case? Although it contradicts the current
> specification which states that they shall not be used, and it would
> defeat confidentiality when using encryption.
>

FS: how would it defeat confidentiality?


>
> Another option is not redirecting and displaying the error message on
> the AS, like when the client_id is unknown for instance.
>

FS: also an acceptable outcome, one with no caveats


>
> Also I don't get the example in
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2 :
>
>       https://server.example.com/authorize?
>         response_type=3Dcode%20id_token
>         &client_id=3Ds6BhdRkqt3
>         &request_uri=3Dhttps%3A%2F%2Ftfp.example.org%2Frequest.jwt
>         %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
>         &state=3Daf0ifjsldkj
>
> in regards to the following statement in
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :
>
>     The client MAY send the parameters included in the request object
>     duplicated in the query parameters as well for the backward
>     compatibility etc.  However, the authorization server supporting this
>     specification MUST only use the parameters included in the request
>     object.
>
> My understanding is that "response_type", "client_id" and "state" will
> be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add
> them to the example?
>

FS: they will only be ignored IF they are also part of the request object
so i believe its fine to have them part of this example.


>
> Maybe I've missed something?
>
> Regards,
>
> --
> Tangui
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


See my reply inline.

S pozdravem,
Filip Skokan

On Thu, =
25 Jul 2019 at 19:57, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =D0=9F=D0=
=B5=D0=BD=D1=81 <tangui.lepense=3D40mail.ru@dmarc.ietf.org> wrote:
In htt=
ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it 

is stated that an error is to be returned when the object request is 

invalid. These errors are "invalid_request_uri" and 

"invalid_request_object".



However, to which redirect URI redirect in the following cases:

* the request object is invalid (eg. invalid signature), should we still 
use client_id/redirect_uri of the invalid request object?=C2=A0

* the request URI could not be reached

* the request object is encrypted and cannot be decrypted (bad key)

FS: if the client_id & redirect_uri combin=
ation is valid (the uri is valid for that client) - yes, its fine to use th=
ose (dtto state). this applies to all three
=C2=A0



Would it be acceptable to use the "client_id" and "redirect_=
uri" request 

query parameters in such a case? Although it contradicts the current 

specification which states that they shall not be used, and it would 

defeat confidentiality when using encryption.

FS: how would it defeat confidentiality?
=C2=A0



Another option is not redirecting and displaying the error message on 

the AS, like when the client_id is unknown for instance.

FS: also an acceptable outcome, one with no caveats
=C2=A0



Also I don't get the example in 

https://tools.ietf.org/html/draf=
t-ietf-oauth-jwsreq-19#section-5.2.2 :



=C2=A0 =C2=A0 =C2=A0 https://server.example.com/authorize?=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 response_type=3Dcode%20id_token

=C2=A0 =C2=A0 =C2=A0 =C2=A0 &client_id=3Ds6BhdRkqt3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 &request_uri=3Dhttps%3A%2F%2Ftfp.example.org=
%2Frequest.jwt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &state=3Daf0ifjsldkj



in regards to the following statement in 

https://tools.ietf.org/html/draft-ie=
tf-oauth-jwsreq-19#section-5 :



=C2=A0 =C2=A0 The client MAY send the parameters included in the request ob=
ject

=C2=A0 =C2=A0 duplicated in the query parameters as well for the backward
=C2=A0 =C2=A0 compatibility etc.=C2=A0 However, the authorization server su=
pporting this

=C2=A0 =C2=A0 specification MUST only use the parameters included in the re=
quest

=C2=A0 =C2=A0 object.



My understanding is that "response_type", "client_id" a=
nd "state" will 

be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add =


them to the example?

FS: they will only=
 be ignored IF they are also part of the request object so i believe its fi=
ne to have them part of this example.
=C2=A0



Maybe I've missed something?



Regards,



-- 

Tangui



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000200aa8058e856644--


From nobody Thu Jul 25 11:19: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 4886E120198 for ; Thu, 25 Jul 2019 11:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM10HW7skmpr for ; Thu, 25 Jul 2019 11:19:25 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006D512018A for ; Thu, 25 Jul 2019 11:19:24 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id e20so68858552iob.9 for ; Thu, 25 Jul 2019 11:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U0tFwEOogzymRZ1H5UA4pDB2y4xEDGvEtGrO2qit/dI=; b=fq6UtR28Rs12veSrxQ2GlAXrBClG+O6Sb1T+LpGxeg9R7a5W35Gon+YPrSBOEiwsYT HGidtczA6r24PgCOWGem97f2wGhNOUCe1wX5I4+MN8i1i01WOlCtVo2TalrzDsT6bCm/ B0o5p83c/5rtfKC+63AsC/ZqyPX6YGklvoC9U=
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=U0tFwEOogzymRZ1H5UA4pDB2y4xEDGvEtGrO2qit/dI=; b=LSlcz84oMLLy6fVM+35iZVWWcwFnive+QDj+2QLjwBtAWxcu4/M+7IiHbWItSGl83Z BlC9FzIS/XVpFAyS3OxoiuVWD0+bzDADU6EWURMoX8Y91d6z1fiXefMKGJJhYAeVJAXa s1iccY3UB4p4ygXR4++hsUk56THjo1irsQAfQGeJb/bDc3d4NulebBBJvtPfUA64Xrkq eSs1dRaHWO+/k9xAga2KffUUmq1Z1uzNzuth8Rw0Qp225D7z/2t/1qkyPOZ/s9QcieUN l+MeEqtrRereS1avOGxDNE1fuMO0rrJFmXWO2BMA1LRJOkXkc9rtckJRw+LLSBTwx6y+ CZoA==
X-Gm-Message-State: APjAAAVHUT/nam2bTVQIsRZSUP3Vfrm4symE03KjotGwFS2Bc7A2WDft uLSzQFyt77SJc2E7vpe52F+IjKQeIga42MFZ8mJG6OMVixmQUk/VJvY0W5DHN+Dso3OWhGyRB0u Wuv57tJc3vvqWwWRad0k=
X-Google-Smtp-Source: APXvYqzp66/NFS/XubG/kQ8ARCy7DepIRmn/6D5mT4iGYTKWdYbbg4KbQbgD8K1hyx9jIf0U0mnaP9ogWEKtnGpdmC4=
X-Received: by 2002:a5d:9b1a:: with SMTP id y26mr18250226ion.238.1564078764010;  Thu, 25 Jul 2019 11:19:24 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 25 Jul 2019 12:18:57 -0600
Message-ID: 
To: Vittorio Bertocci 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000214ad5058e8577b1"
Archived-At: 
Subject: Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 18:19:27 -0000

--000000000000214ad5058e8577b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You're welcome, of course. And thanks for the prompt response. I've
endeavored to continue the parts of the conversation that needed continuing
below.

On Wed, Jul 24, 2019 at 3:46 PM Vittorio Bertocci  wrote:

> Thank you Brian for the thorough and insightful review!
>
Comments:
>
> > On authenticated encryption.
> I did chat with Neil about his draft, but as you mention I didn't
> reference it given that it hasn't bee picked up (yet?).
> On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My
> rationale is that this profile attempts to capture current practices or
> practices that are close enough to the capabilities of existing systems t=
o
> have a reasonable chance of being adopted. None of the products/services
> surveyed used authenticated encryption, and the requirement to acquire a
> symmetric key out of band throws  a big wrench in the otherwise clear-cut
> process of preparing your RS to handle JWT ATs. I will bring the matter u=
p
> as open issue on Friday, and if the consensus will be to include symmetri=
c
> authenticated encryption I'll do that; but my personal preference would b=
e
> to preserve the simplicity of a concrete,
> nothing-of-substance-left-as-exercise-to-the-reader solution that can be
> achieved when the key material can be advertised via metadata.
>

Looking to get consensus is quite reasonable, of course, and I can
sympathize with the aim of simplicity. As I've said before though, I think
the utility it brings is sufficient trade-off with respect to any
additional complexity it brings (which is arguably not that much). And I
imagine I'll continue to recommend it in situations where it makes sense
regardless of where this document ends up. But, well, you know, that's
just, like, my opinion, man.

To set the historical record straight, however, I was among the
products/services surveyed and I explicitly included several examples
showing "AEAD symmetric encrypted AT".



>
> About the nonce mitigation you mention. Do you think this means that I
> should explicitly forbid the presence of a "nonce" claim in JWT ATs?
>

I dunno to be honest. The actual validation of the nonce requires enough
other contortions that it probably doesn't really need to be forbidden
here. And proper use of aud (and maybe other stuff?) stuff also makes using
a AT as an ID token infeasible. So it's okay as is as far as I can tell.
But maybe forbidding nonce isn't a bad suggestion just for the sake of
saying something about it and maybe avoiding some potential mix-ups.



>
> >I think you want to say here that the scope claim in the token has to
> correlate to the scope which was approved. Not necessarily what what
> requested. The authorization request might ask for scope of a+b+c, for
> example, while the user only approves b. Or any other variation on things
> where what was asked for isn't what was gotten..
>
> Here I am trying not to get into the details of what's inside the scope
> claim, more requesting that if "scope" was in the request, the issued tok=
en
> should express a delegation and a symptom of that should be the presence =
of
> the scope claim. Paradoxically that scope claim might be empty if the use=
r
> only consented to scopes that have effect on the presence of other claims
> in the token (say a functional equivalent of profile). Yes, it does sound
> odd, but that's a side effect of the prohibition of sending id_tokens to
> API that creates the requirement to create functional equivalents.
>

I must admit to not 100% following all of that I want to bring it back up
to the text in the draft, which to me, reads as saying that if the authz
request contains a scope, then the AT SHOULD contain a scope (noting that
SHOULD is still actually pretty strong language per RFC2119). I think
that's too strong a correlation between something maybe in the authz
request and a claim in the AT.

I *think* it'd be preferable to say something similar to the effect of (and
it sounds almost silly but it's not meant to), "the scope claim has the
scope". Maybe something along these lines in place of the first
sentence/paragraph of 2.2.2.

  "The issued JWT access token SHOULD/MAY/can/could/will/might include a
scope claim as
   defined in section 4.2 of [TE], which expresses the scope of access
authorized by the token."


>I personally think the SHOULD is too strong here because it puts the onus
> on the resource server to know about (via some config option or something=
)
> and enforce on every transaction a setup/policy thing that the AS is
> responsible for which isn't about the integrity of the authorization data
> in the token. A MAY or even removing the list item would be preferred.
>
> I borrowed this language straight from the OpenID Connect validation step=
s
> for idtokens. Given that JWT ATs can carry identity info, the requirement
> seemed appropriate... also, I think it is reasonable to expect the resour=
ce
> server to know about its own registration- just like it must know about t=
he
> expected aud value and what key should be used to decrypt messages, it
> should know whether encryption was requested or not. In fact, the fact th=
at
> such option was selected at registration time is likely the reflection of=
 a
> policy of the RS itself, something the RS itself would want to ensure has
> been respected. WDYT?
>

I was involved in a similar discussion last yearish around some product
requirements and functionality. And, while I can see the merits on both
sides of it, my opinion still falls squarely on the side I previously
expressed. So what I think is unchanged and I believe that it's an
overreach for a spec like this. Some of the details of the argument are a
bit subtle though and I have a hard time putting them into writing (more
than usual even). Perhaps we could try and use some of the time in Montreal
to have a f2f discussion about it?  Which doesn't even have to be during
the official WG time.



> >multi value audiences
>
> I see the issue. I definitely don't want to redefine the semantic of aud,
> but I also would like to be as crisp as possible on the audience-scope
> correlation and prevent scopes from being misinterpreted as applying to t=
he
> wrong resource. The aud validation will likely happen in some middleware =
in
> front of the API, but authorization checks might happen in the body of th=
e
> API itself when the actual access is being attempted, and having an OR li=
st
> in the aud claim might lead to false positives. RSes correctly written
> should not suffer from this issue (the authorization logic should receive
> only the value from the aud collection that is an actual match) but I hav=
e
> seen enough sloppy implementations to be skeptical about this.
> As a result, I would be inclined to  take out the sentence "or if it
> contains additional audiences that are not known aliases of the resource
> indicator of the current resource server", effectively restricting to
> single value aud and eliminating this issue.
>

While I guess I am still somewhat skeptical about the need to further
constrain the use of audience, it seems that ship has sailed.  I do find it
much more palatable to constrain aud to a single value than to redefine the
semantics of a multi-valued aud.

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

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


You're welcome, of course. And thanks=
 for the prompt response. I've endeavored to continue the parts of the =
conversation that needed continuing below. 

On Wed, Jul 24, 2019 at 3:46=
 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Thank =
you Brian for the thorough and insightful review!
Comme=
nts:

> On authenticated encryption.
I=
 did chat with Neil about his draft, but as you mention I didn't refere=
nce it given that it hasn't bee picked up (yet?).
On referenc=
ing JWE RFC7516 and more JWA RFC7518, I am reluctant. My rationale is that =
this profile attempts to capture current practices or practices that are cl=
ose enough to the capabilities of existing systems to have a reasonable cha=
nce of being adopted. None of the products/services surveyed used authentic=
ated encryption, and the requirement to acquire a symmetric key out of band=
 throws=C2=A0 a big wrench in the otherwise clear-cut process of preparing =
your RS to handle JWT ATs. I will bring the matter up as open issue on Frid=
ay, and if the consensus will be to include symmetric authenticated encrypt=
ion I'll do that; but my personal preference would be to preserve the s=
implicity of a concrete, nothing-of-substance-left-as-exercise-to-the-reade=
r solution that can be achieved when the key material can be advertised via=
 metadata.

Looking to get=
 consensus is quite reasonable, of course, and I can sympathize with the ai=
m of simplicity. As I've said before though, I think the utility it bri=
ngs is sufficient trade-off with respect to any additional complexity it br=
ings (which is arguably not that much). And I imagine I'll continue to =
recommend it in situations where it makes sense regardless of where this do=
cument ends up. But, well, you know, that's just, like, my opinion, man=
. 

To set the historical record straight, however,=
 I was among the products/services surveyed and I explicitly included sever=
al examples showing "AEAD symmetric encrypted AT".
=

=C2=A0

About the nonce mitigation you =
mention. Do you think this means that I should explicitly forbid the presen=
ce of a "nonce" claim in JWT ATs?
<=
div>
I dunno to be honest. The actual validation of the nonce=
 requires enough other contortions that it probably doesn't really need=
 to be forbidden here. And proper use of aud (and maybe other stuff?) stuff=
 also makes using a AT as an ID token infeasible. So it's okay as is as=
 far as I can tell.=C2=A0 But maybe forbidding nonce isn't a bad sugges=
tion just for the sake of saying something about it and maybe avoiding some=
 potential mix-ups.

=C2=A0
<=
br>
>I think you want to say here that the scope claim in the =
token has to correlate to the scope which was approved. Not necessarily wha=
t what requested. The authorization request might ask for scope of a+b+c, f=
or example, while the user only approves b. Or any other variation on thing=
s where what was asked for isn't what was gotten..=C2=A0

=

Here I am trying not to get into the details of what's insid=
e the scope claim, more requesting that if "scope" was in the req=
uest, the issued token should express a delegation and a symptom of that sh=
ould be the presence of the scope claim. Paradoxically that scope claim mig=
ht be empty if the user only consented to scopes that have effect on the pr=
esence of other claims in the token (say a functional equivalent of profile=
). Yes, it does sound odd, but that's a side effect of the prohibition =
of sending id_tokens to API that creates the requirement to create function=
al equivalents.

I must ad=
mit to not 100% following all of that I want to bring it back up to the tex=
t in the draft, which to me, reads as saying that if the authz request cont=
ains a scope, then the AT SHOULD contain a scope (noting that SHOULD is sti=
ll actually pretty strong language per RFC2119). I think that's too str=
ong a correlation between something maybe in the authz request and a claim =
in the AT. 

I *think* it'd be preferable t=
o say something similar to the effect of (and it sounds almost silly but it=
's not meant to), "the scope claim has the scope". Maybe some=
thing along these lines in place of the first sentence/paragraph of 2.2.2.<=
/div>=C2=A0 
=C2=A0 "The issued JWT access token SHOULD/MAY/ca=
n/could/will/might include a scope claim as
=C2=A0 =C2=A0defined in sect=
ion 4.2 of [TE], which expresses the scope of access authorized by the toke=
n."
=C2=A0

>I personally think =
the SHOULD is too strong here because it puts the onus on the resource serv=
er to know about (via some config option or something) and enforce on every=
 transaction a setup/policy thing that the AS is responsible for which isn&=
#39;t about the integrity of the authorization data in the token. A MAY or =
even removing the list item would be preferred.=C2=A0

<=
div>I borrowed this language straight from the OpenID Connect validation st=
eps for idtokens. Given that JWT ATs can carry identity info, the requireme=
nt seemed appropriate... also, I think it is reasonable to expect the resou=
rce server to know about its own registration- just like it must know about=
 the expected aud value and what key should be used to decrypt messages, it=
 should know whether encryption was requested or not. In fact, the fact tha=
t such option was selected at registration time is likely the reflection of=
 a policy of the RS itself, something the RS itself would want to ensure ha=
s been respected. WDYT?

I=
 was involved in a similar discussion last yearish around some product requ=
irements and functionality. And, while I can see the merits on both sides o=
f it, my opinion still falls squarely on the side I previously expressed. S=
o what I think is unchanged and I believe that it's an overreach for a =
spec like this. Some of the details of the argument are a bit subtle though=
 and I have a hard time putting them into writing (more than usual even). P=
erhaps we could try and use some of the time in Montreal to have a f2f disc=
ussion about it?=C2=A0 Which doesn't even have to be during the officia=
l WG time.=C2=A0 

=C2=A0
>multi valu=
e audiences

I see the issue. I definitely don'=
t want to redefine the semantic of aud, but I also would like to be as cris=
p as possible on the audience-scope correlation and prevent scopes from bei=
ng misinterpreted as applying to the wrong resource. The aud validation wil=
l likely happen in some middleware in front of the API, but authorization c=
hecks might happen in the body of the API itself when the actual access is =
being attempted, and having an OR list in the aud claim might lead to false=
 positives. RSes correctly written should not suffer from this issue (the a=
uthorization logic should receive only the value from the aud collection th=
at is an actual match) but I have seen enough sloppy implementations to be =
skeptical about this.=C2=A0
As a result, I would be inclined to=
=C2=A0 take out the sentence "or if it contains additional audiences t=
hat are not known aliases of the resource indicator of the current resource=
 server", effectively restricting to single value aud and eliminating =
this issue.

While I g=
uess I am still somewhat skeptical about the need to further constrain the =
use of audience, it seems that ship has sailed.=C2=A0 I do find it much mor=
e palatable to constrain aud to a single value than to redefine the semanti=
cs of a multi-valued aud. 


=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.
--000000000000214ad5058e8577b1--


From nobody Thu Jul 25 11:48: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 D60FD1201B0 for ; Thu, 25 Jul 2019 11:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=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=mail.ru
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpc5VCY-lo0R for ; Thu, 25 Jul 2019 11:48:09 -0700 (PDT)
Received: from smtp54.i.mail.ru (smtp54.i.mail.ru [217.69.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D5F1201A0 for ; Thu, 25 Jul 2019 11:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=wmm052+VTO8jdcjhIxVduLcCoBm5eph6vpXNssvVjm8=;  b=ftsCcy57cuAlLQkjl4EMA/odoAvN4YDZ44Rwj9YWban90/UdN5BEW3H8Db50lJEwtuxgTQncg0hQSYJYq9rWP1VRdif6rOhFjNssBbhXxlCLTyITb8cBQMs3Rw5yMakadnZ+nKf5h5QlAwHSKrwcnrd9uybHJcXpSgYfDIWqB9A=;
Received: by smtp54.i.mail.ru with esmtpa (envelope-from ) id 1hqimc-0006pt-Nu; Thu, 25 Jul 2019 21:48:07 +0300
To: Filip Skokan , =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Cc: oauth 
References: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru> 
From: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Message-ID: <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
Date: Thu, 25 Jul 2019 21:48:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results: smtp54.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 3FFC80838138E3AB5A78504BD2AC294173B0C787F0EA2BA1667A1FD3CE774639CB2022ED40CBBBD3DA91B6C4C7D8E2FC
X-7FA49CB5: 0D63561A33F958A50AD8B216AB446C668AD1DD314D16F985F1222E096041C3ED8941B15DA834481FA18204E546F3947CB861051D4BA689FCF6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B3A703B70628EAD7BA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C224988F0F0F8BA165F5C76E601842F6C81A12EF20D2F80756B5F868A13BD56FB6657D81D268191BDAD3D78DA827A17800CE7436E4CC186B5AB2DB3661434B16C20AC93541453170D46FCAAAE862A0553A39223F8577A6DFFEA7C045B4009A2530507752512DE092FF5CCEFF80C71ABB335746BA297DBC24807EA27F269C8F02392CDC58410348177836EABEDDA51113D120200306258E7E6ABB4E4A6367B16DE6309
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D4A952EE5F2A92D8AD243C758D39EB3F0454E284FD4F22E913CA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: 
Subject: Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 18:48:14 -0000

Filip, thank you for your reply. Additional remarks inline.

On 25.07.2019 21:14, Filip Skokan wrote:
> See my reply inline.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 25 Jul 2019 at 19:57, Танги Ле ÐŸÐµÐ½Ñ 
>  > wrote:
>
>     In
>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
>     is stated that an error is to be returned when the object request is
>     invalid. These errors are "invalid_request_uri" and
>     "invalid_request_object".
>
>     However, to which redirect URI redirect in the following cases:
>     * the request object is invalid (eg. invalid signature), should we
>     still
>     use client_id/redirect_uri of the invalid request object? 
>
>     * the request URI could not be reached
>     * the request object is encrypted and cannot be decrypted (bad key)
>
>
> FS: if the client_id & redirect_uri combination is valid (the uri is 
> valid for that client) - yes, its fine to use those (dtto state). this 
> applies to all three

It doesn't apply to an encrypted object that cannot be decrypted.

>
>     Would it be acceptable to use the "client_id" and "redirect_uri"
>     request
>     query parameters in such a case? Although it contradicts the current
>     specification which states that they shall not be used, and it would
>     defeat confidentiality when using encryption.
>
>
> FS: how would it defeat confidentiality?
If you use a JWE in the first place, it's so that the parameters cannot 
be read on the wire.
>
>
>     Another option is not redirecting and displaying the error message on
>     the AS, like when the client_id is unknown for instance.
>
>
> FS: also an acceptable outcome, one with no caveats

Except degraded UI for the end user, if we assume that an error on the 
client side is easier to manage that a cryptic error on the AS with no 
link back to the client. Also, the client could have a retry strategy 
(it might just be that the request object at the request object URI is 
expired, due to network latency, etc.).

So if my understanding is correct, it's up to the implementer to make a 
decision on this point? Couldn't it lead to incompatibility, divergent 
implementations?

>
>     Also I don't get the example in
>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2
>     
>     :
>
>     https://server.example.com/authorize?
>             response_type=code%20id_token
>             &client_id=s6BhdRkqt3
>             &request_uri=https%3A%2F%2Ftfp.example.org
>     %2Frequest.jwt
>             %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
>             &state=af0ifjsldkj
>
>     in regards to the following statement in
>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :
>
>         The client MAY send the parameters included in the request object
>         duplicated in the query parameters as well for the backward
>         compatibility etc.  However, the authorization server
>     supporting this
>         specification MUST only use the parameters included in the request
>         object.
>
>     My understanding is that "response_type", "client_id" and "state"
>     will
>     be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to
>     add
>     them to the example?
>
>
> FS: they will only be ignored IF they are also part of the request 
> object so i believe its fine to have them part of this example.

It's seems ambiguous to me when reading the specification. 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4 states 
that:

A Request Object (Section 2.1  ) is used to provide authorization
    request parameters for an OAuth 2.0 authorization request.  It MUST
    contains all the OAuth 2.0 [RFC6749  ] authorization request parameters
    including extension parameters.

So there'd be no such thing as "client_id" and "redirect_uri" as query 
parameters, and other parameters members of the request object in my 
interpretation.

In OpenID Connect you can indeed have both, the request object's 
parameters having precedence over query parameters 
(https://openid.net/specs/openid-connect-core-1_0.html#RequestObject):

When the request parameter is used, the OpenID Connect request parameter 
values contained in the JWT supersede those passed using the OAuth 2.0 
request syntax. However, parameters MAY also be passed using the OAuth 
2.0 request syntax even when a Request Object is used; this would 
typically be done to enable a cached, pre-signed (and possibly 
pre-encrypted) Request Object value to be used containing the fixed 
request parameters, while parameters that can vary with each request, 
such as state and nonce, are passed as OAuth 2.0 parameters.

What do you think?

>
>     Maybe I've missed something?
>
>     Regards,
>
>     -- 
>     Tangui
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 25 11:54: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 0B92F12022C for ; Thu, 25 Jul 2019 11:54:04 -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_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 lBSqv31lKn8x for ; Thu, 25 Jul 2019 11:54:02 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CB91201F0 for ; Thu, 25 Jul 2019 11:54:02 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id j5so95318323ioj.8 for ; Thu, 25 Jul 2019 11:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=a7oJjLQwY4FtZ3cZVGx5Rq5iIUIItdtJjAWmXfrlBOo=; b=eM0LguxUenL36sg389+jW65Gx1/nH7iptqcEKcmmZwZyNk8DfpOadgQMzMO3WYFTOn 6USA+spKE/aQbVUqbMxfqGVSqYXxPG+snAB+XEAFJSwVGy4/hn7IdQdQe5oJ21LGEloX NagdHpOvZJYVAUMGaGzlzshK8RbrcjvjEwnEsa2F+Yw5DvevzZ5xann5wE1g2Yhqinxg xQm2jJWGq3FWqG+Nbjm5sUhD9ti30SATCrzVJCaWhp74/kI2tckzpnJ2g8M8bYUQ5DPN mTcCImF3yaHw8VzhFUz9lT6OtUOMRfxtoxeVboq2v6MD7Wv4RkOHD8QlvnXKTDEHomwm Jrmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=a7oJjLQwY4FtZ3cZVGx5Rq5iIUIItdtJjAWmXfrlBOo=; b=mM32FAqVs/S07uPyliMoYMnx5SPyTj7QIkIZEU1aXH6O1skG9XJaZy6Qn1zmTcQkVq LwpRvA0qpeJyPDc/1HaKbxNUVJp2iFXJO1JVczVLk4u9Ux5erhGy8OIQt77u1+g2BZG2 Jsrgzo9Bac0VwJKLV+8qeKapCB9qXKETyuxAlr9Wt+9q7TwwYLWFxatvDgF85GsdBURz zSDwDWBPUc3gZFadSPNfyWv61iCFUmjr+G/uF2Gq9TmdMcbpmSYqjcwRgO9ue9NaJU/K tRvUUytIfe8Xut0JWteqRnKlpWEfxu/5i1NT7a9rGjVDWVvXzfgjl4mzVgtnKhzqGDne o7ow==
X-Gm-Message-State: APjAAAWCmu7YUuCL0rvgL6I4dq/SY2Bvy22tg5IEd27bX2GG6XVf4mtE Bmtl+DVDmt18z5LwH9UVt6N1WO82Wls=
X-Google-Smtp-Source: APXvYqwsen43oRYKRrTh8I66l4YJ+daMCvijCSUxLjlQphbQ7i+u2Y4SzbBfs+6b1oRYeafXKPKpAw==
X-Received: by 2002:a6b:8f93:: with SMTP id r141mr85716275iod.145.1564080841087;  Thu, 25 Jul 2019 11:54:01 -0700 (PDT)
Received: from [172.16.137.148] ([207.115.96.130]) by smtp.gmail.com with ESMTPSA id p3sm76337933iom.7.2019.07.25.11.54.00 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 11:54:00 -0700 (PDT)
To: oauth@ietf.org
From: Daniel Fett 
Message-ID: <34add299-ae88-4c6f-a33c-82c147549516@yes.com>
Date: Thu, 25 Jul 2019 20:53:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E3730B30E50686DEA3A2B838"
Content-Language: de-DE
Archived-At: 
Subject: [OAUTH-WG] Location and dates for next OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 18:54:12 -0000

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

Hi all,

it seems like there is a rough consensus on having the next OAuth
Security Workshop in Trondheim, Norway. We will therefore start with the
planning.

After checking various event calendars it seems like the following dates
are suitable:

**

  * *

    May 7-9

  *

    July 22-24

  *

    August 3-5

    *

***

First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The
latter two dates are before/after IETF 108 which is July 25-31,
Madrid/Spain.

Unless somebody raises objections because of conflicting
identity/security events we will pick one of these dates in the next two
weeks or so.

-Daniel

*


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


  

    
  
  
    
Hi all,

    
it seems like there is a rough consensus on having the next OAuth
      Security Workshop in Trondheim, Norway. We will therefore start
      with the planning.

    
After checking various event calendars it seems like the
      following dates are suitable:

    

        
    
          
  • May 7-9
    • 
          
  • July 22-24
    • 
          
  • August 3-5
    • 
        

      
        
First date is before EIC ‘20 which is May 12-15 in
          Munich/Germany. The latter two dates are before/after IETF 108
          which is July 25-31, Madrid/Spain.

        
Unless somebody raises objections because of conflicting
          identity/security events we will pick one of these dates in
          the next two weeks or so.

        

        
-Daniel

        

      

  


--------------E3730B30E50686DEA3A2B838--


From nobody Thu Jul 25 11:55: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 A10F212021F for ; Thu, 25 Jul 2019 11:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj1H7tyW7PJU for ; Thu, 25 Jul 2019 11:55:23 -0700 (PDT)
Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253FA1201F8 for ; Thu, 25 Jul 2019 11:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=MX5zuQ8zeMmxW+UUelv0qDUsRY9WjmqmOUG6bsazjnc=;  b=lP/jeJuedh1J8BRtmCZdsoketIpxRqmJedeqqSTbroippdReIb1vdMe/4zXITtX2wVvmGtPL/kxIvp8pTG3y6JNAjSNaJcP7zlCJDP9xLZmCDscJCpTDj4bZRqvyOq0oeZJbiP68CRm94shB1PB/7NzBNmiWuPdKywEnRoxN/jA=;
Received: by smtp40.i.mail.ru with esmtpa (envelope-from ) id 1hqitc-0001gq-P8 for OAuth@ietf.org; Thu, 25 Jul 2019 21:55:21 +0300
To: oauth 
From: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Message-ID: 
Date: Thu, 25 Jul 2019 21:55:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results: smtp40.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 260C666A7D66B36A5A78504BD2AC294173B0C787F0EA2BA198E7F487E88572BC68334DD289734B6F9380524CF741C8BF
X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE723C544A82E63DB9DEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637A61F0BAD8BCAD5198638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC5B52A0C24483FED46AB2967D62766D7C848F3F70FB5908FF389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0E45F71884F0C27A38941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C33CCD70CEBBF18A22117882F4460429728AD0CFFFB425014E40A5AABA2AD371193AA81AA40904B5D9A18204E546F3947C91B80A194963C606AD7EC71F1DB884274AD6D5ED66289B52BA9C0B312567BB2376E601842F6C81A127C277FBC8AE2E8B8F84DE33370BFF23EC76A7562686271EBE1D6DAAD8F14AE1089D37D7C0E48F6C8AA50765F790063702CA68E78BD0E2C3C53DF2FDDED51211089D37D7C0E48F6C5571747095F342E857739F23D657EF2B6825BDBE14D8E7028C9DFF55498CEFB0BD9CCCA9EDD067B1EDA766A37F9254B7
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D4380E2C25BCA234BFD59E7652DC012465A626B283B0EE9978CA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: 
Subject: [OAUTH-WG] RFC7009: what to return when revoking a token which is not the client's?
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 18:55:32 -0000

Hi,

In RFC7009 - section 2.1 
(https://tools.ietf.org/html/rfc7009#section-2.1), it is stated that:

    The authorization server first validates the client credentials (in
    case of a confidential client) and then verifies whether the token
    was issued to the client making the revocation request.  If this
    validation fails, the request is refused and the client is informed
    of the error by the authorization server as described below.

And then in section 2.2 (https://tools.ietf.org/html/rfc7009#section-2.2):

    The authorization server responds with HTTP status code 200 if the
    token has been revoked successfully or if the client submitted an
    invalid token.

Returning an error in the first case (and not the standard 200 HTTP 
status) would leak to another client that the token exists and is 
actually valid. Even though scanning tokens is hard if implemented with 
a sufficient entropy (timing attacks could probably help here), 
shouldn't it be preferable on a security perspective to return an HTTP 
200 code instead of an error?

Is there some historical discussion that I may have missed?

Regards,

-- 

Tangui


From nobody Thu Jul 25 11:59: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 0ACE3120191 for ; Thu, 25 Jul 2019 11:59:26 -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 c5wuzxefSG7x for ; Thu, 25 Jul 2019 11:59:23 -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 4BA5F12019F for ; Thu, 25 Jul 2019 11:59:23 -0700 (PDT)
Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqixT-0003na-EY; Thu, 25 Jul 2019 20:59:19 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-FA10D27C-6DC4-49D3-957E-357DE86E1569; 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: Thu, 25 Jul 2019 20:59:18 +0200
Cc: Tomek Stojecki , Brian Campbell , OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: <0C46E46C-5027-47E7-8214-A4F865127B9C@lodderstedt.net>
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>  <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com> <1903519861.188545.1563954610968@mail.yahoo.com> 
To: Aaron Parecki 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 18:59:26 -0000

--Apple-Mail-FA10D27C-6DC4-49D3-957E-357DE86E1569
Content-Type: multipart/alternative;
	boundary=Apple-Mail-D7BF304A-C5FA-42D1-A501-3A5385868591
Content-Transfer-Encoding: 7bit


--Apple-Mail-D7BF304A-C5FA-42D1-A501-3A5385868591
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 24.07.2019 um 22:13 schrieb Aaron Parecki :

>> 2) Regarding architectures: I think this BCP should focus on recommendati=
ons for securely implementing OAuth in the different potential architecture.=
 I don=E2=80=99t think we should get into the business of recommending and a=
ssessing other solutions (e.g. section 6.1.).
>=20
> This section was originally added from a discussion on the list, I believe=
 it was actually Torsten's suggestion: https://mailarchive.ietf.org/arch/msg=
/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The section was later modified and expand=
ed based on feedback from the meeting in Prague.

My latest feedback is inline with the post you refer to. There I suggested t=
o also consider an architecture where the OAuth logic resides in a backend. I=
 never suggested to add anything outside of an OAuth-based architecture.=

--Apple-Mail-D7BF304A-C5FA-42D1-A501-3A5385868591
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 24.07.2019 um 22:13 schrieb Aaron Parecki <=
;aaron@parecki.com>:

2) Regarding architectures: I think this BCP should focus o=
n recommendations for securely implementing OAuth in the different potential=
 architecture. I don=E2=80=99t think we should get into the business of reco=
mmending and assessing other solutions (e.g. section 6.1.).

This section was originally added from a discussion on the l=
ist, I believe it was actually Torsten's suggestion: https://ma=
ilarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The s=
ection was later modified and expanded based on feedback from the meeting in=
 Prague.

My latest feedback is inline with t=
he post you refer to. There I suggested to also consider an architecture whe=
re the OAuth logic resides in a backend. I never suggested to add anything o=
utside of an OAuth-based architecture.
=

--Apple-Mail-D7BF304A-C5FA-42D1-A501-3A5385868591--

--Apple-Mail-FA10D27C-6DC4-49D3-957E-357DE86E1569
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
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzI1MTg1OTE5WjAvBgkqhkiG9w0BCQQxIgQg
eXBWvVIhI4y+RMbCjvQpbaWvpSCB1g4zGN1WWBdQiZAwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAJIaXK6f+Mfq7AOv
Wqc/M3sYk6rQlCq5X7fB139SBIUf+lmumyl64QveCyLFn/OZmgRBQxuk4GR97t+oyiZBqXftsG4J
g7x/AFU+DoOvtYGq/gRKUxOUJzemP+3z5vf+PWN8aDmH+60ZiaPb4kWpqLhb1taFQExVnLU18g/0
dwVNtqW+OO259z91PUIAVkAn4HR1/AarcLk45p6j3UBoRE+UvE8xnQh3Q+oenUjxYg1D+0c0m2HR
/wnyncsqgbb+4c71b4b+MEUCcDKnk0bwcZ8LCD/oD8dtNd2bUOSsQHbC/xp8minz/C9rHmC+ZDH3
Bl6PjfDp6Q2rrIViETUM79AAAAAAAAA=

--Apple-Mail-FA10D27C-6DC4-49D3-957E-357DE86E1569--


From nobody Thu Jul 25 12:00: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 241C01202A9 for ; Thu, 25 Jul 2019 12:00:43 -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 U2XpBel_fVEx for ; Thu, 25 Jul 2019 12:00:41 -0700 (PDT)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.99]) (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 E26AB1202CC for ; Thu, 25 Jul 2019 12:00:40 -0700 (PDT)
Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqiyj-0002n3-3R; Thu, 25 Jul 2019 21:00:37 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-E539D436-16D3-4053-8B0F-ED43F5449AA0; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com>
Date: Thu, 25 Jul 2019 21:00:36 +0200
Cc: Brian Campbell , OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: <6EC1147B-B23C-44E6-84AF-9E79D384153A@lodderstedt.net>
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>  <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com>
To: David Waite 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 19:00:54 -0000

--Apple-Mail-E539D436-16D3-4053-8B0F-ED43F5449AA0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



> Am 24.07.2019 um 04:13 schrieb David Waite :=

>=20
> Perhaps it should be turned into a stated document assumption (that the re=
ader has decided to use OAuth) rather than guidance later in the document (t=
hat OAuth may not be the best fit)

+1=

--Apple-Mail-E539D436-16D3-4053-8B0F-ED43F5449AA0
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
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzI1MTkwMDM2WjAvBgkqhkiG9w0BCQQxIgQg
2M8I5gg3odQNEYHdaW4/gfUdtvdWv1QYLnBusw+TVu0wgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACKJX3b2to4CSb5N
+PF0XY7ZqAnqg5qdy29VNdm8VLpd6y7hLgRSdBPZt1ZyLSMdL/J12jkr/5YFBjRNidj57fH6aNIg
6dAoHmy9FoCGHoc84yOJSX2L5Llh8TV+mHHoxEQxLK/l5vJqQvHcKS21hxelJu077+l/CGNxMuoA
Nfu2jqFV3mT0ym9IeH3wa+PtqEXSIsj6CGOU8SCDKeHgvaAYWxxM//aKTBZQWR0f2mWcXNXgZNhX
z2P+3dTjuzPcPc50qzOhDOscEi5xlQlKTL8zpJ2TVD75Ebe9xW4n6h2WxNtyF5rQTzCy+UQw2L7/
aRTFGXH7qgvX/UIZyd/cEkMAAAAAAAA=

--Apple-Mail-E539D436-16D3-4053-8B0F-ED43F5449AA0--


From nobody Thu Jul 25 12:02: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 0DD241201CF for ; Thu, 25 Jul 2019 12:02:03 -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 PQqNFfEgueKc for ; Thu, 25 Jul 2019 12:01:59 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44A91201C9 for ; Thu, 25 Jul 2019 12:01:59 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id c2so23727328plz.13 for ; Thu, 25 Jul 2019 12:01:59 -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=Ti9CWX6wlRJE82DmdueofLymWpMc425Mrov1vFW5YxQ=; b=EQizy8YSTcqm5S79/rhnLNAGlzOXDlmNoCFAhj7uBZNPPD6ulLf6FKeZu8xTth40Ot vpGhpsURiKSy50sukzIfgppUHYQIrrfmetQsazXlQOj84rDZMrkLKUEHEmWgWjHNAlDp OXOxVZkd6E+1KOrUUSDx0dMBfgTq4hr3knV/nmR/Z04ZzVce1kRF83mzYFYWxCXC4nF+ ZkJtZESnpJr0P28FaEcVHrofPsxVTlCtK+uDl8DckQN1yIUPdYTFr+LUORguZ11x3rwU PngzhR0cuoolQuN0Yx+VEFfNZYgntmWSQznaL0dyReXSeCpj7coQi4ie4wTkP/2HXhxI yENA==
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=Ti9CWX6wlRJE82DmdueofLymWpMc425Mrov1vFW5YxQ=; b=kIkiel7ZWi7mrDFdBRsDp8xzo5Iz+yJpZorFjMO9V/HKGchylCNSx6R07y/XifB7fi cJcay/fBiIPknxADpwfIzrlSMqOQHITrRXvm/Pn45EcV7nE1e/iH0jgl8GN8LboH691d zn8FgfFVTIAhB8lUf3S9ewmF49tmBk1HrKOXe2/4vSuKl0/sfEfI/NrRbKHnECwEl1P3 HJouiOjgza+G+EkvijzWdBoNm7uggPpgicEg8yovJ9LkunL9aons//fvTNiClHss5Pw8 0YAVFiSI/9ME3M5bE9iiBHGt3n5Ki4yMX/zF6fU7NANMvRcWI7GYDA+e6sREmcMPMViq 6r7A==
X-Gm-Message-State: APjAAAW+cRFEZkS5K33cyTlc7ZbiPBoDwzoyYC1bVrXqCFHQOQhOdYss qdxdyruEF85cnogJO8ScIwwm2jdfyHpUQE52EL4=
X-Google-Smtp-Source: APXvYqxMp2Y6FjhCKZSMZPw2NOkxRsjBhTmiRWbpK9mN2hjukhCPlPkQ8kYOD0NUZn8YqQzMYI/z21XavUM1T30KoaM=
X-Received: by 2002:a17:902:4401:: with SMTP id k1mr68682980pld.193.1564081318890;  Thu, 25 Jul 2019 12:01:58 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Leo Tohill 
Date: Thu, 25 Jul 2019 15:01:48 -0400
Message-ID: 
To: Justin Richer 
Cc: Filip Skokan , OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000699798058e860f9d"
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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, 25 Jul 2019 19:02:11 -0000

--000000000000699798058e860f9d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

 > I agree, I removed the mention of OIDC.

If that means you'd leave the OAuth prohibition, it's still misleading or
confusing.  OIDC is of course an extension of or layer over OAuth.  If you
prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's
the way it reads.



On Thu, Jul 25, 2019 at 12:51 PM Justin Richer  wrote:

> I also think it would be useful, but a problem is that things like
> =E2=80=9Capplication type=E2=80=9D are usually a stand in for a whole bun=
ch of different
> attributes that we actually care about. That=E2=80=99s what happened with
> web/native and why, to my knowledge, nobody really uses those in lieu of
> things like public/confidential and redirect URI locations instead for
> policy decisions. If we do enumerate these, we would also need to enumera=
te
> all of the things it means.
>
> I tried to shy away from =E2=80=9Capplication type=E2=80=9D style switche=
s in XYZ=E2=80=99s straw
> man, and instead opt for recipes of applying the different options to
> different kinds of clients. I don=E2=80=99t know how long that will hold =
up though.
>
> =E2=80=94 Justin
>
> On Jul 25, 2019, at 8:11 AM, Filip Skokan  wrote:
>
> Obviously it can do it on a per-client basis still, but now an AS is goin=
g
>> to have to know a bit more about the app itself. Perhaps we finally need=
 a
>> few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata para=
meter from OIDC=E2=80=99s
>> extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=
=9D? But we at least probably want
>> to point out to AS implementors that this is something they want to
>> consider tracking in their data model for clients.
>>
>
> I would very much like to see that. native/web possibly in combination
> with token_endpoint_auth_method and the client being DCR or "static" is f=
ar
> from being enough to make a policy decision.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 25 Jul 2019 at 13:45, Justin Richer  wrote:
>
>> This raises an interesting question that I don=E2=80=99t think we=E2=80=
=99ve addressed
>> yet: how to appropriately vary token lifetimes and access for different
>> clients.
>>
>> Previously, an AS could see that a client was using the implicit flow an=
d
>> decide to limit token lifetimes or scopes based on that alone. Similarly=
, I
>> know of at least some AS implementations that let you limit what scopes =
you
>> allow under the client credentials grant. The key issue is that if all y=
our
>> clients are using the auth code flow (which I agree they should), then h=
ow
>> does an AS tell the difference in capabilities between incoming clients?
>>
>> Obviously it can do it on a per-client basis still, but now an AS is
>> going to have to know a bit more about the app itself. Perhaps we finall=
y
>> need a few more entries in the =E2=80=9Capplication_type=E2=80=9D metada=
ta parameter from
>> OIDC=E2=80=99s extension RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=
=80=9Cweb=E2=80=9D? But we at least
>> probably want to point out to AS implementors that this is something the=
y
>> want to consider tracking in their data model for clients.
>>
>> =E2=80=94 Justin
>>
>> On Jul 25, 2019, at 4:04 AM, David Waite 
>> wrote:
>>
>>
>>
>>
>> On Jul 24, 2019, at 3:03 PM, Aaron Parecki  wrote:
>>
>> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
>>  wrote:
>>
>> 
>>
>> I would rather say that ANY JS app should use CSP to lock down the
>> browser features to a minimal attack surface. In addition, if refresh or
>> access tokens are involved - further settings like disabling inline
>> scripting (unsafe inline) and eval should be disabled.
>>
>>
>> I'm not sure what to do with this suggestion. It feels like a blanket
>> recommendation of enabling CSP will likely be ignored since it's too
>> broad, and recommending disabling inline scripts is overreaching
>> unless backed up by a specific threat it's protecting against. Did you
>> have a particular threat in mind?
>>
>>
>> I would say that browser applications should take measures to harden
>> their applications again code injection and arbitrary code execution.
>> Examples include eliminating inline script (and limiting embeddable obje=
cts
>> as much as possible) via CSP, and versioning third party resources via
>> techniques like subresource integrity.  Mechanisms such as augmenting th=
e
>> codebase to make sure all appropriate user input, data storage, and outp=
ut
>> properly sanitize data may be used - although they may be more expensive=
 to
>> implement and audit.
>>
>> The AS should likewise take into account an application=E2=80=99s overal=
l
>> security posture when deciding appropriate policies around delegated
>> authorization scopes and token lifetimes.
>>
>> Best current practices include turning the screws tightly around CSP. Bu=
t
>> it is (theoretically) possible to accomplish the same with brute-force
>> sanitization, which has been made simpler with framework support. It is
>> still ultimately the AS job to decide which clients have which capabilit=
ies.
>>
>> -DW
>> _______________________________________________
>> 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
>

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




> I agree, I removed the mention of=
 OIDC.

If that=
 means you'd leave the OAuth prohibition, it's still misleading or =
confusing.=C2=A0 OIDC is of course an extension of or layer over OAuth.=C2=
=A0 If you prohibit OAuth, you prohibit OIDC. You don't mean it that wa=
y, but that's the way it reads. 
=C2=A0 




=
On Thu, Jul 25, 2019 at 12:51 PM Justin Richer <jricher@mit.edu> wrote:






I also think it would be useful, but a problem is that things like =E2=80=
=9Capplication type=E2=80=9D are usually a stand in for a whole bunch of di=
fferent attributes that we actually care about. That=E2=80=99s what happene=
d with web/native and why, to my knowledge, nobody really
 uses those in lieu of things like public/confidential and redirect URI loc=
ations instead for policy decisions. If we do enumerate these, we would als=
o need to enumerate all of the things it means.=C2=A0






I tried to shy away from =E2=80=9Capplication type=E2=80=9D style swit=
ches in XYZ=E2=80=99s straw man, and instead opt for recipes of applying th=
e different options to different kinds of clients. I don=E2=80=99t know how=
 long that will hold up though.








=E2=80=94 Justin









On Jul 25, 2019, at 8:11 AM, Filip Skokan <panva.ip@gmail.com> wrote:










Obviously it can do it on a per-client basis still, but now an AS is g=
oing to have to know a bit more about the app itself. Perhaps we finally ne=
ed a few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata pa=
rameter from OIDC=E2=80=99s extension
 RFC7591 beyond =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we =
at least probably want to point out to AS implementors that this is somethi=
ng they want to consider tracking in their data model for clients.









I would very much like to see that. native/web possibly in combination=
 with token_endpoint_auth_method and the client being DCR or "static&q=
uot; is far from being enough to make a policy decision.






S poz=
dravem,

Filip Skokan












On Thu, 25 Jul 2019 at 13:45, Justin =
Richer <jricher@mit=
.edu> wrote:






This raises an interesting question that I don=E2=80=99t think we=E2=
=80=99ve addressed yet: how to appropriately vary token lifetimes and acces=
s for different clients.






Previously, an AS could see that a client was using the implicit flow =
and decide to limit token lifetimes or scopes based on that alone. Similarl=
y, I know of at least some AS implementations that let you limit what scope=
s you allow under the client
 credentials grant. The key issue is that if all your clients are using the=
 auth code flow (which I agree they should), then how does an AS tell the d=
ifference in capabilities between incoming clients?=C2=A0







Obviously it can do it on a per-client basis still, but now an AS is g=
oing to have to know a bit more about the app itself. Perhaps we finally ne=
ed a few more entries in the =E2=80=9Capplication_type=E2=80=9D metadata pa=
rameter from OIDC=E2=80=99s extension RFC7591 beyond
 =E2=80=9Cnative=E2=80=9D and =E2=80=9Cweb=E2=80=9D? But we at least probab=
ly want to point out to AS implementors that this is something they want to=
 consider tracking in their data model for clients.










=E2=80=94 Justin









On Jul 25, 2019, at 4:04 AM, David Waite <david@alkaline-solutions.com&g=
t; wrote:













On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aaron@parecki.com&=
gt; wrote:



On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier

<dbaier@l=
eastprivilege.com> wrote:





<snip>






I would rather say that ANY JS app should use CSP=
 to lock down the browser features to a minimal attack surface. In addition=
, if refresh or access tokens are involved - further settings like disablin=
g inline scripting (unsafe
 inline) and eval should be disabled.





I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching

unless backed up by a specific threat it's protecting against. Did you<=
br>
have a particular threat in mind?





I would say that browser applications should take measures to harden their =
applications again code injection and arbitrary code execution. Examples in=
clude eliminating inline script (and limiting embeddable objects as much as=
 possible) via CSP, and versioning
 third party resources via techniques like subresource integrity.=C2=A0 Mec=
hanisms such as augmenting the codebase to make sure all appropriate user i=
nput, data storage, and output properly sanitize data may be used - althoug=
h they may be more expensive to implement
 and audit.



The AS should likewise take into account an application=E2=80=99s overall s=
ecurity posture when deciding appropriate policies around delegated authori=
zation scopes and token lifetimes.



Best current practices include turning the screws tightly around CSP. But i=
t is (theoretically) possible to accomplish the same with brute-force sanit=
ization, which has been made simpler with framework support. It is still ul=
timately the AS job to decide which
 clients have which capabilities.



-DW

_______________________________________________

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




--000000000000699798058e860f9d--


From nobody Thu Jul 25 12:04: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 5D2BE12022C for ; Thu, 25 Jul 2019 12:04:09 -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 EHbiV7dxAXNX for ; Thu, 25 Jul 2019 12:04:07 -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 E4590120248 for ; Thu, 25 Jul 2019 12:04:06 -0700 (PDT)
Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqj24-0002zE-DT; Thu, 25 Jul 2019 21:04:04 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-6FCA0155-0B48-43E5-864B-7CF910F102FD; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <1903519861.188545.1563954610968@mail.yahoo.com>
Date: Thu, 25 Jul 2019 21:04:04 +0200
Cc: Brian Campbell , David Waite , OAuth WG 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>  <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com> <1903519861.188545.1563954610968@mail.yahoo.com>
To: Tomek Stojecki 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 19:04:21 -0000

--Apple-Mail-6FCA0155-0B48-43E5-864B-7CF910F102FD
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 24.07.2019 um 09:50 schrieb Tomek Stojecki :
>=20
> I agree that 6.1 takes too broad of a swipe, but I'd say with same-site co=
okies and (sadly) without token-binding, the suggestion to use cookie based s=
ession following oauth/oidc auth is a good one and should be incorporated pe=
rhaps in 6.2?

Sure. Such mechanisms are also used in a backend based architecture for OAut=
h, just as a complement and not an alternative to OAuth

>=20
> Leo sums it up well here:
>> We need to be clear on the distinction between browser based apps that ho=
ld the token(s) in the browser space, vs. those that don't.  I agree that wi=
th this "common domain" architecture, the tokens should not be held in the b=
rowser, but it doesn't follow that oauth should not be used at all. =20
>=20
> Finally and sorry if this is off-topic, why isn't this discussion taking p=
lace in github? Aaron has uploaded the document there. This medium, while go=
od for some things, seems to have a lot of shortcomings for this sort of dis=
cussion and review.=20

Well, since this is IETF ;-)

>=20
> Thanks,
> Tomek
>=20
>=20
> On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite  wrote:=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On Jul 23, 2019, at 12:47 PM, Brian Campbell  wrote:
>>=20
>>=20
>>=20
>>> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt  wrote:
>>>=20
>>> 2) Regarding architectures: I think this BCP should focus on recommendat=
ions for securely implementing OAuth in the different potential architecture=
. I don=E2=80=99t think we should get into the business of recommending and a=
ssessing other solutions (e.g. section 6.1.). Just to give you an example: S=
ection 6.1. states=20
>>>=20
>>> "OAuth and OpenID Connect provide very little benefit in this deployment=
 scenario, so it is recommended to reconsider whether you need OAuth or Open=
ID Connect at all in this case.=E2=80=9D
>>>=20
>>> Really? What experiences is this statement based on? In my experience, s=
haring the same domain =3D=3D host name tells you nothing about the overall a=
rchitecture of a certain deployment. There may be several reasons why OAuth c=
ould be good choice in such a scenario, e.g. security considerations (since y=
our common domain is just a proxy server encapsulating a whole universe of s=
ystems) or even modularity as an architecture principle.=20
>>>=20
>>> I suggest to remove section c. and to rephrase the second paragraph of t=
he abstract.
>>=20
>> I believe the experiences that the statement is based on are the predomin=
ant practice over the course of much of the history of the web of using a co=
okie to maintain an authenticated HTTP session in web applications. When the=
 script of the browser-based application is served from a domain that can sh=
are cookies with the domain of the API, then cookies can still be used to au=
thorize requests (even if those requests are API calls rather than full page=
 HTTP request/response). And I do believe that's likely a better decision in=
 a lot of such cases.=20
>>=20
>> That authenticated HTTP session may be establish from a username/password=
 form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID=
 Connect flow. Or even SAML for that matter. But the the requests after that=
 are authorized by the cookie.=20
>>=20
>> I think there's a tendency to assume because SPA style apps make API call=
s, they simply must use OAuth. Because API implies OAuth in the minds of man=
y (which is a sign of its success). But OAuth isn't necessarily the only thi=
ng that can be used for API authorization. Cookies work too. I think/hope th=
at's what Section 6.1. is getting at - providing some potential guidance tha=
t OAuth might not necessarily be the right choice in those cases where a com=
mon domain allows for a cookie. Perhaps the text in that section could be ph=
ased in a different or better way, but I think its useful to have some menti=
on of in this document.=20
>>=20
>> Although taking out "and OpenID Connect" from the sentence quoted above m=
ight be more appropriate and alleviate some confusion.=20
>>=20
>>=20
>=20
> Perhaps it should be turned into a stated document assumption (that the re=
ader has decided to use OAuth) rather than guidance later in the document (t=
hat OAuth may not be the best fit)
>=20
> There is AFAIK no set of security considerations or best practices we can p=
oint to for =E2=80=9Cuse some non-standardized system for acquiring and usin=
g cookies=E2=80=9D or even =E2=80=9Chere=E2=80=99s a standard for acquiring a=
nd using cookies=E2=80=9D. Omitting some of the moving pieces of OAuth might=
 alleviate some security concerns, but also resurrect some other security is=
sues. The most immediate example that comes to mind: using a HttpOnly cookie=
-as-token instead of an access token may mean that you can=E2=80=99t have in=
jected scripts exfiltrate the token, but applying the access token was also a=
 mitigation against browser CSRF for your APIs.
>=20
> -DW
> _______________________________________________
> 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-6FCA0155-0B48-43E5-864B-7CF910F102FD
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
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzI1MTkwNDA0WjAvBgkqhkiG9w0BCQQxIgQg
eUrUviTaoTme22ruhBvsv5KW27g9L+EsRCltPpewKYUwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAFrCDUFTp9oUkhU/
QzzD0fHHSVwBSotjWllNK77vYKWTVKxN533Ub81iZsMYm/QyLuzTFMTbYz4CPKqLTD9sYnv+nY4e
RsAWiMRiSC8daXNdxl6B3KciIR1l+6k1RxWWmONI0MSZ2I+0vqzzdH50ippjbAS2nvkCsAlURXfD
NQw8A9SypdbsiVsp94wZMxB1oKVN3gzlaVJc2xlIm85W5RIrL8Er/C4tBSDkyh4m6IZjtodYNIIv
ahag0LFsU7QL6JNy3OroCL4FFLXuVw/+a8zuC/DZ/WBc6AgKBWrNq/v2n3anrWPtn+7iMFDNCtgT
naHx3/GUI+vAo9EZ17NEY9IAAAAAAAA=

--Apple-Mail-6FCA0155-0B48-43E5-864B-7CF910F102FD--


From nobody Thu Jul 25 12:37: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 529DE1201D0 for ; Thu, 25 Jul 2019 12:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level: 
X-Spam-Status: No, score=-1.987 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, T_KAM_HTML_FONT_INVALID=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=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 PQcggRzRwQiV for ; Thu, 25 Jul 2019 12:37:08 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B871201C6 for ; Thu, 25 Jul 2019 12:37:08 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r9so49121678ljg.5 for ; Thu, 25 Jul 2019 12:37:07 -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=nnRdXPz/TtHw00MPCRQZKqVLjcaESm77KrjADPGM/os=; b=NpBVRtrwmCnLz0lJu0GxtMUc+1/NR4r1Y+c8WOsPlX6nMl/XhpxnSNarijCTL+Osqk hzFof9atreQQifU9m4OXurT+Zwy6sopeG3kwajC6wJZf7ux3AbVqEjr4x5E4uWSdh6ci pOHVP2aTu7xHWwBKqa/Bnd8+XKWy5cLmQRpZ4IzDFr7wJyPCVTUMHbN+a5zVDBwlDtye fhR2Pe1AO1NTt7+ruHOFgVFdHbDpiTCwtsaYbE97OQQijAWdePVJPbOrD9XrfsDTvlXh Oh4CS3jxD+2F3DJH79QZieXO6zI9uSKlMeHpb3Vwuuyjro7Odam3e42Il6iruWqxxZwt i2SA==
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=nnRdXPz/TtHw00MPCRQZKqVLjcaESm77KrjADPGM/os=; b=NL0ignWFdOornMUAvS3xKsPTIyaqamkuoST1GnIDvINDzTT4zyaT06+oRQGpdJkdHB 3N8H33GeHhQ8Lp/gZsdBHTNy9OTnmUoF/m8yJMtMh0M92ed381fzF4P92BpMGCqRXEiE NTYp49bkBcg31p9aUN6LENpRy463kkbTmAlk5dUNMV7yYpIwXNR4lF9HtiRS8EC0vNjL LOdEWPKEupVujwVWvo7QLSFVqcCVcZVgGdPOGSdZ55MWDho2npnFtjYMCsQLLHy3piYR CZTWT5mu/ROqktYEiaCqT1R/FRDl+FZsvyIKQzkXIBlFjxqBuaez35aW0ngeTye3QArT 8VnQ==
X-Gm-Message-State: APjAAAVF0qspaiDV/ZFhvwSvCaQH4FHctx3pE3IlGXILkGNZlDbNWXqM qirHGSeIvVAhVuvdD080PFT0EOW72VTdjnGWkRUOnWma
X-Google-Smtp-Source: APXvYqwn4/tGNSAPdbYXMj2FzHkJufd5w6xuYGrBMc6O+3iwmZT21ETvqMgEWNdQxWkaZHe9E6runccMgh82F8hRCCo=
X-Received: by 2002:a2e:25a:: with SMTP id 87mr47753600ljc.183.1564083426122;  Thu, 25 Jul 2019 12:37:06 -0700 (PDT)
MIME-Version: 1.0
References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com>
In-Reply-To: <34add299-ae88-4c6f-a33c-82c147549516@yes.com>
From: Dick Hardt 
Date: Thu, 25 Jul 2019 12:36:53 -0700
Message-ID: 
To: Daniel Fett 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000360aa058e868d70"
Archived-At: 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 19:37:11 -0000

--0000000000000360aa058e868d70
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 to July / August. Nicer weather in the north then. =3D)

On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett  wrote:

> Hi all,
>
> it seems like there is a rough consensus on having the next OAuth Securit=
y
> Workshop in Trondheim, Norway. We will therefore start with the planning.
>
> After checking various event calendars it seems like the following dates
> are suitable:
>
>
>    * - May 7-9 - July 22-24 - August 3-5 *
>
>
>
> * First date is before EIC =E2=80=9820 which is May 12-15 in Munich/Germa=
ny. The
> latter two dates are before/after IETF 108 which is July 25-31,
> Madrid/Spain. Unless somebody raises objections because of conflicting
> identity/security events we will pick one of these dates in the next two
> weeks or so. -Daniel *
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1 to July / August. Nicer weather in the north then. =3D)=


On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote:

 =20

   =20
 =20
  

    
Hi all,

    
it seems like there is a rough consensus on having the next OAuth
      Security Workshop in Trondheim, Norway. We will therefore start
      with the planning.

    
After checking various event calendars it seems like the
      following dates are suitable:

    

        
    
          
  • May 7-9
    • 
          
  • July 22-24
    • 
          
  • August 3-5
    • 
        

      
        
First date is before EIC =E2=80=9820 which is May 12-15 in
          Munich/Germany. The latter two dates are before/after IETF 108
          which is July 25-31, Madrid/Spain.

        
Unless somebody raises objections because of conflicting
          identity/security events we will pick one of these dates in
          the next two weeks or so.

        

        
-Daniel

        

      

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000000360aa058e868d70--


From nobody Thu Jul 25 13:08: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 0DCBF1201DB for ; Thu, 25 Jul 2019 13:08: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH1Tl8CV1YGp for ; Thu, 25 Jul 2019 13:08:34 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2D91201EF for ; Thu, 25 Jul 2019 13:08:34 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id g20so99888060ioc.12 for ; Thu, 25 Jul 2019 13:08:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eUU9SSSL4SpsIt/53P8hqGicl4Czyya+mvUBZx/nYPw=; b=i3474G3BLlUOV9g8qRNIUdl9HyoHbX/xjVtUILiPvwqRgDikQ/robKraz/i4E+i1xT 1UpDUHTLR4fA9wd85kN0yPPjptq0O6+GuqArer+q3TqgbCCo6c7wcVi48SxPKgpFKqFv RkpUb3cKbbR8x5wJgN2CHY7gSzfV2x/B4PsIi8kndkRHV73DR+1um5mZI9oFfuOYfh4M ZPtTfsRNW3j5ePxfJ8N+RQlUoVdz43lTEoOLC+T9P7/KlKPT5rlq6b9PT7byuuiQyYE1 L3BCSyfr7HY8aMknqpIRWm/DpEifWLCHJY0WcVl/CztOUOcbSLSWy1lRxJuj5XEkA1cx Yhnw==
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=eUU9SSSL4SpsIt/53P8hqGicl4Czyya+mvUBZx/nYPw=; b=ZjpIGnRc3kh9u9hW3kmEeCP7gHUf1E9qDucCGBe5YFNGRwAin+rpgRpURrqTGBsxcO GBXu69agm1PmUs6pSfbUaEYk9WKxtXHkO309rFEeJvZ16xjoQXcO+FLTDbOGKvNFmBI7 0Qwo0YkMa/vEiIwphmjOwV3Ch8HG+ueS3ZT9dFFvnKsnqtx8BsbkuMo0nkqw0nMdCYG6 HhCij6+QG7ole4HxrStTuNCtgqNRuYcnaxAQizXZPG2va9dR6Cb8YQM5yRv4kzoZlGXk 4Crxqqm+BPVPgY4cEck3BWufXcFqGGkmEidwlLVIjPrQL8+FM+1nkzqO7RUa0df5p1Yv zf7A==
X-Gm-Message-State: APjAAAX7BcsYoNtcIXw6OuskGUcjnQY2nF3ShaauxteEsHA1wzbDzsdU QoAZJlE2ak71MMlGiN7/V6Xis0xzxbfCVw==
X-Google-Smtp-Source: APXvYqxYMBv3K/cPfrWQ41lVICJ2sHtHx7ou99IpyW+Zu/qFQhcNiIQuvuZ95YMOizAfXLBDkwlZmQ==
X-Received: by 2002:a5e:990a:: with SMTP id t10mr77107085ioj.182.1564085313166;  Thu, 25 Jul 2019 13:08:33 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id n17sm40694584iog.63.2019.07.25.13.08.32 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 13:08:32 -0700 (PDT)
Received: by mail-io1-f41.google.com with SMTP id s7so99792536iob.11 for ; Thu, 25 Jul 2019 13:08:32 -0700 (PDT)
X-Received: by 2002:a02:29ce:: with SMTP id p197mr31599794jap.139.1564085312420;  Thu, 25 Jul 2019 13:08:32 -0700 (PDT)
MIME-Version: 1.0
References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com> 
In-Reply-To: 
From: Aaron Parecki 
Date: Thu, 25 Jul 2019 16:07:17 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dick Hardt 
Cc: Daniel Fett , OAuth WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 20:08:36 -0000

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

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

On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt  wrote:
>
> +1 to July / August. Nicer weather in the north then. =3D)
>
> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett  wrot=
e:
>>
>> Hi all,
>>
>> it seems like there is a rough consensus on having the next OAuth Securi=
ty Workshop in Trondheim, Norway. We will therefore start with the planning=
.
>>
>> After checking various event calendars it seems like the following dates=
 are suitable:
>>
>> May 7-9
>>
>> July 22-24
>>
>> August 3-5
>>
>> First date is before EIC =E2=80=9820 which is May 12-15 in Munich/German=
y. The latter two dates are before/after IETF 108 which is July 25-31, Madr=
id/Spain.
>>
>> Unless somebody raises objections because of conflicting identity/securi=
ty events we will pick one of these dates in the next two weeks or so.
>>
>> -Daniel
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Jul 25 13:14: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 4753E1201E3 for ; Thu, 25 Jul 2019 13:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwOesm0v92q8 for ; Thu, 25 Jul 2019 13:14:11 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650096.outbound.protection.outlook.com [40.107.65.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7DE1201DB for ; Thu, 25 Jul 2019 13:14:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OSd455FarAkDMvxcs/iaJC8vT8j2g4GSyg2Op9d2518I7GXcEl0GNns5C2nw0rS5EcFnb0kDYXe/56PpYyjEwkerVzHYy5L8HHHVugsJQyDo6RIS04SKwdoKkp7PVEPoZMbDfbMOoVyQmYY54nC/q7lLyRs+PjIo5ba8oiOQl774GjOgHIcdYrzgr9xEkI0GVhYZzZTsfjwBnlEnxzCLnt18gHVK/7Y0tqCJSR0Hpo2jyZIjPPUYFfezMxxF+moSqhb7gTvSaAYeexcafL6fZnhavRpP9YPYSOtdzKkbxh8G9YOOPisxLCD4F6cpfP0CwZOTy6S6xt54OBa9UCR1uQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BNTxY0j60sXri5iXleYhxd0kTTBX4XXMBNS5a1b2uFc=; b=BcsWPPtlt0dYcEmrLG90Ezom5bJHnWOMauma29CyB0j2sVQzraMSHlz9t5WdLTif4tB0w06xe30ATFG+YIHahA8PedtH28iqXeZuhozg1sEZInU0NGHo66z+Zp5vBdzElLqWKN6qYPwOH8jTt2eYsTjXe3CmLKhGOkTTuT4+vOpJAhNxOZ9QJxfWMCPqQ5GrqrlkwPKDiJXWZZVqDkjndivegGf3X9jScubsrN1ZvJpiH6mHmAGTu1Eb/Fz9W5BTrlagQJVGisRtiMh5T9Unule+lzlwO98DfwBRXLoMcGMgFnOg7zDiDffuOo93U9tSJxPrhHY+hHI7nU1XDImb3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BNTxY0j60sXri5iXleYhxd0kTTBX4XXMBNS5a1b2uFc=; b=ECaHU6/mZT/a2j6pNSNpicaddeX9DRzlffOnzmDmK81rT8E72lzy7xTCPCzAJov1C3F04GISssNC+bB4VapJydODR/yQHLbVbAaGZZIZAWthcInHz9wwU5KkrqNKhnb+o/JuCnRSz/1Gk08YaC5NByWM5Nkbv5KOTGOh0QOWQ3U=
Received: from DM6PR00MB0572.namprd00.prod.outlook.com (20.179.51.15) by DM6PR00MB0634.namprd00.prod.outlook.com (20.179.49.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2154.0; Thu, 25 Jul 2019 20:14:08 +0000
Received: from DM6PR00MB0572.namprd00.prod.outlook.com ([fe80::dc6c:d9d5:4ce9:2abc]) by DM6PR00MB0572.namprd00.prod.outlook.com ([fe80::dc6c:d9d5:4ce9:2abc%6]) with mapi id 15.20.2156.000; Thu, 25 Jul 2019 20:14:08 +0000
From: Mike Jones 
To: Aaron Parecki , Dick Hardt , Daniel Fett 
CC: OAuth WG 
Thread-Topic: [OAUTH-WG] Location and dates for next OAuth Security Workshop
Thread-Index: AQHVQxqshJj3poXQ7kyrl2GRFBbzo6bbummAgAAIf4CAAAGnMA==
Date: Thu, 25 Jul 2019 20:14:07 +0000
Message-ID: 
References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7e70e117-cbb0-4e58-8604-0000b5c7b680; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-25T20:13:12Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [31.133.158.62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e424d443-1fb5-4cc2-2877-08d7113ca662
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:DM6PR00MB0634; 
x-ms-traffictypediagnostic: DM6PR00MB0634:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:1751;
x-forefront-prvs: 0109D382B0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(366004)(136003)(396003)(376002)(346002)(13464003)(53754006)(199004)(189003)(76116006)(2906002)(53936002)(6436002)(66066001)(55016002)(15650500001)(478600001)(6506007)(86362001)(966005)(229853002)(4326008)(5660300002)(6306002)(26005)(11346002)(52536014)(25786009)(102836004)(64756008)(53546011)(10290500003)(14454004)(9686003)(66556008)(7736002)(66476007)(66946007)(66446008)(186003)(99286004)(14444005)(33656002)(7696005)(76176011)(110136005)(316002)(3846002)(8990500004)(10090500001)(22452003)(81166006)(81156014)(486006)(68736007)(8676002)(8936002)(446003)(256004)(71190400001)(71200400001)(476003)(6116002)(6246003)(305945005)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0634; H:DM6PR00MB0572.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wLZ/2jr22G6F4DHgjYL6vSD8QS5j32mMhwpSxo8r69j78n+VcMfV6SDvu5IuSdLI4n9LaeWtOIYoxIh3BFlbdT8/pj5UzhUvlN1WTTTfSMptjzHM3LZ1JjUSJMLQhE3/Kd7aJgoPWbMfhEULEtfCpaL5OwWE/v3tVOhHRjAtB5Zaby8oZuJb05GAXD6Vq9KErR3KvhUaKfv9JEFf/nrstcKzPAUgWW5b5CHC1Y5UeZML2s+k2nW5Ab7CIZ4wzl/OnKNM+jnxTybwuksrCq6UPfwWFTnYaUXv4bCAkqPdIr52Nq5sTGFHHJQUC8ZoQV89tJmGMFYDtxpAMWwEvviMRoo9PFNQt8W1M0hsJFH4wCGYf1FmiWke7C5CJrgDinvmY3cWQv6EgtMA9fBlUzYGvlpih685VGG6AvffiWYF724=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e424d443-1fb5-4cc2-2877-08d7113ca662
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 20:14:08.0343 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0yS5Q4r8RdR3XoGbWMihjk9tCJfdz/EPUOLc1tBYbSLLPjU2Gh/N2X78GGup8iNgCYguw5lcosyrvCQ8hAKu9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0634
Archived-At: 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 20:14:13 -0000

SSdtIG5vdCBhd2FyZSBvZiBhbnkgY29uZmxpY3RzIGZvciBhbnkgb2YgdGhlIHRocmVlIHNldHMg
b2YgZGF0ZXMuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFhcm9uIFBh
cmVja2kNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI1LCAyMDE5IDQ6MDcgUE0NClRvOiBEaWNrIEhh
cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkNjOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBMb2NhdGlvbiBhbmQgZGF0ZXMgZm9yIG5leHQgT0F1
dGggU2VjdXJpdHkgV29ya3Nob3ANCg0KV2UnbGwgYmUgc28gcHJvZHVjdGl2ZSB3aXRoIG9ubHkg
NCBob3VycyBvZiBkYXJrbmVzcyBldmVyeSBkYXkhDQoNCkFsbCBvZiB0aGUgZGF0ZXMgd29yayBm
b3IgbWUsIGJ1dCBJIHdvdWxkIHByZWZlciB0aGUgSnVseSBkYXRlcyBzaW5jZSBpdCdsbCBiZSBl
YXNpZXIvY2hlYXBlciB0byBidW5kbGUgdGhlIHR3byB0cmlwcyBpbnRvIG9uZS4gKEhvcGVmdWxs
eSB3ZSBjb3VsZCBnZXQgdGhlIE9BdXRoIG1lZXRpbmcgZGF0ZXMgZWFybHkgaW4gdGhlIHdlZWsg
YXQgSUVURiB0aGVuKQ0KDQpPbiBUaHUsIEp1bCAyNSwgMjAxOSBhdCAzOjM3IFBNIERpY2sgSGFy
ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiB3cm90ZToNCj4NCj4gKzEgdG8gSnVseSAvIEF1Z3Vz
dC4gTmljZXIgd2VhdGhlciBpbiB0aGUgbm9ydGggdGhlbi4gPSkNCj4NCj4gT24gVGh1LCBKdWwg
MjUsIDIwMTkgYXQgMTE6NTYgQU0gRGFuaWVsIEZldHQgPGRhbmllbGYrb2F1dGhAeWVzLmNvbT4g
d3JvdGU6DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IGl0IHNlZW1zIGxpa2UgdGhlcmUgaXMgYSBy
b3VnaCBjb25zZW5zdXMgb24gaGF2aW5nIHRoZSBuZXh0IE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9w
IGluIFRyb25kaGVpbSwgTm9yd2F5LiBXZSB3aWxsIHRoZXJlZm9yZSBzdGFydCB3aXRoIHRoZSBw
bGFubmluZy4NCj4+DQo+PiBBZnRlciBjaGVja2luZyB2YXJpb3VzIGV2ZW50IGNhbGVuZGFycyBp
dCBzZWVtcyBsaWtlIHRoZSBmb2xsb3dpbmcgZGF0ZXMgYXJlIHN1aXRhYmxlOg0KPj4NCj4+IE1h
eSA3LTkNCj4+DQo+PiBKdWx5IDIyLTI0DQo+Pg0KPj4gQXVndXN0IDMtNQ0KPj4NCj4+IEZpcnN0
IGRhdGUgaXMgYmVmb3JlIEVJQyDigJgyMCB3aGljaCBpcyBNYXkgMTItMTUgaW4gTXVuaWNoL0dl
cm1hbnkuIFRoZSBsYXR0ZXIgdHdvIGRhdGVzIGFyZSBiZWZvcmUvYWZ0ZXIgSUVURiAxMDggd2hp
Y2ggaXMgSnVseSAyNS0zMSwgTWFkcmlkL1NwYWluLg0KPj4NCj4+IFVubGVzcyBzb21lYm9keSBy
YWlzZXMgb2JqZWN0aW9ucyBiZWNhdXNlIG9mIGNvbmZsaWN0aW5nIGlkZW50aXR5L3NlY3VyaXR5
IGV2ZW50cyB3ZSB3aWxsIHBpY2sgb25lIG9mIHRoZXNlIGRhdGVzIGluIHRoZSBuZXh0IHR3byB3
ZWVrcyBvciBzby4NCj4+DQo+PiAtRGFuaWVsDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1
dGhAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dw0KPj4gLmlldGYub3JnJTJGbWFpbG1hbiUyRmxp
c3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuSm9uDQo+PiBlcyU0MG1p
Y3Jvc29mdC5jb20lN0M0YzAxMDFiYzFlZGM0MDNkN2IwZTA4ZDcxMTNiZTc3ZiU3QzcyZjk4OGJm
ODZmMTQNCj4+IDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk5NjgyMTMwNTIwNzk3
NSZhbXA7c2RhdGE9ZEFva1dZeHdHVw0KPj4gU1JYeXJ6czRWJTJCV01YY01ENDgybmh5QVJ0Mjht
ZTR4YkUlM0QmYW1wO3Jlc2VydmVkPTANCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYu
b3JnDQo+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwcyUzQSUyRiUyRnd3dy4NCj4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZv
YXV0aCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5Kb25lcw0KPiAlNDBtaWNyb3NvZnQuY29t
JTdDNGMwMTAxYmMxZWRjNDAzZDdiMGUwOGQ3MTEzYmU3N2YlN0M3MmY5ODhiZjg2ZjE0MWFmDQo+
IDkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk5NjgyMTMwNTIwNzk3NSZhbXA7c2RhdGE9
ZEFva1dZeHdHV1NSWHkNCj4gcnpzNFYlMkJXTVhjTUQ0ODJuaHlBUnQyOG1lNHhiRSUzRCZhbXA7
cmVzZXJ2ZWQ9MA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0wNi5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll
dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q01p
Y2hhZWwuSm9uZXMlNDBtaWNyb3NvZnQuY29tJTdDNGMwMTAxYmMxZWRjNDAzZDdiMGUwOGQ3MTEz
YmU3N2YlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTk2
ODIxMzA1MjA3OTc1JmFtcDtzZGF0YT1kQW9rV1l4d0dXU1JYeXJ6czRWJTJCV01YY01ENDgybmh5
QVJ0MjhtZTR4YkUlM0QmYW1wO3Jlc2VydmVkPTANCg==


From nobody Thu Jul 25 14:05:46 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 0DC40120294; Thu, 25 Jul 2019 14:05:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vincent Roca via Datatracker 
To: 
Cc: draft-ietf-oauth-mtls.all@ietf.org, ietf@ietf.org, oauth@ietf.org, vincent.roca@inria.fr
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Vincent Roca 
Message-ID: <156408873192.17277.1716403359777916336@ietfa.amsl.com>
Date: Thu, 25 Jul 2019 14:05:32 -0700
Archived-At: 
Subject: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-mtls-15
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, 25 Jul 2019 21:05:32 -0000

Reviewer: Vincent Roca
Review result: Ready

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: Ready

The Security considerations and privacy considerations sections both look sound 
to me. 

Nits: 
* section 7.1: s/to which they where issued/to which they were issued/

Cheers.  Vincent




From nobody Thu Jul 25 14:49:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E75120294 for ; Thu, 25 Jul 2019 14:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMGU6uxugBWT for ; Thu, 25 Jul 2019 14:49:12 -0700 (PDT)
Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.179.24]) (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 8525C120275 for ; Thu, 25 Jul 2019 14:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=bno8eyLyqoksZZYUKZ+Cbk6Xb66kGrz7kARNTjd0N58=;  b=uoHHyg2x/a/msJdHN1srSQwnB/0NU0twAniQgMm01AVFV8JcIgJRBuBGv+oGUgbMa9JdjxSWUfCdeU2jgVotZwphswol1DCI9r7Wn3unDjAwrCebipHKOB02EVKnAxAuR7LpD9+TzjJ+wPr3o6f+AHZ/Uu6GPBV4fpJMhguXcNY=;
Received: by smtp5.mail.ru with esmtpa (envelope-from ) id 1hqlbq-0007iH-2m for OAuth@ietf.org; Fri, 26 Jul 2019 00:49:10 +0300
To: oauth 
From: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Message-ID: <3755f0ec-b9b3-a120-3aa5-5b8df1960dec@mail.ru>
Date: Fri, 26 Jul 2019 00:49:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results: smtp5.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 2D1AD755E866B1545A78504BD2AC294173B0C787F0EA2BA1AA33339763D3D7CEEAB2277AF3C63A436E550BA2D929ED76
X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE74B8C64966C4792B6EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063741B82FC540CCF21E8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC242542CF178235601130166FD217AA53F706F8151E398A29389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0B4190103C7DF69538941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C39CFA8CFAC159CE19117882F4460429728AD0CFFFB425014E40A5AABA2AD371193AA81AA40904B5D9A18204E546F3947CA306138418B4807C6E0066C2D8992A164AD6D5ED66289B52BA9C0B312567BB2376E601842F6C81A127C277FBC8AE2E8B9C86BE0A37E1E378D81D268191BDAD3DC74AC4170110C6EC35872C767BF85DA227C277FBC8AE2E8BC081E1E1FE214849EE3FE5A67DB4735935872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9DE2850DD75B2526BE5BFE6E7EFDEDCD789D4C264860C145E
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D44BC19FFDAD63A5ABAA949C6FFB71676046D5F5DDF2E85CF7CA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: 
Subject: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 21:49:22 -0000

Dear all,

draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a 
JWS' signature (the client's key) 
(https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2).

However there no such guidance for JWE encryption:

* any "enc" key published by the AS on its jwks_uri?

* one specific key of the ones listed at the server's jwks_uri? If so, 
how to indicate which one in particular?

* out-of-band configuration?

And should it be part of the specification?

Regards,

-- 

Tangui


From nobody Thu Jul 25 15:44: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 ECAC7120226 for ; Thu, 25 Jul 2019 15:44:01 -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 9bkzm52RcHw0 for ; Thu, 25 Jul 2019 15:44:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463F01201D1 for ; Thu, 25 Jul 2019 15:44:00 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D4E11B82097; Thu, 25 Jul 2019 15:43:47 -0700 (PDT)
To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: martin@martinmay.net, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20190725224347.D4E11B82097@rfc-editor.org>
Date: Thu, 25 Jul 2019 15:43:47 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5793)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 25 Jul 2019 22:44:02 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

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

--------------------------------------
Type: Technical
Reported by: Martin May 

Section: 2.3.1

Original Text
-------------
   Alternatively, the authorization server MAY support including the
   client credentials in the request-body using the following
   parameters:

Corrected Text
--------------
   In addition to that, the authorization server MAY support including
   the client credentials in the request-body using the following
   parameters:

Notes
-----
Given that the authorization MUST support the HTTP Basic authentication scheme in the paragraphs just before this one, using the word "alternatively" here can be understood as "instead of", which is not the intention and can lead to confusion for implementors.

This intention is further highlighted by the use of the word MAY in the paragraph above.

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


From nobody Thu Jul 25 15:54: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 8E28C120226 for ; Thu, 25 Jul 2019 15:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 fKpcETckWoZD for ; Thu, 25 Jul 2019 15:54:14 -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 B7D9D1201D1 for ; Thu, 25 Jul 2019 15:54:13 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x6PMsd0t023286 for ; Thu, 25 Jul 2019 18:54:46 -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; Thu, 25 Jul 2019 18:53:21 -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; Thu, 25 Jul 2019 18:54:01 -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; Thu, 25 Jul 2019 18:54:01 -0400
From: Justin Richer 
To: OAuth WG 
Thread-Topic: [OAUTH-WG] IETF Meetup for XYZ
Thread-Index: AQHVQnlK5M8xZz/tc0eNTyjM8LiwL6bcNc0A
Date: Thu, 25 Jul 2019 22:54:01 +0000
Message-ID: <60E9130D-C027-475D-A0A6-8FB37B0A711B@mit.edu>
References: <17577284-59F6-42E6-B226-9A6DF3E7DE23@mit.edu>
In-Reply-To: <17577284-59F6-42E6-B226-9A6DF3E7DE23@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: [31.133.130.172]
Content-Type: multipart/alternative; boundary="_000_60E9130DC027475DA0A68FB37B0A711Bmitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] IETF Meetup for XYZ
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 22:54:16 -0000

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

RldJVzogV2UgYXJlIG1lZXRpbmcgaW4gdGhlIG1haW4gbG9iYnkgb3V0c2lkZSBvZiBDZW50cmUt
VmlsbGUuDQoNCuKAlCBKdXN0aW4NCg0KT24gSnVsIDI0LCAyMDE5LCBhdCA3OjQxIFBNLCBKdXN0
aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3Rl
Og0KDQpIaSBhbGwsDQoNCkkgd2FzIHRhbGtpbmcgd2l0aCBIYW5uZXMsIGFuZCB3ZeKAmWQgbGlr
ZSB0byBwcm9wb3NlIGEgZGlubmVyIG1lZXR1cCB0b21vcnJvdyAoVGh1cnNkYXkpIGZvciBhbnlv
bmUgd2hvIHdhbnRzIHRvIGRpc2N1c3MgWFlaIGluIG1vcmUgZGV0YWlsIHdoaWxlIHdl4oCZcmUg
aGVyZSBpbiBNb250cmVhbC4gV2XigJlsbCBtZWV0IHJpZ2h0IGFmdGVyIHRoZSBBQ0Ugd29ya2lu
ZyBncm91cCBzZXNzaW9uIGFuZCBmaW5kIGEgcGxhY2UgbmVhcmJ5LCBzbyB0aGF0IHNvbWUgb2Yg
dXMgY2FuIGdldCBiYWNrIGluIHRpbWUgZm9yIHRoZSBsaWdodG5pbmcgdGFsa3MgaW4gdGhlIGV2
ZW5pbmcuDQoNCklmIHlvdeKAmXJlIGludGVyZXN0ZWQsIGVpdGhlciBjb21lIGZpbmQgdXMgdG9t
b3Jyb3cgb3IgbGV0IHVzIGtub3cgc29tZSBvdGhlciB3YXkuDQrigJQgSnVzdGluDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZXSVc6IFdlIGFyZSBtZWV0aW5nIGluIHRoZSBt
YWluIGxvYmJ5IG91dHNpZGUgb2YgQ2VudHJlLVZpbGxlLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw
LCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwgMjQsIDIwMTksIGF0IDc6NDEgUE0sIEp1
c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIGNsYXNzPSIi
PmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p
bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd2FzIHRhbGtpbmcgd2l0aCBIYW5uZXMs
IGFuZCB3ZeKAmWQgbGlrZSB0byBwcm9wb3NlIGEgZGlubmVyIG1lZXR1cCB0b21vcnJvdyAoVGh1
cnNkYXkpIGZvciBhbnlvbmUgd2hvIHdhbnRzIHRvIGRpc2N1c3MgWFlaIGluIG1vcmUgZGV0YWls
IHdoaWxlIHdl4oCZcmUgaGVyZSBpbiBNb250cmVhbC4gV2XigJlsbCBtZWV0IHJpZ2h0IGFmdGVy
IHRoZSBBQ0Ugd29ya2luZyBncm91cCBzZXNzaW9uIGFuZCBmaW5kIGEgcGxhY2UgbmVhcmJ5LA0K
IHNvIHRoYXQgc29tZSBvZiB1cyBjYW4gZ2V0IGJhY2sgaW4gdGltZSBmb3IgdGhlIGxpZ2h0bmlu
ZyB0YWxrcyBpbiB0aGUgZXZlbmluZy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHlvdeKAmXJlIGludGVyZXN0ZWQsIGVpdGhlciBj
b21lIGZpbmQgdXMgdG9tb3Jyb3cgb3IgbGV0IHVzIGtub3cgc29tZSBvdGhlciB3YXkuPGJyIGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv
bjogbm9uZTsiIGNsYXNzPSIiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGlldGYub3Jn
PC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_60E9130DC027475DA0A68FB37B0A711Bmitedu_--


From nobody Thu Jul 25 23: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 3CA621202B4 for ; Thu, 25 Jul 2019 23:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level: 
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 9mvAu-17fhru for ; Thu, 25 Jul 2019 23:30:28 -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 680FA1202AA for ; Thu, 25 Jul 2019 23:30:28 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id a15so51534314qtn.7 for ; Thu, 25 Jul 2019 23:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=fFbv1aUwlFMm/1yT8XlVo27Zlz0nUNGvkmYroLxTE9g=; b=iVojSSX4DZch68hkKM0lKncgzZJ3pxpqmR+bQ7xC+I+HK19pSCTZ1+g9k1TJyb1ogc 6ln8smvIArr+ekhg/5aerYTZBpMX0teY4bsvyinYzZKPbQv7JqU2+ygaiwsMMgPWkSuJ W/Tm79a9ufXNi/a3655bkLCuKruwQNmmS9ahz1dOBmBaZ7QSTel5NbW8v9RiOh6oMkU4 ojuk2Ar82y/KYYBM/W00gRpOB1wslCGg7zTwUpmMw71xvoNSIURdpb2NT00CbdEEJNX1 J+ViVXiIqVWUdYCPhtgPfvdxYExOP4a76qEYzSMri1vhkCTebOrRcstQFv+m6WtIF0CQ akgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=fFbv1aUwlFMm/1yT8XlVo27Zlz0nUNGvkmYroLxTE9g=; b=mvptCFFSIUQEjjwDoY6vHJbg2gvo+LZ3tv63cujNTK7l9IhR66Ne3veN+qvd9dFtLn ZnKWDzextCOdyr11gfVU5/Cz4+Vjv9VZpKSU6jBzs9IQfZmctjw35irT8OHNoVusBgZU NJIqToQIwzJbGzMsSzICuPveCb4YfrV8hhFRCQvAT6ujzi9ezq0LpMbasVRcvYfKStUc 0AXSmdpsK1Cn1uuR9vPkOdsEWldt6HyTWGXiQqxEIZ1awcLBlpLZw9t9IdSkLsfeZk8I zmx+/dZRYkcidxrEbTNGeu5Egh8b9Hnb4j4T3sdUQM3C7QCLPjjJh2JdRLwFHqlwtftr IGYw==
X-Gm-Message-State: APjAAAVl17jqBz65TfJ4o8KFalA6JkY7oUPp6Lu/9MTc/eWXmt1v6KE4 16vhFdc9QKY/tQttWIkzLwWYIeSlZb2y33HR0Q==
X-Google-Smtp-Source: APXvYqwfEnWNzt3w+bUDMKqO721ZuIPuTIkkxCLACh5nniCWkNoRiWcgh38hjKWLojHOhAKF5Zgvf6rdLsZCnFaT6ws=
X-Received: by 2002:ac8:152:: with SMTP id f18mr63309086qtg.84.1564122627368;  Thu, 25 Jul 2019 23:30:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jul 2019 23:30:26 -0700
From: Dominick Baier 
In-Reply-To: 
References: <34add299-ae88-4c6f-a33c-82c147549516@yes.com>   
MIME-Version: 1.0
Date: Thu, 25 Jul 2019 23:30:26 -0700
Message-ID: 
To: Aaron Parecki ,  Mike Jones ,  Dick Hardt , Daniel Fett 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="00000000000096fe0d058e8fad2e"
Archived-At: 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jul 2019 06:30:30 -0000

--00000000000096fe0d058e8fad2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

August will conflict with holiday time for most Europeans=E2=80=A6

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

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

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

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

-- Mike

-----Original Message-----
From: OAuth  On Behalf Of Aaron Parecki
Sent: Thursday, July 25, 2019 4:07 PM
To: Dick Hardt 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

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

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CMichael.Jones%40mic=
rosoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd01=
1db47%7C1%7C0%7C636996821305207975&sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD=
482nhyARt28me4xbE%3D&reserved=3D0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

=

Augu=
st will conflict with holiday time for most Europeans=E2=80=A6

Just been to Trondheim last wee=
k - it was lovely weather.
 
 
=E2=80=
=94=E2=80=94=E2=80=94
Dominick
 
=
On 25. July 2019 at 22:14:28, Mike Jones (michael.jones=3D40microsoft.com@dmarc.ie=
tf.org) wrote:
 
<=
div>
I'm not aware of any conflicts for any of the three=
 sets of dates.



				-- Mike



-----Original Message-----

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

Sent: Thursday, July 25, 2019 4:07 PM

To: Dick Hardt <dick.hardt@g=
mail.com>

Cc: OAuth WG <oauth@ietf.org&g=
t;

Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security Work=
shop



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



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



On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt <dick.hardt@gmail.com> wrote:

>

> +1 to July / August. Nicer weather in the north then. =3D)

>

> On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett <danielf+oauth@yes.com> wrote:

>>

>> Hi all,

>>

>> it seems like there is a rough consensus on having the next OA=
uth Security Workshop in Trondheim, Norway. We will therefore start with th=
e planning.

>>

>> After checking various event calendars it seems like the follo=
wing dates are suitable:

>>

>> May 7-9

>>

>> July 22-24

>>

>> August 3-5

>>

>> First date is before EIC =E2=80=9820 which is May 12-15 in Mun=
ich/Germany. The latter two dates are before/after IETF 108 which is July 2=
5-31, Madrid/Spain.

>>

>> Unless somebody raises objections because of conflicting ident=
ity/security events we will pick one of these dates in the next two weeks o=
r so.

>>

>> -Daniel

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

>> https://nam06.safelinks.protection.outlook.com/?url=
=3Dhttps%3A%2F%2Fwww

>> .ietf.org%2Fmailman%2Flistinfo=
%2Foauth&amp;data=3D02%7C01%7CMichael.Jon

>> es%40microsoft.com%7C4c=
0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14

>> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=
=3DdAokWYxwGW

>> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://nam06.safelinks.protection.outlook.com/?url=3Dhtt=
ps%3A%2F%2Fwww.

> ietf.org%2Fmailman%2Flistinfo%2Foa=
uth&amp;data=3D02%7C01%7CMichael.Jones

> %40microsoft.com%7C4c0101bc=
1edc403d7b0e08d7113be77f%7C72f988bf86f141af

> 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&amp;sdata=3DdAok=
WYxwGWSRXy

> rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&amp;reserved=3D0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://n=
am06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fm=
ailman%2Flistinfo%2Foauth&amp;data=3D02%7C01%7CMichael.Jones%40microsof=
t.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47=
%7C1%7C0%7C636996821305207975&amp;sdata=3DdAokWYxwGWSRXyrzs4V%2BWMXcMD4=
82nhyARt28me4xbE%3D&amp;reserved=3D0

_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinf=
o/oauth


--00000000000096fe0d058e8fad2e--


From nobody Fri Jul 26 03:59: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 6A5E21202E8 for ; Fri, 26 Jul 2019 03:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yXmfRN4stoV for ; Fri, 26 Jul 2019 03:59:04 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE1112024F for ; Fri, 26 Jul 2019 03:59:04 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id j11so30648230otp.10 for ; Fri, 26 Jul 2019 03:59:04 -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=7I23CNQxCkYLgDr2oLUYi+BIikNGGvkS5jsbnQyienA=; b=d1Byq3W0woJ7pHh7lVqK9L38CyQRwBKxUPsAgZBCRcah7emAtmZS5vISgV823rlepN VDixDvddviktglZK51GFpg88ZgZnbln9Z09iGA/ihV9svJmGfgWR7zSyHNih0Tvwwvos O+srl4bORE2Y99tru5W1gYWPb7a9xhcGpgcxiH3gpTh7DRSxNf0qNgtnNkVqO7dHIvgA ukiEO3x+wmPUjyDFgmyC5mOJm+YJvQmNsxVyF4I71uvAmg8teualsogJ9UISxH7sqYTv wSCeh41A7K3XA3LnVW2aWxlsA+Xg13XML8Ydb7kQ9NzdbY4Rb38XnczIFcFvwrTZ1IPd G4iQ==
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=7I23CNQxCkYLgDr2oLUYi+BIikNGGvkS5jsbnQyienA=; b=ckQV43a5CXhIX86yEgI1/qMiY6cwoE25v5aArIXCe5s+nhZa0r3yjrKCL20hm8KooM 8BzKYxEzYhOwbPF39kFI0/8cO8OOYLUdYBSyppzUpuKmplTDsTtkTYGNOuGBPiyWnkZF xVw5s9yt/T6zDqXcITlHcA6/jP6SemUIPG2hXW6ZuUciUG4UP9f0wcdiWOoJV6M6gESP TtslGzR737hv5ZagWkI7EUnoBECJaSq/FrSfS3G5W1M8eEthxFCMagTO+wcriQ3vFpAl dI3exsUd0wgVH6ZvSNK+Tqe8xVKOsArh5wMLa4LyC27mmkjdyJ8HbutA4G1h4MOKQyxI WG0Q==
X-Gm-Message-State: APjAAAVYuEALPHFfRIXG4OGF/pyFjkGRJziIxMFlNWLWVcUl55232Hhe EXkfNtt7Qo0Z9B7+ey5mcg6nuJpGAG8PlIt2xg==
X-Google-Smtp-Source: APXvYqybd2YsuJxB73VpcRY6SScmd6uIPsLQaja5Bypn3C/aL/Osn+saBTB2+Dq3MP3Y8upeJZZ9bR/+ZgGdVg5cydY=
X-Received: by 2002:a9d:2c26:: with SMTP id f35mr68056414otb.362.1564138743739;  Fri, 26 Jul 2019 03:59:03 -0700 (PDT)
MIME-Version: 1.0
References: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru>  <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
In-Reply-To: <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
From: Filip Skokan 
Date: Fri, 26 Jul 2019 12:58:52 +0200
Message-ID: 
To: Nat Sakimura , John Bradley 
Cc: oauth , =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Content-Type: multipart/alternative; boundary="000000000000333924058e936ed8"
Archived-At: 
Subject: Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 Jul 2019 10:59:08 -0000

--000000000000333924058e936ed8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

John, Nat,

Tangui raises a good point I have missed,

draft 14 of jwsreq (JAR) introduced this language

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


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


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


Nat, John, everyone - *does this mean a JAR compliant AS ignores everything
outside of the request object while OIDC Request Object one merges the two
with the ones in the request object being used over ones that are not?* The
OIDC language also includes sections which make sure that some required
arguments are still passed outside of the request with the same value to
make sure the request is "valid" OAuth 2.0 request, something which an
example in the JAR spec does not do. Not having this language means that
existing authorization request pipelines can't simply be extended with e.g.
a middleware, they need to branch their codepaths.

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

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 20:48, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =
=D0=9F=D0=B5=D0=BD=D1=81  wrote:

> Filip, thank you for your reply. Additional remarks inline.
>
> On 25.07.2019 21:14, Filip Skokan wrote:
> > See my reply inline.
> >
> > S pozdravem,
> > *Filip Skokan*
> >
> >
> > On Thu, 25 Jul 2019 at 19:57, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=
=B5 =D0=9F=D0=B5=D0=BD=D1=81
> >  > > wrote:
> >
> >     In
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, i=
t
> >     is stated that an error is to be returned when the object request i=
s
> >     invalid. These errors are "invalid_request_uri" and
> >     "invalid_request_object".
> >
> >     However, to which redirect URI redirect in the following cases:
> >     * the request object is invalid (eg. invalid signature), should we
> >     still
> >     use client_id/redirect_uri of the invalid request object?
> >
> >     * the request URI could not be reached
> >     * the request object is encrypted and cannot be decrypted (bad key)
> >
> >
> > FS: if the client_id & redirect_uri combination is valid (the uri is
> > valid for that client) - yes, its fine to use those (dtto state). this
> > applies to all three
>
> It doesn't apply to an encrypted object that cannot be decrypted.
>
> >
> >     Would it be acceptable to use the "client_id" and "redirect_uri"
> >     request
> >     query parameters in such a case? Although it contradicts the curren=
t
> >     specification which states that they shall not be used, and it woul=
d
> >     defeat confidentiality when using encryption.
> >
> >
> > FS: how would it defeat confidentiality?
> If you use a JWE in the first place, it's so that the parameters cannot
> be read on the wire.
> >
> >
> >     Another option is not redirecting and displaying the error message =
on
> >     the AS, like when the client_id is unknown for instance.
> >
> >
> > FS: also an acceptable outcome, one with no caveats
>
> Except degraded UI for the end user, if we assume that an error on the
> client side is easier to manage that a cryptic error on the AS with no
> link back to the client. Also, the client could have a retry strategy
> (it might just be that the request object at the request object URI is
> expired, due to network latency, etc.).
>
> So if my understanding is correct, it's up to the implementer to make a
> decision on this point? Couldn't it lead to incompatibility, divergent
> implementations?
>
> >
> >     Also I don't get the example in
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.=
2
> >     <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2>
> >     :
> >
> >     https://server.example.com/authorize?
> >             response_type=3Dcode%20id_token
> >             &client_id=3Ds6BhdRkqt3
> >             &request_uri=3Dhttps%3A%2F%2Ftfp.example.org
> >     %2Frequest.jwt
> >             %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
> >             &state=3Daf0ifjsldkj
> >
> >     in regards to the following statement in
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :
> >
> >         The client MAY send the parameters included in the request obje=
ct
> >         duplicated in the query parameters as well for the backward
> >         compatibility etc.  However, the authorization server
> >     supporting this
> >         specification MUST only use the parameters included in the
> request
> >         object.
> >
> >     My understanding is that "response_type", "client_id" and "state"
> >     will
> >     be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to
> >     add
> >     them to the example?
> >
> >
> > FS: they will only be ignored IF they are also part of the request
> > object so i believe its fine to have them part of this example.
>
> It's seems ambiguous to me when reading the specification.
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4 states
> that:
>
> A Request Object (Section 2.1  <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is
> used to provide authorization
>     request parameters for an OAuth 2.0 authorization request.  It MUST
>     contains all the OAuth 2.0 [RFC6749  <
> https://tools.ietf.org/html/rfc6749>] authorization request parameters
>     including extension parameters.
>
> So there'd be no such thing as "client_id" and "redirect_uri" as query
> parameters, and other parameters members of the request object in my
> interpretation.
>
> In OpenID Connect you can indeed have both, the request object's
> parameters having precedence over query parameters
> (https://openid.net/specs/openid-connect-core-1_0.html#RequestObject):
>
> When the request parameter is used, the OpenID Connect request parameter
> values contained in the JWT supersede those passed using the OAuth 2.0
> request syntax. However, parameters MAY also be passed using the OAuth
> 2.0 request syntax even when a Request Object is used; this would
> typically be done to enable a cached, pre-signed (and possibly
> pre-encrypted) Request Object value to be used containing the fixed
> request parameters, while parameters that can vary with each request,
> such as state and nonce, are passed as OAuth 2.0 parameters.
>
> What do you think?
>
> >
> >     Maybe I've missed something?
> >
> >     Regards,
> >
> >     --
> >     Tangui
> >
> >     _______________________________________________
> >     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
>

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


John, Nat,

=
Tangui raises a good point I have missed,

draft 14=
 of jwsreq (JAR) introduced this language

The client MAY send the parameters inc=
luded in the request object
	duplicated in the query parameters as well =
for the backward
	compatibility etc. =C2=A0However, the authorization=
 server supporting this
	specification MUST only use the parameters incl=
uded in the request
	object.=C2=A0

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

The client MAY send the parame=
ters included in the request object
	duplicated in the query parameters =
as well for the backward
	compatibility etc. =C2=A0However, the autho=
rization server supporting this
	specification MUST only use the paramet=
ers included in the request
	object.=C2=A0

Nat, John, everyone - does this mean a JAR compliant AS ignores e=
verything outside of the request object while OIDC Request Object one merge=
s the two with the ones in the request object being used over ones that are=
 not? The OIDC language also includes sections which make sure that som=
e required arguments are still passed outside of the request with the same =
value to make sure the request is "valid" OAuth 2.0 request, some=
thing which an example in the JAR spec does not do. Not having this languag=
e means that existing authorization request pipelines can't simply be e=
xtended with e.g. a middleware, they need to branch their codepaths.
<=
div>
Thank you for clarifying this in advance. I think if eit=
her the behaviour is the same as in OIDC or different this should be called=
 out in the language to avoid confusion, especially since this already exis=
ts in OIDC and likely isn't going to be read in isolation since its eve=
n called out to be already in place in OIDC.

S pozdravem,
Filip Skokan


On Thu, 25 Jul 2019 at =
20:48, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =D0=9F=D0=B5=D0=BD=D1=81=
 <tangui.lepense@mail.ru&g=
t; wrote:
Filip,=
 thank you for your reply. Additional remarks inline.



On 25.07.2019 21:14, Filip Skokan wrote:

> See my reply inline.

>

> S pozdravem,

> *Filip Skokan*

>

>

> On Thu, 25 Jul 2019 at 19:57, =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=
=B5 =D0=9F=D0=B5=D0=BD=D1=81 

> <tangui.lepense=3D40mail.ru@dmarc.ietf.org 

> <mailto:=
40mail.ru@dmarc.ietf..org>> wrote:

>

>=C2=A0 =C2=A0 =C2=A0In

>=C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it

>=C2=A0 =C2=A0 =C2=A0is stated that an error is to be returned when the =
object request is

>=C2=A0 =C2=A0 =C2=A0invalid. These errors are "invalid_request_uri=
" and

>=C2=A0 =C2=A0 =C2=A0"invalid_request_object".

>

>=C2=A0 =C2=A0 =C2=A0However, to which redirect URI redirect in the foll=
owing cases:

>=C2=A0 =C2=A0 =C2=A0* the request object is invalid (eg. invalid signat=
ure), should we

>=C2=A0 =C2=A0 =C2=A0still

>=C2=A0 =C2=A0 =C2=A0use client_id/redirect_uri of the invalid request o=
bject? 

>

>=C2=A0 =C2=A0 =C2=A0* the request URI could not be reached

>=C2=A0 =C2=A0 =C2=A0* the request object is encrypted and cannot be dec=
rypted (bad key)

>

>

> FS: if the client_id & redirect_uri combination is valid (the uri =
is 

> valid for that client) - yes, its fine to use those (dtto state). this=
 

> applies to all three



It doesn't apply to an encrypted object that cannot be decrypted.



>

>=C2=A0 =C2=A0 =C2=A0Would it be acceptable to use the "client_id&q=
uot; and "redirect_uri"

>=C2=A0 =C2=A0 =C2=A0request

>=C2=A0 =C2=A0 =C2=A0query parameters in such a case? Although it contra=
dicts the current

>=C2=A0 =C2=A0 =C2=A0specification which states that they shall not be u=
sed, and it would

>=C2=A0 =C2=A0 =C2=A0defeat confidentiality when using encryption.

>

>

> FS: how would it defeat confidentiality?

If you use a JWE in the first place, it's so that the parameters cannot=
 

be read on the wire.

>

>

>=C2=A0 =C2=A0 =C2=A0Another option is not redirecting and displaying th=
e error message on

>=C2=A0 =C2=A0 =C2=A0the AS, like when the client_id is unknown for inst=
ance.

>

>

> FS: also an acceptable outcome, one with no caveats



Except degraded UI for the end user, if we assume that an error on the 

client side is easier to manage that a cryptic error on the AS with no 

link back to the client. Also, the client could have a retry strategy 

(it might just be that the request object at the request object URI is 

expired, due to network latency, etc.).



So if my understanding is correct, it's up to the implementer to make a=
 

decision on this point? Couldn't it lead to incompatibility, divergent =


implementations?



>

>=C2=A0 =C2=A0 =C2=A0Also I don't get the example in

>=C2=A0 =C2=A0 =C2=A0https://=
tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2

>=C2=A0 =C2=A0 =C2=A0<htt=
ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2><=
br>
>=C2=A0 =C2=A0 =C2=A0:

>

>=C2=A0 =C2=A0 =C2=A0https://server.example.com/authorize=
?

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 response_type=3Dcode%20=
id_token

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 &client_id=3Ds6BhdR=
kqt3

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 &request_uri=3Dhttp=
s%3A%2F%2Ftfp.example.org

>=C2=A0 =C2=A0 =C2=A0<http://2Ftfp.example.org>%2Frequest.jwt
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 %23GkurKxf5T0Y-mnPFCHqW=
OMiZi4VS138cQO_V7PZHAdM

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 &state=3Daf0ifjsldk=
j

>

>=C2=A0 =C2=A0 =C2=A0in regards to the following statement in

>=C2=A0 =C2=A0 =C2=A0https://tool=
s.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :

>

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 The client MAY send the parameters in=
cluded in the request object

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 duplicated in the query parameters as=
 well for the backward

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 compatibility etc.=C2=A0 However, the=
 authorization server

>=C2=A0 =C2=A0 =C2=A0supporting this

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 specification MUST only use the param=
eters included in the request

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 object.

>

>=C2=A0 =C2=A0 =C2=A0My understanding is that "response_type",=
 "client_id" and "state"

>=C2=A0 =C2=A0 =C2=A0will

>=C2=A0 =C2=A0 =C2=A0be ignored by a JAR-compliant OAuth2 server. Isn=
9;t it confusing to

>=C2=A0 =C2=A0 =C2=A0add

>=C2=A0 =C2=A0 =C2=A0them to the example?

>

>

> FS: they will only be ignored IF they are also part of the request 
> object so i believe its fine to have them part of this example.



It's seems ambiguous to me when reading the specification. 

https://tools.ietf.org/html/draft-ie=
tf-oauth-jwsreq-19#section-4 states 

that:



A Request Object (Section 2.1=C2=A0 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is used to provide authorization

=C2=A0 =C2=A0 request parameters for an OAuth 2.0 authorization request.=C2=
=A0 It MUST

=C2=A0 =C2=A0 contains all the OAuth 2.0 [RFC6749=C2=A0 <https=
://tools.ietf.org/html/rfc6749>] authorization request parameters
=C2=A0 =C2=A0 including extension parameters.



So there'd be no such thing as "client_id" and "redirect=
_uri" as query 

parameters, and other parameters members of the request object in my 

interpretation.



In OpenID Connect you can indeed have both, the request object's 

parameters having precedence over query parameters 

(https://openid.net/specs/openid-=
connect-core-1_0.html#RequestObject):



When the request parameter is used, the OpenID Connect request parameter 
values contained in the JWT supersede those passed using the OAuth 2.0 

request syntax. However, parameters MAY also be passed using the OAuth 

2.0 request syntax even when a Request Object is used; this would 

typically be done to enable a cached, pre-signed (and possibly 

pre-encrypted) Request Object value to be used containing the fixed 

request parameters, while parameters that can vary with each request, 

such as state and nonce, are passed as OAuth 2.0 parameters.



What do you think?



>

>=C2=A0 =C2=A0 =C2=A0Maybe I've missed something?

>

>=C2=A0 =C2=A0 =C2=A0Regards,

>

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

>=C2=A0 =C2=A0 =C2=A0Tangui

>

>=C2=A0 =C2=A0 =C2=A0_______________________________________________

>=C2=A0 =C2=A0 =C2=A0OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>

>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list=
info/oauth

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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




--000000000000333924058e936ed8--


From nobody Fri Jul 26 05:01: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 70E1F120330 for ; Fri, 26 Jul 2019 05:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahm01UyhzZSM for ; Fri, 26 Jul 2019 05:01:50 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C38120325 for ; Fri, 26 Jul 2019 05:01:50 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s7so104100331iob.11 for ; Fri, 26 Jul 2019 05:01:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=46jQWD73clXvAYO3w5HEhlvUJXdMdzv8X2loZlnN2mE=; b=lImxDUJ5DEUpUjuIzpK1T2ASNLqBYyv25iECny+Ia1p3ryxU81tXGPX4eWaDKg6eQJ Z403TQP5zYFEQqs3qubefU4LLR1T6pc8UNv177tWFTpboT8zadPHIE1jzcqwpdqNFAMt kCqQqYKeA2TgX9QxezYWxZzxDJk2a7c+ilJF0=
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=46jQWD73clXvAYO3w5HEhlvUJXdMdzv8X2loZlnN2mE=; b=L/UEfQdzyDYDkO+8T11Z2C69r4sMAugT9o5tD3wYzs3Se1EsNZDxit2p8gnlGQ5aQR 2IT1ngZM3ut81V4NASWle7kOfitkU2LV/JzBp1+lgopQbPf9GK+eg5A8lSjwyV50yiqL ZcS/MvVkF5nekLK4FGTQCyL6lkUiTI0E9nOdFNMmh5P7fFd11LmnyU8gRt/8zUbZTTwy R+pwcoacDCkXWL/eXjuef77r2kN0cp5D/datwP4Z760TI1M1CwtqH+/pxf5FOcQC58fh 4909B8vrrniMyx5uWNiPRkA3WcIVyFhYObn8SYto/Jg/u3HVKT4efDDhCOU7mvJdYEGN ag2A==
X-Gm-Message-State: APjAAAUwhN0KqT3ylG64QTAtJHJSSOiSLKknfwPnmYSgQSTTVU60H71M CBCB744jSWxi7mjQxC91njk684Y3fg+qVF7rx0yFQjjOH8Kwrf8m98p8sSZru6kJYHunpfWcobO 5lKqhc6LBznn26amaC3+9sQ==
X-Google-Smtp-Source: APXvYqyjbmgzIr/jhmLQYsUllXd1ROXIWtS/ELA5KfQuNUpt1n3/gSwpspa/MImShHrB5aa9Nf+gxOrUtccWvObkGkU=
X-Received: by 2002:a5d:9b1a:: with SMTP id y26mr22216936ion.238.1564142509686;  Fri, 26 Jul 2019 05:01:49 -0700 (PDT)
MIME-Version: 1.0
References: <3755f0ec-b9b3-a120-3aa5-5b8df1960dec@mail.ru>
In-Reply-To: <3755f0ec-b9b3-a120-3aa5-5b8df1960dec@mail.ru>
From: Brian Campbell 
Date: Fri, 26 Jul 2019 06:01:23 -0600
Message-ID: 
To: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000ab1b0f058e944e69"
Archived-At: 
Subject: Re: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 Jul 2019 12:01:53 -0000

--000000000000ab1b0f058e944e69
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd say this one->* any "enc" key published by the AS on its jwks_uri?

On Thu, Jul 25, 2019 at 3:50 PM =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5=
 =D0=9F=D0=B5=D0=BD=D1=81  wrote:

> Dear all,
>
> draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a
> JWS' signature (the client's key)
> (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2).
>
> However there no such guidance for JWE encryption:
>
> * any "enc" key published by the AS on its jwks_uri?
>
> * one specific key of the ones listed at the server's jwks_uri? If so,
> how to indicate which one in particular?
>
> * out-of-band configuration?
>
> And should it be part of the specification?
>
> Regards,
>
> --
>
> Tangui
>
> _______________________________________________
> 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._

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


I'd say this one->* any "enc" key pu=
blished by the AS on its jwks_uri? 

On Thu, Jul 25, 2019 at 3:50 PM =
=D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =D0=9F=D0=B5=D0=BD=D1=81 <ta=
ngui.lepense=3D40mail.ru@dmarc.=
ietf.org> wrote:
Dear all,



draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a 

JWS' signature (the client's key) 

(https://tools.ietf.org/html/draft=
-ietf-oauth-jwsreq-19#section-6.2).



However there no such guidance for JWE encryption:



* any "enc" key published by the AS on its jwks_uri?



* one specific key of the ones listed at the server's jwks_uri? If so, =


how to indicate which one in particular?



* out-of-band configuration?



And should it be part of the specification?



Regards,



-- 



Tangui



_______________________________________________

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.
--000000000000ab1b0f058e944e69--


From nobody Fri Jul 26 05:07: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 DAB3E120338 for ; Fri, 26 Jul 2019 05:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcC8K_S5TUbJ for ; Fri, 26 Jul 2019 05:07:06 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC3012032A for ; Fri, 26 Jul 2019 05:07:06 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id g17so54196178wrr.5 for ; Fri, 26 Jul 2019 05:07:06 -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=5GkqxTYkwPgnfDxCe49e1A0Ky3GtjzXF0nMMDdsRO+Y=; b=bWfRMM8Cqfi3BeQAF+3RxIr91vv/yPBcOrAUo/mlQUQpyis+7W0AtiEuwH19sffRYw D7jlqJX4mhnM8/iLK1ZZVXtqiAm2/HiroMgKNCES8QQAwh0nCHkDQ22NrkeamgfzqTZ6 dpk7ag1KrWLicU4tx5jUA54lHLpPbVmdP/6GxYwrocRx6eQToxXLufLIL7Az01ItaDsg ungBeXiV50Yq0v21z3v07ljMdfnCINbIHmDoTsqvQEsw1Desi56Lr0DZYoB2kT19WGgy Vn+M3j4x84Kz7WR5s931M1BlA4caT0auT3ezZeRiFFSipMUb8LjeMQXIdAp8NN5B2Ec8 5U1Q==
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=5GkqxTYkwPgnfDxCe49e1A0Ky3GtjzXF0nMMDdsRO+Y=; b=OD6CbELJREK8CxV9Gji6Vkn9W+fSlJfgz72kPfRVVld1Y7CS8x6n6kxL9UtjBt7Lm7 gdJYNJ3B1O9vQw5LflCxryrTkSQIeCEpoWFzBHwKLeRJI11NhaGrB7fYOYrtq2vFlYc9 TBO8LGhwu3vwp4L1lXFjlrwWVnsyKGl9G5O8muZqBTG+RtPEVJklSBBEF7CO07E+RK5F VZXCAvQsHyuXAt4HkKvYeQpVdKgWk/6Pm3xwixMGuVkXkTUQHJTDrNjyXt6A1Ujk1xKQ q8K4L6AfYBmfJVbZDul2K0tgDZVzZuKPw1hbn3e299a/2eEXDDZQbpbMNoeKpf3GjRJc Je3g==
X-Gm-Message-State: APjAAAWvDFaMy2e8GDrwYgR4nk/fyhfLHEi8DQ5p64p+MF90HFeCjjXX AcdGbdgZzag0t5rEvMoQpO4ucX6Z0A==
X-Google-Smtp-Source: APXvYqy4kpj9nTLjXnCLE30stxLRJQoI3dRjZJ+N/z/cbEtJVDVuv9cHkR9kBuLZtop95GH9nBxmrw==
X-Received: by 2002:adf:fd08:: with SMTP id e8mr104946672wrr.147.1564142824850;  Fri, 26 Jul 2019 05:07:04 -0700 (PDT)
Received: from [100.108.13.68] (ip-37-188-156-185.eurotel.cz. [37.188.156.185]) by smtp.gmail.com with ESMTPSA id u13sm61916029wrq.62.2019.07.26.05.07.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2019 05:07:04 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-FAF19800-7CA4-4168-84B9-F431DBA147A4
Mime-Version: 1.0 (1.0)
From: Filip Skokan 
X-Mailer: iPhone Mail (16F203)
In-Reply-To: 
Date: Fri, 26 Jul 2019 14:07:02 +0200
Cc: =?utf-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <0CCE8B72-D140-4638-83B1-FB660D1D2239@gmail.com>
References: <3755f0ec-b9b3-a120-3aa5-5b8df1960dec@mail.ru> 
To: Brian Campbell 
Archived-At: 
Subject: Re: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 Jul 2019 12:07:09 -0000

--Apple-Mail-FAF19800-7CA4-4168-84B9-F431DBA147A4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Any use:enc, without =E2=80=9Cuse=E2=80=9D or =E2=80=9Ckey_ops=E2=80=9D or k=
eyops:encrypt/deriveKey that works with a supported algorithm, or one with t=
he JWA =E2=80=9Calg=E2=80=9D.=20

Odesl=C3=A1no z iPhonu

26. 7. 2019 v 14:01, Brian Campbell :

> I'd say this one->* any "enc" key published by the AS on its jwks_uri?
>=20
>> On Thu, Jul 25, 2019 at 3:50 PM =D0=A2=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5=
 =D0=9F=D0=B5=D0=BD=D1=81  wrote:=

>> Dear all,
>>=20
>> draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a=20=

>> JWS' signature (the client's key)=20
>> (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2).
>>=20
>> However there no such guidance for JWE encryption:
>>=20
>> * any "enc" key published by the AS on its jwks_uri?
>>=20
>> * one specific key of the ones listed at the server's jwks_uri? If so,=20=

>> how to indicate which one in particular?
>>=20
>> * out-of-band configuration?
>>=20
>> And should it be part of the specification?
>>=20
>> Regards,
>>=20
>> --=20
>>=20
>> Tangui
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
 material for the sole use of the intended recipient(s). Any review, use, di=
stribution or disclosure by others is strictly prohibited..  If you have rec=
eived this communication in error, please notify the sender immediately by e=
-mail and delete the message and any file attachments from your computer. Th=
ank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-FAF19800-7CA4-4168-84B9-F431DBA147A4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Any use:enc, without =E2=80=9Cuse=E2=80=9D o=
r =E2=80=9Ckey_ops=E2=80=9D or keyops:encrypt/deriveKey that works with a su=
pported algorithm, or one with the JWA =E2=80=9Calg=E2=80=9D. 

<=
div id=3D"AppleMailSignature" dir=3D"ltr">Odesl=C3=A1no z iPhonu
<=
div dir=3D"ltr">
26. 7. 2019 v 14:01, Brian Campbell <bcampbell=3D40pingiden=
tity.com@dmarc.ietf.org>:

I'd say this one->* any "enc" key publ=
ished by the AS on its jwks_uri? 

=

On Thu, Jul 25, 2019 at 3:50 PM =D0=A2=
=D0=B0=D0=BD=D0=B3=D0=B8 =D0=9B=D0=B5 =D0=9F=D0=B5=D0=BD=D1=81 <tangui.le=
pense=3D40mail.ru@dmarc.ietf.org=
> wrote:
De=
ar all,



draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a 

JWS' signature (the client's key) 

(https://tools.ietf.org/html/draft-i=
etf-oauth-jwsreq-19#section-6.2).



However there no such guidance for JWE encryption:



* any "enc" key published by the AS on its jwks_uri?



* one specific key of the ones listed at the server's jwks_uri? If so, 

how to indicate which one in particular?



* out-of-band configuration?



And should it be part of the specification?



Regards,



-- 



Tangui



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






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

--Apple-Mail-FAF19800-7CA4-4168-84B9-F431DBA147A4--


From nobody Fri Jul 26 06:09: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 26F2D12021D for ; Fri, 26 Jul 2019 06:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6ra2LkL-DAX for ; Fri, 26 Jul 2019 06:09:14 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EC01202B6 for ; Fri, 26 Jul 2019 06:09:12 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id z3so104702041iog.0 for ; Fri, 26 Jul 2019 06:09: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=1PhZzXFsZQpmmX4q3mSaPo1KxDBXdeVWVXpj+JZXZiM=; b=orWlnpflykPVnTyqRbQfxJbflglTqIXiqVlWTQuyAhf9HjvWEAGx+hoD+olzfPbcfE NtMkfbWOSeFYhJKsOIHfH1a4tpFXU5Y5PZQIyaYGN4vCt/R2Zl1kNLBRq11JHHr5T2Ky FoHPWFUme/WK6BA2zPcJFdPBzPkDj/Yujh+F8=
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=1PhZzXFsZQpmmX4q3mSaPo1KxDBXdeVWVXpj+JZXZiM=; b=aTZrbDr8NniZrRAsreSvjhBILkaI8ut5S1S+94lF44LR3p7P66TzG3E+VIpnDstCr/ i8m8rCUyv0qfM9P/I2iTN4/fjdFDpWC5+pm534KUJ9UUn+SjXF0YADJk1/BpvK4FVykr cm/x9iZlx0sbUdSEqzLeDJGXnPROmTONH1/1zzsd1F8rERo8BafkyneFYDUDs9e2ECVm hPZnWFMPkQJRWCXqZPrwHm/oyHF+Uq2XbuqhuD/bvwLwDbfkn8mHkTdi23v64DfI0dhT S9htNfs8YS8aU+0vTJce7+uW5OidOEnJkirPbc/K1egxyM01CNQqQSpwIt0kBc+KfMTp zOIw==
X-Gm-Message-State: APjAAAVTewNmdYC+r270ZFm7x+xYuGaS5vWZKAV69hf3sksKtTWsVRvi S5k8stXZ2v6OeXCHfcBqOti0ahbPmKYes1iKYbENHCdYwV5nBYHqN+4+TjNoxn7beEagNajJviE GIMaBD0q1pJCn9WtUnRE=
X-Google-Smtp-Source: APXvYqyRiSyJ27dIajD1RxLABV2nVEX1e0gsnVBPOESHDkusS0MUamgf45elBZdjk8sWmD0ndfwehCWgimWLEmDAAwc=
X-Received: by 2002:a5d:87c6:: with SMTP id q6mr18162536ios.115.1564146551473;  Fri, 26 Jul 2019 06:09:11 -0700 (PDT)
MIME-Version: 1.0
References: <156408873192.17277.1716403359777916336@ietfa.amsl.com>
In-Reply-To: <156408873192.17277.1716403359777916336@ietfa.amsl.com>
From: Brian Campbell 
Date: Fri, 26 Jul 2019 07:08:45 -0600
Message-ID: 
To: Vincent Roca 
Cc: secdir@ietf.org, draft-ietf-oauth-mtls.all@ietf.org, ietf@ietf.org,  oauth 
Content-Type: multipart/alternative; boundary="00000000000093e883058e953f53"
Archived-At: 
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-mtls-15
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 Jul 2019 13:09:15 -0000

--00000000000093e883058e953f53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Vincent, I've fixed the nit in the source controlled editor's xml
version and it'll show up in the next draft revision.

On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Vincent Roca
> Review result: Ready
>
> Hello,
>
> I have reviewed this document as part of the security directorate=E2=80=
=99s ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments ju=
st
> like any other last call comments.
>
> Summary: Ready
>
> The Security considerations and privacy considerations sections both look
> sound
> to me.
>
> Nits:
> * section 7.1: s/to which they where issued/to which they were issued/
>
> Cheers.  Vincent
>
>
>
>

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

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


Thanks Vincent, I've fixed the nit in the source contr=
olled editor's xml version and it'll show up in the next draft revi=
sion. 

On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker <=
noreply@ietf.org> wrote:
Reviewer: Vincent Roca<=
br>
Review result: Ready



Hello,



I have reviewed this document as part of the security directorate=E2=80=99s=
 ongoing

effort to review all IETF documents being processed by the IESG. These

comments were written primarily for the benefit of the security area

directors.=C2=A0 Document editors and WG chairs should treat these comments=
 just

like any other last call comments.



Summary: Ready



The Security considerations and privacy considerations sections both look s=
ound 

to me. 



Nits: 

* section 7.1: s/to which they where issued/to which they were issued/



Cheers.=C2=A0 Vincent












<=
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.
--00000000000093e883058e953f53--


From nobody Fri Jul 26 06:36:23 2019
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A47120019 for ; Fri, 26 Jul 2019 06:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=mail.ru
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJYEegrxjH7y for ; Fri, 26 Jul 2019 06:36:19 -0700 (PDT)
Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAF912000F for ; Fri, 26 Jul 2019 06:36:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=J+0Ek7ZIJe0hAPxXdxMipeU1qrzN1VT5qHQhZJD3+kU=;  b=J0H+lpdV+VYCJe3lCJJ74jb79Oi22HBqJGUj/xzl5EiuHOUBYrBvWg8/rx1BlhG1DCWXQfflz/F8XER34jas6cdSQrWb80vEKp3Kemq/qjdxPZUmJsEs6xsPk+mAUkg9VM0bpA9CF8lcvE9A2wfWy2YFnyjulAx04bFuyAe7biI=;
Received: by smtp47.i.mail.ru with esmtpa (envelope-from ) id 1hr0ON-0002pA-V0; Fri, 26 Jul 2019 16:36:16 +0300
To: Filip Skokan , Brian Campbell 
Cc: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= , oauth 
References: <3755f0ec-b9b3-a120-3aa5-5b8df1960dec@mail.ru>  <0CCE8B72-D140-4638-83B1-FB660D1D2239@gmail.com>
From: Tangui Le Pense 
Message-ID: 
Date: Fri, 26 Jul 2019 16:36:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <0CCE8B72-D140-4638-83B1-FB660D1D2239@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results: smtp47.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 0014004E1F3277295A78504BD2AC2941C5305B8A749479D54003B903A109DA0C1A14E06CF3A38046765CBB971BACBDC9
X-7FA49CB5: 0D63561A33F958A512595353267EF330529E0A2EDC7ECA3431F42FF5ACC87A938941B15DA834481FA18204E546F3947C68E4D7E803FA7AD5F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BDBA3F3F673D6AB81A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249AC37AC2B1429C73A76E601842F6C81A12EF20D2F80756B5F868A13BD56FB6657D81D268191BDAD3D78DA827A17800CE75C623DA9A0966939CD04E86FAF290E2DBBC930A3941E20C675ECD9A6C639B01B78DA827A17800CE7F42B85D3353DF1D46564932EFBC77E4B75ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57285124B2A10EEC6C00306258E7E6ABB4E4A6367B16DE6309
X-Mailru-Sender: 14EA92FCC1671FFE5482AFB7953ED8E17EA2B9C9B7377FB8156835DC3AD38177D48EB18BE89C37CACA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: 
Subject: Re: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)
X-BeenThere: oauth@ietf.org
X-Mailman-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, 26 Jul 2019 13:36:22 -0000

Thanks for your answers.

Let me rephrase if you don't mind. Acceptable keys for decryption of a 
request object are those with:

    (use:enc or no use)

    AND

    (key_ops:encrypt or key_ops:deriveKey or no key_ops)

    AND

    (alg in request_object_encryption_alg_values_supported (from OpenID 
Connect discovery) or no alg)

Is that correct? I'm not sure I get the "keyops:encrypt/deriveKey that 
works with a supported algorithm" part.

Also, the draft doesn't mention metadata, ushc as those specified by 
OIDC Discovery. Should it?

Best regards,

-- 

Tangui

On 26.07.2019 15:07, Filip Skokan wrote:
> Any use:enc, without “use†or “key_ops†or keyops:encrypt/deriveKey 
> that works with a supported algorithm, or one with the JWA “algâ€.
>
> Odesláno z iPhonu
>
> 26. 7. 2019 v 14:01, Brian Campbell 
>  >:
>
>> I'd say this one->* any "enc" key published by the AS on its jwks_uri?
>>
>> On Thu, Jul 25, 2019 at 3:50 PM Танги Ле ÐŸÐµÐ½Ñ 
>> > > wrote:
>>
>>     Dear all,
>>
>>     draft-ietf-oauth-jwsreq-19 gives guidance on which key use to
>>     verify a
>>     JWS' signature (the client's key)
>>     (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2
>>     ).
>>
>>     However there no such guidance for JWE encryption:
>>
>>     * any "enc" key published by the AS on its jwks_uri?
>>
>>     * one specific key of the ones listed at the server's jwks_uri?
>>     If so,
>>     how to indicate which one in particular?
>>
>>     * out-of-band configuration?
>>
>>     And should it be part of the specification?
>>
>>     Regards,
>>
>>     -- 
>>
>>     Tangui
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
>> privileged material for the sole use of the intended recipient(s). 
>> Any review, use, distribution or disclosure by others is strictly 
>> prohibited..  If you have received this communication in error, 
>> please notify the sender immediately by e-mail and delete the message 
>> and any file attachments from your computer. Thank you./
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Jul 26 11:23: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 0BE6F120409; Fri, 26 Jul 2019 11:23:28 -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 OWM6tFlhar9P; Fri, 26 Jul 2019 11:23:23 -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 B286D120449; Fri, 26 Jul 2019 11:23:22 -0700 (PDT)
Received: by mail-wm1-x341.google.com with SMTP id u25so38060054wmc.4; Fri, 26 Jul 2019 11:23:22 -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=d81MCLz3AtJcf8DxOphlejtuz7p1pLCsHWm8qIZvdvE=; b=gozU4p93+d/RbHBoKu0wh/7XQzhSrF7pNA+Cp+iTR4v8DMQjzcM5E3OE3hEGE8JAFX vi6L8PbneqJ6zP28FXjDPWhkkjYqLJiYEsQBQc27WG+ex2qiaNehBSW1q7CiyWOlpX12 cWJN8olrcCQSrj0tlSFWVD349rKLiFVNxakWfjedTxM5YJaXDc6lKkn69HzxqumZ2tdJ sWks4xpHoJ6KoOHzIBoArK7VFg3XDLnOEsYIbW/+a+caq5j2PqPx5qbQMozzW3zB5h8v U+aPDvdA41uvoXn2+jssvEjC0c41c63B1FcJVofesq2Xs4iI2Hzb8NvifzYJP0pwODkM Bzhg==
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=d81MCLz3AtJcf8DxOphlejtuz7p1pLCsHWm8qIZvdvE=; b=H8U1FI8zUb6hlBW5df5WAbn1/lHlwRnhjsP6GZjdTPzeI9CLANUuKSvbuPM+9VpCK8 vTs7BgyUfkT6xA3j7hP4ROB2XBtpp1SQ63TxhqPE1lt8qGOnS+34/cO3IzVH7mGmkSBe k6y8mNEnK2SMhbOG4W9l8IBWReCVPzmLGQKieNDqggOpyC2WzKwuh23LzPaB1j3Fl92q 51Dcwvpmslny/pXpeENfAKpDfxtLOv9BbmR2aHw09oDn5DO1vb1i+pS8fo2ELMwgcq7V bFptQKfaIJUNSg+fDImGB+tqwGq+Hfn6HRNXMPpFkYXvCDzS9oLqewEUytkeRgC3OwvV eppA==
X-Gm-Message-State: APjAAAWKcm+u48M6raayFxsOOHgo7X3YVv+T+gn1WlYHaHA3ZGHWyWDR NSssVMRrIJZDq6RrlJRbirj0w9wp4eUq8jR9Bbc=
X-Google-Smtp-Source: APXvYqyrzHIyPP1DsXCYXJ1skjpx3XUAkfUMfxR3fTGWdR3+TaHOls4aLNvj1bPdxrP7kMKeW6nSYnLIXymQVhI1N50=
X-Received: by 2002:a1c:7d4e:: with SMTP id y75mr87097311wmc.169.1564165400367;  Fri, 26 Jul 2019 11:23:20 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com>
In-Reply-To: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com>
From: Nat Sakimura 
Date: Fri, 26 Jul 2019 14:23:09 -0400
Message-ID: 
To: Benjamin Kaduk 
Cc: The IESG , oauth , oauth-chairs@ietf.org,  draft-ietf-oauth-jwsreq@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000f1a9f058e99a314"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jul 2019 18:23:28 -0000

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

Thanks very much for the comments.
Here are my responses to your comments.

On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwsreq-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> My apologies; my previous position was incomplete.  Updated to note
> namespacing issues, and one minor terminology nit about "DNS-ID".
>
> There seem to be some pretty serious namespacing issues that are not
> discussed at all in this document.  Specifically, using JWT as a
> container for OAuth 2.0 authorization request parameters (including
> extension parameters) introduces the usage of many new names (of JSON
> name/value pairs) into the JWT claims namespace.  Furthermore, the
> addition is not bounded, as any new OAuth extension parameters are
> implicitly permitted to be used as well!  The IANA Considerations make
> no mention of the collapsed namespace for JWT claims and OAuth 2.0
> (authorization request) parameters, leaving substantial potential for
> collisions in the future.

The simplest solution probably is to register the authorization request
parameters to the JWT Claims registry.
According to my checking, the relevant but not yet registered parameters
are:

Claim Name: "code_challenge"
Claim Description: OAuth PKCE Code Challenge
Change Controller: IESG
Specification Document(s): Section 3 of RFC 7636

Claim Name: "code_challenge_method"
Claim Description: OAuth PKCE Code Challenge
Change Controller: IESG
Specification Document(s): Section 3 of RFC 7636

Claim Name: "redirect_uri"
Claim Description: OAuth Redirection URI
Change Controller: IETF
Specification Document(s): Section 4.1.1 of RFC 6749

Claim Name: "response_type"
Claim Description: OAuth Authorization Response type
Change Controller: IETF
Specification Document(s): Section 3.1.1 of RFC 6749

Claim Name: "state"
Claim Description: OAuth state parameter
Change Controller: IETF
Specification Document(s): Section 4.1.1 of RFC 6749

Claim Name: "vtr"
Claim Description: Vector of Trust request
Change Controller: IESG
Specification Document(s): Section 4.1 of RFC 8485

> Relatedly, using "application/jwt" as the Content-type of the
> HTTP response from dereferencing the request_uri with no explicit
> indication of the type/profile of JWT used (whether in the content type
> or in the JWT claims themselves) gives some risk of misinterpretation of
> the content.  Consider, for example, when that request_uri is
> dereferenced not by the authorization server in the process of
> fulfilling an authorization request, but instead by some other service
> that expects a different type of JWT.

I am making the change to "application/oauth-authz-req+jwt" and add IANA
request.

>
> This second point is a "discuss discuss" -- it's an important question
> and I'd like to talk about it, but it's not clear that any change to the
> document will be needed.
>
> The introduction notes as an advantage of JWT that:
>
>    (d)  (collection minimization) The request can be signed by a third
>         party attesting that the authorization request is compliant with
>         a certain policy.  For example, a request can be pre-examined by
>         a third party that all the personal data requested is strictly
>         necessary to perform the process that the end-user asked for,
>         and statically signed by that third party.  The authorization
>         server then examines the signature and shows the conformance
>         status to the end-user, who would have some assurance as to the
>         legitimacy of the request when authorizing it.  In some cases,
>         it may even be desirable to skip the authorization dialogue
>         under such circumstances.
>
> I'm pretty uncomfortable about suggesting that the authorization
> dialogue can/should be skipped; do we need to keep this example?
>

I have actually deliberately put this text as there seem to be some
disconnect between the engineering community and the privacy regulators
community. Asking for "consent" is something that should be considered as
an exception and should use other lawful basis if possible as UK ICO (The
data protection regulator in the UK) advises. As the editor of "ISO/IEC
29184 Privacy notice and consent", which is being developed with close
coordination with regulators such as European Data Protection Board, I
would have to agree to that position and I took OAuth JAR as one of the
opportunity to call it out. I will add some text explaining it such as:

In some cases, it is deemed harmful to ask for consent when it is not
necessary: i.e., the processing is performed under other lawful basis than
consent, as it would make the consent, that should be an exception, stand
out less. Under such circumstances, this mechanism can be used to skip the
authorization dialogue.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
>    While it is easy to implement, the encoding in the URI does not allow
>    application layer security with confidentiality and integrity
>    protection to be used.  While TLS is used to offer communication
>
> nit: this wording is a little hard to read; it might be easier to
> reorder to "does not allow application layer security to be used to
> provide confidentiality and integrity protection".

Thanks. I will make the change.

>
>    The use of application layer security allows requests to be prepared
>    by a third party so that a client application cannot request more
>    permissions than previously agreed.  This offers an additional degree
>    of privacy protection.
>
> (side note) what would an example of such a third party be.  (We already
> have the resource owner, the client, and the authorization server ...
> maybe it's a fourth party?)

It is a fourth party, e.g., a trust framework provider or an information
fiduciary.
The text need to be modified though as I found an error.
Since now all the OAuth Request parameters must be in the request object,
only the pattern that can be supported for something like this is to push
the request object to the TFP and have the TFP check if it meets the policy
and return request_uri only it is evelauted as OK.

>
>    Furthermore, the request by reference allows the reduction of over-
>    the-wire overhead.
>
> We only barely mentioned by-reference at this point (one line in the
> Abstract), so I'd suggest "passing the request by reference".

Thanks. I will make the change.

>
>    (4)  its development status that it is an RFC and so is its
>         associated signing and encryption methods as [RFC7515] and
>         [RFC7516]
>
> nit: I'd suggest "its development status as a Proposed Standard, along
> with the associated signing and encryption methods [RFC7515] [RFC7516]."

Thanks. I will make the change.

>
>    (c)  (confidentiality protection) The request can be encrypted so
>         that end-to-end confidentiality can be provided even if the TLS
>         connection is terminated at one point or another.
>
> nit: TLS is always terminated at or before the user-agent, though.  So
> maybe the user agent needs to get called out here as well (there could
> of course be TLS termination earlier than the user-agent in some cases,
> too).

Thanks. I will make the change.

>
>    2.  When the client does not want to do the crypto.  The
>        Authorization Server may provide an endpoint to accept the
>        Authorization Request through direct communication with the
>        Client so that the Client is authenticated and the channel is TLS
>        protected.
>
> How can you "not want to do [the] crypto" but still be doing TLS (with
> crypto)?  Perhaps we're looking for "not want to pay the additional
> overhead of JWS/JWE cryptography on top of TLS"?

Thanks. I will make the change.

>
> Section 1.1
>
> RFC 8174 has updated BCP 14 boilerplate text to use.

Thanks. I will make the change.

>
> Section 3
>
> nit: should this section be 2.3 to get wrapped into "terminology"?

It could, but I suppose it could be as is.

>
> It might also be worth putting references in for the terms, though they
> are largely common knowledge at this point.

Hopefully, they are public knowledge ...

>
> Section 4
>
>    A Request Object (Section 2.1) is used to provide authorization
>    request parameters for an OAuth 2.0 authorization request.  It MUST
>    contains all the OAuth 2.0 [RFC6749] authorization request parameters
>    including extension parameters.  The parameters are represented as
>
> nit: "all the parameters" kind of sounds like "all that are defined".
> But I think the intent here is "any parameter used to process the
> request must come from the request object and URL query parameters are
> ignored", so maybe "MUST contain all the parameters (including extension
> parameters) used to process the OAuth 2.0 [RFC6749] authorization
> request; parameters from other sources MUST NOT be used", akin to what
> we say down in Sections 5 and 6.3.
> But we need to be careful about the wording to not exclude the usage of
> the "request" and "request_uri" query parameters to  find the Request
> Object!

Thanks. I will make the description more exact.

>
>    the JWT claims.  Parameter names and string values MUST be included
>
> nit: maybe "the JWT claims of the object"?

Thanks. I will probably make it "the JWT claims of the request object."

>
>    any extension parameters.  This JSON [RFC7159] constitutes the JWT
>    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>    signed or signed and encrypted.
>
> nit: I  think we want "This JSON [RFC7159] object".

Thanks. I will fix it as suggested.

>
> (Long quote incoming)
>
>    The following is an example of the Claims in a Request Object before
>    base64url encoding and signing.  Note that it includes extension
>    variables such as "nonce" and "max_age".
>
>      {
>       "iss": "s6BhdRkqt3",
>       "aud": "https://server.example.com",
>       "response_type": "code id_token",
>       "client_id": "s6BhdRkqt3",
>       "redirect_uri": "https://client.example.org/cb",
>       "scope": "openid",
>       "state": "af0ifjsldkj",
>       "nonce": "n-0S6_WzA2Mj",
>       "max_age": 86400
>      }
>
>    Signing it with the "RS256" algorithm results in this Request Object
>    value (with line wraps within values for display purposes only):
>
>      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
>      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
>      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
>      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
>      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
>      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
>      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
>      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
>      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
>      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
>      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
>      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
>      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
>      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
>      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
>      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
>      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
>      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>
> Decoding the base64 of the body, we see:
> {
>  "iss": "s6BhdRkqt3",
>  "aud": "https://server.example.com",
>  "response_type": "code id_token",
>  "client_id": "s6BhdRkqt3",
>  "redirect_uri": "https://client.example.org/cb",
>  "scope": "openid",
>  "state": "af0ifjsldkj",
>  "nonce": "n-0S6_WzA2Mj",
>  "max_age": 86400,
>  "claims":
>   {
>    "userinfo":
>     {
>      "given_name": {"essential": true},
>      "nickname": null,
>      "email": {"essential": true},
>      "email_verified": {"essential": true},
>      "picture": null
>     },
>    "id_token":
>     {
>      "gender": null,
>      "birthdate": {"essential": true},
>      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>     }
>   }
> }
>
> I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> seem to talk about it.  (Note that this example is used later on as
> well.)

It is an extension parameter that is registered in the OAuth authorization
request registry.
It is defined in OpenID Connect Core and OIDF is in the process of
registering it to the JWT Claims registry as well. I have put them to show
that extension parameters can also be used in the request object. Having
said that, they may be confusing. I should just remove them.

>
> Section 5.2.1
>
>    It is possible for the Request Object to include values that are to
>    be revealed only to the Authorization Server.  As such, the
>    "request_uri" MUST have appropriate entropy for its lifetime.  For
>    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
>    that it be removed after a reasonable timeout unless access control
>    measures are taken.
>
> It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> also be useful.
>

Thanks. I will add it.

> Section 5.2.2
>
> Do we want to remind the reader that the other query parameters are just
> for backwards compatibility?

It is probably be better to remove them as they are not allowed to be used.

>
> Section 5.2.3
>
>    The following is an example of this fetch process:
>
>      GET /request.jwt HTTP/1.1
>      Host: tfp.example.org
>
> It's useful to show good hygeine in examples; can we get the extra
> entropy in this request that we have in the previous example(s)?

Thanks for pointing out. I will fix it. (The previous example also needs to
be changed.)

>
> Section 6.2
>
>    The Authorization Server MUST perform the signature validation of the
>    JSON Web Signature [RFC7515] signed request object.  For this, the
>    "alg" Header Parameter in its JOSE Header MUST match the value of the
>    pre-registered algorithm.  The signature MUST be validated against
>    the appropriate key for that "client_id" and algorithm.
>
> Does "the pre-registered algorithm" concept exist in the specs outside
> of draft-ietf-oauth-jwt-bcp?

Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
Metadata registry forms the concept. RFC7591 allows clients to register the
claims that is in the OAuth Dynamic Client Registration Metadata registry.
The registry has

   - request_object_signing_alg
   - request_object_encryption_alg

besides others. Having said that, it is a bit obscure so I probably should
put some more explanation around it.

>
> Section 8
>
>    HTTP clients MUST also verify the TLS server certificate, using
>    subjectAltName dNSName identities as described in [RFC6125], to avoid
>    man-in-the-middle attacks.  The rules and guidelines defined in
>
> It's probably easier to just say "using DNS-ID [RFC6125], to avoid
> man-in-the-middle attacks".

Thanks. I will do so.

>
> Section 9
>
> The error codes we list in Section 7 are already registered, for the
> OIDC usage.  Do we want to say anything about that?   (I guess it would
> be disallowed by process to try to update the existing registration to
> also point at this document.)

OIDC is an extension of OAuth and it should be fine as is.
What we need to be careful is that there will be no conflict going forward.
I will put the instruction update that will be provided by Mike (Jones).

>
> Section 10
>
> We probably also want to reference draft-ietf-oauth-jwt-bcp.

Thanks. I will put the reference as draft.

>
> Section 10.1
>
>    When sending the authorization request object through "request"
>    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>    using JWE [RFC7516] with then considered appropriate algorithm.
>
> Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
> similarly, in Section 4 we reiterate "signed then encrypted".  Why is it
> okay to talk about just "signed or encrypted" here?

Very good catch. It should be changed to align with other sections.

>
> Section 10.2
>
>    (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.
>
> Similarly to the previous point, you also need to check the signature,
> which will always be there.

You are right. This one should be removed.

>
>    (d)  Authorization Server is providing an endpoint that provides a
>         Request Object URI in exchange for a Request Object.  In this
>
> I don't think this is a complete sentence (and it's definitely not a
> parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
> summary of this method would be "Delegating the authorization check to a
> separate "Request Object to Request Object URI" endpoint on the
> Authorization Server".  (The writing in the rest of this paragraph could
> also use an editing pass.)

Thanks for pointing it out. Changing as follows would be ok?

(d) When Authorization Server is providing an endpoint that provides a
Request Object URI in exchange for a Request Object,
the Authorization Server MUST perform Client
Authentication to accept the Request Object and bind the Client
Identifier to the Request Object URI it is providing. Since
Request Object URI can be replayed, the lifetime of the Request
Object URI MUST be short and preferably one-time use. The
entropy of the Request Object URI MUST be sufficiently large.
The adequate shortness of the validity and the entropy of the
Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for
the validity time would be less than a minute and the Request
Object URI is to include a cryptographic random value of 128bit
or more at the time of the writing of this specification.

>
>    (e)  A third party, such as a Trust Framework Provider, provides an
>         endpoint that provides a Request Object URI in exchange for a
>         Request Object.  The same requirements as (b) above apply.  In
>         addition, the Authorization Server MUST know out-of-band that
>         the Client utilizes the Trust Framework Operator.
>
> The Authorization Server also has to trust the third-party provider to
> actually do its job and not misbehave, right?

Yes. I will add wording around it.

>
> Section 10.3
>
> I'm not entirely sure what "[t]he endpoints that come into question in
> this specification" is supposed to mean -- is it just "the OAuth 2.0
> endpoints presently defined in Standards-Track RFCs"?

Yes. RFC6749, RFC6750, and RFC8414.

>
>    In [RFC6749], while Redirection URI is included, others are not
>    included in the Authorization Request.  As the result, the same
>    applies to Authorization Request Object.
>
> nit: included in what?

In the Authorization request.
I thought it would be too onerous to state

In [RFC6749], while Redirection URI is included in the Authorization
> Request,
> others are not included in the Authorization Request.  As the result, the
> same
> applies to Authorization Request Object.


Would you like to add "in the Authorization Request" as above?

>
> Section 10.4
>
> It's probably also worth citing the generic URI security considerations
> from RFC 3986, here.

I will do so. Thanks.

>
> Section 10.4.1
>
>    "request_uri", and (d) do not perform recursive GET on the
>    "request_uri".
>
> nit: remove the "do" in order to make the construction parallel.

Thanks. I will do so.

>
> Section 12.1
>
>    It is often hard for the user to find out if the personal data asked
>    for is strictly necessary.  A Trust Framework Provider can help the
>    user by examining the Client request and comparing to the proposed
>    processing by the Client and certifying the request.  After the
>    certification, the Client, when making an Authorization Request, can
>    submit Authorization Request to the Trust Framework Provider to
>    obtain the Request Object URI.
>
> side note: In my head the act of certification was the act of making the
> translation to a Request Object URI, so I'm kind of curious where my
> vision differs from reality.

So, I should probably expand the text.
The process is two steps:

1. (Certification Process) The TFP examines the business process of the
client and determines what claims they needs: This is the certification
process. Once the client is certified, then they are issued a client
credential to authenticate against to push request objects to the TFP to
get the request_uri.

2. (Translation Process) The client uses the client credential that it got
to push the request object to the TFP to get the request_uri.

>
> The third paragraph seems to mostly just be describing the procedure of
> how this flow works, which would not necessarily be specific to the
> privacy considerations section.

The third paragraph is also important from the privacy point of view.
In a trust framework that has a policy to only allow TFP vetted request
object,
then the Authorization Server must make sure that it was.
One way to do it is to check the authority section.

>
> Section 12.2.2
>
>    Even if the protected resource does not include a personally
>    identifiable information, it is sometimes possible to identify the
>    user through the Request Object URI if persistent per-user Request
>    Object URI is used.  A third party may observe it through browser
>
> nit: need an article for "persistent per-user Request Object URI" (or
> make it plural, as "URIs are used").

Thanks. I will fix it.

>
>    Therefore, per-user Request Object URI should be avoided.
>
> nit: I think this is better as "static per-user Requeste Object URIs".

Thanks. I will fix it.

>
> Section 13
>
> Are there two different paragraphs for "contributions from the OAuth WG
> members"?  Are they reflecting different types of contribution?

Thanks. I have merged them.


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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



Thanks very much for the comments.=C2=A0
Here are =
my responses to your comments.=C2=A0

On Wed, Jul 3, 2019 at 2=
:59 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
>
> Benjamin Kaduk has enter=
ed the following ballot position for
> draft-ietf-oauth-jwsreq-19: Di=
scuss
>
> When responding, please keep the subject line intact =
and reply to all
> email addresses included in the To and CC lines. (=
Feel free to cut this
> introductory paragraph, however.)
>
=
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteri=
a.html
> for more information about IESG DISCUSS and COMMENT posi=
tions.
>
>
> The document, along with other ballot positi=
ons, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oaut=
h-jwsreq/
>
>
>
> -----------------------------=
-----------------------------------------
> DISCUSS:
> --------=
--------------------------------------------------------------
>
&=
gt; My apologies; my previous position was incomplete.=C2=A0 Updated to not=
e
> namespacing issues, and one minor terminology nit about "DNS=
-ID".
>
> There seem to be some pretty serious namespacing=
 issues that are not
> discussed at all in this document.=C2=A0 Speci=
fically, using JWT as a
> container for OAuth 2.0 authorization reque=
st parameters (including
> extension parameters) introduces the usage=
 of many new names (of JSON
> name/value pairs) into the JWT claims n=
amespace.=C2=A0 Furthermore, the
> addition is not bounded, as any ne=
w OAuth extension parameters are
> implicitly permitted to be used as=
 well!=C2=A0 The IANA Considerations make
> no mention of the collaps=
ed namespace for JWT claims and OAuth 2.0
> (authorization request) p=
arameters, leaving substantial potential for
> collisions in the futu=
re.

The simplest solution probably is to register the authorization =
request parameters to the JWT Claims registry.
According to my checking,=
 the relevant but not yet registered parameters are:

Claim Name: &qu=
ot;code_challenge"
Claim Description: OAuth PKCE Code Challenge
=
Change Controller: IESG
Specification Document(s): Section 3 of RFC 7636=


Claim Name: "code_challenge_method"
Claim Description:=
 OAuth PKCE Code Challenge
Change Controller: IESG
Specification Docu=
ment(s): Section 3 of RFC 7636

Claim Name: "redirect_uri"<=
br>Claim Description: OAuth Redirection URI
Change Controller: IETF
S=
pecification Document(s): Section 4.1.1 of RFC 6749

Claim Name: &quo=
t;response_type"
Claim Description: OAuth Authorization Response ty=
pe
Change Controller: IETF
Specification Document(s): Section 3.1.1 o=
f RFC 6749

Claim Name: "state"
Claim Description: OAuth=
 state parameter
Change Controller: IETF
Specification Document(s): S=
ection 4.1.1 of RFC 6749

Claim Name: "vtr"
Claim Descri=
ption: Vector of Trust request
Change Controller: IESG
Specification =
Document(s): Section 4.1 of RFC 8485

> Relatedly, using "app=
lication/jwt" as the Content-type of the
> HTTP response from de=
referencing the request_uri with no explicit
> indication of the type=
/profile of JWT used (whether in the content type
> or in the JWT cla=
ims themselves) gives some risk of misinterpretation of
> the content=
.=C2=A0 Consider, for example, when that request_uri is
> dereference=
d not by the authorization server in the process of
> fulfilling an a=
uthorization request, but instead by some other service
> that expect=
s a different type of JWT.

I am making the change to "applicati=
on/oauth-authz-req+jwt" and add IANA request.

>
> This=
 second point is a "discuss discuss" -- it's an important que=
stion
> and I'd like to talk about it, but it's not clear tha=
t any change to the
> document will be needed.
>
> The in=
troduction notes as an advantage of JWT that:
>
> =C2=A0 =C2=A0=
(d) =C2=A0(collection minimization) The request can be signed by a third> =C2=A0 =C2=A0 =C2=A0 =C2=A0 party attesting that the authorization re=
quest is compliant with
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a certain polic=
y.=C2=A0 For example, a request can be pre-examined by
> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 a third party that all the personal data requested is str=
ictly
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 necessary to perform the process =
that the end-user asked for,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and static=
ally signed by that third party.=C2=A0 The authorization
> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 server then examines the signature and shows the conforma=
nce
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 status to the end-user, who would h=
ave some assurance as to the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimacy=
 of the request when authorizing it.=C2=A0 In some cases,
> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 it may even be desirable to skip the authorization dia=
logue
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 under such circumstances.
>=

> I'm pretty uncomfortable about suggesting that the authorizati=
on
> dialogue can/should be skipped; do we need to keep this example?=

>

I have actually deliberately put this text as there seem to=
 be some disconnect between the engineering community and the privacy regul=
ators community. Asking for "consent" is something that should be=
 considered as an exception and should use other lawful basis if possible a=
s UK ICO (The data protection regulator in the UK) advises. As the editor o=
f "ISO/IEC 29184 Privacy notice and consent", which is being deve=
loped with close coordination with regulators such as European Data Protect=
ion Board, I would have to agree to that position and I took OAuth JAR as o=
ne of the opportunity to call it out. I will add some text explaining it su=
ch as:=C2=A0

In some cases, it is deemed harmful t=
o ask for consent when it is not necessary: i.e., the processing is perform=
ed under other lawful basis than consent, as it would make the consent, tha=
t should be an exception, stand out less. Under such circumstances, this me=
chanism can be used=C2=A0to skip the authorization dialogue.=C2=A0=C2=A0
>
> ---------------------------------------------------------=
-------------
> COMMENT:
> ------------------------------------=
----------------------------------
>
> Section 1
>
>=
; =C2=A0 =C2=A0While it is easy to implement, the encoding in the URI does =
not allow
> =C2=A0 =C2=A0application layer security with confidential=
ity and integrity
> =C2=A0 =C2=A0protection to be used.=C2=A0 While T=
LS is used to offer communication
>
> nit: this wording is a li=
ttle hard to read; it might be easier to
> reorder to "does not =
allow application layer security to be used to
> provide confidential=
ity and integrity protection".

Thanks. I will make the change.<=
br>
>
> =C2=A0 =C2=A0The use of application layer security allo=
ws requests to be prepared
> =C2=A0 =C2=A0by a third party so that a =
client application cannot request more
> =C2=A0 =C2=A0permissions tha=
n previously agreed.=C2=A0 This offers an additional degree
> =C2=A0 =
=C2=A0of privacy protection.
>
> (side note) what would an exam=
ple of such a third party be. =C2=A0(We already
> have the resource o=
wner, the client, and the authorization server ...
> maybe it's a=
 fourth party?)

It is a fourth party, e.g., a trust framework provid=
er or an information fiduciary.
The text need to be modified though as I=
 found an error.
Since now all the OAuth Request parameters must be in t=
he request object,
only the pattern that can be supported for something =
like this is to push
the request object to the TFP and have the TFP chec=
k if it meets the policy
and return request_uri only it is evelauted as =
OK.

>
> =C2=A0 =C2=A0Furthermore, the request by reference =
allows the reduction of over-
> =C2=A0 =C2=A0the-wire overhead.
&g=
t;
> We only barely mentioned by-reference at this point (one line in=
 the
> Abstract), so I'd suggest "passing the request by ref=
erence".

Thanks. I will make the change.

>
> =
=C2=A0 =C2=A0(4) =C2=A0its development status that it is an RFC and so is i=
ts
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated signing and encryption me=
thods as [RFC7515] and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7516]
>=
;
> nit: I'd suggest "its development status as a Proposed S=
tandard, along
> with the associated signing and encryption methods [=
RFC7515] [RFC7516]."

Thanks. I will make the change.

>=
;
> =C2=A0 =C2=A0(c) =C2=A0(confidentiality protection) The request c=
an be encrypted so
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 that end-to-end conf=
identiality can be provided even if the TLS
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 connection is terminated at one point or another.
>
> ni=
t: TLS is always terminated at or before the user-agent, though.=C2=A0 So> maybe the user agent needs to get called out here as well (there cou=
ld
> of course be TLS termination earlier than the user-agent in some=
 cases,
> too).

Thanks. I will make the change.

>> =C2=A0 =C2=A02.=C2=A0 When the client does not want to do the crypto.=
=C2=A0 The
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Server may prov=
ide an endpoint to accept the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorizat=
ion Request through direct communication with the
> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Client so that the Client is authenticated and the channel is TLS=

> =C2=A0 =C2=A0 =C2=A0 =C2=A0protected.
>
> How can you =
"not want to do [the] crypto" but still be doing TLS (with
>=
; crypto)?=C2=A0 Perhaps we're looking for "not want to pay the ad=
ditional
> overhead of JWS/JWE cryptography on top of TLS"?
<=
br>Thanks. I will make the change.

>
> Section 1.1
><=
br>> RFC 8174 has updated BCP 14 boilerplate text to use.

Thanks.=
 I will make the change. 

>
> Section 3
>
> nit=
: should this section be 2.3 to get wrapped into "terminology"?
It could, but I suppose it could be as is. 

>
> It mi=
ght also be worth putting references in for the terms, though they
> =
are largely common knowledge at this point.

Hopefully, they are publ=
ic knowledge ... 

>
> Section 4
>
> =C2=A0 =C2=
=A0A Request Object (Section 2.1) is used to provide authorization
> =
=C2=A0 =C2=A0request parameters for an OAuth 2.0 authorization request.=C2=
=A0 It MUST
> =C2=A0 =C2=A0contains all the OAuth 2.0 [RFC6749] autho=
rization request parameters
> =C2=A0 =C2=A0including extension parame=
ters.=C2=A0 The parameters are represented as
>
> nit: "al=
l the parameters" kind of sounds like "all that are defined"=
.
> But I think the intent here is "any parameter used to proces=
s the
> request must come from the request object and URL query param=
eters are
> ignored", so maybe "MUST contain all the parame=
ters (including extension
> parameters) used to process the OAuth 2.0=
 [RFC6749] authorization
> request; parameters from other sources MUS=
T NOT be used", akin to what
> we say down in Sections 5 and 6.3=
.
> But we need to be careful about the wording to not exclude the us=
age of
> the "request" and "request_uri" query pa=
rameters to =C2=A0find the Request
> Object!

Thanks. I will ma=
ke the description more exact. 

>
> =C2=A0 =C2=A0the JWT cl=
aims.=C2=A0 Parameter names and string values MUST be included
>
&=
gt; nit: maybe "the JWT claims of the object"?

Thanks. I w=
ill probably make it "the JWT claims of the request object."
<=
br>>
> =C2=A0 =C2=A0any extension parameters.=C2=A0 This JSON [RFC=
7159] constitutes the JWT
> =C2=A0 =C2=A0Claims Set defined in JWT [R=
FC7519].=C2=A0 The JWT Claims Set is then
> =C2=A0 =C2=A0signed or si=
gned and encrypted.
>
> nit: I =C2=A0think we want "This J=
SON [RFC7159] object".

Thanks. I will fix it as suggested. 
=

>
> (Long quote incoming)
>
> =C2=A0 =C2=A0The fol=
lowing is an example of the Claims in a Request Object before
> =C2=
=A0 =C2=A0base64url encoding and signing.=C2=A0 Note that it includes exten=
sion
> =C2=A0 =C2=A0variables such as "nonce" and "max=
_age".
>
> =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=
=A0 "iss": "s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 &=
quot;aud": "https://server=
.example.com",
> =C2=A0 =C2=A0 =C2=A0 "response_type&qu=
ot;: "code id_token",
> =C2=A0 =C2=A0 =C2=A0 "client_i=
d": "s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "redirec=
t_uri": "https://client=
.example.org/cb",
> =C2=A0 =C2=A0 =C2=A0 "scope": =
"openid",
> =C2=A0 =C2=A0 =C2=A0 "state": "a=
f0ifjsldkj",
> =C2=A0 =C2=A0 =C2=A0 "nonce": "n-0=
S6_WzA2Mj",
> =C2=A0 =C2=A0 =C2=A0 "max_age": 86400> =C2=A0 =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0Signing it with th=
e "RS256" algorithm results in this Request Object
> =C2=A0=
 =C2=A0value (with line wraps within values for display purposes only):
=
>
> =C2=A0 =C2=A0 =C2=A0eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew=
0KICJpc3MiOiAiczZCaGRSa3
> =C2=A0 =C2=A0 =C2=A0F0MyIsDQogImF1ZCI6ICJo=
dHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> =C2=A0 =C2=A0 =C2=A0c3=
BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
> =
=C2=A0 =C2=A0 =C2=A0JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZ=
W50LmV4YW1w
> =C2=A0 =C2=A0 =C2=A0bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3B=
lbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> =C2=A0 =C2=A0 =C2=A0Zqc2xka2oiLA0KI=
CJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> =C2=A0 =C2=A0 =
=C2=A0ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ> =C2=A0 =C2=A0 =C2=A0ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnV=
lfSwNCiAgICAgIm5p
> =C2=A0 =C2=A0 =C2=A0Y2tuYW1lIjogbnVsbCwNCiAgICAgI=
mVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> =C2=A0 =C2=A0 =C2=A0wNCiAgICA=
gImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
> =C2=A0 =
=C2=A0 =C2=A0ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KIC=
AgIH
> =C2=A0 =C2=A0 =C2=A0sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJi=
aXJ0aGRhdGUiOiB7ImVzc2Vu
> =C2=A0 =C2=A0 =C2=A0dGlhbCI6IHRydWV9LA0KIC=
AgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> =C2=A0 =C2=A0 =C2=A0lu=
Y29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
> =
=C2=A0 =C2=A0 =C2=A0F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9=
Emo_wHwajyF
> =C2=A0 =C2=A0 =C2=A0KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7=
PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> =C2=A0 =C2=A0 =C2=A00GxFbuPbj96tVuj=
11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> =C2=A0 =C2=A0 =
=C2=A0ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG> =C2=A0 =C2=A0 =C2=A0iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL=
-2QgwUsAlMGzw
>
> Decoding the base64 of the body, we see:
&=
gt; {
> =C2=A0"iss": "s6BhdRkqt3",
> =C2=A0=
"aud": "https://serve=
r.example.com",
> =C2=A0"response_type": "cod=
e id_token",
> =C2=A0"client_id": "s6BhdRkqt3&quo=
t;,
> =C2=A0"redirect_uri": "https://client.example.org/cb",
> =C2=A0&qu=
ot;scope": "openid",
> =C2=A0"state": "=
af0ifjsldkj",
> =C2=A0"nonce": "n-0S6_WzA2Mj"=
;,
> =C2=A0"max_age": 86400,
> =C2=A0"claims&quo=
t;:
> =C2=A0 {
> =C2=A0 =C2=A0"userinfo":
> =C2=
=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0"given_name": {"ess=
ential": true},
> =C2=A0 =C2=A0 =C2=A0"nickname": null=
,
> =C2=A0 =C2=A0 =C2=A0"email": {"essential": tr=
ue},
> =C2=A0 =C2=A0 =C2=A0"email_verified": {"essenti=
al": true},
> =C2=A0 =C2=A0 =C2=A0"picture": null
&=
gt; =C2=A0 =C2=A0 },
> =C2=A0 =C2=A0"id_token":
> =C2=
=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0"gender": null,
> =
=C2=A0 =C2=A0 =C2=A0"birthdate": {"essential": true},> =C2=A0 =C2=A0 =C2=A0"acr": {"values": ["urn=
:mace:incommon:iap:silver"]}
> =C2=A0 =C2=A0 }
> =C2=A0 }<=
br>> }
>
> I'm not sure where the "claims" cla=
im is coming from -- 6749 doesn't
> seem to talk about it. =C2=A0=
(Note that this example is used later on as
> well.)

It is an =
extension parameter that is registered in the OAuth authorization request r=
egistry. 
It is defined in OpenID Connect Core and OIDF is in the proces=
s of registering it to the JWT Claims registry as well. I have put them to =
show that extension parameters can also be used in the request object. Havi=
ng said that, they may be confusing. I should just remove them.=C2=A0
>
> Section 5.2.1
>
> =C2=A0 =C2=A0It is possible fo=
r the Request Object to include values that are to
> =C2=A0 =C2=A0be =
revealed only to the Authorization Server.=C2=A0 As such, the
> =C2=
=A0 =C2=A0"request_uri" MUST have appropriate entropy for its lif=
etime.=C2=A0 For
> =C2=A0 =C2=A0the guidance, refer to 5.1.4.2.2 of [=
RFC6819].=C2=A0 It is RECOMMENDED
> =C2=A0 =C2=A0that it be removed a=
fter a reasonable timeout unless access control
> =C2=A0 =C2=A0measur=
es are taken.
>
> It sounds like a link to https://www.w3.org/TR/capability-urls/ m=
ight
> also be useful.
>

Thanks. I will add it. 

=
> Section 5.2.2
>
> Do we want to remind the reader that the=
 other query parameters are just
> for backwards compatibility?
It is probably be better to remove them as they are not allowed to be use=
d. 

>
> Section 5.2.3
>
> =C2=A0 =C2=A0The foll=
owing is an example of this fetch process:
>
> =C2=A0 =C2=A0 =
=C2=A0GET /request.jwt HTTP/1.1
> =C2=A0 =C2=A0 =C2=A0Host: tfp.example.org
>
> It's us=
eful to show good hygeine in examples; can we get the extra
> entropy=
 in this request that we have in the previous example(s)?

Thanks for=
 pointing out. I will fix it. (The previous example also needs to be change=
d.) 

>
> Section 6.2
>
> =C2=A0 =C2=A0The Autho=
rization Server MUST perform the signature validation of the
> =C2=A0=
 =C2=A0JSON Web Signature [RFC7515] signed request object.=C2=A0 For this, =
the
> =C2=A0 =C2=A0"alg" Header Parameter in its JOSE Heade=
r MUST match the value of the
> =C2=A0 =C2=A0pre-registered algorithm=
.=C2=A0 The signature MUST be validated against
> =C2=A0 =C2=A0the ap=
propriate key for that "client_id" and algorithm.
>
>=
 Does "the pre-registered algorithm" concept exist in the specs o=
utside
> of draft-ietf-oauth-jwt-bcp?

Yes. RFC7591 combined wi=
th some of the OAuth Dynamic Client Registration Metadata registry forms th=
e concept. RFC7591 allows clients to register the claims that is in the OAu=
th Dynamic Client Registration Metadata registry. The registry has
    <=
li>request_object_signing_alg
  • request_object_encryption_alg
    • besides others. Having said that, it is a bit obscure so I probably shoul=
d put some more explanation around it.=C2=A0

    >
    > Section 8<=
br>>
    > =C2=A0 =C2=A0HTTP clients MUST also verify the TLS server c=
ertificate, using
    > =C2=A0 =C2=A0subjectAltName dNSName identities as=
 described in [RFC6125], to avoid
    > =C2=A0 =C2=A0man-in-the-middle at=
tacks.=C2=A0 The rules and guidelines defined in
    >
    > It's p=
robably easier to just say "using DNS-ID [RFC6125], to avoid
    > m=
an-in-the-middle attacks".

    Thanks. I will do so.=C2=
=A0

    >
    > Section 9
    >
    > The error codes we=
 list in Section 7 are already registered, for the
    > OIDC usage.=C2=
=A0 Do we want to say anything about that? =C2=A0 (I guess it would
    >=
 be disallowed by process to try to update the existing registration to
    =
> also point at this document.)

    OIDC is an exte=
nsion of OAuth and it should be fine as is.=C2=A0
    What we need to=
 be careful is that there will be no conflict going forward.=C2=A0
    I will put the instruction update that will be provided by Mike (Jones).=
=C2=A0

>
> Section 10
>
> We probably al=
so want to reference draft-ietf-oauth-jwt-bcp.

Tha=
nks. I will put the reference as draft.=C2=A0

>
> Se=
ction 10.1
>
> =C2=A0 =C2=A0When sending the authorization requ=
est object through "request"
> =C2=A0 =C2=A0parameter, it M=
UST either be signed using JWS [RFC7515] or encrypted
> =C2=A0 =C2=A0=
using JWE [RFC7516] with then considered appropriate algorithm.
>
=
> Up in Section 5 we only allow (a) signed and (b) signed then encrypted=
;
> similarly, in Section 4 we reiterate "signed then encrypted&=
quot;.=C2=A0 Why is it
> okay to talk about just "signed or encr=
ypted" here?

Very good catch. It should be ch=
anged to align with other sections.=C2=A0

>
> Sectio=
n 10.2
>
> =C2=A0 =C2=A0(b) =C2=A0Verifying that the symmetric =
key for the JWE encryption is the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 corre=
ct one if the JWE is using symmetric encryption.
>
> Similarly =
to the previous point, you also need to check the signature,
> which =
will always be there.

You are right. This one shou=
ld be removed.=C2=A0

>
> =C2=A0 =C2=A0(d) =C2=A0Auth=
orization Server is providing an endpoint that provides a
> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Request Object URI in exchange for a Request Object.=
=C2=A0 In this
>
> I don't think this is a complete sentenc=
e (and it's definitely not a
> parallel construction with (a)-(c)=
!).=C2=A0 I think perhaps a crisp one-line
> summary of this method w=
ould be "Delegating the authorization check to a
> separate &quo=
t;Request Object to Request Object URI" endpoint on the
> Author=
ization Server". =C2=A0(The writing in the rest of this paragraph coul=
d
> also use an editing pass.)

Thanks for po=
inting it out. Changing as follows would be ok?=C2=A0

<=
div>=
(d) When=C2=A0Authorization Server is providing an endpoint that provide=
s a
=
Request Object URI in exchange for a Request Object,=C2=A0
<=
div>=
the Authorization Server MUST perform Client
Authentication to accept the Reque=
st Object and bind the Client
Identifier to the Request Object URI it is provid=
ing. Since
Request Object URI can be replayed, the lifetime of the Request
Object U=
RI MUST be short and preferably one-time use. The
entropy of the Request Object=
 URI MUST be sufficiently large.
The adequate shortness of the validity and the=
 entropy of the
Request Object URI depends on the risk calculation based on the=

val=
ue of the resource being protected. A general guidance for
the validity time w=
ould be less than a minute and the Request
Object URI is to include a cryptogra=
phic random value of 128bit
or more at the time of the writing of this specific=
ation.=C2=A0=C2=A0

>
> =C2=A0 =C2=A0(e) =C2=
=A0A third party, such as a Trust Framework Provider, provides an
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoint that provides a Request Object URI in =
exchange for a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object.=C2=A0 Th=
e same requirements as (b) above apply.=C2=A0 In
> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 addition, the Authorization Server MUST know out-of-band that> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Client utilizes the Trust Framework O=
perator.
>
> The Authorization Server also has to trust the thi=
rd-party provider to
> actually do its job and not misbehave, right?<=
/div>

Yes. I will add wording around it.=C2=A0

>
> Section 10.3
>
> I'm not entirely sure wh=
at "[t]he endpoints that come into question in
> this specificat=
ion" is supposed to mean -- is it just "the OAuth 2.0
> end=
points presently defined in Standards-Track RFCs"?

Yes. RFC6749, RFC6750, and RFC8414.=C2=A0

>
> =
=C2=A0 =C2=A0In [RFC6749], while Redirection URI is included, others are no=
t
> =C2=A0 =C2=A0included in the Authorization Request.=C2=A0 As the =
result, the same
> =C2=A0 =C2=A0applies to Authorization Request Obje=
ct.
>
> nit: included in what?

In the =
Authorization request.=C2=A0
I thought it would be too onerous to=
 state

OAuth@ietf=
.org
> ht=
tps://www.ietf.org/mailman/listinfo/oauth



-- 
Nat Sak=
imura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


--0000000000000f1a9f058e99a314--


From nobody Fri Jul 26 13:47: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 5CF8112014F for ; Fri, 26 Jul 2019 13:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaglBMAEV3FM for ; Fri, 26 Jul 2019 13:47:43 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C043712011B for ; Fri, 26 Jul 2019 13:47:42 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id f4so107532492ioh.6 for ; Fri, 26 Jul 2019 13:47:42 -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=fzDVOGa0AyOrAlqob0LXyik5EFGfglIdEZM3l1m7Vuo=; b=Q9o+93idyVJxw5lxcPgruKKO2kf3/gXgT0atSJtGsSiZXhHgrdeVb8qxm1ZFRLeKMp PGBpKZq2bhawn++ksCHyCJCXag1h7kVmY7cPxG2nqj4kRpIFu5xfW2CrlqH7p6ckUWO5 jiGfAKH2laMRLpT6kPf27zc1R8Jt0tEfMla9A=
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=fzDVOGa0AyOrAlqob0LXyik5EFGfglIdEZM3l1m7Vuo=; b=MSyTKessAm8hP16tH0XEGEb2B9tpBSjFOzD4+taIGH1Rw+bWgP4lOEPIaNTyg+NZhT oaHWANA8NdpDaz12FHxLyGr45B15JJUR16APN57AsPLP1BLJvwOfEscyK8qNCJVcjrft vrxntGMIdnN6dWkh9Van5MF//ruupg7mZvDsAzzQMWfDp6ar8epNpvWGz2Zs/B0ueW6e 8iIVhMPgSE0n4OMTGDPmpvTa5fQJyYf+iAI98/gXXKw8d4lwoaTbIO09oYCRnFu2eR/N MwD9CQ1ECpviA4jQ9/lwyfoq8reG32fnuZDUCfj/7jV1tMqUBS1rFsHuLHNCGBg7Cr81 qKlg==
X-Gm-Message-State: APjAAAVEtwSfqegd/AWttR28xaZwoE6wKs1+r5GnlNl5uuhdpnL/2D+5 EUKadC7maAamU+2DLDit34v9PIJr+1XGiOufFHm2+rQZj20uWefoBRwf6A/ezaK4vySBurKpxc5 cLuYgdya4hpFcBQ==
X-Google-Smtp-Source: APXvYqyyH0srwoCMg/oW2iLWLBJzF+t/vb2pUhlhzWTlD+a2VgAoAMHzc9VjwTyAbrU/GWuC744kXSR4FZzLoNe3gHU=
X-Received: by 2002:a6b:fd10:: with SMTP id c16mr85167719ioi.217.1564174061783;  Fri, 26 Jul 2019 13:47:41 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com> 
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 26 Jul 2019 14:47:15 -0600
Message-ID: 
To: Nat Sakimura 
Cc: Benjamin Kaduk , draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, The IESG , oauth 
Content-Type: multipart/alternative; boundary="00000000000051e993058e9ba717"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jul 2019 20:47:49 -0000

--00000000000051e993058e9ba717
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nat, you suggest that the "simplest solution probably is to register the
authorization request parameters to the JWT Claims registry." However, as
I've attempted to articulate several times this week (
https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and
muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
even back in 2017 (
https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I
believe the pragmatic solution to this is to register some of the main JWT
claims into the OAuth parameters registry (not the other way around, as
you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an
authorization request parameter "aud", which would conflicted with the JWT
claim of the same name and cause big problems when used together with JAR).
I suppose the iron clad way to "fix" this would be to merge the two
registries and keep them in sync forever. But that seems awfully heavy
handed and unnecessary. JAR is a specific application of JWT being used to
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely
point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization
request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's
necessary or even useful to pollute the JWT claims registry with the names
of all the authorization request parameters. I happen to be one of the DEs
on the JWT claims registry so, in theory, I have some idea what I'm talking
about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of
authorization request parameters into the JWT claims registry without
without more compelling reason.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:

>
> Thanks very much for the comments.
> Here are my responses to your comments.
>
> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > My apologies; my previous position was incomplete.  Updated to note
> > namespacing issues, and one minor terminology nit about "DNS-ID".
> >
> > There seem to be some pretty serious namespacing issues that are not
> > discussed at all in this document.  Specifically, using JWT as a
> > container for OAuth 2.0 authorization request parameters (including
> > extension parameters) introduces the usage of many new names (of JSON
> > name/value pairs) into the JWT claims namespace.  Furthermore, the
> > addition is not bounded, as any new OAuth extension parameters are
> > implicitly permitted to be used as well!  The IANA Considerations make
> > no mention of the collapsed namespace for JWT claims and OAuth 2.0
> > (authorization request) parameters, leaving substantial potential for
> > collisions in the future.
>
> The simplest solution probably is to register the authorization request
> parameters to the JWT Claims registry.
> According to my checking, the relevant but not yet registered parameters
> are:
>
> Claim Name: "code_challenge"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "code_challenge_method"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "redirect_uri"
> Claim Description: OAuth Redirection URI
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: "response_type"
> Claim Description: OAuth Authorization Response type
> Change Controller: IETF
> Specification Document(s): Section 3.1.1 of RFC 6749
>
> Claim Name: "state"
> Claim Description: OAuth state parameter
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: "vtr"
> Claim Description: Vector of Trust request
> Change Controller: IESG
> Specification Document(s): Section 4.1 of RFC 8485
>
> > Relatedly, using "application/jwt" as the Content-type of the
> > HTTP response from dereferencing the request_uri with no explicit
> > indication of the type/profile of JWT used (whether in the content type
> > or in the JWT claims themselves) gives some risk of misinterpretation o=
f
> > the content..  Consider, for example, when that request_uri is
> > dereferenced not by the authorization server in the process of
> > fulfilling an authorization request, but instead by some other service
> > that expects a different type of JWT.
>
> I am making the change to "application/oauth-authz-req+jwt" and add IANA
> request.
>
> >
> > This second point is a "discuss discuss" -- it's an important question
> > and I'd like to talk about it, but it's not clear that any change to th=
e
> > document will be needed.
> >
> > The introduction notes as an advantage of JWT that:
> >
> >    (d)  (collection minimization) The request can be signed by a third
> >         party attesting that the authorization request is compliant wit=
h
> >         a certain policy.  For example, a request can be pre-examined b=
y
> >         a third party that all the personal data requested is strictly
> >         necessary to perform the process that the end-user asked for,
> >         and statically signed by that third party.  The authorization
> >         server then examines the signature and shows the conformance
> >         status to the end-user, who would have some assurance as to the
> >         legitimacy of the request when authorizing it.  In some cases,
> >         it may even be desirable to skip the authorization dialogue
> >         under such circumstances.
> >
> > I'm pretty uncomfortable about suggesting that the authorization
> > dialogue can/should be skipped; do we need to keep this example?
> >
>
> I have actually deliberately put this text as there seem to be some
> disconnect between the engineering community and the privacy regulators
> community. Asking for "consent" is something that should be considered as
> an exception and should use other lawful basis if possible as UK ICO (The
> data protection regulator in the UK) advises. As the editor of "ISO/IEC
> 29184 Privacy notice and consent", which is being developed with close
> coordination with regulators such as European Data Protection Board, I
> would have to agree to that position and I took OAuth JAR as one of the
> opportunity to call it out. I will add some text explaining it such as:
>
> In some cases, it is deemed harmful to ask for consent when it is not
> necessary: i.e., the processing is performed under other lawful basis tha=
n
> consent, as it would make the consent, that should be an exception, stand
> out less. Under such circumstances, this mechanism can be used to skip th=
e
> authorization dialogue.
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1
> >
> >    While it is easy to implement, the encoding in the URI does not allo=
w
> >    application layer security with confidentiality and integrity
> >    protection to be used.  While TLS is used to offer communication
> >
> > nit: this wording is a little hard to read; it might be easier to
> > reorder to "does not allow application layer security to be used to
> > provide confidentiality and integrity protection".
>
> Thanks. I will make the change.
>
> >
> >    The use of application layer security allows requests to be prepared
> >    by a third party so that a client application cannot request more
> >    permissions than previously agreed.  This offers an additional degre=
e
> >    of privacy protection.
> >
> > (side note) what would an example of such a third party be.  (We alread=
y
> > have the resource owner, the client, and the authorization server ...
> > maybe it's a fourth party?)
>
> It is a fourth party, e.g., a trust framework provider or an information
> fiduciary.
> The text need to be modified though as I found an error.
> Since now all the OAuth Request parameters must be in the request object,
> only the pattern that can be supported for something like this is to push
> the request object to the TFP and have the TFP check if it meets the poli=
cy
> and return request_uri only it is evelauted as OK.
>
> >
> >    Furthermore, the request by reference allows the reduction of over-
> >    the-wire overhead.
> >
> > We only barely mentioned by-reference at this point (one line in the
> > Abstract), so I'd suggest "passing the request by reference".
>
> Thanks. I will make the change.
>
> >
> >    (4)  its development status that it is an RFC and so is its
> >         associated signing and encryption methods as [RFC7515] and
> >         [RFC7516]
> >
> > nit: I'd suggest "its development status as a Proposed Standard, along
> > with the associated signing and encryption methods [RFC7515] [RFC7516].=
"
>
> Thanks. I will make the change.
>
> >
> >    (c)  (confidentiality protection) The request can be encrypted so
> >         that end-to-end confidentiality can be provided even if the TLS
> >         connection is terminated at one point or another.
> >
> > nit: TLS is always terminated at or before the user-agent, though.  So
> > maybe the user agent needs to get called out here as well (there could
> > of course be TLS termination earlier than the user-agent in some cases,
> > too).
>
> Thanks. I will make the change.
>
> >
> >    2.  When the client does not want to do the crypto.  The
> >        Authorization Server may provide an endpoint to accept the
> >        Authorization Request through direct communication with the
> >        Client so that the Client is authenticated and the channel is TL=
S
> >        protected.
> >
> > How can you "not want to do [the] crypto" but still be doing TLS (with
> > crypto)?  Perhaps we're looking for "not want to pay the additional
> > overhead of JWS/JWE cryptography on top of TLS"?
>
> Thanks. I will make the change.
>
> >
> > Section 1.1
> >
> > RFC 8174 has updated BCP 14 boilerplate text to use.
>
> Thanks. I will make the change.
>
> >
> > Section 3
> >
> > nit: should this section be 2.3 to get wrapped into "terminology"?
>
> It could, but I suppose it could be as is.
>
> >
> > It might also be worth putting references in for the terms, though they
> > are largely common knowledge at this point.
>
> Hopefully, they are public knowledge ...
>
> >
> > Section 4
> >
> >    A Request Object (Section 2.1) is used to provide authorization
> >    request parameters for an OAuth 2.0 authorization request.  It MUST
> >    contains all the OAuth 2.0 [RFC6749] authorization request parameter=
s
> >    including extension parameters.  The parameters are represented as
> >
> > nit: "all the parameters" kind of sounds like "all that are defined"..
> > But I think the intent here is "any parameter used to process the
> > request must come from the request object and URL query parameters are
> > ignored", so maybe "MUST contain all the parameters (including extensio=
n
> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
> > request; parameters from other sources MUST NOT be used", akin to what
> > we say down in Sections 5 and 6.3..
> > But we need to be careful about the wording to not exclude the usage of
> > the "request" and "request_uri" query parameters to  find the Request
> > Object!
>
> Thanks. I will make the description more exact.
>
> >
> >    the JWT claims.  Parameter names and string values MUST be included
> >
> > nit: maybe "the JWT claims of the object"?
>
> Thanks. I will probably make it "the JWT claims of the request object."
>
> >
> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
> >    signed or signed and encrypted.
> >
> > nit: I  think we want "This JSON [RFC7159] object".
>
> Thanks. I will fix it as suggested.
>
> >
> > (Long quote incoming)
> >
> >    The following is an example of the Claims in a Request Object before
> >    base64url encoding and signing.  Note that it includes extension
> >    variables such as "nonce" and "max_age".
> >
> >      {
> >       "iss": "s6BhdRkqt3",
> >       "aud": "https://server..example.com "=
,
> >       "response_type": "code id_token",
> >       "client_id": "s6BhdRkqt3",
> >       "redirect_uri": "https://client..example.org/cb
> ",
> >       "scope": "openid",
> >       "state": "af0ifjsldkj",
> >       "nonce": "n-0S6_WzA2Mj",
> >       "max_age": 86400
> >      }
> >
> >    Signing it with the "RS256" algorithm results in this Request Object
> >    value (with line wraps within values for display purposes only):
> >
> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
> >
> > Decoding the base64 of the body, we see:
> > {
> >  "iss": "s6BhdRkqt3",
> >  "aud": "https://server.example.com",
> >  "response_type": "code id_token",
> >  "client_id": "s6BhdRkqt3",
> >  "redirect_uri": "https://client.example.org/cb
> ",
> >  "scope": "openid",
> >  "state": "af0ifjsldkj",
> >  "nonce": "n-0S6_WzA2Mj",
> >  "max_age": 86400,
> >  "claims":
> >   {
> >    "userinfo":
> >     {
> >      "given_name": {"essential": true},
> >      "nickname": null,
> >      "email": {"essential": true},
> >      "email_verified": {"essential": true},
> >      "picture": null
> >     },
> >    "id_token":
> >     {
> >      "gender": null,
> >      "birthdate": {"essential": true},
> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> >     }
> >   }
> > }
> >
> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> > seem to talk about it.  (Note that this example is used later on as
> > well.)
>
> It is an extension parameter that is registered in the OAuth authorizatio=
n
> request registry.
> It is defined in OpenID Connect Core and OIDF is in the process of
> registering it to the JWT Claims registry as well. I have put them to sho=
w
> that extension parameters can also be used in the request object. Having
> said that, they may be confusing. I should just remove them.
>
> >
> > Section 5.2.1
> >
> >    It is possible for the Request Object to include values that are to
> >    be revealed only to the Authorization Server.  As such, the
> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
> >    that it be removed after a reasonable timeout unless access control
> >    measures are taken.
> >
> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> > also be useful.
> >
>
> Thanks. I will add it.
>
> > Section 5.2.2
> >
> > Do we want to remind the reader that the other query parameters are jus=
t
> > for backwards compatibility?
>
> It is probably be better to remove them as they are not allowed to be
> used.
>
> >
> > Section 5.2.3
> >
> >    The following is an example of this fetch process:
> >
> >      GET /request.jwt HTTP/1.1
> >      Host: tfp.example.org
> >
> > It's useful to show good hygeine in examples; can we get the extra
> > entropy in this request that we have in the previous example(s)?
>
> Thanks for pointing out. I will fix it. (The previous example also needs
> to be changed.)
>
> >
> > Section 6.2
> >
> >    The Authorization Server MUST perform the signature validation of th=
e
> >    JSON Web Signature [RFC7515] signed request object.  For this, the
> >    "alg" Header Parameter in its JOSE Header MUST match the value of th=
e
> >    pre-registered algorithm..  The signature MUST be validated against
> >    the appropriate key for that "client_id" and algorithm.
> >
> > Does "the pre-registered algorithm" concept exist in the specs outside
> > of draft-ietf-oauth-jwt-bcp?
>
> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
> Metadata registry forms the concept. RFC7591 allows clients to register t=
he
> claims that is in the OAuth Dynamic Client Registration Metadata registry=
.
> The registry has
>
>    - request_object_signing_alg
>    - request_object_encryption_alg
>
> besides others. Having said that, it is a bit obscure so I probably shoul=
d
> put some more explanation around it.
>
> >
> > Section 8
> >
> >    HTTP clients MUST also verify the TLS server certificate, using
> >    subjectAltName dNSName identities as described in [RFC6125], to avoi=
d
> >    man-in-the-middle attacks.  The rules and guidelines defined in
> >
> > It's probably easier to just say "using DNS-ID [RFC6125], to avoid
> > man-in-the-middle attacks".
>
> Thanks. I will do so.
>
> >
> > Section 9
> >
> > The error codes we list in Section 7 are already registered, for the
> > OIDC usage.  Do we want to say anything about that?   (I guess it would
> > be disallowed by process to try to update the existing registration to
> > also point at this document.)
>
> OIDC is an extension of OAuth and it should be fine as is.
> What we need to be careful is that there will be no conflict going
> forward.
> I will put the instruction update that will be provided by Mike (Jones).
>
> >
> > Section 10
> >
> > We probably also want to reference draft-ietf-oauth-jwt-bcp.
>
> Thanks. I will put the reference as draft.
>
> >
> > Section 10.1
> >
> >    When sending the authorization request object through "request"
> >    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
> >    using JWE [RFC7516] with then considered appropriate algorithm.
> >
> > Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
> > similarly, in Section 4 we reiterate "signed then encrypted".  Why is i=
t
> > okay to talk about just "signed or encrypted" here?
>
> Very good catch. It should be changed to align with other sections.
>
> >
> > Section 10.2
> >
> >    (b)  Verifying that the symmetric key for the JWE encryption is the
> >         correct one if the JWE is using symmetric encryption.
> >
> > Similarly to the previous point, you also need to check the signature,
> > which will always be there.
>
> You are right. This one should be removed.
>
> >
> >    (d)  Authorization Server is providing an endpoint that provides a
> >         Request Object URI in exchange for a Request Object.  In this
> >
> > I don't think this is a complete sentence (and it's definitely not a
> > parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
> > summary of this method would be "Delegating the authorization check to =
a
> > separate "Request Object to Request Object URI" endpoint on the
> > Authorization Server".  (The writing in the rest of this paragraph coul=
d
> > also use an editing pass.)
>
> Thanks for pointing it out. Changing as follows would be ok?
>
> (d) When Authorization Server is providing an endpoint that provides a
> Request Object URI in exchange for a Request Object,
> the Authorization Server MUST perform Client
> Authentication to accept the Request Object and bind the Client
> Identifier to the Request Object URI it is providing. Since
> Request Object URI can be replayed, the lifetime of the Request
> Object URI MUST be short and preferably one-time use. The
> entropy of the Request Object URI MUST be sufficiently large.
> The adequate shortness of the validity and the entropy of the
> Request Object URI depends on the risk calculation based on the
> value of the resource being protected. A general guidance for
> the validity time would be less than a minute and the Request
> Object URI is to include a cryptographic random value of 128bit
> or more at the time of the writing of this specification.
>
> >
> >    (e)  A third party, such as a Trust Framework Provider, provides an
> >         endpoint that provides a Request Object URI in exchange for a
> >         Request Object.  The same requirements as (b) above apply.  In
> >         addition, the Authorization Server MUST know out-of-band that
> >         the Client utilizes the Trust Framework Operator.
> >
> > The Authorization Server also has to trust the third-party provider to
> > actually do its job and not misbehave, right?
>
> Yes. I will add wording around it.
>
> >
> > Section 10.3
> >
> > I'm not entirely sure what "[t]he endpoints that come into question in
> > this specification" is supposed to mean -- is it just "the OAuth 2.0
> > endpoints presently defined in Standards-Track RFCs"?
>
> Yes. RFC6749, RFC6750, and RFC8414.
>
> >
> >    In [RFC6749], while Redirection URI is included, others are not
> >    included in the Authorization Request.  As the result, the same
> >    applies to Authorization Request Object.
> >
> > nit: included in what?
>
> In the Authorization request.
> I thought it would be too onerous to state
>
> In [RFC6749], while Redirection URI is included in the Authorization
>> Request,
>> others are not included in the Authorization Request.  As the result, th=
e
>> same
>> applies to Authorization Request Object.
>
>
> Would you like to add "in the Authorization Request" as above?
>
> >
> > Section 10.4
> >
> > It's probably also worth citing the generic URI security considerations
> > from RFC 3986, here.
>
> I will do so. Thanks.
>
> >
> > Section 10.4.1
> >
> >    "request_uri", and (d) do not perform recursive GET on the
> >    "request_uri".
> >
> > nit: remove the "do" in order to make the construction parallel.
>
> Thanks. I will do so.
>
> >
> > Section 12.1
> >
> >    It is often hard for the user to find out if the personal data asked
> >    for is strictly necessary.  A Trust Framework Provider can help the
> >    user by examining the Client request and comparing to the proposed
> >    processing by the Client and certifying the request.  After the
> >    certification, the Client, when making an Authorization Request, can
> >    submit Authorization Request to the Trust Framework Provider to
> >    obtain the Request Object URI.
> >
> > side note: In my head the act of certification was the act of making th=
e
> > translation to a Request Object URI, so I'm kind of curious where my
> > vision differs from reality.
>
> So, I should probably expand the text.
> The process is two steps:
>
> 1. (Certification Process) The TFP examines the business process of the
> client and determines what claims they needs: This is the certification
> process. Once the client is certified, then they are issued a client
> credential to authenticate against to push request objects to the TFP to
> get the request_uri.
>
> 2. (Translation Process) The client uses the client credential that it go=
t
> to push the request object to the TFP to get the request_uri.
>
> >
> > The third paragraph seems to mostly just be describing the procedure of
> > how this flow works, which would not necessarily be specific to the
> > privacy considerations section.
>
> The third paragraph is also important from the privacy point of view.
> In a trust framework that has a policy to only allow TFP vetted request
> object,
> then the Authorization Server must make sure that it was.
> One way to do it is to check the authority section.
>
> >
> > Section 12.2.2
> >
> >    Even if the protected resource does not include a personally
> >    identifiable information, it is sometimes possible to identify the
> >    user through the Request Object URI if persistent per-user Request
> >    Object URI is used.  A third party may observe it through browser
> >
> > nit: need an article for "persistent per-user Request Object URI" (or
> > make it plural, as "URIs are used").
>
> Thanks. I will fix it.
>
> >
> >    Therefore, per-user Request Object URI should be avoided.
> >
> > nit: I think this is better as "static per-user Requeste Object URIs".
>
> Thanks. I will fix it.
>
> >
> > Section 13
> >
> > Are there two different paragraphs for "contributions from the OAuth WG
> > members"?  Are they reflecting different types of contribution?
>
> Thanks. I have merged them.
>
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf..org 
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

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


Nat, you suggest that the "simp=
lest solution probably is to register the authorization request parameters =
to the JWT Claims registry." However, as I've attempted to articul=
ate several times this week (https://mailarchive=
.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and muliple commen=
ts on https://bitbucket.org/openid/connect/issues/1019) and even =
back in 2017 (https://mailarchive.ietf.org/arch/=
msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I believe the pragmatic solutio=
n to this is to register some of the main JWT claims into the OAuth paramet=
ers registry (not the other way around, as you're suggesting which woul=
dn't even have caught the one name collision we've actually had whe=
re a draft, more than one actually, wanted to call an authorization request=
 parameter "aud", which would conflicted with the JWT claim of th=
e same name and cause big problems when used together with JAR). I suppose =
the iron clad way to "fix" this would be to merge the two registr=
ies and keep them in sync forever. But that seems awfully heavy handed and =
unnecessary. JAR is a specific application of JWT being used to convey an O=
Auth authz request. JAR explicitly uses a few core JWT claims (aud, iss) an=
d one could reasonably imagine other core ones being used as well (exp, iat=
, nbf, jti, etc). An authorization request parameter being introduced that =
uses one of those names is far and away the most likely point of collision =
(and has already happened, as noted previously). A new JWT claim being intr=
oduced that collides with an existing authorization request parameter name =
AND would be used in the context of JAR is far far less likely to happen. S=
o unlikely, in fact, that I don't think it's necessary or even usef=
ul to pollute the JWT claims registry with the names of all the authorizati=
on request parameters. I happen to be one of the DEs on the JWT claims regi=
stry so, in theory, I have some idea what I'm talking about here. In th=
eory. And I do have to be upfront at this point and say that I will push ba=
ck on a request for registration of a bunch of authorization request parame=
ters into the JWT claims registry without without more compelling reason. =
=C2=A0 

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <sakimura@gmail.com> wrot=
e:

Thanks very much for the comments.=C2=A0
Here are my responses =
to your comments.=C2=A0

On Wed, Jul 3, 2019 at 2:59 PM Benjam=
in Kaduk via Datatracker <noreply@ietf.org> wrote:
>
> Benjamin Kaduk has =
entered the following ballot position for
> draft-ietf-oauth-jwsreq-1=
9: Discuss
>
> When responding, please keep the subject line in=
tact and reply to all
> email addresses included in the To and CC lin=
es. (Feel free to cut this
> introductory paragraph, however.)
>=
;
>
> Please refer to https://www.ietf.org/iesg/st=
atement/discuss-criteria.html
> for more information about IESG D=
ISCUSS and COMMENT positions.
>
>
> The document, along w=
ith other ballot positions, can be found here:
> https:/=
/datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>
&=
gt;
> ---------------------------------------------------------------=
-------
> DISCUSS:
> ------------------------------------------=
----------------------------
>
> My apologies; my previous posi=
tion was incomplete.=C2=A0 Updated to note
> namespacing issues, and =
one minor terminology nit about "DNS-ID".
>
> There s=
eem to be some pretty serious namespacing issues that are not
> discu=
ssed at all in this document.=C2=A0 Specifically, using JWT as a
> co=
ntainer for OAuth 2.0 authorization request parameters (including
> e=
xtension parameters) introduces the usage of many new names (of JSON
>=
; name/value pairs) into the JWT claims namespace.=C2=A0 Furthermore, the> addition is not bounded, as any new OAuth extension parameters are> implicitly permitted to be used as well!=C2=A0 The IANA Consideratio=
ns make
> no mention of the collapsed namespace for JWT claims and OA=
uth 2.0
> (authorization request) parameters, leaving substantial pot=
ential for
> collisions in the future.

The simplest solution p=
robably is to register the authorization request parameters to the JWT Clai=
ms registry.
According to my checking, the relevant but not yet register=
ed parameters are:

Claim Name: "code_challenge"
Claim D=
escription: OAuth PKCE Code Challenge
Change Controller: IESG
Specifi=
cation Document(s): Section 3 of RFC 7636

Claim Name: "code_cha=
llenge_method"
Claim Description: OAuth PKCE Code Challenge
Chan=
ge Controller: IESG
Specification Document(s): Section 3 of RFC 7636
=

Claim Name: "redirect_uri"
Claim Description: OAuth Redire=
ction URI
Change Controller: IETF
Specification Document(s): Section =
4.1.1 of RFC 6749

Claim Name: "response_type"
Claim Des=
cription: OAuth Authorization Response type
Change Controller: IETF
S=
pecification Document(s): Section 3.1.1 of RFC 6749

Claim Name: &quo=
t;state"
Claim Description: OAuth state parameter
Change Control=
ler: IETF
Specification Document(s): Section 4.1.1 of RFC 6749

Cl=
aim Name: "vtr"
Claim Description: Vector of Trust request
=
Change Controller: IESG
Specification Document(s): Section 4.1 of RFC 84=
85

> Relatedly, using "application/jwt" as the Content-=
type of the
> HTTP response from dereferencing the request_uri with n=
o explicit
> indication of the type/profile of JWT used (whether in t=
he content type
> or in the JWT claims themselves) gives some risk of=
 misinterpretation of
> the content..=C2=A0 Consider, for example, wh=
en that request_uri is
> dereferenced not by the authorization server=
 in the process of
> fulfilling an authorization request, but instead=
 by some other service
> that expects a different type of JWT.
I am making the change to "application/oauth-authz-req+jwt" and =
add IANA request.

>
> This second point is a "discuss =
discuss" -- it's an important question
> and I'd like to=
 talk about it, but it's not clear that any change to the
> docum=
ent will be needed.
>
> The introduction notes as an advantage =
of JWT that:
>
> =C2=A0 =C2=A0(d) =C2=A0(collection minimizatio=
n) The request can be signed by a third
> =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 party attesting that the authorization request is compliant with
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a certain policy.=C2=A0 For example, a request =
can be pre-examined by
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a third party th=
at all the personal data requested is strictly
> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 necessary to perform the process that the end-user asked for,
&g=
t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 and statically signed by that third party.=
=C2=A0 The authorization
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 server then ex=
amines the signature and shows the conformance
> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 status to the end-user, who would have some assurance as to the
=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimacy of the request when authorizing=
 it.=C2=A0 In some cases,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 it may even b=
e desirable to skip the authorization dialogue
> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 under such circumstances.
>
> I'm pretty uncomforta=
ble about suggesting that the authorization
> dialogue can/should be =
skipped; do we need to keep this example?
>

I have actually de=
liberately put this text as there seem to be some disconnect between the en=
gineering community and the privacy regulators community. Asking for "=
consent" is something that should be considered as an exception and sh=
ould use other lawful basis if possible as UK ICO (The data protection regu=
lator in the UK) advises. As the editor of "ISO/IEC 29184 Privacy noti=
ce and consent", which is being developed with close coordination with=
 regulators such as European Data Protection Board, I would have to agree t=
o that position and I took OAuth JAR as one of the opportunity to call it o=
ut. I will add some text explaining it such as:=C2=A0

<=
div>In some cases, it is deemed harmful to ask for consent when it is not n=
ecessary: i.e., the processing is performed under other lawful basis than c=
onsent, as it would make the consent, that should be an exception, stand ou=
t less. Under such circumstances, this mechanism can be used=C2=A0to skip t=
he authorization dialogue.=C2=A0=C2=A0

>
> ----------------=
------------------------------------------------------
> COMMENT:
=
> ----------------------------------------------------------------------=

>
> Section 1
>
> =C2=A0 =C2=A0While it is easy to=
 implement, the encoding in the URI does not allow
> =C2=A0 =C2=A0app=
lication layer security with confidentiality and integrity
> =C2=A0 =
=C2=A0protection to be used.=C2=A0 While TLS is used to offer communication=

>
> nit: this wording is a little hard to read; it might be ea=
sier to
> reorder to "does not allow application layer security =
to be used to
> provide confidentiality and integrity protection"=
;.

Thanks. I will make the change.

>
> =C2=A0 =C2=A0=
The use of application layer security allows requests to be prepared
>=
; =C2=A0 =C2=A0by a third party so that a client application cannot request=
 more
> =C2=A0 =C2=A0permissions than previously agreed.=C2=A0 This o=
ffers an additional degree
> =C2=A0 =C2=A0of privacy protection.
&=
gt;
> (side note) what would an example of such a third party be. =C2=
=A0(We already
> have the resource owner, the client, and the authori=
zation server ...
> maybe it's a fourth party?)

It is a fo=
urth party, e.g., a trust framework provider or an information fiduciary.The text need to be modified though as I found an error.
Since now all=
 the OAuth Request parameters must be in the request object,
only the pa=
ttern that can be supported for something like this is to push
the reque=
st object to the TFP and have the TFP check if it meets the policy
and r=
eturn request_uri only it is evelauted as OK.

>
> =C2=A0 =
=C2=A0Furthermore, the request by reference allows the reduction of over-> =C2=A0 =C2=A0the-wire overhead.
>
> We only barely menti=
oned by-reference at this point (one line in the
> Abstract), so I=
9;d suggest "passing the request by reference".

Thanks. I =
will make the change.

>
> =C2=A0 =C2=A0(4) =C2=A0its develo=
pment status that it is an RFC and so is its
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 associated signing and encryption methods as [RFC7515] and
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7516]
>
> nit: I'd suggest =
"its development status as a Proposed Standard, along
> with the=
 associated signing and encryption methods [RFC7515] [RFC7516]."
Thanks. I will make the change.

>
> =C2=A0 =C2=A0(c) =C2=
=A0(confidentiality protection) The request can be encrypted so
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 that end-to-end confidentiality can be provided ev=
en if the TLS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection is terminated =
at one point or another.
>
> nit: TLS is always terminated at o=
r before the user-agent, though.=C2=A0 So
> maybe the user agent need=
s to get called out here as well (there could
> of course be TLS term=
ination earlier than the user-agent in some cases,
> too).

Tha=
nks. I will make the change.

>
> =C2=A0 =C2=A02.=C2=A0 When=
 the client does not want to do the crypto.=C2=A0 The
> =C2=A0 =C2=A0=
 =C2=A0 =C2=A0Authorization Server may provide an endpoint to accept the> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Request through direct commu=
nication with the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Client so that the Cli=
ent is authenticated and the channel is TLS
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0protected.
>
> How can you "not want to do [the] cry=
pto" but still be doing TLS (with
> crypto)?=C2=A0 Perhaps we=
9;re looking for "not want to pay the additional
> overhead of J=
WS/JWE cryptography on top of TLS"?

Thanks. I will make the cha=
nge.

>
> Section 1.1
>
> RFC 8174 has updated B=
CP 14 boilerplate text to use.

Thanks. I will make the change. 
<=
br>>
> Section 3
>
> nit: should this section be 2.3 t=
o get wrapped into "terminology"?

It could, but I suppose =
it could be as is. 

>
> It might also be worth putting refe=
rences in for the terms, though they
> are largely common knowledge a=
t this point.

Hopefully, they are public knowledge ... 

><=
br>> Section 4
>
> =C2=A0 =C2=A0A Request Object (Section 2.=
1) is used to provide authorization
> =C2=A0 =C2=A0request parameters=
 for an OAuth 2.0 authorization request.=C2=A0 It MUST
> =C2=A0 =C2=
=A0contains all the OAuth 2.0 [RFC6749] authorization request parameters> =C2=A0 =C2=A0including extension parameters.=C2=A0 The parameters are=
 represented as
>
> nit: "all the parameters" kind of=
 sounds like "all that are defined"..
> But I think the int=
ent here is "any parameter used to process the
> request must co=
me from the request object and URL query parameters are
> ignored&quo=
t;, so maybe "MUST contain all the parameters (including extension
=
> parameters) used to process the OAuth 2.0 [RFC6749] authorization
&=
gt; request; parameters from other sources MUST NOT be used", akin to =
what
> we say down in Sections 5 and 6.3..
> But we need to be =
careful about the wording to not exclude the usage of
> the "req=
uest" and "request_uri" query parameters to =C2=A0find the R=
equest
> Object!

Thanks. I will make the description more exac=
t. 

>
> =C2=A0 =C2=A0the JWT claims.=C2=A0 Parameter names =
and string values MUST be included
>
> nit: maybe "the JWT=
 claims of the object"?

Thanks. I will probably make it "t=
he JWT claims of the request object."

>
> =C2=A0 =C2=
=A0any extension parameters.=C2=A0 This JSON [RFC7159] constitutes the JWT<=
br>> =C2=A0 =C2=A0Claims Set defined in JWT [RFC7519].=C2=A0 The JWT Cla=
ims Set is then
> =C2=A0 =C2=A0signed or signed and encrypted.
>=
;
> nit: I =C2=A0think we want "This JSON [RFC7159] object"=
.

Thanks. I will fix it as suggested. 

>
> (Long quo=
te incoming)
>
> =C2=A0 =C2=A0The following is an example of th=
e Claims in a Request Object before
> =C2=A0 =C2=A0base64url encoding=
 and signing.=C2=A0 Note that it includes extension
> =C2=A0 =C2=A0va=
riables such as "nonce" and "max_age".
>
> =
=C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 "iss": "s=
6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "aud": "https://server..example.=
com",
> =C2=A0 =C2=A0 =C2=A0 "response_type": &quo=
t;code id_token",
> =C2=A0 =C2=A0 =C2=A0 "client_id": =
"s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "redirect_uri&quo=
t;: "https=
://client..example.org/cb",
> =C2=A0 =C2=A0 =C2=A0 "sco=
pe": "openid",
> =C2=A0 =C2=A0 =C2=A0 "state"=
;: "af0ifjsldkj",
> =C2=A0 =C2=A0 =C2=A0 "nonce":=
 "n-0S6_WzA2Mj",
> =C2=A0 =C2=A0 =C2=A0 "max_age"=
: 86400
> =C2=A0 =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0Signing =
it with the "RS256" algorithm results in this Request Object
&=
gt; =C2=A0 =C2=A0value (with line wraps within values for display purposes =
only):
>
> =C2=A0 =C2=A0 =C2=A0eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy=
YmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> =C2=A0 =C2=A0 =C2=A0F0MyIsDQogIm=
F1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> =C2=A0 =C2=
=A0 =C2=A0c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzN=
k
> =C2=A0 =C2=A0 =C2=A0JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHB=
zOi8vY2xpZW50LmV4YW1w
> =C2=A0 =C2=A0 =C2=A0bGUub3JnL2NiIiwNCiAic2Nvc=
GUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> =C2=A0 =C2=A0 =C2=A0Zqc2x=
ka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> =C2=
=A0 =C2=A0 =C2=A0ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCi=
AgICB7DQ
> =C2=A0 =C2=A0 =C2=A0ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRp=
YWwiOiB0cnVlfSwNCiAgICAgIm5p
> =C2=A0 =C2=A0 =C2=A0Y2tuYW1lIjogbnVsbC=
wNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> =C2=A0 =C2=A0 =C2=
=A0wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
&g=
t; =C2=A0 =C2=A0 =C2=A0ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tl=
biI6IA0KICAgIH
> =C2=A0 =C2=A0 =C2=A0sNCiAgICAgImdlbmRlciI6IG51bGwsDQ=
ogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> =C2=A0 =C2=A0 =C2=A0dGlhbCI6IHRy=
dWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> =C2=A0 =C2=
=A0 =C2=A0luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnv=
s
> =C2=A0 =C2=A0 =C2=A0F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPY=
s8KQxsn6R9Emo_wHwajyF
> =C2=A0 =C2=A0 =C2=A0KzuMXZFSZ3p6Mb8dkxtVyjoy2=
GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> =C2=A0 =C2=A0 =C2=A00GxFb=
uPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> =C2=
=A0 =C2=A0 =C2=A0ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLS=
jLLlxmPG
> =C2=A0 =C2=A0 =C2=A0iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jps=
pnTSD7xMbpL-2QgwUsAlMGzw
>
> Decoding the base64 of the body, w=
e see:
> {
> =C2=A0"iss": "s6BhdRkqt3",
=
> =C2=A0"aud": "https://server.example.com",
> =C2=A0"r=
esponse_type": "code id_token",
> =C2=A0"client_i=
d": "s6BhdRkqt3",
> =C2=A0"redirect_uri": &q=
uot;https://cl=
ient.example.org/cb",
> =C2=A0"scope": "openi=
d",
> =C2=A0"state": "af0ifjsldkj",
> =
=C2=A0"nonce": "n-0S6_WzA2Mj",
> =C2=A0"max_=
age": 86400,
> =C2=A0"claims":
> =C2=A0 {
>=
; =C2=A0 =C2=A0"userinfo":
> =C2=A0 =C2=A0 {
> =C2=A0=
 =C2=A0 =C2=A0"given_name": {"essential": true},
>=
; =C2=A0 =C2=A0 =C2=A0"nickname": null,
> =C2=A0 =C2=A0 =C2=
=A0"email": {"essential": true},
> =C2=A0 =C2=A0 =
=C2=A0"email_verified": {"essential": true},
> =
=C2=A0 =C2=A0 =C2=A0"picture": null
> =C2=A0 =C2=A0 },
&=
gt; =C2=A0 =C2=A0"id_token":
> =C2=A0 =C2=A0 {
> =C2=
=A0 =C2=A0 =C2=A0"gender": null,
> =C2=A0 =C2=A0 =C2=A0&quo=
t;birthdate": {"essential": true},
> =C2=A0 =C2=A0 =C2=
=A0"acr": {"values": ["urn:mace:incommon:iap:silve=
r"]}
> =C2=A0 =C2=A0 }
> =C2=A0 }
> }
>
>=
; I'm not sure where the "claims" claim is coming from -- 674=
9 doesn't
> seem to talk about it. =C2=A0(Note that this example =
is used later on as
> well.)

It is an extension parameter that=
 is registered in the OAuth authorization request registry. 
It is defin=
ed in OpenID Connect Core and OIDF is in the process of registering it to t=
he JWT Claims registry as well. I have put them to show that extension para=
meters can also be used in the request object. Having said that, they may b=
e confusing. I should just remove them.=C2=A0

>
> Section 5=
.2.1
>
> =C2=A0 =C2=A0It is possible for the Request Object to =
include values that are to
> =C2=A0 =C2=A0be revealed only to the Aut=
horization Server.=C2=A0 As such, the
> =C2=A0 =C2=A0"request_ur=
i" MUST have appropriate entropy for its lifetime.=C2=A0 For
> =
=C2=A0 =C2=A0the guidance, refer to 5.1.4.2.2 of [RFC6819].=C2=A0 It is REC=
OMMENDED
> =C2=A0 =C2=A0that it be removed after a reasonable timeout=
 unless access control
> =C2=A0 =C2=A0measures are taken.
>
=
> It sounds like a link to https://www.w3.org/TR/capability-urls/ might> also be useful.
>

Thanks. I will add it. 

> Se=
ction 5.2.2
>
> Do we want to remind the reader that the other =
query parameters are just
> for backwards compatibility?

It is=
 probably be better to remove them as they are not allowed to be used. 
=

>
> Section 5.2.3
>
> =C2=A0 =C2=A0The following i=
s an example of this fetch process:
>
> =C2=A0 =C2=A0 =C2=A0GET=
 /request.jwt HTTP/1.1
> =C2=A0 =C2=A0 =C2=A0Host: tfp.example.org
>
> It&#=
39;s useful to show good hygeine in examples; can we get the extra
> =
entropy in this request that we have in the previous example(s)?

Tha=
nks for pointing out. I will fix it. (The previous example also needs to be=
 changed.) 

>
> Section 6.2
>
> =C2=A0 =C2=A0Th=
e Authorization Server MUST perform the signature validation of the
>=
 =C2=A0 =C2=A0JSON Web Signature [RFC7515] signed request object.=C2=A0 For=
 this, the
> =C2=A0 =C2=A0"alg" Header Parameter in its JOS=
E Header MUST match the value of the
> =C2=A0 =C2=A0pre-registered al=
gorithm..=C2=A0 The signature MUST be validated against
> =C2=A0 =C2=
=A0the appropriate key for that "client_id" and algorithm.
>=
;
> Does "the pre-registered algorithm" concept exist in th=
e specs outside
> of draft-ietf-oauth-jwt-bcp?

Yes. RFC7591 co=
mbined with some of the OAuth Dynamic Client Registration Metadata registry=
 forms the concept. RFC7591 allows clients to register the claims that is i=
n the OAuth Dynamic Client Registration Metadata registry. The registry has=

  • request_object_signing_alg
  • request_object_encryption_al=
g
besides others. Having said that, it is a bit obscure so I proba=
bly should put some more explanation around it.=C2=A0

>
> S=
ection 8
>
> =C2=A0 =C2=A0HTTP clients MUST also verify the TLS=
 server certificate, using
> =C2=A0 =C2=A0subjectAltName dNSName iden=
tities as described in [RFC6125], to avoid
> =C2=A0 =C2=A0man-in-the-=
middle attacks.=C2=A0 The rules and guidelines defined in
>
> I=
t's probably easier to just say "using DNS-ID [RFC6125], to avoid<=
br>> man-in-the-middle attacks".

Thanks. I will =
do so.=C2=A0

>
> Section 9
>
> The error=
 codes we list in Section 7 are already registered, for the
> OIDC us=
age.=C2=A0 Do we want to say anything about that? =C2=A0 (I guess it would<=
br>> be disallowed by process to try to update the existing registration=
 to
> also point at this document.)

OIDC is =
an extension of OAuth and it should be fine as is.=C2=A0
What we =
need to be careful is that there will be no conflict going forward.=C2=A0
I will put the instruction update that will be provided by Mike (J=
ones).=C2=A0

>
> Section 10
>
> We proba=
bly also want to reference draft-ietf-oauth-jwt-bcp.

Thanks. I will put the reference as draft.=C2=A0

>
&=
gt; Section 10.1
>
> =C2=A0 =C2=A0When sending the authorizatio=
n request object through "request"
> =C2=A0 =C2=A0parameter=
, it MUST either be signed using JWS [RFC7515] or encrypted
> =C2=A0 =
=C2=A0using JWE [RFC7516] with then considered appropriate algorithm.
&g=
t;
> Up in Section 5 we only allow (a) signed and (b) signed then enc=
rypted;
> similarly, in Section 4 we reiterate "signed then encr=
ypted".=C2=A0 Why is it
> okay to talk about just "signed o=
r encrypted" here?

Very good catch. It should=
 be changed to align with other sections.=C2=A0

>
> =
Section 10.2
>
> =C2=A0 =C2=A0(b) =C2=A0Verifying that the symm=
etric key for the JWE encryption is the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 correct one if the JWE is using symmetric encryption.
>
> Simi=
larly to the previous point, you also need to check the signature,
> =
which will always be there.

You are right. This on=
e should be removed.=C2=A0

>
> =C2=A0 =C2=A0(d) =C2=
=A0Authorization Server is providing an endpoint that provides a
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object URI in exchange for a Request Ob=
ject.=C2=A0 In this
>
> I don't think this is a complete se=
ntence (and it's definitely not a
> parallel construction with (a=
)-(c)!).=C2=A0 I think perhaps a crisp one-line
> summary of this met=
hod would be "Delegating the authorization check to a
> separate=
 "Request Object to Request Object URI" endpoint on the
> A=
uthorization Server". =C2=A0(The writing in the rest of this paragraph=
 could
> also use an editing pass.)

Thanks f=
or pointing it out. Changing as follows would be ok?=C2=A0

(d) When=C2=A0Authorization Server is providing an endpoint that pr=
ovides a
Request Object URI in exchange for a Request Object,=C2=A0<=
/div>
the Authorization Server MUST perform Client
Authentication to accept the=
 Request Object and bind the Client
Identifier to the Request Object URI it is =
providing. Since
Request Object URI can be replayed, the lifetime of the Reques=
t
Ob=
ject URI MUST be short and preferably one-time use. The
entropy of the Request =
Object URI MUST be sufficiently large.
The adequate shortness of the validity a=
nd the entropy of the
Request Object URI depends on the risk calculation based =
on the
value of the resource being protected. A general guidance for
the validity t=
ime would be less than a minute and the Request
Object URI is to include a cryp=
tographic random value of 128bit
or more at the time of the writing of this spe=
cification.=C2=A0=C2=A0

>
> =C2=A0 =C2=A0(e) =
=C2=A0A third party, such as a Trust Framework Provider, provides an
>=
; =C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoint that provides a Request Object URI i=
n exchange for a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object.=C2=A0 =
The same requirements as (b) above apply.=C2=A0 In
> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 addition, the Authorization Server MUST know out-of-band that=

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Client utilizes the Trust Framewor=
k Operator.
>
> The Authorization Server also has to trust the =
third-party provider to
> actually do its job and not misbehave, righ=
t?

Yes. I will add wording around it.=C2=A0
<=
div>
>
> Section 10.3
>
> I'm not entirely sure=
 what "[t]he endpoints that come into question in
> this specifi=
cation" is supposed to mean -- is it just "the OAuth 2.0
> =
endpoints presently defined in Standards-Track RFCs"?

Yes. RFC6749, RFC6750, and RFC8414.=C2=A0

>
&g=
t; =C2=A0 =C2=A0In [RFC6749], while Redirection URI is included, others are=
 not
> =C2=A0 =C2=A0included in the Authorization Request.=C2=A0 As t=
he result, the same
> =C2=A0 =C2=A0applies to Authorization Request O=
bject.
>
> nit: included in what?

In t=
he Authorization request.=C2=A0
I thought it would be too onerous=
 to state

In [RFC6749], while Redirection URI is included in the Authorization R=
equest,=C2=A0
others are not included in the Authorization Request.=C2=
=A0 As the result, the same
applies to Authorization Request Object.=C2=
=A0=C2=A0

Would you like to add "in the Authoriza=
tion Request" as above?=C2=A0

>
> Se=
ction 10.4
>
> It's probably also worth citing the generic =
URI security considerations
> from RFC 3986, here.

I will do so. Thanks.=C2=A0

>
> Section 10.4.=
1
>
> =C2=A0 =C2=A0"request_uri", and (d) do not perf=
orm recursive GET on the
> =C2=A0 =C2=A0"request_uri".
&=
gt;
> nit: remove the "do" in order to make the constructio=
n parallel.

Thanks. I will do so.=C2=A0
=

>
> Section 12.1
>
> =C2=A0 =C2=A0It is often hard=
 for the user to find out if the personal data asked
> =C2=A0 =C2=A0f=
or is strictly necessary.=C2=A0 A Trust Framework Provider can help the
=
> =C2=A0 =C2=A0user by examining the Client request and comparing to the=
 proposed
> =C2=A0 =C2=A0processing by the Client and certifying the =
request.=C2=A0 After the
> =C2=A0 =C2=A0certification, the Client, wh=
en making an Authorization Request, can
> =C2=A0 =C2=A0submit Authori=
zation Request to the Trust Framework Provider to
> =C2=A0 =C2=A0obta=
in the Request Object URI.
>
> side note: In my head the act of=
 certification was the act of making the
> translation to a Request O=
bject URI, so I'm kind of curious where my
> vision differs from =
reality.

So, I should probably expand the text.=C2=
=A0
The process is two steps:=C2=A0

1. (=
Certification Process) The TFP examines the business process of the client =
and determines what claims they needs: This is the certification process. O=
nce the client is certified, then they are issued a client credential to au=
thenticate against to push request objects to the TFP to get the request_ur=
i.=C2=A0

2. (Translation Process) The client uses =
the client credential that it got to push the request object to the TFP to =
get the request_uri.=C2=A0
=C2=A0
>
> The third p=
aragraph seems to mostly just be describing the procedure of
> how th=
is flow works, which would not necessarily be specific to the
> priva=
cy considerations section.

The third paragraph is =
also important from the privacy point of view.=C2=A0
In a trust f=
ramework that has a policy to only allow TFP vetted request object,=C2=A0
then the Authorization Server must make sure that it was.=C2=A0
One way to do it is to check the authority section.=C2=A0

>
> Section 12.2.2
>
> =C2=A0 =C2=A0Ev=
en if the protected resource does not include a personally
> =C2=A0 =
=C2=A0identifiable information, it is sometimes possible to identify the> =C2=A0 =C2=A0user through the Request Object URI if persistent per-us=
er Request
> =C2=A0 =C2=A0Object URI is used.=C2=A0 A third party may=
 observe it through browser
>
> nit: need an article for "=
persistent per-user Request Object URI" (or
> make it plural, as=
 "URIs are used").

Thanks. I will fix it=
.=C2=A0

>
> =C2=A0 =C2=A0Therefore, per-user Request=
 Object URI should be avoided.
>
> nit: I think this is better =
as "static per-user Requeste Object URIs".

Thanks. I will fix it.=C2=A0

>
> Section 13
&g=
t;
> Are there two different paragraphs for "contributions from =
the OAuth WG
> members"?=C2=A0 Are they reflecting different typ=
es of contribution?

Thanks. I have merged them.=C2=
=A0


> _______________________________________________<=
br>> OAuth mailing list
> OAuth@ietf..org
> https://www.ietf.org/mailman/listinf=
o/oauth



-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID=
 Foundation
http:=
//nat.sakimura.org/
@_nat_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








<=
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.
--00000000000051e993058e9ba717--


From evansanita713@gmail.com  Wed Jul 24 12:32: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 471CF12063F for ; Wed, 24 Jul 2019 12:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.156
X-Spam-Level: 
X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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_HELO_NONE=0.001, 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 hylUPS1tjER7 for ; Wed, 24 Jul 2019 12:32:15 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6253A12066E for ; Wed, 24 Jul 2019 12:32:15 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id y4so48207449wrm.2 for ; Wed, 24 Jul 2019 12:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=message-id:mime-version:to:from:subject:date:importance; bh=jH8zw5ohj5e+rDuAZ2bP7svgrOeUTyYdLHhW/g8oS7g=; b=L6vBDzja+kzvlLN6qA5DB6zTQzEk6z6SdufzoR0vVTSp+qSxRZAxBqZGuNR8pKGEm4 lplLXBJe/WvmbcbpC/J0O9uAo0l2GI4PjQuI5t3rv48/1GhQmCqwI5H7RIcltCQNFsmj YhPmh17mP6QVYOwxKECUtrdLXnqqJ+Slw3a6TdhgtVaKcB+qoWSToim+2uuHpH1iR2pj zLZGLSOP3eEbISpXe1vtD1HsKvBlmAqWYzuSzSUwxfq2Vi72nb8h2fac5CjlPA9uB4mL LOqxyvA05IfzG4/XLsoCiNEHMXcNDExtgjTp8+TTkD/YMSlvZcnLjANHGCVTs9nAzX6u xK0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=jH8zw5ohj5e+rDuAZ2bP7svgrOeUTyYdLHhW/g8oS7g=; b=KVZkDfG0LU2T2aWL58Nahy98seVSKWu9/yMiVcuP6bkRicx9xXfQPKPdLs1jQ5GrNZ 65hfwXUtfAHPHT+3tFOWZKOqDzA8SVC0Qyq3/QFOAF8GjlD1dxKggiH+CoeQW9gvtIj7 C0U3Nl5DuguvBEtwknHJSp1jjYrjuZ+A/c3dkkbLJge1x+A8rl80gMYkknfrAvoy5qJa YxUYEGkQREKLJSM5ddvZNuOjPIW8qeIKzw+f8tBNBXKMQHrh7JHbOK0Vw0LViYhcsqGC U2ZLF7iD/Lleq36j+D4JhoKfU0ksKI4RtWg1gKHYoE86olHuVdu9OO8O8NuEZYlG7EBa LTfA==
X-Gm-Message-State: APjAAAWyHk3HBNUMYJuxHUTODzfIivmHC0B/zd21CcwyKlScJ3xQD4ms DLPlGoxno67UF4YgO9x80wf4FRZel0o=
X-Google-Smtp-Source: APXvYqzLg2p41QCX2n0M4arcd2lUB4jga8jyfTcc/vqnf7wG+sZKkoNoyR7gXaCTFamvi9qyEnTO3A==
X-Received: by 2002:adf:e442:: with SMTP id t2mr32953384wrm.286.1563996733621;  Wed, 24 Jul 2019 12:32:13 -0700 (PDT)
Received: from ?IPv6:::ffff:192.168.1.4? (35.39.7.51.dyn.plus.net. [51.7.39.35]) by smtp.gmail.com with ESMTPSA id t1sm57491196wra.74.2019.07.24.12.32.12 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 12:32:13 -0700 (PDT)
Message-ID: <5d38b23d.1c69fb81.8c1f9.42bb@mx.google.com>
MIME-Version: 1.0
To: "oauth@ietf.org" 
From: evansanita713 
Date: Wed, 24 Jul 2019 16:33:02 +0100
Importance: normal
X-Priority: 3
Content-Type: multipart/alternative; boundary="_33FE4067-A4BD-4AF4-8530-C845BB093760_"
Archived-At: 
X-Mailman-Approved-At: Fri, 26 Jul 2019 17:17:15 -0700
Subject: [OAUTH-WG] Question regarding RFC 6749
X-BeenThere: oauth@ietf.org
X-Mailman-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, 24 Jul 2019 19:34:12 -0000

--_33FE4067-A4BD-4AF4-8530-C845BB093760_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hello I got a little problem im keep getting ERROR 405 with this message=20
=E2=80=9CSorry, your request has been blocked as it may cause potential thr=
eats to the server's security.
Your request ID is :=C2=A00bc1a90415639964283497695e3598=E2=80=9C

Can I ask for help pls what I need to do ?
Thanks

Regards
A J Evans


--_33FE4067-A4BD-4AF4-8530-C845BB093760_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


Hello I got a little problem im keep getting ER=
ROR 405 with this message 
=E2=80=9CSorry, your request has been blocked a=
s it may cause potential threats to the server's security.
Your request ID is : 0b=
c1a90415639964283497695e3598=E2=80=9C
 
Can I ask for help pls what I need to do ?<=
/span>
Thanks
 
Regards
A J Evans
 
=

--_33FE4067-A4BD-4AF4-8530-C845BB093760_--


From nobody Fri Jul 26 23:02: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 67DCF120020; Fri, 26 Jul 2019 23:02:51 -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 caD6Z08BUg2B; Fri, 26 Jul 2019 23:02:45 -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 8DE2312029B; Fri, 26 Jul 2019 23:02:44 -0700 (PDT)
Received: by mail-wr1-x441.google.com with SMTP id n9so56538163wru.0; Fri, 26 Jul 2019 23:02:44 -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=XzQgeD2CrJG1paO7AmA4rej2Kv3YWZDZMG+KlCFqUUE=; b=SyEg9JDHU4z11bYpUpCzh1/r7BMUwePXT8H3gE/PFo662c1ZOKMMmOLxIvaA53NPGV nFAMJsDSGVYLbmtK174K/BXELSxF0ZNQd4kNwaUqgHBglsXCeIY6md4YJ+4PWe4JNqdj 0GpuykUb0iUxajvT1nLgRM1onFvGlpG7VFfGpE+58Z/33KgdPjcAyk2WTbOAmodXptjE aai4dB5rBSQcxQWp9Paxd9IZR4jrprXbYlRsdHeC+wjNjgcsxj8TBBSjXKBchVNBbaj1 z4ewrM3A9Eytg+nhTxzGSJAt/OAMlWMRWqgJXO0AZeTUV/dN5rD/yVqhVXf2qeYkLNYV 7uiQ==
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=XzQgeD2CrJG1paO7AmA4rej2Kv3YWZDZMG+KlCFqUUE=; b=TEUuo+bmpocC3rAwo3pQJ8z60YuWHslXWvKm0CAOoddvhypinxRrcZouX1dSvRrvdu Kkjl1c08hfmN4BsAv4wZiyC1vUFP131pF7hA39tWB/L4jQLanSq0TluA0VaKuHC5U3HT M5p2sozL6kxzx9EUAWJuYtusu74NgFFbwPYFERuh2LNuLQdLCeZS4GtidFbDYRNBHgXg wnr4FhWmetGGeQazrZkiloAVHqNnFU4obAIrYZnVIjUGMri9idQfAyyy4M+lffQg3Gha BCOckRjmlL8mb7GFv7I6LEgN/cOYxEHYXgIuNDpblKfL1ITXUf0OtBSm/Gb5m21emr63 dvkQ==
X-Gm-Message-State: APjAAAXJLyH+wj6U5uMjcLSQlshtX+yRLr9kJk/5R73/TckWmjwB+7bb aKQLEdz96mpA1cvGmdhftKyCziQV0vJG8QD4vpc=
X-Google-Smtp-Source: APXvYqyWrSKGCl3FUkvWPCR3ESQpA5Ru8WDd2aANUJfwbH/MpKxc2Tne4Go5j9vMxbif+cwziJ7MMcXeWVSn4EU7pxQ=
X-Received: by 2002:a5d:4e90:: with SMTP id e16mr50653840wru.339.1564207362494;  Fri, 26 Jul 2019 23:02:42 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com>  
In-Reply-To: 
From: Nat Sakimura 
Date: Sat, 27 Jul 2019 02:02:31 -0400
Message-ID: 
To: Brian Campbell 
Cc: Benjamin Kaduk , draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, The IESG , oauth 
Content-Type: multipart/alternative; boundary="000000000000325495058ea368b0"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Jul 2019 06:02:52 -0000

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

Brian,

Perhaps I should have spelled out what I have stated as "grandfather the
currently registered OAuth Authorization Request parameters into JWT Claims
Registry and keep any incoming OAuth Authz param in sync with the JWT
Claims Registry by creating a modified instruction for IANA processings.

I felt that to find out what is being added to the JWT Claims registry as
potentially OAuth Authz Request extension parameters that are coming in the
future a bit arbitrary and not-so-simple while an instruction to add
incoming OAuth Authz Request parameters to JWT Claims Registry is
deterministic and therefore simple.

On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell 
wrote:

> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate several times this week (
> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and muliple comments on https://bitbucket.org/openid/connect/issues/1019)
> and even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I believe the pragmatic solution to this is to register some of the main
> JWT claims into the OAuth parameters registry (not the other way around, as
> you're suggesting which wouldn't even have caught the one name collision
> we've actually had where a draft, more than one actually, wanted to call an
> authorization request parameter "aud", which would conflicted with the JWT
> claim of the same name and cause big problems when used together with JAR).
> I suppose the iron clad way to "fix" this would be to merge the two
> registries and keep them in sync forever. But that seems awfully heavy
> handed and unnecessary. JAR is a specific application of JWT being used to
> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
> (aud, iss) and one could reasonably imagine other core ones being used as
> well (exp, iat, nbf, jti, etc). An authorization request parameter being
> introduced that uses one of those names is far and away the most likely
> point of collision (and has already happened, as noted previously). A new
> JWT claim being introduced that collides with an existing authorization
> request parameter name AND would be used in the context of JAR is far far
> less likely to happen. So unlikely, in fact, that I don't think it's
> necessary or even useful to pollute the JWT claims registry with the names
> of all the authorization request parameters. I happen to be one of the DEs
> on the JWT claims registry so, in theory, I have some idea what I'm talking
> about here. In theory. And I do have to be upfront at this point and say
> that I will push back on a request for registration of a bunch of
> authorization request parameters into the JWT claims registry without
> without more compelling reason.
>
> On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:
>
>>
>> Thanks very much for the comments.
>> Here are my responses to your comments.
>>
>> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
>> noreply@ietf.org> wrote:
>> >
>> > Benjamin Kaduk has entered the following ballot position for
>> > draft-ietf-oauth-jwsreq-19: Discuss
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> > Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> > for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > My apologies; my previous position was incomplete.  Updated to note
>> > namespacing issues, and one minor terminology nit about "DNS-ID".
>> >
>> > There seem to be some pretty serious namespacing issues that are not
>> > discussed at all in this document.  Specifically, using JWT as a
>> > container for OAuth 2.0 authorization request parameters (including
>> > extension parameters) introduces the usage of many new names (of JSON
>> > name/value pairs) into the JWT claims namespace.  Furthermore, the
>> > addition is not bounded, as any new OAuth extension parameters are
>> > implicitly permitted to be used as well!  The IANA Considerations make
>> > no mention of the collapsed namespace for JWT claims and OAuth 2.0
>> > (authorization request) parameters, leaving substantial potential for
>> > collisions in the future.
>>
>> The simplest solution probably is to register the authorization request
>> parameters to the JWT Claims registry.
>> According to my checking, the relevant but not yet registered parameters
>> are:
>>
>> Claim Name: "code_challenge"
>> Claim Description: OAuth PKCE Code Challenge
>> Change Controller: IESG
>> Specification Document(s): Section 3 of RFC 7636
>>
>> Claim Name: "code_challenge_method"
>> Claim Description: OAuth PKCE Code Challenge
>> Change Controller: IESG
>> Specification Document(s): Section 3 of RFC 7636
>>
>> Claim Name: "redirect_uri"
>> Claim Description: OAuth Redirection URI
>> Change Controller: IETF
>> Specification Document(s): Section 4.1.1 of RFC 6749
>>
>> Claim Name: "response_type"
>> Claim Description: OAuth Authorization Response type
>> Change Controller: IETF
>> Specification Document(s): Section 3.1.1 of RFC 6749
>>
>> Claim Name: "state"
>> Claim Description: OAuth state parameter
>> Change Controller: IETF
>> Specification Document(s): Section 4.1.1 of RFC 6749
>>
>> Claim Name: "vtr"
>> Claim Description: Vector of Trust request
>> Change Controller: IESG
>> Specification Document(s): Section 4.1 of RFC 8485
>>
>> > Relatedly, using "application/jwt" as the Content-type of the
>> > HTTP response from dereferencing the request_uri with no explicit
>> > indication of the type/profile of JWT used (whether in the content type
>> > or in the JWT claims themselves) gives some risk of misinterpretation of
>> > the content..  Consider, for example, when that request_uri is
>> > dereferenced not by the authorization server in the process of
>> > fulfilling an authorization request, but instead by some other service
>> > that expects a different type of JWT.
>>
>> I am making the change to "application/oauth-authz-req+jwt" and add IANA
>> request.
>>
>> >
>> > This second point is a "discuss discuss" -- it's an important question
>> > and I'd like to talk about it, but it's not clear that any change to the
>> > document will be needed.
>> >
>> > The introduction notes as an advantage of JWT that:
>> >
>> >    (d)  (collection minimization) The request can be signed by a third
>> >         party attesting that the authorization request is compliant with
>> >         a certain policy.  For example, a request can be pre-examined by
>> >         a third party that all the personal data requested is strictly
>> >         necessary to perform the process that the end-user asked for,
>> >         and statically signed by that third party.  The authorization
>> >         server then examines the signature and shows the conformance
>> >         status to the end-user, who would have some assurance as to the
>> >         legitimacy of the request when authorizing it.  In some cases,
>> >         it may even be desirable to skip the authorization dialogue
>> >         under such circumstances.
>> >
>> > I'm pretty uncomfortable about suggesting that the authorization
>> > dialogue can/should be skipped; do we need to keep this example?
>> >
>>
>> I have actually deliberately put this text as there seem to be some
>> disconnect between the engineering community and the privacy regulators
>> community. Asking for "consent" is something that should be considered as
>> an exception and should use other lawful basis if possible as UK ICO (The
>> data protection regulator in the UK) advises. As the editor of "ISO/IEC
>> 29184 Privacy notice and consent", which is being developed with close
>> coordination with regulators such as European Data Protection Board, I
>> would have to agree to that position and I took OAuth JAR as one of the
>> opportunity to call it out. I will add some text explaining it such as:
>>
>> In some cases, it is deemed harmful to ask for consent when it is not
>> necessary: i.e., the processing is performed under other lawful basis than
>> consent, as it would make the consent, that should be an exception, stand
>> out less. Under such circumstances, this mechanism can be used to skip the
>> authorization dialogue.
>>
>> >
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > Section 1
>> >
>> >    While it is easy to implement, the encoding in the URI does not allow
>> >    application layer security with confidentiality and integrity
>> >    protection to be used.  While TLS is used to offer communication
>> >
>> > nit: this wording is a little hard to read; it might be easier to
>> > reorder to "does not allow application layer security to be used to
>> > provide confidentiality and integrity protection".
>>
>> Thanks. I will make the change.
>>
>> >
>> >    The use of application layer security allows requests to be prepared
>> >    by a third party so that a client application cannot request more
>> >    permissions than previously agreed.  This offers an additional degree
>> >    of privacy protection.
>> >
>> > (side note) what would an example of such a third party be.  (We already
>> > have the resource owner, the client, and the authorization server ...
>> > maybe it's a fourth party?)
>>
>> It is a fourth party, e.g., a trust framework provider or an information
>> fiduciary.
>> The text need to be modified though as I found an error.
>> Since now all the OAuth Request parameters must be in the request object,
>> only the pattern that can be supported for something like this is to push
>> the request object to the TFP and have the TFP check if it meets the
>> policy
>> and return request_uri only it is evelauted as OK.
>>
>> >
>> >    Furthermore, the request by reference allows the reduction of over-
>> >    the-wire overhead.
>> >
>> > We only barely mentioned by-reference at this point (one line in the
>> > Abstract), so I'd suggest "passing the request by reference".
>>
>> Thanks. I will make the change.
>>
>> >
>> >    (4)  its development status that it is an RFC and so is its
>> >         associated signing and encryption methods as [RFC7515] and
>> >         [RFC7516]
>> >
>> > nit: I'd suggest "its development status as a Proposed Standard, along
>> > with the associated signing and encryption methods [RFC7515] [RFC7516]."
>>
>> Thanks. I will make the change.
>>
>> >
>> >    (c)  (confidentiality protection) The request can be encrypted so
>> >         that end-to-end confidentiality can be provided even if the TLS
>> >         connection is terminated at one point or another.
>> >
>> > nit: TLS is always terminated at or before the user-agent, though.  So
>> > maybe the user agent needs to get called out here as well (there could
>> > of course be TLS termination earlier than the user-agent in some cases,
>> > too).
>>
>> Thanks. I will make the change.
>>
>> >
>> >    2.  When the client does not want to do the crypto.  The
>> >        Authorization Server may provide an endpoint to accept the
>> >        Authorization Request through direct communication with the
>> >        Client so that the Client is authenticated and the channel is TLS
>> >        protected.
>> >
>> > How can you "not want to do [the] crypto" but still be doing TLS (with
>> > crypto)?  Perhaps we're looking for "not want to pay the additional
>> > overhead of JWS/JWE cryptography on top of TLS"?
>>
>> Thanks. I will make the change.
>>
>> >
>> > Section 1.1
>> >
>> > RFC 8174 has updated BCP 14 boilerplate text to use.
>>
>> Thanks. I will make the change.
>>
>> >
>> > Section 3
>> >
>> > nit: should this section be 2.3 to get wrapped into "terminology"?
>>
>> It could, but I suppose it could be as is.
>>
>> >
>> > It might also be worth putting references in for the terms, though they
>> > are largely common knowledge at this point.
>>
>> Hopefully, they are public knowledge ...
>>
>> >
>> > Section 4
>> >
>> >    A Request Object (Section 2.1) is used to provide authorization
>> >    request parameters for an OAuth 2.0 authorization request.  It MUST
>> >    contains all the OAuth 2.0 [RFC6749] authorization request parameters
>> >    including extension parameters.  The parameters are represented as
>> >
>> > nit: "all the parameters" kind of sounds like "all that are defined"..
>> > But I think the intent here is "any parameter used to process the
>> > request must come from the request object and URL query parameters are
>> > ignored", so maybe "MUST contain all the parameters (including extension
>> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
>> > request; parameters from other sources MUST NOT be used", akin to what
>> > we say down in Sections 5 and 6.3..
>> > But we need to be careful about the wording to not exclude the usage of
>> > the "request" and "request_uri" query parameters to  find the Request
>> > Object!
>>
>> Thanks. I will make the description more exact.
>>
>> >
>> >    the JWT claims.  Parameter names and string values MUST be included
>> >
>> > nit: maybe "the JWT claims of the object"?
>>
>> Thanks. I will probably make it "the JWT claims of the request object."
>>
>> >
>> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
>> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>> >    signed or signed and encrypted.
>> >
>> > nit: I  think we want "This JSON [RFC7159] object".
>>
>> Thanks. I will fix it as suggested.
>>
>> >
>> > (Long quote incoming)
>> >
>> >    The following is an example of the Claims in a Request Object before
>> >    base64url encoding and signing.  Note that it includes extension
>> >    variables such as "nonce" and "max_age".
>> >
>> >      {
>> >       "iss": "s6BhdRkqt3",
>> >       "aud": "https://server..example.com 
>> ",
>> >       "response_type": "code id_token",
>> >       "client_id": "s6BhdRkqt3",
>> >       "redirect_uri": "https://client..example.org/cb
>> ",
>> >       "scope": "openid",
>> >       "state": "af0ifjsldkj",
>> >       "nonce": "n-0S6_WzA2Mj",
>> >       "max_age": 86400
>> >      }
>> >
>> >    Signing it with the "RS256" algorithm results in this Request Object
>> >    value (with line wraps within values for display purposes only):
>> >
>> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
>> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
>> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
>> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
>> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
>> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
>> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
>> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
>> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
>> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
>> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
>> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
>> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
>> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
>> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
>> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
>> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
>> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>> >
>> > Decoding the base64 of the body, we see:
>> > {
>> >  "iss": "s6BhdRkqt3",
>> >  "aud": "https://server.example.com",
>> >  "response_type": "code id_token",
>> >  "client_id": "s6BhdRkqt3",
>> >  "redirect_uri": "https://client.example.org/cb
>> ",
>> >  "scope": "openid",
>> >  "state": "af0ifjsldkj",
>> >  "nonce": "n-0S6_WzA2Mj",
>> >  "max_age": 86400,
>> >  "claims":
>> >   {
>> >    "userinfo":
>> >     {
>> >      "given_name": {"essential": true},
>> >      "nickname": null,
>> >      "email": {"essential": true},
>> >      "email_verified": {"essential": true},
>> >      "picture": null
>> >     },
>> >    "id_token":
>> >     {
>> >      "gender": null,
>> >      "birthdate": {"essential": true},
>> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>> >     }
>> >   }
>> > }
>> >
>> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
>> > seem to talk about it.  (Note that this example is used later on as
>> > well.)
>>
>> It is an extension parameter that is registered in the OAuth
>> authorization request registry.
>> It is defined in OpenID Connect Core and OIDF is in the process of
>> registering it to the JWT Claims registry as well. I have put them to show
>> that extension parameters can also be used in the request object. Having
>> said that, they may be confusing. I should just remove them.
>>
>> >
>> > Section 5.2.1
>> >
>> >    It is possible for the Request Object to include values that are to
>> >    be revealed only to the Authorization Server.  As such, the
>> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
>> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
>> >    that it be removed after a reasonable timeout unless access control
>> >    measures are taken.
>> >
>> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
>> > also be useful.
>> >
>>
>> Thanks. I will add it.
>>
>> > Section 5.2.2
>> >
>> > Do we want to remind the reader that the other query parameters are just
>> > for backwards compatibility?
>>
>> It is probably be better to remove them as they are not allowed to be
>> used.
>>
>> >
>> > Section 5.2.3
>> >
>> >    The following is an example of this fetch process:
>> >
>> >      GET /request.jwt HTTP/1.1
>> >      Host: tfp.example.org
>> >
>> > It's useful to show good hygeine in examples; can we get the extra
>> > entropy in this request that we have in the previous example(s)?
>>
>> Thanks for pointing out. I will fix it. (The previous example also needs
>> to be changed.)
>>
>> >
>> > Section 6.2
>> >
>> >    The Authorization Server MUST perform the signature validation of the
>> >    JSON Web Signature [RFC7515] signed request object.  For this, the
>> >    "alg" Header Parameter in its JOSE Header MUST match the value of the
>> >    pre-registered algorithm..  The signature MUST be validated against
>> >    the appropriate key for that "client_id" and algorithm.
>> >
>> > Does "the pre-registered algorithm" concept exist in the specs outside
>> > of draft-ietf-oauth-jwt-bcp?
>>
>> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
>> Metadata registry forms the concept. RFC7591 allows clients to register the
>> claims that is in the OAuth Dynamic Client Registration Metadata registry.
>> The registry has
>>
>>    - request_object_signing_alg
>>    - request_object_encryption_alg
>>
>> besides others. Having said that, it is a bit obscure so I probably
>> should put some more explanation around it.
>>
>> >
>> > Section 8
>> >
>> >    HTTP clients MUST also verify the TLS server certificate, using
>> >    subjectAltName dNSName identities as described in [RFC6125], to avoid
>> >    man-in-the-middle attacks.  The rules and guidelines defined in
>> >
>> > It's probably easier to just say "using DNS-ID [RFC6125], to avoid
>> > man-in-the-middle attacks".
>>
>> Thanks. I will do so.
>>
>> >
>> > Section 9
>> >
>> > The error codes we list in Section 7 are already registered, for the
>> > OIDC usage.  Do we want to say anything about that?   (I guess it would
>> > be disallowed by process to try to update the existing registration to
>> > also point at this document.)
>>
>> OIDC is an extension of OAuth and it should be fine as is.
>> What we need to be careful is that there will be no conflict going
>> forward.
>> I will put the instruction update that will be provided by Mike (Jones).
>>
>> >
>> > Section 10
>> >
>> > We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>
>> Thanks. I will put the reference as draft.
>>
>> >
>> > Section 10.1
>> >
>> >    When sending the authorization request object through "request"
>> >    parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>> >    using JWE [RFC7516] with then considered appropriate algorithm.
>> >
>> > Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
>> > similarly, in Section 4 we reiterate "signed then encrypted".  Why is it
>> > okay to talk about just "signed or encrypted" here?
>>
>> Very good catch. It should be changed to align with other sections.
>>
>> >
>> > Section 10.2
>> >
>> >    (b)  Verifying that the symmetric key for the JWE encryption is the
>> >         correct one if the JWE is using symmetric encryption.
>> >
>> > Similarly to the previous point, you also need to check the signature,
>> > which will always be there.
>>
>> You are right. This one should be removed.
>>
>> >
>> >    (d)  Authorization Server is providing an endpoint that provides a
>> >         Request Object URI in exchange for a Request Object.  In this
>> >
>> > I don't think this is a complete sentence (and it's definitely not a
>> > parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
>> > summary of this method would be "Delegating the authorization check to a
>> > separate "Request Object to Request Object URI" endpoint on the
>> > Authorization Server".  (The writing in the rest of this paragraph could
>> > also use an editing pass.)
>>
>> Thanks for pointing it out. Changing as follows would be ok?
>>
>> (d) When Authorization Server is providing an endpoint that provides a
>> Request Object URI in exchange for a Request Object,
>> the Authorization Server MUST perform Client
>> Authentication to accept the Request Object and bind the Client
>> Identifier to the Request Object URI it is providing. Since
>> Request Object URI can be replayed, the lifetime of the Request
>> Object URI MUST be short and preferably one-time use. The
>> entropy of the Request Object URI MUST be sufficiently large.
>> The adequate shortness of the validity and the entropy of the
>> Request Object URI depends on the risk calculation based on the
>> value of the resource being protected. A general guidance for
>> the validity time would be less than a minute and the Request
>> Object URI is to include a cryptographic random value of 128bit
>> or more at the time of the writing of this specification.
>>
>> >
>> >    (e)  A third party, such as a Trust Framework Provider, provides an
>> >         endpoint that provides a Request Object URI in exchange for a
>> >         Request Object.  The same requirements as (b) above apply.  In
>> >         addition, the Authorization Server MUST know out-of-band that
>> >         the Client utilizes the Trust Framework Operator.
>> >
>> > The Authorization Server also has to trust the third-party provider to
>> > actually do its job and not misbehave, right?
>>
>> Yes. I will add wording around it.
>>
>> >
>> > Section 10.3
>> >
>> > I'm not entirely sure what "[t]he endpoints that come into question in
>> > this specification" is supposed to mean -- is it just "the OAuth 2.0
>> > endpoints presently defined in Standards-Track RFCs"?
>>
>> Yes. RFC6749, RFC6750, and RFC8414.
>>
>> >
>> >    In [RFC6749], while Redirection URI is included, others are not
>> >    included in the Authorization Request.  As the result, the same
>> >    applies to Authorization Request Object.
>> >
>> > nit: included in what?
>>
>> In the Authorization request.
>> I thought it would be too onerous to state
>>
>> In [RFC6749], while Redirection URI is included in the Authorization
>>> Request,
>>> others are not included in the Authorization Request.  As the result,
>>> the same
>>> applies to Authorization Request Object.
>>
>>
>> Would you like to add "in the Authorization Request" as above?
>>
>> >
>> > Section 10.4
>> >
>> > It's probably also worth citing the generic URI security considerations
>> > from RFC 3986, here.
>>
>> I will do so. Thanks.
>>
>> >
>> > Section 10.4.1
>> >
>> >    "request_uri", and (d) do not perform recursive GET on the
>> >    "request_uri".
>> >
>> > nit: remove the "do" in order to make the construction parallel.
>>
>> Thanks. I will do so.
>>
>> >
>> > Section 12.1
>> >
>> >    It is often hard for the user to find out if the personal data asked
>> >    for is strictly necessary.  A Trust Framework Provider can help the
>> >    user by examining the Client request and comparing to the proposed
>> >    processing by the Client and certifying the request.  After the
>> >    certification, the Client, when making an Authorization Request, can
>> >    submit Authorization Request to the Trust Framework Provider to
>> >    obtain the Request Object URI.
>> >
>> > side note: In my head the act of certification was the act of making the
>> > translation to a Request Object URI, so I'm kind of curious where my
>> > vision differs from reality.
>>
>> So, I should probably expand the text.
>> The process is two steps:
>>
>> 1. (Certification Process) The TFP examines the business process of the
>> client and determines what claims they needs: This is the certification
>> process. Once the client is certified, then they are issued a client
>> credential to authenticate against to push request objects to the TFP to
>> get the request_uri.
>>
>> 2. (Translation Process) The client uses the client credential that it
>> got to push the request object to the TFP to get the request_uri.
>>
>> >
>> > The third paragraph seems to mostly just be describing the procedure of
>> > how this flow works, which would not necessarily be specific to the
>> > privacy considerations section.
>>
>> The third paragraph is also important from the privacy point of view.
>> In a trust framework that has a policy to only allow TFP vetted request
>> object,
>> then the Authorization Server must make sure that it was.
>> One way to do it is to check the authority section.
>>
>> >
>> > Section 12.2.2
>> >
>> >    Even if the protected resource does not include a personally
>> >    identifiable information, it is sometimes possible to identify the
>> >    user through the Request Object URI if persistent per-user Request
>> >    Object URI is used.  A third party may observe it through browser
>> >
>> > nit: need an article for "persistent per-user Request Object URI" (or
>> > make it plural, as "URIs are used").
>>
>> Thanks. I will fix it.
>>
>> >
>> >    Therefore, per-user Request Object URI should be avoided.
>> >
>> > nit: I think this is better as "static per-user Requeste Object URIs".
>>
>> Thanks. I will fix it.
>>
>> >
>> > Section 13
>> >
>> > Are there two different paragraphs for "contributions from the OAuth WG
>> > members"?  Are they reflecting different types of contribution?
>>
>> Thanks. I have merged them.
>>
>>
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf..org 
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


Brian,=C2=A0

Perhaps I should have spel=
led out what I have stated as "grandfather the currently registered OA=
uth Authorization Request parameters into JWT Claims Registry and keep any =
incoming OAuth Authz param in sync with the JWT Claims Registry by creating=
 a modified instruction for IANA processings.=C2=A0

I felt that to find out what is being added to the JWT Claims registry as=
 potentially OAuth Authz Request extension parameters that are coming in th=
e future a bit arbitrary and not-so-simple while an instruction to add inco=
ming OAuth Authz Request parameters to JWT Claims Registry is deterministic=
 and therefore simple.=C2=A0

On Fri, Jul 26, 2019 at 4:47 PM Brian Cam=
pbell <bcampbell@pingident=
ity.com> wrote:
Nat, you suggest that the &qu=
ot;simplest solution probably is to register the authorization request para=
meters to the JWT Claims registry." However, as I've attempted to =
articulate several times this week (https://mail=
archive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and muliple=
 comments on https://bitbucket.org/openid/connect/issues/1019) and =
even back in 2017 (https://mailarchive.ietf.org/=
arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I believe the pragmatic so=
lution to this is to register some of the main JWT claims into the OAuth pa=
rameters registry (not the other way around, as you're suggesting which=
 wouldn't even have caught the one name collision we've actually ha=
d where a draft, more than one actually, wanted to call an authorization re=
quest parameter "aud", which would conflicted with the JWT claim =
of the same name and cause big problems when used together with JAR). I sup=
pose the iron clad way to "fix" this would be to merge the two re=
gistries and keep them in sync forever. But that seems awfully heavy handed=
 and unnecessary. JAR is a specific application of JWT being used to convey=
 an OAuth authz request. JAR explicitly uses a few core JWT claims (aud, is=
s) and one could reasonably imagine other core ones being used as well (exp=
, iat, nbf, jti, etc). An authorization request parameter being introduced =
that uses one of those names is far and away the most likely point of colli=
sion (and has already happened, as noted previously). A new JWT claim being=
 introduced that collides with an existing authorization request parameter =
name AND would be used in the context of JAR is far far less likely to happ=
en. So unlikely, in fact, that I don't think it's necessary or even=
 useful to pollute the JWT claims registry with the names of all the author=
ization request parameters. I happen to be one of the DEs on the JWT claims=
 registry so, in theory, I have some idea what I'm talking about here. =
In theory. And I do have to be upfront at this point and say that I will pu=
sh back on a request for registration of a bunch of authorization request p=
arameters into the JWT claims registry without without more compelling reas=
on. =C2=A0 

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <sakimura@gmail.com>=
 wrote:

Thanks very much for the comments.=C2=A0
Here are my respo=
nses to your comments.=C2=A0

On Wed, Jul 3, 2019 at 2:59 PM B=
enjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
>
> Benjamin Kaduk=
 has entered the following ballot position for
> draft-ietf-oauth-jws=
req-19: Discuss
>
> When responding, please keep the subject li=
ne intact and reply to all
> email addresses included in the To and C=
C lines. (Feel free to cut this
> introductory paragraph, however.)>
>
> Please refer to https://www.ietf.org/ie=
sg/statement/discuss-criteria.html
> for more information about I=
ESG DISCUSS and COMMENT positions.
>
>
> The document, al=
ong with other ballot positions, can be found here:
> ht=
tps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>=

>
> ----------------------------------------------------------=
------------
> DISCUSS:
> -------------------------------------=
---------------------------------
>
> My apologies; my previous=
 position was incomplete.=C2=A0 Updated to note
> namespacing issues,=
 and one minor terminology nit about "DNS-ID".
>
> Th=
ere seem to be some pretty serious namespacing issues that are not
> =
discussed at all in this document.=C2=A0 Specifically, using JWT as a
&g=
t; container for OAuth 2.0 authorization request parameters (including
&=
gt; extension parameters) introduces the usage of many new names (of JSON> name/value pairs) into the JWT claims namespace.=C2=A0 Furthermore, =
the
> addition is not bounded, as any new OAuth extension parameters =
are
> implicitly permitted to be used as well!=C2=A0 The IANA Conside=
rations make
> no mention of the collapsed namespace for JWT claims a=
nd OAuth 2.0
> (authorization request) parameters, leaving substantia=
l potential for
> collisions in the future.

The simplest solut=
ion probably is to register the authorization request parameters to the JWT=
 Claims registry.
According to my checking, the relevant but not yet reg=
istered parameters are:

Claim Name: "code_challenge"
Cl=
aim Description: OAuth PKCE Code Challenge
Change Controller: IESG
Sp=
ecification Document(s): Section 3 of RFC 7636

Claim Name: "cod=
e_challenge_method"
Claim Description: OAuth PKCE Code ChallengeChange Controller: IESG
Specification Document(s): Section 3 of RFC 763=
6

Claim Name: "redirect_uri"
Claim Description: OAuth R=
edirection URI
Change Controller: IETF
Specification Document(s): Sec=
tion 4.1.1 of RFC 6749

Claim Name: "response_type"
Clai=
m Description: OAuth Authorization Response type
Change Controller: IETF=

Specification Document(s): Section 3.1.1 of RFC 6749

Claim Name:=
 "state"
Claim Description: OAuth state parameter
Change Co=
ntroller: IETF
Specification Document(s): Section 4.1.1 of RFC 6749
<=
br>Claim Name: "vtr"
Claim Description: Vector of Trust reques=
t
Change Controller: IESG
Specification Document(s): Section 4.1 of R=
FC 8485

> Relatedly, using "application/jwt" as the Con=
tent-type of the
> HTTP response from dereferencing the request_uri w=
ith no explicit
> indication of the type/profile of JWT used (whether=
 in the content type
> or in the JWT claims themselves) gives some ri=
sk of misinterpretation of
> the content..=C2=A0 Consider, for exampl=
e, when that request_uri is
> dereferenced not by the authorization s=
erver in the process of
> fulfilling an authorization request, but in=
stead by some other service
> that expects a different type of JWT.
I am making the change to "application/oauth-authz-req+jwt"=
 and add IANA request.

>
> This second point is a "dis=
cuss discuss" -- it's an important question
> and I'd li=
ke to talk about it, but it's not clear that any change to the
> =
document will be needed.
>
> The introduction notes as an advan=
tage of JWT that:
>
> =C2=A0 =C2=A0(d) =C2=A0(collection minimi=
zation) The request can be signed by a third
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 party attesting that the authorization request is compliant with
=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a certain policy.=C2=A0 For example, a req=
uest can be pre-examined by
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a third par=
ty that all the personal data requested is strictly
> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 necessary to perform the process that the end-user asked for,=

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and statically signed by that third pa=
rty.=C2=A0 The authorization
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 server the=
n examines the signature and shows the conformance
> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 status to the end-user, who would have some assurance as to t=
he
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimacy of the request when autho=
rizing it.=C2=A0 In some cases,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 it may =
even be desirable to skip the authorization dialogue
> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 under such circumstances.
>
> I'm pretty unco=
mfortable about suggesting that the authorization
> dialogue can/shou=
ld be skipped; do we need to keep this example?
>

I have actua=
lly deliberately put this text as there seem to be some disconnect between =
the engineering community and the privacy regulators community. Asking for =
"consent" is something that should be considered as an exception =
and should use other lawful basis if possible as UK ICO (The data protectio=
n regulator in the UK) advises. As the editor of "ISO/IEC 29184 Privac=
y notice and consent", which is being developed with close coordinatio=
n with regulators such as European Data Protection Board, I would have to a=
gree to that position and I took OAuth JAR as one of the opportunity to cal=
l it out. I will add some text explaining it such as:=C2=A0

<=
/div>
In some cases, it is deemed harmful to ask for consent when it is=
 not necessary: i.e., the processing is performed under other lawful basis =
than consent, as it would make the consent, that should be an exception, st=
and out less. Under such circumstances, this mechanism can be used=C2=A0to =
skip the authorization dialogue.=C2=A0=C2=A0

>
> ----------=
------------------------------------------------------------
> COMMEN=
T:
> ----------------------------------------------------------------=
------
>
> Section 1
>
> =C2=A0 =C2=A0While it is e=
asy to implement, the encoding in the URI does not allow
> =C2=A0 =C2=
=A0application layer security with confidentiality and integrity
> =
=C2=A0 =C2=A0protection to be used.=C2=A0 While TLS is used to offer commun=
ication
>
> nit: this wording is a little hard to read; it migh=
t be easier to
> reorder to "does not allow application layer se=
curity to be used to
> provide confidentiality and integrity protecti=
on".

Thanks. I will make the change.

>
> =C2=A0=
 =C2=A0The use of application layer security allows requests to be prepared=

> =C2=A0 =C2=A0by a third party so that a client application cannot =
request more
> =C2=A0 =C2=A0permissions than previously agreed.=C2=A0=
 This offers an additional degree
> =C2=A0 =C2=A0of privacy protectio=
n.
>
> (side note) what would an example of such a third party =
be. =C2=A0(We already
> have the resource owner, the client, and the =
authorization server ...
> maybe it's a fourth party?)

It =
is a fourth party, e.g., a trust framework provider or an information fiduc=
iary.
The text need to be modified though as I found an error.
Since =
now all the OAuth Request parameters must be in the request object,
only=
 the pattern that can be supported for something like this is to push
th=
e request object to the TFP and have the TFP check if it meets the policyand return request_uri only it is evelauted as OK.

>
> =
=C2=A0 =C2=A0Furthermore, the request by reference allows the reduction of =
over-
> =C2=A0 =C2=A0the-wire overhead.
>
> We only barel=
y mentioned by-reference at this point (one line in the
> Abstract), =
so I'd suggest "passing the request by reference".

Tha=
nks. I will make the change.

>
> =C2=A0 =C2=A0(4) =C2=A0its=
 development status that it is an RFC and so is its
> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 associated signing and encryption methods as [RFC7515] and> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7516]
>
> nit: I'd su=
ggest "its development status as a Proposed Standard, along
> wi=
th the associated signing and encryption methods [RFC7515] [RFC7516]."=


Thanks. I will make the change.

>
> =C2=A0 =C2=A0(c=
) =C2=A0(confidentiality protection) The request can be encrypted so
>=
; =C2=A0 =C2=A0 =C2=A0 =C2=A0 that end-to-end confidentiality can be provid=
ed even if the TLS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection is termin=
ated at one point or another.
>
> nit: TLS is always terminated=
 at or before the user-agent, though.=C2=A0 So
> maybe the user agent=
 needs to get called out here as well (there could
> of course be TLS=
 termination earlier than the user-agent in some cases,
> too).
Thanks. I will make the change.

>
> =C2=A0 =C2=A02.=C2=A0=
 When the client does not want to do the crypto.=C2=A0 The
> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Authorization Server may provide an endpoint to accept =
the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Request through direct=
 communication with the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Client so that t=
he Client is authenticated and the channel is TLS
> =C2=A0 =C2=A0 =C2=
=A0 =C2=A0protected.
>
> How can you "not want to do [the]=
 crypto" but still be doing TLS (with
> crypto)?=C2=A0 Perhaps w=
e're looking for "not want to pay the additional
> overhead =
of JWS/JWE cryptography on top of TLS"?

Thanks. I will make the=
 change.

>
> Section 1.1
>
> RFC 8174 has updat=
ed BCP 14 boilerplate text to use.

Thanks. I will make the change. <=
br>
>
> Section 3
>
> nit: should this section be 2=
.3 to get wrapped into "terminology"?

It could, but I supp=
ose it could be as is. 

>
> It might also be worth putting =
references in for the terms, though they
> are largely common knowled=
ge at this point.

Hopefully, they are public knowledge ... 

&=
gt;
> Section 4
>
> =C2=A0 =C2=A0A Request Object (Sectio=
n 2.1) is used to provide authorization
> =C2=A0 =C2=A0request parame=
ters for an OAuth 2.0 authorization request.=C2=A0 It MUST
> =C2=A0 =
=C2=A0contains all the OAuth 2.0 [RFC6749] authorization request parameters=

> =C2=A0 =C2=A0including extension parameters.=C2=A0 The parameters =
are represented as
>
> nit: "all the parameters" kind=
 of sounds like "all that are defined"..
> But I think the =
intent here is "any parameter used to process the
> request must=
 come from the request object and URL query parameters are
> ignored&=
quot;, so maybe "MUST contain all the parameters (including extension<=
br>> parameters) used to process the OAuth 2.0 [RFC6749] authorization> request; parameters from other sources MUST NOT be used", akin =
to what
> we say down in Sections 5 and 6.3..
> But we need to =
be careful about the wording to not exclude the usage of
> the "=
request" and "request_uri" query parameters to =C2=A0find th=
e Request
> Object!

Thanks. I will make the description more e=
xact. 

>
> =C2=A0 =C2=A0the JWT claims.=C2=A0 Parameter nam=
es and string values MUST be included
>
> nit: maybe "the =
JWT claims of the object"?

Thanks. I will probably make it &quo=
t;the JWT claims of the request object."

>
> =C2=A0 =
=C2=A0any extension parameters.=C2=A0 This JSON [RFC7159] constitutes the J=
WT
> =C2=A0 =C2=A0Claims Set defined in JWT [RFC7519].=C2=A0 The JWT =
Claims Set is then
> =C2=A0 =C2=A0signed or signed and encrypted.
=
>
> nit: I =C2=A0think we want "This JSON [RFC7159] object&qu=
ot;.

Thanks. I will fix it as suggested. 

>
> (Long =
quote incoming)
>
> =C2=A0 =C2=A0The following is an example of=
 the Claims in a Request Object before
> =C2=A0 =C2=A0base64url encod=
ing and signing.=C2=A0 Note that it includes extension
> =C2=A0 =C2=
=A0variables such as "nonce" and "max_age".
>
=
> =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 "iss": &q=
uot;s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "aud": "<=
a href=3D"https://server.example.com" target=3D"_blank">https://server..exa=
mple.com",
> =C2=A0 =C2=A0 =C2=A0 "response_type":=
 "code id_token",
> =C2=A0 =C2=A0 =C2=A0 "client_id&qu=
ot;: "s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "redirect_ur=
i": "=
https://client..example.org/cb",
> =C2=A0 =C2=A0 =C2=A0 &quo=
t;scope": "openid",
> =C2=A0 =C2=A0 =C2=A0 "state=
": "af0ifjsldkj",
> =C2=A0 =C2=A0 =C2=A0 "nonce&q=
uot;: "n-0S6_WzA2Mj",
> =C2=A0 =C2=A0 =C2=A0 "max_age&=
quot;: 86400
> =C2=A0 =C2=A0 =C2=A0}
>
> =C2=A0 =C2=A0Sig=
ning it with the "RS256" algorithm results in this Request Object=

> =C2=A0 =C2=A0value (with line wraps within values for display purp=
oses only):
>
> =C2=A0 =C2=A0 =C2=A0eyJhbGciOiJSUzI1NiIsImtpZCI=
6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> =C2=A0 =C2=A0 =C2=A0F0MyIsD=
QogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> =C2=A0 =
=C2=A0 =C2=A0c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6IC=
JzNk
> =C2=A0 =C2=A0 =C2=A0JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0=
dHBzOi8vY2xpZW50LmV4YW1w
> =C2=A0 =C2=A0 =C2=A0bGUub3JnL2NiIiwNCiAic2=
NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> =C2=A0 =C2=A0 =C2=A0Zq=
c2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> =
=C2=A0 =C2=A0 =C2=A0ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiA=
NCiAgICB7DQ
> =C2=A0 =C2=A0 =C2=A0ogICAgICJnaXZlbl9uYW1lIjogeyJlc3Nlb=
nRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> =C2=A0 =C2=A0 =C2=A0Y2tuYW1lIjogbnV=
sbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> =C2=A0 =C2=A0 =
=C2=A0wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg> =C2=A0 =C2=A0 =C2=A0ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b=
2tlbiI6IA0KICAgIH
> =C2=A0 =C2=A0 =C2=A0sNCiAgICAgImdlbmRlciI6IG51bGw=
sDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> =C2=A0 =C2=A0 =C2=A0dGlhbCI6I=
HRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> =C2=A0 =
=C2=A0 =C2=A0luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkb=
mnvs
> =C2=A0 =C2=A0 =C2=A0F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_t=
rPYs8KQxsn6R9Emo_wHwajyF
> =C2=A0 =C2=A0 =C2=A0KzuMXZFSZ3p6Mb8dkxtVyj=
oy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> =C2=A0 =C2=A0 =C2=A00G=
xFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> =
=C2=A0 =C2=A0 =C2=A0ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pX=
fLSjLLlxmPG
> =C2=A0 =C2=A0 =C2=A0iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1=
jpspnTSD7xMbpL-2QgwUsAlMGzw
>
> Decoding the base64 of the body=
, we see:
> {
> =C2=A0"iss": "s6BhdRkqt3",<=
br>> =C2=A0"aud": "https://server.example.com",
> =C2=A0&quo=
t;response_type": "code id_token",
> =C2=A0"clien=
t_id": "s6BhdRkqt3",
> =C2=A0"redirect_uri":=
 "https:/=
/client.example.org/cb",
> =C2=A0"scope": "op=
enid",
> =C2=A0"state": "af0ifjsldkj",
&g=
t; =C2=A0"nonce": "n-0S6_WzA2Mj",
> =C2=A0"m=
ax_age": 86400,
> =C2=A0"claims":
> =C2=A0 {
=
> =C2=A0 =C2=A0"userinfo":
> =C2=A0 =C2=A0 {
> =C2=
=A0 =C2=A0 =C2=A0"given_name": {"essential": true},
=
> =C2=A0 =C2=A0 =C2=A0"nickname": null,
> =C2=A0 =C2=A0 =
=C2=A0"email": {"essential": true},
> =C2=A0 =C2=
=A0 =C2=A0"email_verified": {"essential": true},
>=
; =C2=A0 =C2=A0 =C2=A0"picture": null
> =C2=A0 =C2=A0 },> =C2=A0 =C2=A0"id_token":
> =C2=A0 =C2=A0 {
> =
=C2=A0 =C2=A0 =C2=A0"gender": null,
> =C2=A0 =C2=A0 =C2=A0&=
quot;birthdate": {"essential": true},
> =C2=A0 =C2=A0 =
=C2=A0"acr": {"values": ["urn:mace:incommon:iap:si=
lver"]}
> =C2=A0 =C2=A0 }
> =C2=A0 }
> }
>
=
> I'm not sure where the "claims" claim is coming from -- =
6749 doesn't
> seem to talk about it. =C2=A0(Note that this examp=
le is used later on as
> well.)

It is an extension parameter t=
hat is registered in the OAuth authorization request registry. 
It is de=
fined in OpenID Connect Core and OIDF is in the process of registering it t=
o the JWT Claims registry as well. I have put them to show that extension p=
arameters can also be used in the request object. Having said that, they ma=
y be confusing. I should just remove them.=C2=A0

>
> Sectio=
n 5.2.1
>
> =C2=A0 =C2=A0It is possible for the Request Object =
to include values that are to
> =C2=A0 =C2=A0be revealed only to the =
Authorization Server.=C2=A0 As such, the
> =C2=A0 =C2=A0"request=
_uri" MUST have appropriate entropy for its lifetime.=C2=A0 For
>=
; =C2=A0 =C2=A0the guidance, refer to 5.1.4.2.2 of [RFC6819].=C2=A0 It is R=
ECOMMENDED
> =C2=A0 =C2=A0that it be removed after a reasonable timeo=
ut unless access control
> =C2=A0 =C2=A0measures are taken.
>> It sounds like a link to https://www.w3.org/TR/capability-urls/ might<=
br>> also be useful.
>

Thanks. I will add it. 

> =
Section 5.2.2
>
> Do we want to remind the reader that the othe=
r query parameters are just
> for backwards compatibility?

It =
is probably be better to remove them as they are not allowed to be used. 
>
> Section 5.2.3
>
> =C2=A0 =C2=A0The following=
 is an example of this fetch process:
>
> =C2=A0 =C2=A0 =C2=A0G=
ET /request.jwt HTTP/1.1
> =C2=A0 =C2=A0 =C2=A0Host: tfp.example.org
>
> It=
's useful to show good hygeine in examples; can we get the extra
>=
; entropy in this request that we have in the previous example(s)?

T=
hanks for pointing out. I will fix it. (The previous example also needs to =
be changed.) 

>
> Section 6.2
>
> =C2=A0 =C2=A0=
The Authorization Server MUST perform the signature validation of the
&g=
t; =C2=A0 =C2=A0JSON Web Signature [RFC7515] signed request object.=C2=A0 F=
or this, the
> =C2=A0 =C2=A0"alg" Header Parameter in its J=
OSE Header MUST match the value of the
> =C2=A0 =C2=A0pre-registered =
algorithm..=C2=A0 The signature MUST be validated against
> =C2=A0 =
=C2=A0the appropriate key for that "client_id" and algorithm.
=
>
> Does "the pre-registered algorithm" concept exist in=
 the specs outside
> of draft-ietf-oauth-jwt-bcp?

Yes. RFC7591=
 combined with some of the OAuth Dynamic Client Registration Metadata regis=
try forms the concept. RFC7591 allows clients to register the claims that i=
s in the OAuth Dynamic Client Registration Metadata registry. The registry =
has
  • request_object_signing_alg
  • request_object_encryption=
_alg
besides others. Having said that, it is a bit obscure so I pr=
obably should put some more explanation around it.=C2=A0

>
>=
; Section 8
>
> =C2=A0 =C2=A0HTTP clients MUST also verify the =
TLS server certificate, using
> =C2=A0 =C2=A0subjectAltName dNSName i=
dentities as described in [RFC6125], to avoid
> =C2=A0 =C2=A0man-in-t=
he-middle attacks.=C2=A0 The rules and guidelines defined in
>
>=
; It's probably easier to just say "using DNS-ID [RFC6125], to avo=
id
> man-in-the-middle attacks".

Thanks. I wi=
ll do so.=C2=A0

>
> Section 9
>
> The er=
ror codes we list in Section 7 are already registered, for the
> OIDC=
 usage.=C2=A0 Do we want to say anything about that? =C2=A0 (I guess it wou=
ld
> be disallowed by process to try to update the existing registrat=
ion to
> also point at this document.)

OIDC =
is an extension of OAuth and it should be fine as is.=C2=A0
What =
we need to be careful is that there will be no conflict going forward.=C2=
=A0
I will put the instruction update that will be provided by Mi=
ke (Jones).=C2=A0

>
> Section 10
>
> We =
probably also want to reference draft-ietf-oauth-jwt-bcp.

Thanks. I will put the reference as draft.=C2=A0

>=

> Section 10.1
>
> =C2=A0 =C2=A0When sending the authori=
zation request object through "request"
> =C2=A0 =C2=A0para=
meter, it MUST either be signed using JWS [RFC7515] or encrypted
> =
=C2=A0 =C2=A0using JWE [RFC7516] with then considered appropriate algorithm=
.
>
> Up in Section 5 we only allow (a) signed and (b) signed t=
hen encrypted;
> similarly, in Section 4 we reiterate "signed th=
en encrypted".=C2=A0 Why is it
> okay to talk about just "s=
igned or encrypted" here?

Very good catch. It=
 should be changed to align with other sections.=C2=A0

>> Section 10.2
>
> =C2=A0 =C2=A0(b) =C2=A0Verifying that t=
he symmetric key for the JWE encryption is the
> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 correct one if the JWE is using symmetric encryption.
>
&g=
t; Similarly to the previous point, you also need to check the signature,> which will always be there.

You are right. =
This one should be removed.=C2=A0

>
> =C2=A0 =C2=A0(=
d) =C2=A0Authorization Server is providing an endpoint that provides a
&=
gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object URI in exchange for a Reques=
t Object.=C2=A0 In this
>
> I don't think this is a complet=
e sentence (and it's definitely not a
> parallel construction wit=
h (a)-(c)!).=C2=A0 I think perhaps a crisp one-line
> summary of this=
 method would be "Delegating the authorization check to a
> sepa=
rate "Request Object to Request Object URI" endpoint on the
&g=
t; Authorization Server". =C2=A0(The writing in the rest of this parag=
raph could
> also use an editing pass.)

Than=
ks for pointing it out. Changing as follows would be ok?=C2=A0
(d) When=C2=A0Authorization Server is providing an endpoint tha=
t provides a
Request Object URI in exchange for a Request Object,=C2=A0
the Authorization Server MUST perform Client
Authentication to accept =
the Request Object and bind the Client
Identifier to the Request Object URI it =
is providing. Since
Request Object URI can be replayed, the lifetime of the Req=
uest
Object URI MUST be short and preferably one-time use. The
entropy of the Requ=
est Object URI MUST be sufficiently large.
The adequate shortness of the validi=
ty and the entropy of the
Request Object URI depends on the risk calculation ba=
sed on the
value of the resource being protected. A general guidance for=

the validi=
ty time would be less than a minute and the Request
Object URI is to include a =
cryptographic random value of 128bit
or more at the time of the writing of this=
 specification.=C2=A0=C2=A0

>
> =C2=A0 =C2=A0=
(e) =C2=A0A third party, such as a Trust Framework Provider, provides an> =C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoint that provides a Request Object U=
RI in exchange for a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object.=C2=
=A0 The same requirements as (b) above apply.=C2=A0 In
> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 addition, the Authorization Server MUST know out-of-band =
that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Client utilizes the Trust Fram=
ework Operator.
>
> The Authorization Server also has to trust =
the third-party provider to
> actually do its job and not misbehave, =
right?

Yes. I will add wording around it.=C2=A0

>
> Section 10.3
>
> I'm not entirely =
sure what "[t]he endpoints that come into question in
> this spe=
cification" is supposed to mean -- is it just "the OAuth 2.0
&=
gt; endpoints presently defined in Standards-Track RFCs"?
Yes. RFC6749, RFC6750, and RFC8414.=C2=A0

>> =C2=A0 =C2=A0In [RFC6749], while Redirection URI is included, others=
 are not
> =C2=A0 =C2=A0included in the Authorization Request.=C2=A0 =
As the result, the same
> =C2=A0 =C2=A0applies to Authorization Reque=
st Object.
>
> nit: included in what?

=
In the Authorization request.=C2=A0
I thought it would be too one=
rous to state

In [RFC6749], while Redirection URI is included in the Authoriza=
tion Request,=C2=A0
others are not included in the Authorization Request=
.=C2=A0 As the result, the same
applies to Authorization Request Object.=
=C2=A0=C2=A0

Would you like to add "in the Author=
ization Request" as above?=C2=A0

>
>=
 Section 10.4
>
> It's probably also worth citing the gener=
ic URI security considerations
> from RFC 3986, here.

<=
/div>
I will do so. Thanks.=C2=A0

>
> Section 10=
.4.1
>
> =C2=A0 =C2=A0"request_uri", and (d) do not p=
erform recursive GET on the
> =C2=A0 =C2=A0"request_uri".>
> nit: remove the "do" in order to make the construc=
tion parallel.

Thanks. I will do so.=C2=A0

>
> Section 12.1
>
> =C2=A0 =C2=A0It is often h=
ard for the user to find out if the personal data asked
> =C2=A0 =C2=
=A0for is strictly necessary.=C2=A0 A Trust Framework Provider can help the=

> =C2=A0 =C2=A0user by examining the Client request and comparing to=
 the proposed
> =C2=A0 =C2=A0processing by the Client and certifying =
the request.=C2=A0 After the
> =C2=A0 =C2=A0certification, the Client=
, when making an Authorization Request, can
> =C2=A0 =C2=A0submit Aut=
horization Request to the Trust Framework Provider to
> =C2=A0 =C2=A0=
obtain the Request Object URI.
>
> side note: In my head the ac=
t of certification was the act of making the
> translation to a Reque=
st Object URI, so I'm kind of curious where my
> vision differs f=
rom reality.

So, I should probably expand the text=
.=C2=A0
The process is two steps:=C2=A0

=
1. (Certification Process) The TFP examines the business process of the cli=
ent and determines what claims they needs: This is the certification proces=
s. Once the client is certified, then they are issued a client credential t=
o authenticate against to push request objects to the TFP to get the reques=
t_uri.=C2=A0

2. (Translation Process) The client u=
ses the client credential that it got to push the request object to the TFP=
 to get the request_uri.=C2=A0
=C2=A0
>
> The thi=
rd paragraph seems to mostly just be describing the procedure of
> ho=
w this flow works, which would not necessarily be specific to the
> p=
rivacy considerations section.

The third paragraph=
 is also important from the privacy point of view.=C2=A0
In a tru=
st framework that has a policy to only allow TFP vetted request object,=C2=
=A0
then the Authorization Server must make sure that it was.=C2=
=A0
One way to do it is to check the authority section.=C2=A0

>
> Section 12.2.2
>
> =C2=A0 =
=C2=A0Even if the protected resource does not include a personally
> =
=C2=A0 =C2=A0identifiable information, it is sometimes possible to identify=
 the
> =C2=A0 =C2=A0user through the Request Object URI if persistent=
 per-user Request
> =C2=A0 =C2=A0Object URI is used.=C2=A0 A third pa=
rty may observe it through browser
>
> nit: need an article for=
 "persistent per-user Request Object URI" (or
> make it plu=
ral, as "URIs are used").

Thanks. I will=
 fix it.=C2=A0

>
> =C2=A0 =C2=A0Therefore, per-user =
Request Object URI should be avoided.
>
> nit: I think this is =
better as "static per-user Requeste Object URIs".

<=
/div>
Thanks. I will fix it.=C2=A0

>
> Section 1=
3
>
> Are there two different paragraphs for "contribution=
s from the OAuth WG
> members"?=C2=A0 Are they reflecting differ=
ent types of contribution?

Thanks. I have merged t=
hem.=C2=A0


> _________________________________________=
______
> OAuth mailing list
> OAuth@ietf..org
> https://www.ietf.org/mailman/=
listinfo/oauth



-- 
Nat Sakimura (=3Dnat)
Chairman,=
 OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








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


-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_n=
at_en


--000000000000325495058ea368b0--


From nobody Sun Jul 28 05:26: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 1A6761200F7 for ; Sun, 28 Jul 2019 05:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YobTnVOQWrBX for ; Sun, 28 Jul 2019 05:26:15 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C7C12013B for ; Sun, 28 Jul 2019 05:26:09 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id j5so110081915ioj.8 for ; Sun, 28 Jul 2019 05:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GBjES4xfyrsv0pliY4zi0RFZWYpvqkqk2IuH6q04xl8=; b=Kawkh3Sappl59FOjtJSp1sQPGAoiBnCPjmibrTdgSbF97kbkFYBRIMAuTasA7HjzXe wMstIxg146dr21Wv1einpMFV6u4KuRSEeV3t4KyXA1qktQ1tQwhjiVQYzC4HRKx4ZJh7 6wBXqGhdURykaibyRC1vxygeeeeBzwjjLJPqM=
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=GBjES4xfyrsv0pliY4zi0RFZWYpvqkqk2IuH6q04xl8=; b=XjggzBfcg9PR1GX+ZyiidIrZS5ALRd3aim4pjmf1idOM5EnG/MO9mFgnw0gAXtb3So cq0noRCS9OJO5vTXf6QS6j9amPsvPPc0geMOjbuQsrXR3H3BiuKPzF6pNB6G85/sT3r0 i3WGcAddgVJitz0tbrwMkZ5G/rxQr1k7O9vFw7wPqW13TdHjeWK+XvRVGs35uULeylR/ 6s+WSUBLIhN6rjPdImefAcisSeidO59rIeEO430KY0bjm82dxiHUfBg4WQMmKGAgUqii jnL3DTxm1UYRS2/7fdPt3STO+J3ZBZwOhjCgHRuUKzCqc6o2YeB0aw4ZPOrDxfEWO/bE rgew==
X-Gm-Message-State: APjAAAWdlWE81adIcyB5u+Dm5DX9aHgmyrpfhXVHum9wP0/YFkbtmc71 WaE3MZdqJ9qd4RVCWjnyn76XocTX6BLY4mfnER7duhEVrON/nVLYyGg/SfxkHoA5Qboi+cH0B/R cf4MY+4C6COp/ug==
X-Google-Smtp-Source: APXvYqw4GjdqZsE7J4OQu0vA2bYyRRFx1axJfC5AZ2UWUdVcZ5GA78+ZdAj4xGQkNK3bGB8RLyRO1I573OKP4tdQTAg=
X-Received: by 2002:a05:6638:201:: with SMTP id e1mr26929440jaq.45.1564316768603;  Sun, 28 Jul 2019 05:26:08 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com>   
In-Reply-To: 
From: Brian Campbell 
Date: Sun, 28 Jul 2019 06:25:42 -0600
Message-ID: 
To: Nat Sakimura 
Cc: Benjamin Kaduk , draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, The IESG , oauth 
Content-Type: multipart/alternative; boundary="0000000000004f36fb058ebce1f6"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2019 12:26:21 -0000

--0000000000004f36fb058ebce1f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm honestly not sure I follow all that or how it would really work to
prevent name collisions. As a lipnus test, would the one real world
instance of the issue (name collision with 'aud') have been averted by this=
?

While my understanding is obliviously a requirement here, I do have more
familiarity with this stuff than the average person, so my lack of
understanding might serve as a good indicator about the likely simplicity
and efficacy of what's been suggested.


On Sat, Jul 27, 2019 at 12:02 AM Nat Sakimura  wrote:

> Brian,
>
> Perhaps I should have spelled out what I have stated as "grandfather the
> currently registered OAuth Authorization Request parameters into JWT Clai=
ms
> Registry and keep any incoming OAuth Authz param in sync with the JWT
> Claims Registry by creating a modified instruction for IANA processings.
>
> I felt that to find out what is being added to the JWT Claims registry as
> potentially OAuth Authz Request extension parameters that are coming in t=
he
> future a bit arbitrary and not-so-simple while an instruction to add
> incoming OAuth Authz Request parameters to JWT Claims Registry is
> deterministic and therefore simple.
>
> On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell 
> wrote:
>
>> Nat, you suggest that the "simplest solution probably is to register the
>> authorization request parameters to the JWT Claims registry." However, a=
s
>> I've attempted to articulate several times this week (
>> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
>> and muliple comments on https://bitbucket.org/openid/connect/issues/1019=
)
>> and even back in 2017 (
>> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY)=
,
>> I believe the pragmatic solution to this is to register some of the main
>> JWT claims into the OAuth parameters registry (not the other way around,=
 as
>> you're suggesting which wouldn't even have caught the one name collision
>> we've actually had where a draft, more than one actually, wanted to call=
 an
>> authorization request parameter "aud", which would conflicted with the J=
WT
>> claim of the same name and cause big problems when used together with JA=
R).
>> I suppose the iron clad way to "fix" this would be to merge the two
>> registries and keep them in sync forever. But that seems awfully heavy
>> handed and unnecessary. JAR is a specific application of JWT being used =
to
>> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
>> (aud, iss) and one could reasonably imagine other core ones being used a=
s
>> well (exp, iat, nbf, jti, etc). An authorization request parameter being
>> introduced that uses one of those names is far and away the most likely
>> point of collision (and has already happened, as noted previously). A ne=
w
>> JWT claim being introduced that collides with an existing authorization
>> request parameter name AND would be used in the context of JAR is far fa=
r
>> less likely to happen. So unlikely, in fact, that I don't think it's
>> necessary or even useful to pollute the JWT claims registry with the nam=
es
>> of all the authorization request parameters. I happen to be one of the D=
Es
>> on the JWT claims registry so, in theory, I have some idea what I'm talk=
ing
>> about here. In theory. And I do have to be upfront at this point and say
>> that I will push back on a request for registration of a bunch of
>> authorization request parameters into the JWT claims registry without
>> without more compelling reason.
>>
>> On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote=
:
>>
>>>
>>> Thanks very much for the comments.
>>> Here are my responses to your comments.
>>>
>>> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
>>> noreply@ietf.org> wrote:
>>> >
>>> > Benjamin Kaduk has entered the following ballot position for
>>> > draft-ietf-oauth-jwsreq-19: Discuss
>>> >
>>> > When responding, please keep the subject line intact and reply to all
>>> > email addresses included in the To and CC lines. (Feel free to cut th=
is
>>> > introductory paragraph, however.)
>>> >
>>> >
>>> > Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> > for more information about IESG DISCUSS and COMMENT positions.
>>> >
>>> >
>>> > The document, along with other ballot positions, can be found here:
>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------=
-
>>> > DISCUSS:
>>> > ---------------------------------------------------------------------=
-
>>> >
>>> > My apologies; my previous position was incomplete.  Updated to note
>>> > namespacing issues, and one minor terminology nit about "DNS-ID".
>>> >
>>> > There seem to be some pretty serious namespacing issues that are not
>>> > discussed at all in this document.  Specifically, using JWT as a
>>> > container for OAuth 2.0 authorization request parameters (including
>>> > extension parameters) introduces the usage of many new names (of JSON
>>> > name/value pairs) into the JWT claims namespace.  Furthermore, the
>>> > addition is not bounded, as any new OAuth extension parameters are
>>> > implicitly permitted to be used as well!  The IANA Considerations mak=
e
>>> > no mention of the collapsed namespace for JWT claims and OAuth 2.0
>>> > (authorization request) parameters, leaving substantial potential for
>>> > collisions in the future.
>>>
>>> The simplest solution probably is to register the authorization request
>>> parameters to the JWT Claims registry.
>>> According to my checking, the relevant but not yet registered parameter=
s
>>> are:
>>>
>>> Claim Name: "code_challenge"
>>> Claim Description: OAuth PKCE Code Challenge
>>> Change Controller: IESG
>>> Specification Document(s): Section 3 of RFC 7636
>>>
>>> Claim Name: "code_challenge_method"
>>> Claim Description: OAuth PKCE Code Challenge
>>> Change Controller: IESG
>>> Specification Document(s): Section 3 of RFC 7636
>>>
>>> Claim Name: "redirect_uri"
>>> Claim Description: OAuth Redirection URI
>>> Change Controller: IETF
>>> Specification Document(s): Section 4.1.1 of RFC 6749
>>>
>>> Claim Name: "response_type"
>>> Claim Description: OAuth Authorization Response type
>>> Change Controller: IETF
>>> Specification Document(s): Section 3.1.1 of RFC 6749
>>>
>>> Claim Name: "state"
>>> Claim Description: OAuth state parameter
>>> Change Controller: IETF
>>> Specification Document(s): Section 4.1.1 of RFC 6749
>>>
>>> Claim Name: "vtr"
>>> Claim Description: Vector of Trust request
>>> Change Controller: IESG
>>> Specification Document(s): Section 4.1 of RFC 8485
>>>
>>> > Relatedly, using "application/jwt" as the Content-type of the
>>> > HTTP response from dereferencing the request_uri with no explicit
>>> > indication of the type/profile of JWT used (whether in the content ty=
pe
>>> > or in the JWT claims themselves) gives some risk of misinterpretation
>>> of
>>> > the content..  Consider, for example, when that request_uri is
>>> > dereferenced not by the authorization server in the process of
>>> > fulfilling an authorization request, but instead by some other servic=
e
>>> > that expects a different type of JWT.
>>>
>>> I am making the change to "application/oauth-authz-req+jwt" and add IAN=
A
>>> request.
>>>
>>> >
>>> > This second point is a "discuss discuss" -- it's an important questio=
n
>>> > and I'd like to talk about it, but it's not clear that any change to
>>> the
>>> > document will be needed.
>>> >
>>> > The introduction notes as an advantage of JWT that:
>>> >
>>> >    (d)  (collection minimization) The request can be signed by a thir=
d
>>> >         party attesting that the authorization request is compliant
>>> with
>>> >         a certain policy.  For example, a request can be pre-examined
>>> by
>>> >         a third party that all the personal data requested is strictl=
y
>>> >         necessary to perform the process that the end-user asked for,
>>> >         and statically signed by that third party.  The authorization
>>> >         server then examines the signature and shows the conformance
>>> >         status to the end-user, who would have some assurance as to t=
he
>>> >         legitimacy of the request when authorizing it.  In some cases=
,
>>> >         it may even be desirable to skip the authorization dialogue
>>> >         under such circumstances.
>>> >
>>> > I'm pretty uncomfortable about suggesting that the authorization
>>> > dialogue can/should be skipped; do we need to keep this example?
>>> >
>>>
>>> I have actually deliberately put this text as there seem to be some
>>> disconnect between the engineering community and the privacy regulators
>>> community. Asking for "consent" is something that should be considered =
as
>>> an exception and should use other lawful basis if possible as UK ICO (T=
he
>>> data protection regulator in the UK) advises. As the editor of "ISO/IEC
>>> 29184 Privacy notice and consent", which is being developed with close
>>> coordination with regulators such as European Data Protection Board, I
>>> would have to agree to that position and I took OAuth JAR as one of the
>>> opportunity to call it out. I will add some text explaining it such as:
>>>
>>> In some cases, it is deemed harmful to ask for consent when it is not
>>> necessary: i.e., the processing is performed under other lawful basis t=
han
>>> consent, as it would make the consent, that should be an exception, sta=
nd
>>> out less. Under such circumstances, this mechanism can be used to skip =
the
>>> authorization dialogue.
>>>
>>> >
>>> > ---------------------------------------------------------------------=
-
>>> > COMMENT:
>>> > ---------------------------------------------------------------------=
-
>>> >
>>> > Section 1
>>> >
>>> >    While it is easy to implement, the encoding in the URI does not
>>> allow
>>> >    application layer security with confidentiality and integrity
>>> >    protection to be used.  While TLS is used to offer communication
>>> >
>>> > nit: this wording is a little hard to read; it might be easier to
>>> > reorder to "does not allow application layer security to be used to
>>> > provide confidentiality and integrity protection".
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> >    The use of application layer security allows requests to be prepar=
ed
>>> >    by a third party so that a client application cannot request more
>>> >    permissions than previously agreed.  This offers an additional
>>> degree
>>> >    of privacy protection.
>>> >
>>> > (side note) what would an example of such a third party be.  (We
>>> already
>>> > have the resource owner, the client, and the authorization server ...
>>> > maybe it's a fourth party?)
>>>
>>> It is a fourth party, e.g., a trust framework provider or an informatio=
n
>>> fiduciary.
>>> The text need to be modified though as I found an error.
>>> Since now all the OAuth Request parameters must be in the request objec=
t,
>>> only the pattern that can be supported for something like this is to pu=
sh
>>> the request object to the TFP and have the TFP check if it meets the
>>> policy
>>> and return request_uri only it is evelauted as OK.
>>>
>>> >
>>> >    Furthermore, the request by reference allows the reduction of over=
-
>>> >    the-wire overhead.
>>> >
>>> > We only barely mentioned by-reference at this point (one line in the
>>> > Abstract), so I'd suggest "passing the request by reference".
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> >    (4)  its development status that it is an RFC and so is its
>>> >         associated signing and encryption methods as [RFC7515] and
>>> >         [RFC7516]
>>> >
>>> > nit: I'd suggest "its development status as a Proposed Standard, alon=
g
>>> > with the associated signing and encryption methods [RFC7515]
>>> [RFC7516]."
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> >    (c)  (confidentiality protection) The request can be encrypted so
>>> >         that end-to-end confidentiality can be provided even if the T=
LS
>>> >         connection is terminated at one point or another.
>>> >
>>> > nit: TLS is always terminated at or before the user-agent, though.  S=
o
>>> > maybe the user agent needs to get called out here as well (there coul=
d
>>> > of course be TLS termination earlier than the user-agent in some case=
s,
>>> > too).
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> >    2.  When the client does not want to do the crypto.  The
>>> >        Authorization Server may provide an endpoint to accept the
>>> >        Authorization Request through direct communication with the
>>> >        Client so that the Client is authenticated and the channel is
>>> TLS
>>> >        protected.
>>> >
>>> > How can you "not want to do [the] crypto" but still be doing TLS (wit=
h
>>> > crypto)?  Perhaps we're looking for "not want to pay the additional
>>> > overhead of JWS/JWE cryptography on top of TLS"?
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> > Section 1.1
>>> >
>>> > RFC 8174 has updated BCP 14 boilerplate text to use.
>>>
>>> Thanks. I will make the change.
>>>
>>> >
>>> > Section 3
>>> >
>>> > nit: should this section be 2.3 to get wrapped into "terminology"?
>>>
>>> It could, but I suppose it could be as is.
>>>
>>> >
>>> > It might also be worth putting references in for the terms, though th=
ey
>>> > are largely common knowledge at this point.
>>>
>>> Hopefully, they are public knowledge ...
>>>
>>> >
>>> > Section 4
>>> >
>>> >    A Request Object (Section 2.1) is used to provide authorization
>>> >    request parameters for an OAuth 2.0 authorization request.  It MUS=
T
>>> >    contains all the OAuth 2.0 [RFC6749] authorization request
>>> parameters
>>> >    including extension parameters.  The parameters are represented as
>>> >
>>> > nit: "all the parameters" kind of sounds like "all that are defined".=
.
>>> > But I think the intent here is "any parameter used to process the
>>> > request must come from the request object and URL query parameters ar=
e
>>> > ignored", so maybe "MUST contain all the parameters (including
>>> extension
>>> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
>>> > request; parameters from other sources MUST NOT be used", akin to wha=
t
>>> > we say down in Sections 5 and 6.3..
>>> > But we need to be careful about the wording to not exclude the usage =
of
>>> > the "request" and "request_uri" query parameters to  find the Request
>>> > Object!
>>>
>>> Thanks. I will make the description more exact.
>>>
>>> >
>>> >    the JWT claims.  Parameter names and string values MUST be include=
d
>>> >
>>> > nit: maybe "the JWT claims of the object"?
>>>
>>> Thanks. I will probably make it "the JWT claims of the request object."
>>>
>>> >
>>> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
>>> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
>>> >    signed or signed and encrypted.
>>> >
>>> > nit: I  think we want "This JSON [RFC7159] object".
>>>
>>> Thanks. I will fix it as suggested.
>>>
>>> >
>>> > (Long quote incoming)
>>> >
>>> >    The following is an example of the Claims in a Request Object befo=
re
>>> >    base64url encoding and signing.  Note that it includes extension
>>> >    variables such as "nonce" and "max_age".
>>> >
>>> >      {
>>> >       "iss": "s6BhdRkqt3",
>>> >       "aud": "https://server..example.com 
>>> ",
>>> >       "response_type": "code id_token",
>>> >       "client_id": "s6BhdRkqt3",
>>> >       "redirect_uri": "https://client..example.org/cb
>>> ",
>>> >       "scope": "openid",
>>> >       "state": "af0ifjsldkj",
>>> >       "nonce": "n-0S6_WzA2Mj",
>>> >       "max_age": 86400
>>> >      }
>>> >
>>> >    Signing it with the "RS256" algorithm results in this Request Obje=
ct
>>> >    value (with line wraps within values for display purposes only):
>>> >
>>> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRS=
a3
>>> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogIn=
Jl
>>> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJz=
Nk
>>> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW=
1w
>>> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYw=
aW
>>> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIj=
og
>>> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7=
DQ
>>> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm=
5p
>>> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVl=
fS
>>> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCi=
Ag
>>> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAg=
IH
>>> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2=
Vu
>>> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNl=
Om
>>> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmn=
vs
>>> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwaj=
yF
>>> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uR=
Tx
>>> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc=
8K
>>> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxm=
PG
>>> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>>> >
>>> > Decoding the base64 of the body, we see:
>>> > {
>>> >  "iss": "s6BhdRkqt3",
>>> >  "aud": "https://server.example.com",
>>> >  "response_type": "code id_token",
>>> >  "client_id": "s6BhdRkqt3",
>>> >  "redirect_uri": "https://client.example.org/cb
>>> ",
>>> >  "scope": "openid",
>>> >  "state": "af0ifjsldkj",
>>> >  "nonce": "n-0S6_WzA2Mj",
>>> >  "max_age": 86400,
>>> >  "claims":
>>> >   {
>>> >    "userinfo":
>>> >     {
>>> >      "given_name": {"essential": true},
>>> >      "nickname": null,
>>> >      "email": {"essential": true},
>>> >      "email_verified": {"essential": true},
>>> >      "picture": null
>>> >     },
>>> >    "id_token":
>>> >     {
>>> >      "gender": null,
>>> >      "birthdate": {"essential": true},
>>> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>>> >     }
>>> >   }
>>> > }
>>> >
>>> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
>>> > seem to talk about it.  (Note that this example is used later on as
>>> > well.)
>>>
>>> It is an extension parameter that is registered in the OAuth
>>> authorization request registry.
>>> It is defined in OpenID Connect Core and OIDF is in the process of
>>> registering it to the JWT Claims registry as well. I have put them to s=
how
>>> that extension parameters can also be used in the request object. Havin=
g
>>> said that, they may be confusing. I should just remove them.
>>>
>>> >
>>> > Section 5.2.1
>>> >
>>> >    It is possible for the Request Object to include values that are t=
o
>>> >    be revealed only to the Authorization Server.  As such, the
>>> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
>>> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
>>> >    that it be removed after a reasonable timeout unless access contro=
l
>>> >    measures are taken.
>>> >
>>> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
>>> > also be useful.
>>> >
>>>
>>> Thanks. I will add it.
>>>
>>> > Section 5.2.2
>>> >
>>> > Do we want to remind the reader that the other query parameters are
>>> just
>>> > for backwards compatibility?
>>>
>>> It is probably be better to remove them as they are not allowed to be
>>> used.
>>>
>>> >
>>> > Section 5.2.3
>>> >
>>> >    The following is an example of this fetch process:
>>> >
>>> >      GET /request.jwt HTTP/1.1
>>> >      Host: tfp.example.org
>>> >
>>> > It's useful to show good hygeine in examples; can we get the extra
>>> > entropy in this request that we have in the previous example(s)?
>>>
>>> Thanks for pointing out. I will fix it. (The previous example also need=
s
>>> to be changed.)
>>>
>>> >
>>> > Section 6.2
>>> >
>>> >    The Authorization Server MUST perform the signature validation of
>>> the
>>> >    JSON Web Signature [RFC7515] signed request object.  For this, the
>>> >    "alg" Header Parameter in its JOSE Header MUST match the value of
>>> the
>>> >    pre-registered algorithm..  The signature MUST be validated agains=
t
>>> >    the appropriate key for that "client_id" and algorithm.
>>> >
>>> > Does "the pre-registered algorithm" concept exist in the specs outsid=
e
>>> > of draft-ietf-oauth-jwt-bcp?
>>>
>>> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registratio=
n
>>> Metadata registry forms the concept. RFC7591 allows clients to register=
 the
>>> claims that is in the OAuth Dynamic Client Registration Metadata regist=
ry.
>>> The registry has
>>>
>>>    - request_object_signing_alg
>>>    - request_object_encryption_alg
>>>
>>> besides others. Having said that, it is a bit obscure so I probably
>>> should put some more explanation around it.
>>>
>>> >
>>> > Section 8
>>> >
>>> >    HTTP clients MUST also verify the TLS server certificate, using
>>> >    subjectAltName dNSName identities as described in [RFC6125], to
>>> avoid
>>> >    man-in-the-middle attacks.  The rules and guidelines defined in
>>> >
>>> > It's probably easier to just say "using DNS-ID [RFC6125], to avoid
>>> > man-in-the-middle attacks".
>>>
>>> Thanks. I will do so.
>>>
>>> >
>>> > Section 9
>>> >
>>> > The error codes we list in Section 7 are already registered, for the
>>> > OIDC usage.  Do we want to say anything about that?   (I guess it wou=
ld
>>> > be disallowed by process to try to update the existing registration t=
o
>>> > also point at this document.)
>>>
>>> OIDC is an extension of OAuth and it should be fine as is.
>>> What we need to be careful is that there will be no conflict going
>>> forward.
>>> I will put the instruction update that will be provided by Mike (Jones)=
.
>>>
>>> >
>>> > Section 10
>>> >
>>> > We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>>
>>> Thanks. I will put the reference as draft.
>>>
>>> >
>>> > Section 10.1
>>> >
>>> >    When sending the authorization request object through "request"
>>> >    parameter, it MUST either be signed using JWS [RFC7515] or encrypt=
ed
>>> >    using JWE [RFC7516] with then considered appropriate algorithm.
>>> >
>>> > Up in Section 5 we only allow (a) signed and (b) signed then encrypte=
d;
>>> > similarly, in Section 4 we reiterate "signed then encrypted".  Why is
>>> it
>>> > okay to talk about just "signed or encrypted" here?
>>>
>>> Very good catch. It should be changed to align with other sections.
>>>
>>> >
>>> > Section 10.2
>>> >
>>> >    (b)  Verifying that the symmetric key for the JWE encryption is th=
e
>>> >         correct one if the JWE is using symmetric encryption.
>>> >
>>> > Similarly to the previous point, you also need to check the signature=
,
>>> > which will always be there.
>>>
>>> You are right. This one should be removed.
>>>
>>> >
>>> >    (d)  Authorization Server is providing an endpoint that provides a
>>> >         Request Object URI in exchange for a Request Object.  In this
>>> >
>>> > I don't think this is a complete sentence (and it's definitely not a
>>> > parallel construction with (a)-(c)!).  I think perhaps a crisp one-li=
ne
>>> > summary of this method would be "Delegating the authorization check t=
o
>>> a
>>> > separate "Request Object to Request Object URI" endpoint on the
>>> > Authorization Server".  (The writing in the rest of this paragraph
>>> could
>>> > also use an editing pass.)
>>>
>>> Thanks for pointing it out. Changing as follows would be ok?
>>>
>>> (d) When Authorization Server is providing an endpoint that provides a
>>> Request Object URI in exchange for a Request Object,
>>> the Authorization Server MUST perform Client
>>> Authentication to accept the Request Object and bind the Client
>>> Identifier to the Request Object URI it is providing. Since
>>> Request Object URI can be replayed, the lifetime of the Request
>>> Object URI MUST be short and preferably one-time use. The
>>> entropy of the Request Object URI MUST be sufficiently large.
>>> The adequate shortness of the validity and the entropy of the
>>> Request Object URI depends on the risk calculation based on the
>>> value of the resource being protected. A general guidance for
>>> the validity time would be less than a minute and the Request
>>> Object URI is to include a cryptographic random value of 128bit
>>> or more at the time of the writing of this specification.
>>>
>>> >
>>> >    (e)  A third party, such as a Trust Framework Provider, provides a=
n
>>> >         endpoint that provides a Request Object URI in exchange for a
>>> >         Request Object.  The same requirements as (b) above apply.  I=
n
>>> >         addition, the Authorization Server MUST know out-of-band that
>>> >         the Client utilizes the Trust Framework Operator.
>>> >
>>> > The Authorization Server also has to trust the third-party provider t=
o
>>> > actually do its job and not misbehave, right?
>>>
>>> Yes. I will add wording around it.
>>>
>>> >
>>> > Section 10.3
>>> >
>>> > I'm not entirely sure what "[t]he endpoints that come into question i=
n
>>> > this specification" is supposed to mean -- is it just "the OAuth 2.0
>>> > endpoints presently defined in Standards-Track RFCs"?
>>>
>>> Yes. RFC6749, RFC6750, and RFC8414.
>>>
>>> >
>>> >    In [RFC6749], while Redirection URI is included, others are not
>>> >    included in the Authorization Request.  As the result, the same
>>> >    applies to Authorization Request Object.
>>> >
>>> > nit: included in what?
>>>
>>> In the Authorization request.
>>> I thought it would be too onerous to state
>>>
>>> In [RFC6749], while Redirection URI is included in the Authorization
>>>> Request,
>>>> others are not included in the Authorization Request.  As the result,
>>>> the same
>>>> applies to Authorization Request Object.
>>>
>>>
>>> Would you like to add "in the Authorization Request" as above?
>>>
>>> >
>>> > Section 10.4
>>> >
>>> > It's probably also worth citing the generic URI security consideratio=
ns
>>> > from RFC 3986, here.
>>>
>>> I will do so. Thanks.
>>>
>>> >
>>> > Section 10.4.1
>>> >
>>> >    "request_uri", and (d) do not perform recursive GET on the
>>> >    "request_uri".
>>> >
>>> > nit: remove the "do" in order to make the construction parallel.
>>>
>>> Thanks. I will do so.
>>>
>>> >
>>> > Section 12.1
>>> >
>>> >    It is often hard for the user to find out if the personal data ask=
ed
>>> >    for is strictly necessary.  A Trust Framework Provider can help th=
e
>>> >    user by examining the Client request and comparing to the proposed
>>> >    processing by the Client and certifying the request.  After the
>>> >    certification, the Client, when making an Authorization Request, c=
an
>>> >    submit Authorization Request to the Trust Framework Provider to
>>> >    obtain the Request Object URI.
>>> >
>>> > side note: In my head the act of certification was the act of making
>>> the
>>> > translation to a Request Object URI, so I'm kind of curious where my
>>> > vision differs from reality.
>>>
>>> So, I should probably expand the text.
>>> The process is two steps:
>>>
>>> 1. (Certification Process) The TFP examines the business process of the
>>> client and determines what claims they needs: This is the certification
>>> process. Once the client is certified, then they are issued a client
>>> credential to authenticate against to push request objects to the TFP t=
o
>>> get the request_uri.
>>>
>>> 2. (Translation Process) The client uses the client credential that it
>>> got to push the request object to the TFP to get the request_uri.
>>>
>>> >
>>> > The third paragraph seems to mostly just be describing the procedure =
of
>>> > how this flow works, which would not necessarily be specific to the
>>> > privacy considerations section.
>>>
>>> The third paragraph is also important from the privacy point of view.
>>> In a trust framework that has a policy to only allow TFP vetted request
>>> object,
>>> then the Authorization Server must make sure that it was.
>>> One way to do it is to check the authority section.
>>>
>>> >
>>> > Section 12.2.2
>>> >
>>> >    Even if the protected resource does not include a personally
>>> >    identifiable information, it is sometimes possible to identify the
>>> >    user through the Request Object URI if persistent per-user Request
>>> >    Object URI is used.  A third party may observe it through browser
>>> >
>>> > nit: need an article for "persistent per-user Request Object URI" (or
>>> > make it plural, as "URIs are used").
>>>
>>> Thanks. I will fix it.
>>>
>>> >
>>> >    Therefore, per-user Request Object URI should be avoided.
>>> >
>>> > nit: I think this is better as "static per-user Requeste Object URIs"=
.
>>>
>>> Thanks. I will fix it.
>>>
>>> >
>>> > Section 13
>>> >
>>> > Are there two different paragraphs for "contributions from the OAuth =
WG
>>> > members"?  Are they reflecting different types of contribution?
>>>
>>> Thanks. I have merged them.
>>>
>>>
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf..org 
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
.
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

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

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


I'm honestly not sure I follow all that or how it=
 would really work to prevent name collisions. As a lipnus test, would the =
one real world instance of the issue (name collision with 'aud') ha=
ve been averted by this?

While my understandin=
g is obliviously a requirement here, I do have more familiarity with this s=
tuff than the average person, so my lack of understanding might serve as a =
good indicator about the likely simplicity and efficacy of what's been =
suggested.=C2=A0


<=
div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 27, 2019 at 12:02 AM Nat S=
akimura <sakimura@gmail.com>=
; wrote:
Brian,=C2=A0

Perhaps I should have spelled out=
 what I have stated as "grandfather the currently registered OAuth Aut=
horization Request parameters into JWT Claims Registry and keep any incomin=
g OAuth Authz param in sync with the JWT Claims Registry by creating a modi=
fied instruction for IANA processings.=C2=A0

I fel=
t that to find out what is being added to the JWT Claims registry as potent=
ially OAuth Authz Request extension parameters that are coming in the futur=
e a bit arbitrary and not-so-simple while an instruction to add incoming OA=
uth Authz Request parameters to JWT Claims Registry is deterministic and th=
erefore simple.=C2=A0

On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell &=
lt;bcampbel=
l@pingidentity.com> wrote:
Nat, you suggest t=
hat the "simplest solution probably is to register the authorization r=
equest parameters to the JWT Claims registry." However, as I've at=
tempted to articulate several times this week (h=
ttps://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs =
and muliple comments on https://bitbucket.org/openid/connect/issues/101=
9) and even back in 2017 (https://mailarchiv=
e.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I believe the p=
ragmatic solution to this is to register some of the main JWT claims into t=
he OAuth parameters registry (not the other way around, as you're sugge=
sting which wouldn't even have caught the one name collision we've =
actually had where a draft, more than one actually, wanted to call an autho=
rization request parameter "aud", which would conflicted with the=
 JWT claim of the same name and cause big problems when used together with =
JAR). I suppose the iron clad way to "fix" this would be to merge=
 the two registries and keep them in sync forever. But that seems awfully h=
eavy handed and unnecessary. JAR is a specific application of JWT being use=
d to convey an OAuth authz request. JAR explicitly uses a few core JWT clai=
ms (aud, iss) and one could reasonably imagine other core ones being used a=
s well (exp, iat, nbf, jti, etc). An authorization request parameter being =
introduced that uses one of those names is far and away the most likely poi=
nt of collision (and has already happened, as noted previously). A new JWT =
claim being introduced that collides with an existing authorization request=
 parameter name AND would be used in the context of JAR is far far less lik=
ely to happen. So unlikely, in fact, that I don't think it's necess=
ary or even useful to pollute the JWT claims registry with the names of all=
 the authorization request parameters. I happen to be one of the DEs on the=
 JWT claims registry so, in theory, I have some idea what I'm talking a=
bout here. In theory. And I do have to be upfront at this point and say tha=
t I will push back on a request for registration of a bunch of authorizatio=
n request parameters into the JWT claims registry without without more comp=
elling reason. =C2=A0 

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura=
 <sakimura@gmail=
.com> wrote:

Thanks very much for the comments.=C2=A0
Here =
are my responses to your comments.=C2=A0

On Wed, Jul 3, 2019 =
at 2:59 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
>
> Be=
njamin Kaduk has entered the following ballot position for
> draft-ie=
tf-oauth-jwsreq-19: Discuss
>
> When responding, please keep th=
e subject line intact and reply to all
> email addresses included in =
the To and CC lines. (Feel free to cut this
> introductory paragraph,=
 however.)
>
>
> Please refer to https://www=
.ietf.org/iesg/statement/discuss-criteria.html
> for more informa=
tion about IESG DISCUSS and COMMENT positions.
>
>
> The =
document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/>
>
>
> --------------------------------------------=
--------------------------
> DISCUSS:
> -----------------------=
-----------------------------------------------
>
> My apologie=
s; my previous position was incomplete.=C2=A0 Updated to note
> names=
pacing issues, and one minor terminology nit about "DNS-ID".
&=
gt;
> There seem to be some pretty serious namespacing issues that ar=
e not
> discussed at all in this document.=C2=A0 Specifically, using =
JWT as a
> container for OAuth 2.0 authorization request parameters (=
including
> extension parameters) introduces the usage of many new na=
mes (of JSON
> name/value pairs) into the JWT claims namespace.=C2=A0=
 Furthermore, the
> addition is not bounded, as any new OAuth extensi=
on parameters are
> implicitly permitted to be used as well!=C2=A0 Th=
e IANA Considerations make
> no mention of the collapsed namespace fo=
r JWT claims and OAuth 2.0
> (authorization request) parameters, leav=
ing substantial potential for
> collisions in the future.

The =
simplest solution probably is to register the authorization request paramet=
ers to the JWT Claims registry.
According to my checking, the relevant b=
ut not yet registered parameters are:

Claim Name: "code_challen=
ge"
Claim Description: OAuth PKCE Code Challenge
Change Controll=
er: IESG
Specification Document(s): Section 3 of RFC 7636

Claim N=
ame: "code_challenge_method"
Claim Description: OAuth PKCE Cod=
e Challenge
Change Controller: IESG
Specification Document(s): Sectio=
n 3 of RFC 7636

Claim Name: "redirect_uri"
Claim Descri=
ption: OAuth Redirection URI
Change Controller: IETF
Specification Do=
cument(s): Section 4.1.1 of RFC 6749

Claim Name: "response_type=
"
Claim Description: OAuth Authorization Response type
Change Co=
ntroller: IETF
Specification Document(s): Section 3.1.1 of RFC 6749
<=
br>Claim Name: "state"
Claim Description: OAuth state paramete=
r
Change Controller: IETF
Specification Document(s): Section 4.1.1 of=
 RFC 6749

Claim Name: "vtr"
Claim Description: Vector o=
f Trust request
Change Controller: IESG
Specification Document(s): Se=
ction 4.1 of RFC 8485

> Relatedly, using "application/jwt&qu=
ot; as the Content-type of the
> HTTP response from dereferencing the=
 request_uri with no explicit
> indication of the type/profile of JWT=
 used (whether in the content type
> or in the JWT claims themselves)=
 gives some risk of misinterpretation of
> the content..=C2=A0 Consid=
er, for example, when that request_uri is
> dereferenced not by the a=
uthorization server in the process of
> fulfilling an authorization r=
equest, but instead by some other service
> that expects a different =
type of JWT.

I am making the change to "application/oauth-authz=
-req+jwt" and add IANA request.

>
> This second point =
is a "discuss discuss" -- it's an important question
> =
and I'd like to talk about it, but it's not clear that any change t=
o the
> document will be needed.
>
> The introduction not=
es as an advantage of JWT that:
>
> =C2=A0 =C2=A0(d) =C2=A0(col=
lection minimization) The request can be signed by a third
> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 party attesting that the authorization request is comp=
liant with
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a certain policy.=C2=A0 For =
example, a request can be pre-examined by
> =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 a third party that all the personal data requested is strictly
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 necessary to perform the process that the end-u=
ser asked for,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and statically signed by=
 that third party.=C2=A0 The authorization
> =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 server then examines the signature and shows the conformance
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status to the end-user, who would have some ass=
urance as to the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 legitimacy of the requ=
est when authorizing it.=C2=A0 In some cases,
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 it may even be desirable to skip the authorization dialogue
> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 under such circumstances.
>
> I'=
;m pretty uncomfortable about suggesting that the authorization
> dia=
logue can/should be skipped; do we need to keep this example?
>
I have actually deliberately put this text as there seem to be some disco=
nnect between the engineering community and the privacy regulators communit=
y. Asking for "consent" is something that should be considered as=
 an exception and should use other lawful basis if possible as UK ICO (The =
data protection regulator in the UK) advises. As the editor of "ISO/IE=
C 29184 Privacy notice and consent", which is being developed with clo=
se coordination with regulators such as European Data Protection Board, I w=
ould have to agree to that position and I took OAuth JAR as one of the oppo=
rtunity to call it out. I will add some text explaining it such as:=C2=A0

In some cases, it is deemed harmful to ask for cons=
ent when it is not necessary: i.e., the processing is performed under other=
 lawful basis than consent, as it would make the consent, that should be an=
 exception, stand out less. Under such circumstances, this mechanism can be=
 used=C2=A0to skip the authorization dialogue.=C2=A0=C2=A0

>
&=
gt; ----------------------------------------------------------------------<=
br>> COMMENT:
> --------------------------------------------------=
--------------------
>
> Section 1
>
> =C2=A0 =C2=
=A0While it is easy to implement, the encoding in the URI does not allow> =C2=A0 =C2=A0application layer security with confidentiality and inte=
grity
> =C2=A0 =C2=A0protection to be used.=C2=A0 While TLS is used t=
o offer communication
>
> nit: this wording is a little hard to=
 read; it might be easier to
> reorder to "does not allow applic=
ation layer security to be used to
> provide confidentiality and inte=
grity protection".

Thanks. I will make the change.

><=
br>> =C2=A0 =C2=A0The use of application layer security allows requests =
to be prepared
> =C2=A0 =C2=A0by a third party so that a client appli=
cation cannot request more
> =C2=A0 =C2=A0permissions than previously=
 agreed.=C2=A0 This offers an additional degree
> =C2=A0 =C2=A0of pri=
vacy protection.
>
> (side note) what would an example of such =
a third party be. =C2=A0(We already
> have the resource owner, the cl=
ient, and the authorization server ...
> maybe it's a fourth part=
y?)

It is a fourth party, e.g., a trust framework provider or an inf=
ormation fiduciary.
The text need to be modified though as I found an er=
ror.
Since now all the OAuth Request parameters must be in the request o=
bject,
only the pattern that can be supported for something like this is=
 to push
the request object to the TFP and have the TFP check if it meet=
s the policy
and return request_uri only it is evelauted as OK.

&=
gt;
> =C2=A0 =C2=A0Furthermore, the request by reference allows the r=
eduction of over-
> =C2=A0 =C2=A0the-wire overhead.
>
> W=
e only barely mentioned by-reference at this point (one line in the
>=
 Abstract), so I'd suggest "passing the request by reference"=
.

Thanks. I will make the change.

>
> =C2=A0 =C2=A0(=
4) =C2=A0its development status that it is an RFC and so is its
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 associated signing and encryption methods as [RFC7=
515] and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7516]
>
> nit:=
 I'd suggest "its development status as a Proposed Standard, along=

> with the associated signing and encryption methods [RFC7515] [RFC7=
516]."

Thanks. I will make the change.

>
> =C2=
=A0 =C2=A0(c) =C2=A0(confidentiality protection) The request can be encrypt=
ed so
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 that end-to-end confidentiality c=
an be provided even if the TLS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 connecti=
on is terminated at one point or another.
>
> nit: TLS is alway=
s terminated at or before the user-agent, though.=C2=A0 So
> maybe th=
e user agent needs to get called out here as well (there could
> of c=
ourse be TLS termination earlier than the user-agent in some cases,
>=
 too).

Thanks. I will make the change.

>
> =C2=A0 =
=C2=A02.=C2=A0 When the client does not want to do the crypto.=C2=A0 The> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Server may provide an endpoi=
nt to accept the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization Request t=
hrough direct communication with the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Cli=
ent so that the Client is authenticated and the channel is TLS
> =C2=
=A0 =C2=A0 =C2=A0 =C2=A0protected.
>
> How can you "not wa=
nt to do [the] crypto" but still be doing TLS (with
> crypto)?=
=C2=A0 Perhaps we're looking for "not want to pay the additional> overhead of JWS/JWE cryptography on top of TLS"?

Thanks.=
 I will make the change.

>
> Section 1.1
>
> RF=
C 8174 has updated BCP 14 boilerplate text to use.

Thanks. I will ma=
ke the change. 

>
> Section 3
>
> nit: should t=
his section be 2.3 to get wrapped into "terminology"?

It c=
ould, but I suppose it could be as is. 

>
> It might also b=
e worth putting references in for the terms, though they
> are largel=
y common knowledge at this point.

Hopefully, they are public knowled=
ge ... 

>
> Section 4
>
> =C2=A0 =C2=A0A Reques=
t Object (Section 2.1) is used to provide authorization
> =C2=A0 =C2=
=A0request parameters for an OAuth 2.0 authorization request.=C2=A0 It MUST=

> =C2=A0 =C2=A0contains all the OAuth 2.0 [RFC6749] authorization re=
quest parameters
> =C2=A0 =C2=A0including extension parameters.=C2=A0=
 The parameters are represented as
>
> nit: "all the param=
eters" kind of sounds like "all that are defined"..
> =
But I think the intent here is "any parameter used to process the
&=
gt; request must come from the request object and URL query parameters are<=
br>> ignored", so maybe "MUST contain all the parameters (incl=
uding extension
> parameters) used to process the OAuth 2.0 [RFC6749]=
 authorization
> request; parameters from other sources MUST NOT be u=
sed", akin to what
> we say down in Sections 5 and 6.3..
>=
 But we need to be careful about the wording to not exclude the usage of> the "request" and "request_uri" query parameters =
to =C2=A0find the Request
> Object!

Thanks. I will make the de=
scription more exact. 

>
> =C2=A0 =C2=A0the JWT claims.=C2=
=A0 Parameter names and string values MUST be included
>
> nit:=
 maybe "the JWT claims of the object"?

Thanks. I will prob=
ably make it "the JWT claims of the request object."

><=
br>> =C2=A0 =C2=A0any extension parameters.=C2=A0 This JSON [RFC7159] co=
nstitutes the JWT
> =C2=A0 =C2=A0Claims Set defined in JWT [RFC7519].=
=C2=A0 The JWT Claims Set is then
> =C2=A0 =C2=A0signed or signed and=
 encrypted.
>
> nit: I =C2=A0think we want "This JSON [RFC=
7159] object".

Thanks. I will fix it as suggested. 

>=

> (Long quote incoming)
>
> =C2=A0 =C2=A0The following i=
s an example of the Claims in a Request Object before
> =C2=A0 =C2=A0=
base64url encoding and signing.=C2=A0 Note that it includes extension
&g=
t; =C2=A0 =C2=A0variables such as "nonce" and "max_age"=
.
>
> =C2=A0 =C2=A0 =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 "=
iss": "s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 "aud&q=
uot;: "https:=
//server..example.com",
> =C2=A0 =C2=A0 =C2=A0 "respons=
e_type": "code id_token",
> =C2=A0 =C2=A0 =C2=A0 "=
;client_id": "s6BhdRkqt3",
> =C2=A0 =C2=A0 =C2=A0 &quo=
t;redirect_uri": "https://client..example.org/cb",
> =C2=A0 =C2=
=A0 =C2=A0 "scope": "openid",
> =C2=A0 =C2=A0 =C2=
=A0 "state": "af0ifjsldkj",
> =C2=A0 =C2=A0 =C2=
=A0 "nonce": "n-0S6_WzA2Mj",
> =C2=A0 =C2=A0 =C2=
=A0 "max_age": 86400
> =C2=A0 =C2=A0 =C2=A0}
>
>=
; =C2=A0 =C2=A0Signing it with the "RS256" algorithm results in t=
his Request Object
> =C2=A0 =C2=A0value (with line wraps within value=
s for display purposes only):
>
> =C2=A0 =C2=A0 =C2=A0eyJhbGciO=
iJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> =C2=A0 =
=C2=A0 =C2=A0F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQog=
InJl
> =C2=A0 =C2=A0 =C2=A0c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQ=
ogImNsaWVudF9pZCI6ICJzNk
> =C2=A0 =C2=A0 =C2=A0JoZFJrcXQzIiwNCiAicmVk=
aXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
> =C2=A0 =C2=A0 =C2=A0bG=
Uub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> =
=C2=A0 =C2=A0 =C2=A0Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtY=
XhfYWdlIjog
> =C2=A0 =C2=A0 =C2=A0ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQo=
gICAidXNlcmluZm8iOiANCiAgICB7DQ
> =C2=A0 =C2=A0 =C2=A0ogICAgICJnaXZlb=
l9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> =C2=A0 =C2=A0 =
=C2=A0Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS> =C2=A0 =C2=A0 =C2=A0wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWw=
iOiB0cnVlfSwNCiAg
> =C2=A0 =C2=A0 =C2=A0ICAgInBpY3R1cmUiOiBudWxsDQogI=
CAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
> =C2=A0 =C2=A0 =C2=A0sNCiAgICA=
gImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> =C2=A0 =
=C2=A0 =C2=A0dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYW=
NlOm
> =C2=A0 =C2=A0 =C2=A0luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQog=
IH0NCn0.nwwnNsk1-Zkbmnvs
> =C2=A0 =C2=A0 =C2=A0F6zTHm8CHERFMGQPhos-EJ=
caH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
> =C2=A0 =C2=A0 =C2=A0Kz=
uMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> =
=C2=A0 =C2=A0 =C2=A00GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfq=
KnRlrRscc8K
> =C2=A0 =C2=A0 =C2=A0ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7=
CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
> =C2=A0 =C2=A0 =C2=A0iyon_-Te111V8uE=
83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>
> Decoding th=
e base64 of the body, we see:
> {
> =C2=A0"iss": &quo=
t;s6BhdRkqt3",
> =C2=A0"aud": "https://server.example.com"=
,
> =C2=A0"response_type": "code id_token",
&g=
t; =C2=A0"client_id": "s6BhdRkqt3",
> =C2=A0"=
;redirect_uri": "https://client.example.org/cb",
> =C2=A0"s=
cope": "openid",
> =C2=A0"state": "af0i=
fjsldkj",
> =C2=A0"nonce": "n-0S6_WzA2Mj",> =C2=A0"max_age": 86400,
> =C2=A0"claims":<=
br>> =C2=A0 {
> =C2=A0 =C2=A0"userinfo":
> =C2=A0 =
=C2=A0 {
> =C2=A0 =C2=A0 =C2=A0"given_name": {"essenti=
al": true},
> =C2=A0 =C2=A0 =C2=A0"nickname": null,> =C2=A0 =C2=A0 =C2=A0"email": {"essential": true},=

> =C2=A0 =C2=A0 =C2=A0"email_verified": {"essential&q=
uot;: true},
> =C2=A0 =C2=A0 =C2=A0"picture": null
> =
=C2=A0 =C2=A0 },
> =C2=A0 =C2=A0"id_token":
> =C2=A0 =
=C2=A0 {
> =C2=A0 =C2=A0 =C2=A0"gender": null,
> =C2=
=A0 =C2=A0 =C2=A0"birthdate": {"essential": true},
&=
gt; =C2=A0 =C2=A0 =C2=A0"acr": {"values": ["urn:ma=
ce:incommon:iap:silver"]}
> =C2=A0 =C2=A0 }
> =C2=A0 }
=
> }
>
> I'm not sure where the "claims" claim =
is coming from -- 6749 doesn't
> seem to talk about it. =C2=A0(No=
te that this example is used later on as
> well.)

It is an ext=
ension parameter that is registered in the OAuth authorization request regi=
stry. 
It is defined in OpenID Connect Core and OIDF is in the process o=
f registering it to the JWT Claims registry as well. I have put them to sho=
w that extension parameters can also be used in the request object. Having =
said that, they may be confusing. I should just remove them.=C2=A0

&=
gt;
> Section 5.2.1
>
> =C2=A0 =C2=A0It is possible for t=
he Request Object to include values that are to
> =C2=A0 =C2=A0be rev=
ealed only to the Authorization Server.=C2=A0 As such, the
> =C2=A0 =
=C2=A0"request_uri" MUST have appropriate entropy for its lifetim=
e.=C2=A0 For
> =C2=A0 =C2=A0the guidance, refer to 5.1.4.2.2 of [RFC6=
819].=C2=A0 It is RECOMMENDED
> =C2=A0 =C2=A0that it be removed after=
 a reasonable timeout unless access control
> =C2=A0 =C2=A0measures a=
re taken.
>
> It sounds like a link to https://www.w3.org/TR/capabili=
ty-urls/ might
> also be useful.
>

Thanks. I will ad=
d it. 

> Section 5.2.2
>
> Do we want to remind the r=
eader that the other query parameters are just
> for backwards compat=
ibility?

It is probably be better to remove them as they are not all=
owed to be used. 

>
> Section 5.2.3
>
> =C2=A0 =
=C2=A0The following is an example of this fetch process:
>
> =
=C2=A0 =C2=A0 =C2=A0GET /request.jwt HTTP/1.1
> =C2=A0 =C2=A0 =C2=A0H=
ost: tfp.example.org
>
> It's useful to show good hygeine in examples; can we=
 get the extra
> entropy in this request that we have in the previous=
 example(s)?

Thanks for pointing out. I will fix it. (The previous e=
xample also needs to be changed.) 

>
> Section 6.2
><=
br>> =C2=A0 =C2=A0The Authorization Server MUST perform the signature va=
lidation of the
> =C2=A0 =C2=A0JSON Web Signature [RFC7515] signed re=
quest object.=C2=A0 For this, the
> =C2=A0 =C2=A0"alg" Head=
er Parameter in its JOSE Header MUST match the value of the
> =C2=A0 =
=C2=A0pre-registered algorithm..=C2=A0 The signature MUST be validated agai=
nst
> =C2=A0 =C2=A0the appropriate key for that "client_id"=
 and algorithm.
>
> Does "the pre-registered algorithm&quo=
t; concept exist in the specs outside
> of draft-ietf-oauth-jwt-bcp?<=
br>
Yes. RFC7591 combined with some of the OAuth Dynamic Client Registra=
tion Metadata registry forms the concept. RFC7591 allows clients to registe=
r the claims that is in the OAuth Dynamic Client Registration Metadata regi=
stry. The registry has
  • request_object_signing_alg
  • reques=
t_object_encryption_alg
besides others. Having said that, it is a =
bit obscure so I probably should put some more explanation around it.=C2=A0=


>
> Section 8
>
> =C2=A0 =C2=A0HTTP clients MU=
ST also verify the TLS server certificate, using
> =C2=A0 =C2=A0subje=
ctAltName dNSName identities as described in [RFC6125], to avoid
> =
=C2=A0 =C2=A0man-in-the-middle attacks.=C2=A0 The rules and guidelines defi=
ned in
>
> It's probably easier to just say "using DNS=
-ID [RFC6125], to avoid
> man-in-the-middle attacks".

Thanks. I will do so.=C2=A0

>
> Section 9>
> The error codes we list in Section 7 are already registered,=
 for the
> OIDC usage.=C2=A0 Do we want to say anything about that? =
=C2=A0 (I guess it would
> be disallowed by process to try to update =
the existing registration to
> also point at this document.)

OIDC is an extension of OAuth and it should be fine as is.=
=C2=A0
What we need to be careful is that there will be no confli=
ct going forward.=C2=A0
I will put the instruction update that wi=
ll be provided by Mike (Jones).=C2=A0

>
> Section 10=

>
> We probably also want to reference draft-ietf-oauth-jwt-bc=
p.

Thanks. I will put the reference as draft.=C2=
=A0

>
> Section 10.1
>
> =C2=A0 =C2=A0Wh=
en sending the authorization request object through "request"
=
> =C2=A0 =C2=A0parameter, it MUST either be signed using JWS [RFC7515] o=
r encrypted
> =C2=A0 =C2=A0using JWE [RFC7516] with then considered a=
ppropriate algorithm.
>
> Up in Section 5 we only allow (a) sig=
ned and (b) signed then encrypted;
> similarly, in Section 4 we reite=
rate "signed then encrypted".=C2=A0 Why is it
> okay to tal=
k about just "signed or encrypted" here?

Very good catch. It should be changed to align with other sections.=C2=A0<=
/div>

>
> Section 10.2
>
> =C2=A0 =C2=A0(b) =
=C2=A0Verifying that the symmetric key for the JWE encryption is the
>=
; =C2=A0 =C2=A0 =C2=A0 =C2=A0 correct one if the JWE is using symmetric enc=
ryption.
>
> Similarly to the previous point, you also need to =
check the signature,
> which will always be there.

You are right. This one should be removed.=C2=A0

><=
br>> =C2=A0 =C2=A0(d) =C2=A0Authorization Server is providing an endpoin=
t that provides a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request Object URI in=
 exchange for a Request Object.=C2=A0 In this
>
> I don't t=
hink this is a complete sentence (and it's definitely not a
> par=
allel construction with (a)-(c)!).=C2=A0 I think perhaps a crisp one-line> summary of this method would be "Delegating the authorization c=
heck to a
> separate "Request Object to Request Object URI"=
 endpoint on the
> Authorization Server". =C2=A0(The writing in =
the rest of this paragraph could
> also use an editing pass.)

Thanks for pointing it out. Changing as follows would be =
ok?=C2=A0

(d) When=C2=A0Authorization Server is pro=
viding an endpoint that provides a
Request Object URI in exchange for a Request=
 Object,=C2=A0
the Authorization Server MUST perform Client=

Aut=
hentication to accept the Request Object and bind the Client
Identifier to the =
Request Object URI it is providing. Since
Request Object URI can be replayed, t=
he lifetime of the Request
Object URI MUST be short and preferably one-time use=
. The
The adequate sh=
ortness of the validity and the entropy of the
Request Object URI depends on th=
e risk calculation based on the
value of the resource being protected. A genera=
l guidance for
the validity time would be less than a minute and the Request
Object=
 URI is to include a cryptographic random value of 128bit
or more at the time=
 of the writing of this specification.=C2=A0=C2=A0

>=
;
> =C2=A0 =C2=A0(e) =C2=A0A third party, such as a Trust Framework P=
rovider, provides an
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 endpoint that prov=
ides a Request Object URI in exchange for a
> =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Request Object.=C2=A0 The same requirements as (b) above apply.=C2=
=A0 In
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 addition, the Authorization Serv=
er MUST know out-of-band that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Clien=
t utilizes the Trust Framework Operator.
>
> The Authorization =
Server also has to trust the third-party provider to
> actually do it=
s job and not misbehave, right?

Yes. I will add wo=
rding around it.=C2=A0

>
> Section 10.3
>
&=
gt; I'm not entirely sure what "[t]he endpoints that come into que=
stion in
> this specification" is supposed to mean -- is it just=
 "the OAuth 2.0
> endpoints presently defined in Standards-Track=
 RFCs"?

Yes. RFC6749, RFC6750, and RFC8414.=
=C2=A0

>
> =C2=A0 =C2=A0In [RFC6749], while Redirect=
ion URI is included, others are not
> =C2=A0 =C2=A0included in the Au=
thorization Request.=C2=A0 As the result, the same
> =C2=A0 =C2=A0app=
lies to Authorization Request Object.
>
> nit: included in what=
?

In the Authorization request.=C2=A0
I =
thought it would be too onerous to state

In [RFC6749], while Redirection URI is =
included in the Authorization Request,=C2=A0
others are not included in =
the Authorization Request.=C2=A0 As the result, the same
applies to Auth=
orization Request Object.=C2=A0=C2=A0

Would you like t=
o add "in the Authorization Request" as above?=C2=A0
>
> Section 10.4
>
> It's probably al=
so worth citing the generic URI security considerations
> from RFC 39=
86, here.

I will do so. Thanks.=C2=A0
>
> Section 10.4.1
>
> =C2=A0 =C2=A0"request_ur=
i", and (d) do not perform recursive GET on the
> =C2=A0 =C2=A0&=
quot;request_uri".
>
> nit: remove the "do" in o=
rder to make the construction parallel.

Thanks. I =
will do so.=C2=A0

>
> Section 12.1
>
> =
=C2=A0 =C2=A0It is often hard for the user to find out if the personal data=
 asked
> =C2=A0 =C2=A0for is strictly necessary.=C2=A0 A Trust Framew=
ork Provider can help the
> =C2=A0 =C2=A0user by examining the Client=
 request and comparing to the proposed
> =C2=A0 =C2=A0processing by t=
he Client and certifying the request.=C2=A0 After the
> =C2=A0 =C2=A0=
certification, the Client, when making an Authorization Request, can
>=
; =C2=A0 =C2=A0submit Authorization Request to the Trust Framework Provider=
 to
> =C2=A0 =C2=A0obtain the Request Object URI.
>
> sid=
e note: In my head the act of certification was the act of making the
&g=
t; translation to a Request Object URI, so I'm kind of curious where my=

> vision differs from reality.

So, I should=
 probably expand the text.=C2=A0
The process is two steps:=C2=A0<=
/div>

1. (Certification Process) The TFP examines the bu=
siness process of the client and determines what claims they needs: This is=
 the certification process. Once the client is certified, then they are iss=
ued a client credential to authenticate against to push request objects to =
the TFP to get the request_uri.=C2=A0

2. (Translat=
ion Process) The client uses the client credential that it got to push the =
request object to the TFP to get the request_uri.=C2=A0
=C2=A0
=

>
> The third paragraph seems to mostly just be describing th=
e procedure of
> how this flow works, which would not necessarily be =
specific to the
> privacy considerations section.

The third paragraph is also important from the privacy point of view.=
=C2=A0
In a trust framework that has a policy to only allow TFP v=
etted request object,=C2=A0
then the Authorization Server must ma=
ke sure that it was.=C2=A0
One way to do it is to check the autho=
rity section.=C2=A0

>
> Section 12.2.2>
> =C2=A0 =C2=A0Even if the protected resource does not include =
a personally
> =C2=A0 =C2=A0identifiable information, it is sometimes=
 possible to identify the
> =C2=A0 =C2=A0user through the Request Obj=
ect URI if persistent per-user Request
> =C2=A0 =C2=A0Object URI is u=
sed.=C2=A0 A third party may observe it through browser
>
> nit=
: need an article for "persistent per-user Request Object URI" (o=
r
> make it plural, as "URIs are used").

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








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


-- 
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en






<=
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.
--0000000000004f36fb058ebce1f6--


From nobody Sun Jul 28 14:31: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 8B44B120094 for ; Sun, 28 Jul 2019 14:31:28 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0rJ71FiewiP for ; Sun, 28 Jul 2019 14:31:25 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84C120048 for ; Sun, 28 Jul 2019 14:31:23 -0700 (PDT)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id F0CF4472EE6; Mon, 29 Jul 2019 06:31:22 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id AFF134E0046; Mon, 29 Jul 2019 06:31:22 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id x6SLVMjp006368; Mon, 29 Jul 2019 06:31:22 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id x6SLVMqO006366; Mon, 29 Jul 2019 06:31:22 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SLVOIj040497; Mon, 29 Jul 2019 06:31:24 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id x6SLVOkL040496; Mon, 29 Jul 2019 06:31:24 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SLVOsZ040493; Mon, 29 Jul 2019 06:31:24 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM08PA.cu.nri.co.jp (172.159.253.50) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 06:31:21 +0900
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (104.47.92.54) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 06:31:20 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eIq8hJNVT9/whWqKoPN+DLAHgPkVkCr7zBIr4KOAd/WxakY6YKGNDZQqvHTdKsWK8c17PztXj/2Ug3WmFldT9pN013eFVnyDdycm4yadT0a8l1+C7kP2VPXeR+At1x+B4mwEAmmdI5Mx/iG6htOBPzf/tFa4Q8p0EWB1Jk9ICAvHIZ+hpqrN1eTZCvOXBktJ7Dk166A3RhSE9shC9P8m/n90LRSZ8Viwh6v9gOOeSuypxO6YUN3uYB9dckSfTpSOTpESCWjdw1Y0b+3Nytw8ZvkIrJLuAulUowpuwg/cOcmpSe47W+XmsPcmzQmRdfX8iYchHaYlScQbXDBqzV5Y2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mydvS3+UWD30w4IrJKfgJiId75BuUCrBnvgvLw9DNrY=; b=Ckg6o1a453sM+m8A9BWK/gaIPWysea6eDLk5Fy8S1mDZkJ/bKAZVFhHYFJ8CwxkwHwWa87IhhnGKkN8kqjvKcGDq3uKEP+5fVZdfRk/fIipYsIaesAajPGHZYlItayyy/yB/U64NBbXqx5MB+Mu4/rxoA6Bd5o58VyShLdgyzUpXab/iP1/O8ZMa3UHEfruT72vF50bFAl7o7iZyuLBcICN1NY7vIMSqTs0cXeQ77hRIwtpJaqK6+d834F6f924CPZSzzBwzSBYZzcrJqIJbeXtboZCfQFtufMZwfea04XXx0gEdZI3JQ3f+UiNdImbAUgIKNazpMTYQ0eJNLgtBmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cu.nri.co.jp;dmarc=pass action=none header.from=cu.nri.co.jp;dkim=pass header.d=cu.nri.co.jp;arc=none
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com (20.179.173.206) by TYAPR01MB2255.jpnprd01.prod.outlook.com (52.133.179.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Sun, 28 Jul 2019 21:31:19 +0000
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33]) by TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33%6]) with mapi id 15.20.2115.005; Sun, 28 Jul 2019 21:31:19 +0000
From: n-sakimura 
To: Justin Richer , David Waite 
CC: OAuth WG 
Thread-Topic: [OAUTH-WG] Feedback on OAuth for browser-based Apps
Thread-Index: AQHVQFTMw7yeGuX7O0STdvZ1BA6HuqbaRcAAgAC44QCAAD12gIAFWHGA
Date: Sun, 28 Jul 2019 21:31:19 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailadviser: Ver 3.40R03
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [133.250.166.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8d9273ad-eadf-4a5c-1d93-08d713a2ee2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB2255; 
x-ms-traffictypediagnostic: TYAPR01MB2255:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01128BA907
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39830400003)(396003)(136003)(199004)(189003)(51444003)(606006)(26005)(6506007)(53546011)(8936002)(256004)(14444005)(66066001)(186003)(71200400001)(71190400001)(478600001)(2906002)(476003)(3846002)(486006)(446003)(76176011)(68736007)(86362001)(102836004)(81166006)(81156014)(966005)(14454004)(8676002)(99286004)(6116002)(7736002)(7696005)(11346002)(46636005)(66574012)(25786009)(9686003)(236005)(53936002)(76116006)(66556008)(66476007)(66446008)(66946007)(64756008)(6436002)(6246003)(55016002)(110136005)(2171002)(74316002)(52536014)(5660300002)(229853002)(6306002)(316002)(4326008)(54896002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB2255; H:TYAPR01MB4413.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: e10L7R0NsHUmkhqp4cT5TfVhvPWfsHOWlg/nVQjQiVP/H6vDWSU1f8CMW9QdfgEJ191Ux6xXoiOvb4He5y4lbCWOZjnD+IeJKU7gDdB1yrdUuuTWBf0ajMyiVMr+ZO2cx6bCXKT0UYA5gc2FhoqveuJktUGQrTgLMkszvysYofGBq1+36E5HwfDrXiteL609/SNiKmtHk9LjOzfxb22usAqaqFGto3XqB/nTH1NLpUNSisvhywe9QfWRDysCFtJR9GPVYk4gqzaX6220fVK8+BoKd3VadjFuywTqbjq+hPmA27nNJof7ww20243vSCh4Wt/LUZBF03ReDt+ws6LUdKvJZVXRiDvngHzW8uyqQw308waI38fHlVlUuj4pskVqc8F8YaAlerhVPpdaBhIAXHe6jS7l8BvHvhZliSXZ8SQ=
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB44137F45D4A889A933612885F9C20TYAPR01MB4413jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d9273ad-eadf-4a5c-1d93-08d713a2ee2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2019 21:31:19.6797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n-sakimura@cu.nri.co.jp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2255
X-OrganizationHeadersPreserved: TYAPR01MB2255.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] Feedback on OAuth for 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: Sun, 28 Jul 2019 21:31:29 -0000

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

QWdyZWVkLg0KDQpPbiB0aGUgcmVsYXRlZCBpc3N1ZSwgaXNzdWUgb2YgZXhwb3J0aW5nIHRoZSBh
Y2Nlc3MgdG9rZW4gdGhhdCBhIGNvbmZpZGVudGlhbCBjbGllbnQgZ290IHRvIGEgcHVibGljIGNs
aWVudCBpcyB0aGVyZSBhcyBpdCB3YXMgZGlzY3Vzc2VkIGluIHRoZSBGcmlkYXnigJlzIE9hdXRo
IFdHIG1lZXRpbmcuIFRob3VnaCBJIGRpZCBub3QgbWFrZSBhbnkgY29tbWVudCBvbiBGcmlkYXkg
YXMgd2Ugd2VyZSBydW5uaW5nIG91dCBvZiB0aW1lLCBJIHRoaW5rIHRoYXQgaXMgYSBiYWQgaWRl
YSBhcyB0aGUgQXV0aFogc2VydmVyIGhhcyBpc3N1ZWQgaXQgYXNzdW1pbmcgdGhhdCBpdCBpcyBr
ZXB0IGJ5IGEgY29uZmlkZW50aWFsIGNsaWVudC4NCg0KSHlicmlkIHJlc3BvbnNlIHR5cGUgd2Fz
IG1hZGUgYmVjYXVzZSBvZiB0aGUgdmlldyB0aGF0IHRoZSBwdWJsaWMgY2xpZW50IHNob3VsZCBn
ZXQgbGVzcyBwcml2aWxlZ2UuDQoNCklmIHdlIGFyZSBnZXR0aW5nIHJpZCBvZiBJbXBsaWNpdCBm
bG93LCB0aGlzIGFzcGVjdCBuZWVkIHRvIGJlIGFkZHJlc3NlZC4NCg0KSGF2aW5nIHNhaWQgdGhh
dDogaWYgU1BBIGlzIHVzaW5nIHRoZSBjb2RlIGZsb3csIGlzIGl0IG5vdCBhY3RpbmcgYXMgYSBw
dWJsaWMgY2xpZW50IHdpdGhvdXQgYSBjbGllbnQgc2VjcmV0Pw0KDQpOYXQNCg0KRnJvbTogT0F1
dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFJp
Y2hlcg0KU2VudDogVGh1cnNkYXksIEp1bHkgMjUsIDIwMTkgODo0NSBQTQ0KVG86IERhdmlkIFdh
aXRlIDxkYXZpZEBhbGthbGluZS1zb2x1dGlvbnMuY29tPg0KQ2M6IE9BdXRoIFdHIDxvYXV0aEBp
ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEZlZWRiYWNrIG9uIE9BdXRoIGZvciBi
cm93c2VyLWJhc2VkIEFwcHMNCg0KVGhpcyByYWlzZXMgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24g
dGhhdCBJIGRvbuKAmXQgdGhpbmsgd2XigJl2ZSBhZGRyZXNzZWQgeWV0OiBob3cgdG8gYXBwcm9w
cmlhdGVseSB2YXJ5IHRva2VuIGxpZmV0aW1lcyBhbmQgYWNjZXNzIGZvciBkaWZmZXJlbnQgY2xp
ZW50cy4NCg0KUHJldmlvdXNseSwgYW4gQVMgY291bGQgc2VlIHRoYXQgYSBjbGllbnQgd2FzIHVz
aW5nIHRoZSBpbXBsaWNpdCBmbG93IGFuZCBkZWNpZGUgdG8gbGltaXQgdG9rZW4gbGlmZXRpbWVz
IG9yIHNjb3BlcyBiYXNlZCBvbiB0aGF0IGFsb25lLiBTaW1pbGFybHksIEkga25vdyBvZiBhdCBs
ZWFzdCBzb21lIEFTIGltcGxlbWVudGF0aW9ucyB0aGF0IGxldCB5b3UgbGltaXQgd2hhdCBzY29w
ZXMgeW91IGFsbG93IHVuZGVyIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQuIFRoZSBrZXkg
aXNzdWUgaXMgdGhhdCBpZiBhbGwgeW91ciBjbGllbnRzIGFyZSB1c2luZyB0aGUgYXV0aCBjb2Rl
IGZsb3cgKHdoaWNoIEkgYWdyZWUgdGhleSBzaG91bGQpLCB0aGVuIGhvdyBkb2VzIGFuIEFTIHRl
bGwgdGhlIGRpZmZlcmVuY2UgaW4gY2FwYWJpbGl0aWVzIGJldHdlZW4gaW5jb21pbmcgY2xpZW50
cz8NCg0KT2J2aW91c2x5IGl0IGNhbiBkbyBpdCBvbiBhIHBlci1jbGllbnQgYmFzaXMgc3RpbGws
IGJ1dCBub3cgYW4gQVMgaXMgZ29pbmcgdG8gaGF2ZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQg
dGhlIGFwcCBpdHNlbGYuIFBlcmhhcHMgd2UgZmluYWxseSBuZWVkIGEgZmV3IG1vcmUgZW50cmll
cyBpbiB0aGUg4oCcYXBwbGljYXRpb25fdHlwZeKAnSBtZXRhZGF0YSBwYXJhbWV0ZXIgZnJvbSBP
SURD4oCZcyBleHRlbnNpb24gUkZDNzU5MSBiZXlvbmQg4oCcbmF0aXZl4oCdIGFuZCDigJx3ZWLi
gJ0/IEJ1dCB3ZSBhdCBsZWFzdCBwcm9iYWJseSB3YW50IHRvIHBvaW50IG91dCB0byBBUyBpbXBs
ZW1lbnRvcnMgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGV5IHdhbnQgdG8gY29uc2lkZXIgdHJh
Y2tpbmcgaW4gdGhlaXIgZGF0YSBtb2RlbCBmb3IgY2xpZW50cy4NCg0K4oCUIEp1c3Rpbg0KDQoN
Ck9uIEp1bCAyNSwgMjAxOSwgYXQgNDowNCBBTSwgRGF2aWQgV2FpdGUgPGRhdmlkQGFsa2FsaW5l
LXNvbHV0aW9ucy5jb208bWFpbHRvOmRhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb20+PiB3cm90
ZToNCg0KDQoNCg0KDQpPbiBKdWwgMjQsIDIwMTksIGF0IDM6MDMgUE0sIEFhcm9uIFBhcmVja2kg
PGFhcm9uQHBhcmVja2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KDQpP
biBNb24sIEp1bCAyMiwgMjAxOSBhdCAyOjE0IEFNIERvbWluaWNrIEJhaWVyDQo8ZGJhaWVyQGxl
YXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3Rl
Og0KPHNuaXA+DQoNCg0KSSB3b3VsZCByYXRoZXIgc2F5IHRoYXQgQU5ZIEpTIGFwcCBzaG91bGQg
dXNlIENTUCB0byBsb2NrIGRvd24gdGhlIGJyb3dzZXIgZmVhdHVyZXMgdG8gYSBtaW5pbWFsIGF0
dGFjayBzdXJmYWNlLiBJbiBhZGRpdGlvbiwgaWYgcmVmcmVzaCBvciBhY2Nlc3MgdG9rZW5zIGFy
ZSBpbnZvbHZlZCAtIGZ1cnRoZXIgc2V0dGluZ3MgbGlrZSBkaXNhYmxpbmcgaW5saW5lIHNjcmlw
dGluZyAodW5zYWZlIGlubGluZSkgYW5kIGV2YWwgc2hvdWxkIGJlIGRpc2FibGVkLg0KDQpJJ20g
bm90IHN1cmUgd2hhdCB0byBkbyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi4gSXQgZmVlbHMgbGlrZSBh
IGJsYW5rZXQNCnJlY29tbWVuZGF0aW9uIG9mIGVuYWJsaW5nIENTUCB3aWxsIGxpa2VseSBiZSBp
Z25vcmVkIHNpbmNlIGl0J3MgdG9vDQpicm9hZCwgYW5kIHJlY29tbWVuZGluZyBkaXNhYmxpbmcg
aW5saW5lIHNjcmlwdHMgaXMgb3ZlcnJlYWNoaW5nDQp1bmxlc3MgYmFja2VkIHVwIGJ5IGEgc3Bl
Y2lmaWMgdGhyZWF0IGl0J3MgcHJvdGVjdGluZyBhZ2FpbnN0LiBEaWQgeW91DQpoYXZlIGEgcGFy
dGljdWxhciB0aHJlYXQgaW4gbWluZD8NCg0KSSB3b3VsZCBzYXkgdGhhdCBicm93c2VyIGFwcGxp
Y2F0aW9ucyBzaG91bGQgdGFrZSBtZWFzdXJlcyB0byBoYXJkZW4gdGhlaXIgYXBwbGljYXRpb25z
IGFnYWluIGNvZGUgaW5qZWN0aW9uIGFuZCBhcmJpdHJhcnkgY29kZSBleGVjdXRpb24uIEV4YW1w
bGVzIGluY2x1ZGUgZWxpbWluYXRpbmcgaW5saW5lIHNjcmlwdCAoYW5kIGxpbWl0aW5nIGVtYmVk
ZGFibGUgb2JqZWN0cyBhcyBtdWNoIGFzIHBvc3NpYmxlKSB2aWEgQ1NQLCBhbmQgdmVyc2lvbmlu
ZyB0aGlyZCBwYXJ0eSByZXNvdXJjZXMgdmlhIHRlY2huaXF1ZXMgbGlrZSBzdWJyZXNvdXJjZSBp
bnRlZ3JpdHkuICBNZWNoYW5pc21zIHN1Y2ggYXMgYXVnbWVudGluZyB0aGUgY29kZWJhc2UgdG8g
bWFrZSBzdXJlIGFsbCBhcHByb3ByaWF0ZSB1c2VyIGlucHV0LCBkYXRhIHN0b3JhZ2UsIGFuZCBv
dXRwdXQgcHJvcGVybHkgc2FuaXRpemUgZGF0YSBtYXkgYmUgdXNlZCAtIGFsdGhvdWdoIHRoZXkg
bWF5IGJlIG1vcmUgZXhwZW5zaXZlIHRvIGltcGxlbWVudCBhbmQgYXVkaXQuDQoNClRoZSBBUyBz
aG91bGQgbGlrZXdpc2UgdGFrZSBpbnRvIGFjY291bnQgYW4gYXBwbGljYXRpb27igJlzIG92ZXJh
bGwgc2VjdXJpdHkgcG9zdHVyZSB3aGVuIGRlY2lkaW5nIGFwcHJvcHJpYXRlIHBvbGljaWVzIGFy
b3VuZCBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbiBzY29wZXMgYW5kIHRva2VuIGxpZmV0aW1lcy4N
Cg0KQmVzdCBjdXJyZW50IHByYWN0aWNlcyBpbmNsdWRlIHR1cm5pbmcgdGhlIHNjcmV3cyB0aWdo
dGx5IGFyb3VuZCBDU1AuIEJ1dCBpdCBpcyAodGhlb3JldGljYWxseSkgcG9zc2libGUgdG8gYWNj
b21wbGlzaCB0aGUgc2FtZSB3aXRoIGJydXRlLWZvcmNlIHNhbml0aXphdGlvbiwgd2hpY2ggaGFz
IGJlZW4gbWFkZSBzaW1wbGVyIHdpdGggZnJhbWV3b3JrIHN1cHBvcnQuIEl0IGlzIHN0aWxsIHVs
dGltYXRlbHkgdGhlIEFTIGpvYiB0byBkZWNpZGUgd2hpY2ggY2xpZW50cyBoYXZlIHdoaWNoIGNh
cGFiaWxpdGllcy4NCg0KLURXDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5
IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Iu+8re+8syDjgrTjgrfj
g4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglwYW5v
c2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJ
cGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi4xNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTku
MjVwdCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2Ij4NCjx2OnRleHRib3ggaW5zZXQ9
IjUuODVwdCwuN3B0LDUuODVwdCwuN3B0IiAvPg0KPC9vOnNoYXBlZGVmYXVsdHM+PC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkpBIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZ3Jl
ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5PbiB0aGUgcmVsYXRlZCBpc3N1ZSwgaXNzdWUgb2YgZXhwb3J0aW5nIHRo
ZSBhY2Nlc3MgdG9rZW4gdGhhdCBhIGNvbmZpZGVudGlhbCBjbGllbnQgZ290IHRvIGEgcHVibGlj
IGNsaWVudCBpcyB0aGVyZSBhcyBpdCB3YXMgZGlzY3Vzc2VkIGluIHRoZSBGcmlkYXnigJlzDQog
T2F1dGggV0cgbWVldGluZy4gVGhvdWdoIEkgZGlkIG5vdCBtYWtlIGFueSBjb21tZW50IG9uIEZy
aWRheSBhcyB3ZSB3ZXJlIHJ1bm5pbmcgb3V0IG9mIHRpbWUsIEkgdGhpbmsgdGhhdCBpcyBhIGJh
ZCBpZGVhIGFzIHRoZSBBdXRoWiBzZXJ2ZXIgaGFzIGlzc3VlZCBpdCBhc3N1bWluZyB0aGF0IGl0
IGlzIGtlcHQgYnkgYSBjb25maWRlbnRpYWwgY2xpZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SHlicmlkIHJlc3Bv
bnNlIHR5cGUgd2FzIG1hZGUgYmVjYXVzZSBvZiB0aGUgdmlldyB0aGF0IHRoZSBwdWJsaWMgY2xp
ZW50IHNob3VsZCBnZXQgbGVzcyBwcml2aWxlZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5JZiB3ZSBhcmUgZ2V0dGluZyByaWQgb2YgSW1wbGljaXQgZmxvdywgdGhp
cyBhc3BlY3QgbmVlZCB0byBiZSBhZGRyZXNzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYXZpbmcgc2FpZCB0aGF0
OiBpZiBTUEEgaXMgdXNpbmcgdGhlIGNvZGUgZmxvdywgaXMgaXQgbm90IGFjdGluZyBhcyBhIHB1
YmxpYyBjbGllbnQgd2l0aG91dCBhIGNsaWVudCBzZWNyZXQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5OYXQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8
Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBSaWNoZXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk
YXksIEp1bHkgMjUsIDIwMTkgODo0NSBQTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgV2FpdGUgJmx0
O2RhdmlkQGFsa2FsaW5lLXNvbHV0aW9ucy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBX
RyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt
V0ddIEZlZWRiYWNrIG9uIE9BdXRoIGZvciBicm93c2VyLWJhc2VkIEFwcHM8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHJhaXNlcyBhbiBpbnRlcmVzdGluZyBxdWVzdGlv
biB0aGF0IEkgZG9u4oCZdCB0aGluayB3ZeKAmXZlIGFkZHJlc3NlZCB5ZXQ6IGhvdyB0byBhcHBy
b3ByaWF0ZWx5IHZhcnkgdG9rZW4gbGlmZXRpbWVzIGFuZCBhY2Nlc3MgZm9yIGRpZmZlcmVudCBj
bGllbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UHJldmlv
dXNseSwgYW4gQVMgY291bGQgc2VlIHRoYXQgYSBjbGllbnQgd2FzIHVzaW5nIHRoZSBpbXBsaWNp
dCBmbG93IGFuZCBkZWNpZGUgdG8gbGltaXQgdG9rZW4gbGlmZXRpbWVzIG9yIHNjb3BlcyBiYXNl
ZCBvbiB0aGF0IGFsb25lLiBTaW1pbGFybHksIEkga25vdyBvZiBhdCBsZWFzdCBzb21lIEFTIGlt
cGxlbWVudGF0aW9ucyB0aGF0IGxldCB5b3UgbGltaXQgd2hhdCBzY29wZXMNCiB5b3UgYWxsb3cg
dW5kZXIgdGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudC4gVGhlIGtleSBpc3N1ZSBpcyB0aGF0
IGlmIGFsbCB5b3VyIGNsaWVudHMgYXJlIHVzaW5nIHRoZSBhdXRoIGNvZGUgZmxvdyAod2hpY2gg
SSBhZ3JlZSB0aGV5IHNob3VsZCksIHRoZW4gaG93IGRvZXMgYW4gQVMgdGVsbCB0aGUgZGlmZmVy
ZW5jZSBpbiBjYXBhYmlsaXRpZXMgYmV0d2VlbiBpbmNvbWluZyBjbGllbnRzPyZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T2J2aW91c2x5IGl0
IGNhbiBkbyBpdCBvbiBhIHBlci1jbGllbnQgYmFzaXMgc3RpbGwsIGJ1dCBub3cgYW4gQVMgaXMg
Z29pbmcgdG8gaGF2ZSB0byBrbm93IGEgYml0IG1vcmUgYWJvdXQgdGhlIGFwcCBpdHNlbGYuIFBl
cmhhcHMgd2UgZmluYWxseSBuZWVkIGEgZmV3IG1vcmUgZW50cmllcyBpbiB0aGUg4oCcYXBwbGlj
YXRpb25fdHlwZeKAnSBtZXRhZGF0YSBwYXJhbWV0ZXIgZnJvbQ0KIE9JREPigJlzIGV4dGVuc2lv
biBSRkM3NTkxIGJleW9uZCDigJxuYXRpdmXigJ0gYW5kIOKAnHdlYuKAnT8gQnV0IHdlIGF0IGxl
YXN0IHByb2JhYmx5IHdhbnQgdG8gcG9pbnQgb3V0IHRvIEFTIGltcGxlbWVudG9ycyB0aGF0IHRo
aXMgaXMgc29tZXRoaW5nIHRoZXkgd2FudCB0byBjb25zaWRlciB0cmFja2luZyBpbiB0aGVpciBk
YXRhIG1vZGVsIGZvciBjbGllbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCUIEp1c3Rpbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5P
biBKdWwgMjUsIDIwMTksIGF0IDQ6MDQgQU0sIERhdmlkIFdhaXRlICZsdDs8YSBocmVmPSJtYWls
dG86ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbSI+ZGF2aWRAYWxrYWxpbmUtc29sdXRpb25z
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+T24gSnVsIDI0LCAyMDE5LCBhdCAzOjAzIFBNLCBBYXJvbiBQYXJlY2tpICZsdDs8
YSBocmVmPSJtYWlsdG86YWFyb25AcGFyZWNraS5jb20iPmFhcm9uQHBhcmVja2kuY29tPC9hPiZn
dDsgd3JvdGU6PGJyPg0KPGJyPg0KT24gTW9uLCBKdWwgMjIsIDIwMTkgYXQgMjoxNCBBTSBEb21p
bmljayBCYWllcjxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdl
LmNvbSI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mbHQ7c25pcCZndDs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291
bGQgcmF0aGVyIHNheSB0aGF0IEFOWSBKUyBhcHAgc2hvdWxkIHVzZSBDU1AgdG8gbG9jayBkb3du
IHRoZSBicm93c2VyIGZlYXR1cmVzIHRvIGEgbWluaW1hbCBhdHRhY2sgc3VyZmFjZS4gSW4gYWRk
aXRpb24sIGlmIHJlZnJlc2ggb3IgYWNjZXNzIHRva2VucyBhcmUgaW52b2x2ZWQgLSBmdXJ0aGVy
IHNldHRpbmdzIGxpa2UgZGlzYWJsaW5nIGlubGluZSBzY3JpcHRpbmcNCiAodW5zYWZlIGlubGlu
ZSkgYW5kIGV2YWwgc2hvdWxkIGJlIGRpc2FibGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+
DQpJJ20gbm90IHN1cmUgd2hhdCB0byBkbyB3aXRoIHRoaXMgc3VnZ2VzdGlvbi4gSXQgZmVlbHMg
bGlrZSBhIGJsYW5rZXQ8YnI+DQpyZWNvbW1lbmRhdGlvbiBvZiBlbmFibGluZyBDU1Agd2lsbCBs
aWtlbHkgYmUgaWdub3JlZCBzaW5jZSBpdCdzIHRvbzxicj4NCmJyb2FkLCBhbmQgcmVjb21tZW5k
aW5nIGRpc2FibGluZyBpbmxpbmUgc2NyaXB0cyBpcyBvdmVycmVhY2hpbmc8YnI+DQp1bmxlc3Mg
YmFja2VkIHVwIGJ5IGEgc3BlY2lmaWMgdGhyZWF0IGl0J3MgcHJvdGVjdGluZyBhZ2FpbnN0LiBE
aWQgeW91PGJyPg0KaGF2ZSBhIHBhcnRpY3VsYXIgdGhyZWF0IGluIG1pbmQ/PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxicj4NCkkgd291bGQgc2F5IHRoYXQgYnJvd3NlciBhcHBsaWNhdGlvbnMgc2hv
dWxkIHRha2UgbWVhc3VyZXMgdG8gaGFyZGVuIHRoZWlyIGFwcGxpY2F0aW9ucyBhZ2FpbiBjb2Rl
IGluamVjdGlvbiBhbmQgYXJiaXRyYXJ5IGNvZGUgZXhlY3V0aW9uLiBFeGFtcGxlcyBpbmNsdWRl
IGVsaW1pbmF0aW5nIGlubGluZSBzY3JpcHQgKGFuZCBsaW1pdGluZyBlbWJlZGRhYmxlIG9iamVj
dHMgYXMgbXVjaCBhcyBwb3NzaWJsZSkgdmlhIENTUCwgYW5kIHZlcnNpb25pbmcNCiB0aGlyZCBw
YXJ0eSByZXNvdXJjZXMgdmlhIHRlY2huaXF1ZXMgbGlrZSBzdWJyZXNvdXJjZSBpbnRlZ3JpdHku
ICZuYnNwO01lY2hhbmlzbXMgc3VjaCBhcyBhdWdtZW50aW5nIHRoZSBjb2RlYmFzZSB0byBtYWtl
IHN1cmUgYWxsIGFwcHJvcHJpYXRlIHVzZXIgaW5wdXQsIGRhdGEgc3RvcmFnZSwgYW5kIG91dHB1
dCBwcm9wZXJseSBzYW5pdGl6ZSBkYXRhIG1heSBiZSB1c2VkIC0gYWx0aG91Z2ggdGhleSBtYXkg
YmUgbW9yZSBleHBlbnNpdmUgdG8gaW1wbGVtZW50DQogYW5kIGF1ZGl0Ljxicj4NCjxicj4NClRo
ZSBBUyBzaG91bGQgbGlrZXdpc2UgdGFrZSBpbnRvIGFjY291bnQgYW4gYXBwbGljYXRpb27igJlz
IG92ZXJhbGwgc2VjdXJpdHkgcG9zdHVyZSB3aGVuIGRlY2lkaW5nIGFwcHJvcHJpYXRlIHBvbGlj
aWVzIGFyb3VuZCBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbiBzY29wZXMgYW5kIHRva2VuIGxpZmV0
aW1lcy48YnI+DQo8YnI+DQpCZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGluY2x1ZGUgdHVybmluZyB0
aGUgc2NyZXdzIHRpZ2h0bHkgYXJvdW5kIENTUC4gQnV0IGl0IGlzICh0aGVvcmV0aWNhbGx5KSBw
b3NzaWJsZSB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIHdpdGggYnJ1dGUtZm9yY2Ugc2FuaXRpemF0
aW9uLCB3aGljaCBoYXMgYmVlbiBtYWRlIHNpbXBsZXIgd2l0aCBmcmFtZXdvcmsgc3VwcG9ydC4g
SXQgaXMgc3RpbGwgdWx0aW1hdGVseSB0aGUgQVMgam9iIHRvIGRlY2lkZSB3aGljaA0KIGNsaWVu
dHMgaGF2ZSB3aGljaCBjYXBhYmlsaXRpZXMuPGJyPg0KPGJyPg0KLURXPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_TYAPR01MB44137F45D4A889A933612885F9C20TYAPR01MB4413jpnp_--


From nobody Sun Jul 28 15:18: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 012D1120075; Sun, 28 Jul 2019 15:18:38 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcNUuQ5rCw1H; Sun, 28 Jul 2019 15:18:34 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3567212006E; Sun, 28 Jul 2019 15:18:34 -0700 (PDT)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 8EAAE472EE7; Mon, 29 Jul 2019 07:18:33 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id EBC1A4E0046; Mon, 29 Jul 2019 07:18:32 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id x6SMIWkV016274; Mon, 29 Jul 2019 07:18:32 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id x6SMIWMI016271; Mon, 29 Jul 2019 07:18:32 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SMIY5V010800; Mon, 29 Jul 2019 07:18:34 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id x6SMIYZ6010799; Mon, 29 Jul 2019 07:18:34 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SMIY7j010796; Mon, 29 Jul 2019 07:18:34 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 07:18:31 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (104.47.93.56) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 07:18:30 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nM4DXgg0fdRORByOAh+MOnS9cS3qZodbm+2tfRD18xCidO0T5QMB6Wy4D8dEdxmzmVHvHYCuu8WOCN179R42P8nB8SgZAvjhLCGaA1cPIynnzl5KHrSQdYYvbkxsRhbvIUPD04SKgtGwExB9hWw2hf3OLXqdplmQ2oCvc/MtgOhShaoN/idVD7PIdaqvQDCqhAd9r9g5WVo5T3FmZWbFP7gB8UO3vZai2wtadxxQO5zb9amrwKvHed/zkN2Nvffid5QNIejncJq8ANoOIc7pj7NKus/T+mCA7f5QNgpzYekfRjC7QTdSjIy9iRz0FLInKwVbF9chEMMYfa5UZSka0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O5uE8V6EbG4WuQTDgMwC9hSWNnXNt4Y0Ysia+cLrvlQ=; b=SyyTPAYkiOMUxBp0ZY7AEgXeSFot/BdSWMeAi1V73W640IPj7dInK8vBtGZ+V/CB+WpghU+yTd9XxtT9wQOHt5DxJDAhx0U5YRLg3xdusk7Swfg7EdV81iQh7Op3dbuYbYh+GFWvXq4JExrLpvuX8KnadpZHU+cQILBzAR0jK6h6E5oGAO0CGpb4ylelCrZfmZX2gCVct5IGS2Lksk7Q1BBtqn6KcrVWn3PwoyF95D+s1p2gG5RYo2XgjrM475TADVc0kDhSW1a7Zh5Hx2OZiILMO9FqHF9s6YsEACwO49luG4g/wD0KJJLOOuufTCVtftsn880l1L7oPHZpZnLyFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cu.nri.co.jp;dmarc=pass action=none header.from=cu.nri.co.jp;dkim=pass header.d=cu.nri.co.jp;arc=none
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com (20.179.173.206) by TYAPR01MB3423.jpnprd01.prod.outlook.com (20.178.138.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Sun, 28 Jul 2019 22:18:29 +0000
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33]) by TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::a506:c36d:83ec:1b33%6]) with mapi id 15.20.2115.005; Sun, 28 Jul 2019 22:18:29 +0000
From: n-sakimura 
To: Brian Campbell , Nat Sakimura 
CC: Benjamin Kaduk , "draft-ietf-oauth-jwsreq@ietf.org" , "oauth-chairs@ietf.org" , The IESG , oauth 
Thread-Topic: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Thread-Index: AQHVMdFm4kSOMdb7M0aAs1xstru2LqbdWreAgAAoQ4CAAzwAjw==
Date: Sun, 28 Jul 2019 22:18:29 +0000
Message-ID: 
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com> , 
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [39.111.85.236]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d3b9d3fd-7b3a-4448-a9e3-08d713a984e4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB3423; 
x-ms-traffictypediagnostic: TYAPR01MB3423:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:644;
x-forefront-prvs: 01128BA907
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39830400003)(136003)(346002)(396003)(189003)(199004)(14444005)(256004)(81156014)(26005)(5660300002)(66066001)(86362001)(8676002)(11346002)(3846002)(966005)(25786009)(68736007)(476003)(81166006)(478600001)(6116002)(21615005)(2906002)(186003)(52536014)(446003)(8936002)(486006)(30864003)(76116006)(99286004)(66476007)(66946007)(7696005)(76176011)(53546011)(6506007)(6436002)(316002)(66556008)(64756008)(66446008)(4326008)(606006)(6306002)(229853002)(236005)(18265965003)(102836004)(9686003)(53946003)(55016002)(54896002)(14454004)(71200400001)(71190400001)(46636005)(53936002)(54906003)(110136005)(33656002)(6246003)(74316002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB3423; H:TYAPR01MB4413.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fblFqPX04vH0Xu+GvGFvtF53Xa56IxQ9Y+il4v7pLjVngB+1td8vQ7i6xynkuqclBjJ0xeGSYW6bDJGzv1EEJfaoIzLd8Bn5F68MtKvV7a6YyF/fTr0ww1GIFoaj6AANIPrlwjjNm4JNZoqbvo3Aawu63q3jTPdN6M49sYqhaxA3HQllOJbQiACVJ+3iXN9AZKlia7kDxCG8T+vMtDKy1jYRJCiJubiP4T9bYBF+O99A0c5cIgRuZ7864+88RfhB58GilnM6YLMFw0Gq5/iaH6MuiJ7FIW+0KsZjdsBrITi/Pp/l+lV3kus9O1uAdGmOVjaPglvYBLa1pf/iyWEaYWwhO96KDax6Bc14WJytpMbgut6U2eXZEacUqV82b1RO9LXEcAr/rv4AeXcKcVDAbuC0wOl+F2F6rf1L+y4PnXU=
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB4413256F202E0FCA83735F36F9C20TYAPR01MB4413jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d3b9d3fd-7b3a-4448-a9e3-08d713a984e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2019 22:18:29.5523 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n-sakimura@cu.nri.co.jp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3423
X-OrganizationHeadersPreserved: TYAPR01MB3423.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Jul 2019 22:18:38 -0000

--_000_TYAPR01MB4413256F202E0FCA83735F36F9C20TYAPR01MB4413jpnp_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Brian,

You are the expert on the particular IANA registries so I probably are miss=
ing something.

I was thinking that registering JWT claims to OAuth registry is sufficient =
till seeing Ben=1B$B!G=1B(Bs comment, and I was tracking that it is being d=
one by Mike as part of the errata process for OIDC Core. However, after rea=
ding Ben=1B$B!G=1B(Bs comment that mentioning the OAuth extensions, and I c=
hecked that quite a few claims are now being registered to JWT Claims Regis=
try from outside the OAuth community, I started to feel that it may not be =
sufficient. But I must be missing something as you point out that is still =
sufficient.

Could you please explain how the collision between the future OAuth extensi=
on and JWT claims can be avoided by registering main JWT claims to the OAut=
h Parameter registry?
If that is the case, I am all for it as then we do not get back to IANA pro=
cess.

Best,

Nat

Nat Sakimura | =1B$B:jB<2FI'=1B(B
Nomura Research Institute

=1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$5$l$?5!L)>pJs$,4^$^$l$F$$$k>l=
9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"Aw?.e$2$^$9!#=1B(B

PLEASE READ=1B$B!'=1B(BThis e-mail is confidential and intended for the nam=
ed recipient only. If you are not an intended recipient, please notify the =
sender and delete this e-mail.

________________________________
=1B$B:9=3DP?M=1B(B: Brian Campbell 
=1B$BAw?.F|;~=1B(B: Saturday, July 27, 2019 5:47:15 AM
=1B$B08@h=1B(B: Nat Sakimura 
CC: Benjamin Kaduk ; draft-ietf-oauth-jwsreq@ietf.org ; oauth-chairs@ietf.org =
; The IESG ; oauth 
=1B$B7oL>=1B(B: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth=
-jwsreq-19: (with DISCUSS and COMMENT)

Nat, you suggest that the "simplest solution probably is to register the
authorization request parameters to the JWT Claims registry." However, as
I've attempted to articulate several times this week (
https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and
muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
even back in 2017 (
https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I
believe the pragmatic solution to this is to register some of the main JWT
claims into the OAuth parameters registry (not the other way around, as
you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an
authorization request parameter "aud", which would conflicted with the JWT
claim of the same name and cause big problems when used together with JAR).
I suppose the iron clad way to "fix" this would be to merge the two
registries and keep them in sync forever. But that seems awfully heavy
handed and unnecessary. JAR is a specific application of JWT being used to
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely
point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization
request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's
necessary or even useful to pollute the JWT claims registry with the names
of all the authorization request parameters. I happen to be one of the DEs
on the JWT claims registry so, in theory, I have some idea what I'm talking
about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of
authorization request parameters into the JWT claims registry without
without more compelling reason.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:

>
> Thanks very much for the comments.
> Here are my responses to your comments.
>
> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > My apologies; my previous position was incomplete.  Updated to note
> > namespacing issues, and one minor terminology nit about "DNS-ID".
> >
> > There seem to be some pretty serious namespacing issues that are not
> > discussed at all in this document.  Specifically, using JWT as a
> > container for OAuth 2.0 authorization request parameters (including
> > extension parameters) introduces the usage of many new names (of JSON
> > name/value pairs) into the JWT claims namespace.  Furthermore, the
> > addition is not bounded, as any new OAuth extension parameters are
> > implicitly permitted to be used as well!  The IANA Considerations make
> > no mention of the collapsed namespace for JWT claims and OAuth 2.0
> > (authorization request) parameters, leaving substantial potential for
> > collisions in the future.
>
> The simplest solution probably is to register the authorization request
> parameters to the JWT Claims registry.
> According to my checking, the relevant but not yet registered parameters
> are:
>
> Claim Name: "code_challenge"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "code_challenge_method"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "redirect_uri"
> Claim Description: OAuth Redirection URI
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: "response_type"
> Claim Description: OAuth Authorization Response type
> Change Controller: IETF
> Specification Document(s): Section 3.1.1 of RFC 6749
>
> Claim Name: "state"
> Claim Description: OAuth state parameter
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: "vtr"
> Claim Description: Vector of Trust request
> Change Controller: IESG
> Specification Document(s): Section 4.1 of RFC 8485
>
> > Relatedly, using "application/jwt" as the Content-type of the
> > HTTP response from dereferencing the request_uri with no explicit
> > indication of the type/profile of JWT used (whether in the content type
> > or in the JWT claims themselves) gives some risk of misinterpretation o=
f
> > the content..  Consider, for example, when that request_uri is
> > dereferenced not by the authorization server in the process of
> > fulfilling an authorization request, but instead by some other service
> > that expects a different type of JWT.
>
> I am making the change to "application/oauth-authz-req+jwt" and add IANA
> request.
>
> >
> > This second point is a "discuss discuss" -- it's an important question
> > and I'd like to talk about it, but it's not clear that any change to th=
e
> > document will be needed.
> >
> > The introduction notes as an advantage of JWT that:
> >
> >    (d)  (collection minimization) The request can be signed by a third
> >         party attesting that the authorization request is compliant wit=
h
> >         a certain policy.  For example, a request can be pre-examined b=
y
> >         a third party that all the personal data requested is strictly
> >         necessary to perform the process that the end-user asked for,
> >         and statically signed by that third party.  The authorization
> >         server then examines the signature and shows the conformance
> >         status to the end-user, who would have some assurance as to the
> >         legitimacy of the request when authorizing it.  In some cases,
> >         it may even be desirable to skip the authorization dialogue
> >         under such circumstances.
> >
> > I'm pretty uncomfortable about suggesting that the authorization
> > dialogue can/should be skipped; do we need to keep this example?
> >
>
> I have actually deliberately put this text as there seem to be some
> disconnect between the engineering community and the privacy regulators
> community. Asking for "consent" is something that should be considered as
> an exception and should use other lawful basis if possible as UK ICO (The
> data protection regulator in the UK) advises. As the editor of "ISO/IEC
> 29184 Privacy notice and consent", which is being developed with close
> coordination with regulators such as European Data Protection Board, I
> would have to agree to that position and I took OAuth JAR as one of the
> opportunity to call it out. I will add some text explaining it such as:
>
> In some cases, it is deemed harmful to ask for consent when it is not
> necessary: i.e., the processing is performed under other lawful basis tha=
n
> consent, as it would make the consent, that should be an exception, stand
> out less. Under such circumstances, this mechanism can be used to skip th=
e
> authorization dialogue.
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1
> >
> >    While it is easy to implement, the encoding in the URI does not allo=
w
> >    application layer security with confidentiality and integrity
> >    protection to be used.  While TLS is used to offer communication
> >
> > nit: this wording is a little hard to read; it might be easier to
> > reorder to "does not allow application layer security to be used to
> > provide confidentiality and integrity protection".
>
> Thanks. I will make the change.
>
> >
> >    The use of application layer security allows requests to be prepared
> >    by a third party so that a client application cannot request more
> >    permissions than previously agreed.  This offers an additional degre=
e
> >    of privacy protection.
> >
> > (side note) what would an example of such a third party be.  (We alread=
y
> > have the resource owner, the client, and the authorization server ...
> > maybe it's a fourth party?)
>
> It is a fourth party, e.g., a trust framework provider or an information
> fiduciary.
> The text need to be modified though as I found an error.
> Since now all the OAuth Request parameters must be in the request object,
> only the pattern that can be supported for something like this is to push
> the request object to the TFP and have the TFP check if it meets the poli=
cy
> and return request_uri only it is evelauted as OK.
>
> >
> >    Furthermore, the request by reference allows the reduction of over-
> >    the-wire overhead.
> >
> > We only barely mentioned by-reference at this point (one line in the
> > Abstract), so I'd suggest "passing the request by reference".
>
> Thanks. I will make the change.
>
> >
> >    (4)  its development status that it is an RFC and so is its
> >         associated signing and encryption methods as [RFC7515] and
> >         [RFC7516]
> >
> > nit: I'd suggest "its development status as a Proposed Standard, along
> > with the associated signing and encryption methods [RFC7515] [RFC7516].=
"
>
> Thanks. I will make the change.
>
> >
> >    (c)  (confidentiality protection) The request can be encrypted so
> >         that end-to-end confidentiality can be provided even if the TLS
> >         connection is terminated at one point or another.
> >
> > nit: TLS is always terminated at or before the user-agent, though.  So
> > maybe the user agent needs to get called out here as well (there could
> > of course be TLS termination earlier than the user-agent in some cases,
> > too).
>
> Thanks. I will make the change.
>
> >
> >    2.  When the client does not want to do the crypto.  The
> >        Authorization Server may provide an endpoint to accept the
> >        Authorization Request through direct communication with the
> >        Client so that the Client is authenticated and the channel is TL=
S
> >        protected.
> >
> > How can you "not want to do [the] crypto" but still be doing TLS (with
> > crypto)?  Perhaps we're looking for "not want to pay the additional
> > overhead of JWS/JWE cryptography on top of TLS"?
>
> Thanks. I will make the change.
>
> >
> > Section 1.1
> >
> > RFC 8174 has updated BCP 14 boilerplate text to use.
>
> Thanks. I will make the change.
>
> >
> > Section 3
> >
> > nit: should this section be 2.3 to get wrapped into "terminology"?
>
> It could, but I suppose it could be as is.
>
> >
> > It might also be worth putting references in for the terms, though they
> > are largely common knowledge at this point.
>
> Hopefully, they are public knowledge ...
>
> >
> > Section 4
> >
> >    A Request Object (Section 2.1) is used to provide authorization
> >    request parameters for an OAuth 2.0 authorization request.  It MUST
> >    contains all the OAuth 2.0 [RFC6749] authorization request parameter=
s
> >    including extension parameters.  The parameters are represented as
> >
> > nit: "all the parameters" kind of sounds like "all that are defined"..
> > But I think the intent here is "any parameter used to process the
> > request must come from the request object and URL query parameters are
> > ignored", so maybe "MUST contain all the parameters (including extensio=
n
> > parameters) used to process the OAuth 2.0 [RFC6749] authorization
> > request; parameters from other sources MUST NOT be used", akin to what
> > we say down in Sections 5 and 6.3..
> > But we need to be careful about the wording to not exclude the usage of
> > the "request" and "request_uri" query parameters to  find the Request
> > Object!
>
> Thanks. I will make the description more exact.
>
> >
> >    the JWT claims.  Parameter names and string values MUST be included
> >
> > nit: maybe "the JWT claims of the object"?
>
> Thanks. I will probably make it "the JWT claims of the request object."
>
> >
> >    any extension parameters.  This JSON [RFC7159] constitutes the JWT
> >    Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
> >    signed or signed and encrypted.
> >
> > nit: I  think we want "This JSON [RFC7159] object".
>
> Thanks. I will fix it as suggested.
>
> >
> > (Long quote incoming)
> >
> >    The following is an example of the Claims in a Request Object before
> >    base64url encoding and signing.  Note that it includes extension
> >    variables such as "nonce" and "max_age".
> >
> >      {
> >       "iss": "s6BhdRkqt3",
> >       "aud": "https://server..example.com "=
,
> >       "response_type": "code id_token",
> >       "client_id": "s6BhdRkqt3",
> >       "redirect_uri": "https://client..example.org/cb
> ",
> >       "scope": "openid",
> >       "state": "af0ifjsldkj",
> >       "nonce": "n-0S6_WzA2Mj",
> >       "max_age": 86400
> >      }
> >
> >    Signing it with the "RS256" algorithm results in this Request Object
> >    value (with line wraps within values for display purposes only):
> >
> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
> >
> > Decoding the base64 of the body, we see:
> > {
> >  "iss": "s6BhdRkqt3",
> >  "aud": "https://server.example.com",
> >  "response_type": "code id_token",
> >  "client_id": "s6BhdRkqt3",
> >  "redirect_uri": "https://client.example.org/cb
> ",
> >  "scope": "openid",
> >  "state": "af0ifjsldkj",
> >  "nonce": "n-0S6_WzA2Mj",
> >  "max_age": 86400,
> >  "claims":
> >   {
> >    "userinfo":
> >     {
> >      "given_name": {"essential": true},
> >      "nickname": null,
> >      "email": {"essential": true},
> >      "email_verified": {"essential": true},
> >      "picture": null
> >     },
> >    "id_token":
> >     {
> >      "gender": null,
> >      "birthdate": {"essential": true},
> >      "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> >     }
> >   }
> > }
> >
> > I'm not sure where the "claims" claim is coming from -- 6749 doesn't
> > seem to talk about it.  (Note that this example is used later on as
> > well.)
>
> It is an extension parameter that is registered in the OAuth authorizatio=
n
> request registry.
> It is defined in OpenID Connect Core and OIDF is in the process of
> registering it to the JWT Claims registry as well. I have put them to sho=
w
> that extension parameters can also be used in the request object. Having
> said that, they may be confusing. I should just remove them.
>
> >
> > Section 5.2.1
> >
> >    It is possible for the Request Object to include values that are to
> >    be revealed only to the Authorization Server.  As such, the
> >    "request_uri" MUST have appropriate entropy for its lifetime.  For
> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].  It is RECOMMENDED
> >    that it be removed after a reasonable timeout unless access control
> >    measures are taken.
> >
> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might
> > also be useful.
> >
>
> Thanks. I will add it.
>
> > Section 5.2.2
> >
> > Do we want to remind the reader that the other query parameters are jus=
t
> > for backwards compatibility?
>
> It is probably be better to remove them as they are not allowed to be
> used.
>
> >
> > Section 5.2.3
> >
> >    The following is an example of this fetch process:
> >
> >      GET /request.jwt HTTP/1.1
> >      Host: tfp.example.org
> >
> > It's useful to show good hygeine in examples; can we get the extra
> > entropy in this request that we have in the previous example(s)?
>
> Thanks for pointing out. I will fix it. (The previous example also needs
> to be changed.)
>
> >
> > Section 6.2
> >
> >    The Authorization Server MUST perform the signature validation of th=
e
> >    JSON Web Signature [RFC7515] signed request object.  For this, the
> >    "alg" Header Parameter in its JOSE Header MUST match the value of th=
e
> >    pre-registered algorithm..  The signature MUST be validated against
> >    the appropriate key for that "client_id" and algorithm.
> >
> > Does "the pre-registered algorithm" concept exist in the specs outside
> > of draft-ietf-oauth-jwt-bcp?
>
> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
> Metadata registry forms the concept. RFC7591 allows clients to register t=
he
> claims that is in the OAuth Dynamic Client Registration Metadata registry

--_000_TYAPR01MB4413256F202E0FCA83735F36F9C20TYAPR01MB4413jpnp_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable















Brian, 







You are the expert on the particular IANA regi=
stries so I probably are missing something.








I was thinking that registering JWT claims to =
OAuth registry is sufficient till seeing Ben=1B$B!G=1B(Bs comment, and I wa=
s tracking that it is being done by Mike as part of the errata process for =
OIDC Core. However, after reading Ben=1B$B!G=1B(Bs comment
 that mentioning the OAuth extensions, and I checked that quite a few claim=
s are now being registered to JWT Claims Registry from outside the OAuth co=
mmunity, I started to feel that it may not be sufficient. But I must be mis=
sing something as you point out
 that is still sufficient. 







Could you please explain how the collision bet=
ween the future OAuth extension and JWT claims can be avoided by registerin=
g main JWT claims to the OAuth Parameter registry?



If that is the case, I am all for it as then w=
e do not get back to IANA process.








Best, 







Nat











Nat Sakimura | =1B$B:jB<2FI'=1B(B 


Nomura Research Institute







=1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$=
5$l$?5!L)>pJs$,4^$^$l$F$$$k>l9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"Aw?.e$2$^$9!=
#=1B(B







PLEASE READ=1B$B!'=1B(BThis e-mail is confiden=
tial and intended for the named recipient only. If you are not an intended =
recipient, please notify the sender and delete this e-mail.













=1B$B:9=3DP?M=1B(B: Brian=
 Campbell <bcampbell@pingidentity.com>

=1B$BAw?.F|;~=1B(B: Saturday, July 27, 2019 5:47:15 AM

=1B$B08@h=1B(B: Nat Sakimura <sakimura@gmail.com>

CC: Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-oauth-jwsreq@ie=
tf.org <draft-ietf-oauth-jwsreq@ietf.org>; oauth-chairs@ietf.org <=
oauth-chairs@ietf.org>; The IESG <iesg@ietf.org>; oauth <oauth@=
ietf.org>

=1B$B7oL>=1B(B: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-iet=
f-oauth-jwsreq-19: (with DISCUSS and COMMENT)

 







Nat, you suggest that the "simplest solution =
probably is to register the

authorization request parameters to the JWT Claims registry." However,=
 as

I've attempted to articulate several times this week (

https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBS=
tRtcs and

muliple comments on https://bitbucket.org/openid/connect/issues/1019) and

even back in 2017 (

https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquP=
EyigY), I

believe the pragmatic solution to this is to register some of the main JWT<=
br>
claims into the OAuth parameters registry (not the other way around, as

you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an=


authorization request parameter "aud", which would conflicted wit=
h the JWT

claim of the same name and cause big problems when used together with JAR).=


I suppose the iron clad way to "fix" this would be to merge the t=
wo

registries and keep them in sync forever. But that seems awfully heavy

handed and unnecessary. JAR is a specific application of JWT being used to<=
br>
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely

point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization

request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's

necessary or even useful to pollute the JWT claims registry with the names<=
br>
of all the authorization request parameters. I happen to be one of the DEs<=
br>
on the JWT claims registry so, in theory, I have some idea what I'm talking=


about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of

authorization request parameters into the JWT claims registry without

without more compelling reason.



On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <sakimura@gmail.com> wr=
ote:



>

> Thanks very much for the comments.

> Here are my responses to your comments.

>

> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <

> noreply@ietf.org> wrote:

> >

> > Benjamin Kaduk has entered the following ballot position for

> > draft-ietf-oauth-jwsreq-19: Discuss

> >

> > When responding, please keep the subject line intact and reply to=
 all

> > email addresses included in the To and CC lines. (Feel free to cu=
t this

> > introductory paragraph, however.)

> >

> >

> > Please refer to

> =
https://www.ietf.org/iesg/statement/discuss-criteria.html

> > for more information about IESG DISCUSS and COMMENT positions.
> >

> >

> > The document, along with other ballot positions, can be found her=
e:

> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

> >

> >

> >

> > -----------------------------------------------------------------=
-----

> > DISCUSS:

> > -----------------------------------------------------------------=
-----

> >

> > My apologies; my previous position was incomplete.  Updated =
to note

> > namespacing issues, and one minor terminology nit about "DNS=
-ID".

> >

> > There seem to be some pretty serious namespacing issues that are =
not

> > discussed at all in this document.  Specifically, using JWT =
as a

> > container for OAuth 2.0 authorization request parameters (includi=
ng

> > extension parameters) introduces the usage of many new names (of =
JSON

> > name/value pairs) into the JWT claims namespace.  Furthermor=
e, the

> > addition is not bounded, as any new OAuth extension parameters ar=
e

> > implicitly permitted to be used as well!  The IANA Considera=
tions make

> > no mention of the collapsed namespace for JWT claims and OAuth 2.=
0

> > (authorization request) parameters, leaving substantial potential=
 for

> > collisions in the future.

>

> The simplest solution probably is to register the authorization reques=
t

> parameters to the JWT Claims registry.

> According to my checking, the relevant but not yet registered paramete=
rs

> are:

>

> Claim Name: "code_challenge"

> Claim Description: OAuth PKCE Code Challenge

> Change Controller: IESG

> Specification Document(s): Section 3 of RFC 7636

>

> Claim Name: "code_challenge_method"

> Claim Description: OAuth PKCE Code Challenge

> Change Controller: IESG

> Specification Document(s): Section 3 of RFC 7636

>

> Claim Name: "redirect_uri"

> Claim Description: OAuth Redirection URI

> Change Controller: IETF

> Specification Document(s): Section 4.1.1 of RFC 6749

>

> Claim Name: "response_type"

> Claim Description: OAuth Authorization Response type

> Change Controller: IETF

> Specification Document(s): Section 3.1.1 of RFC 6749

>

> Claim Name: "state"

> Claim Description: OAuth state parameter

> Change Controller: IETF

> Specification Document(s): Section 4.1.1 of RFC 6749

>

> Claim Name: "vtr"

> Claim Description: Vector of Trust request

> Change Controller: IESG

> Specification Document(s): Section 4.1 of RFC 8485

>

> > Relatedly, using "application/jwt" as the Content-type =
of the

> > HTTP response from dereferencing the request_uri with no explicit=


> > indication of the type/profile of JWT used (whether in the conten=
t type

> > or in the JWT claims themselves) gives some risk of misinterpreta=
tion of

> > the content..  Consider, for example, when that request_uri =
is

> > dereferenced not by the authorization server in the process of
> > fulfilling an authorization request, but instead by some other se=
rvice

> > that expects a different type of JWT.

>

> I am making the change to "application/oauth-authz-req+jwt&qu=
ot; and add IANA

> request.

>

> >

> > This second point is a "discuss discuss" -- it's an imp=
ortant question

> > and I'd like to talk about it, but it's not clear that any change=
 to the

> > document will be needed.

> >

> > The introduction notes as an advantage of JWT that:

> >

> >    (d)  (collection minimization) The request=
 can be signed by a third

> >         party attesting t=
hat the authorization request is compliant with

> >         a certain policy.=
  For example, a request can be pre-examined by

> >         a third party tha=
t all the personal data requested is strictly

> >         necessary to perf=
orm the process that the end-user asked for,

> >         and statically si=
gned by that third party.  The authorization

> >         server then exami=
nes the signature and shows the conformance

> >         status to the end=
-user, who would have some assurance as to the

> >         legitimacy of the=
 request when authorizing it.  In some cases,

> >         it may even be de=
sirable to skip the authorization dialogue

> >         under such circum=
stances.

> >

> > I'm pretty uncomfortable about suggesting that the authorization<=
br>
> > dialogue can/should be skipped; do we need to keep this example?<=
br>
> >

>

> I have actually deliberately put this text as there seem to be some
> disconnect between the engineering community and the privacy regulator=
s

> community. Asking for "consent" is something that should be =
considered as

> an exception and should use other lawful basis if possible as UK ICO (=
The

> data protection regulator in the UK) advises. As the editor of "I=
SO/IEC

> 29184 Privacy notice and consent", which is being developed with =
close

> coordination with regulators such as European Data Protection Board, I=


> would have to agree to that position and I took OAuth JAR as one of th=
e

> opportunity to call it out. I will add some text explaining it such as=
:

>

> In some cases, it is deemed harmful to ask for consent when it is not<=
br>
> necessary: i.e., the processing is performed under other lawful basis =
than

> consent, as it would make the consent, that should be an exception, st=
and

> out less. Under such circumstances, this mechanism can be used to skip=
 the

> authorization dialogue.

>

> >

> > -----------------------------------------------------------------=
-----

> > COMMENT:

> > -----------------------------------------------------------------=
-----

> >

> > Section 1

> >

> >    While it is easy to implement, the encoding in =
the URI does not allow

> >    application layer security with confidentiality=
 and integrity

> >    protection to be used.  While TLS is used =
to offer communication

> >

> > nit: this wording is a little hard to read; it might be easier to=


> > reorder to "does not allow application layer security to be =
used to

> > provide confidentiality and integrity protection".

>

> Thanks. I will make the change.

>

> >

> >    The use of application layer security allows re=
quests to be prepared

> >    by a third party so that a client application c=
annot request more

> >    permissions than previously agreed.  This =
offers an additional degree

> >    of privacy protection.

> >

> > (side note) what would an example of such a third party be. =
 (We already

> > have the resource owner, the client, and the authorization server=
 ...

> > maybe it's a fourth party?)

>

> It is a fourth party, e.g., a trust framework provider or an informati=
on

> fiduciary.

> The text need to be modified though as I found an error.

> Since now all the OAuth Request parameters must be in the request obje=
ct,

> only the pattern that can be supported for something like this is to p=
ush

> the request object to the TFP and have the TFP check if it meets the p=
olicy

> and return request_uri only it is evelauted as OK.

>

> >

> >    Furthermore, the request by reference allows th=
e reduction of over-

> >    the-wire overhead.

> >

> > We only barely mentioned by-reference at this point (one line in =
the

> > Abstract), so I'd suggest "passing the request by reference&=
quot;.

>

> Thanks. I will make the change.

>

> >

> >    (4)  its development status that it is an =
RFC and so is its

> >         associated signin=
g and encryption methods as [RFC7515] and

> >         [RFC7516]

> >

> > nit: I'd suggest "its development status as a Proposed Stand=
ard, along

> > with the associated signing and encryption methods [RFC7515] [RFC=
7516]."

>

> Thanks. I will make the change.

>

> >

> >    (c)  (confidentiality protection) The requ=
est can be encrypted so

> >         that end-to-end c=
onfidentiality can be provided even if the TLS

> >         connection is ter=
minated at one point or another.

> >

> > nit: TLS is always terminated at or before the user-agent, though=
.  So

> > maybe the user agent needs to get called out here as well (there =
could

> > of course be TLS termination earlier than the user-agent in some =
cases,

> > too).

>

> Thanks. I will make the change.

>

> >

> >    2.  When the client does not want to do th=
e crypto.  The

> >        Authorization Server ma=
y provide an endpoint to accept the

> >        Authorization Request t=
hrough direct communication with the

> >        Client so that the Clie=
nt is authenticated and the channel is TLS

> >        protected.

> >

> > How can you "not want to do [the] crypto" but still be =
doing TLS (with

> > crypto)?  Perhaps we're looking for "not want to pay th=
e additional

> > overhead of JWS/JWE cryptography on top of TLS"?

>

> Thanks. I will make the change.

>

> >

> > Section 1.1

> >

> > RFC 8174 has updated BCP 14 boilerplate text to use.

>

> Thanks. I will make the change.

>

> >

> > Section 3

> >

> > nit: should this section be 2.3 to get wrapped into "termino=
logy"?

>

> It could, but I suppose it could be as is.

>

> >

> > It might also be worth putting references in for the terms, thoug=
h they

> > are largely common knowledge at this point.

>

> Hopefully, they are public knowledge ...

>

> >

> > Section 4

> >

> >    A Request Object (Section 2.1) is used to provi=
de authorization

> >    request parameters for an OAuth 2.0 authorizati=
on request.  It MUST

> >    contains all the OAuth 2.0 [RFC6749] authorizat=
ion request parameters

> >    including extension parameters.  The param=
eters are represented as

> >

> > nit: "all the parameters" kind of sounds like "all=
 that are defined"..

> > But I think the intent here is "any parameter used to proces=
s the

> > request must come from the request object and URL query parameter=
s are

> > ignored", so maybe "MUST contain all the parameters (in=
cluding extension

> > parameters) used to process the OAuth 2.0 [RFC6749] authorization=


> > request; parameters from other sources MUST NOT be used", ak=
in to what

> > we say down in Sections 5 and 6.3..

> > But we need to be careful about the wording to not exclude the us=
age of

> > the "request" and "request_uri" query paramet=
ers to  find the Request

> > Object!

>

> Thanks. I will make the description more exact.

>

> >

> >    the JWT claims.  Parameter names and strin=
g values MUST be included

> >

> > nit: maybe "the JWT claims of the object"?

>

> Thanks. I will probably make it "the JWT claims of the request ob=
ject."

>

> >

> >    any extension parameters.  This JSON [RFC7=
159] constitutes the JWT

> >    Claims Set defined in JWT [RFC7519].  The =
JWT Claims Set is then

> >    signed or signed and encrypted.

> >

> > nit: I  think we want "This JSON [RFC7159] object"=
.

>

> Thanks. I will fix it as suggested.

>

> >

> > (Long quote incoming)

> >

> >    The following is an example of the Claims in a =
Request Object before

> >    base64url encoding and signing.  Note that=
 it includes extension

> >    variables such as "nonce" and "m=
ax_age".

> >

> >      {

> >       "iss": "s6BhdR=
kqt3",

> >       "aud": "https://server..example.com <https://server.example.com>",

> >       "response_type": &q=
uot;code id_token",

> >       "client_id": "=
s6BhdRkqt3",

> >       "redirect_uri": &qu=
ot;https://client..example.org/cb

> <https://client.example.o=
rg/cb>",

> >       "scope": "open=
id",

> >       "state": "af0i=
fjsldkj",

> >       "nonce": "n-0S=
6_WzA2Mj",

> >       "max_age": 86400
> >      }

> >

> >    Signing it with the "RS256" algorithm=
 results in this Request Object

> >    value (with line wraps within values for displa=
y purposes only):

> >

> >      eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmR=
jIn0.ew0KICJpc3MiOiAiczZCaGRSa3

> >      F0MyIsDQogImF1ZCI6ICJodHRwczovL3Nlc=
nZlci5leGFtcGxlLmNvbSIsDQogInJl

> >      c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2t=
lbiIsDQogImNsaWVudF9pZCI6ICJzNk

> >      JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpI=
jogImh0dHBzOi8vY2xpZW50LmV4YW1w

> >      bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3B=
lbmlkIiwNCiAic3RhdGUiOiAiYWYwaW

> >      Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTN=
l9XekEyTWoiLA0KICJtYXhfYWdlIjog

> >      ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQo=
gICAidXNlcmluZm8iOiANCiAgICB7DQ

> >      ogICAgICJnaXZlbl9uYW1lIjogeyJlc3Nlb=
nRpYWwiOiB0cnVlfSwNCiAgICAgIm5p

> >      Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWl=
sIjogeyJlc3NlbnRpYWwiOiB0cnVlfS

> >      wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjoge=
yJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg

> >      ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw=
NCiAgICJpZF90b2tlbiI6IA0KICAgIH

> >      sNCiAgICAgImdlbmRlciI6IG51bGwsDQogI=
CAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu

> >      dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjo=
geyJ2YWx1ZXMiOiBbInVybjptYWNlOm

> >      luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgI=
CB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs

> >      F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8e=
PrGhw_trPYs8KQxsn6R9Emo_wHwajyF

> >      KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7=
PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx

> >      0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7i=
GOCRB3btfJhM0_AKQUfqKnRlrRscc8K

> >      ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7=
CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG

> >      iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1=
jpspnTSD7xMbpL-2QgwUsAlMGzw

> >

> > Decoding the base64 of the body, we see:

> > {

> >  "iss": "s6BhdRkqt3",

> >  "aud": "https://server.example.com",

> >  "response_type": "code id_token",

> >  "client_id": "s6BhdRkqt3",

> >  "redirect_uri": "https://cl=
ient.example.org/cb

> <https://client..example=
.org/cb>",

> >  "scope": "openid",

> >  "state": "af0ifjsldkj",

> >  "nonce": "n-0S6_WzA2Mj",

> >  "max_age": 86400,

> >  "claims":

> >   {

> >    "userinfo":

> >     {

> >      "given_name": {"esse=
ntial": true},

> >      "nickname": null,

> >      "email": {"essential=
": true},

> >      "email_verified": {"=
essential": true},

> >      "picture": null

> >     },

> >    "id_token":

> >     {

> >      "gender": null,

> >      "birthdate": {"essen=
tial": true},

> >      "acr": {"values"=
;: ["urn:mace:incommon:iap:silver"]}

> >     }

> >   }

> > }

> >

> > I'm not sure where the "claims" claim is coming from --=
 6749 doesn't

> > seem to talk about it.  (Note that this example is used late=
r on as

> > well.)

>

> It is an extension parameter that is registered in the OAuth authoriza=
tion

> request registry.

> It is defined in OpenID Connect Core and OIDF is in the process of

> registering it to the JWT Claims registry as well. I have put them to =
show

> that extension parameters can also be used in the request object. Havi=
ng

> said that, they may be confusing. I should just remove them.

>

> >

> > Section 5.2.1

> >

> >    It is possible for the Request Object to includ=
e values that are to

> >    be revealed only to the Authorization Server.&n=
bsp; As such, the

> >    "request_uri" MUST have appropriate e=
ntropy for its lifetime.  For

> >    the guidance, refer to 5.1.4.2.2 of [RFC6819].&=
nbsp; It is RECOMMENDED

> >    that it be removed after a reasonable timeout u=
nless access control

> >    measures are taken.

> >

> > It sounds like a link to https://www.w3.org/TR/capability-urls/ might

> > also be useful.

> >

>

> Thanks. I will add it.

>

> > Section 5.2.2

> >

> > Do we want to remind the reader that the other query parameters a=
re just

> > for backwards compatibility?

>

> It is probably be better to remove them as they are not allowed to be<=
br>
> used.

>

> >

> > Section 5.2.3

> >

> >    The following is an example of this fetch proce=
ss:

> >

> >      GET /request.jwt HTTP/1.1

> >      Host: tfp.example.org

> >

> > It's useful to show good hygeine in examples; can we get the extr=
a

> > entropy in this request that we have in the previous example(s)?<=
br>
>

> Thanks for pointing out. I will fix it. (The previous example also nee=
ds

> to be changed.)

>

> >

> > Section 6.2

> >

> >    The Authorization Server MUST perform the signa=
ture validation of the

> >    JSON Web Signature [RFC7515] signed request obj=
ect.  For this, the

> >    "alg" Header Parameter in its JOSE He=
ader MUST match the value of the

> >    pre-registered algorithm..  The signature =
MUST be validated against

> >    the appropriate key for that "client_id&qu=
ot; and algorithm.

> >

> > Does "the pre-registered algorithm" concept exist in th=
e specs outside

> > of draft-ietf-oauth-jwt-bcp?

>

> Yes. RFC7591 combined with some of the OAuth Dynamic Client Registrati=
on

> Metadata registry forms the concept. RFC7591 allows clients to registe=
r the

> claims that is in the OAuth Dynamic Client Registration Metadata regis=
try





--_000_TYAPR01MB4413256F202E0FCA83735F36F9C20TYAPR01MB4413jpnp_--


From nobody Mon Jul 29 08:49: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 5E4FF12013D for ; Mon, 29 Jul 2019 08:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ReS9iXZVZbpQ for ; Mon, 29 Jul 2019 08:49:06 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBBB1200CC for ; Mon, 29 Jul 2019 08:49:06 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k8so121111514iot.1 for ; Mon, 29 Jul 2019 08:49:06 -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=exky5qScvLGcyd79yGS6XzLB9C/hk4DmHngGuSugqV0=; b=n58e47Avx77R/yacLeT7athwfe3plhH9qcUHTobY2eeqwiE1Sb3t+xcReyjAQctMR8 cKvCd0czXsyBo+kH4cMqc0kI5xeWL3sVrbxOFDwJGLWf6qgp/kLSrB2x5tSb08QPYd62 TX4oZcjSZ1EMDZQ4WqQDrgZV5MK1wtCBAdN4A=
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=exky5qScvLGcyd79yGS6XzLB9C/hk4DmHngGuSugqV0=; b=sEfX0GdOHt2oU70iIM5BRQgchoX3tr9yNdYXP42XW9jWsMnb9KGa13kXNWkR36QaPP 1cj1tPD/GDsTj3QA+dOgfxf44XPoKV8wSB+173HUVnSL7GuXkb/fi74iKXc31cnX+4Ww p5G8RtSoKldG6DJNKyzEJ4iPqdmZlpQsY1OJ1NnMZ+WyMrpboHcK4JW9lstjUTIGSWTh giwxuT9+2dSd/Bcdf4VJ0M0CTlvqf3ZwtK59x/bhvVRUvwr/e8jJAAZYA4qLIUiJ91XP UuVJKxspqtYYYu60EVnrBeQ9m3YF8m3s68v9wNIiiUXjg7MPE4/VI5zLX6T03+zfyg8F +6zQ==
X-Gm-Message-State: APjAAAXd9UJRcYZ6By5yjWBTWZ+aODb7Un9Ay902F+8jKPIMVKrSzOU1 2VXTyhQg8laIFE1fUVE12HMPKzVBhhVqoa2UpI9wBxWU/kSYUqoDw64XUQzyQf09fc7KF8YEQPQ XgKdHCORQTfT6qw==
X-Google-Smtp-Source: APXvYqx78Xick8h2j4FWXtxbntbNmbLivu/QNY+DXrNsxuiOMcvfw9TpiLxPKeKF5SWCs5PKoos6rsgseMHG+fMzIjk=
X-Received: by 2002:a6b:fd10:: with SMTP id c16mr96970978ioi.217.1564415345789;  Mon, 29 Jul 2019 08:49:05 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com>   
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 29 Jul 2019 09:48:39 -0600
Message-ID: 
To: n-sakimura 
Cc: Nat Sakimura , Benjamin Kaduk ,  "draft-ietf-oauth-jwsreq@ietf.org" ,  "oauth-chairs@ietf.org" , The IESG , oauth 
Content-Type: multipart/alternative; boundary="000000000000f7be75058ed3d4b6"
Archived-At: 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Jul 2019 15:49:09 -0000

--000000000000f7be75058ed3d4b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

To be accurate, I'm one of the DEs on the JWT Claims registry
https://www.iana.org/assignments/jwt/jwt.xhtml while Hannes is the DE on
the OAuth Parameters registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pa=
rameters
FWIW.

To completely lock it all down and absolutely avoid collisions in all cases
(all cases that bother to consult the registries anyway), I suppose the two
registries would need to be reconciled and then kept perfectly in sync
going forward. Or even merged into a single super registry. But, to me
anyway, that seems like a huge PITA that's overkill and doesn't account for
the context of use with respect to likelihood of actual collisions.

JAR is a  specific application of JWT that is being used to convey an OAuth
authz request. The collisions that need to be avoided are in that narrow
context. JAR explicitly uses a few core JWT claims (aud, iss) so those need
to be accounted for by registering them as OAuth authorization request
parameters (with some explanation as such).  And one could reasonably
imagine some of the other core claims which are about the token itself
being used as well (exp, iat, nbf, jti, cnf, etc). So those should probably
be accounted for as well.

But most/all of the other JWT claims that have been registered, the SIP
CSeq numeric header field parameter value for example, are highly unlikely
to ever be used in the context of an OAuth authorization request. So won't
be a collision issue in the narrow context of a JWT secured authorization
request.  I think it's unlikely enough to be an issue that I think it's
sufficient to only register the core meta JWT claim names into the OAuth
parameters registry for the authorization request usage location.

True, that's not 100% guaranteed to guard against all collisions. But I
think it's pragmatic trade off that guards against all likly real world
collisions.

And if we are really worried about avoiding it 100% guaranteed all the
time, then JAR should wrap the authorization request parameters in a JSON
object so they have their own effectively distinct namespace. But I realize
that's a major change at this stage. Which leads me back to looking for a
simple(ish) and pragmatic approach to avoiding actual likely collisions.






On Sun, Jul 28, 2019 at 4:18 PM n-sakimura  wrote:

> Brian,
>
> You are the expert on the particular IANA registries so I probably are
> missing something.
>
> I was thinking that registering JWT claims to OAuth registry is sufficien=
t
> till seeing Ben=E2=80=99s comment, and I was tracking that it is being do=
ne by Mike
> as part of the errata process for OIDC Core. However, after reading Ben=
=E2=80=99s
> comment that mentioning the OAuth extensions, and I checked that quite a
> few claims are now being registered to JWT Claims Registry from outside t=
he
> OAuth community, I started to feel that it may not be sufficient. But I
> must be missing something as you point out that is still sufficient.
>
> Could you please explain how the collision between the future OAuth
> extension and JWT claims can be avoided by registering main JWT claims to
> the OAuth Parameter registry?
> If that is the case, I am all for it as then we do not get back to IANA
> process.
>
> Best,
>
> Nat
>
> Nat Sakimura | =E5=B4=8E=E6=9D=91=E5=A4=8F=E5=BD=A6
> Nomura Research Institute
>
>
> =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=
=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=
=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=
=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=
=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=
=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=
=E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3=81=AE=E3=81=86=E3=81=88=E3=80=81=E3=
=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81=
=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=
=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=
=81=BE=E3=81=99=E3=80=82
>
> PLEASE READ=EF=BC=9AThis e-mail is confidential and intended for the name=
d
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
> ------------------------------
> *=E5=B7=AE=E5=87=BA=E4=BA=BA:* Brian Campbell 
> *=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82:* Saturday, July 27, 2019 5:47:15 A=
M
> *=E5=AE=9B=E5=85=88:* Nat Sakimura 
> *CC:* Benjamin Kaduk ; draft-ietf-oauth-jwsreq@ietf.org <
> draft-ietf-oauth-jwsreq@ietf.org>; oauth-chairs@ietf.org <
> oauth-chairs@ietf.org>; The IESG ; oauth 
> *=E4=BB=B6=E5=90=8D:* Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>
> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate several times this week (
> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and
> muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
> even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I
> believe the pragmatic solution to this is to register some of the main JW=
T
> claims into the OAuth parameters registry (not the other way around, as
> you're suggesting which wouldn't even have caught the one name collision
> we've actually had where a draft, more than one actually, wanted to call =
an
> authorization request parameter "aud", which would conflicted with the JW=
T
> claim of the same name and cause big problems when used together with JAR=
).
> I suppose the iron clad way to "fix" this would be to merge the two
> registries and keep them in sync forever. But that seems awfully heavy
> handed and unnecessary. JAR is a specific application of JWT being used t=
o
> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
> (aud, iss) and one could reasonably imagine other core ones being used as
> well (exp, iat, nbf, jti, etc). An authorization request parameter being
> introduced that uses one of those names is far and away the most likely
> point of collision (and has already happened, as noted previously). A new
> JWT claim being introduced that collides with an existing authorization
> request parameter name AND would be used in the context of JAR is far far
> less likely to happen. So unlikely, in fact, that I don't think it's
> necessary or even useful to pollute the JWT claims registry with the name=
s
> of all the authorization request parameters. I happen to be one of the DE=
s
> on the JWT claims registry so, in theory, I have some idea what I'm talki=
ng
> about here. In theory. And I do have to be upfront at this point and say
> that I will push back on a request for registration of a bunch of
> authorization request parameters into the JWT claims registry without
> without more compelling reason.
>
>

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

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


To be accurate, I'm one of the DEs on the JWT Cla=
ims registry https://www.iana.org/assignments/jwt/jwt.xhtml while Han=
nes is the DE on the OAuth Parameters registry https://www.iana.org/assignments/oauth-parameters/oauth-paramet=
ers.xhtml#parameters FWIW.

To completely l=
ock it all down and absolutely avoid collisions in all cases (all cases tha=
t bother to consult the registries anyway), I suppose the two registries wo=
uld need to be reconciled and then kept perfectly in sync going forward. Or=
 even merged into a single super registry. But, to me anyway, that seems li=
ke a huge PITA that's overkill and doesn't account for the context =
of use with respect to likelihood of actual collisions.=C2=A0 =C2=A0 

JAR is a=C2=A0 specific application of JWT that is =
being used to convey an OAuth authz request. The collisions that need to be=
 avoided are in that narrow context. JAR explicitly uses a few core JWT cla=
ims (aud, iss) so those need to be accounted for by registering them as OAu=
th authorization request parameters (with some explanation as such).=C2=A0 =
And one could reasonably imagine some of the other core claims which are ab=
out the token itself being used as well (exp, iat, nbf, jti, cnf, etc). So =
those should probably be accounted for as well. 

But most/all of the other JWT claims that have been registered, the SIP =
CSeq numeric header field parameter value for example, are highly unlikely =
to ever be used in the context of an OAuth authorization request. So won=
9;t be a collision issue in the narrow context of a JWT secured authorizati=
on request.=C2=A0 I think it's unlikely enough to be an issue that I th=
ink it's sufficient to only register the core meta JWT claim names into=
 the OAuth parameters registry for the authorization request usage location=
. 

True, that's not 100% guaranteed to gua=
rd against all collisions. But I think it's pragmatic trade off that gu=
ards against all likly real world collisions.

And =
if we are really worried about avoiding it 100% guaranteed all the time, th=
en JAR should wrap the authorization request parameters in a JSON object so=
 they have their own effectively distinct namespace. But I realize that'=
;s a major change at this stage. Which leads me back to looking for a simpl=
e(ish) and pragmatic approach to avoiding actual likely collisions. 






On =
Sun, Jul 28, 2019 at 4:18 PM n-sakimura <n-sakimura@nri.co.jp> wrote:















Brian, 







You are the expert on the particular IANA regi=
stries so I probably are missing something.








I was thinking that registering JWT claims to =
OAuth registry is sufficient till seeing Ben=E2=80=99s comment, and I was t=
racking that it is being done by Mike as part of the errata process for OID=
C Core. However, after reading Ben=E2=80=99s comment
 that mentioning the OAuth extensions, and I checked that quite a few claim=
s are now being registered to JWT Claims Registry from outside the OAuth co=
mmunity, I started to feel that it may not be sufficient. But I must be mis=
sing something as you point out
 that is still sufficient. 







Could you please explain how the collision bet=
ween the future OAuth extension and JWT claims can be avoided by registerin=
g main JWT claims to the OAuth Parameter registry?



If that is the case, I am all for it as then w=
e do not get back to IANA process.








Best, 







Nat











Nat Sakimura | =E5=B4=8E=E6=9D=91=E5=A4=8F=E5=
=BD=A6 


Nomura Research Institute







=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=
=E3=81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=
=81=AE=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=
=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=
=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=
=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=
=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=
=E9=80=81=E4=BF=A1=E8=80=85=E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3=81=AE=E3=
=81=86=E3=81=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=
=92=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=
=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=
=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82







PLEASE READ=EF=BC=9AThis e-mail is confidentia=
l and intended for the named recipient only. If you are not an intended rec=
ipient, please notify the sender and delete this e-mail.













=E5=B7=AE=E5=87=BA=E4=BA=BA: Brian Campbell <bcampbell@pingi=
dentity.com>

=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: Saturday, July 27, 2019 5:47:1=
5 AM

=E5=AE=9B=E5=85=88: Nat Sakimura <sakimura@gmail.com>

CC: Benjamin Kaduk <kaduk@mit.edu>; draft-ietf-oauth-jwsreq@ietf.org <draft-ietf-oaut=
h-jwsreq@ietf.org>; oauth-chairs@ietf.org <oauth-chairs@ietf.org>; The IESG <iesg@ietf.org>; oauth =
<oauth@ietf.org&=
gt;

=E4=BB=B6=E5=90=8D: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on d=
raft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

=C2=A0







Na=
t, you suggest that the "simplest solution probably is to register the=


authorization request parameters to the JWT Claims registry." However,=
 as

I've attempted to articulate several times this week (

https://mailarchive.ietf.org/arch/msg/oauth/0Een=
xmThjII52SAr9atpBStRtcs and

muliple comments on https://bitbucket.org/openid/connect/issues/1019) and

even back in 2017 (

https://mailarchive.ietf.org/arch/msg/oauth/_E14=
Trqu962cReu3t6FquPEyigY), I

believe the pragmatic solution to this is to register some of the main JWT<=
br>
claims into the OAuth parameters registry (not the other way around, as

you're suggesting which wouldn't even have caught the one name coll=
ision

we've actually had where a draft, more than one actually, wanted to cal=
l an

authorization request parameter "aud", which would conflicted wit=
h the JWT

claim of the same name and cause big problems when used together with JAR).=


I suppose the iron clad way to "fix" this would be to merge the t=
wo

registries and keep them in sync forever. But that seems awfully heavy

handed and unnecessary. JAR is a specific application of JWT being used to<=
br>
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely

point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization

request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it'=
s

necessary or even useful to pollute the JWT claims registry with the names<=
br>
of all the authorization request parameters. I happen to be one of the DEs<=
br>
on the JWT claims registry so, in theory, I have some idea what I'm tal=
king

about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of

authorization request parameters into the JWT claims registry without

without more compelling reason.












<=
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.
--000000000000f7be75058ed3d4b6--


From nobody Mon Jul 29 11:55: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 BD04712001A for ; Mon, 29 Jul 2019 11:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 1_-CKq73-lRb for ; Mon, 29 Jul 2019 11:55:40 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E17120019 for ; Mon, 29 Jul 2019 11:55:40 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id z3so3537573iog.0 for ; Mon, 29 Jul 2019 11:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=3AzDVOhxObXyMnclcqypGrGRPqV5No+KSsZndkKlePU=; b=YTx2lpKvSvhAtZbant8OOPDhV8HfO8nOZe03+3dpKtMrCAiRqB2mAEodOv9TpP0R9N e/OW+Fc9iMexS/IHvGQGZ03RCxlHvSPaPVYW/hI5CepwFkDKp4JZpek3B7F5f9fTXtHb nyJEPH8R2TneYYMO1ubLNg6+GtmW2vsVN56aLAOYqr4bWWxpGYikIT+8VrMqIEsuffAT y6MGLzNvtxv57d+ixYSrJ6kA2TKHQEi+hnFpWzblaqTxL8lUX5dDNqS6NZoafd4E5Ve6 TDId8x6WjcuAXq6gAlVVKtVeJqZgkggLFoBwA+W1dK7l6QH36ODLiBkSo49fk+fN8hDP Ew9g==
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=3AzDVOhxObXyMnclcqypGrGRPqV5No+KSsZndkKlePU=; b=RI4w4bifTjOdMRXxMXosKoCTlv8sJ6rstdBF6P41P+yNrf3c3y40rLNg+foaQUCfcl u4Ey0IOY+1S+GhHMygi6mkYn8vIhtWB03HWPVxXnlt6UH9RflzWLy+ukkuHLPS4nDjqf f6oHwXTOZgPtvNcYcKfW+pXm/HVKldipjrz6lSLm+zVa3tam22QO3jBMXsCw+gf6sRNf vUmbb8IwXzoEjT3/7KsS9YeP7870ERRrnEHSjvxRl5UW6zfx5HoYBbglKaXwQeF5NnIu 3Fe8qNl87da/BIu+badvq0wvpoIVGrMjo7KK2deMg/AfNqUENlasbPYboA7orlm7CT/J K0TQ==
X-Gm-Message-State: APjAAAXSNrN5wPSMKAqGfpjkvawuKncRvVaXH4RrxQTrf47GE6/OpBZ8 W6hZi/558C2t8ZIYKJXDt24bwVyKajvJUiAdCRLGMEUqsn4=
X-Google-Smtp-Source: APXvYqylsObg8dCjUCPOJ90CAmNr1ymUyrmWN0HpyT44QPnfEv7kRHJLQyRYx8c6+WQ9Q7tn62CIKmIP18ksLEGivt8=
X-Received: by 2002:a05:6638:3d2:: with SMTP id r18mr115638154jaq.13.1564426539184;  Mon, 29 Jul 2019 11:55:39 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 29 Jul 2019 14:55:28 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000025383a058ed6701c"
Archived-At: 
Subject: [OAUTH-WG] IETF105 OAuth Meetings Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-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, 29 Jul 2019 18:55:42 -0000

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

All,

Thanks to Aaron, Phil, and Tony we have the following notes for our two
sessions:

Tuesday session:
https://datatracker.ietf.org/meeting/105/materials/minutes-105-oauth-201907231520-00

Friday session:
https://datatracker.ietf.org/meeting/105/materials/minutes-105-oauth-201907261000-01

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

Regards,
 Rifaat

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


All,

Thanks to Aaron, Phil, and Tony we=
 have the following notes for our two sessions:

Tu=
esday session:
=

Friday session:




--00000000000025383a058ed6701c--


From nobody Tue Jul 30 10:34:58 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 8145C1201CB; Tue, 30 Jul 2019 10:34:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant via Datatracker 
To: 
Cc: draft-ietf-oauth-resource-indicators.all@ietf.org, ietf@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Stewart Bryant 
Message-ID: <156450808245.14321.11139106487161414680@ietfa.amsl.com>
Date: Tue, 30 Jul 2019 10:34:42 -0700
Archived-At: 
Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-resource-indicators-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jul 2019 17:34:43 -0000

Reviewer: Stewart Bryant
Review result: Ready

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

For more information, please see the FAQ at

.

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

Summary: A well written document ready for publication.  It has one very minor
nit that needs to be addressed at some point.

Major issues: None

Minor issues: None

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